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

Why does a more specific -from pin -to pin exception override a more general -from clock exception, even if the general one was written into the SDC first?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Path specification priority in PrimeTime is based entirely on how specific the object types named in -from/-to/-through are, not on the order the commands appear in the SDC file. A command naming exact pins ranks above one naming a clock, so the pin-level command wins on any path both commands touch, regardless of which line was written earlier.

Technical Reference DiagramWhy does a more specific -from pin -to pin exception override a more general -from clock exception, even if the general one was written into the SDC first?
Priority ladder for path specification: -from pin/-to pin at top overriding a -from clock/-to clock command written earlier in the SDC, with the clock-level command still governing non-overlapping paths

Technical Explanation

  • The path-specification priority order, from highest to lowest, is -from pin (or -rise_from/-fall_from pin), then -to pin (or -rise_to/-fall_to pin), then -through (or -rise_through/-fall_through), then -from clock, then -to clock.
  • This ranks pins and ports as more specific than clocks, because a pin-level constraint names an exact object while a clock-level constraint sweeps in every path launched or captured by that clock.
  • When two commands of the same exception type conflict — for example two set_max_delay commands — the tool starts at the top of that priority list and works down until the conflict resolves, so a command matching on -from pin beats one matching only on -from clock, even for the subset of paths both commands would otherwise cover.
  • The remaining paths that the more general command covers, but the more specific command does not touch, are still governed by the general command — only the overlapping paths are decided by priority.
  • Combining -from and -to specificity compounds this: a command with both -from pin and -to pin outranks one with only -from pin, which in turn outranks one with only -from clock and -to clock.
  • Write order in the SDC file plays no role in this resolution at all — it only matters for a narrower case within the "newer setting has priority" rule that applies to some other constructs like set_case_analysis, which this priority mechanism does not use.
  • This is a common source of confusion for engineers coming from constructs that genuinely are order-dependent, since the mental model of "the last thing I wrote wins" is correct for some SDC commands and simply wrong for exception path specifications.
  • What breaks: a designer relies on write order to override an earlier general command, adds a new general command later expecting it to take precedence, and finds the original, more specific command from earlier in the file still governs the overlapping paths.

Common Mistake

The Trap: Assuming that a later set_max_delay or set_false_path command in the SDC file automatically overrides an earlier, more general one for the same paths, the way set_case_analysis settings do.

  • A designer adds a new, broader -from [get_clocks CLK1] command near the bottom of the file, intending it to supersede an older, narrower -from pin -to pin command written earlier.
  • report_exceptions still shows the original pin-specific command governing those paths, because specificity — not file order — decided the outcome, and the intended change never took effect.

Follow-up Question & Model Response

"If specificity decides everything, how do I deliberately override an old pin-level exception with a new, more general one?"

Candidate Model Response: You cannot override it by adding a more general command — the priority rule always favors the more specific object type, so the new general command will simply govern only the paths the old, specific command doesn't already cover. The correct approach is to remove or edit the original pin-level command directly, since that is the only way to change what governs those exact pins. report_exceptions -from [pin] -to [pin] (PT) confirms which command is actually in effect on the specific paths in question before and after the change.

Practical Example

An early-flow SDC sets set_max_delay 15 -from [get_clocks CLK1] -to [get_clocks CLK2] (SDC) to bound every CLK1-to-CLK2 crossing. Later, a specific handshake register needs a tighter number, so the team adds set_max_delay 12 -from [get_pins sync_ff/Q] -to [get_pins capture_ff/D] (SDC) after it in the file. report_exceptions -from sync_ff/Q -to capture_ff/D confirms the 12 ns pin-level value governs that one path, while every other CLK1-to-CLK2 crossing still uses the 15 ns clock-level value — exactly the selective override the pin-level specificity was meant to provide.

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 →
Static Timing Analysis (STA) Handbook — ten chaptersSTA HandbookTen chapters on setup, hold, OCV, and PrimeTime signoff. →

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?ExpertWhen 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?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?ExpertWhat is the difference between set_false_path/set_max_delay and the more surgical set_disable_timing, and how does exception precedence resolve conflicts between them?