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

>From: "Bresticker, Shalom" <shalom.bresticker@intel.com>

>See Mantis 214.

Yes, the issues are somewhat related.  They both occur because a time
literal is treated as a real number.  They also both occur because the
timescale can be different for different modules.  Issue 214 occurs when
a parameter is overridden from somewhere that has a different timescale
from the module where the parameter is used.  The 1step issue occurs
because the global timeprecision can be different from the timeprecision
where the 1step is used.  However, the 1step issue occurs even without
parameters, though parameters can interact with it, defeating any simple
attempts to kludge around it.

Also, one of the possible extensions to address 214 better might also
help with the 1step problem.  Making time literals be of a new time type
that carries units with it, rather than just being real numbers, would
allow retaining the information that a "step" unit was used.  That could
allow a delay control to apply different rules to a delay of the time
type based on the units attached to it.

There would be a lot of complexity to such an extension.  It would need
to define all the rules for the type when different operators were applied,
and whether the result was still of the time type.  It would need to
define the rules for implicit conversion from the time type to reals in
a way that was backward-compatible with the current behavior.  It would
be a lot of work.

The problem with #1step is that 1step is defined to produce a real number,
and the rules for how delay controls treat numbers has been defined in
Verilog for 20 years.  I only see a few ways to get around that, which I
have mentioned:

1. Don't use a delay control.  Use a new construct, such as #step, that
   is not a normal delay control and does not follow the existing rules
   about precision.
   
2. Don't have 1step produce a normal number.  Have it produce something
   that is distinct from a number, such as special time type, so that a
   delay control can use new rules for it.
   
3. Have 1step produce a number, but with a value for which the behavior
   of a delay control is not already defined (for example, a negative
   value).  This is not recommended, since such a value would not follow
   intuitive rules for math operations applied to it (e.g. if it were
   negative, 1ps+1step would be less than 1ps, instead of greater).  I
   just mention it for completeness.

Steven Sharp
sharp@cadence.com