SDRAM for specific use - performance and timing questions

[Johannes]

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

 

[Morten Leikvoll]

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

 

[Gabor]

On Sep 29, 8:07 am, 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?

 

[Johannes]

On 29 Sep, 14:33, Gabor <ga...@alacron.com> wrote:

On Sep 29, 8:07 am, 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?

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]

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

 

[John Adair]

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

 

[glen herrmannsfeldt]

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

 

[Nico Coesel]

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

 

[Nico Coesel]

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

 

[Gabor]

On Sep 29, 9:28 am, 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 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

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

 

[glen herrmannsfeldt]

Nico Coesel <nico@puntnl.niks> wrote:
(snip)

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.

This is supposed to be an EPROM replacement. As I understand it,
the DRAM is loaded at powerup with the appropriate bits, and read,
randomly. Most likely the load is sequential and not speed
sensitive.

It does seem to me that the multiple bank with the same data
solution should work, but the OP will have to decide.

-- glen

 

[Ulf Samuelsson]

Johannes skrev 2010-09-29 14:07:

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

Hi Johannes,
If you only need to emulate "read", then a parallel flash should
do the job...

You could also check out PSRAMs.

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

--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB

 

[Johannes]

Sorry for the late reply, stuck in meetings all day. Thanks a lot for
your replies!

@John: Thanks, I'm right now checking if there might be time for the
refresh after the reads, would be the simplest solution. Most likely
not possible though, but I'm checking anyways, just in case. Thanks!

@glen
Two identical devices is also a great idea, will of course work!
Pricing may be an issue, am looking into it.

@gabor
Also a great idea, but I'm not following you all the way. Is it
possible to: 1) Initiate a read 2) initiate a refresh in another bank,
all in 80 ns? Because as I said, there are no guaranteed pauses
whatsoever to do anything else than responding to reads every 80 ns.

@Nico
-Yes, believe me we have checked thoroughly all flash vendors. I know
ISSI is good with keeping parts in production, but they don't do FLASH
at all as far as I know.
-SRAM is also out of the question because of the price. High volume
product + 4 MByte SRAM is not a good combination.
-And as glen pointed out correctly, writes is not an issue, write is
performed only on power-on and is not timing critical

@Ulf
Yes, thanks. Have looked into both FLASH and PSRAM, and would prefer
not to use any of those for the above mentioned reasons, price and
availability is not sufficient. Nice seing you here btw, long
time...


So this leaves me with the following options:
- using two SDRAM's with separate interfaces to the FPGA. One in
refresh while reading the other.
- using a 4 time as large SDRAM and keep identical data in at least
two banks (assuming this works, see comment to gabor above)
- dismiss the idea of using DRAM and re-evaluate the other options
(parallel flash etc.)

Thanks a lot for your time so far, great help. If you get any more
ideas, I'm eternally grateful.

/Johannes

 

[rickman]

On Sep 30, 9:12 am, Johannes <johannesman...@gmail.com> wrote:

Sorry for the late reply, stuck in meetings all day. Thanks a lot for
your replies!

@John: Thanks, I'm right now checking if there might be time for the
refresh after the reads, would be the simplest solution. Most likely
not possible though, but I'm checking anyways, just in case. Thanks!

@glen
Two identical devices is also a great idea, will of course work!
Pricing may be an issue, am looking into it.

@gabor
Also a great idea, but I'm not following you all the way. Is it
possible to: 1) Initiate a read 2) initiate a refresh in another bank,
all in 80 ns? Because as I said, there are no guaranteed pauses
whatsoever to do anything else than responding to reads every 80 ns.

@Nico
-Yes, believe me we have checked thoroughly all flash vendors. I know
ISSI is good with keeping parts in production, but they don't do FLASH
at all as far as I know.
-SRAM is also out of the question because of the price. High volume
product + 4 MByte SRAM is not a good combination.
-And as glen pointed out correctly, writes is not an issue, write is
performed only on power-on and is not timing critical

@Ulf
Yes, thanks. Have looked into both FLASH and PSRAM, and would prefer
not to use any of those for the above mentioned reasons, price and
availability is not sufficient. Nice seing you here btw, long
time...

So this leaves me with the following options:
- using two SDRAM's with separate interfaces to the FPGA. One in
refresh while reading the other.
- using a 4 time as large SDRAM and keep identical data in at least
two banks (assuming this works, see comment to gabor above)
- dismiss the idea of using DRAM and re-evaluate the other options
(parallel flash etc.)

Thanks a lot for your time so far, great help. If you get any more
ideas, I'm eternally grateful.

/Johannes

