Graph-Based vs Path-Based Analysis (GBA vs PBA)

Graph-based analysis (GBA)

GBA treats the design as a timing graph and, at every pin, keeps only the worst arrival time and the worst transition (slew) among all paths that reach it. It then propagates that single worst value forward. This is fast and safe, it can never be optimistic, but it is pessimistic: a downstream path inherits the worst slew from some other path that feeds the same node, even if the two can never happen together. The default STA run is GBA.

Path-based analysis (PBA)

PBA takes a specific path and re-computes its timing using the actual slews and conditions along that path, ignoring the worst-case values that belong to other paths. Because it uses the path's own reality instead of a pessimistic worst-of-everything, PBA almost always reports better (more positive) slack than GBA. The cost is runtime: re-analysing paths one by one is far slower than the single graph pass.

When to use PBA

You run GBA across the whole design to find every potential violation, then run PBA only on the near-critical and failing paths to see which are real. Paths that were failing in GBA often pass in PBA once the false pessimism is removed, recovering that margin can save real fixes. In PrimeTime this is report_timing -pba_mode (path or exhaustive); every serious signoff uses it to avoid over-fixing.

Worked example

A path reports -0.05 ns slack in GBA because node C inherited a slow slew from a neighbouring path. PBA re-times the actual path, finds its true (faster) slew, and reports +0.03 ns, the path meets timing and needs no fix at all. Multiply that across hundreds of near-critical paths and PBA can be the difference between closing timing and burning days on fixes that were never needed.