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

We can state that the usage of disable iff in properties is discouraged
and obsolete. Nevertheless the tools should support it, but probably
issue a warning message.

Regards,
Dmitry

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

Yes we enforce it through methodology

And it is not so new that we can afford to break the language. There are
enough users that it is not some thing to be undertaken without serious
exploration of alternatives.
A lot of users are writing a lot of code right now. 
So lets explore alternatives before we go down this road.
-Faisal




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