Cost vs Density

Four tiers now have their mechanisms. A register file gives every entry its own access path. SRAM shrinks the cell and shares the periphery. DRAM strips the cell to one transistor and one capacitor and accepts refresh, destructive reads and a sequenced access. Flash stores charge on an isolated node and accepts an asymmetric write, block granularity and finite endurance.

Each of those chapters said the technology "makes a trade". None of them said what the trade is. This chapter does, and the question it answers is more precise than it first looks:

What exactly is being exchanged when a design moves between tiers, and why can no single technology win on every axis at once?

That question has a bad answer and a good one. The bad answer is a ranking — this one is fast, that one is cheap — which is how memory technologies are usually compared and which explains nothing. The good answer identifies the axes, shows what each one is physically made of, and then shows which axes are coupled, because a coupling between two axes is exactly what makes a trade unavoidable rather than merely inconvenient.

1. There Is No Single Axis

The instinct is to arrange memory technologies on one line from fast to cheap. That instinct is the error, and naming the axes separately is the first real work of the chapter — because most bad memory-system decisions come from optimising one axis while another quietly decides the outcome.

Cost per bit. What it costs to provide one bit of storage in a shipped product. This is the axis that decides how much capacity a system can have, and §2 takes it apart.

Cell area. The silicon area one bit occupies. Related to cost but not identical to it, because area is a physical quantity and cost includes process, yield, packaging and volume.

Access latency. How long one access takes, from the requester's point of view. Note that after Chapter 1.3 this already has two components — what the storage costs and what waiting for the storage costs.

Access granularity. The smallest unit that can usefully be read, and separately the smallest that can be written. Chapter 1.5 showed these need not be the same number, or even close.

Concurrency. How many independent accesses the structure can serve at once. This is the ports axis of Chapter 1.2, and it is completely independent of capacity.

Maintenance obligation. Whether the storage requires ongoing activity to keep its contents: continuous drive for SRAM, periodic refresh for DRAM, nothing for flash.

Endurance. Whether writing consumes a finite resource.

Volatility. Whether contents survive loss of power.

Power, in two separate kinds. Energy per access, and power consumed merely by existing. These behave very differently across technologies and they optimise differently.

Interface complexity. What a requester must implement in order to use the storage at all — from "present an index" for a register file to "run a protocol with ordering rules, timing constraints, initialisation and periodic maintenance" for a DDR device.

Ten axes. A technology is a point in that space, not a position on a line, and the reason the hierarchy exists is that the points that are good on some axes are necessarily bad on others. §5 is why "necessarily".

2. What Cost Per Bit Is Actually Made Of

This is the axis everything else in the curriculum depends on, and it is worth decomposing properly, because "DRAM is cheaper per bit" is a conclusion, not an explanation.

Work along the chain.

The cell area is the replicated term, which is why it dominates. A structure of a billion bits pays its cell cost a billion times. Every other cost in the chain is paid once per array, once per die or once per part. This is the single most important fact about memory economics and it is purely structural: whatever is replicated per bit is what decides cost per bit. It is why the industry has spent decades shrinking cells, and why a cell with two fewer devices is not a small improvement.

Array efficiency decides how much of the die is actually storage. A die does not consist of cells. It also contains the row decoders, sense amplifiers, write drivers, timing and control logic, redundancy, test structures and the interface — everything Chapter 1.3 §3 called the periphery. The fraction of die area that is cells is what array efficiency names, and it is a real design target, not a rounding error: periphery that is a modest overhead on a large array can dominate a small one. This is the arithmetic behind §4's conclusion.

Yield converts area into cost non-linearly. Manufacturing defects occur at some rate per unit area, so a larger die is less likely to be defect-free. Cost is per good die, so the relationship between area and cost is worse than proportional. Memory is unusual and interesting here: because an array is highly regular and uniform, a defective portion can often be replaced by spare rows or columns — redundancy and repair, which recover parts that would otherwise be scrap. That capability is one genuine reason dedicated memory dies achieve costs that an equivalent array embedded in a logic die does not.

