Verilog Pipelined MIPS32 Processor

Technology

• Vivado Design Suite, Standard Edition
• Lucidchart

I used Lucidchart to design block diagrams to map stage-specific modules and interconnectivity throughout the entire design. I also used Vivado to develop design and testbench modules, and to export custom reporting used to debug and validate the design.

Development

This project includes distinct modules within each stage and general components – like multiplexers and pipeline registers – instantiated multiple times within different stages, in addition to the Data Hazard and Execution Forwarding units. The MIPS Processor module is the parent container for the entire design.

Development began with the design of unique components, followed by general, pipeline components. Next came the design of each stage, instantiating and connecting the respective components. Then, mapping signals to the intermediary pipeline registers between each stage. Finally, integration of the Data Hazard and Execution Forwarding modules, before encapsulating all stage, register, and control components into the MIPS Processor container.

The MIPS32 Processor is the parent container for the design, including the modules and buses that support the five-stage processing and hazard mitigation. The MIPS32 Processor module receives the clock and reset input signals, passing them to the necessary submodules, and returns the result output from each completed instruction, from the Write Back stage.

The following sections describe the modules for the pipeline stages and registers, followed by the hazard mitigation units.

Instruction Fetch (IF) Stage

The Instruction Fetch (IF) stage module centers around the Program Counter (PC) module that holds the address of the instruction to fetch, corresponding to those stored within the Instruction Memory module, and uses an adder to advance the instruction address to that of the following instruction.

The PC receives its next instruction address from a pair of 2:1 multiplexers that work together to select whether the PC receives the next instruction – iterated by the adder – or the address of a branch or jump instruction. The next instruction also depends on the stall control signal, from the Hazard Detection unit, which initiates an NOP instruction when needed. This lightweight design uses a 10-bit PC, which supports its minimal instruction set – as opposed to the full 32-bit implementation found in typical MIPS32 implementations.

The Instruction Memory module contains a series of instructions that initialize 10 register values, followed by a series of basic instructions and batches of instructions designed to trigger specific hazard mitigation responses. SW instructions follow each batch of tests, making the results available for evaluation.

/** InstrMem.v instructions for load-use RAW data hazard tests **/

/* RS Dependency Test */
rom[46] = 32'b10001100000010110000000000100100; // lw  $11, 36($0)
rom[47] = 32'b00000001011000100110000000100000; // add $12, $11, $2

/* RT Dependency Test */
rom[48] = 32'b10001100000011010000000000100000; // lw  $13, 32($0)
rom[49] = 32'b00000000001011010111000000100000; // add $14, $1, $13

/* Store Test Results */
rom[50] = 32'b10101100000011000000000001110100; // sw $12, 29($0)
rom[51] = 32'b10101100000011100000000001111000; // sw $14, 30($0)

This excerpt from Instruction Memory includes the instructions used to test and validate the processor’s response to “load-use” RAW data hazard cases. To simplify this article, all future analysis and commentary about specific instructions focuses only on this subset of instructions. The InstrMem.v file in the GitHub repository contains the entire instruction set, including a comprehensive amount of supporting information via comments.

This block diagram represents a group of pipeline registers between the Instruction Fetch and Instruction Decode (IF/ID) Stages. These temporary registers hold the value of the current instruction and the address of the following instruction.

The IF/ID Pipeline Registers have data hazard and flush control signals, from the Hazard Detection unit, to support stalling and flushing, as required. These control signals are unique to the pipeline registers at this phase, with only clock and reset controls appearing in subsequent instances.

Both output values from these pipeline registers pass through to the ID Stage, and the instruction output also passes to the Hazard Detection unit and the Instruction ID/EX Pipeline Registers, located beyond the next stage.

This Pipeline Registers block diagram – and all following Pipeline Registers diagrams – illustrates a simplified representation of these registers. The actual implementation involves a distinct register module for pair or input and output signals, instead of this consolidated version that contains all signal pairs. The enumeration of these signals corresponds to the distinct instances of these registers that appear within the MIPS32 Processor module.

