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

Bresticker, Shalom wrote:

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

I don't understand why you think there was anything deceptive
here.  There was definite discussion in committee about wanting
combinational blocks to match synthesis behavior (not any particular
synthesis result of course which is why you can't precisely
define a set of rules).  Or did you mean that you believed that
the LRM rules precisely match synthesis rules?

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

That is roughly my understanding.  Karen may be able to provide more
detail.

> 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)?


I don't know how much detail I can talk about here.  But in general,
if you consider the static prefix rules, the LRM requires you to
be sensitive to *all* subelements (the expansion) of a prefix.  The
determination of the prefix depends on the LRM definition of
constantness.  If there are things that synthesis might treat as
constant that fall outside the LRM definition, then the synthesis
results (the actual topology) would not include connectivity that the
simulation would be sensitive to.  This can cause simulation/synthesis
mismatches.

Gord.


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

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