RE: [sv-ec] mantis 2380 comment

 
Given your explanation, I agree now with your proposal.

Francoise
    '
-----Original Message-----
From: jonathan.bromley@doulos.com [mailto:jonathan.bromley@doulos.com] 
Sent: Tuesday, June 09, 2009 4:21 PM
To: Francoise Martinolle
Cc: sv-ec@server.eda.org
Subject: 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.