Skip to main content

Verification & Simulation

Links to specific parts of document:

1.  Coding and design

  1. Keep your demo1, demo2, and demo3 code in separate directories. These have already been created for you in the project tar file and will make it easier for you to manage and submit code.
  2. You must use the proc, proc_hier, proc_hier_bench files in the original project tar file tar. No other interface or naming convention is allowed.
  3. Using the wsrun.pl script will be easier than compiling and running using ModelSim Tutorial here.
  4. Complete the wire assignments in proc_hier_bench.v to wires inside your design.

2.  Steps to verify 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.
  3. Read the Using the assembler document.
  4. Load these programs into the instruction memory of the processor. The memory modules explain how to load the binary image into memory.
  5. As soon as reset is done, your PC will be initialized to 0
  6. Your processor will thus start fetching from address 0 in memory and begin executing your program
  7. 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.
  8. You may also use the WISC-SP22 simulator-debugger and step one instruction at a time to determine what the expected output of the program is.
  9. You will have to "hand-execute" the program on pencil-paper to determine the expected values
  10. There is a dump memory contents option to examine the values written to memory

As mentioned above, you no longer need to do any manual "hand-execution". See below for details.

3.  Running tests programs on your processor

  1. Use the wsrun.pl script with the -prog flag. See wsrun.pl details page.
  2. Go to the directory which has the verilog of all your modules.
  3. At the prompt, type
    wsrun.pl -prog <assmebly program file name> proc_hier_bench *.v
    This will assemble the program, compile your verilog, and the run the program on your verilog. A "trace" of changes to the architecture state for each instruction's execution is written to a file called verilogsim.trace
  4. 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
  5. 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.
  6. 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 the pipe trace and give it a .ptrace extension.

Every cycle that a value is being written to the register file (write-back stage), or being read from mem (memory stage), or being stored to memory (mem 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:

  1. You will use a new testbench called proc_hier_pbench.v. wiscalculator has been modified to generate a compatible .ptrace file also. At the end of simulation you will see archsim.ptrace and verilogsim.ptrace
  2. You must run wsrun.pl with the -pipe option while using this testbench.
  3. Differences are saved in diff.ptrace. This is an intelligent diff which will annotate the original ptrace fill with the instructions and the PC, so its easier to track failures.
  4. A new RELAX-PASS status has been added. This means 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

5.  Verifying Stalling Memory and Cache integrated into processor

As some of you have noticed the stalling memory and the cache modules, do NOT allow unaligned accesses. They all set err output. Our instruction emulator has this feature also, which can be enabled by passing it the -align flag. Henceforth in your simulations you will be using the -align flag which can be passed using wsrun.pl. To simulate your designs with stalling memory and your cache modules integrated, you must do the following: 

          wsrun.pl -align -pipe -prog foo.asm proc_hier_pbench *.v

A specific align test (alignTest.asm) has been added to the complexdemo2 which you can use to test.

Within your design you must OR the err outputs from different state machines and propagate the err output all the way up to the top-level and into the clkrst.v which will STOP simulation when the err output is encountered.

6.  Cache hit rates in processor

A performance tracking enhancement to the proc_hier_pbench.v testbench is also present. The following 4 signals, allow the testbench to track instruction and data cache hit rates for the programs executed: ICacheReq, DCacheReq, ICacheHit, DCacheHit.

See below for the signal names and descriptions. The assignments are dummy assignments.

Connecting these signals is OPTIONAL, but I highly recommended it. If you do not want to use them, simply assign them to 1'b0. If you do connect these signals, you will see IHITRATE and DHITRATE in the summary.log file. These are percentages - they should never exceed 100%.

You can use this data to analyze your processors performance on the programs you are running. Also, in a real industry processor, techniques very similar are use to implement so-called performance counters to measure such events. 

          // new added 05/03
          assign ICacheReq = DUT.p0.readData;
          // Signal indicating a valid instruction read request to cache
          // Above assignment is a dummy example

          assign ICacheHit = DUT.p0.readData;
          // Signal indicating a valid instruction cache hit
          // Above assignment is a dummy example

          assign DCacheReq = DUT.p0.readData;
          // Signal indicating a valid instruction data read or write request to cache
          // Above assignment is a dummy example
          //
          assign DCacheHit = DUT.p0.readData;
          // Signal indicating a valid data cache hit
          // Above assignment is a dummy example