-----Original Message----- From: Warmke, Doug [mailto:doug_warmke@mentor.com] Sent: Wednesday, September 20, 2006 7:03 PM To: Feldman, Yulik; Jonathan Bromley; sv-bc@server.eda-stds.org Subject: 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. [Yulik] Indeed. Just note that F.6.5 doesn't define the mapping for types other than arrays, so the definition should be extended. 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). [Yulik] Maybe for vectors/arrays, but not for structs/unions and the general case. Even for arrays, MSB is the same as LEFT (and LSB is the same as RIGHT) in both cases above, so the difference is only a matter of taste. On the other hand, the notion of MSB/LSB is clearly defined for other types, likes structs, while the notion of LEFT/RIGHT is not. Trying to describe bit ordering of structs using LEFT/RIGHT would be inappropriate. 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. > >Received on Thu Sep 21 00:06:02 2006
This archive was generated by hypermail 2.1.8 : Thu Sep 21 2006 - 00:06:22 PDT