[sv-ec] Champion's feedback on 2506

From: Little Scott-B11206 <B11206@freescale.com>
Date: Tue Jun 21 2011 - 13:42:36 PDT

Hi all:

We are looking for some opinions to help clarify some intent in 2506. The first sentence of the following paragraph came up in SV-EC today. It can be found at the top of page 4 in the proposal for 2506 (either v6+friend_amendments or v7).

Identifiers within the coverpoint are restricted to constant expressions (see 11.2.1), instance constants (for an embedded covergroup), or non-ref arguments to the covergroup. Instance constants referenced from a covergroup shall be members of the enclosing class. The initializers for such instance constants shall appear before the referring covergroup constructor call in the class constructor, and shall not appear with the covergroup constructor call in the body of any looping statement (see 12.7) or fork-join_none, either before or after.

It came up in light of Shalom's feedback:

"Identifiers within the coverpoint are restricted to constant expressions
(see 11.2.1), instance constants (...), or non-ref arguments to the covergroup."
I don't understand this. What does "within the coverpoint" mean?
For example, the example contains "coverpoint x;". I would say that "x" is
"within" the coverpoint, but it is a ref argument.

The concern is that as Shalom states "within the coverpoint" isn't clear. A potential rewording of the first sentence based on my thoughts, suggestions from the meeting today, and feedback from Gord would be:

Only constant expressions (see 11.2.1), instance constants (for an embedded covergroup), or non-ref arguments to the covergroup are allowed to be used in the following coverpoint constructs:
  1) with_expression,
  2) select_expression,
  3) open_range_list, or
  4) an expression specifying a fixed number of bins

The following paragraph in 19.5 would be modified as shown:

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, [], shall follow the bin name. To create a fixed number of bins for a set of values, a legal expression that evaluates to a number can be specified inside the square brackets. The open_range_list used to specify the set of values associated with a bin shall be constant expressions (see 11.2.1), instance constants (for classes only), or non-ref arguments to the coverage group. It shall be legal to use the $ primary in an open_value_range of the form [ expression : $ ] or [ $ : expression ].

The intent is that the constructs in these expressions will be sampled at the time of covergroup creation. It is possible that any variable could be sampled and used, but we want this restriction to provide a hint to the user that the coverage space is NOT dynamic. In the meeting, Gord expressed a desire to know from others how the restriction described above might be interpreted/implemented. For example, is a hierarchical reference to a function whose actual arguments are non-ref covergroup arguments legal?

Thanks,
Scott

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jun 21 13:43:04 2011

This archive was generated by hypermail 2.1.8 : Tue Jun 21 2011 - 13:43:13 PDT