EPROM emulator

[Ludis Langens]

steve ravet wrote:
> 
> 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.

The cypress data seems a bit ambiguous about this.  It appears that
whenever both ports specify the same address, one will get a ~BUSY even
if both are reading.  You would need external logic to determine that
the collision is "safe".


> 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 write isn't lost - just delayed.  (This assumes the writing & losing
device doesn't terminate the cycle before ~BUSY deasserts.)


> The only collision we have to worry about is a read/write collision

That's the reason for two banks - one for the ECM to read and one for
the PIC to write.  This way collisions are impossible.


> Having 2 physical banks of RAM leads to coherency problems.  How do you
> make sure that both RAMs are kept the same?

Why do they have to be the same?  One bank is the currently used image. 
The other bank is for prepping the next image and then switching it into
the ECM fait-accompli*.  The worst case is if doing incremental updates.
 The "download" bank will have an image that is two generations old. 
You'll have to send the previous generation's update and then the latest update.

* The reason for this is so that the ECM never sees a table half updated.


> 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:
> 24 bits worth of tri state buffer (3 ttl parts?)

Double that - unless the PIC has >48 bits of I/O which can be
tri-stated.  You need to tristate the address/data from the ECM to let
the PIC at the memory, and you need to tristate the PIC to let the ECM
have access.  The second block of 24 I/Os is because while the PIC is
locked out of one bank, it still needs access to the other.

One way to reduce the amount of muxes and buffers is to do as John
suggested and time multiplex several virtual banks into one physical
bank.  This makes assumptions about the ECM's use of the memory though.

BTW, using tristate outputs to implement a mux works, but isn't as good
of a design as a real mux.  With the tristates, you need to verify that
multiple drivers aren't ever enabled, even during transitions.  Plus,
any bus line driving a MOS input can't remain undriven for long.

An idea:  Put the Flash/EEPROM/EPROM on just the PIC's side.  On power
up, copy it to an SRAM bank.  This way, no muxes of any sort are needed
for the Flash.  It may even be possible to use some sort of serial
EEPROM.  This method does have a problem of loading the SRAM fast enough
for the ECM to use upon power-up.  Perhaps the PIC could first load a
placeholder image that puts the ECM "to sleep" until the full SRAM is
loaded.  Or perhaps the emulator can be powered up before the ECM.


> 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.

An idea:  Are there any VRAM chips with a non-muxed processor address
(and data) bus and a seperate video row address bus?  A VRAM is a form
of dual port memory that would be just perfect for our use.  The regular
VRAM port can service the ECM while the video in/out port provides
serial access for the PIC.  Upside: VRAM capacity is high enough that
two 128Kbyte banks aren't a problem.  Downside: A PIC might not have
enough RAM to temporarily hold even one row of VRAM data.  Downside:
It'll be DRAM requiring refresh, and with a higher power consumption. 
Downside: This type of VRAM is likely to have a product life of six
months and a lead time of two years, plus having the microscopic pins. 
Upside: It may be cheaply available as a VRAM SIMM for say a CyberClone
450 w/ JKL 16Meg video card - thus the emulator only needs a SIMM socket soldered.


Speaking of power consumption, is it intended to power the emulator from
the ECM?  I've successfully drawn an extra 200 mA (VCC) from a P4
1227748 ECM.  The ECM's total power draw went from 400 mA to 600 mA.  My
add-on board was designed to only draw 50 mA, but a parts shortage
required the use of an NMOS and a TTL part.  The '748 is the simplest of
the P4's, so others may not have as much headroom.

If the emulator is seperately powered, any muxes/buffers can be useful
to provide power supply seperation.


An idea:  The dual port SRAM doesn't need to be for the entire emulated
memory.  The DPSRAM could be used for just the ECM data tables, with an
EPROM/EEPROM/Flash supplying the ECM code.  The RAM would still need to
be 16Kbytes or so to work for the bigger PROMs.  It also needs to be
relocatable to various memory ranges.  To avoid muxes and etc. for
programming the EEPROM/Flash, it may be possible to put it just on the
ECM side and enlist the support of the ECM to do the burning.  (Have the
PIC stuff a burner program into the DPSRAM and boot the ECM into it.)

-- 
Ludis Langens                               ludis (at) cruzers (dot) com
Mac, Fiero, & engine controller goodies:  http://www.cruzers.com/~ludis/