Why does interclock uncertainty override simple clock uncertainty when both apply to the same path?

Short Answer

Simple clock uncertainty describes the skew of one clock against its own ideal edges; interclock uncertainty describes the skew specifically between two named clock domains, and it is the more specific description of the two. When a path qualifies for both because its launch and capture clocks are different, PrimeTime uses the interclock value and ignores the simple one, on the assumption that a value written specifically for that pair of clocks is more accurate than a general per-clock value.

Technical Explanation

• Simple uncertainty applies per clock, with no notion of which other clock a path is crossing to. set_clock_uncertainty 5 [get_clocks CLKA] (SDC) sets a single skew value for every path whose capturing register is clocked by CLKA, regardless of which clock launched the data.
• Interclock uncertainty is written specifically for a pair of clock domains. set_clock_uncertainty 2 -from [get_clocks CLKB] -to [get_clocks CLKA] (SDC) applies only to paths that launch from CLKB and capture on CLKA, a narrower and more specific statement than the simple form.
• When both could apply to the same path, PrimeTime picks the interclock value. A path from CLKB to CLKA in the example above uses the interclock uncertainty of 2, not the simple uncertainty of 5 that CLKA also carries, because the interclock command targets that exact crossing.
• Interclock uncertainty has to be set for both directions of a crossing if both exist. A value defined -from CLKA -to CLKB does not also cover paths -from CLKB -to CLKA; each direction needs its own command even when the number is the same in both directions.
• This precedence exists because a general, per-clock number cannot know about the specific relationship between two domains. Two clocks with independent PLLs might have far more relative skew between them than either has against its own ideal edges, and only an interclock value written for that specific pair captures it.
• The interaction still needs to be checked deliberately. Because the override is silent - there is no warning that the simple value was set aside - it is worth confirming with a report before assuming a per-clock uncertainty is actually in effect on a cross-domain path.

Follow-up Question & Model Response

If a chip has three clock domains and every pair of them can exchange data, how many set_clock_uncertainty commands does full interclock coverage actually require, and why is a single simple value on each clock not a shortcut for this?

Candidate Model Response: With three clocks and every direction of crossing possible, full interclock coverage needs six commands - one for each ordered pair, since -from CLKA -to CLKB and -from CLKB -to CLKA are independent statements even if the numeric value ends up the same for both. A simple value on each of the three clocks is not a shortcut for this, because it describes only that clock's own skew, not the skew of any specific crossing; if the real hardware has a larger relative skew between two particular clocks than either has against its own ideal edges, only the interclock value for that pair will catch it, and the simple values will simply be overridden wherever an interclock statement exists.