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.