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

The difference I see with an oomr and a ref obj is that an oomr expression 
always contains the original object name: "top.r", while a ref obj name can
change
at each level of the hierarchy. So a user could be quite confused if he gets
a handle to the expression r(1) and that is a bit select of an object named 
something else than r. Also we may not be able to decompile the code
correctly
if there is another object in the same scope of the same name as the actual
object.

I see a ref obj modelled more like a formal argument of a task/function.
I think that instead of adding all the relationships I listed in my previous
email, we
should make the ref obj actual point to the expression and not just the
actual object declaration.

Ex:

if I get a ref obj r(i) and r is a vector variable. The vpiActual
relstionship would return a vpiVarBit
and I would be able to access the index from the var bit handle.

So I think that the correct way of modelling this is to retain the ref obj
but extend the enclosure which
returns the actual object to include sub expressions of these objects.
I think that the vpiName of the ref obj should be the decompiled name of the
expression: "r(i)".

I will try to put a proposal for this if people agree that this is the right
way of doing this.

Francoise
    '



-----Original Message-----
From: Jim Vellenga [mailto:vellenga] 
Sent: Monday, April 11, 2005 3:56 PM
To: Francoise Martinolle; Warmke, Doug; Francoise Martinolle; sv-cc@eda.org
Subject: 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
] 		       '
] 		 
] 		 
] 
]