Subject: Re: always_comb semantics
From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Thu Oct 03 2002 - 09:39:48 PDT
Michael McNamara wrote:
>
> This is a scary addition. What we are doing is essentially directing
> the simulator to inline the function, and proceed as if the code had
> been typed inline.
That is a possible implementation but certainly not the only one.
The direction is to compute the the sensitivities *as though* the
function had been inlined. That may have considerably different
impact in terms of a specific implementation.
> Some of the reasons this addition is scary include
>
> 1) hierarchical references on the rhs of expressions out of a
> function that is called by an always_comb block. Are these added
> to the sensitivity list? Karen, would they be added by the
> synthsis tool?
Per the LRM, such hierarchical references would be added. If that
isn't synthesizable, this would be a case of defining "reasonable behavior
for the non-synthesizable constructs". You can get very fun cases
if you start looking at calls to (non-local) hierarchically named
functions. Then any reference from the function to vars in its
enclosing module have to be converted to hierarchical names in the
calling context. That occurs independent of whether you would
actually inline or not.
> 2) functions calling functions requiring much analysis.
>
> I believe an alternative way to achieve the inclusion of the body of
> function in the always @(*) construct would be to instead have System
> Verilog propose the addition of an 'inline' attribute, or if desired,
> a keyword, loosly as follows:
It would have to be a keyword since attributes, by definition,
may be ignored by an implementation. If we are going to have
required semantics, we need a new form.
I am not opposed to going the "inline" route but would have
a few questions about the rules:
1) are void functions permitted to be inline?
2) is inline a directive or a suggestion?
3) can you have an inlined recursive function?
4) can you have hierarchical references in an inlined function?
5) can inlined functions also be constant functions (used
during elaboration)?
....
> Advantages of this are:
>
> 1) no change of behaviour of existing 1364-2001 code
Same is true for always_{comb,ff,latch}
> 2) use of inline will be unsurprizing to most people; their first
> guess about what this means will be correct.
Probably true, depending on the answers to my questions above.
> 3) avoids introduction of extremely similar construct to one that
> already exists.
Agreed.
> Disadvantages:
>
> Does not introduce always_ff and always_latch features (I admit that
> I do not understand what these are, and how they differ from
> always_comb)
From a simulation perspective they are no different (except for possible
exposing optimization hints). From a synthesis perspective, they state
that the user expects the resulting code to be synthesized into a
flip flop or latch.
From a non-synthesis perspective, the three forms are redundant and
could be replaced by a single form as I suggested in an earlier
email:
always_synth (* isCombinational *) begin ..... end
The "always_synth" gives the same simulation semantics as the
current always_{combo,ff,latch} and the attribute -- which should
be defined by the synthesis group, not us -- says what the
expected synthesized construct would be.
From a pure language perspective, this is less redundant and much
more clean. From a designer's perspective, I might prefer the
3 direct forms.
> Does not introduce special 'schedule at time 0, after all initial _and_
> other always blocks have run' semantics.
I think this is an issue in terms of correlating simulation behavior
to synthesized code but can't answer authoritatively on that.
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 : Thu Oct 03 2002 - 09:41:33 PDT