Subject: always_comb semantics
From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Tue Oct 01 2002 - 13:23:32 PDT
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
This archive was generated by hypermail 2b28 : Tue Oct 01 2002 - 13:25:20 PDT