Why do two runs of the same design report different TNS?

Short Answer

TNS depends on how an endpoint that sits in more than one path group is counted. With timing_report_union_tns (PT) at its default of true, each violating endpoint adds its worst slack once; with false, it adds once for every path group it violates in. Two runs with different settings, or with different path groups, report different TNS for exactly the same slacks.

Technical Explanation

• Union mode, the default, adds the worst slack of every endpoint with negative slack, taking the worst across all path groups and all scenarios. Each endpoint counts once.
• Every-group mode adds the worst slack per path group. An endpoint that violates in two groups counts twice, and the violating path count grows the same way.
• In DMSA both modes use each endpoint's worst slack across all scenarios, so a merged TNS never double-counts scenarios.
• Endpoints land in several groups when two clocks reach the same flop or when user path groups overlap. Adding a group_path (SDC) changes every-group TNS without changing a single slack.
• Other causes of a TNS difference come after this one: graph-based versus path-based slack, a different scenario set, or comparing tools. report_qor (PT) and report_qor (ICC2) come from different timers with their own extraction and scenario setup, so their TNS will not match line for line.
• Rule out the counting mode first, since it is a one-line check, before chasing a real regression.

Formula Or Decision Rule

• Union mode (default, timing_report_union_tns (PT) true): TNS = sum over violating endpoints e of the worst slack(e) across all path groups and scenarios.
• Every-group mode (false): TNS = sum over path groups g of the sum over endpoints e violating in g of the worst slack(e, g) across scenarios.
• Decision rule: compare TNS only between runs with the same mode, the same path groups and the same scenarios.

What To Check

• The value of timing_report_union_tns (PT) in both runs.
• The path group list in both runs.
• Violating endpoint count against violating path count.
• The scenario set and path-based analysis mode.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Both runs report the same TNS once mode, path groups and scenarios match.
• Suspicious (illustrative): Every-group TNS is 60% worse than union TNS, so many endpoints sit in two or more groups; look for overlapping path groups.
• Hard stop: A tapeout gate that compares TNS from two tools or two modes. The gate means nothing until the counting matches.

What The Interviewer Is Testing

• Knowing both counting modes and the default.
• Checking the counting mode first when TNS moves without a netlist change.
• Does the answer cover the DMSA rule that scenarios never double-count?

Follow-up Question & Model Response

"Which mode should you use to track signoff?"

Candidate Model Response: Use one mode everywhere, and union mode is the natural choice since it is the default and counts each failing endpoint once. It tells you how much slack must be recovered at the flops, which is what ECO effort follows. Every-group mode helps when each path group has an owner who wants their full debt. Whichever you pick, print it in the QoR report header so nobody compares the two.