Project 5: Building a Computer & Professor Meeting Report
Due 11:59pm Tuesday, May 12
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 gain confidence, practice, and perspective by talking with your professors.
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: Professor Meeting Report
For this part of the assignment, you will meet with the professor for one of your classes and write a short report reflecting on your experience. Read the full instructions in your repo given in the file projects/5/professor_meeting_instructions.docx. After you have read the instructions and met with your professor, you will submit your report by uploading a separate .docx or .pdf file in the projects/5 directory of your repo.
Since some course instructors may take a while to get back to you, we strongly recommend reaching out ASAP to set up a meeting. When you do meet, be sure to come prepared with a list of questions to ask. If you have emailed your professors in advance and believe you will have trouble setting up a meeting with the professor of your choice, please email the course staff and we will make another arrangement. If needed, we would be happy to extend the assignment deadline to make sure you get the most out of your experience!
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 |
|---|---|---|
| Memory.hdl | Entire RAM address space. Estimated Difficulty: Medium. | Test your chip using the provided Memory.tst (& Memory.cmp) test script. |
| CPU.hdl | The Hack CPU. Estimated Difficulty: Hard. | 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: Easy. | 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 the Memory and CPU: It's crucial to unit-test these two complex chips before integrating them into the overall Computer chip.
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.
We've recorded a short ~15 minute optional video briefly describing this assignment, tips for your implementation, and a debugging strategy that you may have been using before but will be particularly helpful for this project. Note: You must be logged in to your @cs account to view.
Project 5 Tips & Debugging Strategies
Use the following timestamps if you want to navigate to a certain portion:
- 0:00 - Brief introduction to Project 5, describing your responsibilities, budgeting your time on the project
- 5:39 - Practical tips for Project 5, approaching CPU.hdl, multi-bit bus representations
- 9:39 - Debugging process for Project 5, viewing .cmp and .out files on disk, using the Hardware Simulator to narrow down bugs
Tips
Complete the computer's construction in the following order:
Memory: This chip includes three chip-parts: RAM16K, Screen, and Keyboard. The Screen and the Keyboard are available as built-in chips, and thus there is no need to implement them. Although the RAM16K chip was built in Project 3, we recommend using its built-in version, as it provides a debugging-friendly GUI.
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.
In theory, your CPU implementation may include internal chips of your own specification, i.e. chips not mentioned in Figure 5.9 of Chapter 5. However, this is not recommended, and will most likely yield a less efficient CPU design. If you choose to create new chips not mentioned in the book, be sure to document and unit-test them carefully before you plug them into the architecture.
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.
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.