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.
In Project 1, you had the opportunity to peruse and reflect on any reading related to the social computing of hardware. We posed a few general questions related to social computing as possible topics you could explore and left the prompt fairly open-ended so that you could explore a higher-level overview of all the societal questions, quandaries, and considerations of building hardware.
As we explore various topics in bottom-up computing, we'll explore more and more specific computing areas that have societal connections. We will aim to hone in on a social computing application relevant to the CSE 390B course content taught each respective week. This is so that we aren't so close to the technical subject matter itself that we overlook the bigger picture ramifications of the technical work that we do. Even though we're computer scientists, it's important that we think about the soceital impact of our work. We've heard this in lecture before, but it's worth repeating that computer science is not a neutral, but social discipline!
For this week, we learned about the boolean arithmetic and the idea of binary overflow. One of the major consequences of binary overflow is buffer overflow. We'll touch on these subjects in later weeks of the course, but buffer overflow occurs when certain parts of computer memory (essentially binary values stored in computers at a greater scale) are inadvertently overwritten due to overflow. As it turns out, buffer overflows have resulted in a number of exploits and security vulnerabilities that have caused historical accidents and tragedies. Find an article below of a buffer overflow-related incident:
And reflect on the following questions below. You may choose a related article related to buffer overflows or other topic related to the topics we have explored in the course so far. You will only need to answer the questions in the document included in the starter code, but you may incorporate any of your thoughts about these reflection questions in the document you write in. The general reflection details and requirements of the social computing reflection can be found here.
There is a document called p2_social_computing.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 the changes as a commit)
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.