LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

LEF/DEF Formats Explained: The Physical Design Data Everyone Ships But Nobody Teaches

18 min read The Physics of Computing
edalefdefvlsiphysical-designasichardwareplace-and-route
Contents

If you have spent any time near an ASIC flow, you have seen LEF and DEF files. They are the ubiquitous physical-design file formats that describe standard cell libraries, technology rules, and the layout of a design at various stages of place-and-route. Every major EDA tool reads and writes them. Every PDK ships them. Most digital designers use them without ever reading the spec.

The gap between “uses them” and “understands them” is large, and closing it changes how you read tool output, how you debug physical issues, and how you integrate open-source EDA tools (OpenROAD, KLayout, Magic) into a real flow. This post is a first-principles walkthrough of what LEF and DEF actually contain, what each major section is for, how the tools consume them, and the practical operations — merging, sanitizing, converting — that physical design engineers do with them every week.

The big picture: what LEF and DEF are

LEF (Library Exchange Format) describes the technology and the cells you use. It is a library artifact — one file (or a few) per PDK — that says things like “metal 2 has a minimum width of 100 nm, runs horizontally, and a via from metal 2 to metal 3 has these rules” and “cell NAND2X1 is 0.192 µm × 0.72 µm, has pins A, B, ZN at these positions, and has this obstruction shape on metal 1.” LEF is what tells the P&R tool what the fabric and the tiles look like.

DEF (Design Exchange Format) describes your design in physical terms: which cells are placed where, how nets are routed, what the die area is, where the I/O pads go, where the power and ground rails run. DEF is the snapshot of a design at some stage of implementation — post-floorplan, post-placement, post-routing. Tools import DEF to resume work; tools export DEF to hand off to the next stage.

If LEF is the grammar, DEF is the essay. Together they are enough to fully describe the physical layout at the cell-and-net level (though not at the polygon level — that is what GDSII or OASIS are for).

Both files are plain ASCII with a formal grammar. You can read them with less. You can write them with awk. You can diff them with git. That is a superpower the binary-database-only EDA world used to deny you.

The LEF file: what is in it

A LEF file has a few top-level sections. The hierarchy is usually:

VERSION 5.8 ;
BUSBITCHARS "[]" ;
DIVIDERCHAR "/" ;

UNITS
    DATABASE MICRONS 1000 ;
END UNITS

PROPERTYDEFINITIONS
    ...
END PROPERTYDEFINITIONS

LAYER metal1
    ...
END metal1

LAYER via1
    ...
END via1

VIA VIA12_DEFAULT DEFAULT
    ...
END VIA12_DEFAULT

VIARULE VIARULE_M1_M2 GENERATE
    ...
END VIARULE_M1_M2

SITE unit
    ...
END unit

MACRO NAND2X1
    ...
END NAND2X1

END LIBRARY

Let us walk through each.

Units

Almost everything in LEF is in microns, and the DATABASE MICRONS 1000 line says “internally, the tool should store coordinates in units of 1/1000 µm” — that is, nanometers. So a coordinate of 0.152 in the file becomes 152 database units. When you see numbers in later tool messages in “DBU,” this is the conversion factor.

Layers

Each layer of the stack gets a LAYER section. Routing layers have width/spacing rules, direction hints, resistance, capacitance:

LAYER metal2
  TYPE ROUTING ;
  DIRECTION HORIZONTAL ;
  PITCH 0.200 ;
  WIDTH 0.100 ;
  SPACING 0.100 ;
  SPACINGTABLE
    PARALLELRUNLENGTH 0 0.300 0.900
    WIDTH 0.000 0.100 0.110 0.130
    WIDTH 0.200 0.110 0.130 0.150 ;
  MINWIDTH 0.100 ;
  MINAREA 0.0100 ;
  AREA 0.0100 ;
  RESISTANCE RPERSQ 0.100 ;
  CAPACITANCE CPERSQDIST 0.0002 ;
