Why DRAM Dominates Main Memory

Chapter 1.6 ended on a fact that ought to be surprising. Laid out across the ten axes that actually matter, DRAM wins none of them outright. It is not the lowest-latency technology in the table — a register file and an SRAM array both beat it. It is not the cheapest per bit — flash is cheaper. It is not persistent. It offers the least concurrency of anything except flash. And it has the second most demanding interface in the table, demanding enough that this curriculum has thirty-three modules devoted to using it.

And yet it holds the main-memory tier in nearly every computing system built in the last several decades, from a phone to a server to an accelerator. So:

Why does a technology that wins no single axis hold the most important storage tier in computing?

The answer is the most useful piece of engineering reasoning in Module 1, and it generalises far beyond memory. Main memory does not need a winner. It needs a conjunction. A tier defined by a set of simultaneous requirements is won by the only candidate that satisfies all of them — not by the candidate that is best at any one. DRAM is that candidate, and the requirement it satisfies most decisively is the one engineers usually leave out of the analysis entirely.

1. State the Requirements Before Naming a Candidate

The discipline that makes this chapter work is refusing to compare technologies until the job is specified. So here is the job, derived from what a processor actually does rather than from what memories happen to offer.

R1 — Reachable by ordinary loads and stores, at word granularity. A processor executes an instruction naming an address and expects the value at that address. Any address, in any order, with no preparation and no larger unit implied. This follows from the instruction set, not from a preference.

R2 — Rewritable without limit and without asymmetry. Any location may be written as often as the program requires, and a write must cost roughly what a read costs. A tier serving every cache miss and every store in the machine cannot have a write model that is conditional, coarse, or finite.

R3 — Capacity sufficient for the working set, at a price the system can pay. Not "large" in the abstract: large enough to hold everything currently in use, at a cost that fits the product. This is a joint requirement — capacity at a price — and either half alone is easy.

R4 — Latency the machine can be built to tolerate. Not low latency. Tolerable latency, given that a cache hierarchy exists precisely to reduce how often this tier is touched, and given that a processor can keep other work in flight while waiting. This is the requirement most often stated too strongly.

R5 — Bandwidth to sustain the miss traffic of everything above it. A tier serving several cores, their caches, and any accelerators and I/O engines in the system must move enough data per unit time to keep them supplied.

R6 — An interface an industry can independently build both sides of. Memory and the systems that use it are made by different companies. Unless both sides can be designed against a common specification and be relied on to interoperate, there is no supply of memory at all — only one vendor's bundle.

R6 is the requirement that decides the chapter, and almost nobody lists it. Hold it.

2. Eliminate the Alternatives Against the Requirements

Now the candidates, each against the list. The mechanisms are all established in earlier chapters, so this is deduction rather than assertion.

Flip-flop storage fails R3, decisively. Chapter 1.2 §11 established why: per-bit generality and per-entry access paths put the entire access cost in the replicated term, and area, wiring, clock power and access organisation all degrade together as the entry count grows. It satisfies R1, R2, R4 and R5 magnificently and cannot be built at the required capacity for any affordable price. One failure is enough.

SRAM fails R3 too, less brutally but just as conclusively. Chapter 1.3 shrank the cell and shared the periphery, which is real progress — it is exactly why caches exist. But the cell is still several actively driven transistors, replicated at every bit, and every cell consumes power merely by existing. At the capacity a working set requires, the cost per bit and the static power are both unaffordable. SRAM satisfies R1, R2, R4, R5 and R6 and loses on the capacity-at-a-price half of R3.

Flash fails R1 and R2, and this is the interesting elimination. Chapter 1.5 showed why, and note that it is not about speed. Its natural access unit is far larger than a word and its erase unit is larger still, so R1 fails. A location can only be programmed from the erased state, making a write conditional, coarse and expensive, and endurance is finite — so R2 fails twice over. It wins R3 outright. Winning the axis everyone talks about while failing two requirements is exactly how a conjunction disqualifies a candidate, and it is why "flash is cheaper per bit" has never been an argument for flash as main memory.

