At yesterday's meeting these three IRs were approved. However, there was not a quorum. So please vote on them. IRs 2111 and 2112 are unchanged. IR1000 contains minor revisions suggested at the meeting. I compaared the current version with the previous, and it contains the proposed changes. Yes No ___ ___ 1000 ___ ___ 2111 ___ ___ 2112 Also, Jim suggested that we describe the Accellera approved version of the LRM as P1076-2006/D3.0 instead of P1076-2007/D3.0 What do you think of this idea? Chuck Swart -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. VHDL Issue Number: 1000 Classification: Terminology, Grammar, and Typographical Errors Language Version: VHDL-93 Summary: Accumulated typographical and terminology errors. Related Issues: 1106 Relevant LRM Sections: Many. Key Words and Phrases: typographical errors, grammatical errors, terminology Current Status: Analyzed 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1994/08/01 - 1995/05/05 Author of Submission: Daniel S. Barclay (for various eagle eyes) Author's Affiliation: COMPASS Design Automation, Inc. Author's Post Address: 5457 Twin Knolls Rd., Suite 100 Columbia, MD 21045 USA Author's Phone Number: 410-992-5700 Author's Fax Number: 410-992-3536 Author's Net Address: daniel@compass-da.com ----------------------- Date Analyzed: 4 March 2007 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: 13 March 2007 Description of Problem ---------------------- This is the VHDL issue report in which to accumulate small, definite errors such as typographical and grammatical errors, as well as simple terminology errors and simple omissions. Note: Less-definite problems with unclear wording should be entering in IR 1106. Note: It is unclear when technically imprecise wording should be reported herein or in IR1000. [Some LRM quotes are from the almost-final 1994/06/24 version. The notation {\i word} indicates that the word (or words) is italicized; {\b word} indicates that the word (or words) is in boldface type.] Typographical and Grammatical Errors: 1.1: In section B.250 (the glossary entry for update), there is one in- stance of "individually or as part of a slice" and one of "individually or part of a slice." It appears that the word "as" is missing from the second instance. 1.2: Section B.250 (the glossary entry for update) is missing the word "a" in "when it is subelement." 1.3: In section 3.2.1.1, the example is missing the formal's simple name "ROM" in the generic map: generic map ((1 to 2) => (others => '0')) 1.4: In section 2.3.1, the first note says: 1--Overloading of the equality operator does not affect the selection of choices in a case statement in a selected signal assignment statement; nor does it have an affect on the propagation of signal values. The second "affect" should be "effect." 1.5: In section 3.1.1.1, the first note says: 1--The first 17 nongraphic elements of the predefined type CHARACTER (from NUL through DEL) are the ASCII abbreviations for the printing characters in the ASCII set (except for those noted in Section 14). The ASCII names are chosen as ISO 8859-1 does not assign them abbreviations. The next 16 (C128 through C159) are also not assigned abbreviations, so names unique to VHDL are assigned. The number 17 should be 33, and the number 16 should be 32. (There are 33 (not 17) non-graphic characters from NUL through DEL, and 32 (not 16) characters in the range C128 through C159. [from Paul Graham of COMPASS Design Automation, Inc.] 1.6: In section 3.2.1.1, the example says: generic map ((1 to 2) => (others => '0')) It should say: generic map (ROM(1 to 2) => (others => '0')) 1.7: In section 7.2.4, an example says: type R1 is 0 to 7; type R2 is 7 downto 0; It should say: type R1 is range 0 to 7; type R2 is range 7 downto 0; 1.8: In section 14.1, in the example on page 191 for E'PATH_NAME, the first line says: library Lib: -- All design units are in this library: The first colon (:) should be a semicolon (;). 1.9: In section 1.3, in the last example, the last VHDL comment (with the text "use defaults" has an em dash instead of two hyphens. 1.10: In section 3.2.1.1, some writers and proofreaders really fell down on the job. The thirteenth paragraph begins: The directions of the index ranges of the formal parameter are that of the type of the formal ... Huh? "The directions are _that_ of ..."? No! "The directions are _those_ of ..." The sixteenth and nineteenth paragraphs have exactly the same problem: The directions of the index ranges of the formal generic or formal port are that of the type of the formal ... The directions of the index ranges of the local generic or local port are that of the type of the local ... Additionally, "type of the formal" should be "base type of the formal" to be clear. 1.11: In section 14.2 on page 199, the comments representing implicitly- defined multiplying operators for type TIME are wrong. The LRM lists the following operators: ... -- function "*" (anonymous: TIME; anonymous: INTEGER) return TIME; -- function "*" (anonymous: TIME; anonymous: REAL) return TIME; -- function "*" (anonymous: INTEGER; anonymous: TIME) return TIME; -- function "*" (anonymous: TIME; anonymous: INTEGER) return TIME; -- function "/" (anonymous: TIME; anonymous: REAL) return TIME; -- function "/" (anonymous, anonymous: TIME) return universal_integer; ... Note that multiplication of type REAL by type TIME is missing, and that the second multiplication of type TIME by INTEGER should be division. That is, the LRM should say: ... -- function "*" (anonymous: TIME; anonymous: INTEGER) return TIME; -- function "*" (anonymous: TIME; anonymous: REAL) return TIME; -- function "*" (anonymous: INTEGER; anonymous: TIME) return TIME; -- function "*" (anonymous: REAL; anonymous: TIME) return TIME; -- function "/" (anonymous: TIME; anonymous: INTEGER) return TIME; -- function "/" (anonymous: TIME; anonymous: REAL) return TIME; -- function "/" (anonymous, anonymous: TIME) return universal_integer; ... 1.12: In section 4.3.2 on page 59, the BNF production for interface_file_declaration is missing a colon. It says: interface_file_declaration ::= file identifier_list subtype_indication instead of saying: interface_file_declaration ::= file identifier_list : subtype_indication [from Jean-Jose Mayol and Paul Menchini] 1.13: In section 14.1, in the example for 'INSTANCE_NAME, it says: assert GBottom'Simple_Name = "bottom" ... instead of saying: assert GBottom'Simple_Name = "gbottom" ... [from Ernst Christen and Chuck Swart] 1.14: In section 14.2, for the predefined equality and inequality operators type FILE_OPEN_STATUS, six lines read: return BOOLEAN; Each should read: -- return BOOLEAN; [from Ernst Christen and Chuck Swart] 1.x: <add typographical and grammatical errors here> Definite Terminology Errors: 2.1: In section 4.3.2.2, there are four instances of "element association" that should be "association element": In the sixth text paragraph: The formal part of a named element association may be in the form of a function call... In the seventh text paragraph: Alternatively, the formal part of a named element association may be in the form of a type conversion... In the eighth text paragraph: Similarly, the actual part of a (named or positional) element association may be in the form of a function call... In the ninth text paragraph: Alternatively, the actual part of a (named or positional) element association may be in the form of a type conversion... 2.2: In section 4.3.3, the second note says, "The alias of an overloadable object is itself overloadable." This is in incorrect use of the term "object." Objects are not overloadable. This use probably should be "named entity." 2.3: In section 3.2.1.1, in the fourth paragraph, the second sentence says: If any of the discrete ranges defines a null range, any array thus constrained is a {\i null array}, having no components. This use of the term "components" is wrong. It should be the term "elements." (This appears to be an old error; Ada uses the term "components" for what VHDL calls elements. 2.4: In section 4.3.2.2, the third note says: --Named association may not be used when invoking implicitly defined operations, since the formal parameters of these operators are not named (see 7.2). "Operations" should be "operators." ("Operators" should not be changed to "operations" because some predefined operations that are functions or procedures do have named formal parameters.) [from Paul Graham of COMPASS Design Automation, Inc.] 2.5: In section 6.1, in the second full text paragraph, the first sentence says: Certain forms of name (indexed and selected names, slices, and attribute names) include a {\i prefix} that is a name or a function call. "Slices" should be "slice names." [from Paul Graham of COMPASS Design Automation, Inc.] 2.6: In section 6.3, in the eighth text paragraph, the first sentence says: An expanded name denotes a named entity declared immediately within a named construct if the prefix denotes a construct that is an entity interface, an architecture, a subprogram, a block statement, a process statement, a generate statement, or a loop statement, and the suffix is the simple name, character literal, or operator symbol of a named entity whose declaration occurs immediately within that construct. "Entity interface" should be "entity declaration." Assuming that the term "construct" refers to syntactic non-terminals, there is no such syntactic construct as an entity interface. "Subprogram" should be "subprogram declaration" and "subprogram body." Again, assuming that the term "construct" refers to syntactic non- terminals, there is no such syntactic construct as an entity inter- face. "Architecture" really should be "architecture body" to be clear and precise. 2.7: In section 2.3, the third paragraph says: A call to an overloaded subprogram is ambiguous ... if [certain things] are not sufficient to identify exactly one (overloaded) subprogram specification. Subprogram specifications are not overloaded. Subprograms or subpro- gram declaration are. "Subprogram specification" should be "subprogram" or maybe "subprogram declaration." 2.8: There are a number of incorrect references to the undefined term "entity interface." (Also see entry 4.5, for less clear problematic uses of the term.) - In section 5.1, the 10th paragraph says: ... If the entity name list denotes an entity interface, architecture body, or configuration declaration, then the expression is required to be locally static (see 7.4) This occurrence of "entity interface" should be "entity declaration." The other items in the list ("architecture body" and "configuration declaration") are constructs. "Entity interface" is not a construct; "entity declaration" is. - In section 6.3, the eighth paragraph says: An expanded name denotes a named entity declared immediately within a named construct if the prefix denotes a construct that is an entity interface, an architecture, a subprogram, a block statement, a process statement, a generate statement, or a loop statement, and the suffix is the simple name, character literal, or operator symbol of a named entity whose declaration occurs immediately within that construct. ... There is no such construct as an "entity interface." Additionally, "architecture" and "subprogram" are not constructs either. If "constructs" is really meant, then these should be changed to "entity declaration", "architecture body" and "subprogram declaration." If "construct" is not actually meant, then "construct" should be changed, and "design entity" (or maybe "design entity interface") should be used. 2.9: In section 5.2.1, the first paragraph says: A binding indication associates instances of a component declaration with a particular design entity. ... "Component declaration" should be "component." A component declaration is a piece of syntax. There is only one instance of a component declaration--the component declaration itself. A component instantiation statement defines an instance of the component defined by a component declaration, but not an instance of the declaration itself. 2.10: Section B.55 says: ... The declarative part defines the lexical area (usually introduced by a keyword such as is and terminated with another keyword such as begin) within which declarations may occur. ... "Keyword" should be "reserved word." VHDL does not have keywords. It has reserved words. (For proof, search for "keyword" in the body of the LRM. Then look at the title of section 13.9.) 2.11: In section 9.2, the production for process_declarative_item says group_type_declaration when it should say group_template_declaration. [from Chuck Swart of Analogy] 2.x: <add terminology errors here> Definite Simple Omissions: 3.1: Section 13.2 says: A space character (SPACE or NBSP) is a separator except within a comment, a string literal, or a space character literal. This list of lexical tokens should include "extended identifier" also. 3.2: In section 4.3.1.2, the ninth text paragraph says If a subelement or slice of a resolved signal of composite type is associated as an actual in a port map aspect (either in a component instantiation statement or in a binding indication), and ... The parenthesized wording should include block statements also. 3.3: In section 5.1, the last text paragraph before the examples says: An attribute specification whose entity designator contains no signature and identifies an overloaded subprogram has the effect of associating that attribute with each of the desig- nated overloaded subprograms declared within that declarative part. "Overloaded subprogram" should be "overloaded subprogram or enumera- tion literal." (It may be defined elsewhere that enumeration literals are treated as subprograms for overload resolution, but they are never defined to _be_ subprograms.) [from Paul Graham of COMPASS Design Automation, Inc.] 3.x: <add other simple omissions here> Other Terminology Problems: 4.1: In section 2.1.1, the fifth text paragraph begins: In a subprogram call, the actual designator (see 4.3.2.2) associated with a formal parameter of class {\b signal} must be a signal. Actually, the actual designator is not a signal; it is a name that denotes a signal. It would be better if "must be" were "must denote", or if "actual designator" were "actual." This applies to the remaining sentences in that paragraph: The actual designator associated with a formal of class {\b variable} must be a variable. The actual designator associated with a formal of class {\b constant} must be an expression. The actual designator associated with a formal of class {\b file} must be a file. 4.2: In section 10.5, the sixth paragraph says: b) Any rule that requires the type of a name or expression to be a type of a certain class; similarly, any rule that requires a certain type to be a discrete, integer, floating point, physical, universal, character, or Boolean type. There is no such thing as a Boolean type. Requiring something to be of predefined type BOOLEAN belongs with the previous numbered paragraph: a) Any rule that requires a name or expression to have a certain type or to have the same type as another name or expression. [from Paul Graham of COMPASS Design Automation, Inc.] 4.3: In section 2.3, the second paragraph says: A given subprogram designator can be used in several sub- program specifications. The subprogram designator is then said to be overloaded; ... This wording does not implement the intended definition. According to the wording, any subprogram with an explicit declaration is overloaded. The subprogram designator is used in the subprogram specification of the subprogram declaration, and it is used in the subprogram specification of the subprogram body. Therefore, it is used in more than one subprogram specification, so it is overloaded This makes no sense. And how many is "several"? Sheesh, this is a language definition, not a touchy-feely approximate impression of the language. Somehow distinguish the (touchy-feely approximate) introduction and orienta- tion to concepts from the precise definition. 4.4: In section 5.1, the fifteenth paragraph says: The decoration of a named entity that can be overloaded attributes all named entities matching the specification already declared in the current declarative part. This wording is very poor and hard to read. The word "attribute" should not be used as a verb here. It makes "overloaded attributes" looks in a noun phrase, and "decorate" is already defined to the be the verb that denotes this action. The words "the specification already declared in ..." looks like a noun phrase. Don't be afraid to say the word "that", as US reporters and news anchors seem to be. This would be much clearer if all named entities matching the specification already declared in the current declarative part were changed to all named entities that are already declared in the current declarative part and that match the specification or to something a little smoother. Finally, is it really the decoration of a named entity that decorates others, or is it something else? 4.5: The term "entity interface" used incorrectly in a number of places. (Also see entry 2.8, for more definitely incorrect uses of the term.) - In section 5.3, the last note paragraph says: 2--Since disconnection specifications are based on declarative parts, not on declarative regions, ports declared in an entity interface cannot be referenced by a disconnection specification in a corresponding architecture body. "Entity interface" should be "entity declaration." Everything else relevant in the paragraph deals with syntax. Entity interfaces are not syntactic; entity declarations are. - In section 5.2.2, the seventh normal paragraph says: It is an error if there is no architecture body associated with the entity interface denoted by an entity name that is the simple name of the instantiated component. This would be clearer if "entity interface" (something other than a construct) were replaced with "entity declaration" (a construct) to parallel the reference to "architecture body" (a construct). - In section 5.2.1, the first paragraph says: ... It may also associate actuals with formals declared in the entity interface. Formals are declared to be part of, or to exist in, the design entity interface defined by the entity declaration. However, they are not declared in an "entity interface." They are declared in an entity declaration, by declarations that exist in the entity declaration. - In section 6.2, the first paragraph says: ... In particular, the simple name for an entity interface, a configuration, a package, a procedure, or a function is the identifier that appears in the corresponding entity declaration, configuration declaration, package declaration, procedure declaration, or function declaration, respectively. The term "design entity interface" would be better than "entity interface." Neither is a clearly defined term, but "design entity interface" appears to mean "interface to a design entity", which is already used. 4.6: In section 10.2, the fourth full paragraph says: In addition to the above rules, the scope of any declaration that includes the end of the declarative part of a given block (whether it be an external block defined by a design entity or an internal block defined by a block statement) extends into a configuration declaration that configures the given block. The wording the scope of any declaration that includes ... extends should be something like if the scope of a declaration includes ..., then the scope extends ... or for a declaration whose scope includes .... the scope extends ... It is declarations whose _scope _includes the end of the declarative part of the block, not _declarations_ that include that end. 4.7: The wording "may" and "may not" is used ambiguously and inconsistent- ly throughout the LRM. (By the way, this entry is not just pickiness on my part. Ta-Yung Liu (at liu@cs.ucr.edu as of 1995/05/01) was confused by the wording for aliases.) At different places, "may not" is used to mean "might not," "cannot," "must not" ("is not allowed to"), and "is allowed not to." Additionally, "may" is used to mean "might" or to mean "is allowed to" (typically optionally). These terms should be clarified and used more consistently. It is not clear exactly what the best solution is. Mainly, "may not" should be used in more than on sense. The following suggestions might help: - Where "may not" means "is not allowed to" (specifying a restriction) it should be "must not" (or "is not allowed to"). - Where "may" means "is allowed to" (specifying allowed cases), it should be "is allowed to" or possibly "may." - Where "may not" means "cannot" (describing implications of other restrictions), it should be "cannot." - Where "may" means "can" (describing results of other rules), it should be "can." - Where "may not" means "might not" because something "is allowed not to," it should be "might not." - Where "may" means "might," it should be "might." Section 2.1.1.1 says, in the last note paragraph: 2--As a consequence of the parameter passing conventions ... the shared variable may not be updated until the procedure completes its execution. Furthermore, a formal variable parameter with modes in or inout may not reflect updates made to a shared variable associated with it as an actual during the execution of the subprogram ... For both occurrences, "may not" could be taken to mean "is not allowed to be," but means "might not." They should be "might not." Section 2.2 says, in note 5: 5--A pure function subprogram may not reference a shared variable. This prohibition exists because a shared variable may not be declared in a subprogram declarative part and a pure function may not reference any variable declared outside of its decla- rative region. All three occurrences could be taken to mean "must not" (specifying a restriction), but they mean "cannot" (describing the result of other restrictions). Section 3.1.4 says, in the note: NOTE--An implementation is not required to detect errors in the execution of a predefined floating point arithmetic operation, since the detection of overflow conditions resulting from such operations may not be easily accomplished on many host systems. The occurrence of "may not" should be "might not." Section 4.2 says, in the last non-note paragraph: A subtype indication denoting an access type or a file type may not contain a resolution function. ... The occurrence of "may not contain" means "is not allowed to contain," and should be simply "must not." Section 4.3.1.3 says, in an example: Counter := Counter + 1; -- The subtype check may or may not fail. ... Counter := Counter - 1; -- The subtype check may or may not fail. These occurrences mean "might or might not," and should say that to be consistent and clearer. Section 4.3.2 says: in. The value of the interface object may only be read. In addition, any attributes of the interface object may be read, except that attributes 'STABLE, 'QUIET, 'DELAYED, and 'TRANSACTION of a subprogram signal parameter may not be read within the corresponding subprogram. ... The occurrence of "may not be read" means "is not allowed to be read" and should be "must not." Section 4.3.2.1 says: A name that denotes an interface object may not appear in any interface declaration within the interface list containing the denoted interface object except to declare this object. This occurrence means "is not allowed to" and should be "must not." Section 4.3.2.2. says, in the third note paragraph: 3--Named association may not be used when invoking implicitly defined operations, since the formal parameters of these operators are not named (see 7.2). This occurrence could be taken to mean "must not" (specifying a restriction), but it means "cannot" (describing the result of other restrictions), and should be "cannot". Section 4.3.3.1 says: a) A signature may not appear in a declaration of an object alias. This occurrence means "is not allowed to" and should be "must not." Section 4.3.2.2 says: a) A subtype indication may not appear in a nonobject alias. This occurrence means "is not allowed to" and should be "must not." Section 4.4 says, in the first paragraph: ... Predefined attributes that are signals may not be updated. This occurrence means "is not allowed to" and should be "must not." Section 4.7 says: A name that is a group constituent may not be an attribute name (see 6.6), nor, if it contains a prefix, may that prefix be a function call. The first occurrence means "is not allowed to be" and should be "must not." The second occurrence means the same thing except is a different construction, and requires a more careful change. Section 6.3 says: The remaining forms of selected names are called expanded names. The prefix of an expanded name may not be a function call. This occurrence means "is not allowed to" and should me "must not." Section 7.2 says: Operators of higher precedence are associated with their operands before operators of lower precedence. ... The precedence of an operator is fixed and may not be changed by the user, but parentheses can be used to control the association of operators and operands. This occurrence means "cannot" (there is not mechanism to change the precedence) and should be "cannot". Section 7.2 says, in the last non-note paragraph's last sentence: No predefined operators have named formal parameters; there- fore, named association (see 4.3.2.2) may not be used when invoking a predefined operation. First of all, this occurrence of "may not" means "cannot." Specifi- cally, the clause after the semicolon does not specify a restriction; it describes the result of other rules in the LRM. Therefore, the "may not" should be "cannot." Second, because this is a description and not a specification, this should be a note. Third, the third note in section 4.3.2.2 already covers this: 3--Named association may not be used when invoking implicitly defined operations, since the formal parameters of these operators are not named (see 7.2). Section 9.2 says: If a sensitivity list appears following the reserved word process, then the process statement is assumed to contain an implicit wait statement as the last statement of the process statement part; this implicit wait statement is of the form wait on sensitivity_list ; where the sensitivity list of the wait statement is that following the reserved word process. Such a process statement must not contain an explicit wait statement. Similarly, if such a process statement is a parent of a procedure, then that procedure may not contain a wait statement. Here "may not" means "is not allowed to" and should be "must not". Section 9.5 says: If the target of a concurrent signal assignment statement is in the form of an aggregate, then the same transformation applies. Such a target may only contain locally static signal names, and a signal may not be identified by more than one signal name. The "may only contain" means "is allowed to contains only" and should be "must contain only." (Note that "only" was in the wrong place.) Section 11.2 says: For a given library logical name, the actual name of the corresponding design libraries in the host environment may or may not be the same. A given implementation must provide some mechanism to associate a library logical name with a host- dependent library. Such a mechanism is not defined by the language. Is not clear whether the point is that the names may be (are allowed to be) either the same or different, or that the names might be either the same or different. It appears to be that they are allowed to be either. Section 12.6.2 says: 5--No effective value is specified for out and linkage ports, since these ports may not be read. This occurrence could be taken to mean "must not" (specifying a restriction), but it means "cannot" (describing the result of other restrictions), and should be "cannot". Section 14.1 says, in the definition of 'INSTANCE_NAME: A library logical name denotes a library; see 11.2. Since multiple logical names may denote the same library, the library logical name may not be unique. The occurrence of "may" means "is allowed to" or "can." It is not clear what it should be. The occurrence of "may not" could be mistaken to mean "is not allowed to be unique," but it means "might not be unique" (and "is allowed to be non-unique") and should be "might not." Section 14.2 says, in the first paragraph: Package STANDARD predefines a number of types, subtypes, and functions. ... Package STANDARD may not be modified by the user. This occurrence means "is not allowed to be" and should be "must not." Section 14.3 says, in the second paragraph after the VHDL text of package TextIO: The language does not define the representation of the end of a line. ... However, as an implementation is permitted to use certain values of types CHARACTER and STRING as line delimiters, it may not be possible to read these values from a TEXT file. This occurrence of "may not" could be mistaken to mean "is not allowed to be possible," but it means "might not be possible" (and "is allowed to be impossible") and should be "might not." Note: There are many occurrence of "may" (without a "not") in the LRM; they should be revised also. 4.x: <add other terminology problems here> Proposed Resolution ------------------- For the current version of VHDL, interpret the text as if it said what it should say. For the next version of VHDL, correct the text to say what it should say. VASG-ISAC Analysis & Rationale ------------------------------ In the following, items marked "**" require changes to be made. 1.1: Corrected in VHDL-2002. 1.2: Corrected in VHDL-2002. 1.3: This is corrected in P1076-2007/D3.0 to generic map ( ROM(1 to 2) => (others => (others => '0')) ) 1.4: Corrected in VHDL-2002. 1.5: Corrected in VHDL-2002. 1.6: This is corrected in P1076-2007/D3.0 to generic map ( ROM(1 to 2) => (others => (others => '0')) ) 1.7: Corrected in VHDL-2002. 1.8: Corrected in VHDL-2002. **1.9: This is a typo. The em dash should be replaced with two hyphens. 1.10: The grammatical errors in the thirteenth, sixteenth and ninetheenth paragraphs are corrected in VHDL-2002. Also, the change to "base type" is implemented in VHDL-2002. 1.11: The error described by the submitter occurs in the printed form of 1076-1993, but is corrected in the PDF form of that revision and in subsequent revisions. 1.12: Corrected in VHDL-2002. 1.13: Corrected in VHDL-2002. 1.14: Corrected in VHDL-2002. 2.1: Corrected in VHDL-2002. 2.2: Corrected in VHDL-2002. **2.3: Corrected in VHDL-2002. However, there is a further occurrence in Annex B in the glossary entry for "update". The text "or a component of the target" should be changed to "or an element of the target" in two places. 2.4: Corrected in VHDL-2002. 2.5: Corrected in VHDL-2002. 2.6: Corrected in VHDL-2002. 2.7: Corrected in VHDL-2002. 2.8: Corrected in VHDL-2002. 2.9: Corrected in VHDL-2002. 2.10: Corrected in VHDL-2002. 2.11: Corrected in VHDL-2002. 3.1: Corrected in VHDL-2002. 3.2: Corrected in VHDL-2002. 3.3: Corrected in VHDL-2002. 4.1: Corrected in VHDL-2002. 4.2: Corrected in VHDL-2002. 4.3: Corrected in VHDL-2002. 4.4: Corrected in VHDL-2002. 4.5: Corrected in VHDL-2002. **4.6: The cited wording does not correctly express the intent. The first suggested rewording expresses the intent, and is similar in form to wording in the subsequent paragraph. The cited paragraph should be revised to: In addition to the above rules, if the scope of any declaration includes the end of the declarative part of a given block (whether it be an external block defined by a design entity or an internal block defined by a block statement), then the scope of the declaration extends into a configuration declaration that configures the given block. **4.7: Most of the uses of "may not" have been replaced in VHDL-2002. Use of "may not" in the sense of "is allowed not to" is acceptable according to IEEE style guidelines. ** 4.3.2.2 Note 3: Change to "cannot". 4.7: Changed to "must not" in P1076-2007/D3.0. 7.2: The text describing the fact that predefined operations cannot be invoked using named association is a corollary of other rules. However, there are other places in the LRM where corollaries are included in the normative text. IEEE style guidelines do not preclude such text. The text should remain. **11.2: Change "the library logical name may not be unique" to "it is possible that the library logical name not be unique." **14.2: Change "Package STANDARD cannot be modified by the user" to "Package STANDARD must not be modified by the user." VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- Interpret as though the corrections had been made VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Make the corrections listed in the analysis.Received on Fri Apr 13 17:55:17 2007
This archive was generated by hypermail 2.1.8 : Fri Apr 13 2007 - 17:55:19 PDT