FYI, Attached is a detailed summary of the Champions 12-day email vote that ended on Sept 17th. There were 4 Champions that voted and 2 that didn't. I have updated the bug notes for these mantis items with all of the feedback. I am planning on having a Champions conference call on Oct 18th, 9am PST. Let me know if this will work for you. We need to have a conference call to take care of those mantis items that had one or more no votes in email votes that have completed. I plan to have about 40 items on the agenda. Please plan on a 2-hour meeting. Neil -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. FYI, Attached is a detailed summary of the Champions 12-day email vote that ended on Sept 17th. There were 4 Champions that voted and 2 that didn't. I have updated the bug notes for these mantis items with all of the feedback. I am planning on having a Champions conference call on Oct 18th, 9am PST. Let me know if this will work for you. We need to have a conference call to take care of those mantis items that had one or more no votes in email votes that have completed. I plan to have about 40 items on the agenda. Please plan on a 2-hour meeting. Neil 6 - with 1 or more no-votes 6 - yes, with friendly amendments 1 - yes, with a note to the editor 1 - yes, with a suggestion 3 - yes, with a comment 1 - irregular voting - proposal was to close as duplicate (1462) 17 - passed unanimously without any feedback given ------------------------------------------------ 35 - total Mantis items voted on Dave - no on 1745, 1681 Editor note for 1794 Brad - no on 1681 Comments on 1928, 1927, 1737, 1459, 1383 Shalom - yes on all Comments on 1945, 1737, 1462 Surrendra - yes on all John H. - no on 1928, 1871, 1340 - no, but also had friendly amendments 1737 - yes with friendly amendments 1957, 1731, 1548, 1462, 1444, 1383, 1280 - yes with suggestions 1951 Stu - didn't vote Francoise - didn't vote List of Mantis items with 1 or more no-votes, friendly amendments or comments ----------------------------------------------------------------------------- svac 1 1681 - 2 no votes - Dave, Brad 2 1737 - 1 no vote - John H. 3 1731 - friendly amendments - John H. 4 1383 - friendly amendments - John H. svbc 1 1794 - 1 note to the editor - Dave 2 1745 - 1 no vote - Dave 3 1340 - 1 no vote - John H. 4 1951 - Suggestion - John H. 5 1957 - friendly amendments - John H. 6 1548 - friendly amendments - John H. 7 1462 - irregular - friendly amendments - John H. - action was to close 8 1444 - friendly amendments - John H. 9 1280 - friendly amendments - John H. 10 1945 - Comment from Shalom svcc <none> svec 1 1459 - comment - from Brad 2 1927 - comment - from Brad 3 1928 - 1 no vote - John H. 4 1871 - 1 no vote - John H. List of Mantis items that passed unanimously (4 yes and 2 not voting) --------------------------------------------------------------------- 1. 1935 SV-BC ansi_port_declaration BNF (A.1.3) 2. 1899 SV-BC Follow-up to 1831, redundant text 3. 1864 SV-BC D3a 6.7: logic and reg are not just equivalent types 4. 1860 SV-BC D3 22.2.2.2 ref port declaration syntax 5. 1855 SV-AC issues with 22.10 after 1722 6. 1814 SV-BC D3 33.5.2.2: sentence in wrong place 7. 1804 SV-AC Add abiltiy to require equiv types for typed formal args 8. 1743 SV-BC Refinements to 0000331 9. 1689 SV-BC Return type of $bits() 10. 1626 SV-BC 12.3: should say clearly that 1364 10.4.4c) does not apply 11. 1625 SV-BC 20.1: typo - "block" -> "blocks" 12. 1607 SV-BC import of a forward typedef 13. 1484 SV-BC Package declarations should not refer to $unit 14. 1351 SV-BC 12.4.3: endtask should not have ; 15. 1341 V-1364 effect of `resetall on `begin_keywords not 16. 1331 SV-BC 10.4.1.3 xref to 8.17 should be 8.18 17. 1233 SV-BC 8.13.1: "similar assignments above" unclear Feedback that was given: ----------------------- svac 1681 - 2 no votes, from Champions email vote ending on Sept 17 - Dave - it was still up for vote in the svac - Brad - wasn't sure which proposal to look at 1737 - 1 no vote - John H. This proposal has not been properly colored to show which parts of the existing text should be retained and which stricken. - Friendly amendments from John H. 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. - Comments from Brad In the body of text, 'assume property', 'assert property' and 'cover property' should not look exactly the same as the rest of the text. Also, why is "inferred" in a parenthetical comment? - Comment from Shalom On page 2 of the proposal, in the sentences: "If the verification statement is assume property or assert property" and "If the verification statement is cover property", "assume property", "assert property", and "cover property" should all be in bold. 1731 - friendly amendments - John H. 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. 1383 - friendly amendments - John H. 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. - Comments - Brad - It's confusing to still have the proposal there even though it wasn't approved. Also, what were the votes for this issue? svbc 1794 - 1 note to the editor - Dave I think the added sentence should appended to the paragraph, not a new paragraph. 1745 - 1 no vote - Dave This type of change should not be going through the committees; it should be at the editor's discretion. In this particular case, the exiting wording is clear and the amount of my time required to review this proposal is not justified. I'm not trying to demean the work Shalom has put into this, but he and I have different opinions of where our efforts should be spent. 1340 - 1 no vote - John H. 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. 1951 - Suggestion - John H. 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. 1957 - friendly amendments - John H. I think that smart quotes should not be used in the example. 1548 - friendly amendments - John H. 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". 1462 - friendly amendments - John H. - DID NOT UPDATE the mantis item since the feedback made no sense.... - Note: the proposal is to close it as covered by 1623, so why did John give this type of feedback? 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 ; ] - Comment from Shalom - the proposal is to close as covered by 1623. 1444 - friendly amendments - John H. I suggest that the comments in the examples also be clarified by changing "no size warning as ..." to "no size warning required as ..." 1280 - friendly amendments - John H. 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. 1945 - Comment from Shalom I would like to see a new, additional example that contains "signed". svcc <none> svec 1459 - comment from Brad Why is this not 'Resolved', but instead 'Feedback'? Neil set it to resolved - after the email vote completed In the svec meeting of 10/1/07 it was mentioned that it was left in the Feedback state by mistake. 1927 - comment - from Brad - should be "none ... remain" pending, not "none ... remains pending", see, for example, http://www.worldwidewords.org/qa/qa-non2.htm 1928 - comment from Brad "expression context" is not defined in the LRM 1928 - 1 no vote - John H. 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". Comments: "expression context" is not defined in the LRM 1871 - 1 no vote - John H. 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.Received on Wed Oct 3 18:39:21 2007
This archive was generated by hypermail 2.1.8 : Wed Oct 03 2007 - 18:39:24 PDT