Subject: Re: [sv-bc] Event controls in always_comb?
From: Peter Flake (Peter.Flake@synopsys.com)
Date: Mon Oct 13 2003 - 04:28:24 PDT
Dave,
At 23:44 10/10/2003 -0700, Dave Rich wrote:
>Steven,
>
>I think it was done to keep the semantics simpler, leaving the check up to
>the tool's own concept of what "combinational" means. I have seen the
>lengthy discussion on the ETF about @*
>(http://boydtechinc.com/btf/report/full_pr/84.html). My personal opinion
>is that the language should not decide what is combinational or
>sequential, that is a style issue. Besides, I see value in adding event
>controls for debugging and higher level modeling.
My personal opinion is different. The whole point of always_comb is that
the language expresses the user decision that it is combinational.
Any form of blocking goes against this, as Steven has pointed out. The
issue as I see it is: warning or error.
>Note that:
>
>always_ff @(B) A=!B;
>
>has legal simulation semantics, but clearly does not represent sequential
>logic using today's traditional modeling styles.
I think this should cause a warning or error, as a clock cannot be inferred.
>Now that you bring it up, I would say that we need to relax the
>restriction on the always_ff block to say at *least* one event control because
>
>always_ff begin @(posedge clk) A <= B; @(posedge clk) A <= C; end
>
>also represents sequential logic.
>
>Looking at the original Superlog donation, it said "The*'always_ff*'
>keyword imposes the restrictions that only one kind of event can be used
>in event expressions and that variables written may not be written by any
>other process." This meant that you could have multiple event controls,
>but they had to be identical as in the example above. I think the original
>SV3.0 committee cut this back to allowing only one event control because
>they thought it would be too difficult to enforce.
Yes, static analysis for equality can be difficult, and the implicit state
machine style in your example is not widely used. A synthesis or property
checking tool should be able to infer a clock (and an asynchronous reset)
from an always_ff.
Peter.
This archive was generated by hypermail 2b28 : Mon Oct 13 2003 - 04:36:21 PDT