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 11:04:12 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 08 2007 - 11:04:37 PST