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

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?

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.

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.

Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number: 510-354-7439
[Description: Twitter-32]<http://www.twitter.com/dave_59> [Description: Technorati-32] <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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.