Test and packaging are per-part costs that do not shrink with the cell. A part must be tested, and memory test takes time proportional to how much storage there is. It must be packaged, and packaging cost is driven by pin count, package type and assembly rather than by transistor count. These terms put a floor under cost per bit that cell shrinking alone cannot go below.

And volume amortises everything that was paid once. Process development, design, mask sets, test program development and qualification are fixed costs spread over units shipped. A technology manufactured in enormous volume to a standard specification — which is precisely what commodity DRAM is — spreads those costs across a vastly larger denominator than a specialised part does. This is an economic mechanism, not a physical one, and it is one of the real reasons the main-memory tier looks the way it does. Chapter 1.7 develops it.

3. Why Sharing the Periphery Is the Central Move

Chapter 1.3 introduced shared decode and sensing as a mechanism. §2 turns it into arithmetic, and the arithmetic explains the entire shape of the hierarchy.

Per-entry access — the register file. Each entry has its own selection and data path. The access resources are replicated per entry, so they land in the replicated term of §2's chain, and per-bit cost is high. In exchange the structure delivers concurrency: several independent accesses per cycle.

Shared access — every array. One decoder and one set of sense amplifiers serve many cells. The access resources are paid once per array rather than once per entry, so they leave the replicated term and enter the amortised one. In exchange the structure gives up concurrency: one row at a time, one access per port per cycle.

So the fundamental exchange has a name. Moving a cost from the per-bit term to the per-array term reduces cost per bit, and the price is exclusivity — because a resource can only be shared by making its users take turns. That is not an implementation detail of SRAM or DRAM. It is the mechanism by which all density is bought, and it is why every dense memory in existence must be scheduled and must be able to make a requester wait.

The rest of this curriculum is one long elaboration of that sentence. A memory controller exists because the access path is shared. Timing parameters exist because sharing a physical structure means waiting for it to be ready. Banks exist because partially unsharing the array recovers some concurrency. Every one of those is the consequence of a cost being moved out of the per-bit term.

4. Amortisation Sets a Minimum Sensible Array Size

A practical corollary that decides real design choices, and the one place in this chapter where a concrete engineering rule falls out.

If the periphery is a fixed cost per array, then the smaller the array, the larger the periphery's share of it. Below some size, the overhead of decoders, sense amplifiers, control and test structures outweighs what the small cell saves — and a structure built from ordinary flip-flops, which needs none of that periphery, is genuinely the better choice.

That is why real designs contain both: registers and small flop-based arrays for the handful of values that need per-entry access or are too small to justify an array's overhead, and compiled arrays or macros above some depth. The crossover depends on the technology, the array's aspect ratio, the port requirements, the target frequency and the flow, so no universal threshold exists — but the existence of a crossover is certain, and knowing that changes how a design is parameterised.

Here is how that decision is actually expressed in RTL, which is the one place code genuinely earns its place in this chapter.

What this is. A compile-time selection pattern: a parameterised storage block that is implemented as flip-flops below a threshold and as an array above it, presenting one interface either way. It is not a synthesis trick and not a claim about any tool's inference — it is how a design keeps a storage-technology decision in one reviewable place instead of scattered through the code.

