深入解析build_clock：CTS时钟树综合的五步流水线及工程优化要点

1. 为什么CTS是后端工程师最头疼也最依赖的步骤

后端流程走到clock_opt，一根build_clock下去，机器经常要吭哧吭哧跑好几个小时，屏幕上滚动着一行行长得差不多的日志。刚开始接触的人最容易犯一个错误：只盯着最后有没有报skew违例，或者hold是不是干净的，根本不关心build_clock里面到底拆成了多少个阶段，每个阶段各自在解决什么问题。等到时序出问题，就只能一遍遍改约束、改buffer型号、改时钟树设置，试得手都酸了还不知道根因在哪。

CTS（Clock Tree Synthesis）在整条后端流程里的地位，本质上就是"给全芯片数万个寄存器统一发报时"。时钟信号从 PLL 或通过 io 进来的那个点开始，要经过一个个 buffer、一层层 metal，最终精确地打到每一个 flip-flop 的 CK 端。这个网络太庞大了，不能指望像普通信号线那样随手布局布线就能搞定。它的延迟、偏差、功耗、噪声，直接决定芯片能不能在目标频率下稳定工作。

很多人问：为什么不能直接把时钟当作特殊信号，让优化器顺手处理一下？答案很现实：普通 net 的优化目标是路径 delay，而时钟网络的核心目标虽然也有 delay，但更特殊的是要让所有叶子节点到时钟根节点的延迟尽量一致，同时还不能引入毛刺、不能让slew退化、也不能把功耗拉爆。普通布线工具根本不懂"平衡"这件事，所以一定有专门的步骤来做这件事。

在 Fusion Compiler 里，这个专门步骤就落在clock_opt阶段，具体执行的命令就是build_clock。这篇文章的目的只有一个：把build_clock内部那些一步步的子步骤逐个拆开，讲清楚每一步到底在算什么东西、改什么东西、打印那行 log 又意味着什么。我保证不整玄学，只说我们在项目里真正用得到的那些认知。

在拆子步骤之前，我先把结论摆出来：build_clock从本质上看，是一条从"抽象拓扑"走向"物理时钟树"的流水线。它不是在某一瞬间"啪"地生成一棵树，而是先做逻辑层面的树形结构设计，再落到物理版图上的金属线，然后再过一遍工程优化的筛子。每一步都有明确的输入和不完全相同的目标，理解了这个分层的思路，后面看日志就不会再觉得像天书了。

2. build_clock 的子步骤全景图：一次运行里的完整流水线

build_clock这个命令在 FC 里并不是一个原子操作，它内部至少可以拆成五个阶段。不同版本的工具对日志文案可能略有差异，但逻辑骨架大体一致。我在某芯片项目里完整跑过一次，配合-echo参数把每一步的启动时间、结束时间打出来，得到了下面这组阶段划分：

实际上，不同版本可能把阶段二和阶段三揉在一起，日志里往往是连续输出；但从工程实现上讲，逻辑树构造和物理布线永远是两个独立的动作，因为前者只需要抽象的 netlist 和时序库模型，后者必须拿到带 metal 层的 legalization 结果。

另一个容易忽略的细节是：build_clock跑完并不代表整棵时钟树的品质就定了。后面跟着的clock_opt里的其他子命令，还会对时钟网络做 delta delay 修正、对时钟 gate 单元做尺寸调整、对跨时钟域路径做额外平衡。所以如果把build_clock看成一个完整的太监流程，后面那些命令就是在给这份工作"打补丁"。

从输入条件看，build_clock之前必须先完成 placement，也就是至少有一份 legal 的布局结果，并且已经完成了时钟网络的布线资源预留。如果你在只有 raw placement 结果就强行跑build_clock，工具通常会警告说缺少完整的物理信息。这是很多人第一次踩的坑：把build_clock当成一个可以在任意阶段调用的水晶魔法。

下面这个表格是我自己整理的使用场景对照，方便判断什么时候该单独调build_clock，什么时候应该让它被clock_opt链式驱动：

