Charge Storage and Leakage

Chapter 2.1 ended on an admission. It said charge stays on the storage node "because there is nowhere for it to go" — and then noted that this is approximate. This chapter is about how approximate, and what follows.

The central question is narrower than "why does DRAM need refresh", because that question invites a circular answer. The question worth asking is:

Charge is placed on a node that is supposed to be isolated. What paths does it actually have available, why can none of them be closed, and what exactly fails as a result?

Answer that mechanically and refresh becomes something you derive rather than something you are told. Answer it loosely — "charge leaks away, so DRAM refreshes" — and you have a slogan that predicts nothing: not why retention varies between cells, not why temperature matters, not why the failure is statistical rather than deterministic, and not why the obligation lands on a controller rather than on the device.

1. Isolation Is a Matter of Degree

The intuition that defeats engineers here is binary: a node is either connected or isolated. Real structures do not work that way.

Every material that is called an insulator conducts a little. Every switch that is called off passes a little. Every junction that is called reverse-biased leaks a little. These are not manufacturing defects to be eliminated; they are the ordinary behaviour of semiconductor structures, and they are consequences of the same physics that makes the structures work at all. A transistor that could be perfectly off would be a transistor with no current at all in any condition.

So the accurate statement about a DRAM storage node is not that it is isolated. It is that the node is connected to its surroundings through paths of extremely high but finite resistance. Charge on it has somewhere to go. It goes there slowly. It goes there continuously, and it never stops.

And here is the property that makes this decisive rather than merely true. Chapter 2.1 §4 established that the cell has no drive: nothing is connected to the node that could push charge back onto it. In a structure with active drive, a small continuous loss is simply supplied — the drive wins and the state holds indefinitely. That is exactly what a static cell's inverters do, and it is why Chapter 1.3's cell needs no maintenance while powered. In the DRAM cell there is no such source. Loss is uncontested, so it accumulates.

That is the whole argument, and it is worth stating as a single implication: passive storage plus unavoidable loss equals a state with a finite lifetime. Neither half alone would be a problem. Together they create an obligation.

2. Where the Charge Goes

Enough mechanism to reason with, without pretending to a device-physics course this chapter is not.

Through the access device. The cell's own switch is the most direct path. A transistor that is turned off does not conduct zero current — it conducts a small current that depends on its construction, its terminal voltages and its temperature. Since the access device sits directly between the storage node and the shared wiring, whatever it passes drains the node. This path is unavoidable in principle: the switch must be able to conduct well when selected, and a device built to conduct well in one condition does not conduct nothing in the other.

Through the junctions in the surrounding silicon. The regions forming the storage node's connection to the substrate behave as junctions, and reverse-biased junctions pass a small current. Again this is normal semiconductor behaviour rather than a defect.

Through the capacitor's own insulator. The dielectric separating the capacitor's two sides conducts slightly. A thinner or otherwise more aggressive dielectric — which is one of the things designers reach for to keep capacitance up as cells shrink — tends to make this worse, which is a genuine tension in cell design rather than an oversight.

And, from outside, through disturbance. Neighbouring structures are capacitively coupled to the node, so activity nearby can shift its charge slightly. This is not leakage in the strict sense — it is not a steady drain — but it has the same effect on the quantity this chapter cares about: the margin between the two states. Its most important manifestation is cell-to-cell disturbance under heavy repeated access, which is a real and much-studied phenomenon in modern devices; the mitigations belong to Module 25, and what matters here is that margin is consumed by activity as well as by time.

The engineering summary. Several independent paths, all consequences of normal device behaviour, all present in every cell, none removable by better manufacturing. Their relative importance differs by technology and by generation, which is precisely why no chapter can usefully rank them with numbers. The structural fact is what transfers: loss is not a defect, it is a property.

3. What Actually Fails Is the Margin

This is the section that separates a mechanical understanding from a slogan, and it corrects the most common wrong picture in the module.

