Computer Architecture 2024 Fall
Our goal is to create a RISC-V CPU that prioritizes simplicity while assuming a foundational understanding of digital circuits and the C programming language among its readers. The CPU should strike a balance between simplicity and sophistication, and we intend to maximize its functionality. This project encompasses the following key aspects, which will be prominently featured in the technical report:
Ensure that you have a functioning GNU/Linux or macOS system with the necessary permissions to install software packages.
Please note that certain packages, such as Verilator, which are available in older Ubuntu distributions, may be too outdated to follow the instructions provided below.
sbt, short for Scala Build Tool, relies on Scala, a JVM (Java Virtual Machine) language that combines object-oriented and functional programming paradigms into a highly concise, logical, and exceptionally robust language. Therefore, before using sbt, you must ensure that a functional JVM is accessible in your environment.
Ensure that Homebrew is installed.
The version numberImage Not Showing Possible ReasonsLearn More →
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
11
is crucial; otherwise, you may encounter unexpected issues with sbt.
curl
step.
Another approach is to utilize Apptainer. See champ's node.
Chisel is a domain specific language (DSL) implemented using Scala's macro features. Therefore, all programming related to circuit logic must be implemented using the macro definitions provided in the Chisel library, rather than directly using Scala language keywords. Specifically, when you want to use a constant in a circuit, such as 12, and compare it with a circuit value, you cannot write if (value == 12)
but instead must write when(value === 12.U)
. Memorizing this fundamental concept is essential to correctly write valid Chisel code.
Chisel is not strictly an equivalent replacement for Verilog but rather a generator language. Hardware circuits written in Chisel need to be compiled into Verilog files and then synthesized into actual circuits through EDA (Electronic Design Automation) software. Furthermore, for the sake of generality, some features found in Verilog, such as negative-edge triggering and multi-clock simulation, are not fully supported or not supported at all in Chisel.
Let's explore a simple combinational logic example.
Unlike traditional execution models, the logic circuits associated with Chisel are continuously active, somewhat akin to continuous assignment in Verilog. However, Chisel takes a departure from Verilog's built-in logic gates and opts for expressions to define logic.
In the above example, we introduce "variables" a
and b
, which essentially serve as "named wires" due to their roles as inputs to the circuit. It is important to note that other wires within the circuit do not necessitate explicit names. While we have assumed one-bit-wide inputs and generated wires in this instance, these expressions can seamlessly adapt to wider wires, with Chisel's logic operators inherently operating in a "bitwise" manner. Furthermore, Chisel boasts a powerful wire width inference mechanism, enhancing its versatility and simplifying its use in designing complex logic circuits.
In the preceding example, the named wires a and b offer the advantage of reusability across multiple locations within the circuit. Likewise, it is possible to assign a name to the output of the circuit:
The keyword val
is derived from Scala and serves as a means to declare a program variable that can only be assigned once, essentially creating a constant. This approach allows for the generation of a single output value at a specific location within the circuit and subsequently distributes it to other locations where the same output is required.
Assigning names to wires and employing fanout mechanisms provide a means to reuse a single output value in multiple locations within the generated circuit.
Function abstraction enables us to reuse a circuit description effectively. Here is an example of a simple logic function:
In this case, the function inputs and output are specified with the type Bits. We will delve deeper into types shortly. When we use the XOR function elsewhere, we essentially create a duplicate of the corresponding logic. You can think of the function as a "constructor" for this logic.
Chisel datatypes are employed to define the type of values that reside in state elements or flow through wires. While hardware circuits fundamentally manipulate vectors of binary digits, employing more abstract representations for values enables clearer specifications and aids in the generation of more efficient circuits by the tools.
The basic types:
Types | meaning |
---|---|
Bits |
Raw collection of bits |
SInt |
Signed integer number |
UInt |
Unsigned integer number |
Bool |
Boolean |
All signed numbers are represented using 2's complement in Chisel. Chisel also provides support for several higher-order types, including Bundles
and Vecs
.
The unsigned integer type is UInt
, and the signed integer type is SInt
. When declaring integers, you can specify the bit width using .W
, for example, UInt(8.W)
. If you want to convert an integer from Scala to Chisel's hardware integer, you can use the .U
operator, for example, 12.U
. The .U
operator also supports specifying the bit width, for example, 12.U(8.W)
.
The boolean type is Bool
, and you can use .B
to convert Scala boolean values to hardware boolean values, for example, true.B
.
While it's useful to keep track of wire types, Scala's type inference allows you to omit type declarations when they are not necessary. For example, in our previous example:
the type of out
was deduced based on the types of a
and b
as well as the operators used. If you want to ensure type clarity or if there is insufficient context for the inference engine, you can always explicitly specify the type like this:
Additionally, as we will explore later, explicit type declaration becomes necessary in certain situations.
Chisel Bundles are used to represent groups of wires that have named fields. They function in a manner similar to C's struct
. In Chisel, Bundles are defined as a class, which is analogous to how classes are defined in languages like C++ and Java.
Chisel provides class methods for Bundles, which means that user-created bundles should "extend" the Bundle class to benefit from automatic connection creation (more on this later). In a Bundle, each field is assigned a name and defined using a constructor of the appropriate type, along with parameters that specify its width and direction. This allows you to create instances of FIFOInput, for example.
You can create nested Bundle definitions and construct hierarchies with them. These Bundles are typically used to define the interface of modules. The Bundle "flip" operator is employed to create an "opposite" Bundle concerning its direction.
Bundle and Vec are class types used for organizing and grouping other types. The Vec class, in particular, represents an array of objects of the same type that can be indexed:
Note: Vec is not a memory array; it functions as a collection of wires (or registers).
Both Vec and Bundle inherit from the class Data. Any object that ultimately inherits from Data can be represented as a bit vector in a hardware design.
Literals are values that you specify directly in your source code. Chisel provides type-specific constructors for defining literals.
By default, Chisel will determine the width of your literal to be the minimum necessary. Alternatively, you can provide a width value as a second argument if needed.
An error will be reported if the specified width value is insufficient.
A port refers to any Data object whose members have directions assigned to them. Port constructors enable the addition of directions during construction:
The direction of an object can also be set during instantiation:
The methods asInput
and asOutput
ensure that all components of the data object are set to the specified direction. There are also other methods available for tasks like reversing direction, among others.
Modules are employed to establish hierarchy within the generated circuit, resembling modules in Verilog. Each module defines a port interface and interconnects subcircuits. These module definitions are essentially class definitions that extend the Chisel Module class.
The Module slot io
is utilized to store the interface definition, which is of type Bundle. In the above example, io
is associated with an unnamed Bundle using the :=
assignment operator. This Chisel operator connects the input on the left-hand side to the output of the circuit on the right-hand side .
Each module implicitly includes clock and reset signals in addition to the declared I/O ports.
Combinational Logic:
The most basic type of state element that Chisel supports is a positive-edge-triggered register, which can be functionally instantiated as follows:
This circuit generates an output that replicates the input signal but with a one-clock-cycle delay. It is important to note that we do not need to explicitly specify the type of the register (Reg
) because Chisel automatically infers it from the input when instantiated in this manner. In Chisel, the clock and reset signals are global and are implicitly included where necessary.
Getting the Repository:
Before testing your system, ensure that you have sbt (the Scala build tool) installed.
When running for the first time, an internet connection is needed to automatically download necessary components. Reference output:
This will generate and test a basic block called Hello
that consistently produces the number 42
(represented as 0x2a
). You should observe [success]
in the final line of the output (from sbt
) and PASSED
on the preceding line, indicating that the block has successfully passed the test case.
Reference output:
source code:
src/main/scala/hello/Hello.scala
Then, you can run the examples:
source code:
src/main/scala/examples/FullAdder.scala
,src/main/scala/examples/Adder4.scala
source code:
src/main/scala/examples/SimpleALU.scala
Alternatively, you can go through all examples:
Take your hardware design to the next level, transitioning from instances to generators! This bootcamp will introduce you to Chisel, a hardware construction DSL developed at Berkeley and written in Scala. It will also provide you with a grasp of Scala as you progress, and it will focus on teaching Chisel through the concept of hardware generators.
Read the following materials: (required)
ucbbar/chisel-bootcamp
mentioned in Local Installation - Mac/Linux is only valid to x86-64 machines. Therefore, we have rebuilt the Docker image sysprog21/chisel-bootcamp
to address known issues and support both x86-64 and Arm64.
Make sure you have Docker installed on your system.
Alternatively, use nerdctl.
Run the following command: (for Linux and macOS + Docker Desktop)
For macOS users who have already installed lima and run limactl start
, you can run the command.
This will download a Dokcer image for the bootcamp and run it. The output will end in the following message:
Next, you can copy the URL provided above, which starts with http://127.0.0.1:8888/?
, and paste it into your web browser to access the Jupyter Notebook-based interactive computing platform.
See Local Installation - Mac/Linux
Single-cycle CPU completes the execution of one instruction within a single clock cycle. Because the clock cycle is fixed, all instructions must take the same amount of time to execute as the slowest instruction. This results in poor performance for a single-cycle CPU. A single-cycle CPU runs only one instruction at a time, and there are no conflicts between instructions, making it the simplest to implement.
The purpose of this experiment is to help everyone understand the basic structure of the CPU and how it executes instructions. We will first introduce some fundamental concepts, then proceed to build the data path and control unit step by step for instruction execution (there will be coding tasks to complete along the way, please remember to do so), ultimately constructing a simple single-cycle RISC-V processor, named MyCPU
.
Get the repository:
Please be aware that the Scala code in this repository is not entirely complete, as the instructor has omitted certain sections for students to work on independently.Image Not Showing Possible ReasonsLearn More →
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
To simulate and run tests for this project, execute the following commands under the ca2024-part3
directory.
Alternately, run
make
.
If you have successfully filled in the implementation with your own efforts, you should encounter the following messages:
Naturally, if you have not made any efforts to improve this implementation, all test cases will fail as shown below:
If you want to run a single test, such as running only InstructionDecoderTest
, execute the following command:
Full
Simplifed
The path through which data moves between functional units is known as the data path. The elements situated along this route that perform operations on or hold data are called data path components, which include the ALU (Arithmetic-Logic Unit), general-purpose registers, memory, and so on. The data path illustrates the various pathways through which data transitions from one component to another.
The processor employs synchronous logic design with a clock.
As the name implies, control signals govern the data path. Whenever a choice must be made, the control unit is responsible for making the correct decision and dispatching control signals to the relevant data path components. For instance, should the ALU perform addition or subtraction? Are we reading from or writing to memory?
So, how does the controller determine what action to take? This primarily relies on the instruction currently in execution. In the RISC-V instruction format, the controller discerns the appropriate decisions by examining the opcode, funct3, and funct7 fields of the instruction, thus emitting the correct control signals. In the CPU schematic, the Decoder, ALUControl, and JumpJudge components can all be regarded as constituents of the control unit. They receive instructions and generate control signals. These control signals serve as guides within the data path to ensure the precise execution of instructions.
In digital circuits, there are two main types of circuits: combinational logic and sequential logic. In CPU design, units composed of these two types of circuits are called combinational units and state units, respectively. In this experiment, only the registers belong to the sequential logic (memory is not within the scope of the CPU core), while the rest are combinational units.
The output depends only on the current input and does not require a clock as a triggering condition. Inputs are reflected immediately in the outputs (ignoring delay).
Combinational logic processes data during clock cycles:
These units store state and use the clock as a triggering condition. Inputs are reflected in the outputs when the clock's rising edge arrives.
Register with write control:
The RISC-V CPU we are designing can execute a core subset of RISC-V instructions (RV32I):
add
, sub
, slt
, etc.lb
, lw
, sb
, etc.beq
, jar
, etc.We will divide the instruction execution into five different stages:
Now, let's build data path components step by step according to the above stages, and then instantiate and connect these data path components in the CPU's top-level module. (The code related to this is located in the src/main/scala/riscv
directory.)
Code can be found in
src/main/scala/riscv/core/InstructionFetch.scala
.
What the instruction fetch stage does:
First, the value of the PC (program counter) register is initialized to the entry address of the program. When an instruction is valid, the current instruction pointed to by the PC is fetched. If a jump is required, the PC is directed to the jump address; otherwise, it is incremented to PC + 4
.
// part3(InstructionFetch)
comment section in src/main/scala/riscv/core/InstructionFetch.scala
so that it can pass the InstructionFetchTest
unit test.
The code is located in
src/main/scala/riscv/core/InstructionDecode.scala
.
What the decode stage does:
add
, read two registersaddi
, read one registerjal
, no reads are necessaryThe above code extracts the register operand numbers from the instruction. In all cases, except when the instruction is lui
, register 1 is set to register 0, and register 2 is set to the values from the rs1(19:15) and rs2(24:20) fields of the instruction, respectively.
The above code extracts immediate values. Since the position of immediate values varies for different instruction types, it is necessary to differentiate instruction types using the opcode and then extract the corresponding immediate value.
Taking ex_aluop1_source
control signal as an example, this control signal determines the input for the first operand of the ALU. It assigns a value to ex_aluop1_source
based on the opcode. When the instruction type is either auipc
, jal
, or B, ex_aluop1_source
is set to 0, controlling the ALU's first operand input to be the instruction address. In other cases, ex_aluop1_source
is set to 1, controlling the ALU's first operand input to be a register.
As you can see, the design of the decoding unit is also simple combinational logic. Knowing the mapping relationship between control signals and instructions is sufficient to complete it. Next, please complete the code for assigning values to the four control signals: ex_aluop2_source
, io.memory_read_enable
, io.memory_write_enable
, and io.wb_reg_write_source
.
control signals | meanings |
---|---|
ex_aluop2_source |
ALU Input Source Selection |
memory_read_enable |
Memory Read Enable |
memory_write_enable |
Memory Write Enable |
wb_reg_write_source |
Write-Back Data Source Selection |
// part3(InstructionDecode)
comment section in src/main/scala/riscv/core/InstructionDecode.scala
to make it pass the InstructionDecoderTest
unit test.
The code is located in
src/main/scala/riscv/core/Execute.scala
.
What the execution stage does:
The above code instantiates ALU and ALUControl within the Execute module. The specific ALU computation logic is implemented in the ALU module, and here, you only need to assign values to the input ports of ALU. The code for ALU can be found in src/main/scala/riscv/core/ALU.scala
.
// part3(Execute)
comment section in src/main/scala/riscv/core/Execute.scala
to make it pass the ExecuteTest
unit test.
The above code determines whether a jump should be taken. The logic for determining a jump is as follows: if it is an unconditional jump instruction, it jumps directly (e.g., jal
and jalr
instructions in the code above). If it is a branch instruction, it checks the corresponding jump condition to decide whether to jump (e.g., the beq
instruction in the code above, which jumps when io.reg1_data
is equal to io.reg2_data
). When a jump is taken, the control signal if_jump_flag
is set to 1.
The code is located in
src/main/scala/riscv/core/MemoryAccess.scala
.
Only load/store instructions have a memory access stage. The other instructions remain idle during this stage or skip it all together. In this stage, reading loads data from memory into registers, and writing stores data from registers into memory.
In the decode stage, if it is an L-type (I-type subtype) instruction, memory_read_enable
is set to 1, and if it is an S-type instruction, memory_write_enable
is set to 1. These two control signals determine whether reading or writing should occur in this stage.
First, the address for reading or writing memory is obtained.
When io.memory_read_enable
is true:
The code reads data from the memory bus and processes it differently based on the instruction type (e.g., lb
sign-extends, lbu
zero-extends, lh
reads two bytes, etc.). The processed data is then assigned to io.wb_memory_read_data
for writing back.
When io.memory_write_enable
is true:
The code writes data to memory, and the data is processed differently based on the instruction type (e.g., sw
takes 32 bits, sh
takes 16 bits, and sb
takes 8 bits).
The code is located in
src/main/scala/riscv/core/WriteBack.scala
.
In the write-back stage, the computed data or data read from memory is written into registers.
The write-back module is essentially a multiplexer, and the code is very simple. However, it raises an interesting question: the write-enable signal is generated in the decode stage, but at that point, the correct write-back data has not been calculated (or read from memory). So, will incorrect write-back data be written into the register file, and why?
The code is located in
src/main/scala/riscv/core/CPU.scala
.
We have implemented all the components required to build the CPU. Now, we need to instantiate and connect these components together according to the single-cycle CPU architecture diagram.
In the code above, we instantiate modules for various execution stages and then establish connections between them to create the CPU.
Please observe the input port code of the Execute module and the CPU architecture diagram, and fill in the connections between the inputs of the Execute module and the outputs of other modules.
// part3(CPU)
comment section in src/main/scala/riscv/core/CPU.scala
to make it pass the corresponding unit tests.
The process by which sbt test
activates the test cases for validating the CPU implementation relies on Chiseltest, an extensive testing and formal verification library designed for Chisel-based RTL (Register-Transfer Level) designs. Chiseltest places a strong emphasis on creating tests that are lightweight, promoting minimal boilerplate code, easy to read and write for enhanced understandability, and conducive to test code reuse through composability.
Provided a C program that computes the Fibonacci sequence, its source code is presented below.
File: csrc/fibonacci.c
Within the main
function, the line *((volatile int *) (4)) = fib(10)
stores the Fibonacci(10) result in the memory address 4
, which can be later verified using a Chiseltest-based test case.
File: src/test/scala/riscv/singlecycle/CPUTest.scala
Given that Fibonacci(10) is known to be 55
, this test case straightforwardly verifies the content of the designated memory region after our CPU executes the instructions.
Before burning the board for verification, you can perform another round of testing using waveform simulation.
Generating Waveform Files During Testing:
While running tests, if you set the environment variable WRITE_VCD
to 1, waveform files will be generated.
Afterward, you can find .vcd
files in various subdirectories under the test_run_dir
directory. You can open them using Surfer.
On the left side of the interface, there is a tree-like structure organized by modules. To add a signal to the window, right-click and select Insert
from the menu.
Verilator is a tool that compiles Verilog and SystemVerilog sources into highly optimized C++ or SystemC code, which can be used for verification and modeling in C++ or SystemC testbenches.
For more details, please refer to the official Verilator website and its manual.
Why do we choose Verilator? It is a high-performance, open-source Verilog/SystemVerilog simulator. While it is powerful and fast, it is not a direct replacement for event-based simulators such as Modelsim and Vivado Xsim. Verilator operates on a cycle-based simulation model, which means it does not simulate exact circuit timing within a single clock cycle and may not capture intra-period glitches. While this approach has its advantages, it also has limitations compared to other simulators.
If you want to quickly test your own written programs, you can use Verilator for simulation. The main simulation function is already written and located in verilog/verilator/sim_main.cpp
. After the first run and every time you modify the Chisel code, you need to execute the following command in the project's root directory to generate Verilog files:
If you don't modify the Scala code as mentioned earlier, the Verilog generation will fail.Image Not Showing Possible ReasonsLearn More →
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
After compilation, an executable file named verilog/verilator/obj_dir/VTop
will be generated. This executable file can take parameters to run different code files. Here are the parameters and their usage:
Parameter | Usage |
---|---|
-memory |
Specify the size of the simulation memory in words (4 bytes each). Example: -memory 4096 |
-instruction |
Specify the RISC-V program used to initialize the simulation memory. Example: `-instruction src/main/resources/hello |
.asmbin` | |
-signature |
Specify the memory range and destination file to output after simulation. Example: -signature 0x100 0x200 mem.txt |
-halt |
Specify the halt identifier address; writing 0xBABECAFE to this memory address stops the simulation.Example: -halt 0x8000 |
-vcd |
Specify the filename for saving the simulation waveform during the process; not specifying this parameter will not generate a waveform file. Example: -vcd dump.vcd |
-time |
Specify the maximum simulation time; note that time is twice the number of cycles. Example: -time 1000 |
For example, to load the hello.asmbin
file, simulate for 1000 cycles, and save the simulation waveform to the dump.vcd
file, you can run:
Keep in mind that a time value of 2000 corresponds to simulating 1000 cycles.Image Not Showing Possible ReasonsLearn More →
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Then, run gtkwave dump.vcd
to check its waveform.
You can observe that the signal io_instruction begins with 000000000
and 00001137
. In the meantime, let's verify the hexadecimal representation of hello.asmbin
:
Its output:
It aligns with the expected waveform.
This occurs because Chisel initially generates FIRRTL code and subsequently applies optimization steps, including logical simplification, constant propagation, and dead code elimination, to the FIRRTL code. The final Verilog code is then generated based on the optimized FIRRTL representation. If the modules/IO ports/registers you created in Chisel do not appear in the generated Verilog code, it is recommended to check for proper module connections and potential logic issues that could lead to constant values in certain registers, among other possible reasons.
If no specific argument is provided to the GNU toolchain, the default linker script is utilized for the linking process. However, for more granular control over the linking process, it is possible to create a custom linker script. You can designate a linker script using the -T
option, as demonstrated below:
The content of the linker script would look something like this:
File:
csrc/link.lds
The first line of the linker script specifies the output instruction format, which is RISC-V in this case. The second line specifies the program's entry address, which is the _start
function. Starting from the third line, it defines the positions of various segments in the program. For example, the .text
segment starts at address 0x00001000
, the .data
segment starts after .text
and is aligned to address 0x1000
, and the .bss
segment starts at address 0x00100000. The last line specifies the program's end address, denoted as _end
.
To regenerate the RISC-V programs utilized for unit tests, change to the csrc
directory and run the make update
command. Ensure that the $PATH
environment variable is correctly configured to include the GNU toolchain for RISC-V.
ELF (Executable and Linkable Format) is an executable file format commonly used in Linux systems. While a detailed understanding of the ELF format is not necessary, having a general idea of its structure can be helpful for this experiment.
An ELF file stores metadata about a program, including the entry address, segment information, symbol information, and more. Among these, segment information is crucial as it contains the program's code and data. Typically, the code segment is named .text
, and the data segment is named .data
. These segments are loaded into memory by the operating system for program execution and data access.
In our experiment, since we do not have an operating system, we use Chisel code to specify the CPU's entry address and load the code and data segments into memory for direct program execution. These code and data segments are flashed into the FPGA logic as initialization data during the synthesis phase. The InstructionROM
module is responsible for generating this initialization data, and the ROMLoader
module handles the loading of data into memory. After this data copying process is complete, the CPU can start executing the program.
The process of generating an executable file for the CPU involves the following steps:
0x1000
, with the space before it reserved for the program's stack.objcopy
tool is employed to duplicate the code and data segments into a distinct file, resulting in a file containing solely binary code and data.After completing the single-cycle CPU experiment, you have developed a processor that can execute instructions as expected. However, this simple CPU can only run continuously according to predefined program instructions and cannot be interrupted midway. In our uncertain world, a practical CPU must always be prepared to handle external events, process interrupts in a timely manner, and return to the original program to continue execution.
In this experiment, you will learn:
Whether using an IDE or executing commands, the root directory is the part2
directory.
From the preliminary knowledge on interrupts and exceptions, we have learned the basic concepts of CSR registers. In this experiment, we will extend the single-cycle CPU to support instructions that operate on CSR registers.
Details about the CSR-related instruction set, including instruction semantics and encoding, can be found in Chapter 9 of the Unprivileged ISA Specification. For the content and meaning of interrupt-related CSR registers, please refer to the Privilege ISA Specification.
Based on the experience of implementing a single-cycle CPU, we can break down the support for CSR instructions into the following:
RegisterFile
register group, with an address space of 4096 bytes. From the instruction manual, we can see that operations on CSR registers are atomic read-modify-write (RMW). The specific semantics of CSR instructions can be found in the manual. The CSR register set needs to address the internal registers, fetch their content, and modify them based on the control signals and CSR register addresses provided by the ID decoding module.In simple terms, the interrupt controller detects external interrupts. When an interrupt occurs and is enabled, it interrupts the CPU’s current execution flow, sets the appropriate CSR register information, and jumps to the interrupt handler to execute the interrupt service routine.
The key is determining what information to save into the corresponding CSR registers. The answer is the CPU state after executing the current instruction. For example, if the current instruction is a jump instruction, the mepc
register should save the jump target address of the current jump instruction.
Some special cases need to be considered. We know that external interrupt enablement is determined by the mstatus
register. If the current instruction modifies mstatus
to disable interrupts, and an external interrupt arrives during its execution, should the next cycle respond to the interrupt? For consistency, we consider that such a situation should not respond to the interrupt, and the CPU should complete the current instruction execution before jumping to the interrupt handler.
Responding to interrupts consists of two parts:
Save the CPU’s next state information in one cycle by writing the relevant content into the appropriate registers. Specifically:
mepc
: Saves the address from which the CPU will resume execution after completing the interrupt or exception handling.mcause
: Records the cause of the interrupt or exception. Details can be found in the Privilege ISA Specification.mstatus
: During interrupt handling, set the MPIE
bit in the mstatus
register to 0 to disable interrupts.Retrieve the interrupt handler’s address from the mtvec
register and jump to that address for further interrupt handling.
After handling the interrupt (mret
), the CPU execution flow needs to be restored. This process is similar to responding to interrupts, but the registers written are limited to mstatus
, and the target address for jumping is fetched from mepc
.
For simplicity, the value written into mstatus
during mret
sets the MIE
bit equal to the MPIE
bit. Thus, if MPIE
is 1, mret
will re-enable interrupts; if MPIE
is 0, mret
will not change the value of mstatus
. This design does not support interrupt nesting. When implementing privilege level switching in the future, changes to mstatus
will be more complex, but all standards are clearly defined in the manual. To explore the implementation of the interrupt mechanism further, refer to Section 3.1.6.1 of the Privilege ISA Specification.
Exception context saving and restoration are similar to interrupt handling, with slight differences in the content saved and restored. Students interested in exploring these differences can investigate further on their own.
There are many ways to implement CLINT. For simplicity, we use a pure combinational logic design for the interrupt controller (the main repository of MyCPU uses a state machine to implement CLINT).
Since the CLINT is based on a single-cycle CPU and uses combinational logic, it immediately responds to external interrupts when they occur.
CLINT requires the ability to modify the contents of multiple registers in one cycle. Normal CSR instructions, however, can only perform RMW operations on one register at a time. Therefore, there is an independent, higher-priority pathway between CLINT and the CSR module to quickly update CSR register values.
We will implement a MMIO-based timer interrupt generator.
MMIO (Memory-Mapped I/O) refers to peripherals that interact with the CPU using registers mapped into the memory address space. The CPU modifies the values of these registers using load/store instructions, enabling interaction with peripherals.
Without implementing a bus, MMIO can be achieved with multiplexers. This is because instruction fetch operations and load/store memory access operations are separated, allowing memory to have a dedicated pathway for instruction fetches. Therefore, our model involves a CPU interacting with multiple peripherals without conflicts between instruction fetch and memory access operations.
The logic address emitted by the CPU determines the target device based on the high bits of the address, while the low bits are used for internal device addressing.
Additionally, the timer interrupt generator includes two control registers:
false
, no interrupts are generated. This register is mapped to logical address 0x80000008
.0x80000004
. The interrupt generator contains an incrementing counter that triggers an interrupt signal when its value reaches the limit
(provided enable
is true). Note: The duration of the interrupt signal is less critical, but it must be at least one CPU clock cycle to ensure the CPU correctly captures the signal.CSR Instruction Semantics
csr
in the CSR register set.rd
.CSRRW (Atomic Read/Write CSR): Used to exchange values between a CSR register and a general-purpose register.
rd
is not register 0:
[csr]
to XLEN bits and write it to rd
, i.e., (rd) = (zero-extended)[csr]
[csr] = (rs1)
rd
is register 0:
[csr] = (rs1)
.CSRRS (Atomic Read and Set Bits in CSR): Used to read the value of a CSR register.
[csr]
to XLEN bits and write it to rd
, i.e., (rd) = (zero-extended)[csr]
.rs1
is not register 0:
[csr] = [csr] | (rs1)
.CSRRC (Atomic Read and Clear Bits in CSR)
[csr]
to XLEN bits and write it to rd
, i.e., (rd) = (zero-extended)[csr]
.rs1
is not register 0:
rs1
: [csr] = [csr] & ~(rs1)
.CSRRWI (Atomic Read/Write CSR Immediate)
rd
is not register 0:
[csr]
to XLEN bits and write it to rd
, i.e., (rd) = (zero-extended)[csr]
.[csr] = (zero-extended)(rs1)
.rd
is register 0:
[csr] = (zero-extended)(rs1)
.CSRRSI (Atomic Read and Set Bits in CSR Immediate): Used to read the value of a CSR register.
[csr]
to XLEN bits and write it to rd
, i.e., (rd) = (zero-extended)[csr]
.rs1
is not 0:
[csr] = [csr] | (zero-extended)(rs1)
.CSRRCI (Atomic Read and Clear Bits in CSR Immediate)
[csr]
to XLEN bits and write it to rd
, i.e., (rd) = (zero-extended)[csr]
.rs1
is not 0:
rs1
: [csr] = [csr] & ~(zero-extended)(rs1)
.MSTATUS register
Test Cases and Waveform Diagrams
Checking Interrupt Assertions and Handling:
interrupt_flag
to 1
:
interrupt_assert
is true
.interrupt_handler_address
equals the value of MTVEC
(previously set to 0x1144
).jump_flag
to false
:
MEPC
saves the value of PC + 4
, i.e., 0x1904
.MCAUSE
:
interrupt_flag = 1
, MCAUSE
should equal 0x80000007L
.MSTATUS
:
0x1880L
(sets MIE
from 1
to 0
, disabling interrupts).Waveform Image:
When encountering the mret
instruction:
interrupt_assert
should be true
.interrupt_handler_address
should equal the value of MEPC
, i.e., 0x1904
.MSTATUS
:
0x1888L
(sets MIE
from 0
to 1
, enabling interrupts).Testing Interrupts during a Jump:
Set interrupt_flag
to 2
:
interrupt_assert
is true
.interrupt_handler_address
equals the value of MTVEC
(previously set to 0x1144
).Set jump_flag
to true
:
MEPC
saves the value of jump_address
, i.e., 0x1990
.Check MCAUSE
:
interrupt_flag = 2
, MCAUSE
should equal 0x8000000BL
.Check MSTATUS
:
0x1880L
(sets MIE
from 1
to 0
, disabling interrupts).When encountering the mret
instruction:
interrupt_assert
should be true
.interrupt_handler_address
should equal the value of MEPC
, i.e., 0x1990
.MSTATUS
:
0x1888L
(sets MIE
from 0
to 1
, enabling interrupts).Testing Interrupts When Interrupts Are Disabled:
MSTATUS
to 0x1880
(interrupts disabled):
interrupt_flag = 1
, verify that interrupt_assert
is false
since interrupts are masked.Test Cases
0x990315
to memory address 0x4.U
(the memory space corresponding to the limit
register).
limit
register and check if it is 0x990315
.0
to memory address 0x8.U
(the memory space corresponding to the enabled
register).
enabled
register and check if it is false
.At 3ps, io_debug_limit
changes to 0x990315
, indicating that 0x4.U
(the memory space corresponding to the limit
register) was successfully written with 0x990315
.
At 7ps, io_debug_enabled
changes to 0
, indicating that 0x8.U
(the memory space corresponding to the enabled
register) was successfully written with 0
.
Test Cases
fibonacci.asmbin
to recursively calculate the 10th Fibonacci number. Verify that the result is 55
.quicksort.asmbin
to execute a quicksort operation. If successful, memory starting at address 4
should contain an array of length 10 with values ranging from 0
to 9
.sb.asmbin
to verify the correctness of register read and write functionality.simpletest.asmbin
to test the interrupt functionality.The following is an analysis of the fourth test: Jump to Trap Handler and Return
Based on the code in simpletest.c
, this program first writes the value 0xDEADBEEF
to memory address 0x4
. Then, it uses the enable_interrupt()
function to allow interrupts and defines the interrupt handler function trap_handler
, which writes the value 0x2022
to memory address 0x4
.
Allow the program to run for 1000 cycles and then read the value at memory address 0x4
to verify it is 0xDEADBEEF
. As shown in the diagram below, at 2003ps, mem_debug_read_data = 0xDEADBEEF
is observed.
Set interrupt_flag
to 0x1
to trigger an interrupt. The program should jump to execute the trap_handler
function. After another 1000 cycles, check the values of the MSTATUS
and MCAUSE
registers.
As shown in the diagram below, MCAUSE = 0x80000007
, which matches expectations.
Finally, read the value at memory address 0x4
to verify whether the interrupt handler executed correctly. The result is 0x2022
, which matches expectations, as shown in the diagram below.
src/main/scala/riscv/core/Execute.scala
src/main/scala/riscv/core/CSR.scala
src/main/scala/riscv/core/CLINT.scala
src/main/scala/riscv/peripheral/Timer.scala
Fill in the corresponding code at the // part2(CLINTCSR)
comments in the files above to pass the tests CPUTest
, ExecuteTest
, CLINTCSRTest
, and TimerTest
.
After completing the single-cycle CPU experiment, you should now have a basic understanding of CPU principles and structure. However, in the single-cycle CPU design, the critical path is too long, limiting the achievable clock frequency. Additionally, only one instruction can be executed per clock cycle, resulting in low instruction throughput. To address these issues, we will attempt to overlap the execution of multiple instructions using pipelining.
Handling hazards is the most challenging and critical aspect of pipelined CPU design. In this experiment, we will first design a simple three-stage pipelined CPU (IF, ID, and EX stages) that only deals with control hazards caused by branch and jump instructions, making it relatively simple to handle. Then, we will further divide the EX stage of the three-stage pipeline into EX, MEM, and WB stages, forming a classic five-stage pipeline. This introduces data hazards that require techniques like stalling and forwarding. Finally, we will move branch and jump handling to the ID stage to further reduce branch delay.
In this experiment, you will learn to:
Whether using an IDE or running commands, the root directory is the part3
directory.
Pipeline registers act as buffers in the pipeline, dividing combinational logic and shortening the critical path. Their functionality is simple: at each clock cycle, depending on the reset (pipeline flush) or stall (pipeline pause) signals, the register content is either cleared, held, or updated with new values. The output of the register is its stored value. For reusability, we can define a parameterized PipelineRegister
module to implement pipeline registers with different data widths.
The module interface has been defined in src/main/scala/riscv/core/PipelineRegister.scala
. The stall
and flush
signals represent pipeline register stall and flush signals, while in
and out
are the values written to and read from the register. Modify the code at the // part3(PipelineRegister)
comment to pass the PipelineRegisterTest
.
You can ignore the CPU for this task and use the basic knowledge from lab0 to implement the required functionality. The code should be no more than seven lines, so treat this as a simple warm-up exercise.
Below is the structure diagram of the three-stage pipelined CPU, where blue lines represent data paths, and red lines represent control signals.
three_stage_pipelined_CPU_structure
We divide the combinational logic of the single-cycle CPU into three stages using two sets of pipeline registers, IF2ID
and ID2EX
:
PC
.The code for these three stages is similar to that of the single-cycle CPU and has been provided. Focus on handling hazards in the following sections.
In the three-stage pipeline, since all data processing occurs in the EX stage, data hazards do not exist. The only issue is control hazards caused by program jumps. Program jumps can occur in three cases:
InterruptAssert
signal from CLINT is received in the EX stage, effectively adding a jump instruction on top of the current EX stage instruction.In all cases, the EX stage sends the jump_flag
and jump_address
signals to the IF stage. However, before the new instruction can be fetched using jump_address
, two instructions already in the IF and ID stages must be discarded. These instructions can be turned into "no-operations" by flushing the corresponding pipeline registers.
A control unit will detect control hazards and flush the pipeline. The module is defined in src/main/scala/riscv/core/threestage/Control.scala
. Based on the analysis, determine the module's input and output, and complete the code at the // part3(Flush)
comment. Also, connect the module in src/main/scala/riscv/core/threestage/CPU.scala
at the // part3(Flush)
comment to pass the ThreeStageCPUTest
.
In the three-stage pipeline, the EX stage still involves complex logic that can lead to delays. To further shorten the critical path, we can extend the pipeline to five stages by dividing the EX stage into ALU, memory access, and write-back stages:
five_stage_pipelined_CPU_structure
Dividing the three-stage pipeline into a five-stage pipeline introduces more complex data hazards. We will use stalling to handle these hazards, creating a fully functional five-stage pipelined CPU. Forwarding and branch prediction can further improve efficiency and are optional extensions.
Data hazards occur when instructions in the ID stage depend on the results of instructions in the EX or MEM stages. In such cases, the IF and ID stages are stalled until the required data is available in the WB stage.
Consider the following instruction sequence:
Without stalling, the pipeline state is as follows:
Clock Cycle | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
---|---|---|---|---|---|---|---|
IF | add | sub | and | jalr | or | xor | |
ID | add | sub | and | jalr | or | xor | |
EX | add | sub | and | jalr | or | ||
MEM | add | sub | and | jalr | |||
WB | add | sub | and |
In cycle 2, sub x2, x0, x1
in the ID stage depends on x1
, which is not written back yet. Similarly, and x3, x1, x2
in cycle 3 depends on the results of previous instructions. How many cycles should these instructions stall?
Complete the Control.scala
module at the // part3(Stall)
comment in src/main/scala/riscv/core/fivestage_stall
to handle stalling and pass the FiveStageCPUStallTest
.
While stalling resolves hazards, it introduces pipeline bubbles, reducing efficiency. Forwarding can bypass waiting by using intermediate pipeline registers (e.g., EX2MEM, MEM2WB). Modify the Control.scala
, Forwarding.scala
, and Execute.scala
modules in src/main/scala/riscv/core/fivestage_forward
at the // part3(Forward)
comment to implement forwarding and pass the FiveStageCPUForward
test.
Although the second instruction, sub x2, x0, x1
, depends on the execution result of the first instruction, in the third clock cycle, the sub
instruction in the EX stage can directly fetch the value of register x1
from the EX2MEM
register as its source operand without stalling. Similarly, the third instruction depends on the first two instructions, and in the fourth clock cycle, the and
instruction in the EX stage can fetch its source operands from EX2MEM
and MEM2WB
.
It is worth noting that in the fifth clock cycle, both EX2MEM
and MEM2WB
contain the value of x2
. In this case, the "latest" value, located in EX2MEM
, should be used. In the sixth clock cycle, the situation differs because the fourth instruction is a load
instruction, which requires the MEM stage to complete before its result is available. Therefore, the or
instruction in the EX stage cannot fetch its source operand from EX2MEM
and must stall for one clock cycle to retrieve it from MEM2WB
.
A control unit is used to handle pipeline stalls and flushes, with its module interface defined in src/main/scala/riscv/core/fivestage_forward/Control.scala
. A forwarding unit is used to detect data hazards and generate forwarding control signals, with its module interface defined in src/main/scala/riscv/core/fivestage_forward/Forwarding.scala
. Additionally, the execute unit (src/main/scala/riscv/core/fivestage_forward/Execute.scala
) needs to use the appropriate forwarded data based on the forwarding unit's control signals. Based on this analysis, modify the code at the // part3(Forward)
comment in the three modules to pass the FiveStageCPUForward
test.
Finally, move branch and jump handling to the ID stage to reduce the branch penalty from two cycles to one. Modify the InstructionDecode.scala
, Control.scala
, and Forwarding.scala
modules in src/main/scala/riscv/core/fivestage_final
at the // part3(Final)
comment to implement this optimization and pass the FiveStageCPUFinal
test.