Modelsim SE is a simulation (and verification) environment from Mentor. The tool provides simulation support for latest standards of SystemC, SystemVerilog, Verilog 2001 standard and VHDL. It also supports mixed-signal simulation and linking to tools like Matlab.
Invoking Modelsim at NCSU
This tutorial borrows heavily from the the Questa Tutorial and is an improvement over Modelsim Tutorial created by Ambarish Sule. To invoke the tool at NCSU, remotely or on a Solaris/Linux platform, type
At this point, all the path settings are good to go for the executables associated with Modelsim. 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
All the work should be done within the same folder say <PATH TO FOLDER>/Simulation/
The Modelsim Simulator 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). This is done by virtue of the compilation of individual units into a common design representation. This enables each individual unit of the entire simulation to be compiled independantly and incremental compilation to be performed. To see how this works, please download the following into a directory (<PATH TO FOLDER>/Simulation/) of your choice in the UNIX design environment.
- The Verilog RTL for the Design Under Test (DUT):
- Execute.v: The top level of the DUT.
- Shifter_ALU.v: A design instance in the DUT.
- Arith_ALU.v: Second design instance within the DUT.
- data_defs.v: Header that defines parameters for the module under consideration. This enables an easier management of design variables.
- Test_Execute.v: Testbench for testing DUT.
The DUT 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.
Within the same folder (for case of simplicity) do all the following.
Step1: Library Creation
We must first establish the library directory (work variable corresponding to line "work = ./mti_lib" in the modelsim.ini file) that will be used to store the different compilation units. To create a library directory we need to issue the command:
% vlib <NAME OF WORK DIRECTORY> (for this tutorial we use the library mti_lib)
It must be noted that the above command needs to be issued just once i.e. to create the library. Once the library as been created you can just compile and simulate using this library. In addition to this, the compilation process needs to be explicitly provided the name of the above directory for successful compilation. This can be done in one of two ways
- Download the modelsim.ini file into the simulation directory. This allows for the specification of the "work" variable to be anything you please (in this case, it is mti_lib as seen in the modelsim.ini file). This is a preferred method unless multiple designs and versions are worked on. The remainder of this tutorial assumes this method is used.
- Include "-work mti_lib" whenever a compilation is done.
Step2: Setting "work" environment variable
To get the "work" variable to within the modelsim.ini to get reflected in the simulation environment, we need to run the following command. This needs to be done once after doing an "add modelsim" in the given directory.
% setenv MODELSIM modelsim.ini
Therefore, assuming you have done a "add modelsim;" and "vlib mti_lib" sometime before to set up the library, your command prompt would look something like the one below in readiness for a simulation.
In the above you will also notice additional commands (which and echo). These are just sanity checks to make sure that the vsim and $MODELSIM are pointing to the right values.
It must be noted that all the commands listed below (and the ones above too actually) can be issued either on the command prompt of the UNIX shell or could be issued at the prompt of the GUI that can be invoked by issuing the following command:
% vsim &
The GUI that pops up would be of the form shown below (Note the presence of the Transcript and the Workspace Windows). A good working method would be to perform all the inital setup in UNIX prompt while the compilation and simulation (waveform viewing) would be in the GUI.
The next two steps need to be performed each time a code change is performed and the changes need to be reflected in the simulations.
We now need to compile the verilog DUT and the testbench for it. A good feature in the tool is that verilog files can be compiled out of order. Thus, verilog compilation can be done by
% vlog *.v OR % vlog *.v -work mti_lib (if modelsim.ini is not configured)
At this point the designs are all loaded into the library. If you have not already done so, you can invoke the GUI as specified earlier. In the GUI, a glance at the Library tab under the Workspace frame shows a list of libraries that have been loaded. One of them would be the mti_lib. If the mti_lib tab is expanded, you will see the stored compilation units (Arith_ALU, Execute etc) and their type (module in this case).
We can now simulate the testbench and the DUT by running the command below. It is to be noted that the compilation of the verilog code provides the topmost module in the compilation hierarchy (here Test_Execute).
% vsim Test_Execute OR % vsim mti_lib.Test_Execute (if modelsim.ini is not configured)
To begin with, note that the prompt has now changed to the VSIM #> format, where # corresponds to the number of commands issued in the simulation mode. Also, at this point the Workspace window would have 3 new tabs corresponding the simulation hierarchy (sim), the source files (Files) and the analysis tool for the register arrays in the system if any (Memories). Also, a new window corresponding to the objects (variables, wires, regs, variables etc) their values and their characteristics appears. In the example 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.
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.
The execution of the above leads to the appearance of the waveform window. To begin with, this window would be a part of (docked with) the GUI but can be separated (undocked) from the GUI frame by hitting the button. This creates a new window with the signals and variables of choice populating the frame to the left.
If the design is not too big, then you can run the command below to log all signals at all values of hierarchy.
% log -r /*
If this is not done, only those signals specified in the waveform window would be logged. Any new signal of interest that needs to be logged would require restarting of the simulation.
To run the simulation kernel and generate waveforms we need to run the command
% run 100ns (or any other time that you would like) OR % run -all (for getting the simulation to run through till it is done)
The second command must only be run if there is a "$finish" that would eventually be invoked.
To begin with, the contents of the waveform window are zoomed out. To zoom use the standard zoom buttons (maginifying glass) at the top of the waveform window. A useful shortcut is to use hit "f" to zoom full. The waveform window that you see should mirror what you see below. 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.
To end a simulation hit
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 the following command on the GUI command window:
% restart -f
- The running of the simulation can be done in a folder different from the HDL folder. This just calls for the running of the vlog command with the path to the HDL. This can be done by using the following command within the simulation folder (where "vlib .." and "setenv MODELSIM .." have been done)
% vlog <PATH_TO_HDL>/*.v
PLEASE NOTE THAT THIS TUTORIAL IS AN ADDITION THAT WOULD BE HELPFUL FOR PEOPLE WHO ARE INTERESTED IN EVALUATING THE POWER CONSUMPTION OF THEIR ARCHITECTURE.
The evaluation of the power consumption in a design involves the determination of the switching activity associated with the nets in the design. This is achievable by the use of the Synopsys' Power PLI in conjunction with the Modelsim simulation environment. To this end, we need to perform a simulation of the post-synthesis netlist with a set of test vectors that characterize the typical data that goes into the DUT (given that switching activity is strongly data dependent). The following instructions are already presented in section 2 of a prototyping flow at Tutorial2:Design Analysis. It is being reproduced here to cater to users just interested in the power evaluation of a placed and routed design.
At this point we assume you have the a placed and routed netlist (this is generally spit out by the Encounter tool when you save your design) and SPEF (Standard Parasitic Exchange Format) file for the design. If these are not present, you will have to do the following within Encounter after routing your design:
encounter%> saveNetlist -excludeLeafCell design_routed.v. encounter%> setExtractRCMode -detail -assumeMetFill encounter%> extractRC encounter%> rcOut -spef design.spef
At this point, it is important to mention that we have the above commands creating design_routed.v and design.spef. These assumptions are being used for the rest of the tutorial. Please be sure to change these to your convenience and modify the commands below to reflect these changes.
- SETTING UP THE MODELSIM TOOL FOR POWER SIMULATION
To begin, the modelsim.ini and the “Forward SAIF file” (Library_fwd.saif) should be copied to the directory that you are doing your power evaulations in. Next we need to create a "Backward SAIF File" which contains all the switching activity numbers. To do so, we need to run a simulation using a testbench that encompasses what you consider good benchmark and the netlist in question. The simulation is going to be performed using Modelsim which you should already be familiar with by virtue of your experience in Tutorial 1. To setup the directory for simulation type the following commands at the command prompt (recollect from Tutorial 1): The below commands needs to be RUN JUST ONCE to set up the work library in a given directory
prompt%> vlib mti_lib
The below 2 commands need to be RUN ONCE FOR a set of simulations (Need not be done if done before in a login session)
prompt%> add modelsim prompt%> setenv MODELSIM modelsim.ini prompt%> add synopsys
Now follow the listed steps:
- The testbench now needs to be modified by adding commands that will enable us to collect switching activity statistics. An example testbench can be downloaded from test_switching.v. In this testbench, within the initial block, the following commands are of importance:
- $read_lib_saif("./Library_fwd.saif");This command reads the forward saif file corresponding to the Device Under Test (DUT).
- $set_toggle_region(test_fixture.DUT); This command tells the simulator that the statistics are going to be generated for the instance DUT under test_fixture (which is the instance of the test module)
- $toggle_start(); This command tells the simulator to begin collecting toggling (switching) statistics.
- $toggle_stop(); Logically, tells the simulator to stop collecting toggling statistics.
- $toggle_report("./counter_back.saif", 1.0e-9,"test_fixture.DUT"); This command forces the creation of the backward saif file while providing the timescale and the instance for which the statistics were collected.
Please be sure to modify the test_fixture.DUT to the correct testbench module name and design under test instance name. Also, if needed change the name of the backward saif file (counter_back.saif) to a name of your choice.
- To compile the design use the following commands :
prompt%> vlog <path_to_file>/design_routed.v prompt%> vlog /afs/bp.ncsu.edu/dist/cadence_cdk/OSU018_StdCells/Typical/osu018_stdcells.v prompt%> vlog ./test_switching.v (assuming the testbench is named test_switching.v)
At this point, if there are some errors, they are likely to be due to the incorrect DUT instance name or incorrect usage of the about $toggle commands.
- Assume now that the testbench name is test_fixture. To invoke the simulator in a command prompt mode and to enable the Simulator to understand the SAIF based commands previously listed type in ONE OF the following commands based on the type of operating system that is under use:
prompt%> vsim –novopt -c -pli /afs/bp.ncsu.edu/dist/synopsys_syn/sparcOS5/power/vpower/libvpower.so test_fixture prompt%> vsim –novopt -c -pli /afs/bp.ncsu.edu/dist/synopsys_syn/sparc64/power/vpower/libvpower.so test_fixture prompt%> vsim –novopt -c -pli /afs/bp.ncsu.edu/dist/synopsys_syn/amd64/power/vpower/libvpower.so test_fixture prompt%> vsim –novopt -c -pli /afs/bp.ncsu.edu/dist/synopsys_syn/linux/power/vpower/libvpower.so test_fixture
Please be sure to modify test_fixture to the correct testbench module name if it is different. The result of this command is the loading of the design of interest and the prompt now becomes VSIM #>
- At this prompt (VSIM #>)type the following commands to run the simulation:
VSIM#> run -all; VSIM#> exit; (this might be un-necessary is $finish is reached)
The result of importance here is the counter_back.saif (or one that you have specified in the $toggle_report() command) file which corresponds to the Backward SAIF file for the present design. This is the file that is going to be used to create the power reports in the next step.
- RUNNING POWER COMPUTATIONS IN DESIGN COMPILER
We shall be running the power computation in the design compiler environment. It is suggested that this analysis be done in a different directory than the synthesis directory. To begin download the power_dcshell.tcl into the directory to be used for power computations. Before we run this file, it is important to note the control variables at the top of this file:
set NETLIST_FILE ../Synthesis/design_routed.v set MODNAME design set CLKNAME clock set CLKPERIOD 10 set SPEF_FILE ../PlaceRoute/design.spef set BACKSAIF_FILE ./counter_back.saif set INSTNAME test_fixture/DUT
The above variables need to be modified based on the directory structure that you presently have, the files you are working with and the design names that you have created. The NETLIST_FILE variable is a full path (w.r.t the power analysis directory) to the placed and routed netlist, MODNAME is the module name (NOT instance name) of your design under test, SPEF_FILE is the full path(w.r.t the power analysis directory) of the SPEF file created by Encounter, BACKSAIF is the full path to the backward saif file created in the previous step by Modelsim. Of particular importance is the INSTNAME which is the path to the design instance in the testbench (here test_fixture/DUT) as seen in the testbench file. Be sure to have the "/" and DO NOT end this path with a "/". Once the necessary modifications have been made in the file, you can either run the entire file within design compiler (OR design vision OR design_analyzer) by doing the following after the tool has been invoked(say design_vision):
design_vision-xg-t> source power_dcshell.tcl
This should result in the creation of the following reports:
- total_power_pre_annotation.rpt: Total power without SPEF
- timing_pre_annotation.rpt: Worst case timing without SPEF
- total_power_post_annotation.rpt, clock_power_post_annotation.rpt: Design and clock power with SAIF and SPEF considered
- timing_post_annotation.rpt: timing report with SPEF
Be sure to check for an increase in critical path delay and power with the addition of SPEF.