版图ECO的那点事（中）
时间：2026-02-01 14:41:55
手机看文章
扫描二维码
随时随地手机看文章
令人又爱又恨的ECO，它又回来了。
在上一讲中，和大家一起讨论地两个关键话题：
- 功能ECO的介入时机
-
eco_netlist的用法和技巧
点击查看上期文章：版图ECO的那点事（上）
ECO版图实现的技巧和经验
在实际的ECO中，版图的实现是非常重要的步骤。是否能完成STA的脚本期望，是数据库能否走向收敛的关键点。一般的STA对应的ECO和相应的修复方法如下：
可以看到，ECO的物理实现就是两种情形
- size_cell
-
add buffer
这里边最会产生的影响其实是面积和器件的位置变动（dis-placement）
通常的版图和ECO流程如下图，在sign-off阶段，理想的是以类似silicon-freeze的方式进行操作
ECO的简明流程如下：
这里的关键节点是在，placement/legalization，任何器件的位置变动带来的意外的影响都有可能导致ECO无法按照期望方向进行，这是因为，原有数据库的cell的放置被调整，之前的绕线需要做相应的调整，同时带来更多的timing/驱动能力的问题，这样就会给数据库带来不期望的抖动。为了尽可能保证原有数据库的状态，这里需要引入一个新名词：Minimal Physical Impact Flow（MPI）：
为了实现MPI的效果，ICC给出了它的一套解决方案。
【敲黑板划重点】
较小的dis-placement带来更为稳定的版图数据，绕线的挑战也比较小，这个是MPI的核心思想下边一起来看一下，如何使用合理的命令和流程来弱化legalization带来的影响：
传统的legalize命令在跑流程的时候，可以很好的进行增量性的legalization，但是到了ECO这里，legalize的动作相对于版图的稳定性而言，就是有点太大了，需要使用place_eco_cells来实现MPI：
从上边这个截图可以看出来，传统的legalize模式，带来的明显的average/max dis-placement，但是place_eco_cell可以非常好的避免这种情况的发生。place_eco_cell可以实现MPI的目标，而且run-time速度也很快，这到底是为什么呢？天底下还有这么既省时又省力的两全其美的好事情？
通常使用的legalize_placement -increment命令，它是一个全局命令，它会在需要legalize的cell就近找寻位置，如果找不到，那么就会push周围的cell，从而在ECO cell就近产生足够的空间，这样会产生明显的涟漪效应，尤其在高利用率的区域。但是place_eco_cell的行为完全不一样，它的操作范围完全是有用户决定的，它的目的就是一个：在规定的范围内，完成目标cell的legalization，如果在规定的区域内（dis-placement threshold）找不到，它就直接放弃，较小的作用范围，带来的就是高速的执行速度。这里有一个test-case，一个全局的的时序修复（size_cell），基于同样的改变，看看两个命令的表现：
-
CMD: legalize_placement -increment
可以看到，这里有30871个cell的位置被改变，ECO的cell其实只有7081个cell。可见大约有23K个cell的移动，是为了来给ECO cell腾挪空间的。 - CMD: place_eco_cell -eco_changed -displacement_threshold 10 -max_displacement_threshold 10
仔细看图片描述，place_eco_cell的作用范围只有10um，目标cell也只有eco_changed的7081个cell，所以runtime极快。
在使用place_eco_cell之后，如何原始数据库的cell并没有被动到，只有ECO_changed cell 被动到，所以有一些没法完成legalize的cell，需要使用legalize_placement -increment 再次调整，保证整个数据库的legalization：
这里可以看到，使用legalize_placement -increment ，moved cell较之前会有所好转。这样通过两步走的手段，可以有效地保证eco_changed的cell的legalization，也能最大限度地完成其他cell的原地不动。这里附带完整脚本流程图如下：
下载文档