Instruction Decode (ID) Stage

The ID Stage is the most complicated of all the stages within this design, handling register operations, the assignment of immediate values, calculations of values needed for branch and jump operations, and facilitating the control signals associated with the data and control hazard responses.

The register operations involve processing write, address, and data values from the Memory Access and Write Back registers to write result values to the register, as needed, the Register File module in the bottom/left of the diagram. This module also receives subsets of the instruction (instr) input from the IF/ID register to perform read operations, passing any required register values as output.

Other subsets of the input instruction value support the calculation of the immediate value, branch control signal, and addresses for the branch, jump, and destination register, with the aid of logical operators: shift registers, bit selectors, an adder, a comparator, and an AND gate, as illustrated in the bottom of the diagram. The top half of the diagram represents the output from the Controller module, which generates control signals for components in future stages, processed through a series of 2:1 multiplexers controlled by the hazard control code (Hazard_CC), calculated from the Hazard Detection unit output signals – denoted with red signals and components.

The Hazard_CC signal uses an OR gate to set it as active if it receives a data and/or control hazard signal from the Hazard Detection unit. The data hazard input is active low, requiring an invertor to trigger the following OR gate. In the event of a hazard, the Hazard_CC flushes all the connected 2:1 multiplexers by forcing them to output values of zero instead of the values received from the Controller module.

The Controller outputs for the branch and jump control codes bypass these hazard-controlled multiplexers, passing the jump control code directly to the module output and sending the branch control code into the selection logic flow previously mentioned.

The output signals pass to the next set of pipeline registers, except for those related to the branch and jump operations, which return to the IF Stage instead. These signals are the control codes at the bottom of the diagram (branch_sel and jump_sel) and the address values that appear in the lower/right (branch_addr and jump_addr).

The Instruction Decode / Execution (ID/EX) Pipeline Registers receive all the output values from the ID Stage and an instruction value from a preceding IF/ID Pipeline Register, as indicated at the bottom of the diagram.

An ID/EX Pipeline Register also receives the instruction value from the preceding IF/ID Pipeline Registers, as indicated at the bottom of the diagram.

Output signal destinations from the ID/EX Pipeline Registers scatter, with only five of them passing through the Execution (EX) Stage. The remaining signals, in addition to those split from the initial five signals, go to both hazard mitigation units and the EX/MEM Pipeline Registers.

Execution (EX) Stage

The Execution (EX) Stage generates two output values, based on an arithmetic logic unit (ALU) calculation and selections from a series of multiplexers and control signals. The ALU result output corresponds to a literal result from an arithmetic or logical operation, or the calculation of a memory address required for a load or store operation. The second output corresponds with a value for writing to a memory address in the following stage.

The ALU executes the operation specified by the control signal it receives from its ALU Controller module, after the latter calculates the operation by considering two input control codes from the previous stage. The data for ALU input “a” comes from the “Mux_Fwd_A” module and the other from the 2:1 multiplexer.

The 4:1 multiplexers receive control signals from the Data Forwarding unit to select from input values they both receive from a previous ALU result, stored in the following Pipeline Registers, and a result value from the Write Back (WB) stage – in addition to a distinct Reg value for each, read from the Register File in the previous stage.

The “Mux_Fwd_B” module output passes directly to the EX Stage output and to the 2:1 Multiplexer. Depending on the instruction type, determined by the ALU source (alu_src) control code, the 2:1 Multiplexer passes the previous input or the immediate value, received from the previous stage, to the ALU for its result calculation.

The Execution / Memory Access (EX/MEM) Pipeline Registers receive the two outputs from the previous stage, in addition to five signals it receives from the ID/EX Pipeline Registers.

The EX Stage outputs pass through these registers to the MEM Stage, along with the Mem Read and Mem Write control signals. The ALU result also passes back to the EX Stage and forward to the MEM/WB Pipeline Registers. The remaining output signals go to the Data Forwarding unit and MEM/WB Pipeline Registers.

