Vera supports a functional coverage system. This system is able to monitor all states and state transitions, as well as changes to variables and expressions. By setting up a number of monitor bins that correspond to states, transitions, and expression changes, Vera is able to track activity in the simulation. Each time a user-specified activity occurs, a counter associated with the bin is incremented. By establishing a bin for each state, state transition, and variable change that you want monitored, you can check the bin counter after the simulation to see how many activities occurred. It is, therefore, simple to check the degree of completeness of the testbench and simulation.

In this section we will covering following topics in details.

• Coverage Group
• Measuring Coverage
• Cumulative and Instance-based Coverage

Basically functional coverage can be seen as bunch of counters, and these counters increment based on some events. Events can be simple or complex. Functional coverage point for a memory controller could have coverage samples as

• Reads
• Writes
• Reads Followed by write
• Write folloed by read
• Data width
• Address width

Functional coverage is declared inside a class, just like randomization constraints. They need to declared before any method is declared.

The coverage_group construct specifies the coverage model. It is defined either at the top level defined in a class (referred to as "embedded") The syntax is the same for both.

Syntax

coverage_group definition_name [(argument_list)]
{
sample_event_definition;
[coverage_point_definitions]
[cross_definitions]
[attribute_definitions]
}

Where

• definition_name : Is the name of the coverage_group.
• argument_list : Are arguments passed at instantiation. They have the same conventions as subroutine arguments and can have their default values set within the declaration
• sample_event_definition : Defines when (or frequency at which) the coverage objects are sampled.
• coverage_point_definitions : define the coverage points that are sampled by the coverage_group. They are declared using the sample construct of a coverage_group.
• cross_definitions : cross_definitions define cross coverage by crossing subsets of the coverage points being sampled by a coverage_group which includes the cross_definition. Crosses of coverage points of a coverage_group can be specified using the cross construct.

When a coverage is defined inside a class it is called embedded coverage group. It is recommended that embedded coverage group is used.

Example

  1 class coverage_covergroup {
  2   // All variables declared here
  3   integer abc;
  4   bit [7:0] data;
  5 
  6   // Declare coverage_groups here
  7   coverage_group c1 {
  8      sample_event = wait_var(abc);
  9      // Body of coveragegroup here
 10      sample data;
 11    
 12   }
 13 
 14   // All the class methods here
 15   task new () {
 16     // do something
 17   }
 18 }
 19 
 20 program test {
 21   coverage_covergroup cov = new();
 22 }

When a coverage is defined outside a class it is called stanalone coverage group.

Example

  1 coverage_group c1 {
  2    sample_event = wait_var(abc);
  3    // Body of coveragegroup here
  4    sample data;
  5 }
  6 
  7 program test {
  8   integer abc;
  9   bit [7:0] data;
 10 }

Copyright © 1998-2014

Deepak Kumar Tala - All rights reserved

Do you have any Comment? mail me at:deepak@asic-world.com