[sv-bc] Proposal for 997

Hi folks,

I've uploaded a proposal for 997 and added a substantial note with my 
extraction of the lengthy email thread from last year on the topic. 
There were an awful lot of issues raised in that thread; I've attempted 
to distill away everything except for the operator short-circuiting, 
since that's the most important issue and is in itself contentious enough.

--Mike

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



14 Nov 2007: Mantis 997: Mike's extraction of the terribly lengthy
email threads from Aug 2006.

There are many potential LRM problems identified in the 997 mail
thread; however, to keep things simple and passable my proposal will
only address one:

 * D4 11.3.5 "Operator expression short circuiting" currently allows
   but does not require short-ciruit evaluation (i.e., skipping
   evaluation of operands that don't affect the result of the
   operation). This causes semantic ambiguity when operand evaluation
   has side effects - it is not defined whether the side effects occur
   or not.

The essense of the proposed change is to require short-circuit
evaluation of the operands for the '&&' (logical AND), '||' (logical
OR), and '?:' (conditional) operators, and require strict evaluation
for the operands of all other operators, removing the current
optionality for all operators.

Note that implementations are free to optimize by skipping evaluation
of any operand as long as the simulation behaves as if the above rules
were followed.

Arguments for making a change:

* The current ambiguity stemming from optional short-circuiting allows
  for differing behavior between compliant implementations (see
  example at end).

* Any benefit gained from allowing implementations to choose will not
  be portable.

Arguments against making a change:

* There exists much carefully-crafted legacy code designed to coax
  desirable output from synthesis tools; requiring or prohibiting
  short-circuit evaluation could require changes in optimization that
  would have a detrimental effect on synthesis output.

Arguments for short-circuit evaluation of '&&', '||', and '?:':

* Many widely-used languages that use '&&', '||', and/or '?:' (e.g.,
  Vera, C, Unix shells, Perl) define them to be short-circuiting.

* Verilog-XL short-circuits these operators.

* Short-circuiting supports common programming idioms that are useful,
  particularly for avoiding runtime errors in testbenches. For
  example, "if (obj != null && obj.val > 0)" to avoid segfaulting on a
  null handle dereference.

* Short-circuiting cannot adversely affect synthesis or formal
  verification semantics since the proposed evalutation scheme is one
  of those already allowed today. The only affect is positive; it
  removes ambiguity.

Arguments for strict evaluation of '&&', '||', and '?:':

* Verilog is originally and primarily a hardware modelling langage,
  and hardware people expect the more static semantics of strict
  evaluation. Software people (some of whom happen to be on a certain
  committee) should be careful not to assume that hardware people
  share their intuitions and expectations - here, they don't.

* We should expect the synthesizable subset to grow over time; it's
  possible that some side-effect-containing code will become
  synthesizable in the future. The semantics of such code should
  follow hardware expectations.

Here is an example from Steven Sharp that I think is particularly good
for discussion (from http://www.eda-stds.org/sv-bc/hm/4985.html):

------------------------------

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.

------------------------------