Memory Access (MEM) Stage

The Memory Access (MEM) Stage consists of a single Data Memory module that performs memory read or write operations based on the combination of control signals and data values received from the EX/MEM Pipeline Registers. In the case of performing a read operation, it passes the value from the corresponding memory address to a MEM/WB Pipeline Register.

The Memory Access / Write Back (MEM/WB) Pipeline Registers contain values from the MEM Stage output along with four inputs from the EX/MEM Pipeline Registers.

The first two outputs are potential output values passed to the Write Back stage and the third is a control signal for the following stage. The last two output values contain register address and write control signal, passed to the ID Stage and to the Data Forwarding unit.

Write Back (WB) Stage

The Write Back (WB) Stage is a 2:1 Multiplexer, selecting either the value read from memory or previous ALU result.

The WB result passes through as the MIPS32 Processor result output and passes to the ID Stage for writing to a register and to the EX Stage as an input consideration for its ALU calculation.

Data Forwarding Unit

As previously mentioned, the Data Forwarding unit identifies and mitigates RAW data hazards by expediting the delivery of calculated values – or forwarding them – to instructions requiring these values before preceding instructions write them to a register.

The Data Forward unit manages this by collecting “write enable” signals, from both the EX/MEM and MEM/WB Pipeline Registers, instruction argument addresses from the ID/EX Pipeline Registers, and destination register addresses from the EX/MEM and MEM/WB Pipeline Registers.

Evaluating these input signals allows the Data Forwarding unit to verify the occurrence of a write operation, using the control signals, and to identify whether argument addresses from the ID/EX Pipeline Registers correspond with destination addresses from instructions further in the pipeline.

After this evaluation, the Data Forwarding module sends its forward A and B control signals – corresponding to the two instruction argument values rs and rt – to the 4:1 Multiplexers in the EX Stage to select the proper input signals: the Register File value from the ID/EX Pipeline Register, the ALU Result from the EX/MEM Pipeline Register, or the WB Result.

Hazard Detection Unit

The Hazard Detection unit mitigates load-use data hazards, beyond the scope of the Data Forwarding unit, and control hazards from branch and jump operations. The Hazard Detection unit identifies RAW data hazards with a load-use dependency by evaluating the “memory read’ control signal and destination address from the ID/EX Pipeline Registers and the argument values from the IF/ID Pipeline Registers to find a potential match between a LW register and an instruction argument. If this hazard exists, the Hazard Detection pushes the stall control signal to the IF and ID Stages and the IF/ID Pipeline Registers to insert a NOP instruction.

To mitigate control hazards, the Hazard Detection unit evaluates the branch and jump selection control signals. If it receives an active signal for either operation, the Hazard Detection unit pushes the flush control signal to the IF/ID Pipeline Registers and the ID Stage to clear any pending instructions from the pipeline.

Testing

The testing process ran concurrently with development – testing the functionality of components, stages, etc. through test benches and manual signal manipulation in the Vivado Simulation environment – and culminated with the development of the tb_MIPS32_Processor.v test bench, included within this project’s repository.

The final test bench includes 32 test cases to validate the execution of the following instructions from the processor’s Instruction Memory module.

• 10 initial register value assignments.
• 9 instructions to validate cases with no hazard mitigation.
• 9 instructions to validate the data forwarding responses for RAW data hazards.
• 2 instructions to validate the stalling responses for load-use RAW data hazards.
• 2 instructions to validate the stalling responses for control hazards.

This test bench returns results from these test cases via the following three methods, each providing a different level of specificity to provide high-level insights and pin-point analyses for resolving points-of-failure within the design.

• Scoring system and high-level performance summary.
• CSV file output with specific test details.
• Waveform diagram with specific details over time.

Simulation Time Constraints

This simulation exceeds the default Vivado limit and requires manual action to complete all tests and save the CSV file. Select “Run Simulation” to begin the tests, followed by “Run All” to complete the remaining tests.

