AVR-Chat

Hello everyone,
After just subscribing to AVR-chat I will introduce myself by asking a 
question - hopefully nobody minds.

My upcoming design involves two CPUs that need to share rather large 
areas of memory - both reading and writing. Lately, 32kByte shared mem 
have been considered enough and so I sit and think about how to do it 
using two AVRs.

Dual ported RAM is way too expensive and hard to get (considering that 
128Kx8 can be had in under $1 a pop) and so focus is on stuff like 
628128-70. This is a 128Kx8 SRAM available in SOP-32 with seperate data 
and memory bus pins, /OE and /WE. The data bus is bidirectional and only 
driven during read operations (== /OE low).

Interfacing with an ATmega128 (M128) is usually done using a 74x573 
latch (as outlined in the data sheet) with its ouput always enabled and 
its Latch Enable tied to M128's ALE.

Now comes the tricky part: As soon as I hook up the additional second 
M128 (and corresponding latch), I get logical and electrical problems. 
What bugs me more are the electrical implications. As A7:0 and D7:0 are 
shared on the AVR-side I need to make sure that both AVRs' latches do 
not drive their outputs while one AVR makes a read operation. My idea is 
to tie the latch's /OE from M128s /RD.

There will of course be a software-guided scheme that ensures mutual 
exclusive access to the external SRAM. This includes lower the initial 
stack pointer to use internal SRAM, having interrupt-used variables in 
internal SRAM too and only accessing external RAM explicitly.

But what if one AVR runs amok? Say errant software or hardware failure 
results in a read strobe to SRAM while one AVR lets its latch drive 
D7:0? Then one may drive 0 while one may drive 1 -> high current.
Is it possible and enough to limit the maximum current using series 
resistors that lower the current to less than the absolute maximum 
ratings of all chips? Will this significantly reduce speed?

Did you ever try this or have comments?

Thanks in advance.

-- Philipp

On Mar 20, 2005, at 8:10 AM, Philipp Adelt wrote:

> Dual ported RAM is way too expensive and hard to get (considering that
> 128Kx8 can be had in under $1 a pop) and so focus is on stuff like
> 628128-70. This is a 128Kx8 SRAM available in SOP-32 with seperate data
> and memory bus pins, /OE and /WE. The data bus is bidirectional and 
> only
> driven during read operations (== /OE low).

How fast must each CPU access the shared RAM? Not video speeds, I 
presume?

Then why not consider a serial RAM? Put it on the SPI bus on each CPU. 
Then if you can't accept only one AVR as master the other as slave you 
only have to deal with a voting scheme to determine which AVR gets 
master status.

Would be interested in why you think you need two CPUs rather that one 
CPU twice as fast.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

David Kelly schrieb:
> How fast must each CPU access the shared RAM? Not video speeds, I 
> presume?

This is correct. The speed itself is not that much a problem. But 
latency may become a problem.
Let me give you a short introduction into the idea: The system consists 
of several nodes that are physically attached to each other via a 
proprietary parallel and asynchronous bus that transfers on the order of 
5MBytes/s. As the bus will be completey timing invariant, slow nodes 
(that I count the AVR based ones to) slow down the bus but will work. To 
keep the slowdown small I need to achieve low latencies in transfers 
that incorporate AVR based nodes.

Two AVRs on the board share the load associated with the nodes' tasks. 
One AVR will be responsible for keeping up communication over the 
bus(es). This will be quiet a challenge for a 16MIPS 8bit device but in 
the current state it seems feasible.

The other AVR will do "real system" interaction. A/D, digital I/O with 
synchronous timing and a bunch of calculations upon this data. As this 
will have some tight timing constraints that require interrupt use for 
almost all of the inputs, it will be hard to join both AVRs.

> Then why not consider a serial RAM? Put it on the SPI bus on each CPU. 

An interesting idea. I will have a look at speeds that are achievable. I 
am somewhat concerned that the number of CPU cycles it takes to write a 
set of bytes will be too high, but I'll see.

> Then if you can't accept only one AVR as master the other as slave you 
> only have to deal with a voting scheme to determine which AVR gets 
> master status.

I will have to do this in every case I guess. There will be a simple 
round robin mechanism to ensure mutual exclusive accesses to the 
external RAM on software level.

> Would be interested in why you think you need two CPUs rather that one 
> CPU twice as fast.

Guess most of what I wrote above applies here. In fact, latency and 
number of usuable interrupts are the limiting factors. Number of I/O 
pins (with edge level interrupt) is interesting, too.
Not to forget that I have designed a lot of working real life devices in 
the <=16MHz area but so far have never touched real high speed systems. 
Being a non-electrical engineer I would prefer to keep the board design 
issues simple (and in my area of expertise so far).

Regards,
Philipp

At 02:26 PM 3/27/05 +0200, Philipp Adelt wrote:
>David Kelly schrieb:
> > How fast must each CPU access the shared RAM? Not video speeds, I
> > presume?

<snip>

>Two AVRs on the board share the load associated with the nodes' tasks.
>One AVR will be responsible for keeping up communication over the
>bus(es). This will be quiet a challenge for a 16MIPS 8bit device but in
>the current state it seems feasible.
>
>The other AVR will do "real system" interaction. A/D, digital I/O with
>synchronous timing and a bunch of calculations upon this data. As this
>will have some tight timing constraints that require interrupt use for
>almost all of the inputs, it will be hard to join both AVRs.

It sounds more like an application for a FIFO or a dual port RAM.  FIFO 
would be better for a buffer type scheme and dual-port for a mailbox type 
scheme.  Both types would take care of most of your timing issues without 
much need for additional handshaking.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Robert Adsett schrieb:
> It sounds more like an application for a FIFO or a dual port RAM.  FIFO 
> would be better for a buffer type scheme and dual-port for a mailbox type 
> scheme.  Both types would take care of most of your timing issues without 
> much need for additional handshaking.

Interesting, I didn't think about FIFOs before. Are there any readily 
available and affordable parts that inplement a fifo? The 16x5bits of a 
74x225 that I found in a quick search are not deep enough.
2x FIFO or a mailbox scheme would both be sufficient if something like 
at least 0,5-1Kbytes per direction are available. The more the better, 
of course.

On the dual port RAM search I did a while ago, the available parts from 
one of my standard suppliers were all Cypress chips. 1Kx8 for >5€/piece 
is far beyond a resonable price for my application.

If I go for some more space I come to price regions where a small FPGA 
would be affordable - that would have enough RAM in its logic cells 
alone... (using programmable logic for the board discussed here is not 
an option for political reasons).

Regards,
Philipp

At 09:03 PM 3/28/05 +0200, Philipp Adelt wrote:
>Robert Adsett schrieb:
> > It sounds more like an application for a FIFO or a dual port RAM.  FIFO
> > would be better for a buffer type scheme and dual-port for a mailbox type
> > scheme.  Both types would take care of most of your timing issues without
> > much need for additional handshaking.
>
>Interesting, I didn't think about FIFOs before. Are there any readily
>available and affordable parts that inplement a fifo? The 16x5bits of a
>74x225 that I found in a quick search are not deep enough.
>2x FIFO or a mailbox scheme would both be sufficient if something like
>at least 0,5-1Kbytes per direction are available. The more the better,
>of course.

Depends on what affordable means ;).  Those sizes are certainly available 
though.  TI and Cypress and probably others.  Plain SRAM is almost 
certainly cheaper.  It'll be a build vs but decision, how much is your time 
worth and how many are you building?  That will (should) decide things for you.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/