From
both a SystemVerilog and SVA user and an SVA instructor
point of view…
Adding
the clock event to the sensitivity list of an always_comb
would be a likely source of simulation and synthesis and
real hardware mismatches. It is a horrible idea. The goal
when always_comb was added to the language – in the days of
Superlog, long before Verilog++ or SystemVerilog, and long
before the AC committee got involved with the language – was
to make simulation and synthesis as closely aligned as
reasonable.
Please
do no mangle the rules of always_comb for purposes that are
not in line with the intent of the construct!
If
you need to add special rules for concurrent assertion
behavior in an always_comb block, specify those rules on the
assert property statement, not on always_comb. For example,
you could define rules that an assert property in any type
of always block will run as a parallel background task with
its own sensitivity list, where perhaps __some__ of the
assertion’s sensitivity was inferred from the always
procedure context but is totally independent of the always
procedure sensitivity list.
I
am copying Cliff Cummings and Don Mills on this message, two
former SV committee members and engineers with a good
understanding of the purpose of always_comb, always_latch,
and always_ff and why we wanted them in SystemVerilog. I
hope they will respond and let me know if I am off base on
my adamant opposition to concurrent assertions affecting the
inferred sensitivity list.
Hi
Ben,
Your
example does not agree with the position of Ed, Anupam and
Manisha.
IMO
a procedural concurrent assertion should be evaluated at
each clock tick when its enabling condition is active. In
Ben’s example I would expect that the new attempt of b
|=> d is checked each time when its enabling condition a
is asserted. Therefore, if a is always 1 this assertion
should be equivalent to assert property(@ (posedge clk)
b|=> d);
If
we adopt the opposite point of view that the clocking event
of the concurrent assertion does not belong to the
sensitivity list then we will have the embedded assertion
roughly equivalent to:
assert
property(@ (posedge clk) $rose(a) |-> b|=> d);
which
does not seem to be very useful.
Inserting
the clocking event into the sensitivity list of the
procedure should not be very expensive in simulation. The
simulator may cache the latest value of the context of the
concurrent assertion and not to reevaluate the entire
procedure on the rising edge of the clock, i.e. actually not
to include the clocking event into the sensitivity list.
Thanks,
Dmitry
From:
ben cohen [mailto:hdlcohen@gmail.com]
Sent: Wednesday, September 21, 2011 20:13
To: Eduard Cerny
Cc: Seligman, Erik; Korchemny, Dmitry;
sv-ac@eda-stds.org
Subject: Re: [sv-ac] RE: Call to vote: Due September
26
I
agree with Ed and Anupa. Below is code that I tested with a
simulator. In the always_comb, I have:
ap_conc: assert property(@ (posedge clk) b|=>
d) else $display("ap_coc error");
The
simulator behaved as the following
ap_conc_equivalent:
assert property(@ (posedge clk) if(a) b|=>
d) else $display("ap_coc error");
logic clk=0, a=0, b=1, c=1, d=0, e=0;
initial forever #10 clk=!clk;
// always @ (posedge clk) b <= !b;
ap: assert (a != e) else $display("ap error");
ap_conc: assert property(@ (posedge clk)
b|=> d) else $display("ap_coc error");
On Wed, Sep 21, 2011 at 8:46 AM,
Eduard Cerny <Eduard.Cerny@synopsys.com>
wrote:
I am also a little confused
what we are voting on, 2093 or 3564. Regarding
3564, my thought is as follows:
for immediate, deferred and
final assertions, only variables in the condition
of the assertion should contribute to the
sensitivity list, not those appearing in the
action blocks. For concurrent assertions, IMHO
they should not contribute in any way to the
sensitivity list. An attempt is enabled when
control reaches the location of the assertion in
the always_comb procedure and then they run
totally independently of the always, on their own
clock. None of the variables in the assertion has
anything to do with the actual evaluation of the
always_comb.
Best regards,
ed
I assume we’re really
voting on 3564, not 2093?
I vote NO on 3564.
Reasoning: The current proposal explicitly
states that expressions in concurrent
assertions do not wake up the always_comb,
but I don’t believe this is a correct
solution. As an RTL author, I would want
the always_comb to wake up at some point
soon after any changes to the sampled
expression, as well as any time a const’
expression changes.
Since we agreed that
more time is needed for a clean definition
of behavior under concurrent assertions, we
should just talk about immediate assertions
in this proposal, and leave the concurrent
case undefined (which we will fix in the
next PAR). So I would rewrite the
proposal as:
Expressions
used in immediate assertions (see 16.3),
within the block or within any function
called within the block, also contribute to
the implicit sensitivity list of an always_comb. In the example
below, the always_comb shall trigger
whenever b,c or e change.
always_comb
begin
a
= b & c;
assert
(a
!= e);
end
-You have until 11:59 pm PDT, Monday,
September 26, 2011 to respond
-An issue passes if there are zero NO votes
and half of the eligible voters respond with a
YES vote.
-If you vote NO on any issue, your vote must
be accompanied by a reason.
The issue will then be up for discussion
during a future conference call.
As of the September 20, 2011 meeting, the
eligible voters are
Ashok Bhatt
Eduard Cerny
Ben Cohen
Dana Fisman
Tapan Kapoor
Jacob Katz
Scott Little
Manisha Kulshrestha
Anupam Prabhakar
Erik Seligman
Samik Sengupta
Tom Thatcher
Mantis 2093 ____ Yes ____ No
http://www.eda-stds.org/mantis/view.php?id=3564
http://www.eda-stds.org/mantis/file_download.php?file_id=5462&type=bug
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain
confidential material for
the sole use of the intended recipient(s).
Any review or distribution
by others is strictly prohibited. If you are
not the intended
recipient, please contact the sender and
delete all copies.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and
is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and
is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential
material for
the sole use of the intended recipient(s). Any review or
distribution
by others is strictly prohibited. If you are not the
intended
recipient, please contact the sender and delete all copies.
--
This message has been scanned for viruses and
dangerous content by MailScanner,
and is
believed to be clean.