RE: [sv-bc] Proposal on striking the 2 paragraphs

Dave Rich wrote:
>The LRM has been clear from day one that
>the ordering of always and initial blocks is not deterministic. 
>
>There should be no semantic difference between
>
>always block_of_code;
>
>and
>
>initial forever block_of_code
>
>They both create concurrent threads of execution and the only difference
>between the two is that the always construct can never be disabled
>(die). If you want thread ordering, you should be using an explicit
>construct like an event control to control the ordering.

Currently there is no semantic difference between these two things.
However, I don't see any strong reason why they "should" remain
the same.  It is convenient for explaining what an always block means,
but that isn't much of an argument if there are good reasons for
making them different.

The fact is that users use them for different things.  Synthesis tools
certainly treat them differently.  Some simulator tools treat them
differently, within the flexibility allowed.  They take advantage of
knowledge of how each is generally used, to optimize better or to give
users the results they expect.

Anyone who claims that SystemVerilog initializer ordering is backward
compatible with Verilog, because it is a legal ordering for Verilog,
cannot argue that requiring always blocks to execute before initial
blocks is not backward compatible with Verilog.  It is an allowed
ordering in Verilog.  And it would actually make combinational always
blocks work as desired, unlike the SystemVerilog initializer rules
which force simulators to make them *not* work.

>Basically, if you are using SystemVerilog, you should not be using
>always. You should be using one of always_comb, always_latch, or
>always_ff

Plenty of legacy Verilog code that worked in Verilog simulators is
going to be compiled under SystemVerilog, and expected to work.  But
the restrictions in SystemVerilog will ensure that it doesn't work.
That is the definition of backward incompatibility that really
matters to users.

Steven Sharp
sharp@cadence.com