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.