Re: [sv-ec] Subtle issue in 262

Steven,

It was these types of issues, among others, that prompted the semantics
that are currently documented in the LRM.

I believe the comparison with a case statement is not warranted because,
unlike a case statement, a randcase has no expression against which the weights
must be compared. The weights are computed as a fraction of unsigned numbers,
regardless of the signdedness of the individual expressions. Section 12.16.1 states
that "Weight expression must evaluate to integral non-negative values.". So your
example is illegal since the first weight evaluates to -1.

I believe the semantics described by the LRM are clear and unambiguous. It states
that each weight is self-determined and that each summand is unsigned.
I take that to lead to the following implementation:

    randcase
        expression_1 : ...
        expression_2 : ...
        ...
        expression_N : ...
    endcase

----
    summand_1 = expression_1;
    summand_2 = expression_2;
    summand_N = expression_N;
    sum = summand_1+ summand_2 + ... + summand_N ;
All of these operations are performed using standard Verilog semantics.
Each summand is computed using the precision of its context, which is the 
precision of its corresponding expression. The sum is computed using the
precision of the addition context, which yields the maximum precision of all 
the summands.
Furthermore, the LRM states that each summand (and hence the sum) is unsigned. 
Hence, sum and all the summands are unsigned, so there is no sign-extension when 
performing the sum. Likewise the division uses two unsigned numbers. I see no
reason to change any of this.
    Arturo
----- Original Message ----- 
From: "Steven Sharp" <sharp@cadence.com>
To: <sv-ec@eda.org>
Sent: Monday, November 08, 2004 1:28 PM
Subject: [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