DRAM fails nothing. It is word-addressable in the ordinary sense (R1 — subject to the access sequence of Chapter 1.4 §4, which constrains order and timing but not reachability). It is rewritable without limit, with a write costing about what a read costs (R2). Its cell is the smallest practical random-access storage element, which delivers capacity at a price (R3). Its latency is high relative to SRAM but within what a cache hierarchy and a concurrency-capable requester can absorb (R4). Its interface moves enough data per unit time to supply the tiers above (R5). And it is specified by an industry body so that memory and controllers from different vendors interoperate (R6).

3. R3 in Detail — Capacity at a Price Is One Requirement

The half of R3 that engineers drop is the price, so it is worth being explicit about why DRAM satisfies the joint requirement rather than just the capacity one. Chapter 1.6 §2 gave the chain; this is DRAM walking down it.

The cell is the minimum. One transistor and one capacitor. Because cell area is the term paid at every bit, having the smallest practical cell is the largest single advantage available on this axis, and DRAM has it.

The die is built to do one thing. A dedicated memory die can be organised for array efficiency in a way an array embedded in a logic die cannot — its floorplan, its process options and its periphery all exist to serve the array.

Defects are repairable. A large, regular array can be manufactured with spare rows and columns, so a die with a defect in the array can often be repaired rather than scrapped. Regularity turned into yield is a real cost advantage and it is specific to memory.

And the volume is enormous. This is the term that compounds all the others. Process development, design, masks, test programs and qualification are fixed costs amortised over units shipped, and commodity DRAM ships at a scale nothing in the alternatives approaches. A part built to a common specification, bought by everyone, made by several competing manufacturers, achieves a cost per bit that the same silicon in a low-volume specialised form would not.

That last point is not incidental to the physics — it is a consequence of R6. The standardisation that makes an industry possible is also what creates the volume that makes the bits cheap. The physics and the economics are linked through the interface, which is why the next section is the one that actually answers the chapter's question.

4. R6 — The Requirement Nobody Lists, and Why It Decides

Ask the question differently: suppose a technology existed that beat DRAM on latency, cost per bit and power, satisfied R1 and R2, and was available only from one vendor with a proprietary interface. Would it take the main-memory tier?

Almost certainly not, and the reasons are engineering reasons rather than commercial squeamishness.

Both sides of the interface are designed by different organisations. The memory is made by a memory manufacturer. The controller is inside an SoC or CPU designed by someone else entirely, often years before the specific memory part is chosen — and frequently before it exists. Unless both sides can be built against a published specification and be relied upon to interoperate, the SoC cannot be designed at all.

A system must be able to source parts from several suppliers. A product whose memory has one possible source is a product with one point of failure in its supply chain, and no pricing pressure. This is a hard architectural constraint at product level, not a preference.

The ecosystem is part of the technology. Using DRAM requires controller IP, PHY IP, verification IP, simulation models, compliance suites, test equipment, signal-integrity models, board-design guidance and engineers who have done it before. All of that exists because the interface is standardised and stable across generations. A proprietary alternative starts with none of it, and every one of those absences is schedule and risk.

Generational continuity protects investment. A standardised interface that evolves in defined steps — with the ordering model, the addressing model and the vocabulary carried forward — lets accumulated design, verification and software investment survive a generation change. That continuity is worth a great deal, and it is why an incremental generation of a standardised technology routinely beats a superior non-standard one.

So the honest answer to the chapter's question has two halves. DRAM's cell won it the physics: the smallest practical random-access element, giving capacity at a price. Standardisation won it the tier, by creating the volume that makes the bits cheap, the interoperability that lets independent vendors build both sides, and the ecosystem that makes the interface's genuine difficulty survivable.

5. What the Tier Costs the Rest of the System

DRAM satisfying R1 to R6 does not make it free. It makes its costs payable, and the whole DDR curriculum is the payment schedule. Naming the costs here is what makes the later modules feel inevitable rather than arbitrary.

