IR 2092 analyzed

From: Chuck Swart <cswart_at_.....>
Date: Thu May 18 2006 - 15:44:54 PDT
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