False Paths — Advanced & Pitfalls

Timing constraints — clocks, generated clocks, I/O delays, exceptions, OCV and MCMM setup

False Paths — Advanced & Pitfalls

Not every path the tool can trace is a path the chip will ever use. Some paths exist on paper but never carry real timing. Forcing the tool to meet timing on them wastes effort and can block a clean result. A false path tells the tool to ignore a path. This chapter goes deep on the advanced uses and the sharp pitfalls. We keep the format generic. We call it SDC. We never name a tool or product. We say "the timing tool" for the engine that checks paths and "the synthesis tool" for the engine that builds logic.

What a False Path Really Claims

The command set_false_path tells the tool to stop timing a path. The tool removes that path from analysis. No setup check. No hold check. The path is treated as if its timing does not matter. This is a strong claim. You are promising that the path is never used in a way that needs timing. Maybe it is a static configuration line set once at boot. Maybe two clocks are unrelated and never exchange data on that route. Maybe the path is logically impossible to activate even though it physically connects. The danger is symmetry. A false path silences both setup and hold on that route. If you were wrong, and the path does matter, the tool will never warn you. The violation simply vanishes from the report. So a false path must rest on real design knowledge, not on a wish to clear a report.

Scoping with -from, -through, and -to

A false path can be broad or narrow. The scope is set by three options. -from names where the path starts. -to names where it ends. -through names a point the path must pass. Used alone, -from waives every path leaving a start point. Used alone, -to waives every path reaching an end point. Combined, they narrow to paths that both start and end at the named points. Adding -through narrows further to paths that also cross a chosen pin or net.

The lesson is to scope tightly. A broad false path is easy to write and easy to overreach. It may waive paths you never meant to waive. A narrow false path, pinned by -from , -to , and -through , waives only what you intend.

# standard SDC — portable across compliant tools
# Broad: every path out of a config register is waived.
set_false_path -from [get_cells cfg_mode_reg]
# Narrow: only the path from cfg_mode_reg, through a mux, to one sink.
set_false_path -from [get_cells cfg_mode_reg] \
-through [get_pins sel_mux/Y] \
-to [get_cells datapath_q_reg]

Layered False Paths and Reconvergence

Real designs accumulate many false paths. They layer up over a project. The risk is that a later, broad false path swallows paths that an earlier engineer relied on being checked. Layering is where mistakes hide. Reconvergent paths sharpen the risk. Reconvergence is when a signal splits into two branches and the branches rejoin later. If you waive a path "through" one branch, you may not waive the parallel branch. The rejoined endpoint may still be timed through the branch you did not name. So a false path on one branch can leave a real path live and unanalyzed in the way you expected.

A worked feel. A signal leaves start_reg , splits at a fork, and the two branches rejoin at end_reg . You write a false path -from start_reg -through brA/Z -to end_reg . The tool waives only the branch crossing brA/Z . The branch through brB/Z is still timed. If both branches were meant to be false, you needed a second constraint or a broader scope. The half-done waiver leaves a surprise in the report.

False Paths Versus Clock Groups

There is a cleaner tool for whole-clock relationships. When two clocks never exchange data, you do not want to waive path by path. You want to declare the clocks unrelated. The command

set_clock_groups  does this. Clocks placed in different asynchronous groups are not timed against

each other at all. The contrast matters. A false path is surgical; it waives specific paths. A clock group is wholesale; it waives every path between two clock domains in both directions at once. Using many false paths to fake a clock-group relationship is fragile. New paths added later between those domains will not be covered, and they will appear as violations or, worse, be quietly checked when they should not be.

# standard SDC — portable across compliant tools
# Prefer clock groups when the whole relationship is asynchronous.
set_clock_groups -asynchronous \
-group [get_clocks clk_sys] \
-group [get_clocks clk_io]

The rule of thumb: if the reason two paths are false is that their clocks never interact, use a clock group. Reserve false paths for routes that are dead for logical or structural reasons within otherwise related clocks.

The Pitfall of Masking Real Violations

The deepest danger of false paths is that they hide failures. A false path is invisible in the timing report. A reviewer cannot see the path that is no longer there. So an over-broad false path can mask a real, timing-critical route, and nobody notices until silicon fails. A few habits guard against this. Scope every false path as tightly as the intent allows. Comment every false path with the reason it is safe. Audit false paths periodically by listing them and asking whether each is still true. Prefer clock groups for domain-wide relationships so that path-level waivers stay rare and meaningful.

# illustrative — names vary by tool
# Audit: list all exceptions and count how many paths each removes.
report_timing_exceptions -type false_path
report_exceptions -ignored -coverage

A worked illustration of masking. An engineer writes set_false_path -to [get_cells alu_result_reg] to silence one noisy configuration path. But alu_result_reg is also the endpoint of a real, busy arithmetic path. The broad -to waives both. The arithmetic path now fails in silicon while the report stays green. A scoped -from ... -through ... -to would have waived only the configuration route and left the arithmetic path checked.

Interview Q&A

the setup check and the hold check on that path are silenced. The path is treated as if its timing does not matter, so no violation on it will ever be reported.

start, -to fixes the end, and -through requires a midpoint. Used alone, -from or -to is broad and waives many paths. Combining all three is surgical and waives only the one route you intend.

branches. A -through on one branch waives only that branch. The parallel branch is still timed to the shared endpoint. So a single waiver can leave a real path live and unanalyzed when you believed both were waived.

never need timing is that their clocks never exchange data. A clock group waives every path between the two domains in both directions at once, which is far more robust than maintaining many individual false paths.

broad waiver can remove a real, timing-critical route along with the dead one you meant to silence. The report stays green while the chip fails, and no reviewer can see the missing path.

reason it is safe, audit the exception list periodically, and prefer clock groups for whole-domain relationships so that path-level waivers stay rare and meaningful.

Key Takeaways

• A false path silences both checks. It removes setup and hold on a route, so a wrong waiver hides failures with no warning.
• Scope decides everything. -from , -through , and -to together waive only the intended route, while a lone -from or -to overreaches.
• Reconvergence breaks naive waivers. A -through on one branch leaves the parallel branch timed, so split-and-rejoin paths need care.
• Clock groups beat many false paths. For whole-domain asynchronous relationships, a clock group is more robust than path-by-path waivers.
• Masking is the real danger. Tight scoping, comments, and periodic audits keep false paths from quietly hiding critical violations.