时序（Timing）对功能ECO有多重要

功能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网表进行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时间，加速了芯片交付客户的进度。