Verification and Simulation

Project Code Testing

1.  Coding and Design

• Keep your demo1, demo2, and demo3 code in separate directories. These have already been created for you in the project git repo under the names /wiscv/nopipe, /wiscv/pipe, and /wiscv/withcache.
• You must use the provided files (core, proc, decode, execute, etc.). No other interface is allowed
• Using the provided makefile will be easier than compiling and running with graphic Modelsim.

2.  Automated Testing

2.1  Setting Up the Makefile

Before you use the provided makefile to verify and simulate your processor, you will have to add the following to your bashrc.local file (this will have to be done on a CSL machine):

export PATH=$PATH:/p/vertical/projects/552RISCV/riscv_toolchain_install/bin
export MGC_HOME=/s/mentor-2018/@sys/V10.0BSXE/MGC_HOME.ixl 
export MGLS_LICENSE_FILE=/s/mentor-2018/etc/cust/mgls/mgc.licenses
export PATH=$PATH:/s/mentor-2018/@sys/bin:/s/mentor-2018/@sys/bin.pclinux:/s/mentor-2018/@sys/V10.0BSXE/MGC_HOME.ixl/bin:/s/mentor-2018/@sys/modelsim_dlx/bin

2.2  Running the Makefile

The makefile comes with a PROG flag.

  make all PROG=foo

1. Go to the top-level testbench directory from the project git repo, wiscv/tb.
2. At the prompt, run make all 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 DUT.Trace in the wiscv/tb/(program name)_sim directory where program name is whatever name specified by the PROG flag (or whatever directory specified by the RUN_DIR flag on the makefile).
   • Remember that you need to specify what version of your project you are running to the makefile by setting the MODE flag to either nopipe or pipe
3. It will also run the program on our reference simulator. A "trace" of changes to the architecture state for each instruction's execution is written to a file called REF.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.
   • You can generate a waveform file by setting the WAVES flag of the makefile to '1' (make all WAVES=1 ...)
   • The waveform file generated (named vsim.wlf) will be located in the generated directory. In order to open it, run vsim vsim.wlf&
     • The vsim command should be available to you by adding /u/k/a/karu/public/html/courses/cs552/fall2020/handouts/bins to your path

3.  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 the makefile with the pipe option for the MODE flag while using this testbench.
2. At the end of a simulation, you will see DUT.pTrace and REF.pTrace files generated.
3. 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:

  make all PROG=foo MODE=pipe

Raw ptrace files are DUT.pTrace and REF.pTrace.