COMP 311: Lab 5

Pull the new starter code!

The starter code for each subsequent lab will be added directly into the same course repository. To update your individual repo, navigate to your workspace on the GitHub website and you should see a “Sync Fork” button. Click this and then “Update Branch.” Now if you run git pull in your terminal, you will have all the materials you need.

OR

If you went through the additional git set-up steps for lab 1, you should be able to run

git pull starter main --rebase

Then all the new code for lab 5 should be there!

Datapath

In Labs 3 and 4, you designed the ALU and the Register File. Now, it’s time to put these components together to design a functioning simple datapath that supports the following RV32I instructions:

1. add
2. and
3. or
4. slt
5. sub
6. addi
7. slti
8. andi

All of these are standard RISC-V RV32I integer ALU or ALU-immediate instructions.

Task 0. ALU Modifications

Copy your circuits from Lab 3 and Lab 4 into your Lab 5 repo.

The diagram below shows the interface of the ALU you designed in Lab 3.

Your ALU had separate control inputs for sub, Bool, and Op. In this task, you will modify the interface of the ALU so that it takes in a 4-bit ALUOperation control signal that encodes the sub, Bool, and Op control signals. (If your earlier ALU had Zero, Negative, or other flags, you may keep them, but they are not required in this lab.) Also, since we are not supporting shift instructions, you can delete the barrel shifter. The new expected interface is shown below:

A[31:0]  ────────────────▶     ┌──────────────────────┐
                               |                      |
B[31:0]  ────────────────▶     │                      │───▶  Result[31:0]
                               │         ALU          │
ALUOperation[3:0] ─────────▶   │                      │
                               └──────────────────────┘

The 4-bit ALUOperation control signal is shown in a table below. This is taken from the Appendix of optional textbook #1.

Testing

Your final design should be in alu.dig. Replace the test cases in your local ALU test with the test cases in alu-test.txt. Run the tests as usual.

• Note: As of 11/26, Kaki decided she would give you all the updated ALU so you can get started. It is uploaded on Canvas to avoid merge conflicts for folks who started early.

Task 1. Control Signals (RISC-V)

The control unit is a circuit that generates the control signals for the current instruction based on the RISC-V instruction fields: opcode, funct3, and (for R-type) funct7. To begin designing the control unit, we first need to define the control signals for each instruction.

You will fill out the CSV file, control-signals.csv, with the control signals for each instruction.

Control Signals Used in This Lab

For this subset, our microcode for each instruction consists of:

• RegWrite (1 bit):
  • 1 if this instruction writes a result back into the register file.
    
• ALUSrc (1 bit):
  • 0 → ALU second input comes from rs2 (R-type).
    
  • 1 → ALU second input comes from the sign-extended immediate (I-type).
    
• ImmSrc[1:0] (2 bits):
  • Indicates the immediate format. For this lab, all ALU-immediate instructions use the RV32I I-type immediate, so we will always use ImmSrc = 00.
    
• ALUOperation[3:0] (4 bits):
  • Selects AND/OR/ADD/SUB/SLT as in Task 0.

So each instruction’s control word has 8 bits total:

RegWrite ALUSrc ImmSrc[1] ImmSrc[0] ALUOp[3] ALUOp[2] ALUOp[1] ALUOp[0]

In control-signals.csv, the columns are:

• Instruction
• RegWrite
• ALUSrc
• ImmSrc1
• ImmSrc0
• ALUOp3
• ALUOp2
• ALUOp1
• ALUOp0
• DataValueForROM

The DataValueForROM column is the 8 control bits concatenated together, written in binary and prefixed with 0b so Digital interprets it correctly.

Example: add

The RISC-V add instruction:

• Writes to rd → RegWrite = 1
• Second ALU input is rs2 → ALUSrc = 0
• Does not use an immediate, but we can still set ImmSrc = 00 (don’t-care here)
• ALU performs ADD → ALUOperation = 0010

So the control bits are:

• RegWrite = 1
• ALUSrc = 0
• ImmSrc1 = 0
• ImmSrc0 = 0
• ALUOp3 = 0
• ALUOp2 = 0
• ALUOp1 = 1
• ALUOp0 = 0

Concatenated:

1 0 0 0 0 0 1 0 = 0b10000010

The add row is provided as an example in control-signals.csv.

What You Should Do

1. For each of the 8 supported instructions (add, sub, and, or, slt, addi, slti, andi), determine the values of RegWrite, ALUSrc, ImmSrc1, ImmSrc0, ALUOp3..0.
2. Write those values into control-signals.csv.
3. For each row, compute the binary DataValueForROM by concatenating the bits into the pattern:
   RegWrite ALUSrc ImmSrc1 ImmSrc0 ALUOp3 ALUOp2 ALUOp1 ALUOp0
   and write it as something like 0b10000010.

It is recommended that you complete this task using Excel or Google Sheets.

Task 2. Microcode (ROM)

