Matt, Here's my votes. I am traveling the morning of the conference call to discuss the voting. I should be able to call in for the first 30 minutes of the call. Stu ~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland Sutherland HDL, Inc. stuart@sutherland-hdl.com 503-692-0898 > SB1-1-1 yes _X_ no ___ abstain ___ > SB1-1-2 yes _X_ no ___ abstain ___ > SB1-1-3 yes _X_ no ___ abstain ___ > SB1-1-4 yes _X_ no ___ abstain ___ > SB1-1-5 yes _X_ no ___ abstain ___ > SB1-2-1 yes ___ no _X_ abstain ___ There are many references in the LRM to "1364" and "1800" without a specific year. Either these references need to be changed to "1364-2005" or "1800-2005", or the definition of "IEEE 1364" and "IEEE 1800" should be left in. Most references to "1364" and "1800" can have a year added, but some may need to stay generic; specifically 1.7, 5.5.2, 21.12 (multiple places), C.2.1, C.2.2, I.12, I.12.1 (multiple places). I will change my vote to yes if the committee decides that all references to "1364" and "1800" have a specific version added. > SB1-3-1 yes ___ no _X_ abstain ___ I have no problems with the current wording, and no new wording is recommended. I will change my vote to yes of specific wording changes are recommended. > SB1-3-2 yes _X_ no ___ abstain ___ > SB1-3-3 yes _X_ no ___ abstain ___ A question is raised as to whether "config" should be listed as a design unit, but no recommendation given. I will change my vote to yes if the committee agrees to remove "config", or for a description of config to be added to clause 3 (saying editor is to create the wording is OK). > SB1-5-1 yes _X_ no ___ abstain ___ > SB1-5-2 yes _X_ no ___ abstain ___ > SB1-5-3 yes ___ no _X_ abstain ___ I think the discussion of time values makes more sense where it is than in clause 4. > SB1-5-4 yes _X_ no ___ abstain ___ > SB1-5-5 yes _X_ no ___ abstain ___ > SB1-5-6 yes _X_ no ___ abstain ___ > SB1-6-1 yes _X_ no ___ abstain ___ > SB1-6-2 yes _X_ no ___ abstain ___ > SB1-6-3 yes _X_ no ___ abstain ___ The suggestion is: "6.14 and 7.6 both describe strings. Merge them ***or*** have only a two-sentence paragraph in 6.14". I do not approve of removing 6.14. I do approve of I approve of having a two-sentence paragraph in 6.14 with a forward reference to 7.6. > SB1-7-1 yes _X_ no ___ abstain ___ > SB1-7-2 yes _X_ no ___ abstain ___ > SB1-10-1 yes ___ no _X_ abstain ___ This needs to be a separate mantis item that goes through the full discussion, voting, and approval process. > SB1-10-2 yes _X_ no ___ abstain ___ > SB1-11-1 yes ___ no _X_ abstain ___ I think a more correct fix is to change the term "procedural assignment operators" in 10.3 and 10.3.1 to "assignment operators", so as to match the description of these operators in 11.2.7 and A.6.3. > SB1-11-2 yes ___ no _X_ abstain ___ The description of the wording problem is not detailed enough for the editor (me) to implement. > SB1-11-3 yes ___ no _X_ abstain ___ This is an open mantis item (#1004), and needs to be addressed using the standard discussion, voting and approval method. > SB1-11-4 yes _X_ no ___ abstain ___ > SB1-12-1 yes _X_ no ___ abstain ___ > SB1-16-1 yes _X_ no ___ abstain ___ > SB1-19-1 yes _X_ no ___ abstain ___ > SB1-19-2 yes ___ no _X_ abstain ___ This is an alleged errata in 1364-2005, and should be addressed as a separate Mantis item. > SB1-20-1 yes _X_ no ___ abstain ___ > SB1-20-2 yes _X_ no ___ abstain ___ > SB1-21-1 yes ___ no _X_ abstain ___ This is an enhancement request that needs to be a separate Mantis item. > SB1-21-2 yes ___ no _X_ abstain ___ This is a change to a definition in 1364-2005. It should be a separate Mantis item for discussion, voting and approval. > SB1-21-3 yes _X_ no ___ abstain ___ > SB1-22-1 yes _X_ no ___ abstain ___ > SB1-22-2 yes _X_ no ___ abstain ___ > SB1-22-3 yes _X_ no ___ abstain ___ > SB1-22-4 yes ___ no _X_ abstain ___ I agree with the principle of the change, but this is a definition that does not exist in either 1364-2005 or 1800-2005. It needs to be a separate Mantis item with discussion, voting and approval. > SB1-25-1 yes _X_ no ___ abstain ___ > SB1-25-2 yes _X_ no ___ abstain ___ > SB1-25-3 yes _X_ no ___ abstain ___ > SB1-27-1 yes _X_ no ___ abstain ___ > SB1-33-1 yes ___ no ___ abstain _X_ I think the current order of clauses 30-33 is fine, but will change order if the committee approves. > SB-O-1 yes ___ no _X_ abstain ___ This needs committee discussion on what the correction should be. Make it a separate Mantis item. > SB-O-2 yes ___ no _X_ abstain ___ This needs committee discussion on what the correction should be. Make it a separate Mantis item. > SB-O-3 yes ___ no _X_ abstain ___ This needs committee discussion on what the correction should be. Make it a separate Mantis item. > SB-O-4 yes ___ no _X_ abstain ___ I think the current split on string literal topics is correct. 5.9 discusses string literal syntax in the same clause with other literals. 11.6.1 discusses operations on string literals in the same clause on operations on other types of data. > SB-O-5 yes ___ no _X_ abstain ___ Moving the discussion on string literals and string types closer together because they are related would only move other closely related topics further apart. This is one of those cases where there is no perfect solution to how to group topics. I prefer to keep string literals with other literals and string arrays with other arrays. > SB-O-6 yes ___ no _X_ abstain ___ This needs committee discussion on what the correction should be. Make it a separate Mantis item. > SB-O-7 yes ___ no _X_ abstain ___ This needs committee discussion on what the correction should be. Make it a separate Mantis item. > SB-O-8 yes _X_ no _X_ abstain ___ This is a duplicate of SB1-10-2, of which I am also in favor. > SB-O-9 yes ___ no _X_ abstain ___ This needs committee discussion on what the correction should be. Make it a separate Mantis item. > SB-O-10 yes ___ no _X_ abstain ___ I think this should be left as-is. > SB-O-11 yes ___ no _X_ abstain ___ Discussion on this should be turned over to the SV-CC committee. > SB2-6-9-1 yes _X_ no ___ abstain ___ > BP1-5-1 yes ___ no _X_ abstain ___ The note in 5.8 should remain deleted. It is redundant with the same note in 5.7. The Greek letter has already been corrected for draft 3. > BP1-5-2 yes _X_ no ___ abstain ___ > BP1-5-3 yes ___ no _X_ abstain ___ This would be changing a definition in 1800-2005. It is also part of a larger issue that has been raised on consistent usage of "data type" and "data object" throughout the LRM, and should be dealt with in a Mantis item on that topic. > BP1-5-4 yes ___ no _X_ abstain ___ This is part of a larger issue that has been raised on consistent usage of "data type" and "data object" throughout the LRM, and should be dealt with in a Mantis item on that topic. > BP1-5-5 yes ___ no _X_ abstain ___ This is part of a larger issue that has been raised on consistent usage of "data type" and "data object" throughout the LRM, and should be dealt with in a Mantis item on that topic. > BP1-5-6 yes _X_ no ___ abstain ___ > BP1-5-7 yes ___ no _X_ abstain ___ This is part of a larger issue that has been raised on consistent usage of "data type" and "data object" throughout the LRM, and should be dealt with in a Mantis item on that topic. > BP1-5-8 yes ___ no _X_ abstain ___ This is part of a larger issue that has been raised on consistent usage of "data type" and "data object" throughout the LRM, and should be dealt with in a Mantis item on that topic. > BP1-6-1 yes _X_ no ___ abstain ___ > BP1-6-2 yes ___ no ___ abstain _X_ I will go along with what the committee decides. > BP1-6-3 yes _X_ no ___ abstain ___ > BP1-6-4 yes _X_ no ___ abstain ___ > BP1-6-5 yes ___ no _X_ abstain ___ This is already covered in Mantis 507, and is scheduled to be corrected in draft 3. > BP1-6-6 yes ___ no ___ abstain _X_ I will go with what the committee decides regarding removal of the editor question, but personally I do not think this is an appropriate usage of an informative note. I think this note should either be deleted or be made part of the preceding paragraph. > BP1-7-1 yes ___ no _X_ abstain ___ I disagree with the suggested change. This subclause is specifically defining a "memory" as a one-dimensional unpacked array. There is no "fastest varying unpacked dimension". An array with multiple unpacked dimensions is not a memory, and referring to one as such would break the VPI definitions of memories and arrays. > BP1-7-2 yes _X_ no ___ abstain ___ > BP1-7-3 yes _X_ no ___ abstain ___ > BP1-7-4 yes ___ no _X_ abstain ___ I disagree with removing the paragraph. An introduction paragraph and general definition of a structure is needed. If the text is not correct, then a proposal on correct wording should be made, discussed, and voted on. > BP1-8-1 yes _X_ no ___ abstain ___ > BP1-9-1 yes _X_ no ___ abstain ___ > BP1-9-2 yes _X_ no ___ abstain ___ > BP1-9-3 yes _X_ no ___ abstain ___ > BP1-9-4 yes _X_ no ___ abstain ___ > BP1-10-1 yes _X_ no ___ abstain ___ > BP1-10-2 yes _X_ no ___ abstain ___ > BP1-10-3 yes _X_ no ___ abstain ___ > BP1-11-1 yes _X_ no ___ abstain ___ > BP1-12-1 yes ___ no ___ abstain _X_ I will go along with the committee decision. I think it is helpful, but not essential, to mention that a default branch is not the only way to catch x/z values in the case expression. > BP1-12-2 yes _X_ no ___ abstain ___ > BP1-12-3 yes _X_ no ___ abstain ___ > BP1-12-4 yes _X_ no ___ abstain ___ > BP1-12-5 yes _X_ no ___ abstain ___ > BP1-13-1 yes _X_ no ___ abstain ___ > BP1-13-2 yes _X_ no ___ abstain ___ > BP1-13-3 yes _X_ no ___ abstain ___ > BP1-13-4 yes _X_ no ___ abstain ___ > BP1-13-5 yes _X_ no ___ abstain ___ > BP1-13-6 yes _X_ no ___ abstain ___ > BP1-13-7 yes _X_ no ___ abstain ___ > BP1-22-1 yes _X_ no ___ abstain ___ > BP1-22-2 yes _X_ no ___ abstain ___ > BP1-22-3 yes _X_ no ___ abstain ___ > BP1-22-4 yes _X_ no ___ abstain ___ > BP1-22-5 yes _X_ no ___ abstain ___ > BP1-A-1 yes _X_ no ___ abstain ___ > MH-1 yes ___ no _X_ abstain ___ This is a duplicate of BP1-7-4. A Mantis item should be created with a proposal for the exact changes needed. > MH-2 yes ___ no _X_ abstain ___ A Mantis item should be created with a proposal for the exact changes needed (one Mantis item could cover both MH-1 and MH-2). > MH-3 yes _X_ no ___ abstain ___ I approve based on the assumption that the requested change is to delete the words "Verilog syntax for" instead of the currently deleted "Verilog syntax". > HC-D-1 yes _X_ no ___ abstain ___ > HC-D-2 yes _X_ no ___ abstain ___ > HC-E-1 yes _X_ no ___ abstain ___ > HC-O-1 yes _X_ no ___ abstain ___ > HC-O-2 yes _X_ no ___ abstain ___ > HC-O-3 yes _X_ no ___ abstain ___ > HC-O-4 yes _X_ no ___ abstain ___ > HC-O-5 yes _X_ no ___ abstain ___ > HC-O-6 yes _X_ no ___ abstain ___ > HC-O-7 yes _X_ no ___ abstain ___ Most of Heath's issues were about formatting. The note at the beginning of these annexes already states that formatting still needs to be done. No review or voting on this type of issue was needed. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Apr 24 23:47:32 2007
This archive was generated by hypermail 2.1.8 : Tue Apr 24 2007 - 23:47:39 PDT