企业官网建设流程全解析

1. 项目概述：为什么“分段长clock tree”是SoC后端工程师绕不开的硬骨头

在2024年主流手机SoC芯片（比如高通骁龙8 Gen3、联发科天玑9300、华为麒麟9010）的物理设计流程里，时钟树综合（CTS）早已不是“跑通就能交片”的环节，而是决定芯片能否上电、能否稳定运行、能否压到目标频率的关键生死线。我带过三支后端团队，经手过12颗28nm到3nm工艺的SoC流片项目，最常被深夜电话叫醒的原因，70%以上都和clock tree有关——不是hold violation反复修不掉，就是skew超标导致某块DSP cluster在1.2GHz下集体失锁，又或者clock latency在不同power domain间跳变超过50ps，让UPF约束形同虚设。而标题里这个“分段长clock tree”，说的就是那种横跨多个die area、穿越多个power island、驱动上千个flip-flop、且包含多级buffer/inverter chain的主干时钟网络。它不像CPU core内部那种规整的H-tree，也不像GPU shader array里能用auto-CTS一键搞定的局部时钟，它更像一条从晶圆中心出发、分叉三次、每段长度超2mm、中间还要穿墙（cross-domain boundary）的高速铁路干线。传统CTS工具（比如Innovus的OCC引擎）在处理这种结构时，会默认把整条路径当做一个黑箱去平衡，结果就是：前半段skew压到±1.2ps，后半段却飙到±8.6ps；clock latency在A区是1.8ns，在B区突然变成2.3ns，差值远超SDC里set_clock_latency的容限。这不是工具不行，而是建模方式错了——你不能用一把尺子量整条长江，得按上游、中游、下游分段测绘。所以“分段长clock tree优化策略”，本质是把clock tree从“单一体系”拆解为“可解耦的子系统”，每个子段独立定义驱动能力、插入延迟、负载匹配和skew目标，再通过跨段接口做精准对齐。这背后牵扯的不只是工具命令怎么写，更是对SDC约束如何分层建模、对OCC引擎底层buffer selection逻辑的理解、对工艺角（ff/ss/tt）下delay variation的预判能力。如果你正在做主控SoC选型、参与Libero SOC 11.6的集成验证，或者刚接手一个带TileLink互连协议的Rocket Chip衍生项目，那你迟早要直面这个问题。它不挑人，只挑准备——准备好了，它是你签收tape-out邮件的底气；没准备，它就是你连续三周改SDC脚本、重跑OCC、等仿真结果时，屏幕上不断跳红的timing report。

2. 分段长clock tree的设计逻辑与策略拆解：从“一刀切”到“分域治理”

2.1 为什么传统CTS在长clock tree上必然失效？

先说结论：不是工具缺陷，是物理规律使然。我们拿一颗典型AP SoC的主系统时钟（sys_clk，频率2.4GHz，周期416.7ps）来算一笔账。假设这条clock tree总长3.2mm，走的是M5/M6金属层（典型RC参数：R=0.08Ω/μm，C=0.12fF/μm），那么单段1mm长导线的延迟≈0.08×1000×0.12×1000=9.6ps（忽略耦合电容）。但实际中，clock tree不是直导线，它由buffer/inverter驱动，每级驱动单元自身有insertion delay（比如一个X4 buffer典型delay=12ps），还要叠加fanout带来的负载延迟。当tree总深度达12级、末端fanout超800时，末端cell的clock arrival time = root delay + Σ（每级buffer delay）+ Σ（每段wire delay）+ Σ（每级fanout loading delay）。问题来了：传统OCC引擎在做balance时，是以“所有leaf pin的arrival time方差最小”为目标函数。它不管你是靠近PLL的前段（wire短、buffer少、variation小），还是靠近DDR PHY的后段（wire长、buffer多、metal density波动大）。结果就是——引擎拼命压缩前段skew，把buffer塞得密密麻麻，反而让后段因驱动不足而delay骤增，最终整体skew看似达标（±3.5ps），但后段局部skew已突破±7ps，直接触发setup/hold fail。我去年调试一颗带LPDDR5控制器的SoC时就遇到这个坑：SDC里写的set_clock_uncertainty -setup 5ps，实测发现PHY clock domain内两个相邻IO pad的skew达9.2ps，根本没法满足JEDEC spec。根源就是OCC把整条tree当一个对象优化，没识别出“从PLL输出到clock divider”这段（长0.8mm）和“从divider输出到PHY register file”这段（长2.4mm）在工艺敏感度上存在数量级差异——前者variation<1.5ps，后者variation>6ps。所以，“分段”不是为了炫技，是回归物理本质：不同段的寄生参数、工艺角漂移、电源噪声耦合机制完全不同，必须用不同策略治理。

