View on GitHub

DINO CPU Assignments

Assignments for UC Davis Computer Architecture 154B. See the Class Website for details

DINO CPU Assignment 2

Originally from ECS 154B Lab 2, Winter 2019.

Modified for ECS 154B Lab 2, Winter 2021

Due on 1/24: See Submission for details

Table of Contents

Introduction

Cute Dino

In the last assignment, you implemented the ALU control and incorporated it into the DINO CPU to test some bare-metal R-type RISC-V instructions. In this assignment, you will implement the main control unit and NextPC unit and update the ALU control unit (if needed). After implementing the individual components and successfully passing all individual component tests, you will combine these along with the other CPU components to complete the single-cycle DINO CPU. The simple in-order CPU design is based closely on the CPU model in Patterson and Hennessy’s Computer Organization and Design.

Updating the DINO CPU code

The DINO CPU code must be updated before you can run each lab. You should read up on how to update your code to get the assignment 2 template from GitHub. We have made the following changes:

You can check out the main branch to get the template code for this lab. If you want to use your solution from lab1 as a starting point, you can merge your commits with the origin main by running git pull or git fetch; git merge origin/main.

If you want to start over and use the provided solution, you can do the following (see how to update your code for more details):

git clone https://github.com/jlpteaching/dinocpu-wq21
cd dinocpu-wq21
git merge origin/lab1-solution

How this assignment is written

The goal of this assignment is to implement a single-cycle RISC-V CPU which can execute all of the RISC-V integer instructions. Through the rest of this assignment, Part I through Part X, you will implement all of the RISC-V instructions, step by step.

If you prefer, you can simply skip to the end and implement all of the instructions at once, then run all of the tests for this assignment via the following command. You will also use this command to test everything once you believe you’re done.

sbt:dinocpu> test

We are making one major constraint on how you are implementing your CPU. You cannot modify the I/O for any module. We will be testing your control unit with our data path, and our data path with your control unit. Therefore, you must keep the exact same I/O. You will get errors on Gradescope (and thus no credit) if you modify the I/O.

Goals

Single cycle CPU design

Below is a diagram of the single cycle DINO CPU. This diagram includes all of the necessary data path wires and MUXes. However, it is missing the control path wires. This figure has all of the MUXes necessary, but does not show which control lines go to which MUX. Hint: the comments in the code for the control unit give some hints on how to wire the design.

In this assignment, you will be implementing the data path shown in the figure below, implementing the control path for the DINO CPU, and wiring up the control path. You can extend your work from Lab 1, or you can take the updated code from GitHub. You will be implementing everything in the diagram in Chisel (the cpu.scala file only implements the R-type instructions), which includes the code for the MUXes. Then, you will wire all of the components together. You will also implement the control unit, NextPC unit and update the alu control unit.

Important Notice: In order to get familiar with debugging your design using single stepper, we strongly encourage you to watch the tutorial video we have provided in the link below. You may have watched it while working on assignment1. As mentioned before, the videos were originally made for spring quarter 2020 (sq20). Just in case you wanted to use any command or text from these videos which contains ‘sq20’, you just need to convert it to ‘wq21’ to be applicable to your materials for the current quarter.

DinoCPU - Debugging your implementation

Single cycle DINO CPU without control wires

Control unit overview

In this part, you will be implementing the main control unit in the CPU design. The control unit is used to determine how to set the control lines for the functional units and the the multiplexers.

The control unit takes a single input, which is the 7-bit opcode. From that input, it generates the 13 control signals listed below as output.

itype         true if we're working on an itype instruction
aluop         true for R-type and I-type, false otherwise
xsrc          source for the first ALU/nextpc input (0 is readdata1, 1 is pc)
ysrc          source for the second ALU/nextpc input (0 is readdata2 and 1 is immediate)
branch        true if branch
jal           true if a jal
jalr          true if a jalr instruction
plus4         true if ALU should add 4 to inputx
resultselect  false for result from alu, true for immediate
memop         00 if not using memory, 10 if reading, and 11 if writing
toreg         false for result from execute, true for data from memory
regwrite      true if writing to the register file
validinst     True if the instruction we're decoding is valid

The following table specifies the opcode format and the control signals to be generated for some of the instruction types.

opcode opcode format itype aluop xsrc ysrc branch jal jalr plus4 resultselect memop toreg regwrite validinst
- default false false false false false false false false false 0 false false false
0000000 invalid false false false false false false false false false 0 false false false
0110011 R-type false true false false false false false false false 0 false true true

