Re: [sv-bc] @* vs. always_comb

>From: Gordon Vreugdenhil <gordonv@model.com>

>always_comb has had conceptual problems from the start -- it
>was intended to mean "yield the same results as would be
>produced by synthesis for combinational logic".  This is
>inherently ill-defined since synthesis tools are vendor
>specific and the exact rules are not fixed in stone nor
>should they be.

There is no need for dependence on the exact synthesis rules.  It
is the job of the synthesis tool to produce logic that matches the
simulation behavior, for those constructs that it accepts.  The
definition of always_comb just has to be general enough that it
covers everything that synthesis could possibly accept.

If it produces sensitivity that is a superset of everything that
the block could ever read, then it is guaranteed to handle all
possible valid synthesis, no matter what constructs synthesis
eventually handles.


>  As one example, synthesis does not handle
>hierarchical references well (or at all).  Originally the
>always_comb definition took that into account.  This became
>so ugly that regularity was reimposed by allowing hierarchical
>sensitivities even through a hierarchically called function.
>The cost of this is significant in terms of both conceptual
>complexity and speed of simulation.

This is unfortunate, but necessary if you want to handle everything
that synthesis could ever accept.  One way to avoid this would be
to make hierarchical calls to functions illegal in always_comb
blocks.


>  The static prefix rules,
>while ugly (I helped write them so I can say that with a grin),
>are an attempt to approximate synthesis results in a static
>manner.  They are certainly not completely in tune with synthesis.

But there is no need to exactly match anything in synthesis.  All
that is required is that the approximation be conservative, so that
it produces a superset of the actual sensitivity.  That is all that
the static prefix rules manage to do.  And there are more practical
rules that can do so.


>Synthesis generally takes approaches that are not amenable
>to a simple description in the LRM.  So in terms of the LRM
>we can then follow several approaches including:
>   1) Remove always_comb and the like.  Vendors can use @* and
>      attributes to direct special analysis for combinational
>      constructs which could modify sensitivity lists.
>   2) Retain the current always_comb rules.  Vendors can
>      still issue additional warnings but are required to follow
>      the senstivity definitions in the LRM
>   3) Refine the current rules to be more closely aligned
>      with synthesizable constructs
>
>(3) is problematic since synthesis rules can change as analysis
>approaches improve.  (1) is likely to be objectionable to
>the user community since code would not be portable across
>implementations.  (2) is also bad since it isn't really
>completely compliant with synthesis and some aspects of it
>(second order hierarchical sensitivities) can pose simulation
>performance issues.

(2) does not have to exactly match synthesis, as noted above.  It just
needs to be conservative enough to give correct results.  And that does
not require the exact sensitivity definitions that are in the current
LRM.  There are other possible rules that avoid some of the simulation
performance issues (though not the hierarchical function call one).
The LRM could also allow implementations more flexibility in what rules
they want to use, as long as they are conservative enough to ensure
correct behavior for combinational logic.


>Which is least worst?  I don't have a strong opinion, but my
>weak opinion is that always_comb has likely become weak enough
>in terms of compliance to synthesis behavior and complex enough
>in terms of simulation analysis, that it is not at all clear
>to me that it is worth keeping.

I think that you are going overboard here.  As already noted, there
is no need to exactly match the synthesis algorithm in order to match
the synthesis behavior.  And there are ways to address some of the
issues with simulation analysis.


Steven Sharp
sharp@cadence.com