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

Agree,
Dmitry

-----Original Message-----
From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
Sent: Sunday, June 11, 2006 8:25 PM
To: Korchemny, Dmitry; Faisal Haque (fhaque); Eduard Cerny; Lisa Piper;
john.havlicek@freescale.com; sv-ac@verilog.org
Subject: RE: [sv-ac] placement of "disable iff"

I'd agree with that. Default reset - not all properties are disabled by
reset. Perhaps to override the deafult disable by using disable iff
(1'b0) in the assertion? 
ed


> -----Original Message-----
> From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
> Sent: Sunday, June 11, 2006 3:18 AM
> To: Faisal Haque (fhaque); Eduard Cerny; Lisa Piper; 
> john.havlicek@freescale.com; sv-ac@verilog.org
> Subject: 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.
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
>