GitHub Classroom link to the starter code. Make sure you have the latest version of DLUnit. You can download it here.

For this project, you will use JLS to build the Single Cycle CPU described in Chapter 7 of the Harris and Harris textbook (Chapter 4 in the Patterson and Hennessy textbook).

You will complete this project in two phases:

• Phase 1: Use the control unit I provide to get the basic instructions working.
• Phase 2: Add additional instructions (which requires modifying my control unit).

It is critically important that you thoroughly test Phase 1 before moving onto Phase 2. Find me immediately if you have any trouble getting the testing software to work. If you don't have the testing software working, you really have no idea whether your CPU is functioning correctly.

Be sure to read this entire document (especially the hints) before you begin. Overlooking any of the instructions or hints can lead you down a dead-end path that will waste hours of your valuable time.

Pre-requisites

• how to turn assembly language statements into machine language statements (you did this for Lab 6), and
• how the single-cycle CPU shown in Figure 7.14 works.

Phase 1

Build the Single-Cycle CPU shown in in Figure 7.14. To help you get started, the starter code contains StarterCPU_w22.jls which includes a

• register file,
• ALU,
• instruction memory,
• data memory, and
• "starter" control unit.

Before you begin, rename the starter CPU file PHSingleCycleCPU.jls. You aren't required to use the provided components; but, building your own can be tedious. The purpose of the "starter" control unit is so that you can debug your CPU's datapath separately from the control unit. Once you have the core instructions working, then modify my control unit to support additional instructions. (This is phase 2.)

Interface

At the end of Phase 1, your CPU should support the following instructions:

Phase 1 Testing

• Name the circuit for the entire CPU PHSingleCycleCPU.jls. (Did you remember to rename the starter file?)
• Name the instruction memory InstMemory.
• Name the register file RegisterFile.
• Main Memory is simply a built-in RAM. Name it MainMemory and configure it with 2²⁰ words.

DLUnit has a built-in test class that can test this CPU. In addition to the .jls file, you also provide an assembly file as input. DLUnit will (1) simulate the assembly code using MARS, (2) simulate the assembly code using your CPU, then (3) compare the final state of the registers from each simulation. The test will pass if your CPU ends in the same state as the CPU simulated by MARS.

IMPORTANT: DLUnit only checks the final state of the CPU. If you write to a register more than once, the intermediate values of that register won't get checked.

The syntax for running DLUnit to test a CPU is java -jar DLUnit.jar jls_file.jls builtin.SingleCycleCPUTest --param assembly_file.a To test your code, you will need to write several example assembly programs. The starter code includes a few example testing programs; however, these programs alone won't test your CPU well.

Avoid the following cases when writing your phase 1 tests:

• The ALU has a very simple implementation of slt/slti. It will give the wrong answer if the inputs overflow when subtracting.
• andi and ori will give incorrect results if the immediate value is negative (or has bit 15 set to 1). You'll fix this in Phase 2.

To run the Phase 1 tests, click on the "Actions" tab on your project's GitHub page, then select "Part 1 Workflow"

Debugging

The best way to debug a circuit that is failing tests is to use JLS to step through each instruction. The starter code includes a bash script named marsAssembler that takes an assembly file as input and generates machine code. To debug your circuit, run marsAssembler and redirect its output to a file named instructions. Your circuit's Instruction Memory element is configured to load data from this file. So, if you launch JLS in a directory containing instructions you will be able to step through your CPU instruction by instruction. Important: marsAssembler is a bash script. It won't run on the Windows command line. You will need to use Cygwin, WSL, or something similar to run it. Another option is to look inside the bash script and just run the Windows version of that command "by hand".

Note: marsAssembler only works with DLUnit version 1.1.1 or newer (built 3 November 2020). You may need to download the most recent version (linked here). Also, make sure marsAssembler and DLUnit.jar are in the same directory.

Phase 1 Hints

