GLS-04: Disabling Timing Checks β€” VLSI Trainers
⌂ Home / GLS Series
Gate-Level Simulation · Article 4 of 7

GLS-04: Disabling Timing Checks

Why timing checks sometimes need to be selectively disabled, the three mechanisms for doing so β€” global elaboration switches, local timing files, and runtime commands β€” and how to make the right choice for each situation.

πŸ€”Why Disable Timing Checks?

In a complete SDF-annotated GLS run the simulator evaluates a timing check at every flip-flop and latch for every clock edge. For a design with tens of thousands of sequential elements running for millions of cycles, most checks pass and are informational β€” but some produce violations that are known and intentional, not bugs. Reporting these creates noise that drowns out genuine failures.

Four categories of situations call for selective timing check disabling:

Principle of minimum disabling: Disable only what is necessary, with the narrowest possible scope, and document every waiver. Disabling too broadly can hide real timing violations. Every timing check disable should have a named justification: “CDC synchroniser at top.u_cdc.sync_ff” β€” not “suppress all holds everywhere”.

πŸ—ΊοΈThree Mechanisms at a Glance

Figure 1 β€” Three mechanisms: scope, timing, and use case
β‘  Global Switches Scope: Entire design β€” all instances Timing: Set once at elaboration Use when: Zero-delay or unit-delay mode. Suppressing all checks during development debug runs. -nospecify -notimingchecks β‘‘ Timing File (tfile) Scope: Per-instance or per-subtree Timing: Set at elaboration β€” checks not compiled β†’ improves performance Use when: CDC, false paths, IP blocks. Production GLS waivers. -tfile timing.tfile β‘’ Runtime tcheck Scope: Per-instance, toggled at any time Timing: During simulation β€” on or off at any simulation time point Use when: Investigating a specific failure. Does NOT improve performance. tcheck inst_path -off | -on vlsitrainers.com

Three mechanisms for disabling timing checks. Global switches (blue) apply to the entire design at elaboration. Timing files (green) target specific instances or subtrees at elaboration, improving both coverage granularity and performance. Runtime tcheck (orange) toggles checks during simulation for interactive debugging β€” no performance benefit since check infrastructure is still compiled.

🌐Global Switches at Elaboration

Global switches are passed as arguments at elaboration time and apply to the entire design without exception β€” every instance, every cell, every timing check of the specified type. They are the bluntest instrument and should be used only when design-wide suppression is genuinely appropriate.

SwitchWhat it disablesTypical use case
-nospecify All timing information in specify blocks β€” both path delays and timing checks. SDF annotation is also suppressed and a warning is issued. Zero-delay GLS mode. DFT scan verification. Early functional regression post-synthesis before SDF is available.
-notimingchecks All timing check evaluations ($setup, $hold, $setuphold, $recrem, $width…) but not path delays. Signal propagation timing remains correct. When you want timing-accurate waveforms but are not yet ready to triage violations β€” e.g. early SDF bring-up where violations are numerous and not yet meaningful.
-nonotifier Notifier register updates in timing checks. The notifier pulses on violation; disabling it removes metastability-model X propagation but keeps violation messages active. When notifier-driven X spread is masking other failures. Keeps violation reporting without X contamination.
-no_tchk_msg Display of timing check warning messages only. Checks still execute; notifiers still update. NTC delays still calculated. When violation messages flood the log file but underlying check logic must remain active for correct X propagation behaviour.
-ntcnotchks Generates NTC delayed signals but does not execute the timing check itself. NTC signals available for probing without violation messages. Designs with intentional negative timing check values where the NTC infrastructure is needed but resulting “violations” are expected and should not fire.
-notimingchecks is not the same as -nospecify: With -notimingchecks, path delays are fully active and signal propagation is correctly timed. Only the check evaluation is suppressed. This is safe when you need timing-accurate waveforms without managing violation noise.

πŸ“‹Local Control via Timing Files

A timing file (tfile) is a plain-text file passed at elaboration via a command-line switch. It configures timing check behaviour independently for different instances or subtrees β€” some fully active, others disabled, others with specific check types selectively suppressed. This granularity makes the timing file the preferred mechanism for production GLS.

Timing file structure

Each line begins with a keyword followed by arguments. Keywords are case-insensitive. Comments begin with // or ;.

// timing.tfile β€” production example

DEFAULT +tcheck              // all checks on by default

PATH top.u_cdc... -tcheck  // disable CDC subtree
PATH top.u_cdc.u_arb +tcheck  // re-enable arbiter inside CDC

PATH top.u_pll $width -tcheck  // only $width checks on PLL

CELLLIB sram_macro_lib -tcheck  // entire IP library

INCLUDE cpu_waivers.tfile    // modular sub-team waivers

πŸ“–Timing File Keywords Reference