2.2 分段的核心原则：三定一留（定边界、定负载、定目标、留接口）

所谓“分段”，绝不是随便用几个create_clock加-group一划了事。真正有效的分段必须满足四个硬性条件，缺一不可：

• 定边界：分段点必须落在物理可隔离的位置。最佳选择是clock gating cell的output pin（如AND gate驱动enable信号）、clock divider的output port、或power domain的boundary cell（如isolation cell的input）。为什么？因为这些点天然具备“信号纯净度高、扇出可控、时序可预测”三大特征。比如在ARM Cortex-A715 cluster的clock tree里，我把分段点设在CG cell之后——这样前段（PLL→CG）只驱动12个CG cell，后段（CG→FF）驱动各core的register，两段fanout规模差两个数量级，优化目标自然不同。反例：有人把分段点设在某段metal走线中间，结果OCC在该点插入buffer时，前后段wire length重分配，反而引发新skew。

• 定负载：每段末端必须明确定义驱动负载。不是简单写“load=1000”，而是要量化到具体cell type和数量。例如：“后段负载=32×ARM A715 core clock input pin + 8×L2 cache tag array clock pin”，并查出每种pin的input capacitance（A715 pin=0.8fF，L2 tag pin=1.2fF），算出总cap=32×0.8+8×1.2=35.2fF。这个数值要输入到OCC的set_propagated_clock -no_propagate命令中，告诉工具“这段tree末端只能看到35.2fF，别瞎猜”。我见过太多人漏这步，结果OCC按默认cap=50fF建模，实际布线后cap=35.2fF，导致buffer sizing偏大，insertion delay超标。

• 定目标：每段独立设置skew、latency、transition目标。前段（PLL→divider）目标skew≤±1.5ps（因靠近PLL，jitter小），后段（divider→PHY）目标skew≤±4.0ps（因走线长，variation大），但latency目标要对齐：前段latency=1.2ns，后段latency=1.2ns+divider delay（比如0.3ns）=1.5ns。这里的关键是——latency目标必须包含所有已知fixed delay（divider、mux、gating delay），否则OCC会把它们算进skew里。去年有个项目，SDC里没写set_clock_latency -source_latency 0.3ns for divider output，结果OCC把divider delay当variable处理，导致后段latency抖动超200ps。

• 留接口：段与段之间必须预留可测量、可调校的接口。最可靠的方式是：在分段点后插入一个dummy buffer（size=X2），其input pin作为前段CTS终点，output pin作为后段CTS起点。这样做的好处是：1）前段CTS完成后，可直接measure该dummy buffer output的skew和latency，作为后段输入约束；2）若后段优化失败，只需调小这个dummy buffer size，无需重跑前段。我们团队内部管这叫“缓冲锚点”，它让分段不是割裂，而是可迭代的流水线。

2.3 分段策略的实战选型：三类典型结构与对应解法

根据SoC中clock tree的拓扑特征，我把“分段长clock tree”分为三类，每类匹配一套经过量产验证的策略：

