DRAM Controllers, JEDEC Timing, and the DFI Interface

01.Part 1, one capacitor, and everything that follows from it

1.1 The cell, and why it forgets

Every idea in this note descends from one physical fact, so start there and derive rather than assert.

A DRAM bit is one capacitor and one transistor. The capacitor holds charge or does not, and the transistor connects it to a long vertical wire called the bitline when a horizontal wire called the wordline is driven high. That is the entire cell. Compare it to the six-transistor SRAM cell in SRAM Arrays and ECC, which holds its value with a pair of cross-coupled inverters actively fighting to keep it. The SRAM cell is powered and self-correcting. The DRAM cell is a bucket.

Buckets leak. The capacitor's charge drains through the access transistor's subthreshold conduction, through junction leakage into the substrate, and through the dielectric. From Power Fundamentals and Clock Gating, subthreshold leakage rises roughly exponentially with temperature, so the leak gets much faster when the part gets hot. JEDEC's answer is a guaranteed retention window: every cell must hold a readable value for at least 64 ms at or below 85 °C for DDR4, halving to 32 ms above that. DDR5 assumes a 32 ms window as its baseline.

That single number generates a timing parameter you will meet again in Part 4. JEDEC does not ask the controller to name rows. It divides the retention window into 8192 REFRESH commands and requires that all 8192 be issued inside it, so the average interval between refresh commands is

$t_{REFI} = \frac{64\ \text{ms}}{8192} = 7.8125\ \mu\text{s}$

for DDR4 at normal temperature, and

$t_{REFI} = \frac{32\ \text{ms}}{8192} = 3.906\ \mu\text{s}$

for DDR5, or for DDR4 running hot. Those are not arbitrary constants somebody chose. They are the retention window divided by the number of refresh commands the standard mandates inside it, and being able to say that out loud is a small but real signal.

Be exact about the 8192 if you are pushed on it, because the tempting simplification is wrong and it is a cheap thing to get right. 8192 is a command count, not a row count. Work it out for an 8 Gb DDR4 x8 part: 8 Gb is 1024 MB, divided across 16 banks is 64 MB per bank, divided by a 1 KB row is 65,536 rows in every bank. So one REFRESH command must internally refresh eight rows in each bank, not one, and a denser part refreshes more rows per command still. The controller never sees any of that, which is precisely why JEDEC counts commands rather than rows, and it is also the reason $t_{RFC}$ in Part 4.9 grows with density while $t_{REFI}$ does not.

1.2 Why reading needs an amplifier, with the charge-sharing arithmetic

Here is the part that is genuinely surprising the first time, and it is worth doing with numbers before any abstraction.

The storage capacitor is small. Public figures for recent processes put it in the region of 20 to 30 femtofarads, and it has been held near that value for many generations because the sensing scheme stops working if it shrinks much further. The bitline it must drive is long, running past thousands of other cells, and its capacitance is several times larger, commonly quoted at 100 to 300 fF.

Take $C_{cell} = 25$ fF, $C_{bl} = 250$ fF, and a supply of 1.2 V. Before a read the bitline is precharged to half the supply, 0.6 V, and left floating. Now raise the wordline. The access transistor turns on and the cell capacitor, sitting at 1.2 V for a stored one, shares its charge with the bitline. Charge is conserved, so the final voltage is the total charge divided by the total capacitance.

$V_{final} = \frac{C_{cell} \times 1.2 + C_{bl} \times 0.6}{C_{cell} + C_{bl}} = \frac{25 \times 1.2 + 250 \times 0.6}{275} = \frac{180}{275} = 0.6545\ \text{V}$

The bitline moved from 0.600 V to 0.6545 V. The entire signal is 54 millivolts, and for a stored zero it swings the same 54 mV downward. Nothing in a logic gate can read that. So every bitline terminates in a sense amplifier, a cross-coupled pair that is switched on after the charge sharing has settled and that amplifies whichever side is higher into a full rail-to-rail difference. This is the same device, doing the same job for the same reason, as the SRAM sense amplifier in Part 3 of SRAM Arrays and ECC. The difference is that the SRAM cell keeps driving its bitlines while the DRAM cell has already given up everything it had.

Two consequences follow immediately and both matter.

The read is destructive. After charge sharing the cell no longer holds 1.2 V, it holds 0.6545 V, which is not a stored one by any definition. The value has been consumed by the act of reading it. What saves the data is that the sense amplifier, once it has resolved, drives the bitline hard to the full rail, and the access transistor is still on, so the cell is written back to full strength by the same amplifier that read it. Reading a DRAM row is really read-amplify-restore, and the restore is not instantaneous. That is the physical content of $t_{RAS}$, which Part 4 will name.