KeywordSyntaxWhat it controls
DEFAULT DEFAULT [timing_spec] Sets default timing behaviour for all instances not explicitly targeted. +tcheck enables, -tcheck disables. Without DEFAULT, the simulator’s built-in default (all checks on) applies.
BASENAME BASENAME [path] [timing_spec] Specifies a base path prefix from which all subsequent PATH statements are interpreted. Useful when all waivers are within one sub-hierarchy β€” avoids repeating the full prefix on every line.
PATH PATH path_spec [check_type] timing_spec The workhorse keyword. Targets a specific instance or subtree. Optional check_type (e.g. $setup, $hold, $width) limits action to one check type. Without check_type, all checks on the matched path are affected.
CELLINST CELLINST [timing_spec] Applies specification to all instances tagged as cell instances in their subhierarchy β€” instances and all cells within their logic cone. Use for hard IP or macro blocks.
CELLLIB CELLLIB lib.cell:view [timing_spec] Applies to all instances of cells from a named library. Disables checks on all instances of a third-party IP library without listing every instance path.
INCLUDE INCLUDE timing_file Includes the contents of another timing file at this point. Enables modular organisation β€” one master tfile including per-block waivers maintained by individual teams.

🎯PATH Keyword and Hierarchy Wildcards

The PATH keyword matches instance paths in the simulation hierarchy. The ... (three dots) wildcard enables subtree targeting:

PATH syntaxWhat it matchesEffect
PATH top.u_cdcExactly the instance top.u_cdc β€” no descendantsChecks disabled only on u_cdc itself
PATH top.u_cdc...u_cdc AND all instances in its entire subhierarchyAll checks in u_cdc block disabled
PATH top.*All direct children of top (one level only)Checks on immediate children of top
PATH ...All instances in the entire designEquivalent to global disable via tfile
Figure 2 β€” PATH keyword: subtree disable with selective re-enable
top u_cdc PATH top.u_cdc… -tcheck sync_ff disabled (inherits) u_arb PATH …u_arb +tcheck u_cpu active (DEFAULT +tcheck) u_alu u_reg checks disabled checks active vlsitrainers.com

PATH hierarchy interaction. DEFAULT +tcheck enables all checks. PATH top.u_cdc… -tcheck disables checks throughout the u_cdc subtree β€” sync_ff inherits the disable. PATH top.u_cdc.u_arb +tcheck re-enables checks specifically for u_arb. u_cpu and its children remain active. This layered pattern β€” disable subtree, re-enable exceptions β€” is the standard approach for CDC waivers.

πŸ” Worked Example β€” Production tfile for a Mixed-Domain SoC

Design: SoC with a 1 GHz CPU, a third-party USB PHY, four CDC synchronisers, and a PLL. Expected violations: synchronisers (intentional metastability), PLL divider width checks (non-50% duty cycle by design), PHY IP (vendor recommends GLS check disable).

// soc_timing.tfile

DEFAULT +tcheck                        // 1. all checks on

// 2. CDC synchroniser subtrees β€” intentional metastability
PATH top.u_cdc_cpu_to_phy...  -tcheck
PATH top.u_cdc_phy_to_cpu...  -tcheck

// 3. Re-enable arbiters inside CDC β€” synchronous logic
PATH top.u_cdc_cpu_to_phy.u_arb +tcheck
PATH top.u_cdc_phy_to_cpu.u_arb +tcheck

// 4. Width checks on PLL divider β€” non-50% by design
PATH top.u_pll.u_divider $width -tcheck

// 5. Third-party USB PHY library β€” vendor recommendation
CELLLIB usb3_phy_lib -tcheck

// 6. Modular sub-team waivers
INCLUDE cpu_core_waivers.tfile
INCLUDE mem_subsystem_waivers.tfile

CDC paths are suppressed but their internal arbiters are not. The PHY library is globally suppressed. Width checks on one specific PLL node are suppressed. Everything else in the 1 GHz CPU core remains fully checked. Sub-team waivers are modularly included.

⚠️$setuphold Asymmetry in Timing Files

A critical subtlety concerns the relationship between combined checks ($setuphold, $recrem) and their individual counterparts ($setup, $hold, $recovery, $removal). The rules are asymmetric:

Figure 3 β€” $setuphold vs $setup/$hold tfile disable asymmetry
Case A β€” tfile $setup on a $setuphold model βœ“ Cell model has: $setuphold(CK, D, 50, 10, …) tfile entry: PATH top.u_ff $setup -tcheck Result: Works β€” $setup half disabled, $hold still active. β†’ Disabling a component of $setuphold works correctly. β†’ Same rule applies to $recrem / $recovery / $removal. Case B β€” tfile $setuphold on $setup/$hold model βœ— Cell model has: $setup(D, CK, 50) $hold(CK, D, 10) tfile entry: PATH top.u_ff $setuphold -tcheck Result: Does NOT work β€” both checks keep firing. β†’ Must use $setup and $hold separately as two lines. β†’ $recrem does NOT disable $recovery or $removal. vlsitrainers.com

$setuphold asymmetry. Case A (green): targeting the $setup component of a combined $setuphold model works correctly. Case B (red): targeting $setuphold against a model that uses separate $setup and $hold statements has no effect. The rule is one-way: combined keywords can disable parts of combined checks, but cannot disable individual checks.