END metal2

Key things:

  • TYPE ROUTING — it carries signals. TYPE CUT is for vias. TYPE MASTERSLICE and TYPE OVERLAP are special.
  • DIRECTION — most metals in a stack have a preferred direction (even layers horizontal, odd layers vertical, for example). Routers honor this for main wires but use perpendicular metal for jogs.
  • PITCH — the minimum distance between two parallel wires. Sets the routing grid.
  • WIDTH — default wire width.
  • SPACING — minimum wire-to-wire spacing.
  • SPACINGTABLE — the table of spacing rules where spacing depends on width and parallel run length. This is how complex DRC is expressed: a 0.2 µm wire running 900 nm parallel to another requires 0.15 µm spacing, not the default.
  • MINAREA — any shape on this layer must have at least this area. Small wire stubs that fail this rule cause “min area violations” in DRC.
  • RESISTANCE / CAPACITANCE — used by tools as a quick lookup until full parasitic extraction is done.

Cut layers (vias) have their own rules (CUT, SPACING, CUTSPACING), and MANUFACTURINGGRID at the top sets the global minimum grid resolution (often 0.5 or 1 nm).

Vias

Two flavors:

  • Fixed vias: explicit pre-defined via shapes. The router drops them as-is.
VIA VIA12_DEFAULT DEFAULT
  LAYER metal1 ; RECT -0.05 -0.05 0.05 0.05 ;
  LAYER via1   ; RECT -0.035 -0.035 0.035 0.035 ;
  LAYER metal2 ; RECT -0.05 -0.05 0.05 0.05 ;
END VIA12_DEFAULT
  • Via rules: generators from which the router synthesizes vias of the right size.
VIARULE VIAGEN12 GENERATE
  LAYER metal1 ; ENCLOSURE 0.020 0.020 ; WIDTH 0.100 TO 2.000 ;
  LAYER via1   ; RECT -0.035 -0.035 0.035 0.035 ; SPACING 0.14 BY 0.14 ;
  LAYER metal2 ; ENCLOSURE 0.020 0.020 ; WIDTH 0.100 TO 2.000 ;
END VIAGEN12

With a via rule, the router can generate a via of the right dimensions (width, number of cuts) for the connection it is making. Bigger wires get bigger vias with more cuts.

Sites

A SITE defines the placement grid unit for standard cells:

SITE unit
  CLASS CORE ;
  SYMMETRY Y ;
  SIZE 0.140 BY 0.960 ;
END unit

Standard cells are placed at site origins. SIZE 0.140 BY 0.960 means each site is 140 nm wide and 960 nm tall (a single-row height). A cell occupies some multiple of sites. Rows in the DEF are stacks of sites.

Macros

Each standard cell (and each macro like a RAM or analog block) has a MACRO definition. This is the bulk of most LEF files.

MACRO NAND2X1
  CLASS CORE ;
  SIZE 0.560 BY 0.960 ;
  SYMMETRY X Y ;
  SITE unit ;

  PIN A
    DIRECTION INPUT ;
    USE SIGNAL ;
    PORT
      LAYER metal1 ;
        RECT 0.055 0.480 0.135 0.560 ;
      LAYER via12 ;
        RECT 0.075 0.500 0.115 0.540 ;
    END
  END A

  PIN B ... END B
  PIN ZN ... END ZN
  PIN VDD
    DIRECTION INOUT ;
    USE POWER ;
    SHAPE ABUTMENT ;
    PORT
      LAYER metal1 ;
        RECT 0 0.890 0.560 0.960 ;
    END
  END VDD
  PIN VSS ... END VSS

  OBS
    LAYER metal1 ;
      RECT 0.200 0.300 0.400 0.700 ;
  END

END NAND2X1

