Abstract

Widening the issue width of an out-of-order processor, from four to six or eight instructions per cycle, requires proportionally more register file read and write ports to feed the execution units. Register file ports are expensive: each port adds wiring, area, and access latency, and a fully-ported multi-read, multi-write SRAM cell is significantly larger than a single-port cell. The tension between issue width and register file cost has become one of the binding constraints on superscalar scaling at sub-5nm nodes, where wiring density is often the bottleneck rather than transistor count. This post examines how banking, port-sharing, and renaming pool sizing interact to shape the practical limits of wide-issue designs in contemporary server and high-performance client CPUs.

Port Count and the Quadratic Cost Problem

An integer register file serving N execution units with read-before-execute scheduling needs at least 2N read ports (two source operands per instruction) and N write ports per cycle. A monolithic SRAM implementation at 8-issue needs 16 read and 8 write ports. The cell area of a multi-port SRAM grows roughly as the square of the port count because the bitline and wordline wiring must accommodate all ports simultaneously. Apple’s Firestorm microarchitecture, with its reported 8-wide decode and large physical register file (estimated at 360+ integer PRF entries by Anandtech’s analysis), handles this by running the register file as a banked structure where instructions are routed to a bank based on their destination register number, reducing the per-bank port count. AMD’s Zen 4 takes a similar approach, splitting the integer and floating-point register files into separate structures and staggering read access across pipeline stages to reduce instantaneous port demand.

Register Renaming Pool Sizing

The physical register file (PRF) must hold all in-flight speculative values plus the committed architectural state. For an 8-wide machine with a 320-entry reorder buffer (as in Intel’s Raptor Lake), the PRF needs enough entries to cover the maximum number of instructions in flight. Undersizing the PRF relative to the ROB creates a structural stall called a PRF full stall, where the rename stage cannot allocate a new physical register even though the ROB has space. Oversizing the PRF wastes area and increases access latency. The practical equilibrium for wide-issue server designs in 2025 sits around 280-400 integer physical registers and 350-512 vector/FP registers, with the vector file often larger because SIMD instructions hold wider data and the vector execution units are typically more latency-tolerant.

Port Sharing via Read-After-Write Forwarding

One technique for reducing port pressure is operand forwarding through the bypass network rather than the register file. If a producer instruction is in the same dispatch group as its consumer, the result can be forwarded directly from the execution unit output to the consumer’s input without a register file read. Intel’s Tremont and Raptor Cove cores both implement aggressive forwarding networks for this reason. The tradeoff is that forwarding logic adds wiring complexity and the bypass network itself has an area cost that scales with issue width. At 8-wide issue, the bypass network connecting all execution unit outputs to all inputs becomes a significant wiring burden, and some designs choose to accept an additional cycle of latency for non-forwarded register reads rather than fully-connect the bypass.

Implications for RISC-V Wide-Issue Designs

The open-source RISC-V ecosystem has produced several wide-issue OoO cores, including BOOM v3 from Berkeley and the NaxRiscv core from SpinalHDL. Both expose parameterizable issue width and PRF size, making them useful research vehicles for studying these tradeoffs. BOOM v3 at 4-wide issue already shows PRF full stall rates of 5-12% on SPEC CPU2017 integer workloads at default PRF sizing, a datapoint that illustrates how quickly the constraint bites as width increases. Proprietary commercial designs address this with custom memory compilers tuned to their specific foundry node, an advantage that open-source research cores cannot yet replicate.