Physical aware ECO

通常的后端流程里边，在流片的前几周，一定会有一段相当忙碌的时间，这段时间就是我们所说的ECO（Engineer Change Order ）阶段。

在最后一版layout完成了以后，后端工程师拿着这个宝贵的数据库，就要开始做timing和physical的ECO了，为了最终的流片做冲刺。

物理上的ECO一般包括以下一些的内容

起因：由于APR工具的library view所限和相关检查规则的不完整，导致APR工具不能看到所有的library cell绕线层的细节，导致出现的metal的问题。基于full gds的第三方工具检查（Hercules/ICV/Calibre）可能会暴露出更多的placement相关的问题。

1：物理绕线short的修复：来自于你的APR工具的报告，也有来自signoff LVS的反馈

2：PV signoff DRC的修复：这里边包括了由于物理摆放问题带来的基层违例，也有绕线之间的距离，面积，密度等的问题

3：对Antenna和 ESD违例的修复

一般的物理修复都是手动的工作，但是也有高手可以使用scripts来实现所有的physical的操作，使用命令的最大好处是可控和可追溯，在这里就不展开了，以后有机会的话，我们再来讲PV。

时序上的ECO一般包括以下一些的内容

起因：通常的layout版图流程的结束，都不太可能会做到full timing clean，加上APR工具和STA（PT）工具的差异性，和在PT侧更多signoff corner/mode的需求，timing ECO一定是少不了的

PS：Synopsys也给出过一些减少差异性的方法，但是感觉还是不能完全解决这个问题，个人理解这些还是要根据工艺和自身R2G流程进行调整。如果你有更好的方法解决APR/STA差异性的问题，不吝赐教！

1：fix logic DRC：max_cap、max_tran、noise，max_fanout等等

2; setup/hold timing violation

3：leakage 优化

这里的timing ECO是今天的主角。

在现阶段的PT里边，已经支持了DMSA（Distributed Multi-Scenario Analysis ），如果还没用过的同学，请移步到下面的链接（PrimeTime: Why Use Distributed Multi-Scenario Analysis (DMSA)?）了解：

https://solvnet.synopsys.com/retrieve/026814.html?otSearchResultSrc=advSearch&otSearchResultNumber=1&otPageNum=1

DMSA的好处就是PT可以在一个会话里边，看到我们所有的MCMM的结果，这样PT在做任何的修复的时候都会顾及在所有的情况下的影响，这样可以有效减少不同corner/mode之间的影响。

在使用了DMSA之后，以前的纯手动PT timing ECO已经可以做到半自动化的水平了，再也不用同时开多个MCMM会话，相互之间手动传递脚本啦。

传统ECO都是logical的，PT基于我们的设定会产生如下类型的命令供APR工具使用

size_cell

remove_buffer

add_buffer

create_cell

在真实的物理班图中，这些命令都会带来物理版图潜在的cell displacement：

size_up_cell：cell的面积面变大，有可能会产生none-legalize的状态，或者和相邻的cell产生overlap，工具在做ECO实现的时候会优先解决cell的none-legalize和overlap，这势必会引起cell的displacement

add_buffer：任何新插入的buffer都需要合法化（legalize），工具默认会把新创建的cell放在命令里边指定相关net的input pin上，如果是多个负载的情况，工具会把这个新创建的cell放置到output pin的附近。新插入的buffer一定是没有合法化的，所以合法化的动作会移动这个新插入的buffer，如果周围cell density紧张紧张的话，也会引起别的cell比较大的displacement

create_cell: 在做一些功能变化（function ECO）的时候，APR工具会使用这个命令来做function ECO，任何新创建的cell都是一个unplaced 的属性，都被工具默认放置到了die的原点坐标，这时候需要特殊的命令来进行处理。

大家可以看到，除过remove_buffer，大部分的timing ECO命令都会导致physical cell的移动，移动的同时一定会带来绕线的变化，通常都是绕线的增长。为了保证数据库的稳定和收敛，在做任何cell 操作的时候，最好的方法就是减少displacement，基于此类需求，PT给出了PECO（Physical-aware ECO）解决方案。简言之就是PT在做timing ECO的同时，考虑到cell的物理位置，

先来理顺一下传统PT ECO的流程和方法，timing 的violation主要分为三类：DRC，setup，hold，除此之外还有一个leakage 优化VT cell的置换，正常的修复流程如下

1： fix DRC

2： fix setup

3: fix hold

4: VT cell swap

这个流程是有道理的，大家可以自行脑补。工具的原则是，任何的修复都不会引起新的问题，譬如在修复DRC的时候，不会产生其他两种类型setup/hold的新问题（默认其他类别的margin都是零，就是其他类型的任何变化都不能被接受），反之亦然。