注意第三种模式里的-build_only_clock_trees这一类选项，不同版本叫法不同，有些叫-cts_mode。它背后的逻辑就是把"建树"和"优化"拆开，分步检查，防止一个步骤崩掉连带后续优化全白跑。这也是我后来坚持在复杂模块上分开跑的原因。

3. 每个子步骤到底在算什么东西：从时钟源到叶节点的一路折腾

3.1 阶段一：时钟拓扑生成，先画出树的骨架

这一步做的是"逻辑树规划"。工具会把所有需要接收时钟信号的寄存器端子（CK 脚）全部挑出来，按照它们的物理位置进行分组，形成一个个 cluster。每一组内部的所有寄存器，未来共享一段共同的时钟路径，这样才有"平衡"的可能性。你没有看错，CTS 的第一步不是立刻插 buffer，而是先把叶子节点做空间聚类。

这个聚类算法的目标是让同一个 cluster 里的寄存器在物理上尽量靠近，同时对不同 cluster 之间保持合理的父子关系，最终形成一棵从根到叶、分支不要畸形发展的树。如果你对布局的 Congestion 很严重，会发现这一步里某些 cluster 特别大，这通常意味着那一块区域的寄存器密度太高，后续插 buffer 非常吃力。

这一步直接决定了最终 skew 的上限。很多情况下，同一个 clock domain 里如果寄存器分布成两个极端岛，工具在拓扑生成时就会被迫把树结构拉长，导致 root-to-leaf 的路径长度差异巨大。我见过一个案例：一个高密度存储区块和逻辑区块共用同一个时钟源，由于 clustering 决策不佳，最终全树 skew 超过 300ps，怎么优化都救不回来，最后只能手动加 dummy 负载来平衡。

3.2 阶段二：缓冲器插入，给树的每一根枝干加力

拓扑骨架定了之后，就该往上面挂硬件了。缓冲器插入阶段，工具会根据预先定义好的时钟 buffer 库（通常是一组专门为时钟设计的缓冲单元），沿着树的分支逐个插入 buffer，目的是把时钟信号从根节点传输到所有叶节点，同时保证每一层的 slew 和 fanout 都在合理范围内。

工具在这个阶段会做大量的"delay 匹配"动作。它不光要保证每个分支都能到达，还要保证两个对称分支上的延迟尽可能相等。这就要用到一个关键的概念：insertion delay，也就是从根节点到某一个叶子节点的总延迟。如果对称分支上插入的 buffer 数量不等，或者一个分支走了 metal 层而另一个分支绕路了，那么两个叶子的到达时间就会出现偏差，这个偏差就是我们所厌恶的skew。

所以你会发现，这个阶段的日志里经常出现inserting buffer cell BUF_...这样一串串信息，同时每插完一个 buffer，工具会调整树的分支结构，重新计算一遍各个叶节点上的期望到达时间。这个动作其实是在进行"全局偏差补偿"：哪个分支慢了，就在快的分支上故意加一个 delay buffer 来抹平差异。很多时候，skew 不平衡的原因不是 buffer 数量不同，而是线和 topology 的影响，所以这一步也包含了初步的布线预测。

3.3 阶段三：时钟网络布线，树从"逻辑"变"物理"

到了这个阶段，时钟树已经有一个逻辑上的 netlist，里面全是理想互连的抽象连线。而现实中的物理由一层一层的 metal 组成，每条线的电阻电容都会改变信号到达时间和 slew。于是工具会启动专门的时钟布线引擎，把时钟网络中的每一条 net 真正 route 到对应的 metal 层上。

在 FC 中，时钟路由与普通信号路由的最重要区别在于：它会对时钟网络做专门的 layer 分配和 wire width/spacing 控制，优先使用那些资源比较充裕、RC 特性更可控的层次。很多时候，你会在约束里看到set_clock_routing_layer这类命令，它们就是为了把时钟走线限定在特定的 BEOL 层，避免时钟信号和底层乱糟糟的信号抢资源。

这一步跑完，工具手里的时钟树就已经是带真实金属属性的了。它会在版图里看到：时钟长什么样、用了哪些 layer、有哪几根 net 特别长。从这个阶段开始，后面所有关于 delay 的估算都必须基于真实的 RC 提取，而不是那套理想互连模型。这一点非常重要，因为很多新手在 CTS 阶段把理想互连和真实互连混为一谈，导致理解的偏差。

