The following IRs are attached. They are also available on the Website. Yes No IR ----- ----- 2075 Arrays with numeric and enumeration index types are not closely related ----- ----- 2080 Case expression should include parenthesized expression ----- ----- 2081 The term ancestor is used where parent is meant VHDL Issue Number: 2075 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary Arrays with numeric and enumeration index types are not closely related Relevant_LRM_Sections 7.3.5 Type conversions Related_Issues Key_Words_and_Phrases closely related types, array types, type conversion Authors_Name Peter Ashenden Authors_Phone_Number +61 414 709 106 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Ashenden Designs Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 13 October 2005 Date Analyzed: Author of Analysis: Ajayharsh Varikat Revision Number: 2 Date Last Revised: 03 February 2006 Description of Problem ---------------------- A user has the following question: Given types: type SLV15To0 is array (15 downto 0) of std_logic; type SMRst is (RstIDE,RstIU,RSTOU, RstCF2B); type SMRstSLV is array (SMRst'left to SMRst'right) of std_logic; Given port identifier: EBD : inout SLV15To0; Given signal: signal SMRCR : SMRstSLV; How do I set SMRCR to the the 4 lsbs of EBD? An assignment SMRCR <: SMRstSLV(EBD(3 downto 0)); is not legal, since the array types are not closely related and so the type conversion cannot be applied. The types are not closely related since one index type is an abstract numeric type and the other is an enumeration type. Proposed Resolution ------------------- Consider whether arrays with other than numeric index types can be defined to be closely related, provided they are of the same dimensionality and have the same element type. VASG-ISAC Analysis & Rationale ------------------------------ Explicit type conversions are allowed only between closely related types. Closely related types are defined in section 7.3.5 of the LRM. In particular, two array types are closely related if, and only if, all of the following apply: - The types have the same dimensionality - For each index position, the index types are either the same or are closely related - The element types are the same In the example given in this IR, the second requirement is not satisfied, which makes it illegal. It is useful to be able to do explicit type conversions between array types that have the same element types, even if the index subtypes are not closely related. The expected result of the conversion is intuitively obvious in most cases. Since the concept of closely related types is only used in the context of type conversions, the easiest way to allow this kind of type conversion is to do away with the second requirement in the current definition of closely related types. This, however, introduces a new issue with type conversions when the target type is an unconstrained array type. For such target types, the bounds of the result are obtained by converting the bounds of the operand to the corresponding index type of the target type. However, for a target type that does not have closely related index types, the above rules for converting bounds are not valid. One way to resolve this issue is to prohibit type conversion to an unconstrained target type when the index types are not closely related. This, however, appears to be too severe a restriction. For example, you could have signals of the following types: signal src : SMRstSLV; signal dst : std_logic_vector(3 downto 0); An assignment from src to dst should be allowed with the appropriate type conversion. However, the only way this can be done is to use a target type that is an unconstrained array type. dst <= std_logic_vector(src); An alternative way to handle this situation would be to define new rules for computing bounds. The direction of the result could be defined to be that of the target type, and the left bound of each index position of the result could be the left bound of the corresponding target index type. The right bound of each index subtype could then be computed such that the size along each dimension of the result is the same as that of the operand. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Implement the second suggestion from the Analysis section. VHDL Issue Number: 2080 Language_Version VHDL-2002 Classification Language Definition Problem Summary Case expression should include parenthesized expression Relevant_LRM_Sections 8.8, page 127, para starting "If the expression is the name of an object..." Related_Issues Key_Words_and_Phrases case statement, locally static subtype Authors_Name Peter Ashenden Authors_Phone_Number +61 414 709 106 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Ashenden Designs Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 26 December 2005, Revised 13 January 2006 Date Analyzed: 02 February 2006 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: Chuck Swart Description of Problem ---------------------- Clause 8.8, in the bottom paragraph of page 127, specifies that the expression in a case statement must have a locally static subtype. It lists forms of expressions that can occur, but omits a parenthesized expression in which the contained expression has a locally static subtype. (This omission was earlier pointed out by John Ries, but has not formally been reported and tracked.) Moreover, on the top of page 128, the clause lists allowed forms for an expression of a one-dimensional array type. Similarly, the list omits a parenthesized expression containing an otherwise allowed form of expression. Proposed Resolution ------------------- In the bottom paragraph of page 127, add the following to the end of the last sentence: ", or if the expression is an expression described in this paragraph and enclosed in parentheses". In the list at the top of page 128, add a further list item: -- An expression described in this list and enclosed enclosed in parentheses VASG-ISAC Analysis & Rationale ------------------------------ The submitter is correct. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the LRM as if the recommendation for future revisions has been adopted. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Make the LRM changes proposed by the submitter. -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2081 Language_Version VHDL-2002 Classification LRM Terminology, Grammar and Typographical Errors Summary The term ancestor is used where parent is meant Relevant_LRM_Sections 2.2, Note 6 on page 25. 8.1, on page 118. Related_Issues Key_Words_and_Phrases explicit ancestor, parent Authors_Name Peter Ashenden Authors_Phone_Number +61 414 709 106 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Ashenden Designs Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 24 January 2006 Date Analyzed: 02 February 2006 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: 02 February 2006 Description of Problem ---------------------- The term "ancestor" is used where the term "parent" should be used. The term "explicit ancestor" is defined in 2.2 on page 24, and refers to the signal or member of a signal that is a prefix of an attribute name. The term "parent" is defined in 2.2 on page 23, and refers to a process or subprogram that directly or indirectly calls a given subprogram. In 2.2, Note 6 on page 25, the term "ancestor" is used to refer to a subprogram declared in a protected type declaration or body; the term "parent" is meant. In 8.1, on page 118, the term "ancestor" is used to refer to a subprogram whose body is declared within a protected type body; the term "parent" is meant. In both cases, the incorrect terminology was introduced in P1076a, probably as a result of misunderstanding of terminology by the language change authors. (I'm probably culpable, at least in part!) Proposed Resolution ------------------- Replace both occurrences of the term "ancestor" with "parent". VASG-ISAC Analysis & Rationale ------------------------------ Part of the problem is the fact that the LRM definition of "parent" does not match either the intuitive understanding of this word or the graph-theoretic use of this word. From a graph-theoretic perspective the word "ancestor" would be more accurate. The LRM could formally define the word "ancestor" when applied to subprograms. However, such a definition could cause confusion with the term "explicit ancestor" which refers to signals. Therefore, the ISAC believes that we should keep the current definition of "parent" and make the changes suggested by the submitter. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the LRM as if the recommendation for future revisions were in effect. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Make the changes suggested by the submitter: Change the word "ancestor" to "parent" in a) 2.2 Note 6 on page 25, and b) 8.1 on page 118. -------------END OF IR----------------Received on Fri Feb 3 17:41:11 2006
This archive was generated by hypermail 2.1.8 : Fri Feb 03 2006 - 17:41:12 PST