Minutes of 01/31/2007 SV-CC Meeting. ATTENDEES 000000000000 777666666666 000111110000 111221009988 310200212131 173068517306 -xxxxxxxxxxx Charles Dawson xxxxx-x-xxxx Ralph Duncan xxxxxxxxxxxx Jim Vellenga xx-xxx-x-xxx Andrzej Litwiniuk xxxx-xxxxxxx Abigail Moorhouse xx--xxxxxx-x Michael Rohleder xxxxxxxxxxxx Chuck Berking xxxxxx-xxxxx Bassam Tabbara xx-x-xxxxxxx Francoise Martinolle xxx----xx-xx Amit Kohli -xxxxxxxxxx- Ghassan Khoory 1. With both Charles and Ghassan absent, Jim Vellenga called the meeting to order. Ralph moved to appoint Jim as moderator pro tem (Chuck seconded). ACCEPTED (unanimous). 2. Reviewed Patent information. - Jim reviewed the patent information. 3. Reviewed minutes of the 01/17/2007 Meeting. - Chuck/Bassam. ACCEPTED (unanimous) 3. Liaisons - Francoise was not yet present to report on SV-BC issues. - Ralph reported on Mantis item 1447, which proposes clarifying and expanding the LRM section on dynamic arrays. Doug Warmke does not have time to drive it, so Ralph will talk with Shalom to see if Shalom can drive the issue forward. 4. New business - Full name for class objects (Chuck). Chuck proposed extending the vpiFullName property so that it applies to class variables and their data members. Jim: 1800 17.14 detail y prohibits the vpiFullName property only for nonstatic data members, but seems to allow it on class variables. Abi: Such objects have an existence in the elaborated design even when they don't actually point to an underlying simulation object. Chuck: Yes, the scope of the thing referred to can change but the way to refer to it does not. VPI must provide a way of connecting the two. Amit: How can you reference a class variable that is itself declared in a class scope? Chuck: The important thing is to track the expression object, even if it involves nested class variables. Michael: Can the full name of a class variable change from time to time if it's embedded in a class? Chuck: Not if it's embedded in a static context. Francoise: Originally, vpiFullName was intended to allow an object to be retrieved again via vpi_handle_by_name(). But this does not work with automatic scopes. And what about unnamed scopes such as unnamed blocks? Jim: 1800 27.9 says that unnamed scopes shall have tool-dependent names. Chuck: Is there a connection between when an application can obtain a vpiFullName and whether or not the handle is valid (vpiValid == TRUE)? Francoise and Abi: The two are unrelated. Steve: We need to separate out the following three issues clearly: -- location -- What is the underlying simulation object? -- alias -- How are we referring to the object? -- time -- How are the location and alias related over time? Jim: This applies even in old Verilog, as array[i] and array[0] can be aliases referring to the same location at times when i has the value 0. Chuck: If we allow vpi_handle_by_name() to accept a full name of a nonstatic member of a class variable, does that object exist even if the class variable points to NULL? Abi and Chuck: Yes, but the application must be aware that it may not point to an underlying simulation object and should test vpiValid. Francoise: A handle does not disappear just because vpiValid becomes false. Jim: 1800 27.22 detail g says that vpi_handle_by_name must accept a full name of a nonstatic data member of a class variable. It does not indicate that the underlying simulation object must exist. Abi; The elaboration name doesn't change along the time line, but what it points to does. Chuck: Suppose that a nonstatic data member of a class variable is referred to as the left-hand side of an assignment, and one obtains a handle to it via the vpiLhs relation. Francoise: The vpiLhs relation should definitely return a handle that represents the expression, even if it is not currently valid. Chuck: We need to clarify what properties and relations of a handle can be accessed when it is not valid. Jim: There are two ways in which a handle can become invalid. -- for class_var.data_member, the handle does not go away even when it no longer points to an underlying simulation object. One may still obtain certain properties. And the handle can once again point to a simulation object when the class variable gets reassigned. -- for a data member obtained relative to a class obj scope, the handle will have no further use once the class obj ceases to exist. Francoise: It's still not clear that these are really different. Francoise: We need to see the issues described succinctly in writing. Steve: In particular, we should consider -- What aliases exist? -- What do they refer to? -- What do they point to at any given time? Action item: Chuck will produce a succinct written description of the issues. Motion by Francoise/Michael to adjourn. ACCEPTED(unanimous). Meeting ended at 1:01 pm EDT. 5. Reviewed items with proposals. 6. Reviewed SV-CC items with proposals (Straw poll only). 7. Old Business 8. Action items - Ongoing review of Michael and Abi's compatibility proposal. - Francoise and Bassam to continue work on assignment patterns. - Francoise to champion adding support for typed parameters to the typespec diagrams. - Abi to champion adding support for parameterized classes. - Abi/JimV to champion improving the ability to compare objects. - Steve Dovich to determine best way to deal with issues between versions of the IEEE specs. - SV-CC to review proposal for Item 0890. 9. Items for consideration at the next meeting (they already have proposals): - Item 1684 vpiParent clarification needed for complex var/net objects 10. Next meeting The next SV-CC meeting will be on 02/14/2007. The next P1800 meeting will be on 02/20/2007. --------------------------------------------------------- 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." ---------------------------------------------------------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Feb 1 10:00:48 2007
This archive was generated by hypermail 2.1.8 : Thu Feb 01 2007 - 10:01:05 PST