Re: [sv-bc] Re: issue 324 for asymmetric casex

>The case items in a case-inside statement syntactically subsume those
>in a case statement, because an expression is a degenerate value range.
>
>  open_range_list : statement_or_null
>  open_value_range { , open_value_range } : statement_or_null
>  value_range { , value_range } : statement_or_null
>  expression { , expression } : statement_or_null

That is fine for the BNF, but I think something more is needed for the
description.

The original reason for adding this functionality is to provide a version
of casex that won't produce pre/post-synthesis simulation mismatches.  The
description should make that part of the functionality clear.

There is also an issue with the description of the case semantics.  In a
normal case, case equality is used, so the only possible outcomes of a
comparison are true and false.  With an inside operator, X is a possible
outcome.  There are a couple of ways of dealing with that.  We could
take the approach of the case equality, and define a "case inside"
operator that produces 0 instead of X in those cases.  Or we can just
define that an X result in the comparison is treated as a non-match
(which has the same effect).

Steven Sharp
sharp@cadence.com