Why it matters

Reading a report is easy once you have done one by hand. This worked example uses a launch flop feeding two capture flops through shared and private logic, so you can see which path is critical, how the shared segment couples the two endpoints, and what a single fix does to both.

The circuit (delays in ns, illustrative)

Clock period 2.0 ns, ideal clocks (zero latency), no uncertainty. Arrival at FF2 = 0.40 + 0.60 + 0.50 = 1.50; at FF3 = 0.40 + 0.60 + 0.80 = 1.80. Required = 2.0 - 0.10 = 1.90 for both.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

T, S = 2.0, 0.10
cq, A, B, C = 0.40, 0.60, 0.50, 0.80
arr2, arr3 = cq + A + B, cq + A + C
req = T - S
s2, s3 = req - arr2, req - arr3
assert abs(arr2 - 1.50) < 1e-9 and abs(arr3 - 1.80) < 1e-9
assert abs(s2 - 0.40) < 1e-9 and abs(s3 - 0.10) < 1e-9
# critical endpoint is FF3. Speeding the SHARED logic A by 0.15 helps both endpoints:
A_fast = A - 0.15
s2b, s3b = req - (cq + A_fast + B), req - (cq + A_fast + C)
assert abs(s2b - 0.55) < 1e-9 and abs(s3b - 0.25) < 1e-9
# speeding only branch B helps FF2 only and leaves the WNS unchanged
s3c = req - (cq + A + C)
assert abs(s3c - s3) < 1e-9
print("PASS: slacks FF2", round(s2, 2), "FF3", round(s3, 2), "-> after fixing shared A:", round(s2b, 2), round(s3b, 2))

FF3 is critical with slack +0.10 ns; FF2 has +0.40. A fix to the shared logic A improves both endpoints by the same amount, so with 0.15 ns removed the slacks become +0.55 and +0.25. A fix to branch B alone would improve FF2 but leave the worst endpoint unchanged. When a path report shows a shared prefix among many failing paths, fixing it pays off for all of them.

What the review looks for

• Closure effort starts with shared logic on many failing paths, not the single worst endpoint.

• A fix is accepted by what it does to the whole fanout cone, including setup and hold on the other endpoints.

• The report is read from the critical endpoint back along its worst predecessors.

Related topics

• Forward and Backward Propagation

• Next: A Tiny Timing Engine