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

VHDL Issue Number:        2072  

Language_Version          VHDL-93
Classification            Language Modeling Enhancement or Deficiency
Summary                   Allow static operations on "ranges"
Relevant_LRM_Sections     <unknown>
Related_Issues            <unknown>
Key_Words_and_Phrases     range, operator
Authors_Name              Stewart Cobb
Authors_Phone_Number      650-644-1418
Authors_Fax_Number        
Authors_Email_Address     stu@novariant.com
Authors_Affiliation       Novariant Corporation
Authors_Address1          1350 Willow Road
Authors_Address2          Menlo Park, CA
Authors_Address3          94025

Current Status:           Forwarded

Superseded By:

------------------------
Date Submitted:           18 August 2005
Date Analyzed:            02 December 2005
Author of Analysis:       Chuck Swart
Revision Number:          1
Date Last Revised:        02 December 2005

Description of Problem
----------------------

This is a change proposal for the syntax of the VHDL language
regarding "ranges" of array types.  It would have the effect of
allowing simple arithmetic to be used in array range references, so
that the following example would work as intended:
    
    --> Types and signals for example:
    
    type     WORD is array (31 downto 0) of std_logic;
    type HALFWORD is array (15 downto 0) of std_logic;
    
    signal my_word    :
    WORD;
    signal my_half_lo : HALFWORD;
    signal my_half_hi : HALFWORD;
    
    --> Proposed change would allow:
    
    my_half_lo <:    my_word(my_half_lo'range);
    my_half_hi <= my_word(my_half_hi'range + my_half_lo'length);
    
    --> Currently legal code is much less clear:
    
    my_half_lo <= my_word(my_half_lo'range);
    
    my_half_hi <= my_word(
      (my_half_hi'high + my_half_lo'length) downto
      (my_half_hi'low  + my_half_lo'length) );
    
    --> It is possible to write a "currently legal" example
    --> that does not require knowledge of the range
    --> directions, but that's even less clear:
    
    my_half_lo <= my_word(my_half_lo'range);
    
    if my_half_hi'ascending then 
      my_half_hi <= my_word(
        (my_half_hi'low  + my_half_lo'length) to
        (my_half_hi'high + my_half_lo'length) );
    else
      my_half_hi <= my_word(
        (my_half_hi'high + my_half_lo'length) downto
        (my_half_hi'low  + my_half_lo'length) );
    end if;
    
    --> This change should also allow expressions like this:
    
    subtype SIGNED_BYTE
      is integer range -128 to 127;
    subtype UNSIGNED_BYTE
      is integer range (SIGNED_BYTE'range - SIGNED_BYTE'low);
    
    --> Expressions like the second one are useful inside
    --> library functions which cannot assume the size, range,
    --> or direction of their arguments.
    

Proposed Resolution
-------------------

If the endpoints of a range are a certain type, then operators which
can be applied to that type should be legal when applied to the
"range", and should be interpreted as applying to both endpoints of
the range simultaneously.
    

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

Some of the problems that the author mentions can be solved by using
aliases to normalize ranges and directions of array objects.However,
this proposal goes farther and permits some form of arithmetic on
ranges.

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

No change.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

Consider this enhancement request.


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