What does a multisource clock sink group actually guarantee, and why would you need one beyond normal tap assignment?

Short Answer

Normal tap assignment (set_multisource_clock_tap_options) assigns each sink to its closest tap driver independently. A multisource clock sink group (create_multisource_clock_sink_group) overrides that independence for specific skew-critical objects, keeping them under the same tap even if that's not each individual object's closest driver -- because for a genuinely skew-critical group, being on the same tap matters more than each member individually being closest to its own nearest driver.

Technical Explanation

• Normal tap assignment (via set_multisource_clock_tap_options) assigns each sink to its closest tap driver independently -- a per-sink, local decision.
• A multisource clock sink group (create_multisource_clock_sink_group) overrides that independence for specific skew-critical objects, keeping them under the same tap driver even when that isn't each individual object's own closest driver.
• The reasoning: for a genuinely skew-critical group of registers, being fed from the same tap (and therefore sharing more of the clock path) matters more than each individual member independently minimizing its own distance to its nearest driver.
• add_to_multisource_clock_sink_group and remove_from_multisource_clock_sink_group let you adjust group membership after creation, rather than requiring the group to be fully specified up front.

Formula Or Decision Rule

Normal tap assignment: each sink -> its closest driver, independently. Sink groups: force specific skew-critical objects onto the SAME tap, overriding independent closest-driver assignment.

What To Check

• Warning sign: a group of registers with a tight skew relationship shows worse-than-expected relative skew despite each individual register's latency looking reasonable on its own.
• Inspect: check whether those registers were assigned to taps independently (normal assignment) rather than grouped via create_multisource_clock_sink_group.
• Correct: group the skew-critical set explicitly so they share a tap, even if that means one member's individual latency is no longer its own theoretical minimum.

Healthy, Suspicious & Hard-stop Results

• Expected: relative skew within a defined sink group is tight, even if individual members' absolute latency isn't each one's theoretical independent minimum.
• Investigate: a skew-critical set of registers shows poor relative skew despite each one individually reporting reasonable latency -- check whether they were ever grouped, or left to independent closest-driver assignment.
• Stop: a known skew-critical register set was never grouped and relative skew violations persist across multiple CTS re-runs -- group them explicitly rather than continuing to hope independent assignment converges.

What The Interviewer Is Testing

Whether you understand the actual reasoning behind sink groups (relative skew within a critical group matters more than each member's individual optimal assignment), not just that the command exists.