// COMPILE-TIME SELECTION. The density decision of §4, expressed once.
//
// THE CRITICAL DESIGN RULE: both branches must present the SAME timing
// contract, or changing a parameter silently changes the interface and
// every consumer breaks. A flop array can read combinationally; a compiled
// array typically cannot. So the flop branch registers its read output to
// MATCH the array branch, deliberately giving up an ability it has, in
// exchange for an interface that does not depend on which branch was taken.
module storage_block #(
  parameter int WIDTH = 32,
  parameter int DEPTH = 64,
  // Where this design draws the line. A project-level decision informed by
  // the flow's macro overhead and the target's constraints -- NOT a
  // universal threshold, which does not exist (§4).
  parameter int MACRO_BIT_THRESHOLD = 4096,
  parameter int ADDR_W = (DEPTH <= 1) ? 1 : $clog2(DEPTH)
) (
  input  logic              clk,
  input  logic              en,
  input  logic              we,
  input  logic [ADDR_W-1:0] addr,
  input  logic [WIDTH-1:0]  wdata,
  output logic [WIDTH-1:0]  rdata      // registered in BOTH branches
);

  localparam bit USE_ARRAY = (DEPTH * WIDTH) > MACRO_BIT_THRESHOLD;

  if (USE_ARRAY) begin : g_array
    // Above the threshold: the shared-periphery structure of §3. In a real
    // ASIC flow this is where the compiled macro is instantiated, against
    // its datasheet's interface and latency.
    sram_sp #(.WIDTH(WIDTH), .DEPTH(DEPTH)) u_store (
      .clk(clk), .en(en), .we(we), .addr(addr), .wdata(wdata),
      .rdata(rdata), .rdata_valid()   // unused here; see sram_sp in 1.3 §5
    );
  end else begin : g_flops
    // Below the threshold: per-entry storage, no periphery to amortise.
    logic [WIDTH-1:0] regs [DEPTH];

    always_ff @(posedge clk) begin
      if (en && we) regs[addr] <= wdata;
      // Registered read, ONLY to match the other branch's contract.
      if (en && !we) rdata     <= regs[addr];
    end
  end

endmodule

Why the matching-contract rule is the whole lesson. A parameter that changes implementation is good engineering. A parameter that changes interface behaviour is a trap: a design that works at one depth and fails at another, for reasons no one connects to a parameter they changed months earlier. Making the flop branch behave like the array branch — even though it could answer faster — is the correct trade, because an interface that is stable across configurations is worth more than a cycle recovered in one of them.

Limitations. One port, no byte enables, and the array branch depends on Chapter 1.3's model standing in for a real macro. In a production flow the macro's interface, latency and test hooks come from its compiler, and the g_array branch is a wrapper that adapts to it — which is exactly where a project's real threshold gets encoded.

Verification implication, and this is the part teams get wrong. A design with a compile-time branch has two implementations, and a test suite that only ever elaborates one has verified half the design. Both configurations must be elaborated and regressed, including at the boundary — just below and just above the threshold — because that is where a parameter arithmetic error hides. This is the DV consequence of a density decision, and it is as real as any functional check.

5. Which Axes Are Coupled, and Why the Trade Is Unavoidable

An engineer can usually improve one axis by paying on another. What makes the hierarchy necessary rather than merely convenient is that some axes are coupled by physics, so no amount of effort decouples them. These are the couplings that matter.

Density against access latency, through shared lines. A denser array puts more cells on each shared wordline and bitline. More cells on a line means more capacitance on it, and a line with more capacitance takes longer to drive and to resolve. Simultaneously, each individual cell's contribution to that line becomes relatively smaller — most acutely in DRAM, where Chapter 1.4 §3 showed a tiny cell charge being shared with a long wire. Making the array denser makes its own signals harder and slower to resolve. This coupling is why "dense and fast" is not an engineering goal that better effort achieves.

Density against concurrency, through sharing. §3's exchange. Amortising the access path is what makes bits cheap and is precisely what prevents simultaneous access.

Cell simplicity against maintenance. Chapter 1.4's lesson in one line: the transistors removed to shrink the cell were the ones holding and driving the value, so a simpler cell must be maintained externally. Refresh is the cell simplification, seen from the system.

Persistence against write cost. Chapter 1.5's lesson in one line: storing charge where it cannot leak means it cannot easily be changed either, so the write becomes a high-voltage, slow, coarse-grained, wearing operation. The isolation that provides retention is the same isolation that makes writing hard.

