The purpose of this is lab is to familiarize youself with the tools the you will be using to design a DLX CPU. You will be asked to use git to clone and push the lab, write Verilog modules for an adder, adder/subtracter, and a resetable enablable flip flop.
We will be using tera for the labs.
Tera is a Linux machine running Red Hat Enterprise Linux 5.
If you were enrolled in the course as of 21 Jan 2013, you should have a tera username and password.
Your username should be the same as your charlie username.
If you already have a tera account for some other reason, your tera password is unchanged.
Otherwise your password should have been provided to you in class.
You can remotely accesses tera (tera.eng.hmc.edu) from any computer on campus with an SSH program.
PuTTY is a free SSH program for Windows.
Linux and Mac users can use the built-in ssh client by typing int their terminal
ssh <username>@tera.eng.hmc.edu
We are sharing tera with two research groups an many clinic teams.
If you expect to have a long running program please nice it so priority can be given to terminal access
nice -n 19 <command you wish to run>
Your group name will be based on your group members' usernames in alphabetical order.
If my username is jspjut and my partner's username is acarter then our group name would be acarter-jspjut.
Note that the order of the names is alphabetical by username, and not by first name or last name unless that happense to agree with the alphabetical ordering for usernames.
You will need to know your group name to be able to push your revisions when they are ready to hand in, and in order to complete the required portions of the lab.
Note that if you change partners in a future lab, your group name will also change.
Git is a powerful, if not very user friendly, revision control and source code management system. For this class you will be using git to recieve copies of lab data, and hand in your finished lab. In addition it is recommended that you use git to manage the files in the project while you are working on them. Git documentation is available at git-scm.com. In order to use git on tera you need to register a public key with tera so the server knows who you are. If you already have a public key that you use to log in you can run
git-add-key <name of public key file>
If you do not have a public key for tera, or have no idea what that means, omit the file to generate one.
Once you register a public key, you an clone the repository for lab 0 by running
git clone git@tera.eng.hmc.edu:e190o-s2013 e190o
this will create a repository in a folder named e190o, you can checkout into a different folder name if you want.
This command will generate a warning: remote HEAD refers to nonexistent ref, unable to checkout..
The remote does not have a master branch, and is instead broken up into different branches for each lab.
Unlike the remote you will be working on the your master branch locally, but can create different branches to work on things simultaneously if you would like.
Note, unlike centralized version control systems like SVN, git is a distrubuted system.
You are cloning the repository, not checking it out.
This that the repository is a seperate instance and is equal to the one on tera,
When you commit you are committing to the local repository and in fact do not have write permissions to the one on tera.
Change your directory into the root directory of the lab, if you cloned into e190o it would be,
cd e190o
Run
git pull origin lab0:master
This tells git to pull the lab0 branch from the origin repository (the repository that you cloned from) and label it as master locally.
Add your group name to the rubric.txt.
There are several text editors available on tera including nano,gedit,vim,emacs.
You may want to start with nano, but vim and emacs provide much greater power if you are willing to learn the commands.
To add your changes to git's staging area, run
git add rubric.txt
Then commit the changes with
git commit
Finally push the changes to your group's handin repository by running
git push git@tera.eng.hmc.edu:e190o-s2013-<group name> master:lab0
this tells git to push the master branch of the local repository to the lab0 branch of the remote repository.
This section of the lab is to refresh your verilog skills.
You can look at a number of example verilog modules, and write a few yourself.
In the verilog directory there are two subdirectories bit and word.
Look over verilog/bit/ohmn.sv and verilog/bit/ohmn.sv as examples of combinational logic,
verilog/word/ohmn.sv as an example of module instantiation,
and verilog/bit/flop.sv and verilog/bit/latch.sv as an example of sequential logic.
In verilog/word/adder.sv there is a stub for an adder module.
Using verilog/word/ohmn.sv as an example write the adder module with using + or - operators.
When you are done, commit your changes to the local repository.
There is a test vector file for the adder module in tests/adder.tv.
It currently only has one simple test vector, add more, and commit your changes.
When you are done, you can try testing your adder by runing
make test-adder
Modify the files until it passes all of your tests, and commit your changes.
In verilog/word/addsub.sv is a stub for an adder and subtracter module.
Using your adder module and additional combination logic write an add and subtract module.
Once again do not use the + or - operators in your code.
When you are done, commit your changes again.
The test vectors are in tests/addsub.tv.
It also currently only has one test vector, add more, and commit your changes.
When you are done, the command to test your addsub is
make test-addsub
In verilog/bit/flopren.sv is a stub for a resetable and enablable flip-flop.
Using sequential logic, write the flopren module (do not instantiate the latch or flop module).
When you are done, commit your changes again.
The test vectors are in tests/flopren.tv.
It also currently only has one test vector, add more, and commit your changes.
When you are done, the command to test your flopren is
make test-flopren
One thing to note is that the flopren can have race conditions.
In your test vectors do not have d, r or en and clk change at the same time.
It is undefined whether clk goes high first or second so d, r and en would have undetermined values.
In later labs there will be a tradeoff between how many cycles it takes to run a program, and how long each cycle takes. Roughly speaking the amount of time a program takes is equal to (Instructions per Program * Cycles per Instruction * Time per Cycle). At the hardware level you will only be able to change Cycles per Instruction and Time per Cycle. We can get a rough count of Cycles per Instruction by executing a benchmark program and seeing how many instructions it ran in how long. In order to see Time per Cycle we need to synthesize the module. In this course we will be using Design Compiler (DC) with a 45nm library. Using synthesis tools like Design Compiler can be a very time consuming process, but for this course we only want rough estimates.
We have set up the necessary scripts for you to run, try running
make time-flop
This should take about 16 seconds to run.
This runs a script in scripts/dc.tcl (you don't need to look at it) that synthesizes the bit_flop module.
Running and make time-name command runs the timing and dumps the results in results/timing.report.
If you open up results/timing.report it should say something similar to
bit_flop (Time = 0.0658)
If this is not the case, then output of DC is put into dc/flop.run.
This output is useful for determining what went wrong with DC.
For this lab it is probably just best that you e-mail the grader with that file attached if there is an error.
We don't want you to spend too much time working on synthesis.
DC also gives timing information on the critical paths, this file will be dumped into dc/bit_flop.time.
Take a look at that file.
There is actually instructions to get timing information on all of the modules you made. Run the command
make timing
this command might take up to a minute, make sure that you get timing reports for all of the modules.
Take a look at the dc/*.time files, especially the dc/adder.time and dc/addsub.time, make sure you understand what the critical path of these modules are.
make tests
should pass all of your tests.
Submit the code by running
git push git@tera.eng.hmc.edu:e190o-s2013-<group-name> master:lab0