(r3) RelaxedOthersAggregate < P1076/Ballots

P1076/Ballots Web>Vhdl2019CollectedRequirements>RelaxedOthersAggregate (revision 3) (raw view)~~EditAttach~~
---+ Relaxed OTHERS Rules for Aggregates

%TOC%

---++ Proposal Information
   * Who Updates: Main.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 [[http://www.eda.org/isac/IRs-VHDL-2002/IR2065.txt][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
<verbatim>
    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; </verbatim>

---+++ CASE 2: Aggregates and signals with generic size
<verbatim>
    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.</verbatim>

---+++ CASE 3: Dynamic aggregates
<verbatim>
    signal pos : integer := 3; 
    signal a : unsigned(7 downto 0) 
    ... 
    a<= (pos => '1',OTHERS => '0'); </verbatim>

---++ 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.
   1 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

-- Main.RyanHinton - 2013-10-1
---++ Non-Supporters

-- Main.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 <strong>others </strong>choice). Also, an aggregate with a non-static <strong>others </strong>choice cannot be used to initialize an unconstrained constant. LRM section 9.3.3.3 "Array aggregates" will need extensive rewording.

-- Main.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._
Topic revision: r1 - 2020-02-17 - 15:34:57 - TWikiGuest
P1076/Ballots