How do you debug an LVS short?

Short Answer

Fix power-to-ground shorts first, then power-to-signal, then signal-to-signal, and only then look at label and text shorts. A short merges two schematic nets into one extracted net, so a single bad jog can produce hundreds of unmatched devices. Use the LVS Short Finder output from IC Validator to see the exact polygon path between the two labels, and confirm routing-level shorts in ICC2 before you stream out again.

Technical Explanation

• When two nets touch, the extractor sees one net carrying two different names. Every device on both nets now looks miswired, so the compare report fills with errors that have nothing to do with the real defect.
• Power-to-ground shorts come first because they corrupt the most devices. With a limit set, the IC Validator Short Finder reports shorts in this order, lowest hierarchy level first: power-ground, power-power or ground-ground, power or ground to signal, then signal-signal.
• icv -create_lvs_short_output (ICV) creates VUE output plus LVS Short Finder data. The default is 200 shorts; give a number or ALL. The data goes to ./run_details/short_out_db with a cellname.vue file. The error_options() (ICV) runset argument can also enable it, but only the command line changes the count.
• Text shorts come next: two different labels on one connected set of shapes. text_net() (ICV) reports these as text shorts, alongside text opens and unused text.
• Before streaming out, check_lvs -checks short (ICC2) finds shapes of different nets that touch in the routed block, including top-level blockages. Whether it also checks top-level shapes against child-cell shapes is controlled by -check_child_cells (ICC2); the Implementation UG and the command reference give different defaults, so set it explicitly. It stops at 20 errors per type unless you raise -max_errors (ICC2).
• The ICC2 check_lvs (ICC2) is a routing-level short, open and floating check. It is not transistor-level LVS, so a clean result there does not replace IC Validator.
• Typical causes are an ECO route crossing a strap, a via dropped on the wrong rail, a hand edit near a macro pin and a merged cell whose PG pins use different names.

What To Check

• The cell.RESULTS (ICV) header: LVS Compare Results: FAIL together with the Short Finder count.
• Which net pairs are merged, sorted by class: power-ground first.
• Whether the same short appears in check_lvs (ICC2), meaning it lives in the routed block, or only in the merged GDS.
• The layer and cell where the Short Finder path crosses from one net to the other.
• The unmatched device count in cell.LVS_ERRORS (ICV) before and after each fix.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): check_lvs -checks short (ICC2) reports 0 shorts, the Short Finder list is empty and cell.RESULTS (ICV) reads LVS Compare Results: PASS.
• Suspicious (illustrative): check_lvs (ICC2) is clean but IC Validator reports 2 signal-signal shorts inside one merged macro cell, or a single short explains more than 300 unmatched devices.
• Hard stop: Any VDD-VSS short. Nothing else in the report is worth debugging until it is gone.

What The Interviewer Is Testing

• Does the candidate order the work by short class instead of by report line?
• Knowledge of -create_lvs_short_output (ICV), its default of 200 and where it writes its data.
• A clear line between the ICC2 routing check and transistor-level LVS in IC Validator.

Follow-up Question & Model Response

"Why can one short create hundreds of LVS errors?"

Candidate Model Response: The extractor merges the two nets into one, so every device touching either net now connects to a net the schematic never had. The compare engine cannot match those devices and reports each one. Nets downstream of the merged net can also fail to match because their neighbours no longer line up. Fixing the single short usually collapses most of the list in one rerun.