Subject: Re: always_comb semantics
From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Wed Oct 02 2002 - 20:03:03 PDT
Kevin Cameron x3251 wrote:
>
...
> > 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?
Per the LRM, there are none. The expectation is that functions
have to represent synthesizable code. Karen could expand
further on that. I don't really want to embed all the
synthesis rules in SystemVerilog; that strikes me as being
unreasonable. However, as long as we give the right behavior
on synthesizable code and **well defined** behavior elsewhere,
I think that is acceptable and in this context is very
worthwhile. That is why I made the proposal I did and why
I don't know about things like function locals; I don't
know if ignoring them would correspond to synthesized
behavior (I think it would). Karen??
Oh, btw, I forgot that there is also the triggering rule that
also differentiates this from @* -- always_comb et al trigger
once automatically at the end of time 0 (after all initial and
always blocks).
Gord.
> 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
-- ---------------------------------------------------------------------- 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 - 20:23:09 PDT