1. ECO工程全景与后期时序修复定位

在数字IC设计流程中，ECO（Engineering Change Order，工程变更指令）并不是一个孤立的“补丁动作”，而是贯穿综合、布局布线、签核各阶段、用于在既有网表或版图上做最小化修改的工程手段。理解ECO，首先要理解它出现的位置：当RTL已经冻结、综合网表已经生成、甚至布局布线已经完成之后，设计仍可能因为功能修正、时序违例、功耗或信号完整性等问题需要改动。此时若重新走完整流程，代价极高，ECO就是在“尽量不动已收敛部分”的前提下完成必要修改。

从Synopsys工具链视角看，ECO大致分为两类：功能ECO与时序ECO。功能ECO通常由RTL变更驱动，需要把RTL改动映射到门级网表，常用Formality做等价性检查、用DC或ICC2/FC完成增量综合与布局；时序ECO则更多由签核结果驱动，例如PrimeTime报出的setup/hold违例，通过插入缓冲、调整驱动、替换单元、修改约束等方式修复。后期时序修复的核心目标，是在满足功能不变、DRC干净、功耗可控的前提下，把WNS/TNS、WHS/THS收敛到签核标准以内。

后期时序修复的约束非常现实：可用的物理空间有限，绕线资源紧张，时钟树已经平衡，电压降和串扰已经存在。因此，时序ECO不是“随便加buffer”，而是要在时序、面积、功耗、可布线性、信号完整性之间做权衡。例如，修复setup违例时插入大驱动单元可能改善延迟，但会增加面积和动态功耗；修复hold违例时插入延迟单元可能引入新的setup风险。工程上通常先处理WNS最差的路径，再处理TNS，最后清理DRC和SI问题。

下面这张图给出Synopsys工具链视角下的ECO工程全景：从RTL/约束输入，到综合、布局布线、签核，再到功能ECO与时序ECO两条修复路径，以及最终回归签核的闭环关系。

图中可以看到，ECO并不是流程的终点，而是签核发现问题后的反馈修正环节。功能ECO和时序ECO虽然驱动源不同，但最终都要回到签核工具中重新验证。对于后期时序修复，工程上通常遵循“先看WNS、再看TNS、最后看hold和SI”的顺序，因为WNS决定芯片能否跑在目标频率，TNS反映整体违例规模，hold问题则可能在修复setup时被引入。

在Synopsys工具链中，后期时序修复的典型输入包括：PrimeTime生成的违例报告、ICC2/FC中的物理数据库、StarRC提取的寄生参数、以及SDC约束。修复动作通过eco_netlist或insert_buffer等命令落到版图上，再经过增量绕线和时序更新。判断修复是否成功，不能只看单条路径变好，而要确认WNS、TNS、WHS、THS四项指标同时满足签核标准，且没有引入新的DRC违例或SI问题。

建立整体工作框架时，可以把ECO理解为“签核驱动、增量修改、回归验证”的闭环。综合阶段关注逻辑映射与初步时序，布局布线阶段关注物理实现与时钟树，签核阶段关注真实寄生下的时序与信号完整性。ECO则是在这个链条的末端，用最小代价把设计拉回收敛状态。理解这个全景，后续学习具体ECO命令、修复策略和脚本实现时，才能清楚每一步动作在流程中的位置和影响。