RE: [sv-ac] comments on 1757

-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com] 
Sent: Tuesday, August 21, 2007 4:28 PM
To: Korchemny, Dmitry
Cc: john.havlicek@freescale.com; sv-ac@eda-stds.org
Subject: Re: [sv-ac] comments on 1757

Hi Dmitry:

> [Korchemny, Dmitry] I don't think that disable iff has well defined
> simulation semantics at all. My understanding is that disable iff uses
> the value of the reset available in the observed region. I still think
> that it should use sampled values, but should not be sampled by the
> (leading) clock.=20
> The difference between disable iff and accept_on/reject_on should be
> that disable iff defines the main reset of the assertion, and when it
is
> high, we have a disabled computation of an attempt, while
> accept_on/reject_on are just temporal operators. In FV it means that
> disable iff has accept_on semantics in assertions and assumptions, and
> reject_on semantics in cover directives.

There is not agreement on what disable iff means in simulation, and it
will take time to look for evidence in the LRM.

My recommendation is to avoid language in the current proposal that 
ties accept_on/reject_on to an interpretation of disable iff.  Rather,
write the normative description of accept_on/reject_on so that it stands
on its own.

[Korchemny, Dmitry] Absolutely agree.

If you want to change or clarify the semantics of disable iff, then
I recommend that that be done in a separate mantis item.

[Korchemny, Dmitry] See 1551

J.H.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.