RE: [sv-ec] Array assignment compatibility

Also see Mantis 2380.

Shalom 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Jonathan Bromley
> Sent: Saturday, June 21, 2008 11:23 AM
> To: sv-ec@server.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.
> 
> 
> 
---------------------------------------------------------------------
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.