ISSUE 402

Number 402
Category errata
Synopsis 9.5: evaluation of case expression
State lrmdraft
Class errata-discuss
Arrival-DateJul 26 2003
Originator "Brad Pierce" <Brad.Pierce@synopsys.com>
Release 2001b: 9.5
Environment
Description
Must a case expression be evaluated exactly once and before
any of the case item expressions? Or it would be legal to
implement a case by

if ( case_item_expression_1 == case_expression )
...
elsif ( case_item_expression_2 == case_expression )
...

I thought such an implementation would be incorrect in general,
because of the possibility of side-effects, but I see nothing
in the LRM to prohibit it. Here are two examples that highlight
the difference --

//------------------------------------------------------------------

module m_1 (o) ; /* Brad.Pierce@synopsys.com */
output [5:0] o ;
reg [5:0] o ;
integer i ;
integer j ;

function [5:0] f ;
input [5:0] n ;
begin
f = i ;
if ( n == i ) i = i + 1 ;
end
endfunction

task g ;
input [5:0] n ;
begin
$display(n) ;
j = j + n - 1 ;
end
endtask

always begin
i = 0 ;
j = 0 ;
while ( i <= 10 )
case ( i )
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
endcase
o = j ;
$display("should be %d? -- is %d", 10*(10+1)/2, o) ;
end

endmodule

//------------------------------------------------------------------

module m_2 (o) ; /* Brad.Pierce@synopsys.com */
output [5:0] o ;
reg [5:0] o ;
integer i ;
integer j ;

function [5:0] f ;
input [5:0] n ;
begin
if ( n == i ) i = i + 1 ;
f = i ;
end
endfunction

task g ;
input [5:0] n ;
j = j + n - 1 ;
endtask

always begin
i = 0 ;
j = 0 ;
while ( i <= 10 )
case ( i )
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
f(i) : g(i) ;
endcase
o = j ;
$display("should be %d? -- is %d", 0, o) ;
end

endmodule

//------------------------------------------------------------------


Fix
At the beginning of the paragraph after
the first "simple example" of Section 9.5
prepend the following sentence --

ADD

The case expression given in parentheses
shall be evaluated exactly once and before
any of the case item expressions.

Audit-Trail
From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/402: 9.5, evaluation of case expression
Date: Tue, 29 Jul 2003 19:53:13 -0400 (EDT)

>Must a case expression be evaluated exactly once and before
>any of the case item expressions?

I believe that was the intent, though the text doesn't clearly
state this anywhere.

Steven Sharp
sharp@cadence.com


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/402: PROPOSAL - 9.5: evaluation of case expression
Date: Mon, 11 Aug 2003 18:41:00 -0400 (EDT)

The situation where XL appears to re-evaluate the case expression is quite
limited, and is due to a particular optimization. It only occurs if the
case expression is an identifier. If it contains any operators, even ones
that don't affect the value (e.g. {i}), then the expression only gets
evaluated once. Even implicit operations, such as extending the width
of the value to match a wider expression in one of the case item expressions,
will ensure it is only evaluated once.

It appears that this is an optimization that determines that the value of
the expression is identical to the value of the identifier, and uses the
value held in the identifier for the comparisons, to save making a copy.
Applying this optimization in this situation, where other expressions
will be evaluated and have side effects before this value is used, results
in the behavior are seeing. This behavior is not intentional, and should
be considered an obscure bug in XL.

If XL is run with all optimizations turned off, this does not happen. The
case expression is only evaluated once. Note that there are other situations
in which XL changes behavior at different optimization levels. In these
cases, turning off all optimizations gives the most consistent and "standard"
behavior.

So I think we can go ahead with the proposal.

Steven Sharp
sharp@cadence.com

Unformatted


Hosted by Boyd Technology