Project 5: Building a Computer Part II and Timed Mock Exam
Due on Thursday, February 17th at 11:59pm PST
Objectives
- To combine the components you've built in previous projects, culminating in a fully working computer!
- To study the flow of data within a typical computer system.
- To practice taking a mock exam and reflect on how you prepare for exams.
Part 0: Get the Starter Materials
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.
Part I: Timed Mock Exam Problem
Each pair or triad of students will set-up a 30 minute session outside of class to conduct a timed mock exam problem. Time will be allocated in class for each pair/triad to connect and coordinate a time to do the mock exam problem. Once a time has been determined, students will need to note the day and time in which their pair/triad will be meeting on the google sheet shared in class. A link to the sheet can also be found on the course Discussion Board.
In your 30 minute session, each group will perform the following items:
- Set-Up: 5 minutes
- Remove as many distractions as possible (i.e. find a quiet space, turn your phone to silent, etc).
- Each student should have their camera on
- Determine someone to start a timer for your mock exam problem
- Grab a scrap piece of paper and pen for working through the mock exam problem
- Pull-up the mock exam problem that was emailed to you the morning of
- Do the Mock Exam Problem: 10 Minutes
Spend 10 minutes working through the mock exam problem individually. Treat it as though it is a problem on an exam!
- Debrief & Complete Reflection: 15 minutes
After your time is up, debrief and discuss how you approached the mock exam problem and what that experience was like for you. As a pair/triad, complete the questions in the
mock_exam_reflection.docxdocument located in your repo. Each person should type up and submit the answers you discuss.
Part II: Building a Computer
Background
In previous projects we've built the computer's basic processing and storage devices (ALU and RAM, respectively). In this project we will put everything together, yielding the complete Hack Hardware Platform. The result will be a general-purpose computer that can run programs written in the Hack machine language.
Overview
Like projects 1, 2, and 3, in this project you will build a set of HDL chips. This time, you will build the highest-level chips in the whole system, culminating with the "Computer" chip itself. As usual, you should construct these chips using the chips listed in previous projects (with a few exceptions noted below), and we recommend going in the order shown.
| Chip Name | Description | Testing |
|---|---|---|
| LoadDReg.hdl | Logic related to loading the D register. Estimated Difficulty: Easier. | Test your chip using the provided LoadDReg.tst (& LoadDReg.cmp) test script. |
| LoadAReg.hdl | Logic related to loading the A register. Estimated Difficulty: Easier. | Test your chip using the provided LoadAReg.tst (& LoadAReg.cmp) test script. |
| JumpLogic.hdl | Logic related to the program counter's load and inc signals. Estimated Difficulty: Mediumish. | Test your chip using the provided JumpLogic.tst (& JumpLogic.cmp) test script. |
| CPU.hdl | The Hack CPU. Should make use of the previous three chips in your implementation, and we recommend using the ARegister and DRegister built-in chips for the corresponding registers in your implementation (see the Tips section for more information). Estimated Difficulty: Harder. | Test your chip using the provided CPU.tst (& CPU.cmp) test script. |
| Computer.hdl | The computer itself! The top-most chip you will implement in this course. Estimated Difficulty: Easier. | Test your chip by running Hack programs on it! You can start with the three listed below. |
Contract
When run in the hardware simulator, the system you build should be capable of correctly executing programs written in the Hack machine language, as specified in Chapter 4.
Testing
Testing LoadDReg, LoadAReg, JumpLogic and CPU: It's crucial to unit-test these chips before integrating them into the overall Computer chip. We recommend starting with the LoadDReg, LoadAReg, and JumpLogic chips, and then using those to aid your CPU implementation.
Testing the Computer: Note that the Hack architecture and Hack machine language go hand-in-hand — that is, the specification of the Hack architecture's behavior (which you are implementing in Computer.hdl) is exactly defined by the rules and specification of Hack machine language. Therefore, the most effective way to test the correctness of Computer.hdl is to try running different Hack machine language programs on it! We provide three test programs that can be used for this purpose, listed below. Note that "running a program" on Computer.hdl consists of inserting that program's instructions on ROM, then starting the simulation. This is essentially like inserting a chip with a single program hard-coded on it into your computer before powering it on, which isn't quite analogous to the way your laptop executes programs, but is actually done in practice for things like microcontrollers and embedded systems! We choose that approach in this project for its simplicity.
For each of the following .hack programs, a corresponding .tst file (& .cmp file) is provided that will load it into ROM and execute it for you.
| Program | Description |
|---|---|
| Add.hack | Adds up the two constants 2 and 3 and writes the result in RAM[0]. Recommended script to test: ComputerAdd.tst (& ComputerAdd.cmp). |
| Max.hack | Computes the maximum of RAM[0] and RAM[1] and writes the result in RAM[2]. Recommended script to test: ComputerMax.tst (& ComputerMax.cmp). |
| Rect.hack | Draws a rectangle of width 16 pixels and length RAM[0] at the top left of the screen. Recommended script to test: ComputerRect.tst (& ComputerRect.cmp). |
A Note on Testing: For this project, alternative test files are provided, suffixed with -external. That's because the normal test files exploit certain "behind-the-scenes" data exposed by the built-in versions of certain chips (like ARegister and DRegister) to read internal state of your CPU, allowing them to be much more thorough. However, if you would like to forego these built-in chips and use your own implementations instead, you won't have access to that additional testing data from your components, so you would have to use the -external versions which use only the chip's outputs to test. We strongly recommend the former approach, because the -external tests are not as thorough in general (and ARegister, DRegister, etc. have helpful GUI representations you can use for debugging).
Resources
See Chapter 5 for details about the computer's implementation, and refer to Chapter 4 for details about Hack machine language (particularly the encoding of its instructions). Use the HDL Reference or HDL Survival Guide to look up details of the language, and the TDL Reference to look up details about the test scripting language. You may also find the Hack Chip Set reference useful to remember chip interfaces.
Tips
We risk repeating ourselves too much here, but we strongly recommend you use the textbook chapters, specifically Chapter 5 and Chapter 4 (sections 5.3.1, 4.2.2, and 4.2.3 will be especially helpful with some of the details of the assignment).
Implementation Strategy
Complete the computer's construction in the following order:
LoadDReg, LoadAReg, and JumpLogic: These chips implement some of the combinational logic of the CPU, and we provide you tests to help check you understand the specifications correctly. This will hopefully allow you to build the resulting CPU in a more incremental manner (potentially helping catch future bugs).
CPU: This chip can be constructed according to the proposed CPU implementation given in Figure 5.9 of Chapter 5, using the ALU and register chips built in Projects 2 and 3, respectively. However, we recommend using built-in chip-parts instead, in particular ARegister and DRegister. The built-in versions of these two chips have exactly the same interface and functionality as those of the Register chip specified in Chapter 3; however, they feature GUI side-effects that come in handy for testing purposes.
We have chosen to include internal chips (LoadDReg, LoadAReg, JumpLogic) not mentioned in Figure 5.9 of Chapter 5. This might yield a slightly less efficient CPU design, but the added scaffolding will hopefully make implementing the CPU more manageable. We do not recommend creating more internal chips than the ones we provide, though it may be possible (feel free to ask us if you have any particularly intriguing ideas in mind).
Instruction Memory: Use the built-in ROM32K chip. It is similar to the RAM chips you've implemented, but handles the loading of programs for you.
Computer: The top-most Computer chip can be constructed according to the proposed implementation shown in Figure 5.10 of Chapter 5.
Debugging tips
Due to the interconnected nature of the CPU, it can be difficult to debug when things are not quite working. We've compiled a list of debugging tips/strategies to try to help guide your debugging. We also encourage you to start early and make use of the discussion board and office hours when you find yourself stuck on a particular part. Here are some things you can do to debug your program:
- Use the .cmp and .out files to find your issue. Determine the exact component/signal that is causing the tests to fail. This will help you focus your scope a bit more.
- Use the circuit diagrams to determine what the failing component relies on. Because the CPU is so interconnected, a failing component could be a result of a bug in some earlier calculation. Determine the internal wires that your component uses as inputs.
- Figure out what the expected values for the internal inputs to your component should be. This is probably the hardest part. Use the specifications and the .cmp file to determine what the values of your input wires should be at the point of failure (they may not be explicitly listed, i.e. you might have to "play computer" to determine the expected value).
- Determine which internal wire to your component is incorrect. You can use the HardwareSimulator to view the state of the internal wires at the time of failure. Check to see if any do not look how you expect them to.
- Review the logic that feeds the incorrect internal wire, potentially working further back in your implementation as necessary. There could be multiple possible reasons why a wire may have the wrong value. For example, if it comes from a register, the issue could be that the register loaded when it shouldn't, or that the wrong input was fed to the register in the first place. Determine the cause of the issue, and then work back further if need be to try to find the source of the issue
- It may feel overwhelming at first. There is a lot going on, so it's going to feel overwhelming at first. Start small by determining what you can be 100% sure of, and reach out if you aren't sure where to begin looking!
Tools
As usual, you will test your chip implementations using the Hardware Simulator. The following diagram shows an example of testing the Rect.asm program using it.
Submitting
To submit your project, make sure you commit and push your changes, then tag them as project-5 and push that tag as well:
git add .(stage all your changes)git commit -m "Finish project 5"(bundle those changes as a commit; the message is up to you!)git push(push that commit to the Gitlab server)git tag project-5(add the project-5 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.
Project Skills and Passing Requirements
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.
- Practice taking a mock exam and reflect on how you prepare for exams
- Complete the timed mock exam exercise
- Begin to build complex, interconnected hardware chips
- Have a close-to-working CPU implementation (including working LoadDReg, LoadAReg, and JumpLogic chips)