FYI, At least one person mentioned that they didn't receive this email from John. Neil -------- Original Message -------- Subject: jh_ballot.txt Date: Mon, 17 Sep 2007 10:14:31 -0500 From: John Havlicek <john.havlicek@freescale.com> Reply-To: john.havlicek@freescale.com To: sv-champions@eda-stds.org CC: Neil.Korpusik@Sun.COM, john.havlicek@freescale.com Hi Folks: My ballot is attached. J.H. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. 1. 0001957 Yes _X_ No ___ Abstain ___ SV-BC Macros: ambiguous whether empty arguments can be used Unanimously approved by SV-BC on August 6, 2007. JH friendly amendment: I think that smart quotes should not be used in the example. 2. 0001951 Yes _X_ No ___ Abstain ___ SV-BC "Null argument" to mean "omitted argument" may be confusing On August 20, 2007 the SV-BC unanimously approved JH suggestion: The proposal says: (An empty argument is characterized by two adjacent commas in the argument list.) I understand that the previous description of the characterization of a "null argument" was the same, but I am worried that this is not precise. After the macro substitution, the example in 1957 produces empty arguments for which the adjacent commas are separated by one or more white spaces. So "two adjacent commas" needs to be interpreted to mean that intervening white space is allowed. The following may be better: (An empty argument is one that is delimited by commas that are either adjacent or separated only by white space.) Also, it seems unusual that an empty argument is not allowed before the first comma or after the last comma. A more precise statement that allows an empty argument before the first comma or after the last comma is something like (An empty argument is one such that at least one of its delimiters is a comma and such that the delimiters are either adjacent or separated only by white space.) This phrasing specifies that each of $display() $display( ) $display( ) ... has no argument rather than one empty argument. 3. 0001945 Yes _X_ No ___ Abstain ___ SV-BC Syntax error in 19.6.1 example Unanimously approved by SV-BC on August 6, 2007 4. 0001935 Yes _X_ No ___ Abstain ___ SV-BC ansi_port_declaration BNF (A.1.3) Unanimously approved by SV-BC on August 6, 2007. 5. 0001928 Yes ___ No _X_ Abstain ___ SV-EC clarification of coverpoint value resolution (18.5.6) Approved on July/23/2007 unanimously vote. JH justification: I was unable to assign an unambiguous technical meaning to the phrase "enumeration value". I don't think that 6.19 makes the meaning of this phrase clear. I think that this phrase is used in various places in Draft3a with different meanings. I don't know whether this proposal intends "enumeration value" to mean "reference to an enumerated named constant" or something else. What is the proposal saying if e itself is a reference to a variable of an enumerated type? I recommend that, at minimum, the proposal either articulate more clearly what "enumeration value" means or provide a reference to a section (perhaps 6.19.3) in which the phrase "enumeration value" is used in the same sense that is meant in 1928. This is not really a good solution to the problem. It would be better to clean up 6.19, uniformizing the terminology, and then pick the right phrase to describe what is intended in 1928. . In 6.19, there is a fairly clear distinction between "enumerated named constants" and the corresponding "enumerated values" of the constants. 6.19 uses the phrase "enumerated name" in a number of places when discussing the identifiers of the associated named constants. 6.19 does not define the phrase "enumeration set", but it has several statements about sets associated with enumerated types: An enumerated type declares a set of integral named constants. and An enumerated type defines a set of named values. . 6.19.2 introduces the phrase "enumeration element", which seems to mean "enumerated named constant". . 6.19.3 introduces the phrases "enumeration set" and "enumeration values", saying: Enumerated types are strongly typed; thus, a variable of type enum cannot be directly assigned a value that lies outside the enumeration set unless an explicit cast is used or unless the enum variable is a member of a union. This is a powerful type-checking aid that prevents users from accidentally assigning nonexistent values to variables of an enumerated type. The enumeration values can still be used as constants in expressions, and the results can be assigned to any variable of a compatible integral type. The way "enumeration value" is used suggests that it means "enumerated named constant" rather than "enumerated value". 6.19.3 also says Enumerated variables are type-checked in assignments, arguments, and relational operators. Enumerated variables are auto-cast into integral values, but assignment of arbitrary expressions to an enumerated variable requires an explicit cast. The example in 6.19.3 makes it clear that strong typing forbids the assignment of a literal integral number to a variable of enumerated type without a cast, even when the value of the number is within the set of enumerated values. This is not enough to conclude that "enumeration set" means the set of enumerated named constants rather than enumerated values because 6.19.3 also says that casting can be used to assign an out-of-range value to an enumerated type. . 6.19.4 introduces further confusion with the sentences Elements of enumerated type variables can be used in numerical expressions. The value used in the expression is the numerical value associated with the enumerated value. "Element" here seems to mean "enumerated named constant". In trying to make sense of this, I would interpret numerical value associated with the enumerated value to mean numerical value associated with the element This has the unfortunate consequence of suggesting that there is no difference between elements, enumerated values, and enumerated named constants. 6.19.4 also says the following An enum variable or identifier used as part of an expression is automatically cast to the base type of the enum declaration (either explicitly or using int as the default). This seems to involve the same notions as 1928, so it suggests to me that "enumeration value" in 1928 is more closely related to "enum variable or identifier" and "enumerated named constant" than to "enumerated value". . 6.19.5 makes repeated use of the phrase "enumeration value" in ways that suggest that it means the same thing as "enumerated named constant" in 6.19. . 6.18 uses the phrase "enumeration values" in a way that seems to mean the same thing as "enumerated named constants". . 6.24.2 uses the phrase "enumeration values" in a way that seems to mean "set of enumerated values". 6. 0001927 Yes _X_ No ___ Abstain ___ SV-EC clarification of default sequence transition bin in covergroup Approved on July/23/2007 unanimously vote. 7. 0001899 Yes _X__ No ___ Abstain ___ SV-BC Follow-up to 1831, redundant text approved by SV-BC e-mail vote that concluded on July 9, 2007. 8. 0001871 Yes ___ No _X_ Abstain ___ SV-EC clarification needed for illegal/ignore transition bins Approved on July/23/2007 unanimously vote. JH justification: I think that this proposal needs to clarify the technical meaning of "contains an ignored/illegal sequence". In the description of 1871 it is written We propose that if the coverage bin cannot be matched without also matching the illegal bin on any sample value, then the coverage bin must be invalidated so that it is excluded from coverage. In the example above, clearly b cannot be matched without also matching i on the third sample value (the transition from 2 to 3), so bin b is excluded. The phrase "contains an illegal sequence" does not convey the same technical meaning as "cannot be matched without also matching the illegal bin on a subsequence, perhaps proper". It leaves in doubt what to do with covergroup cg; coverpoint b { bins b = (1=>2=>3[->1]=>4); illegal_bins bad_trans = (2=>3); } endgroup The sequence 1=>2=>3[->1]=>4 has matches that also match the illegal sequence 2=>3 as proper subsequence. The sequence 1=>2=>3[->1]=>4 also has matches that do not match the illegal sequence as subsequence. 9. 0001864 Yes _X_ No ___ Abstain ___ SV-BC D3a 6.7: logic and reg are not just equivalent types Approved unanimously by SV-BC on August 6, 2007 10. 0001860 Yes _X_ No ___ Abstain ___ SV-BC D3 22.2.2.2 ref port declaration syntax Unanimously to be a duplicate of 1935 by SV-BC on August 6, 2007 11. 0001855 Yes _X_ No ___ Abstain ___ SV-AC issues with 22.10 after 1722 duplicate 12. 0001814 Yes _X_ No ___ Abstain ___ SV-BC D3 33.5.2.2: sentence in wrong place unanimously approved by SV-BC e-mail vote concluded on July 9, 2007. 13. 0001804 Yes _X_ No ___ Abstain ___ SV-AC Add abiltiy to require equiv types for typed formal args Voice vote on 2007-08-07 not to address this since lint tools can check such conditions 14. 0001794 Yes _X_ No ___ Abstain ___ SV-BC uninstantiated interface/program Approved unanimously by SV-BC on August 6, 2007 15. 0001745 Yes _X_ No ___ Abstain ___ SV-BC "outside of" and "inside of" are bad style Approved unanimously by SV-BC on August 6, 2007. 16. 0001743 Yes _X_ No ___ Abstain ___ SV-BC Refinements to 0000331 already covered by expanded version of 0000331 by SV-BC on August 6, 2007 17. 0001737 Yes ___ No _X_ Abstain ___ SV-AC Incomplete fix from 1381 Resolved by e-mail ballot on 2007-05-28, 7y/0n/4a JH justification: This proposal has not been properly colored to show which parts of the existing text should be retained and which stricken. JH friendly amendments: 1. I think that "The enabling condition assumed from the context" should be "The enabling condition inferred from the context". 2. I think that "assert property", "assume property", and "cover property" should be in bold Courier as compound keywords. 3. The LRM is moving to a style in which non-terminals of the syntax are referenced in italics, preserving underscores, rather than Courier. This affects "property_expr" and "property_spec". 4. The font of "case" in "Similarly, the enabling condition is also inferred from case statements" should be bold Courier. 5. 1768 has already been approved. I think that this proposal should be updated to explain inferred enabling conditions for "cover sequence". I think that ##0 should be used for this since the negation dual formulation for "cover property" will not be legal syntax. This will also require some reworking of various places that talk about property_expr and property_spec to be inclusive of the body of a "cover sequence", which may have a "disable iff" clause, but for which there is not an analogous non-terminal "sequence_spec". And the examples may want to illustrate the inference for "cover sequence". 6. The proposal has been crafted carefully so that the transformation inserts the inferred enabling condition after any "disable iff" clause, but this may be a bit too subtle for readers. Consider mentioning this point, perhaps with an example. 18. 0001731 Yes _X_ No ___ Abstain ___ SV-AC Sampled value functions with arbitrary clocks Passed by e-mail ballot 2007-07-03, 9y/0n/2a JH friendly amendments: 1. The added text in Clause 16 and Annex F needs to be in blue. 2. The example in 16.8.3 should use Courier font. For example, I see the first word "bit" in a bold Roman font. The other bold words are the same way. And "&&" is not in Courier. I'm not sure about the punctuations (",", ";"). The source of the proposal may be using an obscure or variant font. I recommend switching to a more common font. 3. In the paragraph after the example in 16.8.3, the font is not consistent in referencing identifiers from the example. They should all be in Courier. 4. In the new section F.2.3.6, the deprecated form "sampled(e,c)" should not appear. 5. In the new section F.2.3.6, Courier font should be used for terminals, such as "1", "0", punctuations (",", ";"), parentheses, "&&", and "=". 6. In the new text in F.4.2, Courier font should be used for terminals in the sequence expression, such as parentheses, "&&", "##1", brackets, etc. 7. I think that the more precise language from 1550 with cross references should be used in F.4.2 to discuss the case when $past looks back too far and the initial values are used. 19. 0001689 Yes _X_ No ___ Abstain ___ SV-BC Return type of $bits() duplicate of SVDB 919. 20. 0001681 Yes _X_ No ___ Abstain ___ SV-AC Introduce global clocking New proposal was uploaded - redoing email vote (didn't reach quorum) 21. 0001626 Yes _X_ No ___ Abstain ___ SV-BC 12.3: should say clearly that 1364 10.4.4c) does not apply no action as it was already addressed by the editor 22. 0001625 Yes _X_ No ___ Abstain ___ SV-BC 20.1: typo - "block" -> "blocks" On July 9, 2007 the attached proposal, typos_1625.htm, was unanimously approved by the SV-BC. 23. 0001607 Yes _X_ No ___ Abstain ___ SV-BC import of a forward typedef SV-BC unanimously approved resolution of this issue 24. 0001548 Yes _X_ No ___ Abstain ___ V-1364 5.1.13: description of condition reversed SV-BC unanimously approved JH friendly amendments: 1. I suggest that this proposal fix Table 11-1 to change "conditional expression" to "conditional operator". 2. I suggest that this proposal fix Table 11-2 to change the plural "conditional operators" to the singular "conditional operator". 25. 0001484 Yes _X_ No ___ Abstain ___ SV-BC Package declarations should not refer to $unit SV-BC unanimously approved 26. 0001462 Yes _X_ No ___ Abstain ___ SV-BC 19.5, A.1.2: timeunits_declaration formatting confusing SV-BC unanimously approved JH friendly amendment: I suggest that SV-BC consider simplifying the syntax using square brackets to denote optional items, as in timeunits_declaration ::= timeunit time_literal ; [ timeprecision time_literal ; ] | timeprecision time_literal ; [ timeunit time_literal ; ] 27. 0001459 Yes _X_ No ___ Abstain ___ SV-EC Mailbox 'new' method should never return null passed unanimously 28. 0001444 Yes _X_ No ___ Abstain ___ SV-BC size warnings in assignment patterns should be allowed SV-BC unanimously approved JH friendly amendment: I suggest that the comments in the examples also be clarified by changing "no size warning as ..." to "no size warning required as ..." 29. 0001383 Yes _X_ No ___ Abstain ___ SV-AC Property coverage definition Duplicate of 805 JH comment: SV-AC still need to vote on the state change to "resolved,won't fix". This is another process mistake for which I am to blame. Approval by the Champions should be conditional on the SV-AC vote. 30. 0001351 Yes _X_ No ___ Abstain ___ SV-BC 12.4.3: endtask should not have ; was unanimously approved by SV-BC e-mail vote 31. 0001341 Yes _X_ No ___ Abstain ___ V-1364 effect of `resetall on `begin_keywords not defined in 1364, 19.11 unanimously approved 32. 0001340 Yes ___ No _X_ Abstain ___ SV-BC inconsistency between module ports and task arguments SV-BC unanimously voted to accept JH justification: 1. This proposal involves scoping rules for various modifiers (direction, data type, the var keyword) of port items in a tf_port_list. The proposal says that an explicit specification of the port direction sets the data type to default logic "if the data type is not explicitly declared". I am not sure that "if the data type is not explicitly declared" has been well defined. From the syntax, one might expect this to mean that some non-white-space token is parsed through the non-terminal data_type. Another definition is that some non-white-space token is parsed through the non-terminal data_type_or_implicit. Another definition is that some non-white-space token is parsed after the position of the optional tf_port_direction and before the port_identifier. It may be that none of these definitions is what is intended by the committee. For example, in task foo (input int a, signed b, c) ... endtask does the declaration of "signed" count as an explicit data type declaration? If so, then I guess that b is "logic signed" (by the default?) and I am not sure whether c is "logic signed" or "logic", although this last distinction may be inconsequential. Otherwise I guess that b is "int signed" and I am not sure whether c is "int signed" or "int". The "var" keyword is allowed as part of the syntax for the port item. In 6.7 it is written Another form of variable declaration begins with the keyword var. The data type is optional in this case. If a data type is not specified, then the data type logic shall be inferred. This leaves doubt about the interpretation of task bar (input logic [1:0] a, var b); ... endtask Is b one bit or two? I also think that it will be helpful if there is a statement in Clause 13 or a reference to some other clause that clarifies the scoping of the modifier "var" and of the modifiers that can be parsed through "[signing] {packed_dimension}". Can these modifiers be inherited by subsequent port items? 2. I think that there is little chance that new text of the form If A then B if C. Otherwise D. will be interpreted as If A then (B if C) else D. rather than If A then (if C then B else D). because the complement of A is "the data type is explicitly defined" and D is "the data type is inherited from the previous argument". Nevertheless, the committee might want to consider a different English structure, such as If A, then the following shall hold: if C then B; otherwise D. 33. 0001331 Yes _X_ No ___ Abstain ___ SV-BC 10.4.1.3 xref to 8.17 should be 8.18 SV-BC unanimously approved 34. 0001280 Yes _X_ No ___ Abstain ___ SV-BC Wrong replication example at end of 3.8 unanimously approved by SV-BC e-mail vote JH friendly amendments: 1. I cannot assign a technical meaning to the phrase "multiple concatenations" in this context. This is the only occurrence of this phrase in Draft3a. The phrase "nested replications" is more intuitive to me. This choice also has the advantage of providing a target for the reference to "replication" in "Each replication represents an entire single dimension". 2. I think that the sentence Each replication represents an entire single dimension. Should be in the "shall" mode of 1.5. 35. 0001233 Yes _X_ No ___ Abstain ___ SV-BC 8.13.1: "similar assignments above" unclear unanimously approved by SV-BC e-mail voteReceived on Wed Oct 3 18:46:09 2007
This archive was generated by hypermail 2.1.8 : Wed Oct 03 2007 - 18:46:10 PDT