数字后端的学习曲线里时钟树综合CTS往往是一道真正拉开差距的分水岭。前面几篇笔记我写过逻辑综合、floorplan、布局布线的基础概念但到了CTS这个环节很多人才第一次意识到时序收敛的成败一半以上是时钟信号的质量决定的。这篇笔记想单独把时钟信号拿出来好好梳理一遍因为CTS的本质就是围绕时钟信号的一系列处理动作——从时钟源到各个触发器的时钟端物理上怎么连线、逻辑上怎么平衡、时序上怎么收敛全都建立在理解时钟信号本身的基础上。如果你正在做数字后端项目或者刚开始接触Innovus数字后端这篇笔记对应的正是数字IC后端设计基本概念学习里最绕但也最关键的一块。我会把时钟信号的本质属性、CTS要解决的核心矛盾、工具里的实操要点、以及实际项目中常见的坑都串起来讲尽量让新手看了能建立整体认知让有经验的同行也能对照检查自己还有没有遗漏。1. 时钟信号到底特殊在哪先搞清楚CTS的对象是什么1.1 时钟信号的关键参数不是只有频率数字电路里到处都是信号但时钟信号是唯一一个全体触发器都在等它的信号。数据传输的节奏、状态机的跳变、寄存器的采样时刻全部由时钟沿clock edge决定。所以分析时钟信号时关注的维度跟普通数据信号完全不同。第一类是时间维度的三大件时钟周期clock period、占空比duty cycle、时钟沿位置。周期决定频率占空比决定高电平时间占总周期的比例这两个参数直接写进SDC约束里。比如一个200MHz的时钟周期是5ns占空比为50%时高电平是2.5ns如果占空比变成40%那高低电平的比例就变了4:6某些基于延迟的模拟电路会受影响但纯数字逻辑里主要关心的是沿的位置。第二类是质量维度的三大件时钟偏斜skew、时钟抖动jitter、时钟延迟latency。这三个概念是CTS的核心对象也是新手最容易混淆的地方。时钟延迟指的是时钟信号从时钟源比如PLL输出或者芯片的时钟输入引脚到某个触发器时钟端的绝对时间差时钟偏斜指的是同一个时钟域内不同触发器时钟端之间的相对时间差时钟抖动则是指时钟沿在每个周期内的随机波动它不是一个固定值而是一个范围。第三类是电学维度的特性transition、占空比失真、噪声容限。时钟信号在长距离走线上会有明显的rise/fall time转换时间如果过长会直接影响触发器的采样窗口甚至导致亚稳态。CTS的工作之一就是把时钟网络的transition控制在合理范围内。这三个维度不是平行的而是层层递进的电学特性影响质量维度质量维度影响时间维度的约束能否满足。理解了这个顺序后面看CTS的各种优化手段就会清晰很多。1.2 为什么数据信号可以不关心skew时钟信号却必须关心有些初学者会问数据路径上也有延迟为什么从来不提data skew这个问题的答案恰恰是理解CTS意义的关键。数据路径上每个信号什么时候到达目的端只影响它自己那个寄存器的采样值是否正确。只要它在时钟沿到达前能够稳定setup check并且在时钟沿之后还能继续保持一段时间hold check那这个信号就算合格了。数据信号的到达时间是绝对值是相对于时钟沿的所以数据路径上所有延迟相加的绝对值必须满足建立时间和保持时间的要求。而时钟信号的到达时间是相对值。一个时钟沿从时钟源出发到达触发器A和触发器B的时间不可能完全一样。A和B之间的采样时间差如果太大就会导致A采到的数据在B看来来晚了或者走早了。这就是为什么CTS要处理skew——不是为了让时钟到达每个触发器的时间都为零而是为了让同一时钟域内各个触发器之间的到达时间差尽可能小。用一个生活化的例子一群人排队做核酸每个人都想知道自己几点能做完。数据信号就好比每个人自己看表只要表的绝对时间准就行时钟信号则好比一个人同时拿着喇叭通知所有人开始如果喇叭声音传到队伍两端的时间不一样那两端的人开始动作的时间就不一样整个队伍就乱了。CTS要做的事情就是让喇叭声音尽量同时传到每个人耳朵里。1.3 时钟信号在实际芯片里的产生与分发结构芯片里时钟信号的源头通常是PLL锁相环或者外部输入的参考时钟。PLL输出的时钟信号干净、稳定、频率准确但从PLL到芯片各个角落的触发器中间要经过很长的物理路径。这段路径上的buffer缓冲器越多延迟越大路径分叉越多不同分支之间的负载越不均衡skew就越难控制。实际芯片里的时钟网络通常呈树形结构称为时钟树。一个典型的时钟树包含几个层次时钟源 - 全局时钟驱动 - 区域时钟缓冲 - 局部时钟缓冲 - 触发器时钟端。每一级缓冲器都会引入延迟也会在一定程度上修复前一级的驱动能力不足问题。时钟树综合就是自动决定这个树形结构中每一级放什么buffer、放在哪里、线怎么走最终让所有触发器的时钟到达时间满足设计目标。这里要特别强调一个概念时钟树的平衡不等于延迟为零。时钟信号从PLL到触发器的延迟insertion delay不可能为零但每个触发器之间的差值skew可以被控制在很小的范围内。有些场景下甚至有意识地制造skew来修复时序这就是后文会展开的useful skew。理解这个区分是读懂CTS报告的第一步。2. CTS要解决的核心矛盾从时序公式看懂CTS的目标2.1 setup和holdCTS存在的第一个理由要做CTS必须先把时序约束公式吃透。这里有一个前提CTS之前PR工具已经完成了布局placement所有标准单元都有了物理位置。此时数据路径上的时序是基本确定的但时钟网络的布线还是理想状态ideal clock。CTS要做的事情就是把理想时钟变成实际时钟propagated clock并且在这个过程中保证时序依然收敛。先看setup检查的公式clock_period - clock_skew - setup_time data_path_delay clock_uncertainty翻译成人话就是数据信号到达目的端触发器的时刻必须早于下一个时钟沿到达该触发器的时刻且留有余量。这里的clock_skew越大留给数据路径的有效时间窗口就越窄。如果数据路径延迟已经优化得很充分、单位延迟接近极限那skew就成了压垮时序的最后一根稻草。再看hold检查的公式data_path_delay clock_skew hold_time clock_uncertainty保持时间检查的是数据信号到达目的端后至少要保持多久不变才能让目的端触发器可靠采样。这里的clock_skew越大数据路径延迟必须越长才能满足要求。换句话说如果skew控制不好setup和hold修复起来都会很痛苦skew大setup修不动要降频hold修不动要插buf加延迟两种修法都是在牺牲面积和功耗。CTS的第一个目标就这么明确了让skew尽可能小为setup和hold留出更多余量。2.2 useful skew把skew从敌人变成武器skew是不是越小越好绝大多数情况下是但有个例外叫useful skew。USeful skew的思路很直接既然时钟到达每个触发器的时间略有差异那能不能利用这个差异来帮助时序收敛假设一条数据路径从触发器A到触发器BB的采样时钟比A的晚到一点点那么在B看来数据路径的有效时间就变长了setup更不容易违例。反过来如果B的时钟比A的早到一点点那么B在采样时数据必须保持更长时间不变hold的余量就变大了。所以对于setup违例的路径可以让目的端时钟晚到对于hold违例的路径可以让目的端时钟早到。在Innovus里CTS引擎CCopt会自动做这种优化。它不仅仅是在平衡skew还会根据具体的时序余量情况主动调整每个时钟节点的相对到达时间让关键路径的时序变好。这就是为什么现在做CTS不只是平衡时钟而是基于时序的时钟优化。理解这个差异化目标是理解CCopt这类工具行为的关键。如果你用旧时代的CTS思维看到skew报出几百ps就紧张但在useful skew策略下这可能是正常且有意的结果。关键是看最终时序是否收敛而不是单纯盯skew数字。2.3 latency和tree lengthCTS的物理代价CTS做得越深、插的buffer越多时钟延迟latency就越大。LATENCY太大有两个坏处一是对OCV片上工艺偏差更敏感因为工艺偏差产生的延迟偏差在长路径上会被放大二是增加功耗每个时钟buffer都在翻转时钟网络的动态功耗可以占总芯片功耗的20%-40%buffer数量越多功耗越高。所以CTS不是越平越好就完事了还要在latency和skew之间做权衡。比如一个大芯片里整个时钟树分成了很多个平衡点merging point每个平衡点下面挂的触发器数量如果差异很大工具就需要插入多级缓冲来平衡负载。负载平衡做得好skew小但平衡的过程会引入额外延迟latency变大。具体怎么取舍取决于设计频率、功耗预算和工艺角的OCV系数。实际项目中CTS报告里会同时给出max latency、min latency、skew、total buffer count、tree depth这几项指标。新手看报告只盯skew老手会把这几项一起看还要结合时钟树的层级结构判断哪些地方可以优化哪些地方是物理上的硬限制。3. 在Innovus里做CTS从约束到tree的完整流程3.1 CTS之前的时钟约束准备做CTS之前SDC里的时钟约束必须完整且准确。这里我按优先级列一下最基本的几个约束项约束项命令示例作用创建时钟create_clock -name clk_200m -period 5.0 [get_ports clk]定义时钟周期和源位置时钟不确定性set_clock_uncertainty -setup 0.15 [get_clocks clk_200m]预留时钟抖动和裕量时钟延迟set_clock_latency -source 0.5 [get_clocks clk_200m]定义从时钟源到定义的时钟点的延迟时钟转换时间set_clock_transition 0.1 [get_clocks clk_200m]定义时钟沿的transition约束时钟树例外set_clock_tree_exceptions -non_stop_pin xxx指定不需要平衡的路径或节点**时钟树的例外clock tree exceptions**是CTS里最重要的几个高阶约束之一常见的包括stop pin时钟树不在这里继续往下延伸、non-stop pin时钟树经过但不在这个节点上打断、exclude pin部分分支不参与平衡、float pin告诉自己该节点已有外部已知延迟。如果这些例外没有设对CTS要么插了多余的buffer要么该平衡的位置没平衡树的质量会大打折扣。在开始CTS之前我强烈建议先跑一遍时钟树的质量检查脚本确认时钟网络的漂移propagate和逻辑连接logical connection都符合预期。很多CTS做出来skew奇大根本原因不是工具参数而是之前时钟定义或者约束里埋了雷。3.2 CCopt引擎的核心逻辑Innovus从17版本之后全面推广了CCoptConcurrent Clock and Data Optimization引擎来做CTS。和旧版CTS引擎最大的区别在于CCopt不是先做时钟树再做数据路径优化而是把时钟树的构建和数据路径的延迟优化放在同一个优化循环里协同处理。CCopt引擎在工作时会做下面这几件主要的事情第一它会先分析整个设计中所有时序路径找出关键路径的位置。这些路径上的触发器的时钟到达时间会被优先优化。非关键路径上的触发器则按常规的平衡策略处理。第二它会同时考虑多个时钟域。多时钟设计里跨时钟域的路径CDC往往有特殊的约束比如set_false_path如果CTS阶段把跨时钟域的时钟端也拿去强行平衡反而会浪费资源。CCopt会识别这些例外不把资源花在无谓的平衡上。第三它会在优化过程中实时权衡skew和latency并且参考OCV的derate系数。同一个skew值在derate系数大的工艺角下对时序的影响会被放大所以工具会更倾向于减少物理距离上不平衡的分支。第四CCopt还能在CTS阶段直接做hold修复hold fixing而且它修hold的方式不是简单地往数据路径上插一堆buffer而是会结合useful skew调整时钟到达时间再做数据路径的small delay修复。两相配合面积和功耗的代价更小。3.3 Innovus里CTS的实操步骤拆解理论说完看实操。假设设计已经完成布局SDC约束也已经读入下面是一份标准的CTS操作流程第一步确认时钟树综合前的环境状态。检查数据库里标准单元库的delay info是否完整、是否有hold margin设好、是否定义好了时钟树的routing layer和via。用命令report_clock_tree -before_cts查看CTS前时钟网络的预估情况确认时钟源位置正确、各分支的负载估计合理。这一步虽然是检查但作用很大有时候时钟网络在place过程中被异常断掉了CTS根本跑不下去要从这里才能看出来。第二步设置时钟树属性。Innovus里有专门的CTS属性设置命令set_ccopt_property、create_ccopt_clock_tree_spec等。关键的属性包括max_transition、max_capacitance、NDR走线规则、目标skew值等。高扇出网络high fanout net的处理方式也需要在这里指定一般建议设置显式的高扇出缓冲器比如CLKBUF来驱动而不是靠数据path buffer硬扛。第三步运行CTS。典型命令是ccopt_design -cts。这一步会根据你的时钟树spec和约束自动完成buffer插入、网络划分、物理走线。运行时间从几分钟到几十分钟不等取决于设计规模和时钟网络复杂度。跑完之后工具会生成CTS报告主要看report_ccopt_skew、report_ccopt_timing这几份审查整体skew、latency、tree深度和时序余量。第四步评估与迭代。绝大多数项目一次CTS跑完就能优异收敛这是不现实的。经验值是时钟网络越大、时钟域越多、频率越高迭代调整的次数就越多。每次迭代要基于上一轮的skew报告和时序报告找到瓶颈点调整对应的约束或工具属性再重新跑CTS。有几个优化点的优先级在我这里永远是先查时钟网络拓扑有没有问题再查跨时钟域路径然后才是工具参数的微调。3.4 时钟树上的细节处理shielding和routing layer选择CTS不光是逻辑层面的平衡物理层面也有很多门道。时钟网络的走线规则NDR通常和数据网络不一样时钟线要求更宽、间距更大、金属层更高目的是减少电阻电容延迟、降低串扰噪声影响。一个很常见的要求是给时钟网络设置double spacing double width甚至在某些高频区域用shield线包裹时钟线。Shield的意思是在时钟线的两边各放一条接地线或电源线把串扰干扰屏蔽掉。代价是布线资源消耗大、绕线困难所以一般只在时钟树的关键部分比如PLL输出后的主干、高频分支才做。时钟网络用的金属层也有讲究。后端工程师通常会把时钟网络单独分配在2-4层金属因为顶层金属往往被电源地网络占据或者引线出来底层金属则因为器件层干扰大、电阻大不利于时钟质量。实际项目里clock routing layer和via的设置往往要跟芯片的电源网络规划配合好否则容易出现IR-drop电源压降的附加问题。3.5 门控时钟gated clock在CTS中的特殊处理现在的低功耗设计里门控时钟几乎是无处不在的。每个模块的时钟都会加一个ICGIntegrated Clock Gating单元在模块不工作时把时钟关闭来省电。ICG在逻辑功能上是时钟信号的闸门但它本身也是一个时钟树上的节点。CTS处理ICG时有一个常见的坑ICG的输出端时钟信号质量取决于ICG单元的驱动能力和输入端的enable信号到达时间。如果enable信号来得太晚时钟沿会被拉宽变形glitch严重时会导致触发器误采样。所以在CTS约束里ICG单元的输出端一般会被设为非平衡点或者通过特殊的方式锁定时钟树的走向。更好的处理方式是在时钟定义时直接在ICG单元的输出端定义generated clock。这样CTS会自动把ICG当作一个时钟树的层次边界ICG之前的时钟树和ICG之后的时钟树可以分别优化ICG引起的延迟也会被正确计入时序分析中。很多新手在做CTS后发现时序大量违例回头一看就是ICG的generated clock没定义全。4. 时钟信号相关的常见问题与排查思路4.1 skew报告中数字异常先看树结构再调参数某个关键时钟域skew报告显示400ps而目标是150ps以内这个数字在新工艺下已经是危险信号了。很多人的第一反应是去调工具的balance力度参数但这往往是在错误方向上努力。正确的排查顺序应该是先打开时钟树的物理拓扑图看看是不是存在某些触发器被孤立了——比如一个附近的cluster有1000个触发器但还有十几个触发器散落在芯片另一端工具为了平衡这十几个远处的触发器不得不把整个树的所有路径都拉长。这时候最有效的办法不是调工具参数而是检查这些孤立触发器为什么会在那里是floorplan阶段封装的模块布局不合理还是时钟树的region约束没有设定好这些物理层面的问题靠调参数是解决不了的。如果确实需要调工具参数比较常用的有ccopt_skew_group的划分配置或者把目标时钟网络拆成多个子树分别处理。但这属于修枝剪叶治标不治本。4.2 hold违例大量爆发CTS之后的时序修复策略CTS做完后发现hold违例满天飞这在很多模块级PR中几乎是必经之路。为什么CTS之前hold看起来没问题CTS之后就炸了因为CTS之前的时钟是理想时钟所有触发器的时钟到达时间被假设完全相同hold检查的路径余量很宽裕。CTS之后时钟变成实际时钟skew的真实值加进公式里hold的窗口一下子变窄了。应对hold违例有个基本判断如果违例普遍出现在跨长距离路径上说明skew太大或者数据路径延迟太短如果违例集中在某个局部区域内很可能是时钟树在这个区域内插入了过多buffer导致局部时钟到达时间偏晚。处理的第一优先级是通过useful skew来调整其次才是插数据path buffer。只有这两种手段都不够时才考虑去调整寄存器之间的逻辑结构。有一个PI设计者经验分享给大家CTS之后的hold修复要尽量在CTS阶段内完成或者紧跟着CTS跑不要拖到详细布线之后。因为一旦进入布线阶段hold修复需要ECO工程变更单流程成本高、风险大而且修复的空间也小了。4.3 串扰crosstalk对时钟信号的影响时钟网络为什么需要shielding时钟网络对噪声的敏感度远远高于数据网络。数据网络上的一点噪声只要不导致逻辑翻转错误就不会出大问题但是时钟网络上的噪声轻则让时钟沿提前或滞后几十个ps重则产生毛刺导致触发器误触发。CTS做完之后工具会报告时钟网络的crosstalk分析结果。当发现某段时钟线受到的耦合噪声超过阈值时工具会尝试绕开干扰源或者加shielding。这里要提醒的是shielding不是万能的。加了shield虽然提高了对横向串扰的免疫力但如果被shield的时钟线本身有较长的平行段线间电容的耦合效应依然存在。在设计早期floorplan阶段就应该有意识地把时钟主干区域留干净避免时钟线贴着高速数据线长距离并行。4.4 电源噪声带来的时钟抖动IR-drop和SSN的连带影响时钟质量不光取决于时钟树本身还和供电质量强相关。当时钟buffer翻转时瞬间的电流冲击会让局部电源电压跌落IR-drop这种跌落如果发生在时钟沿附近会让时钟沿的到达时刻发生偏移等价于增大了jitter。这种电源噪声引起的时钟偏移很难在CTS阶段完全消除。通常的手段包括增强时钟区域电源网络的密度多打电源via、加宽电源轨、在时钟buffer附近放decoupling capacitor去耦电容、控制同时翻转的buffer数量避免过于集中的switching activity。这些措施的意义在于时钟树的物理布局不能只考虑时序平衡还要考虑功耗和供电的局部均衡。4.5 多时钟域设计中的时钟交互问题现在的SoC芯片动辄十几个时钟域CTS要考虑的不只是单个时钟域内部平衡还有跨时钟域之间的交互。比如两个时钟域共用了同一个时钟源它们在物理布局上如果交织在一起CTS可能会默认它们要平衡但实际上它们的同步点有专门的同步器结构并不需要严格平衡。这时候没有设好例外约束工具就会白白浪费资源去平衡不需要平衡的路径。多时钟域的CTS中时钟域之间的时序路径处理要特别小心。异步FIFO、两级同步器、格雷码转换器这些结构的时钟端往往会被设为不同的skew group甚至直接设为false path。如果这些例外没有提前设好CTS的输出结果可能会让人摸不着头脑——某段跨时钟域路径的时序明明无关紧要但时钟树上却多出了大量的buffer。5. 从学习到实战的几点建议5.1 建立时钟质量优先的意识做数字后端的人很容易掉进只要时序收敛就万事大吉的思维陷阱。但时序收敛只是底线时钟信号的质量好坏直接影响芯片的鲁棒性和量产良率。一个skew做得极小但latency很长、功耗爆炸的时钟树和另一个skew略大但latency短、功耗低的时钟树单看时序报告前者好看但在实际硅片上后者可能更稳定。我在一个项目里被这个问题狠狠教育过。当时有一个模块时钟频率不算高CTS跑出来skew只有100ps出头看起来挺好。但到了IR-drop和功耗分析阶段发现时钟树上的buffer功耗占了模块总功耗的三分之一而且这些buffer的翻转电流高度集中把旁边一个敏感模拟模块的电源区都带崩了。后来重新调整了时钟树的平衡策略多花了一些skew指标换回了功耗和供电质量的健康。时钟树综合里的很多设计决策其实是在多个物理指标之间做权衡而不是单点最优。5.2 学会读CTS日志里的潜台词工具的日志和报告里藏着大量信息但用不熟练的人往往只抓最终skew值。我会特别关注以下几个信号clock tree depth如果过大说明平衡策略可能偏保守了要考虑是否某些分支负载太重。total buffer count如果比同工艺同规模的参考设计高出30%以上要警惕是否有无效平衡或者例外的设置出了问题。local skew和global skew的比值如果很大可能存在某个局部区域的负载极端不均衡需要回到布局层面去查。这些指标之间是联动的。光看一个数字很难判断时钟树质量把几个数字放在一起交叉验证很多隐藏问题就会显形。5.3 从CCopt的useful skew行为中学习时钟树的优化空间CCopt引擎引入的useful skew优化改变了传统CTS只追求平衡的思路。但这也同时意味着工具在CTS阶段对触发器位置的摆放会更敏感。同一个RTL两种不同的布局方案CTS跑出来的skew和latency可能天差地别。这提醒我们做CTS不能被动等工具处理要在布局阶段就有意识地优化关键路径上的触发器分布让它们尽可能拉近减少CTS的修复压力。换句话说真正的时钟信号质量保障是一个从floorplan、placement到CTS全程都要持续关注的过程。CTS只是把前面阶段积累的账一次性暴露出来而已。历经几个项目的打磨我自己形成了一个工作习惯每次跑完CTS除了看报告我一定会打开时钟树的可视化界面沿着从时钟源到最末级缓冲器的路径逐段看一遍transition、capacitance、delay数值的递变。这个习惯帮我发现了不少工具日志里没有直接报问题的隐患比如某个分支的transition在靠近触发器的地方突然劣化、某段走线负载明显异常等等。看多了之后对时钟信号在芯片里怎么走、怎么平衡、质量好坏会有一种直观的体感这种体感是任何教科书都教不会的只能在一次次项目迭代里积累。时钟信号这个主题往后还能继续深入的内容还有很多OCV的derate如何影响时钟树结构、AOCV/LV流程里时钟网络怎么建模、多工艺角的CTS如何收敛、甚至新兴的机器学习辅助时钟树优化方向。但核心思路不变——每一个时钟沿都是整个芯片行为的起搏点CTS这门手艺本质上就是把这颗心律调稳、调准、调省。 时钟树综合CTS：从时钟信号本质到时序收敛实战
数字后端的学习曲线里时钟树综合CTS往往是一道真正拉开差距的分水岭。前面几篇笔记我写过逻辑综合、floorplan、布局布线的基础概念但到了CTS这个环节很多人才第一次意识到时序收敛的成败一半以上是时钟信号的质量决定的。这篇笔记想单独把时钟信号拿出来好好梳理一遍因为CTS的本质就是围绕时钟信号的一系列处理动作——从时钟源到各个触发器的时钟端物理上怎么连线、逻辑上怎么平衡、时序上怎么收敛全都建立在理解时钟信号本身的基础上。如果你正在做数字后端项目或者刚开始接触Innovus数字后端这篇笔记对应的正是数字IC后端设计基本概念学习里最绕但也最关键的一块。我会把时钟信号的本质属性、CTS要解决的核心矛盾、工具里的实操要点、以及实际项目中常见的坑都串起来讲尽量让新手看了能建立整体认知让有经验的同行也能对照检查自己还有没有遗漏。1. 时钟信号到底特殊在哪先搞清楚CTS的对象是什么1.1 时钟信号的关键参数不是只有频率数字电路里到处都是信号但时钟信号是唯一一个全体触发器都在等它的信号。数据传输的节奏、状态机的跳变、寄存器的采样时刻全部由时钟沿clock edge决定。所以分析时钟信号时关注的维度跟普通数据信号完全不同。第一类是时间维度的三大件时钟周期clock period、占空比duty cycle、时钟沿位置。周期决定频率占空比决定高电平时间占总周期的比例这两个参数直接写进SDC约束里。比如一个200MHz的时钟周期是5ns占空比为50%时高电平是2.5ns如果占空比变成40%那高低电平的比例就变了4:6某些基于延迟的模拟电路会受影响但纯数字逻辑里主要关心的是沿的位置。第二类是质量维度的三大件时钟偏斜skew、时钟抖动jitter、时钟延迟latency。这三个概念是CTS的核心对象也是新手最容易混淆的地方。时钟延迟指的是时钟信号从时钟源比如PLL输出或者芯片的时钟输入引脚到某个触发器时钟端的绝对时间差时钟偏斜指的是同一个时钟域内不同触发器时钟端之间的相对时间差时钟抖动则是指时钟沿在每个周期内的随机波动它不是一个固定值而是一个范围。第三类是电学维度的特性transition、占空比失真、噪声容限。时钟信号在长距离走线上会有明显的rise/fall time转换时间如果过长会直接影响触发器的采样窗口甚至导致亚稳态。CTS的工作之一就是把时钟网络的transition控制在合理范围内。这三个维度不是平行的而是层层递进的电学特性影响质量维度质量维度影响时间维度的约束能否满足。理解了这个顺序后面看CTS的各种优化手段就会清晰很多。1.2 为什么数据信号可以不关心skew时钟信号却必须关心有些初学者会问数据路径上也有延迟为什么从来不提data skew这个问题的答案恰恰是理解CTS意义的关键。数据路径上每个信号什么时候到达目的端只影响它自己那个寄存器的采样值是否正确。只要它在时钟沿到达前能够稳定setup check并且在时钟沿之后还能继续保持一段时间hold check那这个信号就算合格了。数据信号的到达时间是绝对值是相对于时钟沿的所以数据路径上所有延迟相加的绝对值必须满足建立时间和保持时间的要求。而时钟信号的到达时间是相对值。一个时钟沿从时钟源出发到达触发器A和触发器B的时间不可能完全一样。A和B之间的采样时间差如果太大就会导致A采到的数据在B看来来晚了或者走早了。这就是为什么CTS要处理skew——不是为了让时钟到达每个触发器的时间都为零而是为了让同一时钟域内各个触发器之间的到达时间差尽可能小。用一个生活化的例子一群人排队做核酸每个人都想知道自己几点能做完。数据信号就好比每个人自己看表只要表的绝对时间准就行时钟信号则好比一个人同时拿着喇叭通知所有人开始如果喇叭声音传到队伍两端的时间不一样那两端的人开始动作的时间就不一样整个队伍就乱了。CTS要做的事情就是让喇叭声音尽量同时传到每个人耳朵里。1.3 时钟信号在实际芯片里的产生与分发结构芯片里时钟信号的源头通常是PLL锁相环或者外部输入的参考时钟。PLL输出的时钟信号干净、稳定、频率准确但从PLL到芯片各个角落的触发器中间要经过很长的物理路径。这段路径上的buffer缓冲器越多延迟越大路径分叉越多不同分支之间的负载越不均衡skew就越难控制。实际芯片里的时钟网络通常呈树形结构称为时钟树。一个典型的时钟树包含几个层次时钟源 - 全局时钟驱动 - 区域时钟缓冲 - 局部时钟缓冲 - 触发器时钟端。每一级缓冲器都会引入延迟也会在一定程度上修复前一级的驱动能力不足问题。时钟树综合就是自动决定这个树形结构中每一级放什么buffer、放在哪里、线怎么走最终让所有触发器的时钟到达时间满足设计目标。这里要特别强调一个概念时钟树的平衡不等于延迟为零。时钟信号从PLL到触发器的延迟insertion delay不可能为零但每个触发器之间的差值skew可以被控制在很小的范围内。有些场景下甚至有意识地制造skew来修复时序这就是后文会展开的useful skew。理解这个区分是读懂CTS报告的第一步。2. CTS要解决的核心矛盾从时序公式看懂CTS的目标2.1 setup和holdCTS存在的第一个理由要做CTS必须先把时序约束公式吃透。这里有一个前提CTS之前PR工具已经完成了布局placement所有标准单元都有了物理位置。此时数据路径上的时序是基本确定的但时钟网络的布线还是理想状态ideal clock。CTS要做的事情就是把理想时钟变成实际时钟propagated clock并且在这个过程中保证时序依然收敛。先看setup检查的公式clock_period - clock_skew - setup_time data_path_delay clock_uncertainty翻译成人话就是数据信号到达目的端触发器的时刻必须早于下一个时钟沿到达该触发器的时刻且留有余量。这里的clock_skew越大留给数据路径的有效时间窗口就越窄。如果数据路径延迟已经优化得很充分、单位延迟接近极限那skew就成了压垮时序的最后一根稻草。再看hold检查的公式data_path_delay clock_skew hold_time clock_uncertainty保持时间检查的是数据信号到达目的端后至少要保持多久不变才能让目的端触发器可靠采样。这里的clock_skew越大数据路径延迟必须越长才能满足要求。换句话说如果skew控制不好setup和hold修复起来都会很痛苦skew大setup修不动要降频hold修不动要插buf加延迟两种修法都是在牺牲面积和功耗。CTS的第一个目标就这么明确了让skew尽可能小为setup和hold留出更多余量。2.2 useful skew把skew从敌人变成武器skew是不是越小越好绝大多数情况下是但有个例外叫useful skew。USeful skew的思路很直接既然时钟到达每个触发器的时间略有差异那能不能利用这个差异来帮助时序收敛假设一条数据路径从触发器A到触发器BB的采样时钟比A的晚到一点点那么在B看来数据路径的有效时间就变长了setup更不容易违例。反过来如果B的时钟比A的早到一点点那么B在采样时数据必须保持更长时间不变hold的余量就变大了。所以对于setup违例的路径可以让目的端时钟晚到对于hold违例的路径可以让目的端时钟早到。在Innovus里CTS引擎CCopt会自动做这种优化。它不仅仅是在平衡skew还会根据具体的时序余量情况主动调整每个时钟节点的相对到达时间让关键路径的时序变好。这就是为什么现在做CTS不只是平衡时钟而是基于时序的时钟优化。理解这个差异化目标是理解CCopt这类工具行为的关键。如果你用旧时代的CTS思维看到skew报出几百ps就紧张但在useful skew策略下这可能是正常且有意的结果。关键是看最终时序是否收敛而不是单纯盯skew数字。2.3 latency和tree lengthCTS的物理代价CTS做得越深、插的buffer越多时钟延迟latency就越大。LATENCY太大有两个坏处一是对OCV片上工艺偏差更敏感因为工艺偏差产生的延迟偏差在长路径上会被放大二是增加功耗每个时钟buffer都在翻转时钟网络的动态功耗可以占总芯片功耗的20%-40%buffer数量越多功耗越高。所以CTS不是越平越好就完事了还要在latency和skew之间做权衡。比如一个大芯片里整个时钟树分成了很多个平衡点merging point每个平衡点下面挂的触发器数量如果差异很大工具就需要插入多级缓冲来平衡负载。负载平衡做得好skew小但平衡的过程会引入额外延迟latency变大。具体怎么取舍取决于设计频率、功耗预算和工艺角的OCV系数。实际项目中CTS报告里会同时给出max latency、min latency、skew、total buffer count、tree depth这几项指标。新手看报告只盯skew老手会把这几项一起看还要结合时钟树的层级结构判断哪些地方可以优化哪些地方是物理上的硬限制。3. 在Innovus里做CTS从约束到tree的完整流程3.1 CTS之前的时钟约束准备做CTS之前SDC里的时钟约束必须完整且准确。这里我按优先级列一下最基本的几个约束项约束项命令示例作用创建时钟create_clock -name clk_200m -period 5.0 [get_ports clk]定义时钟周期和源位置时钟不确定性set_clock_uncertainty -setup 0.15 [get_clocks clk_200m]预留时钟抖动和裕量时钟延迟set_clock_latency -source 0.5 [get_clocks clk_200m]定义从时钟源到定义的时钟点的延迟时钟转换时间set_clock_transition 0.1 [get_clocks clk_200m]定义时钟沿的transition约束时钟树例外set_clock_tree_exceptions -non_stop_pin xxx指定不需要平衡的路径或节点**时钟树的例外clock tree exceptions**是CTS里最重要的几个高阶约束之一常见的包括stop pin时钟树不在这里继续往下延伸、non-stop pin时钟树经过但不在这个节点上打断、exclude pin部分分支不参与平衡、float pin告诉自己该节点已有外部已知延迟。如果这些例外没有设对CTS要么插了多余的buffer要么该平衡的位置没平衡树的质量会大打折扣。在开始CTS之前我强烈建议先跑一遍时钟树的质量检查脚本确认时钟网络的漂移propagate和逻辑连接logical connection都符合预期。很多CTS做出来skew奇大根本原因不是工具参数而是之前时钟定义或者约束里埋了雷。3.2 CCopt引擎的核心逻辑Innovus从17版本之后全面推广了CCoptConcurrent Clock and Data Optimization引擎来做CTS。和旧版CTS引擎最大的区别在于CCopt不是先做时钟树再做数据路径优化而是把时钟树的构建和数据路径的延迟优化放在同一个优化循环里协同处理。CCopt引擎在工作时会做下面这几件主要的事情第一它会先分析整个设计中所有时序路径找出关键路径的位置。这些路径上的触发器的时钟到达时间会被优先优化。非关键路径上的触发器则按常规的平衡策略处理。第二它会同时考虑多个时钟域。多时钟设计里跨时钟域的路径CDC往往有特殊的约束比如set_false_path如果CTS阶段把跨时钟域的时钟端也拿去强行平衡反而会浪费资源。CCopt会识别这些例外不把资源花在无谓的平衡上。第三它会在优化过程中实时权衡skew和latency并且参考OCV的derate系数。同一个skew值在derate系数大的工艺角下对时序的影响会被放大所以工具会更倾向于减少物理距离上不平衡的分支。第四CCopt还能在CTS阶段直接做hold修复hold fixing而且它修hold的方式不是简单地往数据路径上插一堆buffer而是会结合useful skew调整时钟到达时间再做数据路径的small delay修复。两相配合面积和功耗的代价更小。3.3 Innovus里CTS的实操步骤拆解理论说完看实操。假设设计已经完成布局SDC约束也已经读入下面是一份标准的CTS操作流程第一步确认时钟树综合前的环境状态。检查数据库里标准单元库的delay info是否完整、是否有hold margin设好、是否定义好了时钟树的routing layer和via。用命令report_clock_tree -before_cts查看CTS前时钟网络的预估情况确认时钟源位置正确、各分支的负载估计合理。这一步虽然是检查但作用很大有时候时钟网络在place过程中被异常断掉了CTS根本跑不下去要从这里才能看出来。第二步设置时钟树属性。Innovus里有专门的CTS属性设置命令set_ccopt_property、create_ccopt_clock_tree_spec等。关键的属性包括max_transition、max_capacitance、NDR走线规则、目标skew值等。高扇出网络high fanout net的处理方式也需要在这里指定一般建议设置显式的高扇出缓冲器比如CLKBUF来驱动而不是靠数据path buffer硬扛。第三步运行CTS。典型命令是ccopt_design -cts。这一步会根据你的时钟树spec和约束自动完成buffer插入、网络划分、物理走线。运行时间从几分钟到几十分钟不等取决于设计规模和时钟网络复杂度。跑完之后工具会生成CTS报告主要看report_ccopt_skew、report_ccopt_timing这几份审查整体skew、latency、tree深度和时序余量。第四步评估与迭代。绝大多数项目一次CTS跑完就能优异收敛这是不现实的。经验值是时钟网络越大、时钟域越多、频率越高迭代调整的次数就越多。每次迭代要基于上一轮的skew报告和时序报告找到瓶颈点调整对应的约束或工具属性再重新跑CTS。有几个优化点的优先级在我这里永远是先查时钟网络拓扑有没有问题再查跨时钟域路径然后才是工具参数的微调。3.4 时钟树上的细节处理shielding和routing layer选择CTS不光是逻辑层面的平衡物理层面也有很多门道。时钟网络的走线规则NDR通常和数据网络不一样时钟线要求更宽、间距更大、金属层更高目的是减少电阻电容延迟、降低串扰噪声影响。一个很常见的要求是给时钟网络设置double spacing double width甚至在某些高频区域用shield线包裹时钟线。Shield的意思是在时钟线的两边各放一条接地线或电源线把串扰干扰屏蔽掉。代价是布线资源消耗大、绕线困难所以一般只在时钟树的关键部分比如PLL输出后的主干、高频分支才做。时钟网络用的金属层也有讲究。后端工程师通常会把时钟网络单独分配在2-4层金属因为顶层金属往往被电源地网络占据或者引线出来底层金属则因为器件层干扰大、电阻大不利于时钟质量。实际项目里clock routing layer和via的设置往往要跟芯片的电源网络规划配合好否则容易出现IR-drop电源压降的附加问题。3.5 门控时钟gated clock在CTS中的特殊处理现在的低功耗设计里门控时钟几乎是无处不在的。每个模块的时钟都会加一个ICGIntegrated Clock Gating单元在模块不工作时把时钟关闭来省电。ICG在逻辑功能上是时钟信号的闸门但它本身也是一个时钟树上的节点。CTS处理ICG时有一个常见的坑ICG的输出端时钟信号质量取决于ICG单元的驱动能力和输入端的enable信号到达时间。如果enable信号来得太晚时钟沿会被拉宽变形glitch严重时会导致触发器误采样。所以在CTS约束里ICG单元的输出端一般会被设为非平衡点或者通过特殊的方式锁定时钟树的走向。更好的处理方式是在时钟定义时直接在ICG单元的输出端定义generated clock。这样CTS会自动把ICG当作一个时钟树的层次边界ICG之前的时钟树和ICG之后的时钟树可以分别优化ICG引起的延迟也会被正确计入时序分析中。很多新手在做CTS后发现时序大量违例回头一看就是ICG的generated clock没定义全。4. 时钟信号相关的常见问题与排查思路4.1 skew报告中数字异常先看树结构再调参数某个关键时钟域skew报告显示400ps而目标是150ps以内这个数字在新工艺下已经是危险信号了。很多人的第一反应是去调工具的balance力度参数但这往往是在错误方向上努力。正确的排查顺序应该是先打开时钟树的物理拓扑图看看是不是存在某些触发器被孤立了——比如一个附近的cluster有1000个触发器但还有十几个触发器散落在芯片另一端工具为了平衡这十几个远处的触发器不得不把整个树的所有路径都拉长。这时候最有效的办法不是调工具参数而是检查这些孤立触发器为什么会在那里是floorplan阶段封装的模块布局不合理还是时钟树的region约束没有设定好这些物理层面的问题靠调参数是解决不了的。如果确实需要调工具参数比较常用的有ccopt_skew_group的划分配置或者把目标时钟网络拆成多个子树分别处理。但这属于修枝剪叶治标不治本。4.2 hold违例大量爆发CTS之后的时序修复策略CTS做完后发现hold违例满天飞这在很多模块级PR中几乎是必经之路。为什么CTS之前hold看起来没问题CTS之后就炸了因为CTS之前的时钟是理想时钟所有触发器的时钟到达时间被假设完全相同hold检查的路径余量很宽裕。CTS之后时钟变成实际时钟skew的真实值加进公式里hold的窗口一下子变窄了。应对hold违例有个基本判断如果违例普遍出现在跨长距离路径上说明skew太大或者数据路径延迟太短如果违例集中在某个局部区域内很可能是时钟树在这个区域内插入了过多buffer导致局部时钟到达时间偏晚。处理的第一优先级是通过useful skew来调整其次才是插数据path buffer。只有这两种手段都不够时才考虑去调整寄存器之间的逻辑结构。有一个PI设计者经验分享给大家CTS之后的hold修复要尽量在CTS阶段内完成或者紧跟着CTS跑不要拖到详细布线之后。因为一旦进入布线阶段hold修复需要ECO工程变更单流程成本高、风险大而且修复的空间也小了。4.3 串扰crosstalk对时钟信号的影响时钟网络为什么需要shielding时钟网络对噪声的敏感度远远高于数据网络。数据网络上的一点噪声只要不导致逻辑翻转错误就不会出大问题但是时钟网络上的噪声轻则让时钟沿提前或滞后几十个ps重则产生毛刺导致触发器误触发。CTS做完之后工具会报告时钟网络的crosstalk分析结果。当发现某段时钟线受到的耦合噪声超过阈值时工具会尝试绕开干扰源或者加shielding。这里要提醒的是shielding不是万能的。加了shield虽然提高了对横向串扰的免疫力但如果被shield的时钟线本身有较长的平行段线间电容的耦合效应依然存在。在设计早期floorplan阶段就应该有意识地把时钟主干区域留干净避免时钟线贴着高速数据线长距离并行。4.4 电源噪声带来的时钟抖动IR-drop和SSN的连带影响时钟质量不光取决于时钟树本身还和供电质量强相关。当时钟buffer翻转时瞬间的电流冲击会让局部电源电压跌落IR-drop这种跌落如果发生在时钟沿附近会让时钟沿的到达时刻发生偏移等价于增大了jitter。这种电源噪声引起的时钟偏移很难在CTS阶段完全消除。通常的手段包括增强时钟区域电源网络的密度多打电源via、加宽电源轨、在时钟buffer附近放decoupling capacitor去耦电容、控制同时翻转的buffer数量避免过于集中的switching activity。这些措施的意义在于时钟树的物理布局不能只考虑时序平衡还要考虑功耗和供电的局部均衡。4.5 多时钟域设计中的时钟交互问题现在的SoC芯片动辄十几个时钟域CTS要考虑的不只是单个时钟域内部平衡还有跨时钟域之间的交互。比如两个时钟域共用了同一个时钟源它们在物理布局上如果交织在一起CTS可能会默认它们要平衡但实际上它们的同步点有专门的同步器结构并不需要严格平衡。这时候没有设好例外约束工具就会白白浪费资源去平衡不需要平衡的路径。多时钟域的CTS中时钟域之间的时序路径处理要特别小心。异步FIFO、两级同步器、格雷码转换器这些结构的时钟端往往会被设为不同的skew group甚至直接设为false path。如果这些例外没有提前设好CTS的输出结果可能会让人摸不着头脑——某段跨时钟域路径的时序明明无关紧要但时钟树上却多出了大量的buffer。5. 从学习到实战的几点建议5.1 建立时钟质量优先的意识做数字后端的人很容易掉进只要时序收敛就万事大吉的思维陷阱。但时序收敛只是底线时钟信号的质量好坏直接影响芯片的鲁棒性和量产良率。一个skew做得极小但latency很长、功耗爆炸的时钟树和另一个skew略大但latency短、功耗低的时钟树单看时序报告前者好看但在实际硅片上后者可能更稳定。我在一个项目里被这个问题狠狠教育过。当时有一个模块时钟频率不算高CTS跑出来skew只有100ps出头看起来挺好。但到了IR-drop和功耗分析阶段发现时钟树上的buffer功耗占了模块总功耗的三分之一而且这些buffer的翻转电流高度集中把旁边一个敏感模拟模块的电源区都带崩了。后来重新调整了时钟树的平衡策略多花了一些skew指标换回了功耗和供电质量的健康。时钟树综合里的很多设计决策其实是在多个物理指标之间做权衡而不是单点最优。5.2 学会读CTS日志里的潜台词工具的日志和报告里藏着大量信息但用不熟练的人往往只抓最终skew值。我会特别关注以下几个信号clock tree depth如果过大说明平衡策略可能偏保守了要考虑是否某些分支负载太重。total buffer count如果比同工艺同规模的参考设计高出30%以上要警惕是否有无效平衡或者例外的设置出了问题。local skew和global skew的比值如果很大可能存在某个局部区域的负载极端不均衡需要回到布局层面去查。这些指标之间是联动的。光看一个数字很难判断时钟树质量把几个数字放在一起交叉验证很多隐藏问题就会显形。5.3 从CCopt的useful skew行为中学习时钟树的优化空间CCopt引擎引入的useful skew优化改变了传统CTS只追求平衡的思路。但这也同时意味着工具在CTS阶段对触发器位置的摆放会更敏感。同一个RTL两种不同的布局方案CTS跑出来的skew和latency可能天差地别。这提醒我们做CTS不能被动等工具处理要在布局阶段就有意识地优化关键路径上的触发器分布让它们尽可能拉近减少CTS的修复压力。换句话说真正的时钟信号质量保障是一个从floorplan、placement到CTS全程都要持续关注的过程。CTS只是把前面阶段积累的账一次性暴露出来而已。历经几个项目的打磨我自己形成了一个工作习惯每次跑完CTS除了看报告我一定会打开时钟树的可视化界面沿着从时钟源到最末级缓冲器的路径逐段看一遍transition、capacitance、delay数值的递变。这个习惯帮我发现了不少工具日志里没有直接报问题的隐患比如某个分支的transition在靠近触发器的地方突然劣化、某段走线负载明显异常等等。看多了之后对时钟信号在芯片里怎么走、怎么平衡、质量好坏会有一种直观的体感这种体感是任何教科书都教不会的只能在一次次项目迭代里积累。时钟信号这个主题往后还能继续深入的内容还有很多OCV的derate如何影响时钟树结构、AOCV/LV流程里时钟网络怎么建模、多工艺角的CTS如何收敛、甚至新兴的机器学习辅助时钟树优化方向。但核心思路不变——每一个时钟沿都是整个芯片行为的起搏点CTS这门手艺本质上就是把这颗心律调稳、调准、调省。