EPROM emulator

steve ravet steve.ravet at arm.com
Mon Feb 15 20:18:30 GMT 1999



Ludis Langens wrote:
> 
> You wrote:
> > 5)  others?
> 
> RAM test.

good idea.

> 
> > It would be nice if 2) and 3) could be done via switches on the board.
> 
> It should also work via a command send down the serial port.

For sure.  Full functionality over the serial port, limited
functionality via buttons and LEDs.

> > Simultaneous access to the same address probably isn't a problem as long
> > as you're only changing the data and not code.
> 
> The specs for the dual port RAM mentioned earlier prohibit accessing the
> same location at the same time from both ports.  In fact, the chip has
> logic to prevent this - the losing side is locked out of the RAM.  This
> isn't a problem if there are two banks - the ECM reads from one, while
> the PIC reads/writes the other.

I read the data sheet and app note for the cypress part.  Simultaneous
reads of the same location are no problem, both ports get the same valid
data.  For situations involving read/write collisions things are more
complicated.  One port wins and one loses.  If the write port loses the
write is lost.  If the read port loses it still might get valid data
depending on the exact timing involved.  For write/write collisions the
write from the losing port is lost.

The only collision we have to worry about is a read/write collision, if
the ECM is trying to read a location that the PIC is trying to update. 
If the PIC wins the ECM might or might not get bad data, but it's
probably not important as long as we stick to modifying data and not
code.  If the ECM wins the PIC will get a BUSY from the ram, and it can
try again a little later.

Having 2 physical banks of RAM leads to coherency problems.  How do you
make sure that both RAMs are kept the same?  You could require the
software to switch RAMs after every write, and duplicate the write for
the second RAM.  But then what if you use the buttons to switch RAMs and
the PC doesn't know about it.  The dual port RAM solves a lot of
problems and saves on MUXes.

It may be a moot point anyway, because the cypress part only comes in a
TQFP package, which means 100 pins on half-millimeter centers.  Who's
going to solder that?  Does anyone know of a DP RAM in a PLCC package?

I had dual port in my head and neglected to think about writing the
flash.  You do need a mux (or simpler, a buffer w/enable) on the address
and data lines coming from the ECM to the flash.  So, now the parts
count is:
1 DP RAM
1 PIC
1 flash
24 bits worth of tri state buffer (3 ttl parts?)
1 D flop
1 TTL OR chip
plus connectors, ribbon cable, etc?

With these parts we should be able to:

1)  ECM reads from DP RAM
2)  ECM reads from DP RAM while PIC updates RAM image
3)  ECM copies RAM contents to flash while ECM reads from RAM
(tri-states separate flash address and data lines from ECM address/data
lines).
4)  ECM reads from flash, PIC updates RAM

I'd draw all this up but I don't have much in the way of schematic
capture...

--steve

-- 
Steve Ravet
ARM, INC
steve.ravet at arm.com
www.arm.com



More information about the Gmecm mailing list