Don't have 2 re-discover these things when u use vericover again:

 

 

• To run the dumping for coverage , use +nccover with the ncverilog command.

 

• The simulator creates a directory cover.cov and dumps the data needed for the vericover analyzer tool.

 

 

• If u are running for discrete file then u have to run ncverilog in interactive mode with -s option. Then on ncsim> prompt u should give the following tcl commands:

                       ncsim> coverage -statement <hierarchy>

                       ncsim> -coverage -dump <hierarchy>

                       ncsim> run

                       ncsim> exit.

 

• If u want to give the tcl commands from a file, then u have to write them in a file ( say, tcl_file) and run ncverilog with the option - +tcl+tcl_file. This option is very much useful , as it avoids manual intervention while running a set of vectors in batch mode.

 

• The simulator creates two types of files:

                       *.dsn : This design file is created if there are any design changes- i.e. if any verilog code is changed below the said hierarchy.                       

                       *.acv : This file is created for each of the vector run. It has an association with the *.dsn file. There can be more than one .acv file corresponding to one .dsn file.

 

• If there are a large no of vectors, then run all of them , generate one .dsn and multiple .acv files . The command nccov -merge <design_file> will generate a merged .acv file of all .acv files, corresponding to the design_file.

 

• The vericover coverage analyzer can be invoked in gui mode by nccov.

 

• If there are 2 instances of the design in the test environment , run the simulation twice keeping each of the instance as top once. For example in case of a project there are two instances: u1xx_top and u2xx_top. Run the simulation specifying hierarchy as xx_top_tb.u1xx_top once and as xx_top_tb.u2xx_top other time. Now one .dsn file two .acv file are created. Merge .acv files . When u run the gui of nccov , n try to see the coverage of each instance , u'll see only u1bt_top. Don't panic!!!! . both the instances have been considered for the coverage but it shows only the instance present in first .acv.

 

• If u want to exclude a instance/module from calculation then right click on it and select `exclude from the category `option. Then press the "A" button at the top to calculate the coverage without that particular module. If u want to again selct it for coverage then again right click select `statement execution required'.

 

• similarly if u want to exclude a statement ( like default) to be excluded from calculation for coverage , same thing should be done.

 

• If u want to save the step 9/10's settings we need to save the .act ( coverage script file) by clicking on the S button. To re do the settings do - open -> file_type .act and then open.

 

Extracts from a discussion in verification guild about covearge.

  Coverage, in general, can be divided into two types: program-based or functional. Program-based (or code) coverage        concentrates on measuring syntactic properties in the execution, for example, that each statement was executed, or each branch was taken. In that sense, fault grading is another program-based coverage model (although it may be better than other models used like statement, path, etc.). The main advantage of code coverage is that it is a "push button" technology.

Functional coverage, on the other hand, focuses on the functionality of the program, and it is used to check that every aspect of the functionality is tested. Therefore, functional coverage is design and implementation specific, and is more costly to measure. The main advantage of functional coverage is that it allows you to concentrate on the most complicated or riskiest parts of your design and do it at the right level of abstraction. For example, if a part of your design is a switch that's responsible for routing data coming and going in all directions, it is more important to make sure that all cases of data arrival from all sources are tested than that all the lines of code have been executed. The most prominent example (and unfortunately a very common case) where program-based coverage fails and functional coverage may succeed is missing code. For example, suppose that you forgot to add the switch the (very rare) case when data is routed back to its source. No program-based coverage model can detect this, while a good functional coverage model that looks for all possible source destination pairs will point-out that this event is not tested and lead to discovery of the bug.

Functional coverage has two main problems, both of them directly connected to the fact that functional coverage models are design dependent. First, the lack of tools for functional coverage and second the effort required to define functional coverage models. Since functional coverage models are design dependent, it is impossible to find coverage tools that will implement the coverage models that you need. Still, recently several tools, such as Specman, Vera, and our in house coverage tools Meteor and Focus, provide a framework that allows users to define their own coverage models and measure coverage on them. These tools have their limitations, and not every needed coverage models can be implemented by them.

The more serious "problem" with functional coverage is that it require you to think on what you really want to do in your testing, not just let your random test generator run wild. Of course, this will help you to a better understanding of the design and how it should be tested, and lead to a better test plan that utilizes the simulation resources more efficiently and produces cleaner design. In fact, we found out that in some cases just the definition of the coverage models, even before coverage was measured, was enough to provide this advantages.

Hosted by www.Geocities.ws