IC科普文:ECO的那些事儿
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了IC科普文:ECO的那些事儿相关的知识,希望对你有一定的参考价值。
很多童鞋应该听过ECO这个名词,今天我们就讲讲这个。
我记得,自己刚工作没多久,大我两届的师兄就告诉我:没有修过ECO的人生是不完整的。结果没过多久我就人生完整了,并且半年修了比他三年修过还多的ECO。当然了,这里有吹牛逼的嫌疑,我也不避讳。作为工程师,你或许看过协议,写过算法,做过验证,跑过仿真,撸过FPGA。但是假如你把所有的bug都kill在了摇篮里,一路顺风顺水就tapeout了,未免有点过于顺利了,人生就缺乏了些啥。
就像王思聪或许会想假如我没那么有钱会怎么样(他真会这么想?),作为工程师,你或许会想,假如在最后阶段,发现bug怎么办?
这就是ECO要干的事情:在后期修正你的bug,弥补你的罪。
讲到这里,我们需要简单介绍下IC设计的flow:
首先老大+牛人们在小黑屋开会,讨论大体架构,定下spec,然后前端工程师吭哧吭哧写代码。写完代码开始搞验证仿真。等到大家仿真验证差不多的时候,几乎不再能抓到什么新bug了,就会进入RTL freeze阶段。
RTL freeze就是说,从今天起,大家谁也不能再修改RTL了。
RTL freeze是一个分水岭。在freeze之前,你仿真也好,看代码也好,FPGA验证也好,发现的任何bug,都可以通过修改RTL的方式进行直接更正。但是freeze之后,被freeze的RTL将会进行综合,STA,然后送给后端人员,做floor plan,电源综合,时钟综合,布局布线等等。这些后端流程都是极其耗时的,而且通常不可逆的,就是说,你让我再做一遍,结果就不能保证了。
那么问题来了,假如说,我在某一天发现了一个bug,我向老大提出要求修改RTL,这个时候后端同事flow已经完成了综合,floor plan和布局,走到布线阶段了。你总不能说我把RTL改了,然后重新综合一遍,让后端的同事再重新从floor plan做起?小心有刀飞过来。
假如运气不好,明天就tapeout了,难道你还要去改RTL,哪有时间让你再做一遍后端的全flow?
运气再差点,已经tapeout了,工艺厂刚刚启动生产线,做完了第一块掩模板的光刻,你跟他们说:停!我还有个bug!要从RTL重新做?
你当然不可能重新从RTL做起,因为时间耽误不起。后端好不容易做收敛的成果也浪费不起。
幸运的是,上面的情况你都可以用ECO搞定。从freeze到tapeout之间的ECO叫pre MASK的ECO;tapeout之后,已经加工完芯片的晶体管,但是还没有做晶体管连线期间的ECO叫做post MASK的ECO。
所谓ECO,简单讲就是直接修改netlist。
简单的例子:
下图是综合之后的一小部分的电路图:
写成RTL就是: D = A & B;
假如说,我发现这段代码有bug,我需要改成: D = (A & B) | E;
怎么办呢?你需要做的是在netlist中加入一个或门,然后将上图中的C端与E端作为或门的输入。新的电路图如下:
怎么实现这种转变呢?
后端工具有专门的CMD支持,你可以采用这种CMD写个脚本,大致内容如下:
addcell AND;
connect C to AND.A1 port;
connect E to AND.A2 port;
connect AND.Z port to D;
当然,这只是个示意,实际的CMD形式不是这样的,但是思想是一样的。
以上这种搞法仅仅适用于pre MASK的ECO,在这个ECO阶段,你可以往设计里面添加各种cell。这样既修复了bug,又不需要重新综合,避免了后端的各阶段成果被破坏掉。比如综合的电源网络,时钟树,以及布局规划都没有被破坏。如果你修改RTL,那么必须重新做综合,然后再从floor plan开始......
到了post MASK阶段,ECO就变得更加艰难些。因为这个时候,芯片已经tapeout,工艺厂已经开始加工基底层了(base层,也就是晶体管层),所以这个时候,没有办法再往设计里面添加cell,比如与门,非门,寄存器等等。但是因为这个时候,芯片的互连线(wire层)还没有加工,所以,你可以改变晶体管的互连线。
但是你并不是没有cell可以用,实际的芯片在tapeout时候,都会在chip中撒很多多余的cell(redundant cell),这些cell分散在各处,用来给post MASK ECO使的。像下图中,红色的点就是四散分布的多余的cell,它们可以是MUX,与非门,或非门,buffer,寄存器等等:
同样是之前提到的那段ECO,在post MASK阶段,假如你能在这些多余的cell里面找到一个或门,然后将C和E的连线改变一下,接到这个或门上,再把或门的输出接到寄存器的D端,就可以解决这个bug。假如运气不好,找不到或门,或许你就得想别的方法,比如找到一个或非门和非门,然后串联起来做一个或门。
当然了,到了这个阶段,因为所有cell的位置和类型都已经固定了,所以连线长短也无法改变,cell大小也不由你挑,很有可能你虽然修完了bug,但是用STA check会发现timing 无法满足。但是已经没辙了,只能死马当活马医了,乞求这条path是false path或者multicycle吧。
修完ECO,怎么确定有没有修正确呢?这就涉及到形式验证。
前端人员,写完ECO CMD之后,利用ECO命令修改旧netlist,得到新的netlist,然后将这个netlist与修改过后的RTL做对比,确定二者功能一样,就叫做形式验证。如下图:
形式验证有专门的EDA工具来做,既可以用来比较两个RTL功能是否一样,也可以比较RTL的功能与综合之后的netlist功能是否一样,还可以比较两个netlist功能是否一样。这里我们不做深入讲解。
需要明白的是,前端工程师既要修改netlist,也要修改RTL,然后将两者进行对比,确定功能一致。这样才能保证ECO命令完成了你想要的功能。
欢迎大家关注我的微信公众号:半导学社。
以上是关于IC科普文:ECO的那些事儿的主要内容,如果未能解决你的问题,请参考以下文章