The Destructive-Read Property

Chapter 2.4 ended with a claim that needs proving: the destructive read is in the wiring, not in the operation. A cell with no drive, connected to a bitline whose capacitance is much larger than its own, cannot avoid giving up its charge — so the property exists before any read is issued.

This chapter proves it and follows it through. The central question:

What exactly happens to a stored charge when a cell is selected, and why can the access not end at the moment the data becomes known?

That second clause is where the interesting engineering is. Everyone eventually learns that a DRAM read is destructive. Far fewer can say what state the cell is in immediately afterwards, why the signal needs amplification rather than mere detection, or why the access has a mandatory tail that no optimisation can remove. Those three answers are what turn "DRAM reads are destructive" from a fact into a mechanism you can reason with — and they are the direct origin of the timing constraints that Modules 9, 13 and 14 will formalise.

1. Five Stages, and Why There Are Exactly Five

The read is a sequence. Naming the stages first makes the rest of the chapter a matter of filling them in.

The count is not arbitrary. Stages 1 and 2 are states; stage 3 is the physical interaction; stage 4 is the analog-to-digital conversion; stage 5 is the repair. Remove any one and the sequence breaks: without 3 there is no evidence, without 4 there is no digital value, without 5 the cell is left holding nothing usable.

And notice where the data arrives. The value becomes known at stage 4, but the access is not finished — stage 5 still has to happen, and it takes real time. That gap between "the data is available" and "the device is ready for something else" is the origin of a whole family of DDR timing constraints, and it is the single most useful thing to take from this chapter.

2. Stage 1 — Isolated

The starting state. The wordline is low, the access transistor is off, and the storage node holds its charge subject only to the slow leakage of Chapter 2.2.

One thing about the bitline matters here, and it is easy to skip past.

The bitline does not begin in an arbitrary condition. Before a read, it is deliberately brought to a known, defined starting condition — a reference against which a small change can be measured. This has to happen, and the reason is worth stating precisely: stage 3 produces a small change, and a change is only meaningful relative to a known starting point. A bitline left in whatever condition the previous access happened to leave it in would make the next read's small shift uninterpretable.

Two consequences that shape everything above the cell.

Preparing the bitline takes time, and it is part of the cost of reading a different row. This is the physical origin of the asymmetry Chapter 1.4 demonstrated at cycle level: an access to an already-open row does not need this preparation, and an access to a different row does. The model in that chapter called it "returning the array to a ready state"; this is what that state is.

The starting condition is shared by the whole column. One bitline serves many cells (2.4 §4), so preparing it prepares it for whichever cell is selected next — another instance of a cost amortised across many cells rather than paid per cell.

3. Stage 2 — Connected

The wordline is asserted. Every access transistor along it turns on, and every cell in that row is connected to its own bitline.

Three points, all consequences of Chapter 2.4's structure rather than new facts.

This is a whole-row event. One wordline, many cells. The row is the unit of participation, so a read of one location necessarily involves every cell in its row. Nothing about the operation is per-cell.

Nothing has happened to the data yet — but it is now unavoidable. At the instant the switch closes, the interaction of stage 3 begins on its own. There is no version of "connected but undisturbed", because the cell has no drive with which to hold its condition against the bitline it is now joined to.

And the cell cannot be consulted about it. Chapter 2.4 §3: selection is a physical connection, not a message. The cell has no say, no acknowledgement, and no ability to signal that anything occurred.

4. Stage 3 — Shared, and Why the Signal Is Small

This is the mechanism the whole chapter turns on. Take it carefully.

Two capacitances are now connected: the cell's storage capacitance, deliberately minimised because cell area is the cost term paid at every bit, and the bitline's capacitance, which is much larger because the bitline is a long wire carrying many cells' connections. The cell has no drive, so it cannot force the bitline anywhere. What happens instead is charge redistribution: the charge that was on the cell spreads across the combined capacitance, and both nodes settle to one shared condition.

