How do you find every timing exception in a design that PrimeTime silently ignored because a higher-priority exception overrode it on the same path?

Short Answer

report_exceptions -ignored (PT) lists every exception command the tool computed but did not apply, because a higher-priority exception — by type or by specificity — already governed that path. Running it across the whole design after every exception file is loaded is the only systematic way to catch an exception that was accepted by the SDC parser but never actually took effect on any path.

Technical Explanation

• report_exceptions -ignored (PT) reports exceptions that lost a precedence conflict, whether the conflict was decided by exception-type priority (false path over max delay over multicycle) or by path-specification priority (pin beats clock, more -from/-to specificity beats less).
• An exception can be entirely ignored, meaning every path it might have matched is instead governed by something else, or partially ignored, still applying to some paths just not the ones a more specific or higher-priority command also covers — the report distinguishes these cases per path.
• Because the SDC parser accepts a syntactically valid exception whether or not it ever actually governs a path, there is no error or warning at load time for an exception that turns out to be fully shadowed by another command.
• Running the report requires a full timing update first, since exception resolution is computed as part of timing analysis, not at parse time — this makes the check relatively expensive to run casually, so it belongs at defined checkpoints, post-SDC-review and pre-signoff, rather than after every edit.
• Scoping the report with -from, -to, or -through arguments matching the exception under review narrows the output to just the paths that command was intended to cover, which is far faster to interpret than the full-design report on a large SoC.
• The report is especially valuable after SDC changes made by someone other than the original author, since an inherited constraint file can carry exceptions whose intent nobody remembers, and only this report shows which ones are actually doing anything.
• What breaks if this check is skipped entirely: constraint files accumulate exceptions that look intentional and reviewed but have been dead, fully overridden, for years, giving false confidence that a relaxation or exclusion is in effect when it never has been.

Follow-up Question & Model Response

"Should this check run on every regression, or only at specific points in the flow?"

Candidate Model Response: Because it requires a full timing update and produces a report sized to the whole exception set, it is better run at defined checkpoints — after a significant SDC change, before each signoff milestone — rather than on every incremental regression where the runtime cost outweighs the benefit. At those checkpoints, diff the ignored-exception list against the previous checkpoint's list, since a newly-ignored exception that used to be active is a much stronger signal of an unintended interaction than the long-standing, already-reviewed entries that show up every time.