Visual walkthrough — Register file organization

We only need three plain-word ideas to start, so let us name them once:

Step 1 — One storage cell (the atom)

WHAT. We start with the smallest possible piece: a single box that remembers one bit. In hardware this box is a D flip-flop. It has one data-in wire, one data-out wire, and one clock tick that tells it "now, capture whatever is on data-in and hold it."

WHY start here? Because a register file is nothing but a huge grid of these boxes. If you understand one box and how to (a) look inside it and (b) change it, you understand the whole file — everything else is just doing that for many boxes at once.

PICTURE. The figure shows one cell. The green arrow is data flowing in on a clock edge; the orange arrow is the value flowing out to be read. The little triangle marks the clock input — think of it as the box's heartbeat.

Step 2 — Stack cells into one register (width $n$)

WHAT. One box holds one bit, but we compute on whole numbers. So we lay $n$ boxes side by side and hand them one shared clock and one shared write-enable line. That bundle is a single register: $n$ bits that update together.

WHY. A $32$-bit number is $32$ bits that must be stored and fetched as a unit — you never want half of a number updated. Sharing one enable line guarantees all $n$ bits capture on the same tick, or none do.

PICTURE. Below, the $n$ cells of Step 1 are drawn in a row. The single teal wire on top is the shared write-enable; when it is $1$ at a clock tick, all $n$ boxes latch their inputs at once.

$\underset{\text{one row}}{\underbrace{\text{register}}}=\underset{\begin{array}{c}\text{how many}\\ \text{bits wide}\end{array}}{\underbrace{n}}\times \underset{\text{Step 1 box}}{\underbrace{\text{cell}}}$

Each symbol above: $n$ = the width (how many bits in one number); "cell" = the single box from Step 1; the product means "a register is $n$ copies of that box wired to one enable".

Step 3 — Stack registers into the file ($N=2^k$ rows)

WHAT. Now stack $N$ of those registers vertically. That grid is the register file: $N$ rows, each $n$ bits wide.

WHY the number $N=2^k$? Because we will name each row with a $k$-bit address, and a $k$-bit binary number can point at exactly $2^k$ different rows — no more, no fewer. Choosing $N$ to be a power of two means no address goes to waste. If $k=5$, then $N=2^5=32$ rows, which is exactly the common case.

PICTURE. A grid: rows are registers (labelled R0, R1, ... R$(N-1)$), columns are bit positions. The total number of storage boxes is the whole grid.

$\underset{\begin{array}{c}\text{number of}\\ \text{registers}\end{array}}{\underbrace{N}}=2^{\stackrel{\text{address bits}}{\overbrace{k}}},\underset{\text{total stored bits}}{\underbrace{N\cdot n}}=\underset{\text{rows}}{\underbrace{2^k}}\times \underset{\text{cols}}{\underbrace{n}}$

$N$ = how many rows; $k$ = how many bits in the address that picks a row; $N\cdot n$ = every box in the grid. For $N=32,n=64$ that is $32\times 64=2048$ boxes of state.

Step 4 — Reading: pick ONE row onto a wire (the MUX)

WHAT. We have $N$ rows but the ALU can only look at one at a time on a read wire. We need a gadget that takes an address and selects the matching row's output onto that wire. That gadget is a multiplexer (MUX): a many-in, one-out switch steered by the address.

WHY a MUX and not something else? The very shape of the read problem is "given $N$ candidates and a chosen index, put the chosen one on a single output wire." That sentence is the definition of a MUX. We reach for a MUX because the problem is literally "select one of many onto a wire" — no other block does exactly that. A $2^k$-to-$1$ MUX steered by the $k$-bit address does the whole job.

PICTURE. The figure shows all $N$ row-outputs entering a big trapezoid (the MUX). A plum-coloured $k$-bit address enters the narrow side and steers exactly one input straight through to the single read port wire on the right. Follow the highlighted path: only the addressed row reaches the output.

Step 5 — Writing: route ONE wire back into ONE row (the decoder)

WHAT. Writing is reading in reverse: one incoming value must land in exactly one chosen row. We take the destination address, feed it into a decoder, and the decoder lights up one of its $2^k$ output lines. We AND that line with a global WriteEnable; only the row whose line is high captures the data on the next clock tick.

