20.

1 Introduction

Functional verification comprises a large portion of designing and verifying a complex system. Designs often
pack a large number of features that exhibit very complex functionality. Validation of such designs is fre-
quently complex, resource intensive, as well as critical. The validation must be comprehensive without re-
dundant effort. To minimize wasted effort, coverage is used as a guide for directing verification resources by
identifying tested and untested portions of the design.

Coverage is defined as a percentage of verification objectives that have been met. It is used as a metric for
evaluating the progress of a verification project to reduce the simulation cycles that are spent in verifying a
design

Broadly speaking, there are two type of coverage metrics. Those that can be automatically extracted from the
design code, such as code coverage, and those that are specified by designers in order to tie the verification
environment to their design intent or functionality. This latter form is referred to as Functional Coverage, and
is the topic of this section.

Functional coverage is a user-defined metric that measures how much of the design specification, as enumer-
ated by features in the test plan, have been exercised. It is, thus, a model of the verification plan. It measures
whether interesting scenarios, corner cases, specification invariants, and other applicable DUT conditions—
captured as features of the test plan— have been observed, validated and tested.

The key aspects of functional coverage are:

 It is user-specified, and is not automatically inferred from the design
 It is based on the design specification (i.e., its intent) and is thus independent of the actual design
code or its structure.

Since it is fully specified by the user, functional coverage requires more upfront effort from designers (some-
one has to write the coverage model). Functional coverage also requires a more structured approach to verifi-
cation. Although functional coverage can shorten the overall verification effort and yield higher quality de-
signs, these shortcomings can impede its adoption.

The SystemVerilog functional coverage extensions address these shortcomings by providing language con-
structs for easy specification of functional coverage models. This specification can be efficiently executed by
the SystemVerilog simulation engine, thus, enabling coverage data manipulation and analysis tools that speed
up the development of high quality tests. The improved set of tests can exercise more corner cases and re-
quired scenarios, without redundant work.

The SystemVerilog functional coverage constructs enable:

 Coverage of variables and expressions, as well as cross coverage between them.
 Automatic as well as user-defined coverage bins.
 Associate bins with sets of values, transitions, or cross products.
 Filtering conditions at multiple levels.
 Events and sequences to automatically trigger coverage sampling.
 Procedural activation and query of coverage.
 Optional directives to control and regulate coverage.

1
20.2 Defining the coverage model: covergroup

The covergroup construct encapsulates the specification of a coverage model. Each covergroup specification
may include the following components:
 A clocking event that synchronizes the sampling of coverage points
 A set of coverage points
 Cross coverage between coverage points
 Optional formal arguments
 Coverage options

The covergroup construct is a user-defined type. The type definition is written once, and multiple instances
of that type can be created in different contexts. Similar to a class, once defined, a covergroup instance can
created via the new() operator. A covergroup may be defined in a module, program, interface, or class.

coverage_group_decl ::= covergroup covergroup_identifier [ ( list_of_task_proto ) ] [ clocking_event ] ;

{ coverage_spec_or_option ; }
endgroup [ : covergroup_identifier ]

list_of_task_proto ::= task_proto_formal { , task_proto_formal }

coverage_spec_or_option ::=
{attribute_instance} coverage_spec
| {attribute_instance} coverage_option

coverage_option ::=
option.option_name = expression
| type_option.option_name = expression

coverage_spec ::=
cover_point
| cover_cross

variable_decl_assignment ::= // covergroup creation

…
| variable_identifier = new [ ( list_of_arguments ) ]
Syntax 20-1—Covergroup syntax (excerpt from Annex A)

The identifier associated with the covergroup declaration defines the name of the coverage model. Using this
name, an arbitrary number of coverage model instances can be created. For example:
covergroup cg; ... endgroup;
cg cg_inst = new;

The above example defines a covergroup named cg. An instance of cg is declared as cg_inst and created us-
ing the new operator.

A covergroup may specify an optional list of arguments. When the covergroup specifies a list of formal ar-
guments, its instances must provide to the new operator all the actual arguments that are not defaulted. Actual
arguments are evaluated when the new operator is executed.

If a clocking event is specified, it defines the event at which coverage points are sampled. If the clocking
event is omitted, users must procedurally trigger the coverage sampling. This is done via a built-in method
(see Section 20.7).

2
A covergroup may contain one or more coverage points. A coverage point can be a variable or an expression.
Each coverage point includes a set of bins associated with its sampled values or its value-transitions. The bins
may be explicitly defined by the user or automatically created by the tool. Coverage points are discussed in
detail in Section 20.4.

enum { red, green, blue } color;

covergroup g1 @(posedge clk);

c: coverpoint color;
endgroup;

