RE: [sv-bc] Is #4.2step legal?

>From: "Arturo Salz" <Arturo.Salz@synopsys.com>

>However, that is not how "step" is defined.
>
>If the global precision is 1fs and you specified #4.2step in a module
>with local time precision and time unit of 1ps, the effective delay
>would be 4fs (4.2fs which is truncated to 4fs). That's why I believe
>fractional step are useless.

Sorry Arturo, but that is not how time precision is defined to work
in Verilog.  And the definition of the time literal "step" in SV does
not change that.  In fact, the current LRM says that it gets rounded
to the current time precision even before it is used in a delay control.

There is not a single construct for "#1step" or "#(1step)".  It consists
of two separate constructs.  One of them is a delay control, which
accepts a literal or arbitrary parenthesized expression, which is an
integer or real number.  It takes that number and scales it by the
time unit and rounds it to the time precision.  It does this regardless
of the form of the expression that the number was calculated from.

The other construct is a time literal.  This is just a fancy way of
specifying a real number that is scaled (or actually inverse-scaled) to
the current time unit.  It behaves just like any other real number after
that.  It can be used in any expression just like any other real constant.
It can be used in a delay control to specify a real number to be used
by the delay control.  But that real number will be treated just like any
other real number by the delay control, which includes rounding to the
current time precision.

Now it turns out that section 3.5 says that the real value produced by a
time literal is rounded to the current time precision already.  So 1step
is already rounded to zero if the local time precision is coarser than
the global precision.  But even if it wasn't, the delay control would do it.

I know that someone will now suggest some horrible kludgy rule to try
to make delay controls work differently when the value was a time literal.
Not only would this be a nasty kludge, but you must realize that a delay
control could use an arbitrary expression containing time literals. There
is no guarantee that it is something as simple as #(1step).  It could be
something crazy like #(array[$rtoi(1ns/1step)>>i]+const_func(1step)).
The rules have to be general, and compatible with Verilog.

The best way to avoid the already-defined rounding behavior of Verilog
delay controls would probably be to define a new construct that has the
behavior of waiting the minimum step size.  Any construct that tries to
create a number and feed it to a delay control will round the number
using the time precision.  If you used something like "#step", and defined
it to wait one global time precision step regardless of the local time
precision, that could work.  In this case "step" would not be allowed in
an expression and would not be defined as having any numeric value.

Mac suggested something similar to this syntax, to avoid the issue of
multi-step delays.  But the more important thing is to avoid treating
it as a number being fed into a normal delay control, because then it
would follow the normal rounding rules for numbers fed into a delay
control.

Arturo, you objected to this because you wanted to be able to pass 1step
as a parameter value to be used as a delay elsewhere.  But it should be
clear from the description above that this could not work.  Even if you
had some kludge rule about 1step used in delay controls, this would not
work when 1step was used as a parameter value.  The parameter value would
end up just being a real number, and that real number would be subject to
the normal precision rules when the parameter was used as a delay.

The concern about new keywords is a valid one, but it is a little late to
be worrying about that with all the other problematic keywords added in
SV.  The word "step" might be commonly used as an identifier, but we could
find an alternative that is much more rarely used than keywords already
added by SV.

Steven Sharp
sharp@cadence.com