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

 

 

-----Original Message-----
From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: Tuesday, March 13, 2007 5:34 PM
To: Feldman, Yulik; Bresticker, Shalom
Cc: sv-bc@server.eda-stds.org
Subject: 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] 

[Yulik] Only "implicitly declared packed arrays" that correspond to
selections from packed structures and unions. Packed arrays that
correspond to selections from packed arrays do not have to obey this
rule. Packed arrays that correspond to selections from packed structures
and unions do not have the problem with element ordering that I
described in previous mail (structures and unions can not be declared
two different ways, like arrays). I agree that packed arrays that
correspond to selections from packed structures and unions should always
be [n-1:0]; but that doesn't imply that packed arrays that correspond to
selections from packed arrays should also always be [n-1:0].

and, as

already pointed out, implicitly declared unpacked arrays are always

ordered [0:n-1]. 

[Yulik] Only in DPI's mapping. It doesn't have to be the same in
definition of data types of part selects. 

The indexes for dynamic arrays and queues are always

ordered [0:n-1].

[Yulik] OK; but like with packed structures and unions this doesn't
imply that selections from fixed-size packed/unpacked arrays should
always be [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.

[Yulik] IMO, the ordering of indexes should be based only on the type of
the expression from which the part select selects the part (the one on
the left of "["). There is always only one such expression (even if it
has multiple sub-expressions).

 

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.