The wrong picture is that a stored 1 gradually becomes a stored 0. That is not what happens, and believing it makes the rest of the behaviour inexplicable.

What happens is that the distance between the two possible states shrinks. Recall Chapter 2.1 §2: writing puts the node near one of two targets, and reading decides which target it is nearer to. That decision is only possible while the two conditions are far enough apart to be told apart against variation and noise. Leakage moves the stored condition away from its target — and as it does, the separation the decision depends on narrows.

Three things this reframing buys immediately.

It explains why the failure is statistical. Cells are not identical. Manufacturing variation means their capacitances and their leakage paths differ, so their margins narrow at different rates. The cells that fail first are the weakest ones in the distribution, not a particular address — which is why retention behaviour is characterised as a distribution across a die and why a device's specification is set by its worst cells rather than its typical ones.

It explains why temperature matters, and in which direction. The leakage mechanisms in §2 are all temperature-dependent, and they all get worse as temperature rises. So a hotter device loses margin faster, which means the interval within which data can still be read reliably is shorter when hot. That is why real memory systems care about device temperature at all — a fact that would be arbitrary under the flipped-bit picture and is a direct consequence under this one.

It explains what the fix has to be. If what degraded is the separation between states, then restoring the separation means re-establishing the state at full strength — reading what the cell currently holds while the decision is still reliable, and writing it back cleanly. That is refresh, and notice that it has been derived rather than asserted: it is the only operation that repairs the thing that broke.

4. Retention Is a Distribution, Not a Constant

A short section with outsized practical value, because it is where datasheets get misread.

If cells vary and conditions vary, then "how long a cell holds its data" is not one number. It is a distribution — across cells on a die, across dies, across temperature, across supply voltage, and across the device's life. The specification a manufacturer publishes is a guarantee constructed from that distribution: an interval within which the device commits to keeping data readable, chosen with margin so that even weak cells under specified worst-case conditions still work.

Three consequences that engineers get wrong.

The specified interval is not a measurement of typical behaviour. Most cells hold their data far longer than the guarantee requires. Observing that a device seems fine when maintained less often than specified proves nothing except that the observation did not happen to include a weak cell at a bad temperature. Designing to observed behaviour rather than to the specification is how a system passes every test and fails in the field, and it is one of the more expensive mistakes available in memory-system design.

The guarantee is conditional. It holds within the device's specified operating conditions. A system running a device outside them — hotter than specified, or at a supply outside range — is outside the guarantee entirely, and the failure mode will be exactly the statistical, condition-dependent corruption §3 describes.

Margin is consumed by activity as well as by time. §2's last mechanism means heavy repeated access to some locations can degrade neighbours faster than the time-based mechanisms alone would. Modern devices include mitigations for this, and a system designer's obligation is to use the device within the terms its specification states rather than to reason from the time-based mechanism alone.

The habit to take from this section: when a memory specification gives a maintenance interval, read it as "the deadline the device guarantees correctness against, under stated conditions" — not as "how long the charge lasts." The first is a contract. The second is a physical quantity that varies per cell, and the contract exists precisely because the quantity varies.

5. From Physical Certainty to System Obligation

Assemble the chapter into the transition that Module 2 is built around.

The physics gives an unconditional statement: a passively stored charge, with no source to contest its loss, has a finite useful lifetime. Nothing about that is negotiable or improvable — it follows from the storage mechanism the tier chose in order to be dense.

A digital system cannot work with an unconditional statement of that shape. It needs a rule, and the rule the physics implies is:

Every location must have its state re-established at full strength within a bounded interval, or the data it holds can no longer be trusted.

That is a correctness requirement, and notice its unusual shape. It is not a requirement on any particular operation — nothing a program does is illegal. It is a requirement on the passage of time, which is a genuinely unusual kind of obligation for a digital design to carry. Most contracts in a digital system are of the form "if you do X you must do Y". This one is of the form "if enough time passes and you have not done Y, you have already lost."

