LEF and DEF are two types of files that APR engineers often encounter in their work, and they will also have a direct impact on the basic configuration of APR and the flow of APR. It is basically equivalent to the basic construction of APR physical design.
LEF/DEF interpretation and usage scenarios
The LEF and DEF files encountered by APR engineers, the specific corresponding process and application scenarios are as follows pic_center
| file name | full name | Scenes |
|---|---|---|
| DEF | Design Exchange FIle | STA-PECO, APR data delivery and reconstruction, routing/layout information transfer, etc. and design-related matters |
| LEF | Library Exchange FIle | Physical library files, process technology files, APR hierarchical design delivery (used with ETM) |
It can be seen from the above that the different initials of the files in the file also represent the similarities and differences between them: LEF is more focused on the library, and DEF is focused on the design.
APR engineers often use various libraries or various versions of libraries to interact. Today, I will discuss and clarify one or two APR-related bits and pieces in LEF.
tech-LEF is usually delivered by FAB, which is usually very rigorous, and there will not be too many accidents. However, for the delivery of IP, the strategies of different vendors are sometimes different, and the LEF of the IP usually has a direct impact on the floorplan, placement, and routing. When problems arise, APR engineers are required to locate them. Therefore, if you can grasp a few key information in LEF, you may find some discoveries even before importing the flow tool; or if there are some abnormalities in flow, then you may get a faster solution by reading LEF. Based on the above, let’s take a look at the LEF information related to APR. Gossip less, ICer Go!
Analysis of tech-LEF
Usually a standard LEF file has the following format.
This format takes into account both tech-LEF and IP LEF application scenarios. The definition of IP LEF MACROstarts from the fields. For the main fields of tech-LEF, here is a simple list for quick listing
| field | paraphrase | example |
|---|---|---|
| VERSION | Version of LEF | 5.7 |
| BUSBITCHARS | bus separator | [] |
| NAMESCASESENSITIVE | Case Sensitive | ON |
| UNITS | Define the conversion relationship between DBU (database unit) and Standard International of various units in the design | DATABASE MICRONS 1000 |
| USEMINSPACING | Define the application scenario of minspacing | USEMINSPACING OBS OFF |
| MANUFACTURINGGRID | Process production grid, cell and routing need to guarantee the minimum grid | MANUFACTURINGGRID 0.001 |
| SITE | Constraints on stepping height and width of std-ecll row |  |
| LAYER | The definition of each layer used by APR includes but is not limited to: type (TYPE), spacing (SPCING), width (WIDTH) , area (AREA) , center distance (pitch), etc. It is mainly used to constrain router winding rules and checker to evaluate winding quality |
 |
