First routed run shows 5,000 setup violations. What's your plan?

Short Answer

Do not start fixing. Five thousand violations on a first routed run is a diagnosis problem: first prove the constraints and the analysis setup are right, then group the violations until they collapse into a handful of causes. Only after that do you decide whether each cluster is ECO work in PrimeTime or a reason to go back to placement or floorplan.

Technical Explanation

• Step one is trust. Run check_timing (PT) and report_analysis_coverage (PT) before looking at a single path. A missing clock or a wrong multicycle can create thousands of false violations.
• Step two is the global picture. report_global_timing (PT) reports WNS and TNS across all violating endpoints and splits them into the four topologies: in-to-reg, reg-to-reg, reg-to-out and in-to-out. TNS concentrated in in-to-reg or reg-to-out points at I/O delays first.
• Step three is clustering. Group by path group and clock pair (report_global_timing -include {per_clock_violations} (PT)), then by hierarchy and by region in the layout. Five thousand endpoints often reduce to five or six clusters.
• Step four is bottleneck analysis. report_bottleneck (PT) lists the leaf cells with the highest bottleneck cost, which are the cells shared by the most violating paths. One weak driver shared by 3,000 paths is one fix, not 3,000. The PT UG says to set timing_save_pin_arrival_and_slack (PT) to true before the first timing update when you use this command.
• Step five is sizing the gap. A cluster that is a few tens of picoseconds short with many shallow endpoints is ECO work: sizing, Vt swaps, buffering with fix_eco_timing (PT). A cluster where the logic depth or the wire length alone exceeds the period will not close with ECOs, because PrimeTime ECO only resizes and buffers existing logic.
• Check the GBA versus PBA gap on a sample. report_timing -pba_mode exhaustive (PT) on the worst paths of each cluster shows how much is analysis pessimism. Scope it with -slack_lesser_than, not all 5,000 endpoints.
• Compare the same paths in ICC2 with report_qor (ICC2) and in PrimeTime with report_qor (PT). The two commands share a name but not an engine or parasitics. A cluster that is clean in ICC2 and failing in PT is a correlation issue, not a design issue.

What To Check

• Unconstrained endpoints, missing clocks and untested setup checks in the coverage report.
• WNS, TNS and violating endpoint count per topology category and per clock pair.
• The top bottleneck cells and how many violating paths each one carries.
• Logic depth and net length on the worst path of each cluster against the clock period.
• GBA against exhaustive PBA slack on a sample of each cluster.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Coverage shows zero untested setup checks, and the violations collapse into fewer than ten clusters, each within about 50 ps of closing.
• Suspicious (illustrative): One clock pair holds 70% of TNS, or ICC2 and PT disagree by more than 30 ps on the same paths.
• Hard stop: Thousands of untested or unconstrained endpoints, or a cluster whose logic depth alone exceeds the period. Fix constraints or re-implement before any ECO.

What The Interviewer Is Testing

• Do you validate constraints and coverage before touching the netlist?
• Can you turn thousands of endpoints into a small number of root causes?
• Knowing where ECO stops working and re-implementation starts.

Follow-up Question & Model Response

"How do you decide whether a cluster is ECO work or a placement problem?"

Candidate Model Response: I look at the worst path of the cluster and ask what fraction of the period is fixed cost. If the cell delays alone on the minimum logic depth, plus the wire delay of a straight route between the endpoints, already use most of the period, sizing cannot recover it. If the gap is a few tens of picoseconds and spread across many shallow endpoints, sizing, Vt swaps and buffering will close it. A detour or a long wire between two macros points to floorplan, not ECO.