SDRAM for specific use - performance and timing questions

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

On Sep 29, 8:07=A0am, Johannes <johan...@excito.com> 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

Completely random access in any SDRAM will not be very fast.  Unless
you can
keep everything in one row per bank (you can keep all banks open at
once) you
have to take a hit for a new random row access.  How big was the
original
memory device you're trying to emulate?  Would it make sense to use
something else like SRAM to emulate it?

On 29 Sep, 14:33, Gabor <ga...@alacron.com> wrote:
> On Sep 29, 8:07=A0am, Johannes <johan...@excito.com> 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
>
> Completely random access in any SDRAM will not be very fast. =A0Unless
> you can
> keep everything in one row per bank (you can keep all banks open at
> once) you
> have to take a hit for a new random row access. =A0How big was the
> original
> memory device you're trying to emulate? =A0Would it make sense to use
> something else like SRAM to emulate it?

Thanks for your reply.
Yes, SRAM is an option but not wanted due to it's high price (it's for
a high volume product), hence the preference of DRAM. The original
memory size is 4 MByte so it's not a lot of data, but DRAM is still a
lot cheaper.

"Johannes" <johannes@excito.com> wrote in message 
news:0aad6682-bdc6-40cf-86c6-ece9be74dd94@l20g2000yqm.googlegroups.com...
>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).

Is there really no Flash chip that could do this job?
I guess EEPROM has its erase/write issues similar to the the flash. Maybe 
that could be emulated..

On 29 Sep, 14:48, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote:
> "Johannes" <johan...@excito.com> wrote in message
>
> news:0aad6682-bdc6-40cf-86c6-ece9be74dd94@l20g2000yqm.googlegroups.com...
>
> >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).
>
> Is there really no Flash chip that could do this job?
> I guess EEPROM has its erase/write issues similar to the the flash. Maybe
> that could be emulated..


Yes, we have actually done a solution already with Flash, but the
customer whishes to move on to another memory solution for two
reasons:
- standard nor flash is getting obsolete in a few years
- since the cycle time required is 80 ns, a standard 70 ns NOR flash
isn't enough when adding some FPGA timing, we need 55 ns NOR flash,
which is virtually impossible to buy these days

Regarding the writes this is not an issue since this is not done in
standard operating modes. (Writes are only done in a machine firmware
upgrade, and is another story).

Thanks for your replies so far. I really need a DRAM wizard to show me
if there are any tricks to fit a refresh cycle in between two random
reads, all in 80 ns. Moving up to DDRx is no problem, if required.

Best Regards,
/Johannes

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...@excito.com> 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

Johannes <johannesmannen@gmail.com> wrote:
(snip)

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

>> Is there really no Flash chip that could do this job?
>> I guess EEPROM has its erase/write issues similar to the the flash. Maybe
>> that could be emulated..

A suggestion which could work for DRAM or Flash, though may
or may not help, is to use two devices with the same data, and
access them alternately.  That gets the average access rate up,
though you have to pipeline the data. 

(snip) 
> - since the cycle time required is 80 ns, a standard 70 ns NOR flash
> isn't enough when adding some FPGA timing, we need 55 ns NOR flash,
> which is virtually impossible to buy these days

-- glen

On Sep 29, 9:28=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Johannes <johannesman...@gmail.com> wrote:
>
> (snip)
>
> >> > We are working on a design proposal with FPGA and DRAM to replace an
> >> > obsolete EEPROM memory. Consequently, we need to emulate standard RO=
M/
> >> > 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).
> >> Is there really no Flash chip that could do this job?
> >> I guess EEPROM has its erase/write issues similar to the the flash. Ma=
ybe
> >> that could be emulated..
>
> A suggestion which could work for DRAM or Flash, though may
> or may not help, is to use two devices with the same data, and
> access them alternately. =A0That gets the average access rate up,
> though you have to pipeline the data.
>
> (snip)
>
> > - since the cycle time required is 80 ns, a standard 70 ns NOR flash
> > isn't enough when adding some FPGA timing, we need 55 ns NOR flash,
> > which is virtually impossible to buy these days
>
> -- glen

