TOC PREV NEXT INDEX  

Appendix D

VHDL Coverage Analysis - Worked Examples

 

In this section we will run coverage analysis on a simple VHDL example. The software we will use is Verification Navigator 2002.03 from TransEDA. At the time of going to print this was the only commercially available general purpose coverage analysis tool for VHDL. The following environment will be used:

Operating system: Unix (Sun Solaris 2.7)
VHDL simulator: ModelSim 5.5 from Model Technology Inc.

Verification Navigator supports a number of simulators and operating systems, if your configuration is different please contact TransEDA for an alternative set of instructions on how to run the worked example and case study.

Getting Organized

It is assumed that Verification Navigator and ModelSim have both been installed according to the vendor's instructions and that the necessary environment (PATH etc.) has been set up to run both tools. If this is not the case, please contact the relevant vendor for technical support before going any further.

The various files necessary to run this case study can be obtained as a single `zip' file (for Windows) or `tar' file (for Unix) from the TransEDA web site at:

www.transeda.com/vmm/

If you encounter any problems in obtaining the `zip' file please contact TransEDA at the following e-mail address:

vmm@transeda.com

Directory and File Structure

Create a new directory on your system, and then unpack the `tar' file into that directory. The directory should now contain the following files:

Design and test bench VHDL files:

alu.vhd
asic.vhd
controller_a.vhd
controller_e.vhd
numeric_bit.vhd
test_asic.vhd

Test vector file (read by test_asic.vhd):

test.vec

Verification Navigator options file:

vnavigator.par

Batch script file:

doit.modelsim

Getting The Results

It is possible to run Verification Navigator completely from the graphical user interface (GUI), although in this case study we will run a batch script. Batch operation is commonly used for large designs because it is far easier to write a script once to be re-used many times. In this case study our batch script is called doit.modelsim and its contents is as follows:

1. vnlib -create coverlib=./vlib
2. vnlib -setwork coverlib
3. vnvhdl -noinstrument numeric_bit.vhd
4. vnvhdl alu.vhd
5. vnvhdl controller_e.vhd
6. vnvhdl -declaration\
controller_e.vhd controller_a.vhd
7. vnvhdl asic.vhd
8. vnvhdl -noinstrument test_asic.vhd
9. vnsim -run 550ns test_asic_configuration

The vnlib commands create libraries and set up logical names, and are analogous to the ModelSim vlib and vmap commands. The first command creates a library in the directory called ./vlib with the VHDL logical name `coverlib'. The `work' library is set to be `coverlib' by the second command.

The vnvhdl commands instrument (add extra VHDL to collect the coverage analysis) and compile the VHDL files. The standard VHDL compilation order rules apply, just as they would for the ModelSim vcom command. The design is compiled bottom up and in the case of controller_e.vhd and controller_a.vhd the entity is compiled before the architecture. The separate entity file is also listed as a declarations file when processing the architecture so all the port types are known. The -noinstrument switch is used to suppress coverage collection on the package file and the test bench. The coverage options for the other VHDL files are defined by the options file vnavigator.par, although these can also be specified on the command line.

The final command in the batch script (vnsim) runs the simulation and collects coverage information. This is analogous to the ModelSim vsim command and runs your normal simulation test bench. The optional -run switch defines how long the simulation is to be run for. If there is more that one test bench for the design the vnsim line would be repeated for each test bench, taking care to choose a different results file name in each case.

To run the batch script the command is:

$ ./doit.modelsim

If your environment has been set up correctly this will create the results file vmm.res. This file is best reviewed using the graphical user interface, although a batch command to create man-readable results files does exist.

To start the graphical user interface the command is:

$ vnavigator &

This action will bring up a top-level flowchart, as shown in Figure D-1, to guide you through the various tools that are available within Verification Navigator's verification environment.

The first button will invoke the Static Verification tool know as VN-Check. Further details on this particular tool can be found in Appendix B.

