A memory controller wants one cache line from DRAM. It cannot simply ask: it must open the right row in the right bank, wait a fixed number of cycles, issue a read, wait again, catch the data on a strobe, close the row before opening another in that bank, and every few microseconds stop everything to refresh. The DRAM never says "ready" or "done". It simply does what it is told, on schedule, and the controller must know every rule.
How does DDR answer each question when one side does all the thinking?
Constraint | DDR |
|---|---|
C1 Distance and medium | A board or module: short, but at very high data rates |
C2 Bandwidth and latency | Very high bandwidth; tens of nanoseconds of latency set by the DRAM array |
C3 Wires | Wide parallel data bus, a command/address bus, and strobes |
C4 Topology | One controller, one or a few ranks of DRAM devices |
C5 Who builds each side | DRAM vendors build to JEDEC standards; controllers must work with any compliant DRAM |
Each answer links to the lesson that explains the idea behind it.
# | Question | Answer |
|---|---|---|
1 | When is the data valid? | Source-synchronous strobes: DQS is edge-aligned with data on reads and centre-aligned on writes (fact S6) (1.3) |
2 | Where does a message start and end? | Commands on the command bus at clock edges; data in fixed-length bursts, BL8 in DDR4 and BL16 in DDR5 (fact S23) (5.8) |
3 | Is the receiver ready? | No ready signal: the DRAM answers after fixed latencies, so the controller schedules everything (a valid-only response) (3.1) |
4 | How much may I send before I hear back? | None from the DRAM: the controller owns all timing (4.1) |
5 | What exactly is being asked? | ACTIVATE, READ, WRITE, PRECHARGE and REFRESH commands addressing banks, rows and columns (fact S23) (5.3) |
6 | How many requests can be in flight? | Many banks and bank groups let the controller overlap accesses (16 banks in DDR4, 32 in DDR5) (fact S23) (6.3) |
7 | In what order do results become visible? | The controller reorders requests to reuse open rows, but must keep same-address order (7.8) |
8 | Who gets the wire? | The controller is the only master; it schedules the shared, bidirectional data bus and pays turnaround cycles to switch between reads and writes (facts S6, S23) (8.2) |
9 | Why can it hang? | No protocol deadlock, but scheduling can starve requests (always favouring open-row hits), and refresh must never be postponed too long (fact S23) (9.1) |
10 | What if bits go wrong? | ECC DIMMs widen the bus to 72 bits for SECDED (fact S23) (10.5) |
11 | How do the two sides agree at start-up? | Initialisation and training (write levelling, read training) align strobes and data to the board (fact S23) (11.4) |
12 | How do we save power without losing data? | Power-down and self-refresh modes when idle (fact S23) (12.2) |
13 | What if there are several copies of one value? | Not applicable: coherence is handled above the memory controller |
14 | Who is allowed to ask? | Not addressed by the protocol |
15 | How do we know it is correct? | Compliance with JEDEC timing; controller verification with DRAM models and training validation on boards (15.8) |
All intelligence in the controller: the DRAM is kept simple and dense; the controller tracks every bank's state and every timing rule.
No handshake: fixed latencies replace ready signals, so the bus can run at full speed with no feedback.
Bank-level concurrency: overlapping accesses to different banks hides the array's latency.
Training: high data rates on real boards require the controller to calibrate timing at start-up.
A memory controller (illustrative) always served open-row hits first to maximise bandwidth. Under a streaming workload, one core's requests to a different row in a busy bank waited for tens of microseconds while another core kept hitting the open row. Capping how many hits may bypass an older request fixed the starvation at a small bandwidth cost: DRAM scheduling is an arbitration problem, with the usual fairness trade-off.
The data bus is bidirectional; the drivers must turn around, so there are idle cycles between directions.
Cells lose charge and data is corrupted; refresh has a hard average interval.
DDR: the controller issues every command; the DRAM answers after fixed latencies, with no handshake.
Strobes for timing, banks for concurrency, refresh and training as mandatory duties.
Performance and fairness are controller scheduling problems.