INVS利用gatearray实现post-mask的function ECO

最新推荐文章于 2025-03-18 21:25:57 发布

原创最新推荐文章于 2025-03-18 21:25:57 发布 · 1.3k 阅读

17 ·

CC 4.0 BY-SA版权

文章标签：

#innovus #postmask #ECO

随着现代IC的设计发展，设计的规模和复杂度逐步增加，对于验证完备性的挑战越来越大，加之TO的时间压力，芯片设计通常会出现下列的场景：

芯片回片一次点亮
大部分的case都可以顺利通过
小部分的功能需要修正

对于重要的特性三，用户可以选择gatearray的cell高效的完成这一个任务。闲言少叙，ICer GO！

由于·硬件设计天然的特性，大部分芯片都会有reversion的计划，有时候也被称作engineering sample# （ES1，ES2，etc.）。产品的迭代效率通常都是reversion的重要因素，所以基于TO数据的bug高效修复（迭代快，成本可控）的要求就显得极为重要。

TO数据space cell方式

基于前端设计经验，在芯片里边规律性的撒一些spare cell，作为后续版本的bug修复使用，但是这种方法局限性比较大：

Spare cell的难以匹配设计修改的要求：
- 功能不全：对于bug，通常都具有未知性，很难做到有的放矢，spare cell的功能经常被bug fix人员诟病功能不完备
- 距离不合适：bug修复需求的物理位置和spare cell的位置相去甚远，
  - 绕线挑战大，可能会占用很多的metal 资源，导致postmask metal fix的mask费用很高，周期很长
  - 时序挑战：太远的距离，导致transiton/cap都有新的变化，甚至需要使用更多的器件实现setup/hold的修复，都是潜在的时序挑战
Spare cell对资源的浪费
- 放置资源：spare cell会切实的占用std-cell的某些区域，为保证分布性，spare cell通常位置较为固定，这个对于APR flow的数据优化会产生一定程度上的不利影响
- 绕线资源：spare cell的input 都需要tie connection（防止栅极浮空被击穿），这些tie connection也是对绕线资源的消耗。

所以，实际芯片的funciton bug ECO的时候，眼睁睁的看着分布式的spare cell，就是用不起来，只能干瞪眼。心里默念，要是当时在某某区域多撒点某某cell该多好啊。像极了学生时代拿到成绩的我们：要是考前把那个啥多看看，这部又能提高几分。永远的如果，永远的下一次，反反复复无穷尽啊！

gatearray方式的特点和用法

为了缓解这种问题，现在的std-cell开发商，在提供标准的std-cell库的基础上，也会提供给用户用于post-mask的ECO 库，由于设计结构的原因，这个库通常被称为：std-cell gatearray 库。是一种类似乐高积木的拼接方式来完成std-cell的构建。

ECO 库的特点

基于gatearray设计的ECO库，所有的cell的版图，都是使用基础单元搭建起来的（gate），然后通过更改metal的方式来实现不同的功能，这个·和传统的std-cell的设计思路是完全不同的。

只要是等宽的ECO cell，cell之间通常只有一层或两层metal不同，意即：只改动metal就可以实现功能变化。譬如下例：等宽度的ECO filler cell 和FILLER cell的GDS比对XOR：

可以看到：ECO filler cell和ECO function cell只有M1不相等（baselayer 是完全一样的），具体XOR区别见下图：

这样就可以通过嗲用芯片里边现有的ECO filler cell，基于用户需求，改变有限的metal层，从而实现任意功能的转化，

ECO filler -> ECO function cell
ECO function cell -> ECO filler

ECO 库的postmask bug fix 的应用流程

postmask的改版，最麻烦的当属功能修正，如果想更换一个cell的功能，通常要动到baselayer和metallayer。但是基于gatearray的ECO库，则可以有效规避baselayer的改动，从而可以高效的完成postmask function bug fix。

ECO lib VS. std-cell LIB

在使用ECO库之前，先看一下ECO cell和普通std-cell的版图区别

在原本的std-cell和ECO库中挑选相同功能/驱动力的cell

INVX2
GAINVX2

版图差异

通过XOR，可以看到，这两个cell的画法是不太相同的

包括有源区，POLY区个connect去都不太一样（PS: cell boundary 是一样的）。基本可以判定，这样的cell就是不同设计需求的产物

时序差异

从lib上看，两者的面积是一样的，这个case的时序也是基本类似的：

ECO库的cell特点

为了有效的利用ECO库，通常都会提供各种功能的器件，同时为了降低ECO库的设计难度，通常会弱化对驱动力不要求。以当前case为例，相较std-cell 库，ECO拥有了常规的与或非门，FF等，驱动力有所限制：

Function	ECO lib驱动力	Std-cell lib 驱动力
AND	X1/X2	X1/X2/X3/X4/X6/X8
AND_into_OR	X1	X1/X2/X3
DELAY	X1/X2	X1
MUX	X1/X2	X1/X2/X3/X4/X6/X8/X12
NAND	X1/X2/X3	X1/X2/X3/X4/X6/X8
NOR	X1/X2	X1/X2/X3/X4/X6/X8
OR	X1/X2	X1/X2/X3/X4/X6/X8
XNR	X1/X2	X1/X2/X3/X4/X6/X8
XOR	X1/X2	X1/X2/X3/X4/X6/X8
INV	X1/X2/X3/X4/X8	X1/X2/X3/X4/X6/X8/X12/X16/X20
BUFFER	X1/X2/X3/X4/X8	X1/X2/X3/X4/X6/X8/X12/X16/X20
DFF	X1/X2	X1/X2/X4

ECO库的使用方法

为了方便GA（gatearray）进行功能替换，ECO 库将所有的cell分成两类：

FILLER
Function cell

由于所有的cell的base-layer都是一样的，那么这里可以利用这个特性实现postmask的function metal fix方法。

数据准备：

在TO的数据库上使用ECO FILLER进行填充。
在ECO FILLER不能覆盖的区域，使用common filler进行填充，确保NWELL的连续

功能修复

基于芯片测试结果，出具bug fix方案
使用ECO function cell构建相关ECO的脚本

ECO cell 置换

在具有ECO FILLER填充的数据库中带入上述ECO脚本
使用ecoPlace方法，完成对与ECO function cell的器件替换

INVS会使用满足ECO function cell宽度的ECO filler区域，完成这个替换

版层变动验证

导出GDS，使用GDS XOR工具，确保bug fix后的GDS和原始GDS只有metal layer的差异

完成绕线：在APR工具里边完成绕线
对数据和进行timing、LV和power的签收验证
使用最终的数据库再次和原始TO的GDS进行XOR比对：出具版层变动的差异信息。触发新的TO

对于上述流程有以下几点需要注意：

设计人员需要使用ECO lib里的function cell进行bug fix
ecoPlace的动作比较关键，用户需要仔细查验这个动作的日志和数据库。步骤如下：
- 删除现有所有的ECO filler
- 将ECO function cell放置到相连接cell的附近
- 恢复之前ECO filler的位置，在改动的区域，对于ECO filler cell做出做适当调整