Timing exceptions

In short: Timing exceptions tell static timing analysis which paths to ignore (false paths) or relax (multicycle paths), and set_case_analysis fixes constant pins so dead logic is pruned — but each one is a promise to the tool that, if wrong, silently hides real violations or wastes area over-constraining the design.

Every digital block reaches a point where the timing report screams about paths that can never actually fail. A reset-synchronizer output feeding a data path. A configuration register that changes once at boot and then sits still for a billion cycles. A clock-domain crossing where a two-flop synchronizer already handles metastability. Static timing analysis (STA) is pessimistic by construction: it assumes every topological path is a real, single-cycle functional path unless you tell it otherwise. Timing exceptions are how you tell it otherwise.

Get them right and your design closes with realistic constraints. Get them wrong and you either ship a chip with an undetected hold or setup failure, or you burn gates and power fighting a path the silicon never exercises. This is why timing-exception review is a standard checklist item in every serious signoff flow, and why interviewers love to probe it.

The four tools in the box

In Synopsys PrimeTime, Design Compiler, and Cadence Genus/Tempus the same four commands dominate:

• set_false_path — remove a path from timing analysis entirely. The tool stops checking setup and hold on it.
• set_multicycle_path — allow a path more than one clock cycle to propagate (or relax hold accordingly).
• set_case_analysis — pin a net to a constant 0 or 1, propagating it to prune unreachable logic and select a mode.
• set_disable_timing — break timing through a specific arc (e.g. a mux select that is tied in one mode), narrower than a false path.

Exception priority matters: when multiple exceptions touch the same path, tools apply a fixed order — set_false_path > set_case_analysis-implied > set_multicycle_path > set_max_delay/set_min_delay. A false path always wins, which is exactly why a sloppy wildcard false path is dangerous.

False paths: real structure, impossible activation

A false path is a connection that exists in the netlist but can never be sensitized as a single-cycle timing-critical path during functional operation. Classic examples:

• Asynchronous clock-domain crossings. A flop in a 400 MHz domain feeding a flop in a 150 MHz domain through a proper synchronizer. The two clocks are asynchronous, so there is no meaningful setup relationship — constrain it with set_clock_groups -asynchronous or an explicit set_false_path between the domains.
• Static configuration registers. A mode register written once by firmware. Its combinational fanout into a data path is logically real but is quasi-static.
• Mutually exclusive mux paths. Two selects that hardware guarantees can never both route the critical arc.

Multicycle paths: slow by design, not by accident

A multicycle path (MCP) is a real functional path that is architecturally guaranteed more than one clock period to settle before its result is captured. Think of a multiplier whose output is only sampled every third cycle because the surrounding FSM holds the enable low for two cycles, or a path between an enabled register that toggles every N cycles.

The subtlety that catches engineers — and interviewers exploit this relentlessly — is the hold multicycle. When you write set_multicycle_path 3 -setup, you move the setup capture edge out by two cycles. But hold is checked one edge before the setup capture edge by default, which now lands at the wrong place. You almost always need a companion set_multicycle_path 2 -hold (generally N-1) to pull the hold check back to the launch edge. Forget it and the tool demands enormous hold buffering that the design does not need.

set_case_analysis: pruning and mode selection

Where false paths and MCPs reshape checks, set_case_analysis reshapes the logic the tool sees. Setting a scan-enable pin to 0 tells STA that functional mode is active, so all scan-shift paths vanish from the picture. Setting a test-mode or BIST select constant lets you analyse one operating mode cleanly. The constant propagates forward: a set_case_analysis 0 on one leg of an AND gate makes the whole output constant, collapsing entire cones of logic.

This is the standard way to analyse a chip with multiple functional modes using MMMC (multi-mode multi-corner) setups — each mode is often just a different set of case-analysis values layered on a shared netlist. Because it prunes logic rather than merely skipping checks, set_case_analysis is also the cleanest way to avoid analysing impossible test states in functional signoff.

Over-constraint: the quieter failure

Under-constraining (too many false paths) is dangerous because it hides violations. Over-constraining is sneakier because the chip still works — it just costs more than it should. A false path that should have been a multicycle path, or a set_max_delay tighter than the real requirement, pushes synthesis and place-and-route to insert buffers, upsize cells, and spend power meeting a target nothing actually needs. On a large SoC this routinely translates into measurable area and leakage you can never recover.

A disciplined rule: never write a wildcard exception like set_false_path -from [all_registers] to silence a report. Always identify the exact start and end points, document why the path is false or multicycle, and review every exception at signoff. An undocumented exception is a latent bug.

Teams that build silicon — including design-services groups like Avecas — treat the exception file as a first-class, version-controlled, reviewed artifact, not a scratchpad for making warnings disappear.

A practical workflow

• Start with set_clock_groups for genuinely asynchronous or physically-exclusive clocks instead of hand-written false paths — it is less error-prone and self-documenting.
• Apply set_case_analysis first to establish the mode, then add MCPs, then false paths only for what remains.
• For every MCP, immediately write the -hold companion.
• Run report_timing -exceptions / report_exceptions and check for ignored or overlapping exceptions.
• Cross-check against the RTL designer's intent — an exception is a claim about architecture, and only the architect truly knows if it is true.

Want to go from reading timing reports to confidently closing a block? Our CourseTron STA & Physical Design track walks through real exception files, hold-MCP debugging, and signoff checklists on industry tools. Start learning the way interviewers expect.

Frequently asked questions

What is the difference between a false path and a multicycle path?

A false path is never a valid single-cycle timing path and is removed from analysis entirely — STA checks neither setup nor hold. A multicycle path is a real functional path that is simply allowed more than one clock period, so STA still checks it, just against a relaxed capture window.

Why do I need a separate hold multicycle constraint?

When you push the setup capture edge out by N cycles, the default hold check moves with it and lands one edge before the new capture edge, which is pessimistic and wrong. Adding set_multicycle_path N-1 -hold pulls the hold check back to the launch edge where it belongs, avoiding unnecessary hold buffers.

Does set_case_analysis remove timing checks like a false path?

No. It forces a net to a constant and propagates that value, which prunes unreachable logic as a side effect. It changes what logic the tool analyses rather than selectively skipping checks on an otherwise-live path.

What happens if I over-constrain with too many false paths?

The tool stops checking those paths, so a genuine setup or hold violation on them goes undetected and can cause the chip to fail in silicon. This is why every false path must be justified and reviewed at signoff.