6.2 ECO：签核前的最后修改窗口
6.2 ECO：签核前的最后修改窗口
本节摘要：ECO（工程变更令）是签核前的最小修改流程：诊断、生成修改脚本、增量实现、增量验证，每一环都要求"只动该动的"。本节按 ECO 的类型拆解风险等级，给出从违例清单到干净网表的完整流程，以及必须回跑的验证清单。
ECO 的全称是 engineering change order——工程变更令。它起源于一个朴素的矛盾：签核发现违例，但全流程重跑要几周，而流片窗口就在眼前。ECO 的答案是只改必须改的：一份修改清单、一段脚本化的小改动、一次增量的实现与验证。它既是技术流程，也是管理流程——每份 ECO 都要有编号、原因、影响面与审批，因为它是流片前最后的物理修改权。
一、ECO 的类型与风险等级
时序 ECO（本节主角）按改动类型排风险。保持修复（插延迟单元）：风险最低，只动数据路径上的延迟，不碰逻辑功能，工具能自动完成；数量可能很大（几百上千个 buffer），但每个改动都局部。尺寸调整与 VT 替换：把某个单元换成同功能强/弱一档或不同阈值电压的版本，接口不变、功能不变，风险低中；副作用在功耗（快 VT 漏电高）与拥塞（大单元占面积）。绕线重排与层提升：不动单元只动线，风险低，收益中等（3.2 的 RC 账）。网表重连（改逻辑）：风险最高，动功能，必须过形式验证——通常留给功能 ECO 流程处理，时序收敛不轻易动它。
另一条分类线是"还能不能动下层金属"。流片前的 ECO 在完整布图上做，自由度高；流片后（或第二次流片）的金属 ECO 只能改高层金属与备用单元（spare cells）——设计时在版图里预埋的可配置单元。备用单元的数量与分布在设计阶段就要规划，它是"硅后修复"的全部家当。
图：一份时序 ECO 的闭环流程
二、增量纪律：ECO 的技术核心
ECO 与全流程重跑的差别全在"增量"二字上。增量实现：只对改动单元做放置与绕线，周边已验证的版图一字不动——布线工具的 ECO 模式保证新线不穿已通过的区域。增量 STA：1.1 说过的"换输入必须全量重算"纪律在这里有个精确的例外——改动只影响局部扇出锥（fanout cone），受影响路径集合内的时序重算等价于全量，集合外的结果不变；靠谱的 ECO 流程会显式计算受影响集合并只对它出报告，但签核确认前的最后一轮仍要全量跑，防止影响集合的边界判断出错。增量验证：形式等价工具接受 buffer 类"中性改动"，尺寸类改动只需重新检查时序与功耗，功能重连才需要完整等价证明。
纪律的反面教材值得一读：某项目为救三个保持违例插了四十几个 buffer，绕线工具顺手把附近一段总线重排了，没人重跑那段总线的串扰分析——流片后功能偶发错误，追了六周才发现是 ECO 溢出效应。教训不是"少插 buffer"，而是"影响面评估要比改动面大一圈"。
功能 ECO：另一条分支
与时序 ECO 并行的是功能 ECO——流片前发现逻辑错误时的最小修改。它不归时序团队主导，但两者共享全部基础设施：改动清单、增量实现、增量验证与文档闭环。功能 ECO 的时序联动值得时序工程师警惕：为绕开一个逻辑错误重新布的线，可能恰好穿过某个时序敏感区，让修复后的路径冒出新违例。成熟项目的做法是功能 ECO 与时序 ECO 用同一个变更控制委员会管理，任何改动合并进网表前都过一遍增量 STA——两支队伍各改各的、最后合并时才对账，是签核前夜最常见的事故剧本。
三、ECO 的收敛验收
一份 ECO 何时算完？三个条件同时满足才算。违例本身清账：目标违例在所有相关场景下转正（不是只在当时看的那一个角——7.4 的矩阵）。没有新账：受影响集合内的建立与保持、脉宽、串扰、功耗与物理规则全部复核，增量与全量两轮 STA 结论一致。文档闭环：ECO 编号、修改清单、验证证据归档，网表版本递进登记。ECO 的完成不是"报告变绿"，而是一整套证据链的闭合——它是流片前最后一次行使修改权，行使记录就是责任记录。
批量 ECO 的组织方式
单条违例的 ECO 很简单，难的是几十条违例怎么组织。批量化的纪律有三条：按修复类型分批——所有保持修复一批、所有尺寸调整一批，同批改动互相独立、验证可以合并做；每批设回归判据——批内改动只允许改善目标违例，对其他场景的连带影响超出白名单就回滚该批；版本快照对齐——每批完成打一个网表标签，任何后续问题都能回溯到具体批次。批量化把验证成本从"每条一次"摊薄到"每批一次"，这是 ECO 能在流片窗口内转完两三圈的唯一原因。反面教材是把不同类型的改动混在一批：保持修复与尺寸调整互相影响，出了问题既不能回滚也不能定位。
ECO 工具链的分工速览
一轮 ECO 会经过四类工具，各自的职责边界值得记清：诊断与脚本生成在 STA 工具（哪些违例、怎么改）；单元的放置与绕线在物理实现工具的 ECO 模式（增量放、增量绕）；改动的功能等价在形式验证工具（中性改动快速放行）；最终的场景级确认回到 STA 与签核报告系统。四类工具之间传递的是同一个改动描述（ECO 脚本），格式统一是效率的关键——很多团队的 ECO 周期长，长在工具间手工翻译改动清单上。工程化程度高的团队把 ECO 脚本做成单一事实源，四类工具都从它出发，改动全程可追溯、可重放。
选型或自查时还有一个实用指标：从提交 ECO 脚本到拿到场景级确认报告的墙钟时间。它综合了四类工具的效率与流程的自动化程度，是 ECO 能力最诚实的成绩单。
本节要点回顾
- ECO 是最小修改流程：诊断、脚本、增量实现、增量 STA、验证回跑，每一步以"只动该动的"为纲。
- 类型决定风险：保持修复最低、重连最高；硅后金属 ECO 只能依赖预埋的备用单元。
- 增量有边界：影响扇出锥内重算等价于全量，但签核确认前必须全量复核一轮。
- 影响面比改动面大一圈：溢出效应（邻线重排、串扰变化、功耗漂移）是 ECO 事故的主要来源。
- 完成即证据链闭合：违例清账、无新账、文档归档，三条件缺一不可。
ECO 修的是"已确认的违例"，而确认之前还有一步：把违例的真伪与根因搞清楚。下一节讲瓶颈定位——按证据聚类，而不是按 slack 排序蛮干。