What is the difference between LEF and DEF?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
LEF is the rulebook and parts catalog — it describes reusable technology data (layers, vias, sites) and cell-level physical abstractions (a cell or macro's boundary, pin geometry, routing obstructions), independent of any specific chip. DEF is the actual layout of one particular design — where instances actually sit, how they're oriented, the die area, rows, tracks, blockages, and (depending on stage/export settings) routing.
Technical Explanation
- LEF is the rulebook and parts catalog — it describes reusable technology data (layers, vias, sites) and cell-level physical abstractions (a cell or macro's boundary, pin geometry, routing obstructions), independent of any specific chip.
- DEF is the actual layout of one particular design — where instances actually sit, how they're oriented, the die area, rows, tracks, blockages, and (depending on stage/export settings) routing.
- A cell's LEF view doesn't tell you where every instance of that cell is placed in your chip — that placement information only exists in DEF.
- What DEF actually contains varies a lot by stage: an early floorplan DEF can be perfectly useful without any detailed signal routes, while a fully routed DEF carries far more information than a floorplan handoff actually needs.
- DEF can technically carry netlist-related connectivity data, but in the standard ICC2 flow the structural Verilog is read separately and floorplan data from DEF is annotated onto it — don't assume reading a DEF alone reconstructs every logical connection you need.
- In practice, ICC2 implementation consumes prepared NDM reference libraries (built from LEF and other source data during library preparation), so LEF is a common source of physical abstractions, but it shouldn't be confused with the assembled implementation database the PD tool actually runs against.
Visual Verification
LEF defines the reusable physical boundary, pin layers, and routing obstructions of a cell master, while DEF captures the instantiated chip floorplan, site-grid coordinates (X,Y), and physical routing shapes.
Command Checks & Actions
read_def block.defImports die size, placement, blockages, and site rows -- the design-specific physical data that LEF itself never carries, since LEF only describes reusable technology and cell abstractions.
report_ref_libsLists the technology/LEF-carrying reference libraries currently attached, separate from any per-design DEF, making the LEF-vs-DEF split visible in the actual session state rather than just conceptually.
Common Mistake
The Trap: Candidates often mistakenly reversing the two formats, or assuming a cell abstract contains a complete transistor-level layout.
Follow-up Question & Model Response
"Why must names and units agree between them?"
Candidate Model Response: Otherwise placements, pins, sites, or layers may not map to the intended objects.
Practical Example
Tapeout Scenario: A memory abstract says the macro is 100 by 200 micrometers and exposes pins along one edge. The design's DEF says that instance u_sram is placed at a particular coordinate and orientation. These statements answer different questions.
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.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising