Why does enabling SI analysis create new PBA-worthy paths that GBA alone never flagged?

Short Answer

Turning on signal integrity (SI) analysis adds a crosstalk delay margin to every net PrimeTime believes could be an aggressor or victim, and graph-based analysis (GBA) applies that margin using a bounded worst-case switching window rather than a path's real timing. That extra, pessimistic margin can push previously comfortable paths close enough to zero slack that they now need a path-based (PBA) re-check to confirm whether the violation is real.

Technical Explanation

• Graph-based analysis (GBA) checks every arc in isolation and keeps the worst delay seen at each stage, so with SI on it adds a crosstalk delta wherever an aggressor could plausibly switch inside the window, without checking whether that aggressor is on the same clock edge as the rest of the path.
• Path-based analysis (PBA) re-times a specific path end to end using its own real timing, so an aggressor's actual switching window can be narrowed once the tool sees the aggressor's timing relative to the victim.
• Because GBA's SI margin is added independently at each stage, a path with several separately timed near-aggressors can look far worse under GBA than any single real switching scenario would ever produce.
• This means SI analysis inflates the near-critical path count first: paths that had healthy slack under a plain graph-based run now sit close enough to zero to need a path-based re-check.
• report_si_bottleneck (PT) ranks nets by delta delay, which is the right first filter before spending path-based re-timing effort on every marginal path SI analysis touches.
• Because PBA typically recovers slack that SI-driven GBA pessimism removed, signoff commonly runs GBA broadly and reserves PBA for the smaller set of paths SI analysis pushes near the edge.
• A practical signoff flow runs GBA with SI on for the whole design, filters to paths within some slack window of zero, then re-times only that filtered set with PBA, so the expensive re-timing effort scales with the number of marginal paths, not with the size of the whole design.
• The gap between a GBA-with-SI slack number and the PBA-recovered slack on the same path is itself useful data: a large gap on a given path usually points at several stacked, independently timed near-aggressors rather than one dominant real coupling event.

Follow-up Question & Model Response

Does that mean signoff should just skip GBA-with-SI and run PBA everywhere?

Candidate Model Response: Not in most flows, because path-based analysis is far more expensive to run across an entire design, since it re-times each path individually instead of reusing one arc-level pass. The typical approach runs GBA with SI enabled across the whole design first, since it is conservative and fast, then filters to the paths that fail or sit close to zero slack and re-runs only those through PBA. That keeps runtime manageable while still catching the real crosstalk-driven failures, since PBA on the filtered set gives the accurate, path-specific answer.