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

I think I prefer (4).  I could live with (5) but
I like the "obviousness" of (4).  If array assignments
require equivalent types in all but one case, I
really prefer to make that case very obvious.  Using
an explicit $cast is a pretty clear indication that
the user understands that there is a special assignment
rule in play.  That also avoids a double assignment
in cases when you want to do a converting assignment.

    module top;
       int   a[100];
       byte  b[100];
       byte  c[];

       initial  $cast(b,a);

       initial begin
           c = new[100](a);
           b = c;
       end
    endmodule


The $cast passes my "obviousness" test; the second
form does not.

Gord.

jonathan.bromley@doulos.com wrote:
> 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.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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