Precharge is a real operation with a real cost. Before the next read the bitline must be returned to exactly half the supply everywhere along its length, because the 54 mV signal is measured against that reference and a bitline left at the previous value would swamp it. Driving a long, heavily loaded wire to a precise mid-rail value and letting it settle is the physical content of $t_{RP}$.

1.3 The row buffer is the row of sense amplifiers

The cells are laid out in a rectangular array. A wordline runs horizontally across thousands of cells, each of which hangs off its own vertical bitline, and each of those bitlines has its own sense amplifier at the edge of the array.

The strip of sense amplifiers now holds every bit that was on that wordline. In DDR4 and DDR5 a row is commonly 1 KB or 2 KB per device, and the strip is called the row buffer, the open page, or the open row depending on who is talking. All three mean the same thing.

Now the fact that reorganises everything. Getting a row into the row buffer is expensive. Getting a column out of an already-open row buffer is cheap. The expensive part is the physics of Part 1.2, the charge sharing and the amplification and the restore. The cheap part is a multiplexer selecting some bits out of a strip of latched, full-rail values. So a memory system's performance is dominated not by how much data you move but by how often you have to move a new row into the buffer, which is Part 3 and, transitively, the entire rest of this note.

1.4 The three commands, before any timing

A DRAM device is a slave. It has no idea what an address means and never issues anything on its own. The controller sends commands on a command/address bus and the device obeys. Three commands carry essentially all the traffic.

ACTIVATE, usually written ACT, takes a bank number and a row number and performs the read-amplify-restore of Part 1.2. After it completes, that bank's row buffer holds that row and the bank is said to have an open row.

READ and WRITE, usually written RD and WR, take a bank number and a column number and move a burst of data between the row buffer and the data pins. They do not touch the array. They require the bank to already have the right row open, and it is the controller's job to guarantee that. If the controller issues a READ to a bank whose open row is the wrong one, the device does not complain, it returns the wrong data.

PRECHARGE, usually written PRE, closes the open row and returns the bitlines to mid-rail so the bank is ready for a different ACTIVATE.

Two more commands round out the set for now. REFRESH, REF, is Part 7. NOP or deselect is the absence of a command, and a real command bus spends most cycles doing exactly that.

There is no cache, no reordering, no protection, and no error signalling in the device. Every one of those functions, if it exists at all, lives in the controller. Say that plainly in an interview, because a surprising number of candidates describe DRAM as though it were an intelligent peer.

---

02.Part 2, how a DRAM part is organised

2.1 Banks, and the number that justifies them

Suppose a device had exactly one array with one row buffer. Then every access that wanted a different row would have to precharge, activate, and read, in that order, with no overlap possible, because there is only one set of sense amplifiers and one wordline driver.

Put a number on how bad that is. Using JEDEC DDR4-3200 as the running example throughout this note, with a clock period $t_{CK} = 0.625$ ns, the minimum time between one ACTIVATE and the next ACTIVATE to the same bank is $t_{RC}$, about 45.75 ns. One column read of a burst of eight on a 64-bit channel delivers 64 bytes and occupies the data bus for four clocks, $t_{CCD}$, which is 2.5 ns.

So a single bank doing one 64-byte access per row activation delivers

$\frac{64\ \text{B}}{45.75\ \text{ns}} = 1.40\ \text{GB/s}$

against a channel peak of $3200 \times 8 = 25.6$ GB/s. One bank can fill about five and a half percent of the bus. To saturate the bus under that access pattern you need

$\left\lceil \frac{t_{RC}}{t_{CCD}} \right\rceil = \left\lceil \frac{45.75}{2.5} \right\rceil = 19$

banks working concurrently, each one in a different phase of its own activate-read-precharge cycle so that their data bursts interleave back to back on the shared bus.

That derivation explains a fact about the standards that otherwise looks like arbitrary escalation. DDR3 x8 devices have 8 banks. DDR4 x8 devices have 16, arranged as four bank groups of four. DDR5 doubled it again to 32, as eight groups of four. Nobody added banks for capacity, since banks do not add bits. They added banks because $t_{RC}$ did not shrink while the data rate kept doubling, so the number of concurrent activations required to keep the bus busy kept climbing. Note the honest consequence, which is that even 16 banks is short of 19, and Part 4.8 will show a second constraint that binds before the bank count does.

Physically, a bank is an independent array with its own row decoder, its own sense-amplifier strip, and its own row-open state. Banks share the command bus, the address bus, and the data bus. That sharing is the whole game: the controller can have many banks busy internally at once, but only one command can be issued per command-bus slot and only one burst can be on the data bus at a time. Bank parallelism is latency overlap, not bandwidth multiplication.

2.2 Bank groups, and why DDR4 had to invent them

Bank groups are the one piece of DRAM organisation that people get wrong most often in interviews, and the reason they exist is worth working through rather than memorising.

