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

Thought I'd throw in my 2 cents here...

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.  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.  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.

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.

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.

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com