What is WNS (Worst Negative Slack)?

Short Answer

Worst Negative Slack (WNS) is the most negative slack value found across every endpoint in a design or path group. It tells you the single most timing-critical path in the design, and how far the design is from meeting its target clock frequency.

Technical Explanation

Out of thousands of paths the tool checks, only one number in the whole report matters most for one simple question: how far off is the worst path?

• What it measures: the tool scans every endpoint's slack and reports the single smallest — most negative — value found. If every path passes, WNS is reported as 0.000 ns, never a positive number.
• What it tells you about frequency: a WNS of -0.200 ns on a 1.0 ns clock period means the design cannot actually run at that period; the true achievable period is roughly 1.0 ns plus that 0.2 ns shortfall.
• Why optimization tools chase it first: implementation tools spend their heaviest optimization effort on whichever path currently holds WNS, since fixing it moves the whole design's achievable frequency.
• Why it is reported per path group: the tool tracks a separate WNS for each defined path group — such as a core clock domain or a specific input-to-register group — since one clock domain being clean does not mean another is.

Follow-up Question & Model Response

If WNS looks fine but the design still fails at tapeout signoff, what else would you check?

Candidate Model Response: I would check Total Negative Slack and the failing endpoint count next, since a clean or small WNS can still hide thousands of small violations spread across the design. I would also confirm WNS is being reported per path group rather than only for the default group, since a clean core-clock WNS says nothing about a separate I/O or test-clock domain. Finally, I would rerun check_timing (PT) to rule out unconstrained endpoints that never made it into any slack calculation at all.