Hi Charlie, There is one implication of approving 2226 as we did. It answered the only question raised for 985 that caused Jim to withdraw the expedited approval motion. The way the question was answered, in effect, means we would have approved 985. I don't want to overstate anything, so: Given 2226 status ( and for the obvious entertainment of being our first consent agenda item ), I suggest we put 985 on the consent agenda for next meeting. ;) ---- I also found 2 other references to "erroneous" that I made in vpi_free_object and vpi_release_handle in clause 37. To reiterate for everyone, erroneous is a formal way of saying this is an error which is not required to be detected. The effect of an erroneous condition is always undefined. In these 2 cases, it is accessing an invalid handle, i.e. one that has been released. It notes that this may cause a crash. The feedback today was that "erroneous" is not common terminology in SV and might be misunderstood to mean error. What we decided today in one place was to replace erroneous with undefined. I think for these other 2 references, it is clear enough as written and I would not unilaterally change what we have approved, in any case. I plan to leave it alone, but if it comes up again at next week's meeting, it is trivial to reword it. ---- IMO, erroneous would be a very useful term for the editor to define and use across SV. The trouble with saying "undefined" can be that it is unclear whether that is a temporary decision similar to the LRM remaining silent about something, a statement about lack of portable behavior, etc. Calling something erroneous, as it is formally defined, is a clear decision (it's an error that may or may not be detected) with good formal semantics. Regards, John -----Original Message----- From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On Behalf Of Charlie Dawson Sent: Wednesday, March 26, 2008 2:20 PM To: sv-cc@server.eda.org Subject: [sv-cc] SV-CC Meeting Minutes for 03/26/2008 Minutes of 03/26/2008 SV-CC Meeting. ATTENDEES 000000000000000000000000000000000000000000 888888887777777777777777777777777666666666 000000001111100000000000000000000111110000 333221112210099888876655443322111221009988 211213101002121221012020212121310200212131 692730629574062925180639518484173068517306 xxxxxxxxxxxxxxxxxxx-xxx-xxxxxx-xxxxxxxxxxx Charles Dawson xxx-xxxxxxxxxxxx--xxxxxxxxxxxxxxxxxxxxxxxx Jim Vellenga x-xxxx-xxx-xxxx---xx--xxxxx-xxxx--xxxxxx-x Michael Rohleder xxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxx Chuck Berking xxxxxxxx-xxxxx-xx--xx-xxxxxxxxxxxxxx-xxxxx Bassam Tabbara xxxxxxxxxxxxxx-xxxxxxxxxxx-xx-xx-x-xxxxxxx Francoise Martinolle x-xxxxx-xxxxxxxx---xxxxxxxxxxx-xxxxxxxxxx- Ghassan Khoory xxxxxxxxxxxxxxxx-----xxxxxxx-xxxxx-xxxxxxx Abigail Moorhouse x-xxxx-xxx-------------x-----xx----------- Steve Dovich xxxxxxxxx--------------------------------- John Shields xx-x-xxx--x-xxxxx--xxxx------------------- Anil Arora ========================================== ---x-xxx-xx-x------xxx-x--x--xxxx----xx-xx Amit Kohli --------xx-x-xxxxx-xxxxxxxx-xxxxxxx-x-xxxx Ralph Duncan ------x--xx--xx-xxxxxxxxxxxxxxxx-xxx-x-xxx Andrzej Litwiniuk -----------x-xxxx--xxxx------------------- Pankaj Pal -------------x-x----xx-------------------- Arjinder Vasir --x-----------------------x--------------- Stu Sutherland ------------------------x----------------- Gord Vreugdenhil ---------------x-------------------------- Neil Korpusik ------------x----------------------------- John Havlicek --x--------------------------------------- Erik Seligman 1. Reviewed Patent information - Chas reviewed the patent information which can be found at http://standards.ieee.org/board/pat/pat-slideset.ppt 2. Approval of agenda Chas pointed out that the GMT was incorrect again. Should be 3:30. Chas will fix for next time (really this time). JimV asked that 0985, 1700, 1603 be added to the Expedited agenda section. JimV/Chuck. ACCEPTED as modified 3. Reviewed minutes for 03/19/2008 Chas thinks we moved to reopen 1942. Chuck was under the impression that 2226 would supersede this one. No one remembers what happened the same. John thinks if we get thru 2226 then we will not have a proposal for solving the problem. Since no one can remember what happened the same, we will leave minutes as is. JimV/Chuck. ACCEPTED (without modification). 4. Liaisons - Francoise reported on the Champions meeting. Neil is intending to have another Champions meeting. SV-BC and SV-EC had last meeting yesterday. Having a last email vote, but basically all done. - No other meetings to report on. 5. Consent Agenda 6. Expedited Agenda Items - Item 985 JimV updated proposal to match draft 4. JimV moves to accept. John wanted to know if we were changing the semantics. JimV added only queues and strings. JimV withdraws motion. - Item 1700 vpiTimeConst and vpiNullConst had same value. JimV/Chuck. PASSED (unanimous) - Item 1603 Chas pointed out that JimV posted a .fm instead of .pdf. JimV will correct. JimV/Chuck. PASSED (unanimous) - Item 1593 vpiName property for members of structs and unions Chuck thinks the proposal is not quite right yet. Asked Abi if she thinks the vpiDecompile and vpiFullName would always return the same thing if there is a full name for the object. Withdrew proposal for now. - Item 2143 How should VPI handle index expressions with side effects? JimV moves that we accept the "Conservative" proposal. Abi seconds. PASSED (unanimous) JimV to remove the other two proposals. - Item 2094 Need to extend VPI to handle class specializations Chuck/Francoise. PASSED (Abi abstained) - Item 1599 The assertion API and VPI sections need changes as per mantis #805 Already done. - Item 1688 Performance of VPI access to memories and MDAs is inadequate John asked if there was any consideration for trying to put a value with a force. Francoise is not sure if you can force a sub element of an array of nets, for example. Friendly amendment to add a comment to refer to the LRM for the effects of a force to follow the normal language rules. Chuck wants to say, if there is no clear language, then we should treat it as an error. See SV-BC Mantis Item 2097. Agreed to follow language rules. Chuck moves that we accept as amended. John seconds. PASSED (unanimous) - Item 2054 Draft 3A, Section 40 - Deprecate Data Read API Bassam says that a similar interface was implemented at one point, and people were using it. Michael really wants this functionality. Especially without VCD being there. Abi moves to accept. Chuck seconds. Michael, Francoise, Ghassan OPPOSED. Bassam ABSTAINED. Abi, John, JimV, Chuck, Steve, Anil in FAVOR. PASSED ( 6 to 3 with 1 abstention). - Item 2226 VPI Handle behavior for HDL objects of dynamic lifetime is not defined Chuck moves that we suspend the rule on requiring the proposal 1 week in advance. ? second. ACCEPTED. Friendly amendment to remove the extra word "default" (in 36.3.6). JimV asked that we make a change to clause 37 in its description of size change. Issue is in 37.34.1. Should an initialization cause a size change? JimV thinks this item should not be about cbSize change, and therefore we should go with what was already in the LRM. JimV would like to take the "initialized or" out. Friendly amendment. Friendly amendment to add "string". Abi had a friendly amendment to change "vpiOthereScheme" to "vpiOtherScheme". Chuck had a friendly amendment to replace actual numbers in Annex N with "editor please use appropriate number". Chuck friendly amendment to change refs to 36.6 to be 36.3.6. JimV made a friendly amendment to change "dynamic objects" to "class objects" in the comments in annex N for cbCreateObj and cbReclaimObj. Francoise asked about vpiAutomatic. JimV suggested she look at Section 36.3.6. The compromise we came up with was designed to deal with the overloading of the term "static". Need to reconcile proposal for Item 2094. Chuck wants a friendly amendment to 36.25 to add a note to the editor to reconcile Item 2094 with vpiAutomatic. Chuck brought up an issue in 37.34.1 with the term "erroneous". Friendly amendment to change it "undefined". JimV noted that somewhere there is "System Verilog" somewhere. John to change to SystemVerilog. Francoise found "datastructure" Should be "data structure". John to fix. John/JimV. PASSED (Michael abstained - did not fully review the proposal). John to implement the friendly amendments. 7. New business - Reviewing SV-AC issues. Chas asked that we meet next week. Francoise noted that we do not have to look at the checkers proposal yet because there is a separate committee being formed to work on it. Francoise asked if there was a list of items we needed to go thru. Chas to send out. Abi asked when would we see draft 5. Francoise will ask Stu. John said that Stu was shooting for early April. Motion to adjourn: Chuck/Michael. Meeting ended at 1:50pm 8. Reviewed items with proposals 9. Reviewed SV-CC items with proposals (Straw poll only) 10. Old Business 11. Action items - Francoise and Bassam to continue work on assignment patterns. - Francoise and Bassam to figure out what should happen when you get the size of a string constant. - Chas to update Item 1570. - Chas to ask the editor about Item 0417. - Steve to write a proposal for dealing with the inconsistencies with the protection properties. - Chas to talk with editor on re-arranging the VPI that is outside of the VPI sections. - Bassam, JimV, and Lisa Piper to work on issues found in Item 1503. - Chas to ask the editor for the framemaker for the Data Read API. - Chas to implement a "consent agenda" and an "Expedited Proposals" in agenda. - Chas to add an "Agenda Approval" to the agenda. - Chas to schedule another Data Read API meeting after DVCon. - Bassam to implement the friendly amendment to Item 1599. - Chas to ask John Havlicek to join the SV-CC meeting when we discuss SV-AC issues. - Chas to ask the SV-AC to fix the #defines in proposal for Item 2005. - Francoise to bring up the issues we found with Item 2250 at Champions meeting. - Chuck to update proposal for Item 1230 with three friendly amendments. - JimV to add friendly amendment to proposal for Item 2216. - Chas to enter Mantis Items for Krzysztof Konopko's questions - Chas to tell SV-AC that we are okay with Item 2005 provided the move the #define 12. Items for consideration at the next meeting (they already have proposals) - Item 0555 31.1 Introduction not needed in context of the larger document - Item 0556 31.2 Beginning of this section not needed in larger context of spec - Item 0557 31.3.1 specific references to objects should be removed - Item 0558 31.3.3 rename section to "Access availability" - Item 0560 31.4.1 & 31.4.2.1 Overloading vpi_handle() is a bad idea - Item 0561 31.4.2 vpi_free_object() should be explicitly referenced here - Item 0562 31.5 needless restriction on traverse object creation - poor terminology - Item 0563 31.5 diagram in figure 31-18 needs to be redrawn - Item 0565 31.6 remove first paragraph of this section - Item 0570 31.8.1 Need prototype for vpi_load_extension() - Item 0571 31.8.1 unnecessary complication added for vpi_close() - Item 0572 31.8 make use of the term 'user' - Item 0580 31.8.4 section is not necessary and colloquial - Item 0583 31.8.4.2 terminology first defined in a footnote? - Item 0584 31.8.4.2 implies that vpi_goto() creates new handle - Item 0593 31.12 Routines should be in table format - Item 2146 Data read API description references wrong header file - Item 2148 Unclear statement about error handling after calling vpi_unload() 13. Next meeting The next SV-CC meeting will be on 04/02/2008. The next P1800 meeting will be on 03/27/2008. -- 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 Wed Mar 26 16:20:21 2008
This archive was generated by hypermail 2.1.8 : Wed Mar 26 2008 - 16:20:38 PDT