Re: [sv-ec] Query Regarding Coverpoints

What is special in a covergroup is that the LRM uses specific language 
to describe when a given object inside a covergroup is visible.

For example, in "coverpoint x" the "x" refers to a constructor argument 
or an object in enclosing scope.  In "cross x, y", the very same name 
"x" in the very same covergroup refers to the coverpoint "x" previously 
created.

These name visibility rules don't generalize; they are specific to 
covergroups.

Dave


Surya Pratik Saha wrote:
> 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.