Clock管理实战：异步时钟域与CTS技术详解

2026年3月23日，我重新理解了一遍Clock

起因是项目里那颗SoC的后端设计走到了时钟树综合（CTS）阶段，早上刚查完异步时钟跨域路径的violation，下午又发现两个时钟域的时钟树在物理版图里"打架"——CTS工具擅自把本该老死不相往来的异步时钟域sink往一起平衡，功耗和时序双双恶化。折腾到晚上，总算把Clock相关的那几条逻辑理顺了。趁热打铁，我把今天处理过的几类问题整理出来，刚好串成四条主线：异步时钟的mode divide到底怎么划；clock dedicated route为什么值得给时钟专门让一条车道；set_clock_group声明完之后，物理隔离怎么做才到位；以及CTS里sink的clock latency究竟是怎么被一步步控制的。

这些内容属于后端工程师、顶层集成工程师、甚至做DFT和低功耗设计的兄弟都会遇到的"Clock类"问题。我不打算写成理论教科书，就按今天实际处理问题的顺序，把能直接抄作业的命令、流程和判断逻辑都放出来，也会把一些只有趟过坑才知道的细节单独拎出来讲。

1. 异步时钟的 mode divide：从约束到物理的完整拆解

1.1 为什么必须给异步时钟"分门别类"

在数字芯片里，异步时钟域几乎无处不在：CPU主频跑到1GHz，旁边UART外设可能就挂个24MHz的慢速时钟，两者之间没有确定的相位关系。STA工具默认是"一根筋"的，它不认识什么叫异步，只会机械地把所有时钟的边沿组合都遍历一遍，然后挑出最悲观的那条路径去检查setup和hold。如果不做任何声明，这种检查会在异步路径上报出一堆根本不存在的violation，修timing的人会累死在假Violation里。

所以早期设计里，这个步骤是必须手工做的：在SDC里把时钟域之间的关系声明清楚。set_clock_groups -asynchronous就是干这个的核心命令，它告诉时序分析工具：这两个时钟域之间不需要做setup/hold检查，所有跨域路径都能走同步器或者异步FIFO的逻辑。

但到了今天，一个SoC动辄十几个PLL、几十个generated clock，同时还要覆盖function mode、test mode、DFT shift mode、低功耗retention mode。每个mode下时钟的"有效集合"不一样，同一个物理管脚上在不同mode下顶着的时钟名也可能不同。单纯写-asynchronous已经不够用了，必须进一步做mode divide——把时钟按工作模式、按物理存在情况切开，让工具只在真正需要分析的组合里花力气。

1.2 实操：mode divide的SDC写法与判断逻辑

一个典型的多模式场景我会这样处理。假设芯片有功能模式和扫描测试模式，功能模式用PLL时钟，测试模式用外部测试时钟；此外还有一颗独立的低速外设时钟，和功能时钟完全异步：

# function mode 主时钟 create_clock -name func_pll_clk -period 2.0 [get_ports func_pll_ref] create_clock -name uart_clk -period 41.6 [get_ports uart_ref] # test mode 时钟 create_clock -name shift_clk -period 10.0 [get_ports test_clk] # 同一个物理点在不同mode下出现两个互斥时钟 set_clock_groups -logically_exclusive \ -group {func_pll_clk} \ -group {shift_clk} # 真正的异步时钟域 set_clock_groups -asynchronous \ -group {func_pll_clk} \ -group {uart_clk}

这里的判断逻辑很关键：-logically_exclusive用于同一个物理点在不同mode下分别出现不同时钟的情况，比如功能模式和移位模式永远不会同时有效，所以这两个时钟在逻辑上是互斥的；-asynchronous用于完全独立的时钟域，它们可能同时运行，但相互之间没有任何timing关系。

对应的，-physically_exclusive用于物理上根本不会同时存在的时钟，比如同一根管脚在芯片工作在两种配置下分别连接了两颗外部晶振，这种场景其实比logically exclusive还要严格，通常用于特殊IO mux后的时钟。

