Graph-Based vs Path-Based Analysis
Recovering margin the fast analysis throws away
When a design is a few picoseconds short at signoff, you do not always have to touch it. Understanding graph-based versus path-based analysis can recover the margin for free, and it is a favourite advanced interview topic.
Graph-based analysis (GBA)
GBA is the default, fast mode. At each pin it keeps only the worst slew and worst arrival time, then propagates that single worst case to every path passing through. It is fast because it stores one number per pin, but it is pessimistic: a given path may never actually see that worst-case slew, yet it is penalized as if it did.
Path-based analysis (PBA)
PBA re-analyzes specific paths using the actual slew that propagates along each one, instead of the worst slew seen anywhere at each pin. Because it uses path-specific conditions, it removes the artificial pessimism GBA added and reports a more accurate, usually better, slack.
| GBA | PBA | |
|---|---|---|
| Slew used | Worst at each pin | Actual per path |
| Speed | Fast (whole design) | Slow (selected paths) |
| Pessimism | Higher | Lower, more accurate |
| Typical use | Full-design signoff | Recover failing paths |
How it is used in practice
You run GBA across the whole design for speed, then run PBA only on the paths that fail or are marginal. Many of those failing paths pass once analyzed accurately, so you close timing without changing the netlist at all. PBA is a recovery tool, not the everyday mode.
the senior answer: GBA is fast but pessimistic because it uses worst-case slew at every pin; PBA re-times the real paths and recovers that pessimism. Run PBA on the failing endpoints before doing any ECO, because the cheapest fix is the one where the path was never really failing.
PBA is much slower per path, so you cannot run it on the entire design. It is targeted: feed it the GBA-failing endpoints. And PBA recovers pessimism, it does not fix a path that is genuinely too slow.