Path Group Prioritization: Theory Deep Dive

Foundational theory

Path Group Prioritization is central to Delay Graph & Path Analysis. Path groups classify timing intent so optimization and debug focus on the paths that matter for signoff and product modes. 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 groups classify timing intent so optimization and debug focus on the paths that matter for signoff and product modes.

• Primary metric: WNS by path group, reg2reg vs in2reg vs reg2out slack

• Primary artifact: path group summary, group_policy SDC, endpoint classification report

• Owners: STA lead, synthesis owner, PD owner

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

• WNS/TNS summarize tail risk across endpoints

Why this matters at signoff

At signoff, Path Group Prioritization 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 GROUPS

reg2reg   : FF -> logic -> FF     (core closure)
in2reg    : input -> FF           (interface)
reg2out   : FF -> output          (interface)
reg2cg    : FF -> clock gate      (special hold risk)

Optimize and report WNS per group — not global average only.

Worked intuition

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

2. Open WNS by path group, reg2reg vs in2reg vs reg2out slack 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 path group summary, group_policy SDC, endpoint classification report 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

Path group map

PATH GROUPS

reg2reg   : FF -> logic -> FF     (core closure)
in2reg    : input -> FF           (interface)
reg2out   : FF -> output          (interface)
reg2cg    : FF -> clock gate      (special hold risk)

Optimize and report WNS per group — not global average only.

Layer responsibilities

STA OWNERSHIP LAYERS — Path Group Prioritization

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.