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

Feldman, Yulik wrote:
> 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?

No. In this case, the part select would not cause the rewiring you describe.
The part select does not have any side-effect on b.  It is purely functional.

assign a = b[2:0];    would become

assign a[0] = (b[2:0])[0];
assign a[1] = (b[2:0])[1];
assign a[2] = (b[2:0])[2];

The parentheses in the above are optional, since they only reinforce the
precedence rule for [].  Dropping them invites a little confusion vs
multi-dimensional indexing, and for that nuance, I probably wouldn't
object to seeing a warning for the b[2:0][0] syntax.

> 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?

There are no part selects or simple assignments that reverse bits in 1364
or in 1800.  Accessing a[2:0] in the above example is an error.

> 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.

Normalize, but conserve endianness - that is a new proposal!
Looking at only classical part selects, it is even pretty reasonable.
Could you write out the result type for A[X+:L] and A[X-:L], please?
Do you want it to take endianness from the +/- syntax, or from A?

Fortunately we're disputing a pretty minor point in the LRM.  How often
are the results of part selects re-indexed anyway?

Greg

Disclaimer:  Just exploring the terrain of this proposal; Synopsys
              takes no position until it votes one in committee.


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