3.4 阶段四：尺寸优化与性能补偿

布线结束后，时钟树的物理形态大致成型，但还有很多局部问题要处理。工具会对树上的 buffer 做尺寸调整，把那些负载过重、slew 退化严重的树杈换成更大尺寸的 buffer；同时会插入额外的 delay buffer 来修正局部 skew 或修复 hold 违规。这一步的名字五花八门，有时候看到日志里出现Optimizing字样，就是这个阶段在干活。

尺寸调整的核心权衡有三个：功耗、延迟、毛刺。buffer 尺寸越大，驱动能力越强，延迟也越短，但功耗上升；换小的 buffer 则相反。工具会在约束框架内进行一个多目标的优化搜索，尽量不违反 slew 和 prison 约束，同时保证时钟信号的翻转阈值一致性。你可能会觉得这看起来像是在"凑 Skew"--其实从工程上讲，就是在不断逼近一个可行的最小值。

另一个容易被忽视的是：这个阶段还会对跨时钟域路径做特别处理。当两个时钟域之间有同步器或 data transfer 时，工具会计算两组时钟树的相位对齐，一般会通过调整延迟来让 setup/hold 满足条件。又因为这种对齐多数情况下是跨树的，所以前面所说的所有操作，都要在多个时钟树的 context 里重新审视。

3.5 阶段五：时钟树时序验算，把最终结果交到下游

这一步已经在做分析工作而不是修改工作了。工具会用真实物理规则，估算整棵时钟树的 delay，并计算每个 flop 上的 slack，把整个时钟网络的品质数字化：比如root-to-leaf延迟、整棵树 skew、每一段 clock net 的 slew、以及是否满足 design rule。

这里最该关注的就是report_clock_timing的输出。这份报告里面不仅有 skew，还有各部分的 latency、slew 和几类违例。我个人习惯把这份报告保存下来，因为它是后续 debug 的基准，也是判断build_clock在不同 iteration 之间有没有发生突变的重要参考。如果阶段五输出的结果不满意，你可以把前面阶段的数据倒出来手动分析，而不必重新跑所有步骤。

阶段五结束之后，build_clock主体流程就完成了，但它往往不是流程的终点，后面还有optDesign -hold之类的工作来继续补漏整理。你可千万别觉得这里已经大功告成，事实上，下游的 hold 分析、芯片级的 CTS 整合还要专门处理。

4. 子步骤之间的互相拉扯：skew、latency 和功耗的三角关系

如果你只把上面的五个阶段看成依次执行的五件事，那就忽略了一个关键点：每一步之间都有强烈的耦合关系。最经典的就是skew与latency之间的零和博弈。拓扑生成阶段如果你刻意把叶子节点分成很多个 cluster，虽然每个 cluster 内部的 skew 好控制，但从全局看，不同 cluster 之间的 skew 又会拉大。反过来，为了追求更小的全局 skew，工具可能会牺牲 latency，而 latency 变大，又会恶化 hold 余量。

我实际跑过一个高频率模块，时钟周期是 800ps，当时为了把全局 skew 压到 50ps 以下，build_clock最后选择的insertion delay从 1.2ns 涨到了 1.8ns。这个延迟本身不影响 setup，但是对于跨时钟域路径、特别是那种通过 register 的时钟取反路径，就变得非常脆弱。后来我不得不给相关路径单独做 reset delay 调整才把 hold 修复干净。

功耗也是同一个博弈里面的主角。时钟网络通常是整个芯片的动态功耗大户，CTS 过程插入的 buffer 越多、选用的 buffer 尺寸越大，功耗蹭蹭就往上涨。有一次我为了优化一个模块的 skew，把一组 buffer 从BUF_X1全部换成了BUF_X4，结果逻辑单元功耗直接上涨了 12%。最后项目经理要求必须压回去，我只好重新调 cluster，靠扁平化树结构换回了功耗的下降。

这两条拉扯关系说明一件事：build_clock不只是"跑一个命令"那么简单，它的结果是你对设计多次权衡后的体现。因为工具内部在每一步都做约束下的优化，所以你的设计约束设置，比如set_clock_tree_options里对 target slew、target skew 的数值，会直接影响五个阶段的决策过程。

