Why set `signoff.check_drc.ignore_child_cell_errors true` before auto-fixing?

Short Answer

Zroute can fix only top-level violations, so the check that feeds auto-fix should report only those. Setting signoff.check_drc.ignore_child_cell_errors (ICC2) to true makes signoff_check_drc (ICC2) write only top-level errors to the error data. Child-cell errors still exist and need their own check and owner.

Technical Explanation

• The option defaults to false, which reports both top-level and child-level errors to the error data file.
• The guide gives it as the setting for generating auto-fix input: with true, signoff DRC reports only violations Zroute can fix.
• It also matters when you reuse results through signoff.fix_drc.init_drc_error_db (ICC2). Existing results can feed signoff_fix_drc (ICC2) only if they were produced with the settings for the automatic fixing flow.
• There is a counting reason too. signoff.check_drc.max_errors_per_rule (ICC2) defaults to 1000, and that cap includes both top-level and child-level violations. Child errors can fill the per-rule list and push out top-level ones.
• signoff_fix_drc (ICC2) itself does not check child blocks during its loops, so child errors would only add noise to its targets.
• The error data shows a child-level error on one cell instance only, which makes lower-level errors easier to find when you do look at them.
• Ignoring is not waiving. After auto-fix, run a check with the option back at false, or a standalone IC Validator run, and send child errors to whoever owns the cell or macro.

What To Check

• The option value in the run that produced the auto-fix input.
• Per-rule counts near 1000, where child errors may be crowding out top-level ones.
• A full-hierarchy check after fixing, with owners for every child error.
• result_summary.rpt (ICC2) reasons such as shapes not Zroute modifiable.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Auto-fix clears all top-level targets, and the full-hierarchy check shows only known child errors with owners.
• Suspicious (illustrative): A rule sits at exactly 1000 errors in a run with child errors included. The cap may be hiding top-level violations.
• Hard stop: The final signoff check was run with the option still true. Child-cell errors were never reported.

What The Interviewer Is Testing

• Knowing Zroute fixes top-level violations only.
• Linking the per-rule cap to mixed top and child counts.
• A strong answer separates ignoring for auto-fix from signing off.

Follow-up Question & Model Response

"Who fixes child-level violations then?"

Candidate Model Response: Whoever owns the child. For a standard cell that is the library team, for a hard macro the IP vendor, and for a sub-block its own implementation owner, who reruns fixing at that level. Sometimes the fix is at the top anyway, for example moving a top-level route that makes a child shape fail a context rule. The point is that each child error gets an owner and a decision, not that auto-fix at the top can reach it.