By DDR4 the external data rate had reached 1.6 to 3.2 gigatransfers per second, so a burst of eight occupies only 2.5 ns of bus time. But the shared circuitry inside the device that reads a row buffer, muxes out the selected columns, serialises them, and drives them to the pins does not run anywhere near that fast. It runs at a lower internal frequency and works on a wide word, which is the prefetch architecture: DDR4 fetches 8 bits per pin per column access, DDR5 fetches 16. The internal path from a bank's sense amplifiers to the serialiser therefore has a recovery time, and that recovery time is longer than $t_{CCD}$ at high data rates.

The fix is to replicate the shared path. Divide the banks into bank groups, and give each group its own local sense-amplifier readout path. Now two column accesses to different bank groups can be issued back to back at the full bus rate, because they use different internal paths, while two column accesses to the same bank group must be spaced further apart, because they share one.

That is why almost every DDR4 and DDR5 timing parameter comes in two flavours, a short one for different bank groups and a long one for the same bank group.

For DDR4, $t_{CCD\_S}$ equals the burst length in clocks, four clocks for a burst of eight, so a controller that alternates bank groups can issue a column command every single burst and keep the data bus completely full. $t_{CCD\_L}$ is materially longer, and JEDEC specifies it in exactly the two-term form Part 4.1 unpacks, $\max(5\,n\text{CK},\ 5\ \text{ns})$. At DDR4-3200 the nanosecond term wins, so $t_{CCD\_L}$ is 8 clocks, twice $t_{CCD\_S}$. At DDR4-1600 the $n$CK term wins instead and it is 5 clocks, only a quarter longer than the short version. The penalty for ignoring bank groups therefore gets worse as the part gets faster, which is the same divergence as everywhere else in this note and is worth noticing rather than memorising either number.

The design consequence is concrete and is the correct answer to "what do bank groups change in your scheduler." The address mapping should place the bank-group bits low enough that a sequential stream walks across groups, and the command scheduler should prefer a ready command in a different bank group over an equally ready command in the same one. A controller that ignores bank groups can lose a large fraction of peak bandwidth on a perfectly sequential stream without a single row miss, which is the counterintuitive part worth saying out loud.

2.3 Ranks, channels, and subchannels

Above the device there are three more levels and they are frequently confused.

A rank is a set of DRAM devices that are selected together by one chip-select and that respond in lockstep to produce the full channel width. Eight x8 devices in a rank give a 64-bit data path. Sixteen x4 devices do the same. Every device in a rank sees the same command at the same time and contributes its slice of every burst. Ranks share all the pins, so switching between ranks costs a bus turnaround penalty, but they provide independent bank state, so a second rank roughly doubles the number of banks the controller can juggle.

A channel is a complete, independent memory interface: its own command bus, its own address bus, its own data bus, and its own controller. Two channels are two memory systems that happen to share an address space. Their bandwidths add.

DDR5 adds a level that did not exist before. A DDR5 DIMM presents its 64 data bits as two independent 32-bit subchannels, each with its own command and address bus and its own bank-group hierarchy. This is not cosmetic. A burst of sixteen on a 32-bit subchannel delivers $32 \times 16 = 512$ bits, which is exactly 64 bytes, exactly one cache line. So DDR5 doubled the number of independently addressable memory pipes without changing the granularity at which a cache line arrives, which is a far better answer to "what did DDR5 actually change" than "it is faster."

2.4 A concrete address decomposition, with small numbers

Abstract hierarchy is useless until you decode an address by hand, so build a deliberately tiny device that fits on a page.

The toy device. Four banks. Eight rows per bank. Eight columns per row. Each column access delivers one 64-byte cache line.

Compute the capacity from the bottom up. One row is $8 \times 64 = 512$ bytes. One bank is $8 \times 512 = 4096$ bytes. The device is $4 \times 4096 = 16{,}384$ bytes, so a physical address is 14 bits, $A[13{:}0]$.

Now the fields. Six bits, $A[5{:}0]$, are the byte offset inside the 64-byte line and never reach the DRAM at all, because the smallest thing the memory system moves is a whole line. Three bits select one of eight columns. Three bits select one of eight rows. Two bits select one of four banks. That is $6 + 3 + 3 + 2 = 14$ bits, and it accounts for every one.

What the controller must decide is which address bits get assigned to which field. Nothing in the DRAM cares. The device sees a bank number, a row number, and a column number on its pins, and it has no opinion about where they came from. The mapping is entirely a controller design choice, it is a pure combinational function, and Part 5.2 shows that it is worth roughly an order of magnitude of performance on realistic traffic.

Take the natural-looking assignment first, the one almost everyone writes down without thinking, with the fields in the order row, bank, column, offset from the most significant bit down.

Decode address $0$. All bits zero, so row 0, bank 0, column 0.

Decode address $4096 = \texttt{0b01\_0000\_0000\_0000}$, which has only bit 12 set. Then $A[13{:}11] = \texttt{010} = 2$, so row 2. $A[10{:}9] = \texttt{00} = 0$, so bank 0. $A[8{:}6] = \texttt{000} = 0$, so column 0.

