How do you find out which of several overlapping timing exceptions actually applied to a path?

Short Answer

report_exceptions (PT) lists every timing exception currently set, including which ones a later, higher-priority exception overrode or which were ignored entirely because a more specific exception already covered that path. Reading that report -- rather than trusting that a set_false_path or set_multicycle_path (SDC) command you wrote was applied -- is the only reliable way to confirm which exception actually reached a given path when several could plausibly match it.

Technical Explanation

PrimeTime resolves overlapping exceptions two separate ways: across exception types, a fixed order applies (set_false_path beats set_max_delay/set_min_delay, which beat set_multicycle_path (SDC)); within one type, a more specific exception -- one naming exact pins instead of a whole clock -- wins over a broader one covering the same path. set_case_analysis (SDC) is the one exception where plain write order decides instead: a newer setting on the same pin overrides an older one.

• Because exception resolution happens automatically and silently during a timing update, a designer who writes several exceptions covering overlapping sets of paths cannot tell from the SDC file alone which one actually governs any specific path.
• report_exceptions (PT) reports the full set of exceptions currently active, and report_exceptions -ignored (PT) specifically reports exceptions that were entered but never actually matched or were fully overridden, which is the direct way to catch a false path or multicycle command that silently did nothing.
• report_timing (PT) also shows, in its header or annotation, which exception, if any, applied to the specific path being reported, so cross-checking a suspicious path's report_timing output against report_exceptions confirms the two agree.
• The command causes a complete timing update to resolve which exception wins where, so it should be run after loading the full exception set, not incrementally after each individual set_false_path (SDC) command, or the resolution shown may not reflect the final combined state.
• Preserving source location information when writing exceptions -- annotating which SDC line created each one -- makes a report_exceptions (PT) output far more actionable, since a designer debugging an overridden exception can trace it straight back to the specific script line responsible instead of searching the whole constraint set.

Follow-up Question & Model Response

If report_exceptions shows an exception as ignored, does that mean it had no effect at all on the design's timing?

Candidate Model Response: An exception reported as ignored had no effect on the specific paths another, higher-priority exception already claimed, but it can still apply to other paths not covered by that overriding exception -- ignored is reported per matched-path overlap, not as a blanket statement about the whole exception. The designer needs to check exactly which paths the ignored exception was written to cover, then confirm whether every one of those paths was actually claimed by the overriding exception, or only some of them. A partial overlap is the more dangerous case, since some of the intended paths get the new exception's treatment while others silently fall back to whatever the overriding exception specifies instead. This is exactly why narrowing down report_exceptions output to the specific paths in question, rather than reading the ignored flag as pass-or-fail, is the reliable way to close out this kind of ambiguity.