Every timing report ends in a few numbers: worst negative slack, total negative slack and the count of failing endpoints. Reading them well is a skill: they answer different questions, and each can mislead if used alone.
Slack of an endpoint is required time minus arrival time (setup) or arrival minus required (hold). Negative slack is a violation.
WNS, worst negative slack, is the minimum (worst) slack over all endpoints; a negative value is a violation, and a positive one tells you the design is clean with that much margin.
TNS, total negative slack, is the sum of all negative slacks. It measures the total amount of violation, not the worst case.
Failing endpoint count (FEP) is the number of endpoints with negative slack.
Endpoint | Setup slack (ns) |
|---|---|
ff_a/D | +0.12 |
ff_b/D | -0.30 |
ff_c/D | -0.05 |
ff_d/D | +0.40 |
ff_e/D | -0.30 |
slacks = {"ff_a/D": 0.12, "ff_b/D": -0.30, "ff_c/D": -0.05, "ff_d/D": 0.40, "ff_e/D": -0.30}
neg = [s for s in slacks.values() if s < 0]
wns = min(slacks.values())
tns = sum(neg)
fep = len(neg)
assert abs(wns - (-0.30)) < 1e-9
assert abs(tns - (-0.65)) < 1e-9
assert fep == 3
print("PASS: WNS =", wns, "TNS =", round(tns, 2), "FEP =", fep)WNS is -0.30 ns, TNS is -0.65 ns and three endpoints fail. Two designs with the same WNS can be very different: one with a single failing endpoint is a local problem, one with 5,000 failing endpoints is a systemic one. TNS and the failing count separate them.
A path is more critical the smaller its slack. Closure work prioritises by criticality: the most negative paths first, then groups with many failing endpoints. A positive slack path with tiny margin is still critical in the sense that any change (an ECO, a different corner, a variation derate) can flip it.
WNS, TNS and FEP are reported per path group and per corner, not only as one chip-wide number.
A clean WNS in a view with the wrong constraints is not clean: check the unconstrained endpoint count alongside slack.
Trends matter more than a snapshot: the magnitude of TNS shrinking, i.e. TNS rising towards zero, run over run is progress even when WNS has not moved.
Design A has a single marginal failing endpoint. Design B has at least 2,400 failing endpoints: WNS -0.05 ns means each failing slack lies between -0.05 ns and zero, so 120 / 0.05 = 2,400 is the minimum count. That is a systemic problem such as a clock or constraint issue, not a single hard path.