首页 > 其他分享 > 芯片设计中的ECO是什么? ------ 转载

芯片设计中的ECO是什么? ------ 转载

时间:2023-08-24 19:23:56浏览次数:43  
标签:修改 ECO tapeout mask cell 芯片 ------ 设计

本文转载自: 芯片设计中的ECO是什么?-腾讯云开发者社区-腾讯云 (tencent.com)

 

如标题所写,我们今天聊一聊IC设计种的ECO。在展开关于ECO的概念之前,我们先大致捋下数字IC设计的流程,有助于我们后面的讨论。

数字IC设计流程简述

1、确定项目需求

根据市场或者芯片功能要求,设计芯片的spec,得到可行的芯片设计方案。

2、系统级设计

用系统建模语言对各模块进行描述

3、前端设计

RTL设计、功能仿真、硬件原型验证、电路综合、DFT、STA

4、后端设计

版图设计、物理验证、后仿真

在复杂的设计流程中,bug是难以避免的。对于芯片设计而言,bug自然是越早发现越好。但是仿真验证差不多,进入RTL freeze阶段后,一旦发现新的bug,就变得有些麻烦。

因为RTL freeze前,你可以通过修改RTL来更正你发现的bug。然而RTL freeze之后,后端人员做好了floorplan,或者已经开始布局布线,这个时候再去重新做一遍,既耗时耗力,又会惹怒后端。这显然不是好的选择。

如果这个时候即将tapeout,甚至已经tapeout,根本就没有机会修改RTL了。

这个时候,我们就需要ECO,来修正我们的失误了。

什么是ECO?

ECO,即Engineering Change Order的缩写,指工程改变命令。

什么意思呢?简单来说就是手动修改集成电路的过程,换句话说,就是直接手动修改netlist。

一般应用于数字芯片版图设计。

对于数字IC设计而言,ECO这一步实际上是正常设计流程的一个例外。它是对设计的layout进行局部的小范围的修改和重新布线,而不影响到设计的其它部分的布局布线,所以其它部分的时序信息没有改变。

根据功能的不同,ECO可以分为功能改变和非功能改变。功能改变是指由于来自客户对设计的追加需求(spec改变)或者设计的最后阶段发现芯片存在 bug 的情况下进行的 ECO;而非功能改变则是为了在不改变 RTL 网表的基础上修复部分时序以及串扰等问题而做的 ECO。

说到底,ECO的目的就是省钱省时间。

那么在不同阶段,进行ECO,有什么样的区别呢?

在阶段上,数字IC设计中的ECO大体可以分为:tapeout前的ECO,tapeout过程的ECO,tapeout后的ECO。

Tapeout前的ECO

在RTL freeze后,tapeout前这一阶段,RTL已经没法修改,但是好歹也没有进入tapeout,还有补救的机会。

此时数字前端负责写coding的工程师需要在final RTL的基础上,通过写ECO脚本的方式来实现功能上的ECO。

ECO代价:时间成本,相对较小

Tapeout过程中的ECO

当数字后端实现后的design,timing已经符合signoff标准,DRC已经clean,LVS已经pass,IR drop,MVRC,Formality,DRCPLUS等都已经pass。

但是,数字前端设计工程师还没来得及做完大部分case的后仿,而且芯片又面临着Timing-TO-Market的压力。此时,进入tapeout阶段。

为什么不给自己留更多余地呢?因为foundary会先做base layer的加工。只要后期仿真发现的问题,不需要再添加额外的cell,就不耽误之前的tapeout(此处有点像流水线)。即使发现需要新加几个cell,这个时候仍然可以通过替换后端实现过程中所加的ECO cell或者spare cell来实现。

ECO代价:时间成本较大

Tapeout后的ECO

当芯片已经tapeout回来,我们在测试过程中却发现了必须修复的bug。这个时候做ECO的代价相对前面两种,就要大很多。