The above example defines coverage group g1 with a single coverage point associated with variable color.
The value of the variable color is sampled at the indicated clocking event: the positive edge of signal clk.
Since the coverage point does not explicitly define any bins, the tool automatically creates 3 bins, one for
each possible value of the enumerated type. Automatic bins are described in Section 20.4.2.

A coverage group may also specify cross coverage between two or more coverage points or variables. Any
combination of more than two variables or previously declared coverage points is allowed. For example:
enum { red, green, blue } color;
bit [3:0] pixel_adr, pixel_offset, pixel_hue;

covergroup g2 @(posedge clk);

Hue: coverpoint pixel_hue;
Offset: coverpoint pixel_offset;

AxC: cross color, pixel_adr; // cross 2 variables

all: cross color, Hue, Offset; // cross 1 variable and 2 coverpoints
endgroup;

The example above creates coverage group g2 that includes 2 coverage points and two cross coverage items.
Explicit coverage points labeled Offset and Hue are defined for variables pixel_offset and pixel_hue. Sys-
temVerilog implicitly declares coverage points for variables color and pixel_adr in order to track their cross
coverage.

A coverage group may also specify one or more options to control and regulate how coverage data is struc-
tured and collected. Coverage options may be specified for the coverage group as a whole, or for specific
items within the coverage group, that is, any of its coverage points or crosses. In general, a coverage option
specified at the covergroup level applies to all of its items unless overridden by them. Coverage options are
described in Section 20.7.

20.3 Using covergroup in classes

By embedding a coverage group within a class definition, the covergroup provides a simple way to cover a
subset of the class properties. This integration of coverage with classes provides an intuitive and expressive
mechanism for defining the coverage model associated with a class. For example,

class xyz;
bit [3:0] m_x;
int m_y;
bit m_z;
endclass

For class xyz, defined below, members m_x and m_y can be covered using a covergroup as follows:

class xyz;

3
 bit [3:0] m_x;
int m_y;
bit m_z;
covergroup cov1 @m_z;
coverpoint m_x;
coverpoint m_y;
endgroup
function new(); cov1 = new; endfunction
endclass

Data members m_x and m_y of class xyz will be sampled on every change of member variable m_z.

When a covergroup is defined within a class, the coverage group itself becomes part of the class, tightly
binding the class properties to the coverage definition. The embedded coverage-group variables need not be
declared; instead the coverage group identifier acts as the coverage instance. This eliminates the need for cre-
ating a separate coverage instance for each class object and binding the coverage instance to the object prop-
erties that are to be covered; a tedious and error prone process. Declaring a variable of an embedded cover-
age-group shall result in a compiler error.

An embedded covergroup can define a coverage model for protected and local class properties without any
changes to the class data encapsulation. Class members can become coverage points or can be used in other
coverage constructs, such as conditional guards or option initialization.

A class can have more than one covergroup. The following example shows two cover groups in class MC.

class MC;
logic [3:0] m_x;
local logic m_z;
bit m_e;
covergroup cv1 @(posedge clk); coverpoint m_x; endgroup
covergroup cv2 @m_e ; coverpoint m_z; endgroup
endclass

In covergroup cv1, public class member variable m_x is sampled at every positive edge of signal clk. Local
class member m_z is covered by another covergroup cv2. Each coverage groups is sampled by a different
clocking event.

An embedded coverage group must be explicitly instantiated in the new method. If it is not then the coverage
group is not created and no data will be sampled.

Below is an example of an embedded coverage_group that does not have any passed-in arguments, and uses
explicit instantiation to synchronize with another object:

class Helper;
int m_ev;
endclass

class MyClass;
Helper m_obj;
int m_a;
covergroup Cov @(m_obj.m_ev);
coverpoint m_a;
endgroup

2
 function new();
m_obj = new;

Cov = new; /* Create embedded covergroup after creating m_obj */

endfunction
endclass

In this example, covergroup Cov is embedded within class MyClass, which contains an object of type Helper
class, called m_obj. The clocking event for the embedded coverage group refers to data member m_ev of
m_obj. We instantiate embedded coverage group Cov is instantiated after instantiating m_obj in the construc-
tor. As shown above, the instantiation of an embedded coverage group is done by assigning the result of the
new operator to the coverage group identifier.

The following example shows how arguments passed in to an embedded coverage group can be used to set a
coverage option of the coverage group.

class C1;
bit [7:0] x;

covergroup cv (int arg) @(posedge clk);

option.at_least = arg;
coverpoint x;
endgroup

function new(int p1);

MyCov = new(p1);
endfunction
endclass

initial begin
C1 obj = new(4);
end

20.4 Defining coverage points

