RE: [sv-ac] Re: [sv-bc] Re: if-else

From: Steven Sharp <sharp_at_.....>
Date: Thu Nov 01 2007 - 17:35:28 PDT
>From: "Rich, Dave" <Dave_Rich@mentor.com>

>
>I don't think you need special semantics for if-else, 1'b0 will work, as
>well as '0. The LRM already says this about the equality operator
>
>If the operands are of unequal bit lengths and if one or both operands
>are unsigned, the smaller operand shall be zero-extended to the size of
>the larger operand. If both operands are signed, the smaller operand
>shall be sign-extended to the size of the larger operand.

Like all the descriptions under the specific operators, this is not a
special-case exception rule.  It is a simplistic user-friendly description
that is only valid when both operands are simple operands, not expressions.
When expressions are involved, the full context/self-determined expression
rules must be applied.  These rules are awkward for compares, because the
operands are neither fully self or context determined.  That is part of
why there is an extra description of the simple case.

Note that the simplistic description talks about extending the operands
just before the operation.  This is not what happens for expressions.
Instead, the size becomes the size of the operand expression and is
propagated down to it.  This is what Verilog always does.  See Mantis
1072 for more details.

If you can come up with a way of describing the rules for compares that
is clearer and does not lead to these misinterpretations, it would be
helpful.  It is an awkward thing to describe clearly.

Anyway, the two operands of a compare are part of each other's context.
Notice that the simplistic rules say that if either operand is unsigned,
they are zero-extended.  In the full expression rules, that translates
into either one being unsigned forcing the other to become unsigned, and
that propagates downward following the normal general expression rules.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Nov 1 17:35:47 2007

This archive was generated by hypermail 2.1.8 : Thu Nov 01 2007 - 17:36:45 PDT