Three things follow, and each is a later chapter or module:

Somebody has to own the deadline. The device cannot own it alone — it does not know when its locations were last written, and it cannot decide to stop serving requests. So the obligation lands on the controller, which must track time and act. That is 2.3, and the digital design it implies.

The maintenance competes with real work. Re-establishing a state occupies the same structures that serve requests, so maintenance consumes device availability. Requests may have to wait for it. That tension is introduced in 2.3 and becomes a scheduling discipline in Module 15.

Maintenance uses the same mechanism as a read. Re-establishing a state means determining what it is and writing it back cleanly — which, as 2.5 and 2.6 will show, is exactly what a read already does. Refresh is not a separate machine bolted onto the device. It is the ordinary access mechanism, run deliberately and for its side effect rather than for its data.

That last point is the one most worth carrying forward, and it is why the canonical order of this module puts refresh before the destructive read: by the time you reach 2.6, you will recognise that the operation you derived in 2.3 was the same one the device was doing all along.

6. What This Means for Design and Verification Work

For RTL engineers. The obligation in §5 becomes state in your design: something counts time, something decides when maintenance is due, something arbitrates between maintenance and requests, and something makes requesters wait. That is real logic with real invariants, and it is the subject of 2.3. The physics does not appear in your RTL — the deadline does.

For verification engineers. This chapter names a class of bug that functional stimulus will not find. A controller that mostly meets its maintenance deadline and occasionally misses it is functionally correct on every transaction and silently wrong about stored data. Nothing in a transaction-level scoreboard notices, because no transaction was mishandled. Catching it requires checking the deadline itself as a property — which is exactly what 2.3's assertions do, and why they matter more than their small size suggests.

For anyone debugging a memory system. §3 and §4 give a signature worth recognising. Corruption that correlates with elapsed time since data was written, with temperature, or with how heavily nearby locations were accessed points at the mechanisms in this chapter. Corruption that is deterministic for a particular address or access sequence does not — that is addressing, control or datapath. Those two investigations share no steps, and the first observation usually separates them.

For system architects. Maintenance consumes a share of device capability, so it belongs in any bandwidth or latency budget as a term rather than as an afterthought. A budget with no term for periodic unavailability is not modelling DRAM, as Chapter 1.4 §10 put it.

7. Common Misconceptions

"Leakage turns a stored 1 into a stored 0." Wrong model: the cell's digital value changes over time. Engineering consequence: the engineer expects deterministic corruption in a predictable direction, and cannot explain why retention varies per cell, why temperature matters, or why the same device is fine for hours and wrong once. Observable failure: a debug effort that looks for a pattern in which bits went wrong instead of measuring the conditions under which they go wrong — and therefore finds nothing. Correct model: the separation between the two possible states narrows. What fails is the decision, not a stored symbol, and it fails first in the weakest cells under the worst conditions. Prevention: reason in terms of margin, as in Figure 1, and characterise failures against time, temperature and access history.

"Better manufacturing will eventually eliminate leakage." Wrong model: leakage is a defect. Engineering consequence: an expectation that the maintenance obligation is temporary, and architectures that treat it as an inconvenience rather than a permanent budgeted cost. Correct model: the leakage paths are ordinary consequences of the same device physics that makes transistors and capacitors work. Improvements change the rates, not the existence — and some changes that help density make particular paths worse. Prevention: treat the obligation as structural. The cell is passive by design, because passive is what makes it small.

"Retention time is a property of the technology." Wrong model: one number describes how long DRAM holds data. Engineering consequence: designing to an observed or typical value, and shipping a system whose weak cells fail under conditions the test never created. This is the field-failure mistake of §4. Correct model: retention is a distribution across cells, dies, temperature, voltage and age. The specification is a conditional guarantee built with margin from that distribution. Prevention: design to the specified interval under the specified conditions, and treat operating outside those conditions as being outside the guarantee.

