ICC2的CTS阶段是我这几年做后端项目里踩坑最密集的环节。前阵子有个项目时钟频率不算高逻辑也不算复杂我本来想着CTS随便跑跑就能过为了追求漂亮的skew报告把target_skew从50ps一路压到30ps结果CTS跑完一看时钟树面积涨了三成插入延迟从0.4ns直接顶到0.7ns后面修hold violation的时候越修越不对劲setup也跟着崩。这篇文章就把从设置target_skew到修复hold violation的完整流程捋清楚包括ICC2里各路命令的合理用法、CTS结果的检查方法以及几个真实踩过的坑和对应的排查思路给正在扛后端项目的朋友做个参考。内容适合刚接触ICC2的工程师也适合已经上手但想在CTS环节少走弯路的同行。1. 为什么CTS阶段就要盯住skew和hold一颗时钟树引发的连环问题1.1 时钟树在数字后端流程里的位置数字后端从netlist到GDS中间要经历place、CTS、route这三大步。CTS介于placement和routing之间看起来只是一个把时钟buffer连起来的步骤但它对后续所有工作影响巨大。place阶段时钟线还是理想的CTS阶段才把虚拟时钟变成真实的时钟网络每个触发器具体分到多少延迟、相互之间差多少都是在这个环节被固定下来的。CTS一旦做砸了后面route和signoff阶段再怎么补救都是事倍功半。很多工程师会把CTS当成一个跑完就完事的节点但实际上CTS的输出质量直接决定了后续timing closure的难度。时钟树综合做得好数据路径上的时序冗余就多修hold时就不会手忙脚乱时钟树做得差哪怕逻辑本身没有问题也会出现大量看似莫名其妙的时序违例。这个道理我是在栽过跟头之后才真正理解的。1.2 skew、latency、hold violation怎么串成一条线latency是时钟从时钟源点到某个触发器的总延迟skew是不同触发器之间latency的差值hold violation则是当时钟沿到达之后数据端还期望数据保持一段时间不变而数据路径因为跑得太快导致数据提前翻转从而违反保持时间要求。CTS阶段如果skew控制不好数据路径上的hold margin就会很不稳定所以很多hold问题不是电路逻辑错了而是时钟树本身的时序分配出了问题。skew还有全局和局部之分。全局skew更关注整棵树的平衡影响的是setup和hold的整体冗余局部skew则更关注相邻几级寄存器之间的时钟差它直接决定hold修复的难度。CTS优化器在做平衡时会同时考虑这两个维度而我们设置target_skew时实际上是在给这个平衡过程设定一个目标边界。1.3 把CTS质量测试当作设计验收的一部分跑完CTS并不是结束。我的习惯是CTS结束后立刻做一轮质量测试包括skew报告、latency报告、transition检查、时钟网络congestion检查甚至看一下时钟树一共插了多少级buffer。这轮检查虽然花不了几分钟但能提前把很多隐患扼杀在早期阶段。所谓CTS测试不是芯片测试而是对时钟树综合结果的质量验证。简单说就是确认每一棵时钟树都满足设计要求skew在合理范围内、latency没有异常偏大、transition没有爆掉、时钟网络区域没有严重的绕线拥塞。如果这些指标都正常后面route阶段大概率会比较顺利如果有任何一项异常务必在进入route之前解决掉否则越往后返工成本越高。2. target_skew的设置理解参数本质再谈命令怎么写2.1 target_skew到底在优化什么target_skew并不是一个硬性约束而是给CTS优化器的一个优化目标。优化器在综合时钟树时会同时考虑skew、latency、transition、电容负载、面积、功耗等多个目标target_skew只是告诉它你把时钟到达时间差异尽量控制在这个范围内。优化器在权衡时不一定百分之百严格执行这个值但如果目标过于激进它会通过增加buffer级数、绕线、增大cell尺寸等代价来完成。这里有一个很多新手容易误解的地方skew越小不等于时序越好。skew越小确实意味着各触发器收到时钟沿的时间更一致但为了缩小skew优化器可能把短路径不断绕长去匹配长路径导致整个时钟网络的latency和面积整体上升。latency上升对hold的影响尤其明显因为hold分析要同时考虑时钟延迟差和数据路径延迟。过度追求小skew往往得不偿失。2.2 ICC2里设置target_skew的常用姿势在ICC2里设置target_skew主要用set_clock_tree_options命令可以按时钟树对象、按时钟域分别指定# 针对某个时钟树设置target_skew set_clock_tree_options -target_skew 0.05 [get_clocks clk] # 更精细一点设置early skew和target skew一起用 set_clock_tree_options -target_early_skew 0.02 -target_skew 0.05 [get_clocks clk] # 或者按clock tree name设置 set_clock_tree_options -target_skew 0.08 -clock_trees clk_tree不同版本的ICC2对参数支持的细节略有差异跑之前最好用man set_clock_tree_options或工具自带文档确认一下。设置完target_skew之后还需要配合target_latency等参数一起考虑否则优化器可能为了把skew压小而无脑拉大所有时钟路径的延迟导致整体latency失控。2.3 skew目标值给多少才合理这是新手最容易犯难的问题。给得太保守skew太大hold难修给得太激进时钟树面积和延迟双双失控。根据我在不同工艺节点上的实测经验大致可以参考这张表工艺节点建议target_skew注意事项28nm及以上80~150 ps可以比较放松优先控制面积和功耗16/12nm40~80 ps需要结合时钟频率调整高频时钟建议偏小7nm及以下25~60 ps必须关注OCV影响太小会导致插入延迟暴涨这个表是经验值不是硬性标准。实际项目里还要看库里的时钟buffer驱动能力、时钟树的结构、是否有大量同步器逻辑等。我的做法是先按表格的中位数设一版跑完CTS看时序报告。如果skew已经达到目标但hold还大面积违例问题往往不是skew本身而是数据路径太短如果skew报告根本没达标再逐步收紧。不要一上来就把值设到极限。3. CTS跑完后的第一轮检查发现问题比修复问题更重要3.1 从clock_opt日志和报表中识别真实风险CTS跑完后第一件事不是看hold报告而是看时钟树本身的质量。report_clock_tree -summary report_clock_timing -type skew report_clock_timing -type latency report_qorreport_clock_tree -summary会列出每棵时钟树的skew、latency、buffer数量等信息report_clock_timing -type skew则细化到每条corner下的skew分布report_qor能看出整体时序的大盘。我一般会重点盯三个数字最大skew、平均latency、时钟树的buffer总数。这三个数字如果都在合理范围后面route阶段出问题的概率就小很多。在CTS测试这一步还有一个容易被忽略的指标是时钟树上的cell类型是不是统一的。如果一棵时钟树上混用了HVT、SVT、LVT等多种阈值电压的buffer在OCV场景下会带来额外的时序不确定性。所以我会在report_clock_tree -summary里顺便检查buffer类型分布发现混用严重会回到CTS配置里做约束。3.2 latency、skew与transition三者互相拉扯很多人在CTS阶段只看skew忽略latency和transition。实际上三者的关系是互相制约的。latency太大意味着时钟到达各寄存器的时间整体偏晚对hold分析来说影响是叠加的skew太小可能为了让时钟短路径绕远路去匹配长路径导致transition变差transition变差又会直接影响噪声和OCV间接影响时序收敛的稳定性。CTS检查时我会同时把三类报告打印出来对照着看。skew和latency都很好但transition爆掉一棵树这种情况优先检查时钟网络的负载和buffer驱动能力。反过来如果transition很好但skew不理想说明buffer驱动力过强、平衡做得不够细需要调整时钟树的约束策略。三者之间找到一个平衡点时钟树整体质量才有保障。3.3 在CTS阶段就预判hold fix的工作量CTS结束后的hold分析有两个用途一是看看有没有需要立即修复的违例二是预估后面hold修复的工作量。具体做法是跑一次report_timing -hold注意不要只看最差的几十条要看整体违例路径的数量和分布。如果violation路径数量很多而且分布在不同时钟域之间大概率是时钟树本身的skew和latency设置有问题这时候最正确的操作是回头调整CTS参数重新跑而不是硬修。如果violation路径数量少、集中在个别模块再考虑在数据路径上插入delay cell。经验法则CTS后的hold violation数量如果超过总寄存器数的5%先怀疑时钟树设计而不是怀疑数据路径。4. hold violation修复的完整流程与实操手段4.1 hold违例的物理本质hold violation的物理含义是在时钟有效沿到来后数据端需要维持一个稳定状态足够长的时间让触发器能够正确锁存。如果数据路径延迟太小数据在时钟沿之后很快翻转触发器就锁不到正确的值。在后端设计里hold问题之所以越来越突出是因为先进工艺下cell delay不断缩短而时钟网络的延迟变得相对明显两者之间的冗余越来越紧张。为什么CTS之前不看hold因为CTS之前时钟是理想网络时钟到达每个触发器的时刻被认为相同skew为0。这种情况下hold检查会漏掉很多真实存在的风险。CTS之后时钟树真实生成每个触发器的实际时钟延迟各不相同hold分析才具有参考价值。这也是为什么hold修复主要发生在CTS阶段之后。4.2 ICC2中定位hold violation的标准流程在ICC2里定位hold violation我习惯按下面的顺序来# 第一步看整体hold违例数据 report_constraints -hold # 第二步抓具体违例路径 report_timing -hold -max_paths 100 -nworst 10 # 第三步按时钟域统计 report_timing -hold -group clk -max_paths 50看hold路径报告时我通常关注三样东西首先是违例路径的skew占比如果skew占了违例数值的大部分说明问题出在时钟树其次是数据路径的长度如果数据路径只有两三级cell就到达终点说明延迟确实太短插delay cell是合理的最后是路径所在模块如果集中在一个特定区域可能是该模块clock gating结构或者clock mux结构导致的。4.3 delay cell、buffer chain与path优化三种修复手段如何选修hold的常规手段有三种。第一种是插入delay cell或buffer chain最常用也最直接。在数据路径上增加延迟来满足保持时间选delay cell时优先用HVT类型因为它们对电压温度波动不那么敏感在多个corner下的表现更稳定同时功耗也更低。第二种是调整数据路径上的逻辑级数或驱动强度。加大前级cell的驱动让数据翻转更快表面上看和修hold背道而驰但在某些路径上如果前级cell的transition太差反而导致后级出现无谓的setup压力适当调整驱动可以一举两得。不过这种方法在hold修复中属于辅助手段不能当主力。第三种是调整时钟路径通过deskew优化时钟到达时间差。但在CTS完成之后动态调整时钟树成本很高而且风险大不到万不得已不建议做。时钟树的balance问题应该在CTS阶段解决而不是在修复阶段补救。三种手段的适用场景可以这样区分修复手段适用场景主要风险delay cell插入路径延迟过短、violation不大增加面积功耗可能连带影响setup调整驱动强度transition异常、路径负载过高可能增加动态功耗时钟deskew时钟树本身不平衡成本高容易引入新的时序问题4.4 修复后的收敛检查与corner确认hold修复完成后不能只看一个corner。同一个数据路径在不同电压、温度、工艺角下cell延迟的变化趋势不一样。常见做法是跑多corner的hold分析确认最差的corner和次差的corner都收敛。ICC2中可以用report_analysis_views先查看当前的分析视图再用report_timing -hold -view指定具体corner分析。修复后还要注意check setup是否被顺带破坏。插入delay cell会增加数据路径延迟而数据路径延迟变大会直接影响setup。如果发现修hold把setup修坏了优先检查delay cell的插入位置和插入数量确认是否过度修复。从工具策略上说最好在CTS阶段就设置合适的hold margin让自动修复有据可依而不是在route阶段让工具随意发挥。5. 避坑实录从target_skew到hold修复的完整排查链路5.1 target_skew设得太小时钟树面积和delay同时失控我曾在28nm项目里把target_skew从50ps一路压到30ps结果CTS完成后的时钟树面积比预估多了40%时钟插入延迟从0.35ns涨到0.65nssetup整体变差hold反而更难修。复盘下来问题就出在过度追求小的skew。优化器为了满足这个激进目标把短路径不断绕长去匹配长路径整个时钟网络被绕成非常复杂的平衡结构延迟整体上涨。这是一个典型的只看单一指标不看整体trade-off的教训。从那以后我给自己定了一个规矩target_skew的调整必须控制在合理区间内并且每一版CTS之后都同时看skew、latency、面积和buffer数量四个维度。如果某个指标因为收紧skew而大幅恶化我会停下来说服自己这个skew目标真的必要吗大多数情况下答案都是没必要。5.2 修hold修崩了setupdelay cell的位置和类型都有讲究另一个印象深刻的坑是修hold修崩了setup。有一次在route_opt阶段让工具自动修hold默认配置下工具插入了一大批标准驱动buffer结果setup WNS从-60ps变成了-140ps。原因是插入的buffer增加了前级cell的扇出负载导致前级cell的输出transition变差进而影响前级到后级路径的setup。后来我调整了修hold时的delay cell类型和位置约束限制工具优先使用低驱动、高阈值电压的delay cell不要在敏感路径上乱插情况才好转。具体操作上可以通过set_fix_hold_options或route_opt阶段的相关选项来控制插入cell的类型和位置不同版本的ICC2在选项名上略有差异建议以工具帮助文档为准。经验之谈延迟单元宁可用数量少、每级延迟稳定的cell也不要插一堆小尺寸buffer堆砌延迟后者对OCV和transition的伤害很大。5.3 多corner下的hold修复冲突OCV带来的额外坑多corner分析下修hold是后端工程师必踩的坑。我在一个16nm项目里遇到了典型的冲突场景在ss corner下把hold修到完全收敛切到ff corner检查时发现同一批路径hold大量违例在ff修好之后ss又崩了。这是因为不同corner下delay cell延迟的变化趋势不同低阈值单元和标准阈值单元对corner变化的敏感度差异很大。我后来做的调整是所有hold修复一律优先使用HVT delay cell并且把hold margin根据OCV仿真结果按corner分开设置在ff corner多留一些margin在ss corner少留一些最终找到都能接受的平衡点。这个经验在先进工艺下尤其重要因为OCV的影响占比越来越大靠单一corner收敛根本无法覆盖全场景。5.4 一条完整的排查链路从hold报告追溯到CTS选项最后分享一个比较完整的排查实例。某次项目CTS后report_constraints -hold显示hold WNS是-0.35ns违例路径900多条。我没有直接去插delay cell而是先跑了一遍report_clock_tree -summary发现其中一个子时钟树的skew达到120ps明显高于目标值。再看latency发现这棵子时钟树比同domain的其他树多了三级buffer。继续查CTS配置发现这个generated clock没有单独设置target_skew用的全局默认值而全局值对这个高速子时钟树来说太宽松。于是重新对该generated clock单独设置了目标skew拆分时钟树后重新跑CTShold违例数量降到100多条剩下的用insert_delay_cell修复整个流程干净了很多。这个案例说明遇到hold问题先回头检查时钟树比盲目修数据路径高效得多。很多时候时序违例的根因不在逻辑端而在时钟端。做CTS这几年我最大的感受是工具的参数永远是为整体时序服务的不要为了一个漂亮的skew数字去牺牲latency、面积和功耗。每次调整target_skew之前我会先问自己三个问题这个时钟域有多少寄存器数据路径本身短不短有没有跨时钟域路径混在里面答案清楚了再动手基本上能把大部分坑提前避掉。最后留一个小习惯每次跑完CTS打开report_clock_tree -summary扫一眼buffer总数和最大latency这两个数字异常后面大概率要花成倍的时间去补救。
