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

How do you tell whether a timing exception actually matched the path you intended?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

report_exceptions (PT) lists every exception-setting command and flags each one with a letter code when part or all of it was ignored - f for an invalid startpoint, t for an invalid endpoint, p for a non-existent path, and o for a path overridden by a higher-priority exception. A command that is fully ignored does not show up in the default report at all; report_exceptions -ignored (PT) is what surfaces those completely silent failures.

Technical Reference DiagramHow do you tell whether a timing exception actually matched the path you intended?
A small circuit with ports A, B, C feeding through buffers u0, u1, u2 to port D; a set_false_path arrow from A to D shown as the dominant exception, and a set_multicycle_path command covering A, B, and C to D shown split into three outcomes labeled o (overridden), valid, and f (invalid startpoint)

Technical Explanation

  • Exception commands can be partially ignored, fully ignored, or fully enforced, and the report distinguishes all three. report_exceptions (PT) by default shows commands that are fully valid or only partially ignored - a command that is completely overridden by something else does not appear unless you ask for it.
  • report_exceptions -ignored (PT) is the option that surfaces fully-ignored commands. Without it, a set_multicycle_path or set_false_path (SDC) command that was entirely overridden by a higher-priority exception looks like it was never even written.
  • The letter codes in the "Ignored" column say exactly why. f means an invalid startpoint, t an invalid endpoint, p a non-existent path between the named points, and o a path overridden by another exception command with higher priority.
  • A command naming several paths can be partially valid and partially ignored at once. If one command names three -from objects to the same -to point, one of those three sub-paths might be overridden, one might be genuinely invalid, and the remaining one enforced - all three outcomes reported on the same line.
  • report_exceptions forces a full timing update before it runs. Because resolving which exceptions actually win requires the tool to have already worked out path validity and priority, it is best run only after every exception in the script has been applied.
  • report_timing -exceptions dominant or -exceptions overridden (PT) gives the same kind of answer for one specific path instead of the whole exception list. It is the better tool when you already know which single path you are worried about, rather than auditing the whole SDC.

Common Mistake

  • Running report_exceptions without -ignored and concluding that every exception command in the SDC took effect somewhere, because none of them appeared with an ignored flag.
  • A command that is completely overridden by a higher-priority exception is invisible in the default report - it is not shown as ignored, it is simply not shown at all.
  • Cost: an exception the author believed was protecting a path is actually doing nothing, and the omission is only found once a real timing failure on that path surfaces much later.

Follow-up Question & Model Response

A set_multicycle_path 2 -from {A B C} -to D command shows up in report_exceptions with an "Ignored" code of f,o on the {A B C} entry. What does that combination of codes actually mean, and which sub-paths, if any, are still enforced?

Candidate Model Response: The combined code means at least two different problems affect the sub-paths this one command was trying to set: o means one of the named startpoints has a path to D that is overridden by a higher-priority exception command, and f means a different named startpoint is not a valid startpoint for any path to D at all. With three startpoints named in one command, this is very likely a per-startpoint breakdown - one is overridden, one is invalid, and by elimination the third is neither, meaning it is the one sub-path this command is actually still enforcing. I would follow up with report_exceptions -ignored filtered to this exact -from/-to pair to see the breakdown startpoint by startpoint instead of guessing from the combined codes.

Practical Example

A design has a false path from port A to port D, set with set_false_path -from A -to D (SDC), and two attempts to also set a multicycle path over some of the same ground: set_multicycle_path 2 -from A -to D (SDC) and set_multicycle_path 2 -from {A B C} -to D (SDC), where C turns out not to be a valid startpoint for any path to D at all. report_exceptions (PT) without -ignored shows only the third command, flagged f,o because its A-to-D piece is overridden and its C-to-D piece is invalid, leaving only its B-to-D piece enforced. The second command - fully overridden by the false path - does not appear at all until report_exceptions -ignored (PT) is run, which is the only way to discover it was ever silently discarded.

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 →
VLSI Physical Design Planning Handbook — fourteen chaptersDesign PlanningFourteen chapters, floorplanning through timing budgets. →

Continue practising

Related STA questions

IntermediateWhat is timing-exception precedence, and why can a broad false path silently swallow an intended multicycle exception?AdvancedHow do you find out which of two conflicting timing exceptions on the same path wins?BeginnerWhat does -through, -from, and -to mean when writing a timing exception?AdvancedHow do you remove one timing exception from a path without clearing every exception on it?