RE: [sv-bc] RE: [sv-ac] sampled assertion function vs data types - refereing to prior simulation

Preponed value in time 0 is a result of implicit $sampled function  so it
does need sampled value func...

DANiel

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of John Havlicek
Sent: Wednesday, November 21, 2007 2:46 PM
To: jonathan.bromley@doulos.com
Cc: sharp@cadence.com; sv-ac@server.eda-stds.org; sv-bc@server.eda.org
Subject: Re: [sv-bc] RE: [sv-ac] sampled assertion function vs data types -
refereing to prior simulation

Hi Folks:

If the clocking event of an assertion occurs in the first timestep, then
that assertion will be evaluated in the first timestep and the first
timestep Preponed values of the expressions will be used for the part of the
assertion evaluation that is performed in the first timestep.

This does not require the use of $past or other sampled value function in
the assertion.

The use of $past or other sampled value function may result in a dependency
of an assertion expression evaluation in a later timestep on the Preponed
values in the first timestep.

My opinion is that SV-BC should be defining what the first timestep Preponed
values are.  I thought that those were well defined, but perhaps that is not
the case.

If for certain kinds of nets, variables, etc., there is no well defined
Preponed value in the first timestep, then the evaluation of an assertion
that relies on such a value will not be well defined.

J.H.


> X-Authentication-Warning: server.eda.org: majordom set sender to 
> owner-sv-ac@eda.org using -f
> X-VirusChecked: Checked
> X-Env-Sender: jonathan.bromley@doulos.com
> X-Msg-Ref: server-8.tower-125.messagelabs.com!1195638026!29856847!1
> X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
> X-Originating-IP: [80.229.89.154]
> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
> Content-Class: urn:content-classes:message
> Date: Wed, 21 Nov 2007 09:40:22 -0000
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-bc] RE: [sv-ac] sampled assertion function vs data 
> types - refereing to prior simulation
> Thread-Index: Acgr1COjFJwdbDiMSAKCHcls4v1i1QASkIAQ
> From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
> 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.org 
> id lAL9f09w024273
> 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
> X-OriginalArrivalTime: 21 Nov 2007 09:41:43.0948 (UTC) 
> FILETIME=[B9E6CCC0:01C82C22]
> 
> Steven,
> 
> many thanks for the helpful clarification.
> 
> > A simulated wire will start with whatever value the simulator 
> > initializes it to before the simulation starts.
> 
> Understood.
> 
> > I can tell you that NC-Verilog [...] starts all nets at x and 
> > transitions them to z at time zero if not driven.  This x->z 
> > transition creates an event
> [...]
> > So the answer in NC-Verilog will be x.  But I don't think you can 
> > count on that being the answer in other implementations.
> 
> That's all very reasonable.  But there remains the problem that 
> assertions need to inspect the values of things in Preponed of time 0, 
> when using $past() and its friends.
> I don't want to prejudge what AC thinks, but I'm guessing that either 
> 'x or 'z would be acceptable to them - but it needs to be specified.
> --
> Jonathan Bromley, Consultant
> 
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW,
UK
> Tel: +44 (0)1425 471223                   Email:
jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com
> 
> The contents of this message may contain personal views which are not 
> the views of Doulos Ltd., unless specifically stated.
> 
> --
> 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.