AdvancedQuestion 36 of 63Source: Synopsys PrimeTime User Guide: Timing Paths and Exceptions

How do you find out which of two conflicting timing exceptions on the same path wins?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

Short Answer

report_timing -exceptions dominant (PT) reports the single exception that actually governs a specific path, and report_timing -exceptions overridden (PT) shows any others that were considered but lost, when more than one exception-setting command touches the same points. As a general precedence rule, set_max_delay (SDC) outranks set_multicycle_path (SDC) on the same path, so an explicit maximum-delay override wins even if a multicycle exception was written for the same through-point.

Technical Reference DiagramHow do you find out which of two conflicting timing exceptions on the same path wins?
A path passing through buffer buf1/Z with two overlapping exception arrows - a set_multicycle_path -setup 2 command and a set_max_delay 1 command - and a report_timing box below labeling set_max_delay as dominant and set_multicycle_path as overridden for that path

Technical Explanation

  • More than one exception command can legally target the same path. A set_multicycle_path -through buf1/Z -setup 2 (SDC) and a set_max_delay -through buf1/Z 1 (SDC) can both be written for paths passing through the same point, and PrimeTime has to pick one.
  • report_timing -exceptions dominant (PT) names the winner for one specific path. It adds a section to the timing report showing exactly which exception-setting command actually governs the check being reported.
  • report_timing -exceptions overridden (PT) shows what lost, for the same path. This is the complement of the dominant view - it lists exceptions that were legally applicable but set aside in favor of a higher-priority one.
  • report_timing -exceptions all (PT) combines both views in a single report. It is the option to reach for when auditing a path where you are not yet sure whether a conflict even exists.
  • A conflicting set_max_delay (SDC) generally beats a set_multicycle_path (SDC) on the same path. In the buf1/Z example, the explicit maximum-delay value takes priority over the multicycle exception even though both were legally written for paths through that point.
  • Reading unconstrained-path reasons through -exceptions all requires a variable set first. Before using report_timing -exceptions all (PT) or get_timing_paths (PT) to explain why a path is unconstrained, the timing_report_unconstrained_paths variable must be set to true, or the extra reasons will not appear.

Common Mistake

  • Writing a set_multicycle_path -through (SDC) command for a shared point in the design without checking whether a set_max_delay (SDC) command already targets the exact same point.
  • The two are not merged or averaged - one wins outright, and set_max_delay typically outranks set_multicycle_path on a path they both apply to, so the multicycle relationship the author intended may never actually take effect.
  • Cost: a designer tunes a multicycle exception's cycle count expecting it to relax the setup check, while a pre-existing max-delay command on the same through-point is the one actually deciding the required time, and the tuning has no effect at all.

Follow-up Question & Model Response

If report_timing -exceptions all on a path shows both a dominant set_max_delay and an overridden set_multicycle_path, is the multicycle command doing anything useful at all, or should it simply be deleted?

Candidate Model Response: Not necessarily useless - it depends on whether the max-delay command is a permanent, intentional constraint or a temporary override that might later be removed or narrowed in scope. If the max-delay command is scoped more broadly than the multicycle command, for example covering more through-points or a different set of corners, deleting the multicycle command could leave a gap once the max-delay command is eventually tightened or removed. The safer move is to check why both were written in the first place, since an overridden exception that was clearly meant to be a fallback is very different from one that was written by mistake without realizing a broader exception already existed.

Practical Example

A path passes through buffer buf1/Z, where two exception commands both apply: set_multicycle_path -through buf1/Z -setup 2 (SDC), written to relax the setup check to two cycles, and set_max_delay -through buf1/Z 1 (SDC), written earlier by a different engineer to cap the same path's delay at 1ns outright. Running report_timing -exceptions dominant (PT) on that path shows the set_max_delay command as the dominant exception, meaning the 1ns cap - not the two-cycle relationship - is what actually determines the required time; report_timing -exceptions overridden (PT) on the same path confirms the multicycle command is present but has no effect on this particular path at all.

Complete STA Handbook

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

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