What's the difference between IC Validator In-Design and a standalone IC Validator run?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
IC Validator In-Design runs the IC Validator engine from inside ICC2 on the saved design library, through commands such as signoff_check_drc (ICC2), so you can find and fix violations without leaving implementation. A standalone run is the icv (ICV) command line on a GDS or OASIS file. In-Design is the fixing loop; standalone on the final stream is the signoff record.
Technical Explanation
- Data source differs. In-Design reads the on-disk design library, so you must
save_block(ICC2) first; it does not see unsaved changes in memory. Standalone reads a stream file written bywrite_gds(ICC2) orwrite_oasis(ICC2). - Cell views differ. By default In-Design reads the design view for the top block and library cells, and only pin information from the frame view for macros and IO pads. You can make it read real geometry with
signoff.physical.merge_stream_files(ICC2), layout views or design views. Standalone sees whatever geometry the stream contains. - Commands differ. In-Design covers
signoff_check_drc(ICC2),signoff_fix_drc(ICC2),signoff_create_metal_fill(ICC2),signoff_fix_isolated_via(ICC2) andsignoff_create_pg_augmentation(ICC2). Standalone isicv(ICV) with any foundry runset, including LVS. - The loop differs. In-Design results load into the ICC2 error browser and feed automatic fixing;
signoff_check_drc.err(ICC2) is stored in the design library. Standalone results are text files and VUE data, and fixes go back to ICC2 by hand or through an ECO. - Scope differs. In-Design checks routing layers by default;
-check_all_runset_layers true(ICC2) extends it to all runset layers. The standalone run executes the whole runset on the full stream. - Licensing: IC Validator In-Design needs an IC Validator license, and the ICV heat map needs an IC Validator NXT license. The ICC2 guide also asks that the IC Validator version be compatible with ICC2, which
report_versions(ICC2) shows. - Error handling differs as well. In-Design reports at most 1000 errors per rule by default through
signoff.check_drc.max_errors_per_rule(ICC2), and can skip child-cell errors withsignoff.check_drc.ignore_child_cell_errors(ICC2) so that only violations Zroute can fix are reported. Standalone reports whatever the foundry runset asks for, which is the full picture you sign off on. - Both use foundry runsets and the same engine, so results should agree on the same geometry. When they differ, the cause is almost always what data each run saw: frame views versus real macro geometry, a stale saved block, or a different layer map.
Common Mistake
The Trap: Signing off on a clean signoff_check_drc (ICC2) result with default settings. Macros were read as frame views, so a spacing violation between top-level routing and a metal shape inside an SRAM was invisible. The standalone run on the merged GDS finds 40 violations at the SRAM edges a day before tapeout. Each one needs a manual reroute, a fresh signoff_check_drc (ICC2) and a new stream-out, so the final run is repeated three times under schedule pressure instead of once.
Follow-up Question & Model Response
"When would you prefer In-Design over a standalone run during implementation?"
Candidate Model Response: During routing and ECO iterations, because the results come back into ICC2 where I can view them in the error browser and run signoff_fix_drc (ICC2) directly. I can also check only changed areas with -auto_eco true (ICC2), which is much faster after small ECOs. The standalone run needs a fresh stream-out each time, so it is slower to iterate. I keep the standalone run for the final signoff on the exact stream file.
Practical Example
Tapeout Scenario: During route cleanup a block runs signoff_check_drc (ICC2) five times in two days, each run about 50 minutes on 16 cores, going from 1,240 violations to 6 (illustrative). signoff_fix_drc (ICC2) clears most of them automatically. The final stream then goes through standalone icv (ICV) with the full DRC runset in about 2.5 hours. It finds 3 more violations inside a macro whose frame view hid them. After a routing fix, both runs report clean on the same geometry. For the next block the team sets signoff.physical.merge_stream_files (ICC2) to the macro GDS from the start, so In-Design sees the same macro geometry as the final run.
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