RE: [sv-ec] New proposal for 2113: Inconsistency in constraining assoc array size

From: Ryan, Ray <Ray_Ryan_at_.....>
Date: Thu Nov 08 2007 - 13:20:39 PST
 Bill,

This should probably be a separate Mantis item. This issue is
independent of whether the size of a queue can be constrained.

I'm need to think about how to clarify an iterative size constraint.

- Ray



> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of William Paulsen
> Sent: Thursday, November 08, 2007 11:56 AM
> To: Ryan, Ray; michael.burns@freescale.com
> Cc: SV_EC List
> Subject: RE: [sv-ec] New proposal for 2113: Inconsistency in 
> constraining assoc array size
> 
> Ray,
> 
> That's a good example.  But do you have a suggestion for new 
> wording in the proposed resolution?
> 
> Bill
> 
>  
> 
> -----Original Message-----
> From: Ryan, Ray [mailto:Ray_Ryan@mentor.com]
> Sent: Thursday, November 08, 2007 2:36 PM
> To: michael.burns@freescale.com; William Paulsen
> Cc: SV_EC List
> Subject: RE: [sv-ec] New proposal for 2113: Inconsistency in 
> constraining assoc array size
> 
> Yes, it is legal (and useful) to declare a dynamic array of 
> dynamic arrays and then randomize the array with a size 
> constraint on the outer array and an iterative constraint on 
> the size of each dynamic element.
> 
> The following should work:
> 
> module top;
> 
> typedef int dyn[];      // dynamic array of "int"
> dyn d2[];               // dynamic array of dynamic array of "int"
> 
> initial
> begin
>     assert(
>       randomize(d2) with {
>         d2.size == 3;
>         foreach(d2[i,j]) {
>             d2[i].size == i + 1;
>             d2[i][j] == (i + 1) * (j + 1);
>         }
>       }
>     );
> 
>     for(int i = 0; i < d2.size; i++)
>     begin
>         for(int j = 0; j < d2[i].size; j++)
>         begin
>             $display("d2[%0d][%0d]=%0d", i, j, d2[i][j]);
>         end
>     end
> end
> 
> endmodule
> 
> > -----Original Message-----
> > From: Michael Burns [mailto:michael.burns@freescale.com]
> > Sent: Thursday, November 08, 2007 11:04 AM
> > To: William Paulsen
> > Cc: Ryan, Ray; SV_EC List
> > Subject: Re: [sv-ec] New proposal for 2113: Inconsistency in 
> > constraining assoc array size
> > 
> > 
> > Ah - I think this is just a syntax issue. Let's try it like this:
> > 
> >    typedef int[] IntAry;
> >    rand IntAry A[];
> >    rand IntAry B[];
> >    << the rest is the same >>
> > 
> > --Mike
> > 
> > Michael Burns wrote:
> > > 
> > > Bill,
> > > 
> > > Can you point me to the reference? I can't find it. From my 
> > > conversations with other members, I sure thought it was the
> > intention
> > > of the committee to allow arbitrary unpacked dimensions of
> > arbitrary type.
> > > 
> > > --Mike
> > > 
> > > William Paulsen wrote:
> > >> Mike,
> > >>
> > >> But 7.4 says only one dimension in a dynamic array can be
> > dynamic -
> > >> you can't have [][]
> > >>
> > >> Bill
> > >>  
> > >>
> > >> -----Original Message-----
> > >> From: Michael Burns [mailto:michael.burns@freescale.com] Sent: 
> > >> Thursday, November 08, 2007 1:01 PM
> > >> To: William Paulsen
> > >> Cc: Ryan, Ray; SV_EC List
> > >> Subject: Re: [sv-ec] New proposal for 2113: Inconsistency in 
> > >> constraining assoc array size
> > >>
> > >> Hi Bill,
> > >>
> > >> I see your problem; you can tell that both arrays should
> > end up with
> > >> size 10, but you have to look inside the foreach's to
> > figure it out.
> > >> Better to just make that kind of thing illegal, right? 
> > Well, I'm not
> > >> sure - it would help with your example, but I think there
> > are other
> > >> issues.
> > >>
> > >> For instance, what about randomizing multidimensional arrays?
> > >>
> > >>    rand int A[][]; // 2-D dynamic array
> > >>    constraint c1 { A.size inside {[1:10]}; }
> > >>    constraint c2 { foreach (A[k]) A[k].size < 5; }
> > >>
> > >> If we enforce your restriction, we are not able to
> > constrain the size
> > >> of subarrays since these sizes will be treated as state 
> variables. 
> > >> Here's a nastier
> > >> one:
> > >>
> > >>    rand int A[][];
> > >>    rand int B[][];
> > >>    constraint c1 { A.size inside {[1:10]}; }
> > >>    constraint c2 { B.size == A.size; }
> > >>    constraint c3 { foreach (A[k]) A[k].size + B[k].size < 5; }
> > >>
> > >> The last constraint really expects to constrain not only
> > the size of
> > >> A's subarrays but B's as well, meaning we can't toss
> > another special
> > >> case rule on the pile stating that you are allowed to
> > constrain the
> > >> size of subarrays with a foreach.
> > >>
> > >> What we really want to do is to disallow those dependency loops, 
> > >> where we need to look in one array's foreach to find the size of 
> > >> another array, and look in the other array's foreach to
> > find the size
> > >> of the first. That's kind of a yucky rule to add though -
> > I fear it
> > >> would be really hard for people to understand, and 
> wouldn't really 
> > >> matter in any real usage anyways. Maybe the rule should just be 
> > >> something really general and nonspecific, like the size of
> > an array must be "resolvable"
> > >> without looking inside any of the array's foreach loops.
> > >>
> > >> --Mike
> > >>
> > >> William Paulsen wrote:
> > >>> Mike,
> > >>>
> > >>> I think that 17.5.7 is not clear about what the
> > randomizer should do
> > >>> with A.size and B.size in this example:
> > >>>
> > >>>     rand int A[];
> > >>>     rand int B[];
> > >>>     constraint c1 { A.size inside { [1:10] }; }
> > >>>     constraint c2 { foreach ( A[ k ] ) B.size == A.size; }
> > >>>     constraint c3 { foreach ( B[ k ] ) A.size > 9; }
> > >>>     
> > >>> What are the generated values of A.size and B.size?
> > >>>
> > >>>
> > >>> My suggestion is to change the third sentence in the new
> > paragraph
> > >>> of
> > >>> 17.5.7 from:
> > >>>
> > >>> As a result of this implicit ordering between size
> > constraints and
> > >>> iterative constraints, the size method shall be treated
> > as a state
> > >>> variable within the foreach block of the corresponding array.
> > >>>
> > >>>
> > >>> To:
> > >>>
> > >>> All size method calls shall be treated as state variables
> > within all
> > >>> foreach blocks.
> > >>>
> > >>>
> > >>>
> > >>> With this change the randomizer will fail with the 
> example above, 
> > >>> but this expected behavior is clear.
> > >>>
> > >>>
> > >>> Bill
> > >>>
> > >>>  
> > >>>
> > >>> -----Original Message-----
> > >>> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On
> > Behalf Of
> > >>> Ryan, Ray
> > >>> Sent: Wednesday, November 07, 2007 9:50 PM
> > >>> To: michael.burns@freescale.com; SV_EC List
> > >>> Subject: RE: [sv-ec] New proposal for 2113: Inconsistency in 
> > >>> constraining assoc array size
> > >>>
> > >>> Mike,
> > >>>
> > >>> This now looks good.
> > >>>
> > >>> Regards,
> > >>> Ray
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: owner-sv-ec@server.eda.org
> > >>>> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Michael Burns
> > >>>> Sent: Tuesday, October 30, 2007 1:12 PM
> > >>>> To: SV_EC List
> > >>>> Subject: [sv-ec] New proposal for 2113: Inconsistency in 
> > >>>> constraining
> > >>
> > >>>> assoc array size
> > >>>>
> > >>>>
> > >>>> Hi folks,
> > >>>>
> > >>>> I've uploaded a new proposal for 2113 - links and notes
> > are below. 
> > >>>> Please review and provide feedback.
> > >>>>
> > >>>> Thanks,
> > >>>> Mike
> > >>>>
> > >>>> http://www.eda-stds.org/mantis/view.php?id=2113
> > >>>>
> > >>>> 
> > http://www.eda-stds.org/mantis/file_download.php?file_id=2680&type=
> > >>>> bu
> > >>>> g
> > >>>>
> > >>>> Added new proposal version 2113-D4-20071029.pdf. Changed
> > >>>> 17.5.7 to only remove assoc. arrays and add queues 
> (there is no 
> > >>>> longer any description there of resizing queues). 
> Added edits to
> > >>>> 17.4 to add
> > >>
> > >>>> queues and describe how they are resized.
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> This message has been scanned for viruses and dangerous
> > content by
> > >>>> MailScanner, and is believed to be clean.
> > >>>>
> > >>>>
> > >>> --
> > >>> This message has been scanned for viruses and dangerous
> > content by
> > >>> MailScanner, and is believed to be clean.
> > >>>
> > >>>
> > >>
> > > 
> > 
> > 
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Nov 8 13:21:00 2007

This archive was generated by hypermail 2.1.8 : Thu Nov 08 2007 - 13:21:08 PST