![]() |
![]() |
![]() |
![]() 11 |
|||
|
||||||
Before Covered can be invoked, you must have a simulatable Verilog design and a VCD or LXT dumpfile containing information from a simulation run of the design that dumps the module(s) that you want to check for coverage. The VCD dumpfile style was chosen due to its universal support by Verilog simulators while the LXT dumpfile style was chosen due to its compactness and growing support by other open source simulators and dumpfile readers. Once you have these two parts, you are ready to begin generating coverage results. |
||||||
In Verilog, the way that you create the VCD dumpfile is by using two types of Verilog system calls (1) $dumpfile and (2) $dumpvars. The following example shows how to create and generate a dumpfile called "test.vcd" that will dump the submodule called "foo". |
||||||
Example |
module test; |
|||||
$dumpfile |
The $dumpfile system call takes in one parameter that is a string of the name of the dumpfile to create, in this case the dumpfile we want to create is called "test.foo". The purpose of this function to create the file (open it for writing) and outputs some initialization information to the file. |
|||||
$dumpvars |
The $dumpvars system call takes in two parameters. The first is the number of levels of hierarchy that you want to dump. In the example, we want to only dump the module instance called "foo" which is why the dump level was set to 1. To dump foo and the level of submodules just beneath it, you would set the dump level to 2 and so on. To dump a module and all submodules beneath it, set the dump level value to 0 (this means the level specified and all levels below it). The second parameter is a Verilog hierarchical reference to the top-level module instance that you want to dump. |
|||||
The $dumpfile system call may only be called once within a Verilog design. Typically, it is called in the top-most level of the design (or testbench as it is commonly referred to as); however, the language allows you to call it from anywhere in your design as long as it precedes any calls to $dumpvars. |
||||||
The $dumpvars system call may be called as many times as necessary to dump the Verilog that you need. For example, if you want to get coverage results for several modules scattered around the design, you may make several $dumpvars calls to dump exactly those modules that you want to see coverage for. |
||||||
For the most part, that is about all there is to creating VCD dumpfiles for the design. All you need to do is run a simulation with these system calls in it and a dumpfile will be generated for that run. Once you have this file, you are ready to see if your design is Covered! |
||||||
An LXT dumpfile can be created in several different ways depending on the Verilog simulation tool that you are using. If you are using the Icarus Verilog open source simulator, you can simply generate an LXT-style dumpfile by specifying the -lxt2 option to the simulator command-line. For example, if you had a file called "foo.v" that contained the same $dumpfile and $dumpvars commands used for VCD dumping and compiled it with Icarus Verilog into a VVP file called "a.out", you could cause Icarus Verilog to generate an LXT dumpfile (instead of a VCD dumpfile by calling "vvp a.out -lxt2". This will cause an LXT style dumpfile instead of the standard VCD style dumpfile. |
||||||
You can also transform many different dumpfile formats into an LXT style dumpfile with the helper programs that come with the GtkWave waveform viewer. |
||||||