Appendix E

FSM Coverage - Worked Examples


As this appendix uses the same set of Verilog files as Appendix C you should refer to that appendix for instructions on how to obtain and download the files.

Directory and File Structure

Create a directory (e.g. my-fsm) on your system and then unpack the complete set of files that you obtained in the above step into that area. Make sure the directory contains the following files and that the filenames and suffix are correct.

test_monitor.v // This is the test bench
circuit.f // Verilog files in the design
doit.fsm.bat // Command line batch file
vnavigator.par // Parameter file

Command Line Batch File

A command line batch file (called doit.fsm.bat) is supplied which can be used to automate the process of analyzing and instrumenting the Verilog source files, running the simulation and collecting the activity-data for the results file. To assist you in understanding the operation of this stage, each line of the batch file is explained below.

1. vnlib -verilog -delete work_lib
2. vnlib -verilog -create my-work=./my-work
3. vnlib -verilog -setwork my-work
4. vnvlog -fsmstate -fsmarc -fsmpath -- -f circut.f
5. vnsim -fsmpath -- test_monitor
6. vnresults -format detail \
-design_units test_monitor.uut.proc

Lines 1 to 3 create a new library to hold the design files that will be analyzed and instrumented. The Verilog source files that make up the complete design that need to be analyzed and instrumented are listed in the circuit.f file. This information is passed to VN-Cover by the command given on Line 4 together with the options to collect state, arc and path coverage for any finite state machines that are contained in any of the Verilog files.

Line 5 specifies the name of the test bench or top-level module (e.g. test_monitor) and runs a normal Verilog simulation to collect the activity-data for the complete design. Line 5 also specifies that FSM path coverage should be evaluated during the simulation The information is written to a results file that has a default name of vnavigator.index. Line 6 is a post-processing stage that creates a text file (from the FSM results file) that gives detailed coverage information for the instances specified in the design_units options. In this particular example only the proc instance contains a finite state machine, so to save time this is the only instance that is included in the design_units options. A simple text editor can be used to inspect the contents of test_monitor.uut.proc.txt and determine the amount of arc, state and path coverage for the FSM in cpu.v.

Collecting Coverage Results

Make sure you are positioned in the directory that you created to hold the Verilog source files. Invoke the command line batch file by entering the following text string.

C:\my-fsm> doit.fsm.bat

This action will automatically invoke the VN-Cover part of Verification Navigator and carry out the following steps.

… Analyze and Instrument the Verilog source files.
… Call the ModelSim simulator to collect FSM coverage information.
… Output a results file containing the FSM activity-data.
… Produce a text file containing detailed coverage information.

The name of the results file is: vnavigator.index which is located in the default sub-directory: vnavigator_results

During the analysis phase a static verification check is performed on any finite state machine that are detected in the various Verilog source files. A number of warnings that relate to the state register that is used within the cpu.v file are displayed in the terminal window. For example, there are warnings about:

… no default state assignment

This message indicates that there is no default clause specified within a `case' construct to explicitly define that the state machine should remain in the same state if none of the other conditions (that would cause it to move to another state) are detected.

… unreachable state

This message indicates that, although there is a piece of HDL code that describes a particular state within the state machine, there is no way of getting to that code from any of the other states. During the simulation phase a number of checks are made to determine the dynamic coverage on each of the extracted state machines. These checks include: FSM state coverage, FSM arc or transition coverage as well as FSM path coverage.

Viewing Coverage Results

There are two ways to view the detailed coverage information that was produced by the command line batch file. You can either inspect the contents of the coverage files with a text editor or use the GUI (graphical user interface) that is available within VN-Cover. This worked example will make use of the graphical user interface which can be invoked by entering the following text string.

C:\my-fsm> vnavigator

This action will bring up a top-level flowchart, as shown in Figure E-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 E-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 E-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.fsm.bat) we can skip this stage and move on to inspecting the FSM coverage results.

Click the Results button - the sixth button as shown on the following flowchart.

Figure E-2

This action will bring up the window as shown below.

Figure E-3

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

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 E-4

Clicking the Detail button, at the base of the FSM Results Summary area of the 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 E-5.

Figure E-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 E-6, shows a summary of the FSM 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 all the state machines that have been detected. As only one state machine has been detected in this design the global summary will relate to just this single state machine.

Figure E-6

As you move around the design by clicking the appropriate module or instance in the hierarchy viewer the summary values change to reflect the coverage at that particular level. The information displayed in the Hierarchy window enables you to identify quickly the state machines that have poor coverage. An inter-window communication process links the Hierarchy window with the Metrics View window (as shown in Figure E-7) and enables you to inspect specific coverage metric values for individual state machines. Although the Hierarchy window is basically a static window, the Metrics View window is dynamic and enables the individual values for FSM coverage measurements to be displayed by clicking the appropriate metric tab located along the top edge of the window.

State Coverage

For example, clicking the entry that relates to the proc module in the Hierarchy window will cause state coverage information to be display as shown in Figure E-7.

Figure E-7

Arc and Path Coverage

As shown below, arc and path coverage results for the FSM can also be obtained by clicking the appropriate tabs along the top edge of the window.

Figure E-8

State Diagram

Earlier in this appendix it was mentioned that one of the tasks conducted during the instrumentation phase was an automatic extraction process to identify any finite state machines within the HDL code. Although this information is primarily used by VN-Cover to perform a static and dynamic analysis it is also used to automatically generate a state diagram for each extracted state machines. An example of the state diagram produced byÝVN-Cover is shown in Figure E-9.

Figure E-9

The Metrics View and Code View windows communicates with the State Diagram window to enable the user to uncover the parts of the state machine that have poor coverage.

Cycle Information

Clicking the information tab labelled FSM Path in the Metric View window and then clicking the line entry (that relates to the extracted state machine) will cause the contents of the State Diagram and Code View windows to change to that shown by Figures E-9 and E-10.

The left-hand pane of the Code View window shows a list of the super-cycles that have been detected by VN-Cover and how many times each of those super-cycles have been traversed. Super-cycles that have not been exercised are shown highlighted with a red background. The pane on the right of the Code View window gives information about the sub-cycles and links that have been detected.

Figure E-10

The lower pane, in the Code View window, conveys detailed information about:

… how the sub-cycles relate to specific super-cycles,
… the number of times the sub-cycles have been traversed.

As some of the sub-cycles are nested within other sub-cycles this can affect the clarity of the information presented to the user. To overcome this there is a mechanism to expand or collapse the amount of information that is displayed in the Code View window. This is achieved by clicking the triangular shaped symbols to expand or contract each part of the sub-cycle.

Finally it should be noted that as you explore the FSM path coverage for the various super-cycles and sub-cycles the State Diagram is constantly updated so that you can visually see the coverage in a color-coded format. i.e. Red indicates no coverage, green indicates 100% coverage, while black indicates that coverage could not be determined.

Copyright (c) 2002
Teamwork International and TransEDA Limited
Voice: (408) 335-1300
Fax: (408) 335-1319
S2C: FPGA Base prototyping- Download white paper

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