RE: [sv-bc] Musings on array assignment compatibility

BTW your examples are all packed arrays, not unpacked.

I think proposals #2 and #4 are not mutually exclusive, but my choice is
still #2. Consider that the majority of arrays in a testbench are single
dimensional, and the majority of array assignments are between matching,
let alone equivalent element types. #2 covers the majority of cases.

That leaves a relatively small number of cases to deal with

int A[2][2];
byte B[2][2];

Isn't the intent clearer to write as

foreach(A[i,j]) A[i][j] = B[i][j];

rather than 

$cast(A,B);


I am opposed to #5 for of a number of reasons. First, it relaxes the
type safety that aggregates arte supposed to enforce. This is a slippery
slope. Second, the casting rules are not reflexive. And third, this will
be difficult to reason with when there are mixes of dynamic and fixed
sized arrays throughout the dimensions.

And just reading Jonathan's latest response, if operator overloading is
ever exploited, this will make type conversions trivial.

Dave



> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Jonathan Bromley
> Sent: Tuesday, June 02, 2009 2:43 AM
> To: sv-bc@server.eda.org; sv-ec@server.eda.org
> Subject: [sv-bc] Musings on array assignment compatibility
> 
> To SV-EC and SV-BC:
> 
> It seems that some members of BC feel quite strongly
> that they wish to keep the current definition of unpacked
> array assignment compatibility, namely that the source
> and destination types should be equivalent.  I have
> some sympathy with that point of view - after all, I've
> lived with it in VHDL for years - even though I've been
> pushing for a relaxation to allow arrays to be assignment
> compatible if their elements are assignment compatible.
> 
> EC agreed that we should try to find a compromise that
> allows users the flexibility of copying arrays with
> only assignment-compatible elements, while preserving
> the safety of the current rules for RTL design.
> However, we must move quickly; any new proposal will
> require very careful sifting through the existing LRM
> text, and we don't have long to do it.
> 
> Here are a few ideas, in no special order.  I'd value
> any feedback you may have.  My current favorite is #5,
> but I'm not sure I've worked through all the consequences
> in detail yet.
> 
> 1) The proposal currently attached to 2380 (file
>    2380-proposal-v1.pdf), allowing assignment
> compatibility between arrays whose elements are
> assignment compatible.  Users who want stronger
> checking against bit-width mismatches should rely
> on their linting or synthesis tools for such checks.
> 
> ~~~~~~~~~~~~~~~~~~~~~
> 
> 2) Keep type-equivalence as the default requirement
>    for assignment compatibility of unpacked arrays,
> but allow a relaxation when the source is an unpacked
> array concatenation (UAC for short).  For example:
> 
>   int [3] i3;
>   byte[3] b3;
> 
>   b3 = {1,2,3};  // OK, UAC has assignment-compatible elements
>   i3 = b3;       // illegal, not equivalent
>   i3 = {b3};     // OK, rules relaxed because of the UAC
> 
> But there's a problem: UAC considers only one array
> dimension (the slowest-varying) so a multi-dim UAC
> would still need to have element type equivalence
> with its target:
> 
>   int [2][2] i22;
>   byte[2][2] b22 = '{ '{1,2}, '{3,4} };
> 
>   i22 = b22;          // illegal, not equivalent
>   i22[0] = b22[0];    // illegal, not equivalent
>   i22 = {b22};        // illegal, elements not equivalent
>   i22[0] = {b22[0]};  // OK because of UAC
> 
> ~~~~~~~~~~~~~~~~~~~~~
> 
> 3) Like (2), but add a special rule for UACs so that
>    the relaxation on element type compatibility goes
> all the way down through every unpacked dimension
> before checking elements for assignment compatibility.
> I don't much like this.
> 
> ~~~~~~~~~~~~~~~~~~~~~
> 
> 4) Arrays must be equivalent to be assignment compatible,
>    but add a new meaning for $cast(): if source and target
> are unpacked arrays of the same shape, do an element-by-
> element copy requiring only assignment compatibility of
> the elements.  This would be an easy loophole for testbench
> code; RTL code, which probably can't use $cast, gets the
> stricter equivalence requirement.
> 
> ~~~~~~~~~~~~~~~~~~~~~
> 
> 5) A subtle change in the rules for assignment compatibility:
>    If the target of an assignment is a fixed-size unpacked
> array, then the source expression must be of equivalent type.
> If the target is a variable-size unpacked array (dynamic or queue)
> then the source expression must be an unpacked array with the
> same number of elements, of assignment-compatible type.
> In this scheme, RTL code (where all arrays are fixed-size)
> would have the stricter rule, but testbench code can easily
> relax the rule by using a queue or dynamic target.
> 
> Thanks in advance for your input.
> --
> Jonathan Bromley
> Consultant
> 
> Doulos - Developing Design Know-how
> VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk *
Project
> Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW,
> UK
> Tel:  + 44 (0)1425 471223                       Email:
> jonathan.bromley@doulos.com
> Fax:  +44 (0)1425 471573                        http://www.doulos.com
> 
>
------------------------------------------------------------------------
----
> ----
> Doulos Ltd is registered in England and Wales with company no. 3723454
> Its registered office is 4 Brackley Close, Bournemouth International
> Airport,
>         Christchurch, BH23 6SE, UK.
> 
> This message may contain personal views which are not the views of
> Doulos, unless specifically stated.
> 
> 
> --
> 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.