BeginnerQuestion 165 of 187Source: Synopsys IC Validator User Guide: Output Files

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

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

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.

Table of IC Validator output file anatomy: cell.RESULTS with its header lines, cell.LAYOUT_ERRORS with summary and details, cell.LVS_ERRORS with failed equivalence points and cell.sum with per-function runtime and memory, arranged in reading order. — Technical Reference DiagramWhich IC Validator output files do you read first, and what's in each?

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.

Command Checks & Actions

IC Validator (icv)cell.RESULTS

Starting point: header verdict, call line, run information and results summary.

IC Validator (icv)cell.LAYOUT_ERRORS

DRC and extraction detail: per-rule summary, then each error with structure and coordinates.

IC Validator (icv)cell.LVS_ERRORS

LVS debug file from compare(): failed equivalence points by priority with diagnostics.

IC Validator (icv)cell.sum

Run log in runset order with memory use and the checks that had errors.

IC Validator (icv)icv -i top.gds -f GDSII -c top -ece drc_runset.rs

Standalone run that returns exit code 30 when errors are reported, useful in scripts.

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).

Common Mistake

The Trap: Checking only the shell exit code in a regression script. The script treats exit 0 as "clean", but without -ece (ICV) exit 0 only means the run completed. A block with 300 spacing violations is marked green for a week until someone opens cell.RESULTS (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.

Practical Example

Tapeout Scenario: A DRC run on block top finishes in 3 hours (illustrative). top.RESULTS says RESULTS: NOT CLEAN, 1,412 rules run, 22 not executed, 5 rules with violations, 64 violations total. top.LAYOUT_ERRORS shows 51 of the 64 on one M3 spacing rule, all in the same macro-edge structure. The 22 unexecuted rules are an optional DFM group, confirmed off by agreement. The team fixes the M3 routing and reruns to RESULTS: CLEAN (ICV).

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.

Explore PnR Flow Mentor Guide →