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
       '