ECO中文翻译就是工程变更（Engineering Change Order） > `ECO，简单讲就是直接修改netlist。` 因为design中写的算法难免有bug，后仿用的case 无法覆盖100%的应用场景，以及实现过程中犯了某些错误等。 大体上数字IC设计中的ECO可以分为Tapeout前的ECO，Tapeout过程的ECO，Tapeout后的ECO。 ## Tapeout前的ECO 很多公司（特别是大公司），他们一般都有规定哪个阶段必须RTL freeze，这个时候不会也不允许再更新新的RTL，即使后面仿真验证有bug。为什么不让更新RTL呢？因为此时数字后端工程师可能都做好布局布线，timing也没什么大问题了，都准备开始修timing了。如果此时release新的RTL，那就意味着需要重新跑整个flow，从综合到PR，再到fixing timing。一方面会严重影响整个项目的Tapeout时间，从而影响Wafer out和芯片上市的时间。另外一方面，数字后端工程师可能有想骂人的冲动。 因此，此时数字前端负责写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吧（就是开始传GDSII给Foundary厂）。为什么敢这么做呢？是在赌博吗，呵呵。其实肯定有赌博的成分，但是更多的还是自信（认为不会出大问题）。因为，前一周左右foundary会 先做base layer的加工。只要后期仿真发现的问题，不需要再添加额外的cell，就不耽误之前的Tapeout（此处有点像流水线）。即使发现需要新加几个cell，这个时候仍然可以通过替换后端实现过程中所加的ECO cell或者spare cell来实现。（如何预先加ECO CELL和spare cell ，后续会专门讨论） EEO代价：时间成本较大 ## Tapeout后的ECO 当芯片已经回来，在测试过程中发现的bug，然后又必须fix掉的bug（无法通过软件绕过去或者代价太高）。这个时候需要通过ECO来解决。这个时候做ECO的代价相对前面两种大很多，都是要消耗很多的真金白银，而且有芯片量产的巨大压力。改动少的可能就改几层Metal layer，多的可能就需要动十几层Metal layer，甚至重新流片。做ECO之前，老板肯定会让数字前端设计工程师出ECO方案，同时让后端工程师进行评估，主要评估需要改动的层数，timing 是否能快速收敛等方面的风险。 ECO代价：时间成本+money 较大 下面小编稍微总结下数字IC设计中做ECO的主要步骤（数字后端工程师必须熟练掌握以下几点工作，第一点除外）： 数字前端工程师制定ECO方案（验证方案有效性，可行性） 写 ECO 脚本 后端工程师根据ECO脚本，进行摆放cell和连线（手工或自动的方式） 形式验证（确保后端进行变更后的功能和前端ECO方案功能一致性） 确认基于Tapeout 版本的GDSII所有改动的层（通过calibre 跑Layout Versus Layout） 重新做dummy insertion或者人工改dummy 再次进行timing signoff（Fixing all setup,hold,timing drc,etc） 再次跑DRC&LVS并fix violations Release 新的GDSII