What is the difference between 'union' and 'every-group' TNS computation in report_global_timing, and why does this matter for DMSA (multi-scenario) results?

Short Answer

Total negative slack (TNS) sums up how much every violating endpoint is behind schedule. In union mode (the default), each endpoint contributes only its single worst negative slack value to the total, even if it belongs to more than one path group or scenario. In every-group mode, an endpoint contributes separately for every path group it is negative in, so the same physical flop can be counted more than once. The tool selects the mode with the timing_report_union_tns variable, and the choice changes the reported TNS magnitude significantly once distributed multi-scenario analysis (DMSA) combines several scenarios together.

Technical Explanation

• TNS is one of the standard signoff quality-of-results metrics reported by report_qor (PT) and report_global_timing (PT): it sums the magnitude of negative slack across all violating endpoints, giving a sense of how much total timing work remains, beyond just the single worst-path number (WNS, worst negative slack).
• A single endpoint (a specific flop's data pin, for example) can appear in more than one path group — for instance, if two different clocks both reach it, or if it is checked under more than one path group classification — and can have negative slack in more than one of those groups simultaneously.
• Union TNS mode (default, timing_report_union_tns = true) takes, for each endpoint, only the single worst negative slack value across every path group and scenario that endpoint appears in, and adds that one number into the total — so each physical endpoint contributes at most once.
• Every-group TNS mode (timing_report_union_tns = false) instead adds up the negative slack separately for every path group in which that endpoint is negative — the same endpoint contributes multiple times if it violates in multiple groups, since each group's violation is treated as a separate reportable failure.
• In distributed multi-scenario analysis (DMSA), where many scenarios (mode/corner combinations) are analyzed and their results merged, both modes still operate per endpoint across all scenarios: union mode takes the single worst slack for that endpoint across every scenario and every group, while every-group mode sums the endpoint's negative slack in every group in every scenario where it is negative.
• Because every-group mode can count the same physical endpoint's violation multiple times, its TNS number is always greater than or equal to the union mode number for the same design and the same set of scenarios — the gap grows with however many endpoints have negative slack in more than one group or scenario simultaneously.
• What breaks: comparing TNS numbers across two signoff runs, or across two different tool configurations, without confirming both used the same timing_report_union_tns setting produces a misleading trend — an apparent TNS "improvement" between runs can simply be an artifact of switching from every-group to union mode, not real timing closure progress.

Follow-up Question & Model Response

"If two DMSA signoff runs report very different TNS values for what should be nearly identical designs, what is the first configuration setting you would check before assuming a real regression?"

Candidate Model Response: I would check timing_report_union_tns first in both runs' setup scripts, since a mismatched setting alone can produce a large apparent difference in TNS with no real timing change behind it. I would also confirm both runs merged the same set of scenarios under DMSA, since a run missing a scenario, or including an extra one, changes which endpoints even have negative slack to sum in the first place, independent of the union-versus-every-group choice.