Subject: RE: always_comb semantics
From: Michael McNamara (mac@verisity.com)
Date: Thu Oct 03 2002 - 09:18:35 PDT
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 - 09:22:22 PDT