这里有个特别容易踩的坑：分频时钟（generated clock）和源时钟的关系，千万不要随手划成异步。我在项目里见过有人看到divider后面挂了个大扇出的低频时钟，想当然写了一句set_clock_groups -asynchronous，把高频源时钟和低频分频时钟划成异步，结果把原本需要检查的同步路径全松掉了。分频时钟和源时钟在绝大多数情况下是有确定相位关系的，属于同步时钟，应该用create_generated_clock去定义，而不是丢进异步分组。CTS阶段看到一堆关键路径没人管，再回头查约束，时间和功耗都已经浪费了。

1.3 光有约束还不够：异步域物理上必须"划清界限"

在项目里吃过一次大亏之后，我养成了一个习惯：任何用了set_clock_groups -asynchronous的时钟域，都顺手检查一遍物理布局。

原因是这样的：set_clock_groups只改了时序分析层面的关系。你告诉STA工具这两个域不检查timing，但布局布线工具仍然会看到两个域的寄存器各自有一大堆。假如两个域的单元在物理上挨得太近，CTS工具甚至会把它们的时钟树往一起balance，本来应该完全解耦的两个时钟，布线完成后在物理上纠缠在一起。

这种纠缠带来的后果是隐蔽的：串扰噪声变大、IR drop出现局部热点、异步边界上的触发器偶发亚稳态。等你做硅后调试的时候，现象往往是一阵一阵的功能异常，极难定位。所以我的经验是：异步时钟域的拆分，必须从约束阶段一路贯彻到物理实现，直到时钟树形成之后再做一次复核。

2. clock dedicated route：给时钟信号让出"专用车道"

2.1 为什么时钟信号值得独占一层金属

很多人对时钟专用走线的理解是"为了让时序好看一点"，其实没那么简单。时钟信号在芯片里是最特殊的一类信号：它翻转频率最高、扇出最大、速度要求最苛刻。一颗高性能SoC里，全局时钟网络的负载可能达到几万个sink，而这个巨大的负载必须靠有限的金属层去驱动。

如果让时钟信号和普通数据信号混走在同一层金属上，会有三个问题。第一是串扰：数据信号翻转频繁，会对时钟信号的边沿产生耦合噪声，当噪声叠加在时钟边沿附近，就可能造成sink端的时钟沿抖动，这在小工艺节点下尤其致命。第二是绕线拥塞：时钟网络巨大的扇出会把普通信号绕线资源挤占掉，丢到后端就是满屏的DRC violation。第三是RC延迟不好控制：混走层金属的宽度、间距往往不统一，时钟路径上的RC延迟变数大，CTS算出来的延迟模型和实际签核结果差距就会变大。

所以先进工艺里普遍的做法是：给时钟信号"专用车道"，也就是clock dedicated route——把某几层金属预留给时钟信号，普通信号不允许占用。

2.2 专用走线层的选择与配套配置

哪几层金属做dedicated clock route，不是随便定的。在实际项目里，我们一般会结合工艺库的routing layer定义、供电网络（PG）规划、以及信号绕线资源综合判断。高层金属一般厚度大、电阻低、寄生效应小，是时钟走线的理想选择；但高层金属同时也要走电源和关键信号。所以一个常见的折中方案是：把M6/M7作为时钟主干道，M4/M5留给局部时钟和关键数据信号。

配置的时候，主要在两个层面做限制。第一个层面是物理实现工具里的route layer设置，例如在跑CTS之前对时钟网络设定可用的绕线层：

set_clock_routing_layer -clock clk_sys \ -preferred_layer {M6 M7} \ -route_type special_clock_route

第二个层面是给普通信号做绕线层限制，强制它们避开时钟专用层。这一步如果不做，工具在绕线资源紧张的时候还是会尝试"偷用"时钟层，dedicated就失去了意义。我记得有次项目时间很紧，省略了普通信号的绕线层限制，结果CTS跑完后时钟网络的DRC比普通信号还多，排查下来才发现是工具把一部分数据线绕到了高层，又把时钟线挤到了低层。

2.3 专用走线的绕线检查与局部区域处理

时钟专用走线真正难的不是全局设置，而是局部区域的处理。比如一颗大SRAM或者硬核IP内部通常没有时钟专用层的概念，时钟信号进入硬核区域后只能按标准单元轨绕线；再比如某个区域高层金属被IO ring和电源网络占满，时钟专用层在局部可能完全走不通。

