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

From: Bassam Tabbara <Bassam.Tabbara_at_.....>
Date: Wed Jan 10 2007 - 08:01:24 PST
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 anddangerous content by MailScanner, and isbelieved to be clean.
Received on Wed Jan 10 08:01:57 2007

This archive was generated by hypermail 2.1.8 : Wed Jan 10 2007 - 08:02:01 PST