How do you run signoff DRC from inside ICC2?

Short Answer

Point ICC2 at the IC Validator installation, set the foundry runset with signoff.check_drc.runset (ICC2), save the block because IC Validator reads the on-disk data, and run signoff_check_drc (ICC2). Results go to the run directory as block.RESULTS (ICC2) and block.LAYOUT_ERRORS (ICC2), and the error data file signoff_check_drc.err (ICC2) is stored in the design library for the error browser and automatic fixing.

Technical Explanation

• The environment comes first. ICV_HOME_DIR (ICC2) must point to an IC Validator installation compatible with the ICC2 version, and IC Validator In-Design needs an IC Validator license.
• signoff.check_drc.runset (ICC2) is the one required application option: at a minimum you must name the foundry runset. Without it the command has nothing to run.
• IC Validator reads the saved block, not what is in memory. Running save_block (ICC2) right before the check is part of the documented procedure; skipping it checks the last saved state.
• By default the tool reads the design view for the top block and standard cells, and only pin information from frame views for macros and IO pads. It checks routing layers only, and reports at most 1000 errors per rule, set by signoff.check_drc.max_errors_per_rule (ICC2).
• Output goes to signoff_check_drc_run (ICC2) unless signoff.check_drc.run_dir (ICC2) says otherwise. There you find block.RESULTS (ICC2) with the run summary, block.LAYOUT_ERRORS (ICC2) with details, and signoff_check_drc.log (ICC2).
• If the results will feed signoff_fix_drc (ICC2), set signoff.check_drc.ignore_child_cell_errors (ICC2) to true first. Zroute can fix only top-level violations, so this keeps the report to fixable ones.
• -select_rules (ICC2) and -unselect_rules (ICC2) narrow the check by rule-name patterns from the runset comments. -select_layers (ICC2) limits it to specific routing layers.

What To Check

• signoff.check_drc.runset (ICC2) points at the current foundry release.
• The block was saved immediately before the run.
• The violation count per rule in block.RESULTS (ICC2), and whether any rule hit the 1000 cap.
• Whether macros were read as frame views, and whether that is acceptable at this stage.
• That child-cell errors are excluded when the results will drive automatic fixing.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Zero violations after routing cleanup, with the current runset and macros read as real geometry for the final pass.
• Suspicious (illustrative): Under 50 violations concentrated on one layer or one macro edge; fixable with signoff_fix_drc (ICC2) or local reroutes.
• Hard stop: A rule at exactly 1000 errors: the cap was hit, the real count is unknown, and something systematic is wrong.

What The Interviewer Is Testing

• Does the candidate know the required option and the on-disk requirement?
• Awareness of the default views and the 1000-per-rule cap.
• Whether they know the output file names and where each lives.

Follow-up Question & Model Response

"Why would a rule show exactly 1000 violations?"

Candidate Model Response: Because signoff.check_drc.max_errors_per_rule (ICC2) defaults to 1000, and the report stops counting there. It usually means a systematic problem, such as a wrong via definition, a layer-map mismatch or a whole macro edge in conflict, not 1000 separate mistakes. I look at a sample of the reported locations to find the pattern first. If I need the full count, I raise the option, but fixing the pattern usually clears most of them.