FPGA with external dual ported memory for higher memory density?
PSoC 4 prototype board for 16K? Not sure about speeds and performance.
How many address lines are you looking at?
PSoC 4 prototype board for 16K? Not sure about speeds and performance.
Which one ?
Features
----------------------------------------------------------------------------
- 32K emulation memory
- Support for 28-pin EPROMs (27C256, 27C512)
- Support for 32-pin EPROMs (27C010, 27C020, 27C040)
- Support for 28-pin SRAMs (6264, 62256)
- Fast transfer of data over USB
- Open-collector reset output to drive target board /RESET signal
PGMFI RTP - This device is still in development and testing. For more info go to: http://www.pgmfi.org
Xtronics ROMulator - This is one of the original RTP devices available. It is an old system that uses a DB9 serial port, but still usable. For more info go to: http://www.xtronics.com
Moates.net Ostrich - This is the recommended RTP hardware for Crome. It is an excellent system with good battery life and uses a USB connection. For more info go to: http://www.moates.net
Moates.net Ostrich
With some external level shifting support, I suspect a small FPGA could handle this easily as long as it has enough build in SRAM
The tricky part will be handling a large asynchronous interface but maybe that will have to be done externally as well.
As costly as they are, it would probably be more economical to buy one unless you want the experience in designing it and have the time.
With some external level shifting support, I suspect a small FPGA could handle this easily as long as it has enough build in SRAM.
96Kbyte on the Spartan6 of Papilo/Pro (it's a very nice fpga-board), BRAM is expensive, also you need to allocate BRAM for your soft core, the BRAM is used to synthetize its ram and its rom, where its firmware will be run.
it seems to me 64Kbyte of the 96Kbyte may be a real constraints in a such practical project.
The tricky part will be handling a large asynchronous interface but maybe that will have to be done externally as well.
The best idea is to synthesize an uart inside fpga and then interfacing it to an FTDI chip. This makes things easy and simple.
As costly as they are, it would probably be more economical to buy one unless you want the experience in designing it and have the time.
My problem is … what to buy.
Still try to consider the parallel port idea. Printing a hex file to an LPT port (even if it is a USB lpt port) makes life extremely simple to get a hex in your emulator quickly.
SoftTech MultiROM
Summary:
Up to 16 Mbit emulation buffer, 8- and 16-bit data bus, 60 ns access time, Trace Buffer, 2.7, 3.3 and 5 V support, Live Access and Virtual Terminal.
Full Text:
SofTec Microsystems has announced the development of MultiROM, an advanced debugging tool for embedded systems. MultiROM is a full-featured EPROM and FLASH mamory emulator, so EPROM or FLASH memory programming during the application development process is no longer required. MultiROM seamlessly replaces the EPROM or FLASH memory of the system under development, thus allowing a very fast uploading of the user’s code directly onto the instrument’s built-in emulation memory. During the emulation, the uploaded code can be watched, edited and analyzed in real time. MultiROM is connected to the host PC through a standard parallel port, in order to achieve faster transfer rates than commonly used serial ports. The MultiROM pod is simply inserted into the target’s memory socket—MultiROM is independent from the target microprocessor, and the emulation of every EPROM or FLASH memory (in DIP, PLCC, TSOP or PSOP package) is completely transparent and straightforward. MultiROM emulates up to 16 Mbit devices, with data bus widths of 8 and 16 bits. The memory access time is guaranteed to be less than 60 ns. MultiROM can emulate 2.7 V, 3.3 V and 5 V devices, thanks to its internal circuitry—-no external adapter is needed, thus ensuring no increase in memory access time. The Live Access feature allows the host PC to transparently view/edit the memory under emulation in real time, without in no way affecting the target’s memory access timings (no wait states inserted). The Live Access feature allows the user, for example, to modify control variables (loop counter variables, timing constants, etc.) and look-up tables, or to simulate conditions that trigger external signals; all this in real time, while the target system is running. MultiROM also features a Virtual Terminal, a communication channel between the host PC and the target system which allows the latter to send messages to the former during the emulation. By simply accessing some dedicated MultiROM locations, the target can send, while running, the content of its variables or whatever other text messages to the host PC; the Virtual Terminal messages are displayed in a dedicated user interface window. The emulator provides an output RESET signal that can be generated as needed. MultiROM, additionally, can generate interrupt signals (depending on memory access conditions specified in the user interface) that can be used by the target system. A trace buffer is also built in into the instrument. MultiROM comes with a powerful user interface for Windows 95/98/NT/2000, power adapter, parallel cable, DIP-32 adapter and user’s manual. Adapters for other packages are available on request. An interface library (DLL) is also provided (as an option) so that you can interface your own programs directly with MultiROM.
I mean the asynchronous parallel memory interface unless you somehow phase lock the FPGA clock to the target system; the EPROM/SRAM control signals and interface can change state at any time relative to the FPGA clock. -CS and the read/write control lines of course latch the address and data bus so maybe that is not such a large problem.
The Dataman S4
I mean the asynchronous parallel memory interface unless you somehow phase lock the FPGA clock to the target system; the EPROM/SRAM control signals and interface can change state at any time relative to the FPGA clock. -CS and the read/write control lines of course latch the address and data bus so maybe that is not such a large problem.
Thanks, it clarifies. Do you know any existing project or product like that ? It looks cool.
The Ostrich's works OK for ROM emulation but have some limitations when tracing. Getting 2 Ostriches syncronised and tracing can be a bit of an issue.
You neglected to mention how fast your target bus speed is, but I assume it's pretty slow.
I used a FTDI USB serial to parallel chip for comms.