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

From: Arturo Salz <Arturo.Salz@synopsys.com>
Date: Tue Jul 12 2011 - 10:07:50 PDT

Dmitry,

We had originally proposed 'assert final' for deferred assertions. I believe it would be appropriate for these new more restrictive assertions since they indeed have final semantics (the action block cannot cause additional events with 0 delay).

        Arturo

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Tuesday, July 12, 2011 4:54 AM
To: Bresticker, Shalom; neil.korpusik@oracle.com
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] Glitch-free deferred assertions

I don't know what is the right name to use here. On one hand I didn't want to introduce new syntactical elements. We also have several examples of such "abuse", e.g., assert #0 and #0 sampling in clocking block. On the other hand, this may be confusing. Maybe somebody can suggest a better name.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Bresticker, Shalom
Sent: Thursday, July 07, 2011 09:42
To: neil.korpusik@oracle.com
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] Glitch-free deferred assertions

Note:

While "1step" is only described in the LRM in the context of the input skew in a clocking block, the BNF allows it as delay_value, and the LRM does not seem to explicitly restrict using it anywhere delay_value can be used.

Shalom

> From 4.4.2.1 Preponed events region:
>
> #1step sampling is identical to taking the data samples in the Preponed
> region of the current time slot.
>
> It would be confusing if deferred assertions start using #1step to
> refer to execution in the Postponed region of the current time slot.
> The two different usages would be with respect to the opposite ends of
> the current time slot.

---------------------------------------------------------------------
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.
---------------------------------------------------------------------
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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jul 12 10:08:41 2011

This archive was generated by hypermail 2.1.8 : Tue Jul 12 2011 - 10:08:45 PDT