DDR SDRAM Controller

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.

bxbxb3

"bxbxb3" <> writes:

> 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
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

Kai Harrekilde-Petersen

On Mon, 24 Jan 2005 06:56:03 +0100, Kai Harrekilde-Petersen
<> wrote:

>"bxbxb3" <> writes:
>
>> 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.

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

Allan Herriman

bxbxb3 wrote:
> 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.

Jerry Coffin

Jerry Coffin wrote:
> 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

a

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.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jerry Coffin

Allan Herriman <> writes:

> On Mon, 24 Jan 2005 06:56:03 +0100, Kai Harrekilde-Petersen
> <> wrote:
>
>>"bxbxb3" <> writes:
>>
>>> 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.
>
> 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
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

Kai Harrekilde-Petersen

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

bxbxb3 wrote:
> 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.
>

FMF

bxbxb3 <> wrote:
> 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?

gthorpe@ee.ryerson.ca