So addresses 0 and 4096 land in the same bank and different rows. Hold onto that, because it is about to cost a factor of ten in Part 5.2.

---

03.Part 3, the row buffer is a cache, and that is the whole model

3.1 Three outcomes, priced individually

An access arrives at a bank. There are exactly three possibilities and they are not equally spaced.

Row hit. The bank already has this row open. Issue RD, wait $t_{CAS}$ for the data to appear on the pins, done. At DDR4-3200 with CL 22, that is $22 \times 0.625 = 13.75$ ns.

Row miss, sometimes called a row-empty or idle-bank access. The bank has no row open, because the last access precharged it. Issue ACT, wait $t_{RCD}$, issue RD, wait $t_{CAS}$. At CL 22 and $t_{RCD}$ 22 that is $13.75 + 13.75 = 27.5$ ns.

Row conflict. The bank has the wrong row open, and only one row can be open per bank because there is only one sense-amplifier strip. Issue PRE, wait $t_{RP}$, issue ACT, wait $t_{RCD}$, issue RD, wait $t_{CAS}$. That is $13.75 \times 3 = 41.25$ ns.

$13.75 : 27.5 : 41.25 \;=\; 1 : 2 : 3$

Three to one, best case to worst, from the device alone. The numbers happen to fall in a clean ratio at the 22-22-22 speed bin because the three parameters are equal there, which is a common but not universal arrangement.

The distinction between a miss and a conflict is the one that gets probed, so be exact about it. A miss finds the bank clean and pays only for opening. A conflict finds the bank dirty and pays for closing first. They are not the same event, and a controller policy that produces many misses can easily be better than one that produces many conflicts, which is precisely the open-page versus closed-page argument in Part 6.3.

3.2 Averaging it, and why the device number is the floor and not the answer

Give a workload a hit rate $h$, a miss rate $m$, and a conflict rate $c$ with $h + m + c = 1$. The average device latency is

$L = 13.75h + 27.5m + 41.25c\ \ \text{ns}$

Three workloads, worked.

Perfectly sequential streaming through a well-mapped address space gives $h$ near 0.9, so $L \approx 13.75(0.9) + 27.5(0.1) = 15.1$ ns. Pointer chasing through a large graph gives essentially $c = 1$, so $L = 41.25$ ns, 2.7 times worse for exactly the same hardware. A mixed workload at $h = 0.5$, $m = 0.2$, $c = 0.3$ gives $L = 6.88 + 5.50 + 12.38 = 24.8$ ns.

Now be honest about what that number is and is not, because this is where a good interviewer separates people who have read about DRAM from people who have measured it. The device latency is the floor. Publicly measured idle memory latency on modern desktop parts lands broadly in the 60 to 90 nanosecond range, and the DRAM device accounts for well under half of it. The rest is the last-level-cache miss handling, the on-chip fabric traversal in both directions from Interconnect and AMBA, the controller's own queueing and scheduling pipeline, the PHY's serialisation and deserialisation, and the fill path back into the cache from Cache Organization and Prefetching. Under load, queueing delay at the controller can exceed every other term combined, because a queue with a utilisation approaching one has an unbounded waiting time.

The sentence to have ready is: the JEDEC parameters set the floor, the scheduler decides how close to the floor you get, and the fabric and the queue decide what the core actually sees.

3.3 Why every later decision is downstream of this one

Everything in Parts 5 through 8 is an attempt to move requests up the picture in 3.1. Address mapping decides which requests land in the same bank and therefore whether they conflict. Scheduling decides the order, and reordering to group same-row requests converts conflicts into hits. Open-page versus closed-page policy is a bet about whether the next request to this bank will hit. Quality of service is the question of whose requests get to be converted into hits when they compete.

Say this once and mean it, because it is the framing that makes the rest of a memory-controller interview coherent rather than a parameter quiz. A DRAM controller is a machine for maximising row-buffer reuse subject to a large set of timing constraints and a fairness requirement. Every mechanism in the rest of this note is one of those three words.

---

04.Part 4, the JEDEC timing parameters, one at a time

4.1 What a timing parameter is, and how to read one

A JEDEC timing parameter is a minimum separation between two commands, expressed either in nanoseconds, in clock cycles written $n$CK, or as the maximum of the two. The device does not enforce them. If the controller issues a command early, the device does something undefined, and undefined for an analogue sense amplifier means corrupted data rather than a clean error. There is no handshake, no ready signal, and no retry. The controller is solely responsible for legality, and that responsibility is the single largest source of RTL in the design.

