Registers and Register Files

A register is a group of n D flip-flops that share a common clock signal and a common write-enable signal, together storing one n-bit value as an atomic unit. Each flip-flop stores exactly one bit; tying their clock inputs together makes all n bits update on the same clock edge, so the register behaves as a single indivisible storage cell for a word (commonly 8, 16, 32, or 64 bits). A write-enable line, `WE`, gates whether the incoming data is actually loaded on the next active edge, or whether the register instead holds its previous value — this is what lets a register be read every cycle but written only when the datapath actually intends to update it. A register file generalizes this idea from one register to an array of registers, addressed like a tiny memory. Concretely, a register file with $2^k$ registers of width $n$ bits provides: a $k$-bit read address (or several) that a decoder and multiplexer combination uses to select which register's contents appear on an output bus; and a $k$-bit write address together with write data and a write-enable, gated by a decoder so that only the addressed register's flip-flops latch new data on the clock edge. The number of independent read and write addresses a design supports is called its port count — a "2-read, 1-write" (2R1W) register file, the classic configuration for a simple RISC datapath, can supply two different register values combinationally in the same cycle that a third register is being written. The crucial asymmetry to internalize is that reads are combinational and writes are clocked. Reading register file address `rs` just routes the stored bits of register `rs` through a multiplexer to an output bus — no clock edge is needed, the value simply becomes available after some propagation delay, exactly like reading any combinational circuit. Writing, by contrast, must respect the clock: new data is only committed to flip-flops on the active clock edge, and only into the register selected by the write-address decoder with write-enable asserted. This separation is what allows a single-cycle datapath to read two operands, compute with the ALU, and write back a result all within one clock period — the reads happen "instantly" (within propagation delay) while only one clocked event, the write, occurs per cycle.

Building one register from flip-flops

Take n positive-edge-triggered D flip-flops. Tie all their clock inputs to the same clock signal `CLK`. Feed bit i of the input word into the D input of flip-flop i, and take bit i of the output word from the Q output of flip-flop i. To make the register only load when desired, insert a 2-to-1 multiplexer in front of each D input: one input is the new data bit, the other is the flip-flop's own current output (a feedback loop), and the multiplexer's select line is the shared `WE` signal. ``` for i in 0 .. n-1: mux_out[i] = WE ? data_in[i] : Q[i] // hold value unless WE=1 D[i] = mux_out[i] on rising edge of CLK: Q[i] <- D[i] data_out = Q[0..n-1] ``` When `WE = 0`, every flip-flop's D input is wired back to its own Q, so the clock edge re-latches the same value — the register appears to "hold." When `WE = 1`, the clock edge loads `data_in`. This is exactly the mechanism used for the program counter, pipeline latches, and every individual architectural register.

Building the register file

Now stack $R = 2^k$ such registers, numbered $0$ to $R-1$, and add addressing hardware.

Write side. A $k$-to-$R$ decoder takes the write address `WA` and produces $R$ one-hot lines. Each line is ANDed with the global `WriteEnable` signal to form a per-register write-enable `we[j]`. All $R$ registers see the same `WriteData` bus, but only the one register whose `we[j] = 1` actually loads it on the clock edge.

