Legalization

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：

根据log中提示的信息我们大致能够了解，在legalize的时候工具通过不断移动cell来尝试获取最合适的位置，如果尝试的次数或者移动的距离超过一定阈值就会报出类似上面的提示，从而告诉我们某些cell的legalization失败了。如果legalization失败的cell数量较少，我们从上述信息中可以获取cell名字检查具体问题，很有可能找到问题的原因。如果出现大规模的legalization失败，那么很有可能就是其他原因导致的，需要进一步分析。

典型问题2：Large Displacement

所谓displaement，可以理解成stdcell的理想位置和legalized位置之间的距离，理论上该距离越小则legalization对timing和绕线的影响就越小。一般来说ICC2/Innovus都会在legalization之后报出类似下面的'Displacement Report'：

从上述信息中我们可以看出，工具会统计出所有移动过的stdcell的displacement距离，并给出displacement值最大的cell信息。一般来说我们比较关注max displacement的值，该数值最好在10um以内，最好控制在5um以内为佳。一旦发现有大量的cell的displacement值都是几十um，则很有可能预示着legalization过程本身存在问题。

典型问题3：Legalization时间过长

一般来说设计无论大小，无论工艺是否先进，legalization步骤都不需要花费太多的时间，少则几秒多则十几分钟一般都能够正常结束。一旦发现legalization进程缓慢或者长时间卡住且没有log更新，则很有可能legalization遇到了问题。

同时需要注意的是，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_spacing

6) 不友好的stdcell形状和pin access方式

与上面4)所描述的情形类似，如果cell本身的金属pin很密集，那么它能摆放的位置就比较有限，如果cell的形状特别细长或者是多个row高度的Multi-Height类型，则其legalization会被进一步削弱。这类cell我们一般希望在设计的早期找到并且在优化中禁止使用(dont_use)。一般我们可以通过以下命令来评估cell的legalization情况：

通过上述分析过程，一般我们遇到的绝大多数legalization相关问题都能找到线索并加以解决。也欢迎大家留言记录你遇到过的legalization问题和大家一同进步！

原文链接：数字后端设计芯讲堂