ExpertQuestion 66 of 69Source: Synopsys PrimeTime User Guide: Timing Exception Priority and report_timing -exceptions

Why does report_timing -exceptions dominant show a different exception than the one you actually wrote?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

When two timing exceptions apply to overlapping parts of the same path, PrimeTime enforces only one of them, the dominant one, based on a fixed priority order, not the order they were written in the SDC. report_timing -exceptions dominant (PT) shows which exception actually won, which can be a set_max_delay (SDC) or set_false_path (SDC) command instead of the set_multicycle_path (SDC) you may have written for that same path, if a higher-priority exception also touches it.

Two overlapping exceptions on the same buffer output net, set_multicycle_path and set_max_delay, with report_timing -exceptions dominant showing the max-delay exception winning until its -through scope is narrowed to just the control signal. — Technical Reference DiagramWhy does report_timing -exceptions dominant show a different exception than the one you actually wrote?

Technical Explanation

PrimeTime resolves overlapping exceptions with a fixed priority, and in general a max-delay or false-path style exception outranks a multicycle-path exception when both cover the same path segment.
report_timing -exceptions dominant (PT) reports only the exception that actually governs the path's timing check, which is the one worth debugging if the timing looks wrong.
report_timing -exceptions overridden (PT) instead lists exceptions that were written but lost to a higher-priority one on that path, which is the view that explains why your intended exception did not take effect.
report_timing -exceptions all (PT) shows both together, which is the most complete view when you are not yet sure which exception is winning.
Because exception priority does not depend on write order in the SDC file, writing the multicycle path after the max-delay command does not change which one wins; only the exception type and its scope over the path matter.
report_exceptions -ignored (PT) is the companion check for paths where an exception was entirely rejected, for example because it referenced an invalid startpoint, rather than merely overridden by a higher-priority one.
Because two exceptions rarely need to cover the exact same path segment on purpose, a dominant-exception surprise is usually a sign that one exception's -through, -from, or -to scope is broader than the engineer who wrote it intended.
This kind of overlap tends to appear when two engineers, or two design revisions, write exceptions for the same shared logic independently, each assuming their own command is the only one touching that path.
Because the dominant exception can change as SDC files are merged or updated across a project, it is worth re-checking report_timing -exceptions dominant after any significant constraint file change, not only when a path's slack looks surprising.

Common Mistake

The Trap: assuming a set_multicycle_path (SDC) command has taken effect just because PrimeTime does not report an SDC error, without checking whether a broader set_max_delay or set_false_path on the same path is silently overriding it.

Debugging a path's slack by only reading the SDC file, instead of asking PrimeTime which exception it actually applied, can lead to editing the wrong command entirely.
Assuming exception priority follows the order commands appear in the constraints file, rather than a fixed type-based ranking, leads to reordering SDC lines that changes nothing.

Follow-up Question & Model Response

If a max-delay exception is overriding your multicycle path on part of a shared bus, how do you get both exceptions to coexist correctly?

Candidate Model Response: The usual fix is to narrow the scope of each exception with -through, -from, or -to (SDC) so they no longer cover the exact same path segment, rather than trying to change which one wins. Since -through order matters and changes which paths are excluded when combined with other exceptions, tightening the through-points on the max-delay exception to only the specific net it must cover can free up the rest of the shared bus for the multicycle exception to apply as intended. Verifying the result with report_timing -exceptions dominant (PT) on a representative path confirms each exception now governs only the segment it was meant to.

Practical Example

A design applies set_multicycle_path -through buf1/Z -setup 2 (SDC) to relax a slow datapath crossing a shared buffer, but a separate set_max_delay -through buf1/Z 1 (SDC) command, added earlier for an unrelated timing-critical control signal through the same buffer, also touches that path. Running report_timing -exceptions dominant (PT) on the datapath shows the 1ns max-delay exception, not the multicycle exception, governing the check, exactly the priority rule the reference documentation describes for conflicting exceptions at the same point. Narrowing the max-delay command's -through list to the specific control-signal net, instead of the whole buffer, lets the multicycle exception apply correctly to the datapath without weakening the control signal's own constraint.

Complete STA Handbook