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
> 
> 
>