RE: [sv-ec] Array assignment compatibility

Hi, Arturo.
 

> I share your concern, and see no reason for this change, 
> especially since the LRM retained the text:
> 
> "Assignment is done by assigning each element of the source 
> array to the corresponding element of the target array."

The change is the statement requiring only assignment compatibility.
The original (i.e., 1800-2005) rule is the one requiring type
equivalence.
Also see Mantis 2380.

Note that the choice of equivalence was not a typo. Following text says,
"Assigning fixed-size unpacked arrays of nonequivalent type to one
another shall result in a compiler error. See 6.22.2 for equivalent
types.

An array of wires can be assigned to an array of variables, and vice
versa, if they have the same number of unpacked dimensions, the same
number of elements for each of those dimensions, and an equivalent type
of elements."


> This introduces several questions regarding unpacked array 
> casting and assignments with overlapping source and destination.
> 
> 1) Array Casting:
> 
> Consider some legacy code such as:
> 
>    typedef int AIT[10];
>    AIT   ai;
>    byte ab[10];
> 
>    ai = ab;
> 
> The assignment was legal (because int and byte are assignment 
> compatible), but it is now illegal.

Based on the above, I think this was illegal in 1800-2005.


> One would think that the easiest way to make the code 
> compliant, would be to add a cast:
>    ai = AIT'(ab);
> 
> However, the rules for unpacked array casting are 
> unspecified. Should the above cast be disallowed since the 
> number of *bits* in the two arrays is different. Or, should 
> the cast operate on an element by element basis (as with the 
> previous assignment compatible rule). This needs to be 
> clarified in the LRM.

Why is this unspecified?
6.24.3 says,

"Assuming A is of bit-stream type source_t and B is of bit-stream type
dest_t, it is legal to convert A into B by an explicit cast:

B = dest_t'(A);

The conversion from A of type source_t to B of type dest_t proceeds in
two steps:

a) Conversion from source_t to a generic packed value containing the
same number of bits as source_t. ...

b) Conversion from the generic packed value to dest_t." 

 
> 2) Assignments with overlapping items:
> 
> Consider this code snippet:
>    byte  a[0:3] = '{ 0,1,2,3 };
> 
>    a[1:3] = a[0:2];
> 
> Given the text stating that assignment is done element by 
> element, is the above equivalent to:
>    a[1] = a[0];
>    a[2] = a[1];
>    a[3] = a[2];
> 
> Which would yield '{ 0, 0, 0, 0 }. 

Note that overlapping assignments of PACKED arrays has always existed in
Verilog.
Just declare a as a packed array instead of an unpacked array.
This has always worked.

Further, consider that the assignment may contain an intra-assignment
timing control. In that case, the RHS is evaluated at an earlier time
step than the assignment to the LHS. 

Curiously, the LRM actually states (10.4.1-10.4.2) that if there is no
intra-assignment timing control, then the order of evaluation of the
variable_lvalue and the expression on the right-hand side. What is meant
here by "evaluation of the variable_lvalue" is a case like where the LHS
contains a variable index. In that case, you need to know the index
value before you can know what element is to be assigned a value. But it
was not never meant to imply that some of the assignment can be
performed before evaluation of the RHS is completed.

Regards,
Shalom 
---------------------------------------------------------------------
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.