SDRAM and DDR (DDR2 - 3 - 4 - 5) evolution: Visual walkthrough

We will only use two ideas from outside: a clock (a signal that ticks) and a byte (8 bits). Everything else is built here.

Step 1 — The one slow thing: a capacitor cell

WHAT: we look at how long one read takes. WHY: because this single number is the villain of the entire story — if it were small, no DDR trickery would be needed. PICTURE:

Figure — SDRAM and DDR (DDR2 - 3 - 4 - 5) evolution

The bucket fills the wire slowly. The time from "open switch" to "voltage is readable" is the column access time, and it has sat near

$t_{access} \approx 15 ns$

$t_{access}$ — the delay you cannot avoid, set by physics of charge, not by cleverness.
$ns$ — nanoseconds, billionths of a second. $15 ns$ means about $66$ million reads per second from one cell path.

Step 2 — Turn "time per read" into a core clock

WHAT: we convert that $15 ns$ delay into a clock frequency the array can sustain. WHY: so we can compare it with the fast bus clock and see the gap we must bridge. PICTURE:

A clock is a square wave: up, down, up, down. If one tick must be at least $t_{access}$ long, the fastest the core can tick is:

$f_{core} = \frac{1}{t _{access}} \approx \frac{1}{15 ns} \approx 66 MHz (per single path)$

In real chips the array is clocked around $f_{core} \approx 100 - 200$ MHz once many cells work together.

$f_{core}$ — how often the slow array can produce a fresh chunk.
$\frac{1}{t _{access}}$ — "one read per $t_{access}$ seconds" flipped into "reads per second". We invert because frequency is the reciprocal of period — a small period means a high frequency.

Hold this: $f_{core} \approx 200$ MHz. It will never change for the rest of the page.

Step 3 — Why one wire per read is hopelessly slow

WHAT: we imagine feeding the CPU straight from the core, one bit at a time. WHY: to expose exactly how much faster the bus wants to run than the core can supply. PICTURE:

The CPU's bus wants to run at, say, $800$ MHz. The core delivers at $200$ MHz. So the bus sits starving three ticks out of four — the fast conveyor belt has nothing to carry.

$gap = \frac{f _{bus}}{f _{core}} = \frac{800}{200} = 4$

$f_{bus}$ — how fast the wires can toggle.
The ratio $4$ means: to keep the belt full, each core read must hand over 4 things at once. That "4 at once" is the seed of prefetch.

Step 4 — Prefetch: fill many buckets in one slow trip

WHAT: widen the read inside the chip so one slow trip yields several bits. WHY: because we can't speed the trip up, but we can make each trip carry more — the bucket-brigade trick. PICTURE:

One slow read grabs $n$ bits at once (top). A small fast shift register (bottom) then spits them out at bus speed. The core ticked once; the bus ticked $n$ times.

$bus bits per core tick = prefetch = n$

$n$ — the prefetch width: $1, 2, 4, 8, 16$ across the generations.
The register is what decouples slow-inside from fast-outside: it absorbs a big gulp, releases a fast stream.

Step 5 — The "D" in DDR: use the falling edge too

WHAT: send data on both the rising and falling edge of the bus clock. WHY: SDR (single data rate) wastes half the clock — the falling edge carries nothing. Using it doubles output for zero extra clock speed. PICTURE:

Top = SDR: a bit only on the ▲ up-edges. Bottom = DDR: a bit on ▲ and ▼. Same clock, twice the bits.

