Subject: Re: always_comb semantics
From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Wed Oct 02 2002 - 13:00:31 PDT
Michael McNamara wrote:
[...]
> Further, always_comb appears to be a simultaneous invention with
> 1364-2001's always @(*) construct, and we (SV-BC) should consider
> dropping the System Verilog addition in favor of the existing always
> @(*) which is an IEEE standard.
I disagree.
always_comb (et al) have different semantics under simulation
since they include sensitivities on items read in the body of functions
called from the block. Although we need to clarify exactly what to
include there, it is an important distinction in terms of how to correctly
handle synthesizable code with function calls.
In addition, an always_{comb,ff,latch} form is a *process*
form, not an event form. The implication is that you cannot
have these in the middle of a sequential block as you can
with an @* sensitivity. This is an important structural
difference.
> Note that always @(*) makes no restriction on other assignments to the
> lhs variables, as you seem to prefer.
The only reason that I prefer that is that it would be too
painful to describe all of the restrictions that we'd need
for the synthesizable form. I'd go along with "it's valid if
DC can synthesize it into combinational logic" but others might
oppose that wording in an IEEE standard.... :-)
> Always @(*) does suffer from the same ambiguity you cite with respect
> to
>
> reg [31:0] a,c,b[3:0];
> always @(*) begin
> a = b[c];
> end
>
> Should the sensitivity list be:
> @( b[c] )
> or
> @( b[0] b[1] or b[2] or b[3] or c )
Absolutely. There was a rather protracted discussion in the
V2K ETF on exactly this. The "summary position" was essentially
that you must use the expanded form. I'm not arguing that half;
my question was on the symmetric question if we keep the LHS
rule. If that gets thrown out (as I suggest) then we are back
to the same form of sensitivity list as @* except that we include
functions. Then the only questions (as far as I am concerned)
are whether locals, etc. are in the list or not (I'd prefer not).
Note that the SystemVerilog LRM does note that the forms **may**
be used by tools to determine correctness of intent. This could
also be done via an attribute with something like:
always (* isCombinational *) @(*) begin....
but we would then be *requiring* simulators to understand
(* isCombinational *) in order to know to look into the functions
for sensitivities. That would be a bad precedent. So, I think
we do need to have at least one new structural form. I wouldn't
be too opposed to something like:
always_synth (* isCombinational *) begin....
to reflect that this is a special "synthesizable" always form but
that doesn't really express intent as well as the 3 current forms.
Gord.
-- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2b28 : Wed Oct 02 2002 - 13:13:10 PDT