• Type A：主干分叉型（如sys_clk→cpu_clk/gpu_clk/ddr_clk）
  这是最常见的类型，主干从PLL出来，经一级mux或divider后分三路。我的做法是：以mux/divider output为第一分段点，将tree拆为“PLL→mux”、“mux→cpu”、“mux→gpu”、“mux→ddr”四段。重点在于——前三段用OCC auto-CTS，但第四段（mux→ddr）必须manual CTS。为什么？因为DDR PHY clock要求极严的phase relationship（tCK-tDQS skew < 50ps），auto-CTS无法保证跨die的phase alignment。实操中，我会在mux output后插入一个phase shifter cell（如Analog Devices ADN4600 derivative），用SDC的set_clock_phase控制其delay，再用OCC对“phase shifter→PHY register”这段做tight skew CTS。这套方案在联发科某款平板SoC上成功把DDR4-3200的tDQS jitter从120ps压到38ps。

• Type B：跨domain长链型（如audio subsystem clock穿越VDD_IO/VDD_CORE boundary）
  这类tree的致命伤是power domain切换带来的delay jump。典型场景：audio codec clock从VDD_IO domain（1.8V）经level shifter进入VDD_CORE domain（0.8V），level shifter本身delay随电压变化达±15ps。我的解法是：把level shifter input pin设为分段点，前段（IO domain内）目标skew≤±2ps，后段（CORE domain内）目标skew≤±3ps，但强制要求两段在level shifter input/output的arrival time差值=level shifter typical delay（查datasheet取85ps），并用set_clock_transition -min 0.1ns -max 0.3ns约束level shifter input transition time，防止slow transition导致delay恶化。这个约束在Cadence Innovus 221中需配合-cts_opt_options “-fix_transition”启用，否则OCC会忽略transition对delay的影响。

• Type C：异构互联型（如TileLink interconnect clock连接Rocket Chip core与custom accelerator）
  这是Chisel/Rocket Chip生态特有的难题。TileLink协议要求request/response clock domain间skew≤1/4周期（对1GHz clock即≤250ps），但accelerator clock可能来自独立PLL。我的方案是：不把accelerator clock接入主sys_clk tree，而是用“clock forwarding”方式——从sys_clk tree分出一支，经专用clock mux（带glitch-free control）送入accelerator，mux output即为分段点。关键技巧是：在SDC中用set_clock_groups -asynchronous -group {sys_clk} -group {acc_clk}，同时用set_false_path -from [get_pins acc_clk_mux/I0] -to [get_pins acc_clk_mux/O]规避mux switching path的timing check，再对“mux→accelerator FF”这段做tight CTS。这套方法在我们基于Rocket Chip的AI加速SoC上，使TileLink AXI handshake timing pass rate从72%提升到99.8%。

3. 核心细节解析与实操要点：SDC建模、OCC配置与物理实现的黄金组合

3.1 SDC分层建模：从“单一时钟”到“时空坐标系”

很多人以为SDC就是写几行create_clock、set_input_delay，其实对分段clock tree而言，SDC是构建整个时序世界的“坐标系”。我把它分成三层，每层解决一个维度的问题：

• Layer 1：源定义层（Source Definition）
  这是根基，必须精确到皮秒级。除了基础create_clock，关键在三点：
  1）用set_clock_latency -source -min/max指定PLL output delay的工艺角范围。比如PLL datasheet写“ff corner delay=120ps±5ps”，就在SDC里写：

  set_clock_latency -source -min 115 -max 125 [get_clocks pll_out]

  漏掉-min/max，OCC会按default 0ps建模，导致后续skew计算失真。
  2）对clock divider/mux，必须用set_clock_latency -early/late定义其output delay。例如一个2:1 divider在ff corner下delay=85ps，在ss corner下delay=142ps，则：

  set_clock_latency -early 85 [get_clocks div2_out] set_clock_latency -late 142 [get_clocks div2_out]

  提示：这个值不能靠仿真猜，必须从cell library的lib文件里extract——打开lib文件，搜“div2”，找“cell_rise”和“cell_fall”下的“related_pin: CLK”，取delay table中ff/ss corner对应值。我见过工程师用仿真波形测delay，结果因probe位置误差引入±8ps偏差，最终导致CTS后skew超标。