The access is a sequence, so something must sequence it. Chapter 1.4 established that a row must be resolved before columns can be accessed, and the array returned to a ready state before a different row can be resolved, with minimum times between the parts. A requester issuing loads cannot express that, so a memory controller must exist to translate requests into legal command sequences — and because the cost of an access depends on which row is already resolved, that controller is a scheduler rather than a translator. Modules 7 through 18.

Contents decay, so something must maintain them. Refresh is mandatory, consumes device capability, and must be interleaved with real traffic without violating either the device's rules or the system's latency requirements. Module 15.

The storage is off-chip, so something must drive the channel. Capacity that cannot fit on the compute die means every access crosses a package boundary and a board at high signalling rates, which requires a PHY — and, because channel characteristics vary with the board, the package, temperature and voltage, a PHY that calibrates itself rather than assuming fixed timing. Modules 19 through 22.

Performance depends on request order, so mapping and scheduling become architecture. Because identical-looking requests cost different amounts depending on device state, how system addresses map onto rows, columns, banks and channels is a first-order performance decision. Module 18.

And all of it must be verified against a specification written by someone else. Interoperability is the point of R6, which means compliance is a real obligation rather than an internal quality bar. Module 27.

Five costs, and every one of them is traceable to a property established in Module 1. That is the sense in which this chapter closes the module's argument: the curriculum's shape is a consequence of the tier decision, not a list of topics someone chose.

6. Where the Boundaries Are Actually Moving

A chapter that claims a technology dominates a tier should say what would change that, and say it accurately rather than dismissively.

The tier boundaries have genuinely moved before, and they move again. The memory hierarchy is not fixed. Levels have been added, capacities have shifted between them, and storage-class technologies with properties between DRAM and flash have been productised. A curriculum that presented the current arrangement as permanent would be teaching a snapshot as a principle.

But what moves is where boundaries sit, not why they exist. The couplings in Chapter 1.6 §5 are physical: density raises the capacitance of shared lines, simplifying a cell moves maintenance outward, isolating charge to make it persist makes it hard to change, and capacity large enough for a working set cannot sit on the compute die. A new technology lands somewhere in that space and creates or shifts a tier. It does not abolish the space.

Two directions worth knowing about, stated at the level this chapter can support. Memory closer to compute: capacity placed nearer the processor with a wider or shorter connection than a conventional channel, trading cost and capacity for bandwidth — Module 26 treats one such approach. Memory further from compute: capacity attached over a general-purpose link rather than a dedicated channel, trading latency for flexibility, capacity and sharing — the subject of the repository's CXL curriculum, and of Module 32's case studies.

The test for any candidate remains §1's list. Not "is it faster" or "is it cheaper" but: does it offer word-granular access, unlimited symmetric rewriting, capacity at a price, tolerable latency, sufficient bandwidth, and an interface an industry can build both sides of — all at once? A technology that satisfies five of six takes a new tier rather than this one, which is precisely what has happened historically. That is a far more useful thing to know than any prediction.

7. Why This Matters in Each Engineering Role

The same tier decision looks different from each seat, and knowing which parts of it are yours is genuinely useful.

RTL design. You are downstream of a resource that is shared, scheduled, and can make you wait. That means request queues, credit or ready-based backpressure, buffering sized against worst-case latency rather than typical, and pipelines that tolerate a variable-latency response. A block designed as though memory answers promptly will work in simulation against a simple model and stall badly against a real one.

Design verification. The behaviour that must be verified is temporal and stateful: ordering rules, cost that depends on device state, periodic maintenance activity, and latency that varies with contention. Stimulus that never creates contention, never forces a row change, and never coincides with maintenance has verified the easy path — the point Chapter 1.4 §10 made and worth repeating, because it is the most common weakness in memory-subsystem verification.

Memory-controller design. Your block exists because of §5's first cost. Its quality is measured in how well request ordering, address mapping and maintenance scheduling exploit whatever locality the traffic has — which is to say, how rarely the device is made to pay for the sequence.

PHY design. Your block exists because of §5's third cost. The interface bandwidth that R5 depends on is only available if the channel can be driven and sampled reliably at rate, across variation in board, package, temperature and voltage — which is why calibration is intrinsic rather than optional.

