When is hierarchical DRC/LVS better than flat, and when do you flatten?

Short Answer

Hierarchical verification checks each repeated cell once and reports its errors once, so it is the default for full-chip DRC and LVS. Flat verification sees every shape in its final context but costs far more runtime and memory and repeats every error per instance. You flatten selectively: a cell whose checks depend heavily on its surroundings, a small block where optimization is not worth it, or a debug run.

Technical Explanation

• Hierarchical DRC recognizes repeated instances and checks each cell once instead of every copy. On a chip with a million standard cells from a few hundred masters, that is the difference between hours and days.
• Errors stay hierarchical too. IC Validator builds an error hierarchy that mirrors the layout, with names such as ERR_CLOCK, so you fix a cell once no matter how often it is placed.
• Context still matters. When parent shapes interact with a child, IC Validator explodes branches to bring the interacting placements under a common parent. The Explode section of cell.vcell (ICV) and the cell.tree0 and cell.tree1 (ICV) files show what changed.
• -flat (ICV) forces a fully flat run and works like adding hierarchy_options() (ICV) with flatten set to all cells. -nho (ICV) only turns off hierarchy optimization, which is not the same as flattening.
• Hierarchical LVS compares equivalence points one at a time and pairs repeated cells, memories and IP. Analog blocks and cells whose devices depend on parent layers are often better compared flat.
• Device leveling is a sign a cell should not stay hierarchical: cell.dls (ICV) lists device bodies that could not be pushed back into their original cell because of layers in other levels.
• In ICC2 the same idea applies to reporting: the signoff_check_drc.err (ICC2) error data shows a child-level error on only one of the cell instances.
• A practical rule: keep hierarchy for anything repeated or supplied as a verified block, and flatten a cell only when its results depend on what surrounds it. Heavy fill and routing drawn over a cell, wells or implants drawn in the parent, and small analog cells with few placements are the usual candidates. Record every flattened cell and the reason, so the next run makes the same choice.

Follow-up Question & Model Response

"Does flattening ever find errors that hierarchical checking misses?"

Candidate Model Response: It should not, if the hierarchy processing is correct, because the tool explodes interacting placements to get the context right. In practice a flat run is useful as a cross-check on a small block or on one cell you suspect. It also gives a simpler picture when a context error is hard to read in the error hierarchy, since every marker sits at its real location. If flat and hierarchical results ever disagree, treat that as a runset or tool issue to report, not as a reason to switch the whole chip to flat. For full-chip signoff you keep hierarchy and flatten only what needs it.