ISAC: IR 2065 OTHERS in aggregates too restrictive Is ISAC-APPROVED

The attached IR was approved at the recent ISAC meeting.
Please give it a final review.
If I don't hear any comments within a couple of days I will
mark it ISAC-Approved and forward it to the VASG.

Chuck Swart


VHDL Issue Number:        2065

Language_Version          VHDL-2002
Classification            Language Modeling Enhancement or Deficiency
Summary                   Aggregates
Relevant_LRM_Sections     7.3.2.2 Array aggregates
Related_Issues            
Key_Words_and_Phrases     aggregate, generic, locally static, unconstrained
Authors_Name              Yannick Grugni
Authors_Phone_Number      +(32)16.390.742
Authors_Fax_Number        
Authors_Email_Address     yannick.grugni@philips.com
Authors_Affiliation       
Authors_Address1          Philips Design Competence Center Leuven,  
Authors_Address2          Interleuvenlaan 74-82,
Authors_Address3          3001 Leuven, Belgium

Current Status:           Analyzed

Superseded By:

------------------------
Date Submitted:           8 March 2005
Date Analyzed:            29 July 2005
Author of Analysis:       Chuck Swart
Revision Number:          1
Date Last Revised:        08 August 2005

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

Please find below 3 examples of aggregates that are not allowed in
vhdl vhdl 93-2002. We would like to have it support in the next vhdl
standard. Most of the compilers (like modelsim) already accept those
kind of code if you enable the option to relax the vhdl standard. So I
don't thing that there is any good technical reason to not allow those
kind of codes. CASE1 and CASE2 are really annoying limitations as the
tendencies of today is write more and more generic codes or general
functions/procedures. (note: minor typos fixed)
    
    
    CASE 1) aggregates & unconstrained signals or variables
    ------------------------------------------
    procedure (b,c :
    out signed) 
    begin 
       b := (OTHERS => '0'); -- not legal because b is unconstrained 
       c :=('1',OTHERS => '0'); -- not legal because c is unconstrained 
    end; 
    
    
    -------------------------------------- --------
    CASE 2) aggregates and signals with generic size
    ----------------------------------------------
    
    generic n : integer := 3; 
    ... 
    signal a : unsigned(n downto 0) 
    constant b: unsigned(n downto 0):=('1',OTHERS=>'0');
    ... 
    a<= ('1',OTHERS => '0');
    a<= (a'high=>'1',OTHERS => '0');
    a<= (n,OTHERS => '0');  
    a<= (3=>'1',OTHERS => '0');
    -- none of  those lines are legal because n is not
    -- locally static.
    
    
    -------------------------------------- 
    CASE 3) 
    -------------------------------------- 
    signal pos : integer := 3; 
    signal a : unsigned(7 downto 0) 
    ... 
    a<= (pos => '1',OTHERS => '0'); 
    -------------------------------------- 
    
    

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



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

This issue is clearly an enhancement request and will be forwarded to
the Modeling and Productivity working group.

For simplicity, we will limit the discussion to array aggregates.

There are two sets of restrictions which apply to expressions
containing an OTHERS choice:

1. Rules which determine whether or not an OTHERS choice is legal at
all, and

2. Rules which determine whether or not an OTHERS choice can be used
in conjunction with additional choices.

Currently, restriction 1 states basically that there must be an applicable
constrained array subtype for such an aggregate to be legal.

Restriction 2 states that an OTHERS choice can be used in conjunction with
additional choices only if the applicable index constraint is locally static.

RESTRICTION 2

Relaxing Restriction 2 involves moving current checks for correctness
(all cases covered once and only once) out of the analyzer.

For the submitter's CASE 2) these checks would be elaboration time
or simulation time checks.

For the submitter's CASE 3) these would be simulation time checks.

These checks would be more complicated and might have negative
performance consequences, but there are no fundamental technical
problems in relaxing Restriction 2.

RESTRICTION 1

There are at least two technical issues with relaxing restriction 1.

First, there are some cases in which there is no meaningful interpretation
of an OTHERS choice, because there is no reasonable way to determine
the size of the aggregate. A clear example of this problem is the use
of an aggregate as an actual to a function or operator which takes an
unconstrained array as an argument.

For example:

FUNCTION count_ones( p1: bit_vector) RETURN integer;
...
    count := count_ones(p1 => (OTHERS => '1')); --How big is p1?

The second problem is a subtle backward incompatibility. We could try
to allow the submitter's CASE 1) by using the bounds of the actual.
If we made no other changes to the rules concerning OTHERS we would
have a problem with the following case (modified from the submitter's
CASE 1):

procedure (b : out bit_vector)
begin
   b := ( 0 => '1', 1 => '0');
end;

Under current rules, since an OTHERS choice is not legal for b, the
aggregate gets its direction from the base type.  So this aggregate is
equivalent to "10".

However, if we made OTHERS legal here, then the aggregate would get
its direction from the actual. If the actual had a DOWNTO direction,
the results under the new rules would be different from current
results. The aggregate value would be equivalent to "01".

This subtle change in the execution of the design could be very hard
for the designer to find, although simulators could probably detect
these potentially dangerous situations and issue appropriate warnings.

In addition, if the actual had different bounds from those of the
aggregate, then the aggregate would be illegal under the proposed
extension, while under current rules only the number of elements in
the aggregate would have to match the size of b.


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

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Forwarded to Modeling and Productivity Group


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