Why should you set clock uncertainty on the clock object instead of a clock port or pin?

Short Answer

Setting set_clock_uncertainty (SDC) on a port or pin applies it only to the capturing registers downstream of that specific object; if multiple uncertainty values reach the same clock multiplexer from different ports, PrimeTime applies the worst of them to the mux's entire fanout, even to registers clocked by an input the mux is not currently selecting. Setting the uncertainty on the clock object itself avoids that ambiguity, because the value follows the clock definition rather than one physical point in its network.

Technical Explanation

• Uncertainty set on a port or pin is scoped by fanout, not by clock identity. It applies to every capturing register whose clock pin sits in the transitive fanout of that specific port or pin - a purely structural, physical-topology rule.
• A clock multiplexer can receive different uncertainty values on its different inputs. If one input port carries a 0.3ns uncertainty and another carries a 0.5ns uncertainty, both values are propagating toward the same mux from different physical directions.
• PrimeTime resolves this by applying the worst uncertainty to the mux's entire fanout. Every register downstream of the mux sees the larger of the two values, even the ones clocked through the input that was not selected for that value at all.
• This worst-case merge happens regardless of which clock is actually disabled at the mux. Even a register that can only ever be reached through the input carrying the smaller uncertainty inherits the larger one, because the fanout-based rule does not know which input is functionally active.
• Setting the uncertainty on the clock object sidesteps this entirely. set_clock_uncertainty 0.3 [get_clocks CLK1] (SDC) applies directly to the clock definition, so every register clocked by CLK1 gets exactly that value, independent of which physical port or mux input the clock happens to arrive through.
• The port/pin form is still useful for a genuinely local, structural margin. It has a real purpose when the uncertainty really is about one specific physical fanout tree rather than about a named clock - but that case is the exception, not the default choice.

Follow-up Question & Model Response

If two ports feeding a clock mux each have their own set_clock_uncertainty value set on the port, and a register is physically reachable only through the smaller-uncertainty input, will report_timing show that register using the smaller value or the larger one - and why?

Candidate Model Response: It will show the larger value, because the port/pin form of set_clock_uncertainty follows structural fanout, not functional reachability - PrimeTime does not evaluate which mux input is actually selected when merging uncertainty values that converge on the same downstream fanout. The register's fanout cone includes both mux inputs' uncertainty settings once they meet at the mux, so the worst of the two wins for everything past that point, regardless of which specific input the register's real clock path uses. Moving both uncertainty values onto the clock objects themselves, rather than the ports, would let each clock keep its own distinct value without the mux merging them together.