A covergroup may contain one or more coverage points. A coverage point can be an integral variable or an
integral expression. Each coverage point includes a set of bins associated with its sampled values or its value-
transitions. The bins may be explicitly defined by the user or automatically created by SystemVerilog. The
syntax for specifying coverage points is given below.

cover_point ::= [label :] coverpoint expression [ iff (expression) ] bins_or_empty

bins_or_empty ::=
{ { bins_or_options ; } }
|;

bins_or_options ::=
{attribute_instance} coverage_option
| {attribute_instance} bins bin_identifier [[ ]] = range_list [iff (expression) ]
| {attribute_instance} bins bin_identifier [[ ]] = ( trans_list ) [iff (expression) ]
| {attribute_instance} bins bin_identifier [[ ]] default [iff (expression) ]

range_list ::= { value_range { , value_range } }

value_range ::= // from Annex A.8.3

3
 expression
| [ expression : expression ]
Syntax 20-2—Coverpoint syntax (excerpt from Annex A)

A coverage point may be optionally labeled. If the label is specified then it designates the name of the cover-
age point. This name may be used to add this coverage point to a cross coverage specification, or to access the
methods of the coverage point. If the label is omitted and the coverage point is associated with a single vari-
able then the variable name becomes the name of the coverage point. Otherwise, an implementation may gen-
erate a name for the coverage point only for the purposes of coverage reporting.

The expression within the iff construct specifies an optional condition that disables coverage for that cover
point. If the guard expression evaluate to false at a sampling point, the coverage point is ignored. For exam-
ple:
covergroup g4;
coverpoint s0 iff(!reset);
endgroup

In the preceding example, cover point s0 is covered only if the value reset is false.

A coverage-point bin associates a name and a count with a set of values or a sequence of value transitions. If
the bin designates a set of values, the count is incremented every time the coverage point matches one of the
values in the set. If the bin designates a sequence of value transitions, the count is incremented every time the
coverage point matches the entire sequence of value transitions.

The bins for a coverage point can be automatically created by SystemVerilog or explicitly defined using the
bins construct to name each bin. If the bins are not explicitly defined, they are automatically created by Sys-
temVerilog. The number of automatically created bins can be controlled using the auto_bin_max coverage
option. Coverage options are described in Section 20.7.

The bins construct allows creating a separate bin for each value in the given range-list, or a single bin for the
entire range of values. To create a separate bin for each value (an array of bins) the square brackets, [], must
follow the bin name. The range_list used to specify the set of values associated with a bin shall be constant
expressions, instance constants (for classes only) or non-ref arguments to the coverage group.

The expression within the iff construct at the end of a bin definition provides a per-bin guard condition. If the
expression is false at a sampling point, the count for the bin is not incremented.

The default specification defines a bin that is associated with none of the defined value bins. The default bin
catches the values of the coverage point that do not lie within any of the defined bins. However, the coverage
calculation for a coverage point shall not take into account the coverage captured by the default bin. The de-
fault bin does not apply to transitions, and is useful for catching unplanned or illegal values.
int v_a;

covergroup cg @(posedge clk);

coverpoint v_a
{
bins a = { [0:63],65 };
bins b[] = { [127:150],[148:191] }; // note overlapping values
bins c[] = { 200,201,202 };
bins others[] = default;
}
endgroup

In the example above, the first bins construct associates bin a1 with the values of variable v_a between 0 and
63, and the value 65. The second bins construct creates a set of 65 bins b[127], b[128],… b[191]. Likewise,

2
the last bins construct creates 3 bins: c[200], c[201], and c[202]. Every value that does not match bins a, b[],
or c[] is added into its own distinct bin.

20.4.1 Specifying bins for transitions

The syntax for specifying transition bins accepts a subset of the sequence syntax described in Section 17:

bins bin_identifier [[ ]] = ( trans_list ) [iff (expression) ]

trans_list ::= trans_set { , trans_set }

trans_set ::= trans_range_list -> trans_range_list {-> trans_range_list }

trans_range_list ::=
range_list
| range_list [ [* value_range ] ] // consecutive repetition
| range_list [ [*-> value_range ] ] // goto repetition
| range_list [ [*= value_range ] ] // non-consecutive repetition
Syntax 20-3 —Transition bin syntax (excerpt from Annex A)

A trans_list specifies one or more sets of ordered value transitions of the coverage point. A single value tran-
sition is thus specified as:
value1 -> value2
It represents the value of coverage point at two successive sample points, that is, value1 followed by value2 at
the next sample point.

A sequence of transitions is represented as:

value1 -> value3 -> value4 -> value5
In this case, value1 is followed by value3, followed by value4 and followed by value5. A sequence may be of
any arbitrary length.

