ExpertQuestion 133 of 141Source: Synopsys PrimeTime User Guide: Reporting and Debugging Analysis Results (Path-Based Timing Analysis)

Can you waive a GBA violation, and what evidence is required?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Yes, a GBA violation can be waived when exhaustive path-based analysis proves the endpoint passes, because GBA is deliberately pessimistic. The evidence must be regular exhaustive PBA to that endpoint, in every scenario where it failed, with no path limit cutting the search. Path-mode PBA, a single recalculated path, or ML-PBA do not qualify.

A decision tree from a GBA violation: run exhaustive PBA with no endpoint limit; if the recalculated slack is positive in every scenario the violation is waivable with the report attached; if PBA used path mode or ML-PBA, or an endpoint hit the path limit, the tree says not waivable. — Technical Reference DiagramCan you waive a GBA violation, and what evidence is required?

Technical Explanation

GBA is pessimistic by design: it uses the worst arrival and the worst slew among all signals feeding a pin, even when they come from different inputs. PBA recalculates one path in isolation, ignoring side-arc slews, and recomputes CRPR and crosstalk for that path.
Slack order changes under recalculation, so the worst GBA path to an endpoint may not be the worst PBA path. Recalculating the single worst failing path does not give the worst recalculated slack to that endpoint. This is why the waiver needs exhaustive mode.
report_timing -pba_mode exhaustive (PT) recalculates as many paths as needed to guarantee the reported paths are the worst recalculated ones. -pba_mode path does not search; its slack can be slightly optimistic, so it cannot back a waiver.
ml_exhaustive is not waiver evidence. The PT UG states that violations cannot be safely waived in an ML-PBA flow, since regular exhaustive PBA may find worse paths or more violating endpoints, and the tool warns with UITE-647.
Check the limits. pba_exhaustive_endpoint_path_limit (PT) defaults to infinity, which is guaranteed to cover all paths. If it is set to an integer and the limit is hit, then with pba_path_recalculation_limit_compatibility (PT) at its default of true the limited endpoint is left out of the search.
Waive per scenario. An endpoint that passes PBA in the slow corner but was also failing in another scenario needs its own evidence there.
The waiver record should name the endpoint, scenario, GBA slack, exhaustive PBA slack, tool version and the setting of the limit variables, so the next signoff run can repeat it.

What To Check

PBA mode in the evidence report is exhaustive, not path or ml_exhaustive.
pba_exhaustive_endpoint_path_limit is infinity, or the limit was not reached.
Recalculated slack is positive in every scenario the endpoint failed in.
Path headers show the paths as recalculated.

Command Checks & Actions

PrimeTime (pt_shell)report_timing -pba_mode exhaustive -nworst 1 -slack_lesser_than 0 -max_paths 1000

Worst recalculated path to each failing endpoint (the PT UG form).

PrimeTime (pt_shell)report_timing -pba_mode exhaustive -to $ep -max_paths 5

Evidence report for one endpoint.

PrimeTime (pt_shell)report_global_timing -pba_mode exhaustive

Global view of what remains after exhaustive PBA.

PrimeTime (pt_shell)report_app_var pba_exhaustive_endpoint_path_limit

Confirms the endpoint path limit setting for the record.

Healthy, Suspicious & Hard-stop Results

Healthy (illustrative): GBA -14 ps, exhaustive PBA +6 ps in all three failing scenarios, limit at infinity; waiver approved with reports attached.
Suspicious (illustrative): PBA slack under +2 ps, where a small extraction change could flip it; waive only with a note to recheck after the next ECO.
Hard stop: Evidence from path mode or ML-PBA, or an endpoint that hit the path limit. Not waivable.

Common Mistake

The Trap: Waiving from a report_timing -pba_mode ml_exhaustive (PT) run because it was the fast report used during ECO. The log had UITE-647. A later exhaustive run shows one of the "waived" endpoints at -9 ps on a path ML-PBA never reported, found two days before tapeout.

What The Interviewer Is Testing

Knowing why GBA is pessimistic and what PBA removes.
Can you explain why only exhaustive PBA supports a waiver?
Awareness of the endpoint path limit and ML-PBA traps.

Follow-up Question & Model Response

"Why not just run PBA on the worst GBA path to each failing endpoint?"

Candidate Model Response: Because recalculation changes the order of paths. The worst path under GBA might improve by 30 ps under PBA while the second-worst path improves by only 5 ps and becomes the true worst. Recalculating just the first one reports a pass that is not real. Exhaustive mode keeps recalculating until the reported path is the worst recalculated path to that endpoint.

Practical Example

Tapeout Scenario: Before signoff, 42 endpoints fail GBA setup by -3 to -21 ps (illustrative). report_timing -pba_mode exhaustive -nworst 1 -slack_lesser_than 0 -max_paths 1000 (PT), with the endpoint path limit at infinity, leaves 5 failing in the slow scenario and 1 in a second scenario. Those 6 go to ECO; the other 36 are waived with per-endpoint evidence in each scenario. One endpoint passed path-mode PBA at +3 ps but failed exhaustive at -4 ps, which is why path mode was not accepted.

PnR Flow Mentor Guide

Master the Physical Design Implementation Flow

Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.

Explore PnR Flow Mentor Guide →