Subject: Re: always_comb semantics
From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Wed Oct 02 2002 - 16:40:42 PDT
Steven Sharp 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.
>
> Yep, I was planning on bringing up the same issue myself. This appears
> to be parallel development of the same basic capability. The IEEE has
> already standardized its solution. It's a little late for alternative
> proposals.
>
> >Note that always @(*) makes no restriction on other assignments to the
> >lhs variables, as you seem to prefer.
>
> This aspect of always_comb (and the other always_* constructs) is
> effectively covered in IEEE 1364-2001 by the availability of attributes
> for synthesis. This allows synthesis lint checking of this kind. It
> also has the advantage of being more extensible and malleable as synthesis
> tools and their restrictions change.
Except that the simulation semantics change!
always_comb (for example) and @* do not give the same results
if there is a function call in the block.
Example:
reg x,y;
function f() return x; endfunction
always_comb z = y | f(); // sensitive to (x or y)
always @* z = y | f(); // sensitive to (y)
If we do this only via attributes, are we going to *require* that
simulators respect the meaning of an attribute? Are you really
proposing that or are you saying that we should ignore this
completely? SystemVerilog 3.0 explicitly discusses the difference
since @* wasn't sufficient for real designs (in terms of simulation
semantics). If we drop the other forms, we end up going back
to requiring the users to have explicit sensitivity lists in
cases like that. Since the motivation for @* was to reduce
the errors that result from explicit lists, it seems that we
ought to address this in some manner. I'm assuming that no
one wants to suggest changing @* (I don't).
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 - 16:54:52 PDT