[sv-bc] RE: Glitch-free deferred assertions

Hi Dave,

Please, see my comments below.

Thanks,
Dmitry

From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Wednesday, July 06, 2011 18:55
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Cc: sv-bc@eda.org
Subject: RE: Glitch-free deferred assertions

Dmitry,

I don't think the description of $strobe, $monitor as an event executing in the postponed region is entirely accurate. These statements execute as part of the active or re-active event queue, and schedule callbacks in the PLI postponed region. That is very different from executing an action block which could be one or more statements, and the arguments are expressions that need to be evaluated as well. If you're going to start putting restrictions on what the action block can contain, like only one display statement with simple primaries as arguments, then the usefulness of the action block becomes very limited.

[Korchemny, Dmitry] In this case we are talking about only issuing messages in the action block. Already in the deferred assertions, actions may be subroutines only, and not arbitrary statements or blocks. For this new kind of assertions I would define that only subroutines may be used as action blocks, and these subroutines should not modify design variables. This will essentially leave us only display statements.

There are many other ways of dealing with the perceived "glitch" in your example. Both a & b are clocked signals, so why are using a deferred assertion in the first place?

[Korchemny, Dmitry] This example comes from the area of formal equivalence check. Many formal equivalence check tool understand only unclocked assertions.

Don't use blocking assignments to write from your testbench directly to your DUT. Use NBAs with a delay or use clocking block output drives. BTW, the LRM recommends against ever using #0 as an input delay in a clocking block, so please do not use that in your examples.
[Korchemny, Dmitry] This methodology is not always safe, but it is widely used to "black-box" surrounding RTL blocks for debug purposes. Therefore I cannot ignore it.

Finally, don't use a program block. The current UVM guidelines and examples supported by all major vendors do not use program blocks. They are unnecessary and are the source of many hidden issues, this being just one of them.
[Korchemny, Dmitry] Since program blocks are part of the LRM, I think they should be properly supported.

Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number: 510-354-7439
[cid:image001.png@01CC3FDC.EF56CD20]<http://www.twitter.com/dave_59>[cid:image002.png@01CC3FDC.EF56CD20]<http://go.mentor.com/drich>

From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Wednesday, July 06, 2011 6:53 AM
To: Rich, Dave; sv-ac@eda-stds.org
Subject: RE: Glitch-free deferred assertions

Hi Dave,

The rationale of this proposal is to get a true glitch-free behavior of deferred assertions. The current behavior of deferred assertions is not glitch free when some of its variables come from the design, and some of the testbench. This situation arises when some part of the design in replaced with the testbench for testing or debugging purposes. You can see the specific example here: http://www.eda-stds.org/mantis/file_download.php?file_id=4571&type=bug.

It looks to me that issuing a message in the Postponed region should be legal because it is very similar to the following statement in the LRM:

4.4.2.9 Postponed events region
$monitor, $strobe and other similar events are scheduled in the Postponed region.
No new value changes are allowed to happen in the current time slot once the Postponed region is reached. Within this region, it is illegal to write values to any net or variable or to schedule an event in any previous region within the current time slot.

Thanks,
Dmitry

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Rich, Dave
Sent: Tuesday, July 05, 2011 17:36
To: sv-ac@eda-stds.org
Subject: [sv-ac] RE: Glitch-free deferred assertions

Having any kind of statement "execute" in the postponed region is problematic. Any function call with inputs must change a value upon entry.

Can you please recap the justification for this proposal?

From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Monday, July 04, 2011 5:41 AM
To: sv-ac@eda-stds.org; Rich, Dave; Vreugdenhil, Gordon
Subject: Glitch-free deferred assertions

Hi all,

In our F2F we discussed glitch-free deferred assertions, and the suggestion was to mature these assertions in the Postponed region. This will, however, introduce a backward incompatibility, and there may be people who are using the action blocks of deferred assertions to trigger events in the test bench.

Would the introduction of a new flavor of the deferred assertion work? I am talking about leaving the existing deferred assertions as they are, e.g.,

assert #0 (a) ...;

and to introduce a new flavor with the following syntax:

assert #1 (a) ...;

This new kind of deferred assertions works exactly as the existing one, except for the fact that they mature in the Postponed region and that their action blocks cannot change any values (i.e., they are essentially limited to issuing messages).

This will introduce rather a small addition to the LRM, and will not break the backward compatibility. This is somewhat similar to the strobe option in covergroups. What do you think?

Thanks,
Dmitry
---------------------------------------------------------------------
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.
---------------------------------------------------------------------
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.
---------------------------------------------------------------------
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.