写这篇文章的起因是我最近在整理一段数字IC后端设计的项目复盘发现整个项目里最占时间、最折磨人、也最能体现后端工程师基本功的环节就是时钟树综合CTS的优化与收敛。很多同学做流程能跑通但遇到skew不收敛、时钟树功耗过高、迭代后时序反而恶化这类问题时就容易卡住。这篇文章就围绕数字IC后端设计里的时钟树综合实战展开把优化技巧、工具流程、典型案例分析放在一起讲希望能给正在做CTS或者准备进入这个方向的工程师一些可落地的参考。1. 时钟树综合到底在解决什么问题1.1 从理想时钟到物理时钟的落差数字IC里所有触发器的采样动作都依赖时钟边沿。在后端设计之前前端给出的约束是“理想时钟”也就是默认时钟边沿同时到达每一个触发器。但物理实现之后时钟信号从时钟源比如PLL输出出发要通过缓冲器、金属走线一层层分发到几百上千个触发器每条路线的长度不同、经过的单元数量不同边沿到达的时刻自然就不可能完全相同。这个到达时刻的差异就是skew而时钟信号从源端到某个触发器的绝对延迟就是insertion delay。CTS的任务就是通过插入缓冲器、调整走线拓扑把这个从“源”到“叶”的延迟差异控制在一个可接受的范围内同时保证transition、电容、扇出等物理约束不超标。我见过不少刚接触后端的人有一个误区以为CTS就是把所有时钟路径的延迟做得完全一致skew做到零。实际工程里不是这么回事。一方面零skew的代价是插入大量缓冲器功耗和面积双双飙升另一方面很多时序路径本来就不需要严苛的skew平衡强行平衡反而浪费资源。CTS要做的是“在需要平衡的地方平衡在不需要平衡的地方放松”这也是useful skew能成立的底层逻辑。1.2 CTS不是孤立步骤而是枢纽CTS在数字IC后端流程里的位置恰好卡在布局placement之后、布线routing之前。这个位置决定了它非常特殊前面承接布局质量后面直接影响布线收敛难度和签核时序。布局阶段如果单元摆放不合理时钟root位置选得差CTS阶段要花数倍的力气去修补CTS如果做粗糙了后续布线阶段时钟线上的串扰、绕线拥塞、DRC违例都会接踵而来。更麻烦的是CTS之后触发器上的clock path一旦确定再想修改布局就是伤筋动骨的事。所以老工程师总说“CTS做得好后端成功一半”这个说法一点不夸张。从我个人的项目经验来看CTS的收益曲线在前期投入上是极度“非线性的”。花一周时间和花一天时间打磨时钟树约束最终的silicon结果差距可能不是一点点。尤其在先进工艺下OCV片上工艺偏差影响越来越明显时钟树路径设计得是否对称、common path是否足够长直接决定了setup和hold修复的难度。2. CTS优化技巧从约束准备到cell选型的推进路线2.1 CTS之前必须检查的时钟约束清单很多CTS问题根子其实出在CTS之前。我见过最典型的场景是CTS跑完发现skew乱七八糟查了半天发现是SDC里时钟定义本身有问题。所以做CTS优化第一步不是急着调工具参数而是把输入约束过一遍。首先是时钟定义。一个设计里往往有几十个时钟域有些时钟之间有明确关系有些是异步的。在SDC里要用create_clock和set_clock_groups把同步和异步关系说清楚。对异步时钟域CTS工具默认会给它们分别建树但如果设置不对工具可能把不同域的时钟当成同组处理白白增加不必要的平衡工作。其次是uncertainty的设置。CTS阶段往往会把uncertainty拆成setup和hold两部分工具在优化时会把这部分余量纳入计算。如果uncertainty设置过大CTS会认为时序收敛难度高于是过度约束skew设置过小后续签核阶段又会暴雷。建议在项目开始时就和前端团队对齐一个uncertainty预算表并在CTS前后保持一致。最后一个容易忽略的点是set_clock_latency和set_clock_source_latency。这两个约束描述的是时钟源到芯片内部clock root之间的延迟。如果在TOP层的块级实现中时钟源并不在当前设计内部就必须通过这两个约束把外部延迟建模进去否则工具会把source latency当作零导致时钟树整体插入延迟的评估严重失真。2.2 时钟树拓扑、Level与buffer选型的实战取舍CTS工具在构建时钟树时核心动作就是反复做三件事选buffer、插buffer、调整拓扑。这三件事背后的取舍逻辑直接决定了时钟树的质量。先看level级数。时钟树级数太少意味着每级buffer驱动的负载过大输出transition会变得很差不仅时序恶化噪音容限也下降。级数太多则累计延迟和抖动都变大功耗和面积也不好。我在实际项目中一般会先看叶子节点的数量和分布密度再决定初始的level目标。比如一个时钟域有2000个触发器、分布在1.5mm见方的区域内我会预期时钟树的逻辑级数在8到12级之间。如果最终结果只有4级大概率是每级驱动的负载过重了如果到了20级那要看看是不是哪里绕线出了反常。buffer选型是另一个关键点。时钟树上的buffer不是越大越好也不是越小越好。大驱动buffer比如CKBD24能带更多负载但在负载较小时本身的输入电容大会拖慢前一级的transition而且功耗也不划算。我通常的做法是让工具使用一组尺寸跨度合理的候选buffer比如从CKBD8到CKBD24之间取2到3种而不是把所有尺寸都塞进去。这样既给了工具选择的自由度又避免了它在不同尺寸之间频繁切换导致clock path里cell delay差异过大。再来说说leaf cell的处理。时钟树的末端通常要接到触发器的CK端而触发器的时钟输入电容往往很大。如果一大片触发器密集排列直接用一层buffer去驱动它们很可能会在transition上爆掉。这时候就需要在离leaf很近的地方“本地化”插入小尺寸buffer做最后一级分发。这里我比较建议配合布局信息去看如果触发器之间分布特别密集用CKBD8这一类小驱动做末级比用大驱动更稳因为走线短、负载也相对可控。2.3 NDR和shielding怎么用才算聪明时钟网络在布线阶段属于典型的高优先级信号对待它的方式不能和普通数据线一样。最简单也最常用的一招就是给时钟树加NDRNon-Default Rule通常是双倍线宽加双倍间距。为什么这么干时钟线长距离走线时如果旁边有一根高翻转率的数据线两者之间的耦合电容会在时钟上注入噪声轻则造成时钟抖动重则产生毛刺把触发器打出错误状态。双倍间距能直接降低耦合电容双倍线宽则降低时钟线自身的电阻让延迟更稳定。我在做7nm项目时对高频时钟域几乎无一例外地使用了double width / double spacing时序收敛的稳定性有明显改善。shielding则是更贵的方案就是在时钟线两侧各加一条接地的金属线把耦合路径物理隔断。它的优点是效果好但代价是占用大量绕线资源而且增加寄生电容时钟延迟会变大。我的建议是不要全芯片无脑加shielding只对最敏感的高速时钟、以及经过长距离平行走线区域的时钟网络局部使用。先把时钟线的绕线路径捋一遍找出那些可能与数据总线长距离并行的区域再有针对性地处理这样性价比最高。3. 三个典型CTS案例的调优全过程3.1 案例一跨模块大扇出时钟的skew收敛这是我在一个AI加速器项目里遇到的实际问题。有一组512个寄存器分布在两个相邻模块里它们需要在同一个时钟周期内完成同步读回操作。CTS完成后我看到的skew报告是120ps而这条路径的预算只有30ps。120ps的skew对周期为1ns的设计来说意味着12%的周期直接没了这是绝对不能接受的。排查第一步是看时钟树拓扑图。工具生成的clock tree schematic显示这条时钟树的root buffer被放在了模块的左下角而左侧寄存器组的负载占了大约六成右侧模块的寄存器映射在上方。由于区域中间横着一块很大的SRAM阵列时钟走线没法直线穿越实际物理绕行呈U形右侧模块的时钟路径明显比左侧长出很多。针对这个情况我做了三件事。第一把root buffer重布局到两个模块负载的几何中心位置而不是守在老位置不动第二在CTS的routing guide里把穿越SRAM上方的绕线区域禁用掉强制时钟路径走更短的顶层金属通道第三把这两个模块的时钟leaf限制在三级以内避免工具为了硬凑平衡而多加buffer。改完重新跑CTSskew从120ps降到了22pssetup margin也跟着回来了。这个案例给我最大的启发是CTS的优化对象虽然是buffer但根本问题往往在布局和绕线规划上。root placement、clock guide这些物理约束比在spec里把skew目标改得再小都来得直接。3.2 案例二ICG时钟门控下的skew异常修复低功耗设计里几乎离不开ICGIntegrated Clock Gating也就是把latch和AND逻辑集成在一起的时钟门控单元。ICG本身不是问题问题在于它的位置和它引入的延迟不平衡。有一个WiFi芯片项目功能模式下hold违例有几百条一开始我以为是hold修复策略太保守但看了时钟树才发现某几个ICG单元被工具摆到了模块角落ICG输出的gated clock要穿过一大片数据逻辑才能到达目标寄存器组。这就导致ICG后级时钟路径的插入延迟严重偏大与其他没经过ICG的触发器之间产生了很大的skew。这个问题的修复路径是这样先把ICG单元按模块的负载中心做了preplace保证每个ICG到其驱动的寄存器组的物理距离大致均衡然后在工具里给ICG设置了dont_touch防止后续优化把它的位置再挪走最后在CTS时给ICG输出端单独加了balance point让工具针对ICG后级额外做一轮平衡。修完这些hold违例直接清零功能模式的时钟margin也恢复到了预期水平。这个案例里有个细节值得注意。ICG的输入电容通常比普通buffer大不少如果驱动ICG的前级buffer驱动能力不足ICG输入端的transition会很差进而影响输出时钟质量。所以在balancing ICG之后我还会额外检查一下ICG输入端的transition和cap报告有问题就在前级补一级buffer而不是让ICG自己硬扛。3.3 案例三多模式多角下共享时钟树的平衡现代芯片基本都要跑多个模式正常功能模式、扫描测试模式可能还有内存内建自测试模式。问题在于这些模式下的时钟结构往往差异很大但物理上又共用同一套时钟网络资源。我在一个消费级SoC项目里遇到过这样的情况芯片功能模式下有一条主时钟频率很高skew预算只有50ps但扫描测试模式下同一根物理时钟网络被复用为scan clock测试时钟的约束相对宽松。工具默认对所有模式一视同仁地平衡结果为了满足测试模式的“假想需求”功能模式下的时钟树被过度平衡插了很多不必要的buffer时钟功耗直接上升了15%。解决思路是把功能模式和测试模式拆开做时钟树约束。在CTS spec里明确声明功能时钟树和测试时钟树是两棵独立树共享同一个root但平衡目标分开功能树严格控制skew测试树只要满足基本DRC就行。同时在MMMCMulti-Mode Multi-Corner设置里把两种模式一起放进签核环境保证优化结果在两边都能收敛。改完之后效果很明显功能模式的时钟功耗回归正常测试模式的setup和hold也都在约束内。通过这个案例我想强调的是CTS的“多模式”处理不是让工具自动去平衡所有模式而是先搞清楚哪些模式真正需要严格约束哪些可以放宽再针对性地告诉工具怎么取舍。4. CTS常见问题与排查技巧实录4.1 时钟树迭代后时序仍然不收敛怎么定位CTS之后时序不收敛是后端工程师最容易焦虑的场景之一。因为一旦到了这个阶段可动手的空间就比place阶段小了很多。我自己的排查习惯是先分清楚时序违例到底是setup问题还是hold问题再分别往回追溯。如果是setup问题先看是不是CTS之后buffer增多导致launch和capture这两条路径上的延迟差被拉大了。这时候要看时钟树的skew报告对比关键路径上发射时钟和捕获时钟的插入延迟。如果skew本身没问题那就是数据路径上组合逻辑太深需要回到place阶段去看单元利用率是不是太高、timing-driven的跑法是不是不到位。如果是hold问题大概率是时钟树上的common path太短。所谓common path就是launch时钟和capture时钟在到达分叉点之前共享的那段时钟路径。这段路径上的延迟在setup和hold分析里是公共的OCV的影响可以被CPPR抵消掉。如果分叉点太靠近触发器common path太短tool能抵消的悲观量就少hold修起来就格外吃力。这时候我会去看分叉点位置必要时在CTS里调整balancing结构让分叉点尽量前移增加公共路径长度。4.2 一张CTS问题定位速查表下面这张表是我在项目里实际用来排查CTS问题的速查表遇到问题时按图索骥效率会高不少。现象可能原因排查方向解决建议单棵时钟树skew收敛不住root位置不合理、负载分布不均、绕线绕远查看clock tree schematic和leaf delay分布重摆root点、增加clock guide、拆分leaf级数CTS后setup大量变差过度平衡相邻skew、buffer级数太多对比preCTS和postCTS的timing报告适当放松skew目标、减少level数量时钟transition/cap违例集中在leaf末级buffer驱动负载过大查看per-pin电容与扇出报告增加一级本地buffer或换用更大驱动ICG后级hold违例多ICG位置偏差、输入电容大、前级驱动不足检查ICG输入slew和输出时钟树preplace ICG、设置dont_touch、增加balance point多模式收敛差不同模式时钟结构差异未在spec中区分检查MMMC设置和CTS spec分组功能树与测试树分开平衡、共用root时钟功耗偏高过度平衡、target skew过严查看时钟网络功耗拆解放宽不必要区域的skew、更换更小驱动buffer时钟绕线拥塞严重NDR和shielding范围过大查看拥塞热图和clock走线路径局部使用NDR、只在关键区域加shielding这张表覆盖了我遇到过的大部分CTS异常场景。但记住表里的“解决建议”是方向不是标准答案。每个项目的工艺节点、布局特征、功耗预算都不一样最终还是要落到具体报告上去分析。4.3 关于工具流程与自动优化的几点习惯建议现在的主流后端工具在CTS上已经非常智能像CCOpt这类技术甚至能把时钟树优化和时序收敛做成交互式迭代。但工具再强使用习惯不好照样会翻车。第一个建议是CTS之后立刻检查clock DRC。不要先去看timing报告先看max transition、max cap、max fanout这三类违例是不是为零。如果这里还有脏数据后面时序报告完全是失真状态你花再多时间去修setup也是白搭。第二个建议是针对skew目标不要拍脑袋。不同工艺、不同时钟频率、不同设计规模下的合理skew差别很大。我一般会先放开跑一版全自动CTS看看工具在不约束skew的情况下能自然收敛到什么水平再根据实际时序瓶颈决定要不要把skew收紧。直接给一个不合理的紧skew目标只会让工具疯狂插buffer功耗面积双双失控。第三个建议是保留每一版CTS的报告和log。时钟树迭代过程中前后对比是定位问题的关键手段。如果发现这一版skew变差了直接对比上一版的clock tree schematic和buffer插入数量往往很快就能发现问题出在哪个模块、哪一段走线上。养成随手保存报告的习惯在项目后期复盘时价值尤其大。另外想多说一句关于useful skew的心得。现在工具都支持自动做useful skew优化通过主动调整局部时钟延迟来帮助setup或hold收敛。工具的好用不代表你可以完全撒手不管。我在项目里会定期抽查工具生成的skew分布报告确认它没有在某个非关键路径上做过度的skew偏移。因为一旦后期ECO改动了某些逻辑之前精心“挪”过的skew可能会变成新问题到时候回退的成本很高。5. 从CTS实战里沉淀下来的几条经验最后再聊几条我个人在实际项目里沉淀下来的体会。第一CTS优化最有效的杠杆在CTS之前布局阶段把时钟root位置、模块划分、拥塞区域想清楚CTS阶段的麻烦至少少一半。我后来养成的习惯是做floorplan和placement时就把时钟网络的物理路径当做一个一等公民来对待而不是等到CTS阶段再来补救。第二时钟树schematic是最好用的调试工具没有之一。时钟树综合的本质是物理网络设计只有把树画出来看你才能直观感受到哪些分支长了、哪些分支歪了。文字报告告诉你skew是120ps但只有tree view能告诉你这120ps是从哪里冒出来的。所以我强烈建议花时间把工具里clock tree debug的功能用熟这会是你排查CTS问题最得力的助手。第三多模式多角下的CTS约束宁早勿晚。如果在项目初期就意识到芯片有功能模式和测试模式之分就该尽早把CTS spec按模式分组设计好。等到时序签核阶段才想起要拆clock tree改动成本会成倍上升甚至影响芯片的流片计划。CTS这个环节做得好的人看起来好像没干什么大事但整个芯片的时序收敛就是顺顺当当的做得不好的人天天在救火setup刚修完hold又崩。差别其实不在于工具用得多花哨而是对时钟物理特性的理解深度、对约束细节的敏感度、以及对排查轨迹的把握能力。希望这篇数字IC后端设计实战的文章能帮你在CTS优化这条路上少踩几个坑多一些从容。
安全合规领先，企业级稳定调用有保障)
