DDR SDRAM Controller

[bxbxb3]

Hi,
Can anybody tell me how does a DDR SDRAM work. What is the state of the
row and column address buses during precharge, idle and refresh
operations. And is it required to have a refresh operation every 64ms even
when the controller is engaged in a write burst? Thanks in advance.

 

[Kai Harrekilde-Petersen]

Hi,
Can anybody tell me how does a DDR SDRAM work. What is the state of the
row and column address buses during precharge, idle and refresh
operations. And is it required to have a refresh operation every 64ms even
when the controller is engaged in a write burst? Thanks in advance.

I would recommend you to find the JEDEC standard and perhaps a few
datasheets on DDR SDRAMs and read them. They will answer your
questions.

WRT refresh: yes, you need to stop whatever you're doing and perform a
refresh every X ms. That's the whole point of refresh cycles.

Regards,


Kai

 

[Allan Herriman]

I would recommend you to find the JEDEC standard and perhaps a few
datasheets on DDR SDRAMs and read them. They will answer your
questions.

WRT refresh: yes, you need to stop whatever you're doing and perform a
refresh every X ms. That's the whole point of refresh cycles.

Not quite. There is a requirement for each row to be touched every
64ms. If the write burst does that, there is no need for a separate
explicit refresh.

Note that some recent DDR SDRAMs contain DLLs that run a calibration
cycle during the refresh operation. Such parts will have a
specification for the maximum time between refreshes, which is
typically a *lot* less than 64ms.

Regards,
Allan

 

[Jerry Coffin]

Hi,
Can anybody tell me how does a DDR SDRAM work.

Sure -- JEDEC can. It sounds like you've read at least some already,
but:

http://www.jedec.org/DOWNLOAD/search/JESD79D.pdf

is the DDR "bible."

What is the state of the
row and column address buses during precharge, idle and refresh
operations.

Page 18 has a table of what signals are used in what states.

And is it required to have a refresh operation every 64ms even
when the controller is engaged in a write burst? Thanks in advance.

Page 26 under "Auto Refresh:

To allow for improved efficiency in scheduling and
switching between tasks, some flexibility in the
absolute refresh interval is provided. A maximum of
eight AUTO REFRESH commands can be posted to any
given DDRSDRAM, and the maximum absolute interval
between any AUTO REFRESH command and the next AUTO
REFRESH command is 8 * tREFI.

At any given time you can only issue a write request if it'll finish
before you need to issue your next auto refresh command. Presumably you
have a state machine with a counter to determine when to issue a
refresh command. In that case, you also check the counter to determine
when you can't issue write commands. For example, if your write burst
takes a maximum of 10 half-cycles, then you only issue a write burst
command if that counter is greater than 10.

Alternatively, you might have a controller with one process to do
reads, one to do writes, and one that does nothing but issue refresh
commands. If so, you'd probably divide the main clock down to the
frequency at which refreshes are needed. In that case, the divider can
also produce a write- inhibit signal N cycles ahead of the refresh
signal, and you'd AND this with the write process' usual enable signal.

Note that I'm not particularly recommending this model -- at least to
me, a state machine seems simpler. Nonetheless, if you do use this
model, inhibiting writes during that interval should be one of the
easier parts of the design.

--

Later,
Jerry.

The universe is a figment of its own imagination.

 

[Jerry Coffin]

Allan Herriman wrote:

[ ... ]

Not quite. There is a requirement for each row to be touched every
64ms. If the write burst does that, there is no need for a separate
explicit refresh.

Yes and no. With older DRAMs, you created a CAS before RAS cycle to do
a refresh, so you knew what addresses were handled by a particular
refresh, and if you were writing to those addresses, you could skip the
refresh.

With a DDR SDRAM, you only issue an auto-refresh command, and it has an
internal refresh controller that decides what addresses to refresh at
any given time. Since you don't know what addresses are being
refreshed, you can't skip refresh cycles selectively. OTOH, you can
skip refresh cycles (entirely) as long as you ensure that every
location on the chip (that you care about) is written at last once
every 64 ms.

--

Later,
Jerry.

The universe is a figment of its own imagination.

 

[a]

Allan Herriman wrote:

[ ... ]

Not quite. There is a requirement for each row to be touched every
64ms. If the write burst does that, there is no need for a separate
explicit refresh.

Yes and no. With older DRAMs, you created a CAS before RAS cycle to do
a refresh, so you knew what addresses were handled by a particular
refresh, and if you were writing to those addresses, you could skip the
refresh.

With a DDR SDRAM, you only issue an auto-refresh command, and it has an
internal refresh controller that decides what addresses to refresh at
any given time. Since you don't know what addresses are being
refreshed, you can't skip refresh cycles selectively. OTOH, you can
skip refresh cycles (entirely) as long as you ensure that every
location on the chip (that you care about) is written at last once
every 64 ms.

Actually, once you exit the state that writes to each address location
once within 64ms you can* revert to using refresh commands.

