How do you apply a false path to only the setup check and leave hold fully checked?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
Adding -setup to a set_false_path (SDC) command restricts the exception to the setup check only, so the hold check on that same path keeps running normally. Without the -setup or -hold qualifier, a false path removes the path from both checks at once, which is often more than the design actually needs.
Technical Explanation
By default, a false path is a blanket exclusion, but the command supports narrowing it to just one of the two checks.
- The plain form removes both checks.
set_false_path -from ... -to ...(SDC), written with no-setupor-holdoption, excludes the path from setup and hold checking together. -setuprestricts the exclusion to setup only.set_false_path -setup -from ... -to ...removes the path from the setup check, but the tool still checks hold on that same path as if no exception existed.-holddoes the mirror job for hold.set_false_path -hold -from ... -to ...leaves setup fully checked and excludes only the hold check.- Why you would want only one check excluded: some conditions genuinely only threaten one side of the timing budget. A path that can never actually launch and capture close enough together to threaten hold, for instance, might still deserve a real setup check if its data eventually does need to settle in time.
- Applying a blanket false path when only one check should be excluded throws away real coverage. If a design truly only has a false condition on the hold side, a full
set_false_pathalso removes a setup check the design may have genuinely needed. - Verify which check is active with
report_timing -delay_type maxand-delay_type min(PT) on the same path, confirming the excluded check truly disappears from the report while the other check still shows a normal slack value.
Common Mistake
The Trap: writing a plain set_false_path for a condition that only ever threatens one of the two checks, and losing coverage on the other check without noticing.
- A designer knows a signal can never launch and capture close enough together to create a hold risk, and reaches for a blanket false path to silence the warning they actually saw, which was a hold warning.
- The same command also removes the setup check, so a genuine setup violation on that path — unrelated to the reason the exception was added — goes unreported from that point on.
Follow-up Question & Model Response
A path only ever risks a hold violation because of how its clock domains are related, but you also want its setup timing tracked normally as the design changes. What would you write?
Candidate Model Response: I would write set_false_path -hold -from ... -to ... (SDC), which excludes only the hold check on that path and leaves the setup check fully active. That way, if a future netlist or placement change makes the path's setup timing tight, the tool still reports it as a real, checked path rather than silently passing because of an exception that was only ever meant to address hold. I would confirm the result with report_timing -delay_type min showing the path removed from the hold report, and report_timing -delay_type max still showing a normal setup slack value for the same path.
Practical Example
A path between two flip-flops on independently-generated but always-synchronous clocks can never have a launch and capture edge close enough to threaten hold, because the two clock edges are guaranteed at least 3ns apart by construction. The team applies set_false_path -hold -from [get_cells FF_SRC] -to [get_cells FF_DST] (SDC), which report_timing -delay_type min (PT) confirms removes the path from the hold report entirely. report_timing -delay_type max on the same path still shows a setup check with 1.2ns of slack, confirming the setup side stayed fully protected.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Continue practising