A set of transitions can be specified as:

range_list1 -> range_list2
This specification expands to transitions between each value in range_list1 and each value in range_list2. For
example,
{1,5} -> {6, 7}
specifies the following four transitions:
1->6, 1->7, 5->6, 5->7

Consecutive repetitions of transitions are represented by:

range_list [* value_range ]
Here, range_list is repeated for value_range times. For example,
3 [* 5]
is same as
3->3->3->3->3

An example of a range of repetition is

3 [* 3:5]
is same as
3->3->3, 3->3->3->3, 3->3->3->3->3

The repetition with non-consecutive occurence of a value is specified as

range_list [*-> value_range ]
Here, the occurence of a value is specified with arbitrary number of sample points where the value does not
occur. For example,
3 [*-> 3]

3
is the same as
…3->....->3...->3
where the dots (…) represent any transition that does not contain the value 3.

Non-consecutive repetition is where the sequence of transitions continues until the next transition. For exam-
ple,
3 [*= 2]
is same as the transitions below excluding the last transition.
3->....->3...->3

A trans_list specifies one or more sets of ordered value transitions of the coverage point. If the sequence of
value transitions of the coverage point matches any complete sequence in the trans_list, the coverage count of
the corresponding bin is incremented. For example:
Bit [4:1] v_a;

covergroup cg @(posedge clk);

coverpoint v_a
{
bins sa = (4 -> 5 -> 6, {[7:9],10}->{11,12});
bins sb[] = (4 -> 5 -> 6, {[7:9],10}->{11,12});
}
endgroup

The example above defines two transition coverage bins. The first bins construct associates the following
sequences with bin sa: 4->5->6, or 7->11, 8->11, 9->11, 10->11, 7->12, 8->12, 9->12, 10->12. The second
bins construct associates an individual bin with each of the above sequences: sb[4->5->6], …,sb[10->12].

20.4.2 Automatic bin creation for coverage points

If a coverage point does not define any bins, Systemverilog automatically creates state bins. This provides an
easy-to-use mechanism for binning different values of a coverage point. Users can either let the tool auto-
matically create state bins for coverage points or explicitly define named bins for each coverage point.

By default, SystemVerilog creates an automatic bin for each of the first N distinct sampled values of a cover-
age point. The value N is determined as follows:
 For an enum coverage point, N is the cardinality of the enumeration.
 For any other integral coverage point, N is the minimum of 2M and the value of the auto_bin_max
option, where M is the number of bits needed to represent the coverage point.

SystemVerilog implementations may impose a limit on the number of automatic bins. See the Section 20.7
for the default value of auto_bin_max.

Each automatically created bin will have a name of the form: auto[value], where value is the sampled cover-
age point value. For enumerated types, value is the label associated with a particular enumerated value.

20.4.3 Specifying Illegal coverage point values or transitions

A set of values associated with a coverage-point or a set of transitions can be marked as illegal by specifying
the standard attribute illegal. For example:
covergroup cg3;
coverpoint a
{
(* illegal *) bins bad_vals = {1,2,3};
(* illegal *) bins bad_trans = (4->5->6};
}

4
 endgroup

All cross products that satisfy the select expression are excluded from coverage, and a run-time warning is
issued. Illegal cross products take precedence over any other cross products, that is, they will result in a run-
time warning even if they are also ignored or included in another cross bin.

20.5 Defining cross coverage

A coverage group may specify cross coverage between two or more coverage points or variables. Cross cov-
erage is specified using the cross construct. When a variable V is part of a cross coverage, SystemVerilog
implicitly creates a coverage point for the variable, as if it had been created by the statement “coverpoint
V;”. Thus, a cross involves only coverage points. Expressions may not be used directly in a cross; a coverage
point must be explicitly defined first.

The syntax for specifying cross coverage is given below.

cover_cross ::= [label:] cross list_of_coverpoints [ iff ( expression ) ] select_bins_or_empty

list_of_coverpoints ::= cross_item , cross_item { , cross_item }

cross_item ::=
cover_point_identifier
| variable_identifier

select_bins_or_empty ::=
{ { bin_selection_or_option ; } }
|;

bin_selection_or_option ::=
{attribute_instance} coverage_option
| {attribute_instance} bins_selection

bins_selection ::= bins bin_identifier = select_expression

select_expression ::=
select_condition
| ! select_condition
| select_expression && select_expression
| select_expression || select_expression
| ( select_expression )

select_condition ::= binsof ( bins_expression ) [. intersect open_range_list ]

bins_expression ::=
variable_indentifier
| cover_point_indentifier [ . bins_indentifier ]

open_range_list ::= { open_value_range { , open_value_range } }

