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

But what John proposes is possible even now, question of methodology. It
does not have to be enforced syntactically by forbidding disable iff in
a property.
ed 

> -----Original Message-----
> From: Lisa Piper [mailto:piper@cadence.com] 
> Sent: Thursday, June 08, 2006 3:14 PM
> To: Eduard Cerny; Faisal Haque (fhaque); 
> john.havlicek@freescale.com; sv-ac@verilog.org
> Subject: 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.
> > > 
> > 
> > 
> 
>