Subject: RE: always_comb semantics
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Thu Oct 03 2002 - 09:56:18 PDT
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.
> 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.
Karen
This archive was generated by hypermail 2b28 : Thu Oct 03 2002 - 09:57:05 PDT