SoC architecture. You own the trade-off directly: how much on-chip SRAM to spend on caches, how many channels, how bandwidth is allocated across competing requesters, and how much latency the compute can be built to tolerate. The whole of Module 1 is the input to those decisions.

8. Common Mistakes

Comparing candidates by their best axis. Wrong mental model: the best technology wins the tier. What the engineer does: argues for a technology from its strongest property — cheapest per bit, lowest latency, non-volatile — without checking the other requirements. Resulting bug: an architecture proposal that cannot work, defended with a true fact. Flash is cheaper per bit; that has never made it a main-memory candidate. How to detect it: ask which of R1 to R6 the proposal has actually checked. A proposal that names one axis has checked one. How to prevent it: evaluate against the conjunction, and state explicitly which requirement each rejected candidate fails.

Leaving the ecosystem out of the analysis. Wrong mental model: technology selection is a physics and cost question. What the engineer does: plans around a technology with no standard interface, no second source, no verification IP and no prior art, budgeting only its silicon. Resulting bug: schedule and risk overruns in exactly the hardest phase — interface bring-up — plus a supply-chain exposure that surfaces at the worst possible time. How to detect it: ask what exists today for that interface: a published specification, multiple suppliers, controller and verification IP, simulation models, compliance suites, engineers with experience. Each absence is cost. How to prevent it: treat R6 as a requirement with the same standing as latency and capacity, because it behaves like one.

Reading "DRAM is slow" as an explanation. Wrong mental model: the memory tier is a weakness to be tolerated. What the engineer does: attributes disappointing performance to the memory technology, and stops. Resulting bug: the actual cause — poor locality, insufficient concurrency, an unfortunate address mapping, a queue bottleneck, saturation — goes uninvestigated, and the same result is obtained on the next system with faster memory. How to detect it: if the same device performs well on another workload, the device is not the explanation. Chapter 1.8 makes this the central method. How to prevent it: insist on a mechanism. "Slow" is not a mechanism; "this access pattern forces a row change on nearly every request" is.

Treating the standard as an implementation detail. Wrong mental model: the specification is a formality; what matters is that the hardware works together. What the engineer does: builds a controller against one device's observed behaviour, or verifies against a single vendor's model, and treats the specification as documentation. Resulting bug: a design that interoperates with the part it was developed against and fails with another — found at qualification with a second supplier, which is late and expensive. The whole value of R6 is lost exactly when it was needed. How to prevent it: verify against the specification and against multiple vendor models, and treat compliance as a deliverable. Module 27's subject.

9. Analysis Scenario — Justifying a Memory Choice Under Review

The situation. A design review challenges a proposal to build a large on-chip buffer in SRAM rather than attaching more DRAM capacity. Both sides have a plausible case. This is the reasoning that resolves it, and it is the applied form of everything in this chapter.

Step 1 — establish which requirement is actually binding. Is the problem capacity, latency, bandwidth, or concurrency? A capacity requirement argues toward DRAM; a latency or concurrency requirement argues toward on-chip SRAM. Arguments that do not first name the binding requirement cannot be settled, because each side is optimising a different axis.

Step 2 — quantify the working set against the proposed SRAM size. If the data in active use fits, the SRAM eliminates most main-memory traffic and its cost may be easily justified. If it does not fit by a wide margin, the SRAM becomes a partially effective cache and the DRAM traffic remains — so it must be justified by hit rate, not by capacity. The measurement is the argument.

Step 3 — price the SRAM honestly. Cell area multiplied by bit count is the floor, not the answer (Chapter 1.6 §2): add array efficiency, the effect of splitting it into instances, the port requirement, and the static power of a large always-powered array. An estimate missing those terms will understate it substantially.

Step 4 — price the DRAM option honestly too. Additional capacity is not just device cost: it may mean channels, pins, board area, power delivery, signal-integrity work and controller resources. And more capacity does not reduce latency — if the binding requirement was latency, DRAM capacity does not address it at all.

