RISC-V CPU with FPGA

03 Nov 2025 / 5 minutes to read / Categories: Featured, Academic

This project was built up over the course of 8 weeks for the module CG3207: Computer Architecture. This module went in depth into the design of a CPU, covering many key topics like its microarchitecture, advanced pipelining techniques, memory management, exception handling, and so on.

The final CPU design was the result of progressive lab assignments that culminated in a 5-stage pipelined RISC-V CPU supporting the RV32IM instruction set, with enhancements beyond these basic requirements being open-ended. The CPU was written in Verilog and implemented on a Nexys4 DDR FPGA board.

Overall Datapath

The diagram below shows the datapath for the 5-stage pipelined RISC-V CPU implemented (multiply/divide unit excluded). It supports the whole RV32IM instruction set with a fully functional hazard unit capable of resolving all data and control hazards.

Vectored Interrupt Handling

A simplified implementation of the typical RISC-V vectored interrupt handling mechanism was included in the design.

The user can write a trap handler vector table in their assembly program, then load the base address of this into the mtvec register. Then, the interrupt enable bit in the mstatus register must be set high, as well as the specific interrupt requests to enable in the mie register. To simplify things, exceptions and interrupts were handled in the same register, although proper RISC-V implementation would require separate handling.

For the exception handlers, which trigger during bad memory accesses, an LED is turned on and hangs the program in an infinite loop. For the interrupt handlers, the program added one to the seven segment display value and returns to the main program.

1
la t0, trap_vector_base
2
csrw mtvec, t0        # set base address of vector table to mtvec
3

4
csrr t0, mstatus
5
ori  t0, t0, 0x8      # set MIE bit (bit 3)
6
csrw mstatus, t0      # enable interrupts globally
7

8
li t0, 0x27           # 0b00100111 only enable DMEM & IROM exception, timer1 & pb0 interrupt
9
csrw mie, t0          # group exceptions and interrupts into mie register for simplified implementation
10

11
trap_vector_base:     # these are the exceptions/interrupts implemented
12
  j DMEM_bad_exception  # mcause == 0
13
  j IROM_bad_exception  # mcause == 1
14
  j timer1_handler    # mcause == 2
15
  j timer2_handler    # mcause == 3
16
  j timer3_handler    # mcause == 4
17
  j pb0_handler       # mcause == 5
18
  j pb1_handler       # mcause == 6
19
  j pb2_handler       # mcause == 7
20

21
DMEM_bad_exception:
22
  li s0, MMIO_BASE
23
  addi s1, s0, LED_OFF
24
  li s2, 0x1
25
  sw s2, (s1)           # activate LED via MMIO to indicate bad memory access
26
  j DMEM_bad_exception  # hang program here on bad memory address
27

28
timer1_handler:
29
  li s0, MMIO_BASE
30
  addi s1, s0, SEVENSEG_OFF
31
  lw t0, (s1)
32
  addi t0, t0, 1
33
  sw t0, (s1)         # add 1 to seven segment display whenever timer1 interrupt occurs
34
  mret                # return from interrupt

On the hardware end, interrupts trigger rising edges on the IRQ wire vector. This is compared to the mstatus and mie registers, which determine if the interrupt should be taken or not.

To handle multiple simultaneous interrupts, priority is given to the interrupt with lowest significance in the IRQ vector (i.e. exceptions, timer, then pushbutton) The highest priority interrupt’s value is written into the mcause register.

If the interrupt is taken, the current PC is saved into the mepc register, and the PC is set to the address in mtvec + 4 * mcause, which runs the interrupt handler. If an mret command is executed, the PC is restored from the mepc register, and the interrupt is cleared.