Note that a case_item_expression is not a specialized syntax for pattern
matching, even in casex or casez. It is exactly what the name implies:
an expression. Most of the time they are just numeric literals, which
may have X or Z bits to act as don't-cares in casex or casez. However,
they can be arbitrary expressions, which are evaluated normally and have
the normal numeric values. X or Z bits in that numeric value are treated
as wildcards by casex or casez.
So the X or Z in a literal in a case_item_expression is not some special
syntax in a template for pattern matching, even if users think of it that
way. It cannot simply be extended with new characters for different kinds
of pattern matching, and be consistent with the way Verilog cases are
currently defined. Such a syntax would not be an expression or have a
value.
On a related note, Jonathan is correct that * could not be used as a
wildcard symbol. Because a case_item_expression can be an arbitrary
expression, multiplication and exponentiation are perfectly legal
operators to appear within them. A case_item_expression such as
32'h1*1 is already perfectly legal in Verilog, meaning a multiplication
of 32'h1 by the unbased constant 1, for a resulting case item expression
value of 1.
I assume the phrase "incoming X's" refers to an X in a case expression
(i.e. the selector in parentheses) that is a non-constant value produced
by the logic of the design. The original request referred to these as
being matched by wildcards in a case_item_expression. In fact, there is
a much worse problem with them. In a casex, these are actually treated
as wildcards themselves. So they will not only match wildcards in the
case_item_expressions (which should be fine, since they were don't-cares)
they will match 0 or 1 too (which is just plain wrong).
This symmetry of wildcards is generally a bad thing. It was done to allow
"reverse" cases where the case expression was a constant with wildcards and
the case item expressions were variables. I don't think that this rarely
used capability really justifies the problems it causes.
If this symmetry is the true problem here, it could be resolved by adding
new asymmetric forms of the casex and casez statements that only treat X
and Z bits as wildcards in the case_item_expression, not in the case
expression.
This symmetry problem has been continued in the SystemVerilog =?= and !?=
operators. Here there is no argument for symmetry, since you can always
arrange to put the "incoming" value on the left and the "pattern" to be
matched on the right. It is a language design error for these operators
to treat X/Z as a don't-care for both operands. I will file an erratum
for this issue.
Steven Sharp
sharp@cadence.com
Received on Mon Aug 30 12:35:08 2004
This archive was generated by hypermail 2.1.8 : Mon Aug 30 2004 - 12:35:17 PDT