Three results, all of which follow from that single sentence.

The bitline's condition changes by a small amount. How large the change is depends on the ratio of the two capacitances, and the ratio is unfavourable by construction — a small capacitance sharing with a much larger one moves the larger one only slightly. The direction of the change reveals what the cell held: a charged cell nudges the bitline one way, a discharged cell the other. The direction carries the information; the magnitude is small.

The cell's condition also changes — and this is the destruction. Its charge is no longer concentrated on the storage node; it has been shared away. Whatever the cell held before, afterwards it holds the same shared condition the bitline does, which is close to the starting reference and far from either target state. The stored value is gone. Not corrupted, not weakened: consumed.

And the evidence is single-use. There is no second chance to observe the cell, because the observation destroyed the thing being observed. This is why the sequence cannot be retried: a failed sensing attempt cannot simply read the cell again.

Why this chapter quotes no ratio. The relationship between cell and bitline capacitance is a real, central, product-specific design quantity, and it is one of the numbers DRAM designers work hardest on — because it sets how much signal sensing has to work with. The structural claim is what transfers and is not in doubt: a minimised cell capacitance sharing with a long shared wire produces a small shift. A specific figure would be wrong for most parts and unverifiable by a reader.

5. Stage 4 — Sensing Is Amplification, Not Detection

A distinction that sounds pedantic and is not.

Detection would mean: look at the bitline, see which way it moved, report it. That framing implies the information is already present in usable form and merely needs to be observed.

Amplification means: take a small difference that is comparable in scale to the things that could confuse it, and produce from it a definite, full-strength digital value. That is a much stronger operation, and it is what the circuitry actually does.

The difference matters because of what the small shift has to be distinguished from. Chapter 2.2 §2 and 2.4 §4 listed the competition: cell-to-cell manufacturing variation, coupling from neighbouring structures, thermal noise, and supply disturbance. The real signal is small; so are all of those. Sensing is the act of making a reliable decision in a regime where the signal and the noise are of comparable scale — which is why it is a specialist circuit-design discipline and why a large part of a memory die is devoted to it.

Three system-level facts follow, and they are this chapter's contribution to everything later.

Sensing takes time. Amplification is a physical process with a duration; it cannot be treated as instantaneous. This is one of the reasons a read is not a single-cycle event.

Sensing is shared, so access is exclusive. The circuitry is too expensive to provide per cell, so it serves a whole column across all rows (Chapter 1.6 §3). While it is resolving one row, it cannot resolve another — which is why one row at a time is a structural limit rather than a policy.

And the result is strong where the evidence was weak. After sensing, the value exists as a full-strength digital condition rather than a small shift. That matters enormously for stage 5, because something now exists that is capable of driving the cell back — and nothing before stage 4 was.

What Module 3 adds. How the circuit achieves this: what it compares against, how the comparison is arranged, how the array is organised around it. This chapter needs only its function and its three consequences.

6. Stage 5 — The Access Cannot End Here

The data is known. A naive design would return it and move on. It cannot, and the reason is the whole of Chapter 2.6 — but the necessity belongs here, because it is a direct consequence of stage 3.

After stage 3 the cell holds a condition close to the reference and far from either target. If the access ended at stage 4, that is the state the cell would be left in: holding nothing recoverable. The next read of that cell would share a meaningless condition onto the bitline, and the value would be lost — not corrupted at some later time by leakage, but destroyed immediately, by the act of having been read.

So the resolved, full-strength value from stage 4 must be driven back into the cell, re-establishing the separation the read consumed. That is possible only because stage 4 produced something strong: the cell could not restore itself, and the small shared condition could not restore it either.

Which yields the sentence that most surprises people coming from software:

A DRAM read contains a write. Not as an optimisation, and not as a side effect worth avoiding — as the completion of the read.

