Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005]

Recall that there is no evaluation order specified for the operands of
|| or any of the other binary Verilog operators.

In

   if ((f(x) || 1) || f(y))

the "(f(x) || 1)" can be legally short-circuited to "1", yielding

   if (1 || f(y))

which can in turn be legally short-circuited to

   if (1)

None of that violates associative evaluation order.

-- Brad


-----Original Message-----
From: Warmke, Doug [mailto:doug_warmke@mentor.com] 
Sent: Tuesday, August 15, 2006 4:19 PM
To: Brad Pierce; sv-bc@eda-stds.org
Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005]

I don't really agree with this reading.

I would make the case that you evaluate the operands following the
associativity rules.  Doing that, if a tool can stop early (i.e. by not
evaluating f(y)), then 5.1.4 allows the tool to do that.

Regardless of all this, isn't it of concern that default synthesis
results may mismatch the results of common simulators?
With my user hat on, I would prefer to see the LRM tightened down in
this regard so that I was guaranteed a match across simulators and
across synthesis results.

The synthesis tools could then provide optional switches to loosen up on
these rules, at the risk that results may not match simulation.  At
least the user has control that way.

Also, even without that switch, synthesis users are well trained in ways
of detailed coding that allow for best synthesis results.  In Karen's
earlier example, I would be inclined to try something like this to guide
synthesis:

    t = a || b || ...;
    if (t || f(x)) begin
        ...

Regards,
Doug


> -----Original Message-----
> From: owner-sv-bc@server.eda-stds.org
> 
> >All that optional short-circuiting allows you to do is stop early
> 
> According to 5.1.4
> 
>   "However, if the final result of an expression can be determined 
> early, the entire expression need not be evaluated."
> 
> The commonsense reading of that sentence says that
> 
>     "if (f(x) || 1 || f(y))"
> 
> can be optimized to
> 
>     "if (1)"
> 
> Evaluating f(x) is not required.  
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-bc@eda-stds.org [mailto:owner-sv-bc@eda-stds.org] On 
> Behalf Of Steven Sharp
> Sent: Tuesday, August 15, 2006 3:09 PM
> To: doug_warmke@mentor.com; sv-bc@eda-stds.org; 
> Karen.Pieper@synopsys.COM
> Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005]
> 
> 
> >From: "Karen Pieper" <Karen.Pieper@synopsys.com>
> 
> >I'm concerned about forcing side effects.
> >
> >For synthesis, users like the best quality of results, timing, area, 
> >etc.  In the case that someone codes:
> >
> >if (f(x) || 1 || f(y))
> >
> >being able to evaluate it as if (1) and just build the then
> clause can
> >reduce the critical path and the area in the design.
> 
> I am surprised that synthesis would allow such a construct if the 
> function has side-effects.  The behavior of the synthesized design 
> could be completely different from what was simulated.  I would think 
> users would consider that a bug in the tool.
> 
> At any rate, the LRM does not allow what you have described.  
> You cannot
> avoid evaluating f(x).  The LRM specifies that the expression 
> evaluation order follows the associativity rules.  That would be 
> left-to-right in this case.  So it requires you to evaluate f(x) 
> before the 1.
>  All that
> optional short-circuiting allows you to do is stop early, not 
> arbitrarily re-order.  So it is optional to evaluate f(y), but not 
> f(x).
> 
> If there are no side-effects in f(), then it doesn't matter, and you 
> can evaluate any way you like.  The results are equivalent.  But if 
> there are side-effects, then the results may not be equivalent.  Then 
> the correct behavior is the behavior you would get from evaluating 
> left-to-right, possibly short-circuiting.  Since synthesis would know 
> whether there were any side-effects, I would think that you would 
> error out in the presence of possible short-circuiting of those 
> side-effects.
> 
> 
> >  The problem also
> >shows up in a case like:
> >
> >If (a || b || .... || f(x))
> >
> >in the event that a is a critical path signal, then there
> are a lot of
> >ors that the signal will have to go through to prove that the side 
> >effects of f(x) can happen, putting that side effect now on the 
> >critical path.
> 
> I assume that you are saying that you could do the side-effects of 
> f(x) unconditionally, by assuming no short-circuiting.  That would 
> avoid making the side-effects conditional on the ORs of the previous 
> conditions.
> In this case, I agree that the current LRM allows this.
> 
> But the resulting logic may not match what the user expected when they

> wrote this code, and which they verified by simulation.
> Users may like
> better timing and area, but not if the circuit doesn't work.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
>