Re: [sv-ec] mantis 2380 comment

Françoise,

> in your second proposal:
[...]
> Should n't it be :
> whose slowest-varying dimension's element type is assignment 
> comaptible (if array type) or equivalent (otherwise) with the 
> element type of the target array

I don't believe so.  However, I've been wrong plenty often
enough before, so let's take a look...

First off, the small change to 10.10 that I added to 2380
fixes an oversight; I noticed that the original wording would
have opened some ambiguities relating to packed arrays.  I hope
that there's no change to the original intent of unpacked array
concatenation (UAC).

> The element type of the slowest varying dimension can itself be an 
> array or not.

Indeed.  As I understand it, the key point of UAC is that 
it considers only the outermost (slowest varying) dimension
of an array, allowing you to compose array values from a 
mix of arrays and element values.  To do this with literal 
constants, which is likely to be a common case, it's 
essential to speak of assignment compatibility - otherwise, 
for example, the following would be illegal:

  byte BA[3];
  BA = {1,2,3};  // integer is not equivalent to byte

It seemed sensible to keep the same rule (assignment
compatible elements in a UAC) for any element type,
even if it is more complicated than an integral value. 
That's had a potentially useful side-effect:

  bit bit_vec[10];
  int int_vec[10];

  int_vec = bit_vec; // illegal, elements not equivalent
  int_vec = {bit_vec};  // legal UAC

The unpacked dimension of bit_vec is "exploded" in the UAC
so that it becomes a bunch of elements, each of which is
assignment compatible with the corresponding element of
int_vec.

I don't really see why this should be affected by whether
the element type is an array, an integral value or something
else (struct? enum? class?).  One good reason for this:
it seems clear (from 8.15) that a derived class handle is
assignment compatible with, but not equivalent to, an
ancestor class handle.  So....

  class C; .....
  class D extends C; .....
  C C_vec[5];
  D D_vec[5];

  C_vec = D_vec;  // reasonable, but illegal
  C_vec = {D_vec};  // legal UAC, element-by-element assignment

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Please forgive me if I've missed your point, but 
right now I don't see any need for a change.

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.