In this case, having multiple copies in the same device may do the
trick since an SDRAM has multiple banks.  Single data rate SDRAM
and DDR 1 generally has four banks and larger DDR 2 parts have 8
banks.  Sticking with the single data rate parts you can do refresh
just by activating a row, but remember this requires an activate to
every
row in every bank within the refresh period, while the auto-refresh
command refreshes a row in all four banks at once.  In this way
if you had to do an access while one bank / row is doing a "refresh"
you can get the data from another bank.

-- Gabor

Johannes <johannesmannen@gmail.com> wrote:

>On 29 Sep, 14:48, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote:
>> "Johannes" <johan...@excito.com> wrote in message
>>
>> news:0aad6682-bdc6-40cf-86c6-ece9be74dd94@l20g2000yqm.googlegroups.com...
>>
>> >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).
>>
>> Is there really no Flash chip that could do this job?
>> I guess EEPROM has its erase/write issues similar to the the flash. Maybe
>> that could be emulated..
>
>
>Yes, we have actually done a solution already with Flash, but the
>customer whishes to move on to another memory solution for two
>reasons:
>- standard nor flash is getting obsolete in a few years

I don't think so. NOR flash has many advantages over NAND flash.
Staying available for a long time is one of them.

>- since the cycle time required is 80 ns, a standard 70 ns NOR flash
>isn't enough when adding some FPGA timing, we need 55 ns NOR flash,
>which is virtually impossible to buy these days

Sure about that? Did you talk to ISSI? They sell devices targeted for
industrial applications. Not high tech but they claim to keep devices
active for many years.

>Regarding the writes this is not an issue since this is not done in
>standard operating modes. (Writes are only done in a machine firmware
>upgrade, and is another story).
>
>Thanks for your replies so far. I really need a DRAM wizard to show me
>if there are any tricks to fit a refresh cycle in between two random
>reads, all in 80 ns. Moving up to DDRx is no problem, if required.

The problem is CAS latency. DDR memory is just wider memory in
parallel banks. This increases the burst transfer bandwidth but the
latency is still very long. 

Did you look into SRAM?

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Gabor <gabor@alacron.com> wrote:

>On Sep 29, 9:28=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Johannes <johannesman...@gmail.com> wrote:
>>
>> (snip)
>>
>> >> > We are working on a design proposal with FPGA and DRAM to replace an
>> >> > obsolete EEPROM memory. Consequently, we need to emulate standard RO=
>M/
>> >> > 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).
>> >> Is there really no Flash chip that could do this job?
>> >> I guess EEPROM has its erase/write issues similar to the the flash. Ma=
>ybe
>> >> that could be emulated..
>>
>> A suggestion which could work for DRAM or Flash, though may
>> or may not help, is to use two devices with the same data, and
>> access them alternately. =A0That gets the average access rate up,
>> though you have to pipeline the data.
>>
>> (snip)
>>
>> > - since the cycle time required is 80 ns, a standard 70 ns NOR flash
>> > isn't enough when adding some FPGA timing, we need 55 ns NOR flash,
>> > which is virtually impossible to buy these days
>>
>> -- glen
>
>In this case, having multiple copies in the same device may do the
>trick since an SDRAM has multiple banks.  Single data rate SDRAM
>and DDR 1 generally has four banks and larger DDR 2 parts have 8
>banks.  Sticking with the single data rate parts you can do refresh
>just by activating a row, but remember this requires an activate to
>every
>row in every bank within the refresh period, while the auto-refresh
>command refreshes a row in all four banks at once.  In this way
>if you had to do an access while one bank / row is doing a "refresh"
>you can get the data from another bank.

This gets you into trouble when writing. If you allow random writes,
you'll need some fancy caching algorithm to allow for any random write
sequences.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------