DRAM 64k 1979 Count Refresh Cycles Array Geometry

# Choose the Array's Shape, and the Refresh Count Falls Out of That Choice

## 1. Turn Step 3's Row-Wide Refresh Into a Concrete Cycle Count

Step 3 established that one $\overline{RAS}$-only cycle refreshes an entire row, which means a complete refresh of the array needs only as many cycles as the array has rows — not as many cycles as it has individual cells. For a 64K-bit array organized as $R$ rows by $C$ columns, with $R\times C=65536$, the number of refresh cycles needed per full retention interval is exactly $R$:

$$n_{refresh}=R,\qquad R\times C=65536$$

This single relationship means the array's row-versus-column split is not an arbitrary layout decision left to convenience. It directly sets how much refresh overhead the chip carries. A square-ish array, $R=C=256$, needs 256 refresh cycles per interval. A array organized as $R=128,\ C=512$ needs only 128. The same total bit capacity, addressed with the same $\log_2(65536)=16$-bit address Step 1 derived, can demand half as many refresh cycles depending purely on how that 16-bit address is split between row and column — a design freedom this project's lineage had never needed to name explicitly, because neither 1968's single-cell framing nor 1974's capacitor geometry work depended on how an array's address space was partitioned.

Row Count Alone Sets the Refresh Burden same 65536 bits, same 16-bit address, very different refresh cycle counts SQUARE-ISH: R=256, C=256 256 × 256 = 65536 n_refresh = 256 8-bit row, 8-bit column split WIDE ROWS: R=128, C=512 128 × 512 = 65536 n_refresh = 128 7-bit row, 9-bit column split half the refresh cycles n_refresh = R, R × C = 65536 fewer, wider rows mean fewer refresh cycles per interval — a new layout-level freedom but wider rows cost more per refresh cycle a tradeoff, not a free lunch — Section 2

## 2. Show the Tradeoff This Freedom Actually Costs

Fewer, wider rows reduce $n_{refresh}$, but Step 3's own mechanism explains why this cannot be pushed arbitrarily far: every one of a row's $C$ cells must be sensed by its own sense amplifier within the same $t_{RAS,min}$ window Step 2 derived, since $\overline{RAS}$ activates the entire row simultaneously. A wider row means more sense amplifiers switching simultaneously, each drawing its own transient current — exactly the kind of simultaneous-current-demand problem the CMOS crossover series' own Step 4 analyzed for switching noise, now appearing inside a single DRAM row-sense operation instead of across a whole logic die.

$$n_{refresh}\times t_{RC}=T_{refresh,total},\qquad \text{total refresh overhead per interval}$$
$$C\uparrow \implies n_{refresh}\downarrow,\ \text{but sense-amp count per row}\uparrow,\ \text{power spike per RAS cycle}\uparrow$$

The total time spent refreshing per retention interval, $T_{refresh,total}=n_{refresh}\times t_{RC}$ (each refresh cycle taking roughly one full RAS cycle time $t_{RC}$), is what a system designer actually budgets against useful access time. Minimizing $n_{refresh}$ by choosing wide rows reduces that total time, but it does so by concentrating more simultaneous sense-amplifier activity into each individual cycle — trading refresh-count overhead for per-cycle power and sensing-margin risk, not eliminating a cost, only relocating it.

Wide Rows Trade Cycle Count for Per-Cycle Sensing Load Real Diagram — the same relocation of cost this project's CMOS series already named FEWER REFRESH CYCLES wide rows, R small, C large T_refresh,total falls more access time for real use the apparent win PER-CYCLE SENSE LOAD C sense amps per RAS pulse simultaneous current demand rises same mechanism as CMOS Step 4's noise the relocated cost T_refresh,total = n_refresh · t_RC, n_refresh = R a real tradeoff, not a free optimization: cycle count down, per-cycle load up array geometry is now a parameter this lineage must choose deliberately how much of the chip's total time does refresh actually consume? that overhead fraction, and the on-chip counter that automates it — Step 5

## 3. Name the Overhead This Geometry Choice Ultimately Produces

This step completes the link Step 3 opened between this series' addressing mechanism and the project's earlier refresh physics, turning a qualitative coupling ("RAS refreshes a whole row") into a quantitative design parameter ($n_{refresh}=R$) a chip designer must actually choose. It also surfaces, for the first time in this project's DRAM lineage, a tradeoff this project has already analyzed once before in a different context: concentrating simultaneous current demand into fewer events to save overhead elsewhere, which the CMOS crossover series' own Step 4 showed carries its own power and signal-integrity cost. The mechanism differs — that series dealt with many logic gates switching on one clock edge, this step deals with many sense amplifiers resolving on one RAS pulse — but the underlying lesson, that concentrating simultaneous activity is never a free way to reduce an overhead count, recurs identically.

What remains unresolved after this step is how a system actually keeps track of which row needs refreshing next, and how often the full cycle of $R$ refresh operations must repeat to stay ahead of $t_{ret}$. Step 5 takes up that operational question directly: the on-chip refresh counter that automates the row-stepping sequence this step's $n_{refresh}=R$ relationship demands, and the fraction of total chip time that automated refresh schedule consumes once every cost this step and Step 3 identified is accounted for.

Take dram 64k 1979 count refresh cycles array geometry 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