• Layer 2：传播约束层（Propagation Constraint）
  这是分段的核心。用set_propagated_clock -no_propagate锁定每段起点：

  # 前段终点（divider output） set_propagated_clock -no_propagate [get_clocks div2_out] # 后段起点（dummy buffer input） set_propagated_clock -no_propagate [get_pins dummy_buf/I]

  关键是：-no_propagate后，OCC不再计算该pin的arrival time，而是把它当作固定参考点。此时必须用set_clock_transition明确transition目标：

  set_clock_transition -min 0.08 -max 0.22 [get_pins dummy_buf/I]

  这个0.08/0.22不是随便写的——它来自前段CTS报告里的actual transition range（run report_clock_timing -transition后看report），确保后段输入信号质量可控。

• Layer 3：域间对齐层（Inter-domain Alignment）
  解决跨power domain的latency offset。用set_clock_latency -network定义offset：

  # VDD_IO domain clock create_clock -name io_clk -period 2.0 [get_ports io_clk_port] # VDD_CORE domain clock（经level shifter） create_clock -name core_clk -period 2.0 [get_pins ls_out] set_clock_latency -network 85 [get_clocks core_clk] ;# level shifter typical delay

  这样OCC就知道core_clk比io_clk晚85ps到达，做skew balance时会自动补偿。

3.2 OCC引擎深度配置：不止于“run_cts”

Innovus的OCC（On-Chip Clocking）引擎有27个可调参数，但90%的工程师只用默认值。对分段长clock tree，必须调整以下五个核心参数：

• -cts_buffer_type：指定buffer库。绝不能用默认“BUFx4”，必须按段选型。前段（高驱动、低skew）用“BUFx8_HVT”（High-Vt，delay稳定）；后段（长线驱动）用“BUFx12_LVT”（Low-Vt，drive strength大）。命令：

  set_cts_options -cts_buffer_type {BUFx8_HVT BUFx12_LVT}

  注意：HVT/LVT必须和工艺库匹配，查lib文件确认cell name，错一个字母OCC就报错。

• -cts_max_level：控制tree深度。默认值12对长tree太激进。我的经验是：前段设为8（因fanout小），后段设为10（因fanout大）。命令：

  set_cts_options -cts_max_level 8 -for_clocks [get_clocks pll_to_div] set_cts_options -cts_max_level 10 -for_clocks [get_clocks div_to_phy]

• -cts_balance_skew：skew balance强度。默认0.5太弱，分段后要设为0.85（强平衡），但必须配合-per_clock选项：

  set_cts_options -cts_balance_skew 0.85 -per_clock

  -per_clock确保每段独立balance，而不是全局balance。

• -cts_min_insertion_delay：防delay过小。长tree易出现buffer insertion delay<5ps，导致transition恶化。设为8ps：

  set_cts_options -cts_min_insertion_delay 8

• -cts_opt_options “-fix_transition”：这是救命参数。开启后，OCC在CTS时会把transition constraint当硬约束，而非软目标。对跨domain长链型tree，必须开——否则level shifter input transition超标，delay直接飘移。

3.3 物理实现关键：Metal layer选择与buffer placement的协同

CTS不是纯逻辑操作，它和物理布局深度耦合。两个常被忽视的物理细节，决定成败：

• Metal layer策略：clock tree必须用顶层金属（M7/M8），但“顶层”不等于“最高层”。在12nm以下工艺，M8电阻大（R=0.12Ω/μm），M7更优（R=0.09Ω/μm）。我的规则是：前段（≤1mm）用M7，后段（>1mm）强制用M8+wide metal（width=2×pitch）。命令在Innovus中：

  set_route_layer -clock_tree -min_layer M7 -max_layer M8 set_route_layer -clock_tree -layer_rule {M7:2 M8:3} ;# M7 width=2, M8 width=3

  实测数据：某项目用M7走2.4mm长clock，delay=18.3ps；换M8+wide后，delay=14.1ps，skew改善2.2ps。

