Relaxed OTHERS Rules for Aggregates

Proposal Information

• Who Updates: RyanHinton
• Date Proposed: 2013-10-10
• Date Last Updated: 201-10-10
• Priority:
• Complexity:
• Focus: General Language

Summary

Relax the rules for an OTHERS clause in array aggregates. This proposal forwards the ISAC request IR2065.

Requirements

Relax the rules for an OTHERS clause in array aggregates. Several use cases are below.

Related Issues: None = General

Competing Issues: None at this time

Use cases

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: Dynamic aggregates

    signal pos : integer := 3; 
    signal a : unsigned(7 downto 0) 
    ... 
    a<= (pos => '1',OTHERS => '0'); 

Language impact

1. How hard is this to implement in the compiler?
   • The Mentor compiler already accepts aggregates of the form described in cases 2 and 3; the compiler will issue a warning when exposed to a non-conforming aggregate.
   • In the opinion of CliffordWalinsky it would probably not be too difficult to implement case 1. Of course, case 1 must be disallowed when an aggregate with an others choice is used to initialize an unconstrained constant.
2. Are there performance impacts for simulation?
   • Performance would be impacted if multiple named associations with non-static choices are included in the proposal. Currently, this possibility is explicitly excluded by the statement of Section 9.3.3.3: "A named association of an array aggregate is allowed to have a choice that is not locally static, or likewise a choice that is a null range, only if the aggregate includes a single element association and this element association has a single choice". Performance is adversely affected with multiple non-static associations because of the need to check for uniqueness and completeness at simulation-time.

Supporters

-- RyanHinton - 2013-10-1

-- PatrickLehmann - 2016-12-06

Non-Supporters

-- CliffordWalinsky - 2013-10-10

• Currently, this proposal is just a series of examples, and lacks precise wording. In particular, there needs to be a requirement that there can only be at most one non-static association (exclusive of any others choice). Also, an aggregate with a non-static others choice cannot be used to initialize an unconstrained constant. LRM section 9.3.3.3 "Array aggregates" will need extensive rewording.

-- TristanGingold - 2016-05-15

• I agree with the previous comment: a more precise wording is required. In particular, what are the bounds of the aggregates, how are they determined ?
• Aggregates are one of the most complex feature of VHDL. Such a change would make it even more complex. So I am reserved.

Add your signature here to indicate support for this proposal.