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

Rethinking this a bit (help me *stop* now! :-)...

I seems the whole vpiValid consideration should be removed from
this proposal entirely, the rule being summarized as:

  Any dynamic design object for which a VPI handle was successfully
  created should have a non-NULL vpiParent for a qualifying prefix
  object.

I.e. the issues are similar enough for other dynamic design objects
such that vpiValid-ity should be considered a separate issue from
vpiParent- at least in terms of objects appearing in the design.

Does this sound like a more reasonable/consistent solution here ?

I'll make this change, if you are all in reasonable agreement.
Regards,
Chuck

-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Chuck Berking
Sent: Wednesday, January 10, 2007 2:31 PM
To: Jim Vellenga; Bassam Tabbara; sv-cc@eda-stds.org
Subject: RE: [sv-cc] Update to Mantis item 1684 (vpiParent proposal)

OK- understood.  I will work this into the new paragraph.

It does seem counter-intuitive to have "class-var"
parents themselves be the only exception to the
preceding phrases:

  "For a variable object with valid prefix objects
   (vpiValid property == vpiValidTrue for all prefix objects),
   the vpiParent transition will return one of the following
   prefix objects, ...
     .....
     .....

   If there is no prefix object (or a prefix is not valid), ..."

Alternate wording suggestions ?

Although it probably can't be discussed in the "detail"
context here, it seems important to impart to VPI users that
the "<class-var>" vpiParent of the compile-time-invariant
design object "<class-var>.<data_member>" is, at best,
dynamically bound to the original design object, i.e. you
can guarantee only that the name and class-definition can
be extracted using the parent.  To get the class-object
relating to the design object is another matter, i.e. you
may need to know the precise simulation *time* (dynamic context)
in which to ask for it.

Though fallout from this will hopefully be rare, it may
be a hard lesson to learn for some VPI application developers.
-CB

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

I evidently didn't state my point clearly enough.

To be explicit, a non-NULL vpiParent should be available
for "<class_var>.<data_member>" even if it has _never_
been valid -- also if it is no longer valid -- and
independently of what it points to.  To my mind,
the VPI object for "<class_var>.<data_member>" is
a representation only of something that can appear in
the SystemVerilog source.  You can't get it by a
vpiMember iteration on a class variable.

If you want to get the real data member objects
currently associated with a class variable, you
do the vpiClassObj on the class variable and then
iterate over the vpiVariables of the class obj.
Those variables, as you have already noted, have
a NULL vpiParent.

To put it another way, the VPI object representing
"<class_var>.<data_member>" is a compile time
invariant, so that its existence doesn't depend
on what it's pointing to at the current simulation
time -- or even if it's pointing to anything at all.

It's for this reason that I believe that the vpiParent
relation for "<class_var>.<data_member>" does not
depend on its validity.

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: Chuck Berking 
]Sent: Wednesday, January 10, 2007 11:30 AM
]To: Bassam Tabbara; Jim Vellenga; sv-cc@eda-stds.org
]Subject: 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.



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