DDR-II - How It Works

by Ryszard Sommefeldt on 5 February 2004, 00:00

Quick Link: HEXUS.net/qav6

Add to My Vault: x

DDR-II

It's nearly here, time to explain it then


DDR-II. What do you think of when you see that written on a spec sheet or a website? DDR at twice the frequency? DDR on a 2x bigger bus? Plain old dual-channel DDR, just written differently? I didn't have a clue either. And when I see it written as DDR2, I get another little bit of confused added on top. Do they mean DDR-II, have they missed a G off the front while talking about graphics card memory? Aieee, it's a bit of minefield at the moment. My thinking is that if I have to explain DDR-II to the HEXUS readership in coming months - Grantsdale and its big brother Alderwood aren't far away now - I should get myself familiar with it. The little article is the result.

It's basically a stupidly good article by MS over at LostCircuits, digested and simplified down to the basics. Imitation is the sincerest form of flattery they say. So here goes.

Simple DDR Explanation

DDR works by taking a driven clock - front side bus frequency usually and modified by multipliers/divisors, enabling it to run to its rated frequency - and outputting two bits of data onto the memory bus from the DRAM's I/O buffers, per driven clock cycle. This is done on the rising and falling edge of that driven clock with DDR, giving it the double data rate moniker; data is read from and written to the bus twice per clock cycle, compared to SDR memory.

The mechanisms that allow a collection of DRAMs on a DDR DIMM to do that, outputting two bits of data per driven clock cycle, aren't too difficult to understand, but can be easily skipped over if you don't want to know the details. Here's a quick summary.

The CPU requests data from a certain memory address and passes that address over the CPU-to-memory controller bus. The memory controller recieves the data request and opens the correct memory bank on the DRAM that holds it, on the correct installed DIMM in the computer. The DRAM is arranged as an array of memory cells, in regular rows and columns. Accesses to the DRAM are done on a column by column basis, so the correct column on the DRAM is accessed and the DRAM instructed to deposit the contents of the address required onto the output pins of the memory module, allowing the memory controller to access it and pass it back to the CPU. The same happens during a memory address write, however the memory controller puts the data on the input pins of the memory module and its written to the DRAM on the correct column, held open like before.

Obviously that's done on a clock cycle basis, from the driven clock of the memory controller, and the DRAM accesses are also governed on a cycle by cycle basis internally. This is where memory timings come in, for example tRAS, the minimum time a memory bank needs to be held open, in numbers of cycles, so that a successful read or write can happen without data corruption. Data buffers on the DRAMs are used to buffer input and output from the cells on the DRAMs to the I/O pins on the module. It's these data buffers that are the key to understanding the difference between DDR and DDR-II.

So per driven clock cycle on the memory controller, the DRAM device can work with two bits of data, twice per clock (DDR), using the mechanism outlined above. Here's how DDR-II takes a different approach with its data buffers, to offer double the data frequency (effective bandwidth) for the same driven clock.

DDR-II

The key to DDR-II bandwidth is the core is running at 1/2 clock frequency of the I/O buffers - it follows that the data buffers are running at twice the frequency of the core. Add a DDR protocol and you are getting four transfers for each core clock cycle. With DDR and a 100MHz driven clock, the data buffers on the DDR DRAM device also run at 100MHz. The DDR principle then makes that 200MHz. With DDR-II the data buffers will run at 200MHz at the same driven clock. This allows them to essentially work on four bits of data per clock cycle, either read or written. Finally, apply the DDR concept to that, where it's done twice per clock, once on the rising edge and once on the falling edge, and you get an effective data frequency of 400MHz for that 100MHz initial clock frequency.

That's the essence of DDR-II. Here's it laid out simply.

DDR : 100MHz driven clock -> 100MHz data buffers -> DDR applied -> 200MHz final data frequency
DDR-II: 100MHz driven clock -> 200MHz data buffers -> DDR applied -> 400MHz final data frequency

The same essential principles still apply, memory timings are still in effect, but will take a different form from the current timings we've just become happy talking about with DDR DRAMs and memory devices.

Voltage and Latency

The last things worth talking about in this article, cribbed from the LC parent, are voltage and memory latency. The signalling voltage for DDR memory, as laid out by JEDEC, is 2.5V. As we all know, running closer to 2.8V is the norm these days, especially with high performance memory, be it DDR400 speeds and very low latency, or DDR500 speeds and higher latency.

The signalling voltage for DDR-II is 1.8V. Using similar principles to those that we apply to CPUs, lower signalling voltage allows for higher clock frequencies. Lower voltage means less time needed for it to swing between no voltage, the signalling voltage, and then back again. Less voltage should also manifest itself in less heat and power consumption. Given that 4GB of DDR400 can draw 40W during a read, saving power with a lower voltage requirement will benefit everyone.

Latencies, specifically access latencies, where the DRAM is instructed to give up the goods onto the I/O pins, are expected to run to CAS-4 or CAS-5, especially in higher speed parts. As the LC article mentions, we gave up those kinds of access latencies back when we moved away from PC100 SDR SDRAM. tRAS also looks to be 8 cycles at the very minimum, given DRAM specifications from Samsung. We're used to tRAS being 8 cycles when running DDR500 speeds with current DDR, but it's common knowledge that low tRAS latencies are key to extracting maximum memory bandwidth performance on current memory controllers. Certain memory access patterns, random access mainly, will surely hurt when done on DDR-II modules, compared to DDR.

Final thoughts

The rumours of DDR-II being backwards compatible with DDR in the electrical and packaging senses are false. DDR-II now requires more pins on the modules, despite sharing the same bus width per DIMM as DDR (64-bit/8-byte) and the signalling and DRAM voltage requirement of 1.8V (although some current DDR DRAMs run at 1.8V too, depending on manufacturer, DIMM and DRAM lineage) make the new standard wholly incompatible with the old.

DDR-II will be cheaper to make, will consume less power and give off less heat, but it will also suffer from access latency issues and the usual problems with transitioning to a new memory format, especially since it doesn't fit in the same slots as before.

However, given Intel's desire to ramp up clock speed and AMD getting more and more sophisticated in their memory controller design and implementation, the need for ever more bandwidth is clear. Somebody has to feed 5GHz Prescotts and it sure won't be RAMBUS, new products with silly bandwidths or not. We'll have to wait and see before making a final judgement on performance; will memory controller design for DDR-II and the modules themselves conspire to make the access latency issue a big one that sheer bandwidth can't overcome?

Or will it turn out to be decent enough and we'll just get on with it, on the desktop at least? Looks like we'll have to, Intel are trying to force the issue. On the AMD side of the fence, don't look for them to support DDR-II on their processors in 2004 in any capacity. Who will market fragmentation hurt more? Who knows, but the inability to move DDR or DDR-II modules between systems based on the competing CPUs won't help you the consumer. It seems that IHVs will create Grantsdale boards that support plain old DDR to help smooth things over.

It's about to arrive on the Intel desktop in a big way and we'll have DDR-II modules and supporting boards to play with in the near future, to semi-evaluate performance before everything hits in Q2, so hopefully this article is of some use to you in thinking about the transition and what it means for memory performance in the future.