I think there is one other solution that has not been mentioned. Why
are you limited to 100 MHz SDRAM? Can't you go with a 133 MHz SDRAM?
Then you would have more clock cycles to do your read and still
initiate a refresh on a separate bank. I guess it has been a long
time since I've worked with SDRAM, so I'm not sure a faster interface
actually would give you more time for a refresh. I would need to look
at a data sheet again.

Rick

 

[Johannes]

I think there is one other solution that has not been mentioned.  Why
are you limited to 100 MHz SDRAM?  Can't you go with a 133 MHz SDRAM?
Then you would have more clock cycles to do your read and still
initiate a refresh on a separate bank.  I guess it has been a long
time since I've worked with SDRAM, so I'm not sure a faster interface
actually would give you more time for a refresh.  I would need to look
at a data sheet again.

Yes, but this doesn't help. 100, 133 or even 1100 MHz DDR-III has the
same random access times (about 50-60 ns for a full random read
cycle). It's only burst that has improved.

 

[Gabor]

On Sep 30, 11:13 am, Johannes <johannesman...@gmail.com> wrote:

I think there is one other solution that has not been mentioned.  Why
are you limited to 100 MHz SDRAM?  Can't you go with a 133 MHz SDRAM?
Then you would have more clock cycles to do your read and still
initiate a refresh on a separate bank.  I guess it has been a long
time since I've worked with SDRAM, so I'm not sure a faster interface
actually would give you more time for a refresh.  I would need to look
at a data sheet again.

Yes, but this doesn't help. 100, 133 or even 1100 MHz DDR-III has the
same random access times (about 50-60 ns for a full random read
cycle). It's only burst that has improved.

I think the point is how many accesses you can make during the 80
ns you have. If you need to read one bank while activating another,
the cycle timing doesn't change, but the number of commands you
can send to the device does. By the way you don't really need to do
a "refresh" to a bank, only activate the row followed by a precharge.
That takes two commands on the address / command interface
anyway you look at it. This represents a smaller portion of the
80 ns when you are running a faster clock rate.

When I have designed SDRAM controllers, I generally start with
a chart to show on each clock cycle what I am doing on the
address / command interface, and what is happening on the
DQ interface. When using multiple banks, this is highly
pipelined and interleaved, so charting it out helps to visualize
what I need to do. For example, when doing high data-rate
access, I have a favorite controller that always moves to the
next bank after a single burst access. It also always uses
the autoprecharge commands for read or write. This means
that I can activate a row, read (or write), and precharge it
in two commands. Interleaving the banks allows an access
to any random row in the next bank with no dead cycles
as long as I have a burst of at least 2 words, and don't change
direction (read v. write). If I look at a single burst to the
same row of each of the four banks as my minimum access
or "word size", then I have essentially a really random access
memory that runs at the device clock rate. Note that since
I am usually doing video and image processing, I'm less
concerned about latency and more concerned with
throughput. In your case however, you can map the
cycle of reading a bank while "refreshing" another and look
at the worst case latency if the external request comes at
any point in the current cycle. By the way, you realize that
some of the latency necessarily comes in the path from
registering the data in the FPGA to placing it on the outputs
of the pseudo-EEPROM bus. This should also be helped
with a hight clock rate.

One more point about refresh. Like the early DRAM devices,
single-data-rate SDRAM only requires a refresh to each
row (of each bank) within the stated refresh period, usually
32 or 64 ms. Any row/bank that you have read or written
in that time does not need additional refresh. In the early days
there were DRAM refresh controllers that kept a log (1 bit
per row) of row accesses and only refreshed the untouched
rows as required, usually in one big burst. Assigning your
address such that row address is in the lower bits usually
causes the additional refresh requirement to be very small
because the access is typically sequential.

All of the above bit is not true of DDR SDRAM. There are
additional reasons to use the auto-refresh command in
these devices, namely giving the chip a window to re-
calibrate its DLL without creating jitter in the DQ interface.
These devices typically require a distributed refresh with
a maximum time between refreshes of 15.6 us. I
don't think this helps in your case.

Regards,
Gabor

 

[rickman]

On Sep 30, 11:13 am, Johannes <johannesman...@gmail.com> wrote:

I think there is one other solution that has not been mentioned.  Why
are you limited to 100 MHz SDRAM?  Can't you go with a 133 MHz SDRAM?
Then you would have more clock cycles to do your read and still
initiate a refresh on a separate bank.  I guess it has been a long
time since I've worked with SDRAM, so I'm not sure a faster interface
actually would give you more time for a refresh.  I would need to look
at a data sheet again.

Yes, but this doesn't help. 100, 133 or even 1100 MHz DDR-III has the
same random access times (about 50-60 ns for a full random read
cycle). It's only burst that has improved.

