1. 时钟树综合到底在解决什么问题1.1 从一颗芯片的“心跳”说起时钟信号是整个同步数字电路的节拍器。你可以把它想象成一支交响乐团的指挥——如果指挥的手势在不同乐手眼里到达的时间不一致小提琴手已经拉完了大提琴手才刚准备起弓整个演奏就乱了。CTSClock Tree Synthesis时钟树综合要干的事情就是把这个指挥信号尽可能同时、尽可能快地送到芯片上成千上万个触发器手里。在先进工艺节点下时钟树的质量直接决定了芯片能不能跑到目标频率、能不能收敛时序、功耗会不会失控。我做过几个28nm和16nm的项目CTS阶段没调好后面绕线阶段再怎么修都是拆东墙补西墙最后要么降频要么面积爆炸。1.2 Skew和Latency这两个指标为什么让人头疼Skew时钟偏斜指的是同一个时钟域内时钟信号到达不同触发器的时间差。理想情况下所有触发器应该在同一时刻收到时钟沿但物理上不可能——走线长度不同、缓冲器延迟不同、负载不同都会造成偏差。Skew太大建立时间和保持时间的余量就被吃掉时序违例跟着来。Latency时钟延迟指的是从时钟源到触发器时钟引脚的总延迟。Latency本身不是坏事但不同路径之间的Latency差异会转化为Skew。而且Latency太大意味着时钟树插入了很多缓冲器功耗和面积都会上去。这两个指标是一对矛盾体。你压Skew可能要加更多缓冲器来平衡各条路径Latency就上去了你压Latency树做得浅Skew又容易失控。所以CTS调优的本质是在Skew、Latency、功耗、面积之间找平衡点。1.3 什么阶段该做CTS什么阶段不该碰很多新手容易犯的一个错误是综合刚出来、布局还没做好就急着跑CTS。这时候标准单元位置都没定时钟树综合出来的结果毫无意义。正确的顺序是综合→布局→时钟树综合→绕线→时序签核。CTS必须在布局之后、绕线之前做因为时钟树需要知道触发器的物理位置才能规划走线。另外如果设计里还有大量未约束的路径、未修复的DRC违例先别碰CTS。CTS会放大这些问题让你在后面更难定位根因。我的习惯是跑CTS之前先确认布局阶段的WNS和TNS已经收敛到可接受范围时钟定义没有遗漏然后才开始。2. 调优之前必须搞清楚的几个核心概念2.1 Skew Calibration到底在做什么Skew Calibration偏斜校准是Innovus里一个非常关键的机制。简单说它是在CTS过程中自动调整时钟树结构让到达各个叶子节点的延迟尽可能一致。它的工作原理不是简单地加缓冲器而是通过调整缓冲器的驱动强度、插入位置、走线层次来精细控制每条路径的延迟。我通常会在CTS配置里打开ccopt相关的skew calibration选项。实测下来打开和不开Skew能差30%到50%。但要注意Skew Calibration会消耗更多的计算资源和运行时间如果设计规模很大跑一次可能要几个小时。所以建议先用小规模测试跑通流程再上全芯片。2.2 单View和多View的取舍这是被问得最多的问题之一CTS到底以一个view为主还是多个view一起做我的经验是取决于你的设计有没有多模式多端角的需求。如果芯片只在一个电压频率组合下工作那单view就够了简单直接运行快。但如果设计需要在不同电压、不同温度、不同频率下都满足时序那就必须做多view CTS。多view CTS的核心思路是在每个view下分别约束时钟然后让CTS引擎找一个在所有view下都满足要求的解。这比单view复杂得多运行时间可能翻倍甚至更多。我一般会先跑单view拿到一个baseline再开多view看差异有多大。如果差异很小说明设计对端角不敏感可以简化如果差异很大那就老老实实做多view。2.3 Latency的构成与分解Latency可以拆成几部分时钟源到时钟树根节点的延迟source latency、时钟树内部的缓冲器延迟network latency、走线延迟wire latency。其中source latency通常是固定的你能优化的是network latency和wire latency。降低Latency的手段包括减少时钟树级数、使用更高驱动强度的缓冲器、优化走线层次尽量走高层金属电阻小、减少负载电容。但每一条都有代价——级数太少Skew控制不住驱动太强功耗上去走高层金属可能和信号线抢资源。3. Innovus CTS的完整实操流程3.1 环境准备与配置文件在跑CTS之前你需要准备好几个东西LEF文件包含标准单元和宏单元的物理信息、DEF文件布局后的设计、SDC文件时序约束、以及CTS的配置文件。我的CTS配置文件通常包含以下内容# 时钟树基本配置 set_ccopt_property target_skew 50ps set_ccopt_property target_max_trans 150ps set_ccopt_property target_max_cap 80fF # 缓冲器选择 set_ccopt_property buffer_cells {CLKBUF_X2 CLKBUF_X4 CLKBUF_X8} set_ccopt_property inverter_cells {CLKINV_X2 CLKINV_X4 CLKINV_X8} # Skew calibration set_ccopt_property skew_calibration true set_ccopt_property skew_calibration_effort high # 走线层次 set_ccopt_property routing_layer_range {M4 M6}这些参数不是拍脑袋定的。target_skew要根据你的时钟周期来定——一般取时钟周期的5%到10%。比如周期是1nsSkew目标设在50ps到100ps之间比较合理。target_max_trans影响信号完整性太大会导致时钟沿变缓太小又需要更多缓冲器。3.2 时钟树规格定义定义时钟树规格是CTS最关键的一步。你需要告诉Innovus哪些是时钟根、哪些是叶子节点、时钟频率是多少、有没有时钟门控。create_clock -name core_clk -period 1.0 [get_ports clk_in] set_clock_tree_options -clock core_clk \ -target_skew 50ps \ -max_transition 150ps \ -leaf_pin_list [get_pins {FF1/CK FF2/CK ...}]这里有个坑叶子节点列表一定要准确。如果漏了某个触发器CTS就不会去平衡它的时钟路径Skew会很大。我一般会用脚本自动提取所有时钟叶子节点避免手工遗漏。3.3 运行CTS与初步检查配置好之后运行ccopt_design命令启动CTS。跑完之后Innovus会生成一份报告包含Skew、Latency、缓冲器数量、时钟树级数等信息。我第一时间会看三个东西全局Skew、最大Latency、缓冲器数量。如果Skew超过目标值先别急着调参数看看是哪些路径拉高了Skew。用report_clock_tree -skew可以列出每条路径的延迟找出偏差最大的那些。3.4 迭代调优的具体手法调优是一个迭代过程。我的常规操作顺序是第一轮调整缓冲器列表。如果Skew大但Latency还可以说明缓冲器驱动能力不够或者类型太单一。加入更多驱动强度的缓冲器让CTS引擎有更多选择。第二轮调整走线层次。如果Latency大检查时钟树是不是走了低层金属。低层金属电阻大延迟高。把时钟树限制在高层金属上Latency能降不少。第三轮调整Skew Calibration力度。如果前两轮效果不明显把skew_calibration_effort从medium调到high。这会增加运行时间但Skew改善明显。第四轮手动干预。如果自动调优还是达不到目标就需要手动插入缓冲器或者调整某些关键路径的走线。这一步要谨慎手动改动容易引入新的问题。4. 常见问题与排查技巧实录4.1 Skew压不下去怎么办这是最常遇到的问题。我的排查顺序是先看叶子节点定义有没有遗漏。我遇到过一次某个时钟域下有一组触发器的时钟引脚没有被识别为叶子节点导致CTS完全没管它们Skew直接爆到200ps以上。后来用report_clock_tree -leaf_pins检查才发现。再看缓冲器列表是不是太窄。如果只有一种驱动强度的缓冲器CTS引擎没有调整空间。加入X2、X4、X8甚至X16的缓冲器让引擎自己选。最后看物理约束。如果某些触发器被放在很偏的位置或者周围布线资源紧张CTS很难平衡。这时候可能需要回到布局阶段调整这些触发器的位置。4.2 Latency突然变大是什么原因Latency突然变大通常有几个原因时钟树级数增加了、走了低层金属、负载电容变大、或者缓冲器驱动能力不足。我一般会先看时钟树的级数报告。如果级数比上一轮多了说明CTS为了压Skew插入了更多缓冲器。这时候要权衡Skew和Latency哪个更重要。如果时序余量够可以适当放宽Skew目标换回Latency。另一个常见原因是时钟门控单元ICG的插入。ICG本身有延迟如果大量使用ICGLatency会上去。这时候可以考虑把ICG移到时钟树的更上游位置减少它对叶子节点的影响。4.3 多View CTS跑不完或者结果很差多View CTS对计算资源要求很高。如果跑不完先检查是不是view数量太多。有些设计有几十个view全开肯定跑不动。我的做法是先做view的聚类分析把相似的view合并只保留有代表性的几个。如果结果很差检查每个view的约束是不是一致。我遇到过SDC里某个view的时钟定义写错了导致CTS在那个view下完全跑偏。用report_clocks逐个view检查确保时钟定义正确。4.4 时钟树功耗太高怎么优化时钟树功耗通常占芯片总功耗的20%到40%优化空间很大。我的手段包括减少缓冲器数量通过优化Skew目标、降低时钟频率如果系统允许、使用时钟门控在不需要时钟的时候关掉、以及选择低功耗的缓冲器单元。但要注意降低功耗不能牺牲时序。我一般会先保证时序收敛再在余量范围内优化功耗。如果时序本身就很紧那就别想着省功耗了。5. 一些踩过的坑和实操心得5.1 不要迷信自动调优Innovus的自动CTS很强但不是万能的。我做过一个设计自动CTS跑出来的Skew是45ps看起来不错但后来发现有一组触发器的时钟路径绕了很远Latency比别的路径大了200ps。自动工具只关心Skew不关心Latency的绝对值。所以跑完自动CTS之后一定要人工检查Latency分布看看有没有异常大的路径。5.2 时钟树综合不是一次就能做好的我见过很多新手跑一次CTSSkew没达标就慌了。其实CTS本来就是一个迭代过程。我的习惯是至少跑三轮第一轮用默认配置拿baseline第二轮调整参数第三轮精细调优。每轮之间分析报告找出瓶颈再针对性调整。5.3 和布局工程师保持沟通CTS的问题很多时候根源在布局。如果触发器摆得太散或者关键路径上的触发器离得太远CTS再怎么调也白搭。我一般会在CTS之前和布局工程师过一遍时钟域的物理分布确保触发器相对集中减少CTS的压力。5.4 记录每一次调优的参数和结果这个习惯让我受益很多。每次调优我都会记录改了什么参数、Skew和Latency变成了多少、运行时间是多少。这样下次遇到类似问题可以直接查记录不用从头试。我现在的项目里CTS调优记录已经积累了几十页成了团队里的参考文档。5.5 别忘了检查时钟树的DRCCTS跑完之后时钟树上可能会有DRC违例比如最小宽度、最小间距、天线效应等。这些违例如果不修绕线阶段会出问题。我一般会用verify_clock_tree命令检查确保时钟树干净。6. 从CTS到绕线后续阶段的衔接CTS做完之后时钟树就固定下来了。接下来的绕线阶段时钟树通常会被设置为“dont touch”避免绕线工具改动时钟树结构。但有时候绕线工具会报告时钟树上的DRC问题这时候需要回到CTS阶段修复而不是让绕线工具强行改。另外CTS之后的时序签核要用带时钟树信息的网表。如果CTS阶段有手动改动一定要更新网表否则签核结果和实际不一致。我个人的体会是CTS是数字后端设计里最需要耐心和经验的环节之一。工具能帮你做80%的工作但剩下20%的调优靠的是对设计本身的理解和对工具行为的预判。多跑、多看、多记录慢慢就有感觉了。
1. 时钟树综合到底在解决什么问题1.1 从一颗芯片的“心跳”说起时钟信号是整个同步数字电路的节拍器。你可以把它想象成一支交响乐团的指挥——如果指挥的手势在不同乐手眼里到达的时间不一致小提琴手已经拉完了大提琴手才刚准备起弓整个演奏就乱了。CTSClock Tree Synthesis时钟树综合要干的事情就是把这个指挥信号尽可能同时、尽可能快地送到芯片上成千上万个触发器手里。在先进工艺节点下时钟树的质量直接决定了芯片能不能跑到目标频率、能不能收敛时序、功耗会不会失控。我做过几个28nm和16nm的项目CTS阶段没调好后面绕线阶段再怎么修都是拆东墙补西墙最后要么降频要么面积爆炸。1.2 Skew和Latency这两个指标为什么让人头疼Skew时钟偏斜指的是同一个时钟域内时钟信号到达不同触发器的时间差。理想情况下所有触发器应该在同一时刻收到时钟沿但物理上不可能——走线长度不同、缓冲器延迟不同、负载不同都会造成偏差。Skew太大建立时间和保持时间的余量就被吃掉时序违例跟着来。Latency时钟延迟指的是从时钟源到触发器时钟引脚的总延迟。Latency本身不是坏事但不同路径之间的Latency差异会转化为Skew。而且Latency太大意味着时钟树插入了很多缓冲器功耗和面积都会上去。这两个指标是一对矛盾体。你压Skew可能要加更多缓冲器来平衡各条路径Latency就上去了你压Latency树做得浅Skew又容易失控。所以CTS调优的本质是在Skew、Latency、功耗、面积之间找平衡点。1.3 什么阶段该做CTS什么阶段不该碰很多新手容易犯的一个错误是综合刚出来、布局还没做好就急着跑CTS。这时候标准单元位置都没定时钟树综合出来的结果毫无意义。正确的顺序是综合→布局→时钟树综合→绕线→时序签核。CTS必须在布局之后、绕线之前做因为时钟树需要知道触发器的物理位置才能规划走线。另外如果设计里还有大量未约束的路径、未修复的DRC违例先别碰CTS。CTS会放大这些问题让你在后面更难定位根因。我的习惯是跑CTS之前先确认布局阶段的WNS和TNS已经收敛到可接受范围时钟定义没有遗漏然后才开始。2. 调优之前必须搞清楚的几个核心概念2.1 Skew Calibration到底在做什么Skew Calibration偏斜校准是Innovus里一个非常关键的机制。简单说它是在CTS过程中自动调整时钟树结构让到达各个叶子节点的延迟尽可能一致。它的工作原理不是简单地加缓冲器而是通过调整缓冲器的驱动强度、插入位置、走线层次来精细控制每条路径的延迟。我通常会在CTS配置里打开ccopt相关的skew calibration选项。实测下来打开和不开Skew能差30%到50%。但要注意Skew Calibration会消耗更多的计算资源和运行时间如果设计规模很大跑一次可能要几个小时。所以建议先用小规模测试跑通流程再上全芯片。2.2 单View和多View的取舍这是被问得最多的问题之一CTS到底以一个view为主还是多个view一起做我的经验是取决于你的设计有没有多模式多端角的需求。如果芯片只在一个电压频率组合下工作那单view就够了简单直接运行快。但如果设计需要在不同电压、不同温度、不同频率下都满足时序那就必须做多view CTS。多view CTS的核心思路是在每个view下分别约束时钟然后让CTS引擎找一个在所有view下都满足要求的解。这比单view复杂得多运行时间可能翻倍甚至更多。我一般会先跑单view拿到一个baseline再开多view看差异有多大。如果差异很小说明设计对端角不敏感可以简化如果差异很大那就老老实实做多view。2.3 Latency的构成与分解Latency可以拆成几部分时钟源到时钟树根节点的延迟source latency、时钟树内部的缓冲器延迟network latency、走线延迟wire latency。其中source latency通常是固定的你能优化的是network latency和wire latency。降低Latency的手段包括减少时钟树级数、使用更高驱动强度的缓冲器、优化走线层次尽量走高层金属电阻小、减少负载电容。但每一条都有代价——级数太少Skew控制不住驱动太强功耗上去走高层金属可能和信号线抢资源。3. Innovus CTS的完整实操流程3.1 环境准备与配置文件在跑CTS之前你需要准备好几个东西LEF文件包含标准单元和宏单元的物理信息、DEF文件布局后的设计、SDC文件时序约束、以及CTS的配置文件。我的CTS配置文件通常包含以下内容# 时钟树基本配置 set_ccopt_property target_skew 50ps set_ccopt_property target_max_trans 150ps set_ccopt_property target_max_cap 80fF # 缓冲器选择 set_ccopt_property buffer_cells {CLKBUF_X2 CLKBUF_X4 CLKBUF_X8} set_ccopt_property inverter_cells {CLKINV_X2 CLKINV_X4 CLKINV_X8} # Skew calibration set_ccopt_property skew_calibration true set_ccopt_property skew_calibration_effort high # 走线层次 set_ccopt_property routing_layer_range {M4 M6}这些参数不是拍脑袋定的。target_skew要根据你的时钟周期来定——一般取时钟周期的5%到10%。比如周期是1nsSkew目标设在50ps到100ps之间比较合理。target_max_trans影响信号完整性太大会导致时钟沿变缓太小又需要更多缓冲器。3.2 时钟树规格定义定义时钟树规格是CTS最关键的一步。你需要告诉Innovus哪些是时钟根、哪些是叶子节点、时钟频率是多少、有没有时钟门控。create_clock -name core_clk -period 1.0 [get_ports clk_in] set_clock_tree_options -clock core_clk \ -target_skew 50ps \ -max_transition 150ps \ -leaf_pin_list [get_pins {FF1/CK FF2/CK ...}]这里有个坑叶子节点列表一定要准确。如果漏了某个触发器CTS就不会去平衡它的时钟路径Skew会很大。我一般会用脚本自动提取所有时钟叶子节点避免手工遗漏。3.3 运行CTS与初步检查配置好之后运行ccopt_design命令启动CTS。跑完之后Innovus会生成一份报告包含Skew、Latency、缓冲器数量、时钟树级数等信息。我第一时间会看三个东西全局Skew、最大Latency、缓冲器数量。如果Skew超过目标值先别急着调参数看看是哪些路径拉高了Skew。用report_clock_tree -skew可以列出每条路径的延迟找出偏差最大的那些。3.4 迭代调优的具体手法调优是一个迭代过程。我的常规操作顺序是第一轮调整缓冲器列表。如果Skew大但Latency还可以说明缓冲器驱动能力不够或者类型太单一。加入更多驱动强度的缓冲器让CTS引擎有更多选择。第二轮调整走线层次。如果Latency大检查时钟树是不是走了低层金属。低层金属电阻大延迟高。把时钟树限制在高层金属上Latency能降不少。第三轮调整Skew Calibration力度。如果前两轮效果不明显把skew_calibration_effort从medium调到high。这会增加运行时间但Skew改善明显。第四轮手动干预。如果自动调优还是达不到目标就需要手动插入缓冲器或者调整某些关键路径的走线。这一步要谨慎手动改动容易引入新的问题。4. 常见问题与排查技巧实录4.1 Skew压不下去怎么办这是最常遇到的问题。我的排查顺序是先看叶子节点定义有没有遗漏。我遇到过一次某个时钟域下有一组触发器的时钟引脚没有被识别为叶子节点导致CTS完全没管它们Skew直接爆到200ps以上。后来用report_clock_tree -leaf_pins检查才发现。再看缓冲器列表是不是太窄。如果只有一种驱动强度的缓冲器CTS引擎没有调整空间。加入X2、X4、X8甚至X16的缓冲器让引擎自己选。最后看物理约束。如果某些触发器被放在很偏的位置或者周围布线资源紧张CTS很难平衡。这时候可能需要回到布局阶段调整这些触发器的位置。4.2 Latency突然变大是什么原因Latency突然变大通常有几个原因时钟树级数增加了、走了低层金属、负载电容变大、或者缓冲器驱动能力不足。我一般会先看时钟树的级数报告。如果级数比上一轮多了说明CTS为了压Skew插入了更多缓冲器。这时候要权衡Skew和Latency哪个更重要。如果时序余量够可以适当放宽Skew目标换回Latency。另一个常见原因是时钟门控单元ICG的插入。ICG本身有延迟如果大量使用ICGLatency会上去。这时候可以考虑把ICG移到时钟树的更上游位置减少它对叶子节点的影响。4.3 多View CTS跑不完或者结果很差多View CTS对计算资源要求很高。如果跑不完先检查是不是view数量太多。有些设计有几十个view全开肯定跑不动。我的做法是先做view的聚类分析把相似的view合并只保留有代表性的几个。如果结果很差检查每个view的约束是不是一致。我遇到过SDC里某个view的时钟定义写错了导致CTS在那个view下完全跑偏。用report_clocks逐个view检查确保时钟定义正确。4.4 时钟树功耗太高怎么优化时钟树功耗通常占芯片总功耗的20%到40%优化空间很大。我的手段包括减少缓冲器数量通过优化Skew目标、降低时钟频率如果系统允许、使用时钟门控在不需要时钟的时候关掉、以及选择低功耗的缓冲器单元。但要注意降低功耗不能牺牲时序。我一般会先保证时序收敛再在余量范围内优化功耗。如果时序本身就很紧那就别想着省功耗了。5. 一些踩过的坑和实操心得5.1 不要迷信自动调优Innovus的自动CTS很强但不是万能的。我做过一个设计自动CTS跑出来的Skew是45ps看起来不错但后来发现有一组触发器的时钟路径绕了很远Latency比别的路径大了200ps。自动工具只关心Skew不关心Latency的绝对值。所以跑完自动CTS之后一定要人工检查Latency分布看看有没有异常大的路径。5.2 时钟树综合不是一次就能做好的我见过很多新手跑一次CTSSkew没达标就慌了。其实CTS本来就是一个迭代过程。我的习惯是至少跑三轮第一轮用默认配置拿baseline第二轮调整参数第三轮精细调优。每轮之间分析报告找出瓶颈再针对性调整。5.3 和布局工程师保持沟通CTS的问题很多时候根源在布局。如果触发器摆得太散或者关键路径上的触发器离得太远CTS再怎么调也白搭。我一般会在CTS之前和布局工程师过一遍时钟域的物理分布确保触发器相对集中减少CTS的压力。5.4 记录每一次调优的参数和结果这个习惯让我受益很多。每次调优我都会记录改了什么参数、Skew和Latency变成了多少、运行时间是多少。这样下次遇到类似问题可以直接查记录不用从头试。我现在的项目里CTS调优记录已经积累了几十页成了团队里的参考文档。5.5 别忘了检查时钟树的DRCCTS跑完之后时钟树上可能会有DRC违例比如最小宽度、最小间距、天线效应等。这些违例如果不修绕线阶段会出问题。我一般会用verify_clock_tree命令检查确保时钟树干净。6. 从CTS到绕线后续阶段的衔接CTS做完之后时钟树就固定下来了。接下来的绕线阶段时钟树通常会被设置为“dont touch”避免绕线工具改动时钟树结构。但有时候绕线工具会报告时钟树上的DRC问题这时候需要回到CTS阶段修复而不是让绕线工具强行改。另外CTS之后的时序签核要用带时钟树信息的网表。如果CTS阶段有手动改动一定要更新网表否则签核结果和实际不一致。我个人的体会是CTS是数字后端设计里最需要耐心和经验的环节之一。工具能帮你做80%的工作但剩下20%的调优靠的是对设计本身的理解和对工具行为的预判。多跑、多看、多记录慢慢就有感觉了。
