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