These have also been copied into the database. Chuck Swart -------------BEGINNING OF IR---------------- VHDL Issue Number: 2092 Language_Version VHDL-2002 Classification Language Definition Problem Summary type conversions don't allow for null arrays Relevant_LRM_Sections 7.3.5 Type conversions Related_Issues Key_Words_and_Phrases type conversion, null array 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: Submitted Superseded By: ------------------------ Date Submitted: 24 April 2006 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem ---------------------- The rules for type conversions for array types include: In an explicit type conversion where the type mark denotes an array type, the following rules apply: if the type mark denotes an unconstrained array type and if the operand is not a null array, then, for each index position, the bounds of the result are obtained by converting the bounds of the operand to the corresponding index type of the target type. If the type mark denotes a constrained array subtype, then the bounds of the result are those imposed by the type mark. In either case, the value of each element of the result is that of the matching element of the operand (see 7.2.2). This misses the case of the type mark denoting a unconstrained array type and the operand being a null array. For this case, there is no definition of the bounds of the result. Proposed Resolution ------------------- It's not clear why a null array is excluded in the case of the type mark denoting an unconstrained array. If there is no good reason for this, then the exclusion can be dropped, thus subsuming the missing case. If there is good reason, then a separate rule covering the missing case needs to be devised, taking into account the reason for the exclusion. VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2093 Language_Version VHDL-2002 Classification Language Definition Problem Summary static type conversions and qualified expressions Relevant_LRM_Sections 7.4 Static expressions, 7.3.5 Type conversions, 7.3.4 Qualified expressions Related_Issues Key_Words_and_Phrases static expression, type conversion, qualified expression 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: Submitted Superseded By: ------------------------ Date Submitted: 24 April 2006 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem ---------------------- The conditions for a type conversion to be locally static or globally static may not be sufficient. In 7.4.1, a type conversion is a locally static primary if its operand is a locally static expression. Similarly, in 7.4.2, a type conversion is a globally static primary if its operand is a globally static expression. The rules for type conversions in 7.3.5 state that if the type mark denotes a constrained array type, the bounds of the result are those of the type mark. The result of such a type conversion can only be locally static (respectively, globally static) if the subtype denoted by the type mark has locally static (respectively, globally static) index ranges. If, for example, the bounds are determined by generics, the subtype is only globally static, and the bounds of the result of the type conversion cannot be determined at analysis time, even if the expression in the type conversion is locally static. Similarly, if the bounds are determined by parameters, the subtype is not even globally static, and the bounds of the result of the type conversion cannot be determined at elaboration time, even if the expression in the type conversion is globally static. Also, if the type mark denotes an unconstrained array type, there is a check that the converted array bounds belong to the index subtype of the array type. To ensure that that subtype check succeeds for a locally static (respectively, globally static) expression, the index subtype must be locally static (respectively, globally static). Further, for both unconstrained and constrained types, there is a check that any constraint on the element subtype is the same for both the operand and the target type. Again, to ensure that that subtype check succeeds for a locally static (respectively, globally static) expression, the element subtype must be locally static (respectively, globally static). A similar problem will exist in VHDL-2006 for qualified expressions when we change them to do a subtype conversion rather than a subtype check. (See LCS-2006-114, FT-26.) Proposed Resolution ------------------- Change the rule for a type conversion being locally static to require that the type mark denote a locally static subtype. Change the rule for a type conversion being globally static to require that the type mark denote a globally static subtype. Suggest to the Accellera LRM-SC that similar changes be made to the rules for qualified expressions being locally and globally static. VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR----------------Received on Mon Apr 24 10:29:57 2006
This archive was generated by hypermail 2.1.8 : Mon Apr 24 2006 - 10:29:59 PDT