IntermediateQuestion 65 of 112Source: Synopsys PrimeTime User Guide: Reporting Timing Exceptions

How do you confirm that a set_false_path exception actually matched a real path?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

The tool accepts a set_false_path (SDC) command even if the objects you named do not resolve to any real path in the design, and it will not warn you by default. Running report_exceptions (PT) or report_timing with the exception in place is how you confirm the command actually removed something, rather than silently doing nothing.

Technical Reference DiagramHow do you confirm that a set_false_path exception actually matched a real path?
A constraint file line pointing at a renamed register, shown resolving to an empty path list in report_exceptions, next to report_timing revealing the same path now checked and showing -140ps of slack.

Technical Explanation

An exception command that runs without an error is not the same as an exception that changed anything.

  • get_cells, get_pins, and get_ports can silently return nothing. If a typo in an object name means the collection is empty, set_false_path -from [get_cells TYPO_REG] -to ... (SDC) still executes without an error — it just applies to zero paths.
  • report_exceptions (PT) lists every currently active exception, expanded to the actual pin-to-pin paths it reaches, so you can see the real scope of a set_false_path instead of trusting the command text alone.
  • report_timing -from ... -to ... (PT) on the same objects shows whether the path still appears as a checked path. If the path you meant to exclude still shows up with a normal slack value, the false path did not reach it.
  • A renamed or removed cell after a netlist change is a common way this quietly breaks. An exception written against REGA before a synthesis rerun can stop matching anything once REGA is renamed or merged away, and the constraint file itself gives no indication that happened.
  • Constraint linting at each stage catches this early. Re-running report_exceptions after every major netlist change — not just once at the start of the project — is what keeps a false path meaningful as the design evolves.
  • Why an unmatched exception is worse than no exception: the constraint file looks complete, reviewers assume the path is excluded, and nobody re-checks it once the underlying object silently stops matching.

Common Mistake

The Trap: trusting that a set_false_path line in the constraint file is doing its job simply because it runs without an error.

  • A designer writes an exception against a cell name from an early netlist, and a later synthesis rerun renames or merges that cell away.
  • The exception silently stops matching anything, the path it was meant to exclude reappears as a checked, possibly violating path, and nobody notices until a late-stage timing report shows an unexpected new failure.

Follow-up Question & Model Response

Your constraint file has 30 set_false_path commands written months ago, before several synthesis reruns. How would you check whether they still apply to real paths today?

Candidate Model Response: I would run report_exceptions (PT) against the current netlist and compare its expanded pin-pair list to what I expect each of the 30 commands to cover. Any exception that expands to an empty list is a clear sign its named objects no longer exist or no longer form a path. For exceptions that do expand to something, I would spot-check a few with report_timing -from ... -to ... (PT) to confirm the path is genuinely being excluded rather than still appearing with a slack value. I would treat any exception that resolves to nothing as a bug in the constraint file, not a harmless no-op, since a path meant to be excluded is now back in the checked set without anyone deciding that on purpose.

Practical Example

A constraint file includes set_false_path -from [get_cells U_LEGACY_FSM/state_reg] -to [get_cells U_LEGACY_FSM/out_reg] (SDC), written against a netlist from three synthesis runs ago. After the FSM is re-encoded, state_reg is renamed to state_reg_enc[2:0] during synthesis. Running report_exceptions (PT) shows the original false path resolving to an empty pin list, and report_timing -from [get_cells U_LEGACY_FSM/state_reg_enc*] -to [get_cells U_LEGACY_FSM/out_reg] reveals the path is back in the checked set with -140ps of slack — a real violation the constraint file had been silently hiding since the rename.

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

BeginnerWhat is a false path?IntermediateWhat is timing-exception precedence, and why can a broad false path silently swallow an intended multicycle exception?IntermediateWalk through how you would debug a path that fails by a surprising amount using report_timing increments.IntermediateHow do you restrict a false path to one clock domain crossing instead of blocking every path between two clocks?