Thanks much- I'm pretty close now, but I'd like others to weigh-in on the general issue (my prev email). -CB -----Original Message----- From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] Sent: Wednesday, January 10, 2007 4:38 PM To: Chuck Berking; Jim Vellenga; Bassam Tabbara; sv-cc@eda-stds.org Subject: RE: [sv-cc] Update to Mantis item 1684 (vpiParent proposal) Chuck, I think just go back to bottom of this email, and strike out "valid and" in your write-up, and we're good to go. I.e. Think class variables no mention of objects or validity. That's it. So we're talking: Class myclass; int a; endclass ... myclass c1; .... c1.a = 5; // we don't care if c1 was ever new-ed, or later reassigned, or null-ed ... For "c1.a" you get a "c1" parent. Thx. -Bassam. -----Original Message----- From: Chuck Berking [mailto:berking@cadence.com] Sent: Wednesday, January 10, 2007 12:55 PM To: Chuck Berking; Jim Vellenga; Bassam Tabbara; sv-cc@eda-stds.org Subject: 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.Received on Thu Jan 11 07:28:02 2007
This archive was generated by hypermail 2.1.8 : Thu Jan 11 2007 - 07:28:29 PST