Pieces:

  • CLASS CORE — a standard cell. Other classes are PAD (I/O), BLOCK (hard macro), ENDCAP, CORNER, and more.
  • SIZE — overall footprint.
  • SYMMETRY — which axes the cell can be mirrored about during placement. X Y means mirror freely; Y means only horizontal flip.
  • SITE — the site grid it lives on.
  • PIN blocks — each pin’s direction, function (USE SIGNAL, USE POWER, USE GROUND, USE CLOCK), and the physical ports (shapes) on specific layers. Multiple rectangles per pin are common.
  • OBS — obstructions. Shapes the router must avoid on certain layers when wiring nets through or over the cell. Think “internal routing of the cell; do not draw over this.”

What about transistor-level info?

LEF intentionally does not describe the poly/diffusion/contact shapes inside the cell. That is in the GDSII. LEF is an abstraction: a cell is a box with labeled pins and layer-specific obstructions, and the polygons that make it up are someone else’s problem. This is on purpose — digital tools do not need the polygons, and abstracting them out lets the P&R tool work fast.

Technology LEF vs Macro LEF

It is common to split LEF into two files: tech.lef (units, layers, via rules, sites) and cells.lef (macro definitions). Most tools accept multiple LEF files loaded in order, and this separation makes it easier to mix-and-match a tech from the PDK with a cell library from the vendor.

The DEF file: what is in it

DEF starts with the design’s global properties and then enumerates everything in the layout. The top-level sections:

VERSION 5.8 ;
BUSBITCHARS "[]" ;
DIVIDERCHAR "/" ;
DESIGN mychip ;

UNITS DISTANCE MICRONS 1000 ;

DIEAREA ( 0 0 ) ( 500000 500000 ) ;

ROW CORE_ROW_0 unit 15000 15000 N DO 1000 BY 1 STEP 140 0 ;
... more rows ...

TRACKS X 0 DO 3571 STEP 140 LAYER metal1 ;
... more tracks ...

VIAS 12 ;
  - VIA_M1M2_0 + VIARULE VIAGEN12 + CUTSIZE 70 70 + LAYERS metal1 via1 metal2 + CUTSPACING 140 140 ;
  ...
END VIAS

COMPONENTS 100000 ;
  - u_cpu_u_dec_U123 NAND2X1 + PLACED ( 34720 46080 ) N ;
  - u_cpu_u_dec_U124 INVX1   + PLACED ( 34860 46080 ) N ;
  - u_dcache_sram  SRAM_32x64 + FIXED ( 120000 220000 ) N ;
  ...
END COMPONENTS

PINS 100 ;
  - clk + NET clk + DIRECTION INPUT + USE SIGNAL
    + LAYER metal3 ( -100 -100 ) ( 100 100 )
    + PLACED ( 0 250000 ) N ;
  ...
END PINS

SPECIALNETS 4 ;
  - VDD + USE POWER
    + ROUTED metal1 400 + SHAPE STRIPE ( 0 1200 ) ( 500000 * )
    ...
    ;
  - VSS + USE GROUND ... ;
END SPECIALNETS

NETS 350000 ;
  - u_cpu/u_dec/n12
    ( u_cpu_u_dec_U123 ZN ) ( u_cpu_u_dec_U124 A )
    + ROUTED metal1 ( 34860 46280 ) ( 34860 46480 )
             NEW metal2 ( 34860 46480 ) ( 35000 46480 )
    ;
  ...
END NETS

END DESIGN

DIEAREA and rows

DIEAREA is the bounding box of the die. ROW entries tile the core area with standard cell rows. Each row is a strip one site tall (960 nm in our example) and N sites wide, placed at a specific origin, oriented N (north, i.e., unflipped) or FS (flipped south — horizontally flipped, vertically mirrored) to enable abutment of power rails between alternating rows.

A typical flat floorplan has hundreds to thousands of rows, each filled during placement with standard cells.

Tracks

TRACKS define the legal routing grid for each layer. The P&R tool places wires on these tracks (or snaps to them during detailed routing).

Components

