What is the difference between worst negative slack (WNS) and total negative slack (TNS), and why does signoff track both?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
Worst negative slack (WNS) is the single most negative slack value anywhere in the design — one number that tells you how bad the worst violation is. Total negative slack (TNS) is the sum of every negative slack value across all failing paths, so it tells you how widespread the problem is, not just how deep.
Technical Explanation
The two numbers answer different questions, and neither one alone tells the whole story.
- WNS is a single worst-case value. It is the slack of the single path furthest below zero. Two designs can have the same WNS of -50ps and look identical on that metric alone.
- TNS adds up every violation, not just the worst one. If one design has one path at -50ps and another has 500 paths averaging -10ps each, the second design has roughly ten times the TNS even though its WNS is far smaller in magnitude.
- WNS tells you where the hardest single fix is. Chasing WNS down usually means finding and fixing one specific critical path, often with a targeted ECO like a cell resize.
- TNS tells you how much optimization effort is left overall. A high TNS with a modest WNS usually means many paths are all a little short, which points to a systemic issue — a library corner, a clock uncertainty setting, or a placement density problem — rather than one bad path.
- Why signoff needs both: a design can pass a WNS-only gate (say, WNS better than -20ps) while still carrying hundreds of small violations that add up to a real yield or timing-margin risk, which only shows up in TNS.
- The two often move together but not always. A single very large fix can drop the WNS to zero while barely denting TNS if many other paths are still slightly negative, so tracking only WNS during closure can hide the remaining volume of work.
Common Mistake
The Trap: reporting only WNS in a status update and calling the design "almost closed" because the worst path looks small.
- A block can have a WNS of -5ps, which sounds nearly clean, while carrying a TNS of -3ns spread across 400 paths — a large amount of remaining optimization work the WNS number hides entirely.
- Fixing the single WNS path first can feel like progress while leaving the bulk of the schedule risk, the 400 smaller violations, untouched.
Follow-up Question & Model Response
Two blocks both report a WNS of -30ps. Block A has a TNS of -30ps and Block B has a TNS of -2,400ps. Do they need the same closure plan?
Candidate Model Response: No, they point to very different problems even though the worst path looks equally bad. Block A's TNS equal to its WNS means essentially one path is failing, so a targeted fix — resizing a cell or adding a buffer on that specific path — should close it quickly. Block B's much larger TNS means dozens or hundreds of paths are all failing by smaller amounts, which usually signals something systemic: a clock uncertainty value that is too conservative, a placement region that is too dense, or a library corner mismatch. I would investigate the common cause behind Block B's violations before attempting individual path fixes, since fixing them one at a time would take far longer than addressing the root cause.
Practical Example
After the first placement-optimization pass on a 1.2GHz core, report_global_timing (PT) shows WNS = -18ps and TNS = -1,850ps across 210 endpoints in the func_grp path group. A second block from the same tapeout shows WNS = -18ps but TNS = -20ps across just one endpoint. The team prioritizes the first block for a clock-uncertainty and placement-density review, since 210 endpoints failing by an average of under 10ps each points to a shared cause, while the second block gets a one-line ECO buffer insertion on its single failing path.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Continue practising