The "maximum of $n$CK and nanoseconds" form catches people out, so unpack it. $t_{RRD\_S}$ specified as $\max(4\,n\text{CK}, 3.3\ \text{ns})$ means the constraint has two independent physical origins. The nanosecond term is analogue physics inside the array, which does not care what your clock is doing. The clock-cycle term is a digital pipeline inside the device that needs a fixed number of internal beats. Whichever is larger at your operating frequency is the one that binds, and which one binds changes with the speed bin. At a slow clock the $n$CK term dominates. At a fast clock the nanosecond term does. A controller must compute both and take the maximum, and it must do so per frequency point, because a good controller supports several. That is a small but real piece of arithmetic in the RTL and it is worth mentioning unprompted.

Everything below uses JEDEC DDR4-3200 at the 22-22-22 bin, $t_{CK} = 0.625$ ns as the running example, because it is public, widely tabulated, and round enough to do in your head.

4.2 $t_{RCD}$, RAS to CAS delay

The constraint. From an ACTIVATE to the first READ or WRITE to that bank.

The physics. This is exactly the interval Part 1.2 described: raise the wordline, let the cell share its charge onto the bitline, wait for that 54 mV to develop, fire the sense amplifiers, wait for them to resolve to full rail. Only when the row buffer holds valid full-rail data can a column be selected out of it.

The value. 22 clocks, 13.75 ns. Notice that this has barely moved in absolute time across four DRAM generations, because it is governed by charge sharing on a bitline and not by any digital pipeline. Data rates went up several-fold and $t_{RCD}$ went down by a few nanoseconds. That divergence is the memory wall of Cache Organization and Prefetching expressed as a single parameter.

4.3 $t_{CAS}$, also written CL, the column access latency

The constraint. From a READ to the first bit of data on the DQ pins.

The physics. Decode the column address, mux the selected bits out of the row buffer, route them across the die to the output path, serialise them at the pin rate, and drive the pads. Notice that this is a digital pipeline, not an analogue settling time, which is why CL is specified in clocks and why its value in clocks rises steadily with each speed bin while its value in nanoseconds stays roughly flat. DDR4-2133 CL 15 is 14.1 ns. DDR4-3200 CL 22 is 13.75 ns. The number people quote on enthusiast forums went up by seven and the latency went slightly down.

There is a matching CWL, CAS write latency, for writes. It is generally smaller than CL because the write path is shorter, and a controller must track both because they determine when the data bus is occupied and in which direction.

4.4 $t_{RP}$, row precharge time

The constraint. From a PRECHARGE to the next ACTIVATE to that bank.

The physics. Turn off the wordline, then drive every bitline in the bank back to exactly half the supply and let it settle. The 54 mV signal of Part 1.2 is measured against that reference, so the reference has to be right to within a few millivolts along a wire running past thousands of cells. That is the whole cost.

The value. 22 clocks, 13.75 ns.

4.5 $t_{RAS}$ and $t_{RC}$, the row cycle

$t_{RAS}$ is the minimum time from an ACTIVATE to the PRECHARGE of the same bank, and it is the first of three parameters in the set that are floors on how quickly you may close a row rather than floors on how quickly you may act. The other two are $t_{RTP}$ in 4.6 and $t_{WR}$ in 4.7, and the legal precharge instant is the latest deadline any of them imposes, never the earliest.

The physics is the restore. Part 1.2 established that reading destroys the cell, and that what saves the data is the sense amplifier driving the bitline hard and writing the cell back through the still-open access transistor. Restoring a capacitor through a resistive access transistor takes time. Precharge before the restore has finished and you have written a weak, marginal value back into every cell on that row, which will fail retention early and produce a bit flip minutes later somewhere else entirely. That is the failure mode, and note what kind of failure it is: not a timing error visible on a scope, but silent data corruption with a long delay fuse.

The value. 32 ns for DDR4-3200, which is 51.2 clocks and therefore 52 clocks after rounding up. Note that it is not equal to the other three, and note that $t_{RAS} > t_{RCD} + \text{CL}$, which means a bank that opened a row and immediately read from it must still wait a little longer before it is allowed to close.

$t_{RC}$, the row cycle time, is the ACTIVATE-to-ACTIVATE minimum for the same bank and is simply

$t_{RC} = t_{RAS} + t_{RP} = 32 + 13.75 = 45.75\ \text{ns}$

This is the parameter that generated the 19-bank result in Part 2.1 and it is the most important single number in the set, because it is the throughput limit of one bank.

4.6 A worked command timeline

Put the parameters on one picture and walk it, because the interaction between $t_{RAS}$ and $t_{RP}$ is where a hand-drawn schedule usually goes wrong.

Two things in that picture are easy to get wrong on a whiteboard and are worth rehearsing.

First, $t_{RAS}$ is measured from the ACTIVATE, not from the last READ, so a bank that opens a row and reads once still cannot close for the full 32 ns even though it has been idle for most of it. Closing early is not slow, it is illegal.

