When you are ready for checkout, you should contact the TA to schedule a time. You can do the checkout as late as you wish before the final deadline. Your final design review should happen after you have finished your checkout. The checkout can be a long process(average about 8 hours in the past). During the checkout, you will be asked to run public and private test cases. You will be asked to debug your design if you do not pass a testcase. We will record the bugs and how long it took you to debug them. Note: You cannot pass the checkout if you do not pass all the test cases.
Loading the program
The public/private test cases will be provided in hex format.
Make sure you create scripts to automatically load the byte code in memory.
Each group decides its own format to load the binary in memory, thus, it is your responsibility to get some automatic tools for this operation.
Some test cases will be long enough to make doing this by hand undoable.
Executing the test cases
In order to efficiently demonstrate the project, the TAs will execute the public test cases found in the website and several private test cases.
The waveforms are very useful for debugging, however, in order to check the correct behavior of your project, the TAs will execute some test cases step by step
checking every instruction.
For this reason, printing the architectural state of the machine for every instruction in the terminal will make things faster.
The more compact and clearer the printing is the better. Including virtual/physical addresses is highly recommended for load/store instructions.
EAX: 0x00ccbbaa
EBX: 0x00ccbbaa
.. ....
I/O tests
You will write your own I/O test for your project. The test should have the following behaviors:
1) Load and store requests going to the I/O devices should bypass the cache.
2) Load and store requests to the simple I/O device.
3) A DMA transfer.
4) Conflicts on the bus. Your DMA should not hold the bus for the entire transfer. (During the DMA transfer, there should be other activity on the bus as well)
You may choose to write one or more tests to cover all the behaviors.
Timing Violations
There should not be ANY timing violations in your design, on the wrong path or the correct path.
Real time debugging
While doing the checkout of the project with the TAs, one student is demonstrating a test case to the TAs.
Meanwhile, it is preferable that the other students are ready
to debug with a laptop or at another desktop. Thus, TAs can also evaluate how the group works and thinks towards solving the bugs found.
Groups that have worked together tend to know more about all the pipeline stages and tend to be faster solving bugs.
Optimizations
You may keep optimizing your design after the checkout. This includes but is not limited to cycle time, branch prediction or prefetching.
Project Verification
Several groups have several tricks to make verification easier:
1) Only one group did not use a control version system and they had a lot of problems with code versions and
detecting when and how they solved each bug
2) One group built a 'golden' model in Behavioral Verilog that implemented all instructions and checks the correctness of each instruction after its retired.
3) Other groups introduce regression tests in their compilation process, thus, every new feature added gets checked with the automatic regression test before it is
introduced in the project repository.
4) Several groups developed scripts to automatically generate code. This is very useful since it checks many formats for all instructions. However,
one needs to make sure it does not forget some cases such as segment overrides, exceptions, etc which are not so common but normal.