We have given you the control signals for the R-type instructions. You must fill in all of the other instructions in the table in src/main/scala/components/control.scala. Notice how the third line of the table (under the // R-type) is an exact copy of the values in this table.

Given the input opcode, you must generate the correct control signals. The template code from src/main/scala/components/control.scala is shown below. You will fill in where it says Your code goes here.

// Control logic for the processor

package dinocpu.components

import chisel3._
import chisel3.util.{BitPat, ListLookup}

/**
 * Main control logic for our simple processor
 *
 * Input: opcode:     Opcode from instruction
 *
 * Output: itype         true if we're working on an itype instruction
 * Output: aluop         true for R-type and I-type, false otherwise
 * Output: xsrc          source for the first ALU/nextpc input (0 is readdata1, 1 is pc)
 * Output: ysrc          source for the second ALU/nextpc input (0 is readdata2 and 1 is immediate)
 * Output: branch        true if branch
 * Output: jal           true if a jal
 * Output: jalr          true if a jalr instruction
 * Output: plus4         true if ALU should add 4 to inputx
 * Output: resultselect  false for result from alu, true for immediate
 * Output: memop         00 if not using memory, 10 if reading, and 11 if writing
 * Output: toreg         false for result from execute, true for data from memory
 * Output: regwrite      true if writing to the register file
 * Output: validinst     True if the instruction we're decoding is valid
 *
 * For more information, see section 4.4 of Patterson and Hennessy.
 * This follows figure 4.22 somewhat.
 */

class Control extends Module {
  val io = IO(new Bundle {
    val opcode = Input(UInt(7.W))

    val itype        = Output(Bool())
    val aluop        = Output(Bool())
    val xsrc         = Output(Bool())
    val ysrc         = Output(Bool())
    val branch       = Output(Bool())
    val jal          = Output(Bool())
    val jalr         = Output(Bool())
    val plus4        = Output(Bool())
    val resultselect = Output(Bool())
    val memop        = Output(UInt(2.W))
    val toreg        = Output(Bool())
    val regwrite     = Output(Bool())
    val validinst    = Output(Bool())
  })

  val signals =
    ListLookup(io.opcode,
      /*default*/           List(false.B, false.B, false.B, false.B, false.B, false.B, false.B, false.B, false.B,      0.U,   false.B, false.B,  false.B),

      Array(              /*     itype,   aluop,   xsrc,    ysrc,    branch,  jal,     jalr     plus4,   resultselect, memop, toreg,   regwrite, validinst */
      // R-format
      BitPat("b0110011") -> List(false.B, true.B,  false.B, false.B, false.B, false.B, false.B, false.B, false.B,      0.U,   false.B, true.B,   true.B),

      // Your code goes here.
      // Remember to make sure to have commas at the end of each line, except for the last one.

      ) // Array
    ) // ListLookup

  io.itype        := signals(0)
  io.aluop        := signals(1)
  io.xsrc         := signals(2)
  io.ysrc         := signals(3)
  io.branch       := signals(4)
  io.jal          := signals(5)
  io.jalr         := signals(6)
  io.plus4        := signals(7)
  io.resultselect := signals(8)
  io.memop        := signals(9)
  io.toreg        := signals(10)
  io.regwrite     := signals(11)
  io.validinst    := signals(12)
}

In this code, you can see that the ListLookup looks very similar to the table above. You will be filling in the rest of the lines of this table. As you work through each of the parts below, you will be adding a line to the table. You will have one line for each type of instruction (i.e., each unique opcode that for the instructions you are implementing).

You will not need to use the validinst signal. It is used for exceptions and other system-related instructions that we are not implementing in this assignment.

Important: DO NOT MODIFY THE I/O. You do not need to modify any other code in this file other than the signals table!

Important: Any don’t care lines should be set to 0! There may be some cases where some control signals could be 1 or 0 (i.e., you don’t care what the value is). You are required to set these lines to 0 for this assignment. If you do not set these lines to 0, you will not pass the control unit test on Gradescope.

Part 0: NextPC unit overview

In the last assignment, when you were required to run your CPU for multiple cycles, you used a simple adder to generate the next value for the pc which was simply pc+4 in all cases. In this assignment you will implement a much smarter unit, NextPC, which is responsible for the next value that must be assigned to the pc for the next cycle.

The NextPC unit recieves eight inputs:

The NextPC unit generates two outputs:

Given the inputs, you must generate the correct value for nextpc and taken. The template code from src/main/scala/components/nextpc.scala is shown below.

// Logic to calculate the next pc

package dinocpu.components

import chisel3._

/**
 * Next PC unit. This takes various inputs and outputs the next address of the next instruction.
 *
 * Input: branch         true if executing a branch instruction
 * Input: jal            true if executing a jal
 * Input: jalr           true if executing a jalr
 * Input: inputx         first input
 * Input: inputy         second input
 * Input: funct3         the funct3 from the instruction
 * Input: pc             the *current* program counter for this instruction
 * Input: imm            the sign-extended immediate
 *
 * Output: nextpc        the address of the next instruction
 * Output: taken         true if the next pc is not pc+4
 *
 */
class NextPC extends Module {
  val io = IO(new Bundle {
    val branch  = Input(Bool())
    val jal     = Input(Bool())
    val jalr    = Input(Bool())
    val inputx  = Input(UInt(32.W))
    val inputy  = Input(UInt(32.W))
    val funct3  = Input(UInt(3.W))
    val pc      = Input(UInt(32.W))
    val imm     = Input(UInt(32.W))

    val nextpc  = Output(UInt(32.W))
    val taken   = Output(Bool())
  })

  io.nextpc := io.pc + 4.U
  io.taken  := false.B

  // Your code goes here
}

In this template, the outputs, nextpc and taken, are set to always be pc+4 and false, respectively.

Before starting Part I, you must remove the parts related to pc+4 and replace it with an instance of NextPC unit and create proper wire connections for it. For this purpose, you must update src/main/scala/single-cycle/cpu.scala. In the next sections, you will gradually complete the body of NextPC unit.

Part I: R-types

In the last assignment, you implemented a subset of the RISC-V data path for just R-type instructions. This did not require a control unit since there were no need for extra MUXes. However, in this assignment, you will be implementing the rest of the RISC-V instructions, so you will need to use the control unit.

The first step is to hook up the control unit and get the R-type instructions working again. You shouldn’t have to change all that much code in cpu.scala from the first assignment after you applying changes regarding NextPC unit. All you have to do is to hook up the opcode to the input of the control unit and its output aluop and itype to the alu control unit. We have already implemented the R-type control logic for you. You can also use the appropriate signals generated from the control unit (e.g., regwrite) to drive your data path.

R-type instruction details

The following table shows how an R-type instruction is laid out:

31-25 24-20 19-15 14-12 11-7 6-0 Name
funct7 rs2 rs1 funct3 rd 0110011 R-type

Each instruction has the following effect. <op> is specified by the funct3 and funct7 fields. R[x] means the value stored in register x.

R[rd] = R[rs1] <op> R[rs2]

Testing the R-types

You can run the tests for this part with the following command:

sbt:dinocpu> testOnly dinocpu.SingleCycleRTypeTesterLab2

Part II: I-types

Next, you will implement the I-type instructions. These are mostly the same as the the R-types, except that the second operand comes from the immediate value contained within the instruction, rather than another register.

Important: The immediate generator will produce the shifted and sign extended value! You do not need to shift the immediate value outside of the immediate generator.

To implement the I-types, you should first extend the table in control.scala. Then you can add the appropriate MUXes to the CPU (in cpu.scala) and wire the control signals to those MUXes. HINT: You only need one extra MUX, compared to your R-type-only design.

In this section, you will (likely) also have to update your ALU control unit. In assignment 1, we ignored the aluop and itype inputs on the ALU control unit. Now that we are running the I-type instructions, we have to make sure that when we’re executing I-type instructions the ALU control unit ignores the funct7 bits. For I-type instructions, these bits are part of the immediate field!

I-type instruction details

The following table shows how an I-type instruction is laid out:

31-20 19-15 14-12 11-7 6-0 Name
imm[11:0] rs1 funct3 rd 0010011 I-type

Each instruction has the following effect. <op> is specified by the funct3 field.

R[rd] = R[rs1] <op> immediate

Testing the I-types

You can run the tests for this part with the following command:

sbt:dinocpu> testOnly dinocpu.SingleCycleITypeTesterLab2

Part III: lw

Next, we will implement the lw instruction. Officially, this is a I-type instruction, so you shouldn’t have to make too many modifications to your data path.

As with the previous parts, first update your control unit to assert the necessary control signals for the lw instruction, then modify your CPU data path to add the necessary MUXes and wire up your control. For this part, you will have to think about how this instruction uses the ALU. You will also need to incorporate the data memory into your data path, starting with this instruction.

Data memory port I/O

The data memory port I/O is not as simple as the I/O for other modules. It’s built to be modular to allow different kinds of memories to be used with your CPU design. We are planning to explore this further in Lab 4. If you want to see the details, you can find them in the mem-port-io.scala file.

The I/O for the data memory port is shown below. Don’t forget that the instruction and data memory ports look weird to use. You have to say io.dmem, which seems backwards. For this assignment, you can ignore the good and ready signals since memory will respond to the request in the same cycle.

Input:  address, the address of a piece of data in memory.
Input:  writedata, valid interface for the data to write to the address
Input:  valid, true when the address (and writedata during a write) specified is valid
Input:  memread, true if we are reading from memory
Input:  memwrite, true if we are writing to memory
Input:  maskmode, mode to mask the result. 0 means byte, 1 means halfword, 2 means word
Input:  sext, true if we should sign extend the result

Output: readdata, the data read and sign extended
Output: good, true when memory is responding with a piece of data
Output: ready, true when the memory is ready to accept another request

lw instruction details

The following table shows how the lw instruction is laid out:

31-20 19-15 14-12 11-7 6-0 Name
imm[11:0] rs1 010 rd 0000011 lw

lw stands for “load word”. The instruction has the following effect. M[x] means the value of memory at location x.

R[rd] = M[R[rs1] + immediate]

Testing lw

You can run the tests for this part with the following command:

sbt:dinocpu> testOnly dinocpu.SingleCycleLoadTesterLab2

Part IV: U-types

U-types are another type of instruction that look similar to the I-types. There are two of them you need to implement, described below.

lui instruction details

The following table shows how the lui instruction is laid out.

31-12 11-7 6-0 Name
imm[31:12] rd 0110111 lui

lui stands for “load upper immediate.” The instruction has the following effect. As in C and C++, the << operator means bit shift left by the number specified.

R[rd] = imm << 12

Important: The immediate generator will produce the shifted and sign extended value! You do not need to shift the immediate value outside of the immediate generator.

Use the diagram as a hint on how to modify your data path and control unit for this instruction. There are multiple different ways to implement this instruction (last year, we used a different design), so be careful to follow the diagram above!

auipc instruction details

The following table shows how the auipc instruction is laid out.

31-12 11-7 6-0 Name
imm[31:12] rd 0010111 auipc

auipc stands for “add upper immediate to pc.” The instruction has the following effect.

R[rd] = pc + imm << 12

Like previous part, use the diagram as a hint on how to modify your data path and control unit for this instruction.

Testing the U-types

You can run the tests for this part with the following command:

sbt:dinocpu> testOnly dinocpu.SingleCycleUTypeTesterLab2

Part V: sw

sw is similar to lw in function, and looks similar to an I-type. You’ll need to think about how to implement the changes needed for the data memory.

sw instruction details

The following table shows how the sw instruction is laid out.

31-25 24-20 19-15 14-12 11-7 6-0 Name
imm[11:5] rs2 rs1 010 imm[4:0] 0100011 sw

sw stands for “store word.” The instruction has the following effect. (Careful, while this looks similar to lw, it has a very different effect!)

M[R[rs1] + immediate] = R[rs2]

Testing sw

You can run the tests for this part with the following command:

sbt:dinocpu> testOnly dinocpu.SingleCycleStoreTesterLab2

Part VI: Other memory instructions

We now move on to the other memory instructions. Make sure your lw and sw instructions work before moving on to this part.

Other memory instruction details

The following table show how the other memory instructions are laid out. lw and sw are included again as a reference.

31-25 24-20 19-15 14-12 11-7 6-0 Name
imm[11:5] imm[4:0] rs1 000 rd 0000011 lb
imm[11:5] imm[4:0] rs1 001 rd 0000011 lh
imm[11:5] imm[4:0] rs1 010 rd 0000011 lw
imm[11:5] imm[4:0] rs1 100 rd 0000011 lbu
imm[11:5] imm[4:0] rs1 101 rd 0000011 lhu
imm[11:5] rs2 rs1 000 imm[4:0] 0100011 sb
imm[11:5] rs2 rs1 001 imm[4:0] 0100011 sh
imm[11:5] rs2 rs1 010 imm[4:0] 0100011 sw

l and s mean “load” and “store,” as mentioned previously. b means a “byte” (8 bits), while h means “half” of a word (16 bits). u means “unsigned.”

The instructions have the following effects. sext(x) stands for “sign-extend x.” As in C and C++, & stands for bit-wise AND.

Hint: The data memory port has mask and sext (sign extend) inputs. You do not need to mask or sign extend the result outside of the data memory port. The data memory port takes care of these details for you.

lb:  R[rd] = sext(M[R[rs1] + immediate] & 0xff)
lh:  R[rd] = sext(M[R[rs1] + immediate] & 0xffff)
lw:  R[rd] = M[R[rs1] + immediate]
lbu: R[rd] = M[R[rs1] + immediate] & 0xff
lhu: R[rd] = M[R[rs1] + immediate] & 0xffff
sw:  M[R[rs1] + immediate] = R[rs2]
sb:  M[R[rs1] + immediate] = R[rs2] & 0xff
sh:  M[R[rs1] + immediate] = R[rs2] & 0xffff

Testing the other memory instructions

You can run the tests for this part with the following command:

sbt:dinocpu> testOnly dinocpu.SingleCycleLoadStoreTesterLab2

Part VII: Branch instructions

This part is a little more involved than the previous instructions. First, you will update the NextPC unit. Then, you will update other necessary modules (e.g. control unit, ALU control if needed, etc) and then wire up the other necessary MUXes.

Branch instruction details

The following table show how the branch instructions are laid out.

imm[12, 10:5] rs2 rs1 funct3 imm[4:1, 11] opcode Name
31-25 24-20 19-15 14-12 11-7 6-0  
imm[12, 10:5] rs2 rs1 000 imm[4:1, 11] 1100011 beq
imm[12, 10:5] rs2 rs1 001 imm[4:1, 11] 1100011 bne
imm[12, 10:5] rs2 rs1 100 imm[4:1, 11] 1100011 blt
imm[12, 10:5] rs2 rs1 101 imm[4:1, 11] 1100011 bge
imm[12, 10:5] rs2 rs1 110 imm[4:1, 11] 1100011 bltu
imm[12, 10:5] rs2 rs1 111 imm[4:1, 11] 1100011 bgeu

b here stands for branch. u again means “unsigned.” The other portion of the mnemonics stand for the operation, either:

The instructions have the following effects. The operation is given by funct3 (see above).

if (R[rs1] <op> R[rs2])
  pc = pc + immediate
else
  pc = pc + 4

Updating your NextPC unit for branch instructions

In this part you will be updating the NextPC component to account for branch instructions. Similar to the CPU implementation in the book, the NextPC will compute whether or not a branch is taken (outputting its result in taken, true if the branch is taken and false if the branch is not taken).

You must take the RISC-V ISA specification and implement the proper control to choose the right type of branch test. You can find the specification in the following places:

You must now extend NextPC module with additional control to generate correct value for nextpc and correct result for taken. As a helpful tip, it’s important to remember that the funct3 wire helps differentiate between different branch instructions.

See the Chisel getting started guide for examples. You may also find the Chisel cheat sheet helpful.

HINT: Use Chisel’s when / elsewhen / otherwise, or MuxCase syntax. You can also use normal operators, such as <, >, ===, =/=, etc.

Important Note: In this assignment you will not use the taken output of NextPC unit anywhere in your single cycle CPU. However, we test if your NextPC unit generates correct value for it. You will utilize taken in the next assignment.

Testing your NextPC unit

We have updated the tests for your NextPC unit. The tests, along with the other lab2 tests, are in src/test/scala/labs/Lab2Test.scala.

In this part of the assignment, you only need to run the NextPC unit tests. To run just these tests, you can use the sbt comand testOnly, as demonstrated below.

sbt:dinocpu> testOnly dinocpu.NextPCBranchTesterLab2

Implementing branch instructions

Next, you need to wire the nextpc output from the NextPC unit into the data path. You can follow the diagram given in the single cycle CPU design section.

Testing the branch instructions

You can run the tests for the branch instructions with the following command.

sbt:dinocpu> testOnly dinocpu.SingleCycleBranchTesterLab2

Part VIII: jal

Next, we look at the J-type instructions. You can think of them as “unconditional branches.”

jal instruction details

The following table shows how the jal instruction is laid out.

31-12 11-7 6-0 Name
imm[20, 10:1, 11, 19:12] rd 1101111 jal

jal stands for “jump and link.” The instruction has the following effect.

pc = pc + imm
R[rd] = pc + 4

You must properly update any required entities in your code (e.g. the control unit, NextPC unit, etc). Finally, you should wire up any necessary MUXes.

Testing jal

You can run the tests for changes you made for NextPC in this part with the following command:

sbt:dinocpu> testOnly dinocpu.NextPCJalTesterLab2

You can run the tests for this part with the following command:

sbt:dinocpu> testOnly dinocpu.SingleCycleJALTesterLab2

Part IX: jalr

jalr is very similar to jal, with one difference. Unlike jal, jalr has the format of an I-type instruction.

jalr instruction details

The following table shows how the jalr instruction is laid out.

31-20 19-15 14-12 11-7 6-0 Name
imm[11:0] rs1 000 rd 1100111 jalr

jalr stands for “jump and link register.” The instruction has the following effect. (Careful, there’s one major difference between this and jal!)

pc = R[rs1] + imm
R[rd] = pc + 4

You must properly update any required entities in your code (e.g. the control unit, NextPC unit, etc). Finally, you should wire up any necessary MUXes.

You can run the tests for changes you made for NextPC in this part with the following command:

sbt:dinocpu> testOnly dinocpu.NextPCJalrTesterLab2

Testing jalr

You can run the tests for this part with the following command:

sbt:dinocpu> testOnly dinocpu.SingleCycleJALRTesterLab2

Testing the entire NextPC module

Now, that you have fully implemented the NextPC unit, you can run the tests for the whole unit with the following command:

sbt:dinocpu> testOnly dinocpu.NextPCTesterLab2

Part X: Full applications

At this point, you should have a fully implemented RISC-V CPU! In this final part of the assignment, you will run some full RISC-V applications.

We have provided four applications for you.

If you have passed all of the above tests, your CPU should execute these applications with no issues! If you do not pass a test, you may need to dig into the debug output of the test.

Important Note: We strongly encourage you to use single stepper to test your design for full applications. It will let you step through the execution one cycle at a time and print information as you go. Details on how to use the single stepper can be found in the documentation. You can also watch the video we have provided in the link below to learn how to debug using single stepper. As mentioned earlier, the videos were originally made for spring quarter 2020 (sq20). Just in case you wanted to use any command or text from these videos which contains ‘sq20’, you just need to convert it to ‘wq21’ to be applicable to your materials for the current quarter.

DinoCPU - Debugging your implementation

Testing full applications

You can run all of the applications at once with the following test.

sbt:dinocpu> testOnly dinocpu.SingleCycleApplicationsTesterLab2

To run a single application, you can use the following command:

sbt:dinocpu> testOnly dinocpu.SingleCycleApplicationsTesterLab2 -- -z <binary name>

Grading

Grading will be done automatically on Gradescope. See the Submission section for more information on how to submit to Gradescope.

Name Percentage
Each instruction type 10% each (× 9 parts = 90%)
Full programs 10%

Submission

Warning: read the submission instructions carefully. Failure to adhere to the instructions will result in a loss of points.

Code portion

You will upload the three files that you changed to Gradescope on the Lab 2 assignment.

Once uploaded, Gradescope will automatically download and run your code. This should take less than 5 minutes. For each part of the assignment, you will receive a grade. If all of your tests are passing locally, they should also pass on Gradescope unless you made changes to the I/O, which you are not allowed to do.

Note: There is no partial credit on Gradescope. Each part is all or nothing. Either the test passes or it fails.

Academic misconduct reminder

You are to work on this project individually. You may discuss high level concepts with one another (e.g., talking about the diagram), but all work must be completed on your own.

Remember, DO NOT POST YOUR CODE PUBLICLY ON GITHUB! Any code found on GitHub that is not the base template you are given will be reported to SJA. If you want to sidestep this problem entirely, don’t create a public fork and instead create a private repository to store your work. GitHub now allows everybody to create unlimited private repositories for up to three collaborators, and you shouldn’t have any collaborators for your code in this class.

Hints

Single stepper

You can also use the single stepper to step through the execution one cycle at a time and print information as you go. Details on how to use the single stepper can be found in the documentation and in DinoCPU - Debugging your implementation.

printf debugging

This is the best style of debugging for this assignment.