~/projects/ooo-cpu

← all projects

OoO RISC-V CPU

A 2-wide superscalar, out-of-order RISC-V core in SystemVerilog, built in the style of the MIPS R10K. EECS 472 team project with Niki Lin, Shaoqian Zhou, and Sophia Chen.

  • SystemVerilog
  • RISC-V
  • R10K
  • EECS 472
github (private) slide deck
2-wide
superscalar
32
ROB entries
16
RS entries
~1.0
target CPI

The problem

In a simple in-order pipeline, one slow load (like a cache miss) stalls every instruction behind it, even ones that don't depend on it. An out-of-order core runs ready instructions early and commits them in program order, so the program still behaves correctly.

in-order 11 cycles lw x1, 0(x9) add x2, x1, x3 mul x4, x5, x6 sub x7, x8, x6 out-of-order 9 cycles lw x1, 0(x9) add x2, x1, x3 mul x4, x5, x6 sub x7, x8, x6 cache miss executing stalled
One load misses in the cache. In order, the independent mul and sub stall behind it. Out of order, they run during the miss and the program finishes 2 cycles sooner.

Architecture

The core is split into a front end that fetches and decodes, a middle that renames registers and tracks instructions, and a back end that executes them and commits results in order.

front end Fetch I-cache, BTB Decode RISC-V decoder middle Dispatch rename, ROB alloc Issue reservation stns back end Execute ALU x2, MULT, LSQ Complete CDB broadcast Retire commit from ROB wakeup via CDB
Instructions flow down each column, left to right. Finished results are broadcast on the common data bus (CDB), which wakes up instructions waiting in the reservation stations.

Key features

  • Register renaming with a map table and free list, R10K-style
  • Reorder buffer (ROB) for in-order commit and precise exceptions
  • Reservation stations that issue instructions as soon as their operands are ready
  • Branch prediction with a BTB, and recovery on a mispredict
  • Load/store queue for memory ordering

My role

I designed and verified the reorder buffer and the rename logic, and helped integrate the middle of the core with the front and back ends.

Process

We agreed on interfaces first, then built each module in small, tested pieces and integrated them one feature at a time. The goal was a working core by Oct 29 and the full CPU by Nov 20.