Timescale Directive Verilog

In short: The Verilog `timescale directive sets each module's time unit (what a #1 delay means) and precision (how finely delays are rounded) — and because the directive is file-scoped and the simulator runs on the finest precision in the whole design, mismatched timescales silently rescale your delays and corrupt timing unless every file declares the same unit and precision.

What `timescale actually controls

Verilog has no inherent notion of seconds or nanoseconds. A delay such as #5 is just a dimensionless number until the compiler directive `timescale gives it physical meaning. The syntax is simple but the two numbers do very different jobs:

`timescale 1ns / 1ps

The value before the slash is the time unit — the multiplier applied to every delay in that file. The value after the slash is the time precision — the smallest increment the simulator tracks, i.e. how delays and times are rounded. Both must be 1, 10, or 100 followed by one of s, ms, us, ns, ps, fs, and precision can never be coarser than the unit.

With `timescale 1ns / 1ps, a delay of #2.75 means 2.75 ns, is stored as 2750 ps, and the simulator's internal clock advances in 1 ps steps. Change the unit to 1ps and that same #2.75 now means 2.75 ps — a thousand-fold error.

How unit and precision interact during simulation

Every numeric delay in a file is first multiplied by the unit, then rounded to the precision. Consider `timescale 1ns / 100ps and a statement #1.457 q = 1;. The tool computes 1.457 ns, then rounds to the nearest 100 ps, scheduling the event at 1.5 ns. The sub-100 ps detail is gone forever. This is exactly how you lose glitches and spike-filtering behaviour when precision is too coarse — and why specify-block path delays and SDF back-annotation demand fine precision.

The ratio between unit and precision also sets how many fractional digits are meaningful. A 1ns/1ps ratio of 1000 gives three decimal places of resolution on nanosecond delays; 1ns/1ns gives none, so #0.5 rounds to #1 (round-half-to-even behaviour varies by tool, so never rely on it).

The real danger: mismatched timescales across modules

Here is the trap that bites every engineer eventually. `timescale is a compiler directive, not a module property. It applies from the point it appears until the next `timescale or the end of compilation — and it carries across file boundaries in compilation order. So a module with no directive of its own silently inherits whatever directive was last seen, which depends on the order you listed files on the command line.

Two modules can run at different time units in the same simulation. A #5 delay in a 1ns module and a #5 in a 1ps module are 1000× apart in real time — yet the code looks identical. This is the single most common cause of "my testbench clock is wrong but the RTL is fine" confusion.

In Synopsys VCS, Cadence Xcelium, and Siemens Questa the directive behaves the same way per the IEEE 1364/1800 standard, but each tool offers an override. VCS and Xcelium accept -timescale=1ns/1ps and Questa's vlog accepts -timescale 1ns/1ps to force a uniform scale regardless of file contents — a useful safety net, but it masks the real bug rather than fixing it. SystemVerilog adds timeunit/timeprecision keywords inside a module, which are lexically scoped and far safer; prefer them in new code.

Precision is global, even when units are not

A subtle consequence catches people even when all units match: the simulator's actual time precision is the finest precision declared anywhere in the design. If 99 files say 1ns/1ns and one library cell says 1ps/1fs, the whole simulation now ticks in femtoseconds. That is perfectly correct behaviour, but it inflates memory and slows wall-clock time dramatically, and it can expose rounding differences you never saw before. Teams chasing a sudden 3× slowdown after integrating a vendor memory model are usually looking at exactly this.

Practical rules that prevent timescale bugs

• Put an identical `timescale at the top of every file — never rely on inheritance from compile order.
• Pick precision fine enough for the finest delay you care about; 1ns/1ps is a safe default for digital RTL and gate-level.
• Use $printtimescale and $timeformat to confirm what the tool actually resolved, and check the compile log for timescale warnings.
• In SystemVerilog, prefer in-module timeunit 1ns; timeprecision 1ps; over the global directive.
• Keep the full method in mind from our Verilog simulation basics guide, and watch for related race conditions in blocking vs non-blocking assignments.

For teams building sign-off-quality verification environments, our engineers at Avecas VLSI design services routinely enforce a single project-wide timescale as a lint rule — a two-minute policy that eliminates an entire class of debug.

Want to go from "my clock is off" to confident gate-level sign-off? The CourseTron FPGA & Verilog verification track walks through timescale, SDF back-annotation, and race-free testbenches with lab exercises on real tools.

Frequently asked questions

Does every Verilog file need its own `timescale?

Technically no — a file without one inherits the last directive seen in compile order. But in practice yes: relying on inheritance makes behaviour depend on file ordering, so the standard recommendation is to declare the same directive in every file.

What happens if one module has 1ns/1ps and another has 1ps/1fs?

Each module scales its own delays by its own unit, so a #1 differs by orders of magnitude between them. The whole simulation's precision becomes 1 fs (the finest declared), slowing the run and increasing memory, while the differing units can silently skew your timing.

Does `timescale affect synthesis?

No. Delays and the directive are ignored by synthesis tools like Synopsys Design Compiler — timing comes from the technology library and SDC constraints. `timescale matters only for simulation.

How do I see the effective timescale in my simulator?

Call $printtimescale on a module instance to print its unit and precision, and use $timeformat to control how %t prints time. The compile/elaboration log also reports the resolved global precision.