RE: [sv-ec] Mantis 2149 - Covergroups sample method with arguments

I have uploaded a new proposal that incorporates David's feedback.

 

            Arturo

 

________________________________

From: David Scott [mailto:david_scott@mentor.com] 
Sent: Thursday, November 15, 2007 3:15 PM
To: Arturo Salz
Cc: SV-EC; sv-ac@eda-stds.org
Subject: Re: [sv-ec] Mantis 2149 - Covergroups sample method with
arguments

 

Another comment with "DCS2:" ... and I agree on the last point.

-- David S

Arturo Salz wrote: 

A few comments in green. As yourself, no response means I concur.

 

            Arturo

 

________________________________

From: David Scott [mailto:david_scott@mentor.com] 
Sent: Wednesday, November 14, 2007 9:51 AM
To: Arturo Salz
Cc: SV-EC; sv-ac@eda-stds.org
Subject: Re: [sv-ec] Mantis 2149 - Covergroups sample method with
arguments

 

A few responses marked with "DCS:" ... no response means in general I
concur.

-- David (Scott)

Arturo Salz wrote: 

Scott,

 

My comments inlined below.

 

            Arturo

 

________________________________

From: David Scott [mailto:david_scott@mentor.com] 
Sent: Friday, November 09, 2007 2:27 PM
To: Arturo Salz
Cc: SV-EC; sv-ac@eda-stds.org
Subject: Re: [sv-ec] Mantis 2149 - Covergroups sample method with
arguments

 

Arturo:

Some reaction from the Mentor covergroup team and Gordon (Dave R and Ray
not represented):

#1.  Syntax.  There was a preference to drop the @, to allow a
declaration like so:

covergroup ct function sample(int x);

The issue is that "@ function" seems like a cue to wait on an event
related to the function, or that it seems somehow related to event-based
sampling.





We're open to syntactical changes.

The reason for the "@ function" syntax was to use an operator to
separate the coverage declaration from the sampling method declaration;
it seems more readable this way. We'd like to hear from other people.


#2.  We'd prefer some re-wording around the first sentence of the last
paragraph.  Maybe something like this:

Within coverpoint and guard expressions, the formal arguments of an
overridden sample method shall be searched after other covergroup items
but before the scope enclosing the covergroup.

("Other covergroup items" might be the option or type_option members,
though not coverpoints and crosses according to Mantis 1279.)





I'm not sure this is better. The more complex verbiage does not appear
to solve any issue.

How does the limitation to coverpoint and guard expressions needed?


DCS: I was trying to suggest a re-wording in line with this comment from
Gordon:

The sentence:
   The formal arguments of an overridden sample method shall be searched
   before the enclosing scope
needs to be clarified -- I assume that this means that *within*
the covergroup, the formals for "sample" are visible and shall
match *after* other covergroup items but before the scope
enclosing the covergroup. 

But, what does "*after* other covergroup items" mean? The only "items"
local to the covergroup are labels (bins, cross) and the option and
type_option built-in identifiers. Is that what you are referring? And,
if so, why do we not need such a clause for the covergroup formals?


DCS2: Well, now I'm thinking maybe my original suggestion is not
necessary.  I was referring to the "option" and "type_option"
structures; the coverpoint/cross names were described in Mantis 1279
written up by Ray last year, and bin names apply only in cross bin
select expressions.

If the "option" and "type_option" structures are treated as implicitly
declared (as is reasonable according to 18.10), then one can conclude
from existing rules that this is illegal:

covergroup cg function sample(int option); // bad: conflicts with
implicitly declared "option" structure
    coverpoint option;
endgroup

And this is legal, though admittedly strange:

covergroup cg function sample(int i);
    coverpoint i + option.weight; // OK: refers to implicitly declared
"option" structure
endgroup

The "option" and "type_option" structures are in the same scope as the
covergroup and overridden sample formals; since Mantis 1279 was resolved
I don't think we have any further ambiguity.




	
	#3.  "error to use a sample argument" should read "error to use
a sample formal".
	
	
	
	

	OK.

	
	#4.  The last example needs a "ref" added in the covergroup
