Hi Dmitry,
Please see my comments below.
Anupam
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Sunday, September 25, 2011 12:16 PM
To: Prabhakar, Anupam; Steven Sharp; sv-ac@eda.org; sv-bc@eda.org
Cc: stuart@sutherland-hdl.com; Cliff Cummings; mills@lcdm-eng.com; Seligman, Erik
Subject: RE: [sv-ac] RE: Call to vote: Due September 26
Hi Anupam,
Please, ignore my previous answer to this mail, I missed the point that you were talking about immediate assertions and sent an answer about concurrent ones.
One simple example is the definition of a standalone deferred assertion: an immediate assertion incorporated into an always_comb block. Had always_comb been non-sensitive to the assertion expression, this definition would be meaningless.
AP : I think this definition can simply be re-worded without any change in functionality.
Another example is the case when an embedded assertion depends on some external signal that may change independently. E.g.,
always_comb begin
if (a) begin
for (int i = 0; i < 8: i++) begin
en[i] = ...;
assert #0 (en[i] -> x[i]); // x is assigned in a different process; This assertion should be checked also when x changes
AP : Even if we make always_comb sensitive to 'x' the assert is still gated by 'a'. Would you also put another assert #0 (en[i] -> x[i]) in the process that assigns 'x' ? For such dependencies it might be best to keep the deferred assert outside the processes which assign 'en' and 'x', especially since the LRM does not limit writing a deferred only in procedural blocks. In any case what I was looking for was an example where not including the immediate assert expression causes undesired behavior other than evaluation of the assertion itself.
...
Thanks,
Dmitry
From: Prabhakar, Anupam [mailto:anupam_prabhakar@mentor.com]
Sent: Saturday, September 24, 2011 07:34
To: Steven Sharp; sv-ac@eda.org; sv-bc@eda.org
Cc: stuart@sutherland-hdl.com; Cliff Cummings; mills@lcdm-eng.com; Korchemny, Dmitry; Seligman, Erik
Subject: RE: [sv-ac] RE: Call to vote: Due September 26
One reasoning to not add the expression in an immediate assertion to always_comb sensitivity is that an assertion should be considered as an observer (rather than a contributor. At the same time the result of an always_comb should not depend on whether immediate assertion expression participates on not - except in some weird cases (like the example I wrote in mantis 3564). I would be interested to see a case where not including immediate assertion expression can lead to undesired behavior - maybe Dmitry/Eric can provide one.
Anupam
From: Steven Sharp [mailto:sharp@cadence.com]
Sent: Friday, September 23, 2011 5:33 PM
To: Prabhakar, Anupam; sv-ac@eda.org; sv-bc@eda.org
Subject: RE: [sv-ac] RE: Call to vote: Due September 26
If I understand procedural concurrent assertions correctly, the always_comb doesn't evaluate them, but rather launches a concurrent subprocess that goes off and check them. As a result, I would not expect them to add anything to the sensitivity of the always_comb. If fork..join_none were allowed in always_comb, I would expect the same thing for any subprocesses that it launched. Or taking the example of fork..join_none, perhaps concurrent assertions should be illegal in always_comb. I don't see what reasonable purpose they serve there, and I suspect that they would lead to other problems besides the issue of the sensitivity list.
However, I disagree with Stu about immediate assertions. These are evaluated by the always_comb process itself. They are equivalent to an if-statement that produces an error and/or executes some code if the condition is not met. If such a construct were coded directly, it would add to the sensitivity list, so why shouldn't the immediate assertion? Stu has acknowledged that not adding it to the sensitivity list would create a problem, for which he suggests that a cautionary note would be adequate. However, he has not pointed out any situation where adding it to the sensitivity list creates a problem. This might cause extra evaluations which serve only to check the immediate assertion without any possibility of changing an output, but this doesn't appear to cause any problem other than some simulation cost. I don't see how this could lead to mismatches between RTL simulation and synthesized hardware (for things other than the assertions themselves, which are not synthesizable).
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Prabhakar, Anupam
Sent: Friday, September 23, 2011 5:46 PM
To: sv-ac@eda.org; sv-bc@eda.org
Subject: [sv-bc] FW: [sv-ac] RE: Call to vote: Due September 26
Including SV-BC for a wider audience ....
-----------------------------------------------------------------------------------------------------------------
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Stuart Sutherland
Sent: Friday, September 23, 2011 2:26 PM
To: 'Samik Sengupta'; 'Seligman, Erik'; sv-ac@eda-stds.org
Cc: Cliff Cummings; mills@lcdm-eng.com
Subject: RE: [sv-ac] RE: Call to vote: Due September 26 (resend with the correct Mantis number)
In my opinion, even adding the condition(s) of an immediate assertion to the always_comb (or always_latch) sensistivity list is a BAD IDEA! It will force engineers to go back to the old days of having to deal with simulation and synthesis seeing very different things in the same block of code, and will lead to mismatches in RTL simulation and synthesized hardware. It is nasty, dangerous, and can risk expensive re-spins of a chip. Don't mess with the rules of inferred sensivity!!!!
I would much rather see a rule in the standard that any type of assertion in always_comb and always_latch does not affect the inferred sensitivity list in any way. A cautionary note would be appropriate that if the immediate assertion reads an expression that are not read elsewhere in the procedure, the immediate assertion will not be evaluated when that expression changes value.
Again, I am copying Cliff and Don, in case fellow real designers think I am off base.
Stu
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Stuart Sutherland
Sent: Friday, September 23, 2011 2:10 PM
To: sv-ac@eda-stds.org
Cc: Cliff Cummings; mills@lcdm-eng.com
Subject: RE: [sv-ac] RE: Call to vote: Due September 26
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.
Stu
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
www.sutherland-hdl.com<http://www.sutherland-hdl.com>
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Friday, September 23, 2011 4:27 AM
To: ben@systemverilog.us; Eduard Cerny
Cc: Seligman, Erik; sv-ac@eda-stds.org
Subject: RE: [sv-ac] RE: Call to vote: Due September 26
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 Anupam. Below is code that I tested with a simulator. In the always_comb, I have:
if(a)
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");
module test_abcde;
logic clk=0, a=0, b=1, c=1, d=0, e=0;
initial forever #10 clk=!clk;
// always @ (posedge clk) b <= !b;
initial begin
#2 e=1'b1;
#3 e=1'b0;
#7 e=1'b1;
#23 b=1'b0;
#40 b=1'b1;
#27 c=1'b0;
end
always_comb
begin
a = b & c;
ap: assert (a != e) else $display("ap error");
if(a)
ap_conc: assert property(@ (posedge clk) b|=> d) else $display("ap_coc error");
end
endmodule
Ben Cohen
On Wed, Sep 21, 2011 at 8:46 AM, Eduard Cerny <Eduard.Cerny@synopsys.com<mailto: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
From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org>] On Behalf Of Seligman, Erik
Sent: Wednesday, September 21, 2011 11:34 AM
To: Korchemny, Dmitry; sv-ac@eda-stds.org<mailto:sv-ac@eda-stds.org>
Subject: [sv-ac] RE: Call to vote: Due September 26
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
From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org>] On Behalf Of Korchemny, Dmitry
Sent: Tuesday, September 20, 2011 11:55 PM
To: sv-ac@eda-stds.org<mailto:sv-ac@eda-stds.org>
Subject: [sv-ac] Call to vote: Due September 26
-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/view.php?id=2093%20>
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<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, 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<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, 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.Received on Sun, 25 Sep 2011 20:45:12 +0000
This archive was generated by hypermail 2.1.8 : Sun Sep 25 2011 - 13:46:12 PDT