ISAC: proposed agenda for ISADC meeting July 21 2005

Next meeting:  Thurdsay July 21 2005, 8 pm Pacific Daylight Time
(Friday July 22 2005, 3 am gmt)

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

1. Review Status of Web Based IR system.

2. New isac issue:

2069    Submitted  Visibility of generics in block configurations

3. Open ISAC issues

2043    Analyzed        Deepak         Numeric VALUE attribute
                                                          parameter 
can't have sign
2054    Submitted       Larry           Individ. assoc. rules for array
                                                         formal are not 
valid
2062    Analyzed        Ajay            Range staticness
2064    Analyzed        Larry           Type conversion of unconstrained  
                                                         output in a 
port map
2065    Submitted       Chuck         OTHERS in aggregates too restrictive
                                                        Please review my 
attached analysis of some OTHERS issues.

4. Process for analyzing old IRs.

5. Relationship between Accellera and ISAC??




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?