Project Code Testing
1. Coding and Design
- Keep your demo1 and demo2 code in separate directories. These have already been created for you in the project tar file.
- You must use the
proc_hier_bench files. No other interfaces or naming conventions are allowed.
- Using the
wsrun.pl script will be easier than compiling and running with graphic Modelsim. Commond-line tutorial here.
- Complete the wire assignments in
proc_hier_bench.v to wires inside your design.
2. Steps to Test Your Design
NOTE: The steps below show how the process for testing assembly programs work. We have provided a script (see section 3) to automate all these for your convenience.
- Write test programs and use provided test programs.
- Use the assembler to create binary images of these programs. See the Using the Assembler page.
- Load these programs into the instruction memory of the processor. The memory module section on project page explains how to load the binary image into memory.
- As soon as reset is done, your PC will be initialized to 0. Your processor will thus start fetching from address 0 in memory and begin executing your program.
- Check the values in registers and memory as the program executes to make sure your processor is executing as expected. Examine waveforms and also look at the "SIMLOG" messages.
- You may also use the WISC-SP13 simulator-debugger to step one instruction at a time.
- You will have to "hand-execute" the program on pencil-paper to determine the expected values.
- There is a dump memory contents option to examine the values written to memory.
3. Automated Testing
wsrun.pl script comes with a
wsrun.pl -prog foo.asm proc_hier_bench *.v
- Go to the directory which has the Verilog code of all your modules.
- At the prompt, run
wsrun.pl with the
-prog flag. This will assemble the program, compile your Verilog design, and then run the program on your Verilog design. A "trace" of changes to the architecture state for each instruction's execution is written to a file called
- It will also run the program on our reference instruction simulator
wiscalculator. A "trace" of changes to the architecture state for each instruction's execution is written to a file called
- If these two traces ever differ, then there is a bug in your design. Find the first PC at which the two traces differ, examine waveforms, and debug.
- Differences are written to a file called
4. Verifying Pipelined Implementation
As you may have realized, generating the trace with PC, INSTRUCTION, REG, MEM ADDR, and MEM VALUE is more complicated for a pipelined design than for the single-cycle design. So for the pipelined design, we will opt for a simple trace format - we'll call this the pipe trace and give it a
Every cycle that a value is being written to the register file (in write-back stage), or being read from memory (in memory stage), or being stored to memory (in memory stage), we will record an entry. PC and the instruction bits will not be recorded. Since NOPs, and branch instruction do not effectively change the registers or memory, they will create no entries in this simplified trace format.
There are 4 differences compared to non-pipelined trace:
- You must run
wsrun.pl with the
-pipe option while using this testbench.
- You will use a new testbench called
wiscalculator has been modified to generate a compatible
.ptrace file also. At the end of a simulation, you will see
- Differences are saved in
diff.ptrace. This is an intelligent diff that will annotate the original
.ptrace filled with the instructions and the PC, so its easier to track failures.
- A new RELAX-PASS status has been added. This status indicates that your processor is doing a set of extra register writes or memory reads or memory writes, but they are not corrupting any state. You should FIX this problem!
Everything else remains the same. To run a program:
wsrun.pl -pipe -prog foo.asm proc_hier_pbench *.v
On failure, see
diff.ptrace. Raw ptrace files are