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

How do you remove one timing exception from a path without clearing every exception on it?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

reset_path (SDC) removes a previously-set set_false_path, set_max_delay, set_min_delay, or set_multicycle_path (SDC) exception, but only if its -from/-to/-through object exactly matches the object used when the exception was originally set - a near match, like a different pin on the same net, silently does nothing. Any exception-setting command also accepts a -reset_path (SDC) option, which clears every existing exception on the matched paths first and then applies the new one, letting you replace an exception cleanly instead of stacking a new one on top of an old one.

Technical Reference DiagramHow do you remove one timing exception from a path without clearing every exception on it?
A clock CLK feeding flip-flop ff1 with a set_false_path originally set on the clock object; a reset_path -from [get_pins ff1/CP] arrow shown failing silently with an X mark because it targets the pin instead of the clock, next to a correct reset_path -from [get_clocks CLK] arrow that succeeds

Technical Explanation

  • reset_path (SDC) targets an exception by matching its original object exactly. Its -from, -to, and -through options need to name the same pin, port, or clock that the original exception command used - not merely an equivalent or nearby one.
  • A near-miss object produces silent failure, not an error. reset_path -from [get_pins ff1/CP] (SDC) does nothing if the original exception was actually set with -from [get_clocks CLK], even though ff1/CP is clocked by CLK and looks like the same thing conceptually.
  • The same applies to -through points on a fanning network. reset_path -through [get_pins a/Z] (SDC) will not clear an exception originally set with -through [get_pins {d/Z g/Z}] (SDC), even if a/Z fans out to both d/Z and g/Z downstream.
  • -reset_path (SDC) on the setting command itself sidesteps the exact-match problem entirely. set_false_path -through [get_pins d/Z] -reset_path (SDC) clears every exception already applied to paths through that point, then immediately applies the new false-path exception in their place.
  • reset_design (PT) is the blunt, whole-design version of the same idea. It removes every user-specified clock, path group, exception, and attribute in one command, useful for starting exception-writing over from a clean slate, not for a single targeted removal.
  • Verifying a removal worked is worth a follow-up report_exceptions (PT) run. Because a mismatched reset_path object fails silently, confirming the exception is actually gone - rather than assuming the command succeeded - closes the loop on this trap.

Common Mistake

  • Calling reset_path with an object that is logically equivalent to the one used in the original exception - a data pin instead of the clock pin, or an upstream fanout point instead of the exact through-point - and assuming the exception is now cleared.
  • reset_path requires an exact object match to the original exception-setting command; anything else is treated as not matching, and the command has no effect at all, with no warning that it failed.
  • Cost: a designer believes an old, incorrect exception has been removed and layers a new one on top of it, when in fact both are now active and interacting in whatever way the tool's precedence rules happen to resolve.

Follow-up Question & Model Response

If you are not sure exactly which object the original exception command used, what is the safer way to guarantee a clean replacement instead of guessing at reset_path's arguments?

Candidate Model Response: The safer approach is to use the -reset_path option directly on the new exception-setting command instead of trying to reconstruct the original object for a separate reset_path call. Writing set_false_path -through [get_pins d/Z] -reset_path (SDC) clears every exception currently applied to paths through that point and applies the new one in a single step, so there is no need to know or guess the exact object the earlier exception used. This is more reliable specifically because reset_path's exact-match requirement is easy to get subtly wrong, while -reset_path's clear-then-apply behavior only depends on correctly identifying the point for the new exception, which you already need to specify anyway.

Practical Example

An engineer originally wrote set_false_path -from [get_clocks CLK] (SDC) to exclude an entire clock domain from setup/hold checking during an early bring-up phase. Later, trying to remove it, they run reset_path -from [get_pins ff1/CP] (SDC), reasoning that ff1 is clocked by CLK and should match - but the command has no effect, because the original exception's object was the clock CLK, not the pin ff1/CP. report_exceptions (PT) run afterward still shows the false path in place, confirming the reset silently failed; re-running reset_path -from [get_clocks CLK] (SDC), matching the original object exactly, finally clears it.

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 →
Timing Constraints (SDC) Handbook — nine chaptersSDC ConstraintsNine chapters on clocks, exceptions, and constraint linting. →

Continue practising

Related STA questions

BeginnerWhat is a false path?AdvancedHow do you tell whether a timing exception actually matched the path you intended?BeginnerWhat is set_case_analysis, and when would you tie a pin to a fixed value?AdvancedCompare disabling a path with case analysis, set_disable_timing and set_false_path - mechanism, blast radius, and when each is the right tool.