• The built-in Register File uses negative-edge triggered flip-flops. Your registers (e.g., the program counter) should also use negative-edge triggered flip flops. When using negative-edge triggered flip-flops, the clock's falling edge defines the beginning of each CPU cycle.
• The WE, OE, and CS inputs to RAM and ROM are active low. (WE stands for Write Enable; OE is Output Enable; and CS is Chip Select. )
• Even though the RAM and ROM control inputs are active low, none of the control wires are active low. Specifically, the memWrite and memRead wires are 1 when a memory write or memory read is desired.
• The built-in RAM and ROM circuits are word addressable, whereas the memories in the textbook are byte addressable. Make sure your circuit converts between them correctly. (The Instruction Memory circuit I provide takes bytes as input, not words.)
• Read carefully about how MIPS implements jump and branch. In particular, notice (1) how MIPS fills bits 28-31 of the jump target and (2) that the branch offset is added to PC + 4, not PC.
• You need a minimum of two tests for beq.
• Make use of probes, watches, and displays to help debug your circuit.
• Be aware of pseudo instructions when writing MIPS code. For example, lw $16, val1 is a pseudo instruction. It won't work unless both lui and lw work.

Phase 2

You have two main tasks to complete for Phase 2:

1. Add additional instructions (which requires modifying the control unit).
2. Determine the critical path for the CPU and set the clock accordingly.

Implement Additional Instructions

Implement these additional instructions:

To implement these instructions, you will need to both (1) add additional data paths in the CPU, and (2) add support for these instruction in the control unit. In fact, you will need to add additional control wires.

The provided control unit is a very simple microcode. If you look inside the control unit, you will see that it is primarily just a ROM (Read Only Memory). Each op code is just an index into the ROM; and the bits stored at that index are the values to be placed on the control wires. In other words, the control unit is just a lookup table. If you right-click on the ROM inside the control unit and select "Modify", then select "Built-in", you can see this microcode. The text field contains two columns. The first is the opcode (in hex), and the second is the bits returned (in hex). To add new instructions, you need only add the hex specifying the control wire values for that op code.

Notice however, that you will need additional control wires for some of the instructions. This control unit has three unused wires; but, you will need at least 4. Thus, you have two choices:

1. Create a new ROM unit with a larger word size in order to add extra bits, or
2. Consolidate two or more of the existing control wires into one, and repurpose the newly "free" wire.

This microcode handles function codes in a special way. Notice that the ROM contains 27=128 lines of data, not 26=64. Lines 1-63 in the ROM contain the control values for each op code except 0. Lines 64-127 contain the control values for instructions that use an op-code/function pair. Specifically, line 64+x contains the control values for the instruction with a function code of x. (Remember, only instructions with an op code of 0 use a function code.) For example, add has an op code of 0 and a function code of 0x20 = 32. Therefore, the control values for add are stored on line 64+32 = 96 which is 0x60.

Phase 2 Hints

• The starter code contains StarterControl.jls. You may want to make your changes to this file, then import it into the CPU when you are done. using a separate .jls file will both you and me to test the control unit separately from the CPU. (I won't be able to help you debug your CPU if I can't test your control unit.)
• Not all I-type instructions are sign-extended. You will need to add a control wire to suppress the sign extension for these instructions. Read the instruction description in the textbook (p620 in Harris and Harris, 2^nd ed.) very carefully. You may be surprised by which immediate instructions are sign extended and which are not.
• The ALU does not correctly implement slt and sltu. You may add hardware to fix them. (You built this hardware for Project 1.) This is optional.
• This CPU uses different ALU op codes than the book. The comment inside the ALU contains the correct list of op codes.
• Notice that some op codes are also function codes (e.g., op code of 0x20 for halt and function code of 0x20 for add). Be sure your tests account for this.

To run the Phase 2 tests, click on the "Actions" tab on your project's GitHub page, then select "Part 2 Workflow"

Submission and grading

In order to get an 'M' or 'E' for this project, you must have

• Written thorough tests for your CPU, and
• Adjusted the clock period to be "tight" (i.e., very close to the minimum value that will work).

To submit your project:

1. Make sure all .jls files include a comment with your name.
2. Make sure PHSingleCycleCPU.jls includes a comment with the clock period.
3. Make sure your repository includes all your test files / test plans.
4. Add a commit message with [Grade Me] and push.

Updated Tuesday, 22 February 2022, 2:54 PM