IntermediateQuestion 23 of 112

How would you set interclock uncertainty between two clock domains, and when is it needed?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Use set_clock_uncertainty (SDC) with -from and -to, for example set_clock_uncertainty 2 -from [get_clocks CLKB] -to [get_clocks CLKA]. It's needed on clock-domain-crossing paths, where the launch register and the capture register sit on different clocks.

Two independent clock trees CLKA and CLKB with a directional set_clock_uncertainty -from/-to value applied only to the CDC crossing path, larger than the in-domain skew value — Technical Reference DiagramHow would you set interclock uncertainty between two clock domains, and when is it needed?

Technical Reference DiagramHow would you set interclock uncertainty between two clock domains, and when is it needed?

Technical Explanation

When a path launches on one clock and gets captured on a different one, the relevant variation is between two separate clocks, not within one — -from and -to on set_clock_uncertainty (SDC) specify exactly that.

The command: set_clock_uncertainty 2 -from [get_clocks CLKB] -to [get_clocks CLKA] sets a 2 (in the design's time unit) uncertainty for any path launched by CLKB and captured by CLKA.
Why it's often larger than within-domain skew: two independent clock trees usually share little or no common path and may even come from different sources, so their edges can drift further apart than edges inside one tree.
Direction matters: -from names the launch clock, -to names the capture clock. If paths cross in both directions, write both directions separately, since the crossing isn't symmetric.
Typical layout: a modest within-domain value, set_clock_uncertainty 0.3 [get_clocks CLKA], paired with a larger interclock value, set_clock_uncertainty 0.6 -from [get_clocks CLKA] -to [get_clocks CLKB], for the crossing paths.
Precedence rule: when a path qualifies for both a plain within-domain uncertainty and an interclock one, the interclock value wins — a CLKA-to-CLKB path uses the 0.6, never the 0.3.

Common Mistake

The Trap: relying on the plain, within-domain set_clock_uncertainty value to cover crossing paths too.

A designer sets one uncertainty per clock and assumes it silently applies to every path touching that clock, including crossings into another domain.
Since the crossing usually needs a bigger number than the in-domain skew, the crossing paths end up under-margined, and a marginal CDC path can pass signoff only to fail with real silicon skew.

Follow-up Question & Model Response

If you only write the interclock uncertainty for CLKA-to-CLKB, does the CLKB-to-CLKA direction get any margin at all?

Candidate Model Response: No — -from and -to are directional, so a command written as -from CLKA -to CLKB covers only paths launched by CLKA and captured by CLKB. Paths going the other way, launched by CLKB and captured by CLKA, fall back to whatever plain, within-domain uncertainty is set on CLKA, since no interclock rule matches them. If the crossing is genuinely bidirectional, which most CDC synchronizer pairs are, you need a second command with -from and -to swapped. Skipping it isn't a syntax error, so the gap is easy to miss during review.

Practical Example

A design has CLKA at 400 MHz and CLKB at 250 MHz, crossing through a two-flop synchronizer in both directions. The team sets set_clock_uncertainty 0.15 [get_clocks CLKA] and set_clock_uncertainty 0.15 [get_clocks CLKB] for in-domain paths, then adds set_clock_uncertainty 0.9 -from [get_clocks CLKA] -to [get_clocks CLKB] and the reverse pair at 0.9 as well, reflecting that the two trees share no common buffer. Post-route STA on the synchronizer's first flop-to-flop path reports the 0.9 value in the required-time calculation, confirming the interclock rule, not the 0.15, is the one in effect.

Complete STA Handbook