Questa SystemVerilog Tutorial

Tool Introduction

QuestaSim is part of the Questa Advanced Functional Verification Platform and is the latest tool in Mentor Graphics tool suite for Functional Verification. The tool provides simulation support for latest standards of SystemC, SystemVerilog, Verilog 2001 standard and VHDL. This tool is an advancement over Modelsim in its support for advanced Verification features like coverage databases, coverage driven verification, working with assertions, SystemVerilog constrained-random functionality.

The aim of this tutorial is to understand the basics of working with SystemVerilog in the Questa tool environment. This is going to be done using the example of a modified DLX execution block with a 2-stage pipeline.

Establishing the Design Environment for compilation

  • One time setup for a given directory used for simulation:

Each time you create a directory for simulations you would have to do the following

prompt%> add questasim63 OR prompt%> add modelsim
    • Copy the modelsim.ini file that comes with this tutorial into the directory. This file sets up the necessary defaults for the Questa tool.
    • Create the library into which all the design units will be compiled. Do this by performing
prompt%> vlib mti_lib

(Note that the name “mti_lib” corresponds to the variable “work” within the modelsim.ini file and is the library to which all the source code would be compiled to create a design single entity). Note that in some cases, if the compilation seems to crash for a reason you think is incorrect, it would be advisable to delete the “mti_lib” directory (Use: \rm –rf mti_lib OR vdel –all) and re-create it as shown above.

  • Setup for simulations within a directory for a given session:

We assume the previous step has already been followed. Let us assume a directory has been setup up correctly and you come into this directory for a future simulation. You would still need to run the following commands each time you start a set of simulations for a given design within a directory.

    • set paths to the Modelsim tool:
prompt%> add questasim63 OR prompt%> add modelsim
    • set environment variable MODELSIM to modelsim.ini
prompt%> setenv MODELSIM modelsim.ini

At this point, all the path settings are good to go for the executables associated with Questa. It is assumed here that user is aware of the requirements for remote access from a Windows platform. If not, the information can be obtained from the remote access page.

Compilation and Simulation

The Questa tool enables compilation of multiple design/verification/modeling units (each of which might be in a different language) into a common library (called the working library) and a common design representation. This enables each individual unit of the entire simulation to be compiled independantly and incremental compilation to be performed. At this point it must be stated that the compilation of the source code can either be done within the simulation environment (GUI) or on the command prompt. The simulation though MUST be performed within the simulation environment. In the interest of simplicity, we shall be performing the compilation of the source code on the command prompt of the UNIX/Linux terminal and providing a basic understanding of the tool capabilities. The other options and some helpful information will be touched upon in the Asides section.

All the work should be done within the same folder say <PATH TO FOLDER>/Simulation/

To begin the compilation and simulation process, please download the following into a directory of your choice (<PATH TO FOLDER>/Simulation/)

This corresponds to a watered down version of the DLX Execute Engine. In this case, we are only going to be looking at the arithmetic, shifting and memory based operations for the Execute Unit. A quick design specification for the Execute unit can be found at Design Spec : pdf doc.

  • The SystemVerilog (SV) Testbench for this RTL:
    • Execute.if.sv the creation and use an interface to the DUT with a clocking block and a modport.
    • Execute.tb.sv the creation of a program which provides constrained stimulus to the DUT. This code has been written to provide the user a very basic introduction to a typical program structure with tasks and passing of signals into the DUT.
    • Execute.test_top.sv the creation of a top level integration of the DUT, the interface and the program for sending stimulus to the design.

For this tutorial the testbench is only going to be used for the creation of constrained stimulus and for sending these stimuli into the DUT. The code provides an example for a standardized testing environment with

At this point we can either do step3 in the GUI environment or at the command prompt. We shall continue with the command prompt.

The next steps need to be performed each time a code change is performed and the changes need to be reflected in the simulations.

Step1: Compilation of source code

  • Compile the Verilog RTL Model: A good feature is that Verilog(protected an unprotected) source files can be compiled out of order. Thus, we begin by compiling the protected verilog files by doing:
 prompt%> vlog *.vp

Which results in the message:

-- Compiling module ALU
-- Compiling module Arith_ALU
-- Compiling module Ex_Preproc
-- Compiling module Shift_ALU

Top level modules:
        ALU
        Ex_Preproc

Which implies that the high level modules in the hierarchy that were discovered are ALU and Ex_Preproc. We also need to compile the unprotected files which is done by performing the following on the command prompt:

 prompt%> vlog *.v

This results in the following message:

-- Compiling module Top

Top level modules:
        Top

Which is on expected lines.

  • Compile the SystemVerilog Testbench: The SV code shares the same ability to be compiled in any order. This holds as long as the includes from one file do not beat on those in another file. It is always suggested to follow an ordered compilation. Thus, SystemVerilog compilation can be done by running the commands
 prompt%> vlog -sv -mfcu Execute.if.sv Execute.tb.sv Execute.test_top.sv

A successful compilation of the systemverilog files should spit out the following message:

QuestaSim-64 vlog 6.3c Compiler 2007.09 Sep 11 2007
-- Compiling interface Execute_io
-- Compiling program Execute_test
-- Compiling module Execute_test_top

Top level modules:
        Execute_test_top

