RE: [sv-ec] Query Regarding Coverpoints

In this case, at least the coverpoint is referring to a variable with
the same name. That maybe could be considered similar to a function
declaration, where the function name refers both to the function itself
and to the function return value. Those two meanings are tightly coupled
and indivisible.
 
But take part of the example from the text of 1279:
 
covergroup cg ( ref int x , ref int y, input int c); 

    coverpoint x;         // creates coverpoint "x" covering the formal
"x"

    x: coverpoint x;      // INVALID: coverpoint label "x" already exits

    b: coverpoint y;      // creates coverpoint "b" covering the formal
"y"

    c: coverpoint x;      // creates coverpoint "c" covering the formal
"x"

Here you have two completely different c's defined with the covergroup:
the coverpoint and the formal argument, with no connection between them.
I understand that visibility rules may make unambiguous in every context
which c can be referred to, but it is really confusing.

Even in classic Verilog, there are a few cases where the same name may
be referred to from the same module with different meanings. For
example, you can define a variable name which is the same as the name of
some module. In a module instantiation, it refers to the module. In most
other cases, it refers to the variable. Those two names are defined with
different name spaces, however.

But I don't remember a case where Verilog allows the same name to be
defined twice in the same name space with completely different meanings.
I think it is bad language design. Isn't the language complex enough
already?

 

Shalom

 

 

________________________________

	From: owner-sv-ec@server.eda.org
[mailto:owner-sv-ec@server.eda.org] On Behalf Of Surya Pratik Saha
	Sent: Wednesday, July 18, 2007 7:16 AM
	To: David Scott
	Cc: Sandeep Dasgupta; SV-EC
	Subject: Re: [sv-ec] Query Regarding Coverpoints
	
	
	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>
<mailto:david_scott@mentor.com> 
	To: Sandeep Dasgupta <sandeep@cal.interrasystems.com>
<mailto:sandeep@cal.interrasystems.com> 
	Cc: SV-EC <sv-ec@eda-stds.org> <mailto: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 <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.