IntermediateQuestion 196 of 222Source: Synopsys IC Validator User Guide S-2021.06-SP2: Command-Line Options (-e) and General DRC and LVS Output Files; Synopsys ICC2 Implementation User Guide X-2025.06-SP2: Performing Layout-Versus-Schematic Checking

How are hard macros black-boxed in LVS, and what's the risk?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A black box tells LVS to treat a macro as a cell with pins only, so the compare checks how the top level connects to those pins and skips the macro contents. IC Validator declares black boxes through the lvs_black_box_options() (ICV) runset function, which you can also add from a file with -e (ICV). The risk is that anything wrong inside the macro, including a stale GDS version, is never checked by your run.

A top-level schematic with an SRAM drawn as an empty box showing only its pins, the top-level nets checked up to the pin boundary in solid lines and the unchecked macro interior hatched, with a note that the interior relies on the vendor LVS report. — Technical Reference DiagramHow are hard macros black-boxed in LVS, and what's the risk?

Technical Explanation

Black-boxing is used for memories, analog blocks and third-party IP whose netlist you may not have at transistor level, or whose own LVS was signed off by the vendor.
In IC Validator the declaration is the lvs_black_box_options() (ICV) function. The runset is foundry-owned, so the argument list comes from the foundry and IP kit, not from you.
The -e (ICV) option adds equiv_options() (ICV) and lvs_black_box_options() (ICV) calls from a file into the run. The file can hold only those two functions, plus other PXL such as a foreach loop, and its entries accumulate with any already in the runset.
The LVS summary in cell.RESULTS (ICV) counts black-box cells checked, passed and failed, and lists failed black boxes and equivalences first so you can grep them.
What stays checked: nets reaching the macro pins, pin names and pin count. What is skipped: the devices and wiring inside. A wrong macro GDS version with the right pins passes.
Top-level metal crossing over the macro is another gap. LVS no longer sees the interior shapes it could short to, so DRC on the full merged GDS has to catch that geometry.
In ICC2, check_lvs -check_child_cells true (ICC2) checks top-level shapes against child-cell shapes, which catches a route touching a macro pin shape before stream-out.

What To Check

The list of black-boxed cells in the run matches the list agreed with the IP owners, and nothing extra slipped in.
A vendor LVS report exists for each black-boxed macro, for the exact GDS version merged at stream-out.
Black-box pass and fail counts in cell.RESULTS (ICV).
Top-level shorts against macro pin shapes with check_lvs (ICC2).
Full-GDS DRC over each macro, since LVS no longer looks inside.

Command Checks & Actions

ICC2 (icc2_shell)check_lvs -checks {short open} -check_child_cells true

Explicitly checks shorts between top-level shapes and child-cell shapes such as macro pins, and reports opens.

IC Validator (icv)icv -i top.gds -c top -e blackbox_cells.rs lvs_runset.rs

Adds the black-box and equivalence calls from a separate file to the foundry runset for this run.

IC Validator (icv)cell.RESULTS

Reports checked, passed and failed black-box cells and lists failures first.

Healthy, Suspicious & Hard-stop Results

Healthy (illustrative): Every black box passes, the list matches the IP sign-off sheet and each macro has a vendor LVS report for the merged version.
Suspicious (illustrative): A black box that was added late to clear a failure, or a macro GDS whose date is newer than its vendor report.
Hard stop: A black-boxed macro with no LVS evidence from its owner. That macro is unverified and cannot go to tapeout.

Common Mistake

The Trap: Black-boxing a memory to clear a stubborn LVS failure the week before tapeout. The failure was real: the merged GDS was an older revision with the same pins but without the vendor's fix to a sense-amplifier connection. LVS passes, and the defect shows up in silicon.

What The Interviewer Is Testing

Knowledge of what a black box checks and what it skips.
Awareness that -e (ICV) adds only equivalence and black-box calls, and that it accumulates with the runset.
A strong answer insists on version-matched vendor evidence for every black box.

Follow-up Question & Model Response

"When is it acceptable to black-box a macro at signoff?"

Candidate Model Response: When the macro owner has signed off its LVS on the exact GDS you are merging, and you have that report on file. The top-level run still checks every connection to the macro pins. You also run full-GDS DRC so geometry over and around the macro is covered. Without version-matched evidence, a black box just hides the macro from verification.

Practical Example

Tapeout Scenario: A top-level run has 14 macros (illustrative). 12 SRAMs are black-boxed with vendor LVS reports that match their GDS dates. A 13th was added to the black-box file last week to clear a failure; its GDS is dated after its report, so it goes back to the vendor. The PLL stays in the compare because a transistor netlist exists. cell.RESULTS (ICV) shows 13 black boxes checked, 13 passed, and the list is cut to 12 before signoff.

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 →