时序(Timing)对功能ECO有多重要

电子说

1.3w人已加入

描述

功能ECO与时序ECO的关系

功能ECO主要指当RTL更新后对后端APR网表做的功能方面的改动。功能ECO可以由手工或者自动化工具完成,得到ECO网表。再由后端布局布线工具(如ICC2、Innovus)读入ECO网表,进行ECO Place和ECO Route。

时序ECO主要指为了解决后端ECO Route时的setup和hold时序违例,可以用后端工具指令、外部工具(本厂或者第三方)、人工替换Cell、优化DRC等方法完成。

ECO

从上图可以看出,功能ECO主要是由前端工程师做,时序ECO主要是由后端工程师做。前端工程师做完一版功能ECO后,需要对ECO网表进行LEC检查,确认ECO网表与新RTL等价,之后再把验证无误的ECO网表交给后端工程师。

后端工程师拿到ECO网表后,到ICC2/Innovus里做后端实现,并解决DRC、时序等问题。在PostMask ECO时,ECO网表的很小的改动都可以可能引起DRC和时序的违例,原因可能是:Cell太远、连线太长、驱动能力不够、绕线拥挤等。遇到时序问题,首先是利用后端工具来优化。小时序问题可以手工或者用Timing ECO工具优化过去,大时序问题就需要前端工程师进行返工。

前端工程师返工时,有哪些办法呢?一是,挑选距离近的sparecell;二是,尽量复用现有stdcell,减少改动的连线的根数;三是,从RTL层面简化修改方案,能不新加DFF就不加,能复用现成的信号就复用现成的信号。四是,与项目经理、产品经理、市场部一起对BUG进行排序,优先解决影响客户使用的BUG,软件绕不过去的BUG,放弃一些次要的BUG。

所以功能ECO常常需要迭代好几次,才能得到一个折中的结果。当然如果必须要解决的BUG太多,或者后端无法实现,那么就只能走Full layer Tapeout,但芯片交付客户也会多晚几个月。现在芯片市场竞争异常激烈,你的产品不行,别人顶上,客户可能就没了。

NanDigits GOF ECO的方案

我们一直在思考如何才能减少功能ECO的迭代次数,让前端工程师在做功能ECO时就能够提早看到时序的影响,并在功能ECO的同时就解决掉时序问题。我们尝试、实践、并成功开发出多个方案。

第一,是前端逻辑层面,自研了LEC(逻辑等价性)算法,利用这个算法能够精准找到新RTL与老APR网表的差异,这会大大缩小ECO的范围。

第二,原创了RTL Patch ECO,在APR网表里写RTL,这种方法可以找到更精准的修改点,弥补了算法在少数案例中表现不佳的情况。

第三,自研了在APR网表中查找RTL等价net的功能。由于综合优化、后端优化,人工在网表中查找rtl等价net是非常麻烦的事情。点一下按钮或者一个命令,GOF ECO就会通过分析网表、两根net做LEC等方式找到等价net。这对手工ECO网表、网表不等价debug等提供了便利。

第四,GOF ECO支持读入DEF/LEF,从中得到每个cell的物理信息。在spare cell映射时考虑这些cell位置信息,挑选出修改点附近更合适的spare cell。当附近没有某个cell时,会做等价变换,用附近的其它cell代替。

第五,GOF ECO实现了spare cell类型的约束,前端工程师可以根据当前spare cell的类型和数量,来指导工具实现更优化的方案。

第六,最新发布的GOF ECO实现了类似PT的report_timing的功能,这样前端工程师在功能ECO的同时就可以评估时序,不需要等后端同事迭代,就能够提前知道当前功能ECO结果在后端实现的难度和风险。也可以同时评估多个ECO方案,择优提供给后端。另外,前端工程师还可以利用GOF API来提前解决一部分时序问题,不需要全部丢给后端。不但减轻了后端的压力,还减少了ECO迭代次数,缩短了ECO时间,加速了芯片交付客户的进度。
 




审核编辑:刘清

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分