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

The following sv-bc mail from Mark hit reflector trouble --

-----Original Message-----

From: "Mark Hartoog" <Mark.Hartoog@synopsys.com>

One of the design problems with Verilog 95 was that all sensitivity
lists 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
>