CCOpt复杂时钟网络调试：配置核对与定点干预

简介面向集成电路物理实现工程师的Cadence Innovus CCOpt技术文档聚焦高性能、低功耗设计中复杂时钟网络的配置与调试问题。内容覆盖时钟树综合CTS基础术语、运行前的时钟约束与缓冲器选型设置以及时钟网络分析、时钟树构建、时钟优化、后处理和验证四个阶段各自的调试点并展开基本检查、CCOpt时钟树调试器、时钟路径追踪与跨视图探测、报告命令、CCOpt属性分析等调试手段还涉及数据路径屏蔽、时钟点刻意偏斜、非连通时钟树平衡、公共主时钟派生从时钟处理等架构性时钟控制场景适合具备一定数字后端基础、需处理复杂时钟网络时序的设计师对照实践。资源包共1个pdf文件约1.3MB为官方英文技术指南结构按目的、受众、术语、准备、流程阶段与调试技术顺序编排便于按章节检索。目前已有211人学习可作为CTS阶段配置与排错时的案头参考。1. 时钟树综合后时序反而更差一个反直觉的常见坑跑完 CCOptreport_timing一看setup 非但没收敛某些路径反而比 CTS 之前更糟或者 hold 出现大面积违例时钟树看着平衡latency 却对不上。这类问题在复杂时钟网络里出现频率极高尤其在多时钟域、门控时钟多、宏单元带时钟直通的 Design 里一根时钟从源到 sink 跨了三四层结构SDC 根本没法完整描述真实时钟架构。新手第一反应是加大优化力度老手会先停掉流程回头看时钟抽取和 skew group 划分。这份《Configuration and Debug of Complex Clock Networks Using CCOpt》面向的就是 Innovus 18.1/19.1 下这类场景讲的是把时钟网络拆开、看清结构、再做定点干预的排查方法。如果你也在 cadence innovus cts 流程里被“越优化越差”折腾过下面的排查顺序可以直接抄。2. 越优化越差先确认基础配置没埋雷CCOpt 能自动从库、Design、SDC 里推断大部分参数问题是这些数据源的设定本来是为 signoff 服务的直接拿来建树结果大概率不是最优。很多“优化不动”或者“建出来的树又大又慢”根因就在开跑之前那几行配置没显式设置。2.1 单元列表为空与 dont_use 被覆盖最容易翻车的一条cts_buffer_cells、cts_inverter_cells这些列表留空。空列表在 CCOpt 里不是“不限制”而是“所有单元都参与挑选”不管 Vt 家族、不管驱动能力最后选出来的 buffer 可能尺寸离谱面积和功耗一起爆。另外要特别注意CCOpt property 里指定的单元会覆盖库定义的dont_use而 18.1 之后用户手动设的 dont touch 会被尊重。也就是说你写进列表里的单元哪怕库标了禁用照样会被用。# legacy 命令写法显式给出可用单元列表 set_ccopt_property buffer_cells {BUF_X2 BUF_X4 BUF_X8} set_ccopt_property inverter_cells {INV_X2 INV_X4 INV_X8} set_ccopt_property clock_gating_cells {CKGATE_X2 CKGATE_X4} set_ccopt_property logic_cells {AND2_X2 OR2_X2 MUX2_X2} # CUIStylus写法 set_db cts_buffer_cells {BUF_X2 BUF_X4 BUF_X8} set_db cts_inverter_cells {INV_X2 INV_X4 INV_X8} set_db cts_clock_gating_cells {CKGATE_X2 CKGATE_X4} set_db cts_clock_gating_cells {CKGATE_X2 CKGATE_X4}逻辑说明这几个 property 决定了时钟树构建时可用的“积木”。buffer 和 inverter 决定树的驱动能力分布clock gating cell 决定门控逻辑能不能被一起优化设了之后能显著减少额外插 buffer 的数量logic cell 让组合逻辑也进入优化范围。参数上每个列表里放 23 档驱动就够放太多会让求解空间变大、run time 上升。如果设计里有 always-on 单元必须手动加进列表工具不会替你补。配完之后不是就完事了工具内部还会对库列表做过滤和裁剪你给的单元不一定全被用上。想知道为什么某个单元没被选中直接查# 查看单元被过滤的原因 report_ccopt_cell_filtering_reasons report_cts_cell_filtering_reasons这两条报告会列出每个候选单元被剔除的理由比如驱动不够、Vt 不匹配、被 dont use 排除。我一般会在正式跑之前先跑一遍确认列表里没有整类单元被静默过滤掉——这种情况下的报错不会出现在 log 里只会表现为“树建得不对劲”。2.2 transition 与 skew 目标过紧反而制造问题target_max_trans和target_skew是影响时钟网络规模和功耗最大的两个参数也是最容易被拍脑袋设错的两个。skew 目标设得过紧工具会拼命做平衡插一堆 buffer面积上去、功耗上去结果时序收益很有限在低功耗设计里transition 目标设得过严时钟网络的电容和动态功耗会成倍增长。而且这两个参数不只影响建树阶段还会影响 clustering 阶段也就是说结构调试的时候它们必须已经设对。# legacy set_ccopt_property target_max_trans 0.12 set_ccopt_property target_skew 0.05 # CUI set_db cts_target_max_transition_time 0.12 set_db cts_target_skew 0.05参数含义target_max_trans单位与工艺库时间单位一致常见 ns一般取库内标准单元典型 transition 的 1.52 倍作为起点target_skew是同一 skew group 内 sink 之间的目标偏差不是越小越好通常取时钟周期的 3%5% 起步再按结果调整。如果 SDC 里带了 transition/skew 约束不设全局目标时工具会退回用 SDC 的值所以两处都要看一眼是否一致。提示过紧的 skew 目标在复杂时钟结构里会触发过量平衡表现为某些分支 buffer 数量异常多。遇到这种情况先放宽目标再对比面积和时序而不是继续加优化选项。2.3 抽取前必须落地的 sink 与路由设置时钟抽取阶段决定了工具“看见”的是什么样的时钟网络。sink_typestop / ignore / exclude用来裁剪抽取范围stop 表示到此为止不再往下追ignore 表示这个点不算 sinkexclude 表示整条路径排除。带宏单元时钟直通、或者有测试逻辑挂在时钟上的设计如果不设 sink_type抽取出来的网络会混进一堆本不该参与平衡的点。# 时钟网络走非默认布线规则 create_route_type -name clk_ndr_1 -bottom_preferred_routing_layer M3 \ -top_preferred_routing_layer M7 -width_multiplier 2 set_ccopt_property route_type -net_type {top trunk leaf} clk_ndr_1 # CUI 对应写法 set_db cts_route_type_top clk_ndr_1 set_db cts_route_type_trunk clk_ndr_1 set_db cts_route_type_leaf clk_ndr_1逻辑说明时钟网络默认走普通布线规则宽度和间距都不够RC 提取出来偏大latency 和 skew 都会受影响。给 top/trunk/leaf 三级分别指定 NDR 是常规做法也可以只给 trunk 和 top 加宽。参数上width_multiplier 2表示线宽翻倍层范围按工艺调整低层金属电阻大一般不让时钟走太低层。抽取设置extraction settings通常不用动除非你的 RC 提取配置本身有问题。还有一条容易被忘的update_io_latency。芯片级设计或者时钟架构特别复杂的 Design建树时修改 IO latency 会让整条时钟路径的延迟基准漂移后面怎么调都对不上。# 关闭 latency 修改chip level 场景常用 set_ccopt_property update_io_latency false set_db cts_update_clock_latency false3. 时钟树看着平衡但时序崩了分阶段停下来看复杂时钟网络最忌讳一口气跑完再看结果。CCOpt 的构建分 cluster、trial、full 三个阶段每个阶段能暴露的问题不一样中途停下来看中间结果往往能提前发现面积、功耗、时序上的优化空间——这些在最终结果里是看不出来的。有个硬限制要记住cluster 和 trial 阶段停下后不能续跑只能重来所以停之前想清楚要看什么。3.1 三个构建阶段各自能查出什么cluster 阶段做的是 sink 聚类和初步结构规划这时候能看出 skew group 划分是否合理如果某个 group 的 sink 数量异常多、或者地理分布极度分散说明 SDC 或结构约束没描述清楚时钟的真实归属。trial 阶段会试建一部分树用来看 buffer 类型选择和初步平衡效果重点看有没有出现异常长的路径或者驱动明显不足的分支。full 阶段才是完整建树到这里主要验证最终 skew、transition 和 DRC。分阶段跑的命令结构大致是这样关键是-stage参数的取值# 抽取时钟网络之后所有针对 clock_tree / skew_group 的设置都要在这之后 ccopt_design -cts -extract # ...此处做 sink_type、per-group 属性等修改... # 只跑到 clustering 阶段检查分组是否合理 ccopt_design -cts -stage cluster # 检查后重跑跑到 trial ccopt_design -cts -stage trial # 完整建树 ccopt_design -cts逻辑说明-extract只做时钟抽取不建树是插入各类 per-group 设置的唯一窗口期。cluster 和 trial 是观测窗口不是可以接着往下走的中间态观察完必须从头跑。full 阶段没有-stage参数直接执行即可。这样拆开跑单次耗时短出问题时也容易定位到是分组错了还是建树策略错了。3.2 skew group 与 clock tree 不是一回事这两个术语在实际设计里经常被混用。skew group 是 CCOpt 用来“搭结构、做初步平衡”的结构性划分clock tree 是它做“平衡”的时钟网络子集。大多数设计里两者是 1:1但复杂结构下一个 clock tree 可能对应好几个 skew group。理解这个区别的意义在于当你在 clock tree 层面调不动的时候问题可能出在 skew group 的划分上得回去改抽取结果或者 SDC。抽取完成后可以做的操作包括修改工具自动生成的 clock 和 skew group、增删 skew group、对单个 clock 或 group 施加专属属性、覆盖从 SDC 推出来的属性比如 SDC 里的 transition/skew 目标在没有全局目标时会被采用。这一层是架构级调试的主战场后面的很多“定点干预”都是在这一步做。注意exclusive skew group 的创建要慎重。它会让工具认为这些 group 之间不需要互相平衡用错地方会直接导致跨域 skew 失控而且这种问题在最终报告里表现为“某些路径莫名 hold 违例”很难反推到分组设置上。3.3 用属性查询反推设计意图CCOpt 的 property 不只用来设也可以用来读。当你不确定工具当前“认为”的时钟结构是什么样先查属性比看 log 快得多。# 查看当前生效的全局与分组属性 get_ccopt_property target_skew get_ccopt_property -clock_tree tree_name target_skew get_ccopt_property -skew_group group_name buffer_cells # 列出所有 clock tree 与 skew group report_ccopt_clock_trees report_ccopt_skew_groups逻辑说明get_ccopt_property不带-clock_tree/-skew_group时查全局值带上就查该层级的覆盖值。这一对比经常能发现“全局设了但分组上被 SDC 覆盖了”的情况。report_ccopt_*系列报告输出结构清单重点看 group 数量、每个 group 的 sink 数和归属跟你在 SDC 里写的时钟关系对照不一致的地方就是抽取出问题的地方。4. 定点干预架构级调整的几种实战场景分析做完如果确认问题出在时钟结构本身而不是 SDC 写得不对就需要对建树过程做定向干预。这一节列的都是复杂时钟网络里高频出现的场景共同点是默认行为在这个结构下是错的必须手工告诉工具“这里不该这么做”。4.1 把数据通路挡在时钟网络之外很多设计里时钟会经过一段组合逻辑再分发给下游比如带使能控制的时钟门控链、或者为了功能安全加的冗余逻辑。默认情况下 CCOpt 可能把这些数据通路上的单元也当成时钟网络的一部分去做平衡结果插了一堆本不需要的 buffer或者把数据路径的时序拖垮。# 把指定 instance 或 pin 标记为时钟抽取的边界 set_ccopt_property sink_type stop -pin inst/pin set_ccopt_property sink_type ignore -pin inst/pin set_ccopt_property sink_type exclude -pin inst/pin三个取值的差别stop让抽取到此为止这个点本身仍是 sink参与平衡但不再往下追ignore表示这个点不算 sink路径继续往下抽exclude是整条路径都不进时钟网络。选错取值的典型症状是用了 stop 但下游还有真实的 sink那些 sink 就脱离了平衡skew 直接失控用了 exclude 但下游其实有时钟负载那部分时钟就根本没被建树时序分析会出现“时钟到达不了”的诡异违例。判断依据是看这个点下游到底还有没有需要平衡的寄存器。4.2 故意制造 skew 与拆开不相干的树有些场景需要主动引入 skew比如为了给关键路径腾出 setup 余量而让捕获时钟晚到或者多周期路径上的刻意错位。CCOpt 支持对特定时钟点设定 skew 目标但这里的原则是“少而准”只在被分析验证过的点上设设完必须重新验证跨域 hold。# 对指定 clock tree 施加非零目标 skew制造刻意的时钟偏移 set_ccopt_property -clock_tree tree_name target_skew 0.08 # 两个时钟树物理上不相干不需要互相平衡 set_ccopt_property -skew_group group_a exclusive true第一段的逻辑把某个 clock tree 的目标 skew 从全局值改成特定值工具会按新目标去平衡这个树从而实现相对其它树的偏移。参数要落在全局 skew 的合理范围内超出太多会引发其它分支的连锁重平衡。第二段的逻辑exclusive 声明这两个 group 之间无需平衡适用于 slave clock 由同一 master 派生但功能上不应互相对齐的情况。用错会导致本该对齐的时钟被拆开hold 大面积违例。与之相对的一个场景是“防止本应对齐的树被拆开”当多个 slave clock 从同一个 master 派生默认可能被分到不同 skew group 各自平衡结果彼此之间出现不该有的偏移。这时候要做的是检查抽取结果把它们归并或显式声明关系而不是加 exclusive。4.3 宏单元时钟直通与输出引脚 skew 保持带时钟直通的宏clock feedthrough是复杂时钟网络里最经典的坑之一。宏内部把时钟从输入脚透传到输出脚默认抽取可能把宏当成黑盒导致宏两端的时钟被当成两个不相干的网络分别平衡跨宏的 skew 完全失控。# 让工具识别宏的时钟直通关系把两端视为同一时钟网络 set_ccopt_property sink_type stop -pin macro_inst/CLK_IN set_ccopt_property feedthrough -pin macro_inst/CLK_OUT macro_inst/CLK_IN逻辑说明先在宏的输入脚设 stop阻止抽取继续往宏内部钻再用 feedthrough 声明输出脚与输入脚的对应关系工具就知道这两个点是同一条时钟路径的两端平衡时会一起考虑。参数上两个 pin 的顺序是“输出脚在前、输入脚在后”写反了不报错但关系不生效症状就是跨宏 skew 依旧失控。这类设置必须在抽取之后、建树之前完成。另一个相关场景是驱动输出引脚output pin的逻辑芯片输出端口上的时钟需要和内部时钟保持相近的 skew否则下游器件的时序基准就错了。处理思路是把输出引脚路径上的逻辑纳入时钟网络平衡范围或者在抽取时显式保留这段路径具体用 sink_type 的取值组合来控制。4.4 禁用特定时钟的综合与抑制过量 buffer有些时钟在功能上存在但在这个实现阶段不该被综合比如只在测试模式用的时钟、或者由其它模块提供的时钟。默认情况下工具会为所有抽取到的时钟建树多建的树既占资源又可能干扰真实时钟的平衡。# 禁止为指定时钟生成时钟树 set_ccopt_property -clock clock_name create_clock_tree false这条设置的效果是让工具跳过该时钟的结构生成但时钟本身在时序分析里依然存在。典型用法是测试时钟和扫描链专用时钟它们不需要在功能模式下被平衡。要注意的是禁用之后如果这些时钟上挂着真实的时序路径分析结果会出现无时钟可达的违例所以禁用清单要和时序约束的 mode 定义对齐。过量 buffer 的抑制则来自另一个方向复杂控制逻辑上如果被误判为需要平衡工具会疯狂插 buffer。处理手段包括用 sink_type 把这段逻辑排除、放宽局部 skew 目标、或者对特定 group 关闭某些优化。判断是否“过量”的参照是同类结构的 buffer 密度某个分支明显高出其它分支一个量级基本就是误判。5. 避坑清单五条踩过的坑与对应解法5.1 停在中途想续跑结果只能重来现象跑到 trial 阶段停下来分析改了几个设置后想接着往下跑工具报错或者行为异常。 原因cluster 和 trial 阶段不是可续跑的状态流程设计上只支持从抽取开始重跑。 解决把“停下来看”当成纯观测动作。需要改设置的话改完从ccopt_design -cts -extract重新走一遍把观测结论用在下一轮完整流程里。5.2 空单元列表导致选出的 buffer 完全不符合预期现象建出来的树用了大量小驱动单元级数多、latency 大或者反过来用了超大驱动单元面积异常。 原因cts_buffer_cells等列表为空时有特殊语义——所有单元参与挑选不受 Vt 和驱动限制。 解决显式给出 23 档驱动的单元列表always-on 单元手动补进去跑之前用report_ccopt_cell_filtering_reasons确认没有被整类过滤。5.3 feedthrough 的 pin 顺序写反跨宏 skew 依旧失控现象宏单元两端时钟分别平衡跨宏路径 skew 很大但检查设置看起来“已经配了”。 原因feedthrough 属性的输出脚和输入脚顺序写反关系静默失效不报错。 解决确认写法是“输出脚在前、输入脚在后”配完用属性查询确认关系已生效再看跨宏路径的 skew 报告。5.4 exclusive skew group 用在了该对齐的时钟上现象两个从同一 master 派生的时钟出现不该有的偏移hold 违例集中在跨这两个域的路径上。 原因默认抽取把它们分到不同 group又加了 exclusive 声明工具认为无需互相平衡。 解决检查 group 划分是否与 SDC 描述的时钟关系一致该对齐的时钟要么归并要么去掉 exclusive改完重新抽取并复验跨域 hold。5.5 skew 目标设太紧面积和功耗双爆现象时钟树 buffer 数量明显多于同类设计功耗超标时序却没明显改善。 原因target_skew过紧触发过量平衡工具为了压 skew 不断插 buffer。 解决把目标放宽到时钟周期的 3%5% 起步对比面积、功耗、时序三者的变化曲线找到收益拐点再定值。全局目标和 SDC 推导值要一起检查避免两处不一致。6. 快速定位把排查顺序固化成习惯复杂时钟网络的问题真正难的不是解决是定位。我的做法是把排查压成一个固定顺序从便宜的动作开始避免一上来就翻大报告。第一步永远是基础配置核对单元列表非空且含 always-on、transition 和 skew 目标都显式设了、update_io_latency在芯片级场景已关闭、NDR 已指定。这一步用属性查询就能完成一分钟内出结果能排掉相当比例的“玄学”问题。第二步看抽取结果用report_ccopt_clock_trees和report_ccopt_skew_groups输出结构清单跟 SDC 里写的时钟关系逐条对照。重点看三件事group 数量和归属是否符合预期、有没有本该是 1:1 的关系变成了多对一、有没有宏单元或门控逻辑被错误纳入。这一层的偏差是后面所有问题的源头。第三步才是分阶段跑。cluster 阶段看分组是否合理、sink 数量分布是否均匀trial 阶段看 buffer 选择、有没有异常长的分支full 阶段验证 skew、transition、DRC。每个阶段停下来只做观测把结论记下来改设置就从抽取重跑。定位过程中有几个报告值得常备排查目标命令关注点单元被过滤原因report_ccopt_cell_filtering_reasons是否有整类单元被静默剔除时钟树结构清单report_ccopt_clock_treestree 数量、归属、与 SDC 对照skew group 划分report_ccopt_skew_groupsgroup 数量、sink 分布、exclusive 使用当前生效属性get_ccopt_property -clock_tree/-skew_group全局值与分组覆盖值是否冲突时钟路径追踪CCOpt clock tree debugger单条路径逐级 latency 与 buffer 类型CCOpt clock tree debugger 是定位单条异常路径的主力工具配合 clock path tracing 和跨设计视图的 cross probing可以把一条路径从源到 sink 逐级展开每一级的 latency、驱动单元、扇出都看得见。基本检查反而是最容易被跳过的时钟路径延迟是否在合理范围、树是否平衡、扇出比有没有异常突变。这三项查完问题基本能圈到某个分支或某个 group 上。从那以后我每次跑 CCOpt都强制先做一遍基础配置核对和抽取结果清单再决定要不要动架构级设置——很多所谓“工具跑得不对”的问题都在第一分钟就被排掉了。希望帮到你。本文还有配套的精品资源点击获取