Subject: RE: always_comb semantics
From: Michael McNamara (mac@verisity.com)
Date: Thu Oct 03 2002 - 10:11:18 PDT
Karen Pieper writes:
> At 09:18 AM 10/3/02 -0700, Michael McNamara wrote:
>
>
> >Peter Flake writes:
> > > Mac,
> > >
> > > The differences between always_comb and always @* are:
> > > Functions in always_comb participate in the sensitivity list
> > > calculation
> > > Time 0 evaluation is guaranteed.
> > >
> > > These differences make the simulation of combinational logic more
> > accurate,
> > > reducing pre/post synthesis mismatch.
> > >
> > > Kevin, the functions do not have to be static or local, but a synthesis
> > > tool may impose these restrictions.
> >
> >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.
> >
> >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?
>
> Functions are effectively inlined by synthesis, so the variables
> used are added to the sensitivity list. This includes both
> function local (but not automatic) variables and module-level
> variables. Synthesis traditionally does not support hierarchical
> reference because heirarchical reference effectively adds implicit
> ports to a design which is a mess to get to work through all of the
> backend tools and formal verification tools.
This says that to be useful as a 'What I See In Simulation Is What I
Get From Synthesis' (WISISIWIGFS) feature, then the always @(*) /
always_comb, et cetera should NOT add hierarchical references to the
sensitivity list.
Do folks Agree? Disagree? IMHO, if we are doing this, we should do it
right.
> > 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:
> >
> > function [31:0] f (input [31:0] in) begin
> > f = in * top.factor
> > endfunction
> >
> > always @(*) begin
> > a = (*inline *) f(b,c);
> > end
> >
> > always @(*) begin
> > a = inline f(b);
> > end
> >
> > would map to
> >
> > always @(b,top.factor) begin
> > a = b * top.factor;
> > end
> >
> > always @(b,top.factor) begin
> > a = b * top.factor;
> > end
> >
> >Advantages of this are:
> >
> > 1) no change of behaviour of existing 1364-2001 code
> >
> > 2) use of inline will be unsurprizing to most people; their first
> > guess about what this means will be correct.
> >
> > 3) avoids introduction of extremely similar construct to one that
> > already exists.
> >
> >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)
>
> Flip-flops and latches are inferred from always blocks. In order
> for a latch to be inferred, the @() list in the block must have no
> edge sensitive logic. Any variable that is not completely defined
> on every path through the always block will become a latch.
> Flip-flops are inferred for variables that are not fully defined
> where the @() expression has edge sensitive logic in it.
So, would a synthesis tool use different rules than the above to
process an 'always', 'always_ff', or 'always_latch' block in System
Verilog; or would it treat all of them as it today treats an always
block? If it is the later, then I again question why we are using up
keywords.
>
> Karen
>
>
>
This archive was generated by hypermail 2b28 : Thu Oct 03 2002 - 10:14:08 PDT