RE: [sv-ac] 1547 review

Arturo,

Except that the modport will have clocking with the properties, but not
the assertions. These would have to be either in the module / program
that use the modport or in the interface. There is no control over which
assertions should be associated with which modport in latter case.

ed  

> -----Original Message-----
> From: Arturo Salz [mailto:salz@synopsys.COM] 
> Sent: Wednesday, February 21, 2007 4:01 PM
> To: john.havlicek@freescale.com; Bassam.Tabbara@synopsys.COM
> Cc: Eduard.Cerny@synopsys.COM; Dave_Rich@mentor.com; 
> piper@cadence.com; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] 1547 review
> 
> John,
> 
> I have a faint memory that the reason we allowed assertions 
> in clocking
> blocks was to allow a group of assertions to included as part of an
> interface modport. So the intent was to enable users to instantiate
> assertions in asymmetrical interfaces, in which only certain modports
> might contain have assertions or different sets of assertions. Perhaps
> there are other issues that prevent this methodology, but I seem to
> recall that this was the original intent.
> 
> 	Arturo
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of John
> Havlicek
> Sent: Wednesday, February 21, 2007 12:11 PM
> To: Bassam.Tabbara@synopsys.COM
> Cc: Eduard.Cerny@synopsys.COM; Dave_Rich@mentor.com;
> john.havlicek@freescale.com; Bassam.tabbara@synopsys.COM;
> piper@cadence.com; sv-ac@eda-stds.org
> Subject: Re: [sv-ac] 1547 review
> 
> Hi Bassam:
> 
> I agree that we should not remove the capability to put
> sequence/property declarations within a clocking block.
> 
> My point is that if there is no need to put sequence/property
> declarations in a clocking block, then I can live with not
> being able to put assertion directives in a clocking block.
> I would just advise people not to put any assertion item in
> a clocking block.
> 
> J.H.
> 
> > x-mimeole: Produced By Microsoft Exchange V6.5
> > Content-class: urn:content-classes:message
> > X-Former-Content-Transfer-Encoding: base64
> > Date: Wed, 21 Feb 2007 11:41:44 -0800
> > Thread-Topic: [sv-ac] 1547 review
> > Thread-Index: AcdV7CCwFFVEyTCMTI2btShcUa2wggAAvSwQAAAnnBAAACdRIA==
> > From: "Bassam Tabbara" <Bassam.Tabbara@synopsys.com>
> > Cc: <Bassam.tabbara@synopsys.com>, <piper@cadence.com>,
> <sv-ac@eda-stds.org>
> > X-OriginalArrivalTime: 21 Feb 2007 19:41:44.0814 (UTC)
> FILETIME=[515140E0:01C755F0]
> > 
> > Hi Ed,
> > 
> > We shouldn't. I think the point is no need to put asserts 
> in there as
> proposal.
> > 
> > THX. 
> > -Bassam
> > 
> > -----Original Message-----
> > From: Eduard Cerny <edcerny@synopsys.COM>
> > To: Rich, Dave <Dave_Rich@mentor.com>; john.havlicek@freescale.com
> <john.havlicek@freescale.com>
> > CC: Bassam.Tabbara@synopsys.COM <Bassam.Tabbara@synopsys.COM>;
> piper@cadence.com <piper@cadence.com>; sv-ac@eda-stds.org
> <sv-ac@eda-stds.org>
> > Sent: Wed Feb 21 11:37:51 2007
> > Subject: RE: [sv-ac] 1547 review
> > 
> > But the LRM already allows sequences and properties to be in cb. Can
> we
> > remove them now?
> > ed 
> > 
> > > -----Original Message-----
> > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> > > Behalf Of Rich, Dave
> > > Sent: Wednesday, February 21, 2007 2:34 PM
> > > To: john.havlicek@freescale.com
> > > Cc: Bassam.Tabbara@synopsys.COM; piper@cadence.com;
> sv-ac@eda-stds.org
> > > Subject: RE: [sv-ac] 1547 review
> > > 
> > > > 
> > > > It may be that there is no point in putting sequence or property
> > > > declarations in a clocking block, in which case this proposal
> > > > would be unnecessary.
> > > > 
> > > > J.H.
> > > > 
> > > [DR>] That was my point.
> > > 
> > > -- 
> > > This message has been scanned for viruses and
> > > dangerous content by MailScanner, and is
> > > believed to be clean.
> > > 
> > > 
> > > 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.