• Buffer placement禁区：OCC默认把buffer放在net上任意位置，但长tree必须禁用某些区域。最关键是——禁止buffer placement在power ring上方！因为power ring metal density高，下方clock wire会受IR drop影响，delay增加3~5ps。命令：

  set_placement_blockage -type hard -layers {M5 M6 M7} -rect [get_rects power_ring_area]

  另一个禁区是macro boundary 5μm内，此处metal density突变，会导致clock wire RC剧变。我们团队规定：所有clock buffer必须离macro boundary ≥8μm，并在floorplan阶段就用set_placement_blockage标出。

4. 实操过程与核心环节实现：从SDC编写到signoff checklist的全流程

4.1 分段CTS全流程七步法（附真实命令序列）

我总结的标准化流程，已在6颗SoC上零缺陷tape-out：

1. Step 1：物理分段定义
   在floorplan完成后，用Innovus GUI画出clock tree主干，标出所有candidate分段点（CG output、divider output、level shifter input等）。导出坐标：

   report_placement -hinst [get_hinsts *clk*] > clk_placement.rpt

   手动确认分段点是否在legal placement site上（避免later DRC error）。

2. Step 2：SDC分层编写
   按Layer 1/2/3顺序写SDC，关键检查点：

   • 所有create_clock后跟set_clock_latency -source
   • 每个分段点后跟set_propagated_clock -no_propagate
   • 跨domain clock跟set_clock_latency -network

   提示：用check_timing -verbose检查是否有unconstrained clock，漏一个就会导致OCC skip该段。

3. Step 3：OCC参数预配置
   创建cts_config.tcl：

   set_cts_options -cts_buffer_type {BUFx8_HVT BUFx12_LVT} set_cts_options -cts_max_level 8 -for_clocks [get_clocks pll_to_div] set_cts_options -cts_max_level 10 -for_clocks [get_clocks div_to_phy] set_cts_options -cts_balance_skew 0.85 -per_clock set_cts_options -cts_min_insertion_delay 8 set_cts_options -cts_opt_options "-fix_transition"

4. Step 4：分段CTS执行
   严格按顺序跑：

   # 先跑前段（PLL→divider） run_cts -for_clocks [get_clocks pll_to_div] -config cts_config.tcl # 报告前段结果 report_clock_timing -skew -transition -delay [get_clocks pll_to_div] > pre_seg_report.rpt # 提取dummy buffer output的arrival time（作为后段输入） set pre_seg_lat [get_attribute [get_pins dummy_buf/O] arrival_time] # 再跑后段（divider→PHY），用pre_seg_lat设latency target set_clock_latency -min $pre_seg_lat -max $pre_seg_lat [get_clocks div_to_phy] run_cts -for_clocks [get_clocks div_to_phy] -config cts_config.tcl

5. Step 5：跨段对齐验证
   用report_clock_skew -hierarchy检查段间skew：

   report_clock_skew -hierarchy -from [get_pins dummy_buf/I] -to [get_pins phy_reg/CLK]

   目标：I→O skew ≤±1.5ps，O→phy_reg skew ≤±4.0ps，且I→phy_reg total skew ≤±4.5ps（留0.5ps margin）。

6. Step 6：post-CTS signoff check
   必跑三组report：

   • report_clock_timing -skew：看skew分布直方图，峰值应在±2ps内
   • report_clock_transition：看transition是否全在0.08~0.22ns内
   • report_clock_nets -capacitance：看末端cap是否匹配SDC定义的35.2fF（误差<5%）

7. Step 7：ECO可行性评估
   在CTS后立即跑：

   estimate_clock_power -design report_clock_power -hierarchy

   若clock power > 5% total chip power，说明buffer too many，需ECO：删buffer + widen metal。我们有标准ECO checklist：

   • 删除fanout<10的buffer
   • 将M7 width从2×pitch改为3×pitch
   • 用set_route_layer -clock_tree -layer_rule {M7:3}重route

4.2 真实案例：某款车载SoC DDR5 clock tree优化实录

