RE: [sv-ac] 1547 review

All you get is yet another way to infer the clock.

> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
On
> Behalf Of John Havlicek
> Sent: Thursday, February 22, 2007 9:15 AM
> To: Eduard.Cerny@synopsys.com
> Cc: john.havlicek@freescale.com; shalom.bresticker@intel.com; sv-
> ac@server.eda-stds.org
> Subject: Re: [sv-ac] 1547 review
> 
> Hi Ed:
> 
> What do we get if a sequence declared in a clocking block
> refers to both inputs and outputs of the clocking block
> (and perhaps also to variables that do not appear in the
> clocking block) and that sequence is instantiated in an assertion?
> 
> J.H.
> 
> > X-MIMEOLE: Produced By Microsoft Exchange V6.5
> > Content-class: urn:content-classes:message
> > Date: Thu, 22 Feb 2007 07:44:54 -0800
> > Thread-Topic: [sv-ac] 1547 review
> > Thread-Index: AcdWe8hx1qpjTuxhTmG0sOM2yrm91AAG07Yw
> > From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> > Cc: <sv-ac@eda-stds.org>
> > X-OriginalArrivalTime: 22 Feb 2007 15:44:55.0206 (UTC)
> FILETIME=[6624E460:01C75698]
> >
> > I think that the simplest thing to do would be to do nothing. I.e.,
> > allow sequences and properties as it is now and that's it. I do not
see
> > much use of assertions in clocking blocks.
> >
> > ed
> > =20
> >
> > > -----Original Message-----
> > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On=20
> > > Behalf Of John Havlicek
> > > Sent: Thursday, February 22, 2007 7:19 AM
> > > To: shalom.bresticker@intel.com
> > > Cc: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > > Subject: Re: [sv-ac] 1547 review
> > >=20
> > > Hi Shalom:
> > >=20
> > > I am miserably confused both about the intent of the capability
> > > of putting assertion items within clocking blocks and modports
and=20
> > > about whether the various restrictions allow the intent to be
> > > realized.
> > >=20
> > > Regarding the sampling, there is the following language in 17.3:
> > >=20
> > >    If a variable used in an assertion is a clocking block input
> > >    variable, the variable must be sampled by the clocking block
with
> > >    #1step sampling. Any other type of sampling for the clocking
block
> > >    variable shall result in an error. The assertion using the
clocking
> > >    block variable shall not do its own sampling on the variable,
but
> > >    rather use the sampled value produced by the clocking block.
This
> > >    is explained in Clause 9.
> > >=20
> > > I'm not sure what you get if you refer to both clocking block
inputs
> > > and outputs within an assertion.
> > >=20
> > > J.H.
> > >=20
> > > > X-ExtLoop1: 1
> > > > X-IronPort-AV: i=3D"4.14,205,1170662400";=20
> > > >    d=3D"scan'208"; a=3D"200018743:sNHT18645032"
> > > > X-MimeOLE: Produced By Microsoft Exchange V6.5
> > > > Content-class: urn:content-classes:message
> > > > Date: Thu, 22 Feb 2007 12:32:47 +0200
> > > > X-MS-Has-Attach:=20
> > > > X-MS-TNEF-Correlator:=20
> > > > Thread-Topic: [sv-ac] 1547 review
> > > > Thread-Index: AcdWHi85FwnXBPaXTmyxjp1x0T8O5wATmfJg
> > > > From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> > > > Cc: <sv-ac@eda-stds.org>
> > > > X-OriginalArrivalTime: 22 Feb 2007 10:32:48.0122 (UTC)=20
> > > FILETIME=3D[CBEEA5A0:01C7566C]
> > > >=20
> > > > I have no opinion on the issue, but as to why someone might want
> > > > assertion constructs in a clocking block, Ed previously wrote:
> > > >=20
> > > > "I could see a case where the user has a clocking block for=20
> > > specifying
> > > > sampling and driving and wants to put assertions on the=20
> > > signals that are
> > > > marked as input, output, ...=3D20
> > > > BUT, I hope that it will not confuse the user that the=20
> > > assertions sample
> > > > at 1step while the clocking block specifies some other sampling
and
> > > > driving offset."
> > > >=20
> > > > Shalom
> > > >=20
> > > >=20
> > > > > I think we need to review the way assertion constructs
> > > > > can or cannot be put into clocking blocks, interfaces, and
> > > > > modports.
> > >=20
> > > --=20
> > > This message has been scanned for viruses and
> > > dangerous content by MailScanner, and is
> > > believed to be clean.
> > >=20
> > >=20
> 
> --
> 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.