企业官网建设流程全解析

数字后端做了几年，经常有新人问我：综合做完、floorplan摆完，接下来干什么？十有八九，答案就是时钟树综合（CTS，Clock Tree Synthesis）。这步在整个数字后端流程里，属于那种“看起来就是绕绕线、插插buffer，实际上一堆门道”的环节。芯片能不能按时收敛、功耗和面积是否可控、时序有没有隐藏的坑，很大程度上都压在CTS这块。这篇笔记，我就把时钟树综合的方法和实际项目里的操作心得摊开来讲，从核心原理到Innovus里的具体做法，再到那些文档里不会写的踩坑经验，一次说清楚。

1. 时钟树综合的核心思路与方案选型

1.1 时钟树综合到底在解决什么问题

先说个最朴素的比喻。时钟信号就像全芯片的“心跳”，所有寄存器都靠着这个心跳来同步工作。理想情况下，每个寄存器的时钟边沿应该同时到达，这样数据从一个寄存器传到下一个寄存器时，大家都踩着同一个节拍。但现实里时钟信号从时钟源（比如PLL的输出）到各个寄存器，要经过很长的布线路径，有的路径长、有的路径短，到达时间自然就有先有后。这个先有后的时间差，就是时钟偏斜，业内叫clock skew。

如果skew太大，就可能出现两种情况：数据到达太晚，目标寄存器采样不到正确值（setup违例）；或者数据到达太早，把还没被采样的旧数据冲掉了（hold违例）。所以CTS的核心任务非常单一：在满足物理约束和时序约束的前提下，插入buffer和inverter，把时钟信号从源头平稳地送到每一个时序单元的时钟端，让skew尽量小、clock latency尽量可控，同时功耗和面积不能失控。

这里还要分清两个概念：CTS之前我们管这叫时钟树综合，CTS之后还要做时钟树优化（CTO，Clock Tree Optimization）。CTS阶段主要解决全局skew和基本latency问题，CTO则是在布线前针对具体的setup/hold违例做局部优化，比如插delay cell修hold、调整buffer大小修transition。很多新人以为CTS做完时钟树就完事了，其实后面还有个拉锯战。

1.2 实际项目中怎么选时钟树结构

数字后端的时钟树结构，一般有三种常见形态：H树、网格树（Mesh）、以及最常用的缓冲树（Buffer Tree）。H树靠平衡的物理拓扑把时钟路径做到等长，skew天生小，但缺点是很吃布线资源，而且对block形状和摆放位置太敏感，自适应能力差，在真实项目里很少单独用。网格树靠顶层金属把时钟短接到一片区域里，skew能做到极小，但功耗和短路风险都很突出，一般只在超高速、对skew要求极其苛刻的模块里局部使用。

我们日常做的主流方案是缓冲树。它的思路很直接：从clock root出发，工具自动分析所有sink（寄存器时钟端、宏单元时钟端、时钟门控单元等）的位置，逐级插入buffer，把信号扇出摊平。缓冲树的好处是灵活，能跟着floorplan走，功耗和面积也可控，配合工具里的target skew设置就能满足绝大多数设计场景。

在Innovus里还有个常见选择，是使用balanced tree还是default tree。Balanced tree会强制工具按H树的思想去平衡各路径长度，收敛出来的skew更漂亮，但代价是buffer数量明显变多、布线资源消耗更大。默认模式则是工具按时序和物理拥塞程度动态决定树的形态，功耗和面积更好。以我自己的项目经验，除非是高速接口或者DDR相关的时钟域，默认模式足够用，把target skew和useful skew配置到位就行。纯为了skew好看而无脑开balanced tree，后期修congestion和DRC的时候会想哭。

1.3 CTS阶段的关键性能指标

做CTS不是跑完命令就拍屁股走人，你得会看报告、会判断结果好还是坏。核心指标我一般盯这几个：global skew（全局偏斜）、local skew（局部偏斜）、insertion delay（时钟插入延迟）、transition time（时钟信号跳变时间）、以及时钟网络的功耗和面积占比。