举个例子，如果target skew设置得极其激进，工具就会在阶段一优先做更小的 cluster、在阶段二插入更多的 delay buffer、阶段四反复做尺寸迭代。整棵树的风险对变化很敏感，金属线的 corner 一波动，skew 立刻跑飞。你可能得到一份很漂亮的 nominal skew，结果在 worst corner 上完全失控。

这也是为什么我在实际项目中都会留一定的 skew margin，而不是完全用工具默认值往死里压。通常做法是把约束里的target skew设得比实际要留的余量更宽，同时配合set_clock_tree_options指定 layer rule，这样工具在权衡时就不至于在 extreme 边缘疯狂试探。

除了 skew 和 latency，这里还有一对隐性纠缠：slew与fanout。同一个 buffer 驱动的分支越多，slew 越差，为了修 slew，该树杈就要换大的 buffer 或增加 buffer 级数，又会增加 latency。所以你在阶段三的布线结果上看到的某些 long net，往往是工具为了平衡 fanout 和 slew 之后的结果。不要一看到长线紧张，很多时候它就是一步最优化后的产物。

5. 实测输出解读：build_clock 的日志里那些行信息值得牢牢盯着

很多人跑build_clock的时候顺着日志往下翻，看到一遍遍重复的 buffer 列表就跳过了，然后等最终结果。但某些中间信息直接决定了最终效果，错过了就白跑一轮。我把日志里最值得盯的几类信息整理一下，你在下一次跑的时候可以对号入座。

第一类：cluster 的边界的构建信息。日志里如果出现cluster size = ...、number of clusters = ...这类字样，建议记下来。如果和上一次 iteration 相比，cluster 数量突然大幅增加，可刻可能是某个区域的寄存器密度出现了异常分布，需要回溯到 floorplan 去审视。

第二类：每一棵时钟树的skew随迭代的收敛曲线。FC 日志在优化过程中往往会反复打印中间 skew 值。你需要关注的不只是最终值，而是它收敛到靠后的那几次迭代里，斜率是不是已经平滑了。如果出现一次跳跃下降、后几次几乎不变的平台期，很可能是工具陷入了局部的极值，这时候靠控件参数往往很难再突破，需要你主动干预拓扑。

第三类：hold或者setup违例的中间统计。虽然build_clock的主要职责是构建时钟树，但它也会顺带做 phase alignment，所以你可以看到和 setup/hold 相关的调整信息。如果这个阶段已经有大量 hold 需要修，那么后续optDesign -hold会非常吃力，因为很多 hold 路径是跨时钟域的，后续互不影响的部分会变得很复杂。

第四类：关于slew和max_capacitance的违规报告。这种违规通常集中在阶段三布线之后。如果某个时钟线的slew怎么也修不干净，多半是金属层选择不对，或者是使用了不合适的 layer rule。这时候我会去检查set_clock_routing_layer的限制，确认有没有把信号线过细的层设到了时钟上。

第五类：routing resource的占用信息。时钟走线往往占资源多，如果日志里出现 resource 异常，可能是局部 congestion 把时钟树的路挤坏了。解决办法不是去调 CTS 参数，而是去改 floorplan 甚至调 placement。

日志本身因为工具版本不同差异很大，但没有关系，你只需要建立起 "哪类输出对应哪类问题" 的映射习惯。比方说看到一大堆inserting buffer to balance delay，那就知道工具正在进行延迟校正，如果你设置的 skew 太紧，这一步会重复很多遍。知道它在哪里耗时间，总比干看着 13h 进程傻等要强。

我在跑那个存储模块时，就是靠日志里 cluster 数量的突变判断出问题根源：某一块高密度 RAM 区域把寄存器全挤在一起，导致build_clock花了大量时间在这个 cluster 里做延迟补偿。后来我特意在那个区域加了一圈 placeholder 隔离，CTS 的时间直接降了 40%。所以排日志并不是浪费时间，是在给下一次 iteration 提供方向。

6. 我踩过的 CTS 坑和对应的破法

