A register behind a clock MUX sees multiple clocks. Is that always an error?

Short Answer

No — seeing two different clocks arrive at one clock pin isn't automatically a bug. It's exactly what you'd expect at a clock MUX (functional clock vs. test clock, or two PLL outputs for different performance modes), where only one input is actually selected at a time in any given operating mode. The tool, though, doesn't know your chip's functional intent by default — it just sees a pin with two active clock definitions and will report it, sometimes as a DRC-style warning, sometimes just noise in the report.

Technical Explanation

• ** If set_case_analysis (or scenario-based mode constraints) correctly fixes the MUX select for each scenario, then only one clock is "live" per scenario and the report is benign.
• If the constraints leave the select ambiguous — no case analysis, or a mode where both clocks are simultaneously treated as active — that's a hard stop, because ICC2/STA genuinely can't tell which edge should be used for setup/hold, and you'll get either an over-constrained or (worse) an under-constrained result.
• Also check set_clock_groups (or exclusivity/asynchronous grouping) around the MUX — if the two clocks are meant to be mutually exclusive, that intent needs to be declared explicitly, not assumed.
• Bottom line: multiple clocks at a MUX pin is a prompt to go verify mode logic and constraints, not an automatic failure — but leaving it ambiguous across a scenario absolutely is one.

What To Check

• Warning sign: check_timing reports multiple_clock at the downstream register.
• Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
• Correct: Inspect case analysis, clock groups, mode SDC, and MUX connectivity; obtain functional/STA ownership for exclusivity intent.

Healthy, Suspicious & Hard-stop Results

• Expected: It may be valid across modes, but within one scenario the MUX selection and exclusivity must reflect functional reality; ambiguity is a hard stop.
• Stop before floorplanning when required logic or timing coverage is missing or unexplained.

What The Interviewer Is Testing

Be ready to explain why this matters before floorplanning.

Follow-up Question & Model Response

Model response: “I would save the report, inspect one affected object in the correct block and scenario, and make or request this correction. ”