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

Ignoring nested "disable iff"'s would hide issues.  Issuing a warning
could lead to lots of warnings that are often overlooked.  A slight
modification of that would be to issue a warning or error iff a nested
"disable iff" is different from the top level property.  For clocks, an
error is supposed to occur if an assertion in procedural code uses a
different clock, but it is ok if it is the same clock.  Disable iff
could be the same way - it is ok to be nested only if it is consistent
with the top level disable iff.

But frankly, I'd prefer to see the root cause of the issue solved as
John proposed, even if there is a backwards compatibility issue. The
standard is new now and will be around for a very long time!

lisa

-----Original Message-----
From: owner-sv-ac@verilog.org [mailto:owner-sv-ac@verilog.org] On Behalf
Of Eduard Cerny
Sent: Thursday, June 08, 2006 2:50 PM
To: Faisal Haque (fhaque); john.havlicek@freescale.com;
sv-ac@verilog.org
Subject: RE: [sv-ac] placement of "disable iff"

Faisal, I agree, we should avoid the compatibility problem. Would it
make sense to ignore a disable iff if it appears in a nested property?
Just issue a warning?

ed 

> -----Original Message-----
> From: owner-sv-ac@verilog.org 
> [mailto:owner-sv-ac@verilog.org] On Behalf Of Faisal Haque (fhaque)
> Sent: Thursday, June 08, 2006 2:47 PM
> To: john.havlicek@freescale.com; sv-ac@verilog.org
> Subject: RE: [sv-ac] placement of "disable iff"
> 
> John,
> Interesting thought. However, I think we should avoid backward
> compatibility issues. Is there another way to do this?
> Faisal
> 
> 
> > -----Original Message-----
> > From: owner-sv-ac@verilog.org 
> > [mailto:owner-sv-ac@verilog.org] On Behalf Of John Havlicek
> > Sent: Thursday, June 08, 2006 7: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.
> > 
> 
>