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

What's the justification for only tightening these two particular
Verilog operators, && and ||?

There would still be nondeterminism for all of the other binary
operators in the presence of side-effecting operands, because the
evaluation order of their operands is not specified either.

In for a penny, in for a pound.  Why should the following be
nondeterministic when f and g have side-effects

      if ( (|f(a)) | (|g(a) )

but the following be deterministic

      if ( f(a) || g(a) )

? Why should the following reduce to if(1)

      if ( (|f(a)) | 1'b1 )

but not also the following reduce to if(1)

      if ( f(a) || 1'b1 )

? So far the only justification I've heard is that in C the && and ||
operators are lazy and left-to-right, and in C the & and | operators are
neither lazy nor left-to-right, and Verilog should be like C.  But
Verilog is not C.

There is already a Verilog way to guarantee lazy evaluation, namely, ?:.

-- Brad

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

IMHO, even more reason to get this tightened up in the LRM.
We need to strive for portability and consistency to maximize the health
of the language and the satisfaction of the users.

Regards,
Doug 

> -----Original Message-----
> From: owner-sv-bc@server.eda-stds.org 
> [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Brad Pierce
> Sent: Tuesday, August 15, 2006 4:40 PM
> To: sv-bc@server.eda-stds.org
> Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005]
> 
> According to
> 
>     http://www.eda-stds.org/sv-bc/hm/4942.html
> 
> there are still significant differences among common Verilog 
> simulators on these kinds of test cases.
> 
> -- 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
> > 
> > 
> > 
> 
>