Layout Knowledge Base

Files · Chips

LEF and DEF in plain language

LEF describes the layers, vias, sites, and cell abstracts of a digital library; DEF describes one design built from it, with die area, rows, placed instances, pins, power grid, and wires.

Last edited: October 27, 2026

LayoutEditor window showing a routed section of a SKY130 DEF: rows of gray cell outlines, blue horizontal metal 1 wires and power rails, orange vertical metal 2 wires, green metal 3 bands, and black via cuts

LEF (Library Exchange Format) and DEF (Design Exchange Format) are text formats for digital IC layout. LEF describes a library: a technology LEF lists the routing layers, vias, and placement sites of a process, and a cell LEF describes each standard cell or block as an abstract with an outline, pins, and obstructions. DEF describes one design built from that library: the die area, the rows, which cell instance sits where and in which orientation, the I/O pins, the power grid, and the signal wires. Neither format contains transistor geometry. The polygons of each cell stay in the cell's GDSII or OASIS file. Place-and-route tools read LEF and write DEF; a layout editor reads both to display or convert the result. The format reference on this page is the LEF/DEF 5.8 Language Reference (Cadence, May 2017); page numbers are its printed page numbers.

The picture at the top is a LayoutEditor window with a 25 × 15.25 µm section of a routed DEF: user_proj_example.def from the caravel_user_project repository (efabless, commit f534826), read with the SKY130 technology LEF and two SKY130 cell LEF files. Thin gray rectangles are the outlines of placed cells in horizontal rows. Blue wires are metal 1, which the technology LEF declares horizontal. Orange wires are metal 2, declared vertical, and the green bands are metal 3. Black squares are via cuts, and the wide blue lines between the rows are power rails. Where metal 2 crosses metal 1, LayoutEditor draws the overlap darker. The pin shapes on the local-interconnect layer li1 inside the cells are left out of this view.

Three files

File Content Coordinates Example on this page
Technology LEF units, manufacturing grid, layers with type, routing direction, pitch, width, and spacing; fixed vias and via-generation rules; placement sites micrometers sky130_fd_sc_hd.tlef: 13 layers, 25 VIA, 25 VIARULE
Cell LEF one MACRO per cell: class, size, site, symmetry, pins with port rectangles, obstructions (OBS) micrometers sky130_fd_sc_hd__inv_1.lef
DEF one design: die area, rows, tracks, vias, components, pins, special nets, nets, blockages, regions integer database units gcd_sky130hd_floorplan.def (OpenROAD test data), user_proj_example.def

A DEF refers to LEF objects by name only. A component names a macro, and a wire names a layer and a via. The reference requires that the technology LEF is read first and that every object is defined before it is used (p. 12). The read order technology LEF, cell LEF, DEF follows from these references. Keywords are case-insensitive (p. 7); names of cells, pins, nets, and layers are not.

The technology LEF

The SKY130 high-density technology LEF starts with VERSION 5.7, DATABASE MICRONS 1000, and MANUFACTURINGGRID 0.005. The second line sets 1000 database units per micrometer for the library; the third sets a 5 nm vertex grid. A SITE is the placement unit of a row: unithd has SIZE 0.46 BY 2.72, so every cell of this library is a whole number of 0.46 µm sites wide. The layers follow in process order: nwell, pwell, li1, mcon, met1, via, met2, via2, met3, via3, met4, via4, met5. The block for metal 1, lines 94 to 109 of the file:

LAYER met1
  TYPE ROUTING ;
  DIRECTION HORIZONTAL ;

  PITCH 0.34 ;
  OFFSET 0.17 ;

  WIDTH 0.14 ;                     # Met1 1
  # SPACING 0.14 ;                 # Met1 2
  # SPACING 0.28 RANGE 3.001 100 ; # Met1 3b
  SPACINGTABLE
     PARALLELRUNLENGTH 0
     WIDTH 0 0.14
     WIDTH 3 0.28 ;
  AREA 0.083 ;                     # Met1 6
  THICKNESS 0.35 ;

