Signoff DRC takes 30 hours. How do you cut runtime without cutting coverage?

Short Answer

Add compute before you remove checks. IC Validator scales across CPUs and hosts with -host_init (ICV), -host_add (ICV) and -host_elastic (ICV), keeps hierarchical processing on so repeated cells are checked once, and caches the compiled runset between runs. Then find the few checks that dominate runtime and fix their cause. Incremental and rule-subset runs help during iteration, but the final signoff run is full.

Technical Explanation

• -host_init (ICV) takes a CPU count, host:cpus pairs, or LSF, SGE or NB to read the allocation from the scheduler. -host_add (ICV) adds CPUs to a running job, and -host_elastic (ICV) adds hosts when commands queue and removes them when idle.
• Licenses scale with cores. Under Elite licensing, DRC on 16 cores needs 4 licenses, since each license enables 4 cores, so ask for licenses when you ask for hosts.
• Runset caching saves the parsed and optimised runset, so later runs with the same runset skip that step. It is on by default and -norscache (ICV) turns it off; it cuts startup time, not geometry processing.
• Hierarchical processing checks repeated cells once. -flat (ICV) and -nho (ICV), which turns off hierarchy optimisation, both cost runtime on a large design, so check that neither slipped into the run script.
• -ndg (ICV) is for small cells. It skips dependency generation, which means no distributed processing and every function running in sequence on one host. On a 30-hour full-chip run it makes things far worse.
• cell.sum (ICV) lists memory and page faults per check. A few checks that swap to disk or run for hours usually point at a cause, such as a huge flat fill cell or a machine with too little memory.
• During iteration, -il (ICV) runs only violations that depend on the layers you name, and ICC2 offers signoff_check_drc -auto_eco true (ICC2). Both reduce coverage by design, so the tapeout run is a full one.

What To Check

• CPUs and hosts actually used, against those requested.
• Slowest checks and their memory in cell.sum (ICV).
• Stray options in the run script such as -flat (ICV), -nho (ICV) or -ndg (ICV).
• Licenses available for the core count.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Runtime falls from 30 to 6.5 hours on 64 cores with the same rule count, and no check swaps to disk.
• Suspicious (illustrative): Runtime falls but the log shows fewer rules executed, which means coverage changed.
• Hard stop: A signoff result produced with a rule subset, -il (ICV) or -ndg (ICV) on the full chip.

What The Interviewer Is Testing

• Does the candidate protect coverage while cutting runtime?
• Knowledge of distributed processing options and license scaling.
• Awareness of what -ndg (ICV) actually does.

Follow-up Question & Model Response

"The run is distributed over 128 CPUs but runtime barely improved over 32. Why?"

Candidate Model Response: The run is limited by a few long sequential checks or by one host's memory, not by CPU count. Look at cell.sum (ICV) for checks with long runtimes and heavy page faults. Common causes are a flat, very large cell such as fill merged as one structure, which defeats hierarchy, or a density or DP check that runs on the whole die at once. Fix the data structure or give those checks a larger-memory host rather than adding more CPUs.