Re: [sv-ec] Query Regarding Coverpoints

Hi David,

A new mantis item would need to be opened. I suggest that you
go ahead and open a mantis item if you feel that a clarification
would be useful.


Neil



David Scott wrote On 07/17/07 14:59,:
> SV-EC members,
> 
> I think Ray's Mantis 1279 -- approved long ago, I know -- missed a 
> context in which an identifier can refer to a coverpoint.  See the 
> quotation below from 18.5 in my response to Sandeep Dasgupta.
> 
> That list needs to include "binsof" expressions (in the cross bin 
> declaration syntax, the "bins_expression" production), as clearly those 
> can refer to a coverpoint.
> 
> Do we require that this list be complete?  It seems to me yes.
> 
> If you'd like me to file another Mantis, please let me know.  Presumably 
> we'd leave 1279 alone and file a new one?
> 
> Dave S
> 
> 
> David Scott wrote:
> 
>>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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-276-6385
Frontend Technologies (FTAP)                      Fax: 408-276-5092
Sun Microsystems                       email: neil.korpusik@sun.com
---------------------------------------------------------------------



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