And it creates the timing structure of the device. The data is available at stage 4, but the array is not finished until stage 5 completes. So there is a window in which the value has been delivered and the device is still busy with the consequences of having delivered it. Every timing constraint of the form "after reading, you must wait before doing X" is that window, and Modules 13 and 14 will give those constraints names and values. Understanding the window mechanically now is what makes those parameters derivable rather than memorisable later.

7. The Control Signals, in Sequence

The five stages are a physical progression, and this chapter will not draw them as voltages — the digital waveform component would misrepresent a continuous quantity, and Chapter 2.1 §7's discipline applies to figures as much as to code.

What can be drawn honestly is the digital control that sequences the stages. These are real signals a controller and an array's periphery exchange, and their ordering is the point.

These are control signals, not physical quantities. bl_prepare is a command to bring the bitline to its starting condition, not a picture of the bitline's voltage. sense_en enables the sensing circuitry; it does not depict amplification. The stages themselves are continuous processes, and the figure shows only the digital scaffolding that orders them.

Read the sequence for its ordering, which is the teachable content.

Cycles 0–1 — preparation. The bitline is brought to its known starting condition, and row_ready is high because no row is engaged. This is stage 1, and it is the cost an access to a different row pays.

Cycle 2 — the wordline asserts and row_ready falls. Stages 2 and 3 begin together, because they must: connecting is sharing, for a cell with no drive. From this cycle the selected row's stored states are being consumed.

Cycles 3–5 — sensing. sense_en is active and amplification is under way. Note that data_valid is not asserted yet: the value exists as a resolving analog condition, not yet as a trustworthy digital one. Asserting valid early would be the design equivalent of reading a needle before it has settled.

Cycle 5 — data valid. Stage 4 completes and the value is available. A naive reading of the figure would stop here.

Cycles 5–7 — the phase band. restoring is active at the same time as data_valid. The data has been delivered and the array is still working. This is the window §6 described, and it is the single most important feature of the figure.

Cycle 8 — restoration completes and row_ready returns. Only now may a different row be engaged.

8. What This Means for Design and Verification

For RTL engineers. The gap in the phase band is your problem. A controller must track that the array is busy after it has returned data, which means "data returned" and "resource free" are two separate pieces of state. A design that treats the arrival of data as the end of the operation will issue the next operation too early — and because the array cannot refuse (Chapter 2.4 §3), nothing will report the violation.

For verification engineers. Two properties are worth pinning immediately. First, valid must not be asserted before sensing has resolved, because an early valid delivers an undecided value that will often happen to be right. Second, a new row must not be engaged before restoration completes, because that is data destruction with no error signal. Both are temporal properties on control signals, and both are checkable without any visibility into the array — which is fortunate, since there is nothing digital to observe inside it.

For anyone using a behavioural memory model. A model that returns stored values has no stage 3, no stage 4 and no stage 5. It cannot exhibit an early-valid bug, a premature row change, or marginal sensing, because it has none of the mechanisms those bugs corrupt. That is the right level of abstraction for most verification, and knowing what the model cannot show you is what prevents concluding that a design is proven against behaviour the model never had.

For interpreting timing constraints when they arrive. Modules 13 and 14 will present a family of parameters as a catalogue. This chapter is where they come from: each one separates two stages whose physical processes must not overlap. A reader who holds the five stages can usually predict what a given constraint must be protecting before being told.

9. Common Misconceptions

"A DRAM read is destructive because the sensing circuit drains the cell." Wrong model: the destruction is caused by the reading circuitry, so better circuitry could avoid it. Engineering consequence: the engineer expects the property to be an implementation artefact that a future generation removes, and treats restore and its timing consequences as temporary overhead. Observable failure: architecture and performance models that assume the read's mandatory tail can be engineered away, producing predictions that no device will ever meet. Correct model: the destruction happens at stage 3, before any sensing circuit is involved. It is charge redistribution between a small capacitance and a much larger one, which is what connecting a driveless cell to a bitline is. No sensing design avoids it. Prevention: locate the destruction at the connection, not at the amplifier.