这种时候我的建议是分三层去查：第一层查局部替代路径，通过shielding（屏蔽线）方式给时钟信号加保护地线，牺牲一点点绕线资源换信号完整性；第二层查绕线阻塞，如果拥堵点集中在某个小区域，可以考虑给该区域内的时钟网络临时切换到次优层，但要把切换点统一安排在sink比较密集的位置，避免散乱切换造成RC不均衡；第三层查时钟网络是否跨过了噪声源，比如高频振荡器附近、大电流开关电路上方，这类区域即使有专用层，也建议在时钟线两侧加屏蔽。

检查工具上，PR工具会在CTS之后给出时钟网络的绕线质量和delay报告，签核阶段还要用专门的SI引擎跑一遍时钟网络上的耦合噪声分析。如果看到某条clock net上的coupling-induced delay偏差超过预期，优先检查它是否违规走到了非专用层，而不是急着改CTS约束。

3. set_clock_group 的物理隔离：时序声明之外的"硬隔离"

3.1 三种clock group声明方式的适用场景对比

很多工程师把set_clock_groups当成一个"写完就没事"的命令，这是理解上的偏差。这个命令在时序分析层面的作用是明确的，但它在物理实现阶段的影响同样不能被忽略。先把三种方式放到一起看：

我之前在一个低功耗项目里，有个时钟既出现在功能模式，又出现在retention模式。功能模式下它是高频主时钟，retention模式下它完全被关掉，另一个慢速时钟接管。如果我只用-asynchronous声明，工具在retention mode下可能还会为了"潜在的异步关系"保留一堆时钟树buffer，白白增加漏电；正确做法是对功能时钟和retention时钟用-logically_exclusive，工具知道这两个时钟永不共存，就能把多余的时钟树资源省下来。这个区别在面积和功耗紧张的模块里，差距能到5%以上。

3.2 物理隔离不是"分个区"那么简单

set_clock_group之后的物理隔离，我理解成三步。

第一步是区域划分。对于两个交互频繁的异步模块，我给它们各画一个placement fence，把两个模块的标准单元限制在各自区域内，中间留出通道给同步器或者异步FIFO：

create_placement -fence [list {100 100 500 500}] -name async_uart_region create_placement -fence [list {700 700 1100 1100}] -name cpu_region

第二步是硬blockage。区域之间必须给时钟网络留出干净的走线通道，如果两个区域之间堆满了缓冲单元，时钟走线就会被迫绕远路，latency和skew都会恶化。我会在区域边界附近加hard blockage，只允许时钟线通过：

create_place_blockage -boundary [list {550 100 650 1100}] -type hard

第三步是同步器单元的摆放。这一步很多人忽略。跨异步时钟域的同步器或者异步FIFO的地址同步逻辑，应该放在两个时钟域的物理边界处，而不是由工具随机放置。随机放置的同步器可能离发送域近一点、离接收域远一点，导致跨域信号到达时间分布不均匀，CTS阶段很难对这些路径做平衡。我一般会在约束里对同步器路径打上set_clock_tree_exceptions -stop_pin，让CTS不要把它们和普通功能寄存器混在一个balance组里。

3.3 隔离做与不做的差距在哪里

说一个可以量化的例子。去年做过一个带两个独立音频时钟域的设计，刚开始没有做物理隔离，两个时钟域的寄存器混合摆放。CTS跑完，一个是26.7MHz的音频时钟，一个是49.152MHz的主音频时钟，它们的时钟树skew分别是87ps和112ps，看着好像还行；但两个时钟域之间的异步路径出现了一片hold violation，因为CTS工具尝试统一平衡两个域的时钟路径，导致其中一边的clock latency被拉长到接近另一个域的两倍。

后来我把两个音频模块用fence隔开，中间加了一条hard blockage走线通道，再给同步器路径设了CTS例外。同样的设计，两个时钟域的skew分别收敛到41ps和53ps，跨域hold violation全部清零。时钟树面积也小了大约15%，因为工具不再傻乎乎地把两个域的时钟树往一起凑。