Capacity against physical distance. A structure large enough to hold a system's working set cannot fit on the compute die, so it goes off-chip — and then every access crosses a package boundary and a board, over an interface that must be driven, received, and timed. That distance costs latency and energy per bit moved, and it forces an interface with its own protocol and its own engineering. The whole of the DDR standard, and every PHY module in this curriculum, is the bill for this one coupling.

And one axis that is coupled only economically. Cost per bit against specialisation: the cheapest bits are the ones manufactured in the largest volume to a common specification, which means the cheapest memory is necessarily standardised memory. A technology can be better on every physical axis and still lose on cost because it ships in smaller volume. That is not a physics coupling, and it is no less real.

6. The Trade Surface

With the axes named and the couplings identified, the four technologies can be compared honestly — relatively, not numerically. Every entry below is an ordering claim, defensible from the mechanisms in Chapters 1.2 to 1.5, and none is a measurement.

Read the table by columns, not by rows. Every column has at least one entry no other column can match, and at least one it loses badly. The register file wins latency and concurrency and loses cost by the widest margin of anything in the table. Flash wins cost and persistence and loses on write granularity, endurance and interface. DRAM wins nothing outright — and that is the most interesting fact in the table, so it gets its own chapter next.

And read the interface row carefully, because it is the row engineers under-weight. The cost of using a technology is a real cost. A register file needs an index. A DRAM device needs a protocol engine, a scheduler, a training procedure and a maintenance manager — the entire DDR curriculum. That complexity is part of the price of the cheap bits, and it is paid in design and verification effort rather than in silicon area.

7. Common Mistakes

Comparing technologies on one axis. Wrong mental model: memory technologies can be ranked. What the engineer does: selects a tier because it wins the axis currently under discussion — picks the fastest storage for a capacity problem, or the cheapest for a latency problem. Resulting bug: a design that fails on an axis nobody was looking at: an area or cost overrun discovered at floorplan, or a latency miss discovered in performance validation. Neither is fixable late. How to detect it: ask which of §1's ten axes the requirement actually constrains, and check whether the choice was evaluated against all of them or just one. How to prevent it: write the requirement as a point in the axis space — capacity, granularity, concurrency, latency tolerance, persistence, power budget — before naming a technology.

Treating cost per bit as a property of the cell. Wrong mental model: a smaller cell means cheaper storage. What the engineer does: assumes an embedded array will achieve something like commodity-memory economics, or that a novel technology's cell advantage translates directly into product cost. Resulting bug: a business or architecture case built on a cost that the design cannot reach, because array efficiency, yield, repair, test, packaging and volume were never in the model. How to detect it: look for a cost estimate that has one term in it. §2's chain has at least five. How to prevent it: cost the whole chain, and be especially careful with volume — it is the term most often omitted and frequently the largest.

Believing "denser is slower" is a manufacturing limitation. Wrong mental model: better engineering would eventually give density and latency together. What the engineer does: plans around an expectation that the next generation will improve both, or treats a memory's latency as a target for negotiation. Resulting bug: architecture that depends on a latency improvement that does not arrive, because the coupling in §5 is physical rather than an effort problem. Generational improvements have historically been much stronger in transfer rate than in the latency of an individual access — a directional fact that Chapter 1.8 develops. How to prevent it: design for tolerance of latency rather than for its absence — concurrency, prefetching, locality — which is the strategy the entire memory hierarchy embodies.

Ignoring interface cost when selecting a tier. Wrong mental model: the cost of memory is the cost of the memory. What the engineer does: budgets silicon and money for the storage while under-budgeting the controller, PHY, training, verification and bring-up effort that using it requires. Resulting bug: schedule and effort overruns rather than silicon ones — and they land in the hardest phase, because interface bring-up is where the unknowns are. How to detect it: compare the project's memory-subsystem effort estimate against the number of modules in this curriculum that exist purely to make a DRAM device usable. If the estimate is small, it is wrong. How to prevent it: treat interface complexity as a first-class selection criterion, and prefer a standardised interface with existing IP, tooling and expertise unless there is a strong reason not to.

