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

I believe the intention was that #1step would never be rounded
when used in clocking decls.  The semantic intent is to specify
sampling in the preponed region.  This is clear to me from reading
other text in that area of the LRM.  Adding text to explicitly forbid
rounding due to local time precision would be a good clarification.

Thanks,
Doug 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Jonathan Bromley
> Sent: Monday, November 06, 2006 2:23 AM
> To: Arturo Salz; stuart@sutherland-hdl.com; sv-ec@server.eda-stds.org
> Subject: RE: [sv-ec] Testbench examples ...#1step
> 
> > I agree that using #1step in anything other than a clocking 
> > block sample
> > is of dubious value, but that's a methodology issue. We 
> used a special
> > timeunit to specify this special skew in order to allow the 
> skew to be
> > passed in as a parameter. That ruled out using a new keyword. 
> 
> Sorry, I'd missed this point.  Thanks for the clarification.
> 
> So that takes us straight back to Steven Sharp's point about
> unexpected/unwanted rounding of 1step to zero.
> 
> Two suggestions spring to mind:
> 
> 1) add a special rule to the effect that time values specified
>    using "step" should never be rounded - it looks as though this
>    would ratify the de facto position;
> 2) require tools to issue a warning whenever an "input #..." has
>    the effect of "input #0", but was not specified using the 
>    literal #0.  Since the semantics of input #0 are so sharply
>    different from anything else, I suspect users might value that.
> -- 
> 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.
> 
>