The asymmetry rule: A combined keyword in a tfile ($setuphold, $recrem) can disable component parts of a combined check in the cell model. But it cannot disable individual checks ($setup, $hold). To disable those, list them explicitly as separate PATH lines.

⏱️Runtime Disable via tcheck Command

The tcheck command toggles timing check messages and notifier updates on or off for a specified instance during the simulation run β€” at any simulation time point.

// Syntax
tcheck <instance_path> -off | -on

// Examples
tcheck top.u_cdc.sync_ff[0] -off  // silence this FF
tcheck top.u_cdc.sync_ff[0] -on   // re-enable it
tcheck top.u_cpu...           -on   // whole subtree

Use tcheck for interactive debugging only: silencing a specific instance while examining another, scripted debug sequences around known-noisy operations, isolating the failing signal. It should never be used as a production waiver mechanism.

tcheck does not improve simulation performance. Timing check logic is already compiled into the simulation at elaboration β€” checks still evaluate every clock edge. Only reporting and notifier update is suppressed. If performance improvement is needed, the timing file approach (which prevents check compilation) is correct.

πŸ”€Choosing the Right Mechanism

Figure 4 β€” Decision flowchart: which mechanism to use
Running zero-delay or unit-delay mode? YES Use -nospecify Global, elaboration NO Suppress ALL timing checks globally? YES -notimingchecks Delays still active NO Target specific instances / subtrees? YES Timing file (-tfile) Production waivers Debug only tcheck command Runtime, interactive vlsitrainers.com

Decision flowchart. Zero-delay mode uses -nospecify. Suppressing all checks while keeping delay accuracy uses -notimingchecks. Targeted production waivers for CDC, false paths, or IP belong in a timing file. Interactive debug during a running simulation uses tcheck β€” but should be converted to a tfile entry if it needs to persist across runs.

πŸ”¬VLSI Connections

πŸ”¬ The tfile as a formal verification closure document

In a real SoC tape-out project, the timing file grows throughout the project schedule. At first it is nearly empty β€” all checks active, every violation investigated. As the project matures, verified CDC crossings, characterised false paths, and approved IP blocks are added one by one, each with a comment giving the justification and the engineer who signed off. By tape-out, a large SoC tfile may contain hundreds of entries. This file becomes a formal project document reviewed by lead verification and design engineers as part of signoff checklist review. The principle is: a timing violation appearing in GLS must either be fixed by backend ECO or waived by tfile entry with documented justification. An unexamined violation is never acceptable for signoff. Managing the tfile is therefore part of the formal verification closure process, not a simulation technicality.

πŸ”¬ -notimingchecks and NTC delayed signal side effects

The -notimingchecks switch disables timing check evaluation but leaves path delays active. However, it has an important side effect on NTC (Negative Timing Check) signals. NTC delays are generated for flip-flops with negative setup or hold values β€” they create delayed versions of clock and data signals used internally by the timing check. If -notimingchecks is used, these NTC delayed signals are not generated. On designs with NTC flip-flops, this changes functional simulation behaviour because the NTC-delayed signals were driving downstream logic. The safer alternative is -ntcnotchks β€” which generates NTC signals (preserving functional behaviour) but suppresses timing check evaluation and violation messages. This distinction matters most at advanced nodes where negative hold values are common in standard cell libraries.

πŸ”¬ Timing check density and GLS performance

Timing check evaluation is one of the largest contributors to GLS simulation run time. A design with 500,000 flip-flops, each with a $setuphold check, generates 500,000 evaluations per clock edge. At 1 GHz with billions of simulation time steps, the total check evaluations are astronomically large. Modern simulators batch and optimise these evaluations, but the overhead remains significant. The timing file approach reduces this directly β€” a check removed at compile-time elaboration is never evaluated at runtime. On a large SoC where CDC waivers and IP blocks represent 20–30% of all flip-flops, a well-maintained tfile can reduce timing check evaluation overhead by that same proportion, directly shortening GLS turnaround times. This is why performance is a legitimate motivation for tfile entries alongside correctness motivations β€” the two goals reinforce each other.

Summary β€” GLS-04 key points: Four legitimate reasons to disable timing checks: CDC synchronisers (intentional metastability), false paths, hard IP with known-conservative checks, and performance. Three mechanisms: global switches (entire design, elaboration time), timing file (-tfile, per-instance or per-subtree, elaboration time, improves performance), runtime tcheck command (per-instance toggle during simulation, no performance benefit, debug only). Global switches: -nospecify (all timing including delays), -notimingchecks (checks only, delays active), -nonotifier (notifier propagation), -no_tchk_msg (messages only), -ntcnotchks (NTC signals without check execution). Timing file keywords: DEFAULT, BASENAME, PATH, CELLINST, CELLLIB, INCLUDE. PATH with … targets entire subhierarchies; without … targets exact instance only. PATH with check type (e.g. $setup) targets only that check type. $setuphold asymmetry: combined keyword can disable components of a combined check model, but cannot disable individual $setup/$hold checks β€” those must be listed separately. The tfile is the production waiver mechanism; every entry requires documented justification; it is a formal signoff document.
Scroll to Top