Second, there is a separate constraint the picture only hints at. $t_{RTP}$, read to precharge, is the minimum from a READ to a PRECHARGE of the same bank, because the column data must finish leaving the row buffer before the bitlines are yanked to mid-rail. The legal precharge time is therefore the later of the $t_{RAS}$ deadline and the $t_{RTP}$ deadline, and a controller that tracks only one of them will occasionally issue an early precharge. In RTL this is not an if-else, it is a set of independent countdown timers per bank whose expiry flags are ANDed into a single pre_legal signal, and that structure generalises to every parameter in this part.

4.7 $t_{WR}$, and why writing is worse than reading

The constraint. $t_{WR}$, write recovery, runs from the end of the write data burst to the PRECHARGE of that bank. DDR4 specifies 15 ns.

The physics. A write does not put a value in the row buffer and stop. It drives the sense amplifier to the new value, the sense amplifier drives the bitline, and the bitline charges the cell capacitor through the access transistor. That last step is charging a capacitor through a resistance and it is slow. Precharge before it completes and the cell holds an intermediate voltage, which is the silent-corruption failure of 4.5 again wearing different clothes.

Note the asymmetry that follows, because it is worth naming explicitly. A read finishes at the pins and a write finishes in the array. A read's cost is visible as latency and the controller can pipeline around it. A write's cost is invisible as latency, because nobody is waiting for a write to complete, but it occupies the bank for a long time after the data has gone by. That is why write-heavy traffic hurts a memory system more than its bandwidth share suggests, and it sets up Part 6.4.

4.8 $t_{RRD}$ and $t_{FAW}$, and the power-delivery argument

These two are the most interesting parameters in the set because neither of them is about the array's logical ability to do the work.

$t_{RRD}$, row-to-row delay, is the minimum between two ACTIVATE commands to different banks. Different banks are independent arrays with their own decoders and their own sense amplifiers, so logically there is no reason at all why they cannot activate simultaneously. The reason they cannot is current.

Work out how much. A DDR4 device with a 1 KB page and a x8 organisation raises one wordline and sense-amplifies 8192 cells at once, since a kilobyte is 8192 bits. That numeral is the same as the refresh-command count in Part 1.1 and has nothing to do with it, which is worth noticing once so the coincidence never trips you. Each of those sense amplifiers takes a bitline that has settled at $V_{DD}/2 \pm 54$ mV and drives it hard to a full rail, and each bitline is a few hundred femtofarads. Every one of those transitions happens in the same few nanoseconds, because the whole point of a sense-amplifier strip is that it fires as one. Reach for the machinery of Power Fundamentals and Clock Gating, but reach for the right quantity out of it. What the device's power delivery cannot supply is current, so the number to compute is the charge $Q = CV$ and not the energy $CV^2$. With 8192 bitlines at 250 fF and 1.2 V, one activation moves on the order of

$Q = 8192 \times 250 \times 10^{-15} \times 1.2 \approx 2.5\ \text{nC}$

If that charge moves in roughly 10 ns the average current is around 250 mA, and the instantaneous peak is higher. That is a large transient for a small package with limited decoupling, drawn through the same package inductance that produces the droop of DVFS Droop and Thermal. Treat that arithmetic as an order-of-magnitude illustration rather than a datasheet figure, since real devices segment the array and stage the sensing precisely to spread the transient, but the shape of the argument is right and it is the argument JEDEC is encoding.

So JEDEC caps the rate. $t_{RRD}$ enforces a minimum gap between any two activations. And then $t_{FAW}$, the four activate window, enforces something stronger and stranger: no more than four ACTIVATE commands may be issued in any rolling window of $t_{FAW}$ nanoseconds, across the entire device, regardless of which banks they target.

The exact values depend on page size and speed bin, which is itself the giveaway. At DDR4-3200 JEDEC tabulates $t_{RRD\_S} = 3.3$ ns and gives $t_{FAW}$ in three page-size columns: 13 ns for a half-kilobyte page, 21 ns for one kilobyte, and 30 ns for two. $t_{FAW}$ is indexed by page size. A purely logical constraint would not care how wide the row is. A charge-per-activation constraint has to, because a 2 KB page sense-amplifies twice as many cells and therefore moves twice the charge. Note that the numbers move with page size without doubling with it, 21 to 30 rather than 21 to 42, which is what you would expect from a window that must also stay wide enough to hold four activations at all. Do not oversell the scaling as linear. That indexing is the evidence that the parameter is about power delivery, and saying so is a much better answer than reciting the definition.

Now price it, because this is the number that lands.

Four activations per 21 ns is one activation every 5.25 ns. Under fully random access every activation yields exactly one 64-byte column read, so the achievable rate is

$\frac{64\ \text{B}}{5.25\ \text{ns}} = 12.2\ \text{GB/s}$