"Refresh and restore are the same thing." Wrong model: two words for one operation. Engineering consequence: confusion about why each exists, and an inability to reason about their different costs and schedules. They use the same mechanism and answer different problems. Correct model: restore is the mandatory repair of the disturbance caused by an access, and it happens as part of every access (2.6). Refresh is a deliberately initiated access whose purpose is the repair, performed on locations nobody asked for, to meet a time-based deadline. Same machinery, different trigger, different obligation. Prevention: remember that refresh is scheduled by a deadline while restore is compelled by an access that just happened.

"If the system is busy reading memory, refresh is unnecessary." Wrong model: ordinary access maintains the data as a side effect, so a busy device needs no maintenance. Engineering consequence: a plausible-sounding optimisation that loses data. It contains a grain of truth — an access does re-establish the state of what it touches — but the deadline applies to every location, and a workload touches a small and unpredictable subset. Correct model: the obligation is universal and time-based. Nothing about being busy guarantees coverage of the locations nobody touched, which are exactly the ones at risk. Prevention: treat the deadline as applying to all storage, independent of traffic. Module 15 covers what a controller may legitimately do with that latitude.

8. Debugging — Corruption That Comes and Goes

Symptom. A system occasionally reads incorrect data from memory. No error is reported by any logic. It is not reproducible on demand, the affected locations are not always the same, and it seems worse in some deployments than others.

This is the hardest class of memory bug to attribute, and the discriminators are all in this chapter.

Mechanism 1 — the maintenance deadline is being missed. What to observe: the actual interval between maintenance operations for the worst-case location, not the average, and whether anything in the system can postpone maintenance under load. Expected evidence: corruption correlating with sustained heavy traffic, because that is when a controller is most tempted or most forced to defer maintenance. How to discriminate: reduce the offered load and see whether the corruption stops while the data set stays the same. If it does, the deadline is the suspect and the fix is in the controller's scheduling, not in the device.

Mechanism 2 — the device is running outside its specified conditions. What to observe: die temperature and supply voltage under the failing workload. Expected evidence: correlation with temperature, often with a threshold above which the rate rises sharply. How to discriminate: reproduce at a controlled lower temperature. This mechanism and mechanism 1 can look identical in a log, and they separate cleanly on this test — which is why it is worth doing early even though it needs equipment.

Mechanism 3 — access-pattern-induced disturbance. What to observe: whether the workload hammers a small number of locations extremely heavily and repeatedly. Expected evidence: corruption in locations near the heavily accessed ones rather than in the accessed ones themselves — a distinctive and diagnostic signature. How to discriminate: change the access pattern while keeping the data and the load constant. If a pattern change fixes it, this is the mechanism.

Mechanism 4 — data that sat untouched for a long time. What to observe: the elapsed time between writing a location and the failing read. Expected evidence: failures concentrated in cold data — locations written once and read much later — while hot data is always correct. How to discriminate: a test that writes the whole memory, waits, and reads it back, separating the wait from any traffic. This isolates the pure time-based mechanism from mechanisms 1 and 3.

Mechanism 5 — not this chapter at all. What to observe: whether the corruption is deterministic for a specific address or a specific access sequence. Expected evidence: the same bits wrong in the same way every time. How to discriminate: reproducibility itself. Deterministic corruption is a logic bug — addressing, control, datapath, or a controller sequencing error — and none of the mechanisms above produce it. Establishing this first saves the most time, because it points at an entirely different investigation.

Root-cause discrimination, in order of cost. First ask whether it reproduces deterministically: that separates logic bugs from everything in this chapter. Then vary load, temperature, access pattern and dwell time one at a time, because each of the four mechanisms above responds to exactly one of those and is insensitive to the others. Four experiments, four distinguishable outcomes.

