RE: [sv-bc] FW: Manti 1345, 1711: unique if/case

My previous example showed that the order of evaluation of the case
item expressions can matter in the presence of side effects.  Here
are some other situations where precise specification is required:

begin
  int s = 4;
  case (4)
    4, s++: $display("hello");
    s: $display("world);
  endcase
end

Here it matters whether you continue evaluating case item expressions
after one expression attached to a case item has matched already.

You evaluate the case item expression 4 and determine that it matches
the case expression.  You know that the first case item has matched.
An efficient implementation would stop evaluating case item expressions
for the first case item, as matching more of them will not change the
fact that the first case item has matched.  If you do that, then when
you evaluate the first case item expression for the second case item
(s), you will get another match and a uniqueness violation.

If your implementation is inefficient and evaluates the second case
item expression for the first case item (s++), then s will become 5
as a side effect.  Then (s) will not match, and you will not get a
uniqueness violation.

Here is a case where it matters whether you continue evaluating after
you know you have a violation:

initial
begin
  int s = 4;
  unique case (4)
    4: $display("hello");
    s: $display("world");
    s++: $display("goodbye");
  endcase
  $display("s = %0d", s);
end

Here you definitely have a uniqueness violation, regardless of the
evaluation order.  Assume a top-to-bottom evaluation order.  When you
reach the second case item, you get a second match and know that you
have a uniqueness violation.  Continuing to evaluate will not change
the fact that you have a uniqueness violation, so it is unnecessary
unless the LRM says it is required.  If you continue evaluating, you
will evaluate the s++; otherwise you won't.  In one case you will
print "s = 5"; otherwise you will print "s = 4".

All these examples are crazy code.  Making them simple enough to be
easy to understand makes it is easy to see that they are crazy.  But
a more complex example of the same thing might not be so obviously
crazy.  Even if they were, the LRM should specify the behavior of all
possible code, not just the sane code.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.