The big one. COMPONENTS <N> declares there are N components (instances) in the design, and each line is one instance: its hierarchical name, the cell type, its placement status (UNPLACED, PLACED, FIXED), and its coordinate+orientation.

  • PLACED — position assigned but the tool can legally move it.
  • FIXED — pinned; do not move. Used for hard macros, IO pads, and manually placed components.
  • UNPLACED — coordinate is meaningless; tool must place it.
  • Orientation: N (north), S (south), E (east), W (west), FN (flipped north), FS, FE, FW. FS is very common for cells in odd-numbered rows.

Pins (top-level I/O)

Each top-level port of the chip is a PINS entry with its direction, usage, layer, shape, and physical location on the die boundary.

SPECIALNETS vs NETS

The distinction:

  • SPECIALNETS: power and ground, typically wider pre-routed stripes and rings. Shapes are explicit (rectangular stripes with explicit widths and extents) and include features like blanket POWER/GROUND usage.
  • NETS: signal nets. A net lists its connections (cell/pin pairs) and, if routed, the sequence of shapes.

Signal routing syntax is terse: ROUTED metal1 ( x1 y1 ) ( x2 y2 ) draws a wire from the first point to the second on the named layer. The width defaults to the layer’s WIDTH from LEF; you can override with metal1 320 for a 320 DBU wide wire. Vias are placed with ( x y ) VIA12 at the turn points. NEW starts a new segment (disjoint path on the net), useful when a net has multiple branches.

GCELLGRID

GCELLGRID X 0 DO 101 STEP 5000 ;
GCELLGRID Y 0 DO 101 STEP 5000 ;

Defines a coarse grid used by the global router. Congestion is reported per GCELL. Familiarity with this helps you interpret “GCELL (34, 17) is 130% congested” messages.

Blockages and regions

BLOCKAGES 2 ;
  - LAYER metal2 RECT ( 10000 10000 ) ( 20000 20000 ) ;
  - PLACEMENT RECT ( 50000 50000 ) ( 60000 60000 ) ;
END BLOCKAGES

REGIONS 3 ;
  - digital_region RECT ( 0 0 ) ( 300000 500000 ) ;
END REGIONS

Blockages tell the tool “do not route here” or “do not place cells here.” Regions define areas with special constraints (only certain cells can be placed inside, for example).

Units, coordinates, and the conversion pitfall

LEF says DATABASE MICRONS 1000 — every LEF coordinate in microns gets multiplied by 1000 to get database units (nm).

DEF can have a different UNITS DISTANCE MICRONS value than LEF. 1000 is most common but 2000 or 10000 shows up. The tool scales accordingly when importing. When you edit DEF by hand or script, check the UNITS line and use its scale factor. A script that assumes 1000 DBU/µm but runs against a 2000 DBU/µm DEF produces wildly wrong coordinates.

If you are converting between tools that use different internal precisions, this becomes the one thing that actually matters.

Reading LEF/DEF for debugging

Some real operations you will do often:

Find a cell’s location from DEF

1
2

grep -n 'u_cpu_u_dec_U123' top.def
# returns: - u_cpu_u_dec_U123 NAND2X1 + PLACED ( 34720 46080 ) N ;

From here you know exactly where the cell is. Helpful for correlating STA violations with physical layout.

Count placed vs unplaced cells

1
2

grep -c 'PLACED' top.def
grep -c 'UNPLACED' top.def

Useful sanity check after placement — no cells should be UNPLACED when you are done.

Extract all macros and their sizes from LEF

1

awk '/^MACRO/{m=$2} /SIZE/{print m, $2, $4}' cells.lef | sort -k2 -n

Lists every macro, widest first. Gets you a quick feel for what occupies the die.

Find all cells in a specific region

A short Python script reading the DEF’s COMPONENTS section filters instances by placement coordinates — useful for “what is this congested area?” analysis.

LEF/DEF in modern flows

