RE: [sv-ac] RE: Call to vote: Due September 26 (resend with the correct Mantis number)

Hi Cliff,

I agree with your point. Note, however, that it is possible to limit performance degradation because of inclusion of a clock into the sensitivity list as I suggested in my previous mail.

As for the assertion writing methodologies is concerned, they may be different. For example, we do embed concurrent assertions into RTL. Also, I don't see a difference for Makefiles between embedding concurrent and deferred assertions.

Thanks,
Dmitry

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Clifford E. Cummings
Sent: Saturday, September 24, 2011 03:36
To: Stuart Sutherland
Cc: 'Samik Sengupta'; Seligman, Erik; sv-ac@eda-stds.org; mills@lcdm-eng.com
Subject: Re: [sv-ac] RE: Call to vote: Due September 26 (resend with the correct Mantis number)

Hi, All -

Per Stu's comment, I am not completely up on the discussion, but I do have concerns.

In general, adding extra unrelated (in an RTL sense) signals to a sensitivity list would not affect the output value. Re-triggering combinational logic additional times should still resolve to the correct combinational outputs. Similarly, re-triggering latch-based logic would either pass the combinational value through to the output during transparent mode, and not impact the output during latching mode. We have always encouraged engineers to avoid extra sensitivity list signals mostly for simulation performance reasons because extra triggers translates into re-evaluation of the expressions within the logic blocks. Unsuspecting engineers could cause significant performance degradation by adding multiple assertion-tested signals to the sensitivity list.

I don't know what is legal or not, but my greater concern is if an assertion action block is allowed to make assignments to the always_comb and always_latch outputs. That would certainly be dangerous and could cause outputs to be wrong and mismatch the synthesized logic. Under those circumstances, non-input signals changing could cause the assertion to assign an invalid output value that would not be fixed until the next RTL input changes.

As an interesting side-note, Harry Foster and I have been strongly recommending the placement of concurrent assertions into bind files as opposed to putting them in the RTL code itself (which is a deviation from Harry's recommendations in his Assertion Based Design book). The reason is that RTL synthesis is often controlled by Makefiles, and every time a new assertion is added to the RTL code, the file time-stamp changes and could cause engineers to re-synthesize designs that in reality have not changed. Keeping the separate bind file allows engineers to add all the assertions they want without fear of triggering a synthesis Makefile run.

Regards - Exiled SV Committee Member - Cliff

On 9/23/2011 2:26 PM, Stuart Sutherland wrote:
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
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> [mailto:owner-sv-ac@eda.org] On Behalf Of Samik Sengupta
Sent: Friday, September 23, 2011 11:53 AM
To: Seligman, Erik; 'sv-ac@eda-stds.org<mailto:sv-ac@eda-stds.org>'
Subject: [sv-ac] RE: Call to vote: Due September 26 (resend with the correct Mantis number)

Hello Erik,

Thanks. I thought of that, although I did not check the mantis. I think it is okay to say just "immediate", although IMO in this case verbosity may be helpful. But I am fine either way.

Regards,
Samik

From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org] On Behalf Of Seligman, Erik
Sent: Friday, September 23, 2011 2:41 PM
To: 'sv-ac@eda-stds.org<mailto:sv-ac@eda-stds.org>'
Subject: [sv-ac] RE: Call to vote: Due September 26 (resend with the correct Mantis number)

Samik- wrt #2- remember that where we define deferred & final assertions, we explicitly state that they are kinds of immediate assertions, so I think we're covered as long as we just talk about immediate. (I remember writing the defs that way explicitly to avoid later verbosity in situations like this.)

From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org] On Behalf Of Samik Sengupta
Sent: Friday, September 23, 2011 11:39 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 (resend with the correct Mantis number)

Mantis 3564 __X__ 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

Friendly amendments:

Only the condition checked in the immediate assertion should be added to the sensitivity list, i.e., nothing from action block should wake up the always_comb.

I think we should be more specific and say "Expressions used in immediate, final, and deferred assertions" - not only immediate.

I agree to Ed, Anupam, and Manisha that no expression from concurrent assertion, including the clock, should go into the sensitivity list.

Thanks,
Samik

From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Wednesday, September 21, 2011 12:12 PM
To: 'sv-ac@eda-stds.org<mailto:sv-ac@eda-stds.org>'
Subject: [sv-ac] Call to vote: Due September 26 (resend with the correct Mantis number)

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

--
--
Cliff Cummings - Sunburst Design, Inc. 14355 SW Allen Blvd., Suite #100, Beaverton, OR 97005 Phone: 503-641-8446 / FAX: 503-641-8486 cliffc@sunburst-design.com<mailto:cliffc@sunburst-design.com> / www.sunburst-design.com<http://www.sunburst-design.com> World Class Verilog, SystemVerilog & OVM/UVM Training
--
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.