This is also in the website -------------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 IR 2075 Arrays with numeric and enumeration index types are not closely related 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: Analyzed Superseded By: ------------------------ Date Submitted: 24 April 2006 Date Analyzed: 03 May 2006 Author of Analysis: Chuck Swart Revision Number: 1 Date Last Revised: 03 May 2006 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 ------------------------------ There are a number of problems with null arrays. This IR will attempt to address several of them. 1) Rules for determining null range don't always work. Consider the following example: type VECTOR1 is array ( BOOLEAN range<>) of BIT; constant C1: VECTOR1 := ""; Strictly applying the rules of section 7.3.1 we have a constant with leftmost bound of FALSE, direction TO, but no legal right bound. The most compatible way to resolve this issue is to use the stated rules for the leftmost bound if that bound has a LEFTOF value. If not, shift everything right by one, so the left bound will be BOOLEAN'RIGHTOF(BOOLEAN'LEFT) and the right bound will be BOOLEAN'LEFT. This works in all cases except issue 2 below. 2) In some esoteric cases there is no way to indicate a null range Consider the following example: type SMALL is ( VALUE1 ) ; type VECTOR2 is array ( SMALL range <>) of BIT; constant C2: VECTOR2 := ""; There is no way to set any bounds for this constant, because any null range requires two distinct values. A practical solution is to require that all enumeration types contain at least two values. 3) Null arrays are needlessly excluded from type conversions There does not appear to be any good reason for excluding null arrays in the case of type marks denoting an unconstrained array type. The Ada 1983 LRM, upon which the VHDL LRM is based, does not have such an exclusion. The Ada 1995 LRM, which is written in a different style says for array type conversions: "...For each nonnull index range, a check is made that the bounds of the range belong to the corresponding index subtype." This statement implies that null arrays (which have at least one null index range) are legal. In addition to removing the restriction on null arrays from the original text, a small additional wording change is required to implement IR 2075, which allows conversions between arrays with numeric and enumeration index types. To achieve maximum generality, in computing array bounds for a target type that is unconstrained, the direction of the result is that of the target type and the left bound of each index subtype is the left bound of the corresponding target index type. For null arrays, null index ranges in the expression would have to be mapped to null index ranges in the result. The rules of clause 7.3.1 for null literals could be applied. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Clause 3.1.1 Enumeration Types Change the rule for enumeration type definition to: enumeration_type_definition ::= ( enumeration_literal, enumeration_literal {,enumeration_literal} ) Make the same change to the Syntax Summary in Annex A This change guarantees that all enumeration types have at least two values. Clause 7.3.1 Literals Change the paragraph fragment which says: "For a null array value...otherwise the rightmost bound is the successor (as given by the 'SUCC attribute) of the leftmost bound." To "For a null array value represented by either a string or bit-string literal, the direction and leftmost bound of the array value are determined as follows:the direction and nominal leftmost bound of the array value are determined as in the non-null case. If there is a value to the left of the nominal leftmost value (given by the 'LEFTOF attribute) then the nominal leftmost value is the leftmost value and the value to its left is the rightmost value. Otherwise, the value to the right of the nominal leftmost value is the leftmost value and the nominal leftmost value is the rightmost value. Clause 7.3.5 Type conversions (Exact wording not supplied because this area will be significantly rewritten for next LRM revision.) Add wording to the effect that for null index ranges in the expression, the rules of 7.3.1 are applied to the appropriate index subtypes. -------------END OF IR----------------Received on Thu May 18 15:44:43 2006
This archive was generated by hypermail 2.1.8 : Thu May 18 2006 - 15:44:45 PDT