The second button will invoke the Dynamic Verification tool known as VN-Cover. You should click this button to bring up another flowchart, as shown in Figure D-2 below. This flowchart is known as the Verification Flow and is designed to guide you through the various parts of the Dynamic Verification tool.

The third button will cause a window to be displayed that shows how many of the design units or modules have satisfied the user specified sign-off criteria.

The fourth button will invoke the Testsuite Optimisation tool know as VN-Optimise. Further information on this particular tool can be found in Chapter 12.

The Verification Flow flowchart, as shown in Figure D-2, is used to allow you to interact graphically with VN-Cover to create libraries, select the design files that you want to instrument and set up communication with your chosen simulator. As we have already generated the results file using the command line script (doit.modelsim) we can skip this stage and move on to inspecting the coverage results.

Click the Results button - the sixth button on the flowchart.

Figure D-2

This action will bring up the window as shown below.

Figure D-3

Click the Load Results Files button to display the list of results files that are available to you.

Select the file labelled vnavigator.index by clicking the corresponding entry in the Results File(s) pop-up window. This action will load the requested results file into Verification Navigator's internal database area. A summary of the coverage that has been achieved is displayed in the Results Summary window.

Figure D-4

Clicking the Detail button, at the base of the Results Summary window, will enable you to obtain detailed information about coverage in specific parts of the design. The action of clicking the Detail button will cause the display screen to change and become populated with the set of six windows as shown in Figure D-5.

Figure D-5

The Flow Manager window is really an iconised version of the Verification Flow window and can be used as a way to return to the main flow if you need to repeat the instrumentation or simulation phases.

The right-hand section of the Hierarchy window, as shown in Figure D-6, shows a summary of the coverage measurements for the section of the design's hierarchy that is currently selected. At the moment the whole of the design's hierarchy has been selected so what is indicated is a global summary for the whole of the design.

Figure D-6

The Hierarchy window shows the cumulative coverage for all the measurements for either the whole of the design hierarchy or a part of it. To see the figures for part of the hierarchy click on the name of the instance at the top of the sub-tree you are interested in. If the overall coverage shown in the Hierarchy window is not acceptable the next step is to investigate the problems. The Metrics View window, shown in Figure D-7, makes this easy by listing, for every coverage measurement, all the design instances in the order of worst coverage through to best coverage. This makes it quick and easy to find the instances with coverage problems.

Figure D-7

The next step is to click on an instance in the Metrics window which you are interested in (for example test_asic.uut1.uut). This displays the VHDL source code for that instance in the Code View window with color-coded highlighting to show the coverage problems. Figure D-8 shows an example of the Code View window.

Figure D-8

If more detail is required on any coverage problem you can click on the color-coded line to pop up the Detail View window. Figure D-9 shows the branch Detail View window produced by clicking on line 37 of the Code View. The Detail View window shows that one branch of the `case' statement has not been executed.

Figure D-9

Figure D-10 shows the condition coverage detail created by clicking on line 32 in the Code View window. In this example, the expression has two inputs, and input RTB has not uniquely controlled the expression to logical 1. The report lists the test pattern required to complete the coverage on that expression (STB = 0, RTB = 1).

Figure D-10

The detailed toggle coverage information is obtained by pressing on the Toggle tab in the Code View window. Figure D-11 shows an example of this for instance test_asic.uut1.uut2. In this example only one signal has not been toggled by the test bench and is therefore highlighted.

Figure D-11

We have worked through the basic principles of collecting and viewing coverage analysis results for a VHDL design. Having identified the coverage analysis problems it is up to you as the designer or verification engineer to decide if the missing coverage is significant and if so how to add extra test patterns to test the uncovered code.

If required additional practical exercises can be obtained from TransEDA and can also be found in the `example' directory where Verification Navigator was installed on your system.


    TOC PREV NEXT INDEX  
Copyright (c) 2002
Teamwork International and TransEDA Limited
http://www.transeda.com
Voice: (408) 335-1300
Fax: (408) 335-1319
info@transeda.com
CST Webinar Series



Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy