In your proposal, you wrote: The only way to assert the property is to use a hierarchical reference to the name of the property. This is undesirable for three reasons: 1) relying on hierarchical references affects code portability 2) many methodologies recommend keeping the property definition and its associated verification directive local for ease of debug 3) the ability to instantiate properties from packages in a clocking block You were the one linking properties in packages and clocking blocks in 3). Dave ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Wednesday, February 21, 2007 8:58 AM To: Rich, Dave; Bassam Tabbara; sv-ac@eda-stds.org Subject: RE: [sv-ac] 1547 review Dave, I don't understand the link between the clocking block and a package? Can you explain? Lisa -----Original Message----- From: Rich, Dave [mailto:Dave_Rich@mentor.com] Sent: Wednesday, February 21, 2007 11:49 AM To: Bassam Tabbara; Lisa Piper; sv-ac@eda-stds.org Subject: RE: [sv-ac] 1547 review 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.Received on Wed Feb 21 09:06:59 2007
This archive was generated by hypermail 2.1.8 : Wed Feb 21 2007 - 09:07:09 PST