DIRECTION is the preferred routing direction. PITCH is the distance between routing tracks, and OFFSET places the first track. WIDTH is the default wire width. The SPACINGTABLE requires a spacing of 0.14 µm for wires narrower than 3 µm and 0.28 µm for wider ones, and AREA is the minimum area in µm². The comments name the SkyWater rules behind the values (m1.1, m1.2, m1.3b, m1.6); what a DRC rule deck is checks the same rules on polygons. The router works with the LEF values; the sign-off DRC deck checks the final polygons.

Routing layer DIRECTION PITCH (µm) WIDTH (µm)
li1 VERTICAL 0.46 0.34 0.17
met1 HORIZONTAL 0.34 0.14
met2 VERTICAL 0.46 0.14
met3 HORIZONTAL 0.68 0.30
met4 VERTICAL 0.92 0.30
met5 HORIZONTAL 3.4 1.6

A VIA ... DEFAULT statement is a fixed via: one or more rectangles on each of three layers. L1M1_PR has a 0.17 × 0.17 µm cut on mcon, the same square on li1, and a 0.29 × 0.23 µm rectangle on met1. A VIARULE ... GENERATE statement is a generation rule: enclosures on the two metal layers, the cut rectangle, and the cut-to-cut spacing. A router uses it to build vias of other sizes and writes each result into the VIAS section of the DEF (p. 339). The OpenROAD floorplan used below defines via_1600x480 from the rule M1M2_PR with CUTSIZE 150 150, CUTSPACING 170 170, and ROWCOL 1 5: one row of five cuts under a 1.6 × 0.48 µm metal 1 rectangle, used where the power grid connects to the rails.

LEF identifies layers by name. The GDS layer and datatype numbers, such as 68/20 for metal 1 drawing, come from the PDK's layer table, not from the LEF; reading a layer map describes that table.

The cell LEF

The first lines of the inverter macro:

MACRO sky130_fd_sc_hd__inv_1
  CLASS CORE ;
  SOURCE USER ;
  ORIGIN  0.000000  0.000000 ;
  SIZE  1.380000 BY  2.720000 ;
  SYMMETRY X Y R90 ;
  SITE unithd ;
  PIN A
    ANTENNAGATEAREA  0.247500 ;
    DIRECTION INPUT ;
    USE SIGNAL ;
    PORT
      LAYER li1 ;
        RECT 0.320000 1.075000 0.650000 1.315000 ;
    END
  END A

The cell is three sites wide and one site high. SYMMETRY lists the orientations that a placer may apply. Pin A has one port rectangle on li1, the output Y has three. The supply pins VGND and VPWR each have li1 rectangles and one metal 1 rectangle across the full cell width, centered on the bottom and top edge; these are the rails that join when cells abut in a row. OBS would list obstruction rectangles, areas a router must not use; the inverter's OBS block is empty. A macro carries no diffusion, polysilicon, or contacts. A router needs the outline, the pin access shapes, and the obstructions; the transistors are not needed until the mask data is assembled.

LayoutEditor window: on the left the inverter as the cell LEF describes it, an outline with blue rails and teal pin rectangles; on the right the same cell from the SKY130 GDS with an olive n-well, green diffusion, a red polysilicon gate, teal li1, and black contacts

Both cells are sky130_fd_sc_hd__inv_1, drawn in LayoutEditor at the same scale. Left: the abstract from the cell LEF, after the conversion script further down. The gray outline is the 1.38 × 2.72 µm macro size, the blue bands are the met1 rail ports, and the teal rectangles are the li1 ports of A, Y, VGND, and VPWR. Right: the cell from the SKY130 cell library GDS, reduced to n-well (olive), diffusion (green), polysilicon (red), li1 (teal), met1 (blue), and contact cuts (black). The pin rectangles on the left lie where the li1 shapes on the right are.

The DEF

The OpenROAD test file gcd_sky130hd_floorplan.def (OpenROAD commit bcc4a9be) is a design after floorplanning and power-grid generation, before placement of the logic:

