Verilog Timescale

In short: `timescale / tells a Verilog simulator what a bare #delay means and how finely time is rounded — set it consistently across every module, because the simulator silently inherits or overrides it in surprising ways.

If you have ever watched a testbench run a thousand times faster than you expected, or seen a #5 delay behave like #5000, you have met the `timescale directive. It is one line of code, yet it quietly governs every unit-less delay in your design. This article unpacks what the directive actually does, how time unit and precision interact, and the cross-module pitfalls that trip up even experienced RTL and verification engineers.

What the directive declares

The syntax defined by the IEEE 1364 (and carried into IEEE 1800 SystemVerilog) standard is:

`timescale  / 

The time unit is the multiplier applied to any bare delay number. With `timescale 1ns/1ps, writing #5 means "advance 5 ns". The time precision is the smallest increment the simulator tracks and the granularity to which delays are rounded. Both fields must be an integer 1, 10, or 100 followed by a unit from s, ms, us, ns, ps, fs. Crucially, the precision cannot be coarser than the unit — 1ns/1us is illegal.

Rule of thumb: unit sets the meaning of your numbers; precision sets how accurately they are stored. A ratio of 1000 (e.g. 1ns/1ps) is extremely common because it gives three decimal places of sub-nanosecond resolution.

How precision rounds delays

The simulator picks a single global time step for the whole simulation: the smallest precision found across all compiled modules. Every delay you write is converted into integer multiples of that global step. Consider `timescale 1ns/100ps:

• #1.3 → 1.3 ns, which is 13 steps of 100 ps — stored exactly.
• #1.37 → rounds to the nearest 100 ps, i.e. 1.4 ns. The extra 0.07 ns is lost.
• #0.04 → rounds to 0, so the delay vanishes entirely.

This rounding is defined by the standard as "round to nearest", with ties handled by the tool. In practice, Synopsys VCS, Cadence Xcelium, and Siemens Questa all honour the finest precision in the design, which is why a stray 1fs precision in one library model can balloon memory usage and slow the whole run — the entire simulation now ticks in femtoseconds.

Watching time move: an animated view

Scope and inheritance: the real trap

The directive is not lexically scoped to a module — it is a compiler directive that stays in effect for every module compiled after it, until the next `timescale is seen. This has three consequences that cause real bugs:

• A module with no `timescale above it inherits whatever directive the previously compiled file left active. Change your file compile order and the same RTL can behave differently.
• If no module in the compile set declares a timescale, the tool falls back to a default (often 1ns/1ns, but it is tool- and switch-dependent) or errors out.
• Mixed timescales are legal and common — a 1ns testbench driving a 1ps-precision gate netlist — but the global precision becomes the finest one present.

Best practice across industry teams: put an identical `timescale at the top of every source file, or (better) stop relying on the directive and pass it on the command line — vcs -timescale=1ns/1ps, xrun -timescale 1ns/1ps, or qrun -timescale 1ns/1ps. A single global override removes the file-order dependency entirely.

Why it matters for timing and performance

Two forces pull in opposite directions. Finer precision gives you accurate delays — essential for SDF-annotated gate-level simulation where setup/hold margins live in picoseconds. But finer precision also means the event scheduler advances in smaller ticks, inflating the number of time slots it tracks and increasing both runtime and memory. A design that only needs nanosecond resolution should not carry a femtosecond precision; the penalty can be an order of magnitude in wall-clock time with no accuracy benefit.

For RTL functional verification, where you mostly care about cycle behaviour rather than absolute delays, a coarse 1ns/1ns or even 1ns/10ps keeps regressions fast. Save the fine precision for the netlist runs that actually consume SDF. If you are building your first self-checking environment, see our guide on writing a Verilog testbench, which shows where the directive belongs relative to the clock generator.

Common pitfalls checklist

• Vanishing delays: a #0.5 under a 1ns/1ns timescale rounds to 0 and your intended skew disappears.
• Silent inheritance: a reused IP file with no directive picks up the last-compiled timescale — always declare your own.
• Precision explosion: one vendor model with 1fs precision slows every other module in the build.
• Testbench/DUT mismatch: a 10ns testbench feeding a 1ns DUT makes every clock look ten times slower than intended.
• `resetall`: remember that `resetall clears the active timescale, reverting subsequent modules to the tool default.

Analog-mixed-signal and advanced-node flows add further nuance; teams doing production tape-outs often lean on a design-services partner such as Avecas VLSI design services to standardise simulation methodology across RTL, gate, and SDF decks. For the deeper event-scheduling model, our note on Verilog's event scheduler regions explains how delays map onto the active, inactive, and NBA queues.

Ready to master simulation from first principles? Our hands-on CourseTron Verilog & SystemVerilog course walks you through timescales, race conditions, and testbench architecture with lab exercises on industry simulators.

Frequently asked questions

Is `timescale required in every file?

The language does not force it, but relying on inheritance is fragile. Either declare an identical directive at the top of every file or set it globally on the simulator command line so compile order cannot change behaviour.

What happens if time precision is finer than I need?

Nothing functionally wrong, but the simulator advances in those smaller steps everywhere, which increases runtime and memory. Match precision to the accuracy you actually require — nanoseconds for RTL, picoseconds for gate-level SDF.

Can different modules use different timescales?

Yes. Each module uses its own unit for its own delays, but the simulation's global time step is the finest precision present anywhere in the compiled design.

Does SystemVerilog change any of this?

No. IEEE 1800 keeps the same directive and semantics. SystemVerilog adds the timeunit/timeprecision statements as a lexically scoped alternative, but the classic `timescale behaves identically.