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

>From: "Stuart Sutherland" <stuart@sutherland-hdl.com>

>I do NOT support making short circuiting mandatory...for any operator.  It
>is not hardware behavior, and Verilog is first and foremost a hardware
>modeling language.  

Actually Stu, if synthesis tools accept code that involves side-effects,
then any short-circuiting they apply is part of the hardware behavior.

You are thinking of purely combinational logic for the expression.  In
that case, it doesn't matter whether evaluation does short-circuiting.
It is just an invisible simulator optimization that has no effect on the
behavior.  It doesn't matter what the LRM says about it, or whether
the real hardware "evaluates"; a simulator is free to short-circuit
anyway.

What is relevant are the cases where short-circuiting affects the
actual behavior, because of side-effects from evaluation.  In these
cases, the expression is not equivalent to any combinational logic.
It may be equivalent to some sequential logic.  I had assumed that
synthesis tools would reject such expressions.  From what Karen said,
it sounds like they may accept them.  If so, then it is even more
important to get this defined in the LRM.

Let me provide an example that might make this clearer.  I will use
an increment operator for the side-effect.  If synthesis does not
accept these, you can substitute a function call that has the same
side-effect.  Karen implied that those might be accepted.  An increment
operator just makes the example easier to follow.

Consider the code

    if (b && state++)
    begin
      out = 0;
    end
  
With short-circuiting, this is equivalent to

    if (b)
    begin
      if (state)
        out = 0;
      state = state + 1;
    end
    
Without short-circuiting, this is equivalent to

    if (b && state)
    begin
      out = 0;
    end
    state = state + 1;
    
Both of these are synthesizable if they appear in an appropriate
context, and they have quite different behaviors.  In one case,
state always gets incremented, and in the other, state is incremented
only if b is true.  The hardware "implements" short-circuiting in the
original expression by only enabling the increment of state if b is
true.

This is an example of how short-circuiting can be a hardware behavior.
More importantly, it shows how you can get different hardware if
synthesis assumes short-circuiting than if it doesn't.

Karen suggested that synthesis should be free to assume whichever
one it wants.  If b is on the critical path, it can choose not to
use it to enable the increment.  If b isn't on the critical path,
the tool might choose to use it to enable the increment.  Karen
suggested that synthesis tools should be free to do this, to allow
them to give better timing or area.  I would suggest that synthesis
should NOT be free to do this, but should give you the hardware
that you intended.

You can complain that you would never write code like this.  But
if the tools allow it, it's because they think someone might use
it.  And if the LRM says it is undefined whether there is short-
circuiting, then the tools are free to give you unpredictable hardware.

Short-circuiting is not a property of software or of hardware.  It is
a property of the language semantics.  If you specify that it should
or should not occur, then the resulting language can be implemented
in software or in hardware.  If you specify that it is undefined, then
you can get different behaviors in different implementations.  The only
relation this has to software vs. hardware is that the situations where
short-circuiting is most desirable are ones that are not currently
synthesizable into hardware.

Steven Sharp
sharp@cadence.com