Select “Run All” by one of the following:

• Click the ▶ icon on the upper toolbar.
• Select “Run” >> “Run All” from the top-level menu bar.
• Press the [F3] keyboard button.

Test Results

## Example Tcl score summary message

Test cases passed: XX / 22

After selecting “Run All,” this summary message appears in the Vivado Tool Command Language (Tcl) console, with ‘XX’ representing the number of valid test cases out of 22 (omitting the 10 initial register assignments). This output provides instant high-level performance feedback, confirming the correct execution of all tests or indicating the need to review the following, more detailed reporting.

/** Test bench snippet: Initializing and saving CSV output **/

integer f; // Output CSV variable

/** Initialize CSV file **/
initial begin	
    f = $fopen("tb_mips32.csv", "w");
    $fwrite(f,"Test Condition,Expected,Actual,Result\n");
end
	
/** Close CSV file and finish simulation **/
initial begin
    #3000; // Delay until all test cases finish
    $fclose(f);

    $finish;
end

This snippet contains the Verilog assignments and blocks necessary to set up and finalize the comma-separated value (CSV) output file, named tb_mips32.csv. After defining the CSV variable, the first block opens the output file, in write mode, and prints the header row. The second block closes the CSV file prior to finishing the simulation.

The CSV output was my primary validation method because of the simple and targeted insights it offered, compared to the following waveform output.

## Example of CSV header and test case results

Test Condition,Expected,Actual,Result
...
Data Hazard (RS Dependency): ADD,d15f1416,00000000,FAIL
Data Hazard (RT Dependency): ADD,b54bc032,b54bc032,PASS
...

This example snippet from the CSV output file shows the heading values, followed by the rows of test feedback from the two “load-use” RAW data hazard cases.

After exporting the CSV data, I pasted into an Excel template that I created, using conditional formatting to emphasize specific points-of-failure. For example’s sake, I manually changed one of the actual result values to demonstrate an error response, but my final scorecard returned all accurate results and a score of 100%.

After identifying errors within the scorecard, I referred to the waveform output to identify points of failure and analyze adjacent results to discover root causes. This waveform snippet focuses on the same two cases as previous examples because the full waveform output is massive. The GitHub repository contains the entire waveform output, for reference.

/** Test bench excerpt: Load-Use RAW Data Hazard test cases **/

$fwrite(f, "Data Hazard (RS Dependency): ADD,d15f1416,%h,", uut.Data_Mem.ram[29]);
if(uut.Data_Mem.ram[29]==32'hd15f1416) begin
    $fwrite(f, "PASS\n");
    point = point + 1;
end
else $fwrite(f, "FAIL\n");

$fwrite(f, "Data Hazard (RT Dependency): ADD,b54bc032,%h,", uut.Data_Mem.ram[30]);
if(uut.Data_Mem.ram[30]==32'hb54bc032) begin
    $fwrite(f, "PASS\n");
    point = point + 1;
end
else $fwrite(f, "FAIL\n");

This snippet of code from the test bench shows the conditions for evaluating the two load-use RAW data hazard test cases. Each test case contains conditional logic to compare the expected and actual results from the corresponding memory address. The corresponding “PASS” or “FAIL” message prints to a row of the CSV file, including the actual value read from memory. A “PASS” result also includes an iteration of the point value.

/** Test bench excerpt: Results summary message **/

$display ("Test cases passed: %0d / 22\n", point);

Finally, the test bench executes a statement to display the Tcl performance summary message at the end of the test block, before finishing the simulation.

The insights from the three simulation outputs work together to create an effective troubleshooting workflow. The summary gives feedback on overall performance, the CSV output includes specific details about points of failure, and the waveform diagram provides context surrounding any points of failure and their impact on the entire system.

Credits

This project is a major update to a project I developed for the “Organization of Digital Computers Laboratory (EECS 112L)” course I completed at the Samueli School of Engineering at UC Irvine.

References

MIPS32 Architecture Instruction Set Manual