改动少的可能仅需要改几层Metal layer,改动大的话可能需要动十几层Metal layer,甚至重新流片。在此阶段,前端设计工程师需要出具ECO方案,同时让后端工程师进行评估,主要评估需要改动的层数,timing 是否能快速收敛等方面的风险。

在一次次确认后,敲定方案,进行ECO。

ECO代价:时间与金钱成本巨大

由此可见,即使ECO能够亡羊补牢,但是为了节省更多的时间和金钱成本,还是尽早发现问题,尽早解决吧。

关于ECO的分类:

常见的ECO可以分为pre mask ECOpost mask ECO,也就是任何layer都可以动到的ECO和只修改metal layer的ECO。

两者的区别在于,pre mask ECO的晶体管和布线层都还没有开始做出mask,此时可以往netlist里面添加cell。而post mask ECO的晶体管层已经开始进行加工了,但是布线层还没有加工,还能修改,可以通过ECO改变各种已有cell的连线关系,但是不能添加新的cell,有一定局限。

换句话说,从freeze到tapeout之间的ECO叫pre mask ECO;tapeout之后,已经加工完芯片的晶体管,但是还没有做晶体管连线期间的ECO叫做post mask ECO。

Pre mask ECO:

Pre mask ECO比Post mask ECO要灵活得多。在tapeout之前,如果发现有任何需要修改的地方,都可以用这种方法。它可以改成百上千个单元。该操作主要是针对静态时序分析和后仿真中出现的问题,对电路的网表直接进行修改,待网表修改完毕之后反馈到PR工具中对标准单元的布局和连线进行小范围的改动。当然,直接对网表进行修改是存在风险的,所以之后一定要进行形式验证(formal verification),确保功能实现。

Post mask ECO:

Post mask ECO是利用预先留好的备用单元(Spare Cell),做的逻辑修改。如果后期发现Timing存在问题(或者想小动Function),可以利用附近的Spare Cell搭配上层金属连线来修改电路结构。比起Pre mask ECO,这种ECO受限于Spare Cell的位置,所以它的修改规模十分有限。

Spare Cell:

Foundry提供一种服务,允许客户在wafer加工到poly以及M1层的时候,让大部分wafer暂时停止加工,而少量wafer继续加工直至完成。之后可以对这些完成了的wafer上的die进行测试,如果发现存在功能或者时序上的问题,那么可以通过利用那些预布在die上的spare cell来解决。

由于绝大部分的金属层都没有加工,因此在不修改标准单元布局的情况下,只用改动几层金属的mask并利用spare cell去修复这些问题。如此一来,也大大降低了流片的风险。而Post mask ECO则提供了一种根据silicon测试结果进行Debug的方法。

Post mask ECO 可行的前提是设计里有足够的可供新功能实现的cell, 如Spare cell, Freed cell, GA cell。

Freed cell,这些cell原本服务于原始的逻辑功能,但是因为逻辑功能更改,被释放出来,既然已被释放故可以用于来实现新的功能。GA cell,是内部晶体管没有链接的cell,是可以被“编程”的cell,在做ECO 时,通常用最底层金属如M1 将GA cell 内部的晶体管链接起来,以实现对应的逻辑功能,如:与或非、选择器、寄存器等。

而Post mask ECO的修复则受制于这些cell的位置,可以说是不太灵活了。

从逻辑和物理来看,ECO又可以分为Logic ECO和Physical ECO。Logic ECO是对网表的逻辑功能的修改。在芯片设计的后期阶段,前端工程师可能会发现设计上的某些bug,进而需要对电路做修改,而此时的schedule已经不允许进行重新综合,因此会选择在PR的网表上进行逻辑修改,一般情况是会增加一些逻辑或者将某些逻辑的net重新连接;而Physical ECO主要是针对PR工具无法完全修复的问题进行手动修正。一般包括Timing ECO,drc fix等。

ECO的实际运用与技巧

对于版图工程师来说,经常会碰到一些function ECO的需求:

从上图可以看到,为了保证数据库有优先级的收敛,最后的timing ECO会分为几个主要步骤

·功能模式的时序修复:function mode

