When do you run exhaustive PBA, and how do you keep it affordable?

Short Answer

Run exhaustive PBA when graph-based violations are close enough that removing pessimism could clear them, and always for final signoff numbers. Keep it affordable by scoping it: search only failing paths with -slack_lesser_than, check with -pba_mode path first, and narrow to the groups or endpoints you need. Never waive a violation on ml_exhaustive results, because ML-PBA can miss worse paths and extra failing endpoints.

Technical Explanation

• Path mode recalculates the paths graph-based analysis picked without searching further, so its slack either matches a full search or is slightly optimistic. Exhaustive mode keeps searching until the returned paths are the worst after recalculation.
• The PT UG advice is to use exhaustive with -slack_lesser_than, run it only when path mode shows slacks near the target, keep the scope specific, and set timing_report_use_worst_parallel_cell_arc (PT) to true.
• report_timing -pba_mode exhaustive -slack_lesser_than 0 (PT) returning no paths means no violations. -max_paths and -nworst count at the end of the search, and a large -nworst raises runtime quickly.
• pba_exhaustive_endpoint_path_limit (PT) defaults to infinity, which is guaranteed to find the worst slack. An integer is faster when graph and path slacks already agree, but by default an endpoint that hits the limit drops out of the search with a UITE-480 warning.
• ML-PBA is a subset of exhaustive. If it reports no violations, exhaustive agrees, but when it reports violations there may be worse paths and more endpoints, and the tool warns with UITE-647. It needs the endpoint limit at infinity and a PrimeTime-ADV-PLUS license.
• By default only the data portion is recalculated; clock paths are recalculated only with pba_recalculate_full_path (PT) set to true.
• Early on, cover-design reports with path-mode PBA find violations quickly; exhaustive is for signoff.
• fix_eco_timing -pba_mode exhaustive (PT) fixes against recalculated slack, so no cells are spent on pessimism.

What To Check

• The gap between graph-based and path-mode slack on the worst paths.
• The endpoint limit setting and any UITE-480 warnings.
• UITE-647 warnings anywhere in a signoff log.
• Runtime per path group.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Exhaustive PBA on 420 graph-based violators leaves 36, and the search finishes in under an hour.
• Suspicious (illustrative): UITE-480 limit warnings on dozens of endpoints, which left the search and are unverified.
• Hard stop: Any signoff waiver based on a log that contains UITE-647.

What The Interviewer Is Testing

• The three modes and ML-PBA's subset rule.
• Can you name the scoping levers and the endpoint limit behaviour?

Follow-up Question & Model Response

"Why is path-mode PBA not enough for signoff?"

Candidate Model Response: Path mode recalculates only the paths graph-based analysis already chose, with no further search. Another path to the same endpoint may have worse recalculated slack than the one ranked first, so path mode can be slightly optimistic. Exhaustive mode keeps searching until the returned paths are guaranteed to be the worst after recalculation. Signoff needs that guarantee.