3. Running tests programs on your processor

At the prompt, typewsrun.pl -prog <assmebly program file name> proc_hier_bench *.vThis 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

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

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 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:

You will use a new testbench called proc_hier_pbench.v. See the project modules page. wiscalculator has been modified to generate a compatible .ptrace file also. At the end of simulation you will see archsim.ptrace and verilogsim.ptrace

You must run wsrun.pl with the -pipe option while using this testbench.

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.

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.