Subject: Re: always_comb semantics
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Oct 02 2002 - 17:50:41 PDT
> From owner-sv-bc@server.eda.org Wed Oct 2 16:55:29 2002
> From: "Gordon Vreugdenhil" <gvreugde@synopsys.com>
> Reply-to: gvreugde@synopsys.com
> X-Accept-Language: en
> To: "Steven Sharp" <sharp@cadence.com>
> cc: Gordon.Vreugdenhil@synopsys.com, mac@verisity.com, sv-bc@server.eda.org
> Subject: Re: always_comb semantics
>
> 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)
What are the restrictions on the functions that can be called?
Do they have to be static? local?
Kev.
> 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 - 17:51:47 PDT