·存储器自测模式的时序修复:mbist mode

·其他测试模式的时序修复:test mode

·芯片接口时序修复:IO mode

功能模式的重要性、工作量和难度都是最大的,需要尽早修复,然后是其他的模式。整个流程基本上是按照步骤和优先级完成整个芯片的时序修复的。

改变功能的ECO被称之为function ECO,但是实际上,这种ECO可能是针对真正的function mode的,也有可能是针对mbist 逻辑的,或者有可能是针对at-speed test mode的。

由于function ECO会引起潜在的timing arc的变化,因此带入function ECO的时间点是有讲究的。一般来讲,只会在一种模式的timing修复告一段落的时候,才会带入这个模式的function ECO。

假如在时间节点Pre-B,前端准备好了一个比较大的function ECO,这个ECO是给mbist服务的。通常需要先验证这个脚本的正确性,如果脚本本身没问题,在这个Pre-B的时候并不带入,因为这个时候整个mbist的时序还不够稳定。

等到了Pre-C的时间节点,mbist的时序修复基本完成的阶段,这时可以代入这个ECO。理论上讲,新出来的timing violation都是由于这个脚本引起的。

增量设计工作模式,是ECO阶段的重重之重,任何违背增量设计方案的举动,都会造成局部损耗,甚至更糟的结果。

功能ECO的脚本生成的探究和技巧

后端一般会在最终layout的节点,给前端分享最终layout版本的网表。一般为了阅读方便,后端都是给前端一个不带PG信息的netlist。前端同学在完善数据库的过程中,同时也会对各种问题进行评估,最终给出解决方案:

·软件改动

·约束用户行为

·硬件改动

如果有任何需要在硬件方面做的功能修改,前端会先保证RTL修改、验证完成后,对相应的final layout的网表进行修改。

综上所述,一个function ECO的诞生过程大抵如下:

前端主要关注功能,后端主要关注实现,对于下面的几个主题的关注度,这里展示一下:

前端基于final layout的网表,改出来一版带function ECO的功能网表,这个流程基本就算大功告成了。

ECO版图实现的技巧和经验

在ECO中,版图的实现是非常重要的步骤。是否能完成STA的脚本期望,是数据库能否走向收敛的关键点。一般的STA对应的ECO和相应的修复方法如下:

ECO的物理实现就是两种情形

·size_cell

·add buffer

这里边最会产生的影响其实是面积器件的位置变动(dis-placement)

器件的位置变动带来的影响都可能导致ECO无法如期进行,因为原有数据库的cell的放置被调整,之前的绕线需要做相应的调整,同时带来更多的timing/驱动能力的问题,这样就会给数据库带来不期望的抖动。

为了尽可能保证原有数据库的状态,这里引入一个新名词:Minimal Physical Impact Flow(MPI)。

较小的dis-placement带来更为稳定的版图数据,绕线的挑战也比较小,这是MPI的核心思想。

ECO收尾阶段的风险和注意点

在ECO收尾阶段,所有决策和行动都需要慎重,否则出了问题就叫苦不迭了。

先说结论,兼顾metal fill,MCMM以及VT cell的灵活使用,是ECO后期成功收敛的关键要素。

MCMM,全称为:multi_corner和multi_mode。

multi_corner(PVT):process/voltage/tmperature。

multi_mode:function/scan_shift/scan_capture。

看到它的全称,想必你就明白它的重要性了。

至于metal fill,先进工艺是需要fill的支持,来保证流片的物理需求,fill是基于绕线和布局的,如果绕线或者布局改变了,就需要重新跑fill。所以在先进工艺,一定不能忽略fill对timing的影响,tapeout之前,一定要保证fill的信息完全和真实的数据库匹配,这样跑出来的timing才完整可信。

ECO的时序信息通常是增量示的,除非你改变了绕线。这是需要在ECO后期阶段牢记的一点。

对于一个数据库,经常会遇到在接近TO的ECO的迭代中,会冒出一些和修复timing没有关系的微小的setup/hold violation。这个大多是由于绕线的细微改变,而导致的时序变化。这个时候,VT cell就会派上用场。

