Reprinted from:

Physical implementation — LEF and DEF_zhuangdk's blog - CSDN blog_The difference between lef files and def files https://blog.csdn.net/zhuangdk/article/details/111669164

LEF
LEF is the abbreviation of Library Exchange Format and is the description format of the C home physics library. LEF is divided into two types: tech lef and cell lef. No matter which stage of tooling, you must first read the tech lef and then read the cell lef, because the information defined in tech lef should be referenced in cell lef.

Tech lef defines metal layer, via, design rule and other information. Please study the following pictures cut from the oil pipe in detail. The figure introduces in detail what information tech lef and cell lef contains and the correspondence between cell lef and cell abstract view.
layer type: routing, cut (contact), masterslice (poly, active), overlap.
design rule: width, pitch, spacing.

via definition.
metal direction.
resistance and capacitance per unit square.
antenna factor.

The geometry and abstract view of the cell are defined in the Cell lef:

site extension.
cell descriptions, cell dimensions.
layout of pins and blockages, capacitances.

check_design will perform lib/lef consistency check, and can report which lib cells have no corresponding lefs and which lefs and no corresponding lib cell. The tool will automatically set the dont_use attribute for cells with lib but no lefs, so it is necessary to ensure that all std cells corresponding to the lefs used in the comprehensive are read in.
When reading def, if some macro lefs are missing, the tool will report PHYS-* Error. Without lefs, the tool cannot know the cell's appearance and pin location, so you must read all the lefs used in macro.

DEF
DEF's full name Design Exchange Format is used for circuit physical information interaction and is a bridge connecting the front and back ends of digital implementations. The commonly used DEF version is 5.8. The following information can be defined in DEF. This article does not analyze the meaning of each part, but only outlines some of the information required for physical synthesis. DEF file has the following limitations:

The length of the identifier cannot exceed 2048 characters, such as the names of net and cell. Usually, if some cell names in the design are too long, change_name will be performed after the synthesis is over, limiting the length of its name to within 2048 characters;
Declarations in DEF all end with ";" and must be preceded by ";".
Each section in DEF can only be specified once, and ends with "END SECTION". The DEF file is usually relatively large. After getting the DEF, you can use 'grep END' to check which sections are defined in the current DEF file.
In DEF, except for + ORIGINAL in NETS section, all objects must be defined first and then used, some objects are read from netlist, some objects are read from techlef/lef, and some objects are defined in DEF.
、

head

The DEF header contains:

The generated tool and tool version, here: Innovus 18.12-s102_1.
Linux operating system;
date of document production;
The name of the current design;
The command to generate DEF, here is: defOut -floorplan ../fp.def

units 

The first part of the DEF file defines:

The version number of DEF, here is 5.8;
splitter;
bus bit symbol;
Design name;
Units distance micros, here is 2000.

The other parts are easy to understand. We need to specifically mention Units. The definition of units cannot be changed as you wish. The protocol stipulates that the value must be less than or equal to the value specified in DATABASE MICRONS in tech lef. It is best that the values ​​on both sides are consistent. At some advanced technology points, if the definitions of the two values ​​are inconsistent, VIA will be offset. This value is used to calculate the actual distance in DEF, and if it is 2000, it means 1um = 2000 units.

Properties and Die Area

All properties used in DEF need to be defined in the Properties section, and the distance of Core2Die is also defined in the Properties section. So far, except for the 7nm H300 other processes, there are no special requirements for the distance of Core2Die. There are particularly specific requirements for the 7nm H300, otherwise there will be a problem of track offset. DIEAREA defines the shape and size of the current design. If it is a rectangle, it has two coordinates, and if it is a polygon, it will have a series of coordinates. The corresponding coordinate value divided by the value of units in Units distance micros is the actual distance.

ROWS

All std cells need to be placed on the ROW, so in DEF, all used SITEs need to be defined and SITEs are read from Tech lef.

There are several section definitions in DEF that require specifying directions, and the directions are also specified in the definition of ROW. There are the following effective directions in DEF. In the above example, the direction difference between each two adjacent ROWs is 180 degrees. The purpose of this is to share the power supply and ground with multiple ROWs.

TRACKs

Define tracks for each layer that can be used for routing otherwise the winding resources are unavailable. This original description is better, and it will change its flavor after translation. The original text is appreciated: "Defines the routing grid for a standard cell-based design. Typically, the routing grid is generated when the floorplan is initialized. The first track is located at an offset from the placement grid set by the OFFSET value for the layer in the LEF file. The track spacing is the PITCH value for the layer defined in LEF."

Components

DEF for synthesis This section of content:
All hard macros should be defined as placed or fixed.
Write all physical only cells out and take up a place;
If there is a power swtich, it is best to write it out as well, which will take a hole;
All hard macros should have lef, otherwise the tool will not know its shape and will also report an error;
Don't write STD cells unless some STD cells are manually instantiated and have location requirements.

Pins

The pin here refers to the input and output port of hard macro. This part defines the location of each pin. It is best to assign a good location for each pin. However, in the early stage of implementation, some pins do not use pins such as DFT, and no location can be accepted.

VIAs and SPECIALNETs

The comprehensive DEF does not require signal nets, but you must write down Special nets, especially for process nodes after 16nm. Special nets will occupy a lot of winding resources, which has a great impact on timing and congestion.

The Special nets part will use VIA, and all the VIAs used need to be defined in advance.
Lists the names and geometry definitions of all vias in the design. Two types of vias can be listed: fixed vias and generated vias. All vias consist of shapes on three layers:

a cut layer and two routing (or masterslice) layers that connect through that cut layer. 
A fixed via is defined using rectangles or polygons, and does not use a VIARULE. The fixed via name must mean the same via in all associated LEF and DEF files. 
A generated via is defined using VIARULE parameters to indicate that it was derived from a VIARULE GENERATE statement.

For a generated via, the via name is only used locally inside this DEF file. The geometry and parameters are maintained, but the name can be freely changed by applications that use this via when writing out LEF and DEF files to avoid possible via name collisions with other DEF files.

Blockages and Regions

Blockages and Regions are both design constraints. It is best not to write to DEF. You can write to Tcl file separately. For example, in Innovus, you can use the command "writeFPlanScript -section".