Step 5 — check the concurrency requirement, which usually decides. How many simultaneous accesses does the consumer actually need? A requirement for several accesses per cycle rules out a single-ported structure of either kind and forces banking or replication — which changes both options' costs materially. This is the axis most often discovered late.

Step 6 — identify the measurement that would settle it. Usually a hit-rate or reuse measurement on representative traffic: what fraction of accesses would the proposed SRAM absorb? If the answer is high, it wins on latency and on the DRAM traffic it removes. If low, it is expensive silicon holding data that is touched once.

What this scenario teaches. The technique is not memory-specific. Name the binding requirement, price both options completely, check the axis nobody stated, and identify the one measurement that decides. That is how a tier decision is made defensibly — and it is the method Module 1 exists to install.

10. Interview Reasoning

"Why is main memory DRAM rather than SRAM?" Because main memory's requirement is capacity at a price, and SRAM fails the price half at that capacity: a cell of several actively driven transistors, replicated at every bit, plus static power proportional to how much storage exists. SRAM satisfies every other requirement, which is exactly why it is the cache tier. The complete answer names the conjunction rather than the ranking: SRAM is not disqualified for being worse, but for failing one requirement that cannot be traded away.

"Flash is cheaper per bit than DRAM. Why is main memory not flash?" Because cost is one requirement among several and flash fails two others outright. Its access granularity is far larger than a word and its erase granularity larger still, so it cannot serve word-granular loads and stores. And a write is conditional on a prior erase, coarse, expensive and limited by finite endurance, so unlimited symmetric rewriting is unavailable. Winning the cost axis while failing addressability and rewritability is precisely how a conjunction disqualifies a candidate.

"Is DRAM the best memory technology?" No, on any single axis — and that is the interesting answer. It is not the fastest, cheapest, most persistent or most concurrent. It holds the tier because main memory demands a conjunction of word-granular access, unlimited symmetric rewriting, capacity at a price, tolerable latency, sufficient bandwidth and an interoperable interface, and DRAM is the only technology that satisfies all of them at once. A candidate who reframes "best" as "qualifies" has understood the chapter.

"How much does standardisation matter, really?" Enough to be a requirement rather than a benefit. Memory and controllers are designed by different companies, often years apart, so a published specification is what makes an SoC designable at all. Standardisation also creates the manufacturing volume that amortises fixed costs and therefore makes the bits cheap, and the ecosystem — controller and verification IP, models, compliance suites, experienced engineers — that makes a genuinely difficult interface survivable. A superior technology with a proprietary single-source interface would face all of that as risk.

"What would it take for something to replace DRAM in main memory?" Satisfying R1 through R6 simultaneously: word-granular access, unlimited symmetric rewriting, capacity at a competitive price, tolerable latency, sufficient bandwidth, and a standardised interface with multiple suppliers and a real ecosystem. Beating DRAM on one or two axes is not sufficient and historically has not been — technologies that satisfy most of the list have taken new tiers rather than this one, which is itself the most instructive observation available.

"Why does a DRAM-based memory system need a controller when an SRAM array does not?" Because a DRAM access is a sequence with mandatory ordering and minimum intervals, its cost depends on which row is already resolved, and its contents require periodic maintenance. A requester issuing loads cannot express any of that, so something must translate requests into legal command sequences and choose their order — which makes the controller a scheduler rather than a bridge, and makes its policy a first-order performance component.

11. Engineering Check

A proposal argues that a new memory technology should replace DRAM in a product's main-memory tier. It has: lower access latency than DRAM, lower cost per bit, non-volatility, word-granular reads, and a write that is roughly ten times more expensive than a read and has a finite endurance rating. One supplier makes it, with a proprietary interface.

1. Which requirements does it satisfy? R1 for reads. R4 comfortably — it beats DRAM. R3 on the price half, and presumably on capacity. R5 is unstated and would need checking. Persistence is a bonus that no main-memory requirement asked for, which is worth noticing: a strength that satisfies no requirement earns nothing under a conjunction.

