Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   VHDL (http://www.velocityreviews.com/forums/f18-vhdl.html)
-   -   CPU <> Memory chip communication interface (http://www.velocityreviews.com/forums/t23905-cpu-memory-chip-communication-interface.html)

Skybuck Flying 08-04-2005 09:23 AM

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.



Jonathan Bromley 08-04-2005 10:01 AM

Re: CPU <> Memory chip communication interface
 
On Thu, 4 Aug 2005 11:23:23 +0200, "Skybuck Flying"
<nospam@hotmail.com> 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:jonathan.bromley@doulos.com
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.


Bob Monsen 08-04-2005 07:06 PM

Re: CPU <> Memory chip communication interface
 
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

Skybuck Flying 08-05-2005 02:37 AM

Re: CPU <> Memory chip communication interface
 
> 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.



Bob Monsen 08-05-2005 02:49 AM

Re: CPU <> Memory chip communication interface
 
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

Skybuck Flying 08-05-2005 02:52 AM

Re: CPU <> Memory chip communication interface
 
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 08-05-2005 04:39 AM

Re: CPU <> Memory chip communication interface
 

"Bob Monsen" <rcsurname@comcast.net> wrote in message
news:8uudndJMU45UTm_fRVn-qg@comcast.com...
> 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.co...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_...eral_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.



Pooh Bear 08-05-2005 04:55 AM

Re: CPU <> Memory chip communication interface
 

Skybuck Flying wrote:

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


Holy ****. You really are a cretin.

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

Graham


Bob Monsen 08-05-2005 09:10 AM

Re: CPU <> Memory chip communication interface
 
Skybuck Flying wrote:
> "Bob Monsen" <rcsurname@comcast.net> wrote in message
> news:8uudndJMU45UTm_fRVn-qg@comcast.com...
>
>>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.co...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_...eral_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

Skybuck Flying 08-05-2005 10:10 AM

Re: CPU <> Memory chip communication interface
 

"Bob Monsen" <rcsurname@comcast.net> wrote in message
news:5vmdneq0d61ksW7fRVn-jg@comcast.com...
> Skybuck Flying wrote:
> > "Bob Monsen" <rcsurname@comcast.net> wrote in message
> > news:8uudndJMU45UTm_fRVn-qg@comcast.com...
> >
> >>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.co...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.




All times are GMT. The time now is 06:57 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.