"Sensing detects which way the bitline moved." Wrong model: the information is present and merely needs observing. Engineering consequence: underestimating why sensing is difficult, why it takes time, why it occupies substantial die area, and why marginal behaviour exists at all. Correct model: the shift is comparable in scale to variation, coupling and noise. Sensing makes a reliable decision in that regime and produces a full-strength result — amplification, not observation. Prevention: ask what the signal must be distinguished from. The answer explains the effort.

"Once the data is valid, the read is finished." Wrong model: data availability and resource availability are the same event. Engineering consequence: a controller that issues the next operation as soon as data returns, violating the array's requirements. Since the array cannot refuse and reports nothing, the result is corrupted rows discovered much later. Observable failure: data loss concentrated in rows accessed immediately before a row change, with no error signal anywhere — a pattern that looks inexplicable without this mechanism. Correct model: the value is known at stage 4; the array is finished at stage 5. Figure 2's phase band is the gap, and it is mandatory. Prevention: track "data returned" and "resource free" as separate state. Every DDR timing constraint of the form "after reading, wait before X" is this gap.

"Reading the same location twice in a row is cheap, because the data is already there." Wrong model: a read is idempotent, so repeating it costs nothing. Engineering consequence: incorrect performance reasoning, and — more seriously — an assumption that a read can be retried if something goes wrong. Correct model: the first read consumed the cell's charge. The value survives because stage 5 put it back, not because reading left it alone. The evidence is single-use, so a read cannot be retried against the same cell; it can only be repeated after restoration has re-established the state. Prevention: remember that what persists after a read is the result of the restore, not the original charge.

"Destructive read is why DRAM needs refresh." Wrong model: one mechanism, one consequence. Engineering consequence: conflating two obligations with different triggers and different schedules, so neither can be reasoned about. Typically it produces the belief that a busy system needs no refresh — since reads restore what they touch. Correct model: two independent mechanisms consume margin. Reading disturbs a row deliberately and quickly, and the repair is restoration, compelled by the access. Leakage (2.2) degrades every cell slowly whether or not it is touched, and the repair is refresh, compelled by a deadline. Same repair machinery, different causes. Prevention: ask what triggered the repair — an access, or the clock? Chapter 2.3 §1 draws the line.

10. Debugging — Rows Lost Immediately After Being Read

Symptom. Data is corrupted in rows that were recently read. It is reproducible, appears immediately rather than developing over time, and no error is reported. Rows that are only written, or read rarely, are fine.

The combination of immediate, reproducible and correlated with reading rules out Chapter 2.2's statistical mechanisms and points squarely at this chapter's sequence.

