20,000 signoff DRCs appear late in the schedule. How do you triage?

Short Answer

Don't start fixing. A flood that large almost always comes from a few root causes, so first group the violations by rule and by region, then ask what changed. Fill, a macro abstract that differs from its GDS, and a rule deck or layer map that does not match the design are the usual suspects. Only after the cause is known do you decide what signoff_fix_drc (ICC2) can repair and what must be fixed upstream.

Technical Explanation

• Look at counts per rule before looking at any single error. The rule table in cell.RESULTS (ICV), written only when the verbose_results_file (ICV) argument of run_options() (ICV) includes ERRORS, gives violations per rule, and a count of exactly 1000 is suspicious because signoff.check_drc.max_errors_per_rule (ICC2) defaults to 1000, so the real number may be higher.
• Group by region with the ICV heat map. Set signoff.check_drc.enable_icv_explorer_mode (ICC2) to true, run signoff_check_drc (ICC2) and open View > Map > ICV Heatmap. It needs IC Validator P-2019.06 or later and an IC Validator NXT license.
• Violations that cluster along macro edges point at the abstract. By default signoff DRC reads only pin data from the frame view of macros and pads, so a hard macro whose GDS differs from its frame can be clean in ICC2 and fail on the merged layout.
• Violations spread evenly over the whole die on one or two rules point at fill or at the deck. By default signoff DRC reads fill data only if it is newer than the design view, so fill older than the last design save is silently skipped, and a new runset or layer map can rename or renumber layers under you.
• Narrow reruns keep the loop short. signoff_check_drc -select_rules (ICC2) checks only rules matching a pattern taken from the runset COMMENT section, and -coordinates (ICC2) limits the check to a region.
• Know what automatic fixing will skip. signoff_fix_drc (ICC2) ignores rules with more than 1000 violations by default, fixes data nets only, excludes rules unsuitable for autofix and fixes top-level violations only, because Zroute cannot change child cells.
• Read result_summary.rpt (ICC2) after each fix run. TOTAL, TARGETED and REMAINING TARGETED per rule, plus the reason codes in COMMENT, tell you which rules the router never tried.

What To Check

• Violation count per rule, and which rules sit at the 1000 reporting cap.
• Heat map clusters: macro edges, one region, or uniform over the die.
• Runset, layer map and fill versions against the last clean run.
• Rules that the automatic fixer marked as not targeted, and why.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): The 20,000 collapse to three causes; after a refill and a strap fix found through the macro GDS merge, 500 routing violations remain and automatic fixing clears 460.
• Suspicious (illustrative): Several rules still sit at exactly 1000 after the root-cause fix, so the true count is unknown.
• Hard stop: Any rule that clusters on a macro edge and cannot be reproduced once the macro GDS is merged, or violations inside child cells counted as fixed.

What The Interviewer Is Testing

• Can the candidate explain why a large count usually has few causes?
• Knowledge of the reporting cap and the autofix skip threshold, both 1000 by default.
• Does the answer name the frame-view limitation for macros?

Follow-up Question & Model Response

"Why would a rule show exactly 1000 violations in two consecutive runs even though you fixed hundreds?"

Candidate Model Response: Because signoff.check_drc.max_errors_per_rule (ICC2) stops reporting at 1000 per rule by default. If the real count was 4,000, fixing 800 still leaves more than 1000, and the report looks unchanged. Raise the limit for that rule's investigation run, or check a smaller region, to see the real trend. The same threshold matters to automatic fixing, since signoff_fix_drc (ICC2) skips rules above 1000 by default.