Every step of a digital implementation flow produces or consumes DEF:

  • Synthesis → Floorplan reads a synthesized Verilog netlist plus the LEF, produces an initial DEF with die area, rows, tracks, hard macros placed, and power-ground planned.
  • Placement reads the floorplan DEF, legally places standard cells, writes a post-placement DEF.
  • Clock Tree Synthesis reads the post-placement DEF, adds buffers and routes the clock tree, writes a post-CTS DEF.
  • Routing reads the post-CTS DEF, adds signal routes, writes a post-route DEF.
  • ECO (Engineering Change Orders) rewrites parts of a DEF to patch in cells or reroute nets without going back to earlier stages.

Modern tools increasingly operate in their own database (Innovus’s OpenAccess, Synopsys’s Milkyway or NDM, OpenROAD’s OpenDB). DEF is still the lingua franca that crosses tool boundaries and the format you use to hand data to KLayout, open-source extractors, LVS/DRC hooks, or your own scripts.

Hard macros in LEF

Hard macros — SRAM compilers, analog blocks, PLLs — are delivered as LEF + GDSII. The LEF describes the block as a MACRO with CLASS BLOCK (or CLASS BLOCK BLACKBOX), its pin layout, and obstructions that tell the router what parts of the block cannot be routed over.

For memories, you often have multiple LEF views:

  • Full view: every pin at its correct layer and position, with full obstructions.
  • Abstract view: a simpler model with obstructions simplified to speed up tool runs.
  • Timing-only view: physical footprint without pin details, for very early-stage floorplanning.

Picking the right view for the right stage matters. The full LEF is truth; the abstract views are faster.

OBS vs unrouted pins: the subtle thing everyone misses

A cell has pins (accessible connection points) and obstructions (shapes that block routing). What happens on top of a pin? Some cells have pins on metal 1 with obstructions on metal 1 around them; the router can connect to the pin from metal 2 via a via. Some cells deliberately have no obstructions above their pins; the router can enter horizontally on metal 1 to reach them. The choice affects routability significantly.

Modern libraries often provide PIN ACCESS hints or multi-point access shapes on higher layers. If you are debugging a “why can the router not connect this pin?” issue, open the LEF macro, look at the pin’s PORT shapes and the OBS around them, and see whether there is legal geometry to approach from a routable layer.

Common LEF/DEF problems in the wild

Pin on a wrong layer

A pin declared on metal3 but the PDK says metal3 is a routing layer starting at a different stack. The router cannot place a via from metal2 to the pin. Fix: check the layer stack spec in the tech LEF; confirm pin layer matches routing intent.

OBS blocking a pin

Obstruction shapes accidentally covering the pin shape. Router can see the pin but has no legal approach. Fix: regenerate the LEF from the PDK’s abstract generator (Cadence Abstract, Siemens Calibre LVL) if you have a bad hand-edited version.

Units mismatch

LEF at 1000 DBU/µm, DEF at 2000 DBU/µm, third-party tool assumes one or the other. Cells appear at wildly wrong positions. Diagnose by opening both files and confirming the UNITS directive; fix by scaling coordinates or regenerating.

Row origin off-grid

Rows specified at coordinates not on the placement grid. Some tools silently round, others reject. Fix: ROW origins must be integer multiples of the SITE dimensions.

Missing tracks for a layer

The router needs TRACKS for every layer it will use. A LEF or DEF missing tracks for metal5 means the tool cannot route on that layer. Fix: add TRACKS entries.

Inconsistent macros between LEF and Liberty

LEF says a cell has pins A, B, ZN; the Liberty .lib says A1, A2, Y. Tools get confused, either refusing to load or producing “unconnected pin” errors. Always cross-check LEF pin names with Liberty.

Stale BLOCKAGES

After a floorplan change, old placement or routing blockages are still in the DEF. The tool honors them and the design looks congested. Fix: regenerate floorplan blockages from a fresh script.

LEF/DEF and open-source EDA