Mechanism 1 — a new row was engaged before restoration completed. What to observe: the interval between a read's data becoming valid and the next row selection, compared against the array's stated requirement. Expected evidence: corruption concentrated in rows that were read immediately before a row change, and absent in rows followed by another access to the same row. How to discriminate: this correlation with a following row change is highly specific. If inserting a delay before row changes makes the corruption stop, this is it — and the bug is a controller treating data-valid as the end of the operation (§9's third misconception).

Mechanism 2 — restoration was cut short by an aborted access. What to observe: whether any control path can deselect a row or reset the array mid-access — an error path, a flush, a timeout, a clock-domain event. Expected evidence: corruption correlating with those exceptional events rather than with ordinary traffic. How to discriminate: mechanism 1 correlates with normal row changes; this one correlates with exceptional control flow. Look at what preceded each failure, not just what followed it.

Mechanism 3 — data valid was asserted before sensing resolved. What to observe: the delay from sensing enable to valid, and whether returned data is occasionally wrong rather than the row being destroyed. Expected evidence: wrong values returned while the stored data remains intact on a later read. How to discriminate: check whether the location is still good afterwards. If a re-read returns the correct value, nothing was destroyed and this is an early-valid bug on the read path. If the location is permanently wrong, it is mechanism 1 or 2. That one question splits the space.

Mechanism 4 — two rows were connected at once. What to observe: the wordline selection vector, for one-hot-zero legality and for stability across the access. Expected evidence: two rows damaged per event rather than one, in a consistent pairing. How to discriminate: count the damaged rows. This is Chapter 2.4 §7's failure and its assertions catch it directly.

Mechanism 5 — the bitline was not prepared. What to observe: whether the preparation step runs before every access to a new row. Expected evidence: the first read after a row change returning wrong data, with the stored contents intact, and correctness improving when the previous access happened to leave the bitline in a favourable condition — so the error rate depends on the preceding access's data. How to discriminate: dependence on the previous access's value is a signature nothing else in this list produces.

Root-cause discrimination in two questions. Is the location still good on a later read? No → the row was destroyed: mechanisms 1, 2 or 4, separated by counting damaged rows and by whether an exceptional control event preceded it. Yes → the data path returned a wrong value without destroying anything: mechanisms 3 or 5, separated by whether the error depends on the previous access's data.

The reasoning lesson. This chapter's failures divide cleanly into destruction and misreading, and those have completely different causes and fixes. Every investigation should establish which it is before anything else — and the test is cheap: read the location again.

11. Interview Reasoning

"Why is a DRAM read destructive?" Because the cell has no drive and its storage capacitance is much smaller than the bitline it is connected to. Selection physically joins the two, so the cell's charge redistributes across the much larger capacitance: the bitline shifts slightly, in a direction that reveals the stored state, and the cell is left holding the shared condition rather than its original one. A strong answer locates the destruction at the connection rather than at the sensing circuit, and notes that no improvement in sensing avoids it.

"Why is the resulting signal small, and why does that matter?" Because a deliberately minimised capacitance is sharing charge with a much larger one, so the larger node moves only slightly. It matters because the shift must be distinguished from cell-to-cell variation, coupling, thermal noise and supply disturbance — all of comparable scale. That is why sensing is amplification rather than detection, why it takes time, why it occupies significant die area, and why marginal behaviour is possible at all.

"Why does a DRAM read contain a write?" Because stage 3 consumed the stored charge. If the access ended when the data became known, the cell would be left holding a condition close to the reference and far from either target — nothing recoverable. So the full-strength value produced by sensing must be driven back to re-establish the separation. It is the completion of the read, not an optimisation: and it is only possible because sensing produced something strong, since neither the cell nor the diluted shared condition could restore anything.

"Data is valid. Is the read finished?" No, and this is the distinction that matters most in practice. The value is known when sensing resolves, but restoration is still in progress and the array is not available for a different row until it completes. So "data returned" and "resource free" are separate pieces of state, and a controller that conflates them will engage the next row too early — which destroys data silently, because the array cannot refuse and reports nothing. Every DDR constraint of the form "after reading, wait before X" is this window.

"Can a DRAM read be retried if sensing fails?" Not against the same cell, because the evidence was single-use: the charge that carried the information was consumed by the act of observing it. What can be done is to wait for restoration to complete and then read again — but that reads back the value sensing decided on, so a wrong decision has already been written into the cell. This is a good part of the reason modern devices include error correction on the die: a marginal sensing decision is not recoverable by repetition.

"How are destructive read and refresh related, and how are they different?" They share repair machinery and nothing else. Both consume margin and both are repaired by re-establishing the state at full strength. But reading disturbs one row deliberately and immediately, and its repair is compelled by the access that just happened; leakage degrades every cell slowly whether touched or not, and its repair is compelled by a deadline. That is why a busy system still needs refresh: accesses only restore the rows they happen to touch, and the deadline applies to all of them.

12. Engineering Check

A controller design returns read data to the requester as soon as the array asserts data-valid, and immediately begins the next operation — which happens to target a different row in the same part of the array.

1. What has the design got right? The data path. The value returned to the requester is correct: sensing resolved it, and it was delivered at the right moment. Any test that only checks returned data will pass, which is exactly why this bug survives.

2. What has it got wrong, and at which stage? It treated stage 4 as the end of the access. Restoration — stage 5 — had not completed, so the row it just read is still holding a shared condition rather than a re-established state. By engaging a different row, the design takes the bitlines and the sensing circuitry away from the row that still needed them.

3. What is the observable consequence, and when? The previously read row is left holding nothing recoverable. Its data is destroyed immediately, with no error reported, because the array cannot refuse and has no way to signal the violation. The failure surfaces at some later, unrelated read of that row — which is what makes it look inexplicable in a log.

4. Why will a data-comparison scoreboard not catch it? Because the transaction that triggered the damage returned correct data. The corruption is in a different location and is discovered by a later transaction, with nothing connecting the two. The check has to be on the timing of the control sequence, not on returned values — the same lesson Chapter 2.3 §7 drew for the refresh deadline.

5. What state does the design need to be correct? Two separate facts rather than one: data has been returned and the array is free. The second becomes true only when restoration completes, which is later. That separation is the whole content of the fix, and it generalises — whenever an operation has a tail beyond its result, a design needs two pieces of state, not one.

6. Which property would you write, and what would it be checked against? That a row selection never occurs while the previously selected row is still restoring — expressed on the control signals of Figure 2, checking that row_ready has returned before a new wordline is asserted. It needs no visibility into the array, which is fortunate, because there is nothing digital in there to observe.

13. Summary

A DRAM read is a five-stage sequence, and the count is structural. The cell is isolated, holding its charge against a bitline that has been brought to a known starting condition. The wordline asserts and the row is connected — a whole-row event, since one wordline serves many cells. The charge is then shared: because the cell has no drive and its capacitance is much smaller than the bitline's, its charge redistributes across the larger capacitance, shifting the bitline slightly in a direction that reveals the stored state, and leaving the cell holding the shared condition instead of its own. That is the destruction, and it happens at the connection, before any sensing circuit is involved.

The shift is then sensed — which is amplification, not detection, because the signal is comparable in scale to variation, coupling and noise, and a reliable decision in that regime is hard. Sensing takes time, is shared across a column so access is exclusive, and produces a full-strength result where the evidence was weak.

And because stage 3 consumed the stored state, the access cannot end there. The resolved value must be restored — driven back into the cell at full strength — which is possible only because sensing produced something strong. So a DRAM read contains a write, as its completion rather than as a side effect.

The consequence that matters most in practice: the data becomes valid at stage 4, but the array is not finished until stage 5. Data availability and resource availability are separate events, and the gap between them is mandatory. Every DDR timing constraint of the form "after reading, wait before X" is that gap — and a controller that treats data-valid as the end of the operation destroys the row it just read, silently, because the array cannot refuse and reports nothing.

14. What Comes Next

Stage 5 has been named, justified, and used — but not examined. Chapter 2.6 is its chapter, and it closes Module 2 by turning the mechanism into the digital control obligations a system must implement.

It answers the questions this chapter left open. What exactly does restoration do to the cell, and what is it driven by? Why does it cover a whole row rather than the accessed location? What does it mean that a row, once restored, is sitting in the sensing circuitry in a resolved state — and what does that imply about accessing further locations in the same row? And, in the module's closing RTL, how does a controller sequence an access so that prerequisites cannot be skipped and the array is never engaged before it is ready?

Return to The DRAM Cell (1T1C) for the structure this mechanism runs on, Charge Storage and Leakage for the other mechanism that consumes margin, or The Refresh Requirement for the deadline it creates. For the system-level consequence of state-dependent access cost, see DRAM. The full path is on the DDR tutorials index.