1. 时钟树综合到底在解决什么问题数字IC后端流程里时钟树综合Clock Tree SynthesisCTS是绕不开的一道坎。前端设计把RTL写完之后综合出来的网表里时钟端口到各个触发器的路径是理想化的工具默认时钟到达所有寄存器的时间完全一致。但到了物理实现阶段金属连线的RC延迟、缓冲器的插入延迟、不同路径的绕线长度差异都会让时钟信号到达各个触发器的时间产生偏差。这个偏差就是时钟偏斜Clock Skew偏斜太大建立时间和保持时间就守不住芯片直接跑不起来。CTS的核心任务就三件事把时钟信号从根节点扇出到所有需要时钟的时序单元控制偏斜在可接受范围内同时把时钟树的功耗和面积压到合理水平。听起来简单做起来全是细节。我做过几个不同工艺节点的项目从40nm到7nm都有每次CTS都会遇到不一样的问题但底层逻辑是相通的。OCC电路是CTS里一个特殊的存在。OCC全称On-Chip Clocking有些文献也叫On-Chip Controller它本质上是挂在时钟树上的一个测试逻辑模块用于在扫描测试模式下切换时钟来源。正常功能模式下OCC让功能时钟通过测试模式下OCC切换到测试时钟并且能够控制时钟脉冲的数量和频率。问题在于OCC电路本身有时序单元它也需要时钟而且它的时钟路径往往和功能逻辑的时钟路径交织在一起CTS工具处理不好就会导致OCC附近的时钟树严重不平衡。这篇文章面向的是已经了解数字后端基本流程、正在做或准备做CTS的工程师。我会从OCC电路对时钟树的影响讲起拆解时钟树平衡的具体策略给出可复现的配置思路和参数选择依据最后分享几个我在实际项目中踩过的坑和排查方法。不管你是刚接触CTS的新手还是做过几个项目但总在OCC附近翻车的老手应该都能找到有用的东西。2. OCC电路对时钟树结构的真实影响2.1 OCC电路的基本结构与时钟需求OCC电路通常由几个关键部分组成时钟选择器Clock Mux、脉冲发生器Pulse Generator、分频计数器Divider Counter以及同步逻辑。时钟选择器负责在功能时钟和测试时钟之间切换脉冲发生器根据扫描链的移位和捕获需求产生精确数量的时钟脉冲分频计数器则用来降低测试时钟频率以适应ATE设备的限制。这些模块里脉冲发生器和分频计数器都是时序逻辑它们需要时钟来驱动。而且这些时序单元对时钟的质量要求并不低——脉冲发生器如果时钟偏斜太大产生的脉冲宽度就会不一致扫描测试的shift和capture时序就可能违例。更麻烦的是OCC电路通常放在时钟树的根部附近它的时钟路径和功能时钟路径共享很大一段公共路径CTS工具在平衡时钟树时必须同时考虑OCC内部寄存器和功能寄存器的时钟到达时间。我见过一个典型场景某项目在CTS之后做时序分析发现OCC模块内部的脉冲计数器出现了保持时间违例。查了半天原因是CTS工具把OCC内部的时钟路径当成了普通功能路径来平衡但OCC内部的寄存器距离时钟根节点更近时钟到达时间比功能寄存器早了一大截保持时间自然守不住。这个问题的根源在于CTS工具默认的平衡目标是把所有sink点的时钟到达时间拉到一致但OCC内部的sink点和功能sink点对时钟延迟的需求其实是不一样的。2.2 OCC电路引入的时钟树平衡难点OCC电路给CTS带来的第一个难点是时钟域交叉。功能时钟和测试时钟在OCC的时钟选择器处汇合CTS工具需要为这两个时钟分别建树但又要在选择器输出端之后合并成一棵树。如果工具处理不当两个时钟域的缓冲器插入策略会互相干扰导致其中一个时钟的偏斜被优化了另一个反而恶化。第二个难点是脉冲发生器的时钟路径特殊性。脉冲发生器内部的计数器需要在每个时钟周期翻转它的时钟路径延迟直接影响脉冲宽度的精度。如果CTS工具把脉冲发生器的时钟路径和普通功能寄存器的时钟路径做同样的平衡处理脉冲发生器可能会因为时钟到达太晚而错过捕获窗口。我在一个28nm项目里遇到过这个问题OCC产生的测试脉冲宽度比预期窄了将近15%导致扫描链的capture阶段偶尔失败。后来单独给脉冲发生器做了一条短路径问题才解决。第三个难点是OCC电路的物理位置约束。OCC通常被放在芯片的时钟根节点附近这个区域往往布线资源紧张CTS工具在这里插入缓冲器时容易遇到布线拥塞。拥塞会导致绕线长度增加进而增大时钟延迟和偏斜。更糟糕的是如果CTS阶段没有预留足够的布线资源到了绕线阶段才发现OCC附近的时钟线绕不出去那就只能回头改CTS整个流程要重跑一遍。2.3 为什么OCC电路不能简单当作普通逻辑处理有些工程师会觉得OCC电路不就是几个寄存器加一个Mux吗CTS工具应该能自动处理。这种想法很危险。普通功能逻辑的寄存器对时钟偏斜的容忍度相对较高因为数据路径的延迟通常远大于时钟偏斜。但OCC电路不同它的脉冲发生器和分频计数器工作在测试时钟下测试时钟的频率虽然比功能时钟低但对脉冲宽度的精度要求反而更高。ATE设备在捕获测试响应时采样窗口是固定的如果OCC产生的脉冲宽度偏差太大采样就会出错。另外OCC电路的控制信号比如扫描使能、测试模式选择通常来自芯片的测试端口这些信号的时序路径也需要在CTS阶段一并考虑。如果CTS工具只关注时钟树本身的平衡忽略了这些控制信号的时序测试模式下的建立时间和保持时间就可能出问题。我在一个项目中遇到过测试模式下的建立时间违例查到最后发现是OCC的扫描使能信号路径太长而CTS阶段没有对这条路径做约束。3. 时钟树平衡策略的选型与参数计算3.1 全局平衡与局部平衡的取舍CTS工具通常提供两种平衡策略全局平衡Global Skew Balancing和局部平衡Local Skew Balancing。全局平衡的目标是把整个时钟树的所有sink点拉到同一个时钟到达时间局部平衡则允许不同区域有不同的目标延迟只要区域内部的偏斜满足要求即可。对于包含OCC电路的设计我通常推荐混合策略对功能逻辑的时钟树做全局平衡对OCC电路及其附近的测试逻辑做局部平衡。原因在于OCC电路的时钟路径和功能逻辑的时钟路径在物理上虽然共享根节点但它们的时序需求不同。功能逻辑追求的是所有寄存器时钟到达时间一致而OCC电路追求的是脉冲发生器时钟路径尽可能短且稳定。如果强行把两者拉到同一个目标延迟要么功能逻辑的偏斜被牺牲要么OCC的脉冲精度被牺牲。具体操作上可以在CTS工具里给OCC模块的时钟sink点设置独立的skew group让工具单独为这个group做平衡。比如在Innovus里可以用set_clock_tree_exceptions命令给OCC模块的时钟端口设置-skew_group属性在ICC2里则通过set_clock_tree_options的-skew_group选项来实现。这样工具在平衡时钟树时会把OCC的sink点和功能sink点分开处理避免互相干扰。3.2 目标偏斜值的计算依据目标偏斜值Target Skew是CTS最关键的参数之一。设得太松时序守不住设得太紧工具会插入大量缓冲器功耗和面积飙升。目标偏斜值的计算需要从时序预算反推。假设设计的功能时钟周期是T建立时间要求是Tsu保持时间要求是Thold数据路径的最大延迟是Tdata_max最小延迟是Tdata_min。那么建立时间对偏斜的要求是Skew_max_setup ≤ T - Tsu - Tdata_max保持时间对偏斜的要求是Skew_max_hold ≤ Tdata_min - Thold实际的目标偏斜值应该取这两个约束中更严格的那个再留10%到20%的余量。举个例子如果T2nsTsu0.1nsTdata_max1.5ns那么建立时间允许的最大偏斜是0.4ns。如果Tdata_min0.2nsThold0.05ns那么保持时间允许的最大偏斜是0.15ns。这时候目标偏斜应该设在0.12ns到0.13ns左右而不是0.4ns。对于OCC电路目标偏斜值需要单独计算。OCC的脉冲发生器通常工作在测试时钟下测试时钟周期一般是功能时钟周期的4到10倍。假设测试时钟周期是10ns脉冲宽度精度要求是±5%那么脉冲发生器的时钟偏斜应该控制在0.5ns以内。这个值通常比功能逻辑的目标偏斜宽松但OCC内部的寄存器数量少路径短工具实现起来反而更容易。3.3 缓冲器选型与插入策略CTS工具在平衡时钟树时会自动插入缓冲器但缓冲器的类型和插入策略需要工程师提前配置。缓冲器的选型主要考虑三个因素驱动能力、延迟和功耗。驱动能力强的缓冲器延迟小但功耗和面积大驱动能力弱的缓冲器功耗小但延迟大可能需要多级级联。对于OCC电路附近的时钟路径我倾向于选择中等驱动能力的缓冲器并且限制级联级数不超过3级。原因是OCC电路通常位于时钟根节点附近这里的时钟线需要驱动大量功能逻辑的时钟端口如果缓冲器驱动能力太弱时钟信号的转换时间Transition会变差进而影响偏斜。但如果驱动能力太强又会在OCC附近产生较大的开关噪声干扰测试逻辑。在Innovus里可以用set_clock_tree_references命令指定可用的缓冲器列表用set_clock_tree_options的-max_fanout和-max_transition选项控制缓冲器的扇出和转换时间。在ICC2里对应的命令是set_lib_cell_purpose和set_clock_tree_options。我的经验是把OCC模块的时钟路径的max_transition设得比功能逻辑更严格一些比如功能逻辑设0.15nsOCC设0.1ns这样可以保证OCC附近的时钟信号质量。3.4 时钟树综合的约束配置清单下面是我在一个典型项目里用的CTS约束配置清单基于Innovus语法ICC2的配置逻辑类似但命令名不同# 设置时钟树基本参数 set_clock_tree_options -target_skew 0.12 -max_transition 0.15 -max_fanout 32 # 给OCC模块设置独立的skew group set_clock_tree_exceptions -skew_group occ_group -clock_tree_sinks [get_pins occ_inst/pulse_gen/clk] # 设置OCC模块的max_transition更严格 set_clock_tree_options -max_transition 0.1 -skew_group occ_group # 指定缓冲器列表 set_clock_tree_references -references {BUF_X4 BUF_X8 BUF_X12} # 设置OCC附近的布线约束 set_clock_tree_options -layer_list {M3 M4 M5} -skew_group occ_group # 禁止在OCC模块内部插入缓冲器 set_dont_touch [get_cells occ_inst/pulse_gen/*]这段配置的核心思路是功能逻辑用一套参数OCC模块用另一套更严格的参数两者通过skew group隔离。set_dont_touch那行是为了防止CTS工具在OCC内部随意插入缓冲器破坏脉冲发生器的结构。当然具体参数值需要根据工艺节点和设计频率调整不能照搬。4. 实操过程与关键环节实现4.1 CTS前的准备工作CTS不是孤立的一步它的效果很大程度上取决于前面的布局和约束质量。在跑CTS之前我通常会检查以下几项第一时钟定义是否完整。用report_clocks命令确认所有时钟都已经定义包括功能时钟、测试时钟、以及OCC产生的分频时钟。如果有遗漏CTS工具会把这些时钟路径当成普通信号路径处理后果很严重。第二时序约束是否合理。用report_timing检查时钟路径的建立时间和保持时间约束确保没有过约束或欠约束。特别是OCC模块的测试模式约束需要单独设置set_case_analysis来指定测试模式下的时钟选择。第三布局是否合理。OCC模块的位置应该在时钟根节点附近但也不能太近否则布线拥塞。我一般会把OCC放在距离时钟根节点200到500微米的位置具体取决于工艺节点的布线资源。第四电源网络是否稳定。CTS会插入大量缓冲器这些缓冲器的开关电流会对电源网络造成冲击。如果电源网络不够强CTS后可能会出现电压降问题影响时钟信号的完整性。4.2 CTS执行与中间检查跑CTS的时候我习惯分两步走先跑一遍全局CTS检查时钟树的整体结构再跑局部优化。全局CTS用clock_opt -only_cts命令跑完之后用report_clock_tree查看时钟树的层次结构、缓冲器数量和偏斜分布。中间检查的重点是OCC模块附近的时钟树。用report_clock_tree -skew_group occ_group查看OCC的偏斜是否满足要求用report_timing -clock_tree查看OCC内部寄存器的时序是否干净。如果发现OCC附近的偏斜偏大可以手动调整OCC模块的物理位置或者增加OCC时钟路径的缓冲器级数。有一个细节容易被忽略CTS工具在平衡时钟树时会优先优化sink点数量多的分支sink点少的分支可能被牺牲。OCC模块的sink点通常只有几个很容易成为被牺牲的对象。解决办法是在CTS配置里给OCC的skew group设置更高的优先级比如在Innovus里用set_clock_tree_options -priority high -skew_group occ_group。4.3 时钟树平衡的后处理CTS跑完之后时钟树的基本结构就定了但还需要做后处理来修复残余的偏斜和时序违例。后处理主要包括三步第一步时钟树绕线优化。CTS阶段插入的缓冲器和时钟线只是逻辑连接实际的绕线延迟还没有完全确定。用route_clock_tree命令对时钟树做专门绕线绕线时优先使用高层金属比如M5、M6因为高层金属的电阻小延迟更可控。第二步偏斜再平衡。绕线之后实际的时钟延迟会和CTS阶段的估算有偏差需要用clock_opt -only_ps命令做偏斜再平衡。这一步会微调缓冲器的位置和尺寸把偏斜拉回目标值。第三步时序签核。用report_timing做最终的建立时间和保持时间检查重点关注OCC模块和时钟树根节点附近的路径。如果还有违例可能需要手动插入延迟单元或者调整时钟树的拓扑结构。4.4 一个完整的OCC时钟树优化案例我在一个40nm的项目里遇到过一个典型的OCC时钟树问题。设计的功能时钟频率是400MHz测试时钟频率是50MHzOCC模块放在时钟根节点旁边。CTS跑完之后功能逻辑的偏斜是0.08ns满足要求但OCC模块的脉冲发生器出现了保持时间违例违例值是-0.12ns。排查过程是这样的先用report_clock_tree -skew_group occ_group查看OCC的时钟树结构发现脉冲发生器的时钟路径只有一级缓冲器而功能逻辑的时钟路径有三级缓冲器。这意味着脉冲发生器的时钟到达时间比功能逻辑早了将近0.3ns保持时间自然守不住。解决办法是在脉冲发生器的时钟路径上插入两级延迟缓冲器把它的时钟到达时间往后推。具体操作是在Innovus里用insert_buffer命令手动插入缓冲器然后用set_clock_tree_exceptions把这两级缓冲器标记为-dont_touch防止后续优化把它们删掉。插入之后重新跑偏斜再平衡OCC的保持时间违例从-0.12ns降到了-0.02ns再微调一下缓冲器尺寸就干净了。这个案例的教训是CTS工具默认的平衡策略是“拉平”所有sink点的时钟到达时间但OCC模块的sink点对时钟延迟的需求和功能逻辑不同。如果不给OCC单独设置约束工具就会按照功能逻辑的需求来平衡OCC的时序就容易出问题。5. 常见问题与排查技巧实录5.1 OCC附近时钟偏斜过大的排查思路OCC附近时钟偏斜过大是最常见的问题表现是OCC内部寄存器的建立时间或保持时间违例或者扫描测试的capture阶段失败。排查思路可以按以下顺序进行先看OCC的skew group是否设置正确。用report_clock_tree -skew_group命令确认OCC的sink点是否被分到了独立的group里。如果没有说明CTS工具把OCC和功能逻辑混在一起平衡了需要重新配置。再看OCC的时钟路径级数是否和功能逻辑匹配。用report_clock_tree -structure查看OCC时钟路径的缓冲器级数如果比功能逻辑少很多说明OCC的时钟到达太早需要插入延迟缓冲器。最后看OCC附近的布线是否拥塞。用report_congestion查看OCC模块周围的布线资源利用率如果超过80%说明布线拥塞导致时钟线绕远延迟增加。解决办法是调整OCC的物理位置或者给时钟线预留专用的布线通道。5.2 测试模式下时钟脉冲宽度异常的定位方法测试模式下时钟脉冲宽度异常的表现是扫描测试的shift或capture阶段随机失败而且失败率与测试频率相关。定位方法如下第一步用report_timing -mode test查看测试模式下的时序报告重点关注OCC脉冲发生器的时钟路径。如果脉冲发生器的时钟到达时间与预期偏差超过10%说明时钟树有问题。第二步用report_clock_tree -skew_group occ_group查看OCC的偏斜值。如果偏斜超过测试时钟周期的5%说明OCC的时钟树需要优化。第三步检查OCC的脉冲发生器是否被CTS工具插入了缓冲器。用report_clock_tree -cells查看OCC内部的缓冲器列表如果发现脉冲发生器的时钟路径上有工具自动插入的缓冲器说明set_dont_touch约束没有生效需要重新设置。5.3 CTS后时序违例的快速修复清单下面这个表格整理了CTS后常见时序违例的现象、原因和修复方法可以作为速查表使用违例现象可能原因修复方法OCC内部保持时间违例OCC时钟到达太早插入延迟缓冲器或调整OCC skew group功能逻辑建立时间违例时钟偏斜过大收紧目标偏斜值增加缓冲器级数测试模式脉冲宽度异常OCC时钟路径被工具改动设置dont_touch手动固定OCC时钟路径时钟树功耗超标缓冲器过多或驱动能力过强减少缓冲器级数换用低驱动缓冲器时钟线绕线拥塞OCC附近布线资源不足调整OCC位置或给时钟线预留布线通道时钟信号转换时间恶化缓冲器驱动能力不足换用高驱动缓冲器或增加缓冲器级数5.4 几个容易踩的坑和实操心得第一个坑是忽略OCC的控制信号路径。很多工程师只关注OCC的时钟路径忘了扫描使能和测试模式选择这些控制信号也需要时序约束。这些信号的路径延迟如果太大测试模式下的建立时间就会违例。我的做法是在CTS阶段就给这些控制信号设置set_max_delay约束让工具在布局和优化时一并考虑。第二个坑是OCC模块的电源网络没加强。OCC模块内部的脉冲发生器和分频计数器在测试模式下会频繁翻转开关电流比功能模式下大得多。如果电源网络不够强OCC附近的电压降会导致时钟信号抖动脉冲宽度不稳定。我在一个项目里遇到过这个问题后来在OCC模块周围增加了电源条带问题才解决。第三个坑是CTS后没有做OCC的专项时序检查。常规的时序签核只检查功能模式测试模式的时序容易被忽略。我习惯在CTS后单独跑一遍测试模式的时序分析用report_timing -mode test命令确保OCC相关的路径都干净。第四个坑是盲目追求零偏斜。有些工程师把目标偏斜设成0结果CTS工具插入了大量缓冲器功耗和面积飙升而且实际偏斜也做不到0。我的经验是目标偏斜设在时钟周期的5%到8%之间比较合理既能满足时序要求又不会过度消耗资源。5.5 不同工艺节点下的OCC处理差异不同工艺节点下OCC电路的处理策略需要调整。在40nm及以上节点金属线的电阻相对较大时钟树的延迟主要来自绕线OCC的时钟路径需要重点关注绕线长度。在28nm到16nm节点缓冲器的延迟占比增加OCC的时钟路径需要重点关注缓冲器级数和驱动能力。在7nm及以下节点金属线的电阻进一步增大而且布线资源非常紧张OCC模块的位置和布线通道需要提前规划否则CTS阶段很容易遇到拥塞。我在7nm项目里的做法是在布局阶段就给OCC模块预留专用的布线通道用create_route_guide命令给时钟线划定布线区域避免CTS阶段和功能信号线抢资源。另外7nm节点的时钟树通常采用H-tree或Mesh结构OCC模块需要挂在这些结构的特定分支上不能随意放置。6. 时钟树综合后的验证与签核要点6.1 时钟树质量的评估指标CTS跑完之后需要用一组量化指标来评估时钟树的质量。我常用的指标包括全局偏斜Global Skew、局部偏斜Local Skew、时钟树插入延迟Insertion Delay、时钟树功耗Clock Tree Power和时钟树面积Clock Tree Area。全局偏斜是所有sink点中最大时钟到达时间和最小时钟到达时间的差值反映时钟树的整体平衡程度。局部偏斜是同一区域内sink点的时钟到达时间差值反映局部平衡程度。对于OCC模块局部偏斜比全局偏斜更重要因为OCC内部的寄存器需要精确的时钟对齐。时钟树插入延迟是时钟根节点到sink点的平均延迟这个值影响时钟树的功耗和时序余量。插入延迟太大时钟树的功耗会增加而且时序余量会被压缩。我一般会把插入延迟控制在时钟周期的20%到30%之间。6.2 测试模式下的时序签核测试模式下的时序签核和功能模式不同需要单独设置约束和检查项。测试模式的关键检查项包括扫描链的shift时序、capture时序、OCC脉冲发生器的脉冲宽度、以及测试时钟的偏斜。扫描链的shift时序检查的是扫描触发器在shift阶段的建立时间和保持时间。由于shift阶段的数据路径是扫描链的前一级触发器到后一级触发器路径很短保持时间容易违例。解决办法是在扫描链的触发器之间插入延迟单元或者降低shift时钟的频率。capture时序检查的是扫描触发器在capture阶段的建立时间和保持时间。capture阶段的数据路径是功能逻辑的组合逻辑路径较长建立时间容易违例。解决办法是优化组合逻辑的延迟或者调整OCC产生的脉冲宽度。6.3 时钟树综合的迭代优化CTS很少一次就能做到完美通常需要两到三轮迭代。第一轮CTS跑完之后先看全局偏斜和OCC的局部偏斜如果偏差不大直接做后处理和签核。如果偏差较大需要调整CTS参数重新跑。第二轮迭代的重点是优化OCC的时钟树。根据第一轮的偏斜报告调整OCC skew group的约束比如收紧max_transition、增加缓冲器级数、或者调整OCC的物理位置。第二轮跑完之后OCC的偏斜通常能降到目标值以内。第三轮迭代是微调。如果还有少量sink点的偏斜超标可以手动插入延迟单元或者调整缓冲器尺寸。这一轮的工作量不大但需要细心因为手动改动可能会影响其他sink点的偏斜。6.4 签核前的最终检查清单在签核之前我通常会过一遍以下检查清单确保没有遗漏所有时钟都已定义包括功能时钟、测试时钟和OCC产生的分频时钟OCC模块的skew group设置正确且优先级足够高OCC内部的脉冲发生器和分频计数器没有被CTS工具插入缓冲器测试模式下的时序约束完整包括扫描使能和测试模式选择信号时钟树的全局偏斜和局部偏斜都在目标值以内时钟树的插入延迟、功耗和面积在预算范围内OCC附近的布线拥塞率低于80%电源网络能够支撑OCC在测试模式下的开关电流这份清单看起来简单但每一条背后都对应着实际项目中踩过的坑。我见过太多项目因为漏了其中一条导致CTS后返工浪费大量时间。7. 写在最后OCC电路的时钟树优化说到底是一个“分而治之”的问题。功能逻辑和测试逻辑对时钟的需求不同强行用同一套平衡策略去处理必然有一方要妥协。把OCC单独拎出来给它独立的skew group、独立的约束、独立的优化目标问题就简单多了。我在实际项目中的体会是CTS工具再智能也替代不了工程师对电路的理解。工具只知道把sink点的时钟到达时间拉平但它不知道哪些sink点对时钟质量更敏感哪些sink点可以容忍更大的偏斜。这些判断需要工程师根据电路的功能和测试需求来做。所以CTS配置里的每一个参数都应该有明确的理由而不是照搬模板。最后分享一个小技巧在CTS之前先用report_clock_tree -pre_cts命令看一下时钟树的预综合结构了解时钟根节点到各个sink点的逻辑路径。这个报告能帮你提前发现潜在的问题比如某个sink点的逻辑路径特别长或者某个区域的sink点特别密集。提前知道这些CTS配置就能更有针对性少走很多弯路。