Global skew是所有sink里最大和最小时钟延迟之差，报告里经常叫clock skew。Local skew则要精细得多，它看的是时序路径上有时序关系的两个寄存器之间的skew，比如一个launch flop和一个capture flop在物理上紧挨着，那么它们之间的skew才真正影响这条路径的时序收敛能力。很多新人只看global skew，结果全局数字挺好看，一到时序分析就疯狂报错，原因就是local skew被人忽略了。

Insertion delay指从clock root到sink的总延迟，它决定了时钟树对片外或片内其他模块的时序接口，过大会影响I/O时序，过小又可能导致CTS难收敛。Transition time则是时钟信号从一个电平跳到另一个电平的时间，太大会导致寄存器采样不稳定，太小则说明buffer驱动过强、功耗浪费。这些参数互相牵制，所以CTS本质上是个平衡的艺术，不是单点最优。

2. 时钟树综合前的准备与关键配置

2.1 CTS之前必须完成的检查项

很多人一拿到place后的设计就急吼吼地跑CTS，这是大忌。CTS是全局性操作，前面任何一步留了隐患，到这里都会成倍放大。我习惯在CTS前跑一轮pre-CTS检查清单，每项都确认没问题再动手。

第一项是时钟定义检查。用report_clock_tree和check_timing把时钟源、时钟门控、生成时钟（generated clock）都确认一遍。这里最常见的坑是generated clock的master pin选错，导致CTS的root不对，后面怎么调都白费。第二项是scan chain check，扫描链上的shift时钟和功能时钟必须正确mux，否则CTS时工具会把scan clock和func clock当成两个不相干的domain处理，时序会出大问题。第三项是floorplan检查，硬宏（hard macro）的pin位置是否合理、blockage是否堵住了时钟走线方向、端到端的channel有没有预留，这些都会直接影响CTS的绕线质量和拥塞度。

还有一项容易被忽略的是power intent。时钟树上的buffer用的通常是标准单元库里的单元，它们的电源域必须和所在区域的逻辑一致，如果floorplan阶段没把power domain切干净，CTS插出来的buffer可能直接被工具放在没有power connection的区域，后期要么修起来麻烦，要么直接造成IR drop问题。

2.2 时钟树综合spec文件的编写技巧

CTS spec是整个CTS阶段的“剧本”，Innovus、ICC2这些工具都是照着spec来干活的。Spec里定义了时钟树的root、sink、需要balanced的时钟组、skew目标、最大transition、最大insertion delay、可用的buffer/inverter单元列表、禁止使用的层和区域等。新手最容易犯的错就是从项目模板里拷一份过来改两笔就上，结果每个clock domain的约束要求其实差别很大。

我写spec时有一个习惯：把时钟按功能分成几类，不同类型的时钟给不同的skew和transition目标。比如核心逻辑时钟，对skew要求适中、但时钟频率高，transition必须控制紧一些；低速外设接口时钟，频率低、时序裕量大，skew给松一点能省大量buffer，功耗和面积都划算；高速DDR或者SerDes相关的时钟，那是特殊对待，不仅skew目标紧，还要在旁边加useful skew的约束，让工具能利用skew去优化关键路径。

还有一个细节是关于sink的。Spec里可以手动指定某些pin是sink，比如宏单元（memory）的时钟pin、模拟IP的时钟输入，这些如果不显式加进去，工具可能会漏掉或者用默认方式处理，后续很容易出现局部skew超标。手动加sink时还要注意把inverter的input pin设成ignore，否则工具会把反相器的输入也当成sink加进去，做出一个废树。

2.3 Useful skew的正确打开方式

Useful skew（也叫skew scheduling）是个好工具，但也容易坑人。它允许非零skew存在，利用launch clock晚到或capture clock早到来给关键路径让出时间裕量，从而修掉setup违例。听着很美好，但它的代价是让别的路径的时序压力变大，或者让hold变得难修，所以实际中使用useful skew得“定向”而不是“全局”。

在Innovus里开启useful skew的主要方法是给时钟组设置max useful skew的值，并且配合set_clock_tree_options里的useful skew mode。这里我的经验是，只有当某几条路径的setup violation很顽固、通过优化数据路径已经修不动的情况下才启用，而且max useful skew一开始给个几十皮秒的量级试跑，看看整体时序有什么变化，切忌一上来就设个几百ps，那是给自己找麻烦。