The set of control signals for each instruction is known as microcode. We store the microcode in a small memory unit in our datapath called a ROM. ROM stands for read-only memory. As the name implies, it’s memory that is read-only. Why is it read only? Once your datapath is complete, we should never need to update the control signals, so there is no need to write to this memory.

You can think of the ROM as a table that stores our control signals. Each row of the ROM stores the 8-bit microcode for one instruction. The address at which you will store each instruction’s control signals is shown below.

Address 0 will store the control bits for add. Address 1 will store the control bits for sub, etc. (The instructions could have been stored in any order; the order above just matches our spreadsheet.)

Component: ROM

You can find the ROM in Components → Memory → ROM.

Place the ROM in a new file called: control-unit.dig. If you pulled the lab within the first 20 mins of it being posted (good job!!!) Kaki included a wrong control-unit. Delete it and start fresh.

ROM Inputs

• A: the address that we want to read from (3 bits wide for 8 entries).
• sel: we’ll connect this to a constant 1 because we always want to be able to read from the ROM.

ROM Outputs

• D: the data stored at address A — this will be your 8-bit microcode word.

Example Usage

• If we set A to 0 and sel to 1, the output D will contain the microcode for the add instruction.
• If we set A to 1 and sel to 1, the output D will contain the microcode for the sub instruction.

Configuration

Let’s configure our ROM!

Upon opening up the ROM you see this window:

It will be your job to set the configuration:

• Data bits: How many control bits are there for each instruction?
  → In this lab: 8.
• Address bits: Our datapath will support 8 instructions, so we need 8 entries in the ROM.
  → We need log₂(8) = 3 address bits.

Now, we want to copy and paste the DataValueForROM column from control-signals.csv into the ROM. To edit the contents of the ROM:

1. Right-click on the ROM component and click Edit.
2. Make sure that your values in the spreadsheet are prefixed with 0b (e.g., 0b10000010) so that they are stored correctly in the ROM.
3. Copy that column from your CSV and paste it into the ROM editor.

Testing

There are no automated tests for this task. You should manually check:

• When you set A to 0, the ROM outputs the microcode for add.
• When you set A to 1, the ROM outputs the microcode for sub.
• And so on for the other addresses.

Task 3. Control Unit (RISC-V Decode)

In this task, you will complete your implementation of the control unit. Below you will find the interface of the control unit:

Your control unit will:

1. Use the RISC-V instruction fields opcode, funct3, and funct7 to determine which instruction is being executed.
2. Produce a one-hot set of signals, one per instruction (e.g., is_add, is_sub, is_and, …).
3. Feed those signals into a priority encoder to select the ROM address.
4. Use that address to read the correct microcode from the ROM.
5. Output the microcode bits (RegWrite, ALUSrc, ImmSrc, ALUOperation) as control signals to the rest of the datapath.

RISC-V Instruction Patterns (for this lab)

For reference, the RV32I encodings for the instructions we support are:

• R-type (opcode = 0110011)
  • add : funct7 = 0000000, funct3 = 000
    
  • sub : funct7 = 0100000, funct3 = 000
    
  • and : funct7 = 0000000, funct3 = 111
    
  • or : funct7 = 0000000, funct3 = 110
    
  • slt : funct7 = 0000000, funct3 = 010
• I-type ALU (opcode = 0010011)
  • addi : funct3 = 000
    
  • slti : funct3 = 010
    
  • andi : funct3 = 111

You can use comparators to match these bit patterns and produce one boolean signal per instruction.

Example for add:

• Check opcode == 0110011
• Check funct3 == 000
• Check funct7 == 0000000
• AND these conditions together to get a single is_add signal.

Do the same for each instruction (is_sub, is_and, is_or, is_slt, is_addi, is_slti, is_andi).

Component: Priority Encoder

You will need to use a priority encoder to complete this task.

You can find the priority encoder at Components → Plexers → Priority Encoder.

We will use an 8-input priority encoder where:

• Each input (in0 … in7) corresponds to one instruction (add, sub, and, or, slt, addi, slti, andi).
• The encoder’s num output is a 3-bit binary address (0–7) that selects which instruction is active.
• The encoder’s any output is high whenever any of the inputs are high.

The priority encoder sets the num output to the binary value of the highest-numbered input that is active (high). The highest priority input is in7 and the lowest priority input is in0. If multiple inputs are high (which should not happen if your decode is correct), the encoder will choose the one with the highest index.

The following truth table illustrates the operation of an 8-bit priority encoder:

Wiring the Control Unit

1. The comparators decode the RISC-V instruction into is_add, is_sub, …, is_andi.
2. These signals feed the priority encoder’s inputs (in0..in7).
3. The encoder’s num output is the ROM address (A).
4. The ROM’s D output is the 8-bit microcode for that instruction.
5. Split those 8 bits into the individual control wires (RegWrite, ALUSrc, ImmSrc, ALUOperation) and send them to the datapath.

Testing:

An example test case for the add instruction is below:

opcode   funct3  funct7    RegWrite ALUSrc ImmSrc1 ImmSrc0 ALUOp3 ALUOp2 ALUOp1 ALUOp0
0b0110011 0b000  0b0000000 0b1      0b0    0b0     0b0     0b0    0b0    0b1    0b0

