数字后端工程师的日常里时钟树综合CTS永远是那个让人又爱又恨的环节。爱的是它决定了芯片能不能跑到目标频率恨的是它总在你想不到的地方给你挖坑。最近我在做一个多电压域、多时钟域的模块时钟结构复杂到用传统的CTS flow跑出来的skew和insertion delay完全没法看于是重新捡起了Innovus的Flexible H-tree和Multi-tap Clock Flow。这套组合拳在先进工艺节点下几乎是绕不开的但官方文档写得过于手册化很多实操细节和踩坑经验根本不会告诉你。这篇内容是我自己跑完整个lab之后的完整复盘从环境准备到最终signoff每一步的意图、参数背后的逻辑、以及实测中遇到的意外情况都会讲到。如果你正在做7nm及以下的时钟树设计或者被复杂时钟域的skew问题折磨过这篇应该能帮你省下不少试错时间。1. 为什么传统CTS在复杂时钟域下会失效1.1 传统CTS flow的底层假设与局限传统CTS的核心逻辑是一棵树管所有。工具从clock root出发根据sink的分布和约束自动构建一棵平衡的时钟树。这个逻辑在单时钟域、sink分布均匀的场景下工作得很好但一旦遇到多时钟域交织、sink分布极度不均匀、或者存在大量跨域交互的情况问题就来了。最典型的症状是工具为了平衡所有sink的延迟会在某些路径上插入大量的buffer导致insertion delay飙升同时skew反而因为buffer的PVT变化而恶化。我这次的项目里有一个时钟域只有3个sink但分布在芯片的三个角落传统CTS硬是插了17级buffer来平衡结果OCV一开skew直接崩到没法看。另一个问题是clock gating cell的处理。传统flow下工具会把ICG当作普通sink来处理但实际上ICG的clock pin和enable pin的时序关系非常敏感如果CTS阶段没有特殊处理很容易在后续的timing signoff阶段发现ICG的setup/hold违例。1.2 Flexible H-tree的核心思路Flexible H-tree的思路完全不同。它不追求一棵树而是允许你手动定义时钟树的骨架结构。你可以把时钟域拆分成多个子区域每个区域用独立的H-tree来驱动然后在顶层用一个轻量的tree把各个H-tree的root连起来。这样做的好处是每个子区域的skew可以独立优化不会因为其他区域的sink分布而被迫插入额外的buffer。同时H-tree的对称结构天然对OCV友好因为对称路径上的PVT变化可以相互抵消。Innovus里的Flexible H-tree支持两种模式一种是完全手动定义H-tree的每一级分支点另一种是定义H-tree的leaf区域让工具自动生成中间的树结构。实际项目中我建议用第二种模式因为完全手动定义在sink数量多的时候工作量太大而且容易出错。1.3 Multi-tap Clock Flow解决的是什么问题Multi-tap Clock Flow解决的是一个时钟源驱动多个物理位置分散的负载的问题。传统做法是从clock root拉一根长线到远端然后在远端做CTS。但这根长线的延迟和PVT变化会直接传递到远端sink导致skew恶化。Multi-tap的思路是在芯片的多个位置放置tap point每个tap point从主干时钟网络上抽一个时钟信号然后在本地做CTS。这样每个tap point的本地skew可以做得很好而tap point之间的skew由主干网络的H-tree来保证。这两个flow结合起来基本可以覆盖先进工艺下所有复杂的时钟结构。下面我从环境准备开始一步步拆解整个实操过程。2. 环境准备与设计导入的隐藏细节2.1 Innovus版本选择与license配置Flexible H-tree和Multi-tap Clock Flow对Innovus版本有要求。我实测下来Innovus 20.10及以上版本支持得比较好19.x版本虽然也有这些命令但有些option缺失跑复杂flow的时候会报错。建议至少用21.10版本这个版本对Multi-tap的support最完整。License方面这两个flow不需要额外的license feature但需要确保你的license里有CTS相关的feature。可以在Innovus启动后用checkLicense命令确认。如果license不够工具会在跑CTS的时候报错但报错信息很隐晦不会直接告诉你缺哪个feature。启动Innovus的时候建议加上-overwrite选项避免因为上次跑挂了的lock文件导致启动失败。另外-no_gui模式在跑大批量实验的时候很有用可以省不少内存。innovus -overwrite -no_gui -files run_cts.tcl2.2 设计导入时MMMC配置的注意事项MMMCMulti-Mode Multi-Corner的配置直接决定了CTS的约束。我这次的项目有3个modefunc、test、low_power和5个cornerss、ff、tt、ss_cworst、ff_cbest配置的时候有几个坑第一CTS阶段只需要考虑setup和hold的极端corner不需要把所有corner都打开。打开太多corner会让CTS的runtime暴涨而且对结果没有实质帮助。我一般只开ss和ff两个cornerss看setupff看hold。第二clock uncertainty的设置要区分pre-CTS和post-CTS。pre-CTS阶段因为时钟树还没建uncertainty要设大一点一般设0.1~0.15nspost-CTS阶段可以收紧到0.05ns左右。这个设置如果搞反了要么CTS过度约束导致面积爆炸要么约束太松导致后续timing没法收敛。第三如果设计里有多个电压域MMMC里要正确配置level shifter的约束。Innovus在CTS阶段会自动处理level shifter但前提是你的MMMC配置正确。我遇到过因为level shifter约束没配好CTS把level shifter当普通buffer处理结果跨电压域的路径延迟完全不对。2.3 Floorplan对CTS的影响Floorplan的质量直接决定CTS能不能做好。我这次的项目因为前期floorplan没做好CTS阶段返工了两次。几个关键点macro的摆放要尽量规整避免在时钟树的主干路径上出现大的blockage。如果macro摆放太乱CTS工具会绕线导致insertion delay增加。我一般会在floorplan阶段就用reportCongestion检查一下时钟主干路径上的congestion情况。power plan的stripe密度也会影响CTS。如果stripe太密CTS的buffer可能放不下去工具会报no legal location的错误。建议在CTS之前用checkPlace确认一下有没有placement blockage。另外如果设计里有analog block或者memory要确保这些block的clock pin位置是合理的。我遇到过memory的clock pin在block的正中间CTS要从外面绕进去延迟特别大。这种情况要么调整memory的摆放方向要么在memory旁边手动放一个tap point。3. Flexible H-tree的实操配置与参数拆解3.1 H-tree骨架的定义方式Innovus里定义Flexible H-tree主要用createHtree命令。这个命令的参数比较多我挑几个关键的讲。createHtree -name htree_clk_core \ -root $root_pin \ -leaf $leaf_pins \ -level 3 \ -pattern H \ -balance true-level指定H-tree的级数。级数越多树的对称性越好但插入的buffer也越多。一般3~4级就够了超过4级的话buffer的延迟会抵消对称性带来的好处。我这次用的是3级实测skew可以控制在15ps以内。-pattern指定H-tree的图案支持H、X、T三种。H型适合矩形区域X型适合正方形区域T型适合长条形区域。选错了图案会导致树的对称性变差skew恶化。-balance选项控制是否做延迟平衡。如果打开工具会在H-tree的每个分支点插入buffer来平衡延迟。这个选项在sink分布不均匀的时候很有用但会增加面积和功耗。3.2 Leaf区域的划分策略Leaf区域的划分是Flexible H-tree最关键的一步。划分得好skew和面积都能优化划分得不好还不如用传统CTS。我的经验是leaf区域的大小要跟sink的数量和分布匹配。一般来说每个leaf区域包含50~200个sink比较合适。太少的话H-tree的级数会很多面积浪费太多的话leaf内部的skew不好控制。划分的时候还要考虑物理位置的规整性。尽量让每个leaf区域是一个矩形或者接近矩形的形状避免出现L型或者凹型。因为H-tree的对称结构要求leaf区域本身是对称的如果leaf区域形状不规则H-tree的对称性就没法保证。另外如果设计里有多个时钟域不同时钟域的leaf区域要分开划分不要混在一起。混在一起的话H-tree的root会变成多个时钟域的公共点导致时钟域之间的skew互相影响。3.3 H-tree的balance与skew控制H-tree建好之后需要用reportHtree检查一下结构是否合理。重点看几个指标指标含义合理范围Max skew最大skew 20psInsertion delay插入延迟 300psBuffer countbuffer数量根据面积预算Level count级数3~4级如果skew超标首先检查leaf区域的划分是否合理。如果leaf区域本身不对称H-tree再怎么调也没用。其次检查balance选项是否打开以及balance的target是否设置合理。Insertion delay超标的话一般是H-tree的级数太多或者root到leaf的路径太长。可以考虑减少级数或者在root附近加一个tap point来缩短路径。3.4 实测中遇到的H-tree结构异常我这次跑的时候遇到一个奇怪的问题H-tree建好之后reportHtree显示skew只有12ps但跑完CTS之后实际的skew变成了35ps。排查了半天发现是H-tree的leaf pin和实际的sink pin没有对齐。原因是我在定义leaf区域的时候用的是sink的instance name但Innovus在CTS阶段会把一些sink的clock pin重新映射到其他pin上比如ICG的clock pin会被映射到enable pin上。这就导致H-tree的leaf pin和实际CTS的sink pin不一致H-tree的对称性被破坏了。解决办法是在定义leaf区域的时候用-leaf_pin选项明确指定sink的clock pin而不是用instance name。这样即使Innovus做了pin映射H-tree的leaf pin也不会变。4. Multi-tap Clock Flow的tap point规划与实现4.1 tap point的物理位置选择Multi-tap的核心是tap point的规划。tap point放得好整个时钟网络的skew和insertion delay都能优化放得不好还不如不用。tap point的位置选择有几个原则第一tap point要尽量靠近sink密集的区域。如果某个区域有大量的sink在这个区域的中心放一个tap point可以大大缩短本地CTS的路径长度。第二tap point之间的距离要均匀。如果tap point之间的距离差异太大主干网络的H-tree就没法保证对称性tap point之间的skew会恶化。我一般会让tap point之间的距离控制在500~1000um之间。第三tap point要避开congestion严重的区域。如果tap point放在congestion严重的区域主干网络的绕线会很长insertion delay增加。可以在Innovus里用reportCongestion检查一下候选位置的congestion情况。4.2 tap point的时钟网络连接方式tap point和主干网络的连接方式有两种一种是直接连接一种是经过buffer连接。直接连接的方式简单但tap point的负载会直接加到主干网络上影响主干网络的skew。经过buffer连接的方式可以隔离tap point的负载但会增加一级buffer的延迟。我一般建议用经过buffer连接的方式特别是在tap point数量多的时候。因为主干网络的skew对tap point的负载非常敏感如果直接连接主干网络的skew会随着tap point数量的增加而恶化。连接的时候还要注意tap point的buffer要放在主干网络的H-tree的leaf位置而不是随便放。因为H-tree的leaf位置是对称的buffer放在leaf位置可以保证tap point之间的skew最小。4.3 Multi-tap flow下的CTS约束设置Multi-tap flow下的CTS约束和传统CTS不太一样。传统CTS的约束是直接设在clock root上Multi-tap flow的约束要分两层主干网络的约束和本地CTS的约束。主干网络的约束主要控制tap point之间的skew。这个约束一般设得比较松因为主干网络的H-tree本身就能保证对称性。我一般设20~30ps。本地CTS的约束主要控制tap point内部的skew。这个约束要设得紧一点因为本地CTS的sink数量少容易做得好。我一般设10~15ps。另外Multi-tap flow下要特别注意clock gating cell的处理。因为ICG可能分布在不同的tap point区域如果CTS阶段没有特殊处理ICG的enable pin的时序可能会出问题。Innovus提供了-icg选项来处理ICG建议打开。4.4 tap point数量与skew的权衡tap point的数量不是越多越好。tap point越多本地CTS的skew越好控制但主干网络的负载越重insertion delay越大。而且tap point本身也会占用面积和功耗。我这次的项目里试了3种tap point数量4个、8个、16个。实测结果如下tap point数量主干skew本地skewInsertion delay面积增量418ps22ps280ps1.2%815ps14ps310ps2.1%1612ps11ps380ps3.8%从数据看8个tap point是性价比最高的。16个虽然skew更好但insertion delay和面积都增加太多。4个的话本地skew有点超标。当然这个数据是针对我这次的项目不同的设计会有不同的最优值。建议在项目初期做几个实验找到最适合的tap point数量。5. 两个flow结合后的CTS结果验证与signoff5.1 CTS后的timing检查要点CTS跑完之后不能直接signoff要先做几项检查。第一检查clock tree的结构是否合理。用reportClockTree看一下clock tree的级数、buffer数量、skew、insertion delay。如果发现某个分支的buffer数量异常多可能是那个区域的sink分布有问题需要回去调整leaf区域或者tap point。第二检查clock gating cell的时序。用reportTiming -clock_gating看一下ICG的setup和hold是否满足。如果违例可能是CTS阶段没有正确处理ICG需要重新跑CTS并打开-icg选项。第三检查跨时钟域的路径。用reportTiming -cross_clock看一下跨时钟域的路径是否有违例。如果有可能是两个时钟域的skew差异太大需要调整H-tree的balance或者tap point的约束。5.2 OCV下的skew验证OCVOn-Chip Variation是CTS signoff的关键。CTS阶段跑出来的skew是在tt corner下的OCV一开skew会变大。我这次的项目tt corner下skew是15psOCV一开变成了28ps。OCV下的skew验证要用reportClockTree -ocv命令。这个命令会考虑PVT变化对clock tree的影响给出OCV下的skew。如果OCV下的skew超标有几个办法一是增加H-tree的级数提高对称性。对称性越好OCV的影响越小。二是减少buffer的数量。buffer越多OCV的累积效应越明显。三是用clock shielding。clock shielding可以减少clock net的耦合电容降低PVT变化的影响。5.3 功耗与面积的最终权衡CTS的最终目标是timing、功耗、面积的平衡。Flexible H-tree和Multi-tap flow虽然能优化skew但会增加buffer数量和面积。我这次的项目CTS后的面积增量是2.1%功耗增量是3.5%。这个代价在先进工艺下是可以接受的因为skew的优化带来的频率提升可以抵消面积和功耗的增加。如果面积预算特别紧可以考虑减少H-tree的级数或者tap point的数量。但要注意skew会相应变差可能影响频率。5.4 实测中遇到的OCV违例与修复过程我这次遇到一个OCV违例在ss_cworst corner下某个tap point的本地skew超标了。排查发现这个tap point的sink分布特别不均匀一半的sink在左边一半在右边而且右边的sink距离tap point特别远。修复过程首先尝试调整tap point的位置往右边移了一点但效果不明显。然后尝试在这个tap point内部再分一个子tap point把右边的sink单独用一个子tap point来驱动。这样调整之后OCV下的skew从35ps降到了22ps满足了约束。这个经验说明tap point的sink分布均匀性很重要。如果某个tap point的sink分布不均匀要么调整tap point的位置要么在内部再分子tap point。6. 几个容易踩的坑与实操心得6.1 H-tree的leaf pin映射问题前面提到过H-tree的leaf pin和实际CTS的sink pin不一致会导致skew恶化。这个坑我踩了两次第一次是ICG的pin映射第二次是level shifter的pin映射。解决办法是在定义leaf区域的时候用-leaf_pin选项明确指定sink的clock pin。另外在CTS之前用reportClockTree -leaf检查一下leaf pin和实际sink pin是否一致。如果不一致要手动修正。6.2 Multi-tap flow下的clock gating处理Multi-tap flow下ICG可能分布在不同的tap point区域。如果CTS阶段没有正确处理ICGICG的enable pin的时序会出问题。Innovus提供了-icg选项来处理ICG。打开这个选项后工具会把ICG的clock pin和enable pin一起考虑确保enable pin的时序满足。但这个选项会增加CTS的runtime而且可能会增加buffer数量。我的建议是如果设计里ICG数量不多可以打开这个选项如果ICG数量很多可以考虑手动处理把ICG的enable pin的约束单独设。6.3 tap point的buffer选择tap point的buffer选择也很关键。我一般用CLKBUF系列因为CLKBUF的驱动能力强延迟小。但CLKBUF的面积比普通BUF大如果面积预算紧可以用普通BUF。另外tap point的buffer的驱动能力要根据负载来选。如果tap point的负载大要用驱动能力强的buffer如果负载小可以用驱动能力弱的buffer。选错了会导致延迟增加或者skew恶化。6.4 CTS后的clock net绕线优化CTS跑完之后clock net的绕线可能不是最优的。可以用optClockTree命令做一下绕线优化。这个命令会重新绕clock net减少绕线长度和耦合电容。但要注意optClockTree可能会改变clock tree的结构导致skew变化。所以跑完optClockTree之后要重新检查skew和insertion delay。6.5 实验设计的重要性最后说一点Flexible H-tree和Multi-tap flow的参数很多不同的参数组合会有不同的结果。建议在项目初期做几个实验找到最适合的参数组合。实验的时候可以用Innovus的-no_gui模式跑省内存。每个实验的runtime大概在30分钟到1小时之间取决于设计的规模和复杂度。我这次做了5个实验分别调整了H-tree的级数、tap point的数量、balance的target。最终选定的参数组合是H-tree 3级、tap point 8个、balance target 15ps。这个组合在skew、insertion delay、面积之间取得了最好的平衡。踩过几次坑之后我最大的体会是Flexible H-tree和Multi-tap Clock Flow不是一键优化的工具它们需要你对设计的时钟结构有清晰的理解然后手动定义骨架和tap point。工具能做的是在你定义的框架下做优化但框架本身的质量决定了最终结果的上限。所以花时间在floorplan和时钟结构规划上比花时间调CTS参数更值得。