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

How do you restrict a false path to one clock domain crossing instead of blocking every path between two clocks?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Naming clocks with -from [get_clocks A] -to [get_clocks B] in set_false_path (SDC) declares every path between those two clocks false, in both register-to-register directions the clocks touch. To keep only one specific crossing false while other paths between the same two clocks stay checked, you name the actual startpoint and endpoint cells or pins instead of the clock objects.

Technical Reference DiagramHow do you restrict a false path to one clock domain crossing instead of blocking every path between two clocks?
Two clock domains, CLKA and CLKB, connected by 40 status registers and one two-flop synchronizer, with a clock-level false path shown covering all 41 paths versus a narrowed false path covering only the 40 status registers.

Technical Explanation

The startpoint and endpoint you give set_false_path decide how wide the exception reaches, and a clock object is the widest choice available.

  • Naming a clock expands to every related path. set_false_path -from [get_clocks CLKA] -to [get_clocks CLKB] (SDC) applies to every register and port related to CLKA as a startpoint, paired with every one related to CLKB as an endpoint — not just the one pair you had in mind.
  • Naming cells or pins narrows it to one crossing. set_false_path -from [get_cells REGA] -to [get_cells REGB] only removes that specific register pair, leaving every other CLKA-to-CLKB path fully checked.
  • Why the wide form is tempting: if a whole clock domain crossing is asynchronous and none of its paths are meant to be timed together, the clock-level form is a fast way to say so in one line.
  • Why the wide form is risky in a partially-synchronized design: if even one register pair between CLKA and CLKB is meant to be checked — say, a synchronized handshake signal — the clock-level false path silently removes that pair too, along with everything else.
  • A tool-level check helps confirm scope. report_exceptions (PT) lists the expanded pin-by-pin form of any exception, so you can see exactly which paths a clock-level set_false_path actually reached before trusting it.
  • The general rule: use the narrowest object — a specific cell, pin, or port — that still covers everything you actually intend to exclude, and reserve the clock-level form for a domain crossing where truly nothing should ever be checked.

Common Mistake

The Trap: writing set_false_path -from [get_clocks CLKA] -to [get_clocks CLKB] to silence one noisy pair of registers, without checking whether any other CLKA-to-CLKB path is meant to be timed.

  • A designer sees one warning between two async clocks and reaches for the clock-level exception because it is the shortest command to write.
  • A separately synchronized handshake signal between the same two clocks gets swept up in the same false path, so a real timing bug on that signal is never reported again.

Follow-up Question & Model Response

How would you confirm, after the fact, exactly which register pairs a clock-level set_false_path actually covered?

Candidate Model Response: I would run report_exceptions (PT), which expands a clock-level exception down to the individual pin pairs it applies to, rather than trusting the one-line command at face value. If the design has hundreds of registers on each clock, I would expect that report to be long, and I would specifically look for any pair I know is supposed to stay timed, such as a synchronized handshake register. If I found one, I would replace the clock-level exception with a narrower -from/-to naming the specific cells that are genuinely asynchronous, and leave the handshake path out of the exception entirely so it keeps getting checked.

Practical Example

A design has a 100MHz CLKA domain and a 66MHz CLKB domain connected by 40 unrelated status registers and one synchronized two-flop handshake signal, sync_req. The team first tries set_false_path -from [get_clocks CLKA] -to [get_clocks CLKB] (SDC), which silences all 41 paths, including sync_req's second synchronizer stage. After running report_exceptions (PT) and noticing sync_req in the expanded list, they replace the command with 40 explicit -from/-to pairs naming only the unrelated status registers, leaving the sync_req synchronizer path fully checked for the metastability-recovery timing it actually needs.

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?IntermediateWhy should you prefer the -from/-to form of an exception over the -through-plus-clock form?IntermediateWhat is timing-exception precedence, and why can a broad false path silently swallow an intended multicycle exception?IntermediateHow do you confirm that a set_false_path exception actually matched a real path?