在传统PT的会话期望下，所有的timing都是朝着收敛的方向发展。但是，如前所述，任何cell的displacement的变化，以及绕线的变化，在实际ECO实现的过程中，都有可能引起新的问题，或者timing收敛的趋势不符合预期，所以这里一定会有结果上的差别，通常上讲PT会话里的时序修复一般都比ECO实现后的结果更为乐观。

所以讲，ECO是一个需要细心和耐心的工作，任何的大动作都是需要避免的，如果出现下面这个信息，求layouter心理阴影面积

对于physical上面来讲，任何不受控制的large displacement都是ECO的敌人，这时候就是PECO上场的时候

PECO好比在原先的PT ECO fix加了一个额外physical aware的过滤器，只有那些physical 变化是在限定范围内的改变才会被PT fix_ECO_timing真正应用。

由于额外的干预项，在PT侧，PECO的修复的效果的结果一定会比传统ECO的方式差一些，但是由于APR实现的稳定性，整体数据库的回退现象大面积减少，从而提高timing ECO 的整体收敛速度。

为了支持physical aware，使用PECO的时候，需要以下文件来支持物理信息文件的导入。

UPF：对low-power的支持

LEF：工艺库的物理信息 （Library Exchange File ）

DEF: 设计库的物理信息 （Design Exchange File） ：所有的leaf-cell 的物理位置和绕线的信息

Voltage_area： VA的物理信息：PT可以判定VA的区域来进行add_buffer_on_route的操作。

Std-cell spacing file: std-cell 的spacing rule的约束,在某些高级工艺里边，mixVT的cell是不能abut的，所以需要这个文件来限制cell 之间的间距

基于这样的版图信息，PECO有三类的physical aware工作模式：

第一种： open-site模式， PECO只在可以放置的空区域，进行cell的size_up和增添，目标是不产生任何其他cell的displacement，新插入的cell和size_up的动作，都会同时代入被操作cell的物理位置信息，不需要单独跑legalize的命令，就可以达到std-cell合法化放置的目的。

如上高亮所示，这些变动到的cell在结束的时候都会有一个set_cell_location的动作， 这个cell在经历了这个动作后，就是legalize的了，同时也不会带来新的overlap或者placement rule 的违例，这就是看不到displacement的原因了。

细心的同学可以注意到，这里的add_buffer是on_route模式，在ECO阶段，这个命令很常用，可以最小限度减少routing上的改动，同时可以有效地修复max_tran/SI的问题。由于绕线都是physical相关的，这个命令只会出现在PECO模式下。

第二种：occupy模式：PECO允许add_buffer或者size_up的placment和现有数据库的std-cell有交叠，这样可能会带来一定程度上的displacement影响，这种优化在局部利用率比较高的地方，是很有用的，舍弃一部分displacement的代价来换取timing的提高。

第三种是：none physical模式：PECO在不考虑physical信息的情况下来做timing ECO，这就等价于传统的ECO方式。

如果只是用open_site的方式来使用PECO，那么一定可以得到physical/timing同步收敛的数据库，但是在大多数情况下，仅仅open_site是不足够的，所以推荐使用下面的PECO流程来逐步收敛timing。

下边的示例罗列出ECO和PECO 对同一条violation修复时，生成脚本的区别

可以看到，在这个例子里边，两个模式下修复的方法是一样的，但是在open_site模式下，工具会吐出来一些cell placement的命令，这样在icc2的实现时，这些cell都是可以被直接放置好的，PECO就是通过这样的方式减少timing ECO对physical 的影响，来加快timing收敛的速度的。

是不是已经感觉到PECO的强大了，但是由于各种physical状态的各种复杂情况的存在，目前的PECO还是有一下限制的，fix_eco_timing会在结尾的地方罗列出来一些unfixable的原因，下列原因都是在引入PECO后有可能会出现的一类，需要用户在使用的时候多加注意

除此之外，PECO只是可以规划出cell 的放置，但是放置后的绕线问题还是需要APR工具来解决的。重绕线的问题PECO是不能全部考量的，出现DRC/Short是有可能的。

总体上讲，PECO是可以保证整个数据库收敛的速度和稳定性的，上述的一些限制也是可以忍受的，毕竟如果使用传统ECO方式，这类问题可能会在layout实现时候暴露出来，PECO的策略是不引入新的问题，至少也是维持现状，下表罗列两种ECO方式的区别：

在实际的工作中，PECO确实可以加速ECO的工作，并且保证physical的稳定性，尤其是在ECO的初期，芯片上相对的空闲区域比较富余，这个时候基本上可以使用open_site的方式做到全自动的ECO迭代，对于艾思这种比较懒的工程师，这样是再流畅不过了！

如果你有对PECO更多的想法和疑问，欢迎扫描下面的微信，一起进群讨论吧。

猛戳下图关注公众号，获取等多后端知识