What's the difference between graph-based and path-based analysis?

Short Answer

Graph-based analysis times every node once and keeps the worst arrival and the worst slew at each pin, even when they come from different inputs, so it is fast and pessimistic. Path-based analysis takes one path, drops the side inputs and recalculates the delays with the slews that belong to that path, so it is more accurate and slower. You find violations with GBA and use PBA to see how much of the remaining violation is real.

Technical Explanation

• In GBA, PrimeTime considers both the worst arrival time and the worst slew among the signals feeding a pin, even if the latest signal is not the one with the slowest slew. That bound covers every path at once, which is why a whole design can be timed in one update.
• PBA recalculates a path in isolation: it propagates the edge along the path, ignores slews from side arcs and redoes delay calculation. CRPR and crosstalk delta delays are also recomputed for that path.
• report_timing -pba_mode path (PT) recalculates the paths GBA selected without searching for others. Its slack either matches a full search or is slightly optimistic, so it is a quick estimate of how much PBA helps.
• report_timing -pba_mode exhaustive (PT) searches as many paths as needed to guarantee that the reported paths are the worst recalculated ones. That is the mode signoff decisions should use.
• Slack order can change after recalculation, so the worst GBA path to an endpoint is not always its worst PBA path. Recalculating only the top path of each endpoint can therefore be optimistic.
• By default only the data portion is recalculated; clock paths are recalculated only if pba_recalculate_full_path (PT) is set to true.
• A faster mode, report_timing -pba_mode ml_exhaustive (PT), uses machine learning to speed up the search and may miss a worse path, so it helps early triage but should never be the basis for a waiver. It needs a PrimeTime-ADV-PLUS license (PT UG licensing table).

What To Check

• GBA WNS and endpoint count first, so you know the size of the problem PBA is being asked to shrink.
• The path mode improvement per endpoint, as a quick estimate.
• The exhaustive result for every endpoint you plan to waive or leave unfixed.
• The header of each report, which shows the path type as recalculated when PBA was applied.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): PBA exhaustive recovers 5 to 15 ps on reconvergent paths and every remaining endpoint is either fixed or clean.
• Suspicious (illustrative): path mode shows +12 ps while exhaustive shows only +2 ps on the same endpoint, meaning another path to it is worse after recalculation.
• Hard stop: A path waived on path mode or ml_exhaustive results only. Re-run exhaustive before any signoff decision.

What The Interviewer Is Testing

• Can you explain where GBA pessimism comes from, in terms of slew and arrival merging?
• Knowing that path mode may be slightly optimistic and exhaustive is the signoff mode.
• An awareness that slack order changes after recalculation shows real hands-on use.

Follow-up Question & Model Response

"Why not run PBA exhaustive on the whole design from the start?"

Candidate Model Response: Its runtime grows with the number of violating paths it must search, and early in closure there can be many thousands. GBA is conservative, so a path clean in GBA is clean in PBA, and fixing with GBA first removes most violations cheaply. The PT user guide recommends running exhaustive only once path mode shows slack close to the target, and bounding it with -slack_lesser_than. I would use it at the end, on the small set of paths that remain.