微信客服：xiaoxionga100
微信客服：ITCS521
logisim和小部分的python代写-CS2630
时间：2021-05-06
CS2630: Computer Organization
Homework 5
Single-cycle MIPS processor with I/O
1 Table of Contents
2 GOALS FOR THIS ASSIGNMENT .....................................................................................................2
3 INTRODUCTION ............................................................................................................................2
4 TEAMS .........................................................................................................................................2
5 READING THIS DOCUMENT ...........................................................................................................3
6 GETTING STARTED ........................................................................................................................3
7 THE PROCESSOR ...........................................................................................................................5
7.1 ONE OR MORE STUDENTS ................................................................................................................6
7.2 TWO OR MORE STUDENTS ................................................................................................................6
7.3 INSTRUCTION DETAILS .....................................................................................................................7
7.3.1 LW INSTRUCTION.................................................................................................................................... 7
7.3.2 CLZ INSTRUCTION ................................................................................................................................... 7
7.4 WHAT YOU MUST IMPLEMENT ..........................................................................................................7
7.5 TIPS ON BUILDING THE CONTROL UNIT ................................................................................................8
7.6 HOW YOU MUST TEST .....................................................................................................................8
7.7 .....................................................................................................................................................8
7.8 TESTING TIPS ................................................................................................................................8
8 ASSEMBLING AND RUNNING NEW PROGRAMS .............................................................................9
9 INPUT/OUTPUT (IO) ................................................................................................................... 14
9.1 WHAT YOU MUST DO ................................................................................................................... 15
10 REQUIREMENTS AND GRADING ................................................................................................ 15
10.1 RUBRIC ................................................................................................................................... 15
10.2 EXAMPLE SCORES ...................................................................................................................... 16
10.3 ADDITIONAL REQUIREMENTS ........................................................................................................ 16
10.4 SUBMISSION CHECKLIST ............................................................................................................... 16
11 RECOMMENDED APPROACH TO FINISHING THE PROJECT .......................................................... 17
12 HELP AND TIPS ......................................................................................................................... 18
12.1 GENERAL TIPS ........................................................................................................................... 18
12.2 THE TEST FAILED, NOW WHAT? ..................................................................................................... 18
12.3 TEAMWORK TIPS ....................................................................................................................... 20
12.4 WHERE TO GET HELP .................................................................................................................. 20
13 ACADEMIC HONESTY ................................................................................................................ 21
14 ACKNOWLEDGEMENTS ............................................................................................................. 21
2 Goals for this assignment
• Design and implement a substantial digital system
• Add new instructions to the datapath and control
• Use robust testing methodology in digital logic design
• Learn how to load binary code from the assembler into the instruction memory
• Create MIPS programs that adequately test the processor
3 Introduction
In HW4 you built a major component of a MIPS processor, and in HW5 you will build the rest of
a processor, as well as IO to make it useful. As in part 1, we provide the top-level skeleton file
and test circuits, and you will provide the implementation and additional tests.
4 Teams
You can work either individually, as a team of 2, or as a team of 3. The number of students will
determine the requirements of the project.
• 1 student: the basic set of instructions (see section: The Processor)
• 2 students: all of the above plus the additional instructions (see section: The Processor)
• 3 students: all of the above plus IO (see section: Input/Output (IO))
Feel free to do more than the requirements for your team size; however, there is no extra
credit.
5 Reading this document
There is a lot here. I recommend thinking of the project in three components: datapath,
control, and testing. At some point you should read the whole document, but here's what you
should read first if you want to get started fast but still be thorough.
• Datapath expert:
1. Getting started, with emphasis on 3, 4a, and 4b
2. The Processor including What you must implement and excluding Tips on building
the control unit
3. Read: Mips Processor (ICON) if you haven't yet
4. Recommended approach to finishing the project
5. Teamwork Tips
6. Where to get help
• Control unit expert:
1. Getting started, skimming what is after step 2
2. The Processor including What you must implement and emphasizing Tips on
building the control unit
3. Read: Mips Processor (ICON) if you haven't yet
4. Recommended approach to finishing the project
5. Teamwork Tips
6. Where to get help
• Testing expert:
1. Getting Started, emphasis on getting it to work with either your alu/regfile or the
provided ones
2. The Processor, emphasis on How you must test and Testing tips.
3. Read: Mips Processor (ICON) if you haven't yet
4. Assembling and running new programs
5. Recommended approach to finishing the project
6. Tips
7. Teamwork Tips
8. Where to get help
6 Getting started
1. Download the starter code from
https://github.com/bmyerz/project2-mips-processor/archive/refs/heads/proj2-part2-sp21.zip
or, if you are using git, you can instead clone the repository. Just make sure checkout the
branch proj2-part2-sp21. That is, do the following:
git clone https://github.com/bmyerz/project2-mips-processor.git
git checkout proj2-part2-sp21
2. Try running the tests
Use the same method for running Linux commands that you used in part 1 of the project.
i. Run the tests
make p2sc
You should see output like
cp alu.circ alu-control.circ regfile.circ mem.circ cpu.circ control.circ iodevices.circ tests
cd tests && python3 ./test.py p2sc | tee ../TEST_LOG
Testing files...
Error in formatting of Logisim output (check ./starter_test.circ):
you have a non-integer in this list: ['xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'00000000000000000000000000000000', 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx']
FAILED test: starter test (Error in the test)
Passed 0/1 tests
The x’s indicate that those bits are disconnected.
3. Copy your alu.circ and alu-control.circ solution from HW4 into the new directory.
4. To get the register file component, follow these instructions. (Also, if you prefer to use a
reference solution to the ALU/ALU Control, follow the instructions at (b)).
a. To use the register file replacement
download regfile.circ and cs3410.jar from the HW5 ICON
You must put regfile.circ in the base directory of your project.
You must have two copies of the cs3410.jar file: one in the base directory and one in the
tests/ directory.
A nice feature of this version of regfile.circ is that it uses a fancy register file that shows
the values of the registers, which may make debugging a bit easier.
b. To use the reference implementation of the ALU (optional)
You may choose to use one or both of alu.circ and alu-control.circ.
download ALU.jar from the HW5 ICON
download alu.circ and/or alu-control.circ from the HW5 ICON
You must put alu.circ and/or alu-control.circ in the base directory of your project (as it
was in HW4).
You must have two copies of the ALU.jar file: one in the base directory and one in the
tests/ directory.
5. You can check if you copied the ALU and register file (whether using yours or ours)
properly into your project folder by running the part 1 tests and seeing that they pass.
make p1
cp alu.circ alu-control.circ regfile.circ tests
cd tests && python3 ./test.py p1 | tee ../TEST_LOG
Testing files...
PASSED test: ALU add (with overflow) test, with output in
python
PASSED test: ALU arithmetic right shift test
PASSED test: ALU Control R-type Test
PASSED test: ALU Control I-type Test
PASSED test: RegFile read/write test
PASSED test: RegFile $zero test
PASSED test: RegFile debug outputs test
Passed 7/7 tests
6. When you open up cpu.circ in Logisim, you’ll see that alu, mem, regfile, control, and alu-
control are all available as subcircuits.
7 The processor
Your team’s task is to design, implement, and test a single-cycle MIPS processor. The processor
must support a specific subset of instructions from the 32-bit MIPS instruction set architecture.
That subset is:
7.1 One or more students
Instruction
sll
srl
sra
add
addu
addiu
addi
j
and
or
andi
ori
lw
sw
beq
bne
7.2 Two or more students
Additionally, support these instructions
Instruction
jr
slt
sltu
sltiu
slti
lui
clz
The specification of the instructions is exactly the one in the “MIPS reference card” or “Human-
friendly MIPS reference card” on (find in Modules on ICON) except for the following
differences.
If you are in this category, you should expand upon alu-control.circ to calculate the ALU’s
Switch for slt, sltu, sltiu, and slti. You might do that in any of the following ways:
a) If you are using your own alu-control.circ, modify it.
b) If you are using the reference solution to alu-control.circ, you can modify that file. Just
be aware that you need to add circuits to alu-control.circ that work together with the
“black box” subcircuit that is already in there.
c) Regardless of which alu-control.circ you are using, an alternative is just to put the new
logic outside of there, directly in cpu.circ.
7.3 Instruction details
7.3.1 lw instruction
lw’s opcode is 35. This matches MARS and the MIPS Green Sheet. We mention this because the
human friendly MIPS reference sheet assigns lw the wrong opcode.
7.3.2 clz instruction
The clz instruction is “count leading zeroes”. This instruction is not listed in the MIPS reference
sheet, but MARS supports it as a core instruction.
The clz is a MIPS instruction that was not covered in the class. To find its
behavior, look at the Help menu in MARS.
You must use MARS to reverse engineer the bit encoding of this instruction. Try assembling a
program with clz, with different values of the argument registers. It is actually not R-type, I-
type, or J-type but a fourth type of instruction that is similar to R-type.
HINT: To implement clz, use a combination of components available in the Arithmetic library.
7.4 What you must implement
You must modify cpu.circ to implement the CPU. Do not modify or move the inputs and
outputs. You may use sub-circuits in your implementation as long as remains the
top level circuit of cpu.circ. You may use any built-in Logisim components.
For your Data Memory, you can use mem.circ. That module can read or write one memory
location on every cycle. When Write_En=1, the memory will write data Write_Data to the
location given by Address on the next rising edge of the clock, and when Write_En=0 the
Read_Data port will have the value at the location given by Address.
Note that the cpu.circ file has five output pins across the top. These provide hardwired access
to five of the registers of the register file. You can connect them directly to the five outputs at
the top of the Register File we provided you.
7.5 Tips on building the control unit
Your control unit should go inside of control.circ.
Building a control unit can be very complex and error prone due to the large number of input
and output bits, so you should try to reduce complexity where possible. Specifically,
• Rely on a logic analyzer, such as Logisim's logic analyzer tool (found at Project | Analyze
circuit). It will allow you to input a function as a truth table and automatically generate
the circuit. Note that the logic analyzer requires 1-bit inputs, so you'll have to split multi-
bit wires into individual bits.
• Use "don't cares" to simplify the logic (the logic analyzer represents them as X's)
• Keep in mind that most control signals are calculated from solely the opcode.
7.6 How you must test
7.7
1. Run the tests with the command make p2sc.
2. To ensure you pass the autograder, you must test your CPU beyond the given tests.
Adding new tests is similar to HW4, except:
• the sample test harness to copy is one of cpu_test_template.circ,
cpu_lite_test_template.circ, or cpu_end_test_template.circ instead of alu-
harness.circ.
• instead of loading the test inputs into ROMs, you will load the instruction
memory (it is a ROM) with an assembled program.
See the section “Assembling and running new programs” for a step-by-step guide.
See the get_test_format function in tests/decode_out.py for the format of the output of
the "cpu" tests. The first list is the headers and the second list is the bit widths.
['$s0 Value', '$s1 Value', '$s2 Value', '$ra Value', '$sp Value', 'Time Step', 'Fetch Addr',
'Instruction'], [32,32,32,32,32,8,32,32]
7.8 Testing tips
• Since there is some effort to adding a new test, try to balance keeping the tests simple
while including multiple instructions
• Make sure to check different cases, such as branch, not branch, branch forward, branch
backward
• Having to give the expected values of the 5 registers, fetch Address, and instruction bits
on every single clock cycle can be overkill for more complex tests. To help you, we've
included different types of tests that check only some of the outputs.
Type Checks outputs Recommendation Template
cpu '$s0 Value', '$s1
Value', '$s2 Value',
'$ra Value', '$sp
Value', 'Time Step',
'Fetch Addr',
'Instruction'
use for short/simple
tests, where you want
to check everything
on every cycle
cpu_test_template.circ
cpu-lite '$s0 Value', '$s1
Value', '$s2 Value',
'$ra Value', '$sp
Value', 'Time Step'
use for tests where
you don’t want to
have to check fetch
address and
instruction, but you
still want to check the
register values on
every cycle
cpu_lite_test_template.circ
cpu-end '$s0 Value', '$s1
Value', '$s2 Value',
'$sp Value'
use for tests where
you only want to
check the state of
some registers when
they change.
cpu_end_test_template.circ
Note: To understand why cpu-end tests do not check outputs every cycle, rather only
when the registers change, it is helpful to know that Logisim only prints a new line of
output when one of the output values changes. For cpu and cpu-lite, the inclusion of
"Time Step" ensures that a line gets printed every cycle.
You specify the test Type by making the last argument to TestCase be "cpu", "cpu-lite", or "cpu-
end" in your tests.py file.
Add your expected outputs as a list of lists in the Python file as described in HW4.
8 Assembling and running new programs
The project kit comes with a copy of Mars (mars.jar) so that you can assemble MIPS programs
in the format required for the instruction memory. What follows is the workflow that we
recommend for writing MIPS programs and running them on your processor.
1. Edit your MIPS program in MARS (as you did in in prior labs).
You should set the following “Memory Configuration…”, to tell MARS to assemble the
addresses the same way our command line assembler does (.text starts at address
0x00000000 and .data starts at address 0x00002000)
2. Test and debug your program in MARS (as you did in prior labs).
3. Save your MIPS program to a file. We’ll assume the name “foo.s” for these directions,
but you should name the file appropriately.
4. When you are ready to run your program on the MIPS processor, you will use the
assembler provided with the project kit.
Make sure you know the file path of your MIPS file. It’s easiest if you just save it to the base
directory of your project.
i. Change directories to path of your project folder
cd /path/to/project (/path/to should be the actual file path)
ii. Double check that the MIPS program is in your directory by running ls.
Makefile
TEST_LOG
alu-harness.circ
alu.circ
alu-control.circ
cpu.circ
example_IO_controller.circ
foo.s
mars-assem.sh
mars.jar
mem.circ
regfile-harness.circ
regfile.circ
tests
iii. Run the assembler on your MIPS program
./mars-assem.sh foo.s
If your assembly file didn’t have a .data section you might see a message, but it is
just a warning.
This segment has not been written to, there is nothing to dump.
cat: data_t.hex: No such file or directory
rm: data_t.hex: No such file or directory
iv. List the files in the folder again (by running ls) to check that there was output.
Makefile
TEST_LOG
alu-harness.circ
alu.circ
alu-control.circ
cpu.circ
example_IO_controller.circ
foo.s
foo.s.data.hex
foo.s.text.hex
mars-assem.sh
mars.jar
mem.circ
regfile-harness.circ
regfile.circ
tests
You should see a .text.hex file, which contains the text segment. If you had a .data section, you
should also see a .data.hex file, which contains data memory contents up to and including the
.data segment.
5. Now you can load the program into your processor in Logisim. Make a copy of one of
the three templates, depending on what type of test you want: cpu_test_template.circ,
cpu_lite_test_template.circ, or cpu_end_test_template.circ. Call your copy
foo_test.circ. And then open that new file in Logisim.
i. Load the instruction memory by right-clicking the Instruction Memory ROM and
choosing Load Image...
Navigate to the foo.s.text.hex file
ii. Load the data memory (OPTIONAL; only need to do this step if your MIPS program
has a .data section). The data memory implementation is provided to you in
mem.circ, which you should use as a “Logisim library…” in your CPU.
right-click the RAM | Load image | navigate to foo.s.data.hex
You can double-check that your data was loaded into the expected address in memory
by right clicking the RAM > Edit Contents… > and scrolling down to the row for 002000 to see
the data.
iii. Make sure to Save the circuit file containing the instruction memory so that you
don’t have to load the program again (just like you had many test harnesses in Part
1, you will just have another copy the template test for each test program).
Note that you will have to load your data memory each time you change
programs or “Reset Simulation”. Logisim applies the reset to RAMs but not ROMs.
Therefore, we suggest making your tests not have a .data section so that you don't
have the inconvenience of loading the RAM ahead of time.
6. Now you can simulate your CPU by ticking the clock. Notice that once the instruction
memory gets to instructions 0x00000000, your processor should just be executing
NOOPs (short for “no operation”) until you stop the simulation. You don’t have to do
anything special for implementing NOOP: notice that if you reverse engineer machine
code 0x00000000, you’ll see it is an sll that tries to write to $zero.
9 Input/output (IO)
You now have a processor that executes real MIPS programs! Now it is time to make it more
interesting by including some IO devices. We will use a methodology for IO called Memory
mapped IO (MMIO).
The way MMIO works is that some range of addresses is reserved for controlling IO devices
rather than accessing memory.
If you look back at MARS's Memory Configuration (Settings > Memory Configuration), you'll see
that addresses starting at 0x00007f00 are reserved for MMIO.
An output device will take in the same Address/MemWrite/WriteData signals as the data
memory, except it will listen for its range of addresses (0x00007F00 and above). When
MemWrite=1 and the Address is in range, the output device will be written to.
We've provided an example module in example_IO_controller.circ. It is a single LED
that can be turned on by writing a 1 to address 0x00007F00 and turned off by writing a 0 to
address 0x00007F00.
There are more IO devices besides the LED available in Logisim's Input/Output folder.
You can experiment with how they work. Post to Piazza discussion if you have trouble
understanding how to control one of them.
9.1 What you must do
Your task is to implement an interesting application that uses some input and/or output device.
i. In iodevices.circ, build an IO controller for the device that you want to use and
attach it to the appropriate signals in your cpu. The iodevices.circ should not contain
its own clock; rather, it should have an input pin for the clock. Your iodevices
subcircuit should be placed in the top level of cpu.circ OR in a clearly labeled
subcircuit within cpu.circ. The device must be more than the single LED example
(i.e., at least two LEDs but other devices are encouraged, too). Write as short of a
MIPS test program as possible that will read or write (depending on if you picked an
input or output) the device. Call the test program iotest.s and the test harness
iotest.circ.
a. Note that if you choose to use an input device (e.g., button, joystick) then you’ll
want to capture the input into a register. Your program can use lw to read that
register with MMIO.
ii. Optionally, you may include a more interesting program that shows off your IO
device. Include a test harness, as well as a brief description in a file called
io_readme.txt.
iii. Pat yourself on the back. You've built a working and useful computer! Show off your
work to others. (just don't share copies of your files)
10 Requirements and grading
10.1 Rubric
You can also see ICON for the rubric that we'll use to grade
• 108 points – Demonstrate your processor works correctly. The processor passes the
autograder tests (we have hidden tests that cover all required functionality). Passing the
starter test will get you 76.5 points. Then you will earn further points for every
additional test you pass.
• 42 points – Demonstrate that you tested your processor. You submitted test files to
show you considered each instruction and corner cases. You will earn 21 of these points
for having just 1 new test and the remainder for covering the rest of the
instructions/cases.
o For teams of 3: 65% of the 42 points are for the tests and 35% of the 42 points
are for the I/O requirements
o For each test, you must include the .s file, changes to test.py, and the .circ file!
10.2 Example scores
To make it really clear what your priorities should be, here are some examples of scores.
• 94.75% (A): approximately ¾ of tests passing (100.125/108) and you wrote tests for all
cases (42/42)
• 89.5% (B+): approximately ½ tests passing (92.25/108) and you wrote tests for all cases
(42/42)
• 84.25% (B): approximately ¼ tests passing (84.375/108) and you wrote tests for all cases
(42/42)
• 79% (C+): one test passing (76.5/108) and you wrote tests for all cases (42/42)
• 75.5% (C): approximately ½ tests passing (92.25/108) and you wrote one test (21/42)
• 72% (C-): all tests passing (108/108) and you wrote zero tests (0/42)
• 70.25% (C-): approximately ¼ tests passing (84.375/108) and you wrote one test (21/42)
• 65% (D): one test passing (76.5/108) and one test written (21/42)
• 61.5% (D-): approximately ½ tests passing (92.25/108) and you wrote zero tests (0/42)
• 56.25% (F): approximately ¼ tests passing (84.375/108) and you wrote zero tests (0/42)
• 0% (F): there’s certainly lots of stuff in cpu.circ but no tests pass (0/108); ) and you
wrote zero tests (0/42)
10.3 Additional requirements
1. You must sufficiently document your circuits using labels. For sub-circuits, label all
inputs and outputs. Label important wires descriptively and label regions of your circuit
with what they do.
You must make your circuits as legible as possible. Learn to make use of tunnels when they will
save on messy wiring. (see Documentation on Tunnels)
10.4 Submission checklist
Your circuits don’t have any errors (Red (E) or orange (wrong width) wires). You ought to
avoid blue (X) wires, too.
make p2sc runs the tests without crashing
Your circuits pass the original tests
Your circuits pass additional automated tests that you have written
You made a zip file hw5.zip that contains these files in the following directory
structure:
1. cpu.circ (your completed CPU)
2. control.circ (your completed control unit)
3. iodevices.circ (your completed IO device(s), if appropriate)
4. tests/
any additional files you’ve added for your testing, which means
• your test harness files (i.e., the copies of
cpu_test_template/cpu_lite_test_template/cpu_end_test_templa
te), renamed appropriately, and with instruction memory loaded
appropriately
• the MIPS assembly files that you used for your tests
• tests.py (because you will add code to this file for your tests)
Exclude
• Any auto-generated files such as the .hex files
Be responsible. Double-check and triple-check your zip file that it contains the correct
versions of your files. Near the end of the semester we have no time for exceptions.
1. Tip if you collaborating using github, you can download a zip file of your repo
when you are done.
As a team: One submission by any team member for the team. You are responsible for
the contents all being in there on time. Upload a zip file to ICON "Homework 5: A MIPS
Processor".
1. Make sure you complete the “HW5 team signup” on ICON before submitting
your project.
11 Recommended approach to finishing the project
This project involves lots of implementation and testing (both circuits and MIPS code). We
highly recommended that you get to a basic working processor quickly, which passes some
simple tests with support for limited number of instructions and then add complexity from
there. (Notice that in the textbook and lectures on MIPS processor design, complexity was
added incrementally). During grading,
1. a CPU that passes many tests but is missing some instructions
will be given far more credit than
2. a CPU that passes 0 or a few tests but attempts to support all instructions
Therefore, here is a general order we suggest
1. just enough to pass starter_test.circ
2. create and pass tests for other arithmetic instructions
3. create and pass tests for lw/sw
4. create and pass tests for branches and j instruction
5. create and pass tests for the rest of the instructions
6. (if team of 3) implement the IO device and program
12 Help and Tips
12.1 General tips
• If you open a file in Logisim, and Logisim prompts you saying it cannot find *.jar or *.circ
then you should quit out of Logisim without continuing.
o To fix the jar issue, make sure ALU.jar (if you are using our alu.circ and/or alu-
control.circ) and cs3410.jar are in both the base directory and the tests/
directory.
o To fix the circ issue, run the sanitize.sh command by typing “./sanitize.sh
[FILENAME]” on the command line, from the base directory. For example, if
when you open cpu.circ you get the prompt, then run “./sanitize.sh cpu.circ”.
• Do not waste your time writing the instruction memory hex files manually. You should
be writing MIPS source programs in MARS. Leave the assembling to the assembler (See
the section above called “Assembling and running new programs”).
• Be aware that running the tests will copy alu.circ, alu-control.circ, regfile.circ, cpu.circ,
control.circ, mem.circ, and iodevices.circ into the tests/ directory. You should not
modify those copies (tests/alu.circ, tests/alu-control.circ, tests/regfile.circ,
tests/cpu.circ, test/control.circ, tests/mem.circ, tests/iodevices.circ) because you risk
getting mixed up and losing work.
• Do not leave testing until the last minute. You should be testing as you finish each
instruction.
• Do not rely on just the provided tests. You must add more. The autograder will test your
circuits extensively. If you fail all of the autograder tests, you will receive a failing
grade (See ICON rubric for scale).
• Do not rely solely on manually testing your circuits (i.e. poking inputs in the Logisim GUI
and looking at the output). Manual testing is both time-consuming and error-prone. You
should extend the automated tests (as described in the testing sections of this
document).
12.2 The test failed, now what?
We recommend a specific debugging process. It is similar to testing software: use a unit test to
identify the failing test then use a debugger with a “breakpoint” to determine where the cause
is.
1. Determine the failing test. Do this by running make p2sc. Choose a single failing test to
focus on. Within the output for that test, identify which Time Step is failing. For
example, Time Step 1 is failing here.
cp alu.circ regfile.circ mem.circ cpu.circ control.circ iodevices.circ tests
cd tests && python3 ./test.py p2sc | tee ../TEST_LOG
Testing files...
Format is student then expected
$s0 Value $s1 Value $s2 Value $ra Value $sp Value Time Step Fetch Addr Instruction
0 0 0 0 0 0 0 20100001
0 0 0 0 0 0 0 20100001
0 0 0 0 0 1 20100009 0
1 0 0 0 0 1 4 20110002
FAILED test: starter test (1,2,3) (Did not match expected output)
2. When debugging, you always need to go top down. The top in our case, is the test
harness. Open the circ file in tests/, for the failing test. In the running example, this is
tests/starter_test.circ.
3. Let’s just first check that we can replicate the failing test. Tick the clock until the failing
Time Step. In our case, it is 1, so we tick once. Indeed, the Fetch Addr is a huge number
but it should have been 4.
4. Since the CPU is sequential logic, values change at the rising edge of the clock.
Therefore, the root cause of a failing test happened in the clock period BEFORE the
failing Time Step. Reset the simulation and tick up to that Time Step. In this case, we
failed on Time Step 1, so we want to be on Time Step 0.
5. Now let’s find the register whose value was wrong in Time Step 1, to see who wrote the
wrong value to it in Time Step 0. In many cases, one of $s0, $s1, $s2, $ra, $sp will be
wrong, which are registers in the Register File. But in our running example, the Fetch
Addr was wrong so it is the PC register we want to focus on. To dive into the CPU, right
click the CPU in the editor and click View Main.
6. Find the register, and use the poke tool to see the values going into it. In our case of the
PC, it looks like it is indeed getting the wrong value of 20100009.
7. From here, continue tracing backwards to see where the erroneous value came from. In
our case, we discovered we were giving the PC register the value of Instruction+4
instead of PC+4.
8. You cannot edit the debugging mode version of your circuit! Open your actual circuit
file and make the changes there. In our case, it was cpu.circ that we needed to edit.
12.3 Teamwork tips
• Our recommendations are on assigning expertise to team members. However, you are
producing one working product. The team is responsible for the project as a whole.
• Logisim circuits are hard to collaborate on unless you break them up into pieces. This is
due to the .circ file format not being easily merged. Therefore, we have provided a
structure so that you can work in parallel:
o Test expert works on the test .circ files
o Datapath expert works on the cpu.circ file
o Control expert works on the control.circ file and alu-control.circ file
o IO expert works on the iodevices.circ file
• It is your responsibility to keep in contact with your team and notify the staff as early as
possible if cooperation problems arise that your team cannot resolve on its own. Often,
issues can be remedied if recognized early. The staff's role in problem solving will be to
facilitate team discussions and not to criticize individual team members.
• Although we do not require you and your team to use a version control system (e.g., git
or svn), we highly recommend doing so to keep track of your changes. If you use version
control just be aware that merging .circ files will corrupt them (unlike plain text files), so
avoid working on the same file concurrently to avoid merge conflicts all together. Ask
the staff for help if you get stuck! (Re-read the 2nd teamwork tip in this list)
• Slip days: refer to the syllabus
12.4 Where to get help
Go in this order:
1. Look for the answer in this document.
2. Refer to the readings and class materials. For example, the design of a processor
with a small number of instructions is given in the textbook (of course, you’ll want to
make sure you build yours to the specifications given in this project document).
3. Get help from your teammates.
4. Find other students to discuss issues at a high level. However, do not share
programs or circuit files outside of your team.
5. Refer to the discussion board on Piazza and ask questions there.
6. Ask the staff in class, DYB, or office hours.
13 Academic honesty
Building your own programmable processor is a highlight of a CS (or related) degree, so do it
yourself! We remind you that if you do choose to reuse sub-circuits designed by someone
outside of your team that you clearly cite where they came from. Not citing your sources is
plagiarism. You are strictly prohibited from looking at solutions to other versions of this
project. The staff will be checking design .circ files against past and present submissions. Any
academic dishonesty will result in a zero on this project and report of the incident to the
College.
14 Acknowledgements
• starter code forked from UC Berkeley CS61C
https://github.com/cs61c-spring2016/proj3-starter
• document based on UC Berkeley CS61C project 3.2
http://www-inst.eecs.berkeley.edu/~cs61c/sp16/
• Helper library register file from Cornell CS3410, Spring 2015
http://www.cs.cornell.edu/courses/cs3410/2015sp
学霸联盟
Homework 5
Single-cycle MIPS processor with I/O
1 Table of Contents
2 GOALS FOR THIS ASSIGNMENT .....................................................................................................2
3 INTRODUCTION ............................................................................................................................2
4 TEAMS .........................................................................................................................................2
5 READING THIS DOCUMENT ...........................................................................................................3
6 GETTING STARTED ........................................................................................................................3
7 THE PROCESSOR ...........................................................................................................................5
7.1 ONE OR MORE STUDENTS ................................................................................................................6
7.2 TWO OR MORE STUDENTS ................................................................................................................6
7.3 INSTRUCTION DETAILS .....................................................................................................................7
7.3.1 LW INSTRUCTION.................................................................................................................................... 7
7.3.2 CLZ INSTRUCTION ................................................................................................................................... 7
7.4 WHAT YOU MUST IMPLEMENT ..........................................................................................................7
7.5 TIPS ON BUILDING THE CONTROL UNIT ................................................................................................8
7.6 HOW YOU MUST TEST .....................................................................................................................8
7.7 .....................................................................................................................................................8
7.8 TESTING TIPS ................................................................................................................................8
8 ASSEMBLING AND RUNNING NEW PROGRAMS .............................................................................9
9 INPUT/OUTPUT (IO) ................................................................................................................... 14
9.1 WHAT YOU MUST DO ................................................................................................................... 15
10 REQUIREMENTS AND GRADING ................................................................................................ 15
10.1 RUBRIC ................................................................................................................................... 15
10.2 EXAMPLE SCORES ...................................................................................................................... 16
10.3 ADDITIONAL REQUIREMENTS ........................................................................................................ 16
10.4 SUBMISSION CHECKLIST ............................................................................................................... 16
11 RECOMMENDED APPROACH TO FINISHING THE PROJECT .......................................................... 17
12 HELP AND TIPS ......................................................................................................................... 18
12.1 GENERAL TIPS ........................................................................................................................... 18
12.2 THE TEST FAILED, NOW WHAT? ..................................................................................................... 18
12.3 TEAMWORK TIPS ....................................................................................................................... 20
12.4 WHERE TO GET HELP .................................................................................................................. 20
13 ACADEMIC HONESTY ................................................................................................................ 21
14 ACKNOWLEDGEMENTS ............................................................................................................. 21
2 Goals for this assignment
• Design and implement a substantial digital system
• Add new instructions to the datapath and control
• Use robust testing methodology in digital logic design
• Learn how to load binary code from the assembler into the instruction memory
• Create MIPS programs that adequately test the processor
3 Introduction
In HW4 you built a major component of a MIPS processor, and in HW5 you will build the rest of
a processor, as well as IO to make it useful. As in part 1, we provide the top-level skeleton file
and test circuits, and you will provide the implementation and additional tests.
4 Teams
You can work either individually, as a team of 2, or as a team of 3. The number of students will
determine the requirements of the project.
• 1 student: the basic set of instructions (see section: The Processor)
• 2 students: all of the above plus the additional instructions (see section: The Processor)
• 3 students: all of the above plus IO (see section: Input/Output (IO))
Feel free to do more than the requirements for your team size; however, there is no extra
credit.
5 Reading this document
There is a lot here. I recommend thinking of the project in three components: datapath,
control, and testing. At some point you should read the whole document, but here's what you
should read first if you want to get started fast but still be thorough.
• Datapath expert:
1. Getting started, with emphasis on 3, 4a, and 4b
2. The Processor including What you must implement and excluding Tips on building
the control unit
3. Read: Mips Processor (ICON) if you haven't yet
4. Recommended approach to finishing the project
5. Teamwork Tips
6. Where to get help
• Control unit expert:
1. Getting started, skimming what is after step 2
2. The Processor including What you must implement and emphasizing Tips on
building the control unit
3. Read: Mips Processor (ICON) if you haven't yet
4. Recommended approach to finishing the project
5. Teamwork Tips
6. Where to get help
• Testing expert:
1. Getting Started, emphasis on getting it to work with either your alu/regfile or the
provided ones
2. The Processor, emphasis on How you must test and Testing tips.
3. Read: Mips Processor (ICON) if you haven't yet
4. Assembling and running new programs
5. Recommended approach to finishing the project
6. Tips
7. Teamwork Tips
8. Where to get help
6 Getting started
1. Download the starter code from
https://github.com/bmyerz/project2-mips-processor/archive/refs/heads/proj2-part2-sp21.zip
or, if you are using git, you can instead clone the repository. Just make sure checkout the
branch proj2-part2-sp21. That is, do the following:
git clone https://github.com/bmyerz/project2-mips-processor.git
git checkout proj2-part2-sp21
2. Try running the tests
Use the same method for running Linux commands that you used in part 1 of the project.
i. Run the tests
make p2sc
You should see output like
cp alu.circ alu-control.circ regfile.circ mem.circ cpu.circ control.circ iodevices.circ tests
cd tests && python3 ./test.py p2sc | tee ../TEST_LOG
Testing files...
Error in formatting of Logisim output (check ./starter_test.circ):
you have a non-integer in this list: ['xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'00000000000000000000000000000000', 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx']
FAILED test: starter test (Error in the test)
Passed 0/1 tests
The x’s indicate that those bits are disconnected.
3. Copy your alu.circ and alu-control.circ solution from HW4 into the new directory.
4. To get the register file component, follow these instructions. (Also, if you prefer to use a
reference solution to the ALU/ALU Control, follow the instructions at (b)).
a. To use the register file replacement
download regfile.circ and cs3410.jar from the HW5 ICON
You must put regfile.circ in the base directory of your project.
You must have two copies of the cs3410.jar file: one in the base directory and one in the
tests/ directory.
A nice feature of this version of regfile.circ is that it uses a fancy register file that shows
the values of the registers, which may make debugging a bit easier.
b. To use the reference implementation of the ALU (optional)
You may choose to use one or both of alu.circ and alu-control.circ.
download ALU.jar from the HW5 ICON
download alu.circ and/or alu-control.circ from the HW5 ICON
You must put alu.circ and/or alu-control.circ in the base directory of your project (as it
was in HW4).
You must have two copies of the ALU.jar file: one in the base directory and one in the
tests/ directory.
5. You can check if you copied the ALU and register file (whether using yours or ours)
properly into your project folder by running the part 1 tests and seeing that they pass.
make p1
cp alu.circ alu-control.circ regfile.circ tests
cd tests && python3 ./test.py p1 | tee ../TEST_LOG
Testing files...
PASSED test: ALU add (with overflow) test, with output in
python
PASSED test: ALU arithmetic right shift test
PASSED test: ALU Control R-type Test
PASSED test: ALU Control I-type Test
PASSED test: RegFile read/write test
PASSED test: RegFile $zero test
PASSED test: RegFile debug outputs test
Passed 7/7 tests
6. When you open up cpu.circ in Logisim, you’ll see that alu, mem, regfile, control, and alu-
control are all available as subcircuits.
7 The processor
Your team’s task is to design, implement, and test a single-cycle MIPS processor. The processor
must support a specific subset of instructions from the 32-bit MIPS instruction set architecture.
That subset is:
7.1 One or more students
Instruction
sll
srl
sra
add
addu
addiu
addi
j
and
or
andi
ori
lw
sw
beq
bne
7.2 Two or more students
Additionally, support these instructions
Instruction
jr
slt
sltu
sltiu
slti
lui
clz
The specification of the instructions is exactly the one in the “MIPS reference card” or “Human-
friendly MIPS reference card” on (find in Modules on ICON) except for the following
differences.
If you are in this category, you should expand upon alu-control.circ to calculate the ALU’s
Switch for slt, sltu, sltiu, and slti. You might do that in any of the following ways:
a) If you are using your own alu-control.circ, modify it.
b) If you are using the reference solution to alu-control.circ, you can modify that file. Just
be aware that you need to add circuits to alu-control.circ that work together with the
“black box” subcircuit that is already in there.
c) Regardless of which alu-control.circ you are using, an alternative is just to put the new
logic outside of there, directly in cpu.circ.
7.3 Instruction details
7.3.1 lw instruction
lw’s opcode is 35. This matches MARS and the MIPS Green Sheet. We mention this because the
human friendly MIPS reference sheet assigns lw the wrong opcode.
7.3.2 clz instruction
The clz instruction is “count leading zeroes”. This instruction is not listed in the MIPS reference
sheet, but MARS supports it as a core instruction.
The clz is a MIPS instruction that was not covered in the class. To find its
behavior, look at the Help menu in MARS.
You must use MARS to reverse engineer the bit encoding of this instruction. Try assembling a
program with clz, with different values of the argument registers. It is actually not R-type, I-
type, or J-type but a fourth type of instruction that is similar to R-type.
HINT: To implement clz, use a combination of components available in the Arithmetic library.
7.4 What you must implement
You must modify cpu.circ to implement the CPU. Do not modify or move the inputs and
outputs. You may use sub-circuits in your implementation as long as remains the
top level circuit of cpu.circ. You may use any built-in Logisim components.
For your Data Memory, you can use mem.circ. That module can read or write one memory
location on every cycle. When Write_En=1, the memory will write data Write_Data to the
location given by Address on the next rising edge of the clock, and when Write_En=0 the
Read_Data port will have the value at the location given by Address.
Note that the cpu.circ file has five output pins across the top. These provide hardwired access
to five of the registers of the register file. You can connect them directly to the five outputs at
the top of the Register File we provided you.
7.5 Tips on building the control unit
Your control unit should go inside of control.circ.
Building a control unit can be very complex and error prone due to the large number of input
and output bits, so you should try to reduce complexity where possible. Specifically,
• Rely on a logic analyzer, such as Logisim's logic analyzer tool (found at Project | Analyze
circuit). It will allow you to input a function as a truth table and automatically generate
the circuit. Note that the logic analyzer requires 1-bit inputs, so you'll have to split multi-
bit wires into individual bits.
• Use "don't cares" to simplify the logic (the logic analyzer represents them as X's)
• Keep in mind that most control signals are calculated from solely the opcode.
7.6 How you must test
7.7
1. Run the tests with the command make p2sc.
2. To ensure you pass the autograder, you must test your CPU beyond the given tests.
Adding new tests is similar to HW4, except:
• the sample test harness to copy is one of cpu_test_template.circ,
cpu_lite_test_template.circ, or cpu_end_test_template.circ instead of alu-
harness.circ.
• instead of loading the test inputs into ROMs, you will load the instruction
memory (it is a ROM) with an assembled program.
See the section “Assembling and running new programs” for a step-by-step guide.
See the get_test_format function in tests/decode_out.py for the format of the output of
the "cpu" tests. The first list is the headers and the second list is the bit widths.
['$s0 Value', '$s1 Value', '$s2 Value', '$ra Value', '$sp Value', 'Time Step', 'Fetch Addr',
'Instruction'], [32,32,32,32,32,8,32,32]
7.8 Testing tips
• Since there is some effort to adding a new test, try to balance keeping the tests simple
while including multiple instructions
• Make sure to check different cases, such as branch, not branch, branch forward, branch
backward
• Having to give the expected values of the 5 registers, fetch Address, and instruction bits
on every single clock cycle can be overkill for more complex tests. To help you, we've
included different types of tests that check only some of the outputs.
Type Checks outputs Recommendation Template
cpu '$s0 Value', '$s1
Value', '$s2 Value',
'$ra Value', '$sp
Value', 'Time Step',
'Fetch Addr',
'Instruction'
use for short/simple
tests, where you want
to check everything
on every cycle
cpu_test_template.circ
cpu-lite '$s0 Value', '$s1
Value', '$s2 Value',
'$ra Value', '$sp
Value', 'Time Step'
use for tests where
you don’t want to
have to check fetch
address and
instruction, but you
still want to check the
register values on
every cycle
cpu_lite_test_template.circ
cpu-end '$s0 Value', '$s1
Value', '$s2 Value',
'$sp Value'
use for tests where
you only want to
check the state of
some registers when
they change.
cpu_end_test_template.circ
Note: To understand why cpu-end tests do not check outputs every cycle, rather only
when the registers change, it is helpful to know that Logisim only prints a new line of
output when one of the output values changes. For cpu and cpu-lite, the inclusion of
"Time Step" ensures that a line gets printed every cycle.
You specify the test Type by making the last argument to TestCase be "cpu", "cpu-lite", or "cpu-
end" in your tests.py file.
Add your expected outputs as a list of lists in the Python file as described in HW4.
8 Assembling and running new programs
The project kit comes with a copy of Mars (mars.jar) so that you can assemble MIPS programs
in the format required for the instruction memory. What follows is the workflow that we
recommend for writing MIPS programs and running them on your processor.
1. Edit your MIPS program in MARS (as you did in in prior labs).
You should set the following “Memory Configuration…”, to tell MARS to assemble the
addresses the same way our command line assembler does (.text starts at address
0x00000000 and .data starts at address 0x00002000)
2. Test and debug your program in MARS (as you did in prior labs).
3. Save your MIPS program to a file. We’ll assume the name “foo.s” for these directions,
but you should name the file appropriately.
4. When you are ready to run your program on the MIPS processor, you will use the
assembler provided with the project kit.
Make sure you know the file path of your MIPS file. It’s easiest if you just save it to the base
directory of your project.
i. Change directories to path of your project folder
cd /path/to/project (/path/to should be the actual file path)
ii. Double check that the MIPS program is in your directory by running ls.
Makefile
TEST_LOG
alu-harness.circ
alu.circ
alu-control.circ
cpu.circ
example_IO_controller.circ
foo.s
mars-assem.sh
mars.jar
mem.circ
regfile-harness.circ
regfile.circ
tests
iii. Run the assembler on your MIPS program
./mars-assem.sh foo.s
If your assembly file didn’t have a .data section you might see a message, but it is
just a warning.
This segment has not been written to, there is nothing to dump.
cat: data_t.hex: No such file or directory
rm: data_t.hex: No such file or directory
iv. List the files in the folder again (by running ls) to check that there was output.
Makefile
TEST_LOG
alu-harness.circ
alu.circ
alu-control.circ
cpu.circ
example_IO_controller.circ
foo.s
foo.s.data.hex
foo.s.text.hex
mars-assem.sh
mars.jar
mem.circ
regfile-harness.circ
regfile.circ
tests
You should see a .text.hex file, which contains the text segment. If you had a .data section, you
should also see a .data.hex file, which contains data memory contents up to and including the
.data segment.
5. Now you can load the program into your processor in Logisim. Make a copy of one of
the three templates, depending on what type of test you want: cpu_test_template.circ,
cpu_lite_test_template.circ, or cpu_end_test_template.circ. Call your copy
foo_test.circ. And then open that new file in Logisim.
i. Load the instruction memory by right-clicking the Instruction Memory ROM and
choosing Load Image...
Navigate to the foo.s.text.hex file
ii. Load the data memory (OPTIONAL; only need to do this step if your MIPS program
has a .data section). The data memory implementation is provided to you in
mem.circ, which you should use as a “Logisim library…” in your CPU.
right-click the RAM | Load image | navigate to foo.s.data.hex
You can double-check that your data was loaded into the expected address in memory
by right clicking the RAM > Edit Contents… > and scrolling down to the row for 002000 to see
the data.
iii. Make sure to Save the circuit file containing the instruction memory so that you
don’t have to load the program again (just like you had many test harnesses in Part
1, you will just have another copy the template test for each test program).
Note that you will have to load your data memory each time you change
programs or “Reset Simulation”. Logisim applies the reset to RAMs but not ROMs.
Therefore, we suggest making your tests not have a .data section so that you don't
have the inconvenience of loading the RAM ahead of time.
6. Now you can simulate your CPU by ticking the clock. Notice that once the instruction
memory gets to instructions 0x00000000, your processor should just be executing
NOOPs (short for “no operation”) until you stop the simulation. You don’t have to do
anything special for implementing NOOP: notice that if you reverse engineer machine
code 0x00000000, you’ll see it is an sll that tries to write to $zero.
9 Input/output (IO)
You now have a processor that executes real MIPS programs! Now it is time to make it more
interesting by including some IO devices. We will use a methodology for IO called Memory
mapped IO (MMIO).
The way MMIO works is that some range of addresses is reserved for controlling IO devices
rather than accessing memory.
If you look back at MARS's Memory Configuration (Settings > Memory Configuration), you'll see
that addresses starting at 0x00007f00 are reserved for MMIO.
An output device will take in the same Address/MemWrite/WriteData signals as the data
memory, except it will listen for its range of addresses (0x00007F00 and above). When
MemWrite=1 and the Address is in range, the output device will be written to.
We've provided an example module in example_IO_controller.circ. It is a single LED
that can be turned on by writing a 1 to address 0x00007F00 and turned off by writing a 0 to
address 0x00007F00.
There are more IO devices besides the LED available in Logisim's Input/Output folder.
You can experiment with how they work. Post to Piazza discussion if you have trouble
understanding how to control one of them.
9.1 What you must do
Your task is to implement an interesting application that uses some input and/or output device.
i. In iodevices.circ, build an IO controller for the device that you want to use and
attach it to the appropriate signals in your cpu. The iodevices.circ should not contain
its own clock; rather, it should have an input pin for the clock. Your iodevices
subcircuit should be placed in the top level of cpu.circ OR in a clearly labeled
subcircuit within cpu.circ. The device must be more than the single LED example
(i.e., at least two LEDs but other devices are encouraged, too). Write as short of a
MIPS test program as possible that will read or write (depending on if you picked an
input or output) the device. Call the test program iotest.s and the test harness
iotest.circ.
a. Note that if you choose to use an input device (e.g., button, joystick) then you’ll
want to capture the input into a register. Your program can use lw to read that
register with MMIO.
ii. Optionally, you may include a more interesting program that shows off your IO
device. Include a test harness, as well as a brief description in a file called
io_readme.txt.
iii. Pat yourself on the back. You've built a working and useful computer! Show off your
work to others. (just don't share copies of your files)
10 Requirements and grading
10.1 Rubric
You can also see ICON for the rubric that we'll use to grade
• 108 points – Demonstrate your processor works correctly. The processor passes the
autograder tests (we have hidden tests that cover all required functionality). Passing the
starter test will get you 76.5 points. Then you will earn further points for every
additional test you pass.
• 42 points – Demonstrate that you tested your processor. You submitted test files to
show you considered each instruction and corner cases. You will earn 21 of these points
for having just 1 new test and the remainder for covering the rest of the
instructions/cases.
o For teams of 3: 65% of the 42 points are for the tests and 35% of the 42 points
are for the I/O requirements
o For each test, you must include the .s file, changes to test.py, and the .circ file!
10.2 Example scores
To make it really clear what your priorities should be, here are some examples of scores.
• 94.75% (A): approximately ¾ of tests passing (100.125/108) and you wrote tests for all
cases (42/42)
• 89.5% (B+): approximately ½ tests passing (92.25/108) and you wrote tests for all cases
(42/42)
• 84.25% (B): approximately ¼ tests passing (84.375/108) and you wrote tests for all cases
(42/42)
• 79% (C+): one test passing (76.5/108) and you wrote tests for all cases (42/42)
• 75.5% (C): approximately ½ tests passing (92.25/108) and you wrote one test (21/42)
• 72% (C-): all tests passing (108/108) and you wrote zero tests (0/42)
• 70.25% (C-): approximately ¼ tests passing (84.375/108) and you wrote one test (21/42)
• 65% (D): one test passing (76.5/108) and one test written (21/42)
• 61.5% (D-): approximately ½ tests passing (92.25/108) and you wrote zero tests (0/42)
• 56.25% (F): approximately ¼ tests passing (84.375/108) and you wrote zero tests (0/42)
• 0% (F): there’s certainly lots of stuff in cpu.circ but no tests pass (0/108); ) and you
wrote zero tests (0/42)
10.3 Additional requirements
1. You must sufficiently document your circuits using labels. For sub-circuits, label all
inputs and outputs. Label important wires descriptively and label regions of your circuit
with what they do.
You must make your circuits as legible as possible. Learn to make use of tunnels when they will
save on messy wiring. (see Documentation on Tunnels)
10.4 Submission checklist
Your circuits don’t have any errors (Red (E) or orange (wrong width) wires). You ought to
avoid blue (X) wires, too.
make p2sc runs the tests without crashing
Your circuits pass the original tests
Your circuits pass additional automated tests that you have written
You made a zip file hw5.zip that contains these files in the following directory
structure:
1. cpu.circ (your completed CPU)
2. control.circ (your completed control unit)
3. iodevices.circ (your completed IO device(s), if appropriate)
4. tests/
any additional files you’ve added for your testing, which means
• your test harness files (i.e., the copies of
cpu_test_template/cpu_lite_test_template/cpu_end_test_templa
te), renamed appropriately, and with instruction memory loaded
appropriately
• the MIPS assembly files that you used for your tests
• tests.py (because you will add code to this file for your tests)
Exclude
• Any auto-generated files such as the .hex files
Be responsible. Double-check and triple-check your zip file that it contains the correct
versions of your files. Near the end of the semester we have no time for exceptions.
1. Tip if you collaborating using github, you can download a zip file of your repo
when you are done.
As a team: One submission by any team member for the team. You are responsible for
the contents all being in there on time. Upload a zip file to ICON "Homework 5: A MIPS
Processor".
1. Make sure you complete the “HW5 team signup” on ICON before submitting
your project.
11 Recommended approach to finishing the project
This project involves lots of implementation and testing (both circuits and MIPS code). We
highly recommended that you get to a basic working processor quickly, which passes some
simple tests with support for limited number of instructions and then add complexity from
there. (Notice that in the textbook and lectures on MIPS processor design, complexity was
added incrementally). During grading,
1. a CPU that passes many tests but is missing some instructions
will be given far more credit than
2. a CPU that passes 0 or a few tests but attempts to support all instructions
Therefore, here is a general order we suggest
1. just enough to pass starter_test.circ
2. create and pass tests for other arithmetic instructions
3. create and pass tests for lw/sw
4. create and pass tests for branches and j instruction
5. create and pass tests for the rest of the instructions
6. (if team of 3) implement the IO device and program
12 Help and Tips
12.1 General tips
• If you open a file in Logisim, and Logisim prompts you saying it cannot find *.jar or *.circ
then you should quit out of Logisim without continuing.
o To fix the jar issue, make sure ALU.jar (if you are using our alu.circ and/or alu-
control.circ) and cs3410.jar are in both the base directory and the tests/
directory.
o To fix the circ issue, run the sanitize.sh command by typing “./sanitize.sh
[FILENAME]” on the command line, from the base directory. For example, if
when you open cpu.circ you get the prompt, then run “./sanitize.sh cpu.circ”.
• Do not waste your time writing the instruction memory hex files manually. You should
be writing MIPS source programs in MARS. Leave the assembling to the assembler (See
the section above called “Assembling and running new programs”).
• Be aware that running the tests will copy alu.circ, alu-control.circ, regfile.circ, cpu.circ,
control.circ, mem.circ, and iodevices.circ into the tests/ directory. You should not
modify those copies (tests/alu.circ, tests/alu-control.circ, tests/regfile.circ,
tests/cpu.circ, test/control.circ, tests/mem.circ, tests/iodevices.circ) because you risk
getting mixed up and losing work.
• Do not leave testing until the last minute. You should be testing as you finish each
instruction.
• Do not rely on just the provided tests. You must add more. The autograder will test your
circuits extensively. If you fail all of the autograder tests, you will receive a failing
grade (See ICON rubric for scale).
• Do not rely solely on manually testing your circuits (i.e. poking inputs in the Logisim GUI
and looking at the output). Manual testing is both time-consuming and error-prone. You
should extend the automated tests (as described in the testing sections of this
document).
12.2 The test failed, now what?
We recommend a specific debugging process. It is similar to testing software: use a unit test to
identify the failing test then use a debugger with a “breakpoint” to determine where the cause
is.
1. Determine the failing test. Do this by running make p2sc. Choose a single failing test to
focus on. Within the output for that test, identify which Time Step is failing. For
example, Time Step 1 is failing here.
cp alu.circ regfile.circ mem.circ cpu.circ control.circ iodevices.circ tests
cd tests && python3 ./test.py p2sc | tee ../TEST_LOG
Testing files...
Format is student then expected
$s0 Value $s1 Value $s2 Value $ra Value $sp Value Time Step Fetch Addr Instruction
0 0 0 0 0 0 0 20100001
0 0 0 0 0 0 0 20100001
0 0 0 0 0 1 20100009 0
1 0 0 0 0 1 4 20110002
FAILED test: starter test (1,2,3) (Did not match expected output)
2. When debugging, you always need to go top down. The top in our case, is the test
harness. Open the circ file in tests/, for the failing test. In the running example, this is
tests/starter_test.circ.
3. Let’s just first check that we can replicate the failing test. Tick the clock until the failing
Time Step. In our case, it is 1, so we tick once. Indeed, the Fetch Addr is a huge number
but it should have been 4.
4. Since the CPU is sequential logic, values change at the rising edge of the clock.
Therefore, the root cause of a failing test happened in the clock period BEFORE the
failing Time Step. Reset the simulation and tick up to that Time Step. In this case, we
failed on Time Step 1, so we want to be on Time Step 0.
5. Now let’s find the register whose value was wrong in Time Step 1, to see who wrote the
wrong value to it in Time Step 0. In many cases, one of $s0, $s1, $s2, $ra, $sp will be
wrong, which are registers in the Register File. But in our running example, the Fetch
Addr was wrong so it is the PC register we want to focus on. To dive into the CPU, right
click the CPU in the editor and click View Main.
6. Find the register, and use the poke tool to see the values going into it. In our case of the
PC, it looks like it is indeed getting the wrong value of 20100009.
7. From here, continue tracing backwards to see where the erroneous value came from. In
our case, we discovered we were giving the PC register the value of Instruction+4
instead of PC+4.
8. You cannot edit the debugging mode version of your circuit! Open your actual circuit
file and make the changes there. In our case, it was cpu.circ that we needed to edit.
12.3 Teamwork tips
• Our recommendations are on assigning expertise to team members. However, you are
producing one working product. The team is responsible for the project as a whole.
• Logisim circuits are hard to collaborate on unless you break them up into pieces. This is
due to the .circ file format not being easily merged. Therefore, we have provided a
structure so that you can work in parallel:
o Test expert works on the test .circ files
o Datapath expert works on the cpu.circ file
o Control expert works on the control.circ file and alu-control.circ file
o IO expert works on the iodevices.circ file
• It is your responsibility to keep in contact with your team and notify the staff as early as
possible if cooperation problems arise that your team cannot resolve on its own. Often,
issues can be remedied if recognized early. The staff's role in problem solving will be to
facilitate team discussions and not to criticize individual team members.
• Although we do not require you and your team to use a version control system (e.g., git
or svn), we highly recommend doing so to keep track of your changes. If you use version
control just be aware that merging .circ files will corrupt them (unlike plain text files), so
avoid working on the same file concurrently to avoid merge conflicts all together. Ask
the staff for help if you get stuck! (Re-read the 2nd teamwork tip in this list)
• Slip days: refer to the syllabus
12.4 Where to get help
Go in this order:
1. Look for the answer in this document.
2. Refer to the readings and class materials. For example, the design of a processor
with a small number of instructions is given in the textbook (of course, you’ll want to
make sure you build yours to the specifications given in this project document).
3. Get help from your teammates.
4. Find other students to discuss issues at a high level. However, do not share
programs or circuit files outside of your team.
5. Refer to the discussion board on Piazza and ask questions there.
6. Ask the staff in class, DYB, or office hours.
13 Academic honesty
Building your own programmable processor is a highlight of a CS (or related) degree, so do it
yourself! We remind you that if you do choose to reuse sub-circuits designed by someone
outside of your team that you clearly cite where they came from. Not citing your sources is
plagiarism. You are strictly prohibited from looking at solutions to other versions of this
project. The staff will be checking design .circ files against past and present submissions. Any
academic dishonesty will result in a zero on this project and report of the incident to the
College.
14 Acknowledgements
• starter code forked from UC Berkeley CS61C
https://github.com/cs61c-spring2016/proj3-starter
• document based on UC Berkeley CS61C project 3.2
http://www-inst.eecs.berkeley.edu/~cs61c/sp16/
• Helper library register file from Cornell CS3410, Spring 2015
http://www.cs.cornell.edu/courses/cs3410/2015sp
学霸联盟
