Questasim Commands For Uvm

7 views

Skip to first unread message

Juan Navarro

unread,

Jul 27, 2024, 1:10:59 AM7/27/24

to nyamunlaki

I regard the graphical user interface (GUI) as a front-end for the commands listed in this article. For example, when you click the Compile button in the ModelSim GUI, it runs the vcom command back-end. The screenshot below shows the command echoed to the transcript window after we click the Compile button.

questasim commands for uvm

Download Zip >> https://urluss.com/2zQxvZ

The vcom command has lots and lots of optional arguments that allow you to control the compilation rules in detail. Check out the ModelSim Reference Manual for a comprehensive list of all the options.

Using the vmap tool, you can view and edit the mapping between the VHDL library name and the path to the compiled VHDL code in your file system (the folder you created with vlib and compiled into using vcom).

That will print a list of library mappings from which you may recognize some names from. For example, ieee and std. The standard libs are probably located in your ModelSim installation directory as they came with the simulator.

This article shows how to work with strings containing line breaks in VHDL. Read on to learn how to split long lines in your VHDL code, print text containing newline characters, and how VHDL differs from regular programming languages regarding non-printing control characters in strings.

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.

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.

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.

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.

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.

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

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:

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:

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:

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

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).

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

I want to use VCD file from QuestaSim 6.0 in RTL compiler to obtain power report. The netlist file I am using in QuestaSim for simulation and VCD file generation is also generated by RTL compiler byt when I run following commands I got no asserted signals in the power result. Does RTL compiler supports other VCD files besides from NCVHDL?

VCD is VCD and it does not matter what tool generates it as long as VCD it is legal. You will have to do some additional debug and figure why it is not annotating. Most common reason is testbench generating VCD scoped at the testbench level which the design obviously does not have. Other reasons are naming conventions on elaborated flops, etc.

Yes I have checked the contents of VCD file and it only contains signals from the component I am testing. However when I convert this VCD file into saif format using vcd2saif tool from Synopsys it reads correctly in RTL compiler.

However, that should not be necessary. I suspect you need to use the -vcd_scope (or -vcd_module in older releases) option to read_vcd in order to select the "scope" in the VCD that you want to apply to the top design in RC.

As mentioned, we force signals using the interactive mode of those EDA tool, so whenever we in the command line interface (aka cli) we can call the force commands to force signals. Usually, I create a file containing forcing commands, then source this file during simulation like below.

Command Description alias creates a new Tcl procedure that evaluates the specified commands; used to create a user-defined alias find locates incrTcl classes and objects lecho takes one or more Tcl lists as arguments and pretty-prints them to the Main window lshift takes a Tcl list as argument and shifts it in-place one place to the left, eliminating the 0th element lsublist returns a sublist of the specified Tcl list that matches the specified Tcl glob pattern printenv echoes to the Main window the current names and values of all environment variables

Okay during my trials this is what i came across:-
1. when modelsim is onvoked with "vsim.exe" it is simple to open a
command pipeline to the modelsim interpreter and issue commands as and
when required whithout any gui required.
2. if vsim -gui is issued then the gui opens but no command pipeline
can be established. Is there a specific person for this? I assume that
since a command line is made available it may create conflicts if a
command pipeline is feeding this intepreter prompt simulatenously
alongwith a user.One way to work aroung the GUI problem would be to open a socket
connection with your external Tcl script and Modelsim. But i somehow
find this way of doing IPC rather blunt.Does anyone have a better way
of doing an IPC into modelsim from another script/application.regards,
nachiket.

In the compilation phase all syntactical bugs/typos will be pointed out. After you have succesfully managed to compile the design, actual simulation/debugging of semantical mistakes (= design errors) may begin. (In fact ModelSim may point out some possible design pitfalls already in compilation phase.) You can manage your VHDL libraries with following shell commands. Study them carefully: vlib Create a new libraryvmap Map physical and logical libraryvdir List currently compiled design unitsvdel Delete a design unitvmake Automatically generate MakefileCompilation and simulation commands: vcom Compile VHDL source codevsim Simulate compiled design 4. Exercises and demosIn the following example we will design simple traffic lights control circuit with behavioral vhdl. We will compile and simulate vhdl with ModelSim and study how to create and manage VHDL libraries in practice. Then we will improve the functionality of our traffic lights editing the source code and verifying our changes with second simulation. First we need a VHDL library where we can compile our source code.

Create two libraries (codelib and traffic_lib) % vlib codelib % vlib traffic_lib As you can see vlib created two directories (codeliband traffic_lib) and one file into each of the directories (_index or _info). That file contains information about compiled VHDL sources and the state of the library (of cource at this moment both of these files are empty). You should never edit these files yourself 'by hand'. Let the ModelSim itself handle its own bookcounting. In order to change the state of the library use only appropriate library commands. Now we must tell ModelSim where our newly created libraries are located in physical media (= path on the disk we are using).

Map the physical and logical library % vmap codelib $PWD/codelib % vmap traffic_lib $PWD/traffic_lib $PWD here represents full path to the physical library. vmap writes an initialization file called modelsim.ini into your working directory which contains information about your working environment (like which libraries you are using etc.). Hint: If you use only vmap without parameters you will get a list of currently mapped libraries, which ModelSim.ini you are currently using and physical location of every library.

package.vhdl
behavioral.vhdl
top_level_entity.vhdl

Compile the source code:

Compile the vhdl package into the traffic_lib: % vcom package.vhdl -work traffic_lib -source The following command-line options can be used with vcom: