RE: [sv-cc] ref obj: more clarifications and issues

I noticed that 19.12.1 defines the meaning of a ref
port in the following way:

"A ref port shall be connected to an equivalent variable
data type. References to the port variable shall be
treated as hierarchal references to the variable it
is connected to in its instantiation."

With this in mind, it seems as if VPI ought to treat
a ref port in the same way that it treats an
out-of-module reference -- what the 1364 standard
calls a hierarchical name reference.  As near as I
can make out, whenever VPI traverses a structure
or expression and comes across something that appears
as a hierarchical name reference in the source text,
VPI returns the object referred to rather than
something special representing the reference.  Is
that correct?

Regards,
Jim Vellenga

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

] -----Original Message-----
] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
] Behalf Of Francoise Martinolle
] Sent: Monday, April 11, 2005 9:45 AM
] To: 'Warmke, Doug'; Francoise Martinolle; sv-cc@eda.org
] Subject: RE: [sv-cc] ref obj: more clarifications and issues
] 
] If we were modeling every expression of a ref obj as a ref 
] obj we would need to add the following relationships:
]   iteration on bits: vpiBit
]   iteration on indices: vpiIndex
]   iteration on var selects: vpiVarSelect
]   iteration on members of a struct/union ref object: 
] vpiMemberObj ( I think it was changed to memberObj from 
] another errata)
]   iteration on drivers and loades: vpiDriver, vpiLoad
]   iteration on variables, events, parameters, methods to 
] access the variables, events, parameters, methods
]                          of a class obj which is a ref obj: 
] vpiVariables, vpiNamedEvent, vpiParameter, vpiMethods
]  
]   one to one relationship for accessing the right and left 
] range of a ref obj which is a part select
]  
]   We may also want to add properties such as:
]     vpiArrayMember
]     vpiStructUnionMember
]     vpiScalar
]     vpiVector
]     vpiSize
]     vpi_get_value
]     vpi_put_value
]  
]  
] This is what I think is missing and it could be more missing. 
] I would need to spend more time
] researching what is missing.
]  
] Francoise
]        '
] 
] 
] ________________________________
] 
] 	From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] 
] On Behalf Of Warmke, Doug
] 	Sent: Sunday, April 10, 2005 10:48 AM
] 	To: Francoise Martinolle; sv-cc@eda.org
] 	Subject: RE: [sv-cc] ref obj: more clarifications and issues
] 	
] 	
] 	Francoise,
] 	 
] 	My first instinct is to model these portions of ref 
] parent objects as ref.
] 	The main reason is that if we model them as normal 
] variables, then it would
] 	be cumbersome to determine if the selected object is a 
] ref or not.
] 	A vpi programmer would always have to inspect upwards 
] towards a parent
] 	object until it could be fully determined that there is 
] no ref in the upward
] 	object chain.  (Imagine a complex object with nested 
] structs, unions, arrays,
] 	and a select made to a deep child in there).
] 	 
] 	What relationships do you think would be missing if 
] these were modeled as ref?
] 	 
] 	Thanks,
] 	Doug
] 	 
] 
] 
] ________________________________
] 
] 		From: owner-sv-cc@eda.org 
] [mailto:owner-sv-cc@eda.org] On Behalf Of Francoise Martinolle
] 		Sent: Friday, April 08, 2005 5:54 PM
] 		To: sv-cc@eda.org
] 		Subject: [sv-cc] ref obj: more clarifications and issues
] 		
] 		
] 		I uploaded an update for the ref obj diagram, 
] however I still think that there are some 
] 		clarifications or issues with the access to ref obj.
] 		The access depicted by this diagram seems to 
] only support ref obj which represent the entire net/variable.
] 		However we could have an expression which is a 
] bit select of a net, a member select of a variable and the variable
] 		or net are passed by reference.
] 		 
] 		Consider the following example:
] 		ex:
] 		typedef struct { logic [1:0] m1; real m2 
] [2:0];} struct_t;
] 		 
] 		module m (ref struct_t v);
] 		 
] 		 initial begin
] 		     v.m1 = 2'b0;      ??
] 		     v.m1[1:0] = 2'b0;    ??
] 		     v.m1[0] = 1'b0;       ??
] 		     v.m2 = '{0.0. 1.0, 2.0};    ??
] 		     v.m2[2] = 3.0;     ??
] 		 end
] 		endmodule
] 		 
] 		v is a ref obj but what is v.m1? 
] 		If v was not passed by reference, v.m1 would be 
] a logic var.
] 		But because v is passed by reference and v is a 
] ref obj, does it make it a ref obj?
] 		 
] 		Same question for v.m2. v.m2 would be an array 
] var if v was not passed by reference.
] 		 
] 		If v.m2 is a ref obj, what is its name and 
] vpiActual returns?
] 		 
] 		I am also wondering what does the vpiParent 
] relationship does? Is it used for the purpose of walking from
] 		a sub ref obj to its parent ref obj (for 
] instance from a var select ref obj to the array 
] 		var ref obj like in the case of v.m2[2]?)
] 		 
] 		If we model all these uses as ref obj, I think 
] that we are missing a few relationships and properties to 
] 		be able to distinguish between the expressions 
] in the example. 
] 		If we don't, is it okay to go from var select 
] handle representing v.m2[2] to a parent ref obj representing v?
] 		 
] 		Perhaps we can discuss these issues on Monday.
] 		 
] 		 
] 		Francoise
] 		       '
] 		 
] 		 
] 
]