The details are attached. Please vote as early as possible. Thanks, Neil -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions, Thank you for agreeing to hold a 5-day email vote. Below is the list of mantis items that we are voting on. Each of these was on the agenda in one of the previous 3 Champions meetings. The Champions made friendly ammendments for some of them. Others were sent back to the committees for updates or further review. There was one that was rejected by the Champions. The technical committees have made changes in response to the Champions feedback and would like to have the Champions re-vote them. Please mark each mantis item with your vote. If you vote no, you must provide a reason. I would like you to also provide a reason if you decide to abstain. ***> This email vote will end at 5pm PST, Aug 29 <*** SV-AC Mantis items passed by the Champions after making friendly ammendments Yes ___ No ___ Abstain ___ 1550 Friendly ammendments added, approved by svac Yes ___ No ___ Abstain ___ 1567 Friendly ammendments added, approved by svac Yes ___ No ___ Abstain ___ 1722 Friendly ammendments added, approved by svac SV-AC Mantis items sent back to the committees for updates: Yes ___ No ___ Abstain ___ 1591 Revised, passed by email ballot 7y/0n/2a Yes ___ No ___ Abstain ___ 1601 Revised, passed by email ballot 8y/0n/1a Yes ___ No ___ Abstain ___ 1704 Revised, passed by email ballot 8y/0n/1a Yes ___ No ___ Abstain ___ 1729 Revised, passed by email ballot 7y/0n/2a Yes ___ No ___ Abstain ___ 1768 Reviewed by LP, DB, JH., no change needed SV-AC Mantis items rejected by the Champions Yes ___ No ___ Abstain ___ 1466 Revised, passed by e-mail ballot 6y/0n/3a SV-EC Mantis items passed by the Champions after making friendly ammendments Yes ___ No ___ Abstain ___ 1789 Friendly ammendments were added SV-EC Mantis items sent back to the sv-ec for updates and further review Yes ___ No ___ Abstain ___ 1787 changes by the Champions were made Yes ___ No ___ Abstain ___ 1777 changes by the Champions were made Yes ___ No ___ Abstain ___ 1736 changes by the Champions were made Yes ___ No ___ Abstain ___ 1723 changes by the Champions were made Yes ___ No ___ Abstain ___ 1680 changes by the Champions were made Yes ___ No ___ Abstain ___ 1655 changes by the Champions were made Yes ___ No ___ Abstain ___ 1615 changes by the Champions were made Yes ___ No ___ Abstain ___ 1612 changes by the Champions were made Yes ___ No ___ Abstain ___ 1609 changes by the Champions were made Yes ___ No ___ Abstain ___ 1605 changes by the Champions were made Yes ___ No ___ Abstain ___ 1580 changes by the Champions were made Yes ___ No ___ Abstain ___ 1556 no changes were needed Yes ___ No ___ Abstain ___ 1545 section numbers were updated Yes ___ No ___ Abstain ___ 1480 no changes were needed Yes ___ No ___ Abstain ___ 1427 section numbers were updated Yes ___ No ___ Abstain ___ 1371 no changes were required Yes ___ No ___ Abstain ___ 1336 section numbers were updated Yes ___ No ___ Abstain ___ 888 section numbers were updated Yes ___ No ___ Abstain ___ 594 section numbers were updated Below I am showing what actions have been taken by the committees in response to the feedback from the Champions, along with a summary of the feedback that was sent to the committees. Neil RESULTS OF SV-AC ACTIVITY IN RESPONSE TO FEEDBACK FROM THE CHAMPIONS Mantis items passed by the Champions after making friendly amendments ---------------------------------------------------------------------- - The svac has made the friendly ammendments and then re-approved the new proposals. 1550: Revised, passed by e-mail ballot 2007-08-24, 5y/0n/4a. Revised proposal is Sampled1550.070822.pdf in Mantis. 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: Revised, passed by voice vote 2007-08-21, 7y/0n/0a. Revised proposal is proposal-1567-2007-08-21.doc in Mantis. 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: Revised, passed by e-mail ballot 2007-08-24, 7y/0n/2a. Revised proposal is 1722-bind_clarifications_draft3a-3.pdf in Mantis. 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 committee for updates: ---------------------------------------------------- - The sv-ac made the set of changes specified by the champions and re-approved the new proposals. 1591: Revised, passed by e-mail ballot 2007-08-24, 7y/0n/2a. Revised proposal is proposal-1591-2007-08-22.doc in Mantis. 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. 1601: Revised, passed by e-mail ballot 2007-08-24, 8y/0n/1a. Revised proposal is 1601_3.pdf in Mantis. - 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. 1704: Revised, passed by e-mail ballot 2007-08-24, 8y/0n/1a. Revised proposal is 1704_5.pdf in Mantis. 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.] 1729: Revised, passed by e-mail ballot 2007-08-24, 7y/0n/2a. Revised proposal is ImmediateAssertAssumeCover1729_070822.pdf in Mantis. 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: Reviewed by LP, DB, JH. There was only one friendly amendment and that was incorporated. No revision is required. - 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 -------------------------------------- - The sv-ac has revised the proposal and re-approved it 1466: Revised, passed by e-mail ballot 2007-08-24, 6y/0n/3a. Revised proposal is 1466_shortcuts.pdf in Mantis. 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. RESULTS OF SV-EC ACTIVITY IN RESPONSE to FEEDBACK FROM THE CHAMPIONS They are all updated to draft3a and correspond to the discussions we had during last meeting. 1336 - Dave Rich updated it. Mantis items passed by the Champions after making friendly ammendments ---------------------------------------------------------------------- Id Summary 1789 Clarification of string behavior svec Passed unanimously by email vote June 22, 2007 was updated 8/16 for draft 3a Neil updated it so that it is move obvious to the Editor what is to be changed in section 2. of the proposal. 8/24/07 The latest proposal is SV-1789_for_champions.pdf Friendly ammendments: - "1. Change this sentence (on page 128)": in Draft 3a, this is page 126. - In 2, " bit [10:0] a = "\x41"; // assigns to a `b000_0100_0001": the back-tic in the comment preceding 'b' should be an apostrophe. - In 4, "one of them can be a string literal which is implicitly converted to a string type data object for the comparison": this appears twice, there should be a comma before the word 'which'. Mantis items sent back to the sv-ec for updates: ------------------------------------------------ 1787 LRM needs to discuss transition bins of length 1 svec Approved on April 30, 2007 unanimously. Was updated on 8/19 with changes from the Champions incorporated. - 1787 should refer to 18.5.1 instead of 18.4.1. - The mantis "Additional info" section refers to sv-178702.html but that attachment was not found - There was an approved friendly amendment ("shall be illegal") That update is not in the current proposal. 1777 Clarification of 1800-2005 section 18.4.1 svec Approved on April 30, 2007 unanimously. Was updated on 8/20/07 with changes from the Champions incorporated. All of the Champions feedback was incorporated except for the last item. - 1777 is not updated to Draft 3a. It refers to 18.4.1 in 1800-2005, which is apparently 18.5.1 in Draft 3a - The struck-out text starts with "The goto repetition with nonconsecutive occurrence", but I don't see the word "goto" in the original. There may be other differences. - The capitalization of 'goto' in the proposal is inconsistent. In Draft 3a, it seems to be consistently uncapitalized. - The intransitive "will increment" is inconsistent with the rest of the paragraph that says bins are "incremented". - It's a little odd that it says "Next, ..." regarding what happens on the 15th-18th samples, and only after that talks about what happens on the 12th-13th samples. 1736 Example in 12.4.2 has dynamic array packed. svec Approved on April/24/2007 unanimously by email vote. The proposal was not updated, as none were required. The mantis summary description was updated, as requested. - Would be nice to change xref in Mantis summary line to 13.5.2. 1723 Size method for associative arrays svec Approved on June/11/2007 with 2 No votes: Cliff - doesn't think of size as being the number of elements, thinks of it as the address spanned, encompassed by elements already allocated. Stu - no change needed Was updated 8/15/07 with the correct section number. The suggested grammar change was not made, the sv-ec felt that this change was not needed (8/20/07). - The reference should be to 7.10.1 instead of 17.10.1. - Grammar issues "The syntax for the num() and size()methods are as follows:" should be "The syntax for the num() and size()methods is as follows:" 1680 "literal string" should be "string literal" svec Approved on April/24/2007 unanimously by email vote. Was updated 8/16/07 with the correct section number. The sv-ec did not see any other changes that were required (8/20). - 1680 was not updated to Draft 3a. - There are text as well as section number issues. 1655 Coverage Calculation Corner Case Crumminess svec Approved on April 30, 2007 unanimously. Was updated 8/20/07 with the feedback from the Champions incorporated. 1. The title line of the proposal says 18.10, but it should be 18.11 (or 18.6 and 18.11). 2. Similarly, the line "ADD the specified blue text 18.5 as follows:" should refer to 18.6. 3. "intersect cross-products specified" should not be hyphenated, for consistency with LRM. 4. In "since the explicitly declared bins covers all cases for which i == 0", "bins" should be "bin". 5. "ADD the specified blue text to 18.5.1 as follows:" should refer to 18.6.1. 6. In "Additionally, the cross retains those automatically-generated bins that represent cross-products not intersecting any of the user-defined bins. There are 6 of these: <b1,a3>, <b1,a4>, <b3,a3>, <b3,a4>, <b4,a3>, and <b4,a4>," "cross-product" should not be hyphenated, and the cross products should be specified with a before b, e.g., <a3,b1> instead of <b1,a3>. 7. "MODIFY 18.6 as follows:" should be 18.7. 8. "In Table 18-29, the alignment of the cell bodies in the top three rows is not consistent with the rest of the table. The six inconsistent cells should be modified to match the rest of the table" looks already fixed in Draft 3a. 9. "MODIFY 18.10 as follows:" should be 18.11. 10. "d) If get_coverage or get_inst_coverage are called with two arguments, zero is assigned to both arguments; the numerator and denominator." should be "is called". Yes, I know the mistake is in the existing text. 11. "In consistency with the above behavior, $get_coverage shall return a value of 100.0 if called on a design that has no constructed covergroups, or if called on a design in which all covergroups have a weight of 0." "In consistency with" sounds strange. "Consistent with" sounds better. "$get_coverage" should be "get_coverage()"? What is a "constructed covergroup"? The term does not seem to appear in the LRM. Is there a non-constructed covergroup? If not, why not just 'covergroup'? 12. "MODIFY 18.10.1 as follows:" should ne 8.11.1. 13. "ADD the following text at the very end of 18.10.2:" should be 8.11.2. 14. "In case the denominator of the cross coverage calculation formula has a value of zero:" - Better is "If the denominator ..." 15. "d) If get_coverage or get_inst_coverage are called with two arguments, zero is assigned to both arguments-the numerator and denominator." - should be "is called". 1615 can processes spawned by functions execute blocking statements? svec Approved on October/23/2006 unanimously. Was updated 8/22 with the feedback from the Champions incorporated. The svec decided to leave it as a 4th-level subclause. The svec also decided that the existing wording was correct. The problem with the example was fixed. A new typo was accidentally introduced into the new proposal. I have requested a fix. from: sided effect to: side effect - This proposal wanted to add 11.6.1 (in 1800-2005) after 11.6. The text from 11.6 is now in 9.3.2. I don't like 4th level subclauses (9.3.2.1), so I am not sure where and how to place this. - The following sentence seems hard to understand: "Calling a function that executes a fork..join_none block shall be illegal in any context in which a side effect is disallowed or any context other than procedural code originating in an initial block." I think the following would be simpler: "Calling a function that executes a fork..join_none block shall be legal only in procedural code originating in an initial block and illegal in any context in which a side effect is disallowed." (Is there a difference between "originating in an initial block" and "in an initial block"? If so, are readers going to understand the difference?) - Is the following sentence needed: "Implementations shall issue an error either at compile time or run time when they have determined the illegal condition.?" - The function declaration is called start_check, but the function calls start_checks. 1612 Timeunits decls don't make sense in class decls (BNF) svec Approved on May 2,2007 unanimously by email vote. Was updated on 8/16 with the correct section numbers. Reference to Syntax 7-1 should be 8-1. Footnote 17 should be footnote 16. 1609 import statements should not be allowed in class scopes svec Approved on June/25/2007 unanimously. Was updated 8/20 with the correct section number. 25.2 should be 25.3. 1605 Clarification of mailbox/semaphore constructor svec Approved on October/23/2006 unanimously. Was updated with the corrected section numbers 8/20. The text being marked as struck out is not the actual text in the LRM. I requested this to be fixed 8/24. The references should be 15.3.1 and 15.4.1 1580 Access to interface objects via virtual interface svec Approved on May 2, 2007 unanimously by email vote. Was updated with the corrected section number 8/15. The wording wasn't changed since the sv-ec went through several iterations to converge on the correct wording. - 20.9 should be 24.10. - "Access to all objects declared in an interface is always available by hierarchical reference, regardless of whether the interface is accessed through a port, through a virtual interface, or if there are modports to restrict those access mechanisms." I think "if" should also be "whether". - "When an interface is connected with a modport in either the module header or port connection, access through a port or through a virtual interface is limited to only objects listed in the modport, for only types of objects legal to be listed in a modport (nets, variables, tasks, functions, and clocking blocks). All other objects may be referenced." I find this wording very unclear. It is unclear what "all other objects" refers to, and it is unclear how they may be referenced. - The original text had, "All objects are still visible by hierarchical reference." This seemed to repeat the first sentence, "Access to all objects declared in an interface is always available by hierarchical reference," and if so, to be redundant. Does this proposal intend to change the meaning of the last sentence? - I also find the difference between "module header" and "port connection" unclear, since I think of port connections as part of the module header. 1556 in-line static variable initialization - require keyword static? svec Approved on June/11/2007 unanimously. No updates were needed. 1545 13.12.1: $urandom example error svec Approved on October/9/2006 unanimously. Was updated 8/20/07 with the corrected section number (17.13.1). 1480 method_call_root BNF should use primary, not expression svec Approved on October/9/2006 unanimously. No updates were needed. 1459 Mailbox 'new' method should never return null svec Approved on September/11/2006 unanimously. This appears to be a duplicate of 1605. <not added to the email vote since it is a duplicate> 1427 dynamic_array_new svec Approved on April 30, 2007 unanimously. Was updated 8/16 with corrected section numbers. A new typo was introduced when the proposal was updated. From: type of this operation To: type of this operand The formating was also messed up on this text. I requested a fix for this problem 8/24. 1371 Semantic of program block $exit svec Approved on June/25/2007 unanimously. No changes were required. 1336 Rules for allowed statements in a function svec Approved on Jan/22/2007. unanimously. Was updated 8/22 with the correct section numbers. Original proposal says "add a new section 12.3.4" New one says add a new section after 13.4.4 and the new section is still shown as 12.3.4. I have requested this change to be made. 888 foreach identifiers are too restrictive svec Approved on October/23/2006 unanimously. Was updated 8/20 with the section numbers corrected. 594 15.8 special syntax for accessing interfaces through clocking block svec Approved on October/9/2006 unanimously. Was updated 8/17 with the correct section numbers.Received on Fri Aug 24 17:06:53 2007
This archive was generated by hypermail 2.1.8 : Fri Aug 24 2007 - 17:06:56 PDT