against a DDR4-3200 channel peak of 25.6 GB/s. $t_{FAW}$ alone caps random-access bandwidth at about 48 percent of peak, before considering refresh, bus turnaround, or any scheduling inefficiency whatsoever. And notice that it agrees with the independent derivation in Part 2.1: saturating the bus needs one column access every $t_{CCD\_S} = 2.5$ ns, and $2.5/5.25 = 48$ percent. Two different arguments, one from bank cycle time and one from activation rate, converge on the same answer, which is a good sign the model is right.

The design conclusion is the one that matters. Adding banks past a certain point buys nothing under random access, because $t_{FAW}$ binds before the bank count does. What buys something is improving locality so that each activation yields more than one column access, which is the entire justification for address mapping in Part 5.2 and open-page policy in Part 6.3.

4.9 $t_{RFC}$ and $t_{REFI}$, refresh in the parameter set

$t_{REFI}$ was derived in Part 1.1 from the retention window divided by the row count: 7.8125 µs for DDR4 at normal temperature, halving above 85 °C, and 3.906 µs as the DDR5 baseline.

$t_{RFC}$ is the refresh cycle time, the interval during which the device is busy servicing a REFRESH and will accept no other command. It is large and it grows with density, because a single all-bank REFRESH internally activates and restores a row in every bank and a denser part has more to do. Widely published values are 350 ns for an 8 Gb DDR4 device and 550 ns for 16 Gb, and 295 ns for a 16 Gb DDR5 device under the standard all-bank scheme. Refresh gets its own part, Part 7, because the controller's freedom to schedule it is where the engineering lives.

4.10 The full set, and the honest advice about memorising it

Two pieces of honesty about this table are worth stating out loud in an interview rather than hiding.

Do not memorise the numbers. They change with every speed bin, every density, every page size, and every generation, and the authoritative tables live in JESD79-4 for DDR4 and JESD79-5 for DDR5. What you should be able to do without a datasheet is name what each parameter physically encodes, say which mechanism it comes from, and predict which direction it moves when the part gets denser, hotter, or faster. That is the knowledge that transfers, and it is what a designer actually needs, because the RTL reads its values from configuration registers anyway.

Know which ones are shrinking and which are not. The parameters governed by digital pipelines, CL and CWL and the $n$CK terms, scale with the clock. The parameters governed by analogue physics inside the array, $t_{RCD}$ and $t_{RP}$ and $t_{RAS}$ and $t_{RFC}$, have been approximately flat in nanoseconds for a decade and $t_{RFC}$ is getting worse with density. That divergence is why controller quality matters more every generation, not less. When the data rate doubles and $t_{RC}$ does not move, the cost of a row conflict measured in lost transfers doubles.

---

05.Part 5, inside the controller

5.1 The two queues, and why there are two

A memory controller is not one pipeline. It is two queues with a translation between them, and understanding why they are separate is most of understanding the block.

The transaction queue, sometimes called the request queue or the pending-transaction buffer, holds requests as the rest of the chip described them: an address, a size, a read or write flag, a client identifier, a quality-of-service class, and an identifier the response must carry back. Its entries are protocol objects that arrived over AXI or CHI from Interconnect and AMBA. It knows nothing about rows or banks.

The command queue holds DRAM commands: ACT to bank 5 row 219, RD to bank 5 column 12, PRE to bank 5. Its entries are things that can be placed on the command bus in a single slot. One transaction becomes between one and three commands depending on the state of its bank, and sometimes more if the access has to be split.

Between them sits the address mapper, a purely combinational function turning a physical address into a channel, rank, bank group, bank, row, and column. It is one of the very few parts of a memory controller that is not a state machine, and it is the subject of 5.2.

Around them sit three more things. A per-bank state tracker holding, for every bank, whether a row is open and which one, plus a set of countdown timers implementing the parameters of Part 4. A command arbiter choosing which of the currently-legal commands to issue this slot, which is Part 6. And a data path with the write data buffer, the read return buffer, ECC generation and checking, and the crossings to the PHY, which is Part 10.

The reason the two queues are separate is worth being able to state crisply. Reordering must happen at the transaction level, because that is where the memory model constraints live, and legality must be enforced at the command level, because that is where the JEDEC parameters live. Mixing them produces a design where you cannot reason about either. It also means the controller has to enforce the ordering rules of Load Store and Memory Ordering itself: two accesses to overlapping addresses may not be reordered relative to each other, so the transaction queue needs an address-overlap check on insertion, which in practice is a small content-addressable memory of exactly the kind in Arbiters FIFOs and CAMs.

5.2 Address mapping, and the factor of ten hiding in it

Return to the toy device of Part 2.4: four banks, eight rows, eight columns of 64 bytes, 16 KB total, 14 address bits.

The stream. Two clients are running at once, which is the normal case on any SoC. Client A streams sequentially from address 0. Client B streams sequentially from address 4096. Their requests arrive interleaved, A0, B0, A1, B1, and so on, because the fabric is round-robining between two masters. Each reads eight consecutive 64-byte lines, so there are sixteen requests in total and they cover 1 KB.

