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

Good examples.  This clarifies some other bizarre cases in the case_item
expression as well.  I could just as likely code this:

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

In which case the order of the case_item expressions becomes important.
If I evaluate the first expression, I have no match on the first
case_item because it changes the second expression.  It also makes this
unique non-violating.  If I evaluate the second expression first, then I
have a match.  Regardless of whether I evaluate the first expression, I
still have the second case_item matching and hence a unique violation.

You are right that these are corner cases. They seem like really rare
cases and as a designer if I code them like this, I deserve what I get.
Do you really believe we have to iron these out in the LRM?  I also want
optimized implementation because it's faster run time.  These types of
issues should be caught in linting tools, not spec'd out.

That said however I think the optimization could be spelled out.  That
seems like the best solution.  Is that the argument we are making here?
i.e. "the evaluation of case_item expressions shall start from the left
hand side and move to the right and upon first match will cease further
evaluation" and "all case_item's will be evaluated from top to bottom
and after the first violation will stop..."   

Thanks, 
-Tom

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Friday, November 16, 2007 4:34 PM
To: Bresticker, Shalom; sv-bc@eda.org; Alsop, Thomas R
Subject: 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.