ExpertQuestion 49 of 69Source: Synopsys PrimeTime User Guide: Exception Order of Precedence

When set_false_path, set_max_delay, and set_multicycle_path all match the same path, what order of priority decides which one PrimeTime actually applies?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

PrimeTime applies exception precedence independently to each path, not each command, and among conflicting exception types the fixed order is set_false_path first, then set_max_delay/set_min_delay, then set_multicycle_path last. When two or more of these types genuinely conflict on the same path, only the highest-ranked one takes effect and the others are silently ignored for that path.

Technical Reference DiagramWhen set_false_path, set_max_delay, and set_multicycle_path all match the same path, what order of priority decides which one PrimeTime actually applies?
Priority ladder diagram: set_false_path at top, set_max_delay/set_min_delay in the middle, set_multicycle_path at the bottom, with a path matching both false_path and multicycle showing the multicycle setting struck through as ignored

Technical Explanation

  • The tool checks exception conflicts per path, meaning the same two commands can both apply — one to some paths, the other to different paths — with only the truly overlapping paths resolved by the priority rule.
  • The fixed type priority, highest to lowest, is: set_false_path, then set_max_delay/set_min_delay together, then set_multicycle_path.
  • Some pairs are never considered in conflict at all and both stay active together: two separate set_false_path settings, set_min_delay paired with set_max_delay, and set_multicycle_path -setup paired with set_multicycle_path -hold.
  • If a path is declared false and also given a maximum delay value, the false-path declaration wins outright and the maximum delay setting is simply ignored for that path — not merged, not averaged, just dropped.
  • This priority is independent of which command was written first or last in the SDC file — order of appearance in the script has no effect on type priority, only on path-specification priority, the separate rule for -from/-to/-through specificity, when two commands of the same type conflict.
  • report_exceptions -ignored (PT) lists every exception the tool computed but did not apply because a higher-priority exception won on that path, which is the only reliable way to see this resolution happening.
  • This precedence check happens automatically on every timing update, silently, with no message printed to the log by default — the only way to surface it is to explicitly ask for the ignored-exception report, which is why teams that never run it can carry a shadowed exception for years without noticing.
  • What breaks: a designer who intends a multicycle path to relax a specific route, while an earlier, broader false-path command already covers part of that same route, never sees the multicycle setting apply there — and without checking -ignored, has no way to know the multicycle exception was silently dropped.

Common Mistake

The Trap: Assuming that adding a set_multicycle_path command guarantees the specified relaxation applies, without checking whether an existing set_false_path or set_max_delay command already covers the same path with higher priority.

  • The multicycle setting is accepted by the SDC parser with no error or warning, so the mistake produces no visible symptom in the constraint file itself.
  • The path is either still marked false, with no timing checked at all, or still bound by the max-delay value, and the engineer who added the multicycle exception assumes it is now governing the path when it never was.

Follow-up Question & Model Response

"If I suspect a multicycle exception I wrote is being overridden, how do I confirm it and find out which command is winning?"

Candidate Model Response: Run report_exceptions -ignored -to [endpoint] (PT) on the specific endpoint the multicycle path targets; if the multicycle setting appears in that list, the report also names the higher-priority exception that overrode it. From there, decide whether the false-path or max-delay command was actually meant to cover that specific route — if not, narrow its -from/-through/-to scope so it no longer overlaps the path the multicycle exception is meant to relax. This is far more reliable than inferring the conflict from timing report numbers alone, since an ignored multicycle exception produces no distinct symptom of its own.

Practical Example

A datapath multiplier output feeds an accumulator over three cycles, so the team writes set_multicycle_path 3 -setup -from mult/Q -to acc/D (SDC). Weeks earlier, a broader set_false_path -from mult/Q had been added to cover an unrelated bypass mode. report_exceptions -ignored -to acc/D shows the multicycle setting listed as overridden by the earlier false-path command, meaning the accumulator path was never timed at all — a real functional path with three legitimate clock cycles to settle had been mistakenly excluded from checking entirely.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →
Timing Constraints (SDC) Handbook — nine chaptersSDC ConstraintsNine chapters on clocks, exceptions, and constraint linting. →

Continue practising

Related STA questions

ExpertHow do -through points combine across multiple set_false_path commands, and why is that different from listing several -through points in one command?BeginnerWhat is a multicycle path?AdvancedWhy does setting only -setup 2 create a hold problem? Walk the edges.ExpertHow do you find every timing exception in a design that PrimeTime silently ignored because a higher-priority exception overrode it on the same path?