ISAC: Proposed agenda for ISAC meeting 05 May 2005

Next ISAC Meeting: Thursday May 05 2005, 8 pm Pacific Daylight Time
             (Friday May 06 2005, 3 am GMT)

 
 telecom info (same as always)
 US 888.742.8686
 Other 303.928.2600
 Conference ID 3331797

1. Review and respond to ballots on ISAC-Approved Issues.
(Please read Peter's emails which contain comments)

2. Open ISAC issues:

2038
2043
2054
2062
2064
2065
 
3. Meet at DAC on Friday June 17


4. Status of web based IR system.

I am attaching a file with contains partial analysis of IR2065.




The paper addresses the semantic issues with expanding allowable cases for
OTHERS in array aggregates.

The current rules allow OTHERS in array aggregates if the "subtype" of
the array aggregate can be determinable from context. In general,
this means that the aggregate must be associated with a constrained
array subtype for the OTHERS to be legal. In most cases, this constrained
array subtype must also be locally static. A modest exception to the
locally static rule allows OTHERS for dynamic constraints if the aggregate
has only the OTHERS and no additional associations.

An additional rule states that if there is no OTHERS association, but
an OTHERS would be legal, the the direction, but not the bounds come
from context.

We examine the possibility of extending the use of OTHERS to more
cases.

1. There are some situations in which an OTHERS makes no sense.
In particular when an aggregate is used as a parameter to a subprogram
where the formal is unconstrained. In this case there is no reasonable
way to determine the size of the aggregate.

variable v1: bit_vector(1 to 3);
...
   if( v1 = (OTHERS => '1')) ...

2. Suppose we extended the rules to allow OTHERS for
unconstrained arrays as in the first example of CASE1 from the IR.

    procedure (b,c :
    out signed) 
    begin 
       b := (OTHERS => '0'); -- not legal because b is unconstrained 
       c :=('1',OTHERS => '0'); -- not legal because b is unconstrained 
    end; 

If we allow this we introduce a subtle incompatibility.

Consider a similar procedure:

  procedure proc1 (
    var1 : inout bit_vector) is
    begin
      var1 := (1=>'1',0=>'0');
--      var1 := (0=>'0',others => '1');
--      var1 := (1=>'1',others => '0');
    end;

Under current rules, only the first assignment is legal.
It creates an aggregate with bounds and direction 0 to 1.
If proc1 is called with a parameter whose bounds and direction
are 1 downto 0, then the net affect is a reversal of bits.
Note also, that it would be legal to call this with any
bit_vector of size 2.


label1 : process
  variable v1 : bit_vector(1 downto 0):= "10";
begin  -- process label1 
  proc1(v1);     --v1 is reversed
  b1 := (v1=('1','1'));
  wait;
end process label1 ;

If we allow the two OTHERS cases which are commented out in
proc1, then it seems reasonable that all three cases should
produce the same result, i.e. the bounds and direction should
be picked up from the formal.

3. Interplay with proposed FT changes?