版图ECO的那点事(中)

[复制链接]
查看981 | 回复0 | 2020-11-20 16:16:19 | 显示全部楼层 |阅读模式
本帖最后由 Gaohanqing 于 2020-11-20 16:18 编辑

      令人又爱又恨的ECO,它又回来了。
      ECO版图实现的技巧和经验
      在实际的ECO中,版图的实现是非常重要的步骤。是否能完成STA的脚本期望,是数据库能否走向收敛的关键点。一般的STA对应的ECO和相应的修复方法如下:
类别问题描述修复手段实现方法
max_transition
max_capacitance
驱动不够
负载过大
input cap过大
绕线过长
增加驱动
打短绕线
负载分割
size_cell
add_buffer_on_route
split_fanout
setup violation数据侧延迟过大
捕捉侧时钟过早
发射级时钟过晚
做快数据
做慢捕捉侧时钟
做快发射级时钟
size_cell
insert_buffer
add_buffer_on_route
hold violation数据侧延迟过小
捕捉侧时钟过晚
发射级时钟过早
做慢数据
做快捕捉侧时钟
做慢发射级时钟
size_cell
insert_buffer
add_buffer_on_route
            可以看到,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的原地不动。这里附带完整脚本流程图如下:
      

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则