$edges per cycle = {12 SDR (rising only) DDR (rising + falling)$

The clock frequency is identical in both rows.
We double throughput by counting both edges — that's why the metric splits into two names. See below.

Step 6 — Assemble the master formula

WHAT: multiply the three independent multipliers we just built. WHY: each one answers a different question, so they stack cleanly. PICTURE:

Three gears in a chain — core, prefetch, edges — turning the slow $200$ MHz into a fast data rate:

$f_{data rate} = slow, fixed f_{core} \times n bits/read prefetch \times 1 or 2 (edges)$

$f_{core}$ — the frozen villain, $\approx 200$ MHz.
$prefetch$ — how many bits one slow read yields (Step 4).
$edges$ — 1 for SDR, 2 for DDR (Step 5).

Then bandwidth just tacks on the bus width $w$ :

$BW = f_{data rate} \times \frac{w}{8}$

$\frac{w}{8}$ — bytes per transfer ( $w$ bits ÷ 8 bits/byte). We divide by 8 to convert bits to bytes, the unit modules are stamped in. See Memory bandwidth vs latency.

Check DDR3-1600 (Step-by-step reverse): core $200$ × prefetch $8$ × edges... wait — DDR3 also runs the I/O clock at 4× core, then doubles again on both edges. So $200 \times 4 = 800$ MHz I/O clock, $\times 2$ edges $= 1600$ MT/s. ✓ The slow core is still $200$ MHz.

Step 7 — Edge case: why prefetch stops at 8n

WHAT: we test what happens if we keep doubling prefetch forever. WHY: the pattern "double prefetch → double speed" breaks, and a good derivation must show where its own rule dies. PICTURE:

Prefetch $n$ forces a minimum burst of $n$ bits — you always fetch that many even if the CPU wanted fewer. At $16 n$ , $32 n$ the burst overshoots typical cache-line needs: the extra bits are thrown away → wasted bandwidth (grey bits in the figure).

$useful bits \leq fetched bits = prefetch$

When fetched > needed, the difference is pure waste.
So DDR4 froze prefetch at 8n and instead added bank groups; DDR5 split the channel into two 32-bit subchannels, each 8n → effectively 16n without a 16-bit-wide burst. Evolution shifted from bigger gulps to more independent gulps — concurrency, not burst size.

Step 8 — Degenerate case: SDR falls out for free

WHAT: set edges $= 1$ and prefetch $= 1$ in the master formula. WHY: a formula you trust must reproduce the simplest case with no special handling. PICTURE:

$f_{data rate} = f_{core} \times 1 \times 1 = f_{core}$

At PC100: $f_{core} = 100$ MHz, $w = 64$ bits:

$BW_{SDR} = 100 \times 1 0^{6} \times \frac{64}{8} = 800 MB/s$

Exactly the parent's "PC100 = 800 MB/s". The gears simply have ratio 1 — the machine still works, it just isn't geared up yet.

The one-picture summary

One slow well ( $200$ MHz core) → a wide prefetch scoop (fill $n$ buckets at once) → a fast double-edge belt (drop a bucket on ▲ and ▼) → the CPU. Each generation only enlarges the scoop and speeds the belt; the well never gets faster.

$f_{data rate} = f_{core} \times prefetch \times edges, BW = f_{data rate} \times \frac{w}{8}$

Recall Feynman retelling — say it to a 12-year-old

There's a slow well and a fast conveyor belt. You can't make the well fill faster — that's the $15$ nanosecond capacitor, frozen for 25 years. So two tricks: (1) every time you go to the well, scoop up many buckets at once (that's prefetch — 1, then 2, 4, 8, 16 buckets). (2) Put a bucket on the belt every time the belt-arm goes up AND down, not just up (that's the double in DDR). Multiply: buckets-per-trip × edges-per-tick × how-often-the-well-runs = your speed. Every new DDR just scoops more or runs the belt faster — until the scoop got too big ( $8 n$ ) and you'd carry buckets nobody ordered, so instead they dug more independent wells (bank groups, subchannels). Same water, cleverer plumbing.

Recall Quick self-test

Master formula in words? ::: data rate = core clock × prefetch × edges per cycle DDR3-1600 core clock? ::: 200 MHz (÷2 edges = 800 I/O, ÷4 prefetch-clock = 200) Why did prefetch freeze at 8n? ::: bigger bursts fetch data nobody needs → wasted bandwidth SDR from the master formula? ::: prefetch=1, edges=1 → data rate = core clock

Connections

DRAM cell structure and refresh — the slow capacitor of Step 1
CAS latency and memory timings — the "15 ns" written as clock cycles
Bank groups and interleaving — Step 7's replacement for bigger prefetch
Memory bandwidth vs latency — why the $\frac{w}{8}$ in Step 6 isn't the whole story
Signal integrity and voltage scaling — the cost of running the belt ever faster
Cache and the memory hierarchy — who orders the buckets