RE: [sv-ac] 1547 review

All:

Clocking block output signals are not "sampled" signals.
They are signals with one or more writers, in which the
clocking block participates in normal value resolution
with any other writers on the signal.

Clocking block inouts can be thought of as split into
two components:  An input side and an output side.
The input side is sampled just like a clocking block input.
The output side is driven just like a clocking block output.

The only real interplay here is between assertions and
the "sampled" clocking signals:  inputs and the input
side of inouts.

A tinsy bit of terminology and rules for you:

   bit ov, iv;       // <-- These are "clocking signals"
   wire ow, iw;      // <-- So are these, though of net type.
   clocking cb @(posedge clk);
      input iv, iw;  // <-- These are input "clockvars"
      output ov, ow; // <-- These are output "clockvars"
   endclocking

To read the sampled value of iv, read "cb.iv".
To drive ov synchronized to clk, write "cb.ov".
It is always illegal to read "cb.ov".  Read ov instead.
All the above applies to iw and ow, too.

It is possible that there are other writers on ov or ow.
In that case, the output clockvar participates in
updates just like any other writer.  For ov, it is
"last writer wins".  For ow, it is net resolution.

Regards,
Doug

> -----Original Message-----
> From: owner-sv-ac@server.eda.org 
> [mailto:owner-sv-ac@server.eda.org] On Behalf Of John Havlicek
> Sent: Friday, February 23, 2007 4:24 AM
> To: Kulshrestha, Manisha
> Cc: shalom.bresticker@intel.com; john.havlicek@freescale.com; 
> sv-ac@server.eda-stds.org
> Subject: 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.
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.