WHY a decoder + enable? The write problem is "one wire → one of many rows", the mirror of the MUX. A decoder turns a $k$-bit address into $2^k$ lines with exactly one line hot — precisely the "pick which row gets written" signal. The AND-with-WriteEnable is the safety catch: no row changes unless we deliberately say "write now."

PICTURE. The $k$-bit write address enters a decoder (left). Of its $N$ output lines, exactly one (highlighted orange) is $1$. That line is ANDed with the teal WriteEnable and becomes the shared enable of that one register's cells from Step 2. The green data bus reaches all rows, but only the enabled row latches it.

Step 6 — Two read ports at once (replicate the MUX)

WHAT. A real instruction add rd, rs1, rs2 needs both source rows in the same cycle. One MUX gives us one row per cycle, so we build a second independent MUX reading the same grid of cell-outputs, steered by a second address. Now rs1 and rs2 come out together.

WHY replicate, why not reuse? A single MUX can only put one row on its output per cycle — reusing it would serialise the two reads into two cycles, killing single-cycle execution. Two ports means two separate selection paths off the same stored bits. The stored boxes are shared; only the read machinery is duplicated. This is what "$R=2$ read ports" physically means.

PICTURE. The same grid, now with two trapezoid MUXes hanging off it — the burnt-orange one steered by address A gives read port 1, the teal one steered by address B gives read port 2. Both draw from the identical cell outputs at once.

$\underset{\text{read ports}}{\underbrace{R}}=2,\underset{\text{write ports}}{\underbrace{W}}=1⟹\text{two MUXes, one decoder}$

$R$ = number of independent read MUXes; $W$ = number of independent write decoders. The 2-and-1 combo is exactly the shape of a 2-operand ALU op.

Step 7 — Why ports cost the SQUARE (the wiring picture)

WHAT. Now the punchline. Each read port lays wires across every cell (to reach whichever row it selects), and each write port does too. So the wires crossing one cell grow with $(R+W)$. But adding a port also fattens each cell — it needs more word-lines (horizontal) and more bit-lines (vertical) — so both the height and the width of every cell grow with $(R+W)$. Area is height $\times$ width, so it grows as $(R+W)\times (R+W)$.

WHY this matters. This square law is the reason register files stay small and few-ported. It is not a scary formula — it is just "both the height and the width of a cell stretch with ports."

PICTURE. One cell drawn twice: left with $R=2,W=1$ (thin), right with $R=4,W=2$ (fat in both directions). Horizontal word-lines and vertical bit-lines are counted so you can see height $\propto (R+W)$ and width $\propto (R+W)$.

Step 8 — The degenerate row: R0 hardwired to zero

WHAT. For one special row — register $0$ — we build no flip-flops at all. Its read-MUX input is simply tied to constant $0$, and its decoder write-line is left disconnected so writes vanish.

WHY this edge case? It costs nothing (a wire tied low is free) yet gives every program a permanent source of the constant $0$. That collapses several instructions into the ALU you already have: mov rd, rs becomes add rd, rs, r0; nop becomes add r0, r0, r0. The degenerate row is a feature, not a gap.

PICTURE. The R0 row drawn with its boxes greyed/removed; its MUX line pinned to $0$, its write-enable line cut. Compare to a normal row beside it.

The one-picture summary

Everything above, compressed: the shared grid of cells in the middle; two read MUXes (steered by source addresses A, B) pulling operands out to the ALU; one decoder + WriteEnable routing the ALU result back into the destination row; R0 tied low. Trace green = write path, orange/teal = read paths, plum = address/steering.

Connections

• Register file organization — this page is the from-zero derivation of that note's result.
• Multiplexers and Decoders — Steps 4 and 5 are exactly these two blocks.
• Datapath and ALU — Step 9 shows the read ports feeding, and write port draining, the ALU.
• Pipeline Hazards — the same-cycle read/write case hinted at in Step 6.
• Memory Hierarchy — this grid is the fastest tier of storage.
• RISC vs CISC — R0 tricks (Step 8) are a RISC hallmark.
• Yeh note Hinglish mein padho →