另外，useful skew还会影响hold修复的难度。因为hold修复需要在时钟路径上插入delay cell，如果本来就有useful skew，CTS后的hold slack会变差，后期ECO修复的量也会增加。所以setup和hold像天平的两端，用useful skew修setup时，一定要同步跑一遍post-CTS hold检查，别按下葫芦浮起瓢。

3. 时钟树综合实操流程与关键实现

3.1 从place到CTS的完整操作步骤

这里我以Innovus工具为主线，把从place完成后到CTS结束的典型流程走一遍，命令和参数都是我在项目里实际用过的，可以直接参考。

第一步，读入设计并做预处理。Place完成后先跑optDesign -preCTS做一轮预CTS优化，把数据路径上的setup问题粗修一轮。这一步的主要目的是让CTS开始时数据路径的时序状态尽量干净，工具做时钟树时能更专注于skew和latency的收敛，而不是同时操心一堆setup违例。

第二步，创建并检查CTS spec。用create_clock_tree_spec生成初始spec文件，然后手动检查或修改关键参数。我通常会重点看这几行：Clock tree name、Root、Skew group、Target skew、Target transition、Insertion delay target。如果有多个时钟域需要平衡，可以在spec里用BalanceClockTree加上时钟组名。

第三步，执行CTS。命令是clock_design_opt，这个命令会一次性完成时钟树的综合和优化。跑之前我会先ccopt_design -cts，只做CTS不做优化，查看报告确认时钟树本身的指标是否达标，再跑clock_design_opt做全面优化。分两步走的好处是问题定位更清晰，如果结果不好，一眼就能看出是CTS阶段的问题还是优化阶段的问题。

第四步，检查CTS结果。跑完CTS后，用report_clock_tree和report_clock_timing分别看时钟树结构和时序报告。重点看global skew、per-clock-domain skew、还有每个domain的max transition是否超限。我一般还会打开时钟树视图，在GUI里看一看有没有特别长的绕线或者大量buffer挤在一个区域的情况，这种东西只看数字往往是看不出来的。

第五步，post-CTS优化和hold修复。CTS完成后数据路径上会暴露出新的setup和hold违例，这时跑optDesign -postCTS和optDesign -hold分别处理。注意hold修复通常在setup修完之后单独跑，因为如果先修hold再修setup，可能会把hold又弄坏。

3.2 Innovus中时钟树相关核心命令与参数

工具命令这种东西，用多了就熟，但新手往往不知道该重点记哪些。我把CTS阶段高频用到的几组命令整理成了一张速查表，项目里可以直接对照着用。

我这里特别说一下set_clock_tree_exceptions。这个命令处理的是时钟树上的特殊点，比如某个pin需要stop（不加buffer）、某个macro的时钟pin需要作为leaf处理、某段net不允许插buffer。我之前遇到过一个模拟IP的时钟pin，工具总是给它加buffer，导致模拟模块的时钟相位不对，最后就是用set_clock_tree_exceptions -stop_pin指定这个pin才解决的。所以遇到奇怪的CTS行为，先别急着怀疑工具坏了，检查一下exception是不是有遗漏或者误设。

3.3 congestion map和density map怎么从Innovus的database里导出来

这个是我被问过最多的问题之一，特别是刚接手别人项目、想看place阶段的拥塞情况和密度分布时。Innovus里查看和导出congestion map、density map的方法其实不复杂，但新手经常在GUI里点半天找不到。

一个直接的办法是在GUI里通过菜单操作。打开Innovus GUI后，点击菜单栏的Tools，选择Global Status，或者直接在命令行敲summaryReport，可以查看基本的congestion概览。但要看具体的map图，需要在GUI的物理视图（Physical View）里，通过菜单Display -> Congestion，然后选择对应的layer和type。Density map则在Display菜单下的Density里，可选cell density、power density、pin density等不同模式。

