See the attachment for details. Neil -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Results of Champions and P1800 Working Group reviews of SV-EC mantis items: - At the P1800 Working Group meeting held Aug 30th all of the mantis items that were passed by the Champions were approved by the P1800. This includes those mantis items that were approved by the Champions in their 5-day email vote which concluded Aug 29. - The six mantis items that failed the Champions email vote will be on the agenda for the next Champions meeting. It is still possible for these to pass at the next Champions meeting, since it only takes one no vote during an email vote to cause a proposal to fail. - Those mantis items with friendly ammendments can not be sent to the Editor until the friendly amendments are made by the Technical Committee. This requirement was stipulated in the motion made in the P1800 Working Group meeting. - I am the person that will send the mantis items to the Editor. 1. 1789 passed 2. 1787 passed - friendly ammendments suggested 3. 1777 passed - friendly ammendments suggested 4. 1736 passed 5. 1723 failed 2 no votes 6. 1680 passed - mantis 2002 was opened to address additional issues 7. 1655 passed - friendly ammendments suggested 8. 1615 failed 2 no votes 9. 1612 passed 10. 1609 failed 1 no vote 11. 1605 passed 12. 1580 failed 2 no votes 13. 1556 failed 3 no votes 14. 1545 passed 15. 1480 passed 16. 1427 passed 17. 1371 passed - friendly ammendments suggested 18. 1336 failed 1 no vote 19. 888 passed - friendly ammendments suggested 20. 594 passed 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 Friendly ammendments suggested 1) The editor, when implementing 1787, change both occurrences of "range_value" to "value_range". 12. 1777 changes by the Champions were made Friendly ammendments suggested 1) The editor, when implementing 1777, change both occurrences of "An arbitrary number" to "Any number" and delete 'arbitrary' from "any number of arbitrary". 2) 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 1) Needs an example of the new method. 2) Not clear that that the indexing expressions are still legal after the change from [*] to [int]. 3) Not clear that the change from [*] to [int] is correct, "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 [*] ? 15. 1680 changes by the Champions were made 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 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 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". 6) The sentence pointed out by Shalom 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 ..." Friendly ammendments suggested 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 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 1) If the following re-ordering suggesting is adopted, I would change my vote to yes. "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)." Maybe it's just an ordering problem, and should say something like "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." Now looking at your commentary, I see it says that "The wording wasn't changed since the sv-ec went through several iterations to converge on the correct wording." I don't agree that it's the "correct wording". 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". 5) The last two sentences conflict with each other. The sentence "When an interface...is limited to ...". Next sentence " All other objects may be referenced" Friendly ammendments suggested 1) 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 1) Doesn't this break backward compatibility with traditional Verilog by requiring an explicit lifetime keyword for all initialized variables in static tasks and functions? 2) 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. 3) The example is confusing. 4) 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 5) 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. 23. 1545 section numbers were updated 24. 1480 no changes were needed 25. 1427 section numbers were updated 26. 1371 no changes were required Friendly ammendments suggested "constructs", as in "initial constructs", should be "procedures". 27. No 1336 section numbers were updated 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". Friendly ammendments suggested The editor, when implementing 1336, change "shall not have" to "shall not contain". 28. 888 section numbers were updated Friendly ammendments suggested The editor, when implmenting 888, make sure the dot after implicit_class_handle is red. 29. 594 section numbers were updatedReceived on Sat Sep 1 20:20:36 2007
This archive was generated by hypermail 2.1.8 : Sat Sep 01 2007 - 20:21:04 PDT