Mapping M1, the obvious one. Fields in the order row, bank, column, offset, so row is $A[13{:}11]$, bank is $A[10{:}9]$, column is $A[8{:}6]$, offset is $A[5{:}0]$.

Client A's eight addresses are 0, 64, 128, ..., 448. All of them have $A[13{:}9] = 0$, so all eight are bank 0, row 0, columns 0 through 7.

Client B's eight addresses are 4096, 4160, ..., 4544. All of them have $A[12] = 1$ and nothing else above bit 8, so $A[13{:}11] = \texttt{010} = 2$ and $A[10{:}9] = \texttt{00} = 0$. All eight are bank 0, row 2, columns 0 through 7.

Now interleave them. A0 opens bank 0 row 0 and reads. B0 wants bank 0 row 2, which is a row conflict: precharge, activate, read. A1 wants row 0 again, another conflict. Every single one of the sixteen requests after the first is a row conflict, and they are all in one bank so nothing overlaps with anything.

$T_{M1} \approx 16 \times t_{RC} = 16 \times 45.75 = 732\ \text{ns for 1 KB} \implies 1.4\ \text{GB/s}$

Fifteen of sixteen banks are idle throughout. This is the classic bank thrashing pathology and it is entirely a consequence of where the bits went.

Mapping M2, XOR the bank index with row bits. Keep every field where it was, but compute the bank index as

$\text{bank} = A[10{:}9] \oplus A[12{:}11]$

Recompute. Client A at address 0: $A[10{:}9] = \texttt{00}$, $A[12{:}11] = \texttt{00}$, so bank $= \texttt{00} = 0$, row 0. Client B at address 4096: $A[10{:}9] = \texttt{00}$, $A[12{:}11] = \texttt{10}$, so bank $= \texttt{10} = 2$, row 2.

The two streams now live in different banks. Client A occupies bank 0 with row 0 open and gets eight consecutive row hits after one activation. Client B occupies bank 2 with row 2 open and does the same. The two activations happen in different banks and overlap.

$T_{M2} \approx t_{RCD} + \text{CL} + 16 \times t_{CCD} \approx 27.5 + 16 \times 2.5 = 67.5\ \text{ns} \implies 15.2\ \text{GB/s}$

Row hit rate went from 0 to 14 out of 16, which is 87.5 percent, and the elapsed time fell by a factor of about eleven, for exactly the same request stream on exactly the same silicon. Nothing changed except which address bits were wired into the bank decoder. That is why the address map is the highest-leverage single decision in a memory controller and why it is a configurable register in every commercial one.

Four rules generalise out of that example and they are the answer to "how would you choose an address map."

Put the bits that change fastest into the fields whose reuse you want. Column bits should sit immediately above the line offset, so that a sequential stream walks columns of one open row and hits.

Put the bank and bank-group bits immediately above the column bits. Then a stream that runs past the end of one row lands in a different bank, so the next activation overlaps with the current row's remaining accesses instead of serialising behind them. Putting bank-group bits at the very bottom, below the column bits, is also a defensible choice on some designs because it maximises $t_{CCD\_S}$ opportunities, and choosing between those two is a real trade-off, not a solved problem.

Never put bank bits at the top. If bank is the most significant field, an entire contiguous region of the address space lives in one bank and every stream inside it serialises.

Break power-of-two aliasing with an XOR. Real address streams are full of power-of-two strides: frame buffers, matrix rows, page-aligned allocations, and per-thread stacks. Any of those can put two hot streams in the same bank with a plain field split. Folding some high-order bits into the bank index with an XOR scatters them, at the cost of a handful of gates and a small amount of debug pain, because a physical address no longer maps to a bank in a way you can compute in your head. The technique is public and long-standing in the literature on permutation-based interleaving, and it is standard practice.

The honest caveat to add unprompted: there is no universally best map, because it depends on the traffic. A GPU streaming a frame buffer, a CPU chasing pointers, and a display engine reading scanlines want different things. Which is why every commercial controller makes this a configuration register and why bringing up a new SoC includes a campaign of measuring candidate maps against real traces.

5.3 The per-bank timing tracker, which is where the RTL actually is

If you are asked to design a memory controller on a whiteboard, this is the structure to draw, because it is the part that is genuinely a logic design problem rather than a policy discussion.

For every bank in the system the controller holds:

• a valid bit, meaning a row is open
• the open row number
• a set of countdown timers, one per constraint that gates a future command on this bank

The timers are ordinary down-counters loaded with the configured parameter value when the relevant command issues, decrementing every memory clock, and saturating at zero. A command to this bank is legal when every timer that gates it reads zero. So the ACTIVATE-legal condition for bank $b$ is roughly