open_value_range ::=
expression
| [ expression : expression ]
| [ expression : $ ]
| [$ : expression ]
Syntax 20-4 —Cross coverage syntax (excerpt from Annex A)

5
The label for a cross declaration provides an optional name. The label also creates a hierarchical scope for the
bins defined within the cross.

The expression within the optional iff provides a conditional guard for the cross coverage. If at any sample
point, the condition evaluates to false, the cross coverage is ignored.

Cross coverage of a set of N coverage points is defined as the coverage of all combinations of all bins associ-
ated with the N coverage points, that is, the Cartesian product of the N sets of coverage-point bins. For exam-
ple:
bit [3:0] a, b;

covergroup cov @(posedge clk);

aXb : cross a, b;
endgroup

The coverage group cov in the example above specifies the cross coverage of two 4-bit variables, a and b.
SystemVerilog implicitly creates a coverage point for each variable. Each coverage point has 16 bins, namely
auto[0]…auto[15]. The cross of a and b (labeled aXb), therefore, has 64 cross products, and each cross prod-
uct is a bin of aXb.

Cross coverage between expressions previously defined as coverage points is also allowed. For example:
bit [3:0] a, b, c;

covergroup cov2 @(posedge clk);

BC: coverpoint b+c;
aXb : cross a, BC;
endgroup

The coverage group cov2 has the same number of cross products as the previous example, but in this case,
one of the coverage points is the expression b+c, which is labeled BC.
bit [31:0] a_var;
bit [3:0] b_var;

covergroup cov3 @(posedge clk);

A: coverpoint a_var { bins yy[] = { [0:9] }; }
CC: cross b_var, A;
endgroup

The coverage group cov3 crosses variable b_var with coverage point A (labeled CC). Variable b_var auto-
matically creates 16 bins (auto[0] …auto[15]). Coverage point A explicitly creates 10 bins yy[0]..yy[9]. The
cross of two coverage points creates 16 * 10 = 160 cross product bins, namely the pairs shown below:

<auto[0], yy[0]>
<auto[0], yy[1]>
...
<auto[0], yy[9]>
<auto[1], yy[0]>
...
<auto[15], yy[9]>

Cross coverage is allowed only between coverage points defined within the same coverage group. Coverage
points defined in a coverage group other than the one enclosing the cross may not participate in a cross.

6
In addition to specifying the coverage points that are crossed, SystemVerilog includes a powerful set of opera-
tors that allow defining cross coverage bins. Cross coverage bins can be specified in order to group together a
set of cross products. A cross-coverage bin associates a name and a count with a set of cross products. The
count of the bin is incremented every time any of the cross products match, i.e., every coverage point in the
cross matches its corresponding bin in the cross product.

User-defined bins for cross coverage are defined using bins select-expressions. The syntax for defining these
bin selection expressions is given in Syntax 20-4.

The binsof construct yields the bins of its expression, which can be either a coverage point (explicitly defined
or implicitly defined for a single variable) or a coverage-point bin. The resulting bins can be further selected
by including (or excluding) only the bins whose associated values intersect a desired set of values. The desired
set of values can be specified using the open_range syntax shown in Syntax 20-4. For example, the following
select expression:
binsof( x ).intersect { y }
denotes the bins of coverage point x whose values intersect the range given by y. Its negated form:
! binsof( x ).intersect { y }
denotes the bins of coverage point x whose values do not intersect the range given by y.

The bins selected can be further combined with other selected bins using logical operators && and || .

20.5.1 Example of user-defined cross coverage and select expressions

bit [7:0] v_a, v_b;

covergroup cg @(posedge clk);

a: coverpoint v_a
{
bins a1 = { [0:63] };
bins a2 = { [64:127] };
bins a3 = { [128:191] };
bins a4 = { [192:255] };
}

b: coverpoint v_b
{
bins b1 = {0};
bins b2 = { [1:84] };
bins b3 = { [85:169] };
bins b4 = { [170:255] };
}

c : cross v_a, v_b

{
bins c1 = ! binsof(a).intersect {[100:200]}; // 4 cross products
bins c2 = binsof(a.a2) || binsof(b.b2); // 7 cross products
bins c3 = binsof(a.a1) && binsof(b.b4); // 1 cross product
}
endcovergroup

The example above defines a coverage-group named cg that samples its cover-points on the positive edge of
signal clk (not shown). The coverage-group includes two cover-points, one for each of the two 8-bit variables,
v_a and v_b. The coverage-point labeled ‘a’ associated with variable v_a, defines four equal-sized bins for
each possible value of variable v_a. Likewise, the coverage-point labeled ‘b’ associated with variable v_b,
defines four bins for each possible value of variable v_b. The cross definition labeled ‘c’, specifies the cross
coverage of the two cover-points v_a and v_b. If the cross coverage of cover-points a and b were defined
without any additional cross-bins (select expressions) the then cross coverage of a and b would include 16