For the tools of the C family, students can use tech-LEF directly; for the tools of the S family (ICC and ICC2), they all need to use the technology file (TF) file provided by FAB, which can basically be equivalent to tech -LEF, just the process is different.
tech-LEF is more like a strong physical requirement based on FAB-node. These rules will weigh and evaluate various resources of APR tools, including but not limited to:
| APR resources | Related LEF settings |
|---|---|
| std-cell row | SITE |
| track per-layer (including impact on NDR) |
LAYER PITCH |
| layer shame | LAYER |
| layer prefer routing direction | LAYER DIRECTION |
| grid check | MANUFACTURINGGRID |
The APR tool parses the tech-LEF to create the corresponding physical design constraints. It can be seen that, under the unit chip area, the above configuration of tech-LEF will determine the final available resources of the chip. The smaller the SITE/PITCH/MANUFACTURINGGRIDtech-LEF file size (etc.) is, the smaller the values at each definition point will be. Corresponding The more on-chip resources there will be.
Analysis of IP LEF
For the LEF file of IP, there will usually follow the following template
In order to be compatible with LEF5.8, the fields that will be seen in the second half of this standard template PROPERTY LEF58are usually only used for complex designs with complex processes. Usually, non-LEF5.8 fields are sufficient for IP delivery.
Similarly, the APR tool will analyze the LEF of the IP, thereby bringing in the influence of the IP on layout, routing and other resources, and under this influence, complete the integration of the IP and the final GDS merge (merge).
- CLASS
is usually more than this MACRO for basic classification. Here is a list of their definitions and the tool marks corresponding to the S family and the C family.
| keywords | S home mark | C home mark |
|---|---|---|
| BLOCK | mask_layout_type==macro | cell.subClass ==block |
| RING | mask_layout_type==macro | cell.subClass ==blockRing |
| CORE | mask_layout_type==std | cell.subClass == core |
| PAD | mask_layout_type==io_pad | cell.subClass == pad |
| PAD SPACER | mask_layout_type==io_pad | cell.subClass == padSpacer |
Since the flow of the C family uses LEF directly, usually the information related to LEF can be directly obtained through cell.subClass, and the FRAME view of the S family is created based on the LEF file through MW/NDM and provided to the ICC/ICC2 tool. Here There will be some transfers with normal syntax. Taking ICC2 as an example, the following table lists the information mapping relationship between LEF and NDM FRAME
- FOREIGN
This is an offset between the mark LEF and GDS. If the origin of the GDS design of the IP does not fall on the origin of the coordinates, then there may be a non-zero value here. If the origin of the GDS is in the first quadrant, FOREIGN is negative. Value, if it is in the third quadrant, it is a positive value, see the example in the figure below for details
- ORIGIN
refers to the offset relative to the current origin when the IP is placed,
assuming the following IP configuration:
MACRO B1
......
ORIGIN X1 Y1
FOREIGN B1 X2 Y2
The coordinates placed in the APR are: X3 Y3
, then the starting point of the final B1 GDS polygon extraction is (X1+X2+X3 Y1+Y2+Y3)
For the usual IP: X1=Y1=X2=Y2=0.
For an IP with a GDS relative displacement: X1 + X2 =0, Y1+Y2=0
From a personal point of view, the advantage of this is that the error of GDS offset and top-level integration can be stitched, so that the final GDS-out remains Stable output. (Please correct me if my understanding is biased)
- The SIZE
field describes the width and height of the IP. The syntax format is:SIZE WIDTH BY HEIGHT. For a rectangular IP, this field can easily express the area of the IP through the width and height: SIZE=WIDTH*HEIGHT
Careful students can See, the description of BLOCK here can only be a simple rectangle, which is a limitation of the LEF rule. For a polygonal MACRO, LAYER support is required. This will be discussed later. - SYMMETRY
defines the constraints on the orientation of the IP. IP designers need to pay attention to the fact that their IP may encounter operations such as inversion and mirroring when it is integrated by the top layer. Through this handle, the APR tool can be restricted from performing controlled inversion of the IP, which can effectively avoid problems caused by wrong orientation of the IP. The base DRC is wrong. This is very important for IP users. The configurable options are as follows:
| toward | explain |
|---|---|
| 如果不定义SYMMETRY，仅允许朝向N | |
| X | 允许水平反转 |
| Y | 允许垂直反转 |
| R90 | 允许90度反转，由于poly 的限制，这种只会在比较大的工艺节点构造里被允许可以 （memory可能会被排除） |
对于常见的std-cell，通常都是可以水平和垂直反转的，那么对应的SYMMETRY的写法是：SYMMETRY X Y
- SITE
对于比较规则的IP，SITE会比较有用，譬如std-cell和IO的site，这样APR工具在创建core或者IO-ring的时候，就可以基于site对std-cell和IO进行自动布局，这也是APR placer工具做布局，合规化（legalized）基础，对于普通IP这里也可以不做定义。但是对于先进工艺，由于coloring/grid的问题，所以在IP上面（尤其是较有规律的SRAM）这个site的应用场景会变得更加丰富了。 - PIN
这里是IP描述的主要部件，给用户提供访问IP的pin的物理位置信息，所有的坐标都是相对于当前IP的左下角（N 朝向）而言的。
这里分别给出信号pin和电源pin两个示例。
对于信号pin，上述示例的信号pin是一个std-cell，为了M1的pin形状需要用三个矩形来描述（rectangle），对应的VDD需要有多达六个矩形来描述
对于IP，通常的pin是abut到boundary的，而且是单rectangle的。示例如下
这个是用户使用IP LEF较常用的一种格式。这里有几个地方需要注意
- IP的pin需要和IP的boundary贴合，方便外界访问，如果做不到贴合。那么OBS的创建需要注意，至少保证pin可以通过drop via进行访问
- IP的pin的width需要满足当前层的min-width需求，长度建议1um，方便绕线和GUI观察
- pin和pin之间需要至少控制一个track，这样可以满足潜在的HV spacing 需求
从上述例子可以看出，LEF也是支持antenna的信息的，这样可以支持APR工具在只有LEF的时候也可以对antenna进行评估和修复。
- OBS
OBS是Obstruction的缩写，故名思意是对IP的遮挡，对于IP的应用，通常会牵扯到两类遮挡，这个和APR的常规的处理非常相似，- 放置遮挡（placement OBS）：对APR工具的放置进行阻止
- 绕线遮挡（routing OBS）：对APR工具的绕线进行阻止
由于IP都要自己的SIZE（boundary），如果用户不在这里OBS的句柄里边额外定义，那么IP的SIZE描述的区域都是不能放置其他器件的。
在前文有说道，SIZE只支持矩形，但是如果有了OBS配合就可以支持多边形了。
这里使用OBS调用OVERLAP 类型的LAYER对IP的SIZE进行切割，这样就形成了一个多边形了。这里的OVERLAP是一个特殊层，需要在tech-LEF里边进行预先定义，具体实例如下
这样在APR工具里边就可以看到一个多边形IP了。
对于绕线遮挡，OBS通过调用routing /cut LAYER 来进行定义。通常如果IP的顶层是M4，那么IP的出pin 也会在M4 和 M3（M4-1）层。这样的规则和APR的partition策略比较相像。
但是通常，出pin的位置都是需要外界绕线直接访问的，所以出pin的位置是不能就想遮挡的，如果IP的顶层是M4，那么最多有一些M4的资源可以始放出来，M4一下的M3/2/1都应该进行遮挡，否则APR工具会在上边走线，这也是OBS存在的重要价值所在。
废话不说，有图有真相
As can be seen from the above figure, the IP here has a pin that fits the boundary of M1, and this IP is covered by the OBS of M1, but in the LEF rules, the pin bbox has the feature of overwriting the OBS, so around the M1 character, there will be An OBS blank area, follow up the pin width and the corresponding spacing to adjust, this can be clearly seen through the MW of the S home
Combined with the above theory, a relatively simple IP OBS is written as follows
Both tech-LEF and IP LEF follow the LEF syntax and can be merged together, but usually due to different vendors, IP LEF only pays attention to the information within the MACRO, and the rest is basically completed by tech-LEF. If Users need global definition changes, please move to tech-LEF for optimization. If it is an update of VIAGEN rule or NDR rule, it can also be added from the perspective of project/process. This configuration is more biased towards tech-LEF.
There are many keywords in LEF. LEF is usually extracted from GDS using the abstract tool. Due to the strong dependence of APR tools on LEF, for APR engineers, it is only necessary to be able to see the conventional syntax. When problems occur, they can find the corresponding reasons and solutions. Finally, Or to promote APR work more efficiently.
[Knock on the blackboard to draw key points]
Being able to read LEF is a icing on the cake skill of an APR engineer. It can get twice the result with half the effort for quickly locating process and delivery problems.
References
Synopsys Library Manager User Guide
Synopsys ICC user guide
Synopsys ICC2 user guide
Cadence LEF/DEF 5.8 Language Reference
Cadence Innovus user guide