RE: [sv-bc] part selects on arbitrary expressions

Then there's 4.11 which says:

"One or more bits of a packed structure can be selected as if it were a
packed array, assuming an [n-1:0] numbering"

and

"One or more bits of a packed union can be selected as if it were a
packed array, assuming an [n-1:0] numbering"

So implicitly declared packed arrays are always ordered [n-1:0] and, as
already pointed out, implicitly declared unpacked arrays are always
ordered [0:n-1]. The indexes for dynamic arrays and queues are always
ordered [0:n-1].

Basing the ordering of indexes for part selects on arbitrary expressions
should be independent of the operands ordering because you could have
multiple operands with mixed ordering.

BTW, if this is not the problem you were discussing, please change the
subject header.

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Feldman, Yulik
> Sent: Tuesday, March 13, 2007 7:46 AM
> To: Bresticker, Shalom
> Cc: sv-bc@server.eda-stds.org
> Subject: RE: [sv-bc] part selects on arbitrary expressions
> 
> I don't think any of these is really related to the problem we're
> discussing and is a good enough reason to decide on the [0:N-1]
> convention. 4.7 and 5.2 do not interfere with the definition of part
> selects on bit-stream types, and the biggest problem of Annex F is
that
> it defines the meaning of the "normalized range" term, so using a
> different definition for the same term will be confusing.
Semantically,
> the definition of the normalized range in DPI shouldn't conflict with
> any other definition of the "normalized range" of data type of part
> selects. Note that you can always "DPI-normalize" the already
> "part-select-normalized" range of the data type.
> 
> The problem that I see with always using the [0:N-1] "normalized"
range
> (and, in fact, with always using the [N-1:0] "normalized" range) for
> data types of part selects, is the ambiguity in bit significance of
> array elements. Consider, for example, the following code:
> 
> bit a [0:2];
> bit b [2:0];
> assign a = b;
> 
> The semantics of the assignment is the same as the following:
> 
> assign a[0] = b[2];
> assign a[1] = b[1];
> assign a[2] = b[0];
> 
> Now, let's apply a part select on "b":
> 
> assign a = b[2:0];
> 
> If the data type of b[2:0] is now "bit[0:2]", does this mean that the
> end result should be
> 
> assign a[0] = b[0];
> assign a[1] = b[1];
> assign a[2] = b[2];
> 
> since the data types of LHS and RHS of the assignment now match?
> Apparently, not. But then how do you define/decide when the elements
> should be assigned in straight or in reverse order, if the data types
of
> the part selects do not anymore correspond to the bit significance of
> the elements of the part selects?
> 
> The same problem exists with the [N-1:0] normalized range,
> symmetrically.
> 
> I would suggest to normalize the range to the (0,N-1) bounds, but to
> decide on either [0:N-1] or [N-1:0] choice based on the kind of type
> declaration from which the part select selects a part. If the MSB of
the
> type declaration is bigger than LSB, then use [N-1:0] type for the
part
> select; otherwise, use the [0:N-1] type. This way the order of
"element
> significance" will be preserved.
> 
> --Yulik.
> 
> -----Original Message-----
> From: Bresticker, Shalom
> Sent: Tuesday, March 13, 2007 11:50 AM
> To: Feldman, Yulik
> Cc: sv-bc@server.eda-stds.org
> Subject: RE: [sv-bc] part selects on arbitrary expressions
> 
> Yulik,
> 
> I also do not like choosing 0 as a left bound for unpacked dimensions,
> but there is a basis for it:
> 
> 4.7 says,
> "The indices of string variables shall be numbered from 0 to N-1
(where
> N is the length of the string) so that index 0 corresponds to the
first
> (leftmost) character of the string and index N-1 corresponds to the
last
> (rightmost) character of the string."
> 
> 5.2 says,
> "SystemVerilog accepts a single positive number, as an alternative to
a
> range, to specify the size of an unpacked array, like C. In other
words,
> [size] becomes the same as [0:size-1]."
> 
> F.1 says,
> "The C layer of DPI basically uses normalized ranges. The term
> normalized ranges means [n-1:0] indexing for the packed part (packed
> arrays are restricted to one dimension) and [0:n-1] indexing for a
> dimension in the unpacked part of an array. Normalized ranges are used
> for the canonical representation of packed arrays in C and for
> SystemVerilog arrays passed as actual arguments to C, with the
exception
> of actual arguments for open arrays. The elements of an open array can
> be accessed in C by using the same range of indices as
> defined in SystemVerilog for the actual argument for that open array
and
> the same indexing as in SystemVerilog."
> 
> F.6.5 says,
> "Packed arrays are treated as one-dimensional; the unpacked part of an
> array can have an arbitrary number of dimensions. Normalized ranges
mean
> [n-1:0] indexing for the packed part and [0:n-1] indexing for a
> dimension of the unpacked part of an array. Normalized ranges are used
> for accessing all arguments but open arrays. The canonical
> representation of packed arrays also uses normalized ranges."
> 
> Shalom
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> > On Behalf Of Feldman, Yulik
> > Sent: Tuesday, March 13, 2007 8:54 AM
> > To: Greg Jaxon; Brad Pierce
> > Cc: sv-bc@server.eda-stds.org
> > Subject: RE: [sv-bc] part selects on arbitrary expressions
> >
> > Greg,
> >
> > Maybe you meant (6,6,4), not (0,6,4). (0,6,4) doesn't make sense to
> > me.
> > First, it is not clear what 0 corresponds to. Second, choosing
(0,6,4)
> > means that selection from packed array has different bounds from
> > selection from unpacked array (note that the two arrays have exactly
> > the
> > same bounds; the packedness is the only difference). Making such a
> > difference seems to me an unnecessary complication in the
definition.
> >
> > --Yulik.
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.