I hope, everyone of you have gone through the previous part of the RISC-V CPU Development blog series, where we talked about the design of Decode Unit (DU) of Pequeno. If not, please go through it before moving ahead.

In this blog, we will design the Register File of Pequeno.

Register File

In RISC-V CPUs, the register file is a critical component that consists of a set of general purpose registers used for data storage during execution. Pequeno CPU has 32 general-purpose registers of size 32-bit (x0–x31).

• The register x0 is called zero register. It is hard wired to a constant value 0, providing a useful default value which can be used with other instructions. Say, you want to initialize another register to 0. It is as simple as mv x1, x0.
• x1-x31 are general purpose registers to hold intermediate data, addresses, and results of arithmetic or logic operations.

Interfaces

In the CPU’s architecture, which we designed in Part-2, Register File requires two access interfaces.

Read Access Interface	For read access from Decode Unit (DU) The read data is sent to Execution Unit (EXU)
Write Access Interface	For writeback from WriteBack Unit (WBU)

Register File – Interfaces

Read Access Interface

This interface is used to read the register at the address sent by DU. Some instructions for e.g., ADD, require two source register operands rs1, rs2. Therefore, two read ports are required at Read Access I/F, to read two registers simultaneously. The read access should be single-cycle access so that the read data is sent to EXU along with the payload of DU in the same clock cycle. The read data and the DU payload are thus synchronized in the pipeline.

Write Access Interface

This interface is used to writeback the result of execution to the register at the address sent by the WBU. Only one destination register, rdt, is written at the end of execution. Hence, one write port is sufficient. The write access should be single-cycle access.

Stall and Flush Logic

Since DU and Register File are required to be in sync at the same stage of pipeline, they should stall together always (Why? Check the block diagram from the last part!). For example, if DU gets stalled, Register File should not pump out the read data to EXU, as it will corrupt the pipeline. Register File should also stall in this scenario. This is ensured by generating the read_enable to Register File by inverting the stall signal to DU. When stall is active, read_enable is driven low and the previous data is retained at the read data output, effectively stalling the Register File operation.

Since Register File doesn’t send any instruction packet to EXU, it doesn’t require any flushing logic. Flushing logic needs to be taken care only inside the DU.

Architecture

To summarize, Register File is designed with two independent read ports and one write port. Both read and write accesses are single-cycle. The read data is registered. The final architecture would look like:

Register File – Architecture

We have successfully designed the Register File of Pequeno! 🙂

GitHub Repo of Pequeno

All source codes are available for free in the GitHub repo of Pequeno. You can follow me in GitHub and add the repo to your favorites!

Find the repo here: pequeno_riscv

What’s next?

We have so far completed: Fetch Unit (FU), Decode Unit (DU), Register File. In the upcoming part, we will be designing the monster, the Execution Unit (EXU) of Pequeno.

Visit the complete blog series

This post is part of RISC-V CPU Development blog series 

<< Previous part |~~~~ J U M P ~~ T O ~~~~| Next part >>

Support

Leave a comment or visit support for any queries/feedback regarding the content of this blog.
If you liked Chipmunk , don’t forget to follow!:

Follow Chipmunk