RE: [sv-cc] FW: [sv-bc] Ref args

I think Dave is right.  A ref arg is not the same thing as a VPI ref
obj.
A VPI ref obj sometimes represents a ref arg, and sometimes does not.
 
While a named event may fall into the category of "variable" at the
HDL level, they are distinct in the VPI object model, so I think the
existing text is OK on that matter.
 
Francoise has already told us that the object model for ref objs needs
work in general, and perhaps we should look at virtual interfaces as
part of that.
 
Regards,
Jim Vellenga

---------------------------------------------------------
James H. Vellenga                            978-262-6381
Software Architect                              (FAX) 978-262-6636
Cadence Design Systems, Inc.         vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
---------------------------------------------------------- 

 


________________________________

	From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf
Of Bresticker, Shalom
	Sent: Friday, April 04, 2008 2:32 AM
	To: SV-CC
	Subject: [sv-cc] FW: [sv-bc] Ref args
	
	
	fyi

________________________________

	From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Rich, Dave
	Sent: Thursday, April 03, 2008 6:18 PM
	To: Bresticker, Shalom; sv-bc@server.eda.org;
sv-ec@server.eda.org
	Subject: RE: [sv-bc] Ref args
	
	

	Shalom,

	 

	I don't think this is a conflict. This is just describing ways
one would obtain a ref object. I do see two little nits: named events
are variables, and virtual interface declarations can appear outside of
classes.

	 

	A ref argument also includes constructors of covergroups, which
may indeed be considered a built-in function. Mantis 1575, which has no
proposal yet, would like the restrictions for const ref to be relaxed
and not require a strict lvalue.

	 

	Dave

	 

	 

	
________________________________


	From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
	Sent: Thursday, April 03, 2008 4:44 AM
	To: sv-bc@server.eda.org; sv-ec@server.eda.org
	Subject: [sv-bc] Ref args

	 

	I just noticed that 36.14 in Draft 4 has the following:

	Details:

	1) A ref obj represents a declared object or sub-element of that
object that is a reference to an actual instantiated object. A ref obj
exists for ports with ref direction, for an interface port, a modport
port, or for formal task function ref arguments. The specific cases for
a ref obj are:

	- A variable, named event, named event array that is the lowconn
of a ref port

	- Any subelement expression of the above

	- A local declaration of an interface or modport passed through
a port or any net, variable, named event, named event array of those

	- A virtual interface declaration in a class definition

	- A ref formal argument of a task or function, or sub-element
expression of it

	A ref obj may be obtained when walking port connections
(lowConn, highConn), when traversing an expression that is a use of such
ref obj, when accessing the virtual interface of a class, or when
accessing the io decl of an instance or task or function."

	Is there any conflict with the text of Mantis 2235? 

	Thanks,

	Shalom

		 

		Mantis 2235 adds to 13.5.2, 
		"Only the following shall be legal to pass by reference:


		* a variable 

		* a member select of a class property or a member of an
unpacked structure 

		* a non-slice indexed select of an unpacked array. 

		Nets and selects into nets shall not be passed by
reference. "

		 

	
---------------------------------------------------------------------
	Intel Israel (74) Limited
	 
	This e-mail and any attachments may contain confidential
material for
	the sole use of the intended recipient(s). Any review or
distribution
	by others is strictly prohibited. If you are not the intended
	recipient, please contact the sender and delete all copies.

	-- 
	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 <http://www.mailscanner.info/>
, and is 
	believed to be clean. 
	
---------------------------------------------------------------------
	Intel Israel (74) Limited
	
	This e-mail and any attachments may contain confidential
material for
	the sole use of the intended recipient(s). Any review or
distribution
	by others is strictly prohibited. If you are not the intended
	recipient, please contact the sender and delete all copies.

	-- 
	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.