When do you chase WNS, and when TNS?

Short Answer

Chase TNS when there are many shallow violations and the aim is to reduce the amount of fixing work left. Chase WNS when a few deep paths set the frequency or block signoff. Early in closure TNS tells you how much work remains; at signoff every violating endpoint must be fixed, so the order is only a question of which method moves the design fastest.

Technical Explanation

• WNS is the single worst slack. It sets the achievable frequency for that clock and tells you whether a structural fix is needed. TNS is the sum of negative slack over violating endpoints and tells you how much fixing remains.
• In PrimeTime, timing_report_union_tns (PT) defaults to true, which counts each violating endpoint once, using its worst slack across path groups. Check the setting before comparing TNS numbers between runs or between tools.
• A high TNS with a small WNS usually means many endpoints just short, often from one shared cause such as a clock uncertainty change or a weak cell on a common path. Bottleneck analysis and broad sizing attack it well.
• A deep WNS with low TNS means a few structurally bad paths. Sizing will not fix them; they need restructuring, a placement change, a pipeline stage, or a constraint review.
• Clock-network ECO can be told to target TNS. fix_eco_timing -cell_type clock_network -target_violation_type tns (PT) allows some endpoints to get worse while total negative slack improves, with WNS held at the existing value or at a limit set by -wns_limit. Clock network fixing runs only in the physically aware flow, and TNS targeting needs a PrimeTime-ADV license (PT UG, ECO Flow).
• Path groups decide what "worst" means during implementation. If a few deep paths dominate one group, the optimizer spends effort there; splitting them into their own group lets the other endpoints get attention too.
• Normalized slack is a useful third number when clocks differ. A -20 ps slack on a four-cycle path matters less to frequency than -10 ps on a single-cycle path, and report_timing -normalized_slack (PT) ranks paths by that effect once timing_enable_normalized_slack (PT) is set to true before the timing update.
• Near signoff the distinction fades. Every violating endpoint must be fixed or waived with evidence, so you track both numbers and the violating endpoint count.

Follow-up Question & Model Response

"Why can fixing WNS first make TNS worse?"

Candidate Model Response: Fixing the worst path often means upsizing cells or changing clock arrival on registers that other paths share. Larger cells add load to their drivers and slow side paths, and clock changes shift slack from one stage to the next. Many endpoints that were slightly negative can get a little worse while the worst one improves. That is why I compare WNS, TNS and endpoint count together after each pass. If WNS is the blocker, I fix it with the smallest local change I can find and re-check the neighbours before moving on.