Closure is iterative. Analyze violations, classify root causes, apply a minimal-risk ECO, re-run STA, and confirm no new damage.
Setup violations call for less logic or wire delay, or for added latency.
Hold violations call for more minimum delay, from buffers or routing detours.
Always inspect path topology, not just worst slack numbers.
A report names the launch and capture flops, the slack, and the cells and nets along the path. The excerpt below is illustrative; tool text differs.
Illustrative setup excerpt (simplified):
Path: u_alu/prod[7] -> u_out/y[7]
slack -0.42 ns (required 2.00 ns, arrival 2.42 ns)
launch u_alu/clk rise, capture u_out/clk rise, next cycle
cells 14 (8 arithmetic, 4 mux, 2 buffer), nets 15
launch tcq 0.20 ns, remaining cell delay 1.62 ns, total net delay 0.60 ns
worst arc: multiply stage 0.31 ns, then net n_884 0.28 nsSlack is required minus arrival at the capture edge. Negative setup slack means the data arrives too late.
Read the bar left to right from the launch edge. Each segment is one kind of delay, drawn to scale.
The arithmetic: 0.20 + 1.62 + 0.60 = 2.42 ns, and 2.00 - 2.42 = -0.42 ns.
The split: 1.82 ns of cell delay against 0.60 ns of net delay, so cells dominate this path.
The target: any fix must remove at least 0.42 ns from the bar, in every required view.
The illustrative excerpt is cell-delay dominated because clock-to-Q plus remaining cell delays total 1.82 ns versus 0.60 ns of net delay. Fourteen cells alone would not establish that classification. Inspect aggregate delays, slew, loads and individual arcs before choosing sizing, restructuring or routing changes.
Classification narrows the candidates. Placed repeaters can reduce distributed RC delay and improve slew on a long net; driver sizing or branch cloning may help high loads. A logic-depth path may need restructuring or an actual arithmetic split if local ECOs cannot meet the budget. Select from parasitics, load/slew and shared-branch reports, then compare setup and hold.
No. Obtain cell and net delay totals, slew and loads. A long route could dominate despite the cell count. Upsizing cells at random is not a plan.
No. Re-run full STA and confirm no new damage. The loop ends at zero violations, not at one fix.
The violating cone plus the regression that must stay green through every ECO.
`timescale 1ns/1ps
module close_cone (
input logic [3:0] a, b, c,
input logic sel,
output logic [7:0] y
);
logic [7:0] prod;
always_comb begin
prod = a * b + c; // multiply-add cone: the reported critical path
y = sel ? prod : prod ^ 8'h0F;
end
endmodule
The report excerpt is illustrative; tool text differs.