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

Hi Dmitry, Ed:

Just to clarify, my suggestion was that default disable iff apply
to concurrent assertion directives, but be overridden by explicit
disable iff in the assertion directive.

J.H.

> X-IronPort-AV: i="4.05,228,1146466800"; 
>    d="scan'208"; a="49556302:sNHT26059194"
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Mon, 12 Jun 2006 10:19:36 +0300
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] placement of "disable iff"
> thread-index: AcaLCB5zOoI4wuWTTcGnwJYL+zHyEwAIrtEwAABU93AAAKU6QAAA8NpgAAAP8MAAfPL9IAAVQnDQAB07kqA=
> From: "Korchemny, Dmitry" <dmitry.korchemny@intel.com>
> X-OriginalArrivalTime: 12 Jun 2006 07:19:59.0841 (UTC) FILETIME=[9D5CCD10:01C68DF0]
> 
> Agree,
> Dmitry
> 
> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]=20
> 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?=20
> ed
> 
> 
> > -----Original Message-----
> > From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]=20
> > Sent: Sunday, June 11, 2006 3:18 AM
> > To: Faisal Haque (fhaque); Eduard Cerny; Lisa Piper;=20
> > john.havlicek@freescale.com; sv-ac@verilog.org
> > Subject: RE: [sv-ac] placement of "disable iff"
> >=20
> > We can state that the usage of disable iff in properties is=20
> > discouraged
> > and obsolete. Nevertheless the tools should support it, but probably
> > issue a warning message.
> >=20
> > Regards,
> > Dmitry
> >=20
> > -----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"
> >=20
> > Yes we enforce it through methodology
> >=20
> > And it is not so new that we can afford to break the=20
> > language. There are
> > enough users that it is not some thing to be undertaken=20
> > without serious
> > exploration of alternatives.
> > A lot of users are writing a lot of code right now.=20
> > So lets explore alternatives before we go down this road.
> > -Faisal
> >=20
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]=20
> > > Sent: Thursday, June 08, 2006 12:35 PM
> > > To: Lisa Piper; Eduard Cerny; Faisal Haque (fhaque);=20
> > > john.havlicek@freescale.com; sv-ac@verilog.org
> > > Subject: RE: [sv-ac] placement of "disable iff"
> > >=20
> > > But what John proposes is possible even now, question of=20
> > > methodology. It does not have to be enforced syntactically by=20
> > > forbidding disable iff in a property.
> > > ed=20
> > >=20
> > > > -----Original Message-----
> > > > From: Lisa Piper [mailto:piper@cadence.com]
> > > > Sent: Thursday, June 08, 2006 3:14 PM
> > > > To: Eduard Cerny; Faisal Haque (fhaque);=20
> > > john.havlicek@freescale.com;=20
> > > > sv-ac@verilog.org
> > > > Subject: RE: [sv-ac] placement of "disable iff"
> > > >=20
> > > > Ignoring nested "disable iff"'s would hide issues.  Issuing=20
> > > a warning=20
> > > > could lead to lots of warnings that are often overlooked.=20
> >  A slight=20
> > > > modification of that would be to issue a warning or error=20
> > > iff a nested=20
> > > > "disable iff" is different from the top level property. =20
> > > For clocks,=20
> > > > an error is supposed to occur if an assertion in procedural=20
> > > code uses=20
> > > > a different clock, but it is ok if it is the same clock. =20
> > > Disable iff=20
> > > > could be the same way - it is ok to be nested only if it is=20
> > > consistent=20
> > > > with the top level disable iff.
> > > >=20
> > > > But frankly, I'd prefer to see the root cause of the issue=20
> > > solved as=20
> > > > John proposed, even if there is a backwards compatibility=20
> > > issue. The=20
> > > > standard is new now and will be around for a very long time!
> > > >=20
> > > > lisa
> > > >=20
> > > > -----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;=20
> > > > sv-ac@verilog.org
> > > > Subject: RE: [sv-ac] placement of "disable iff"
> > > >=20
> > > > Faisal, I agree, we should avoid the compatibility problem.=20
> > > Would it=20
> > > > make sense to ignore a disable iff if it appears in a=20
> > > nested property?
> > > > Just issue a warning?
> > > >=20
> > > > ed
> > > >=20
> > > > > -----Original Message-----
> > > > > From: owner-sv-ac@verilog.org
> > > > > [mailto:owner-sv-ac@verilog.org] On Behalf Of Faisal=20
> > > 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"
> > > > >=20
> > > > > John,
> > > > > Interesting thought. However, I think we should avoid backward=20
> > > > > compatibility issues. Is there another way to do this?
> > > > > Faisal
> > > > >=20
> > > > >=20
> > > > > > -----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"
> > > > > >=20
> > > > > > All:
> > > > > >=20
> > > > > > We currently require that "disable iff" be placed only=20
> > > at the top=20
> > > > > > level.
> > > > > >=20
> > > > > > Discussions in P1800 about the relation of "disable iff" to=20
> > > > > > coverage and action blocks seem to have converged (or be
> > > > > > converging) to treating a disabled evaluation as=20
> > neither "true"=20
> > > > > > nor "false".
> > > > > >=20
> > > > > > The formal semantics currently allows "disable iff" to=20
> > > be nested. =20
> > > > > > The main reason for this was to simplify the inductive=20
> > > definition=20
> > > > > > of the semantics.
> > > > > >=20
> > > > > > In the past, I have had the vision of relaxing the rules on=20
> > > > > > "disable iff" to make it nestable and an analog of PSL=20
> > > "abort". =20
> > > > > > However, this will not work well with the "neither true=20
> > > nor false"=20
> > > > > > treatment of disabled evaluations.
> > > > > >=20
> > > > > > Now my vision is different--that "disable iff" be=20
> > restricted to=20
> > > > > > the top level eternally.  In the future, we can add=20
> > > accept/reject=20
> > > > > > as in ForSpec, or the PSL abort syntax, to serve as the=20
> > > nestable=20
> > > > > > operators that yield "true" or
> > > > > "false" results.
> > > > > >=20
> > > > > > Assuming that we will keep "disable iff" at the top level=20
> > > > > > eternally, there is little or no use in putting it=20
> > > inside property=20
> > > > > > declarations.
> > > > > > To me, it seems we should think of "disable iff" as=20
> > attached to=20
> > > > > > the assertion directives.
> > > > > >=20
> > > > > > What do people think about making this change syntactically? =20
> > > > > >=20
> > > > > > The change would introduce a backwards compatibility problem
> > > > > > -- people who have written "disable iff" expressions inside=20
> > > > > > property declarations would have to move them to the relevant=20
> > > > > > assertion directives.
> > > > > >=20
> > > > > > The benefit would be a syntactic enforcement of the
> > > > top-level rule.
> > > > > > And I think the usage of "disable iff" would be simplified. =20
> > > > > > People would not have to worry about not being able to=20
> > > instantiate=20
> > > > > > a property with a "disable iff" inside
> > > > another property.
> > > > > >=20
> > > > > > I think we should also add a default "disable iff" at=20
> > > the module=20
> > > > > > level (and in other scopes where it makes sense) and have the=20
> > > > > > default apply to all the assertion directives that do=20
> > not have=20
> > > > > > otherwise specified "disable iff" expressions.
> > > > > >=20
> > > > > > Best regards,
> > > > > >=20
> > > > > > John H.
> > > > > >=20
> > > > >=20
> > > > >=20
> > > >=20
> > > >=20
> > >=20
> >=20