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