A QoR number means nothing until the run reproduces. Pin the RTL revision, the constraint sources, the library, and the flow script.
Rerun the exact script before changing anything. If the number moves between identical runs, the flow itself has noise to fix first.
Pin down | Why it matters |
|---|---|
RTL revision | Edits move paths, so the same source must give the same netlist. |
Constraints | Clock and delay asks set every slack, so a changed ask looks like a changed design. |
Library and script | Cell choice and pass order vary results, so both stay fixed during debug. |
Sort paths by slack and start with the worst one. Slack is required time minus arrival time, in the same EXAMPLE time units.
One EXAMPLE path asks for 5.0 ns and arrives at 5.6 ns. The calc block works the slack.
EXAMPLE parameters: required time 5.0 ns, arrival time 5.6 ns
slack = required - arrival = 5.0 - 5.6 = -0.6 ns
verdict: negative slack, so this path misses its askFixing a kinder path first wastes the run. The worst path sets the clock the design can close.
Each worst path falls into one of four classes. The class picks the fix, so naming it comes before editing.
Class | Typical sign | Fix direction |
|---|---|---|
Constraint | Missing clock, loose path, or impossible ask | Correct the ask, then rerun before touching RTL. |
RTL structure | Latch, deep priority chain, or repeated arithmetic | Restructure the source logic. |
Library | Missing cell or weak drive option | Widen the cell choice or revisit the library setup. |
Tool behaviour | Pass order or mapping choice varies the result | Narrow the flow change and compare against the pinned baseline. |
Change one thing per rerun. Two simultaneous fixes hide which one worked.
Slack is 5.0 minus 5.6, which is -0.6 ns. The path misses its ask.
The run cannot say which fix helped. One change per rerun keeps cause and effect linked.