【Backend Flow工程实践 19】CTS：从 skew group 到 clock route rule，时钟树综合到底在综合什

作者：Darren H. Chen

方向：Backend Flow / 后端实现流程 / EDA 工具工程 / CTS

demo：LAY-BE-19_cts_flow

标签：Backend Flow、EDA、CTS、Clock Tree Synthesis、Skew Group、Clock Route Rule、Post-CTS Optimization

上一篇文章讨论了一个基本问题：

text 复制代码

为什么 clock network 不是普通 net，而是后端实现的节奏系统？

这一篇进一步进入 CTS。

CTS 是 Clock Tree Synthesis 的缩写，表面上是"时钟树综合"。但很多人对 CTS 的理解停留在：

text 复制代码

插 clock buffer，把 clock 接到所有寄存器。

这太粗糙了。

真正的 CTS 不是简单插 buffer，而是在给定 clock definition、skew group、sink distribution、library、route rule、timing constraint 和 physical constraint 的情况下，综合出一张可布线、可分析、低偏斜、可控延迟、可修复的 clock distribution network。

换句话说，CTS 综合的不是一棵"树"的形状，而是一个多约束时间分发系统。

本文从底层原理、架构和方法论角度回答：CTS 到底在综合什么？

一、CTS 的输入是什么？

CTS 的输入不是一个 clock net 名字。

一个成熟 CTS 阶段至少需要这些输入：

text 复制代码

clock definitions
clock sources
clock sinks
skew groups
clock buffer / inverter library
clock gating cells
clock route rules
placement result
blockage / macro / keepout
routing layer constraints
timing constraints
power constraints
transition / cap / fanout constraints
scenario / mode / corner context

如果这些输入缺失，CTS 可能仍然能跑，但结果未必可信。

例如：

text 复制代码

clock sink 识别错误 -> 时钟分发不完整；
skew group 划分错误 -> balancing 目标错误；
clock buffer 不合适 -> transition 或 power 失控；
route rule 缺失 -> post-route latency 漂移；
placement 质量差 -> clock tree 被迫绕路；
clock gating 处理错误 -> 功耗和 timing 都受影响。

所以 CTS 首先是建模问题，其次才是综合算法问题。

二、CTS 的输出是什么？

CTS 的输出也不只是 clock buffer。

它至少改变这些内容：

text 复制代码

clock tree topology
clock buffer / inverter instances
clock net segmentation
clock sink connection
clock latency distribution
skew distribution
clock transition
clock route guidance
clock NDR / route rule assignment
post-CTS timing landscape

从数据库角度看，CTS 会把原来比较理想化的 clock model 变成真实物理结构。

pre-CTS 时，clock 常常是 ideal 或估算状态。

post-CTS 时，clock network 变成：

text 复制代码

真实 cell + 真实 net + 真实 physical connection + 真实 timing arc

这就是为什么 CTS 是后端流程中的关键转折点。

三、Skew Group：CTS 不是给所有 sink 做同一种平衡

Skew group 是理解 CTS 的第一把钥匙。

可以把 skew group 简化理解为：

text 复制代码

一组需要满足共同 skew 目标的 clock sinks。

但它背后的意义更深。

不同 sink 之间是否需要平衡，取决于它们之间是否存在同步 timing 关系。

例如：

text 复制代码

同一个 clock domain 内的寄存器之间通常需要控制 skew；
异步 clock domain 之间不应该按同一组 skew 目标强行平衡；
generated clock 可能需要单独建模；
scan clock 与 functional clock 可能有不同约束；
clock gating 后的子树可能需要特殊处理。

如果 skew group 定义错误，CTS 的优化方向就会错误。

这就是为什么 CTS 不是一个纯几何问题，而是 timing relationship 驱动的问题。

四、CTS 的底层目标函数

从抽象角度看，CTS 的目标可以写成一个多目标优化问题：

text 复制代码

minimize:
  skew_cost
  latency_cost
  transition_cost
  power_cost
  congestion_cost
  rule_violation_cost

subject to:
  sink connectivity
  clock buffer legality
  max transition
  max capacitance
  max fanout
  placement legality
  route layer constraints
  skew group constraints
  scenario constraints

这说明 CTS 不可能只追求一个指标。

例如：

text 复制代码

降低 skew -> 可能增加 buffer 和 wirelength；
降低 latency -> 可能牺牲 skew 或 transition；
降低 power -> 可能增加 skew；
减少 congestion -> 可能增加 latency；
使用高层金属 -> 可能改善 delay，但增加 routing 资源竞争。

