RE: [sv-ec] Testbench examples ...#1step

Concerning #1step and rounding of time values
according to local timeprecision, I tried a 
testcase in three simulators:

- all agree that #1step samples as if in the Preponed region,
  independent of the local timeprecision;
- one tool appears to treat #0 identically to #1step.

The first observation suggests that my suggestion to 
treat 1step as a special case, and not as a value equal
to the global timeprecision, would have little negative
impact; the second observation suggests strongly that
few users are exploiting "input #0", otherwise the
bug would presumably have been reported and fixed.
-- 
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

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]On
> Behalf Of Jonathan Bromley
> Sent: 04 November 2006 12:33
> To: sv-ec@server.eda.org
> Subject: RE: [sv-ec] Testbench examples ...#1step
> 
> 
> Steven Sharp wrote:
> > Verilog defines the semantics of #<number>, which includes rounding
> > to the local time precision.  If the local time precision is coarser
> > than the finest precision in the design, then the real number that
> > is represented by 1step will be rounded to zero.  So #1step will be
> > equivalent to #0.  It will not delay by the finest precision in the
> > design as people seem to think it will.
> 
> If this is true (and I have no reason to disagree) then it has
> very unpleasant side-effects.  In a clocking, "input #0" has
> semantics that are spectacularly different from 
> input #<anything else>.  For "input #1step" to be silently
> coerced to "input #0" would be a disaster for most users.
> 
> However, it's worth checking whether existing tools actually
> handle #1step in the way Steven describes, or whether they
> treat it as a special case.
> 
> I have never liked the discontinuity between "input #0"
> and other forms of clocking input, and in any case "input #0"
> is horribly fragile because its intent is completely broken
> by the existence of any non-zero delays on the signal being
> sampled.  I would like to see "input #0" abolished, and I
> have consistently urged users to avoid it.
> 
> I believe that it would be better to redefine
> "input #0" to mean "sample in the Preponed region of the
> current timestep", therefore getting the effect that most
> people think they want from "input #1step", and exactly
> matching the $sampled() semantics of assertions.  But of 
> course there may be existing code out there that uses the 
> wait-until-all-the-fuss-is-over sampling of "input #0",
> and that would be horribly broken by this change.
> 
> A reasonable alternative is to redefine #1step
> to be a magic spell meaning "sample in the Preponed region",
> rather than defining "step" as a time unit that can be
> used in arbitrary expressions.  This latter change would 
> probably have little collateral damage, since (as far as I 
> know) no tools support the "step" time unit in any context
> other than #1step sampling in clockings.
> -- 
> 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.