2. 后期时序问题分类与ECO决策入口
后期时序修复的第一步不是急着改网表，而是把PrimeTime报告里的违例“翻译”成工程语言：这是哪一类问题、由什么引起、能不能靠改约束或改实现解决、是否必须动功能逻辑。只有分类清楚，才能选对ECO入口。本节围绕建立时间、保持时间、过渡、电容、噪声、串扰以及OCV/AOCV/POCV这几类典型后期问题，说明如何从报告判断是否必须ECO，以及功能ECO与时序ECO的分界。
一、先分清“约束问题”与“物理实现问题”
拿到一份PT报告，先看违例的WNS/TNS和违例路径数量，再看路径的起点、终点和时钟域。若违例集中在跨时钟域、异步接口或未约束的生成时钟上，很可能是约束不完整导致的假违例；若违例集中在同一时钟域内、且路径延迟明显偏大，则更可能是真实的物理实现问题。判断顺序建议是：先确认时钟定义、输入输出延迟、多周期/虚假路径是否完整，再判断是否属于真实时序违例。这一步决定了后续是改SDC还是改网表。
二、建立时间违例：看数据路径还是时钟路径
建立时间违例的本质是“数据到得太晚”。在PT中，setup slack = required time − arrival time。若slack为负，需要拆开看：是launch clock path偏慢、capture clock path偏快，还是data path组合逻辑太长。常见处理手段包括：对数据路径做逻辑重组、插入缓冲、降低扇出、换用驱动更强的单元；对时钟路径则考虑CTS平衡、有用偏斜（useful skew）或调整时钟树。若违例路径跨越多个模块且逻辑层级很深，单靠size cell和buffer往往收效有限，此时应评估是否进入功能ECO，例如重构布尔逻辑或改变流水线级数。
三、保持时间违例：先看是否可修，再看是否必须动功能
保持时间违例是“数据到得太早”，hold slack = arrival time − required time。后期修hold通常比setup更敏感，因为插入延迟单元会影响setup余量。判断入口是：违例是否集中在短路径、是否与时钟偏斜强相关、是否出现在扫描链或复位路径上。若hold违例只出现在少数路径，可通过插入延迟单元、调整单元阈值电压或局部绕线解决；若违例大面积出现且与时钟树结构相关，应先检查CTS结果和OCV降额是否过紧，而不是直接改功能。只有当hold违例无法通过物理手段收敛、且影响功能正确性时，才考虑功能ECO。
四、过渡、电容与噪声：先看规则违例是否触发时序退化
transition违例表示信号边沿过慢，会直接导致单元延迟增大和噪声容限下降；capacitance违例表示负载超过驱动能力，通常与高扇出或长线相关；noise和crosstalk违例则反映相邻网络耦合引起的电压毛刺或延迟变化。这三类问题在PT中常以max_transition、max_capacitance、noise margin等形式报告。处理顺序是：先修transition和capacitance，因为它们会恶化setup/hold；再评估crosstalk对关键路径的影响。若某条路径的setup违例在开启SI分析后明显变差，说明串扰是主因，应优先做屏蔽、增大间距或换线，而不是盲目size cell。
五、OCV/AOCV/POCV：降额方式决定修复策略
OCV用统一降额覆盖片上偏差，AOCV按逻辑深度和物理距离调整降额，POCV则用统计分布描述参数变化。三者的共同点是：它们都会改变slack的计算结果，但不会改变网表本身。判断入口是：若违例只在开启AOCV/POCV后出现，且路径深度或距离较大，说明降额模型对结果影响显著，此时应优先检查降额文件、derate设置和路径分组是否正确，而不是直接改逻辑。若在合理降额下仍无法收敛，才进入物理或功能ECO。
六、功能ECO与时序ECO的分界
时序ECO只改单元尺寸、缓冲、延迟单元、连线或阈值电压，不改变逻辑功能；功能ECO则要修改布尔逻辑、增加或删除寄存器、改变模块接口或重构数据通路。分界判断可以归纳为三条：第一，若违例路径的逻辑功能本身正确，只是延迟不满足，优先时序ECO；第二，若违例源于逻辑层级过深、组合环、错误的多路选择或缺失的流水线寄存器，时序ECO无法根治，应进入功能ECO；第三，若违例只在特定工作模式或测试模式下出现，先确认模式约束和测试逻辑，再决定是否动功能。
实际项目中，一个常见的判断误区是：看到setup违例就立刻size cell。若违例路径的launch clock path被OCV降额压得很低，而capture clock path降额很小，真正的问题是时钟树偏斜和降额设置，而不是数据路径太慢。此时应先检查CTS结果和derate文件，再决定是否插入有用偏斜。另一个误区是hold违例一律插延迟单元，若违例集中在扫描链上，插入延迟单元可能影响扫描移位频率，应优先调整扫描链顺序或使用lockup latch。
七、从报告到决策的实操检查清单
下面给出一份可直接对照PT报告使用的检查清单，用于快速定位问题类型并选择ECO入口。清单中的阈值和示例参数属于教学假设，实际项目应按工艺和签核标准调整。
| 检查项 | 观察内容 | 判断倾向 |
|---|---|---|
| 时钟定义 | create_clock / create_generated_clock 是否覆盖所有时钟 | 缺失 → 先补约束，不进入ECO |
| IO延迟 | set_input_delay / set_output_delay 是否与接口协议一致 | 不一致 → 改SDC |
| setup违例 | data path延迟占比 vs clock skew占比 | data为主 → 时序ECO；逻辑深 → 功能ECO |
| hold违例 | 是否集中在短路径、扫描链、复位路径 | 局部 → 时序ECO；大面积 → 查CTS/OCV |
| transition/cap | max_transition / max_capacitance 违例数量与分布 | 先修规则违例，再评估时序 |
| noise/crosstalk | 开启SI后slack变化量 | 变化大 → 优先屏蔽/增距 |
| OCV/AOCV/POCV | derate设置、路径深度、距离 | 降额过紧 → 先调模型，再改网表 |
最后强调一点：后期时序修复不是“看到违例就改”，而是“先分类、再定位、后决策”。建立时间、保持时间、过渡、电容、噪声、串扰和OCV/AOCV/POCV各自对应不同的报告字段和修复手段。把PT报告中的slack拆解成launch path、data path、capture path三段，再结合约束完整性和降额设置，就能在功能ECO与时序ECO之间做出有依据的选择，避免把可修的时序问题升级成昂贵的逻辑改动。