Re: [sv-ec] Query Regarding Coverpoints

Hi David,
I don't completely agree with your comment on "ra: coverpoint ra". If 
something labeled item is declared inside a module or any other scope 
with same name item, it is a conflicting issue. All tools fail for that. 
What is special in covergroup then?

Regards
Surya



-------- Original Message  --------
Subject: Re:[sv-ec] Query Regarding Coverpoints
From: David Scott <david_scott@mentor.com>
To: Surya Pratik Saha <spsaha@cal.interrasystems.com>
Cc: Sandeep Dasgupta <sandeep@cal.interrasystems.com>, SV-EC 
<sv-ec@eda-stds.org>
Date: Thursday, July 19, 2007 1:45:31 AM
> I think the current LRM is still unambiguous.  Again, I recommend 
> reading 2008 Draft 3a for clarifications on this matter, because it 
> was one of the most serious issues fixed against 2005.
>
> If the covergroup is an "embedded covergroup", i.e., declared in class 
> scope, then "covergroup gc" declares a variable "gc" of anonymous 
> type.  Then "gc.ra" is a hierarchical path including a covergroup 
> variable, and so "ra" is the coverpoint; you could use "gc.ra.stop()", 
> for example.  There is an explicit statement somewhere in the LRM that 
> the constructor argument is /never /accessible outside the 
> covergroup.  (One of the things this LRM language implies is that 
> visibility rules are essentially different inside and outside the 
> covergroup scope.)
>
> If the covergroup is declared in a module (or program or other) scope, 
> then "gc" refers to a covergroup type, and "gc.ra" would be illegal; 
> "gc::ra" would be legal, however, and allow access to static data and 
> methods, as in "gc::ra::get_coverage()".
>
> As for "ra: coverpoint ra" conflicting, I don't think it does, as that 
> simply describes explicitly what happens implicitly: that coverpoints 
> of a simple variable get named according to the variable name; the 
> leftmost "ra" is a label that does not need to refer to anything but 
> creates the name by which the coverpoint is subsequently referred, 
> while the rightmost "ra" refers to the constructor argument.
>
> Dave
>
>
> Surya Pratik Saha wrote:
>> Hi David,
>> Then for the e.g. provided by Sandeep, if the hierarchical reference 
>> is like "gc.ra", then what it will point to? It is really confusing. 
>> LRM has to clarify clearly the name resolution rule for coverpoint 
>> variable. Also as per LRM text, the following two snippet are same:
>>
>> *covergroup gc (ref int ra, int low, int high ) @(posedge clk);
>> coverpoint ra // sample variable passed by reference
>> {
>> bins good = { [low : high] };
>> bins bad[] = default;
>> }
>> endgroup *
>>
>> and
>> *covergroup gc (ref int ra, int low, int high ) @(posedge clk);
>> ra: coverpoint ra // labeled by ra
>> {
>> bins good = { [low : high] };
>> bins bad[] = default;
>> }
>> endgroup
>>
>> *Does the later labeled declaration not conflict with 'ref int ra'? 
>> What do you think. Different simulators behave differently for that.
>> Regards
>> Surya
>>   
>>
>>
>> -------- Original Message  --------
>> Subject: Re:[sv-ec] Query Regarding Coverpoints
>> From: David Scott <david_scott@mentor.com>
>> To: Sandeep Dasgupta <sandeep@cal.interrasystems.com>
>> Cc: SV-EC <sv-ec@eda-stds.org>
>> Date: Wednesday, July 18, 2007 3:21:45 AM
>>> Sandeep --
>>>
>>> This was clarified in the 2008 version of the specification. The 
>>> latest 2008 draft is now available for purchase through the IEEE, I 
>>> believe; if you don't have it, I highly recommend it.
>>>
>>> Whether or not you consider that the covergroup has "two different 
>>> objects of the same name", the rules for visibility have been 
>>> clarified so that only one type of object is visible in a given 
>>> context. To quote:
>>>
>>>> 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.6),
>>>> — 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.
>>>
>>> In other contexts -- which includes at least option assignments 
>>> within the covergroup, the coverpoint declaration itself, and of 
>>> course bin declarations (though not in the case of a ref argument 
>>> like "ra") -- the name could not refer to the coverpoint.
>>>
>>> By the way, I have just realized that "binsof" expressions should be 
>>> added to the list above for coverpoint name visibility.
>>>
>>> Anyway, with this rule, it is unambiguous what "ra" means in a given 
>>> context.
>>>
>>> -- Dave Scott, Mentor Graphics
>>>
>>>
>>> Sandeep Dasgupta wrote:
>>>> Hi,
>>>>
>>>> I have the following query regarding coverpoints,
>>>>
>>>> Consider the test case as is given in IEEE Std 1800-2005, section 
>>>> 18.4,
>>>> covergroup gc (ref int ra, int low, int high ) @(posedge clk);
>>>> coverpoint ra // sample variable passed by reference
>>>> {
>>>> bins good = { [low : high] };
>>>> bins bad[] = default;
>>>> }
>>>> endgroup
>>>>
>>>> Now as per section 18.4 "Defining coverage points",
>>>> 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.
>>>>
>>>> So as per the above specification, the coverpoint used in the 
>>>> example above should be labeled with
>>>> the name of the single variable associated with the coverpoint, 
>>>> i.e. ra.
>>>> Also the covergroup gc contain a variable with the same name, ref 
>>>> int ra.
>>>> So is it possible for a scope (in this case a covergroup scope) to 
>>>> have two objects with same name(in this case ra )?
>>>> Please give your suggestions.
>>>>
>>>>
>>>> Thanks and Regards,
>>>> Sandeep Dasgupta.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>





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