Subject: Re: always_comb semantics
From: Michael McNamara (mac@verisity.com)
Date: Wed Oct 02 2002 - 14:10:41 PDT
Gordon Vreugdenhil writes:
> 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.
OK, well basically my point is to question whether it is valuable to
anyone (except perhaps to Verilog training vendors) have two very
similar constructs, neither which appear to be exactly what anyone
wants; as opposed to fixing one of them to be 'right', and going with
that. IMHO, simplicity is a huge virtue here.
Does anyone see value in having 4 semi automatic sensitivity
procedural statements?
> 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.
Correct me if I am wrong here, but it is my understanding that
synthesis tools indeed do inline the function calls, and make the
process sensitive to all the right hand sides. Presumably this is
why always_comb was specified as it is.
> 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.
>
There is a difference, and it is one where the SV form is weaker, as
basically with the always_* form one cannot naturally implement gated
clock designs, whereas with the 1364-2001 form, one can.
>
> > 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.... :-)
And this indeed is what we are creating; so focusing on can we clearly
articulate the rules is very much of front and center importance.
> > 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).
I ask the group: what would a synthesis tool build given
reg [31:0] a,c,b[3:0];
always @( /* contents of sensitivity list is ignored */ ) begin
a = b[c];
end
> 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 - 14:12:55 PDT