因此 CTS 的结果是多目标折中。

五、Clock Buffer 选择：不是越大越好

Clock buffer 的作用是驱动 clock load。

但选择 buffer 时不能简单认为越大越好。

大 buffer 的优点：

text 复制代码

驱动能力强
transition 好
延迟可能更低

大 buffer 的代价：

text 复制代码

输入负载更大
面积更大
动态功耗更高
可能造成局部拥塞
可能导致过强驱动和 EM 风险

小 buffer 的优点：

text 复制代码

面积小
功耗低
局部影响小

小 buffer 的问题：

text 复制代码

驱动不足
transition 变差
级数增加
latency 增加

所以 CTS 中 buffer selection 是一个 library、load、transition、power、route 的综合决策。

六、Clock Topology：H-tree、balanced tree 与实际工程树

理论上，时钟树可以有很多拓扑。

例如：

text 复制代码

H-tree
balanced binary tree
fishbone
mesh-like structure
hybrid tree

但真实工程中，CTS 往往不是按教科书画一棵完美树。

因为真实芯片存在：

text 复制代码

macro blockage
irregular floorplan
non-uniform sink distribution
power straps
routing congestion
multiple voltage domains
scan/test structures
clock gating hierarchy

因此 CTS 生成的是工程约束下的可行拓扑，而不是数学上的理想拓扑。

这也是为什么同一个 clock，在不同 floorplan 下 CTS 结果会差异很大。

七、Clock Route Rule：为什么 CTS 不能脱离 routing？

CTS 不是 detail routing，但它必须提前考虑 routing。

原因是 clock delay 很大程度上来自 wire RC。

如果 CTS 只按理想连线估算，而后续 routing 使用了不同层、不同宽度、不同 spacing，post-route timing 就会发生明显偏移。

Clock route rule 的作用是让 CTS 和 routing 对 clock net 的物理实现有共同预期。

典型规则包括：

text 复制代码

preferred routing layers
wire width
wire spacing
shielding strategy
via rule
non-default rule
routing blockage awareness

这类规则的本质是：

text 复制代码

把 clock 的物理实现方式提前纳入 CTS 估算。

没有 route rule，CTS 结果很容易在 post-route 阶段失真。

八、Pre-CTS 与 Post-CTS Timing 为什么不同？

pre-CTS 阶段，clock 可能被设为 ideal 或使用估算 latency。

这时 timing report 的 clock path 不是完全真实的。

CTS 后，clock path 变成真实 buffer 和 net：

text 复制代码

clock source
-> clock buffer
-> clock net
-> branch buffer
-> leaf net
-> sink clock pin

因此 post-CTS timing 会引入：

text 复制代码

real insertion delay
real skew
clock transition
clock buffer delay
clock net RC estimation
clock reconvergence effect

所以 CTS 后必须重新分析 timing。

很多 path 在 pre-CTS 看起来安全，post-CTS 可能变差。

也有一些 path 因 useful skew 变好。

这就是 CTS 对 timing closure 的影响。

九、Post-CTS Optimization 在优化什么？

CTS 完成后，通常还需要 post-CTS optimization。

它处理的问题包括：

text 复制代码

setup violation
hold violation
clock transition violation
clock cap / fanout violation
clock skew outlier
data path 因真实 clock 变差
局部 congestion
buffer legalization side effect

特别是 hold。

CTS 之前，hold 分析可能还不完全真实。

CTS 后真实 clock skew 出现，短路径 hold violation 常常会增加。

因此 post-CTS 阶段经常需要：

text 复制代码

insert delay buffer
resize data path cells
adjust placement
fix transition
incremental timing optimization

这说明 CTS 不是结束，而是打开了一个新的优化阶段。

十、CTS Report 应该怎么看？

成熟 flow 不应该只看 CTS 是否完成，而要看报告结构。

建议关注：

text 复制代码

clock tree summary
sink count
buffer count
inverter count
max latency
min latency
skew distribution
transition distribution
capacitance violations
fanout violations
clock power estimate
clock route rule usage
worst skew group
outlier sinks

一个好的 cts_summary.rpt 应该能回答：

text 复制代码

哪几个 clock 最难收敛？
哪个 skew group 最差？
clock buffer 是否异常多？
latency 是否过大？
是否存在 transition outlier？
是否存在 clock route rule 未生效？
CTS 后 setup / hold 分别如何变化？

如果 report 不能回答这些问题，就很难进行工程化 debug。

十一、方法论：CTS 前必须有 precheck

