FYI, Attached are the minutes from the Champions meeting held on July 26. Action items are listed at the bottom. Note that I didn't follow the point being made about section 34.4. Did I record the wrong section number? This was the discussion before we covered mantis 1567. Minutes from the other two meetings will be sent tomorrow. Neil -- --------------------------------------------------------------------- Neil Korpusik Tel: 408-276-6385 Frontend Technologies (FTAP) Fax: 408-276-5092 Sun Microsystems email: neil.korpusik@sun.com --------------------------------------------------------------------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions meeting minutes of July 26, 2007 8am - 10am PST Attendees: 1. Dave Rich 2. Neil Korpusik 3. Surrendra Dudani 4. Brad Pierce 5. Shalom Bresticker 6. Francoise Martinolle 7. Stu Sutherland 1. Review IEEE patent policy http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Dave - assume that the patent policy was read Second: Surrendra Passed unanimously 2. Summary - from agenda There are about 90 mantis items that are ready for the Champions to review. I have scheduled 3 meetings for us to go over them. By the time we have the third meeting there will be another set ready for review. I have picked 36 for the first meeting. They are listed below. I will be going through the list to determine which of them passed unanimously and which had people either opposed or against them. I will send out an update that contains that information early next week. The chairs of the technical committees have told me that this set of mantis items has been made consistent with draft3 of the LRM and are now ready for the champions to review. Please start your review. 3. Mantis items From sv-cc Id Summary 985 cbSizeChange for queues too? approved unanimously 10/25/06 (wasn't marked as passed until recently) Dave - Needs updating 27.14 is now 36.16 Stu - ok Move: stu - approve the proposal for mantis 985, with the friendly amendment to update the section number Second: dave Passed: unanimously 1385 Please document compatibility issues between 1364 and 1800 VPI approved unanimously 06/20/07 - with friendly amendments stu - ok - some renumbering will happen [I can't remember where the renumbering will occur but I think he was referring to the section numbers within section 35 due to other mantis items that are also adding to section 35. -- Neil] Move: stu Second: fm Passed unanimously 1603 Unused vpiMultiArray declaration in vpi_user.h approved unanimously - see bugnote Dave - Change should be to 1800-2008 Annex L Stu - ok - backward compatibility issue. fm - They checked with vendors, not yet implemented. not covered by 1385 was in vpi_users.h file but was not in any diagram no one could have known where it was used. Move: stu - approve the proposal for mantis 1603 Second: fm Passed unanimously 1614 P1800-2005: 27.52 no expr for disable fork objects approved unanimously 01/03/07 Dave - 27.52 is now 36.67 stu - diagram line is the only change? Dave - see the mantis description Move: stu - approve the proposal for mantis 1614, with the friendly amendment to update the section number Second: dave Passed unanimously 1631 P1800-2005 27.14 note k has an error approved unanimously 01/03/07 Dave - 27.14 is now 36.16 stu - ok Move: stu - approve the proposal for mantis 1631, with the friendly amendment to update the section number Second: dave Passed unanimously 1632 P1800-2005 sections 27.14 note k and 27.22 note f are incompatible approved unanimously 01/03/07 Dave - 27.22 is now 36.26 stu - ok Move: stu - approve the proposal for mantis 1632, with the friendly amendment to update the section number Second: dave Passed unanimously 1664 IEEE 1800-2005 27.7 Note 'e': First sentence should be rewritten approved unanimously 01/03/07 Dave - 27.7 is now 36.9 stu - ok Move: stu - approve the proposal for mantis 1664, with the friendly amendment to update the section number Second: dave Passed unanimously 1669 P1800-2005 Sections 27.34 and 27.36 commas are inconsistent approved unanimously 01/03/07 with friendly amendments Dave - 27.34 is now 36.45 stu - spelling error, and an extra comma AI/Neil - send feedback to the svcc: add a note to the editor and fix the section number Move: stu - approve the proposal for mantis 1669, with the friendly amendment to update the section number Second: dave Passed unanimously 1684 vpiParent clarification needed for complex var/net objects approved unanimously 02/16/07 - with a friendly amendment Dave - 27.14 is now 36.16 Fm - there are 2 whole new sections to be added stu - ok , he has to redo the formatting anyway. bolding needs to be redone - first pasted in to a text file and then into frame from there. - 2-3 pages stu highlights the section number - 1 para stu will put the text in blue Brad - keywords need to be bolded, should be in blue Dave - when new text - he doesn't think blue is needed Move: stu - approve the proposal for mantis 1684, with the friendly amendment to update the section number Second: dave Passed unanimously 1699 1800-2005+ draft 3 sections 36.34 and 36.68 problem with vpiReturn approved unanimously 06/20/07 Stu - needs to change ### to an available number stu will add a margin note for this FM - other numbers should remain as is. Move: stu - approve the proposal for mantis 1699, with the friendly amendment to update the section number Second: dave Passed unanimously 1700 vpiTimeConst and vpiNullConst have the same value approved unanimously 01/03/07 Dave - Annex I is now Annex L stu - is the only change to the value? can't they have the same value? fm - no they can't stu - ok Move: stu - approve the proposal for mantis 1700, with the friendly amendment to update the section number Second: dave Passed unanimously 1716 Clarify handling of DPI formals/actuals with rand/randc qualifier approved unanimously 02/28/07 Dave - Annex F is now Annex I stu - ok FM - clarifications for rand, randc arguments value without extra bits is passed back(only value passed thru) Move: stu - approve the proposal for mantis 1716, with the friendly amendment to update the section number Second: dave Passed unanimously From sv-ac 1460 Allow actions within assume property statement only 8 of 10 voted stu - ok with editing changes Move: stu - approve the proposal for mantis 1460 Second: surrendra Passed unanimously 1466 shortcuts for delay and consecutive repetition failed the email vote of 03/31/07 Bassam Dave - I am opposed to this enhancement at the current time for the following reasons: 1. This is not Verilog-like. Use of a range specification [n:m] in Verilog is quite common and having a single character does not fit with rest of the language. Also, '?' means 'z' in Verilog 2. Other parts of the language use similar range specifications (Queues and coverage transitions). If we must have these shortcuts, shouldn't they be uniformly applied? In then end, I don't think the 2 keystroke shortcut is worth the instability. Dave - Steve Sharp also questioned the usefulness of this. Shalom - the desire was for PSL and SystemVerilog to be more similar Dave - hard to put a focused effort on this type of issue. This is an enhancement. We need more time to work out the issues. Fm - agrees with Dave. If just a shortcut, we don't need it. stu - you lose code documentation ? in UDP means don't care, ==? wildcard Dave - if it was a PSL conflict that would be a stronger reason to add it Surrendra- users want concise syntax for assertions. some users really want it Shalom - n for an unpacked array size - people want to take PAL and easily convert it to sv - ? is not in PSL Dave - objected to that as well. Brad - shortcuts are easier to read. fm - understands the long-hand easier Dave - 1,$ is a pop operation for a queue - covergroups also inconsistent? - If we allow shortcuts they should be uniformly applied throughout the language. stu - other committees should have a chance to comment on this? Shalom - opposite argument was used for 'let' for assertions Move: Brad - approve the proposal for mantis 1466 Second: Surrendra Abstain: Shalom - has no strong opinion either way. Oppose: Dave - see above reasons fm - should be similar to verilog, e.g. designers don't need a new syntax. Stu - 1. no added capability 2. obfuscates the code - means different things in different contexts. Motion failed 1543 Meaningless sentence in 17.15 and Annex H <already in the lrm> 1550 $sampled function definition approved unanimously 02/14/07 7 yes, 3 not voting stu - the annex for deprecated stuff. Does this need to be added there? [The use of clocking_event arg to $sampled has been deprecated] Brad - seems like an error. Should issue a warning. Dave - proposal should be written as though the argument is not there. Shalom - what about the syntax shown in - section 19.11 - section 16.8.3 Stu - SystemVerilog 3.1a, does mention the use of clocking_event There could be a backward compatibility issue. Thinks a warning should be generated. Dave - Take out the whole sentence about the clocking event can be used. Friendly amendments: - Add a description of the deprecated syntax to Annex C.2 The deprecated syntax should only appear in Annex C.2 and not in sub-clause 16.8.3 - Remove the following sentences from 16.8.3 "The function $sampled does not use a clocking event, although one can be optionally provided. The optional clocking event is ignored, and its use is deprecated" - Change the syntax for $sampled in 19.11, 16.8.3 such that the argument clocking_event is not shown. Move: stu - approve the proposal for mantis 1550, with the set of friendly amendments Second: Brad Passed unanimously <--------< is 34.4 really deprecated? >----> Shalom - If deprecated constructs are only in annex, what about 34.4? Stu - vpi object diagrams are also an issue. for clause 34, consolidate it to one note that refers to annex c and update annex c to say what is deprecated. Move deprecated stuff to annex c. fm - there are a few places here that are of concern. AI/neil - send input to the sv-cc. <--------------------------------------------> 1567 22.9: in Syntax 22-7, should be no semicolon Neil - getting rid of a ; Brad - should use a strikeout on s as well Neil - it looks like there are 2 strike-outs here. Friendly amendment Change the proposal to make it more obvious what is being changed. - The s that is being removed should have a strikethrough and be in red - The ; being removed should have a strikethrough on it Move: Brad - approve the proposal for mantis 1567, with the friendly amendment Second: Stu - assuming they do the friendly amend. Passed unanimously 1591 17.7.3, 22.9: $past syntax not precise approved unanimously by email vote 02/14/07 stu - similar to 1550 brad - they are just making it consistent for cases with defaults. can do this with system functions today. e.g. $left() thinks it is ugly Move: stu - send it back to update the part about $sampled (see 1550) also rename or remove old proposals. Second: brad Passed unanimously 1601 * new keyword for untyped formal arguments Shalom sent feedback. John responded. Also check my exchange with John on what is purely editorial in nature. Was updated and is in the process of being revoted... Dave - I am opposed to this enhancement at the current time. It is unfortunate that we ever allowed un-typed formals. The language should be fixed properly so that un-typed formal are obsolete rather than allowing them to be mixed with typed formals. Dave - basically changing the language to be more strongly typed makes things more obfuscated to mix them. - looks like the new set of people are in favor of a new approach and are rewriting the language. - using context as a new type Brad - a new type that means any type. Dave - this proposal could affect future changes with respect to a variable number of arguments. - untyped formals weren't well thought out originally. - is there a real need to mix typed and untyped formals? sur - recursive properties can be an issue. You need to maintain the type in passing values between properties. - you don't always know what you are passing to an assertion - there were a lot of discussions on this Dave - can put the untyped arguments first. The only reason for this proposal is to allow them in the middle. Doesn't see the ordering of args making a strong case for this. stu - doesn't like adding new keywords using the word context in a different way here (not good either). Dave - we need untyped arguments in other parts of the language. we need to make sure that we are ok with whatever is allowed in svac. fm - doesn't like context Brad - 'untyped' could possibly be used in place of context Dave - still opposed, even by using the new keyword untyped. by rejecting this proposal, only effect is to force untyped to be first. Not a major restriction. Sur - the proposal makes it more clear that they are untyped. Dave - keyword versus good idea. Stu - send it back to use untyped and request a justification for proposal Move - Stu - send 1601 back to the sv-ac to use 'untyped' in place of 'context' and request a justification for the proposal Second - Dave Abstain - sur - not convinced of reasons for rejecting it. Passed with one abstain 1648 Default reset for assertions (default disable) unanimously passed by email vote 06/25/07 Dave - I am against this enhancement at the current time. I believe this feature will be useful in a wider context, such as covergroups, but the committees have not had time to study this. If we add this feature now, it will be harder to address the other areas due to backward incompatibilities. For example, suppose the sv-ec decides that default disable should also disable sampling of covergroups. We can't add that capability later; we must look at all the other areas that could be affected. But due to schedules and merge activities, the other committees have not been able to investigate. Fm - agrees that there could be backward compatibility issues. - ask svec about adopting it? - Brad agrees with this Brad - ask svec - if covergroups should use this as well? Dave - there may be other places as well. Sur - can't have disable properties on sub properties. Stu - doesn't think everything is being considered. Same properties can have different behavior depending on how used. Top-level versus not top-level (e.g. rule b on first page). Sur - disable applies to the assertion not the property itself. Issues: Brad - The bnf shouldn't be in the text. Fm - 3rd paragraph under syntax box, part about "...on the position of...", doesn't need to say it. "The scope of the... " isn't clear. - There are issues in the other 2 paragraphs as well. stu - Wording of first paragraph - should be reworded "One can specify..." --> "A default disabling condition may be..." Move: Stu - send 1648 back to svac with this set of 3 concerns. Second: Dave Passed unanimously 4. Meetings August 8 August 15 List of action items from this meeting 1. Neil - send mantis formatting guidelines to committees - strike-outs in red - new text in blue - keywords bolded - etc. 2. Francoise - send a list of the itemized issues she found with the proposal for mantis item 1648 to the champions and the svac. 3. Neil - send email to sv-ec (mantis 1648) Would a default disable be useful for covergroups? 4. Neil - send email to sv-cc Itemize the feedback for all of the mantis items with issues that were processed by the sv-cc. 5. Neil - mantis 1603 - provide input to the 1800 - backward compatibility issue. 6. Francoise - should mantis 1603 be in the backward compatibility section? If this constant was used it would be a problem. Do this change in a separate mantis item. 7. Neil - delete the old proposal for mantis 1460. sv-ac 8. Neil - notify sv-ac that the proposal for mantis 1466 failed 9. Neil - notify sv-ac of the friendly amendments to 1550, 1567 10. Neil - note on committees on old proposal names 11. Neil - request changes to mantis 1591, 1601 from sv-acReceived on Fri, 17 Aug 2007 18:58:46 -0700
This archive was generated by hypermail 2.1.8 : Fri Aug 17 2007 - 18:59:23 PDT