13 

6   Getting Started

Before you are ready to being scoring, merging and generating coverage reports from the design, you will first need to decide whether you want to post-process VCD/LXT -formatted dumpfiles generated from simulation or whether you want to accummulate coverage information alongside the simulator using the simulator's VPI interface. There are advantages and disadvantages to either method, so select the method that will best work for you.

Generating coverage information from VCD/LXT -formatted dumpfiles requires three steps: (1) compile the simulator to dump in the specified format, (2) run the simulation, (3) run Covered's score command using the dumpfile as input along with the design. Performing these steps will generate the needed CDD file that can be used for merging or reporting. The advantages to this approach is that the steps are fairly simple and are compiler/simulator -independent. However, there are two main drawbacks. First, compiling with dumping enabled often slows simulation by some significant factor. Second, the dumpfiles generated from simulation can often be quite large (especially for VCD dumping), consuming a lot of disk space. Additionally, if your simulator dumps in a format different from VCD or LXT, you will need to perform an additional step in transforming the original dumpfile into one of these formats. This is often a time-consuming task if the design and/or dumpfile is significantly large. If you are generating lots of dumpfiles for coverage (say from running a regression), the amount of disk space needed to store these files can be tremendous, making this approach almost not feasible.

Generating coverage information using the VPI interface of the simulator requires three main steps: (1) create a base CDD file from the design along with a top-level Verilog module and PLI table file (this second file is needed for the commercial VCS compiler), (2) compile the simulator using the Covered VPI module (or shared object), (3) run the simulation. The end result of these steps is the same CDD file that results from using the dumpfile method described above. The primary advantage of this approach is that no dumpfiles are required, saving on disk space and dumpfile processing time. The drawbacks of this approach are the following: (1) simulation runs much slower using the VPI and Covered (most likely slower than creating dumpfiles from the simulator), (2) Covered VPI modules are only available for certain compilers (Icarus Verilog, Cver and VCS currently); however, adding support for other compilers should not be a difficult thing to do, (3) the VPI modules will only work for compilers that support the VPI interface (a Verilog-2001 feature).

6.1  What is needed for dumpfile scoring?

Before Covered can be invoked for dumpfile scoring, 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.

6.1.1  Creating a VCD dumpfile

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;

initial
  begin
    $dumpfile( "test.vcd" );
    $dumpvars( 1, test.foo );
  end

foo_mod foo();

endmodule

module foo_mod;

...

endmodule

$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!

6.1.2  Creating an LXT dumpfile

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.

6.2  What is needed for VPI scoring?

After Covered has been configured and built to include the creation of a VPI loadable module or shared object file (see Installing from Source for details), Covered is capable of scoring during a simulation run by using the VPI (Verilog Procedural Interface) access mechanism. This is done by loading the Covered VPI module (or shared object) into the simulator executable prior to running (depending on the simulator being used). The following steps should be taken to create a scored CDD file using this method.

1. Create the Verilog file that will be compiled as a top-level module in the design (alongside the actual top-level(s)).

   This is done by running the score command with the -vpi option. The following example command-line shows how this step is done, creating a file called "covered_vpi.v".

   covered score -t top -vpi

2. Compile the simulator executable, including the previously generated file and the Covered VPI module. See the compile instructions for the Icarus Verilog, Cver or VCS simulators below.
3. Run the simulation. Once simulation is complete, the resulting CDD file will be a completely scored database, ready to be merged with other CDD files from the same design or reported on.

6.2.1  Compiling for Icarus Verilog

If you are compiling an Icarus Verilog simulation, simply add -m /usr/local/libexec/covered.vpi covered_vpi.v to the command-line.

6.2.2  Compiling for Cver

If you are compiling a Cver simulation, simply add +loadvpi=/usr/local/libexec/covered.cver.so:vpi_compat_bootstrap covered_vpi.v to the command-line.

6.2.3  Compiling for VCS

If you are compiling a VCS simulation, simply add +vpi -load /usr/local/libexec/covered.vcs.so:covered_register covered_vpi.v to the command-line.

[  Contents  |  First Page  |  Previous Page  |  Home   | Next Page  |  Last Page  ]