Re: SDRAM for specific use - performance and timing questions
- From: John Adair <g1@xxxxxxxxxxxxxxxx>
- Date: Wed, 29 Sep 2010 06:13:46 -0700 (PDT)
I think you have grasped the problem correctly in that latency is the
biggest issue. We have done similar things on our Craignell1
http://www.enterpoint.co.uk/component_replacements/craignell.html and
Craignell2 http://www.enterpoint.co.uk/component_replacements/craignell2.html
modules that are aimed at obsolete component replacement.
Refresh can be an issue but you can design a controller to do refresh
after a EEprom access cycle that may solve that issue. Success of that
depends on how often the virtual EEprom is accesssed and how fast the
host microprocessor is.
One technique to consider is to use the FPGA RAM for this. It is much
faster and works well for small EEprom. The RAM can be preloaded at
configuration or loaded after from SPI Flash. If you know how the
memory space is used you can also use a page swapping technique and
preload the FPGA RAM before an access cycle occurs for a guven memory
location.
To make any of these work you may need a higher clock frequency.
Remember your incoming signals are probably asynchronous to your
module clock and you may lose half a clock or more just synchronising.
To do anything different may cause problems.
In the extreme think about using an external SRAM as an alternative to
SDRAM.
John Adair
Enterpoint Ltd.
On 29 Sep, 13:07, Johannes <johan...@xxxxxxxxxx> wrote:
I hope this is the correct group, I suspect there is more people here
really understanding how an SDRAM works than in the embedded group.
We are working on a design proposal with FPGA and DRAM to replace an
obsolete EEPROM memory. Consequently, we need to emulate standard ROM/
SRAM-style reads, with a maximum read cycle timing of 80 ns. (The
loading to SRAM would be from a serial flash, handled by FPGA, but
this is a one-time-per-power-on, non-critical operation).
I first figured this should be doable with a 100 MHz standard SDRAM,
since it has about 60 ns worst-case random read timing, but, it then
struck me that it needs refreshing as well.
Q1: Am I assuming correctly that this will _not_ be doable with a 100
MHz SDRAM, since there is no time for refreshing in between two reads?
There is no way to do two fully random reads within 80 ns? What if I
stick within the same bank (yes, leaving 75% of the DRAM unused, but
still)?
Q2: Further; am I assuming correctly that it wont help me to step up
to DDR or DDR2, since the only thing improved is the burst rates,
fully random byte reads are still as slow (active-to-active command
period, Trc)?
Nothing else is guaranteed from the host system, there are no
guaranteed pauses we could use for refresh, and it is not guaranteed
that the host system reads the entire memory sequentially, which also
would have solved the refresh issue. It is simply a host processor
without cache executing it's code from this emulated EEPROM.
A million thanks in advance for anything bringing me forward in this
process.
Best Regards,
/Johannes
.
- References:
- SDRAM for specific use - performance and timing questions
- From: Johannes
- SDRAM for specific use - performance and timing questions
- Prev by Date: Re: SDRAM for specific use - performance and timing questions
- Next by Date: Re: SDRAM for specific use - performance and timing questions
- Previous by thread: Re: SDRAM for specific use - performance and timing questions
- Next by thread: Re: SDRAM for specific use - performance and timing questions
- Index(es):
Relevant Pages
|
