Pipelined RV32I RISC-V Core

System Overview

This is the culmination (PD5) of an incremental course project that builds a RISC-V processor across successive deliverables. It reuses the datapath blocks proven in the single-cycle design and transforms them into a genuine five-stage pipeline. The essential new engineering is not the arithmetic or decoding — those are inherited — but the machinery that makes a pipeline behave correctly under hazards: the pipeline registers that decouple the stages, the forwarding network that resolves most data dependencies with no penalty, the stall logic for the dependencies forwarding cannot cover, and the flush logic that discards wrongly-fetched instructions after control-flow changes.

Three classes of hazard can corrupt results in a pipeline. Structural hazards are avoided by design (separate instruction/data memory ports, and a register file that writes and reads in the same cycle). Data hazards are resolved by forwarding, with stalls for the rest. Control hazards are handled by fetching sequentially and flushing on taken branches and jumps.

Architecture — Five-Stage Datapath

The top-level pd5 module wires together the five stages, the two memory instances, the register file, the four pipeline registers, and the hazard unit. Solid paths are the normal per-cycle dataflow; the dashed feedback paths are forwarding from the EX/MEM (MX) and MEM/WB (WX) pipeline registers back into Execute.

1. 1
   IF — Instruction Fetch PC in a reset-initialised register (0x01000000); advances by 4, holds during a stall, or loads a branch/jump target. Instruction word read from a read-only imem instance.
2. 2
   ID — Decode, Immediate & Control decode splits the fields, igen assembles the sign-extended immediate (I/S/B/U/J), and a combinational control decoder drives the datapath — with safe defaults so unknown opcodes are inert.
3. 3
   EX — Execute The ALU runs the full RV32I repertoire and computes effective / branch / jump targets; branch_control produces equal and less-than flags that resolve each branch type. Forwarded operands feed both the ALU and the comparator.
4. 4
   MEM — Memory Access Byte-addressable with byte/half/word accesses by funct3 — combinational reads with sign/zero extension (lb/lh vs lbu/lhu), synchronous size-aware writes (sb/sh/sw).
5. 5
   WB — Write-Back A two-bit wbsel commits the ALU result (00), loaded data (01) or the return address PC+4 (10). A second instance of the block computes the next-PC target for Fetch.

Instruction Set — RV32I Formats

All instructions are 32 bits wide and fall into six encoding formats distinguished by how the immediate is assembled. The opcode occupies the low seven bits in every format.

The ALU implements the full arithmetic, logic, shift and comparison repertoire, plus the upper-immediate operations:

Pipeline Registers

All four inter-stage registers live in one pipeline_registers module. Each latches the data and control its downstream stage needs, supports stalling via a write-enable, and resets to a defined idle state; the two front-end registers (IF/ID, ID/EX) additionally support flushing.

A flush inserts a bubble — a benign no-op. In IF/ID a flush loads the canonical NOP encoding in place of the fetched instruction; in ID/EX it clears the memory and branch control signals so the squashed instruction touches nothing:

// IF/ID flush loads the canonical NOP:
0x00000013   // addi x0, x0, 0  →  decodes to a harmless no-op
// ID/EX flush clears memren / memwren / branch controls
// so the bubbled instruction cannot access memory or alter control flow

Hazard Handling

The hazard unit is the defining contribution of this deliverable. It observes the register indices and control signals across ID, EX, MEM and WB and drives three families of output: forwarding selects, stall/write-enable signals, and flush signals.

Most data dependencies are resolved without any stall by forwarding a result from a later pipeline stage straight into Execute, before it is written back. Each source operand has a 3:1 select — and crucially, the forwarded operands feed both the ALU and the branch comparator, so branches that depend on a just-computed value compare against the correct data.

1. MX
   EX/MEM → EX forward Routes the ALU result waiting in EX/MEM back into Execute — covers a dependency on the immediately preceding instruction.
2. WX
   MEM/WB → EX forward Routes the writeback-selected value in MEM/WB back into Execute — covers a dependency on the instruction two ahead. MX wins when both match.
3. LU
   Load–use stall A load's data isn't ready until end of MEM — one cycle too late. Freeze PC & IF/ID, bubble ID/EX one cycle; the dependency then becomes an ordinary forward.
4. WD
   Write–decode stall A combinational ID read of a register being written synchronously in WB could see the stale value; stall one cycle so the updated value is read next cycle.
5. CF
   Control-flow flush On a taken branch or jal/jalr in EX, squash the two speculatively-fetched instructions to bubbles and load the computed target into the PC. Suppressed while stalling.
6. WM
   Store-data forward For a load immediately followed by a store of the same register, substitute the WB data for the store data before it reaches memory (resolved in top-level wiring).

Pipeline in Action

Two cycle-by-cycle views of hazards resolving. In the first, back-to-back dependent instructions proceed with zero penalty thanks to forwarding, while a load–use dependency costs exactly one bubble.

In the second, a taken branch is resolved in Execute (c3). The two instructions already fetched onto the wrong path are squashed to bubbles, and the correct target is fetched from the next cycle.

Verification

The design was developed and verified on Linux, driven entirely from bash. The primary simulator was ModelSim (Intel FPGA / Quartus), with Verilator as an open-source alternative; waveforms were captured as VCD and inspected in gtkwave. Verification is anchored on probe signals exposed at every stage, compared each cycle against a golden reference so any mismatch pinpoints the exact diverging cycle and signal.

make compile -C verif/scripts/ VSIM=1
make run     -C verif/scripts/ VSIM=1 TEST=<name>
make run     -C verif/scripts/ VSIM=1 TEST=<name> PATTERN_CHECK=1
# a correct design reports "Checks passed"

Because the benchmarks are self-contained programs, the top level watches the instruction stream for termination:

ecall  0x00000073   // ends the simulation immediately
ret    0x00008067   // function test: end once x2 (sp) unwinds to top of memory

Results & Future Work

PD5 passes the complete verification suite. Waveform inspection confirmed the intended behaviour: forwarded operands arrive at Execute the same cycle they are needed; load–use and write–decode dependencies each cost exactly one bubble; and taken branches and jumps redirect the PC with the two mis-fetched instructions cleanly squashed.