More EPROM Emulator ideas

[steve ravet]

Ludis Langens wrote:
> 
> TI has added a JTAG interface to a lot of the standard octal
> buffer/latch/transceiver chips.  The transceivers are even available in
> 18 and 20 bit versions.  We could implement dual port access to standard
> memories by using these chips instead of muxes.  Two of the wide chips
> and two octal chips would be enough to interface two banks of RAM.  The
> ECM gets access to the memory by letting signals flow through the
> buffers in normal mode.  The PIC gets access by switching to a JTAG test
> mode and intercepting the signals.  A plus for us is that the JTAG port
> needs only 4 pins on the PIC - an 18 pin PIC might be able to run the
> whole emulator.  Minuses:  These chips are expensive, about $10 each.
> The bigger ones use packaging just as scary as the Cypress DPRAMs.
> 
> IDT's web pages say that their 64K*8 dual port RAM is available in an 84
> pin PLCC - who was it that said only the smaller devices were available
> in such sensible packages?
> 
> IDT also has what they call a SARAM - Sequential Access RAM.  It is a
> form of dual port RAM, one port is a normal RAM port, the other sort of
> like a FIFO where the memory chip keeps track of the address.  We could
> hook the normal port to the ECM and the sequential port to the PIC.
> This reduces the number of I/O's needed on the PIC.  The biggest device
> IDT has is 8K*16, which we could easily use as two banks of 8K*8.  This
> isn't really big enough - a 64K*8 DPRAM makes a lot more sense.
> 
> At the risk of creeping featurism, the emulator should have an EPROM
> reader socket.  This allows a user to pull the stock chip out of an ECM,
> copy the data into the emulator (or a laptop), and start tuning - all
> without needing a separate EPROM reader/burner.
> 
> Actually, an optional EPROM programmer (for a limited number of devices)
> would be a nice feature.

That's good that IDT has the big memories in nice packages.  I thought
from looking that it was only 32K and below.  The EPROM socket is also a
good idea, only costs an additional I/O from the PIC.  The SARAM is a
good idea also but, would require 4, plus being sequential you'd have to
download the whole image each time.  I like the DPRAM still.  What if we
dumped the flash and went with a battery backed DPRAM approach.  That
would eliminate the flash part and some muxes, and ease the IO demand on
the PIC.  Add a 9 volt battery connector and some battery backup
circuitry right from the app note.  That would effectively be the same
as having the flash.

Did we ever find anyone to do the schematic capture/layout?

--steve

-- 
Steve Ravet
steve.ravet at arm.com
Advanced Risc Machines, Inc.
www.arm.com