Read side. For each read port, a $k$-to-1 (implemented as a tree of 2-to-1 stages, or directly as an $R$-to-1) multiplexer takes all $R$ registers' output buses as its data inputs and the read address as its select, producing one $n$-bit output. A 2-read-port file duplicates this multiplexer twice, with independent addresses `RA1` and `RA2`, so two different registers (or the same one) can be read out simultaneously. ``` // Parameters: R = number of registers, n = bits per register, k = log2(R) function register_file_read(RA): // purely combinational return REG[RA] // conceptually: R-to-1 mux selects REG[RA] function register_file_write(WA, WriteData, WriteEnable, CLK): decoder_lines = one_hot(WA) // k-to-R decoder: R bits, exactly one = 1 for j in 0 .. R-1: we[j] = decoder_lines[j] AND WriteEnable // only REG[j] with we[j] = 1 updates on the clock edge on rising edge of CLK: if we[j] == 1: REG[j] <- WriteData else: REG[j] <- REG[j] // hold // Per-cycle datapath usage, e.g. for `add rd, rs, rt`: A = register_file_read(rs) B = register_file_read(rt) Result = ALU_add(A, B) register_file_write(rd, Result, WriteEnable=1, CLK) ``` A subtlety worth stating precisely: register 0 is often hardwired to the constant zero in many instruction sets (this is a convention of the ISA, not an inherent property of the hardware). This is implemented by simply forcing `we[0] = 0` unconditionally (writes to register 0 are silently discarded) and forcing the read multiplexer to output all-zero bits whenever the read address equals 0, bypassing the stored flip-flops entirely. Another subtlety is same-cycle read-after-write. If an instruction writes register `rd` and the same cycle's read address happens to equal `rd`, does the read see the old or new value? In the design above, the read multiplexer samples `REG[j]` combinationally, and `REG[j]` only updates after the clock edge — so a read in the same cycle as a write to the same register sees the old value, unless the register file is deliberately built with "write-before-read" bypass logic (an internal forwarding path) that compares `WA` to `RA` and forwards `WriteData` directly to the read output when they match. Real processors sometimes add this bypass to simplify pipeline hazard handling; MIPS-style textbook datapaths typically model it explicitly as a design choice.

Space. A register file with $R$ registers of width $n$ bits requires $R \cdot n$ flip-flops for storage, each flip-flop itself built from a constant number of gates (a master–slave pair, roughly on the order of 20 transistors for a standard-cell D flip-flop). The write decoder is $O(R)$ gates (a $k$-to-$R$ decoder built from AND gates over $k = \log_2 R$ address lines and their complements). Each read port's multiplexer requires $O(R)$ gates when built as a tree of 2-to-1 stages, each stage handling one address bit, so $P$ read ports cost $O(P \cdot R)$ multiplexer gates. Total hardware is therefore

which for realistic values (e.g., $R = 32$, $n = 32$, $P = 2$) is dominated by the $R \cdot n = 1024$ flip-flops, with the addressing logic a much smaller additive term.

Time. A read is purely combinational: its delay is the depth of the read multiplexer tree, $O(\log R)$ multiplexer stages (each a constant-delay 2-to-1 mux), plus the flip-flop's clock-to-Q propagation delay for the winning register's stored bit to become valid at all. So read latency is

A write is bounded by the requirement that write data must be stable, and the decoder's one-hot select line must be stable, before the setup-time window preceding the clock edge; the decoder itself is $O(\log R)$ deep (address bits fan into AND gates), so the write-enable path must satisfy

Both are logarithmic in the number of registers, not linear, precisely because decoders and mux trees are built as balanced binary trees over the $k = \log_2 R$ address bits rather than as a linear scan — this is the same structural idea used in Multiplexers and Decoders generally, applied here to selecting among many storage words instead of many data lines.

Correctness argument. The invariant that must hold at every clock edge is: exactly one register (or none) is written, and every register not addressed for writing retains its previous value. This follows from three facts about the design. First, the write decoder produces a one-hot output for any valid address — exactly one of its $R$ output lines is 1 — because a decoder is built so that output line $j$ is the AND of the address bits (or their complements) matching the binary representation of $j$; only one $j$ can match a given address pattern. Second, each register's write-enable is the AND of its decoder line and the global `WriteEnable`, so at most one register has `we[j] = 1` on any cycle, and if `WriteEnable = 0`, no register has `we[j] = 1`. Third, each flip-flop's own hold-vs-load multiplexer guarantees that when `we[j] = 0` for that register, its D input is wired to its own Q output, so the clock edge re-writes the identical value — the register is unaffected in any externally observable sense. Together these three facts guarantee at most one register changes value per cycle, and it changes to exactly `WriteData` — matching the architectural semantics of "write register `rd`" in an instruction set.

