RE: [sv-ec] Array assignment compatibility

Arturo,

> The rules for unpacked array concatenation can help in simple
> situations, but will generally not work with multi-dimensional arrays.

Agreed.  Nor do I see any reasonable way to fix that; 
unpacked array concatenation is very clearly intended to 
deal with only one dimension at a time.

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

Depending on the outcome of this issue, it might be worth
a note or example, yes.  It wasn't my intent to make this
the "prescribed" or even recommended way - it's just
something that happened to fall out of Mantis 1702.  And,
as you say, it works only for one dimension.

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

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

I'm becoming increasingly troubled about this.  The definition of
bit-stream casting is so wide that it hijacks the cast operation,
making it effectively unusable for anything unpacked unless you
really want bit-streaming.  Bit-stream casting can do some 
"interesting" reshaping operations on multi-dimensional 
unpacked arrays.  I can imagine that giving users some nasty
surprises, particularly if they have done creative things 
with type parameters.

> As to my last example...

Thanks for the clarification about the SV-BC emails.  It looks
as though everyone agrees that the RHS gets evaluated first
before anything is done to the LHS.  Of course that's sensible.
It ought to be in the LRM, but in view of the wide agreement
with common-sense it's probably something that should be filed
as a Mantis for correction in a future LRM revision.
-- 
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 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.