Assuming one tier will eventually absorb the others. Wrong mental model: the hierarchy is a historical artefact that a sufficiently good technology will collapse. What the engineer does: treats hierarchy-aware design — locality, staging, tiering — as temporary complexity. Resulting bug: software and hardware that is not built for a hierarchy and performs badly on every real system. How to prevent it: recognise that the couplings in §5 are physical. A new technology changes where the tier boundaries sit, and there have been real examples of that; it does not remove the reason boundaries exist. The requirements a main-memory tier must satisfy are the test, and they are the subject of the next chapter.

8. Engineering Analysis — An Area Estimate That Came in Wrong

This chapter's analogue of a debugging scenario is an estimation failure, because that is how the cost/density trade actually goes wrong in practice.

Symptom. A block's storage was estimated from bit count and a per-bit area figure. The synthesised and placed result is substantially larger than the estimate, and the block no longer fits its floorplan allocation.

Hypotheses, ordered by how much of the gap they typically explain.

Hypothesis 1 — the storage was not implemented the way the estimate assumed. Evidence: the synthesis report's cell composition for the block. Discriminator: if the area is dominated by flip-flops where an array was expected, the description was not mapped to an array at all — the single largest and most common source of this failure, and the reason Chapter 1.3 insisted on reading the report rather than assuming inference. Check this first because it is both the most likely and the cheapest to confirm.

Hypothesis 2 — array efficiency was not in the estimate. Evidence: compare the estimate's basis against the macro's actual dimensions, or the array's periphery area. Discriminator: if the array was built but is larger than bits multiplied by cell area, the missing term is the periphery of §2 — and if the arrays are small and numerous, this term can be very large.

Hypothesis 3 — the array was split into many small instances. Evidence: the number of array instances and their individual depths. Discriminator: many small arrays each pay their own periphery, which is §4's minimum-size effect appearing as an area overrun. A design that instantiated per-channel or per-way arrays for convenience can multiply the overhead without any single decision looking wrong. Fix direction: consolidate into fewer, deeper arrays where the access pattern allows — which usually requires revisiting the port requirements that motivated the split.

Hypothesis 4 — the port requirement forced a more expensive structure. Evidence: how many simultaneous accesses the block actually needs. Discriminator: if the design requires more concurrency than one port provides, the implementation may have replicated the array or used a multi-port structure, both of which cost far more than the bit count suggests. This is Chapter 1.2 §4's ports axis showing up as area.

Hypothesis 5 — reset or an unusual enable structure defeated the intended mapping. Evidence: whether the array declaration carries a reset, and whether the enable structure matches the flow's expected template. Discriminator: this is a specific and very common cause of hypothesis 1 rather than an independent one, and it is worth checking explicitly because the fix is small once identified.

Discrimination in one step. Read the cell composition and instance count for the block from the synthesis report. Flip-flop-dominated area points at hypothesis 1 or 5; many array instances points at 3; one array larger than expected points at 2; a replicated or multi-ported structure points at 4. The report answers in minutes what speculation cannot answer at all — and the habit worth taking from this section is that storage area is a measurement, not an estimate, from the moment the first synthesis run exists.

9. Verification and Analysis Perspective

A trade-off chapter still has substantive DV content, and it is not the content people expect.

Every configuration of a configurable design is a design. §4's selection pattern produces two implementations. A regression that elaborates one configuration has verified one. Configurations at and around every threshold belong in the regression list, and parameter arithmetic — widths derived with $clog2, thresholds compared with the wrong operator — is a genuine bug class that only shows up at the boundary.

Performance claims are verification artefacts. If a design's justification includes an access latency, a bandwidth or an area, then something must check that the built design still meets it. A performance property that nobody measures is a comment. The measurement can be an assertion on a latency bound, a counter-based check in a regression, or a report threshold in the flow — but it must exist somewhere that fails when reality diverges.