6.1 坑一：直接把整棵时钟树交给工具默认值就撒手不管

我刚开始做后端那阵，总是习惯把所有时钟参数完全交给工具默认。结果一跑，全局 skew 曲线就是降不下去。后来把set_clock_tree_options -target_skew从默认值改到了target_skew 0.06，同时指定了layer rule和clock tree dendrite check，效果就立竿见影。很多问题的背后不是工具弱，而是你没有告诉工具你的真实需求。

这种坑的本质是：默认参数通常是一种折衷值，既不想把功耗打爆，也不想把 skew 压到极限。但真正项目里，不同的模块、不同的时钟频率，所需要的侧重点完全不同。我建议把clk_tree_options独立成约束文件，按模块可控调节。

6.2 坑二：忽略了多角多阶在 CTS 阶段作用

很多人只会在setup holdviolation 的时候才想起 multi-corner，但 CTS 阶段涉及的 skew 本身就是一个角度分裂量。我曾经在只跑 typ 角的阶段把 skew 调得十分漂亮，结果到了 worst 角一测，hold slack 直接崩了。原因是树的 buffer 在不同 PVT 下的延迟漂移方向不一致，你看到的平衡其实是个假平衡。

解决思路：在做 CTS 阶段，一定要同时跑多个 corner，至少在 worst 和 best 各跑一次。并且，对于这种跨角位平衡的问题，工具里的set_clock_tree_options很多有关联 corner 的选项可以被明确指定。即便你没有用上 sign-off 的复杂配置，做一个基础的 CCC 扫描也比只看一个角强。

6.3 坑三：处理时钟树上的门控逻辑时太粗糙

时钟门控（clock gating）是现代设计中绕不开的东西。如果不做细致处理，build_clock阶段会把 gating cell 后面的那部分网络当作一条普通分支，造成 gating cell 前后延迟不均。工具虽然默认会做一定的特殊处理，但如果你把 enable 信号时序搞得太紧张，CTS 依然可能在 gating cell 附近大量插入 buffer，带来功耗块缓冲问题。

我的做法是：在约束里对时钟门控单元指定set_clock_gating_check，同时对门控 ICG cell 的 pin 做完整的 timing 约束设置。这样工具在 CTS 时就能知道：这里的 enable 端必须要有足够的 setup 余量。否则它会认为时钟 pin 是主导引脚，仓促插入 buffer 平衡它，结果导致门控逻辑本身时序崩溃。

6.4 坑四：忽略了实测中 clock net 上的 DRC 违规

build_clock跑完，如果以为时钟网络一定自带 DRC 干净，那就大错特错了。阶段四虽然做了 slew 和电容的优化，但簇里那些 "short" 和 "spacing" 违规，尤其是与普通信号网络的间距冲突，常常独立于build_clock被单独上报。这些违规通常要在详细布线时才能被完全解决，但时钟网络的 DRC 越干净，后道工作就越轻松。

我习惯在后 CTS 阶段用verify_clock_routes类命令单独验证时钟网络的 DRC。如果发现大量违规，我会先检查 metal 层的定义是不是合理，是否限制了时钟不能走某层。这个坑在层次化流程中尤其重，因为多个 partition 叠加时，时钟走的资源定义不一致就会出现这种问题。

6.5 坑五：在高阶制程里没处理好长线电阻

当到了 7nm 及以下工艺，金属的电阻率显著上升，长时钟线带来的 IR drop 和 delay 会非常明显。如果 CTS 阶段没有对长线做 sense 修正或采用更优的 layer rule，你会发现同样拓扑下，不同 corner 的 skew 差异能达到 100ps 以上。这个坑的解法是：在build_clock前就专门为时钟网络定义一套 high metal 层走线，并在物理上限制长线，同时考虑用多次迭代的方式让工具对长线做修正。

这些都是我和同事们翻了无数次车才总结出来的东西。到了最后，回归到那句老话：CTS 不是一个开关，开一下就有结果；它随时需要你的判断和干预。你越是理解build_clock内部每一步在做什么，越能在它出错时做出应对，而不是只能换个参数再跑一遍，满脸写满无知。希望这篇文章，能帮你把 CTS 这个"黑盒"打开一条缝。