在这种 PPA 推动中，综合到实现的周期是一个关键组成部分。对于芯片设计周期的这一部分，大多数团队使用 Synopsys 数字设计系列，即 Synopsys Design Compiler 或 Synopsys Fusion Compiler 产品。他们通常希望利用所有可用的复杂功能，如retiming、multibit banking、高级data-path优化等，以实现最大的QoR。设计团队努力来满足他们较短的市场窗口，拥有快速、可预测的 SoC 设计周期是核心的竞争优势。
对他们来说，能够快速响应经常的、意料之外的或者最后一刻的RTL功能的改动也至关重要。这时RTL被冻结，而synthesis和place and route处于后期阶段，所以这些更改通常以功能ECO的形式实现。用ECO来修复功能验证错误或添加的关键新功能是非常有必要的。
与完全芯片重新走了遍流程相比，ECO是首选，因为它需要的时间和金钱更少。不幸的是，这些 ECO 往往在设计周期的后期出现，并且可能有相当复杂——这意味着 ECO 会影响时序、状态机、时钟复位路径等。这就清晰的提出了对自动化工具的需求。
什么是功能ECO？
ECO就是把RTL中变化的逻辑直接插入到门级网表中。自动化解决方案应该要能够对比修改前后的设计，找到受影响的逻辑锥，来确定能够反映RTL变化门电路，并生成一个可以在原始APR网表中轻松变更的补丁。
ECO有各种各样的实现方式，在设计中添加逻辑、删除逻辑、或者更精细的修改，例如解决绕线后的信号完整性。所有ECO的目标都是尽快将产品推向市场，同时将正确性和进度的风险降至最低。解决ECO可能是一个压力大、工作时间长和充满不确定的工作。
快速周转时间：你希望能够尽快生成准确的补丁
最小迭代：补丁应该功能正确，且考虑时序，以便对后端实现影响最小
基于上述需求，我们来回顾一下市场上现有的功能 ECO 解决方案的局限性。
第一代功能ECO解决方案存在一个基本的流程限制：它们都遵循网表驱动ECO流程。这意味着ECO创建过程只能比较两个完整综合的netlist，即原始netlist和重新综合的netlist。尽管ECO的部分明显就在几行RTL或几个逻辑门范围里，但这些解决方案迫使用户对整个设计（注：或子系统，取决于综合和APR的partition）进行完整重新综合。如果这个partition重跑完整的综合需要几天时间，这很可能是一个非常昂贵的步骤，从实现ECO的进度压力上看，设计团队无法承受。
第二个限制是许多工具都希望在重新综合时严格保持综合优化选项不变。换句话说，这些解决方案希望重新综合的网表与原始网表具有完全相同的优化。这是因为，在重新综合时，作为RTL的修改可能会使得综合工具采用不同的优化方法。例如，一些之前是常量的寄存器，在RTL修改后可能不再是常量。又如，banking策略可能不同，某些寄存器合并、寄存器复制的步骤也可能不同。
工具通过对比有着不同优化方法的两个网表，来正确识别逻辑锥里真正的差异，将会非常难。所以，很可能不能产生功能正确的补丁，或者足够优化的补丁。这对重新综合提出来不必要的限制。这也要求工程师做大量的手动操作或自定义的设置，来让重新综合的网表足够接近，以便ECO工具来对齐两个网表来创建最小的补丁。
由于担心在ECO时会面临这些复杂情况，设计人员通常会减少或限制综合优化，如ungroup、sequential优化和inversion push，来让ECO过程更顺利。从本质上讲，ECO决定了设计团队怎样做综合。
总结一下
许多现有的自动化功能ECO解决方案在从RTL修改到ECO完成过程中会受到以下限制：
1、仅支持网表ECO流程，强制用户做重新综合这一步，这会极大地影响周转时间（TAT），因为一个partition的综合有时可能需要几天时间。
2、施加限制，即重新综合必须以与原始综合用完全相同的方式重跑，以最大限度地减少两个网表之间的优化差异。这再次影响TAT，因为需要大量的自定义设置才能重跑综合。
3、如果不遵循上面两点，都可能导致工具创建的补丁功能不正确，或者补丁不够优化，这将导致多次手动迭代才能获得正确的补丁。
4、最后，由于害怕ECO的复杂度，设计人员最终会禁用综合优化措施，牺牲了QoR。
