Re: [sv-bc] Question about shortint'(8'hFF + 8'h01)

Paul Graham wrote:
>>And yes, this did reverse issue 147. People do make the wrong decisions.
>
>
> So it seems that for packed data types at least, a type conversion has
> almost no effect. With issue 147, a type conversion created a little
> region of self-determination. Issue 111 removes that little region.
> But this raises the question of whether the operand to a type
> conversion affects the sign of the surrounding expression. For
> instance:
>
> typedef logic [31:0] uint;
> typedef logic signed [31:0] sint;
>
> uint u;
> sint s;
>
> wire q = s > sint'(u);
>
> If u were self-determined, then its unsignedness would not affect
> the comparison. But now that u is not self-determined, then its
> unsignedness should affect the sign of the comparison.
>
> This is different from:
>
> wire q = s > $signed(u);

Paul,

I believe that the cast isolates the context-determination of its operand
from the rest of the expression. Functionally it acts as though it was
a temporary variable of the casting_type. The casting_type influences the
type and size of the expression in which it appears, so your example is
a signed comparison. If the context surrounding a cast T'(o) determines a
different type for it, the operand expression, o, is first coerced to
have the type T (which might involve truncation and imposing a signedness
and/or packed array rank), and then coerced again to fufill its role in the
surrounding context.

The errata is concerned only with what effects the casting_type has on
the operand expression (inside the parentheses). Here I think your
question about type-determination is relevant, but your example misses
the discriminating case. I'd worry more about uint'( s >> 1 ),
which I believe is an arithmetic shift (copy the sign bit). Furthermore,
if sint was 16 bits wide and uint remained 32 wide, s would sign extend
to 32 bits, arithmetically shift right 1 and only then be reinterpreted
as a 32 bit unsigned quantity. This agrees with the "implicit cast"
rationale, and accommodates the "context-determined expression bit width"
rules from V2K and its predecessors.

Greg Jaxon

P.S. This is just my personal understanding of things as presently written.
      I could be mistaken, and often have been on this particular topic.

> Also, does the type conversion itself count as an operand for sizing?
> For instance:
>
> logic [7:0] x, y;
> logic [15:0] z;
>
> z = x + integer'(y);
>
> Is this rhs of the assignment evaluated to 16 bits (from the lhs) or
> 32 bits (from the integer type conversion)? I guess in this case it
> doesn't affect the result, but I wonder if there are cases where it
> would make a difference.
>
> Paul
>
>
Received on Fri Sep 17 15:22:59 2004