






Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
A beginner's introduction to using the modelsim simulator for simulating verilog hdl codes in the context of the cpre 305 lab sessions at iowa state university. It covers getting started with modelsim, coding in modelsim, and simulation in modelsim, with a focus on handling compilation errors and using testbenches.
Typology: Lab Reports
1 / 12
This page cannot be seen from the preview
Don't miss anything!







Getting Started
This section of the guide will first explain the basic rules you will need to follow for your CprE 305 lab sessions. All the relevant Verilog and project files will be stored on the local drive of your lab machine in the following directory structure:
C:\CprE305[Your Net-ID]\Lab[Session Number]
This will enable easy retrieval of the relevant files of any lab session. For example, if your Net-ID were to be ‘smith’, all the files related to your third lab session should be stored under:
C:\CprE305\smith\Lab03.
We shall now proceed to the explanation of the basic features of the ModelSim 5.8b simulator. Every simulation that you perform will be a part of a project. You can create a project at the start of every lab session. As soon as you fire up ModelSim from the desktop, you will be presented with a slight variant of a screen like the one below.
At the start of each session, click on File > New > Project. If there is a prompt to continue by closing the current project, click on ‘Yes’. You will now be presented with
a child window requesting the details of the project to be created. Fig. 02 shows a sample data set which can be used to create the new project. On creating a new project, you will be asked to optionally add items to the project. At this juncture, you can opt to create a new file (which will be automatically added to the project) [Fig. 03]. Make sure that the new file which you are creating has a ‘.v’ extension, and that it is added as a Verilog type file [Fig. 04]. This file is placed by default in the same directory as the project ‘.mpf’ file.
We shall now revert back to Fig. 01, which is how the screen should look after the above steps. The screen shot in Fig 01 has two main parts, the ‘Workspace’ and the command prompt window. When no simulation is running, the workspace has two tabs (at the bottom of the ‘Workspace’ segment’), ‘Project’ and ‘Library’. The ‘Project’ tab shows the list of files which are members of the current project. Every HDL file needs to be compiled before simulation. The post compilation results are stored in the ‘work’ directory by default. The modules available after compilation can be viewed by clicking on the ‘Library’ tab. Commands can also be typed in at the ‘ModelSim>’ command prompt. All operations which can be performed through the GUI can also be done on the command prompt. This helps in bunching a set of tasks together in the form of a script for automation of the creation and compilation of huge projects. However, these are advanced features and we shall be requiring minimal use of them in the course of our lab sessions.
In the next section, we will be looking at the editing of HDL files inside ModelSim and methods to compile these files and load them for simulation.
message is displayed in the command prompt segment of the main window. A double click on this message opens an ‘Unsuccessful Compile’ child window which tries to give more helpful information as to what caused the compilation error.
After taking due note of the compilation errors, the child window may be closed and the errors may be taken care of in the editor. The compilation procedure may be repeated as necessary. In case you have a huge piece of code, and you find it a bit tedious to scroll down to the line containing the error, you can also double click the error message in the child window. This automatically highlights the line which caused the compilation error. We shall now proceed with the assumption that you have a successfully compiling code.
Fig. 07 shows the main window (with the ‘Library’ tab of the workspace being active) after a successful compile. The library shows the list of already compiled modules which can be loaded for simulation or referenced by another loaded simulation. The modules under the ‘work’ heading represent the list of Verilog modules which have been successfully compiled. A double click on a particular module loads it for simulation. Alternatively, you can also enter the command ‘vsim work.[Module Name]’ at the ‘ModelSim>’ prompt to load that particular module. If the module which you are attempting to load has a reference to other modules, they will be loaded too. For advanced options while loading modules (which you will not be requiring in the lab sessions), you can opt to go through the ‘Simulate > Simulate..’ menu too. To end a simulation, you can either type in ‘quit –sim’ at the command prompt or go through the ‘Simulate > End Simulation’ option in the menu.
Once a module is loaded for simulation, there are two major changes in the main window. The workspace acquires two more tabs in the lower left corner, namely ‘sim’ which contains the list of all the modules being simulated and ‘Files’ which contains the list of the files which contain the codes for the modules in the ‘sim’ tab. The second major change is the alteration of the ‘ModelSim>’ command prompt to the simulation command prompt ‘VSIM01>’. The new command prompt is used for entering simulation commands.
In the next section, we will look at how simulation can be performed on a loaded design unit.
The ‘signals’ window contains a list of all the signals in the loaded module. Initially, all the input signals are in the high impedance state (HiZ) while the output signals are in the unknown state (StX). The ‘wave’ window is empty. In order to set the initial stimuli, the signals are selected one by one and the ‘Edit’ menu on the signals window is utilized. There are two possible options available at this juncture. A simple ‘Force’ option in the ‘Edit’ menu can be used to deposit a particular value on the signal, while the ‘Clock’ option can be used to deposit a clock waveform. A lot of potentially confusing options are presented while setting the stimuli. It is better that the default options are accepted. Only the logic value needs to be set in the ‘Force’ option and the clock period in the ‘Clock’ option, as in Fig. 09 and Fig. 10. If you are able to alter the other options to adapt to the stimulus you want to create, it is an added bonus!
The next task is to view these signals in the waveform window. In the ‘signals’ window, follow the ‘Add > Wave’ menu to click on the ‘Signals In Design’ option. At this point, you can run the simulation by either typing ‘run’ at the VSIM command
prompt, or by clicking on the relevant ‘Run’ icon (which can be found in both the ‘wave’ as well as the ‘edit’ window). Alternatively, you can also use the ‘Simulate > Run’ menu on the main window and click on ‘Run 100ns’ option to make the waveform progress over the time line. Fig. 11 shows a waveform in the middle of a simulation run.
As you must have realized by now, using this method to apply stimuli for simulation purposes will be tedious and error prone, even for moderately sized modules. This necessitates a better approach to simulation, which is the usage of testbench modules.
This guide will go slightly off-track now in order to explain in brief about the creation of testbenches. We shall still keep the NAND3 module under consideration. In order to exhaustively verify that the NAND3 module works correctly, we need to supply it with all the possible combination of three inputs, which makes for a total of eight different input sets. Imagine trying to do this with the earlier stimuli application methodology! Fortunately, the testbench concept of HDLs makes our task simple. We code a behavioral module, which imitates a simulator applying the inputs in sequence. We can take advantage of all the C-like features of Verilog in this module. Another advantage of the testbench approach is that text output can be obtained in addition to the waveforms. This is invaluable in large designs where handling waveforms could turn out to be cumbersome.
The testbench module has neither inputs nor outputs. It contains register declarations for all the inputs to be applied, and a wire declaration for each output to observe. For example, the NAND3 testbench has three registers and one wired signal. It makes the job simpler to have the names of these signals the same as the one in the module to be tested. In addition to these signals, we also have an integer counter variable which can be looped in order to apply the desired inputs in sequence. This loop can be coded using the ‘for’ statement with a desired delay between the execution of two consecutive loop instances. Another block inside the same module can monitor the values of all the signals in the design. A provision can also be made to stop the simulation after all the input combinations have been applied. Most importantly, in any testbench, it should not be forgotten to instantiate the unit under test with proper mapping of ports. In this case, the unit under test is an instantiation of the NAND3 module.
The testbench module can be coded in a separate Verilog file, or within the same file as the module to be tested. In any case, it must be ensured that all the modules are compiled and available for simulation in the work library. When starting the simulation, make sure that the testbench module is selected, and not the base module. In case you want to view the waveforms too, follow the directions given earlier to add signals to the waveform window (Open the ‘signals’ and ‘wave’ window through the ‘View’ menu, and follow ‘Add > Wave’ menu in the ‘signals’ window and click on ‘Signals in Design’). A ‘run –all’ at the VSIM command prompt or a run through the ‘Simulate’ menu in the main window should complete the testing.
Refer to Fig. 12 for the testbench listing and the waveform and text output of the testbench. The text output can be seen at the bottom right corner of the figure, with the waveform just above it. Pay careful attention to how the testbench has been coded. There are a multitude of resources available for you to learn to code efficient and effective testbenches.