[sv-ac] placement of "disable iff"

From: John Havlicek <john.havlicek_at_.....>
Date: Thu Jun 08 2006 - 07:29:12 PDT
All:

We currently require that "disable iff" be placed only at the top
level.

Discussions in P1800 about the relation of "disable iff" to coverage
and action blocks seem to have converged (or be converging) to
treating a disabled evaluation as neither "true" nor "false".

The formal semantics currently allows "disable iff" to be nested.  The
main reason for this was to simplify the inductive definition of the
semantics.

In the past, I have had the vision of relaxing the rules on "disable
iff" to make it nestable and an analog of PSL "abort".  However, this
will not work well with the "neither true nor false" treatment of
disabled evaluations.

Now my vision is different--that "disable iff" be restricted to the
top level eternally.  In the future, we can add accept/reject as in
ForSpec, or the PSL abort syntax, to serve as the nestable operators
that yield "true" or "false" results.

Assuming that we will keep "disable iff" at the top level eternally,
there is little or no use in putting it inside property declarations.
To me, it seems we should think of "disable iff" as attached to the
assertion directives.

What do people think about making this change syntactically?  

The change would introduce a backwards compatibility problem -- people
who have written "disable iff" expressions inside property
declarations would have to move them to the relevant assertion
directives.

The benefit would be a syntactic enforcement of the top-level rule.
And I think the usage of "disable iff" would be simplified.  People
would not have to worry about not being able to instantiate a property
with a "disable iff" inside another property.

I think we should also add a default "disable iff" at the module level
(and in other scopes where it makes sense) and have the default apply
to all the assertion directives that do not have otherwise specified
"disable iff" expressions.

Best regards,

John H.
Received on Thu Jun 8 07:28:45 2006

This archive was generated by hypermail 2.1.8 : Thu Jun 08 2006 - 07:29:05 PDT