Re: [sv-ec] Confusion over covergroup instantiation inside class

Hi Surya,

Mantis 1239 added the following line:

   "An embedded covergroup variable may only be assigned in the new method."

Neil



On 10/30/08 07:23, Brad Pierce wrote:
> Surya,
> 
>  
> 
> The footnote was deleted by
> 
>  
> 
>        http://www.eda.org/svdb/view.php?id=1239
> 
>  
> 
> You may also be interested in
> 
>  
> 
>         http://www.eda.org/svdb/view.php?id=1279
> 
>  
> 
> -- Brad
> 
>  
> 
>  
> 
> *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of 
> *Bresticker, Shalom
> *Sent:* Thursday, October 30, 2008 2:49 AM
> *To:* Surya Pratik Saha; sv-ec@eda.org
> *Subject:* RE: [sv-ec] Confusion over covergroup instantiation inside class
> 
>  
> 
> Hi,
> 
>  
> 
> The Draft 7a LRM says,
> 
> "A *covergroup *declaration within a class is an /embedded covergroup 
> /declaration. An embedded *covergroup *declaration declares an anonymous 
> *covergroup *type and an instance variable of the anonymous type. The 
> /covergroup_identifier /defines the name of the instance variable."
> 
> and
> 
> "An embedded covergroup variable may only be assigned in the new method. 
> An embedded coverage group can be explicitly instantiated in the *new 
> *method. If it is not, then the coverage group is not created and no 
> data will be sampled."
> 
> So the following would work:
> 
>  
> 
> module top;
> class myclass;
>   covergroup my_cg;
>   endgroup : my_cg
> function new();  my_cg = new; endfunction
> endclass
> endmodule
> 
>  
> 
> The footnote you quoted has been deleted.
> 
>  
> 
> I'm sure others can give you fuller explanations, as I don't understand 
> this too well yet.
> 
>  
> 
> Please don't cc: sv-bc on such issues.
> 
>  
> 
> Shalom
> 
>  
> 
>     ------------------------------------------------------------------------
> 
>     *From:* owner-sv-ec@server.eda.org
>     [mailto:owner-sv-ec@server.eda.org] *On Behalf Of *Surya Pratik Saha
>     *Sent:* Thursday, October 30, 2008 11:28 AM
>     *To:* sv-bc@server.eda.org; sv-ec@server.eda.org
>     *Subject:* [sv-ec] Confusion over covergroup instantiation inside class
> 
>     Hi,
>     In the LRM section "18.3 Using covergroup in classes" it is
>     mentioned a covergroup can be instantiated explicitly. But the
>     following case:
> 
>     module top;
>     class myclass;
>       covergroup my_cg;
>       endgroup : my_cg
>       my_cg x = new();
>     endclass
>     endmodule
> 
>     is failed by most of the standard simulators. Is there any reason
>     for that.
>     Also in all the examples given in that section, the instantiation of
>     covergroup without declaring the identifier is used only inside
>     function new. But in the foot note 15, it is mentioned:
> 
>     *"It shall be legal to omit the covergroup_variable_identifier from
>     a covergroup instantiation only if this implicit instantiation is
>     within a class that has no other instantiation of the covergroup."
>     *
>     Does that signify, covergroup can be instantiated outside the
>     function new too? What about the case:
>     module top;
>     class myclass;
>       covergroup my_cg; 
>       endgroup : my_cg
>       my_cg  = new();
>     endclass
>     endmodule
> 
>     which except one, all the standard simulator fail.
> 
>     -- 
> 
>     Regards
> 
>     Surya
> 
> 
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean.
> 
> ---------------------------------------------------------------------
> 
> Intel Israel (74) Limited
> 
>  
> 
> This e-mail and any attachments may contain confidential material for
> 
> the sole use of the intended recipient(s). Any review or distribution
> 
> by others is strictly prohibited. If you are not the intended
> 
> recipient, please contact the sender and delete all copies.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> ------------------------------------------------------------------------
> 
> Section 18.3 Using covergroup in classes
> 
> 
> REPLACE
> 
>  
> 
> When a covergroup is defined within a class and no explicit variables of 
> that covergroup are declared in the class, then a variable with the same 
> name as the coverage group is implicitly declared, e.g, in the above 
> example, a variable cov1 (of the embedded coverage group) is implicitly 
> declared. Whether the coverage group variable is implicitly or 
> explicitly declared, each class contains exactly one variable of each 
> embedded coverage group. Each embedded coverage group thus becomes part 
> of the class, tightly binding the class properties to the coverage 
> definition. Declaring multiple variables of the same embedded coverage 
> group shall result in a compiler error.
> 
> WITH
> 
> A *covergroup* declaration within a class is an embedded *covergroup* 
> declaration. An embedded *covergroup* declaration declares an anonymous 
> *covergroup* type and an instance variable of the anonymous type. The 
> covergroup_identifier defines the name of the instance variable. In the 
> above example, a variable cov1 (of the anonymous coverage group) is 
> implicitly declared.
> 
>  
> 
>  
> 
> UPDATE
> 
> An embedded covergroup variable may only be assigned in the *new* 
> method. An embedded coverage group must can be explicitly instantiated 
> in the *new *method. If it is not, then the coverage group is not 
> created and no data will be sampled.
> 
>  
> 
>  
> 
>  
> 
> Section 18.2  - /Syntax 18-1—Covergroup syntax/
> 
> DELETE
> 
> variable_decl_assignment ::=
> 
> ...
> 
> | [ covergroup_variable_identifier ] = new [ ( list_of_arguments ) ]15
> 
>  
> 
> DELETE note 15
> 
>  
> 
> 15. It shall be legal to omit the covergroup_variable_identifier from a 
> covergroup instantiation is within a class that has no other 
> instantiation of the covergroup.
> 
>  
> 
> Annex A.2.4 Declaration assignments
> 
> MODIFY
> 
> variable_decl_assignment ::=
> 
> variable_identifier { variable_dimension } [ *= *expression ]
> 
> | dynamic_array_variable_identifier *[ ] *[ *= *dynamic_array_new ]
> 
> | class_variable_identifier [ *= *class_new ]
> 
> | [ covergroup_variable_identifier ] = new [ ( list_of_arguments ) ]15
> 
>  
> 
> Annex A.10 Footnotes (normative)
> 
> DELETE
> 
> 15) It shall be legal to omit the covergroup_variable_identifier from a 
> covergroup instantiation only if this implicit instantiation is within a 
> class that has no other instantiation of the covergroup.
> 
>  
> 
>  
> 
>  
> 
> / /
> 
>  
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> 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 contexts:
> 
> ·         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 operand of the scope resolution 
> operator refers to a *covergroup. *For example, “covtype :: cp :: 
> type_option.weight”
> 
>  
> 
> For example:
> 
>  
> 
>   *covergroup* cg ( *ref* *int* x , *ref* *int* y, *input* *int* c);
> 
>  
> 
>     *coverpoint* x;         // creates coverpoint “x” covering the 
> formal “x”
> 
> *    *x*: coverpoint *x*;*      // INVALID: coverpoint label “x” already 
> exits
> 
> *    *b*: coverpoint *y*;*      // creates coverpoint “b” covering the 
> formal “y”
> 
>  
> 
>     c: *coverpoint* x;      // creates coverpoint “c” covering the 
> formal “x”
> 
>  
> 
>     option.weight = c;    // set weight of “cg” to value of formal “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, y {          // Creates implicit coverpoint “y” covering
> 
>                           // the formal “y”. Then creates a cross of
> 
> *                          *// coverpoints “x”, “y”
> 
>       option.weight = c;  // set weight of cross to value of formal “c”
> 
>     }
> 
>     b: *cross* y, x;        // INVALID: coverpoint label “b” already exists
> 
>  
> 
>   *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 contexts:
> 
> ·         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 operand 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 REPLACE
> 
> 
> Identifiers on the left side of the class scope resolution operator :: 
> can be class names or package names (see 19.2).
> 
>  
> 
> WITH
> 
>  
> 
> The left operand of the scope resolution operator ::shall be a class 
> name, package name (see 19.2),  *covergroup* type name, *coverpoint* 
> name or *cross* name (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
> 
>  
> 
> coverage_option_assignment 
> ::=                                                                                                      
> // not in Annex A
> 
> instance_name.option.option_name = expression ;
> 
> | instance_name.covergroup_item_identifier.option.option_name = expression ;
> 
>  
> 
> 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
> 
>  
> 
> coverage_type_option_assignment ::=
> 
>   covergroup_name::type_option.option_name = expression ;
> 
> | covergroup_name::covergroup_item_identifier::type_option.option_name = 
> expression ;
> 
>  
> 
> 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.
> 
>  
> 
>  
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.