If both set_clock_gate_latency and set_clock_latency are applied to the same clock-gating cell, which one wins?

Short Answer

set_clock_latency has higher precedence and is not overwritten. set_clock_gate_latency specifies clock network latency BEFORE clock gates are inserted, used at compile_fusion insertion time, as a function of clock domain, gating stage, and CGC fanout -- but if set_clock_latency has also been applied to the same object, that value governs, not the gate-latency-by-stage estimate.

Technical Explanation

• set_clock_gate_latency specifies clock network latency BEFORE clock gates are inserted, used at compile_fusion insertion time -- a function of clock domain, gating stage (-stage), and CGC fanout (-fanout_latency).
• set_clock_latency has higher precedence and is NOT overwritten by set_clock_gate_latency -- if both are applied to the same object, the direct set_clock_latency value governs.
• For clock-gated registers specifically, set_clock_gate_latency is typically used with -stage 0 and a fanout_latency table covering all fanout with one bucket (e.g. {1-inf <val>}).
• If -clock is omitted from set_clock_gate_latency, it applies to all clocks -- a broad default that's easy to apply more widely than intended.

Formula Or Decision Rule

Precedence: set_clock_latency > set_clock_gate_latency. The gate-latency command is a pre-insertion estimate; the direct latency command, if present, always wins.

What To Check

• Warning sign: a clock-gating cell's latency doesn't match what set_clock_gate_latency's stage/fanout table would predict.
• Inspect: check whether set_clock_latency was also applied to that same object -- if so, it's overriding the gate-latency estimate, as documented.
• Correct: if the override is unintentional, remove the conflicting set_clock_latency rather than trying to tune set_clock_gate_latency to compensate for a value it can never actually win against.

Healthy, Suspicious & Hard-stop Results

• Expected: a CGC's effective latency matches set_clock_gate_latency's prediction when no conflicting set_clock_latency exists on that object.
• Investigate: a CGC's effective latency doesn't match set_clock_gate_latency's prediction -- check for a set_clock_latency override before assuming the gate-latency command itself is wrong.
• Stop: set_clock_gate_latency is being tuned repeatedly to try to match a target it can never reach because a higher-precedence set_clock_latency is silently overriding it.

What The Interviewer Is Testing

Whether you know the exact precedence rule between these two commands, since debugging a latency mismatch without it wastes real time tuning the wrong lever.