数字IC后端时钟树综合CTS优化实战：从skew收敛到功耗平衡的工程指南

写这篇文章的起因，是我最近在整理一段数字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怎么用才算聪明

时钟网络在布线阶段属于典型的高优先级信号，对待它的方式不能和普通数据线一样。最简单也最常用的一招，就是给时钟树加NDR（Non-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。改完重新跑CTS，skew从120ps降到了22ps，setup margin也跟着回来了。

这个案例给我最大的启发是：CTS的优化对象虽然是buffer，但根本问题往往在布局和绕线规划上。root placement、clock guide这些物理约束，比在spec里把skew目标改得再小都来得直接。

3.2 案例二：ICG时钟门控下的skew异常修复

低功耗设计里几乎离不开ICG（Integrated 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就行。同时，在MMMC（Multi-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问题的速查表，遇到问题时按图索骥，效率会高不少。

这张表覆盖了我遇到过的大部分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优化这条路上少踩几个坑，多一些从容。