Cell vs Net Delay Budgets: Theory Deep Dive

Foundational theory

Cell vs Net Delay Budgets is central to Delay Graph & Path Analysis. Path delay splits between library cell arcs and interconnect parasitics; implementation fixes target the dominant contributor. Senior STA engineers always tie slack movement to corner, mode, constraint set, and parasitic view — not just a single report line.

Core concepts explained

• Path delay splits between library cell arcs and interconnect parasitics; implementation fixes target the dominant contributor.

• Primary metric: cell delay %, net delay %, high fanout net count, transition violations

• Primary artifact: report_timing -cap -tran -nets, delay breakdown report, RC extraction log

• Owners: PD owner, STA owner, extraction owner

• Setup: max delay path; Hold: min delay path

• WNS/TNS summarize tail risk across endpoints

Why this matters at signoff

At signoff, Cell vs Net Delay Budgets failures block tapeout or force risky ECO. The timing graph turns netlist + parasitics + constraints into slack. Wrong analysis setup wastes weeks of PD effort.

Mental model

PATH DELAY BREAKDOWN

cell delay  ████████████████  62%
net delay   ██████████        38%

If net-heavy -> routing/RC fix.
If cell-heavy -> sizing/VT/upsize.

Worked intuition

1. Name corner, mode, and view for the failing run.

2. Open cell delay %, net delay %, high fanout net count, transition violations and identify worst path group.

3. Read critical path: cell vs net, launch/capture clocks.

4. Check constraints on that path (exceptions, generated clocks).

5. Collect report_timing -cap -tran -nets, delay breakdown report, RC extraction log and tag database versions.

6. Classify: constraint bug, view mismatch, or real path.

7. Propose minimal ECO and list MMMC+SI regression.

Common misconceptions

• One typical corner is enough for signoff.

• False paths can be applied broadly to green-wash violations.

• Implementation WNS equals signoff WNS without view mapping.

• Setup fix automatically preserves hold.

Visual reinforcement

Delay breakdown bar

PATH DELAY BREAKDOWN

cell delay  ████████████████  62%
net delay   ██████████        38%

If net-heavy -> routing/RC fix.
If cell-heavy -> sizing/VT/upsize.

Layer responsibilities

STA OWNERSHIP LAYERS — Cell vs Net Delay Budgets

layer              owns                         failure mode
----------------   --------------------------   ---------------------
constraints        clocks, IO, exceptions       false violations
implementation     cells, nets, placement       real path delay
extraction         SPEF/RC corners              view mismatch
signoff policy     derate, MMMC matrix          margin disputes
closure           ECO order, regression        fix breaks other corner

STA deep dive

Slack is a path story — read the graph, not just the number.

Concept diagram

TIMING GRAPH

FF --cell-- logic --net-- logic --cell-- FF
launch                              capture

Metric graph

SLACK TAIL

paths |    ***
      |  *******
      |*********  <- fix WNS first

Reports and artifacts

• WNS/TNS

• path slack histogram

• cell vs net %

• path group summary

Mini case study

WNS -90ps but 80% net delay on one congested route — PD route fix beat upsizing three cells.

Debug branches

• Cell-heavy -> sizing/VT

• Net-heavy -> route/layer

• Check launch/capture clocks

Senior review question

Ask: what corner/mode/view proves this topic is closed or failing?

Key takeaways

• State corner, mode, view, and database tag with every slack claim.

• Run setup and hold plus MMMC regression after every ECO.

Common pitfalls

• Comparing STA runs with different SPEF or SDC tags.

• Broad false_path to green-wash violations.

• Setup-only ECO without hold check.

Theory reinforcement

The timing graph turns netlist + parasitics + constraints into slack.