“Here is a critical path report. Walk me through it.” The interviewer hands over a setup report excerpt and watches where the eyes go first.
The question tests triage, not vocabulary. A senior names the endpoints, the slack, and whether the fix is structural or physical.
Start with the header: startpoint, endpoint, path group, and slack sign. Then compare arrival against required before touching any detail.
REPORT (illustrative, not tool output)
Startpoint : u_pipe/s1_reg/Q
Endpoint : u_pipe/y_reg/D
Path Group : clk (max)
Slack : -0.30 ns (VIOLATED)
Arrival : 2.10 ns (launch tcq 0.25 + logic 0.85 + net 1.00)
Required : 1.80 ns (period 2.00 - setup 0.10 - uncertainty 0.10)The numbers above are invented for teaching. Only the structure matches a real report.
Read both bars from the launch edge on the left. The top bar is when the data gets there; the bottom bar is when it had to be there.
The net segment (1.00 ns) is the longest piece of arrival, longer than the logic (0.85 ns).
The shaded end of the required bar is margin already taken out: setup 0.10 and uncertainty 0.10.
The highlighted gap is the slack. Removing 0.30 ns from any part of arrival closes it.
Slack −0.30 ns means the path misses by 0.30 ns. Arrival exceeds required.
Arrival 2.10 ns is the launch edge plus tcq, logic, and net delay. Net delay is nearly half, so placement matters.
Required 1.80 ns is the period minus setup and uncertainty. This illustrative excerpt assumes ideal clocks (zero skew). In a propagated-clock report, launch clock latency appears in arrival and capture clock latency in required, so skew is included through those terms.
One endpoint is shown. Ask for WNS/TNS and endpoint clustering next. A shared high-fanout net or clock problem can affect many endpoints yet admit a local fix; one endpoint can require architecture work if its logic/latency budget is infeasible.
Term | What to say about it |
|---|---|
WNS (worst negative slack) | Worst reported deficit in the selected view; inspect path type and clock relationship before estimating frequency. |
TNS (total negative slack) | Aggregate deficit: triage extent and shared causes, not ECO/architecture by itself. |
Cell vs net split | Inspect logic depth, load, slew, fanout and routing. Sizing/buffering can improve net-heavy paths too, at power/min-delay cost. |
Launch vs capture clock | Inspect their edge relationship. Related generated clocks can be timed normally; unrelated clocks require CDC structures and appropriate exceptions. Either case can have setup or hold problems. |
Frequency estimate only: for a same-clock, single-cycle register path, fixed arrival/clock terms, no exceptions and setup slack s at period T, the zero-slack estimate is T_min = T - s. For illustrative T = 2.00 ns and s = -0.30 ns, T_min = 2.30 ns, f_max about 435 MHz. Re-run STA: other paths may limit, clock terms may change, and this formula does not apply directly to hold, IO, multicycle or different-clock paths.
Q: WNS is −0.05 ns but TNS is −40 ns. What does that change? Cluster endpoints by shared logic/net/clock causes. Try targeted load, buffering or clock fixes if shared causes explain the spread; consider restructuring/pipelining if the logic budget remains infeasible. Endpoint count alone does not choose the remedy.
Q: The net delay is 80 percent of arrival. What do you propose? Inspect RC, slew, load and fanout. Compare placement, buffering/driver sizing and replication; sizing can reduce RC delay through stronger drive. Pipeline only if the interface permits added latency. Recheck total delay, hold and power.
Q: Launch and capture clocks differ. What do you check first? The constraint between them. A missing or wrong generated clock makes the required time fiction.
“Upsize the cells.” Without load/slew and total-delay evidence this is a guess. It can help cell- or net-heavy paths, but adds upstream load and may worsen minimum delay or power.
“Add uncertainty and skew again to the reported deficit.” Reported slack already includes the modeled clock and margin terms. With required 1.80 ns and arrival 2.10 ns, reducing arrival by 0.30 ns reaches zero slack if everything else stays fixed. Any extra engineering margin must be justified separately, then all affected views rechecked.
“Fix this endpoint and tape out.” One endpoint fixed while TNS stays negative is not closure. Report both numbers every time.
Slack is −0.30 ns, so the constraint is violated. Data arrives 0.30 ns after the latest acceptable time.
No. Slack is +0.05 ns; the required time already includes the specified uncertainty. Recheck the implemented path and every required analysis view rather than double-counting that margin.
No. TNS describes extent in the selected view. Inspect endpoint clusters, shared causes, load/slew, clock terms and feasible fixes before estimating closure effort.
The report excerpt is invented for teaching; only its structure matches a real report. It assumes ideal clocks. The T = 2.00 ns example is illustrative.