Subject: RE: always_comb semantics
From: Michael McNamara (mac@verisity.com)
Date: Wed Oct 02 2002 - 08:37:02 PDT
Gordon Vreugdenhil writes:
> The definition of correctness and the sensitivity lists for
> always_comb, always_ff, and always_latch needs some attention.
> The 3.0 LRM says (sect 9.2, in part):
> - There is an inferred sensitivity list that includes every
> variable read by the procedure
> - The variables written on the left-hand side may not be
> written by any other process
> - <triggering rules>
> ...
> - always_comb is sensitive to changes within the contents of
> a function....
>
> always_ff and always_latch are symmetric.
>
>
> So, here are some questions:
> 1) What is the granularity of the "variables written"? For
> example, if I have an array (or struct) and write to one
> part in one always_comb and another in a different
> always_comb, is that an error?
>
> ex: reg [7:0] m[10:1];
> always_comb m[1] = x;
> always_comb m[2] = y;
>
> 2) If a function writes to a variable, does that count as
> a write within the calling process?
>
> function f begin
> y = x;
> f = x;
> end
> endfunction
>
> always_comb m[1] = f();
> always_comb m[2] = f();
>
> Is the answer different when writing to local variables
> declared within a function? What if some other process
> writes into the function locals via a hierarchical name?
> Is there any difference between an auto function and a normal
> function?
>
> 3) Similar issues arise with RHS implied sensitivities.
> Formally speaking, one needs to include the function
> locals as hierarchically named dependencies since such
> locals can be modified via a hierarchical references.
>
>
> This seems to be more than a little unreasonable to me. The
> *intent* of always_comb, for example, is that it expresses
> combinational logic. The "LHS rule" is a baby step towards
> requiring combinational behavior, but it isn't nearly complete.
> There is no discussion of delays, side-effects, non-blocking
> assigns, write-after-read of variables, etc, etc.
>
> I think that we should either massively tighten up the rules
> to remove many of the ambiguities or get rid of the LHS
> rules completely, tighten up the senstivity list definition,
> and let that define the simulation behavior. Synthesis tools
> can do their own sanity checks.
>
> My suggestions are as follows:
> 1) remove the "unique writer" (LHS) rule
> 2) explicit state that function locals and formal arguments
> of functions are excluded from the implicit sensitivity
> list.
>
>
> Gord
> --
> ----------------------------------------------------------------------
> Gord Vreugdenhil gvreugde@synopsys.com
> Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054
> Synopsys Inc., Beaverton OR
>
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.
Note that always @(*) makes no restriction on other assignments to the
lhs variables, as you seem to prefer.
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 )
-mac
This archive was generated by hypermail 2b28 : Wed Oct 02 2002 - 08:43:52 PDT