*To do this you have issue enough refresh commands (immediately after
exiting the burst state) to cover the worst case scenario of
miss-alignment between where your burst address was up to and where the
internal refresh counters may be up to. This depends on the size of RAM
and the frequency your clocking it at.
-a

 

[Jerry Coffin]

a wrote:

[ ... ]

Actually, once you exit the state that writes to each address location
once within 64ms you can* revert to using refresh commands.

*To do this you have issue enough refresh commands (immediately after

exiting the burst state) to cover the worst case scenario of
miss-alignment between where your burst address was up to and where the
internal refresh counters may be up to. This depends on the size of RAM
and the frequency your clocking it at.

Ah, good point. That's a situation I hadn't considered.

 

[Kai Harrekilde-Petersen]

Not quite. There is a requirement for each row to be touched every
64ms. If the write burst does that, there is no need for a separate
explicit refresh.

I actually left that out on purpose. Sometimes it's better to do the
"full dance" before trying 'clever' optimizations.

Regards,


Kai

 

[FMF]

You might want to look at a VHDL model of a DDR SDRAM. You can find
some at www.eda.org/fmf/

 

[gthorpe]

Hi,
Can anybody tell me how does a DDR SDRAM work. What is the state of the
row and column address buses during precharge, idle and refresh
operations. And is it required to have a refresh operation every 64ms even
when the controller is engaged in a write burst? Thanks in advance.

I have an additional question: how can you design the controller so that it
can overlap certain commands e.g. overlap the precharge of one bank with
read, write or bank activation for a separate bank?

Also, I am thinking that having this feature will only be useful if the
address bus's master devices can issue commands while previous commands are in
progress (e.g. if the processor can only issue a read and has to wait for it
to complete before it issues another command then nothing can be overlapped by
the memory controller). Do processors support this in general (specifically,
would anyone happen to know the semantics of the front side bus used by the
Pentium 4 [I think it is the Scalable Bus, a superset of the P6 bus protocol)?
Any pointers?

 

[a]

Hi,
Can anybody tell me how does a DDR SDRAM work. What is the state of the
row and column address buses during precharge, idle and refresh
operations. And is it required to have a refresh operation every 64ms even
when the controller is engaged in a write burst? Thanks in advance.

I have an additional question: how can you design the controller so that it
can overlap certain commands e.g. overlap the precharge of one bank with
read, write or bank activation for a separate bank?

Also, I am thinking that having this feature will only be useful if the
address bus's master devices can issue commands while previous commands are in
progress (e.g. if the processor can only issue a read and has to wait for it
to complete before it issues another command then nothing can be overlapped by
the memory controller). Do processors support this in general (specifically,
would anyone happen to know the semantics of the front side bus used by the
Pentium 4 [I think it is the Scalable Bus, a superset of the P6 bus protocol)?
Any pointers?

You can overlap commands when using the burst read or burst write command.
e.g. Burst length = 8.
cycle 0 - ACTIVE BANK 0 ROW 0
cycle 1 - NOP
cycle 2 - NOP
cycle 3 - WRITE BANK 0 COL 0
cycle 4 - NOP
cycle 5 - NOP
cycle 6 - NOP
cycle 7 - WRITE BANK 0 COL 8
cycle 8 - NOP
cycle 9 - NOP
cycle 10- NOP
cycle 11- WRITE BANK 0 COL 16
....etc

You can issue other commands in cycles 4,5,6 and 8,9,10 etc to other
banks. It is also possible to get full bandwidth utilisation by opening
a row in the next bank before you finish writing to the current row in
the current bank. So when you finish writing to the current bank's row
you can go to the next bank's active row immediately with no lost
cycles. You can then precharge the previous banks row and continue on
and on...
....
cycle 251- WRITE BANK 0 COL 496
cycle 252- ACTIVE BANK 1 ROW 0
cycle 253- NOP
cycle 254- NOP
cycle 255- WRITE BANK 0 COL 504
cycle 256- NOP
cycle 257- NOP
cycle 258- NOP
cycle 259- WRITE BANK 1 COL 0
cycle 260- PRECHARGE BANK 0 ROW 0
cycle 261- NOP
cycle 262- NOP
cycle 263- WRITE BANK 1 COL 8
....

You can access the whole SDRAM in one continuous go using this
interleaving fashion as long as you meet the refresh requirements.
Note that this makes your refreshing scheme non trivial.
See previous posts.
-a

 

[Guest]

You can overlap commands when using the burst read or burst write command. [...]
You can access the whole SDRAM in one continuous go using this
interleaving fashion as long as you meet the refresh requirements.
Note that this makes your refreshing scheme non trivial.
See previous posts.

Thanks for your response. I know that the SDRAM is capable of overlapping
commands: my problem is I don't know how to design the _controller_ to do it
effectively! The refresh scheme I can solve by using a separate process and
using an arbiter (refresh gets preference over SDRAM commands) and by having
the units which does the reads/writes look at how much time is left for
refresh when executing commands.

I don't know how to coordinate several operations in flight and I think it
resembles pipelining, but the variable timing (it depends on bank state)
makes it different (harder).