Final Project - Shahid Beheshti University(2023)
This project focuses on designing and implementing a multi-cycle RISC-V processor using microprogrammed control that can execute these instructions:
- R-type instructions
- I-type instructions
- lw
- sw
- beq
- jal
The processor consists of three main units:
- Memory
- Data path
- Controller
In the single-cycle design, we used separate instruction and data memories to read the instruction memory and read or write the data memory all in one cycle. Now, we use a combined memory for instructions and data. This is more realistic and feasible because we can read the instruction in one cycle, then read or write the data in another cycle.
Multi-cycle data paths break up instructions into separate steps. The steps based on the executing instruction, are as follows:
R-type instructions: Fetch, Decode, ExecuteR, ALUWB.
I-type instructions: Fetch, Decode, ExecuteI. ALUWB.
lw instruction: Fetch, Decode, MemAdr, MemRead, MemWB.
sw instruction: Fetch, Decode, MemAdr, MemWrite.
beq instruction: Fetch, Decode, BEQ.
jal instruction: Fetch, Decode, JAL, ALUWB.
Therefore the data path consists of a Register File, ALU, Extend unit, several multiplexers for picking up the input of other units, and 5 Nonarchitectural registers to hold the results of each step:
Each functional unit can be used more than once in an instruction, as long as it is used in different clock cycles.
For more information about the multi-cycle data path, please refer to Section 7.4.1 of the book "Digital Design and Computer Architecture: RISC-V Edition".
The controller, by receiving the necessary signals as inputs, provides control signals to various sections of the datapath. The difference between the controller in a microprogrammed control unit and a multi-cycle is that in microprogramming, the required control signals for each state are stored in a row of internal memory, such as a ROM. Upon receiving each line from the ROM (control word), we effectively have all the required control signals.
- It can more systematic design of the control unit.
- It is simpler to debug and change.
- It is used to control functions implemented in software and not hardware.
- It is more flexible.
- Adaptability is obtained at more cost.
- It is slower than a hardwired control unit.
To execute an instruction, we require logic that produces the correct control signals by generating inputs to the ROM. This logic is called address select logic. It determines the next micro-operation based on the current micro-operation and the instruction's opcode.
There is a multiplexer that selects which one of its inputs will be the address for the next micro-operation. Based on the executing instruction and the current execution stage, the following scenarios are considered:
The micro-operation that comes after the current micro-operation in the ROM should be executed precisely. This is implemented using an Adder.
In the decode state, the next state is determined based on the opcode. this is implemented using the Dispatch ROM 1.
In the MemAdr state, the next state is determined based on the opcode, and this is implemented using the Dispatch ROM 2.
When the instruction is completed, the next state is the Fetch state.
In the ExecuteR, ExecuteI, and JAL states, the next state is the ALUWB.
The controller module also consists of an ALU Decoder and Instr Decoder. The ALU Decoder produces ALUControl based on ALUOp and funct3. In the case of the sub and add instructions, the ALU Decoder also uses funct7_5 and op_5 to determine ALUControl, as given in the table below:
A small Instruction Decoder combinationally produces the ImmSrc select signal for extend unit, based on the opcode using the table below:
Testing and evaluation are imperative to guarantee the proper functionality of the processor. For this purpose, we first examine the controller's functionality and subsequently test the overall processor functionality.
First, we test the functionality of the Microprogrammed Control Unit. For this purpose, we write a test vector(TV) file containing input instruction sequences along with their expected outputs. Then, in the controller testbench, we compare the generated outputs with the expected outputs. If they do not match, we display the signal value, the expected value, and the corresponding test number. Finally, we present the total number of tests and the count of incorrect outputs.
Output for controller testbench:
Finally, to verify the overall functionality of the processor, we write code in assembly language that utilizes various instructions supported by the processor. Then, we write a specific value at a designated memory address, dependent on the correctness of the corresponding code. Then, we convert the desired code into machine code. Next, we store the respective machine code in a text file and initialize the memory with the values of the machine code instructions in memory module. Ultimately, we compare the expected value with the value present at the specified memory address after executing all the instructions. If they match, our test passes; otherwise, the test failes.
Output for processor testbench:
