DRAM Refresh
Every cell in this memory is read and written back on a fixed schedule, forever, whether it needs it or not. The schedule is not set by how long a cell holds its value. It is set by how long the WORST cell on the die holds its value, and measurement puts that cell at roughly one in a hundred million. Everything after that is three divisions: the window shared across the rows, and the interval that produces set against the time a refresh takes. This page makes all three movable, because the arithmetic is the interesting part and nobody ever leaves it in the reader's hands.
New to how a memory chip holds a bit? Start here
A bit in this kind of memory is not a switch that stays where it is put. It is a charge on a capacitor about a millionth of a millimetre across, and one transistor that connects it to a wire. That is the whole cell, which is why this memory is cheap and dense and why everything else on this page follows.
A charge that small leaks away. Nothing is broken when it does; it is what charge does. So the machine has to go round and read every cell before its charge has drifted too far to be told apart from the other value, and write back what it read. The reading is the refreshing: there is no separate operation.
Fast and forgetful, or slow and permanent
Memory is quick and loses everything when the power goes. A disk keeps what it was given and is slower by a factor with several zeroes in it. No single part is both, and no amount of engineering has made one.
So nearly every design in this topic is buying one with the other. Keep it in the fast part and you are quick until the lights go out. Write it to the slow part first and you are safe but waiting. The machines here are the arrangements people found in between, and each of them is honest about which half it gave up.
The machine for this idea on its own is Write-Ahead Log, if you would rather press it than read about it.
The bit disappears unless the machine keeps reading it back
1 One cell, and the window in which the charge it holds is still readable as the value that was written
The standard gives every cell the same window, and it is set by the worst one. The two measured figures below are not modelled: they come from a study that read retention times off a real 32 GB system. The population table beside them is a model, and it is here for the counting argument rather than as a claim about any part.
| cells | need a window shorter than | share of the system |
|---|
2 That window shared out across every row, which is what fixes the interval between one refresh and the next
The window belongs to the whole part and every row has to fit inside it. Divide one by the other and the interval falls out; nothing else decides it. The standard prints the answer to two figures, and the arithmetic here does not round.
| quantity | value |
|---|
3 The interval against the time a refresh takes, which is the share of the memory the program never gets
A refresh takes time during which the part is not answering, and how long it takes is specified per density. That time against the interval is the share of the memory the program never gets, and it is the only number here anybody has to care about.
| density | refresh cycle | share of the part's life |
|---|
These ran in this browser when the page loaded. Each claim, whether it held, and the number behind it.
| claim | held | measured |
|---|---|---|
| the interval times the number of rows is the retention window again, exactly | yes | 7.8125 µs x 8192 rows = 64 ms, and the identity holds for six row counts including three that do not divide the window evenly |
| the interval this arithmetic produces is the interval the standard specifies | yes | the specification gives tREFI as 7.8 µs; 64 ms across 8,192 rows is 7.8125 µs, which is that number before it was rounded to two figures |
| above 85 °C the interval is halved, which doubles the overhead and moves nothing else | yes | the specification gives 3.9 µs above 85 °C against 7.8 µs below it, and the overhead goes from 4.19% to 8.38% with the same rows and the same cycle |
| the cost grows with every density in the table, and the interval never moves | yes | 256 Mb 0.96%, 512 Mb 1.34%, 1 Gb 1.63%, 2 Gb 2.50%, 4 Gb 4.19%; tREFI is 7.8 µs at every one of them |
| doubling the rows doubles the overhead, because the window did not grow with them | yes | 4.19% at 8,192 rows becomes 8.38% at 16,384, on the same 64 ms window |
| the schedule is set by a handful of cells in a hundred billion | yes | in the measured 32 GB system fewer than 1,000 cells of more than 1 x 10^11 need a window shorter than 256 ms, which is about one in 1 x 10^8; the standard gives all of them 64 ms, four times shorter still |
| a window has to clear the worst cell, and the count notices when it does not | yes | no cell of 64 loses its value at 64 ms; stretch the window to 512 ms and 64 of them do |
| no power figure appears anywhere on this page | yes | refresh is often introduced as an energy problem, and the energy depends on the process, the die and the mode, none of which is modelled here; the share of TIME follows from the two documents this page cites and the share of ENERGY does not |
| this is one standard at one generation, and tRFC has grown a great deal since | yes | the refresh cycle times here are DDR2, topping out at 4 Gb. Later generations specify much longer ones at much higher densities, so the trend this page shows continues past the right-hand end of its own table; the figures are the ones that can be pointed at in an archived document rather than the most current ones |
What is real here, and what is not
The population of cells is a model; the two figures beside it are not
Retention times in the table are spread geometrically upward from the standard window, which is a model and not a measurement. The real distribution is not geometric and it has a tail, which is exactly what makes this hard. The counting argument does not depend on the shape: a window has to clear the worst cell, so every better cell is refreshed more often than it needs. The numbers that carry the argument -- about thirty cells needing a window under 128 ms, fewer than a thousand needing one under 256 ms, out of more than a hundred billion -- are read off a published measurement of a real system and are not modelled here at all.
This is DDR2, and the numbers have grown since
The refresh cycle times on this page are from JESD79-2B and stop at 4 Gb because that is where that document's table stops. Later generations specify much longer refresh cycles at much higher densities, so the trend shown here continues past the right-hand end of its own table rather than levelling off. The figures used are the ones that can be pointed at in an archived document instead of the most recent ones, because a number nobody can check is not better for being newer.
The standard rounds and this page does not
JESD79-2B gives the average refresh interval as 7.8 microseconds. Sixty-four milliseconds divided across 8,192 rows is 7.8125 microseconds, which is the same number before it was printed to two figures. The arithmetic here stays in integer picoseconds and the round trip is checked by cross-multiplication, because the difference is multiplied by the row count before anybody looks at it.
No power figure appears anywhere, and that is deliberate
Refresh is often introduced as an energy problem, and the figure usually quoted is that it can be a large share of standby power in a low-power device. That depends on the process, the die, the mode and the temperature, none of which is modelled here. The share of TIME follows from the two documents this page cites. The share of ENERGY does not, so it is not printed.
The rows are per bank, and banks refresh together
The row count here is the count in one bank, because that is what the refresh counter steps through and what a specification lists. A part with eight banks does not need eight times as many refresh cycles; the banks are refreshed together. Using the whole device's row count as the divisor gives an answer several times too large, and it is a common way to get this wrong.
1968 is the grant, and the invention is a year or two earlier
Dennard's one-transistor cell was filed on 14 July 1967 and granted on 4 June 1968, and he has described arriving at the idea in 1966. The roster carries the grant year because that is the date the document itself bears. Where a date rests on one person's recollection this site says so rather than picking the tidier story.
Sources
- Robert H. Dennard, Field-effect transistor memory, US Patent 3,387,286, assigned to IBM: filed 14 July 1967, granted 4 June 1968.
- JEDEC Solid State Technology Association, DDR2 SDRAM Specification, JESD79-2B, January 2005, for the refresh interval, the refresh cycle time at each density and the rule above 85 °C.
- Jamie Liu, Ben Jaiyen, Richard Veras and Onur Mutlu, RAIDR: Retention-Aware Intelligent DRAM Refresh, ISCA 2012, for the measured distribution of cell retention times.
- Logical Art, the studio this belongs to.