RE: [sv-ec] Mantis 2380 - array assignment compatibility

I also agree.

Shalom 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Arturo Salz
> Sent: Thursday, May 14, 2009 10:24 AM
> To: jonathan.bromley@doulos.com; sv-ec@eda.org
> Subject: RE: [sv-ec] Mantis 2380 - array assignment compatibility
> 
> Jonathan,
> 
> What you propose seems eminently reasonable to me - and 
> certainly matches my intent back when I first wrote some 
> parts of those sections. BTW, you may want to poll people in 
> the SV-BC as well.
> 
>         Arturo
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of jonathan.bromley@doulos.com
> Sent: Wednesday, May 13, 2009 1:14 PM
> To: sv-ec@eda.org
> Subject: [sv-ec] Mantis 2380 - array assignment compatibility
> 
> I think  the un-addressed ballot items 33, 34, 56 (Mantis 2380)
> may well come back to haunt us, so it's probably as well to be
> prepared for it.
> 
> We are in a bit of a mess with array assignment compatibility.
> There is plenty of text in 7.6 saying that unpacked arrays
> of any kind (fixed-size, queue, dynamic) should be assignment
> compatible if they are of the same shape and their elements
> are of **assignment compatible** type, and I would strongly
> argue that users would reasonably expect that to be true.
> On the other hand, there is also a specific statement in
> 7.6 that fixed-size unpacked arrays are assignment
> compatible with one another only if their shapes are the
> same and their elements are of **equivalent** type.  I have
> argued before, and restate here, that I see no sensible
> reason for the element-equivalence requirement.  If an
> implementation wishes to use memory block-copy to copy
> one unpacked array to another, it is free to do so if
> it can statically determine that the elements are
> of equivalent type.  If they are not, it would be a
> great courtesy to users for the implementation to do
> the element-by-element copy, which the language does
> not readily permit users to code in a general way.
> 
> I would therefore very much like to rewrite 7.6 to redefine
> assignment compatibility of unpacked arrays so that the
> elements need only be assignment-compatible, not equivalent.
> This would require a few other very minor LRM changes:
> a cross-reference from the main entry on assignment
> compatibility (6.22.3) to the new 7.6 text, a few small
> fixes elsewhere.  I'm happy to write up a proposal if
> people agree this is sensible.  But I also understand
> that there may be some vendor push-back against this.
> 
> What do you think?
> 
> Thanks
> --
> Jonathan Bromley
> Consultant
> 
> Doulos - Developing Design Know-how
> VHDL * Verilog * SystemVerilog * SystemC * PSL * 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                        http://www.doulos.com
> 
> --------------------------------------------------------------
> ------------------
> Doulos Ltd is registered in England and Wales with company no. 3723454
> Its registered office is 4 Brackley Close, Bournemouth International
> Airport,
>         Christchurch, BH23 6SE, UK.
> 
> This message may contain personal views which are not the views of
> Doulos, 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.
> 
> 
> 
---------------------------------------------------------------------
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.