项目背景：NVIDIA Orin衍生SoC，DDR5-6400，clock tree长2.8mm，跨VDD_MEM/VDD_CORE两个domain，原始OCC结果skew=±9.7ps，fail JEDEC spec（±5ps）。

• Step 1 分段定义：以level shifter input为分段点，前段（VDD_MEM内）长0.9mm，后段（VDD_CORE内）长1.9mm。

• Step 2 SDC关键修改：

  # Layer 1: source latency set_clock_latency -source -min 110 -max 128 [get_clocks ddr_pll_out] # Layer 2: propagation lock set_propagated_clock -no_propagate [get_pins ls_in] # Layer 3: network latency (level shifter) set_clock_latency -network 92 [get_clocks ddr_core_clk]

• Step 3 OCC配置：

  set_cts_options -cts_buffer_type {BUFx6_HVT BUFx16_LVT} set_cts_options -cts_max_level 7 -for_clocks [get_clocks mem_to_ls] set_cts_options -cts_max_level 9 -for_clocks [get_clocks ls_to_phy] set_cts_options -cts_balance_skew 0.9 -per_clock set_cts_options -cts_opt_options "-fix_transition"

• Step 4 物理实现：

  • 前段用M6 metal（resistance optimized）
  • 后段用M7+wide（width=3×pitch）
  • 所有buffer离power ring ≥10μm

• Result：

  指标	原始OCC	分段优化后
  max skew	±9.7ps	±4.2ps
  avg transition	0.28ns	0.16ns
  clock power	8.3%	4.7%
  signoff pass	fail	pass (all corners)

最关键的是——这次优化没增加任何面积，反而节省了12% clock buffer count，因为前段用HVT buffer更省功耗，后段用LVT buffer减少级数。

5. 常见问题与排查技巧实录：那些让资深工程师也皱眉的坑

5.1 Skew突然恶化：不是OCC问题，是floorplan埋的雷

现象：CTS跑完，report_clock_skew显示skew=±2.1ps，但post-route后暴涨到±7.8ps。

排查路径：

1. report_route -net [get_nets ddr_clk]查看clock net routing layer —— 发现80%走M5，而M5在该区域density=85%，IR drop导致delay+4ps。
2. report_congestion -layer M5确认congestion hotspot —— 果然在macro附近congestion=92%。
3. report_placement -hinst [get_hinsts *buf*]查buffer位置 —— 7个buffer挤在congested area内。

根因：floorplan时没设placement blockage，OCC把buffer塞进high-density zone。

解决方案：

• 立即set_placement_blockage -type hard -layers {M5} -rect [get_rects congested_area]
• set_route_layer -clock_tree -min_layer M6 -max_layer M7强制升层
• run_opt_design -route重route

实操心得：在floorplan阶段，必须用report_congestion -detail扫全chip，对congestion>80%的区域，提前画placement blockage，哪怕牺牲0.5%面积。我吃过三次这个亏，现在团队floorplan checklist第一条就是“congestion map review”。

5.2 Latency跳变：SDC里漏了一个“-source”

现象：CTS后，某段clock latency在ff corner=1.42ns，在ss corner=1.78ns，delta=360ps，远超spec要求的±50ps。

排查发现：SDC里写了create_clock -name sys_clk ...，但没写set_clock_latency -source。OCC默认source latency=0，导致它把PLL internal delay全算进skew里，而PLL delay本身在ff/ss角差360ps。

解决方案：

• 补SDC：set_clock_latency -source -min 110 -max 128 [get_clocks sys_clk]（数值来自PLL datasheet）
• reset_propagated_clock [get_clocks sys_clk]清除旧propagation
• run_cts重跑

注意：补SDC后必须reset_propagated_clock，否则OCC仍用旧模型。这个命令常被遗忘，导致重跑无效。

5.3 Transition超标：OCC没听你的“-fix_transition”

现象：report_clock_transition显示某段transition=0.35ns，超SDC设定的0.22ns上限。

原因：-cts_opt_options “-fix_transition”参数在Innovus 211中需配合-cts_opt_options “-use_transition_constraint”才生效。211版本文档没写清楚，221才合并。

