[sv-ec] Subtle issue in 262

There are still two ways we could handle the unsigned aspect of this, which
have subtle differences.

In an ordinary case, the signedness of the expressions is computed as if
they were all operands of the same big compare expression. As with any
context-determined expression, if all the operands are signed, then the
result is signed. If any operand is unsigned, then the result is unsigned,
and all operands are treated as unsigned (which means any sub-expressions
inside them are also treated as unsigned, and so forth).

So when you say that the results of the expressions will ultimately be
treated as unsigned, there are two ways of doing this. The expressions
can be evaluated normally, possibly as signed, and then treated as unsigned
at the very end. Or the expressions can simply be considered unsigned from
the start. This can make a big difference. For example

  randcase
   4'sb1111 : x = 1;
   5'sb00001 : x = 2;
  endcase
  
If this were a case statement, these are both signed so they would both
be evaluated as signed. Extending 4'sb1111 to the 5-bit result width
with sign-extension will produce 5'sb11111, which will convert to unsigned
as 31. But if they are treated as unsigned before being evaluated, then
4'sb1111 will be zero-extended, producing 5'b01111, or 15. That is a
rather different weight value.

In addition to sign versus zero-extension, there are some operators that
have different signed and unsigned versions, such as division. So it is
important to establish the signedness with which the expressions are
evaluated.

I think it is probably easier to describe the expressions as being
evaluated as unsigned, rather than possibly being evaluated as signed
and then treated as unsigned. However, I think that is more likely to
surprise users. If someone does a weight calculation that is equivalent
to (-5)/(-1), they probably expect to get 5 rather than 0.

Steven Sharp
sharp@cadence.com
Received on Mon Nov 8 13:28:55 2004