The most important thing to note in this example is that the topmost design unit is Execute_test_top which has an instance of the “testbench Execute_test” connected to the DUT “Top” through the interface “Execute_io”.

Step2: Simulation of design

We can now simulate the design unit (testbench + DUT) by invoking the simulator (vsim) with the top level design unit (Execute_test_top).

 % vsim -novopt Execute_test_top

This leads to the invocation of the simulation GUI with three windows: Workspace, Objects and transcript. To begin with, note that the prompt is of the form VSIM #>, where # corresponds to the number of commands issued in the simulation mode. Also, at this point the Workspace window would have tabs corresponding the simulation hierarchy (sim), the source files (Files) and the analysis tool for the register arrays in the system if any (Memories). The objects window contains variables, wires, regs, variables etc their values and their characteristics. An example of the window at this point is shown below:

SimStart.PNG
In the figure below, the hierarchy corresponding to the DUT has been expanded and its contents populate the objects window by virtue of clicking on the name DUT on the workspace window.

SimWindow1.PNG

At this point we need to have a means of viewing the values that are of interest to us. To add the signals of interest to the waveform viewer, we would need to select these from the Objects window -> right click -> add to wave -> select signals. This can also be done for a given instance in the Workspace window but this might need to an excessive number of values which might be overkill. An example set of signals in the Object window have been highlighted and sent to the the waveform window below:

AddWave1.PNG

The execution of the above leads to the appearance of the waveform window. To begin with, this window could be a part of (docked with) the GUI but can be separated (undocked) from the GUI frame by hitting the Undock.PNG button. This creates a new window with the signals and variables of choice populating the frame to the left. There is going to be a need to adjust the frames to make the the names and signal values appear in a manner favorable to you. We leave it up to you to play around with the waveform window. If the design is not too big, then you can run the command below to log all signals at all levels of hierarchy. If the command below was not executed prior to a simulation run, only those signals specified in the waveform window would be logged and hence any new signal of interest would require restarting of the simulation:

 VSIM#> log -r /*

To run the simulation we need to run the command (for a 200ns advancement of simulation time OR a full run)

 VSIM#> run 200ns (or any other time that you would like) OR  VSIM#> run -all (for a full run of the simulation)

It must be noted that the testbench must have the ability to finish (using $finish, exit) at some point during the simulation to do a “run -all”. Else, the simulation would run iterate forever.

On issuing the above command, the contents of the waveform window could be zoomed in. To zoom use the standard zoom buttons (maginifying glass). A useful shortcut is to use hit “f” to zoom full (the 200ns that the simulation has been run). The waveform window that you see should mirror what you see below for the case where we have add reset, src1, src2, opselect, operation etc. from the object window to the waveform. The figure also shows you one other useful feature where you can change the radix of the numerical representation to one that you are comfortable with.

WaveformWindow1.PNG

To end a simulation run

 VSIM#> exit

Also, if changes were made to the code while the GUI was up, you can recompile (on the UNIX command prompt if you so wish) and then re-start the simulation by running (assuming we want to recompile ALL the files).

 VSIM#> vlog *.sv -sv -mfcu
 VSIM#> vlog *.vp 
 VSIM#> vlog *.v 
 VSIM#> restart -f

We could have recompiled just the files that were modified.

Asides

  • The running of the simulation can be done in a folder different from the HDL and the testbench folders. This just calls for the running of the vlog command with the path to the HDL and the SystemVerilog files. This can be done by using the following command within the simulation folder (where “vlib ..” and “setenv MODELSIM ..” have been done)
 VSIM #> vlog <PATH_TO_HDL>/*.v
 VSIM #> vlog -sv -mfcu -novopt <PATH_TO_TESTBENCH>/*.sv
  • Working on the command prompt: It is useful to note that, if the GUI is to be avoided (debug using only text commands/generation of files/checking for compilation correctness.), the simulation can be invoked in the non-GUI mode by doing a vsim –c. This causes a QuestaSim(OR Modelsim) prompt to appear where you compile (vlog), invoke the simulation (vsim) and run the entire simulation (run). This is sometimes a good alternative when X-windows proves troublesome or you do not have a connection strong enough to support a GUI based operation.
  • Using .do files: An extremely useful feature in QuestaSim(OR Modelsim)is the presence of do files. These are the equivalent of shell scripts for Modelsim. All the necessary compilation commands, simulation commands, waveforms etc can be stored within a .do file. This allows you to avoid typing in all the commands manually. Instead, you can call this file within the vsim environment ( GUI / no GUI) by doing a
 VSIM #> do <filename>.do.

Of particular importance in working with do files is working with waveforms. Once you have set up all the relevant waves on the waveform window, it is feasible in QuestaSim(OR Modelsim)to store the format of these waves in a .do file and restore the same set of waves the next time you come back to the simulator. This is done by saving all the waveforms by doing a

 File->Save

and saving the format as a .do file. The next time you invoke the simulator, MAKE SURE THAT THE DESIGN HAS BEEN LOADED using a vsim <modulename> for eg, vsim –novopt Execute_test_top, after which you can open the waveform window and do a

 File -> Load -> <filename>.do

to get the same set of waveforms as before.

Mentor Support

Help regarding Mentor tools can be obtained from

/afs/bp.ncsu.edu/dist/questasim62/docs/pdfdocs

Useful References

more to come …