CPU <> Memory chip communication interface

Discussion in 'VHDL' started by Skybuck Flying, Aug 4, 2005.

  1. Hi,

    First I would like to program a simple CPU and Memory chip in pascal/delphi.

    (Maybe a better word for memory chip would be memory controller ?)

    The CPU and Memory chip communicatie in serial bits with each other.

    These serial bits could be commands/addressess which the memory chip can
    understand.

    I would like to program the cpu's microcode with blocking
    routines/functions.

    For example:

    ReadBit( A ); // block until a bit has been read.
    ReadBit( A ); // block until the next bit has been read.
    ReadBit( A ); // block until the next bit has been read.

    WriteBit( B ); // block until a bit has been written.
    WriteBit( B ); // block until the next bit has been written.
    WriteBit( B ); // block until the next bit has been written.

    For simulation purposes the implementation of these routines could be really
    simply to fake communication with the memory chip.

    The question is if these two functions can be implemented two BLOCK in a
    realworld microcode cpu enviroment (cpu's usually work with clocks which
    keep on ticking... ) ?

    Bye,
    Skybuck.
    Skybuck Flying, Aug 4, 2005
    #1
    1. Advertising

  2. On Thu, 4 Aug 2005 11:23:23 +0200, "Skybuck Flying"
    <> wrote:

    >First I would like to program a simple CPU and Memory chip in pascal/delphi.

    [...]

    You're asking all the right questions, but as someone else has said,
    you are asking them in lots of little pieces and you will therefore
    get fragmentary answers and fragmentary understanding.

    You seem to be trying to build an understanding of digital
    electronics, simulation and modelling almost from scratch.
    This is admirable but doomed. PLEASE, PLEASE find out about
    what others have achieved (it's a great deal) in this area.
    Because you have tried to invent the concepts for yourself,
    you will be receptive to the ideas and you will learn very
    quickly, and then you can go on to do creative new stuff.

    Try for these search terms...

    SystemC
    Transaction level modelling
    Untimed functional models
    Bus functional models
    Finite state machines
    Handshake protocols
    Wait states

    Go to www.systemc.org and find what's there. The SystemC
    reference simulator is free, so you can see how its kernel
    is built and how it helps you build interesting simulations.
    SystemC has a highly developed set of ideas about the
    relationship between transaction-level modelling (your
    "read" and "write" actions on a memory are transactions)
    and the behaviour of hardware that works clock by clock,
    "cycle-accurate" modelling. Take a look at the SystemC
    part of our website and see if any of the examples are
    helpful.

    Right now, you are frantically trying to re-invent a
    wheel that's taken five decades to build. It's
    a great way to prepare for learning, but a lousy way
    to get anything useful done.
    --
    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

    Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
    Tel: +44 (0)1425 471223 mail:
    Fax: +44 (0)1425 471573 Web: http://www.doulos.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
    Jonathan Bromley, Aug 4, 2005
    #2
    1. Advertising

  3. Skybuck Flying

    Bob Monsen Guest

    Skybuck Flying wrote:
    > Hi,
    >
    > First I would like to program a simple CPU and Memory chip in pascal/delphi.
    >
    > (Maybe a better word for memory chip would be memory controller ?)
    >
    > The CPU and Memory chip communicatie in serial bits with each other.
    >
    > These serial bits could be commands/addressess which the memory chip can
    > understand.
    >
    > I would like to program the cpu's microcode with blocking
    > routines/functions.
    >
    > For example:
    >
    > ReadBit( A ); // block until a bit has been read.
    > ReadBit( A ); // block until the next bit has been read.
    > ReadBit( A ); // block until the next bit has been read.
    >
    > WriteBit( B ); // block until a bit has been written.
    > WriteBit( B ); // block until the next bit has been written.
    > WriteBit( B ); // block until the next bit has been written.
    >
    > For simulation purposes the implementation of these routines could be really
    > simply to fake communication with the memory chip.
    >
    > The question is if these two functions can be implemented two BLOCK in a
    > realworld microcode cpu enviroment (cpu's usually work with clocks which
    > keep on ticking... ) ?
    >
    > Bye,
    > Skybuck.
    >
    >


    Two protocols you may wish to become familiar with are SPI and I2C. They
    are both serial protocols, which are designed to communicate with
    peripherals. There are memory devices that use both of these (and many
    others...). Many microcontrollers have built-in support of them, meaning
    you can do a 'write' or a 'read', and the microcontroller will handle
    the gory details.

    Now, Pascal is simply a computer language. It can run in a variety of
    environments. However, access to the hardware is generally controlled by
    the operating system. If you are programming on the 'bare metal' as they
    say, then you can do whatever the hell you want. Your "ReadBit" routine
    can simply loop, waiting for the hardware to respond. It can block, and
    let other processes or threads do work while it waits. It can shut off
    the CPU, and wait for an interrupt.

    On the other hand, if you are programming through an OS, which is
    controlling access to the ports, you must use whatever facilities are
    provided by the OS in your "ReadBit()" routine.

    This particular question may be better answered in the embedded software
    newsgroups.

    --
    Regards,
    Bob Monsen

    If a little knowledge is dangerous, where is the man who has
    so much as to be out of danger?
    Thomas Henry Huxley, 1877
    Bob Monsen, Aug 4, 2005
    #3
  4. > the operating system. If you are programming on the 'bare metal' as they
    > say, then you can do whatever the hell you want. Your "ReadBit" routine
    > can simply loop, waiting for the hardware to respond. It can block, and
    > let other processes or threads do work while it waits. It can shut off
    > the CPU, and wait for an interrupt.


    Where can I find an example of this concept on the internet, if any ?

    I don't know how complex this technique is... but if it's not too complex I
    would like
    to see a drawing of the gates required etc, as to get a better understanding
    of
    how it works together with the clock signal etc.

    Bye,
    Skybuck.
    Skybuck Flying, Aug 5, 2005
    #4
  5. Skybuck Flying

    Bob Monsen Guest

    Skybuck Flying wrote:
    >>the operating system. If you are programming on the 'bare metal' as they
    >>say, then you can do whatever the hell you want. Your "ReadBit" routine
    >>can simply loop, waiting for the hardware to respond. It can block, and
    >>let other processes or threads do work while it waits. It can shut off
    >>the CPU, and wait for an interrupt.

    >
    >
    > Where can I find an example of this concept on the internet, if any ?
    >
    > I don't know how complex this technique is... but if it's not too complex I
    > would like
    > to see a drawing of the gates required etc, as to get a better understanding
    > of
    > how it works together with the clock signal etc.
    >
    > Bye,
    > Skybuck.
    >
    >


    There are lots of examples of PIC code which drives I2C or SPI devices.
    Google for "PIC I2C SPI". I got 35,000 hits.

    --
    Regards,
    Bob Monsen

    If a little knowledge is dangerous, where is the man who has
    so much as to be out of danger?
    Thomas Henry Huxley, 1877
    Bob Monsen, Aug 5, 2005
    #5
  6. I guess these routines could simply loop around and have the cpu looping
    inside them.

    So a simply concept of cpu<->memory chip communication could be the
    following:

    one line to indicate information bit is ready/stable
    one line to indicate information bit has been read
    one line for the information bit.

    So a memory chip places the data bit on the information bit line. Then it
    turns ready/stable line to on.
    The cpu sees this and reads the information bit line. Then the cpu turns the
    information bit read line to on.
    The main memory chip turns the ready/stable line off. The cpu turns the
    read line to off.

    And now a transfer of a single bit has occured :)

    And vice versa for the other way around.

    This might be an inefficient way to transfer bits... since if the
    lines/wires are very long it would take a long time for the electrons ;) to
    travel across the wire... but still not bad for a simple concept to work
    with :)

    Later ofcourse the implementation of the read/write functions can be changed
    to use different cpu<->memory chip communication
    protocols/architectures/techniques like a wire made up of
    transistors/flipflops/etc to have multiple bits travel across the wire ;)

    Bye,
    Skybuck.
    Skybuck Flying, Aug 5, 2005
    #6
  7. "Bob Monsen" <> wrote in message
    news:...
    > Skybuck Flying wrote:
    > >>the operating system. If you are programming on the 'bare metal' as they
    > >>say, then you can do whatever the hell you want. Your "ReadBit" routine
    > >>can simply loop, waiting for the hardware to respond. It can block, and
    > >>let other processes or threads do work while it waits. It can shut off
    > >>the CPU, and wait for an interrupt.

    > >
    > >
    > > Where can I find an example of this concept on the internet, if any ?
    > >
    > > I don't know how complex this technique is... but if it's not too

    complex I
    > > would like
    > > to see a drawing of the gates required etc, as to get a better

    understanding
    > > of
    > > how it works together with the clock signal etc.
    > >
    > > Bye,
    > > Skybuck.
    > >
    > >

    >
    > There are lots of examples of PIC code which drives I2C or SPI devices.
    > Google for "PIC I2C SPI". I got 35,000 hits.


    Ok, the PIC description seems a bit to general, too complex, too many
    variations for me to understand ;)

    http://en.wikipedia.org/wiki/PIC_microcontroller

    The I2C bus is something I can understand :)

    http://www.semiconductors.philips.com/markets/mms/protocols/i2c/

    However it seems to be really slow :)

    "
    To begin, the bus has kept pace with performance and today provides three
    levels of data rate transfer: up to 100 kbps in Standard mode, up to 400
    kbps in Fast mode, and up to 3.4 Mbps in High-Speed mode
    "

    That's per second ??

    And ofcourse it uses fixed bit address, 8 bit bytes, and is ment for
    multiple devices on the same bus which might be interesting, but it's not a
    requirement for me at the moment :)

    So first I would have to understand why this thing is so slow... probably
    the electronics or maybe it's the clock rate ? etc...

    Or... is it a physical limitation ?

    So first I would need to understand how fast eletronics and a 0 or 1 signal
    can move across a wire and can be detected by devices, ports etc.

    So first I would need to compare my own idea which is kinda simple to this
    idea...

    So the first question would be: How fast would my alternative idea be with
    the latest and greatest hardware thingies... like gates and stuff and
    resistors.

    The second question would be: How fast would it be if it used
    generally/common available components on the market today ? ;)

    Now on to SPI ;)

    I guess this is the one you mean ;)

    http://en.wikipedia.org/wiki/Serial_Peripheral_Interface

    Ok that's a very general description. Not much use but ok ;) It does explain
    some benefits... like reduced cost ;) and disadvantages slower ;)

    http://embedded.com/showArticle.jhtml?articleID=9900483

    This link is also about SPI and explains it's more suited for data
    streams... ;) instead of addressed stuff ;)

    It's also point to point ;) ( the lack of device addressing means less
    overhead. )

    "
    At a higher level

    SPI does not have an acknowledgement mechanism to confirm receipt of data.
    In fact, without a communication protocol, the SPI master has no knowledge
    of whether a slave even exists. SPI also offers no flow control. If you need
    hardware flow control, you might need to do something outside of SPI.
    "

    Ok, that sounds bad... the text above it also sounds pretty bad... lot's of
    problems.. but hell it was ment for point to point... maybe single device to
    single device... not necessarely single device to multiple devices...

    Anyway both communication methods seems to require/work based on the concept
    of a clock.
    So the cpu and the memory need to run at the same clock speed. If the cpu
    can not keep up.. it would miss important bits ? Sounds a little bit bad ;)
    But then again... since the cpu would be looping around or something like
    that... maybe it wouldn't miss a single bit of everything was timed right :)

    However my cpu might need to talk to multiple devices hmmmm... :) but I
    would simply add more lines :) :p

    Well two nice examples of serial communication. I really need to find out
    the physical limitations of signals across wires first :)

    Bye,
    Skybuck.
    Skybuck Flying, Aug 5, 2005
    #7
  8. Skybuck Flying

    Pooh Bear Guest

    Skybuck Flying wrote:

    > Hi,
    >
    > First I would like to program a simple CPU and Memory chip in pascal/delphi.


    Holy Shit. You really are a cretin.

    May I suggest the 'Ladybird Book of Electronics' to you ? Ohh... maybe you just
    read it ?

    Graham
    Pooh Bear, Aug 5, 2005
    #8
  9. Skybuck Flying

    Bob Monsen Guest

    Skybuck Flying wrote:
    > "Bob Monsen" <> wrote in message
    > news:...
    >
    >>Skybuck Flying wrote:
    >>
    >>>>the operating system. If you are programming on the 'bare metal' as they
    >>>>say, then you can do whatever the hell you want. Your "ReadBit" routine
    >>>>can simply loop, waiting for the hardware to respond. It can block, and
    >>>>let other processes or threads do work while it waits. It can shut off
    >>>>the CPU, and wait for an interrupt.
    >>>
    >>>
    >>>Where can I find an example of this concept on the internet, if any ?
    >>>
    >>>I don't know how complex this technique is... but if it's not too

    >
    > complex I
    >
    >>>would like
    >>>to see a drawing of the gates required etc, as to get a better

    >
    > understanding
    >
    >>>of
    >>>how it works together with the clock signal etc.
    >>>
    >>>Bye,
    >>> Skybuck.
    >>>
    >>>

    >>
    >>There are lots of examples of PIC code which drives I2C or SPI devices.
    >>Google for "PIC I2C SPI". I got 35,000 hits.

    >
    >
    > Ok, the PIC description seems a bit to general, too complex, too many
    > variations for me to understand ;)
    >
    > http://en.wikipedia.org/wiki/PIC_microcontroller
    >
    > The I2C bus is something I can understand :)
    >
    > http://www.semiconductors.philips.com/markets/mms/protocols/i2c/
    >
    > However it seems to be really slow :)
    >


    The advantages of I2C and SPI are that there are already devices that
    use these protocols.

    However, most general purpose computers use a parallel bus to connect to
    the memory controller. There is a hardware protocol, specified by the
    processor, for presenting the address and doing the read or write. This
    is a very fast scheme, but has some inherent flaws, such as signals
    arriving at the destination at different times, ground bounce,
    crosstalk, etc. Improperly terminated memory busses can ring, producing
    data errors.

    There are some new serial ICs that allow one to serialize these parallel
    accesses, but I don't know much about them ( I read an article on them
    in EDN... ;). I believe their primary purpose is to allow the designer
    to bypass the traditional problems of clock and signal skew at higher
    speeds. As I recall, the clock and data are transmitted using some kind
    of manchester encoding scheme (similar to ethernet), so a single
    connection can be used. Special hardware on both sides encodes and
    decodes the data, and presents the 'user' with a parallel interface.

    There are also schemes where multiple of these asynchronous serial
    connections can transmit parts of words, which can then be reassembled
    at some point elsewhere on the board. This is even faster.

    In general, there are an infinite number of answers. I believe you don't
    know enough to ask the right questions. Perhaps a better approach would
    be to describe what it is you are really trying to do, rather than
    asking general, open-ended questions that generate far too much
    information for you to process.

    Sadly, this forum is not very good for obtaining general knowledge. A
    book like "The Art of Electronics" or something like that might be a
    better place to start. An electronics course at your local Junior
    College might also be way to go.

    > "
    > To begin, the bus has kept pace with performance and today provides three
    > levels of data rate transfer: up to 100 kbps in Standard mode, up to 400
    > kbps in Fast mode, and up to 3.4 Mbps in High-Speed mode
    > "
    >
    > That's per second ??
    >
    > And ofcourse it uses fixed bit address, 8 bit bytes, and is ment for
    > multiple devices on the same bus which might be interesting, but it's not a
    > requirement for me at the moment :)
    >
    > So first I would have to understand why this thing is so slow... probably
    > the electronics or maybe it's the clock rate ? etc...
    >
    > Or... is it a physical limitation ?
    >


    The speed limit has to do with the nature of the protocol. It works by
    one of the communicating processors grounding the bus through a
    resistor. However, there is capacitance inherent in any device, and this
    grounding must drain this capacitance. This takes time, proportional to
    the product of the resistance and capacitance.

    > So first I would need to understand how fast eletronics and a 0 or 1 signal
    > can move across a wire and can be detected by devices, ports etc.
    >


    Again, you need a basic course in analog electronics. Try the MIT open
    courseware, which is free. 6002 is a good place to start.

    > So first I would need to compare my own idea which is kinda simple to this
    > idea...
    >


    You don't even understand the problems yet, much less the solutions. I
    understand your desire, but the first step towards competence is first
    finding out what you don't know.

    > So the first question would be: How fast would my alternative idea be with
    > the latest and greatest hardware thingies... like gates and stuff and
    > resistors.
    >
    > The second question would be: How fast would it be if it used
    > generally/common available components on the market today ? ;)
    >
    > Now on to SPI ;)
    >
    > I guess this is the one you mean ;)
    >
    > http://en.wikipedia.org/wiki/Serial_Peripheral_Interface
    >
    > Ok that's a very general description. Not much use but ok ;) It does explain
    > some benefits... like reduced cost ;) and disadvantages slower ;)
    >
    > http://embedded.com/showArticle.jhtml?articleID=9900483
    >
    > This link is also about SPI and explains it's more suited for data
    > streams... ;) instead of addressed stuff ;)
    >
    > It's also point to point ;) ( the lack of device addressing means less
    > overhead. )
    >
    > "
    > At a higher level
    >
    > SPI does not have an acknowledgement mechanism to confirm receipt of data.
    > In fact, without a communication protocol, the SPI master has no knowledge
    > of whether a slave even exists. SPI also offers no flow control. If you need
    > hardware flow control, you might need to do something outside of SPI.
    > "
    >
    > Ok, that sounds bad... the text above it also sounds pretty bad... lot's of
    > problems.. but hell it was ment for point to point... maybe single device to
    > single device... not necessarely single device to multiple devices...
    >
    > Anyway both communication methods seems to require/work based on the concept
    > of a clock.
    > So the cpu and the memory need to run at the same clock speed. If the cpu
    > can not keep up.. it would miss important bits ? Sounds a little bit bad ;)
    > But then again... since the cpu would be looping around or something like
    > that... maybe it wouldn't miss a single bit of everything was timed right :)
    >


    For both of these protocols, the master provides the clock. For I2C,
    there is a mechanism for a slow slave to hold off the master. For SPI,
    there is no such mechanism. It is up to the master to clock the slave at
    a speed the slave can handle.

    > However my cpu might need to talk to multiple devices hmmmm... :) but I
    > would simply add more lines :) :p
    >
    > Well two nice examples of serial communication. I really need to find out
    > the physical limitations of signals across wires first :)
    >
    > Bye,
    > Skybuck.
    >
    >



    --
    Regards,
    Bob Monsen

    If a little knowledge is dangerous, where is the man who has
    so much as to be out of danger?
    Thomas Henry Huxley, 1877
    Bob Monsen, Aug 5, 2005
    #9
  10. "Bob Monsen" <> wrote in message
    news:...
    > Skybuck Flying wrote:
    > > "Bob Monsen" <> wrote in message
    > > news:...
    > >
    > >>Skybuck Flying wrote:
    > >>
    > >>>>the operating system. If you are programming on the 'bare metal' as

    they
    > >>>>say, then you can do whatever the hell you want. Your "ReadBit"

    routine
    > >>>>can simply loop, waiting for the hardware to respond. It can block,

    and
    > >>>>let other processes or threads do work while it waits. It can shut off
    > >>>>the CPU, and wait for an interrupt.
    > >>>
    > >>>
    > >>>Where can I find an example of this concept on the internet, if any ?
    > >>>
    > >>>I don't know how complex this technique is... but if it's not too

    > >
    > > complex I
    > >
    > >>>would like
    > >>>to see a drawing of the gates required etc, as to get a better

    > >
    > > understanding
    > >
    > >>>of
    > >>>how it works together with the clock signal etc.
    > >>>
    > >>>Bye,
    > >>> Skybuck.
    > >>>
    > >>>
    > >>
    > >>There are lots of examples of PIC code which drives I2C or SPI devices.
    > >>Google for "PIC I2C SPI". I got 35,000 hits.

    > >
    > >
    > > Ok, the PIC description seems a bit to general, too complex, too many
    > > variations for me to understand ;)
    > >
    > > http://en.wikipedia.org/wiki/PIC_microcontroller
    > >
    > > The I2C bus is something I can understand :)
    > >
    > > http://www.semiconductors.philips.com/markets/mms/protocols/i2c/
    > >
    > > However it seems to be really slow :)
    > >

    >
    > The advantages of I2C and SPI are that there are already devices that
    > use these protocols.
    >
    > However, most general purpose computers use a parallel bus to connect to
    > the memory controller. There is a hardware protocol, specified by the
    > processor, for presenting the address and doing the read or write. This
    > is a very fast scheme, but has some inherent flaws, such as signals
    > arriving at the destination at different times, ground bounce,
    > crosstalk, etc. Improperly terminated memory busses can ring, producing
    > data errors.
    >
    > There are some new serial ICs that allow one to serialize these parallel
    > accesses, but I don't know much about them ( I read an article on them
    > in EDN... ;). I believe their primary purpose is to allow the designer
    > to bypass the traditional problems of clock and signal skew at higher
    > speeds. As I recall, the clock and data are transmitted using some kind
    > of manchester encoding scheme (similar to ethernet), so a single
    > connection can be used. Special hardware on both sides encodes and
    > decodes the data, and presents the 'user' with a parallel interface.
    >
    > There are also schemes where multiple of these asynchronous serial
    > connections can transmit parts of words, which can then be reassembled
    > at some point elsewhere on the board. This is even faster.
    >
    > In general, there are an infinite number of answers. I believe you don't
    > know enough to ask the right questions. Perhaps a better approach would
    > be to describe what it is you are really trying to do, rather than
    > asking general, open-ended questions that generate far too much
    > information for you to process.
    >
    > Sadly, this forum is not very good for obtaining general knowledge. A
    > book like "The Art of Electronics" or something like that might be a
    > better place to start. An electronics course at your local Junior
    > College might also be way to go.
    >
    > > "
    > > To begin, the bus has kept pace with performance and today provides

    three
    > > levels of data rate transfer: up to 100 kbps in Standard mode, up to 400
    > > kbps in Fast mode, and up to 3.4 Mbps in High-Speed mode
    > > "
    > >
    > > That's per second ??
    > >
    > > And ofcourse it uses fixed bit address, 8 bit bytes, and is ment for
    > > multiple devices on the same bus which might be interesting, but it's

    not a
    > > requirement for me at the moment :)
    > >
    > > So first I would have to understand why this thing is so slow...

    probably
    > > the electronics or maybe it's the clock rate ? etc...
    > >
    > > Or... is it a physical limitation ?
    > >

    >
    > The speed limit has to do with the nature of the protocol. It works by
    > one of the communicating processors grounding the bus through a
    > resistor. However, there is capacitance inherent in any device, and this
    > grounding must drain this capacitance. This takes time, proportional to
    > the product of the resistance and capacitance.
    >
    > > So first I would need to understand how fast eletronics and a 0 or 1

    signal
    > > can move across a wire and can be detected by devices, ports etc.
    > >

    >
    > Again, you need a basic course in analog electronics. Try the MIT open
    > courseware, which is free. 6002 is a good place to start.


    I seek a simple but realistic answer to my question for a real world device.
    If it's not simple then so be it.

    I do not seek a dumbed down version of reality so the MIT open courseware is
    not for me.

    Bye,
    Skybuck.
    Skybuck Flying, Aug 5, 2005
    #10
  11. Skybuck Flying wrote:

    >
    > "Bob Monsen" <> wrote in message
    > news:...
    >> Skybuck Flying wrote:
    >> > "Bob Monsen" <> wrote in message
    >> > news:...


    Hi Skybuck

    [snip]

    >> > So first I would need to understand how fast eletronics and a 0 or 1

    > signal
    >> > can move across a wire



    http://www.google.com/search?hl=en&ie=ISO-8859-1&q=transmission line theory&btnG=Google Search

    >> > and can be detected by devices, ports etc.


    Just off of the top of my head (it's 5.30am here, and I've just done
    a 16 hour day ... are you *sure* you want to move into this field? ;-) )

    Here's some pointers to help with your research:

    (warning, links may have wrapped)

    http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=schmitt trigger&btnG=Search
    http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=transistor switching frequency&btnG=Search
    http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=dynamic current vlsi&btnG=Search
    http://www.google.com/search?q=capacitive load&btnG=Search&hl=en&lr=&ie=ISO-8859-1
    http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=signal to noise ratio&btnG=Search
    http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=ground bounce&btnG=Search
    http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=phase locked loop&btnG=Search
    http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=clock recovery&btnG=Search

    There's a lot more than this, but IO isn't really my core experience.
    Hopefully this will give you a starting point.

    >> >


    [snip]

    >
    > I seek a simple but realistic answer to my question for a real world
    > device. If it's not simple then so be it.
    >
    > I do not seek a dumbed down version of reality so the MIT open courseware
    > is not for me.
    >


    Everything you will ever deal with in electronics, logic, or computer
    architecture is an approximation to some degree. One of the key skills
    is choosing the right approximation for the specific task at hand.

    HTH

    - Derek


    > Bye,
    > Skybuck.
    Derek Gladding, Aug 19, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Skybuck Flying

    Main memory <-> Cpu communication ?

    Skybuck Flying, Aug 2, 2005, in forum: VHDL
    Replies:
    2
    Views:
    1,021
    Jonathan Kirwan
    Aug 2, 2005
  2. Skybuck Flying
    Replies:
    5
    Views:
    1,696
    Pooh Bear
    Aug 5, 2005
  3. Skybuck Flying
    Replies:
    1
    Views:
    522
    Pooh Bear
    Aug 5, 2005
  4. Skybuck Flying
    Replies:
    4
    Views:
    543
    Skybuck Flying
    Aug 5, 2005
  5. pavunkumar

    How , system cpu and user cpu times calculates

    pavunkumar, Feb 27, 2009, in forum: C Programming
    Replies:
    1
    Views:
    351
Loading...

Share This Page