Timing-exception candidates

A timing exception — set_false_path, set_multicycle_path, set_max_delay — removes or relaxes a path in static timing analysis. That makes it the single highest honesty-risk artifact in the timing flow: an unjustified exception silently hides a real violation. This guide explains what these exceptions do, why a tool can only ever suggest a candidate with an explicit assumption, and the small set of candidates that can be derived soundly from RTL structure.

What a timing exception does — and why that is dangerous

Static timing analysis checks that every path closes against the clock. A timing exception tells STA to stop checking a path, or to give it more time. set_false_path removes the path from analysis entirely; set_multicycle_path allows it several clock periods instead of one; set_max_delay relaxes its bound. When the exception is correct, it stops STA wasting margin on a path that genuinely is not exercised at speed. When it is wrong — the path is exercised — STA no longer reports the violation, and the chip ships with a timing bug that has vanished from every report. An exception can turn a real failure into a silent pass, which is exactly the failure mode an honest tool must refuse to create.

An exception is an assertion, not a fact

The reason a tool cannot simply prove an exception is that every exception encodes a claim about how the design is operated, not just how it is wired. A false path between two clocks asserts they never interact at speed. A multicycle path asserts an enable fires at most every N cycles. A relaxed config path asserts the configuration is stable while the datapath that reads it is running. Those are facts about intended use. A structural tool can recognise the shape that usually justifies an exception and surface it as a candidate together with the assumption that has to hold — but the engineer owns the justification.

False-path candidate: a clock-domain crossing

The most common false-path candidate is a register-to-register path that crosses an asynchronous clock domain. Once a proper synchronizer is in place, the raw combinational path through the crossing is not meant to be timed, and it is conventionally constrained with set_false_path or set_max_delay. The stated assumption is that the synchronizer exists — which a separate CDC analysis reports on. The exception is a candidate to apply after CDC closure, not a substitute for it.

# False-path CANDIDATE (SDC). Conventionally applied to a register->register
# path that crosses an asynchronous clock domain, ONCE a synchronizer is
# confirmed. The constraint tells STA to stop timing the crossing.
#   ASSUMPTION: a proper CDC synchronizer exists on this crossing.
#   This is a CANDIDATE for review, not a proven false path.
set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b]

Multicycle candidate: a counter-decoded enable

A destination flop whose clock enable is the decoded terminal count of a free-running counter (en = (cnt == K) with cnt <= cnt + 1) cannot capture every cycle, so its data path may legitimately take more than one clock period. That is a multicycle-path candidate, with the assumption that the counter period is what it appears to be. When the terminal count is not a resolvable literal, the candidate is surfaced as “N>1, unverified” rather than guessed.

# Multicycle-path CANDIDATE (SDC). The destination flop is gated by an enable
# that is the decoded terminal count of a free-running counter, so it cannot
# assert every cycle:  en = (cnt == K);  cnt <= cnt + 1;
#   ASSUMPTION: the enable asserts at most once every N cycles (N = K+1).
#   Verify the counter period before applying. CANDIDATE, not a fact.
set_multicycle_path 4 -setup -to [get_pins acc_reg/D]
set_multicycle_path 3 -hold  -to [get_pins acc_reg/D]

Static / config-register candidate

A register written only under an externally driven write-enable (a primary input with a config/write name) and read by combinational datapath logic is a quasi-static path. It is a candidate to relax, with the assumption that the configuration is stable during operation — not written while the datapath that reads it is active. As with the others, the structure makes it a candidate; the operating assumption makes it legitimate.

The honesty contract

A sound timing-exception workbench follows one non-negotiable rule: every finding is a candidate, never a stated “false path” or “multicycle path” as fact, and every candidate carries the assumption that must hold for it to be applied. The tool deliberately derives only the candidates it can derive soundly and skips the rest, because a missing candidate is safe while a wrong one is dangerous. It produces exploration evidence to help an engineer write and justify the right SDC constraints — it never signs off timing.

How ChipVerify AI helps

ChipVerify AI (a pre-signoff RTL evidence tool, currently in closed beta, not a foundry signoff tool) runs a deterministic structural analysis that surfaces false-path, multicycle, and static-register exception candidates with their assumptions stated, so you can review and justify each one before it ever reaches an SDC file. It will not assert an exception as a fact, because that is the one move that can hide a real timing violation.

Related reading

• Setup & hold time and STA basics — the timing checks an exception removes or relaxes.
• Clock domain crossing (CDC) — the assumption behind most false-path candidates.
• Tapeout readiness — timing closure as a signoff line item.
• Verification waivers — the same audit-trail discipline an exception deserves.

Try the public scanner at /tinytapeout or request access.

FAQ