如果你需要在命令行里把图导出来，方便放到报告里或者分享给同事，可以用下面的方法。Innovus支持通过saveImage命令截图，先用菜单或命令打开对应的map显示，再用saveImage把当前视图保存成图片文件。命令格式大致是saveImage -file congestion.png -format png。但一定要先把congestion显示打开，不然截出来的就是一张普通的版图。

另外还有一个思路是直接导出congestion数据，而不是图。用命令report_congestion -report_type summary可以输出拥塞数据文本，再用脚本（比如Perl或者Python）把拥塞热点画成自定义的热力图。这个方法灵活，能给到更直观的热点区域标识，适合做flow的人。如果只是想快速看一眼，GUI加saveImage足够了。

3.4 实际操作里怎么判断CTS结果能不能继续往后走

CTS跑完不能光看报告零违例就说可以了，我一般还有一套额外的“体检项”。

第一项是打开时钟树buffer的分布图，看看是不是有几个区域buffer堆得特别密。这种情况通常意味着这些区域的sink特别集中或者布线资源紧张，后续跑到Route阶段大概率会出congestion，甚至引发DRC问题。如果发现这类区域，我会回到floorplan阶段微调一下布局，把高密度区域的逻辑疏散一些，或者调整blockage，而不是硬顶着继续走流程。

第二项是检查时钟树上的串扰风险。时钟网络是最敏感的网络之一，如果CTS后的时钟路径上有长距离并行线，或者和高速数据路径平行走线，后期布线完成后串扰带来的delay变化会非常大，甚至直接让timing崩掉。Innovus里可以用report_clock_tree -traverse看时钟path的物理走线，挑出特别长的net检查。最好是跑一轮快速布线（trial route）再评估CTS质量，因为trial route后的数据比CTS刚完成时更接近真实情况。

第三项是功耗评估。时钟树一般是芯片里功耗的大头，尤其在低功耗设计中，CTS好不好直接影响动态功耗的最终数字。跑完CTS后用report_power看一下clock网络的功耗占比，如果明显高于预期，需要检查是不是buffer尺寸偏大、插得过多，或者时钟门控没起作用。有时候单纯把一些load小的分支换成小尺寸buffer，功耗能省下一大截，代价只是稍微增大一点skew，但如果这个domain的skew裕量足够，这笔交易完全划算。

4. 时钟树综合常见问题与排查技巧实录

4.1 时钟树skew超标但找不到原因

项目里最磨人的问题之一就是skew超标，而且报告里看不出明显的root cause。我自己排查这种问题有一套固定的顺序。

第一步看报告本身。用report_clock_timing -type skew按group输出所有sink的skew分布，找出最大的几个outlier。如果是同一个group里某几个sink特别慢或者特别快，先看它们的物理位置是否有共性，比如是不是聚在某个角落、是不是在一个深沟槽（channel）的尽头、是不是在hard macro的遮挡后面。物理位置有共性的，大概率是绕线路径异常，打开时钟树视图沿着出问题的path走一遍就能看到是不是走了远路。

第二步查sink的属性。有些pin被工具识别成sink，但实际物理上离其他sink很远，或者这个pin的时钟负载特别小。比如某些ICG（integrated clock gating）单元的时钟端，和普通register的时钟端混在一个group里，容易造成sink之间电容差异大，skew自然难收敛。这时候看看能不能把这个ICG的时钟pin单独列成一个sink group去平衡。

第三步检查exception。之前加过stop_pin或者dont_touch的时钟路径，很容易变成skew outlier。我遇到过一个大IP的时钟pin设了dont_touch，结果它后面带的几百个寄存器和主树之间产生了巨大skew，最后把dont_touch的范围收缩到最小必要区域才解决。所以排查时要反查exception，看看是不是自己挖的坑。

4.2 post-CTS阶段hold违例越修越多

修hold是每个后端工程师的“老朋友”，但post-CTS阶段hold越修越多是很多新人的噩梦。这个问题的根因往往不是hold本身难修，而是修复的时机和方法不对。

CTS后出现的hold违例，和数据路径上cell的delay以及时钟路径上的buffer delay都有关系。如果直接用optDesign -hold去插delay cell，工具会在数据路径上大量插入buffer来补偿时钟延迟差，但这些buffer会改变数据路径的电容和延迟，影响setup，更麻烦的是插进去的delay cell本身也要时钟同步，密集插入会挤压布线资源，导致局部拥塞，而拥塞又反作用在时钟树上，让skew恶化。

