RE: [sv-ec] New proposal for 2113: Inconsistency in constraining assoc array size

It has been discussed and agreed that it was not the intent that only
one dimension can be dynamic. Mantis 1447 is addressing that, along with
other dynamic array issues.

Shalom 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Brad Pierce
> Sent: Thursday, November 08, 2007 9:22 PM
> To: sv-ec@server.eda.org
> Subject: RE: [sv-ec] New proposal for 2113: Inconsistency in 
> constraining assoc array size
> 
> Bill,
> 
> Where does the LRM say that you can't declare a dynamic array 
> of dynamic arrays?
> 
>      integer mem_mem [] [] ;
> 
> -- Brad
> 
>   
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of William Paulsen
> Sent: Thursday, November 08, 2007 10:52 AM
> To: Michael Burns
> Cc: Ryan, Ray; SV_EC List
> Subject: RE: [sv-ec] New proposal for 2113: Inconsistency in 
> constraining assoc array size
> 
> 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.
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.