I have looked over all of John's review comments. There are several font or other formatting issues which are editorial. As long as these are clearly noted in the bug-notes of the appropriate Mantis item, I will take care of them for draft 7a. Interspersed in the editorial corrections, John has added lots of "I think" and "I recommend" types of opinions. These are not editorial corrections to how the proposed changes were implemented; they are changes to the proposals and/or existing LRM text. If there are issues that need to be addressed, then new Mantis items need to be opened. These opinions will not be implemented as part of the draft 7a corrections. Having opinions interspersed with real corrections in the same bug note will make it difficult for the editor to find the actual corrections, and make it difficult for the AC committee to determine if the actual corrections were made. As the editor, I request that the AC committee enter a new bug note to each Mantis item with this intermixing problem, where the new bug note explicitly lists only the editorial corrections that need to be made to draft7's implementation of the proposal. I replaced "iff" with its defined English wording of "if, and only if" for a reason. The text of the LRM should use proper English to describe syntax and semantics. The word "iff" is a keyword and can be used when talking specifically about that keyword. It is NOT an English word, and should not be used to describe syntax and semantics. We allowed it in Annex F and the IEEE let it slide by for 1800-2005. At the AC's insistence, one paragraph has been added in the main text of the LRM that uses this term. I will be surprised if this makes it past the final IEEE reviews of the LRM. Even after final ballot, the IEEE can changed--and has changed in past 1364 and 1800 LRMs--what they feel is incorrect English wording or punctuation. We want to avoid leaving the door open for the IEEE to change wording after ballot is complete. As the editor for the standard, one of my responsibilities is to try to ensure that the proposals that are added meet the IEEE requirements for wording, the use of fonts, etc. When a proposal does not meet IEEE requirements, it is my job to correct it. It is the committee's job to review my work and ensure that any such corrections do not inadvertently change the meaning of the proposal or the standard. Changing "iff" to its proper English wording is the right thing for the standard, and does not change the meaning of the proposal. Stu ~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland stuart@sutherland-hdl.com +1-503-692-0898 www.sutherland-hdl.com > -----Original Message----- > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of > John Havlicek > Sent: Monday, September 22, 2008 8:30 AM > To: sv-ac@eda.org > Subject: [sv-ac] Draft 7 review[SPAM] > > Hi All: > > Below are the results of my Draft 7 review. I've entered notes > in Mantis and switched from completed to editor state where > appropriate. > > Note that some of these recommendations may require SV-AC approval > before the editor will act on them. > > J.H. > > Draft 7 Review: > --------------- > > 1549 (bug note 7087) > The bug note specified one paragraph for the two sentences in 16.8 > describing name resolution. Draft 7 has them in separate paragraphs. > I think that the separate paragraphs can be left as they are or > joined into one. > The change of property to courier bold in the third paragraph of > 16.13.18 > was done in the first sentence, but not in the second. There is also > an > instance of the phrase "of type property" in the second paragraph of > 16.13.18 > that should follow the same font convention. The bug note did not > specify > the multiple occurrences explicitly. > In F.2, The references to item that existed before 2434 have been > italicized. > However, 2434 adds a reference to item that is not italicized. I > think that > the font should be roman italic, not courier italic. There are also > two > other references to item added by 2434 in F.5.2.1, one in 3)b) of > flatten_property(p), and one in 3)b) of flatten_sequence(r). Their > fonts > should be made consistent as well. > By the way, the rewriting algorithm subsections (F.5.2, F.5.3) do not > belong in > F.5 (Extended expressions). They should be in their own F.x section > called > "Rewriting algorithms". This may have resulted from mistaken > instructions in > the proposals, but it does not make sense to have them underneath > "Extended > expressions". > > 1648 (bug notes 7089 and 7206) > In 16.16, I think that assertion a8, the always procedure that > contains it, > and the preceding comment should be deleted. This is because > concurrent > assertions in procedural code have been changed by SV-SC, and this > example > is not consistent with those changes. > > 1667 (bug note 7167) > No issue found. > > 1667 (Annex F) > F.5.2.1, flatten_property(p), 6). Mantis 2434 has eliminated the > capability > for default actual arguments to reference formal arguments. > Therefore the > linear ordering described in this step needs to be stricken. This > obviates > the need to answer the editor's question; for those interested, the > correct > reference is to 16.13.19. I recommend deleting the following: > > Determine a linear ordering of the local variable formal arguments > of p' so > that one local variable formal argument is guaranteed to precede a > second > local variable formal argument if the second local variable formal > argument > has a default actual argument that references the first local > variable > formal argument. According to 16.8.2, each local variable formal > argument > of a property is of direction input. > > I recommend changing > > Arrange these local variable declarations to be in the linear > order chosen > above. > > to > > These local variable declarations may be arranged in any order. > > F.5.2.1, flatten_sequence(r), 6). Mantis 2434 has eliminated the > capability > for default actual arguments to reference formal arguments. > Therefore the > linear ordering described in this step needs to be stricken. I > recommend > deleting the following: > > Determine a linear ordering of the local variable formal arguments > of r' so > that one local variable formal argument is guaranteed to precede a > second > local variable formal argument if the second local variable formal > argument > has a default actual argument that references the first local > variable > formal argument. > > I recommend changing > > Arrange the local variable declarations added to the beginning of > the body > of r' to be in the linear order chosen above. > > to > > The local variable declarations added to the beginning of the body > of r' > may be arranged in any order. > > F.5.2.1, flatten_sequence(r), 6)b) and 6)c). In each, change roman > "sequence expr" > to roman italic "sequence_expr" near the end of the sentence. > Editor's question after flatten_sequence(r) in F.5.2.1. The reference > to 16.8.2 > is correct. > > 1668 (bug note 7169) > Not implemented in Draft 7. > > 1668 (bug note 7170) > No issue found. The editor did not implement the section renumbering > suggested. > The editor recommends that SV-AC approve this change. The suggestion > has been > repeated in comments for 1549. > > 1687 (bug note 7171) > No issue found. > > 1698 (bug notes 7090 and 7131) > 16.9.3, in the paragraph beginning "$past returns the value of > expression1". Change > in two places > > ev if, and only if, expression2 > > to > > ev iff expression2 > > as in the proposal. The fonts should be italic for "ev" and > "expression2" and > bold courier for "iff". > > Rationale: "ev iff expression2" is itself an event expression and is > precisely > the event expression that is required for this discussion. > > 1734 (bug note 7166) > No issue found. > > 1806 > In Syntax 16-20, add > > | restrict_property_statement > > to the RHS of the production for concurrent_assertion_statement. > > 2100 (bug note 7064) > In F.4.1, the editor has faithfully rendered T^p as shown in the > proposal, but this font will need to be aligned with the font of > T^p from the Annex F changes from 1932. The T is supposed to be > in a calligraphic font. > > 2173 > In Syntax 16-16 and Annex A.2.10, RHS of production for > property_declaration, > there should be no red ";" following property_statement_spec. > 16.13.16, the horizontal line at the top of Syntax 16-19 is missing. > F.3.4.6, the sentence beginning "Where specify(b) is ..." needs to > apply to all > the items with case property statements. The proposal shows this > text shifted > to the left. I think it will be better to put this text before the > items with > case property statements and change the wording to "Let specify(b) be > ...". > > 2327 > In 16.15.8, item ac), change > > if, and only if, the evaluation attempt of property_expr1 is > nonvacuous and > either expression_or_dist never holds or the evaluation of > property_expr > ends before the first clocking event where expression_or_dist > holds for the > first time. > > to > > if, and only if, the underlying evaluation attempt of > property_expr is > nonvacuous and expression_or_dist does not hold in any time step > of that > evaluation attempt. > > as in the proposal. The language for items ab) and ac) needs to be > aligned. > In 16.15.8, item ad), I think that the expression_or_disti and > property_stmti > should be set using the same font conventions in the case property > statement > and in the explanation. I prefer the italic font with subscripts as > in the > proposal. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Sep 22 09:14:17 2008
This archive was generated by hypermail 2.1.8 : Mon Sep 22 2008 - 09:14:26 PDT