But if the read takes 60 ns and you have 80, can't you get a refresh
in between the reads? Or does the full read cycle require the full 80
ns?

Looking at the data sheet, I see that you can interleave banks which
appears to add nothing to the time of a random read. You would need
to use more then two banks with duplicate data, but you could start a
read on bank 0, then do a refresh on bank 1. Next read bank 1 and
refresh bank 2. Finally read bank 2 and refresh bank 0. By the time
this is complete, you can go back to reading bank 0. I'm not sure if
you you can do this with two banks. It depends on the time required
between the refresh to starting the next read.

Rick

 

[glen herrmannsfeldt]

Gabor <gabor@alacron.com> wrote:
(snip)

One more point about refresh. Like the early DRAM devices,
single-data-rate SDRAM only requires a refresh to each
row (of each bank) within the stated refresh period, usually
32 or 64 ms. Any row/bank that you have read or written
in that time does not need additional refresh. In the early days
there were DRAM refresh controllers that kept a log (1 bit
per row) of row accesses and only refreshed the untouched
rows as required, usually in one big burst. Assigning your
address such that row address is in the lower bits usually
causes the additional refresh requirement to be very small
because the access is typically sequential.

This reminds me, some years ago I was working on a design with
a very large finite state machine, with the possibility of
storing it in SDRAM. I had thought about the possibility of
positioning the states in memory such that the row access
pattern would be sufficient for refresh. Normally, it might
stay in a small number of states, so I had thought about
duplicating some of the states to supply enough that it
would reliably satisfy the refresh requirement.

Still, with random input, one might be able to statistically
get the probability of missing a row refresh within the refresh
time very small, but maybe not zero.

-- glen

 

[Brian Drummond]

On Thu, 30 Sep 2010 08:13:30 -0700 (PDT), Johannes <johannesmannen@gmail.com>
wrote:

I think there is one other solution that has not been mentioned.  Why
are you limited to 100 MHz SDRAM?  Can't you go with a 133 MHz SDRAM?
Then you would have more clock cycles to do your read and still
initiate a refresh on a separate bank.  I guess it has been a long
time since I've worked with SDRAM, so I'm not sure a faster interface
actually would give you more time for a refresh.  I would need to look
at a data sheet again.


Yes, but this doesn't help. 100, 133 or even 1100 MHz DDR-III has the
same random access times (about 50-60 ns for a full random read
cycle). It's only burst that has improved.

But a typical device has (say) RAS-CAS) latency of 2. Therefore if in Cycle 1
you open Bank 1 and present the read row address, it will be in Cycle 3 that you
present the column address. (Then there are a couple more cycles before you get
the data back)

That leaves Cycle 2 spare.

Use it to start a Refresh in the alternate bank; Refresh will take a few cycles
in its own right...

If the Refresh is not complete by the end of the current 80ns period, you cannot
read from the Bank 2 in the second 80ns period, so you need to cycle through 4
banks. (That will give 240ns for a refresh; ample time including any precharge
requirements.

Gabor is right - you need something like a spreadsheet to map out what happens
in each cycle, in each bank.

The importance of 133MHz or higher is not to achieve faster random reads, but to
increase degrees of freedom for aligning other activities (refresh, precharge)
in the gaps during the reads - 133MHz memory (clocked at 125) would give 10
cycles rather than 8.

- Brian

 

[Johannes]

Brian, you are right. Also thanks gabor for the insight, I am right
now looking at a chart and trying to figure out worst case timings,
and it appears to work, even without duplicating sdrams or having the
same data in multiple banks. Something like this:

SDRAM @ 125 MHz.

- host cpu issues a read for adress 'A'. FPGA propagation delay appr.
12 ns before reaching SDRAM
- synchronizing to SDRAM clk costs maximum 1 clk' = 8 ns
- 0.5 clk' delay for command to be clocked in to SDRAM
- SDRAM cycle 1: ACTIVE adress 'A'
- SDRAM cycle 2: NOP
- SDRAM cycle 3: READ (2 clk' between ACTIVE and READ fulfills Trcd >
15 ns)
- SDRAM cycle 4: ACTIVE adress 'B' for refresh, according to a running
refresh counter. (3 clk' between the two actives fullfills Trrd > 15
ns)
- SDRAM cycle 5: NOP
- SDRAM cycle 5,5: DATA valid (CAS latency = 2)
- FPGA propagation delay appr: 12 ns
TOTAL SUM: 12+8+4+4,5*8+12 = 72 ns

then the next cycle the refresh algorithm could do a precharge for
that row. If a read request for an already open row would appear this
is no problem since it's just to go on and read then. I will go
through this again monday, but so far so good.


Good feeling a friday night, again thanks all for this precious help!

/Johannes