1
cross products corresponding to all permutations of bins a1 through a4 with bins b1 through b4, that is, cross
products <a1, b1>, <a1,b2>, <a1,b3>, <a1,b4>… <a4, b1>, <a4,b2>, <a4,b3>, <a4,b4>.

The first user-defined cross bin, c1, specifies that all bin c1should include only cross products of cover-point a
that do not intersect the value range 100-200. This select expression excludes bins a2, a3, and a4. Thus, bin c1
will cover only four cross-products of <a1,b1>, <a1,b2>, <a1,b3>, and <a1,b4>.

The second user-defined cross bin, c2, specifies that bin c2 should include only cross products whose values
are covered by bin a2 of cover-point a or cross products whose values are covered by bin b2 of cover-point b.
This select expression includes the following 7 cross products: <a2, b1>, <a2,b2>, <a2,b3>, <a2,b4>, <a1,
b2>, <a3,b2>, and <a4,b2>.

The final user-defined cross bin, c3, specifies that bin c3 should include only cross products whose values are
covered by bin a1 of cover-point a and cross products whose values are covered by bin b4 of cover-point b.
This select expression includes only one cross-product <a1, b4>.

20.5.2 Excluding cross products

A group of bins can be excluded for coverage by specifying the standard attribute ignore. For example:
covergroup yy;
cross a, b
{
(* ignore *) bins foo = binsof(a).intersect { 5, [1:3] };
}
endgroup

All cross products that satisfy the select expression are excluded from coverage. Ignored cross products are
excluded even if they are included in other cross-coverage bin of the enclosing cross.

20.5.3 Specifying Illegal cross products

A group of bins can be marked as illegal by specifying the standard attribute illegal. For example:
covergroup zz(int bad);
cross x, y
{
(* illegal *) bins foo = binsof(y).intersect {bad};
}
endgroup

All cross products that satisfy the select expression are excluded from coverage, and a run-time warning is
issued. Illegal cross products take precedence over any other cross products, that is, they will result in a run-
time warning even if they are also ignored or included in another cross bin.

20.6 Specifying coverage options

Options control the behavior of the a covergroup, coverpoint and cross. There are two types of options: those
that are specific to an instance of a covergroup, and those that specify an option for the covergroup type as a
whole.

The following table lists instance specific covergroup options and their description. Each instance of a cover-
group can initialize an instance specific option to a different value. The initialize option value affects only that
instance.

2
 Option name Default Description
weight= number 1 If set at the covergroup syntactic level, it specifies the
weight of this covergroup instance for computing the
overall instance coverage of the simulation. If set at the
coverpoint (or cross) syntactic level, it specifies the
weight of a coverpoint (or cross) for computing the in-
stance coverage of the enclosing covergroup.
goal=number 90 Specifies the target goal for a covergroup instance, or a
coverpoint or a cross of an instance.
comment=string “” A comment that appears with the instance of a cover-
group, or a coverpoint or cross of the covergroup in-
stance. The comment is saved in the coverage database and
included in the coverage report.
at_least=number 1 Minimum number of hits for each bin. A bin with a hit
count that is less than num is not considered covered.
detect_overlap=Boolean 0 When true, a warning is issued if there is an overlap be-
tween the range list (or transition list) of two bins of a
coverpoint.
auto_bin_max=number 64 Maximum number of automatically created bins when no
bins are explicitly defined for a coverpoint.
cross_auto_bin_max=number unbounded Maximum number of automatically created cross product
bins for a cross.
cross_num_print_missing= 0 Number of missing (not covered) cross product bins that
number must be saved to the coverage database and printed in the
coverage report.
per_instance=Boolean 0 Each instance contributes to the overall coverage informa-
tion for the covergroup type. When true, coverage infor-
mation for this covergroup instance is tracked as well.
Table 20-1: Instance specific coverage options

The instance specific options mentioned above can be set in the covergroup definition. The syntax for setting
these options in the covergroup definition is:

option.option_name = expression ;

An example is shown below.

covergroup g1 (int w, string instComment) @(posedge clk) ;

// track coverage information for each instance of g1 in addition
// to the cumulative coverage information for covergroup type g1
option.per_instance = 1;

option.comment = instComment; // comment for each instance of this covergroup

a : coverpoint a_var
{
// Create 128 automatic bins for coverpoint “a” of each instance of g1
option.auto_bin_max = 128;
}
b : coverpoint b_var;
{
// This coverpoint contributes w times as much to the coverage of an instance of g1 than
// coverpoints “a” and “c1”
option.weight = w;
}

