Re: Analysis of IR 2092

I approve.

-ajay

----- Original Message ----- 
From: "Chuck Swart" <cswart@model.com>
To: <isac@eda.org>
Sent: Friday, May 26, 2006 11:40 AM
Subject: ISAC: Analysis of IR 2092


> Please review this ASAP and vote yes or no
>
> We are simultaneously submitting this to both the ISAC and
> the VASG to try to make the Accellera LRM deadline.
>
> 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            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.
>
> The least intrusive solution is to make it an error to declare
> a null string if the base type of the index subtype of the array type
> does not have 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 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.
>
>    For a null array value it is an error if the base type
>    of the index subtype of the array type does not have at least
>    two elements."
>
> 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----------------
>