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

From: Alsop, Thomas R <thomas.r.alsop_at_.....>
Date: Fri Nov 16 2007 - 16:13:23 PST
Thanks.  This is the example that I was wondering about.  When Shalom
mentioned case_item expression side-effects this didn't make sense.
After I replied I was wondering along the lines of the unique case_item
evaluation.  This is one reason why we have different behavior among
different implementations.  I know that the definition allows any
case_item to be evaluated in any order if it's unique, but from an
implementation perspective can we do anything to enforce the
implementation evaluation?  Or do we just live with these side effects?

-Tom

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Friday, November 16, 2007 4:08 PM
To: Bresticker, Shalom; sv-bc@eda.org; Alsop, Thomas R
Subject: RE: [sv-bc] FW: Manti 1345, 1711: unique if/case


>From: "Alsop, Thomas R" <thomas.r.alsop@intel.com>

>This is why side-effects doesn't have a meaning for me in this clause.
>I understood what you meant by side effects I just didn't see a clear
>example nor could I extrapolate one.

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

If you evaluate the second case item expression (s) first, then it
will be 4, and will match the case expression.  Then you evaluate
the first case item expression ((s++)+1) and it is 5, and will not
match the case expression.  You display "world".

If you evaluate the first case item expression ((s++)+1), then it
will be 5, and will not match the case expression.  As a side-effect,
it will increment s, so that s is 5.  Then you evaluate the second
case item expression (s), which is 5 and will not match the case
expression.  You do not display anything, but print a warning that
none of the cases matched.

The incrementing of s is a side-effect of the evaluation of ((s++)+1.

Steven Sharp
sharp@cadence.com

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Nov 16 16:17:12 2007

This archive was generated by hypermail 2.1.8 : Fri Nov 16 2007 - 16:17:21 PST