FYI, I sent this email to the sv-ac a few minutes ago. Neil -------- Original Message -------- Subject: [sv-ac] Feedback from the Champions Date: Mon, 20 Aug 2007 18:38:43 -0700 From: Neil Korpusik <Neil.Korpusik@Sun.COM> Reply-To: Neil.Korpusik@Sun.COM To: sv-ac@eda.org sv-ac, The Champions held 3 meetings over the course of the past few weeks. Attached are the results of those meetings for mantis items that have been approved by the sv-ac. I am working with the Champions to set up an email vote on proposals that the sv-ac and sv-ec can get done by this Wednesday. We are doing this to see if we can squeeze some additional mantis items through to the Working Group at the last minute. It isn't clear how the Working Group will react to a set of last minute changes, but we are attempting to get as many done as possible for draft 4 of the LRM. The svac mantis items reviewed by the Champions fall into several categories. Mantis items passed by the Champions as shown in the latest proposals ---------------------------------------------------------------------- - These have been forwarded onto the Working Group for review "as-is" 1460 Allow actions within assume property statement 1674 Context value functions 1677 Add $changed sampled value function 1730 Allow literal sequence and property actual arguments 1734 Incomplete fix to Annex F in 0805. 1735 Incomplete fixes from 0928 1361 need a way to control execution of action blocks Mantis items passed by the Champions after making friendly amendments ---------------------------------------------------------------------- - The friendly amendments should be made by the sv-ac, approval by the Champions is contingent upon these changes being made. 1550 $sampled function definition 1567 22.9: in Syntax 22-7, should be no semicolon 1722 there exists bind inconsistencies between the BNF and the text Mantis items sent back to the committee for updates: ---------------------------------------------------- - The Champions found issues with each of these. Details are in the attachement. 1591 17.7.3, 22.9: $past syntax not precise 1704 need to specify behavior of attached subroutine on empty seq match 1601 new keyword for untyped formal arguments 1648 Default reset for assertions (default disable) 1729 Introduce immediate assume and cover statements 1768 need to define how to interpret whether the argument to cover is a Mantis items rejected by the Champions -------------------------------------- - Details are shown in the attachment 1466 shortcuts for delay and consecutive repetition Mantis items that should be closed -------------------------------------- - No further action is required of the sv-ac on this 1543 Meaningless sentence in 17.15 and Annex H Mantis items that the Champions wanted more time to discuss with others ----------------------------------------------------------------------- - This mantis item will be discussed at the next meeting of the Champions which is currently scheduled for Sept. 5 1681 Introduce global clocking Neil -- 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. Mantis items passed by the Champions as shown in the latest proposals ---------------------------------------------------------------------- Id Summary 1460 Allow actions within assume property statement svac approved unanimously (only 8 of 10 voted) 1674 Context value functions $inferred_clock, $inferred_disable, $inferred_enable svac approved unanimously by email vote 06/25/07 1677 Add $changed sampled value function svac approved unanimously - 02/06/07 meeting 1730 Allow literal sequence and property actual arguments svac Resolved by ballot, 2007-04-30, 7y, 0n, 2a Updated for draft 3a July 24 1734 Incomplete fix to Annex F in 0805. svac Resolved by e-mail ballot on 2007-04-30, 7y/0n/2a Updated for draft 3a July 19 Abstain: Brad - not qualified to review this proposal Francoise - same reason Passed with two abstains 1735 Incomplete fixes from 0928 svac Resolved by email ballot, 2007-03-14, 9 yes, 0 no Updated for draft 3a July 21 1361 need a way to control execution of action blocks svac Passed by e-mail ballot on 2007-07-31, 7y/0n/1a Friendly amendment added during e-mail ballot was confirmed by voice vote on 2007-08-07, 8y/0n/0a. Mantis items passed by the Champions after making friendly ammendments ---------------------------------------------------------------------- Id Summary 1550 $sampled function definition svac approved unanimously 02/14/07 7 yes, 3 not voting 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. 1567 22.9: in Syntax 22-7, should be no semicolon svac 2006-12-08. Unanimously approved. Friendly amendments: 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 1722 there exists bind inconsistencies between the BNF and the text svac Passed by e-mail vote on 2007-07-31, 8y/0n/0a Friendly ammendments: (correct the spelling and capitalization problems) - spelling error - 22.10 (auxiliary has only on 'l') more than one occurrence (at the end) - Item 1) if the... capitalize the if identifier is spelled wrong (3 times) Mantis items sent back to the committees for updates: ----------------------------------------------------- 1591 17.7.3, 22.9: $past syntax not precise svac approved unanimously by email vote 02/14/07 Updates required: Has similar issues as those flagged for 1550. - Update the part about $sampled (see feedback for mantis 1550) - Rename or remove old proposals. 1704 need to specify behavior of attached subroutine on empty seq match svac approved unanimously by email vote 03/01/07 Three changes need to be made: - "must not admit" should be "shall not admit" - Get rid of commas in the next to last sentence. - When used on a sequence that admits an empty match an error message shall be issued. [The sv-ac should determine the appropriate wording for this error case.] 1601 new keyword for untyped formal arguments svac Passed by e-mail vote on 2007-07-31, 8y/0n/0a This is an enhancement - 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. - 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? - 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. - doesn't like adding new keywords using the word context in a different way here (not good either). - 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. - 'untyped' could possibly be used in place of context - 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. Resolution from Champions: Send 1601 back to the sv-ac to use 'untyped' in place of 'context' and request a justification for the proposal. 1648 Default reset for assertions (default disable) svac unanimously passed by email vote 06/25/07 - 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. - there may be other places that could use it as well. - 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). Set of issues: - The bnf shouldn't be in the text. - 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. - First paragraph - should be reworded "One can specify..." --> "A default disabling condition may be..." Resolution from Champions: Send 1648 back to svac with this set of 3 concerns. 1729 Introduce immediate assume and cover statements svac Resolved by e-mail ballot on 2007-04-30, 9y/0n/0a Updated for draft 3a July 19 The following set of changes need to be made to this proposal: - 16-1 syntax was changed since this mantis item was updated action_block ::= else <--- is now null - The () in the syntax box should be in red - On bottom of page 2 - example - assume and cover need bolding - Add a note to the editor in the proposal to not change the action_block syntax. - Syntax A.6.10 immediate_assert_statement ::= <--- use a different name here - Should be more generic since it has 3 choices Dave suggests immediate_assertion_statement. immediate_assert --> immediate_assert_statement immediate_assume --> immediate_assume_statement immediate_cover --> immediate_cover_statement Compare this to the syntax in A.2.10 - Syntax box on page 2 - has different set of blue items vs. A.6.10 - 16.3 , 2nd paragraph is new -- needs to be blue , 4th paragraph assert should be bold - Paragraph after 16-1 - should be bold for assert. 2nd paragraph Stu thinks this sentence might be ok. - make bolding consistent for this whole section - there seem to be some grammar errors as well. 1768 need to define how to interpret whether the argument to cover is a property or sequence svac Passed by e-mail vote on 2007-07-31, 8y/0n/0a. Voice vote on 2007-08-07 to confirm friendly amendment suggested during e-mail ballot, 8y/0n/0a. - missing a friendly amendment? - has changes dependent on 1599 Send mantis item 1768 back to the svac so that they can add the missing friendly amendment [Discussion after the vote - some people dropped off the line already] It looks like the amendment is actually there. Resolution from Champions: Can the sv-ac check to make sure that the friendly ammendment is there? Mantis items rejected by the Champions -------------------------------------- Id Summary 1466 shortcuts for delay and consecutive repetition svac Resolved by voice vote on 2007-05-01. 7y/0n/1a 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. - It is hard to put a focused effort on this type of issue. We need more time to work out the issues. - If just a shortcut, we don't need it. - '?' in a UDP means don't care, ==? wildcard - If it was a PSL conflict that would be a stronger reason to add it - ? is not in PSL - 1,$ is a pop operation for a queue - covergroups may also be inconsistent. - If we allow shortcuts they should be uniformly applied throughout the language. - should be similar to verilog, e.g. designers. We don't need a new syntax. - no added capability - Obfuscates the code - means different things in different contexts. Mantis items that should be closed -------------------------------------- Id Summary 1543 Meaningless sentence in 17.15 and Annex H svac Unanimously approved 2006-12-08 Champions think the changes are already in the lrm. Should be closed Mantis items that the Champions wanted more time to discuss with others ----------------------------------------------------------------------- 1681 Introduce global clocking svac Passed by e-mail vote on 2007-07-31, 8y/0n/0a. - The proposal doesn't discuss what the global clock is with respect to compilation units - there is no concept of globals in SystemVerilog - it should be a tool option - strange that it is global and needs to be in a module, it should be in compilation unit space - not sure it fits in with the general usage of the language. The lrm is based on event based simulation - if in a package would need to be imported - not sure why need this global thing, we already have clocking blocks. - The proposal says that global clock is for the design. Can the testbench use the global clock? (proposal seems to not say) - proposal shouldn't use the term design if it isn't clearReceived on Mon Aug 20 18:42:10 2007
This archive was generated by hypermail 2.1.8 : Mon Aug 20 2007 - 18:42:13 PDT