DRAM 64k 1979 on Chip Refresh Counter Automation

# Let the Chip Remember Which Row Comes Next, So the System Does Not Have To

## 1. State What Manual Row-Stepping Would Demand of the Host System

Step 4 established that a complete refresh needs exactly $R$ row-wide $\overline{RAS}$-only cycles, one per row, repeated often enough to stay ahead of $t_{ret}$. Nothing in that derivation says who decides *which* row address to present on each of those $R$ cycles. The naive answer — the host system presents row addresses $0,1,2,\ldots,R-1$ in sequence, driving the address pins itself for every refresh cycle — works, but it burdens the host with a bookkeeping task that has nothing to do with the data the host actually wants to store or retrieve: tracking a counter whose only job is cycling through row addresses on a schedule the DRAM's own retention physics dictates, not the host's own logic.

This is the kind of distributed-responsibility problem this project's earlier series have repeatedly resolved by moving the burden onto the device whose physics created it in the first place, rather than leaving it to an external system that has no natural reason to carry it. The 1979 generation's answer is an on-chip refresh counter: a small register, built into the DRAM itself, that increments automatically and supplies the next row address whenever a refresh-only cycle is requested — the host triggers a refresh cycle generically, without specifying which row, and the chip's own counter supplies the row address Step 4's schedule requires.

$$\text{row}_{refresh}(n) = (\text{row}_{refresh}(n-1)+1)\bmod R$$
Row-Stepping Moves Onto the Chip That Needs It Done the host triggers a refresh; the chip's own counter decides which row MANUAL ROW-STEPPING host tracks row 0, 1, 2, ... R-1 host drives row address every cycle host carries DRAM's own bookkeeping a burden with no host-side purpose ON-CHIP COUNTER host triggers refresh generically chip's own counter supplies row address row(n) = (row(n-1)+1) mod R bookkeeping stays where it originated RESPONSIBILITY MOVES TO WHERE THE PHYSICS LIVES retention time is a property of the DRAM array, not of the system using it automating the schedule inside the chip is the natural place to put it does automation actually cost less time than it saves? measuring the real refresh-overhead fraction — Section 2

## 2. Measure the Actual Overhead Fraction This Schedule Consumes

Automating the counter removes the host's bookkeeping burden, but it does not remove the time $R$ refresh cycles actually take — Step 4's $T_{refresh,total}=R\times t_{RC}$ still has to fit somewhere within each retention interval $t_{ret}$. The fraction of total chip time this consumes is a direct ratio:

$$f_{overhead}=\frac{T_{refresh,total}}{t_{ret}}=\frac{R\cdot t_{RC}}{t_{ret}}$$

For representative 64K-generation values — $R=256$ rows, $t_{RC}$ on the order of a few hundred nanoseconds, and $t_{ret}$ in the low tens of milliseconds — $f_{overhead}$ comes out to a small single-digit percentage of total available time: real, non-zero, but small enough that the host system's useful access time is barely diminished, provided the refresh schedule is interleaved with normal accesses rather than forcing the whole array offline in one uninterrupted burst. This is exactly the quantified verification this project's established accounting discipline requires: Step 4 identified the tradeoff in principle, and this step confirms numerically that the chosen geometry and automated schedule keep that tradeoff's cost small relative to what it buys.

Refresh Overhead Is Real but Small, Given at 1979's Typical Numbers Real Diagram — the overhead fraction this series' entire argument rests on staying small f_overhead = R · t_RC / t_ret R ≈ 256, t_RC ≈ few hundred ns, t_ret ≈ tens of ms small single-digit percentage of total chip time interleaved with normal access, not a disruptive all-at-once burst THE NUMBERS CONFIRM STEP 4'S TRADEOFF WAS WORTH MAKING automated row-stepping plus the chosen geometry keep overhead small enough to ignore in practice a direct quantitative check, not an assumption this series' core mechanism is now fully specified what later DRAM inherits from it — the series' closing step

## 3. Place Automation in the Project's Pattern, and Preview the Series' Close

This step follows a pattern this project's earlier series have used whenever a repeated operational burden emerges from a device's own physics: move the responsibility onto the device itself rather than leaving it to the system around it. The 1968 series established that refresh is necessary at all; this series has now carried that necessity through addressing (Steps 1–2), shown it compounds across an entire row (Step 3), quantified the cycle count a given geometry demands (Step 4), and closes the mechanism here by automating the schedule so the host system experiences only a small, interleaved, mostly invisible overhead rather than an explicit bookkeeping task.

With this step, the series has fully specified the mechanism a 64K-generation DRAM actually needs to work in practice: multiplexed addressing with its RAS/CAS timing discipline, the row-wide activation that discipline rides on top of, the geometry-dependent refresh count that activation implies, and the on-chip automation that makes the resulting schedule invisible to the system using the chip. What remains is the step this project's established closing pattern calls for: separating what of this mechanism is permanent practice inherited by every later generation of DRAM from what was particular to 64K's specific pin count, row count, and timing numbers.

Take dram 64k 1979 on chip refresh counter automation further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app