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.Received on Thu Nov 8 12:07:50 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 08 2007 - 12:08:06 PST