arguments, like so: "covergroup C1 (ref int v)".
	
	
	
	

	No. That's the whole point of the example.

	Users may think that it's OK to use the "v" covergroup argument
by the constructor (to set the weight option) and the "v" sample formal
by the definition of the coverpoint., The rule is intended to avoid this
ambiguity.


DCS: In your example "v" was a coverpoint expression.  If someone were
to write it passing "v" into the constructor, they would write it as
"ref int v".  You are passing "b" -- assigned to weight -- through the
sample method, a different illegality.




You're right. I forgot to add to the example, it should have read:

covergroup C1 (int v) @ function sample (int v, bit b);    // error (v)

   coverpoint v;

   option.per_instane = b;  // error: b may only designate a coverpoint

   option.weight = v;       // error: v is ambiguous

endgroup

 

 


#5.  Just for people to consider, we are expecting the following to be
legal (with our preferred syntax)?

int a;
covergroup ct (ref int b) function sample(int c);
    coverpoint a + b + c;
endgroup

 

Yes. We agree. Awkward, but legal nonetheless.

 

#6.  A host of issues around sample arguments.  One thing that occurred
to us -- without, I'll note, Gordon's blessing! -- is that we could
possibly allow this:

int a;
covergroup ct function sample(ref int x = a);
    coverpoint a;

This would allow event-based sampling to occur as well as procedural
sampling, let's say with this syntax (which I know would be a change
from the proposal):

covergroup ct function sample(ref int x = a) @(e);

With event-based sampling, the default arguments would be used, which as
you see cause "a" from the enclosing scope to be sampled.  It wasn't
clear from Mike's original e-mail whether the override was expected to
be optional (used occasionally) or required (used always).





I am very uncomfortable with this change. The current proposal makes it
clear that there are two mutually exclusive ways to trigger a
covergroup: via an events (or block event) or procedurally through the
sample method. Otherwise, there are other issues like "strobe" sampling
that rear their ugly head.


DCS: I'm OK disallowing what I suggested; it does make it simpler to
disallow it.  I'll comment on "strobe" later in the thread, though.






If default arguments are used, what restrictions are there?  Can they be
covergroup formals, like this?

covergroup ct (ref int a) function sample(ref int x = a);

 

Good point. I would say no. Covergroup formals should not be visible in
the scope of default arguments.

 

Can they be non-static class properties for an embedded covergroup?





Yes. Any reason to disallow them?


What about "output" arguments?  While this sounds nonsensical, someone
might find a use for something like this:

function int f(output o, input i);
    o = 2*i;
    return o;
endfunction

covergroup ct function sample(output o, input i);
    coverpoint f(o,i);
endgroup

 

As you say, "output" arguments are nonsensical. Do we need an explicit
error rule? Is there any plausible expectation on the part of users?


DCS: I have no idea whether users would expect this or not -- users
frequently surprise me -- but an explicit sample arguments list opens up
the possibility.  We need language in the proposal to disallow what we
believe makes no sense.

I'm OK with such a restriction. But, shouldn't we add the same for
covergroup formals (it also makes no sense there).

 

 

Finally, what about a null argument list to sample?  That sounds to me
like it should be disallowed.





The current BNF allows it and I see no problem for an overridden method
to have the same signature as the default method. In a way the proposal
is saying that omitting the coverage_event is the same as an explicit
"covergroup <name> @ function sample();"



-- David Scott, Mentor Graphics


Arturo Salz wrote: 

I've uploaded a proposal for Mantis 2149. Please review.
 
        Arturo
 
-----Original Message-----
From: owner-sv-ec@eda.org On Behalf Of Michael Burns
Sent: Wednesday, October 24, 2007 4:38 PM
To: SV_EC List
Cc: John Havlicek
Subject: [sv-ec] Mantis 2149 - Covergroups sample method with arguments
 
 
Mantis 2149 - Covergroups sample method with arguments has been
submitted 
describing what we'd like to see in a solution for the covergroup sample
issue I 
raised a week or two ago.
 
--Mike Burns
 
 
  

 

 

 


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