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

Hi Jonathan:

I expect that the general rules for updating driven nets are not being
defined in this paragraph.  Can the sentence

   Nets with drivers shall assume the output value of their drivers.
   
simply be deleted?

J.H.

> X-VirusChecked: Checked
> X-Env-Sender: jonathan.bromley@doulos.com
> X-Msg-Ref: server-2.tower-92.messagelabs.com!1195570273!34259912!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: Tue, 20 Nov 2007 14:51:08 -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: AcgrgK18hz1swbZ0R3ay5m0JqXORMgAAtHnA
> From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
> Cc: <danielm@aldec.com.pl>, <sv-ac@eda-stds.org>, <sv-bc@eda.org>
> X-OriginalArrivalTime: 20 Nov 2007 14:52:04.0791 (UTC) FILETIME=[EA603470:01C82B84]
> 
> > I believe what you say about the initial value of w being 1'bz.
> > But what does the sentence [mean]
> >     Nets with drivers shall assume the output value of their drivers.
> 
> I think I can weasel my way out of that one...  Before time 0,
> the driver doesn't yet have an output value because its input
> has not yet propagated to its output.
> 
> However, this goes back to what I asked in an earlier post...
> > Or is this too mechanistic a view of continuous assignment?
> 
> The truth is that this is a corner case that needs specific=20
> definition, because it will never be really obvious and=20
> it is likely to be at the mercy of tool implementation
> differences unless it's defined as a special case. =20
> Personally I would have thought that defining the=20
> time-0 Preponed value of all nets to be 'z would be wise,=20
> because it will make sense not only for nets with=20
> simple zero-delay drivers but also for drivers=20
> with delays, and nets that are truly undriven.
> --=20
> 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=20
> 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.