3
 c1 : cross a_var, b_var ;
endcovergroup

Option assignment statements in the covergroup definition are evaluated at the time that the covergroup is
instantiated. The per_instance option is instance constant. It can only be set in the covergroup definition.
Other instance specific options can be set procedurally after a covergroup has been instantiated. The syntax
is:

coverage_option_assignment ::= // Not in Annex A

instance_name.option.option_name = expression ;
| instance_name.covergroup_item_identifier.option.option_name = expression ;

Here is an example:

covergroup gc @(posedge clk) ;

a : coverpoint a_var;
b : coverpoint b_var;
endcovergroup
…
gc g1 = new;
g1.option.comment = “Here is a comment set for the instance g1”;
g1.a.option.weight = 3; // Set weight for coverpoint “a” of instance g1

The following table summarizes the syntactical level (covergroup, coverpoint, or cross) at which instance
options can be specified. All instance options can be specified at the covergroup level. Except for the weight,
goal, comment, and per_instance options, all other options set at the covergroup syntactic level act as a de-
fault value for the corresponding option of all coverpoint(s) and cross(es) in the covergroup. Individual
coverpoint or crosses may overwrite these default values. When set at the covergroup level, the weight,
goal, comment, and per_instance options do not act as default values to the lower syntactic levels.

Allowed in Syntactic Level

Option name
covergroup coverpoint cross
weight Yes Yes Yes
goal Yes Yes Yes
comment Yes Yes Yes
at_least Yes (default for coverpoints & crosses) Yes Yes
detect_overlap Yes (default for coverpoints) Yes No
auto_bin_max Yes (default for coverpoints) Yes No
cross_auto_bin_max Yes (default for crosses) No Yes
cross_num_print_missing Yes (default for crosses) No Yes
per_instance Yes No No
Table 20-2: Coverage options per-syntactic level

20.6.1 Covergroup Type Options

The following table lists options that describe particular feature (or property) of the covergroup type as a
whole. They are analogous to static data members of classes.

4
 Option name Default Description
weight=constant_number 1 If set at the covergroup syntactic level, it specifies the weight
of this covergroup for computing the overall cumulative (or
type) coverage of the saved database. If set at the coverpoint
(or cross) syntactic level, it specifies the weight of a cover-
point (or cross) for computing the cumulative (or type) cover-
age of the enclosing covergroup.
goal=constant_number 90 Specifies the target goal for a covergroup type, or a cover-
point or cross of a covergroup type.
comment=string_literal “” A comment that appears with the covergroup type, or a cover-
point or cross of the covergroup type. The comment is saved
in the coverage database and included in the coverage report.

The covergroup type options mentioned above can be set in the covergroup definition. The syntax for setting
these options in the covergroup definition is:

type_option.option_name = expression ;

Different instances of a covergroup cannot assign different values to type options. This is syntactically disal-
lowed, since these options can only be initialized via string or number literals. Here is an example:

covergroup g1 (int w, string instComment) @(posedge clk) ;

// track and save coverage information for each instance of g1 in addition to the
// cumulative coverage information for covergroup type g1
option.per_instance = 1;

type_option.comment = “Coverage model for features foo and bar”;

// comment for each instance of this covergroup

option.comment = instComment;

a : coverpoint a_var
{
// Use weight of 2 for computing the coverage of each instance
option.weight = 2;
// Use weight of 3 for computing the cumulative (type) coverage for g1
type_option.weight = 3;
// NOTE: type_option.weight = w would cause syntax error.
}
b : coverpoint b_var;
{
// Use weight of w for computing the coverage of each instance
option.weight = w;
// Use weight of w+5 for computing the cumulative (type) coverage of g1
type_option.weight = w + 5;
}
endgroup

In the above example the coverage for each instance of g1 is computed as:
(((instance coverage of “a”) * 2) + ((instance coverage of “b”) * w)) / ( 2 + w).

On the other hand the coverage for covergroup type “g1” is computed as:
( ((overall type coverage of “a”) * 3) + ((overall type coverage of “b”) * (w+5)) ) / ( 3 + (w+5)).

Type options can be set procedurally at any time during simulation. The syntax is:

5
 coverage_type_option_assignment ::= // Not in Annex A
covergroup_name::type_option.option_name = expression;
| covergroup_name::covergroup_item_identifier::type_option.option_name = expression;

Here is an example:

covergroup gc @(posedge clk) ;

a : coverpoint a_var;
b : coverpoint b_var;
endcovergroup
...
gc::type_option.comment = “Here is a comment for covergroup g1”;
gc::a::type_option.weight = 3; // Set the weight for coverpoint “a” of covergroup g1
gc g1 = new;