这件事给我的感受是：异步时钟域的物理隔离，不是"锦上添花"，而是"必须做的硬隔离"。时序声明和物理隔离要一起提交review，光看SDC会漏掉一大半风险。

4. CTS 如何控制 sink 的 clock latency：一份可参考的完整流程

4.1 latency、skew、insertion delay，先分清这三件事

CTS阶段最常被问到的概念，是clock latency和clock skew到底什么关系。我的理解是这样的：

clock latency就是时钟信号从时钟源点（root）到达某个sink（比如触发器的CK端）所经历的总延迟，包括从PLL输出到时钟根节点的延迟，加上在时钟树里经过各级buffer/inverter的插入延迟（insertion delay）。skew则是同一时钟域内，不同sink之间latency的差值。

控制latency的目标，不是把它压缩到越小越好，而是让它在一个可控范围内，同时把skew压低。这里有一个权衡：latency压得太低，工具可能会选择更少的buffer级数，但这样时钟网络的驱动能力可能不够，transition变差，skew反而会恶化；latency放得太长，时序裕量被吃掉，setup很快就会出现violation。所以实际项目里，我会先把target latency和target skew两个约束同时喂给CTS工具，让它在两者之间找平衡。

4.2 从约束到CTS收敛的完整操作流程

我在一个中等复杂度SoC模块上验证过的流程，大致走六步。

第一步，定义时钟关系。SDC里把主时钟、生成时钟、时钟分组全部写清楚，这一步有任何遗漏，后面CTS再怎么调都是白费。第二步，设置CTS约束。关注的参数是target latency、target skew、max transition：

set_clock_tree_options -clock clk_sys \ -target_latency 2.2 \ -target_skew 0.12 \ -max_transition 0.5 set_clock_tree_options -clock clk_uart \ -target_latency 2.8 \ -target_skew 0.20 \ -max_transition 1.0

第三步，设置CTS例外。对同步器、锁存器、门控时钟单元、宏单元时钟端逐一检查，决定哪些pin要stop，哪些要non-stop。这里我习惯单独列一个脚本管理，因为例外列表会和约束一样频繁变更。

第四步，跑CTS生成时钟树。工具会在每个balance组内自动选择buffer种类、确定位置、连线。这个阶段我会关注报告里是否存在"unbalanced group"警告，如果有，说明有sink漏在组外，需要回查例外设置。

第五步，post-CTS优化。跑完时钟树后，我一般会先看skew报告和latency报告，再决定是否需要进一步优化。对于个别偏离太远的sink，可以用set_clock_tree_exceptions -clock_delay_balance单独调整它的balance目标。

第六步，迭代收敛。一次CTS跑出来的结果很少直接达标，常见情况是某些sink的transition超标、某些组的skew不满足、或者局部绕线拥塞导致工具把时钟树绕到很远。我的习惯是先看一组完整的报告再动手，而不是盯着某一个指标反复调。

4.3 控制latency的核心手段与实测心得

CTS控制sink的clock latency，本质上是在做三件事：选路由、选buffer、选平衡点。

选路由这件事，前面讲的clock dedicated route是基础。route层的选择直接决定了RC延迟的基数，高层金属延迟低、低层金属延迟高。同样目标的latency，用高层金属可能只需要两级buffer，用低层金属可能要三级甚至四级。所以在CTS前把routing layer设置好，比CTS后再去调buffer高效得多。

选buffer是CTS工具的核心能力，但工程师要做的是给工具提供正确的约束。比如set_clock_tree_options里的buffer种类，我会在库里挑出两到三种不同驱动强度的clock buffer，告诉工具优先用中驱动、必要时用大驱动，避免工具为了修transition而大材小用，把tree做得又大又耗电。

选平衡点是控制skew的关键。我的经验是，不要在CTS阶段对过于分散的sink强行追求绝对skew，死磕局部skew往往会引入更长的全局路径。更实际的做法是把sink按逻辑相关性分组，每个组内部做到skew足够小，组与组之间允许有合理的latency偏差，然后用同步器结构去吸收。

