[sv-bc] RE: [sv-ec] 2380: a proposal requiring element equivalence

I think you are correct, but the example goes back to SV 3.1, where equivalence was not required.
The error then began in 1800-2005, which changed the requirement to equivalence.
So changing "int" to "integer" and "signed" to "wire" would fix it, I think.

Actually, I think the whole paragraph about assignment array wires to variables and vice-versa is not needed.

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
> Sent: Tuesday, June 09, 2009 1:36 AM
> To: sv-ec@eda.org; sv-bc@eda.org
> Subject: [sv-bc] RE: [sv-ec] 2380: a proposal requiring 
> element equivalence
> 
> I don't understand why the following are said to be 
> assignment-compatible under the version 2 rules
> 
>       int A[10:1];
>       wire [31:0] W [9:0];
> 
> even though their elements are not of equivalent types.
> 
> -- Brad
> 
> 
> 
> ________________________________________
> From: owner-sv-ec@eda.org [owner-sv-ec@eda.org] On Behalf Of 
> jonathan.bromley@doulos.com [jonathan.bromley@doulos.com]
> Sent: Monday, June 08, 2009 7:39 AM
> To: sv-ec@eda.org; sv-bc@eda.org
> Subject: [sv-ec] 2380: a proposal requiring element equivalence
> 
> Last week's discussions were somewhat inconclusive
> but it seems clear we should preserve the
> requirement that array elements be type-equivalent
> for the arrays to be assignment compatible.
> I went through the relevant text as carefully
> as I could, and rewrote the proposal to insist
> on type equivalence; it's now attached as an
> alternative version.  PLEASE NOTE there are
> now TWO QUITE DIFFERENT proposals attached to
> 2380:  "v1" relaxing the rules to allow
> assignment compatible elements, "v2" affirming
> the need for type-equivalent elements.
> 
> Good features of the new (v2) proposal:
> - No problem with back-compatibility of bitstream
>   casts; that all stays the same as 1800-2005.
> - BC's wish for stricter type checking on array
>   copy operations appears to be satisfied.
> - The loophole provided by unpacked array
>   concatenation is still there, allowing
>   copy of 1-dimensional arrays with merely
>   assignment compatible element types:
>     arr1 =  arr2 ; // needs type-equivalent elements
>     arr1 = {arr2}; // needs assignment-compatible elements
> 
> Less good:
> - Strange asymmetry between rules for the outermost
>   (slowest-varying) dimension and all the others,
>   especially when a mix of queue/dynamic/fixed
>   dimensions is present.
> - No simple way to copy multi-dimensional arrays
>   with elements that are assignment compatible but
>   not equivalent.
> 
> Please review.
> 
> Thanks
> --
> Jonathan Bromley
> 
> 
> 
> --
> 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.