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更多的想法和疑问,欢迎扫描下面的微信,一起进群讨论吧。

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180718G14LDE00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券