SystemVerilog Working Group members, As a result of the 3 meetings of the Champions, there were several mantis items that were sent back to the technical committees. The sv-ac and sv-ec quickly responded to the Champions feedback by updating the set of mantis items in their committee that were flagged by the Champions. There were a small number that they didn't have time to react to. The Champions had agreed to conduct a 5-day email vote to consider this set of updated mantis items. That email vote concluded at 5pm PST. Attached is a summary of these results. The technical committees would appreciate it if the Working Group would consider allowing those mantis items that have now been approved by the Champions to be added to draft 4 of the LRM. 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. Results of the 5-day Champions email vote: All of those which had either a no vote or an abstain vote are marked with an "-->". SV-AC Mantis items passed by the Champions after making friendly ammendments: ----------------------------------------------------------------------------- 1. 1550 passed [Stu] friendly ammendments suggested 2. 1567 passed [Dave] the proposal should be in a pdf file 3. 1722 passed [Brad] friendly ammendments suggested SV-AC Mantis items sent back to the committees for updates: ----------------------------------------------------------- 4. 1591 passed [Dave] the proposal should be in a pdf file 5. --> 1601 failed Dave 6. 1704 passed 7. --> 1729 failed Shalom 8. 1768 passed [Brad] friendly ammendments suggested SV-AC Mantis items rejected by the Champions: --------------------------------------------- 9. --> 1466 abstain - Stu SV-EC Mantis items passed by the Champions after making friendly ammendments: ----------------------------------------------------------------------------- 10. 1789 passed SV-EC Mantis items sent back to the sv-ec for updates and further review: ------------------------------------------------------------------------- 11. 1787 passed [Brad] friendly ammendments suggested 12. 1777 passed [Brad] friendly ammendments suggested 13. 1736 passed 14. -->1723 failed Brad, Shalom 15. 1680 passed [Shalom] Suggested a new mantis to be opened. 16. 1655 passed [Shalom] friendly ammendments suggested 17. -->1615 failed Shalom 18. 1612 passed 19. -->1609 failed Brad 20. 1605 passed 21. -->1580 failed Shalom 22. -->1556 failed Brad, Shalom, Stu 23. 1545 passed 24. 1480 passed 25. 1427 passed 26. 1371 passed [Shalom] friendly ammendments suggested 27. -->1336 failed Shalom 28. 888 passed [Brad] friendly ammendments suggested 29. 594 passed <--------------< Details of the vote are summarized below >----------------> This email vote ended at 5pm PST, Aug 29 1. Brad - voted - feedback incorporated below 2. Dave - voted - feedback incorporated below 3. Shalom - voted - feedback incorporated below 4. Stu - voted - feedback incorporated below 5. Francoise - --- 6. Surrendra - --- 7. Neil - N/A SV-AC Mantis items passed by the Champions after making friendly ammendments: ----------------------------------------------------------------------------- 1. 1550 Friendly ammendments added, approved by svac [Stu] friendly ammendments suggested 1) All references to "preponed" should be "Preponed". This is to make the capitalization of event region names consistent with a change made by the SV-EC in another Mantis item, already incorporated in draft 3a. 2) The changes to clause 16.8.3 add in two places new text describing that $sampled returns default uninitialized values under certain conditions. I recommend that these two new descriptions end with a cross reference: "(see 6.7, Table 6-1)". [clause and table numbers per draft 3a] 2. 1567 Friendly ammendments added, approved by svac [Dave] the proposal should be in a pdf file 3. 1722 Friendly ammendments added, approved by svac [Brad] friendly ammendments suggested 9) The editor, when implementing 1722, change occurences of "bind instantiation" to "bind_instantiation" and occurrences of "interface instantiation" to "interface_instantiation". SV-AC Mantis items sent back to the committees for updates: ----------------------------------------------------------- 4. 1591 Revised, passed by email ballot 7y/0n/2a [Dave] the proposal should be in a pdf file 5. No 1601 Revised, passed by email ballot 8y/0n/1a no - Dave [Dave] I still believe this enhancement needs a thorough review across all committees. It adds additional complexity for what may be an interim solution. There still may be time for this in the 2008 LRM, but if not, the penalty for not approving this seems to be one of convenience. [Shalom] friendly ammendments suggested 1) From: "This semantics is described in Subclause 16.7." To: "This semantics is described in 16.7." 2) In "The formal arguments w and y of foo2 are untyped, while the formal argument x has data type bit," the word "bit" should be bold. 6. 1704 Revised, passed by email ballot 8y/0n/1a 7. No 1729 Revised, passed by email ballot 7y/0n/2a no - Shalom [Shalom] 1) The following text is unclear as to what behavior is only optional/recommended and what is required: "The immediate cover statement is used to detect the occurrence of specific signal values in the procedural code. The tools can collect such information in a database and then report the results at the end of simulation. The reporting should include the number of times the cover statement expression was true and in that sense it is equivalent to recording the success of an assert statement on the same expression. cover statements can also be used as search targets in formal tools. The results of a cover statement shall contain the following: - Number of times succeeded - Number of times failed" 2) Most of the text says "can", "should", but the last sentence says "shall". 3) Also, the following is confusing to the reader as it refers to the BNF without saying so: "In addition, statement_or_null is executed every time expression is true." And if so, 'expression' should be in a different font than the rest of the sentence as well as 'statement_or_null'. 8. 1768 Reviewed by LP, DB, JH., no change needed [Brad] friendly ammendments suggested 8) Change 'Type' of 1768 in svdb from Clarification to Enhancement 10) The editor, when implementing 1768, add + and * to cycle_delay_const_range_expression instead of adding ##[+] and ##[*] to cycle_delay_range. SV-AC Mantis items rejected by the Champions: --------------------------------------------- 9. Ab 1466 Revised, passed by e-mail ballot 6y/0n/3a abstain - Stu [Stu] 1) I abstain on this item because I feel the change is unnecessary. It does not add new functionality, and only makes assertion sequences even more cryptic. 2) If I had had voting privileges on the AC committee, I would have voted against this enhancement. 3) I would vote against it if I had voting privileges at the P1800 working group level. 4) I do not feel it is appropriate to vote NO on this at the champions level, because the champions charter is different. SV-EC Mantis items passed by the Champions after making friendly ammendments: ----------------------------------------------------------------------------- 10. 1789 Friendly ammendments were added SV-EC Mantis items sent back to the sv-ec for updates and further review: ------------------------------------------------------------------------- 11. 1787 changes by the Champions were made [Brad] friendly ammendments suggested 11) The editor, when implementing 1787, change both occurrences of "range_value" to "value_range". 12. 1777 changes by the Champions were made [Brad] friendly ammendments suggested 12) The editor, when implementing 1777, change both occurrences of "An arbitrary number" to "Any number" and delete 'arbitrary' from "any number of arbitrary". [Shalom] friendly ammendments suggested In the next to last paragraph, in "Transition bin b5", the word "Transition" should be added and not struck out. 13. 1736 changes by the Champions were made 14. No 1723 changes by the Champions were made no - Brad, Shalom [Brad] 6) Needs an example of the new method. 7) Not clear that that the indexing expressions are still legal after the change from [*] to [int]. [Shalom] Not clear that the change from [*] to [int] is correct, due to Brad's question, "According to [7.9.4], all of these unsigned integral values are sign extended to 32 bits, becoming negative ints. Was that the intent of your change?" Can't it be left unchanged, as [*] ? Brad's issues on 7.9.4 should be filed as a separate Mantis. 15. 1680 changes by the Champions were made [Shalom] Suggested a new mantis to be opened. Several changes suggested to be addressed in a separate mantis. These are listed in a bugnote to mantis 1680. [Neil] mantis item 2002 has been opened to address these issues. 16. 1655 changes by the Champions were made [Shalom] friendly ammendments suggested The sentence, "The changes in this proposal are based on the P1800-2008-draft2.pdf document" should refer to Draft 3a to avoid confusion. 17. No 1615 changes by the Champions were made no - Shalom [Shalom] I still feel that this language of 1615 is confusing: "Calling a function that executes a fork..join_none block shall be illegal in any context in which ... or any context other than in ..." 1) Is there any reason to write, "in any context in which" instead of simply "wherever"? 2) Can't "illegal in ... any context other than in" be written simply as "legal only in"? 3) Probably "or" should be "and". I don't think this is minor wordsmithing. I think the proposed language is confusing. 4) Also, in "Examples of such illegal contexts are ... static variable declaration initialized", should the last word be "initializers"? 5) "initial block" should be "initial procedure". [Brad] friendly ammendments suggested 13) The editor, when implementing 1615, change "join_noen" to "join_none". 18. 1612 changes by the Champions were made 19. No 1609 changes by the Champions were made no - Brad [Brad] The new text is out of place where proposed, as becomes more apparent if you look at the full original paragraph instead of just the proposal in isolation. The better place for this restriction is a normative footnote in the BNF, specifically on the first production in class_property of A.1.8. It should say something like, "It shall be illegal for a data_declaration in a class_property to be a package_import_declaration." 20. 1605 changes by the Champions were made 21. No 1580 changes by the Champions were made no - Shalom [Shalom] 1) If Brad's re-ordering suggesting is adopted, I would change my vote to yes. 2) I still think the last sentence, "All other objects may be referenced," is still a little unclear. Better would be, if I have understood it correctly, "All other objects may be referenced even through a port or a virtual interface." If I did not understand it correctly, then my vote is still no. Editorial corrections: 3) Change "in either the module header or port connection" to "in either the module header or a port connection". 4) Change "or if there are modports" to "or whether there are modports". [Brad] friendly ammendments suggested 14) The editor, when implementing 1580, clarify the text to make it read more smoothly, taking into account Shalom's earlier comments, and reordering the penultimate sentence to "When an interface is connected with a modport in either the module header or port connection, then, for those types of objects legal to be listed in a modport (nets, variables, subroutines, and clocking blocks), access through a port or through a virtual interface is limited to only those objects listed in the modport." 22. No 1556 no changes were needed no - Brad, Shalom, Stu [Brad] 2) Doesn't this break backward compatibility with traditional Verilog by requiring an explicit lifetime keyword for all initialized variables in static tasks and functions? 3) In any case, reverting this change is not necessary. Users are free to add 'static', and methodologies are free to require 'static', but there's no language reason to again make it mandatory for everybody. 4) The example is confusing. 5) The comments in the example are wrong, because they say 1 2 3 3 3 3 3 3 3 3 should be printed, but actually it should be 2 3 4 4 4 4 4 4 4 [Shalom] The example comments are not correct, since the code should not compile. The actual behavior would depend on how the illegality is fixed. It also seems to depend on an execution ordering which is not specified in the LRM. [Stu] I vote no because the e-mail discussion from other champions leads me to believe that the proposal needs further analysis from the SV-EC. 23. 1545 section numbers were updated 24. 1480 no changes were needed 25. 1427 section numbers were updated 26. 1371 no changes were required [Shalom] friendly ammendments suggested "constructs", as in "initial constructs", should be "procedures". 27. No 1336 section numbers were updated no - Shalom [Shalom] 1) Same wording problem as in 1615. 2) Question: 1615 proposal says, "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." 1336 proposal says, "A function that tries to schedule an event that will become active only after that function returns shall be an error in any context in which a side effect is disallowed or in any context other than a thread originating in an initial or always block." 1615 proposal does not mention always block and 1336 proposal does. Is that correct? 3) "always block" should be "always procedure". [Brad] friendly ammendments suggested 15) The editor, when implementing 1336, change "shall not have" to "shall not contain". 28. 888 section numbers were updated [Brad] friendly ammendments suggested 16) The editor, when implmenting 888, make sure the dot after implicit_class_handle is red. 29. 594 section numbers were updatedReceived on Wed Aug 29 18:36:53 2007
This archive was generated by hypermail 2.1.8 : Wed Aug 29 2007 - 18:37:51 PDT