Section Content In the gcd floorplan
UNITS DISTANCE MICRONS database units per micrometer 1000
DIEAREA die outline 279.96 × 280.13 µm
ROW a row of sites with origin, orientation, count, and step 95 rows of 564 sites; every second row FS
TRACKS routing grid per layer and axis 12 statements, X and Y for 6 layers
VIAS vias generated from VIARULEs 4
COMPONENTS instances: name, macro, status, point, orientation 1143: 873 FIXED tap cells, 270 without a location
PINS I/O pins with layer rectangles 54
SPECIALNETS power and ground wiring 2 (VDD, VSS)
NETS signal connectivity, optionally with routed wires 306, not routed

Other sections, absent from this file, are BLOCKAGES (placement or routing keep-outs, p. 232), REGIONS (fence and guide areas, p. 298), GCELLGRID (the global-routing grid, p. 250), and NONDEFAULTRULES (wider or more widely spaced wires for selected nets). The caravel DEF of the picture at the top is the routed state of another design: 487,167 components, 543 pins, and 1044 nets in 51 MB of text.

A component status is PLACED, FIXED, COVER, or UNPLACED (p. 237, pp. 242–243). Automatic tools may move a PLACED component, must not move a FIXED one, and nothing may move a COVER component. UNPLACED has no location. The small test file for this page places three inverters and routes one net:

COMPONENTS 3 ;
    - u1 sky130_fd_sc_hd__inv_1 + PLACED ( 1380 2720 ) N ;
    - u2 sky130_fd_sc_hd__inv_1 + PLACED ( 4140 5440 ) FS ;
    - u3 sky130_fd_sc_hd__inv_1 + PLACED ( 6900 2720 ) FN ;
END COMPONENTS
PINS 1 ;
    - a + NET a + DIRECTION INPUT + USE SIGNAL
      + PORT
        + LAYER met2 ( -70 -300 ) ( 70 300 )
        + PLACED ( 1610 300 ) N ;
END PINS
SPECIALNETS 2 ;
    - VGND ( * VGND ) + USE GROUND
      + ROUTED met1 480 + SHAPE FOLLOWPIN ( 1380 2720 ) ( 8740 2720 )
      NEW met1 480 + SHAPE FOLLOWPIN ( 1380 8160 ) ( 8740 8160 ) ;
    - VPWR ( * VPWR ) + USE POWER
      + ROUTED met1 480 + SHAPE FOLLOWPIN ( 1380 5440 ) ( 8740 5440 ) ;
END SPECIALNETS
NETS 2 ;
    - a ( PIN a ) ( u1 A ) + USE SIGNAL
      + ROUTED met2 ( 1610 300 ) ( * 3910 ) M1M2_PR
      NEW met1 ( 1610 3910 ) ( 1840 * ) L1M1_PR ;
    - n1 ( u1 Y ) ( u2 A ) + USE SIGNAL ;
END NETS

A routed wire is a chain of points on one layer. * repeats the coordinate of the previous point, a via name at the end of a chain places that via, and NEW starts the next segment of the same net. ( * VGND ) connects every component pin named VGND. Net n1 lists its two pins and has no ROUTED part: before routing, NETS is a netlist.

Special nets are for power, clock meshes, and hand-routed wiring; the reference states that a signal router should not modify them (p. 307). A special wire carries its width in the statement, here 480 database units, and a SHAPE such as FOLLOWPIN (a rail over a row) or STRIPE (a power-grid strap). Without an extension value its ends are flush with the end points (p. 322). Regular nets are created and changed by the router. Their wires take the default width from the LEF layer and extend past each end point by half the wire width (p. 261).

Units

LEF values are micrometers. DEF values are integers in database units, and UNITS DISTANCE MICRONS 1000 makes 1000 of them one micrometer: the row origin 10880 in the gcd file is at 10.88 µm. The LEF factor DATABASE MICRONS defaults to 100 (p. 158), and the legal values are 100, 200, 400, 800, 1000, 2000, 4000, 8000, 10000, and 20000 (p. 159). The DEF factor must not exceed the LEF factor and must divide it evenly (p. 160). Readers differ on files that break the rule: in the research tests for this page, OpenROAD rejected a DEF with factor 2000 on a LEF with 1000 (error ODB-0126), and LayoutEditor read the same file and scaled it. A reader that accepts a file does not show that the file is valid. Database units covers the GDS side of the same question.

Orientation and the placement point