And note the reasoning discipline. Every mechanism here is conditional, so the investigation is about finding which condition controls the failure rate — not about examining the failing data. Engineers accustomed to deterministic logic bugs tend to start by staring at the corrupted values, which in this class of bug carries almost no information.

9. Verification Perspective

The specific value of this chapter for a DV engineer is that it describes a correctness property no transaction-level check will detect.

The property is temporal and global. "Every location has its state re-established within the deadline" is not a statement about a transaction. A scoreboard comparing read data against expected data catches it only after corruption has already happened, and only if the test happens to read a location whose deadline was missed, at a temperature where it matters. That is a test strategy relying on luck.

So check the deadline directly. In a controller design the deadline is tracked by real logic, which means it is observable and assertable. Chapter 2.3 §9 writes those assertions. The principle generalises well beyond memory: when a requirement is about elapsed time rather than about an operation, assert the timing mechanism rather than sampling for the consequence.

Stimulus that actually exercises it. Sustained load with no idle gaps, so the controller is pressured to defer maintenance. Traffic patterns that leave large regions untouched for long intervals. Maintenance arriving exactly when a request does. Back-to-back maintenance. Reset asserted with maintenance pending — and the question of what a system may assume about stored data after reset, which is a genuinely subtle contract.

Coverage worth asking for. Maximum observed interval between maintenance operations for the worst-case location; occupancy of any queue that holds deferred maintenance; and the number of requests delayed by maintenance. Those three make the obligation measurable rather than merely asserted, and a regression that reports them will show a deadline drifting long before it is missed.

10. Interview Reasoning

"Why does DRAM lose its data over time?" Because the storage node is connected to its surroundings through several unavoidable high-resistance paths — the access device's off-state conduction, junction leakage in the surrounding silicon, conduction through the capacitor's dielectric — and, critically, because Chapter 2.1 §4's cell has no drive to contest that loss. In a structure with active drive a small continuous loss is simply supplied; here nothing supplies it, so it accumulates. A strong answer names both halves: the loss paths and the absence of anything opposing them.

"Does leakage flip a bit from 1 to 0?" No, and the correct picture matters. The stored condition drifts away from its target, which narrows the separation between the two possible states. What fails is the sensing decision — it becomes unreliable when the separation approaches the scale of cell-to-cell variation and noise. That is why failures are statistical rather than deterministic, why they hit the weakest cells first, and why temperature and elapsed time control the rate.

"Why does temperature appear in a memory specification?" Because every leakage mechanism is temperature-dependent and all of them worsen as temperature rises, so margin is lost faster when hot and the interval within which data remains reliably readable is shorter. This is why real memory systems monitor device temperature and why a maintenance interval is specified together with the conditions it applies under. Running outside those conditions means the guarantee does not apply.

"How is leakage different from what happens during a read?" They are different mechanisms with different time scales and different triggers. Leakage is a slow, continuous, unavoidable drain that acts on every cell whether or not anything touches it. A read deliberately connects the cell to shared wiring, which redistributes its charge in a single fast interaction — a much larger and much faster disturbance, and one that happens only when the cell is accessed. Both consume margin, both require the state to be re-established, and the repair happens to be the same operation. 2.5 is the second mechanism.

"Why is the maintenance obligation on the controller rather than on the device?" Because meeting the deadline requires knowing when to act and being able to act at the expense of other work, and the device can do neither on its own: it does not track when its locations were last written, and it cannot decide to stop serving requests in order to maintain itself. So the requirement — every location re-established within a bounded interval — becomes logic in the controller that tracks time, decides when maintenance is due, arbitrates it against requests, and makes requesters wait. That is what makes it a correctness obligation for a digital designer rather than a device characteristic.

11. Engineering Check

A team observes that their memory subsystem works correctly in the lab when maintenance is performed considerably less often than the device specification requires. They propose relaxing the interval to recover the bandwidth that maintenance consumes.

