RE: [sv-bc] Errata: undesirable behavior of wildcard compares

I whole-heartedly agree with Steven, and would like to see this "erratum"
fixed in the P1800 SV LRM. For the sake of discussion, though (and for my
own edification) I'll play devil's advocate for a moment.

The wildcard comparison operators were added as a shortcut to casex for
single comparisons, and with the added convenience of being able to be used
in continuous assignment statements without having to hide the casex
statement in a function. The casex statement allows the X or Z don't care
bits to be specified in either the case expression or the case-item
expression. I have on rare occasion seen code that specifically uses the
symmetric behavior of casex to set mask bits in the case expression.
Synthesis does not support masking bits in this way, and will flag it as an
error. Synthesis only allows X and Z to be specified in constant values
used in the case-item expression. (Someone please correct me if I am wrong
about this). Lint tools that check for synthesizable guidelines will also
flag this bit masking of the case expression as a coding style error.

My devil's advocate question is, is it best to keep the wildcard comparison
operators orthogonal with casex, and let style guidelines and lint checkers
enforce only specifying the don't care bits on one side of the operator?
This would allow deliberate bit masking if desired, even though it has all
the risks Steven has pointed out (and which casex also has).

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
503-692-0898

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Steven Sharp
> Sent: Monday, August 30, 2004 2:59 PM
> To: sv-bc@eda.org
> Subject: [sv-bc] Errata: undesirable behavior of wildcard compares
>
> The wildcard comparison operators (=?= and !?=) in section 7.5 have
> behavior that is undesirable for use in designs. They are symmetric
> and treat X or Z as a wildcard in either operand. This can result in
> overly optimistic simulation, and pre- versus post-synthesis
> mismatches.
>
> In every practical situation, one of the operands will be a value
> produced by other logic in the design, and the other operand will be
> a pattern to compare against. The pattern will generally be
> a constant
> value, with X or Z used to indicate a don't-care. In the
> value produced
> by other logic in the design, an X or Z will indicate an unknown logic
> value instead. Treating those as don't-cares is wrong.
>
> For example, consider an address decoder that generates a
> column-select
> by checking a subset of the address bits:
>
> assign cs = (address =?= 16'hff??);
>
> If the address is 16'hff37, the result should be true. If the address
> is 16'h0f37, the result should be false. This works. But suppose the
> incoming address is tristated, or 16'hZZZZ. The way the operator is
> defined, the decoder will produce true. It should produce
> unknown or X.
> In a real design, the decoder would not reliably produce a 1.
> Or suppose
> the address is 16'hXf37, due to contention, initialization problems or
> timing errors. In the real design, that could end up being
> 16'hff37, which
> would produce true, or 16'h0f37 or other values, which would
> produce false.
> But the way the operator is defined, simulation will produce
> true. These
> simulation results are overly optimistic and therefore wrong.
>
> A synthesis tool will produce decode logic that sets cs to
> the AND of the
> upper 8 address bits and ignores the lower 8 bits. During
> post-synthesis
> simulation, address values of 16'hZZZZ or 16'hXf37 will
> produce an X out
> of that decode logic. That won't match the pre-synthesis
> simulation, which
> incorrectly produced true.
>
> There is a straightforward solution. The wildcard compare
> operators should
> not be symmetrical. They should be defined so that X or Z
> are treated as
> don't-cares only in one of the two operands, the one intended
> to be treated
> as a pattern. In general, people tend to write their
> compares with the
> variable value on the left, and the constant value they are
> comparing it
> to on the right. Since this is the natural order, it is the
> right operand
> that should be treated as a pattern. When doing a compare,
> the designer
> would put the value produced from other logic on the left,
> and the pattern
> to be matched on the right. This would fix the problem.
>
> In the example above, this would produce X in the cases where
> the result
> should be unknown. The behavior would also match the
> interpretation of
> the synthesis tool. This behavior is more desirable in all practical
> design situations I can think of. I can't come up with any reasonable
> situation where the currently described behavior is better.
>
> I proposed this kind of asymmetric wildcard compare operator
> for IEEE 1364,
> while still unaware of the SystemVerilog version. I proposed
> a slightly
> different syntax that made it clearer that the right-hand
> operand had the
> wildcards in it: ==? and !=?.
>
> Steven Sharp
> sharp@cadence.com
>
>
>
Received on Mon Aug 30 15:42:05 2004