我的习惯是先用report_clock_timing -hold看一下hold违例的分布，如果违例集中在某几个clock domain，先看这个domain的useful skew是不是设置得太激进，如果是，先调整spec里的useful skew设置重跑CTS，这往往比后期猛插delay cell高效得多。如果违例分布很散，那再用optDesign -hold修，同时用set_clock_tree_options把时钟树的max transition稍微收紧一点，给留出余量。

还有一个容易忽略的点：hold修复用的delay cell，一定别插入到时钟路径上。有些工具优化策略在某些模式下会做出这种坑操作，直接污染时钟树。跑完hold修复后建议习惯性重跑一次report_clock_tree，确认时钟树的结构没有被优化器动过。

4.3 时钟树上的信号完整性问题和功耗陷阱

时钟网络的信号完整性（SI）问题，比数据路径上的SI更难修。因为时钟信号如果受到串扰影响，产生glitch或者延迟漂移，影响的是一大片寄存器的采样窗口，属于系统性风险。在CTS阶段就要提前布局，后期才能少遭罪。

一个很实用的办法是给时钟网络加shielding（屏蔽线）。在floorplan阶段或者CTS后的优化阶段，手动或者用工具自动在关键时钟路径旁边加VSS/VDD屏蔽线，能大幅减少串扰耦合。但屏蔽线会消耗布线资源，所以一般只对长距离的时钟主干和跨模块走线做屏蔽，普通分支就靠width/spacing约束来控制风险。

功耗角度，时钟树插入buffer的数量和尺寸直接影响动态功耗。有个小技巧，CTS spec里可以把max transition稍微放宽一点，例如从默认的60ps放宽到80ps，工具就能用更小的buffer，数量也没那么多，功耗能省不少，代价是skew会变大一点点，但很多时候skew预算并没有用到极限，省下这笔功耗很划算。这个思路我喜欢叫“按需定价”，每个指标在有裕量的前提下，尽量去换省功耗省面积。

4.4 多时钟域交互时的时钟树处理

现在的芯片基本都是多时钟域设计，CTS时最怕的其实是跨时钟域路径上的时序问题没有得到正确约束。如果两个时钟域之间的同步器（synchronizer）没设好false path或者max delay约束，CTS工具会尝试去平衡两个毫不相干的时钟域，白白浪费大量buffer。

我一般会在CTS之前，用set_false_path把跨时钟域的同步路径标注干净。注意，这里不是说所有跨时钟域路径都要设false path，而是同步器内部的跨域路径设false path，同步器下游的路径还是要保留时序约束。另外，如果两个时钟域之间有频率倍频关系（比如200MHz和400MHz），CTS时要给倍频时钟单独建skew group，并设置好两个group之间的关系，否则工具很难做到各自的收敛目标。

跨时钟域的CTS还有一个容易踩的坑：如果一个时钟域是从另一个时钟域分频出来的（比如MMCM/PLL生成的clock），那么spec里的root必须是在分频器输出上，而不是上游的源时钟。放错root之后，整个group的sink路径会被强行加了一长段逻辑，skew和latency都很难看，而且这种问题报错不一定明显，往往要等仿真或者时序收敛时才暴露。

5. 时钟树综合的进阶用法与个人经验总结

5.1 低功耗设计中的时钟门控与CTS协同

低功耗设计里，时钟门控（clock gating）地位极高，而CTS和clock gating的配合直接决定了功耗优化效果。时钟门控单元（ICG）被插入在逻辑综合阶段，但真正让它发挥省电效果，要靠CTS阶段把它正确地挂进时钟树里。

CTS时，ICG的时钟输入是作为一个sink接入时钟树的，而ICG输出的gated clock又会驱动后面的一堆寄存器。工具会把ICG从sink到它的负载作为一个独立的子树来处理。这里有个关键点：ICG的输入时钟端必须设置成CTS的through pin或者sink，否则工具可能不会为它正确构建子树。很多时候clock gating省电效果不佳，就是CTS阶段没把ICG处理对，导致ICG后面的寄存器仍然被当作直连时钟处理，gating形同虚设。

