CPU <> Memory chip communication interface

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.

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

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.

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.

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

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.

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.

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.

I guess these routines could simply loop around and have the cpu looping inside them.

So a simply concept of cpumemory 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 cpumemory chip communication protocols/architectures/techniques like a wire made up of transistors/flipflops/etc to have multiple bits travel across the wire ;)

Bye, Skybuck.

Holy Shit. You really are a cretin.

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

Graham

complex I

understanding

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

The I2C bus is something I can understand :)

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 ;)

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

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.

they

routine

and

three

not a

probably

signal

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.

device.

courseware is

Well it's the thruth I can't help it, go watch the first video of course

The dude says so himself.

Dumbing down things will create more problems on the long run. It's a solution to no where.

Bye, Skybuck.

To succeed as a troll you must be subtle. You had the 'clueless newbie' theme going fairly well until now. Calling MIT material 'dumbed down' whilst pretending not to understand what capacitors and resistors are is being too obvious.

cheers,

Al

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)

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

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