Section 18 Coverage
In 18.4 ADD (following the paragraph)
A coverage point creates a hierarchical scope and can be optionally labeled. If the label is specified, then it designates the name of the coverage point. This name can 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 variable, then the variable name becomes the name of the coverage point. Otherwise, an implementation can generate a name for the coverage point only for the purposes of coverage reporting, that is, generated names cannot be used within the language.
A coverpoint name has limited visibility. An identifier can only refer to a coverpoint in the following context:
· In the coverpoint list of a cross declaration (see 18.5),
· In a hierarchical name where the prefix specifies the name of a covergroup variable. For example, “cov1.cp.option.weight” where ‘cov1’ is the name of a covergroup variable and ‘cp’ is the name of a coverpoint declared within the covergroup.
· Following ‘::’ where the left side of the scope resolution operator refers to a covergroup. For example, “covtype :: cp :: type_option.weight”
For example:
covergroup cg ( ref int x , input int c);
coverpoint x; // creates coverpoint “x” covering the formal “x”
c: coverpoint x { // creates coverpoint “c” covering the formal “x”
option.weight = c; // set weight of “cg” to value of parameter “c”
d: coverpoint x {
option.weight = 2; // set the weight of coverpoint “d”
}
d.option.weight = 2; // invalid use of “d”, also syntax error
cross x, c { // create a cross of coverpoints “x”, “c”
option.weight = c; // set weight of cross to value of parameter “c”
}
endgroup
In 18.5 ADD (following the paragraph)
The label for a cross declaration provides an optional name. The label also creates a hierarchical scope for the bins defined within the cross.
A cross name has limited visibility. An identifier can only refer to a cross in the following context:
· In a hierarchical name where the prefix specifies the name of a covergroup variable. For example, “cov1.crs.option.weight” where ‘cov1’ is the name of a covergroup variable and ‘crs’ is the name of a cross declared within the covergroup.
· Following ‘::’ where the left side of the scope resolution operator refers to a covergroup. For example, “covtype :: crs :: type_option.weight”.
In 18.2 ADD (to the end of the paragraph)
A covergroup can specify an optional list of arguments. When the covergroup specifies a list of formal arguments, 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. A ref argument allows a different variable to be sampled by each instance of a covergroup. Input arguments will not track value of their arguments; they will use the value passed to the new operator. The formal arguments of a covergoup can not be accessed using a hierarchical name (the formals cannot be accessed outside the covergroup declaration).
In 7.21 MODIFY
Identifiers on the left side of the class scope resolution operator :: can be class names, or package names (see 19.2), covergroup type names, coverpoint names or cross names (see 18.4, 18.5).
In Syntax 18-4 of 18.5 and in A.2.11 REPLACE
[ cover_point_identifier : ] cross list_of_coverpoints [ iff ( expression ) ] select_bins_or_empty
WITH
[ cross_identifier : ] cross list_of_coverpoints [ iff ( expression ) ] select_bins_or_empty
In A.9.3 ADD
cross_identifier ::= identifier
In 18.6 MODIFY
The identifier option is a built-in member of any coverage group every covergroup, coverpoint and cross (see 18.9 for a description).
In 18.6.1 MODIFY
The identifier type_option is a built-in, static member of any coverage group every covergroup, coverpoint and cross (see 18.9 for a description).
In 18.9 (first paragraph) MODIFY
The type and type_option option and type_option members of a covergroup, coverpoint, and cross are implicitly declared structures with the following composition:
In 18.6 MODIFY
Option assignment statements in the covergroup definition are evaluated at the time that the covergroup is instantiated. The per_instance option can only be set in the covergroup definition. Other instance specific options can be set assigned procedurally after a covergroup has been instantiated. The syntax is as follows:
In 18.6 DELETE Syntax 18-5
Syntax 18-5—Coverage option assignment syntax (not in Annex A)
In 18.6.1 MODIFY
The strobe type option can only be set in the covergroup definition. Other type options can be set assigned procedurally at any time during simulation. The syntax is as follows:
In 18.6.1 DELETE Syntax 18-6
Syntax 18-6—Coverage type option assignment syntax (not in Annex A)
In A.2.11 and 18.2 Syntax 18-1 REPLACE
| type_option.member_identifier = expression
WITH
| type_option.member_identifier = constant_expression
In 18.2 MODIFY
A covergroup can contain one or more coverage points. A coverage point can be cover a variable or an expression. Each coverage point includes a set of bins a …
In 18.3 MODIFY
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 be used in coverpoint expressions or can be used in other coverage constructs, such as conditional guards or option initialization.
In 18.4 MODIFY
A covergroup can contain one or more coverage points. A coverage point can be an integral variable or specifies an integral expression that is to be covered. Each coverage point includes a set of bins associated with it’s the sampled values or its value transitions of the covered expression. The bins can be explicitly defined by the user or automatically created by SystemVerilog. The syntax for specifying coverage points is given below.