另外，多级clock gating的树结构（比如一个enable控制一级ICG，再级联下一级ICG）在CTS里也容易出问题，主要是不好控制各级之间的skew。我的做法是：对多级ICG结构，把第一级ICG的时钟输出设成clock tree的through pin，手工引导工具的平衡策略，让每一级的relative skew都能满足要求，而不是放任工具自动处理。

5.2 CTS与布线阶段的衔接要点

CTS做完不是终点，后面还要经历布线、STA signoff、物理验证等一系列阶段。这之间的衔接如果没处理好，CTS阶段辛苦攒下来的时序裕量可能在后面被消耗光。

最大的坑是布线后的时钟树走线变化。CTS阶段生成的时钟树是理想化或者粗略布线后的结果，真实布线完成后，时钟net的电容、电阻会变化，skew和latency都会跟CTS报告有偏差。所以业界成熟的流程都是在CTS后加一轮时钟树布线（Clock Net Routing），然后在signoff STA里基于真实时钟树布线结果重新提取RC和计算时序。如果你用的是只做了一次全局布线的快速流程，一定要记得在最后signoff前重新提取时钟网络的实际寄生参数。

还有一点是关于时钟树的SPEF提取。正式流程里，CTS后要单独对时钟网络做高精度RC提取（比如用starrc抽取clock net），因为在片内片上误差（OCV）分析里，时钟路径的悲观度最大，提取精度直接关系到芯片能不能跑到目标频率。很多小团队在自研流程里忽略了这步，用默认的全局提取精度去跑，结果在实测时发现时序和仿真对不上。精度这东西，平时感觉不到差别，关键时刻就是救命的。

5.3 我积累下来的几条CTS实操心得

做了这么多项目，踩了这么多坑，我把自己觉得最值钱的几条CTS心得整理一下，分享给同样在后端这条路上走的人。

第一，CTS的spec一定不要图省事复用旧项目的。每个芯片的频率、规模、floorplan、时钟拓扑都不一样，spec里的参数哪怕看起来很像，实际最优值也可能相去甚远。我见过有人图省事，连续几个版本沿用同一个spec，结果skew和transition的margin被慢慢吃光，最后在signoff阶段才爆雷。

第二，CTS跑完看报告时，别只看平均值，要看最大值和最小值。平均值漂亮的时钟树，可能有一堆个别的sink正在悬崖边上。report_clock_tree -detail的每一行都值得认真扫一遍，特别是那些transition、skew指标接近上限的sink，提前想办法处理，好过最后在tapeout前手忙脚乱地修。

第三，在数控芯片这种对时序非常敏感的设计里，CTS的迭代往往不止一轮。我通常做完一版CTS后会拿它去跑一轮完整的post-CTS STA，看全芯片的setup/hold情况，如果整体裕量还有富余，就回头把target skew合理收紧一点，换取更好的功耗和面积；如果整体裕量紧张，就反过来放松skew，给数据路径让路。时钟树和数据路径，是跷跷板的两端，永远在博弈中找平衡。

第四，也是最重要的一点：永远给自己留一条后路。CTS阶段的每一步，都建议设置好可回退的checkpoint。因为CTS一旦跑得不对，数据路径的优化结果可能也被污染了，有checkpoint就能快速回到某个干净的状态重新开始，不需要重新跑place和optimize。我自己的习惯是，在CTS前、CTS后、hold修复后各存一个snapshot，每个关键节点能保存数据库就保存，别怕占硬盘。

时钟树综合这步，放在整个数字后端流程里看，既不是最炫技的环节，也不是最耗时的环节，但它是最能体现一个后端工程师对时序本质理解程度的环节之一。把CTS的原理吃透、把工具命令用熟、把各种异常状况都摸过一遍之后，你会发现后端的其他环节也突然“通”了很多，因为CTS就像一根线，串起了floorplan的效率、时序的收敛、功耗的平衡和布线的顺畅。这期的笔记就到这里，下次有空我再聊聊时钟树综合之后的路由优化和signoff阶段那些事。