Which IC Validator output files do you read first, and what's in each?

Short Answer

Read cell.RESULTS (ICV) first; the guide calls it the starting point for analyzing a run. Its header says RESULTS: CLEAN (ICV) or RESULTS: NOT CLEAN (ICV) for DRC, and LVS Compare Results: PASS | FAIL (ICV) plus a DRC-and-extraction line for LVS. Then go to cell.LAYOUT_ERRORS (ICV) for DRC detail, cell.LVS_ERRORS (ICV) for LVS detail and cell.sum (ICV) for run statistics.

Technical Explanation

• cell.RESULTS (ICV) holds the results header, how IC Validator was called, basic run information such as input library, top cell and runset, a results summary, assign-layer statistics, run configuration, and performance statistics such as runtime and peak memory. "cell" is replaced by the top-cell name.
• The header is the verdict. A DRC run shows RESULTS: CLEAN (ICV) or RESULTS: NOT CLEAN (ICV). An LVS run shows two lines, LVS Compare Results: PASS | FAIL (ICV) and DRC and Extraction Results: CLEAN | NOT CLEAN (ICV). A run that did not finish shows RESULTS: RUN ABORTED (ICV).
• The DRC results summary gives total rules run, rules not executed, rules with violations and total violations. The per-rule table appears only when the runset asks for it through verbose results in run_options() (ICV).
• cell.LAYOUT_ERRORS (ICV) starts with CLEAN or ERRORS, then an error summary per rule, then details: rule description, structure name and position or bounding box. Coordinates are hierarchical, relative to the named structure, reported once per referenced structure.
• cell.LVS_ERRORS (ICV) is written by compare() (ICV). It lists PASS or FAIL, failed equivalence points in high and low priority, and diagnostics. It is the starting point for LVS debug.
• cell.sum (ICV) records the run in runset order, including memory and the checks that had errors. With -verbose (ICV) the same information also prints to the screen in processing order.
• Error-level exit status is separate. With -ece (ICV), exit code 30 means the run completed with errors in the error files; exit code 0 alone means the run completed, not that it was clean.

What To Check

• The header line of cell.RESULTS (ICV), and both lines for an LVS run.
• Rules not executed in the DRC summary; a rule that did not run cannot fail.
• Top cell, runset name and input file in the run information, to confirm you are reading the right run.
• The first high-priority failed equivalence in cell.LVS_ERRORS (ICV).
• Peak memory in the performance statistics when runtime looks wrong.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): RESULTS: CLEAN (ICV) with zero rules not executed, or LVS PASS with extraction CLEAN.
• Suspicious (illustrative): CLEAN, but the summary shows 22 rules not executed; confirm those rules are expected to be switched off for this block.
• Hard stop: RESULTS: RUN ABORTED (ICV), or LVS PASS with DRC and Extraction Results: NOT CLEAN (ICV).

What The Interviewer Is Testing

• Can the candidate name the file to open first, and why?
• Knowledge of the two-line LVS header, not just PASS or FAIL.
• Whether they distinguish a completed run from a clean run.

Follow-up Question & Model Response

"Why check "rules not executed" when the header already says CLEAN?"

Candidate Model Response: CLEAN only means no executed rule reported a violation. If a rule group was switched off, or a layer was missing so a rule had nothing to act on, that rule never ran. The DRC summary in cell.RESULTS (ICV) counts rules that were not executed, and the per-rule table marks them. I compare that list against what the foundry requires for tapeout before trusting the verdict.