RE: [sv-cc] Update to Mantis item 1684 (vpiParent proposal)

Good points, all- thanks!

Just to confirm my understanding-
You are both saying it is still useful to return a non-NULL
vpiParent for a VPI handle to an originally valid
"<class_var>.<data_member>" design construct, even if the
"class_var" is no longer pointing to the original class-
object ?  What if it's pointing to a different one that's
valid ?

Note- I'm presuming the VPI application would expect
to be able to use the "class_var" VPI handle so-derived to
get to the relevant class-object- but it should ONLY be
be able to do so if it can assume the parent handle is
specifically correlated to the data-member instance referred-to
in the design (from which the original VPI handle was created).
I was in effect using vpiParent == NULL to "ward-off"
this potentially erroneous correlation.  Am I missing
something here ?
-CB

-----Original Message-----
From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
Sent: Wednesday, January 10, 2007 11:01 AM
To: Jim Vellenga; Bassam.tabbara@synopsys.com; Chuck Berking;
sv-cc@eda-stds.org
Subject: Re: [sv-cc] Update to Mantis item 1684 (vpiParent proposal)

Hi Jim, Chuck, all

I very much agree with Jim. This is indeed what I had in mind. Sorry my
"used" phrase was meant to motivate striking  out the "validity" test in
the sense that application will get an error or no "useful info" back
I.e don't care concern here. Yes indeed it can show up in source and
again my understanding is that chuck means to focus on syntactic parent
I.e class var not object.

Hopefully my poor choice of word before  helped clarify the feedback now
:).

THX. 
-Bassam

-----Original Message-----
From: Jim Vellenga <vellenga@cadence.com>
To: Bassam Tabbara <Bassam.Tabbara@synopsys.COM>; Chuck Berking
<berking@cadence.com>; sv-cc@eda-stds.org <sv-cc@eda-stds.org>
Sent: Wed Jan 10 06:44:40 2007
Subject: RE: [sv-cc] Update to Mantis item 1684 (vpiParent proposal)

I would agree with Chuck, but for a different reason.
An object of the form

  <class_var>.<data_member>

that appears in the design can be considered what
Abi calls a "compile-time invariant".  It has meaning
whether or not it currently points to something.  If
one extracts it from a statement such as

  <class_var>.<data_member> = ....

the object has meaning in a decompiler or similar
application even when it doesn't represent anything
that exists at the current simulation time.  For
this reason, I would like the vpiParent relation for
such an object to exist (and point to <class_var>)
even if vpiValid does not have the value vpiValidTrue
for the object.

Thus, I differ from Bassam in saying that the object
can be "used" even when it's not "valid".  But I agree
with him that the word "valid" should not be part of
the criteria. 

Regards,
Jim

--------------------------------------------------------- 
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 Bassam Tabbara
]Sent: Tuesday, January 09, 2007 5:33 PM
]To: Chuck Berking; sv-cc@eda-stds.org
]Subject: RE: [sv-cc] Update to Mantis item 1684 (vpiParent proposal)
]
]Hi Chuck,
]
]For (2) below I suggest striking out the "valid and", sentence would
]read "... when they are explicitly used ...", they can only be used if
]"valid". Goal is to avoid confusing with (the object's) vpiValid.
]
]Thx.
]-Bassam.
]
]-----Original Message-----
]From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
]Chuck Berking
]Sent: Tuesday, January 09, 2007 9:34 AM
]To: sv-cc@eda-stds.org
]Subject: [sv-cc] Update to Mantis item 1684 (vpiParent proposal)
]
]FYI- I have updated the vpiParent solution proposal for Mantis item
]#1684 with the following changes (copy attached for your convenience):
]
]1) I have changed the wording to introduce the list of viable vpiParent
]   prefix objects (3rd paragraph) in both variables (27.14) and nets
](27.13)
]   sections to read:
]
]   Was:  "... whichever comes first in successive prefix order:"
]
]   Is now: "... whichever comes first in prefix order (rightmost to
]lefmost):"
]
]2) I have added a paragraph in the variables section (for 27.14)
]   to narrowly qualify the inclusion of class variables as parent
]objects:
]
]   "Class variables (as mentioned in the prefix object types above)
]shall be
]    returned as parent objects only when they are valid and explicitly
]used to
]    reference corresponding class data members in the design. A VPI
]handle to
]    a data member that does not correspond to such an explicit 
]reference
]in the
]    design (e.g. a VPI handle to a data member derived from iterations
]on its
]    vpiClassObj or vpiClassDefn) shall have a NULL parent."
]
]Feedback welcome.
]Regards,
]Chuck Berking
]
]--
]This message has been scanned for viruses and dangerous content by
]MailScanner, and is believed to be clean.
]
]
]-- 
]This message has been scanned for viruses and
]dangerous content by MailScanner, and is
]believed to be clean.
]
]
]

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.