FYI. ------- Start of forwarded message ------- X-eda.org-MailScanner-Watermark: 1206744892.99733@n35sDmMJ0BkiSG5FTU6fpg X-Authentication-Warning: server.eda.org: majordom set sender to owner-sv-champions@eda.org using -f X-eda.org-MailScanner-Watermark: 1206744857.0758@2qyzBamCyz2PwK01/gJ1Fg Date: Fri, 21 Mar 2008 15:54:13 -0700 From: Neil Korpusik <Neil.Korpusik@Sun.COM> Subject: [sv-champions] Minutes of the March 20, 2008 conference call To: sv-champions@eda.org Reply-to: Neil.Korpusik@Sun.COM X-eda.org-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-sv-champions@eda.org X-eda.org-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m2LMsp9q003676 X-eda.org-MailScanner-From: owner-sv-champions@server.eda.org X-OriginalArrivalTime: 21 Mar 2008 22:55:59.0073 (UTC) FILETIME=[BA8D8D10:01C88BA6] This is a multi-part message in MIME format. --Boundary_(ID_pgalo6DWXwWe97XkgGwA0w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_pgalo6DWXwWe97XkgGwA0w) Content-type: text/plain; name=m032008.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=m032008.txt Champions Continuation of March 13, 2008 Conference call March 20, 2008 Thursday 7:30-9:00 AM PDT Attendees: ---------- 1. * Stu Sutherland 2. - Surrendra Dudani 3. * Brad Pierce 4. * Francoise Martinolle 5. * Shalom Bresticker 6. * John Havlicek 7. * Dave Rich 8. * Neil Korpusik Request from Jeita on consistency of style for syntax excerpts and tables ------------------------------------------------------------------------- Stu would like to leave the syntax style the way it is. Karen agrees What do the champions think? I had forgotten to allow time for JEITA's request to make the style for syntax excerpts and tables consistent. I had researched this a few months ago, shortly after draft 4 was released, and determined that we are within IEEE style guidelines to make the two consistent (the IEEE has a definite style to follow for tables, but syntax excerpts is our own creation, and has no style guideline--the current style follows that of figures, but can be changed to the style of tables). There is a related request from JEITA that the title for syntax excerpts be moved to before the excerpt instead of after. We can do that. The unanswered question is do we want to do this? JEITA requested the change so that when a person searches for, or hyperlinks to, a syntax excerpt title, they jump to the beginning of the excerpt, rather than the end. That is useful, but when reading the PDF or printed LRM pages, my personal preference is to see the title at the bottom of the box. Would you like me to ask the various committee chairs what they prefer, or would you like to just make a judgment call on this? Regarding the impact on the schedule, changing the style will only take a few minutes, as that is a global change that can be applied using search and replace. Moving the placement of the title is a half-days work; it requires manually searching for and moving the title line for every syntax excerpt in the entire LRM. Stu - One other issue raised by Jeita was the following inconsistency. This has since been fixed by the Editor. syntax: versus syntax_ Move: Brad - leave the position of the titles on the syntax excerpts "as-is". Second: John Passed unanimously List of Mantis items that are ready for review: ---------------------------------------------- 11. 1901 SV-AC Cycle delay for ## concatenation allows identifier to specify the delay w/o restricting to constant epxr - fixed - 2008-02-28: Voice vote 7y/0n/0a John - clarifies that the expression for ## must be a constant. Move: Brad - approve the proposal for Mantis item 1901 Second: John Passed unanimously 14. 1837 SV-CC Wrong outline for net in VPI generate diagram - fixed - was sent back to svcc from champions Oct 25 - was updated and approved by svcc On 01/30/2008 the SV-CC PASSED an amended proposal to solve the issues found by the Champions committee. (unanimous) Move: Stu - approve the proposal for Mantis item 1837 Second: Brad Passed unanimously 16. 1830 SV-AC JEITA: A.2.10 There are no Sequence methods(ended, triggered, matched) in the BNF [added to my notes] - fixed - 2008-02-19: The friendly amendments were approved by voice vote, 6y/0n/0a. - Part of the Champion's email vote ending Feb 23. For: Brad, Stu, Surrendra, Shalom, John No: Francoise Francoise What is the VPI model for those sequence methods? Needs to be passed to VPI. Brad Note to editor: The 'ended', 'triggered' and 'matched' in BNF should be red. - Mantis was not updated with the results of the email vote Shalom - Has an objection. Why adding methods to the bnf for sequences? Not in bnf for enum, for example. What is the justification? Stu - agrees - it would set a precedent. John - Suspects that no one in the sv-ac cares. - This was a Jeita request. - Let's kill it and sent the feedback to Jeita. Move: Dave - reject the proposal, no change needed to bnf. It would be inconsistent with the rest of the LRM. Second: Stu Passed unanimously 17. 1828 SV-BC JEITA: 9.2.2.3, 9.2.2.4 should/can and mandatory statements - fixed - On February 18, 2008 the SV-BC approved the attached proposal. The approval was not unanimous: For: Gord, Shalom, Cliff, Karen, Don Heath Stu, Tom Opposed: Brad (If check is recommended, the check should be well-defined) Mark (If check is recommended, the check should be well-defined) Steven (Small change, unnecessary and shares opinion of Mark/Brad) Abstain: Alex (Likes current text but does not feel strongly either way) Stu - Changes can and may to should (still leaves it up to the tool) Thinks it really doesn't change the lrm. Agrees with it, doesn't think it is necessary. Shalom - 'should' is a recommendation, not making it a requirement. - Thinks it should be approved. Brad - Simulators will know what to do, with respect to synthesis? Shalom - these things have been well defined for years, except for some corner cases. There isn't room for a lot of ambiguity. - You don't need to talk about synthesis here. Brad - always_latch is problematic Shalom - it is a recommendation (won't be in violation of standard) Move: Shalom - approve the proposal for Mantis item 1828 Second: Stu Opposed: Brad Passed with one opposed. 18. 1806 SV-AC Introduce "restrict property" verification statement - fixed - 2008-02-26: Voice vote to approve friendly amendments, 9y/0n/0a. - John added feedback to the bug notes 03/18/08 The changes at the beginning of 16.14 are not consistent with 1987. 1987 changes the list of the kinds of assertion (assert, assume, cover) to 16.2. I am changing 1987 to add restrict to this list in 16.2, and 1987 deletes the list from 16.14. There is another statement in 16.14 that needs to be modified: "The assert, assume, or cover statements can be referenced by their optional name." I will change this in 1987 to use "assertion statement" rather than listing the kinds. These changes will make 1806 dependent on 1987. 1806 could duplicate these changes to be made independent. - Dmitry requested to leave it on the Champions agenda (svac meets 3/20) John - 1987 now approved - 1806 was approved by svac this morning, unanimously Stu - have other committees reviewed the keyword 'restrict'? Move: Stu - approve the proposal for 1806 contingent upon both the svbc and svec approving the use of the keyword restrict. Second: John Passed unanimously 20. 1698 SV-AC The description of sampled value functions is insufficient - fixed - 2008-08-26: Voice vote to approve friendly amendment from DK, 9y/0n/0a. - Email from Shalom 03/13/08 Assuming that default clocking is not defined, the following two examples are illegal because no clock can be inferred: assign x = $rose(b); // illegal always @(posedge clk) begin ... @(negedge clk2); x = $past(y, 5); // illegal end I'm in doubt about whether the first example would work even if a default clocking is defined. It might not be illegal, but I am in doubt about whether it would work, because continuous assignments are triggered only when a net or variable on the right hand side changes. Can anyone resolve my doubt one way or the other? Stu - $rose will only be called when the argument b changes. - there might be other cases where it won't work. John - $rose compares the current argument with previous value for last clocking event. The value is stable throughout the timestep. The value changes whenever b changes. Dave - the argument change would wake up the call. Shalom - not sure about that. John - the intent was for the inferred clock to be applied to the call to $rose. - not sure if default clocking actually applies to $rose. Thinks it only applies to assertion statements. - There is a legitimate question about the application of the default clocking applying to $rose. Shalom - There is an activation question as well... Move: John - send Mantis 1698 back to the svac to clarify clock inferencing for $rose (and all of the other sampled value functions). Second: Shalom Passed unanimously 21. 1687 SV-AC Wrong equivalence for $isunknown - fixed - 2008-02-19: Voice vote to approve, 6y/0n/0a. Move: Dave - approve the proposal for Mantis item 1687 Second: John Passed unanimously 22. 1686 SV-AC assertion evaluation does not wait on subroutines - fixed - 2008-02-14: Passed by e-mail ballot, 8y/0n/1a. Dave - Is there more text about a subroutine attached to a function? - When calling subroutines we usually mean both functions and tasks. John - Tasks, system tasks, void system functions. Things with no return values. Move: John - approve the proposal for Mantis item 1686 Second: Dave Passed unanimously 23. 1648 SV-AC Default reset for assertions [updated my notes] - fixed - was sent back to the svac by the champions Jan 17 The proposal was updated and approved by the committee. - Was sent to the sv-ec for review by the Working Group The sv-ec chose to take no action at this point in time. - Was sent back to the svac from the champions The proposal was updated and approved by the svac. - 2008-02-05: voice vote to approve the proposal dated 2008-01-31. 8y/0n/0a Brad - was our feedback addressed? John - see his note Move: Brad - approve the proposal for Mantis item 1648 Second: John Passed unanimously 24. 1601 SV-AC new keyword for untyped formal arguments [updated my notes] - fixed - Feedback was provided by the svbc - Sent back to the committee by the Champions Was updated and approved by the svac. - Failed to pass in the Champions email vote Updated and approved by the committee - Was sent to the sv-ec for review by the Champions The svec chose not to take any action at this point in time. Neil - 1549 is now approved John - some of the changes are made to 1549 - the proposal introduces the untyped keyword Move: Brad - approve the proposal for Mantis item 1601 Second: John Passed unanimously 25. 1599 SV-AC The assertion API and VPI sections need changes as per mantis #805 - fixed - made changes for the cc - approved by the cc John - this is all vpi related Move: Brad - approve the proposal for Mantis item 1599 Second: John Passed unanimously 27. 1340 SV-BC inconsistency between module ports and task arguments [updated my notes] - fixed - svbc has reapproved the proposal - On August 20, 2007 the SV-BC unanimously voted to accept the proposal. - 1 no vote from Champions email vote of Sept 17, 2007. - Unofficial explanation: (from Shalom) At the last meeting of SV-BC, the committee decided to re-approve the proposal as is. With respect to the Champions' feedback bringing up larger issues, SV-BC decided not to address them within the scope of 1340, but rather to open a new Mantis (maybe two) that addresses them, but time does not allow them to be resolved now. New Mantis item is 2273. - On February 4, 2008, the SV-BC unanimously approved the proposal. - Part of the Champion's email vote ending Feb 23. For: Brad, Francoise, Surrendra, Shalom, John No: Stu Stu This change is not backwards compatible, at least the way I interpret it. The new text "then the default data type is logic if it is the first argument or if the argument direction is explicitly specified" implies that even when a data type has been specified, the next time a direction is given, the previously defined data type is dropped, and the data type is changed to "logic". I don't think that is how current implementation work. Also, what if "ref" is specified instead of a direction? - Shalom mentioned that he wasn't sure what state it should be in 03/08/08 Mantis 1465 deals with some of John's feedback on 1340. 1465 is covered under the heading of "champions feedback". Shalom - had some offline correspondence with Stu. Feels that Stu is now ok with it. Move: Shalom - approve the proposal for Mantis item 1340 Second: Brad Passed unanimously 28. 1230 SV-CC How to represent packed arrays of complex types in VPI - fixed - The proposal PASSED the SV-CC as amended on 02/27/2008 (unanimous). Move: Brad - approve the proposal for Mantis item 1230 Second: Dave Passed unanimously Checker related mantis items: ---------------------------- The svec provided feedback to the svac and the Working Group on the checker-related proposals. Below is a copy of the list of Mantis items that the svec thought should be reviewed as a group. Neil requested input from the Champions that could be brought to the Working Group meeting that will be held next week. List from the svec ------------------ 1 1900 - on agenda - this is the checker proposal * 2 1549 - approved by WG * 3 1681 - approved by WG * 4 1648 - on agenda - default reset for assertions * 5 1728 - already approved by champions * 6 1682 - approved by WG 7 2088 - on agenda 8 2089 - on agenda List of additions from Champions (not on the svec list) ------------------------------------------------------ 9 2110 - on agenda 10 2182 - vpi for checkers 11 1995 - in loops - it is related (checkers in for-loops) * - Mantis items that 1900 depends on (they don't depend on 1900). Stu - These are huge changes that require a lot longer amount of time to be reviewed and studied by the other committees to understand the impact to the rest of the language. There appears to be a lot of impact to the rest of the language Dave - We should make a recommendation to the Working Group to form a new technical sub-committee to address checkers. The sub-committee should be composed of members from all 4 of the TC's including the svcc. Bouncing proposals back and forth between committees is not productive. John - not sure that all items on the svec list are related to checkers. 1549, 1681, 1648, 1682, 1728 - these have no dependencies on checkers Shalom - 1900 has a note in it: 1549 is listed (among others) - The 1900 proposal assumes the others already exist. The dependency is only one-way and only weakly. John - 1549 stands on its own, it isn't dependent on 1900. - There are many examples in 1900 that rely on changes in other proposals(e.g. let). 1900 depends on 1728. A one-way dependency. Brad - If a proposal is already approved it shouldn't be given to another group. Move: John - request the svac to redo the relationships for 1900. Second: Brad Passed unanimously Move: Dave - recommend that the Working Group create a new sub-committee to address the checker related proposals, there should be members from all 4 of the Technical Committees. Second: Francoise Passed unanimously 31. 1900 SV-AC Add new 'checker' construct to SVA - Fixed - Proposal failed in Champions email vote ending on Feb 4 - 2 no-votes (Dave, Shalom), 1 abstain (John) - Dave - This proposal needs to be addressed when it can have the full attention of all the committees as effects every part of the language. Otherwise, I feel that this enhancement goes beyond the level of enhancements authorized by the P1800 PAR in embedding a new language with SV. The number of keywords and statements being introduced can not be thoroughly reviewed with the resources we have for the current par. A suggestion would be to call a join meeting to have the SV-AC present this proposal to members of all the other committees as part of a design review. - Shalom - Sent a lot of feedback to the sv-ac (in 5 parts). - John - had quite a few friendly amendments - The proposal was updated based on feedback from the champions - 2008-02-28: Voice vote 7y/0n/0a to approve the 2008-02-27 .pdf version, parts 1 and 2. <not addressed - part of the set of checker-related proposals> 32. 2089 SV-AC Allow checker construct (0001900) to include final blocks with immediate assertions - fixed - Made changes requested by the svec - 2008-02-27: e-mail vote passed, 6y/0n/3a <not addressed - part of the set of checker-related proposals> 33. 2088 SV-AC Allow Checker construct (0001900) to include covergroups - fixed - Made changes requested by the svec. - 2008-02-28: Voice vote 7y/0n/0a <not addressed - part of the set of checker-related proposals> 34. 2110 SV-AC Allow checkers in procedural for loops - fixed - related to checkers - Dependency on 1900 and 1995 being approved (1995 was approved) - 2008-02-11: Passed by e-mail vote, 5y/0n/4a. There were friendly amendments. - Friendly amendments approved by voice vote on 2008-02-12, 8y/0n/0a. - Part of the Champion's email vote ending Feb 23. For: Francoise Abstain: Brad - depends on 1900, which is still in feedback state Shalom - I think this should be postponed till approval of 1900. Francoise No: Stu, John Stu Checkers is too big of a change to the standard to be added at this late date. Checkers affect, or are affected by, many different parts of the standard. All SV committees need several weeks to study the impact of checkers. John Rationale for negative vote: I think that 2088 is changing in response to comments from SV-EC in a way that will not be consistent with the conditional changes on pp. 4-5. In particular, I am concerned about whether a covergroup declaration will be allowed in a checker. Friendly amendments: John - Smart quotes should not be used in the courier examples. - In the example beginning at the bottom of p. 2, the sampled value of ok is 1'b1 in the first timestep in which there is a posedge of clk due to the initialization assignment. It is true, although perhaps misleading, to say that the sampled value is always equal to (my_bits[3] == 0). This assumes, of course, that no other code updates my_bits. The declaration of control_variable_copy is not shown, and we do not know what its sampled value is in the first timestep in which there is a posedge of clk. <not addressed - part of the set of checker-related proposals> Additional mantis items that are now in the resolved state: ---------------------------------------------------------- 35. 2243 sv-ec issue with option.per_instance - fixed - The proposal was unanimously approved by the sv-ec in the March 17, 2008 conference call. Move: Dave - approve the proposal for Mantis item 2243 Second: Brad Passed unanimously 36. 677 sv-bc Ballot Feedback Issue 264: unique/priority violation should be errors - duplicate - On March, 3 2008 the SV-BC voted to resolve this issue as a duplicate of issue 2008, with one opposed Stu opposed - he believes the violations should be errors. Move: Dave - approve the resolution of duplicate for Mantis item 677 Second: Brad Passed unanimously 37. 1709 sv-bc How to use the stream operator in an expression - no change required (was fixed) - Resolution of this issue as addressed by 1707 was unanimously approved by the SV-BC via e-mail vote that closed Feb 29, 2008. Move: Dave - approve the resolution of 'no change required' for Mantis item 1709 Second: Brad Passed unanimously 38. 1526 sv-bc Streaming concatenation, like assignment pattern, has no self-determined type - no change required (was fixed) - Resolution of this issue as addressed by 1707 was unanimously approved by the SV-BC via e-mail vote that closed Feb 29, 2008. Move: Brad - approve the resolution of 'no change required' for Mantis item 1526 Second: Dave Passed unanimously 39. 1769 sv-ac Elaboration time user assertion and error reporting tasks - fixed - Failed to pass the Champions email vote ended on Feb 23, 2008. The proposal was updated and approved by the sv-ac. - Passed by voice vote on 3/10/08: 6y/0n/0a Dave - was it reviewed by bc? John - the bug notes show that there was bc feedback. Dave - it is currently in an svbc email vote..... Move: Brad - approve the proposal for Mantis item 1769 contingent upon svbc approval. Second: Shalom Passed unanimously Additional list from Shalom --------------------------- 40. 2008 sv-bc Glitch problem in unique/priority if/case - fixed - approved by the SV-BC on March 17, 2008 with one opposed and two abstain Opposed: Stu (ambiguous severity level will lead to implementation differences that will be problematic for users) Abstain: Heath (agrees with Stu but no enough to oppose) Alex (joined the conversation late) Brad - Stu voted against it (he wasn't on-line at this point). 41. 1111 sv-bc 1364-2005, 12.3.3 -- port direction declarations that don't mention the size of port - no change required - March 17, 2008 the SV-BC unanimously approved to resolve this issue with no change required. 42. 927 sv-bc Tagged union expression and casting - fixed - March 17, 2008 the SV-BC unanimously approved Brad - a one word change 43. 1829 sv-bc JEITA: 6.8 we believe that usually logic [31:0] would be little endian. - fixed - March 17, 2008 the SV-BC unanimously approved Move: Brad - approve the proposals for Mantis items 1829, 927, and the resolution of 'no change required' for 1111 Second: Shalom Passed unanimously Additional mantis items that the svac is updating based on Champions feedback The sv-ac chair requested the Champions to review, in case the sv-ac is able to resolve before the champions conference call. ----------------------------------------------------------------------------- 44. 2069 SV-AC Formal semantics for coverage is missing - was sent back to sv-ac. John - was approved this morning. 1 friedly from email vote - has the Champions feedback Move: Brad - approve the proposal for Mantis item 2069 Second: John Passed unanimously 45. 1932 SV-AC Introduce LTL and other temporal operators [added to my notes] - was sent back to the sv-ac. John - Has issues with new keywords next --> next_time All other new keywords were left in the proposal. Mantis items in the resolved state which do not need to be on the agenda ------------------------------------------------------------------------- 1. 2250 SV-AC VPI changes related to 1932 waiting for input from the svcc 2. 2182 SV-AC Elaborate VPI diagrams for checkers waiting for input from the svcc Erik has sent out an update - 03/10/08 3. 2168 SV-AC Formal semantics for edge-sensitive clocks Has already been approved by the Champions - needs to go to Working Group 4. 2163 SV-BC Clarify hierarchical scopes created (or not) by for and foreach loops Was already approved by Champions with friendly amendments. It is now ready for the working group. 5. 2150 SV-AC use of automatic variables in action block and subroutine calls should not be allowed Was already approved by Champions with friendly amendments. It is now ready for the working group. 6. 2091 SV-AC Need a clarification where concurrent assertions may appear - fixed - was approved by champions with friendly amendments 7. 1987 SV-AC Change "verification statement" to "assertion" or "assertion statement" and add to the glossary - fixed - already approved by the champions (with friendly amendments) --> - Shalom 03/13/08 Mantis 1806 introduces the restrict property assertion statement. Mantis 1987 does not seem to take this into account. 8. 1728 SV-AC Introduce "let"statement - fixed - was already approved by the champions 9. 1447 SV-EC Contradictory stmts about unsized array dimensions (5.1 vs. 5.7 and 5.8) - was already approved by the champions List of Mantis items that were handled in the March 13, 2008 conference call ---------------------------------------------------------------------------- 1. 2219 SV-BC not clear whether continuous assignment of event is allowed Passed unanimously in March 13, 2008 conference call. 2. 2173 SV-AC Add case construct for properties. Passed with one opposed. <now back in feedback state...> Mantis 2333 was created for the Champions feedback on 2173. 3. 2106 SV-BC Clarifications needed for declaration before use of objects Passed unanimously 4. 2100 SV-AC Add synchronous resets syntax as oppose to the asynchronous Passed unanimously with Shalom's friendly amendment. <now in feedback state> 5. 2097 SV-BC release/deassign with variables driven by continuous Passed unanimously 6. 2069 SV-AC Formal semantics for coverage is missing Sent back to sv-ac. <now in feedback state> 7. 2043 SV-BC $cast should appear in 19.5 Conversion functions Passed unanimously - resolution of 'no change required' 8. 2005 SV-AC Solution for glitch problem in immediate assertions Passed with one abstain (with a friendly amendment). 10. 1932 SV-AC Introduce LTL and other temporal operators [added to my notes] Sent back to the sv-ac. <now in feedback state> All of the following are duplicates of other Mantis items. 9. 1982 SV-AC 16.7: Description of actual arguments is unclear and maybe 12. 1852 SV-AC Ballot Feedback Issue STU2: Declarations on Assertions 13. 1849 SV-AC Update VPI object diagrams for immediate assume, cover 15. 1833 SV-AC JEITA: 16.3 Precise definition of immediate assertion 19. 1786 SV-AC Definition of "if else" in Annex F seems broken 26. 1564 SV-BC 4.16, glossary: inconsistent definitions of bit-stream type 29. 0588 SV-CC 31.9 uses the term "user", and has grammatically incorrect 30. 0587 SV-CC 31.8.7 Please replace the term "user" with a more accurate term 3. Next meeting March 27 - Thursday Working Group meeting April 10 - Thursday 8-10 PDT --Boundary_(ID_pgalo6DWXwWe97XkgGwA0w)-- ------- End of forwarded message ------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun Mar 23 08:18:45 2008
This archive was generated by hypermail 2.1.8 : Sun Mar 23 2008 - 08:19:40 PDT