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

Chuck please read my email just now on top of Jim's. I think a better way to state this is to focus on source syntax I.e you get class var without regard to object, validity does not come into play hence my critique of the word "valid" in sentence.

THX. 
-Bassam

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

Thanks for the inputs.  My goal was actually intended to cover the
case where vpiValid == FALSE for the underlying class object at the
point in the VPI *application* when the vpiParent was requested of the
data member handle.  I.e. this presumes the VPI handle for the data
member could "outlast" the validity of its underlying class object,
even when it (the VPI handle) was derived from a design construct
(implicitly valid) when it was first created.  I thought it was
important to re-emphasize this here even though I did generally make
this point just before the list of prefix items.  Let me know if you
think I need to clarify it further to clear up this potential confusion.
Regards,
Chuck

-----Original Message-----
From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
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 anddangerous content by MailScanner, and isbelieved to be clean.