Subject: RE: always_comb semantics
From: Peter Flake (flake@co-design.com)
Date: Thu Oct 03 2002 - 13:52:06 PDT
Mac,
We thought hard about "inline" and concluded that it should only affect
performance, not functionality.
This particularly applies to an attribute. Also there is the issue of
recursive application of "inline".
Hierarchical references can be simulated in any always block, but not
synthesized.
The time 0 schedule is particularly important where all the inputs are
constant. Note that wire declarations have a similar property.
The always_latch indicates a design intent to have at least one latch. A
synthesis tool could produce an error if this were not so.
The always_ff indicates a design intent to have a single style of
flip-flops in synthesis. The generality of an always block is not allowed.
Peter
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?
>
> 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)
>
> Does not introduce special 'schedule at time 0, after all initial _and_
> other always blocks have run' semantics.
>
> >
> > Regards,
> >
> > Peter.
> >
> > At 08:37 AM 10/2/02 -0700, Michael McNamara 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.
> > >
> > >Note that always @(*) makes no restriction on other assignments to the
> > >lhs variables, as you seem to prefer.
> > >
> > >Always @(*) does suffer from the same ambiguity you cite with respect
> > >to
> > >
> > > reg [31:0] a,c,b[3:0];
> > > always @(*) begin
> > > a = b[c];
> > > end
> > >
> > > Should the sensitivity list be:
> > > @( b[c] )
> > > or
> > > @( b[0] b[1] or b[2] or b[3] or c )
> > >
> > >
> > >-mac
> > >
> > >
> > >
> >
> >
This archive was generated by hypermail 2b28 : Thu Oct 03 2002 - 15:03:21 PDT