How are known, accepted DRC violations waived without hiding new ones?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
In IC Validator you classify each accepted error once, export the classifications to an error classification database (cPYDB), and import that database into later runs through the match_errors (ICV) argument of error_options() (ICV). An error comes back pre-classified only when it matches an entry in the cPYDB, so anything new or changed still shows up unclassified. For hierarchical matching, run with -pec EXPLODE (ICV), especially on the run that creates the cPYDB.
Technical Explanation
- Classify errors from the first run with
pydb_report(ICV) or VUE, export them to a cPYDB withpydb_export(ICV), and name that cPYDB inmatch_errors(ICV) on later runs. Matched errors appear pre-classified incell.LAYOUT_ERRORS(ICV). - The classes are Error (unclassified, the default), Ignore (fix later in the flow), Waive (intended, will exist at signoff), Watch (fix in the next design cycle), Fixed and Unmatched. Only Waive means accepted for tapeout.
- In the default CELL_LEVEL mode, hierarchy optimizations can make errors inconsistent between runs, so the guide says to set the flow argument of
hierarchy_auto_options()(ICV) to ERROR_CLASSIFICATION. - HIERARCHICAL mode, chosen with
match_errors_processing_mode(ICV), tolerates hierarchy changes. A match needs the complete hierarchical error shape to overlap exactly, though single errors can also match individually. The guide recommends-pec EXPLODE(ICV), or partially_exploded_cells set to EXPLODE, for these runs. - A waiver cannot hide a new error of the same rule somewhere else, because a new location or shape does not match. The real risk runs the other way: stale entries. If a waived shape changes but is still acceptable, purge and recreate its cPYDB entries, since old shapes can block a hierarchical match.
mustfix_errors(ICV) names violation comments or cells that cannot be classified Ignore or Waive in the current run, which keeps the waiver list away from rules the project says must be fixed.- Counts change as well: the per-rule table in
cell.RESULTS(ICV) excludes waived violations, and with-ece(ICV) exit code 30 is not issued for a layout with only waived errors. Matching applies to DRC; ERC, device extraction and density errors are not supported.
What To Check
- Unclassified count per rule in the new
cell.LAYOUT_ERRORS(ICV). - Unmatched entries, meaning waivers the current run did not produce because the layout changed or the error moved.
- The run used
-pec EXPLODE(ICV) when matching is HIERARCHICAL. - No classified entries on rules the project lists as must-fix.
Command Checks & Actions
icv -i top.gds -c top -pec EXPLODE drc.rsFirst run with EXPLODE, recommended before building a cPYDB.
pydb_report -pydb_name PYDB_top -pydb_path ./run_details/pydb -classify classify.csvClassifies errors in bulk from a CSV file.
pydb_export -pydb_name PYDB_top -pydb_path ./run_details/pydb -cpydb_name CPYDB_top -cpydb_path ./cpydb -createCreates the cPYDB; later runs use -merge instead.
icv -i top.gds -c top -pec EXPLODE -cpydb CPYDB_top ./cpydb drc.rsReruns DRC with that cPYDB appended, so matched errors come back classified.
pydb_report -pydb_name PYDB_top -pydb_path ./run_details/pydb -show_classified file=classified.txtWrites the classified error report for review.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): Every accepted error is waived by cell and window with a comment, with zero unclassified errors and zero Unmatched entries.
- Suspicious (illustrative): A few Unmatched entries after an ECO near a waived structure, or new unclassified errors on a rule that also carries waivers.
- Hard stop: Waive entries on a must-fix rule, or a whole rule waived for all cells.
Common Mistake
The Trap: Classifying a whole violation as Waive with the cell column left blank, which the classify file format allows, because most errors of that rule sat in one approved structure. Every other error of that rule in the same run is waived too, including a real spacing error in freshly routed logic that nobody looked at, and it goes into the cPYDB as accepted.
What The Interviewer Is Testing
- Does the candidate know waivers live in a classification database matched by shape, not in a list of rule names?
- Awareness of CELL_LEVEL versus HIERARCHICAL matching and why
-pec EXPLODE(ICV) is recommended. - Whether they treat Unmatched entries and stale shapes as cleanup work.
Follow-up Question & Model Response
"What does an Unmatched entry tell you?"
Candidate Model Response: It is an error stored in an imported cPYDB that the current run did not produce. After an ECO it more often means the waived shape moved or changed, so the old entry no longer covers it and the new shape shows up as an unclassified error nearby. I compare each Unmatched entry with the unclassified errors around it, purge the stale entry, and reclassify the new shape if it is still acceptable.
Practical Example
Tapeout Scenario: A first ICV run reports 1,240 DRC errors (illustrative). 1,180 sit in a foundry-approved guard structure and are classified Waive by cell and window, with the approval number in the comment, then exported to CPYDB_top; the other 60 are fixed. After an ECO, the second run reports 1,174 errors pre-classified Waive, 13 unclassified errors and 6 Unmatched cPYDB entries (1,174 + 6 = 1,180). Four Unmatched entries are waived shapes that moved one track; their new shapes are 4 of the 13 unclassified errors, so the stale entries are purged and the new shapes reclassified. The other 2 belong to guard shapes the ECO removed. The remaining 9 are new spacing violations in ECO routing and go to fixing.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Continue practising