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.

I'll play along.

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

Which is presumably why it was made symmetric in the language. In a casex,
you can't just swap the case expression with the case-item expressions.
With a comparison operator, you can always swap them to put the pattern with
the don't cares on the right.

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

There is some prettiness in making the wildcard compares exactly match the
behavior of casex, though in this case it involves unnecessarily copying a
behavior that is undesirable. And as I commented on issue 99, it might be
beneficial to add new versions of casex/casez that are asymmetric, so that
users can avoid this risk. Then the operator would match those.

Style guidelines and lint checkers won't help any with this problem. That
could only cover situations where both sides of the operator are constants,
which isn't very useful (and in fact wouldn't cause any synthesis problem,
since it is just a constant expression and doesn't need corresponding logic).

The problem arises with an operand that is produced by the logic of the
design and contains X or Z (meaning unknown or high impedance, not don't
care). There is no way a lint tool can detect that, since it requires
simulating the design to determine. And the only style guideline you
could give is "make sure your design doesn't produce any Xs", which is good
advice, but verifying it is one of the jobs of simulation. And that job
gets harder when operators are optimistically discarding Xs.

Steven Sharp
sharp@cadence.com
Received on Tue Aug 31 12:38:45 2004