通常的后端流程里边，在流片的前几周，一定会有一段相当忙碌的时间，这段时间就是我们所说的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。 

时序timing上的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)?）了解：

 

网站链接

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在PECO的过程中，通过必要的手段来降低甚至避免cell的displacement。在理想化的状态，如果每次的PECO修复，都不会引起cell的placement，新创建的cell或者size_up的操作都是有合适放置空间的，那么理论上完全可以做到全自动化流程：PT.PECO –> APR -> PT.PECO，是不是感觉到工作一下就没难度啦？别着急，PECO可以加速ECO进程，但是做到完美取代工程师还尚需时日，PECO到底怎么用？又有哪些优缺点，下面我们一一道来：

先来理顺一下传统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。

引用：

http://www.52-ic.com/1402.html