RE: [sv-ec] random resizing of associative array

Arturo,

If an associative array with integral indices can be 
resized and the indices become 0..N (N = size-1) what 
about the following:

module top;
  typedef enum bit[7:0] {  red= 1, teal= 2, blue= 4, 
                          aqua= 8, cyan=16, gold=32,
                          pink=64, rust=128 } color;
  int assoc[color];
  initial begin
    assert( randomize(assoc) with (assoc.size()==8;} );
    ...
  end
endmodule

Note that "assoc[color'(3)] = 20;" is a legal assignment.
So does the randomize create 8 entries with index values
0,1,2,3,4,5,6,7 ?


My opinion is that resizing of an associative array is not
defined in the current LRM. 
 - In section 13.3 where size constraints are introduced,
   they are only described for dynamic arrays.
 - The size() method is not defined for associated
   arrays. So size constraints can't be specified (per LRM).
 - The semantics of resizing associative arrays is not
   described.

Also, if randomize resizing of an associative array should be
equivalent to using a dynamic array, why even add this as an 
enhancement?

- Ray

> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] 
> Sent: Wednesday, May 17, 2006 3:56 PM
> To: Rich, Dave; Arturo Salz; Ryan, Ray; Vreugdenhil, Gordon
> Cc: sv-ec@eda.org
> Subject: RE: [sv-ec] random resizing of associative array
> 
> Dave,
> 
> I didn't imply you said that. I'm sorry if I left that impression.
> 
> The index value IS a state variable because it must be a 
> literal constant. Only the foreach construct allows 
> non-literal indices.
> 
> My point is that I did specify how the index value is set: 
> when an associative array isd resized, the indices become 
> 0..N (N = size-1).
> And, it follows from that description that arrays of non 
> integral indices cannot be resized.
> 
> 	Arturo
> 
> -----Original Message-----
> From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> Sent: Wednesday, May 17, 2006 3:13 PM
> To: Arturo Salz; Ryan, Ray; Vreugdenhil, Gordon
> Cc: sv-ec@eda.org
> Subject: RE: [sv-ec] random resizing of associative array
> 
> Arturo,
> 
> I think we are in agreement, at least agree your example 
> should be legal.
> 
> I didn't say that you couldn't use an AA in a constraint; I 
> just said the index value would be a state variable, i.e. not 
> randomized.
> 
> If you were to allow re-sizing an AA, you'd have to specify 
> how the index value is to be set.
> 
> Dave
> 
> 
> > -----Original Message-----
> > From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> > Sent: Wednesday, May 17, 2006 3:04 PM
> > To: Rich, Dave; Ryan, Ray; Vreugdenhil, Gordon; Arturo Salz
> > Cc: sv-ec@eda.org
> > Subject: RE: [sv-ec] random resizing of associative array
> > 
> > Dave,
> > 
> > Disallowing associative arrays from participating in constraints as 
> > random variables is too restrictive. If users do not resize the 
> > associative array there is no ambiguity. Also, the LRM 
> already states 
> > that index expressions must be literal constants, so it's 
> not possible 
> > to randomize the indices. Consider the following:
> > 
> > 	rand byte aa[int];
> > 	rand a, b;
> > 
> > 	constraint x { foreach( aa, j ) { aa[j] inside { a, b }; }
> > 
> > That is a perfectly good constraint.
> > 
> > I believe the only erratum needed is to specify what 
> happens when the 
> > size of the associative array is constrained. My proposal is 
> > straightforward and I believe allows most useful situations without 
> > being unduly restrictive.
> > 
> > 	Arturo
> > 
> > -----Original Message-----
> > From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> > Sent: Wednesday, May 17, 2006 2:35 PM
> > To: Ryan, Ray; Vreugdenhil, Gordon; Arturo Salz
> > Cc: sv-ec@eda.org
> > Subject: RE: [sv-ec] random resizing of associative array
> > 
> > I don't think this is the desired behavior, nor does the LRM even 
> > remotely suggest this.
> > 
> > I would propose that we add an erratum explicitly saying that
> > randomize() shall not re-size an associative array and 
> shall consider 
> > the size and keys as state variables.
> > 
> > Dave
> > 
> > 
> 
>