What is TNS (Total Negative Slack)?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
Total Negative Slack (TNS) is the sum of every violating endpoint's slack across the design, added together as negative numbers. It measures how widespread timing failure is, in a way that a single worst-path number like WNS cannot.
Technical Explanation
WNS finds the single deepest violation; TNS instead asks how much violation exists everywhere, all added up.
- How it is computed: the tool adds up the slack of every endpoint whose slack is negative, and simply skips any endpoint that already passes, since a passing path contributes nothing.
- What it reveals that WNS cannot: a deep single violation and a shallow but widespread one can produce the same WNS, yet very different TNS values, so TNS is what actually distinguishes an isolated problem from a systemic one.
- What a large TNS usually points to: a broad, structural issue — a clock tree problem affecting many registers at once, or a systematically under-sized cell family — rather than one bad path that can be hand-fixed.
- How it is meant to be read alongside failing endpoint count: the number of endpoints that are actually violating, together with TNS, shows both how many paths are broken and how badly, which neither number alone tells you.
- How it behaves during optimization: as a design converges toward timing closure, TNS should shrink steadily toward 0.000 ns as violations get fixed one by one.
Common Mistake
The Trap: Trying to clear a large TNS by hand-fixing individual paths one at a time, the way you might close a single WNS violation.
- Hand edits work fine for one or two isolated paths.
- A large TNS usually needs a global fix — re-optimizing placement, re-buffering broadly, or resolving a clock tree issue — since thousands of small hand edits do not scale.
Follow-up Question & Model Response
If TNS is large but WNS is small, what does that combination tell you about where the problem lives?
Candidate Model Response: That combination usually means the design has many paths each violating by a small amount, rather than one or two paths violating badly, and small-but-widespread violations often point to something shared across those paths — a common clock uncertainty setting, a slightly under-driven clock buffer stage, or a cell family that is a touch too weak everywhere it is used. I would look for what many of the violating endpoints have in common before trying to fix any single path, since fixing the shared cause usually clears most of the list at once.
Practical Example
A design reports WNS of -15 ps but TNS of -8.4 ns spread across 640 endpoints. Tracing several of those endpoints back shows they all share one clock buffer stage that was accidentally left at a minimum drive strength; upsizing that single buffer clears most of the 640 violations at once.
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.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising