Re: [sv-ac] 1547 review

Hi Manisha:

The restriction from the second paragraph of 17.3 applies only to
clocking block inputs.

I do not know all the rules of clocking block.  A priori, though,
it seems that an assertion could use a clocking block non-input 
that is not a #1step signal.

J.H.

> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Thu, 22 Feb 2007 09:24:42 -0800
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] 1547 review
> Thread-Index: AcdWHi85FwnXBPaXTmyxjp1x0T8O5wATmfJgAA5dlzA=
> From: "Kulshrestha, Manisha" <Manisha_Kulshrestha@mentor.com>
> Cc: <sv-ac@eda-stds.org>
> X-OriginalArrivalTime: 22 Feb 2007 17:24:44.0208 (UTC) FILETIME=[57DE1300:01C756A6]
> 
> Now LRM P1800 clearly mentions that the signals used in an assertion are
> sampled using 1step sampling. It is an error if assertion uses a signal
> from a clocking block which has any other type of sampling.
> 
> Manisha
> 
> I have no opinion on the issue, but as to why someone might want
> assertion constructs in a clocking block, Ed previously wrote:
> 
> "I could see a case where the user has a clocking block for specifying
> sampling and driving and wants to put assertions on the signals that are
> marked as input, output, ...=20
> BUT, I hope that it will not confuse the user that the assertions sample
> at 1step while the clocking block specifies some other sampling and
> driving offset."
> 
> Shalom
> 
> 
> > I think we need to review the way assertion constructs can or cannot=20
> > be put into clocking blocks, interfaces, and modports.
> 
> --
> 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.