[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 14:58:39 2004