RE: [sv-bc] 19.12.5: array of instances connection to packed array port

The second paragraph of F.6.5 explains the concept of "linearized packed
array".
I think it's what you want by "equivalent packed array"; check it out.
If we want to go that way, we should combine the two into one
"LRM fiction" and re-use it in both places.

One problem with using MSB-LSB rather than LEFT-RIGHT is that
you may run into problems treating 'reg [7:0] r' differently than
'reg [0:7] r'.  LEFT-RIGHT is usually a better paradigm to use for
Verilog vectors (and even arrays).

In any case, treatment in this area needs careful wording so as
to handle all forms of packed array declaration correctly.

Thanks,
Doug

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Feldman, Yulik
> Sent: Wednesday, September 20, 2006 4:07 AM
> To: Jonathan Bromley; sv-bc@server.eda-stds.org
> Subject: RE: [sv-bc] 19.12.5: array of instances connection 
> to packed array port
> 
> Yes, it definitely makes sense.
> 
> Once such notion is defined, the bit mapping between the original type
> and the vector will also be needed to be defined, in both directions.
> This will help in understanding how the ports of arrays of 
> instances are
> mapped.
> 
> Note that there can be some complexities in such definition. For
> example:
> 
> 1. Mapping from the bit vector to the original type is ambiguous, when
> the original type contains packed unions.
> 
> 2. Note every slice of the vector can be mapped to a single 
> slice of the
> original type. For example, if we have two dimensional array
> a[1:0][1:0], which is mapped into a one-dimensional vector 
> a'[3:0], then
> the slice a'[2:0] doesn't have direct representation using a single
> slice on "a".
> 
> 3. If the original type contains a packed struct with one 
> member, should
> the slice on the vector that slices the whole struct be mapped to the
> member of the struct, or to the whole struct?
> 
> Still, it would be much better if the notion of the vector and the
> definitions of the mapping are defined explicitly, rather than left to
> the imagination of LRM readers and tool implementers.
> 
> --Yulik.
> 
> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On
> Behalf Of Jonathan Bromley
> Sent: Wednesday, September 20, 2006 1:05 PM
> To: sv-bc@server.eda-stds.org
> Subject: RE: [sv-bc] 19.12.5: array of instances connection to packed
> array port
> 
> > I think the phrase could be made more successful if it were 
> phrased in
> > terms of bit significance, starting from LSB to MSB (indirectly
> > referring to the vector equivalent Steven mentioned)
> 
> Would it not be better still if we had an explicit notion of the
> "equivalent vector" of any packed object?  I suspect that would be
> useful in other situations too.  By defining the equivalent vector
> to have a normalized subscript range [N-1:0] you could make it
> rather easy to rewrite 19.12.5.
> 
> I'm not suggesting that "equivalent vector" be defined in 19.12.5,
> but rather that it be a definition quite early in the LRM that
> can be used in discussion of *any* packed object.
> 
> Nor am I suggesting that the equivalent vector be required to
> exist as a real physical object.  It would be only a convenient
> (and well-defined) fiction in the LRM.
> -- 
> 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.
> 
>