CTS 前建议至少检查：

text 复制代码

clock 是否定义完整；
clock source 是否唯一或符合预期；
clock sinks 是否可统计；
skew group 是否合理；
clock buffer list 是否准备好；
clock gating cell 是否识别；
clock route rule 是否存在；
placement 是否 legal；
macro blockage 是否正确；
pre-CTS timing 是否达到进入条件。

这些检查应该写入：

text 复制代码

cts_precheck.rpt

典型格式：

text 复制代码

[PASS] clock definition found
[PASS] sink count = 12893
[WARN] skew group CORE_CLK has high sink spread
[FAIL] no clock route rule assigned for SCAN_CLK

这类报告可以显著降低 CTS debug 成本。

十二、方法论：CTS 后必须做 compare

CTS 后不应该只看单点 report，而应该和 pre-CTS baseline 比较。

建议比较：

text 复制代码

WNS / TNS / violation count
setup worst paths
hold worst paths
clock latency distribution
skew distribution
transition violations
cap/fanout violations
clock buffer count
congestion map

这样才能知道 CTS 造成了什么变化。

一个成熟 flow 的 CTS 阶段应该输出：

text 复制代码

pre_cts_timing.rpt
cts_precheck.rpt
cts_summary.rpt
post_cts_timing.rpt
cts_delta_summary.rpt
hold_fix_plan.rpt

其中 cts_delta_summary.rpt 是关键。

它把 CTS 从"工具执行结果"变成"工程可解释事件"。

十三、demo 设计：LAY-BE-19_cts_flow

这个 demo 的目标是建立 CTS 阶段的 precheck、summary 和 delta compare 框架。

推荐目录结构：

text 复制代码

LAY-BE-19_cts_flow/
├─ data/
│  ├─ sample_pre_cts_timing.rpt
│  ├─ sample_cts_summary.rpt
│  └─ sample_post_cts_timing.rpt
├─ scripts/
│  ├─ run_cts_flow_demo.csh
│  └─ clean.csh
├─ tcl/
│  ├─ 01_cts_precheck.tcl
│  ├─ 02_run_clock_tree_synthesis.tcl
│  ├─ 03_report_cts_summary.tcl
│  ├─ 04_report_post_cts_timing.tcl
│  └─ 05_compare_pre_post_cts.tcl
├─ reports/
│  ├─ cts_precheck.rpt
│  ├─ cts_summary.rpt
│  ├─ post_cts_timing.rpt
│  └─ cts_delta_summary.rpt
└─ README.md

运行入口可以抽象为：

csh 复制代码

#!/bin/csh -f

setenv EDA_TOOL_BIN /path/to/eda_tool
setenv DESIGN_ROOT  /path/to/LAY-BE-19_cts_flow

$EDA_TOOL_BIN -batch $DESIGN_ROOT/tcl/02_run_clock_tree_synthesis.tcl \
  >&! $DESIGN_ROOT/reports/run_cts.log

demo 的验证目标是：

text 复制代码

CTS 前是否具备进入条件；
CTS 后 clock tree 指标是否可报告；
pre/post timing delta 是否可比较；
hold fix 风险是否能被提前识别。

十四、从专家视角看 CTS

CTS 的难点不在"插 buffer"三个字，而在它连接了多个工程世界：

text 复制代码

clock constraint
clock domain
physical placement
library cell selection
routing rule
timing equation
power optimization
post-CTS repair

它一旦完成，Backend Flow 就从"数据路径主导"进入"数据路径 + 真实时钟路径共同主导"的阶段。

这也是为什么 CTS 是后端实现的关键分界线。

十五、总结

本文回答了：CTS 到底在综合什么？

核心结论如下：

CTS 的输入包括 clock、sink、skew group、library、placement、route rule 和 timing context；
CTS 的输出是 clock topology、buffer、latency、skew、transition 和真实 clock path；
skew group 决定哪些 sinks 需要一起平衡；
clock buffer 选择是 delay、transition、power、area 的折中；
clock route rule 让 CTS 与 routing 对 clock 物理实现形成共同预期；
CTS 后 timing 会显著变化，必须做 post-CTS analysis；
post-CTS optimization 重点处理真实时钟路径引入的问题；
成熟 flow 必须建立 CTS precheck、summary 和 pre/post compare。

结尾一句话

CTS 综合的不是一堆 clock buffer，而是把抽象时钟约束、物理 sink 分布、route rule 和 timing closure 目标，综合成一个真实可运行的时间分发网络。