Re: [sv-ac] 1547 review

Hi Dave:

I have understood the major motivation for this proposal to be 
to provide a way to place the assertion directives close to the
sequence and/or property declarations in the clocking block.

The sequence and property declarations could be put outside the
clocking block with no clock specified and the assertion directives
could reference the clocking block.

I think I am missing the point in putting the sequence or property
declarations in the clocking block.  I have assumed that there is one,
and therefore I have wanted a way to put the assertion directives
nearby.

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.

> X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda.org using -f
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Wed, 21 Feb 2007 08:48:37 -0800
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] 1547 review
> Thread-Index: AcdVZsjiNVt6BITFQLuIyBzTSqyrgwABNwuwAAF2xDYAFtfZEA==
> From: "Rich, Dave" <Dave_Rich@mentor.com>
> X-OriginalArrivalTime: 21 Feb 2007 16:48:40.0416 (UTC) FILETIME=[23BBDE00:01C755D8]
> X-eda.org-MailScanner: Found to be clean, Found to be clean
> X-Spam-Status: No, No
> X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda-stds.org id l1LGmpa7004631
> Sender: owner-sv-ac@eda.org
> X-eda.org-MailScanner-Information: Please contact the ISP for more information
> X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org
> 
> I see little point in having properties or assertions in a clocking
> block as there is already another way to associate a clock with a set of
> assertions.
> 
> always @(posedge clk) // or @(cb) is there is an existing clocking block
> 	begin
> 	assert property (p1);
> 	assert property (p2);
> 	end
> 
> There's no requirement that there has to be a procedural statement in an
> always block.
> 
> In any case, I agree with Bassam that a cb reference is not the kind of
> hierarchical reference that affects portability. 
> 
> Also, I don't see how a reference to a cb makes it undesirable to
> reference a property from a package. Or was that supposed to be a
> benefit?
> 
> Dave
> 
> 
> 
> 
> > -----Original Message-----
> > From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
> On
> > Behalf Of Bassam Tabbara
> > Sent: Tuesday, February 20, 2007 8:34 PM
> > To: piper@cadence.com; Bassam.tabbara@synopsys.com; sv-ac@server.eda-
> > stds.org
> > Subject: Re: [sv-ac] 1547 review
> > 
> > Hi Lisa,
> > 
> > You declare them there to get the clocking and can always assert thru
> cb's
> > name.
> > 
> > THX.
> > -Bassam
> > 
> > -----Original Message-----
> > From: Lisa Piper <piper@cadence.com>
> > To: Bassam Tabbara <Bassam.Tabbara@synopsys.COM>; sv-ac@eda-stds.org
> <sv-
> > ac@eda-stds.org>
> > Sent: Tue Feb 20 20:02:07 2007
> > Subject: RE: [sv-ac] 1547 review
> > 
> > Hi Bassam,
> > 
> > 
> > 
> > I guess I don't understand the use model.  When would you want to
> define
> > properties and sequences in a clocking block?  When would you do this
> and
> > not want to assert them?
> > 
> > 
> > 
> > Lisa
> > 
> > 
> > 
> > ________________________________
> > 
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Bassam
> > Tabbara
> > Sent: Tuesday, February 20, 2007 10:17 PM
> > To: sv-ac@eda-stds.org
> > Subject: [sv-ac] 1547 review
> > 
> > 
> > 
> > The proposal seems fine but I disagree with what its objective. I
> believe
> > the clocking block is a declaration scope so it would be quite
> inadequate
> > to add executing statements into a construct intended to orthogonalize
> > clocking/sampling definition (declaration) from structure/behavior.
> > Putting asserts there is undesirable in my opinion, and would open the
> > door to other statements.
> > 
> > Thx.
> > 
> > -Bassam.
> > 
> > 
> > 
> > 
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner <http://www.mailscanner.info/> , and
> is
> > believed to be clean.
> > 
> > -- This message has been scanned for viruses anddangerous content by
> > MailScanner, and isbelieved 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.