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



> 
> If this is the desired behavior, a dynamic array should
> be used.
> 
> To truly randomize an associative array I like Arturo's
> method of randomizing two dynamic arrays (one for the
> indices, the other for the value) - and then combining
> them to form the associative array. With this approach,
> constraints can be applied to the indices as well as
> the values.
> 
> If re-sizing of associative array is allowed, I believe
> many Users would expect behavior other than the dynamic
> array model. I would also expect questions (enhancement
> requests) about how to constrain the indices. I think
> it would be a better to simply not allow resizing of
> associative arrays - and recommend the two array method instead.
> 
> 
> Regarding the discussion about re-sizing an dynamic array
> of class handles. Issue #889 proposes that if the element
> type is a class handle, re-sizing is not supported. In
> this case, the value of array.size() is treated as state value.
> 
> - Ray
> 
> 
> > -----Original Message-----
> > From: Vreugdenhil, Gordon
> > Sent: Wednesday, May 17, 2006 1:35 PM
> > To: Arturo Salz
> > Cc: Ryan, Ray; sv-ec@eda.org
> > Subject: Re: [sv-ec] random resizing of associative array
> >
> > That mostly answers my questions but leaves one important
> > issue open.  If I have indices (1, 3, 5) referring to
> > non-null class objects and specify a size constraint of 3, is
> > that an error?
> > I am not "resizing" but would be "reorganizing" the indices.
> > From a user perspective, this doesn't require class
> > construction so if we define it to be illegal (equivalent to
> > requiring class construction) then this needs to be made
> > explicit.  If this is legal then I would wonder about the
> > rules for determining the reinsertion order.
> > At the same time the LRM should clarify whether it is legal
> > if the indices were already (0, 1, 2).
> >
> > Gord.
> >
> >
> > Arturo Salz wrote:
> >
> > > Gord,
> > >
> > > Your example should end up with an array of size 3, whose
> > indices are
> > > (0, 1, 2), and the contents are randomized according to any
> > constraint.
> > > That's why I wrote that constraining the size of an
> > associative array
> > > can be treated in the same way as a dynamic array.
> > >
> > > If the element type is a class type then the array cannot
> > grow in size
> > > because the solver doesn't know how to create the
> > additional objects.
> > > Object creation as part of the constraint solution is a whole
> > > different discussion, which would lead to several enhancements.
> > >
> > > 	Arturo
> >
> > --
> > --------------------------------------------------------------------
> > Gordon Vreugdenhil                                503-685-0808
> > Model Technology (Mentor Graphics)                gordonv@model.com
> >