2. Which does it fail, and are the failures fatal? R2 fails on both counts — the write is asymmetric by a large factor and endurance is finite, so a tier absorbing every store in the machine would both run slowly on write-heavy work and consume a lifetime-limited resource. R6 fails completely: one supplier, proprietary interface. R1 is partially satisfied, since word-granular reads are not word-granular writes.

3. Is the latency advantage decisive? No, and this is the reasoning to practise. R4 asks for tolerable latency, and DRAM already satisfies it — a cache hierarchy exists to reduce how often the tier is touched and a requester can keep work in flight while waiting. Beating a requirement that is already met adds value only if nothing else is lost, and here a great deal is.

4. Where might the technology genuinely belong? Somewhere its strengths satisfy requirements that are actually binding and its weaknesses are acceptable. Persistence plus word-granular reads plus a costly write is a poor fit for a tier serving every store and a plausible one for a tier holding data that is read far more often than written, or one where persistence removes work elsewhere. Failing to win this tier is not failing — it is an argument for a different tier, which is how the hierarchy has grown historically.

5. What would change the answer for the main-memory tier? Symmetric, unlimited writes and a standardised multi-vendor interface — which is to say, fixing R2 and R6. Both are hard, and the second is not a technical problem at all, which is exactly why it is the requirement engineers underestimate.

6. What single measurement would most inform the decision? The workload's write fraction and write volume. If stores are a small fraction of traffic and lifetime write volume is well inside the endurance rating, the R2 failures are less severe than they look and the case deserves analysis. If the tier absorbs heavy store traffic, the proposal is disqualified by arithmetic rather than by opinion — and one measurement has settled a debate that could otherwise run for months.

12. Summary

DRAM wins no axis outright — not latency, not cost per bit, not persistence, not concurrency — and it holds the main-memory tier anyway. That is not a paradox; it is what happens when a role is defined by a conjunction of requirements rather than by a ranking.

Main memory must be reachable by ordinary loads and stores at word granularity, rewritable without limit and without asymmetry, provide capacity at a price the system can pay, offer latency the machine can be built to tolerate and bandwidth to sustain the traffic above it, and present an interface an industry can independently build both sides of.

Against that list the alternatives are eliminated by mechanism rather than by ranking. Flip-flop storage and SRAM fail capacity-at-a-price, because their cells are replicated per bit and their access cost sits in the replicated term. Flash fails word-granular addressing and unlimited symmetric rewriting — while winning the cost axis, which is the clearest demonstration of how a conjunction works. DRAM fails nothing.

Two halves of the answer, and the second is the one usually missing. The cell won the physics: the smallest practical random-access storage element, which is what delivers capacity at a price. Standardisation won the tier: a specification published by JEDEC that lets independent vendors build memory and controllers that interoperate, which creates the manufacturing volume that makes the bits cheap and the ecosystem — IP, models, compliance suites, experience — that makes a genuinely difficult interface survivable.

And the tier's costs are the curriculum. A sequenced access needs a scheduler; decaying contents need a maintenance manager; off-chip capacity needs a self-calibrating PHY; state-dependent cost makes address mapping and request ordering architectural; and an interoperable interface makes compliance an obligation. Every module after this one is a consequence of the tier decision Module 1 has now justified.

13. What Comes Next

Module 1 has one question left, and it is the one that makes the rest of the curriculum urgent rather than merely necessary.

DRAM is the right answer for main memory — and it is a long way from compute, its access is a sequence, and its cost depends on state. Meanwhile the compute it serves has grown enormously capable. Chapter 1.8 is about what happens when those two facts meet: why increasing compute capability eventually stops translating into proportional system performance, why "DRAM is slow" is the wrong way to say it, and why latency and bandwidth are separate problems with separate solutions.

It also closes the module, by drawing the whole chain from the register file to the memory wall into one argument — and by setting up why Module 2 has to begin inside the DRAM cell.

Return to Cost vs Density for the trade surface this chapter applied, DRAM for the mechanism, or The Memory Hierarchy for the map. For the tier that is becoming fabric-attached rather than channel-attached, see What Is CXL. The full path is on the DDR tutorials index.