Storage choice changes the verification target. A flop-based array is fully visible to simulation, and a scoreboard can shadow it exactly. A macro is typically a model with its own behaviour, timing and initialisation semantics, and the questions become different: is the model the right one, are its timing checks enabled, does its initialisation match what the design assumes, and does the design respect its documented constraints. A design that switches implementation across a parameter switches verification strategy with it, which is worth planning for rather than discovering.

Coverage should include the expensive case. This generalises Chapter 1.4 §10's uniform-access-cost mistake. Whatever the density trade cost — exclusivity, latency, a maintenance obligation — stimulus must exercise it. A test suite that never creates contention on a shared port, never forces a row change, and never coincides with maintenance activity has verified the design's easy path.

10. Interview Reasoning

"Why is DRAM cheaper per bit than SRAM?" Primarily because the cell is far simpler — one transistor and one capacitor against several actively driven transistors — and the cell is the term paid at every bit. But the complete answer names the rest of §2's chain: dedicated memory dies achieve high array efficiency, use redundancy and repair to recover otherwise-scrap parts, and ship in enormous volume against a standard specification, which amortises the fixed costs over a vastly larger denominator. A candidate who mentions only the cell has the biggest term; one who mentions volume and repair is reasoning about products rather than about cells.

"Why can we not have storage that is both very dense and very fast?" Because the two are coupled by the physics of shared lines. Density puts more cells on each wordline and bitline, which raises the capacitance that must be driven and resolved while shrinking each cell's relative contribution to the line — so the array's own signals become slower and harder to sense as it gets denser. Separately, density is bought by sharing the access path, and sharing means taking turns. Neither coupling is an effort problem, which is why the engineering response is to build a hierarchy and design for latency tolerance rather than to wait for a technology that resolves it.

"Would you build a 64-entry buffer from flip-flops or from an array?" The honest answer is that it depends, and the interesting part is on what. Below some size the array's periphery overhead outweighs the smaller cell, so flip-flops win; the crossover depends on the technology, the flow's macro overhead, the aspect ratio, the port requirement and the target frequency, so it is a project-level number rather than a universal one. If the buffer needs more than one simultaneous access, that alone may decide it. And whichever is chosen, both implementations should present the same timing contract so the choice stays an implementation detail.

"A new memory technology has a smaller cell than DRAM. Will it be cheaper per bit?" Not necessarily, and the structure of the answer matters more than the verdict. Cell area is one term in a chain that also includes array efficiency, die yield and repair, test time, packaging and — often decisively — production volume. A technology with a better cell that ships in low volume against a non-standard interface can easily cost more per bit than a commodity part with a worse cell. And cost is only one of ten axes: the technology also has to offer the granularity, rewritability, latency and interface a tier requires.

"What does the interface complexity of a memory technology cost, and who pays it?" It is paid in design and verification effort rather than in silicon area, and it is paid by the system integrating the memory, not by the memory. A DRAM device needs a controller with a scheduler, an address-mapping policy, a refresh manager and a PHY with a training procedure, plus the verification and bring-up effort for all of it. That is a real and large cost, and it is part of the price of the cheap bits — which is why a standardised interface with mature IP and tooling is itself a selection criterion.

11. Engineering Check

A block needs a buffer. Three variants of the requirement, otherwise identical. Variant A — 32 entries, and the datapath needs two entries read and one written every cycle. Variant B — 16,000 entries, one access per cycle. Variant C — 16,000 entries, one access per cycle, and the contents must survive a power-down of the block.

1. Which axes does each variant actually constrain? A constrains concurrency hard — three accesses per cycle — and capacity barely. B constrains capacity and therefore cost per bit, and concurrency barely. C constrains capacity and adds persistence, which is a different axis entirely rather than a harder version of the first two. Naming the constrained axis before naming a technology is the whole method.

2. What does A have to be built from, and why? A per-entry structure with multiple ports — the register file of Chapter 1.2. A single-ported array cannot deliver three accesses in one cycle, and at 32 entries the array's periphery overhead is unattractive anyway (§4). The high cost per bit is irrelevant here because there are very few bits.