OpenROAD, KLayout, and Magic all read LEF and DEF natively. This means you can, for example:

  • Synthesize with Yosys.
  • Place and route with OpenROAD, producing a DEF.
  • Open the DEF in KLayout for visual inspection.
  • Extract with OpenRCX (built into OpenROAD) to produce SPEF.
  • Run Magic or Calibre for DRC/LVS, which consume LEF plus the GDSII of the macros.

The formats are the glue. If you are doing hobbyist or academic chip design (think the TinyTapeout or SkyWater 130 nm PDK flow), everything is expressed in LEF/DEF at the stage where digital tools meet layout tools.

Quick-reference: fields worth memorizing

LEF LAYER

  • TYPE ROUTING | CUT | MASTERSLICE
  • DIRECTION HORIZONTAL | VERTICAL | DIAG45 | DIAG135
  • PITCH, WIDTH, SPACING, SPACINGTABLE
  • MINWIDTH, MINAREA
  • RESISTANCE, CAPACITANCE

LEF MACRO

  • CLASS CORE | BLOCK | PAD | ENDCAP | CORNER | COVER
  • SIZE <w> BY <h>
  • SYMMETRY X Y R90
  • SITE <site>
  • PIN/PORT/OBS
  • USE SIGNAL | POWER | GROUND | CLOCK | ANALOG | RESET
  • DIRECTION INPUT | OUTPUT | INOUT | TRISTATE | FEEDTHRU

DEF COMPONENT

  • - <inst_name> <cell_name> + UNPLACED | PLACED | FIXED | COVER ( x y ) <orient> ;
  • Orientations: N, S, E, W, FN, FS, FE, FW.

DEF NET

  • - <net_name> ( <inst_a> <pin_a> ) ( <inst_b> <pin_b> ) — connections.
  • + USE SIGNAL | POWER | GROUND | CLOCK | RESET
  • + ROUTED <layer> ( x y ) ( x y ) NEW <layer> ... — routed shape sequence.
  • + FIXED / + COVER — do not modify this net’s routing.

When to roll your own LEF/DEF parser

Full LEF/DEF parsers are non-trivial — the grammar is formal, edge cases abound, and LEF/DEF versions (5.7, 5.8) have feature differences. If you need robust parsing:

  • Cadence’s LEF/DEF parser is shipped with some tools and is a de facto reference.
  • Si2 LEF/DEF OpenLEF/OpenDEF — open-source reference C++ library.
  • OpenROAD’s OpenDB in Python — probably the easiest modern way to load, inspect, and modify LEF/DEF programmatically.
  • KLayout Python API — graphical plus scriptable.

For quick extractions (list all cell locations, count things, find a specific net), awk/grep/python are fine. For anything that rewrites structure or spans multiple files, use a real library — hand-rolled parsers miss edge cases (multi-line entries, escaped identifiers, PROPERTY values, cross-LEF macros) and silently produce wrong output.

Wrapping up

LEF and DEF are the plain-text formats that describe what the digital flow produces at every physical stage. LEF is the library: the abstraction of cells and the technology rules. DEF is the layout snapshot: cells placed, nets connected, power delivered. Neither is glamorous, and both are under-documented in most training material because they “just work” — until something doesn’t.

When something doesn’t, the debugging path is almost always the same: open the file, find the relevant section, read what is actually there. A stuck pin, a mysteriously congested region, a DRC violation at a cell boundary, a tool rejecting your floorplan — all of them resolve to “the LEF said X but the tool expected Y.” The only way to close that gap is to have read LEF/DEF enough that you do not need the spec open on another monitor.

Keep a copy of the LEF/DEF reference (the Si2 specification, or the “Cadence LEF/DEF Language Reference” PDF, both freely available) handy. Read a real PDK’s LEF end to end once. Read a post-route DEF of a small design and trace a couple of nets visually. That hour spent will pay back every time a physical-design problem lands on your desk.

Comments