RE: [sv-ec] Array assignment compatibility

Jonathan,

The rules for unpacked array concatenation can help in simple
situations, but will generally not work with multi-dimensional arrays.
And, if this is the prescribed way to deal with these situations then it
would be helpful to add note in the LRM stating this explicitly along
with an example (perhaps the simple one below).

I agree that there is a type checking inconsistency between fixed size
and dynamic arrays. They should all be either equivalent or assignment
compatible. I see good arguments in favor of either.

We also seem to be in agreement that the rules for array casting - other
than bit stream casting - are undefined. And, if we are going to live
with this, shouldn't we make them illegal or risk running into more
implementation divergences?

As to my last example, I believe we are both in agreement that the
desired semantics is to have the assignment behave as if the RHS were
copied into an intermediate temporary variable. But, the LRM should
state that explicitly - and I propose removal of the sentence stating
arrays are copied element by element. That was only useful to explain
the behavior of the assignment-compatible rules - now that the rule
requires equivalent types, it serves no purpose other than to confuse.

And, by 2240, I meant the email thread,
http://www.eda-stds.org/sv-bc/hm/2240.html (sorry for the confusion).

	Arturo

-----Original Message-----
From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
Sent: Monday, June 23, 2008 2:10 PM
To: Arturo Salz; sv-ec@eda.org
Subject: RE: [sv-ec] Array assignment compatibility

Arturo

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

Yes, it is exactly such situations that I find are so bizarrely
affected by the "equivalent element types" rule.  However, 
the rules introduced by Mantis 1702 for unpacked array 
concatenation would unambiguously permit

   ai = {ab};

Maybe it's right to have this as the canonical way to
cast an unpacked array to another of the same shape but
with assignment-compatible rather than equivalent elements.
If that's everyone's wish, then I could live with the 
current tighter rule about simple assignment - but it
raises a query over the 1447 relaxation whereby queues, 
dynamic arrays and fixed-size unpacked arrays can be 
copied on to one another if their elements are 
assignment-compatible.

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

I believe that this is a bit-stream cast (since both ai and ab 
are of bit-stream types, by the definition in 6.24.3) and it is 
illegal because they contain different numbers of bits and the
target is fixed-size and unpacked.

I agree that we don't appear to have a definition of the cast 
operation type_name'() for unpacked arrays that are not of 
bit-stream type, but I think we could live with that issue
being shelved.

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

Which would clearly be insane.  If the definition suggests that this
might occur, then the definition needs fixing.  It would be triflingly
easy to write a definition based on copying via an intermediate
variable, if need be.

> This is related to Mantis items 2240 and 2221.

Sorry, I can't see the connection with 2240?
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * 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                           Web:
http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

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