Tradeoffs. More read/write ports increase bandwidth (useful for superscalar issue of multiple instructions per cycle) but each additional port adds an entire multiplexer tree (for reads) or an entire decoder-and-write-bus (for writes), so area and the read/write critical path both grow roughly linearly with port count, and wire congestion in the physical layout grows faster still because every port's bus must reach every register. This is why register files with many ports (8+ read ports in wide superscalar designs) become a real bottleneck and are heavily optimized in industrial CPU design — sometimes split into replicated banks to trade area for reduced fanout.

Consider a small 8-register, 8-bit-wide register file (R = 8, n = 8, so k = 3 address bits), with register 0 hardwired to zero, executing this sequence: ``` 1: R1 <- 5 (write immediate 5 into R1) 2: R2 <- 3 (write immediate 3 into R2) 3: R3 <- R1 + R2 (read R1, read R2, write R3) 4: R1 <- R3 + R1 (read R3, read R1, write R1 -- same-cycle RAW test) ``` Trace of register contents and read/write activity, cycle by cycle (assume no bypass forwarding — reads see pre-edge values):

Step through cycle 4 carefully, since it is the instructive case. The instruction reads `RA1 = 3` (register R3, holding 8 from the previous cycle's write) and `RA2 = 1` (register R1, still holding 5, because the write that will change R1 has not happened yet). Both reads are combinational multiplexer outputs and complete well within the cycle, independent of any clock edge. The ALU computes $8 + 5 = 13$. Only then, on the clock's rising edge at the end of cycle 4, does the write decoder assert `we[1] = 1` (since `WA = 1`), loading `WriteData = 13` into R1's flip-flops; every other register's write-enable is 0, so R2 and R3 hold unchanged. This confirms the invariant argued above: at most one register changes per cycle, reads observe the state as of the start of the cycle, and the write commits atomically at the edge — exactly the behavior required for the datapath to compute correctly without needing to know, at read time, whether a later write in the same cycle will target the same register. If register 0 were addressed as `RA1` or `WA` at any point, the design forces the read output to 0 regardless of stored contents, and forces `we[0] = 0` regardless of the decoder or `WriteEnable`, so `R0 <- 7` (say) would silently be discarded — a deliberate ISA-level convention, not a hardware bug.

The register file as a discrete architectural structure emerged as computer designers separated "fast, small, addressable storage" from main memory, formalizing an idea implicit in the earliest stored-program machines. The conceptual root is the stored-program computer itself, whose accumulator and index registers were the ancestors of the modern general-purpose register file; the generalization to a uniform, addressable array of interchangeable registers — rather than a handful of special-purpose ones — became a defining feature of load-store architectures in the RISC era.

Every general-purpose CPU core — from embedded microcontrollers to superscalar server chips — contains a register file as the fastest tier of its memory hierarchy, sitting above L1 cache and main memory in both speed and proximity to the ALU. Compilers perform register allocation, deciding which program variables live in this small, fast array versus spilling to slower memory, precisely because register file capacity is limited and access is so much faster than a load or store. GPU architectures push register files to an extreme, with thousands of hardware threads each demanding private register space, making register file area and bank conflicts a first-order performance concern in GPU compiler design. Pipelined and out-of-order processors add extra read/write ports, renaming tables, and sometimes multiple physical copies of the register file to sustain the bandwidth that superscalar issue and speculative execution require. The same decoder-plus-multiplexer addressing pattern used here recurs throughout digital design — in cache tag arrays, in TLBs, and in the addressable state elements that a finite state machine's control unit reads and updates every cycle, making the register file a direct, load-bearing stepping stone toward understanding full processor control and datapath design.

Ask the tutor: How would you redesign this register file to add a third read port, and what does that cost in gates and delay?