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=bug
>>
>> 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.