I approve all except 1729 1723 1615 1580 1556 1336 See comments on 1601 1777 1680 1655 1371 > -------- Original Message -------- > Subject: [sv-champions] 5-day email vote > Date: Fri, 24 Aug 2007 17:06:10 -0700 > From: Neil Korpusik <Neil.Korpusik@Sun.COM> > Reply-To: Neil.Korpusik@Sun.COM > To: undisclosed-recipients: ; > > The details are attached. > Please vote as early as possible. > > Thanks, > Neil > > > > 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 _x_ No ___ Abstain ___ 1550 Friendly ammendments > added, approved by svac > Yes _x_ No ___ Abstain ___ 1567 Friendly ammendments > added, approved by svac > Yes _x_ No ___ Abstain ___ 1722 Friendly ammendments > added, approved by svac > > SV-AC Mantis items sent back to the committees for updates: > Yes _x_ No ___ Abstain ___ 1591 Revised, passed by email > ballot 7y/0n/2a > Yes _x_ No ___ Abstain ___ 1601 Revised, passed by email > ballot 8y/0n/1a Minor editorial corrections to 1601: "This semantics is described in Subclause 16.7." should be "This semantics is described in 16.7." 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. > Yes _x_ No ___ Abstain ___ 1704 Revised, passed by email > ballot 8y/0n/1a > Yes ___ No _x_ Abstain ___ 1729 Revised, passed by email > ballot 7y/0n/2a 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" Most of the text says "can", "should", but the last sentence says "shall". 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'. > Yes _x_ No ___ Abstain ___ 1768 Reviewed by LP, DB, JH., > no change needed > > SV-AC Mantis items rejected by the Champions > Yes _x_ 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 _x_ No ___ Abstain ___ 1789 Friendly ammendments were added > > SV-EC Mantis items sent back to the sv-ec for updates and > further review > Yes _x_ No ___ Abstain ___ 1787 changes by the Champions were made > Yes _x_ No ___ Abstain ___ 1777 changes by the Champions were made Editorial correction: In the next to last paragraph, in "Transition bin b5", the word "Transition" should be added and not struck out. > Yes _x_ No ___ Abstain ___ 1736 changes by the Champions were made > Yes ___ No _x_ Abstain ___ 1723 changes by the Champions were made 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. > Yes _x_ No ___ Abstain ___ 1680 changes by the Champions were made The following cases, listed in my bugnote to 1680, should be corrected in a new Mantis: 5.9: When an integral type is larger than required to hold the literal string value being assigned, the value is right-justified, and the leftmost bits are padded with zeros, as is done with nonstring values. 11.2: An operand can be one of the following: - Constant literal number, including real literals - Literal string 20.7: Syntax 20-9, Syntax 20-16, Syntax 20-17, Syntax 20-18, Syntax 20-19, Syntax 20-20: filename ::= literal_string | variable | expression 20.7.1.1: The filename is optional and defaults to the literal string dump.vcd if not specified. ( dump.vcd should also be enclosed in quotation marks. ) 20.7.3.1: Literal strings are not allowed for the module_identifier. and file_pathname - can be a double quoted path name (literal string), an integral variable, or an expression that denotes the file which shall contain the port VCD information. 20.7.3.2, 20.7.3.3, 20.7.3.4, 20.7.3.5: The file_pathname argument can be a double quoted path name (literal string), an integral variable, or an expression that denotes the file_pathname specified in the $dumpports system task. Annex L.2: #define vpiConstant 7 /* numerical constant or literal string */ > Yes _x_ No ___ Abstain ___ 1655 changes by the Champions were made Editorial correction: The sentence, "The changes in this proposal are based on the P1800-2008-draft2.pdf document" should refer to Draft 3a to avoid confusion. > Yes ___ No _x_ Abstain ___ 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 ..." Is there any reason to write, "in any context in which" instead of simply "wherever"? Can't "illegal in ... any context other than in" be written simply as "legal only in"? Probably "or" should be "and". I don't think this is minor wordsmithing. I think the proposed language is confusing. Also, in "Examples of such illegal contexts are ... static variable declaration initialized", should the last word be "initializers"? "initial block" should be "initial procedure". > Yes _x_ No ___ Abstain ___ 1612 changes by the Champions were made > Yes _x_ No ___ Abstain ___ 1609 changes by the Champions were made > Yes _x_ No ___ Abstain ___ 1605 changes by the Champions were made > Yes ___ No _x_ Abstain ___ 1580 changes by the Champions were made If Brad's re-ordering suggesting is adopted, I would change my vote to yes. 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: Change "in either the module header or port connection" to "in either the module header or a port connection". Change "or if there are modports" to "or whether there are modports". > Yes ___ No _x_ Abstain ___ 1556 no changes were needed 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. > Yes _x_ No ___ Abstain ___ 1545 section numbers were updated > Yes _x_ No ___ Abstain ___ 1480 no changes were needed > Yes _x_ No ___ Abstain ___ 1427 section numbers were updated > Yes _x_ No ___ Abstain ___ 1371 no changes were required Editorial note: "constructs", as in "initial constructs", should be "procedures". > Yes ___ No _x_ Abstain ___ 1336 section numbers were updated Same wording problem as in 1615. 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? "always block" should be "always procedure". > Yes _x_ No ___ Abstain ___ 888 section numbers were updated > Yes _x_ No ___ Abstain ___ 594 section numbers were updated Shalom -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Aug 29 07:48:56 2007
This archive was generated by hypermail 2.1.8 : Wed Aug 29 2007 - 07:48:58 PDT