[sv-ec] RE: Champion's feedback on 2506

Hi all:

I haven't seen any response to this message on the reflector. I did get a few positive comments on the changes off reflector. Swapnajit was fine with the change, but his expectation/hope is that the committee will address this long-standing issue.

Swapnajit states: "It is taking a dubious stand by intending on one hand that any expression can be used as long as we use the construction time value and also saying on the other hand that only legal expressions (i.e. const expr etc) can be used. I believe such dichotomy will result in more confusion from the user side in future. The text of LRM should exactly convey the meaning which experts believe is correct. And I believe that all experts are unanimous about the fact that construction time value of any generic expression can be used. There is no point carrying on this old restriction into future versions of the doc."

Swapnajit points to the thread at http://www.eda.org/sv-ec/hm/7480.html to support the idea that the intention that any expression is legal as long as it sampled properly. My understanding from the recent SV-EC meeting is that while it would be possible to allow any expression folks were in favor of limiting the expressions to ease the coverage merging problem and help users remember that the coverage space is static. The comments on mantis 1802 seem to support this idea.

I would favor making this change to 2506 (assuming it satisfies Shalom) and then look at resolving 1802. What do other folks think?

Thanks,
Scott

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Little Scott-B11206
Sent: Tuesday, June 21, 2011 3:43 PM
To: sv-ec@eda.org
Cc: Bresticker, Shalom
Subject: [sv-ec] Champion's feedback on 2506

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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.