另外，在极高性能的模块里，我会考虑给顶层时钟网络做H-tree结构，或者用局部clock mesh，把latency做到极小、skew做到几十ps以内。但这类方案对功耗和面积代价很大，普通的时钟树加balance组已经足够，没必要上来就上重武器。

4.4 CTS常见的失败场景排雷

CTS跑挂的情况五花八门，但归纳起来主要就几类：

latency远超目标。最常见的原因是时钟网络绕线太长或者绕线层设错。我会先查有没有sink被fence逼到绕远路，再看route layer配置是否真的生效。skew收敛不了。往往是因为个别sink的负载特别重，例如一个memory的CK端带着巨大电容，工具为了驱动它不得不加入多级buffer，导致这个分支的latency比其他分支高出一大截。这种情况可以对重负载sink单独做set_clock_tree_exceptions，让它绑一个专用buffer，而不是和普通寄存器混在一个分支里。transition违规。很多时候不是buffer不够强，而是clock net上的sink分布太散，绕线过长。把大扇出sink拆开，插几个中继buffer，transition立刻就下来了。

我踩过的一个比较隐蔽的坑是：对门控时钟（clock gating cell）的处理。门控时钟单元的EN端口如果被工具当作普通sink处理，CTS可能为了平衡它而引入额外的buffer，导致门控信号到达时间出现偏差，时序上出现奇怪的glitch路径。正确做法是对门控单元的输出pin设置CTS例外，让EN端口走普通逻辑优化，不让它混进时钟树平衡组里。

5. Clock管理自查清单，以及两则踩坑复盘

5.1 每次跑CTS前我都会过一遍的清单

这些东西如果等CTS跑完再查，往往要多花两三轮迭代时间。我现在习惯在项目早期就把它们固定成checklist，每次修改时钟约束之后逐条过一遍：

• [ ] 所有主时钟和generated clock是否完整定义，频率是否和架构文档一致；
• [ ] 异步时钟域是否用set_clock_groups -asynchronous正确声明；
• [ ] 多mode互斥时钟是否用-logically_exclusive，物理互斥时钟是否用-physically_exclusive；
• [ ] 分频时钟有没有被误划成异步关系；
• [ ] 时钟树约束里target latency和target skew是否设置，是否和时钟频率匹配；
• [ ] 同步器和异步FIFO路径是否设置了CTS例外；
• [ ] 门控时钟单元的输出是否做了例外处理；
• [ ] 时钟专用走线层是否配置，普通信号绕线是否避开了专用层；
• [ ] 物理隔离fence/blockage是否覆盖了异步域边界；
• [ ] 是否有sink遗漏在balance组外，报告里有没有unbalanced警告。

这套清单看着琐碎，但几乎每一条都在真实项目里救过我。漏掉任何一条，后面要补的成本都是指数级上涨。

5.2 两则印象特别深的复盘

第一则是一个高速接口模块的时钟树transition超标问题。接口数字部分和模拟部分交接处有几十个高速触发器，时钟频率很高，CTS跑完transition报警一大片。我一开始不停加buffer，效果甚微。后来开着layout仔细查，发现那些触发器的位置被IO constraint钉得非常散，时钟绕线绕了大半个模块才到。解决方案不是加buffer，而是跟前端确认后调整了几个触发器的placement区域约束，让它们稍微聚拢，transition立刻达标。这件事让我记住了：CTS优化前先看物理分布，乱加buffer只是掩盖问题。

第二则关于异步时钟域的物理隔离，我在前面已经详细讲过了。简单说，两个音频时钟域因为没做fence，CTS把两个域的时钟树平衡到了一起，导致跨域hold violation和额外功耗。隔离做完之后，面积和时序都明显改善。从那以后，"set_clock_groups写了就要做物理隔离"成了我评审别人设计时必问的问题。

做后端这些年，和Clock相关的问题永远是最耗时、最容易反复的一类。时钟树一旦长歪了，改起来牵一发动全身。上面这些方法不一定适用于所有工艺和工具，但思考路径是可以复用的：先理清时钟关系，再做物理规划，最后才谈CTS精细优化。按这个顺序走，Clock类的坑大部分都能提前躲开。