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

Gord,

I must say that I am very surprised and disappointed to read these
words.

If what you say is to be taken literally, then a giant fraud has been
perpetrated on the user community.

But I don't want to get into demagoguery.

Suppose we limit the discussion to code which is accepted by synthesis
tools. For example, my understanding is that most synthesis tools don't
allow hierarchic references except into instantiated generate blocks.

Synthesis tools ignore combinational sensitivity lists, don't they?
(Except to issue warnings about missing or extra signals. But they don't
use them when constructing the logic, do they?)

In what realistic cases is there a mismatch between synthesis and
simulation (again, while fulfilling all restrictions placed on us by
synthesis tools)?

Thanks,
Shalom

>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>Behalf Of Gordon Vreugdenhil
>Sent: Monday, December 12, 2005 5:23 PM
>To: sv-bc@eda.org
>Subject: 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