What are the common routing DRC violations?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
The ones you see most are different-net spacing, shorts, minimum area, minimum width and length, end-of-line spacing, via enclosure problems, and open nets. check_routes lists them by type and saves the DRCs to the zroute.err error data; open nets appear in its text report. Knowing which type dominates tells you where to look for the cause.
Technical Explanation
- Different-net spacing: two wires of different nets closer than the minimum spacing. This is the most common type and usually comes from local crowding.
- Short: two different nets touching or overlapping. It is a hard failure and must be zero at signoff; it is also often invisible to timing.
- Minimum area: a metal shape too small to manufacture reliably, often a tiny piece of metal around a via.
- Minimum width and minimum length: a wire narrower or shorter than the layer allows, often near pins or jogs.
- End-of-line spacing: the end of a wire too close to another shape. These rules are stricter than normal spacing at advanced nodes.
- Via enclosure: not enough metal around a via cut, including end-of-line and jog enclosure variants.
- Opens: a pin not connected to its net.
check_routesalso reports antenna, frozen layer, min and max layer, and voltage area violations in the same run.
What To Check
- The DRC type histogram from
check_routes, to see which type dominates. - Where each type clusters: pins, macro edges, NDR nets or open space.
- Opens separately from DRCs, since they need a different fix.
- Whether the count matches the last detail routing log, to catch stale error data.
Command Checks & Actions
check_routesReports DRCs by type, opens, antenna and voltage area violations, and saves them to `zroute.err`.
get_drc_errors -error_data zroute.err -filter {type_name == "Diff net spacing"}Selects only the different-net spacing errors so you can look at them in isolation.
write_drc_error_data -error_data zroute.err -file_name route_drc.errExports the error data to a file you can reopen or share.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): Zero shorts and zero opens, and fewer than 50 remaining DRCs, all understood.
- Suspicious (illustrative): A few hundred DRCs of one type in one area; worth a targeted look before signoff.
- Hard stop: Any short or open at the end of routing, or thousands of DRCs of mixed types spread over the block.
Common Mistake
The Trap: Reading only the total DRC count. A report of 60 DRCs looks nearly done, but 4 of them are shorts on a reset net, and a short is a functional failure. The type breakdown takes seconds to read and would have shown them at once.
What The Interviewer Is Testing
- Whether you know the common types by name and cause.
- Do you separate shorts and opens from ordinary spacing DRCs?
- A strong answer shows you can filter the error data rather than scroll through it.
Follow-up Question & Model Response
"Why is a short often invisible to static timing analysis?"
Candidate Model Response: Timing uses the netlist connectivity and extracted parasitics per net. A short connects two nets in the layout that are separate in the netlist, so timing still sees two nets and calculates their delay normally. Extraction may add some capacitance between them, but nothing flags them as merged. That is why shorts must be caught by check_routes and check_lvs, not by reading timing reports.
Practical Example
Tapeout Scenario: check_routes on a routed block reports 138 violations (illustrative): 92 different-net spacing, 21 end-of-line spacing, 18 minimum area, 5 via enclosure and 2 shorts. Filtering with get_drc_errors shows the 92 spacing errors all sit in a 30 um by 30 um area next to an SRAM. The 2 shorts are on a scan enable net crossing a clock NDR wire. The engineer fixes the shorts first, then treats the SRAM area as a congestion problem rather than 92 separate DRCs.
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.

Continue practising