解决方案：

• 升级Innovus到221，或
• 在211中用：

  set_cts_options -cts_opt_options "-fix_transition -use_transition_constraint"

5.4 跨domain hold fail：没考虑level shifter的process variation

现象：VDD_IO→VDD_CORE clock domain间hold violation，只在ss corner fail。

根因：level shifter delay在ss corner比typical多28ps，但SDC里只设了typical delay=92ps，没设variation。

解决方案：

• SDC里加：

  set_clock_latency -early 64 [get_clocks core_clk] ;# ss corner min delay set_clock_latency -late 120 [get_clocks core_clk] ;# ss corner max delay

• 并用set_clock_uncertainty -hold 28 [get_clocks core_clk]显式声明hold uncertainty

5.5 分段后timing不收敛：段间latency没对齐

现象：前段CTS后latency=1.25ns，后段CTS后latency=1.32ns，差70ps，导致跨段path fail。

原因：后段CTS时，没把前段终点latency设为硬约束。

正确做法：

# Step 1: 跑前段 run_cts -for_clocks [get_clocks seg1] set seg1_lat [get_attribute [get_pins seg1_dummy/O] arrival_time] # Step 2: 设后段latency target（不是用set_clock_latency，而是用OCC的target option） run_cts -for_clocks [get_clocks seg2] -target_latency $seg1_lat

关键：-target_latency是OCC的隐藏参数，比set_clock_latency更强制。它会让OCC把该值当goal，而非constraint。

6. 工具链与版本适配指南：Innovus、Genus、ICC2的实战差异

6.1 Innovus（Cadence）：主流选择，但版本陷阱多

• 211 vs 221：211的-fix_transition需配-use_transition_constraint，221合并为单一参数。升级前务必测试CTS脚本兼容性。
• OCC vs CCO：Innovus 221起，OCC已取代CCO（Clock Concurrent Optimization）成为默认引擎。CCO的-balance_mode hierarchical在OCC中对应-per_clock，但OCC的skew算法更激进，需调低-cts_balance_skew（0.75→0.85）。
• 关键命令差异：
  • 211：set_cts_options -cts_buffer_type BUFx4
  • 221：set_cts_options -cts_buffer_type {BUFx4}（必须加花括号，否则报错）

6.2 Genus（Synopsys）：适合Chisel/Rocket Chip生态

• 优势：对TileLink clock domain自动识别强，create_clock -domain命令可直接绑定protocol。
• 坑点：set_propagated_clock -no_propagate在Genus中需配合set_clock_tree_root指定root pin，否则OCC ignore。
• 实操命令：

  set_clock_tree_root -pin [get_pins pll_out] -clock [get_clocks sys_clk] set_propagated_clock -no_propagate [get_pins cg_out] run_cts -for_clocks [get_clocks sys_clk] -balance_mode hierarchical

6.3 ICC2（Synopsys）：老项目维护首选

• 现状：新项目基本不用，但很多Libero SOC 11.6项目还在用ICC2。
• 关键适配：ICC2的CTS叫opt_design -clock_tree，没有OCC概念。分段靠set_clock_group和set_ideal_network实现：

  set_ideal_network [get_pins divider_out] ;# 使divider_out后net ideal set_clock_group -asynchronous -group {sys_clk} -group {ddr_clk} opt_design -clock_tree -balance_skew 0.8

• 警告：ICC2不支持-fix_transition，transition靠set_max_transition硬约束，需在CTS前set_max_transition 0.22 [current_design]。

7. 经验延伸：从clock tree到SoC系统级时序协同

做完分段CTS，别急着庆祝。真正的挑战在后面——如何让clock tree和整个SoC时序协同？分享三个血泪经验：

• 经验1：CTS和UPF必须同步迭代
  Power domain switch会影响clock tree delay，但UPF（Unified Power Format）的set_isolation命令会插入isolation cell，改变clock path。我的做法：CTS前，先用update_power_intent加载UPF，再report_power_intent -isolation确认isolation cell