RE: [sv-ac] placement of "disable iff"

From: Eduard Cerny <Eduard.Cerny_at_.....>
Date: Thu Jun 08 2006 - 07:36:50 PDT
John,

a problem may be that you cannot write a property in which the reset
condition is a formal parameter because verif. statements are not
parameterizable.

The introduction of a default reset would be useful, however.  

ed


> -----Original Message-----
> From: owner-sv-ac@verilog.org 
> [mailto:owner-sv-ac@verilog.org] On Behalf Of John Havlicek
> Sent: Thursday, June 08, 2006 10:29 AM
> To: sv-ac@verilog.org
> Subject: [sv-ac] placement of "disable iff"
> 
> 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:36:22 2006

This archive was generated by hypermail 2.1.8 : Thu Jun 08 2006 - 07:36:35 PDT