DEF has eight orientations (p. 244):

DEF Transformation
N none (R0)
S rotate 180°
W rotate 90° counterclockwise
E rotate 270° counterclockwise
FN mirror across the y axis
FS mirror across the x axis
FW mirror across the x axis, then rotate 90°
FE mirror across the y axis, then rotate 90°

The point in a component statement is the lower-left corner of the cell's bounding box after the orientation is applied, not the position of the cell origin. A GDS reference stores the origin, a mirror flag, and an angle. For mirrored and rotated orientations the two coordinates differ. With the inverter's size of 1380 × 2720 database units, the three components of the test file become these GDS references:

Component DEF GDS reference
u1 N at (1380, 2720) origin (1380, 2720), no mirror, 0°
u2 FS at (4140, 5440) origin (4140, 8160), mirrored, 0°
u3 FN at (6900, 2720) origin (8280, 2720), mirrored, 180°

LayoutEditor window: three inverter abstracts on blue metal 1 rails, two in a lower row and one flipped in the row above, with amber squares at the lower-left corner of each cell and red squares at the GDS origins, one at the top-left of the flipped cell and one at the lower-right of the right cell

The test file after conversion in LayoutEditor. Amber squares mark the three DEF points, red squares the origins of the GDS references. For u1 at the lower left both coincide. u2 in the upper row is flipped top to bottom: its DEF point is its lower-left corner, its GDS origin the upper-left corner. u3 at the right is flipped left to right: the origin is at its lower-right corner. The upper row is FS so that its VPWR rail lies on the VPWR rail of the lower row; the gcd floorplan flips every second row for the same reason. The orange strip at the lower left is the met2 pin a with its wire up to the two vias at pin A of u1.

Reading LEF and DEF in LayoutEditor

LayoutEditor reads the files in the order of the references: open the technology LEF, then import the cell LEF files, then import the DEF. The GUI follows the same order. A LEF layer name that already exists in the layer setup keeps its layer number. A new name gets the first free layer number in file order, with datatype 0. The resulting numbers therefore depend on the layer setup of the installation, and they are not the PDK's numbers. The LayoutScript program below loads the three files, looks up which number each LEF layer name received, moves every shape to its SKY130 layer and datatype, puts pin labels on the label datatype, moves macro outlines to the SKY130 boundary layer 235/4, and saves GDS:

import os, sys
from LayoutScript import *
tech_lef, *cell_lefs, def_file, out_gds = [os.path.abspath(p) for p in sys.argv[1:]]
SKY130 = {  # LEF layer name -> SKY130 GDS layer, datatype; pwell has only a label pair (64/59)
    "nwell": (64, 20), "pwell": (64, 59), "li1": (67, 20), "mcon": (67, 44),
    "met1": (68, 20), "via": (68, 44), "met2": (69, 20), "via2": (69, 44),
    "met3": (70, 20), "via3": (70, 44), "met4": (71, 20), "via4": (71, 44), "met5": (72, 20)}
d = project.newLayout().drawing
d.openFile(tech_lef)                      # 1. technology LEF: layer names, vias, sites
for lef in cell_lefs: d.importFile(lef)   # 2. cell LEFs: one cell per MACRO
d.importFile(def_file)                    # 3. DEF: placement, pins, wiring
name_of = {layers.findLayer(n): n for n in SKY130 if layers.findLayer(n) >= 0}
moved, cl = 0, d.firstCell
while cl is not None:
    el = cl.thisCell.firstElement
    while el is not None:
        e = el.thisElement
        if e.isShape() or e.isText():
            if e.layerNum in name_of:     # LEF name -> SKY130 pair; pin labels -> label datatype
                n = name_of[e.layerNum]; layer, dt = SKY130[n]
                e.layerNum = layer; e.setDatatype((59 if n == "pwell" else 5) if e.isText() else dt); moved += 1
            elif e.layerNum == 0:         # macro outline -> prBndry 235/4
                e.layerNum = 235; e.setDatatype(4); moved += 1
        el = el.nextElement
    cl = cl.nextCell
d.saveFile(out_gds)
print("shapes_moved", moved)

The test script runs it on the test file and reads the GDS back:

