[sv-bc] 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.

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
...

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.