It is your job to: - Add additional tests for the remaining instructions to verify that your control unit correctly decodes them and produces the right control outputs. —

Task 4. Instruction Memory and Program Counter

The Instruction Memory and Program Counter have been set up for you in cpu.dig.

The instruction memory is a ROM. We want the instruction memory to be able to store 1024 instructions, so the ROM should have 10 address bits. Each instruction is 32 bits, so the size of each entry in the instruction memory should be 32 bits. You can see the configuration of the ROM below.

In RV32I, the total addressable memory space is 4 GB or 2³² bytes. The instruction memory for this lab is actually a portion of the entire memory (specifically addresses 0x00003000 to 0x00003FFC). The size of our instruction memory is 2¹² bytes (1024 instructions × 4 bytes per instruction).

Our instruction memory component has 1024 entries, so we need to address it with log₂1024 = 10 bits instead of 32 bits.

Which bits of the program counter do we use to address the instruction memory?

• We will use bits 2–11 of the PC.
  
• Why? The value stored in the PC is a byte address; however, the address we use to index the ROM is a word address. To convert the byte address to the word address, we just shift the byte address right by 2 bits (dropping bits 0 and 1).

There is nothing for you to complete for this task. Just make sure you understand the explanation above.

Task 5. Everything Else (RISC-V Datapath)

Complete cpu.dig by adding your:

• ALU (alu.dig)
• Register File (register-file.dig)
• Immediate generator / extender (to produce an I-type sign-extended immediate)
• ALUSrc mux (to choose between rs2 and the immediate)
• Control Unit (from Task 3)
• Instruction Memory and PC (already provided)

Important RISC-V details:

• The register file always writes to the rd field of the instruction; there is no RegDst signal in RISC-V.
• For R-type instructions, the ALU inputs are rs1 and rs2.
• For I-type ALU instructions (addi, slti, andi), the ALU inputs are rs1 and the sign-extended I-type immediate.
• All 8 instructions in this lab write their result back to rd (so RegWrite = 1 for all of them).

Recommended Wiring

• Register file:
  • ReadReg1 = rs1
  • ReadReg2 = rs2
  • WriteReg = rd
  • RegWrite = control signal from your control unit / ROM
  • WriteData = ALU result
• ALU:
  • Input A = ReadData1 (from register file)
  • Input B = output of the ALUSrc mux
    • ALUSrc = 0 → use ReadData2 (R-type)
      
    • ALUSrc = 1 → use immediate (I-type)
  • ALUOperation = control signal from your control unit / ROM

When you add the Register File, the input/output names may be overlapping. To fix this, open your register-file.dig and widen the component by clicking Edit → Circuit specific settings and changing the width field.

To confirm that your circuit is functioning correctly, the provided tests verify the values of ReadReg1 and ReadReg2. To check these signals against expected values, we have to make them outputs of cpu.dig. The output pins have already been provided. Ensure you connect these output pins to their corresponding signals.

Testing (RISC-V)

Overview of Provided Files

• basic-tests.s: Contains a set of basic RISC-V RV32I instructions for testing your CPU (using only the 8 supported instructions).
• format.py: A script that formats the machine code instructions for easy copy & paste into Digital’s instruction memory ROM.
• basic.txt: Digital test file contents.

Directions

1. Read Over the Provided Instructions

Open basic-tests.s to view the RISC-V instructions used to test your CPU. The program uses only:

• add, sub, and, or, slt
• addi, slti, andi

and sets up a few registers to known values so we can check your datapath.

2. Convert the Instructions to Machine Code

We will use the miniRISC-V simulator/assembler.

1. Open basic-tests.s and take a look at the RISC-V assembly instructions we’ve given you to start.
2. In the miniRISC-V simulator, you can clear the whole window, paste in one instruction, and hit ``assemble’’. Then go to Dump Memory. It will show you the hexadecimal representation of each instruction in memory.
3. Save this output in a new .mem file. Each line in this file should contain one machine code instruction.

3. Format the Instructions for Digital

The instructions need to be formatted to be compatible with Digital’s instruction memory.

Use format.py to convert the .mem file into a .csv file containing a single 0b... 32-bit binary word per line:

python format.py <input_file> <output_file>

Replace with the name of your .mem file.

Replace with the desired name for your output .csv file.

For example

python format.py basic-tests.mem basic-tests.csv

Load Instructions into Digital

1. Open the generated .csv file in Excel and copy the contents.
2. Paste the contents into the instruction memory in Digital. You can also hit Edit –> File –> Load, to load in a file!

Set Up Testing in Digital

1. Copy and paste the contents of basic.txt into the Digital testing unit.
2. Run the tests as normal in Digital.

Extend the Tests

Once the basic tests pass, you will need to write additional tests for the remaining instructions. Note, you will only pass as many tests as you have instructions loaded up in memory. So if you just put the first instruction in memory (addi x4, x0, -20), you will only pass the first test.

Submission Instructions

Assignments are submitted through Gradescope.