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.