Subject: Re: [sv-bc] Event controls in always_comb?
From: Dave Rich (David.Rich@synopsys.com)
Date: Fri Oct 10 2003 - 23:44:04 PDT
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.
Note that:
always_ff @(B) A=!B;
has legal simulation semantics, but clearly does not represent
sequential logic using today's traditional modeling styles.
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.
I think for the same reasons that always_comb allows event controls,
always_ff should allow more than one event control.
Dave
Steven Sharp wrote:
>The specification says in 9.4 that an always_ff block imposes the restriction
>that only one event control is allowed.
>
>However, 9.2 does not impose any restrictions on event controls in always_comb
>blocks (aside from allowing tools to warn if the behavior does not represent
>combinational logic, as it wouldn't if there were any event controls in it).
>Was this intentional or an oversight?
>
>Note that a blocking delay control in an always_comb block would also prevent
>it from properly modeling combinational logic, since it would not respond to
>its inputs while waiting at the delay control. The same is true of an
>always_ff.
>
>Steven Sharp
>sharp@cadence.com
>
>
>
>
-- -- David.Rich@Synopsys.com Technical Marketing Consultant http://www.SystemVerilog.org tele: 650-584-4026 cell: 510-589-2625
This archive was generated by hypermail 2b28 : Fri Oct 10 2003 - 23:46:43 PDT