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