Detail routing DRCs won't converge. What do you check?

Short Answer

First look at the DRC count per iteration to confirm it has really stopped falling. Then group the violations by type and location, because the pattern tells you the cause: a cluster at pins points to pin access, a dense area points to local density, macro edges point to access or blockages, and NDR nets point to rules. Fix that cause and rerun; more iterations rarely help once the curve is flat.

Technical Explanation

• Detail routing prints a DRC summary at the end of each iteration. A curve that drops steeply and then goes flat for several iterations means the router has done what it can locally.
• Group the remaining violations with get_drc_errors, filtering by type. One dominant type in one place almost always has one cause.
• Violations at pins of the same cell type across the block point to pin access: off-track pins, a bad cell abstract or a PG shape covering pins. check_routability helps confirm it.
• A tight cluster in open standard cell area points to local density. Congestion there is high, and the fix is spreading cells or lowering local density.
• Violations along macro edges point to pin access at the macro or a blockage too close to it. Pin access routing guides can help.
• Violations on NDR or shielded nets point to rules: vias that cannot meet the wider enclosure, or too many wide nets in one area.
• If redundant via insertion is running in a high-effort concurrent mode, relaxing it can let DRCs converge.

What To Check

• DRC count per detail routing iteration.
• Violation types and their locations, grouped.
• Congestion and cell density where violations cluster.
• Pin access results from check_routability for the affected cells.
• Any concurrent redundant via mode set above the default.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): The count keeps falling each iteration and ends below about 50, spread out and of mixed types.
• Suspicious (illustrative): A plateau of a few hundred violations in one or two places, with a clear cause.
• Hard stop: Thousands of violations spread across the block, which means the block is not routable as placed.

What The Interviewer Is Testing

• Whether you read the convergence curve before acting.
• Do you diagnose by pattern, not by count?
• A strong answer shows you know which causes need design changes rather than router effort.

Follow-up Question & Model Response

"When is more router effort the right answer?"

Candidate Model Response: When the curve is still falling steadily and the remaining violations are scattered and mixed. That usually means the router was stopped early or the area is tight but solvable. An incremental pass, or allowing more iterations, can finish the job. If the curve is flat, or the violations are concentrated, effort is not the problem.