RE: [sv-ec] Array assignment compatibility

Jonathan,

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

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.

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.

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

This is related to Mantis items 2240 and 2221.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Jonathan Bromley
Sent: Saturday, June 21, 2008 1:23 AM
To: sv-ec@eda.org
Subject: [sv-ec] Array assignment compatibility

My apologies if this has already been aired; I've been less
assiduous in following these discussions recently than I
should have been.

Mantis 1447 introduced some new, more flexible rules about
array assignment (a very good thing, in my opinion) but
it has introduced what appears to be an internal contradiction,
or at least an absurdity, in the rules for array assignment
(clause 7.6 in draft 6).  The original rule, taken straight
from 1800-2005, says that two unpacked arrays are assignment
compatible if they are of the same shape and their elements
are of EQUIVALENT type.  But near the beginning of page
106 we learn that queues, dynamic arrays and fixed-size
arrays are mutually assignment compatible if they have
appropriate shapes and their elements are of ASSIGNMENT
COMPATIBLE type, a much weaker condition.  Are we to assume,
then, that...

   int AI[10];
   byte AB[10];
   logic [15:0] QW[$];

   AB = AI;  // illegal, element types not equivalent

   QW = AI;  // legal, element types assignment compatible
   AB = QW;  // legal, runtime shape-match check is OK,
             //    element types assignment compatible

I remain of the opinion that the requirement for element
types to be equivalent is tiresome and unnecessary; if the
element types _are_ equivalent then a tool can easily
implement the array assignment as a memory block copy,
but if not then it is committed to element-by-element 
copying as in the second part of my example.  Now that
1447 has mandated this element-by-element copy in some
situations, isn't it time to remove the equivalent element
types restriction altogether?


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

This e-mail and any  attachments are  confidential and Doulos Ltd.
reserves 
all rights of privilege in  respect thereof. It is intended for the use
of 
the addressee only. If you are not the intended recipient please delete
it 
from  your  system, any  use, disclosure, or copying  of this  document
is 
unauthorised. 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.



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