ISAC: Two new IRs

Please review for the next meeting.

Chuck Swart


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

VHDL Issue Number:        2071

Language_Version          VHDL-2002
Classification            Language Modeling Enhancement or Deficiency
Summary                   Indexed name in case expression
Relevant_LRM_Sections     LRM 8.8 Case statement
Related_Issues            
Key_Words_and_Phrases     case, index, staticness
Authors_Name              Gingold
Authors_Phone_Number      0
Authors_Fax_Number        
Authors_Email_Address     tgingold@free.fr
Authors_Affiliation       
Authors_Address1          
Authors_Address2          
Authors_Address3          

Current Status:           Submitted

Superseded By:

------------------------
Date Submitted:           16 August 2005
Date Analyzed:
Author of Analysis:
Revision Number:          0
Date Last Revised:

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

If the expression is a one dimensional array of character type and
the expression is an indexed name, the indexes must be locally static
expressions.
    
As far as I can see, there is no need to require the expression to be
static.  Some users want to use non-static expressions or globally
static expressions.

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

Remove
    
    "and whose indexing expressions are locally static expressions"

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

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

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


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

-------------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:           Submitted

Superseded By:

------------------------
Date Submitted:           18 August 2005
Date Analyzed:
Author of Analysis:
Revision Number:          0
Date Last Revised:

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
------------------------------
TBD

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

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


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