3. What does B have to be built from? A shared-periphery array. At 16,000 entries, per-entry access paths would be unaffordable in area and unroutable, and the requirement asks for only one access per cycle — which is exactly what a shared structure provides. B is the case where §3's exchange is obviously correct: give up concurrency that is not needed, get density that is.

4. Why is C not simply B with a different technology? Because persistence is not a capacity axis. A flash-based solution would bring an asymmetric write, a block erase granularity and finite endurance (Chapter 1.5) — so if the buffer is written frequently, a persistent technology in place of the array is the wrong answer regardless of capacity. The usual architecture is B's array plus a mechanism: keep it powered during the power-down, or save and restore its contents through a persistent tier. The requirement is met by system design rather than by cell choice.

5. Under what circumstance would B's answer change? If the access requirement rose to several simultaneous accesses per cycle, a single array would no longer serve, and the design would face replication, banking or multi-porting — all of which move cost back into the per-bit term. Notice the shape of that: the concurrency requirement, not the capacity, is what would force the expensive structure. That is the axis engineers most often fail to state up front.

6. What would you measure to confirm the choice was right? For A, the port utilisation — if all three accesses are rarely needed in the same cycle, the concurrency requirement was overstated and a cheaper structure would do. For B, the array's realised area from the synthesis report against the estimate, and the port's busy fraction. For C, the write volume over the product's life if any persistent technology is involved, because that is the budgeted resource (Chapter 1.5 §4). In every case the measurement is cheap and the assumption is expensive.

12. Summary

Memory technologies do not sit on a line from fast to cheap. They are points in a space of at least ten axes — cost per bit, cell area, latency, read granularity, write granularity, concurrency, maintenance obligation, endurance, volatility, power, and the complexity of the interface required to use them at all.

Cost per bit is a chain, not a cell property. Cell area matters most because it is the term paid at every bit, but array efficiency, die yield and repair, test time, packaging and production volume all multiply into the result. The same cell can land at very different costs per bit depending on everything after it — which is why a commodity part manufactured in enormous volume to a standard specification is economically unlike an embedded array with identical cells.

Density is bought by moving costs out of the per-bit term, which in practice means sharing the access path across many cells. The price of sharing is exclusivity: a shared resource serves its users in turn. That single exchange is why every dense memory must be scheduled, must be able to make a requester wait, and eventually needs a controller.

Some axes are coupled by physics and cannot be separated by effort. Density raises the capacitance of shared lines while shrinking each cell's contribution to them, so denser arrays are intrinsically harder and slower to sense. Simplifying the cell removes what was holding and driving the value, so maintenance moves outward. Isolating charge well enough to persist makes it hard to change. And capacity large enough for a working set cannot sit on the compute die, so it goes off-chip — which is the coupling that creates the interface this entire curriculum is about.

One axis is coupled only economically, and it is decisive: the cheapest bits are the ones made in the largest volume to a common specification. Standardisation is not a side effect of the main-memory tier. It is part of why the tier is affordable.

13. What Comes Next

The trade surface is now explicit, and it contains a striking fact: DRAM does not win any axis outright. It is not the fastest, not the cheapest, not the most persistent, not the most concurrent, and it has the second most demanding interface in the table.

So Chapter 1.7 asks the question that the surface makes unavoidable — why does a technology that wins nothing hold the most important storage tier in nearly every computing system? The answer is that main memory does not need a winner on any single axis. It needs a conjunction: fine-grained addressing, unlimited symmetric rewriting, tolerable latency, capacity at a price a system can pay, and an interface an industry can build to. DRAM is the only technology that satisfies all of them at once — and the last of those requirements turns out to be at least as important as the physics.

Return to Flash for the tier below, DRAM for the capacity tier's mechanism, or The Memory Hierarchy for the map. The full path is on the DDR tutorials index.