Legalization是后端设计中的基本概念之一，我们可以简单地理解为工具尝试找到合适的位置放置standard cell (以下简称stdcell)。但是stdcell【合适的位置】的定义却随着工艺的演进变得越来越复杂。一般来说工具认为一个【legalized stdcell】通常要满足以下基本条件：
图1：Legalization基本条件
尽管legalization的绝大部分工作是由EDA工具自动完成的，但后端工程师仍然有可能遇到legalize失败的问题，同时有很多因素可能会影响工具的legalize进而影响绕线和时序，因此今天我们和大家分享一下legalization的常见问题，希望能帮助大家解决实际中遇到的困难。
典型问题1：Legalize失败**
在ICC2和Innovus中，都有可能遇到legalization失败的问题。可能是少量cell无法找到合适的位置，也有可能是大规模的legalize失败。典型的现象是log中报出如下信息，工具提示对某些cell无法找到合适的位置，同时legalization步骤很长时间也无法完成甚至导致工具crash：
ICC2 Warning示例:
After %d legalization trials, instance %s (ref_name) has the following legality failures: (LGL-164)
================ Instance Legality Failure Profile ===============
non-overlap
rule failures failure % failure %
------------------------------------------------------------------
pg_drc 480000 x.00% y.00%
pin_color_align 480000 x.00% y.00%
spacing_rule 480000 x.00% y.00%
legal_orient 480000 x.00% y.00%
vt_min_width 480000 x.00% y.00%
tpo_min_width 480000 x.00% y.00%
od_length 480000 x.00% y.00%对应的Innovus中也会报出类似的信息：
InnovusInformations/Warnings示例:
**Info: (IMPSP-2030):
Within search radius 250.880 um from center (1475.620 3234.480), there is no legal location for instance "top/i131" ( cell: "AOIX3" ). This is likely caused by "Soft_Blockage_Violation". The legalization search will continue in the rest of core area.
**Info: (IMPSPS-2031):
Within search radius 216.576 um from center (669.984 795.264 ), there is no legal location for instance "top/U232" ( cell : "INVD1" ). This is likely caused by "Implant_Min_Area_Violation".
**Info: (IMPSP-2033):
Within search radius 73.728 um from center (399.960 149.760), there is no legal location for cell: "LXTC20". This is likely caused by "DRC_Violation". The legalization search will continue in the rest of core area.
**Info: (IMPSP-2034):
Within search radius 307.200 um from center (0.000 1328.400), there is no legal location for cell: "iso1". This is likely caused by "DRC_Violation".
**WARN: (IMPSP-2040):根据log中提示的信息我们大致能够了解，在legalize的时候工具通过不断移动cell来尝试获取最合适的位置，如果尝试的次数或者移动的距离超过一定阈值就会报出类似上面的提示，从而告诉我们某些cell的legalization失败了。如果legalization失败的cell数量较少，我们从上述信息中可以获取cell名字检查具体问题，很有可能找到问题的原因。如果出现大规模的legalization失败，那么很有可能就是其他原因导致的，需要进一步分析。
典型问题2：Large Displacement**
所谓displaement，可以理解成stdcell的理想位置和legalized位置之间的距离，理论上该距离越小则legalization对timing和绕线的影响就越小。一般来说ICC2/Innovus都会在legalization之后报出类似下面的'Displacement Report'：
ICC2 Displacement Report:
================ Displacement Report =================
Area: placed=3152425, unplaced=0, fixed=4344236, blocked=0, total=12249828
Density = 7496661/12249828 sites = 61.20%
Inbound cells: 0; 2-row cells: 60723; >2-row cells: 217
Total cell instance count: 408811 (318180 placed, 0 unplaced, 90631 fixed)
Number of cells moved: 293772 (71.86%) Orientation changes only: 1097
Average cell displacement: %f um (AW: 0.1330 um = 0.5544 rh)
RMS cell displacement: %f um (AW: 0.2135 um = 0.8894 rh)
Max cell displacement: %f um = 12.5109 rh
Max displaced cell: %s (-213.864 29.04Innovus Legalization Summary Report:
*** Starting place_detail (2:16:53 mem=9204.0M) ***
Total net bbox length = 7.221e+06 (3.421e+06 3.800e+06) (ext = 2.722e+06)
Move report: Detail placement moves 270691 insts, mean move: 0.34 um, max move: 33.30 um
Max move on inst (%s): (-105.81, -476.29) --> (-72.62, -476.40)
Runtime: CPU: 0:01:24 REAL: 0:00:25.0 MEM: 9660.0MB
Summary Report:
Instances move: 270691 (out of 270691 movable)
Instances flipped: 0
Mean displacement: 0.34 um
Max displacement: 33.30 um (Instance: %s ) (-105.805, -476.288) -> (-72.618, -476.4)
Length: 16 sites, height: 2 rows, site name: %s , cell type: %s
从上述信息中我们可以看出，工具会统计出所有移动过的stdcell的displacement距离，并给出displacement值最大的cell信息。一般来说我们比较关注max displacement的值，该数值最好在10um以内，最好控制在5um以内为佳。一旦发现有大量的cell的displacement值都是几十um，则很有可能预示着legalization过程本身存在问题。
典型问题3：Legalization时间过长**
一般来说设计无论大小，无论工艺是否先进，legalization步骤都不需要花费太多的时间，少则几秒多则十几分钟一般都能够正常结束。一旦发现legalization进程缓慢或者长时间卡住且没有log更新，则很有可能legalization遇到了问题。
比如ICC2中会实时报告legalization的进度：
Information: Legalizing 317143 moveable cells.
Legalization progress 13%...
Legalization progress 27%...
Legalization progress 42%...
Legalization progress 57%...
Legalization progress 72%...
Legalization progress 100%...而Innovus也会在Legalization结束后给出相应的Runtime统计：
*** Starting place_detail (2:16:53 mem=9204.0M) ***
Total net bbox length = 7.221e+06 (3.421e+06 3.800e+06) (ext = 2.722e+06)
Move report: Detail placement moves 270691 insts, mean move: 0.34 um, max move: 33.30 um
Max move on inst ( %s ): (-105.81, -476.29) --> (-72.62, -476.40)
Runtime: CPU: 0:01:24 REAL: 0:00:25.0 MEM: 9660.0MB同时需要注意的是，ICC2工具在优化过程中有时会发现进程卡住却没有任何提示，该现象一方面有可能是设计的时序难以优化而需要长时间迭代，另一方面工具也会在优化过程中调用legalizer引擎而不显示legalization进度，因此该现象也有可能是legalization问题导致的，需要具体问题具体判断。
问题分析与解决
归根结底，上述问题的原因都可以总结成一句话：stdcell很难找到合适的位置摆放。但形成这种现象的原因却可能是多方面的：
1) 局部或整体density过高(包括hard bound/fence的大小和区域设置不合理)
一方面需要在芯片面积规划阶段合理评估每个模块的初始利用率(density/utilization)，另一方面要时刻关注优化步骤(placeopt/postcts/postroute)之后的利用率变化，一般来说整个PR过程的利用率增长不会超过10个点，平均在5个点左右比较比较普遍。一旦初始利用率很高或者优化后利用率暴涨，legalization问题也多半会随之而来。这类问题的关键却并非legalization本身，而更有可能是面积规划过小，时序约束不合理或者设计本身存在的问题，需要进一步分析。典型原因如绕线紧张的部位工具会把大量cell向四周推开从而导致外围的density升高，我们需要找到问题的本质加以分析才能真正解决legalization问题。
对于局部的利用率过高，尤其是用户设置了hard bound/fence等约束后发现大量cell被强制聚集到某个区域，则很有可能是bound/fence的面积与位置规划不合理导致的，此时应该调整bound/fence的大小和位置来尝试缓解这种情况。局部过高利用率示例：
2) site row允许的orientation与power rail不匹配
一般来说每个site row都对摆放其中的stdcell的orientation有约束，我们可以直接通过以下命令获取：
icc2_shell> get_attribute [get_site_rows *site_row_0] legal_orientations而该属性和设计本身使用的site的symmetry属性息息相关，不同的symmetry属性会导致site row具有不同的legal_orientations。因此如果出现大规模的legalization问题，需要查看是否存在stdcell的orientation无法和site row的legal_orientations不匹配的情况。我们可以通过命令获取其对应的site的属性，当然也可以通过查看.tf或tech lef文件查看site的属性：
icc2_shell> get_attribute [get_site_rows *site_row_0] site_def.symmetry
@innovus > get_db [get_db rows coreROW_1] .site.symmetry 除此之外，每个row上摆放的cell还需要与对应的电源rail连接，如果电源rail的位置和stdcell允许的oriention不匹配也会出现大规模legalization的问题：
3) 不合理的hard placement blockage
此类问题一般是用户的误操作或者不合理设置导致的，一般可能很快定位问题，不作赘述。
4) stdcell出pin的金属层绕线密度过大
某些类型的stdcell的pin的金属层可能会在PR过程中大量使用，尤其是可能被电源网络占据大量的绕线资源。如果pin很密集的stdcel大量聚集在某处，同样可能导致legalization的问题。此时一方面分析找到这类对legalization不友好的cell类型设置dont_use，另一方面也需要评估电源网络的pattern是否可以调整来让此类cell更容易legalize。
5) 太多或太严苛的用户定义的spacing rule/relative placement
一般我们可以通过少量设置cell之间的spacing rule来减少DRC，同时也可以用relative placement让某些cell的摆放更符合设计者的需求。但是过多过于复杂的的规则会加重算法的负担，显著增加legalization的runtime甚至导致有些cell找不到合适的位置摆放。因此这类设置除非必要否则不宜多加：
# ICC2
set_placement_spacing_label
set_placement_spacing_rule
# Innovus
set_cell_edge_spacing6) 不友好的stdcell形状和pin access方式
与上面4)所描述的情形类似，如果cell本身的金属pin很密集，那么它能摆放的位置就比较有限，如果cell的形状特别细长或者是多个row高度的Multi-Height类型，则其legalization会被进一步削弱。这类cell我们一般希望在设计的早期找到并且在优化中禁止使用(dont_use)。一般我们可以通过以下命令来评估cell的legalization情况：
@innovus >check_library -place -cell A
icc2_shell> analyze_lib_cell_placement -lib_cells可以从报出的结果中找到下面的信息，一般来说pass rate越低，legalization frequency site数值越大则证明cell越难以legalize：
# Innovus
reporting cell legal frequency ...
cell (ref_name) legalization frequency: one legal location out of every 6.19 sites
# ICC2
Lib Cell Pass Rate
---------------------------------------------------------------- ---------
lib_name:ref_name.frame 通过上述分析过程，一般我们遇到的绝大多数legalization相关问题都能找到线索并加以解决。也欢迎大家留言记录你遇到过的legalization问题和大家一同进步！
如果这篇文章让你学到了一些新知识，请帮忙转发，谢谢大家~
来源：数字后端设计芯讲堂
作者：数字后端设计芯讲堂
推荐阅读
- 后端进阶系列：Innovus+ICC2对比7nm工艺的后端实现（物理篇）
- 后端进阶系列：Setup&Hold互卡问题和Useful Skew的影响
- 后端进阶系列：Innovus+ICC2对比7nm工艺的后端实现（QoR篇）
如果大家有任何后端技术与职业发展方面的问题，抑或关于数字后端感兴趣的技术话题想要了解和探讨，欢迎关注我的知乎专栏： 数字IC后端设计工程师修炼之路
同时欢迎关注微信公众号：数字后端芯讲堂，一起探讨技术，共同提升!
本极术专栏也会同步更新芯片设计后端的技术干货，也请关注数字IC后端设计工程师修炼之路。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
