Why do port-label and text problems cause LVS failures?

Short Answer

LVS uses text labels to give extracted nets their names and to anchor the top-level ports to the schematic. If a label lands on the wrong layer, misses its shape or sits on a shape of another net, the compare starts from a wrong or missing anchor. The result is a text open, a text short or unused text, and the rest of the compare often fails around it.

Technical Explanation

• The runset pairs each text layer with the metal it names. In text_net() (ICV) a pairing such as M1 with M1_text attaches every label on M1_text to the M1 polygon under it.
• text_net() (ICV) returns a connect database and also produces errors for text shorts, text opens and unused text. A text short is two different names on one connected net. A text open is one name on two unconnected pieces. Unused text is a label that touches no shape on its paired layer.
• Unused text is the quiet one. The port loses its name, the compare has to match it by structure alone, and a symmetrical block may then match ports the wrong way round.
• Labels come from stream-out. write_gds -output_pin all (ICC2) writes each pin as text plus geometry, which is the default; write_gds -output_pin geometry (ICC2) drops the text. Net shapes get no text unless you add write_gds -output_net_text (ICC2).
• The layer map given with write_gds -layer_map (ICC2) decides which layer and data type the text lands on. If it disagrees with what the runset expects for text, every label on that layer becomes unused text.
• A label placed over the wrong shape is worse than a missing one. It names the wrong net, gives a text short or forces a bad match, and the report points at devices rather than the label.
• Treat text as design data: port names, PG names and bus bit order should match the netlist exactly, including the bus delimiters used at stream-out.

What To Check

• The text error counts from the text_net() (ICV) checks: shorts, opens and unused text, before any device mismatch.
• That each top-level port label sits on the pin shape and on the text layer the runset pairs with that metal.
• The stream-out layer map for text purposes against the runset layer assignments.
• PG labels on every PG pin that the netlist expects, spelled as in the netlist.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): 0 text shorts, 0 text opens and 0 unused text; every top-level port matched by name.
• Suspicious (illustrative): A handful of unused labels on one layer, often a sign that one text data type in the layer map is wrong.
• Hard stop: Any text short on a top-level port or PG net. The compare is anchored to a wrong name and its result cannot be trusted.

What The Interviewer Is Testing

• Does the candidate know the three text error types and what each means?
• Awareness that stream-out settings, not only layout, decide where text lands.
• Reading text errors before device mismatches.

Follow-up Question & Model Response

"Why is unused text dangerous even when LVS still passes?"

Candidate Model Response: An unused label means that net was matched by structure rather than by name. For a regular block the compare may still pick the right pairing, so LVS passes. For symmetric logic, such as two identical bus halves, it can pair them the wrong way and still pass. The chip then has ports whose names in the netlist do not match what is on silicon, which shows up only at package or system test.