时间是TO前最值钱的,使用VT cell进行ECO,最大的方便时省略了ECO 绕线、寄生参数的抽取和STA的re-run。这三个步骤的时间是非常长的。有了VT cell的帮忙,这些时间统统可以省略。

经历了这么一系列流程与注意事项,我们终于可以完成ECO,确保tapeout顺利,获得一块good chip。

标签:修改,ECO,tapeout,mask,cell,芯片,------,设计
From: https://www.cnblogs.com/hxing/p/17654967.html

相关文章

  • buildroot 构建根文件系统
    一、开发背景原开发板的文件系统拥有很大的冗余文件,需要裁剪文件系统或者根据需要定制文件系统二、开发需求1、构造最小系统,支持基本指令,例如cd、ls、tar等基础指令三、开发环境LinuxUbuntu 4.15.0-65-generic+ buildroot-2023.02.3+i.mx6d(cortex-A9)......
  • 切换Mac后maven项目无法启动报错
    `/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/bin/java-agentlib:jdwp=transport=dt_socket,address=127.0.0.1:53666,suspend=y,server=n-XX:TieredStopAtLevel=1-noverify-Dspring.output.ansi.enabled=always-Dcom.sun.management.jmxremote-Dspri......
  • 建立保持时间及违例解决方法 ------ 转载
    转载自: 建立保持时间及违例解决方法-知乎(zhihu.com) 建立保持时间概念为什么要有建立保持时间?参考:为什么会有建立时间(setuptime)和保持时间(holdtime)要求-知乎(zhihu.com)答:简单来说,DFF可以由两个latch构成,每个latch是通过传输门组成的mux组成。如果不满足建......
  • Ubuntu22.04(禁用)彻底删除Snap以及出现“rm: 无法删除"XXX":只读文件系统”的解决方案
    Ubuntu22.04(禁用)彻底删除Snap以及出现”rm:无法删除"XXX":只读文件系统“的解决方案导语Snaps是Ubuntu的母公司Canonical于2016年4月发布Ubuntu16.04LTS(LongTermSupport,长期支持版)时引入的一种容器化的软件包格式。自Ubuntu16.04LTS起,Ubuntu操作系......
  • C++对象的创建和销毁过程分析
    对象的创建和销毁过程分析1、对象的创建过程①给对象划分内存空间(栈、堆)②执行初始化列表根据继承表的顺序调用父类的无参构造或有参构造通过:父类(val)调用父类的有参构造根据成员变量的定义顺序调用类类型成员的无参构造或有参构造通过:类类型成员名(val)调用类类型成员......
  • lvgl:对象obj
    1对象object  1.1对象lv_obj_t     对象object:构建用户界面的基本单位,也称之为控件widgets;对于button,label,image,list等组件都可称之为对象;//lv_obj.h对象结构体;typedefstruct_lv_obj_t{constlv_obj_class_t*class_p;struct_lv_obj_t*parent;......
  • 认识微服务-微服务技术对比
       ......
  • C++面向对象、类和对象、访问控制限定符
    面向对象和面向过程面向过程:关注如何解决问题,以及解决问题的步骤面向对象:关注的解决问题的"人"即"对象",以及实现能解决问题的"对象"注意:面向对象的细节的本质上还是面向过程,因此面向对象不是解决问题的捷径,而是以更高的维度去思考问题面向对象的四个特性:抽象:先找出(想象)......
  • 认识微服务-SpringCloud
        ......
  • Qt模仿多标签页窗口拖拽操作
    本功能的实现主要依托于Qt的拖拽操作。从本文可以学到Qt的拖拽机制,自定义QMimeData的数据类型,和自定义的QGraphicsEffect效果。本文的视觉特效是应用于拖拽的时候指示当前鼠标的位置和拖拽结果新标签页会放置在当前窗口的第几个标签页之后。以下是窗口的效果图片,为了方便标签是用......