IntermediateQuestion 67 of 112Source: Synopsys PrimeTime User Guide: Specifying Timing Paths

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 Reference DiagramHow do you apply a false path to only the setup check and leave hold fully checked?
A single path shown with two parallel timing checks, setup and hold, with -hold removing only the hold check line while the setup check line remains active with a visible slack value.

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 -setup or -hold option, excludes the path from setup and hold checking together.
  • -setup restricts 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.
  • -hold does 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_path also removes a setup check the design may have genuinely needed.
  • Verify which check is active with report_timing -delay_type max and -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

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Timing Constraints (SDC) Handbook — nine chaptersSDC ConstraintsNine chapters on clocks, exceptions, and constraint linting. →