To complete this assignment, you will need to use git to access the starter materials that have been pushed to
your repository by the course staff.
First, run git status and see if it reports any changes. If you have any, you'll need to commit them
before proceeding (git add . followed by git commit -m "Your message here").
Then, run:
git pull (download any commits on the Gitlab server to your local repository)
After running that command, you have synchronized the local copy of your repo with the copy on the server. Very rarely, you may get a "merge conflict" where git can't automatically figure out how to combine the changes we pushed to the server. If that happens, feel free to email the staff list to resolve the issue.
Complete the 24-Hour Time Audit worksheet located in your repo at projects/2/time_audit.docx.
Pick a "typical" day in which you have a number of activities going on (i.e. classes, studying, work, etc.). For 24 hours, track all activities that you are engaging in every 30 minutes. Be honest and be specific. If you are studying for Math 308 and browsing Instagram, note this. If you are spending time cooking breakfast and washing dishes, note this. Once you have completed your 24-hour time audit, complete the reflection questions on page 2 of the document.
Edit the document "in-place" and submit by pushing to GitLab — that is, make sure the completed version has the same name in the same location and commit/push the changes just like you did in Project 0 and the Project 1 reflection.
The centerpiece of the computer's architecture is the CPU, or Central Processing Unit — and the centerpiece of the CPU is the ALU, or Arithmetic-Logic Unit. In this project you will gradually build a set of chips, culminating in the construction of the ALU chip of the computer we are building (called the "Hack" computer). The design of the ALU differs between all computers, but the rest of the chips you will build are standard and used in real computers today!
BEFORE starting the work for Part II: Boolean Arithmetic (but after reading through the spec), estimate how long you believe it will take you to complete it. You will need to include this for your reflection in Part IV.
In this project, you will again build a set of chips. The only building blocks you can use are any chips you've already implemented (whether in Project 1 or in this project), AND the "Additional Chips" listed in Project 1 that were not assigned for credit. As before, we highly recommend you implement in the order listed here.
| Chip Name | Description | Test Script | Expected Output |
|---|---|---|---|
| HalfAdder | Adder with 2 inputs, sum & carry outputs | HalfAdder.tst | HalfAdder.cmp |
| FullAdder | Adder with 3 inputs, sum & carry outputs | FullAdder.tst | FullAdder.cmp |
| Add16 | 16-bit Adder | Add16.tst | Add16.cmp |
| ALU | Arithmetic Logic Unit (initial version, only needs to support the And function and doesn't
need to handle status outputs) |
ALU-nostat-noadd.tst | ALU-nostat-noadd.cmp |
| ALU | Arithmetic Logic Unit (revised version, supports both And and Add but still no
handling of status outputs) |
ALU-nostat.tst | ALU-nostat.cmp |
| ALU | Arithmetic Logic Unit (complete version) | ALU.tst | ALU.cmp |
When loaded into the supplied Hardware Simulator, your chip design (modified .hdl program), tested on the supplied .tst script, should produce the outputs listed in the supplied .cmp file. If that is not the case, the simulator will let you know.
The relevant reading for this project is Chapter 2 and (again) Appendix A. Since you will be depending heavily on chips from Project 1, you may find this Chip Set Overview helpful to look up the chip signature (i.e. names of connections) for the chips you need. Like the previous project, you may also find this HDL Survival Guide written by Mark Armbrust helpful.
For each chip, we supply a skeletal .hdl file with a place holder for a missing implementation part. In addition, for each chip we supply a .tst script that instructs the hardware simulator how to test it, and a .cmp ("compare file") containing the correct output that this test should generate. Your job is to complete and test the supplied skeletal .hdl files. For the ALU, two additional .tst scripts are provided to test your intermediate implementations. The Hardware Simulator will allow you to load the intermediate scripts and the ALU chip to test them, even though they don't have the same name.
You will find the supplied Hardware Simulator and all the necessary project files in the tools/
directory and in the projects/2 directory of your repository, respectively.
Using built-in chips: The HDL programs you write will include chip parts that you've built in Project 1. However,
as long as you don't copy those .hdl files into the projects/2 directory, the Hardware Simulator will
use the built-in versions instead. We strongly recommend using the built-in versions so you don't have to depend
on a complete implementation of the previous project to complete this one (and it will speed up chip execution
slightly).
Implementation order: While we recommend building the chips in the order above, just like in Project 1 the Hardware Simulator has built-in versions that can be used if you are stuck on one and want to move on. To use the built-in version, simply rename the file, so the Simulator doesn't find "{chipname}.hdl" in the directory and try to use it.
The Hack ALU produces two kinds of outputs: a "main" 16-bit output resulting from operating on the two 16-bit inputs, and two 1-bit "status outputs" named 'zr' and 'ng'. We recommend building this functionality in three stages:
And function (ignoring the f input bit) and ignoring the zr and
ng status outputs. When completed, your implementation should be able to pass the
ALU-nostat-noadd.tst tests.
And and Add functions (using the
f input bit). Your implementation should now pass the ALU-nostat.tst tests.
ALU.tst. Now you have a fully functioning ALU!
By using this approach, you can better detect problems as you add code to your implementation, attributing errors seen in each new test to the incremental code that you've added in that stage. This three-staged implementation plan was initially proposed by Mark Armbrust and iterated upon by our course staff.
Don't forget to peruse Chapter 2 of the online textbook before you start implementing chips. It breaks down each one's interface in depth, and often describes strategies for implementation.
When you test your code by running the hardware simulator as shown in lecture by loading the corresponding .tst script and pressing Run, it may indicate a "comparison error". When that happens, we recommend going to your file explorer and searching for: (1) a corresponding .cmp file that shows the inputs being tested and EXPECTED outputs of your chip, and (2) a corresponding .out file that shows the ACTUAL outputs of your chip when tested. Given that information, a good next step is tracing through your design with those inputs to see why it produced the value it did.
The following additional chip (described in Chapter 2) can be used in future projects, but you are not required to implement it. Again, the goal is to give you a tool you can use to make future projects easier, but there is little to be gained by implementing this yourself.
You're now in the midst of developing a (virtual) computer! There are many social aspects and issues related to hardware design, development, and production and your first social reflection is aimed at exploring some of these. First, read through the general reflection details and requirements which will give you an idea of what's required for the reflection. Then find an article/blog/paper to complete the requirements with that is loosely related to the prompts below. The prompts don't have to be strictly adhered to, they are just there to give you an idea of possible topics you could explore for this reflection.
There is a document called project_2_reflection.docx located in the projects/2 directory
where you can complete the reflection. Edit the document "in-place" and submit by pushing to Gitlab.
To submit your project, make sure you commit and push your changes, then tag them as project-2 and
push that tag as well:
git add . (stage all your changes)git commit -m "Finish project 2" (bundle those changes as a commit; the message is up to you!)
git push (push that commit to the Gitlab server)git tag project-2 (add the project-2 tag to that last commit)git push --tags (push the tag to the Gitlab server)Then, verify that the tag and all your code is uploaded correctly by checking on gitlab.cs.washington.edu.
Below are the skills you need to demonstrate in order to pass this project, along with concrete tasks we expect you to complete to demonstrate each skill. Remember that in order to receive a passing grade for the class, you must receive a passing grade on each project. Only completing the bare minimum to pass a project will result in a low grade. See the syllabus for more details and let us know if you have any questions.