Verification and Simulation

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, proc_hier, and 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.

1. Write test programs and use provided test programs.
2. Use the assembler to create binary images of these programs. See the Using the Assembler page.
3. 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.
4. 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.
5. 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.
6. You may also use the WISC-SP13 simulator-debugger to step one instruction at a time.
7. You will have to "hand-execute" the program on pencil-paper to determine the expected values.
8. There is a dump memory contents option to examine the values written to memory.

3.  Automated Testing

The wsrun.pl script comes with a -prog flag.

  wsrun.pl -prog foo.asm proc_hier_bench *.v

1. Go to the directory which has the Verilog code of all your modules.
2. 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 verilogsim.trace.
3. 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 archsim.trace.
4. 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 diff.trace.

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 .ptrace extension.

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:

1. You must run wsrun.pl with the -pipe option while using this testbench.
2. You will use a new testbench called proc_hier_pbench.v. Our wiscalculator has been modified to generate a compatible .ptrace file also. At the end of a simulation, you will see archsim.ptrace and verilogsim.ptrace.
3. 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.
4. 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 archsim.ptrace and verilogsim.ptrace.