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

This was snarfed by the majordomo.  I modified the offending
word.


>Subject: RE: [sv-bc] @* vs. always_comb
>Date: Tue, 13 Dec 2005 08:41:35 -0800
>From: "Mark Hartoog" <Mark.Hartoog@synopsys.com>
>To: "Gordon Vreugdenhil" <gordonv@model.com>
>Cc: "Bresticker, Shalom" <shalom.bresticker@intel.com>, 
><sv-bc@server.eda.org>
>
>One of the design problems with Verilog 95 was that all 
>sensitivity list[editor]s had to be manually created and that mistakes 
>could lead to simulation synthesis mis-matches. V2k attempted 
>to address this with always @*. Always @* produces an optimum 
>sensitivity list for the simple, most common cases, but it 
>does not look into functions or handle temporary variables optimally.
>
>Always_comb is an attempt to improve on always @* by including 
>functions and recognizing temporary variables. I think 
>always_comb is a significant improvement.
>I do not know of a case where an always_comb block which is 
>actually combinational will have a simulation/synthesis 
>mismatch. There are cases where the sensitivity list will be 
>sub-optimal, but the extra executions of a truly combinational 
>always block should not change the simulation result.
>
>> 
>> Gordon Vreugdenhil wrote:
>> > 
>> > 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.
>> 
>> <blush>
>> 
>> Bad example -- obviously that isn't an issue since if the logic is 
>> actually combinational, having additional simulation time 
>evaluations 
>> won't change the results.
>> 
>> It may indeed be that for combinational logic we may just have a 
>> superset of synthesized behavior accepted for simulation (i.e. that 
>> there are blocks that are simulatable using always_comb that aren't 
>> synthesizable) which is not really an issue.
>> 
>> Let me have a bit more coffee first...
>> 
>> Gord.
>> 
>> --
>> --------------------------------------------------------------------
>> Gordon Vreugdenhil                                503-685-0808
>> Model Technology (Mentor Graphics)                gordonv@model.com
>> 
>
>