-------------BEGINNING OF IR----------------

VHDL Issue Number:        2097

Language_Version          VHDL-2002
Classification            Language Definition Problem
Summary                   Operations with Array aggregates
Relevant_LRM_Sections
Related_Issues
Key_Words_and_Phrases
Authors_Name              Jim Lewis
Authors_Phone_Number      503-590-4787
Authors_Fax_Number
Authors_Email_Address     jim@synthworks.com
Authors_Affiliation       SynthWorks
Authors_Address1
Authors_Address2
Authors_Address3

Current Status:           VASG-Approved

Superseded By:

------------------------
Date Submitted:           13 June 2006
Date Analyzed:            22 September 2006   
Author of Analysis:       Lance Thompson
Revision Number:          3
Date Last Revised:        23 May 2007

Description of Problem
----------------------
The following code is a desirable hardware coding
style, however, currently I have an issue with it 
in that some synthesis implementations accept it and 
others don't.  

    signal ASel, BSel : std_logic;
    signal Y, A, B : std_logic_vector(7 downto 0) ;

    Y <=
        (A and (A'range => ASel)) or
        (B and (B'range => BSel)) ;

It would be helpful to know if one or the other 
is correct.

Proposed Resolution
-------------------
TBD

VASG-ISAC Analysis & Rationale
------------------------------

Given the following object declarations,
    signal ASel, BSel : std_logic;
    signal Y, A, B : std_logic_vector(7 downto 0) ;
 
The submitter asks if this statement is legal
    Y <=
        (A and (A'range => ASel)) or
        (B and (B'range => BSel)) ;

Taking the statement in sections, y <= ( expression ) or ( expression)
is certainly ok, so the question must revolve around the expression "A
and ( A’range => ASel )" and its counterpart for B.  The form "name
and aggregate" is a permitted form of the call to the AND function.

The reviewer supposes that the question is focused on the aggregate
portion of the expression.

One of the permissible forms of aggregate described in 7.3.2 resolves
to 

( discrete_range => expression ) 

ASel is a name which is a valid expression fits the criteria for the
right hand portion of the aggregate.  For the left hand portion, we
look to the description of the predefined attribute a'range.  A’range
is defined to return the range of the object A.  The range is of a
form that satisfies the definition of a discrete range.

7.3.2 also states that the type of the aggregate must be solely
determinable from its context.  If overload resolution has determined
that

function "and"( l, r : std_ulogic_vector ) return std_ulogic_vector; 

is the only applicable function, then the type of the aggregate is
determined by the type required by that AND function.

Clause 7.3.2.2 goes on to describe how the bounds and direction are
determined.  The direction is "to" because the index subtype of the
base type (std_ulogic_vector) of the aggregate is natural and
natural’s direction is to.  Note that the direction is not derived
from the direction specified in the discrete range of the aggregate.
The left and right bounds are 0 and 7 respectively, the smallest and
largest numbers in the discrete range.

So, the form of the expression appears reasonable.

But another issue may be whether or not the correct AND function can
be determined.

10.5 rule a specifies that rules requiring names or expressions to have
   a required type are considered.  Starting with the statement, the
   assignment to y requires that the result of the expression be a
   std_ulogic_vector.  There is only 1 OR function that satisfies that
   rule assuming that ieee.std_logic_1164 is the only package in play.
   That OR function requires that it’s left and right expressions be
   std_ulogic_vector’s thus requiring the single and function:

function "and"( l, r : std_ulogic_vector ) return std_ulogic_vector;

The right expression of the and function must be a std_ulogic_vector,
so that establishes the type required by the aggregate expression used
in that position.

So, it would seem that all the language requirements have been met and
the statement is quite legal.

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No changes needed.

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
No changes needed.


-------------END OF IR----------------