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.