[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.