The following table summarizes the syntactical level (covergroup, coverpoint, or cross) that type options can
be specified. When set at the covergroup level, the type options do not act as defaults for lower syntactic lev-
els.

Allowed Syntactic Level

Option name
covergroup coverpoint cross
weight Yes Yes Yes
goal Yes Yes Yes
comment Yes Yes Yes

20.7 Predefined coverage tasks and functions

The following coverage methods are provided for the covergroup. These methods can be invoked procdurally
at any time.

Method Can be called on Description

(function) covergroup coverpoint cross
void sample() Yes No No Triggers sampling of the covergroup
real get_coverage() Yes Yes Yes Calculates the coverage number (0…100)
real get_type_coverage() Yes Yes Yes Calculates type coverage number (0…100)
void Yes No No Sets the instance name to the given string
set_inst_name(string)
void start() Yes Yes Yes Starts collecting coverage information
void stop() Yes Yes Yes Stops collecting coverage information
real query() Yes Yes Yes Returns the cumulative coverage informa-
tion (for the coverage group type as a
whole)
real inst_query() Yes Yes Yes Returns the per-instance coverage informa-
tion for this instance

20.8 Predefined coverage system tasks

SystemVerilog provides the following system tasks to help manage coverage data collection.

$set_coverage_db_name( name ) – Sets the filename of the coverage database into which coverage informa-
tion is saved at the end of a simulation run.

6
$load_coverage_db ( name ) – Load from the given filename the cumulative coverage information for all
coverage group types.

$get_coverage() – Returns as a real number in the range 0 to 100 the overall coverage of all coverage group
types. This number is computed as described above.

$get_inst_coverage() – Returns as a real number in the range 0 to 100 the overall per-instance coverage of all
instances of all coverage group. This number is computed as described above.

20.9 Querying coverage at run time

There are two methods that allow querying of coverage information during simulation. These are described in
Section 20.7.

20.10 BNF

coverage_group_decl ::= covergroup covergroup_identifier [ ( list_of_task_proto ) ] [ clocking_event ] ;

{ coverage_spec_or_option ; }
endgroup [ : covergroup_identifier ]

list_of_task_proto ::= task_proto_formal { , task_proto_formal }

coverage_spec_or_option ::=
{attribute_instance} coverage_spec
| {attribute_instance} coverage_option

coverage_option ::=
option.option_name = expression
| type_option.option_name = expression

coverage_spec ::=
cover_point
| cover_cross

variable_decl_assignment ::= // covergroup creation

…
| variable_identifier = new [ ( list_of_arguments ) ]

cover_point ::= [label :] coverpoint expression [ iff (expression) ] bins_or_empty

bins_or_empty ::=
{ { bins_or_options ; } }
|;

bins_or_options ::=
{attribute_instance} coverage_option
| {attribute_instance} bins bin_identifier [[ ]] = range_list [iff (expression) ]
| {attribute_instance} bins bin_identifier [[ ]] = ( trans_list ) [iff (expression) ]
| {attribute_instance} bins bin_identifier [[ ]] default [iff (expression) ]

range_list ::= { value_range { , value_range } }

value_range ::= // from Annex A.8.3

7
 expression
| [ expression : expression ]

bins bin_identifier [[ ]] = ( trans_list ) [iff (expression) ]

trans_list ::= trans_set { , trans_set }

trans_set ::= trans_range_list -> trans_range_list {-> trans_range_list }

trans_range_list ::=
range_list
| range_list [ [* value_range ] ] // consecutive repetition
| range_list [ [*-> value_range ] ] // goto repetition
| range_list [ [*= value_range ] ] // non-consecutive repetition

cover_cross ::= [label:] cross list_of_coverpoints [ iff ( expression ) ] select_bins_or_empty

list_of_coverpoints ::= cross_item , cross_item { , cross_item }

cross_item ::=
cover_point_identifier
| variable_identifier

select_bins_or_empty ::=
{ { bin_selection_or_option ; } }
|;

bin_selection_or_option ::=
{attribute_instance} coverage_option
| {attribute_instance} bins_selection

bins_selection ::= bins bin_identifier = select_expression

select_expression ::=
select_condition
| ! select_condition
| select_expression && select_expression
| select_expression || select_expression
| ( select_expression )

select_condition ::= binsof ( bins_expression ) [. intersect open_range_list ]

bins_expression ::=
variable_indentifier
| cover_point_indentifier [ . bins_indentifier ]

open_range_list ::= { open_value_range { , open_value_range } }

open_value_range ::=
expression
| [ expression : expression ]
| [ expression : $ ]
| [$ : expression ]