I have made some very minor changes from the copy of the IR which Ajay sent me, some reformatting, spelling changes, etc. Chuck Swart VHDL Issue Number: 2038 Language_Version: VHDL-2002 Classification: LRM Terminology, Grammar and Typographical Errors Summary: Minor semantic errors Relevant_LRM_Sections: Related_Issues: Key_Words_and_Phrases: Authors_Name: Chuck Swart Authors_Phone_Number: 503.685.0846 Authors_Fax_Number: 503.685.0921 Authors_Email_Address: cswart@model.com Authors_Affiliation: Model Technology Authors_Address1: - 8005 SW Boeckman Rd Authors_Address2: - Wilsonville, OR 97070 Authors_Address3: - Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 02 July 2004 Date Analyzed: 04 May 2006 Author of Analysis: Ajayharsh Varikat Revision Number: 3 Date Last Revised: 04 May 2006 Description of Problem ---------------------- This is a repository for low-level errors in the LRM which are basically typos, but which require some analysis to correct. An example is the use of the word "type" where "base type" or "subtype" is correct. Section references and direct quotes are from the VHDL-2002 LRM. For convenience, VHDL-93 line numbers are also indicated. Many of these issues were raised by James Unterburger, jamesu@model.com. 1. Section 1.3.1 (line 356) index-specification ::= discrete_range | <static_>expression Does not state that discrete_range must be (globally) static. Does not state that type of discrete_range or static_expression must be the same as the type of the FOR GENERATE parameter. Unclear if the discrete_range or static_expression must belong to the subtype of the FOR GENERATE parameter and what it means if they do not, or if a null discrete_range is allowed or not. 2a. Section 3.2.1.1 (line 366) The clauses which start with: "The index range for each index of an array object is determined as follows:" and is followed by a sequence of paragraphs beginning with "--".(numbered below) The -- paragraphs are hard to read, because they don't reflect the hierarchical nature of the cases. Technically, the LRM is correct: Each -- paragraph deals with a disjoint case. However, some of the paragraphs should be read together to fully understand the requirements. It would be better if the paragraphs were reformatted (perhaps using more indentation) to more accurately reflect relationships between the various cases such as: object declaration variable or signal (--1) constant (--2) attribute specification (--3) access value (--4) interface objects constrained array subtype (--5) unconstrained array subtype subprogram parameter association in whole (--6) individual association (--7) formal generic or port association in whole (--8) individual association (--9) local generic or port association in whole (--10) individual association (--11) 2b. Section 3.2.1.1 (lines 386,395,405) Same LRM area as 2a. Paragraphs --7,--9,--11 The rules for determining the index range(s) for individually associated formals of an unconstrained array subtype do not say what to do with null slice names in the choices in the association elements when determining the "maximum and minimum values of the indices given in the association elements corresponding to the formal". In fact, they don't mention slices at all, instead using the term "indices" meaning that they thought only of indexed names, and not slice names at this point in the LRM. 3. Section 3.3, (line 491) "...objects that are created by the evaluation of allocators (see 7.3.6) have no simple name." It also states that the access value returned by that allocator designates the object. Yet 8.5, (line 360) says "The determination of the type of the target of a variable assignment statement may require determination of the type of the expression if the target is a name that can be interpreted as the name of a variable designated by the access value returned by the variable..." Since objects designated by access values have no names, then how can the access value returned by a function call be the name of the value it designates? Comment: Is this nothing more than a name vs simple name issue? fcn.all := is ok. Also the issue might be moot since IR2048 recommends that access types be disallowed as return values from functions. 4. Section 4.3.2.2 (lines 463, 468, 474) Three paragraphs starting: "The formal part of a named element assocation..." Uses the the term "element association" when "association element" is intended. 5. Section 4.3.2.2, (line 511) Paragraph starting: "If an interface element in an interface list includes a default expression..." Verbiage for "formal port" should probably include a cross-reference to 1.1.1.2, where stricter rules are laid down. 6. Section 4.3.3.2 Nonobject aliases (line 594) "d) Alternatively, if the name denotes a physical type [...]" Indeed, physical types are always anonymous. This is due to clause 3.1.3 (Physical types): A physical type definition defines both a type and a subtype of that type. The type is an anonymous type, [...] As a consequence, the use of a nonobject alias is certainly more limited than expected (export feature described in LCS-0008). 7. Section 7.2.3, (line 138) Paragraph beginning: "The index subtypes of the return values of all shift operators are the same as the index subtypes of their left arguments" The term "index subtypes" is used instead of "index ranges" or "index bounds and direction". Perhaps this sentence should refer to them in the singular such as: "The index range of the return value of each of the shift operators is the same as that of the left operand." Also, left "operand" instead of left "argument". 8. Section 7.2.4, (line 203) Paragraph starting: "In all cases, it is an error if either bound of the index subtype of the result does not belong to the index subtype of the type of the result..." and 7.3.2.2, (line 409) Paragraph starting: "For an aggregate of a one-dimensional array type, each choice... An aggregate of an n-dimensional array type... is written as a one-dimensional aggregate in which the index subtype of the aggregate is..." and 7.3.2.2, (lines 439 and 440) Paragraph starting: "The bounds of an array that does not have an others choice are determined as follows. If the aggregate appears in one of the contexts in the preceding list, then the direction of the index subtype..." Same mistaking of "index subtype" for "index range" 9. Section 7.3.1, (lines 345 and 348) Paragraph starting: "For a nonnull array value represented by ... the direction and bounds of the array value are determined by...For a null array value...the direction and leftmost bound of the array value are determined..." They mention "the direction and bounds of the array value" but they mean "direction and bounds of the array's index range". Comment: This might be OK. 10. Section 7.3.1, (line 347) Paragraph starting: "For a nonnull array value represented... For a null array value represented... the direction and leftmost bound of the array value are determined as in the non-null case..." The rules for determining the index bounds of a null string literal say to use either PRED or SUCC, yet the [14.1 Predefined attributes] rules for these attributes produce an error. A related problem is that the index range of a null array with an index subtype that is an enumeration type has no legal representation at all: type foo is array(character range <>) of bit; constant c : foo := ""; Constant c has left bound nul, direction TO, and right bound ??? 11. Section 7.3.2.2, (line 417) Paragraph starting: "Apart from a final element association with the single choice OTHERS... An OTHERS choice is locally static if the applicable index constraint is locally static." -- What does "applicable index constraint" mean? 12. Section 7.3.2.2, (line 421) Paragraph starting: "a) As an actual associated with a formal parameter or formal generic..." The list appears to have "formal port" left out by mistake, no doubt when they went from 87 to 93, where expressions in PORT MAPs became legal. 13. Section 8.4 Signal assignment statement Does not go into detail, as does 8.5.1, about how an implicit subtype conversion between array types during signal assignment occurs. Comment. This might be covered. 8.4.1 states: "The execution of a signal assignment statement whose target is of a composite type proceeds... Each such sequence is then used to update the projected output waveform of the driver of the matching subelement of the target." "Matching subelement" might be enough. 14. Section 8.4 Signal assignment statement and 8.5 Variable assignment statement For aggregate targets, does not specify whether or not an implicit subtype conversion occurs, for the aggregate as a whole, when of an array type. Comment.This might be covered. 8.4 states: "If the target of the signal assignment statement is in the form of an aggregate, then the type of the aggregate... This form of signal assignment assigns slices or subelements of the right-hand side values to the drivers associated with the signal named as the corresponding slice or subelement of the aggregate." 8.5 has similar wording for variable assignments. Does the term "corresponding" imply implicit conversion? 15. Section 8.5 Variable assignment statement (line 344) Paragraph starting: "If the target of a variable assignment statement is in the form of an aggregate, and if the locally static name..." Does not repeat rules similar to those stated in 8.4 (line 176), regarding OTHERS choice and discrete range choice. This paragraph starts with: "If the target of a signal assignment statement is in the form of an aggregate, and if the expression..." Proposed Resolution ------------------- TBD VASG-ISAC Analysis & Rationale ------------------------------ 1. The issues raised are valid. Any discrete range used in the index specification must be static. The grammar in section 1.3.1 should be modified to the following: index-specification ::= <static_>discrete_range | <static_>expression The issue about the type of the index specification has been addressed in IR2083. The LRM states that "If such a block configuration contains an index specification that is a discrete range, then the block configuration applies to those implicit block statements that are generated for the specified range of values of the corresponding generate parameter; the discrete range has no significance other than to define the set of generate statement parameter values implied by the discrete range." This indicates that a null range, although legal, defines an empty set of generate statement parameter values, and hence would have no effect on elaboration. 2a. This section has been rewritten in addressing FT14 and IR2054. The changes in LCS-2006-113 make this much clearer. 2b. This has been addressed in IR2054 and LCS-2006-113. 3. A variable designated by an access value has no name, and hence the sentence quoted here is inaccurate. The intent of this sentence is to point out one situation where the type of the expression in a variable assignment has to be evaluated in order to determine the type of the target. Since this aspect is already covered in other normative sections of the LRM, this particular sentence is redundant and may either be removed or converted into a note. 4. While this was an issue in the 1993 standard, it has been addressed in the 2002 revision. 5. The quoted paragraphs from sections 4.3.2.2 and 1.1.1.2 contain both overlapping and complementary aspects for ports that are unconnected, unassociated or have default expressions. There is already a cross reference from 1.1.1.2 to 4.3.2.2, and it would be useful to have the reverse cross-reference. 6. An alias declaration can be used to import and export declarations. For example, an alias for an item from package A could be declared in package B, and anyone using package B would automatically have access to the aliased item. However, as the submitter points out, this is not possible for anonymous types, because the type has no name that could be used in an alias declaration. This is a limitation in the language right now, and a note may be added at the end of section 4.3.3.2 to indicate this. If there is a real need among users for such a feature, we could forward this to the appropriate language enhancement working group. 7. As the submitter points out, the term "index range" is more appropriate here. Knowing the index subtype of the left operand would be insufficient to determine it's range if the operand has an unconstrained index subtype. The proposed change in wording is accepted. 8. For the issue from section 7.2.4, change the quoted sentence to: "In all cases, it is an error if either bound of the index range of the result does not belong to the index subtype of the type of the result..." For the first issue from 7.3.2.2, the current usage of the term index subtype is appropriate. For the second issue from 7.3.2.2, this sentence has been deleted as part of the changes from LCS-116. However, there are other sentences introduced that refer to the direction of an index subtype. These should be changed to refer to the direction of the corresponding index range. 9. The sentence quoted here refers to the "direction and bounds of an array value". It would be technically more accurate to use the phrase "direction and bounds of the array's index range", although the intent is clear in the current wording. 10.The rules for determining the index bounds of a null string or bit-string literal break if: a) The direction is ascending and the left bound is equal to I'left where I is the index subtype, or b) The direction is descending and the left bound is equal to I'right where I is the index subtype. One way to resolve this would be to determine the index bounds of such a null array as follows: a) If the direction is ascending, then the left bound is I'right and the right bound is I'left b) If the direction is descending, then the left bound is I'right and the left bound is I'right This may introduce backward compatibility issues. An alternative that does not have backward compatibility issues is to define new rules for determining the left bound for a null string or bit-string array for the broken boundary cases. 11.The "applicable index constraint" here refers to the index constraint associated with the index subtype of the array aggregate. 12. This has been addressed in IR2040. 13. The second paragraph in section 8.5.1 describes what the implicit subtype conversion means in terms of matching elements. Similar semantics are specified in the last but one paragraph of section 8.4.1. Specifically, by the sentence: "Each such sequence is then used to update the projected output waveform of the matching subelement of the target". 14. For signals, this is covered by the paragraph from section 8.4.1 quoted in (13) above. This applies to aggregate targets as well. For variables, there is a paragraph in section 8.5 that states: "If the target of the variable assignment statement is in the form of an aggregate, then the type of the aggregate... This form of signal assignment assigns each slice or subelement of the right-hand side value to the variables named as the corresponding slice or subelement of the aggregate." 15. Section 8.4 has a paragraph that states: "If the target of a signal assignment statement is in the form of an aggregate, and if the expression... It is an error if a given signal name or any subelement thereof is identified as a target by more than one element association in such an aggregate. Furthermore, it is an error if an element association in such an aggregate contains an others choice or a choice that is a discrete range" The motivation for the last sentence in this paragraph appears to be that the use of others choices and discrete ranges may associate a given signal (or subelement) at multiple places in an aggregate, which would result in assignments happening multiple times to the corresponding drivers. There is a similar issue in variable assignments. If there are multiple assignments to any variable (or subelement), then the order in which they are executed would determine the final value. Since this order is implementation defined, the final value would also be implementation dependent. To avoid this, a restriction similar to the one in 8.4 should be added to the corresponding paragraph in 8.5. VASG-ISAC Recommendation for IEEE Std 1076-2003 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- 1. Implement the changes mentioned in the analysis. 2. Addressed by IR2054. 3. Delete the paragraph mentioned in the analysis. 4. This is already addressed in IEEE Std 1076-2003. 5. Add the cross-reference mentioned in the analysis. 6. Forward to Requirements WG. 7. Implement the proposal in the analysis. 8. Implement the changes from the analysis section. 9. Implement the new wording suggested in the analysis section. 10. TBD. 11. No change. 12. Superseded by IR2040. 13. No change. 14. No change. 15. Implement the changes suggested in the analysis.Received on Thu May 4 13:39:15 2006
This archive was generated by hypermail 2.1.8 : Thu May 04 2006 - 13:39:16 PDT