PYTHONPATH=/opt/layout/python python3 lefdef_to_gds.py sky130_fd_sc_hd.tlef sky130_fd_sc_hd__inv_1.lef lefdef_demo.def lefdef_demo.gds
python3 lefdef_check.py lefdef_demo.gds lefdef_demo refs
shapes_moved 97
units_m 1e-09
ref L1M1_PR 1840 3910 mirror=0 angle=0 name=-
ref M1M2_PR 1610 3910 mirror=0 angle=0 name=-
ref sky130_fd_sc_hd__inv_1 1380 2720 mirror=0 angle=0 name=u1
ref sky130_fd_sc_hd__inv_1 4140 8160 mirror=1 angle=0 name=u2
ref sky130_fd_sc_hd__inv_1 8280 2720 mirror=1 angle=180 name=u3
path layer=68 width=480 pathtype=0 1380,2720 8740,2720
path layer=68 width=480 pathtype=0 1380,5440 8740,5440
path layer=68 width=480 pathtype=0 1380,8160 8740,8160
path layer=68 width=140 pathtype=2 1610,3910 1840,3910
path layer=69 width=140 pathtype=2 1610,300 1610,3910

Each macro becomes a cell with its outline, its port and obstruction rectangles, and one text label per pin. Each LEF via becomes a cell. Each component becomes a cell reference that carries the instance name as GDS property 10. Special wires become paths with flush ends (path type 0) and the width from the DEF; regular wires become paths that extend half their width past the end points (path type 2) with the LEF default width. The same output results when the layer setup holds only neutral names, so the script does not depend on the names an installation already has. On the gcd floorplan the script moves 24,961 shapes and writes 1143 component references plus 2907 via references in the top cell. On the caravel DEF, all 487,167 component references matched the DEF position and orientation in the tests for this page; reading took about 15 s.

The GDS contains abstracts, not mask data. For a mask file, the cells must come from the cell library GDS; chip tutorial 5 shows that step on a routed design.

DEF content that does not become geometry

DEF content In the GDS written by LayoutEditor
DIEAREA, ROW, TRACKS, GCELLGRID no shapes; these are outlines and grids, not mask layers
BLOCKAGES, REGIONS skipped with a warning
NONDEFAULTRULES skipped with a warning; affected nets are drawn with the LEF default width
component without location (UNPLACED or no status) reference at (0, 0); 270 references in the gcd floorplan
net connectivity no GDS record; LayoutEditor builds its own netlist from the DEF

Two pin cases need a count after import. In the research tests for this page, pins with the + FIXED status produced no shape and no label, and a pin with two rectangles produced only its label. In the caravel DEF this concerned the two supply pins, so 541 of 543 pins appeared.

LayoutEditor can also write LEF from a layout. The written file is derived from the layout's cells and the layer setup; it does not reproduce the PDK's technology LEF (sites and via rules are missing), so a router needs the PDK's original files.

Errors in the read order

The tests for this page loaded the test file with one input missing:

  • Technology LEF and DEF, no cell LEF: LayoutEditor reports 1 Cellref(s) can not be resolved. Empty cell added. (sky130_fd_sc_hd__inv_1). The three references exist, but u2 sits at (4140, 5440) instead of (4140, 8160): without the macro size, the DEF point cannot be converted to a reference origin.
  • Cell LEF and DEF, no technology LEF: LayoutEditor reports that via information is missing and adds L1M1_PR and M1M2_PR as empty cells. The signal wires get width 0, because the default wire width is a technology LEF value.

In the caravel design, one missing cell LEF (sky130_ef_sc_hd.lef, 8 macros) left 275,569 component references pointing to an empty cell, reported in a single message line.

Checks after a conversion

  1. Count the cell references with an instance name and compare the result with the COMPONENTS count of the DEF.
  2. Count the pin labels in the top cell and compare with the PINS count.
  3. List the layer/datatype pairs in the GDS. A shape on datatype 0, or on a number that is not in the PDK layer table, belongs to a LEF name that was not mapped.
  4. Check one mirrored instance against the lower-left rule.
  5. Search the import messages for unresolved cell references and skipped sections.

Continue exploring