It is quite possible that the code given to you in the lab contains bugs, or that a certain description is wrong, if you come across such a case, or come across something that you think might be wrong, do not hesitate to let the professor or a grader know. It is also quite possible that we will update portions of the lab to reflect these changes, instructions will be sent by e-mail to add these changes to your lab
The purpose of this is lab is to build a relatively simple, but still working multi-cycle processor. You will be expected to use the LXRE ISA for your processor.
Groups in this class are encouraged not just to build on their own work, but to build on other people's work.
At the end of each assignment, code from other people's assignment will be available for every group to look at (it may take
some time to get them there).
Each group's assignment will be in the git@tera.eng.hmc.edu:e190o-s2013 repository (same as the labs), but the
branch name will be lab#-group.
You may use, and are encouraged to use any other groups work as the starting point for your lab.
You are also encouraged to discuss techniques for solving the problem, however you should NOT be sharing code
for the current lab, either a file, or written out (like on a white board).
First its a good idea to backup your branch locally, make sure everything is commited and run
git branch lab0
This will create a local branch inside of your repository.
You can always see what branches you have by running git branch with no arguments.
Next you will want to fetch the updated code, you can run
git fetch origin
If there is a group you like, you can switch to their code by running
git reset --hard origin/lab0-group name
the hard reset means discard anything in the original branch (you almost always want a reset --hard).
Next merge the changes with the new code for lab1 by running
git merge origin/lab1.0
Hopefully there are no or very few merge conflicts, fix the files and add them, then commit.
Your goal is to build a processor.
In the added files is verilog/cpu which contains stubs for code you will be working on.
The header file verilog/cpu/lxre.h is a header file containing defines that will probably be helpful.
You should look through it to become familiar with these defines.
A simple register file has been provided in verilog/reg/reg.sv,
the line logic [`BUS] registers[31:0] is a memory, and means that there are 32 registers of size `BUS (defined in the header file).
Note that while there is no write enable on register file, because register $0 is always 0, if you don't want to write just write to register $0.
Just be aware that they exist, you'll need to know about this when you build caches, but not now.
In addition there is a memory module in verilog/mem, you shouldn't need to look at how the memory works for this lab, but you can check it out if you are curious.
The instruction set you will be working with is LXRE (it's a take off of DLX which is an instruction set that Hennessy and Paterson designed for teaching).
It is described in the resources section.
In addition a simulator and assembler have been provided.
The simulator is sim-lxre and the assembler is asm-lxre.
For this week you are asked to design a multicycle implementation of the LXRE instruction set. Each instruction is expected to go through the Instrution Fetch, Decode, Execute, possibly the Memory stage, and finally the Writeback stage. This is not a pipelined design, however you will be working on a pipeline design in Lab 1.1, so you should design your processor with the goal of pipelining it.
The assembler is fairly simple, a line is broken up into the following components.
SECTION LABEL VALUE COMMENT
SECTION is one of .code, .data, or .value.
LABEL is an identifier (any valid C identifier) followed by a colon.
VALUE is either an instruction or data value, such as integer number, char, or string as would be entered in C.
COMMENT starts with a # at continues to the end of the line.
This should be a simplified form of MIPS assembly, just note that all registers must be prefixed by a $.
Read more about the assembler in the resources section.
Note that the assembler outputs a 32 bit image, a utility script 32to64 has been written to convert that to 64 bit
image used by verilog (and the sim-nc simulator)
The sim-lxre simulator simulates an image, it takes the image filename as an argument.
Adding a -d in front means it prints out helpful debugging information to STDERR.
Once you are done with your processor, make sure that it compiles with
make build-cpu
The file tests/cpu.tv contains a list of programs that run to test the cpu.
To start out with you may want to edit the file so there is halt.
Then run the command
make test-cpu
If your program has an error, you can look at nc/nc.log to see what went wrong.
You can add more tests by creating more .lxre files in the asm/ folder.
Add some more tests, and make sure your code passes them!
You may will need to debug your verilog code.
To aid in this you can add debug statements, to see an example of how you should add one, see verilog/cpu/reg.sv.
To debug your implementation you can run
make test-cpu-debug TEST=name
For example if you want to test how asm/halt.lxre works on your code, you would run
make test-cpu-debug TEST=halt
You may also want to see how the code runs on the simulator, you can run
make test-sim-debug TEST=name
to see what instructions it is executing on the provided simulator.
The following is the debug example from verilog/cpu/reg.sv.
`ifdef DEBUG
$display("DEBUG : REG[%d] = %08x", rdaddr, rddata);
`endif
The DEBUG environment variable will be defined when you use make test-cpu-debug or make test-sim-debug.
The $display(); function works similarly to printf() in C and allows you to print values and strings during testing and simulation.
$display() should normally only be used within conditionals checking if debugging is on or off to prevent them from being seen during synthesis.
Similar to lab 0, you can run design compiler to view the timing characteristics of your design from synthesis. To use design compiler where lxre.sv contains the top level of your cpu run
make time-lxre
The timing report will again look something like lxre (Time = 0.2500) where the cycle time is reported in nanoseconds.
To get the clock rate based on the timing reported by design compiler, you should take the inverse.
In the example reported here, the processor would run at 4 GHz.
With this timing information, you should be able to compute the run time for a program to be able to compare performance for a given program with other groups if you are interested.
If you would like to leave comments or feedback on the lab, please leave a text file called FEEDBACK in your repository and push that along with your handin.
At a bare minimum, it would be useful to know how much time you spent on the lab.