Re: [sv-bc] Errata: inconsistent time literal rules

Steven,

Very 'sharp'!

One question: I did not understand the following sentence,
near the end:

> Changing a literal in an expression to a parameter defined to have the
> same value as the literal has the effect of changing the behavior.

Please clarify.

Thanks,
Shalom

On Tue, 31 Aug 2004, Steven Sharp wrote:

> In section 2.5, it says
>
> "Note that if a time literal is used as an actual parameter to a
> module or interface instance, the current time unit and precision
> are those of the module or interface instance."
>
> First of all, this is incorrect terminology, which makes it unclear
> what it is referring to. I assume it is referring to overriding a
> module parameter value using a module instance parameter value
> assignment. If so, then it should say so. Since this is unclear,
> it is unclear whether it also applies to defparams. I realize that
> the SystemVerilog LRM deprecates defparams, but this is unlikely to
> occur in the eventual Verilog language.
>
> Second, this makes the rules for scaling time literals inconsistent,
> varying with where they are referenced in the module. This appears to
> be an attempt to get the literal scaled properly for where it will
> ultimately be used as a delay. However, this rule does not actually
> accomplish that goal. The fact that it does work in some situations
> may make the problem worse by misleading users into thinking that it
> will work in all situations. A simpler and more consistent rule
> will be easier for users to understand, and less likely to surprise
> them.
>
> It is easy to produce examples where this rule does not accomplish
> the presumed goal. All that is necessary is for the overridden
> parameter to be passed on to another module instance that has a
> different timescale. It may even be used as a delay in different
> modules that have different timescales, so that no scaled value
> would be correct. Here is an artificial example that displays
> the problem:
>
> `timescale 1ns/10ps
> module foo;
> parameter delay = 0;
> initial #delay $display("time = %t", $time);
> endmodule
>
> `timescale 1ps/1ps
> module bar;
> parameter delay = 0;
> initial #delay $display("time = %t", $time);
> endmodule
>
> `timescale 100ps/100ps
> module mid;
> parameter delay = 0;
> foo #(delay) f();
> bar #(delay) b();
> endmodule
>
> `timescale 1ns/1ns
> module top;
> mid #(5.5ns) m();
> endmodule
>
>
> Here the rules say that 5.5ns should get scaled to the timescale of module
> mid, and therefore top.m.delay would be set to 55. Then top.m.f.delay
> and top.m.b.delay would both be set to 55. In top.m.f, that would mean
> 55ns and in top.m.b, that would mean 55ps. Neither of these is the 5.5ns
> that was specified.
>
> In a more realistic example, the modules foo and bar would be in different
> files and/or libraries, and would use the delays as propagation delays.
>
> Also consider what happens if the user decides to pass the delay down to
> multiple submodules. Normally you would want to put that commonly used
> value into a parameter, so you can change it in once place:
>
> `timescale 1ns/1ns
> module top;
> parameter delay = 5.5ns;
> mid #(delay) m();
> mid2 #(delay) m2();
> endmodule
>
> But that completely changes the behavior. Now the 5.5ns will be scaled
> to the timescale of module top, so delay will have a value of 6. The
> resulting delay in top.m.f would be 6ns (which is accidentally scaled
> correctly, but incorrectly rounded off), and in top.m.b would be 6ps.
> Changing a literal in an expression to a parameter defined to have the
> same value as the literal has the effect of changing the behavior.
> This will be unexpected by most users.
>
> This note complicates the way time literals work, without actually giving
> the correct timescaling in the general case. Simply deleting this special
> case would at least simplify things. It would also solve the unexpected
> behavior in the second example.
>
> BTW, to solve the general case would require something like a special type
> to indicate that an object (e.g. a parameter) contains a time, instead of
> just a number. Then the scaling could be deferred until the value was
> actually used as a delay, allowing the scaling to be done with the timescale
> where the delay was actually used. It is unfortunate that the type names
> "time" and "realtime" have already been used for simple integer and real
> types, since those would be ideal names.

-- 
Shalom Bresticker                        Shalom.Bresticker @freescale.com
Design & Reuse Methodology                           Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                 Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 5441478
  
[ ]Freescale Internal Use Only      [ ]Freescale Confidential Proprietary