Re: [sv-ec] Subtle issue in 262

Arturo,

I am going to have to disagree with a number of your points.

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

I don't believe that the documentation in the LRM deals with these issues
any better. The main difference seems to be that the LRM *fails* to
document the semantics fully, leaving the behavior undefined. It does
not define whether the length conversion before summing should be done
with the signedness of the expression or as unsigned. This is comparable
to the issue I raised. The difference is that I am actually trying to
get the behavior defined, which is certainly not a flaw in my proposal
as compared to the current LRM text.

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

There are interim values, the sum of the weights and a random number based
on it. That random number must be compared against the weights. To perform
the sum and the comparisons requires that the weights be the same length as
the sum and the random number. The current text includes incomplete special-
case rules for inserting conversions to get those length matches. This is
not consistent with Verilog, where such length matches are always gotten by
making the expressions context-determined, so that they come out the same
length by following the standard expression evaluation rules.

The width requirements for the comparisons are the same as for a case
statement, since both require all the expressions to be compared to a
single value. The analogy between them is quite close.

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

This is one of the issues that I raised in 262 and which was discussed
at the EC meeting. I asked whether the expressions were not allowed to
be negative signed values, or whether they were just treated as unsigned
values. The consensus seemed to be that they were just treated as
unsigned values and that negative signed values would be treated as large
unsigned values. This was stated quite clearly during the meeting. Your
opinion that this is illegal does not agree with my understanding of the
consensus at the meeting.

If other participants understood this differently, please speak up.

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

These two statements are inconsistent. A self-determined weight may be
signed. If the summands are unsigned, then there must be an implicit
conversion somewhere in there. Or maybe the term summand is supposed to
mean the expression rather than the result of the expression, in which
case the expression was supposed to be evaluated as unsigned rather than
evaluated as self-determined and the converted to unsigned. If not, is
the summand the same width as the expression or the same width as the
sum? If it is the same width as the sum, then there is a second implicit
conversion to that width, and it is not clear what order the two conversions
should be done in. So the LRM is neither clear nor unambiguous.

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

That is one possible interpretation. However, it is not consistent with
Verilog. The summands are interim results. All interim results in Verilog
are computed at the width of the expression. Inserting explicit assignment
statements in your conceptual model and trying to invoke the rules for
assignment statements is inappropriate. There are no explicit assignment
statements in the original source, and Verilog treats explicit assignment
statements differently from interim results in calculations. I don't even
think that the rules for assignment match what you want anyway.

It is also not clear in the LRM text whether the summands are the width
of the RHS expressions, or the width of the sum. All the LRM says is
that they are unsigned. I assume that your intent is that they are the
same width as the RHS expression, but unsigned.

This still leaves you with the problem of the comparisons. You have
provided no interim value for the expressions/summands which is the same
width as the random number for comparison purposes. Are you suggesting
that there is another set of intermediate values, similar to your summands,
that has yet another converted value of the weights? This conceptual model
becomes even more unwieldy and ambiguous, with no specification of how that
conversion should be done.

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

Actually, with the statement that the weight expressions are self-determined,
your interpretation here is incorrect. If they are self-determined, then
they will be evaluated with self-determined signedness. Your conceptual
model of assignments to unsigned summands wouldn't change that, since the
signedness of the LHS of an assignment does not affect the signedness of
the RHS. So a RHS side consisting of division of two signed numbers would
be done as signed division.

If you want the expressions to be treated as unsigned during evaluation,
then the existing LRM text doesn't do that. You need the expressions to
be treated as context-determined, with this treated as an unsigned context.
That is what variant 1 of my proposal would do.

Steven Sharp
sharp@cadence.com
Received on Tue Nov 9 13:29:33 2004