SDRAM for specific use - performance and timing questions

[rickman]

On Oct 1, 11:43 am, Johannes <johannesman...@gmail.com> wrote:

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

Are you sure you can do a refresh on a currently running read? I'm
not saying you can't, but it seems like it might mess up the read.
You actually have two separate timing constraints. One is the path
you have outlined above, the read access timing. The other is the
SDRAM read cycle and refresh timing. Your FPGA interface timings add
up to 32 ns of the 72 ns total. The SDRAM is only using 40 ns in this
process. That means you can use the other 40 ns (or is it 32 ns?) of
the total cycle time to do the refresh and not have to worry about the
refresh conflicting with the read in progress.


.... | NOP | ACTIVE | NOP | READ | NOP | DATA | REFRESH | NOP | ... |
NOP | ACTIVE | ...
^ ^
^
Processor Req Data Output to FPGA
Processor Req

Another advantage of this approach is that you can use the chip wide
auto refresh and don't need to supply the address. You can use an
internal counter to time the refresh interval and just send NOPs in
the idle time until a refresh is required. Heck, I think the timing
may work out to let you run the SDRAM at 100 MHz.

Rick

 

[Gabor]

On Oct 1, 12:29 pm, rickman <gnu...@gmail.com> wrote:

On Oct 1, 11:43 am, Johannes <johannesman...@gmail.com> wrote:



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

Are you sure you can do a refresh on a currently running read?  I'm
not saying you can't, but it seems like it might mess up the read.
You actually have two separate timing constraints.  One is the path
you have outlined above, the read access timing.  The other is the
SDRAM read cycle and refresh timing.  Your FPGA interface timings add
up to 32 ns of the 72 ns total.  The SDRAM is only using 40 ns in this
process.  That means you can use the other 40 ns (or is it 32 ns?) of
the total cycle time to do the refresh and not have to worry about the
refresh conflicting with the read in progress.

... | NOP | ACTIVE | NOP | READ | NOP | DATA | REFRESH | NOP | ... |
NOP | ACTIVE | ...
       ^                                  ^
^
    Processor Req                 Data Output to FPGA
Processor Req

Another advantage of this approach is that you can use the chip wide
auto refresh and don't need to supply the address.  You can use an
internal counter to time the refresh interval and just send NOPs in
the idle time until a refresh is required.  Heck, I think the timing
may work out to let you run the SDRAM at 100 MHz.

Rick

The only problem is that the auto-refresh needs to start with all
banks precharged. I don't think there's enough time to complete
the current cycle including precharge and have an additional Trc
for the auto-refresh cycle.

 

[rickman]

On Oct 1, 2:03 pm, Gabor <ga...@alacron.com> wrote:

On Oct 1, 12:29 pm, rickman <gnu...@gmail.com> wrote:



On Oct 1, 11:43 am, Johannes <johannesman...@gmail.com> wrote:

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

Are you sure you can do a refresh on a currently running read?  I'm
not saying you can't, but it seems like it might mess up the read.
You actually have two separate timing constraints.  One is the path
you have outlined above, the read access timing.  The other is the
SDRAM read cycle and refresh timing.  Your FPGA interface timings add
up to 32 ns of the 72 ns total.  The SDRAM is only using 40 ns in this
process.  That means you can use the other 40 ns (or is it 32 ns?) of
the total cycle time to do the refresh and not have to worry about the
refresh conflicting with the read in progress.

... | NOP | ACTIVE | NOP | READ | NOP | DATA | REFRESH | NOP | ... |
NOP | ACTIVE | ...
       ^                                  ^
^
    Processor Req                 Data Output to FPGA
Processor Req

Another advantage of this approach is that you can use the chip wide
auto refresh and don't need to supply the address.  You can use an
internal counter to time the refresh interval and just send NOPs in
the idle time until a refresh is required.  Heck, I think the timing
may work out to let you run the SDRAM at 100 MHz.

Rick

The only problem is that the auto-refresh needs to start with all
banks precharged.  I don't think there's enough time to complete
the current cycle including precharge and have an additional Trc
for the auto-refresh cycle.

Yes, tRC is 60 ns and tRP is 15 ns so the minimum read cycle time is
60 ns at 133 MHz. So you can't use the auto REFRESH with a read in 80
ns.

The PRECHARGE to ACTIVE timing requirement convinces me there is no
way a second ACTIVATE command can be run to refresh the same bank
while it is being read. The refresh will have to be done on a
different bank containing the same data and the two banks will need to
be ping-ponged to allow refreshing to both.

Rick

 

[Thomas Entner]

On a typical SDRAM, you have tRC = 60ns (active to active-time of the
same bank) and tRFC = 60ns (auto-refresh-duration). So it will never
be possible to do a random-access + a refresh in one 80ns cycle. The
only thing that should work, like others already suggested, is to
store the data twice in different banks and do the refreshing "by
hand", i.e. issuing activate + precharge-commands to every row of
every bank (I am not sure if this solution is even officially
specified by the SDRAM-manufacturers, altought it should work). So you
can refresh one bank while reading the data from the other bank. So
reading should be straight forward. Writing is more difficult, as you
have to write every data twice to both banks. As you are emulating an
EEPROM, there should the possibility to delay the CPU after a write
(with a BUSY-bit or something), otherwise it would get very tricky.

But as you mentioned that this is a price sensitive application, have
you considered to switch to another CPU and/or change something on the
firmware-level, as my feeling is that this would result in the most
cost effective solution with similar development effort.

Thomas

www.entner-electronics.com

 

[Johannes]

Thomas and Rick, thanks a lot for clarifying the last parts for me.
With your and the others' help I'm now confident with what the
requirements are and have presented this to my client, we'll see which
solution we'll end up persuing.

1) Put into evidence that there always is enough time _between_ reads
to perform a scratch refresh. When measuring timing on the original
machine this seems OK but this needs firm evidence.
2) Using dual SDRAMs
3) Using a 4x size SDRAM, and toggle between banks
4) Using NOR-flash
5) Using SRAM (already out because of the price)

Solutions involving changing the original CPU is out of the question,
and the same applies to changing the original software. This since the
application is medical, and any changes on that level would require re-
validations and certifications, costs for that are unreasonable.


Again, thanks a lot for your efforts!

/Johannes