Skip to content

Commit d80dd1e

Browse files
Update README.md
1 parent 5a2cbeb commit d80dd1e

1 file changed

Lines changed: 2 additions & 4 deletions

File tree

README.md

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2,11 +2,9 @@
22

33
A 6-stage pipelined RISC-V processor implementing the RV32IM instruction set in SystemVerilog, deployed on a Digilent Basys 3 FPGA (Xilinx Artix-7 XC7A35T) with clean timing closure at **100 MHz**.
44

5-
I started this project with the standard Patterson & Hennessy 5-stage pipeline running the base RV32I instruction set. It worked, hit about 91 MHz on the Artix-7, and passed the official riscv-tests compliance suite. But I wanted to push it further, so I started adding what real embedded cores actually have: hardware multiply/divide (the full RV32M extension), M-mode privileged architecture with CSR access and trap handling, a gshare branch predictor with a BTB and return address stack, and hardware performance counters that let software measure its own IPC.
5+
The design began as a 5-stage RV32I pipeline running at 91 MHz. However, after extending the ISA with hardware multiply/divide, M-mode privileged CSRs, trap handling, and a gshare branch predictor, the execute stage became the critical bottleneck, accumulating 19 logic levels and a 15.5 ns combinational path that resulted in a WNS of -5.539 ns, effectively capping the design at 64 MHz. To resolve this, I split the execute stage into separate forwarding (EX1) and computation (EX2) stages, which reduced the critical path to 7 logic levels and achieved clean timing closure at 100 MHz. As a consequence, the deeper pipeline increases the branch misprediction penalty from 2 to 3 cycles; nevertheless, the gshare predictor with BTB and return address stack mitigates this sufficiently that the 56% frequency improvement far outweighs the added latency.
66

7-
The problem was that all of these features converge in the execute stage. After adding them, the critical path blew up to 19 logic levels and 15.5 ns through the forwarding mux, ALU carry chain, and branch resolution logic. Timing failed at -5.539 ns, capping the design at roughly 64 MHz. I could have accepted that, but 36% of every clock cycle being dead time wasn't something I was willing to ship. So I split the execute stage into EX1 (forwarding and operand selection) and EX2 (ALU, branch, MDU, CSR), following the same approach that cores like ARM Cortex-M4 and RISC-V Ibex use when they need to hit higher frequencies. That brought the critical path down to 7 logic levels at 9.87 ns and closed timing at 100 MHz with +0.135 ns of positive slack.
8-
9-
The tradeoff is a deeper pipeline: mispredictions now cost 3 cycles instead of 2. But the gshare predictor with BTB and RAS absorbs most of that penalty, and the 56% frequency gain more than compensates. The full design supports all 48 RV32IM instructions, runs C programs compiled with a standard RISC-V GCC toolchain over UART, and has been validated through a 24-point comprehensive test suite, the 37-test riscv-tests compliance suite, and deployment on real hardware.
7+
In addition to the pipeline restructuring, the processor supports all 48 RV32IM instructions, includes 64-bit hardware performance counters for cycle-accurate IPC measurement, and runs bare-metal C programs compiled with a standard RISC-V GCC toolchain with output over UART. The design has been validated through a 24-point comprehensive test suite, the 37-test riscv-tests ISA compliance suite, and deployment on physical hardware.
108

119
**Author:** Devansh Joshi
1210

0 commit comments

Comments
 (0)