How do you stop clock propagation at a specific pin with set_sense -stop_propagation?

Short Answer

By default the tool keeps treating a signal as a clock through every downstream pin it can trace it to. When a clock-like signal legitimately feeds both real clock destinations and ordinary data logic — a test clock reused as a data mux input in some modes, for example — set_sense -type clock -stop_propagation tells the tool to stop treating it as a clock past that specific pin, so the rest of the fanout is analyzed as ordinary data.

Technical Explanation

Some cells in a clock-like network are not really part of clock distribution at all, and the tool needs to be told the clock signal stops there instead of continuing to propagate as a clock.

• The tool normally keeps propagating a clock through every cell in its fanout, treating each downstream pin as still carrying clock timing unless told otherwise.
• A test clock feeding a multiplexer that also drives ordinary data logic in some modes is a common case where that default is wrong. Once the signal leaves the clock's intended distribution point, continuing to treat it as a clock can create clock-like timing checks somewhere they do not belong.
• set_sense -type clock -stop_propagation -clocks TESTCLK [get_pins UMUX2/Z] (SDC) tells the tool to stop treating the named clocks as clocks past that specific pin. Past that point, the signal reverts to being timed as ordinary data.
• This is different from disabling a timing arc entirely with set_disable_timing (SDC). Stop-propagation only affects how the clock is treated going forward from that pin; the arc itself, and any real data-path timing through it, still gets analyzed normally.
• Why it matters: getting this wrong either creates clock paths that should not exist, cluttering reports with meaningless checks, or misses a real data-path timing check on a signal the tool kept treating as a clock instead.

Follow-up Question & Model Response

A test clock signal, TESTCLK, feeds a multiplexer whose output drives both a scan flip-flop's clock pin and, through a separate branch, an ordinary data input elsewhere in the design. How do you constrain this correctly?

Candidate Model Response: I would apply set_sense -type clock -stop_propagation -clocks [get_clocks TESTCLK] [get_pins MUX1/Z] (SDC) on the mux output pin so the clock stops propagating there, then let downstream data-path timing analysis handle the ordinary data branch normally. I would not use set_disable_timing on that arc, since the data branch still needs a real timing check — it should just no longer be evaluated as a clock relationship. I would confirm with report_clock (PT) that TESTCLK's propagated clock tree ends at MUX1/Z as intended, with no clock endpoints appearing further downstream on the data branch.