1. What is wrong with the evidence? It measures typical behaviour and the requirement is about worst-case behaviour. Retention varies across cells and conditions (§4), so a lab test at moderate temperature with a particular data pattern exercises neither the weakest cells nor the worst conditions. Absence of failure in a test that could not have produced the failure is not evidence.

2. What would have to be true for the proposal to be safe? That every cell in every device the product will ever ship, at every temperature and voltage within the operating range, across the product's life, holds its margin for the longer interval. The manufacturer's specification is precisely the statement that they guarantee the shorter interval and not more — so the proposal is a claim the supplier has declined to make, and the team would be assuming the liability for it.

3. What failure would you predict, and what would it look like? Rare, non-reproducible incorrect data, concentrated in cold locations, worse at elevated temperature, worse on some units than others because cell distributions differ between dies. It would pass qualification and appear in the field as an intermittent fault with no clear trigger — the most expensive shape a bug can have.

4. Which lab experiment would most cheaply falsify their conclusion? Write the entire memory, hold it at the top of the specified temperature range with no traffic for longer than the proposed interval, then read it all back and compare. That isolates the time-and-temperature mechanism from every traffic effect and puts the weakest cells under the worst conditions the specification allows — which is exactly the case their lab test omitted.

5. If the bandwidth cost of maintenance is genuinely a problem, what are the legitimate directions? Scheduling rather than skipping: performing maintenance when the device would otherwise be idle, spreading it to avoid long uninterrupted blocking, and using whatever latitude the device's specification explicitly permits for deferring and catching up. Module 15 is the discipline of doing that properly. The distinction is fundamental — when to do required work is an engineering decision; whether to do it is not.

6. What should the design have that would make this argument unnecessary? Instrumentation: a reported maximum interval between maintenance operations for the worst-case location, and a count of deferrals. With that, the question "are we meeting the deadline?" is a measurement rather than a debate, and a drift toward the limit is visible long before anything fails.

12. Summary

A DRAM storage node is not isolated; it is connected to its surroundings through several unavoidable high-resistance paths — off-state conduction through the access device, junction leakage in the surrounding silicon, conduction through the capacitor's dielectric — plus capacitive disturbance from nearby activity. None is a defect; all are ordinary consequences of the physics that makes the devices work.

What makes that decisive is Chapter 2.1's first absence: the cell has no drive, so nothing contests the loss. In a structure with active drive a small continuous loss is simply supplied. Here it accumulates. Passive storage plus unavoidable loss equals a state with a finite lifetime.

What fails is not a flipped bit but the margin. The stored condition drifts off target and the separation between the two possible states narrows, until the sensing decision is no longer reliable against cell variation and noise. That is why failures are statistical, hit the weakest cells first, worsen with temperature, and depend on how long data has sat untouched and on how heavily neighbours were accessed.

Retention is therefore a distribution, not a constant, and a specified interval is a conditional guarantee built with margin — never a measurement of typical behaviour. Designing to observed rather than specified behaviour is how a system passes every test and fails in the field.

And the physical certainty becomes a system rule of an unusual shape: every location must have its state re-established at full strength within a bounded interval, or its data can no longer be trusted. That is a correctness requirement about the passage of time rather than about any operation — which is why it lands on a controller as real logic with real invariants.

13. What Comes Next

The rule is derived. Now it has to be implemented, and implementing a deadline is a digital design problem with a shape worth studying.

Chapter 2.3 builds it: what conceptual work the maintenance operation performs, why it necessarily consumes device availability, why a request may have to wait for it, and — in the module's first RTL — how a design tracks a deadline, decides that maintenance is due, arbitrates it against real traffic, and proves it never silently drops the obligation. That is where this module's physics becomes state machines and assertions.

Return to Capacitor Storage for the storage element and its two absences, SRAM for the actively maintained cell that needs none of this, or DRAM for the tier-level argument. The full path is on the DDR tutorials index.