VC Spyglass CDC重汇聚问题调试与修复实战指南

1. 重汇聚问题到底在说什么

CDC（Clock Domain Crossing，跨时钟域）验证做久了，你会发现真正让人头疼的往往不是那些一眼就能看出来的单比特同步器缺失，而是重汇聚（Reconvergence）。这个词听起来有点抽象，但它在SoC设计里出现的频率极高，尤其是在多时钟域、多复位域交织的复杂模块中。

简单来说，重汇聚指的是同一个源信号经过两条或多条不同的路径穿越时钟域边界后，在目的时钟域又重新汇合到一起。如果这些路径上的同步器类型不同、延迟不同、或者某条路径根本没有同步处理，那么重汇聚之后的信号就会出现毛刺、亚稳态传播、甚至功能错误。这种问题在仿真中不一定能复现，但在硅后测试中往往是致命的。

VC Spyglass CDC是Synopsys Spyglass平台下的CDC专项检查工具，它在业界SoC验证流程中的位置非常关键。相比早期的Spyglass CDC基础版本，VC Spyglass CDC在重汇聚分析上做了大量增强，支持结构化的重汇聚路径追踪、自动识别同步器类型差异、以及基于形式化引擎的收敛性检查。但工具再强，也得有人会用、会看报告、会定位根因。

这篇文章面向的是已经有一定CDC验证基础、正在使用或准备使用VC Spyglass CDC的SoC验证工程师、前端设计工程师和DFT工程师。我会从重汇聚的成因讲起，一步步拆解VC Spyglass CDC的调试流程，包括环境配置、报告解读、路径追踪、根因定位和修复验证。文章里会穿插我在实际项目中踩过的坑和总结出来的快捷操作，尽量让你看完就能上手。

提示：重汇聚问题不是靠跑一次工具就能全部抓出来的，它需要结合设计意图、时钟关系、复位策略综合判断。工具报告只是起点，不是终点。

2. 重汇聚的成因与VC Spyglass CDC的检查逻辑

2.1 重汇聚是怎么产生的

要理解重汇聚，先得理解信号跨时钟域的基本路径。假设有一个源时钟域clk_a，一个目的时钟域clk_b。源信号sig_a要传到clk_b域，常规做法是经过一个两级触发器同步器。但如果sig_a在clk_a域内先被组合逻辑分成了两条路径，比如一条经过与门、一条经过或门，然后这两条路径各自穿越到clk_b域，最后又在clk_b域内通过某个逻辑门汇合，这就是典型的重汇聚结构。

重汇聚带来的风险主要有三类。第一类是同步器类型不一致，比如一条路径用了两级触发器，另一条路径用了脉冲同步器，两者的延迟特性完全不同，汇合后会产生窄脉冲。第二类是路径延迟差异，即使两条路径都用了两级触发器，但如果一条路径上多了缓冲器或者组合逻辑，到达汇合点的时间就会错开，导致目的域采到错误值。第三类是某条路径完全未同步，这是最严重的情况，亚稳态会直接传播到目的域。

在实际SoC中，重汇聚经常出现在这些场景：多比特控制信号的分发、中断信号的聚合、DMA请求的仲裁、以及低功耗管理模块的状态机交互。尤其是当设计里存在多个异步时钟域，且它们之间有复杂的握手协议时，重汇聚几乎是不可避免的。

2.2 VC Spyglass CDC的检查机制

VC Spyglass CDC对重汇聚的检查主要依赖三个引擎的协同：结构分析引擎、同步器识别引擎和形式化收敛引擎。

结构分析引擎会遍历整个设计的网表，识别出所有跨时钟域的路径，并标记每条路径上的同步器结构。它会生成一个跨时钟域路径数据库，记录每条路径的源触发器、目的触发器、经过的组合逻辑、以及同步器类型。

同步器识别引擎则负责判断每条路径上的同步策略是否合法。VC Spyglass CDC内置了多种同步器模板，包括两级触发器、脉冲同步器、握手同步器、异步FIFO、DMUX同步器等。如果某条路径上的结构不符合任何已知模板，工具会报出未识别同步器警告。

形式化收敛引擎是VC Spyglass CDC相比基础版最大的升级。它会对重汇聚路径进行形式化建模，检查在所有可能的输入序列和时钟相位关系下，汇合点的输出是否会出现非预期的翻转。这个引擎能抓到一些结构分析漏掉的深层问题，比如同步器虽然合法但相位关系不满足收敛条件的情况。

工具的报告里，重汇聚问题通常以Reconvergence、Convergence、SyncConvergence等标签出现。报告会给出源信号、目的信号、经过的同步器列表、以及形式化引擎的判定结果。但报告不会直接告诉你“这条路径应该怎么改”，它只告诉你“这里有问题”。所以接下来的调试步骤才是关键。

2.3 为什么重汇聚比普通CDC问题更难查

普通CDC问题，比如缺少同步器，工具一报一个准，你直接加同步器就行。但重汇聚问题往往涉及多个模块、多条路径、多种同步策略的交互，工具报出来的可能只是冰山一角。

我遇到过这样一个案例：一个中断聚合模块，来自三个不同时钟域的中断信号分别经过各自的同步器后，在一个或门里汇合。工具报了重汇聚，但形式化引擎没有报收敛失败。当时我以为只是工具误报，结果硅后测试发现，在某些极端温度条件下，中断会丢失。后来用VC Spyglass CDC的路径追踪功能逐条分析，才发现其中一条路径的同步器虽然结构正确，但它的复位信号来自另一个异步域，导致在复位释放阶段出现了短暂的亚稳态窗口。

这个案例说明，重汇聚问题的根因可能在同步器本身，也可能在复位、时钟门控、电源域切换等外围逻辑。VC Spyglass CDC能帮你缩小范围，但最终判断还得靠人。

3. 环境配置与运行参数实战

3.1 工程目录与文件准备

VC Spyglass CDC的运行需要几个核心输入：RTL或网表文件、SDC约束文件、时钟定义文件、以及可选的UPF电源域描述文件。我习惯把工程目录组织成下面这样：

cdc_project/ ├── rtl/ # RTL源码 ├── sdc/ # 时钟约束 ├── upf/ # 电源域描述（可选） ├── spyglass/ # 工具脚本和输出 │ ├── cdc_run.tcl │ ├── cdc_project.prj │ └── reports/ └── waivers/ # 豁免文件

cdc_project.prj是Spyglass的项目文件，里面需要指定RTL文件列表、SDC文件、以及顶层模块名。我一般用脚本自动生成这个文件，避免手动维护文件列表时漏文件。

# cdc_project.prj 示例 read_file -type verilog ./rtl/top.v read_file -type verilog ./rtl/clk_gen.v read_file -type verilog ./rtl/intr_aggregator.v read_file -type sdc ./sdc/top.sdc set_option top top set_option language_mode mixed set_option designread_enable_synthesis yes

designread_enable_synthesis yes这个选项很重要。VC Spyglass CDC在读取RTL时会做一些简单的综合推断，如果不开这个选项，某些同步器结构可能识别不出来。但开了之后，读取时间会变长，所以大型SoC项目里要权衡。

3.2 时钟定义与约束文件

SDC文件里最关键的是create_clock和create_generated_clock。VC Spyglass CDC会根据这些定义来划分时钟域。如果时钟定义不完整，工具会把一些实际异步的时钟当成同步时钟，导致漏报。

# top.sdc 示例 create_clock -name clk_cpu -period 2.0 [get_ports clk_cpu] create_clock -name clk_ddr -period 3.3 [get_ports clk_ddr] create_clock -name clk_peri -period 10.0 [get_ports clk_peri] # 异步时钟组声明 set_clock_groups -asynchronous \ -group {clk_cpu} \ -group {clk_ddr} \ -group {clk_peri}

set_clock_groups -asynchronous是必须的。如果不声明异步关系，VC Spyglass CDC会认为所有时钟都是同步的，重汇聚检查就失去了意义。但这里有个坑：有些设计里存在时钟切换逻辑，比如CPU在低功耗模式下会切到低速时钟。这种情况下，时钟之间的关系是动态的，静态的set_clock_groups可能不够。VC Spyglass CDC支持set_clock_groups -logically_exclusive和-physically_exclusive，需要根据实际设计选择。

3.3 运行脚本与关键参数

cdc_run.tcl是主运行脚本。下面是我常用的一个模板：

# cdc_run.tcl new_project cdc_project # 读取设计 read_file -type verilog ./rtl/top.v read_file -type verilog ./rtl/clk_gen.v read_file -type verilog ./rtl/intr_aggregator.v read_file -type sdc ./sdc/top.sdc # 设置顶层 set_option top top set_option language_mode mixed set_option designread_enable_synthesis yes set_option enableSV yes # CDC检查参数 set_option cdc_enable_reconvergence yes set_option cdc_reconvergence_depth 10 set_option cdc_enable_formal yes set_option cdc_formal_effort high set_option cdc_sync_depth 2 # 运行CDC检查 run_goal cdc/cdc_setup run_goal cdc/cdc_run # 生成报告 write_report cdc_reconvergence ./reports/reconvergence.rpt write_report cdc_summary ./reports/summary.rpt

这里有几个参数需要重点说明。cdc_enable_reconvergence yes是打开重汇聚检查的总开关，默认是开的，但有些老版本可能默认关闭。cdc_reconvergence_depth 10控制路径追踪的深度，默认是5。对于大型SoC，路径可能经过很多级逻辑，深度设小了会漏掉一些重汇聚点。我一般设到10到15，但设太大运行时间会显著增加。

cdc_enable_formal yes打开形式化引擎。这个引擎很吃内存和CPU，对于超过500万门的设计，建议先跑结构分析，定位到可疑区域后再开形式化。cdc_formal_effort high会提高形式化求解的穷举程度，能抓到更深层的问题，但运行时间可能翻倍。

cdc_sync_depth 2指定同步器的最小触发器级数。默认是2，如果你的设计里有三级同步器，可以设成3，避免工具把三级同步器误判为两级。

注意：cdc_reconvergence_depth和cdc_formal_effort这两个参数是时间和精度的权衡。项目初期可以设小一点快速迭代，sign-off阶段再设大。

3.4 运行时间与资源估算

VC Spyglass CDC的运行时间跟设计规模、时钟域数量、重汇聚路径数量强相关。根据我的经验，一个100万门左右的SoC子系统，结构分析大概需要20到30分钟，形式化引擎如果全开，可能需要2到4小时。如果设计里有大量异步FIFO和握手同步器，时间会更长。

内存方面，结构分析大概每100万门需要4到8GB，形式化引擎每100万门需要16到32GB。所以跑大型设计时，建议用64GB以上内存的服务器，并且把cdc_formal_effort设成medium先跑一轮，定位到热点模块后再对局部开high。

4. 报告解读与重汇聚路径追踪

4.1 重汇聚报告的结构

VC Spyglass CDC的重汇聚报告通常包含这几个字段：Source、Destination、Path Group、Sync Type、Formal Result、Severity。下面是一个简化后的报告示例：

Reconvergence Report ==================== Source: u_intr_agg/intr_src_a_reg/Q Destination: u_intr_agg/intr_comb_reg/D Path Group: clk_cpu -> clk_peri Path 1: u_intr_agg/intr_src_a_reg/Q -> sync_2ff_a -> u_intr_agg/intr_comb_reg/D Path 2: u_intr_agg/intr_src_a_reg/Q -> sync_pulse_b -> u_intr_agg/intr_comb_reg/D Sync Type: Path1=2FF, Path2=Pulse Formal Result: FAIL Severity: High

这个报告告诉我们：源信号intr_src_a_reg/Q经过两条路径到达目的触发器。路径1用了两级触发器同步器，路径2用了脉冲同步器。形式化引擎判定为FAIL，严重级别High。

看到这个报告，第一反应应该是：为什么同一个源信号会有两条不同同步类型的路径？这通常意味着设计意图不清晰，或者代码里存在冗余逻辑。接下来要做的就是用工具的路径追踪功能，把这两条路径的完整逻辑展开。

4.2 用Path Trace定位完整路径

VC Spyglass CDC提供了path_trace命令，可以交互式地追踪任意一条跨时钟域路径。在Spyglass的GUI里，你可以直接双击报告里的路径，工具会自动展开原理图。但在批处理模式下，可以用TCL命令：

# 追踪指定路径 path_trace -from u_intr_agg/intr_src_a_reg/Q \ -to u_intr_agg/intr_comb_reg/D \ -clock_group {clk_cpu clk_peri} \ -output ./reports/path_trace_a.rpt

生成的报告会列出路径上经过的每一个单元、每一根网络、以及每个单元的时钟域归属。我一般会重点关注这几个信息：路径上有没有组合逻辑环、有没有锁存器、有没有时钟门控单元、同步器的复位端接在哪里。

在实际项目中，我遇到过一种情况：路径追踪显示两条路径都经过了两级触发器，但其中一条路径的同步器第一级触发器的复位端接的是一个异步复位信号，而另一条路径的复位端接的是同步复位信号。这种差异在结构报告里看不出来，只有路径追踪才能发现。

4.3 形式化结果的解读

形式化引擎的FAIL结果需要谨慎对待。不是所有FAIL都意味着设计有bug，有些可能是约束不完整导致的假失败。VC Spyglass CDC的形式化引擎会生成一个反例波形（Counter Example），展示在什么输入序列和时钟相位下会出现收敛失败。

反例波形是调试重汇聚问题最有价值的线索。我通常会做这几步：

1. 打开反例波形，看源信号在什么时刻发生变化。
2. 看两条路径上的同步器输出在什么时刻出现差异。
3. 看汇合点的逻辑在差异出现时是否产生了非预期的翻转。
4. 回溯到RTL代码，确认这个行为是否符合设计意图。

如果反例波形显示的场景在实际系统中不可能发生（比如某个输入组合被上层协议禁止），那就可以写waiver豁免掉。但如果反例波形显示的场景是合理的，那就必须修设计。

提示：写waiver时一定要写清楚豁免理由，并且附上反例波形的分析结论。否则下次跑回归时，别人看到waiver会一头雾水。

4.4 严重级别的判断标准

VC Spyglass CDC把重汇聚问题分为High、Medium、Low三个级别。High通常意味着形式化引擎判定FAIL，且路径上存在同步器类型不一致或未同步路径。Medium通常是形式化引擎判定PASS但结构上存在潜在风险，比如路径延迟差异较大。Low通常是工具误报或者已经被waiver覆盖的问题。

我的经验是：High必须逐条分析，Medium要抽样分析，Low可以批量waiver但要有记录。有些团队为了赶进度，把所有Medium和Low都waive掉，结果硅后出了问题再回头查，成本高得多。

5. 根因定位与修复方案

5.1 同步器类型不一致的修复

同步器类型不一致是重汇聚最常见的根因。修复方法通常有两种：统一同步器类型或者在汇合点前增加收敛逻辑。

统一同步器类型是最直接的做法。如果两条路径一条用了两级触发器，另一条用了脉冲同步器，那就把脉冲同步器改成两级触发器。但这样做的前提是设计意图允许。如果脉冲同步器是为了传递单周期脉冲，改成两级触发器后脉冲会变成电平，功能就变了。这种情况下，应该反过来，把两级触发器路径改成脉冲同步器，或者在汇合点前把电平转换成脉冲。

在汇合点前增加收敛逻辑是更稳妥的做法。比如在两条路径汇合前各加一个两级触发器，把两条路径的延迟对齐，然后再汇合。这样即使同步器类型不同，汇合点的信号也是稳定的。

// 修复前：两条路径直接汇合 assign intr_comb = sync_2ff_a_out | sync_pulse_b_out; // 修复后：增加收敛触发器 reg sync_2ff_a_conv, sync_pulse_b_conv; always @(posedge clk_peri or negedge rst_n) begin if (!rst_n) begin sync_2ff_a_conv <= 1'b0; sync_pulse_b_conv <= 1'b0; end else begin sync_2ff_a_conv <= sync_2ff_a_out; sync_pulse_b_conv <= sync_pulse_b_out; end end assign intr_comb = sync_2ff_a_conv | sync_pulse_b_conv;

这个修复方案的核心思想是：在目的时钟域内，用同一级触发器对两条路径的输出重新采样，消除路径延迟差异。但要注意，如果两条路径的源信号变化频率接近目的时钟频率，增加收敛触发器可能仍然不够，需要更复杂的握手协议。

5.2 路径延迟差异的修复

路径延迟差异通常是因为两条路径上的组合逻辑级数不同。比如一条路径经过了两级与门，另一条路径经过了三级或门。这种情况下，即使同步器类型相同，到达汇合点的时间也会错开。

修复方法是在延迟较小的路径上插入缓冲器或触发器，对齐两条路径的延迟。但插入缓冲器会受PVT影响，不一定能保证所有条件下都对齐。更可靠的做法是在汇合点前插入一级触发器，用目的时钟重新采样。

// 修复前：路径延迟不一致 assign path_a = sync_a_out & sync_a_out_dly; assign path_b = sync_b_out | sync_b_out_dly | sync_b_out_dly2; assign result = path_a & path_b; // 修复后：在汇合点前对齐 reg path_a_align, path_b_align; always @(posedge clk_peri or negedge rst_n) begin if (!rst_n) begin path_a_align <= 1'b0; path_b_align <= 1'b0; end else begin path_a_align <= path_a; path_b_align <= path_b; end end assign result = path_a_align & path_b_align;

这个修复方案的关键是把组合逻辑的汇合点移到触发器之后。这样两条路径的延迟差异被触发器的建立保持时间吸收，汇合点的信号是稳定的。

5.3 未同步路径的修复

未同步路径是最严重的情况。如果工具报告某条路径上完全没有同步器，那意味着亚稳态会直接传播到目的域。修复方法就是加上合适的同步器。

但加同步器不是随便加两级触发器就行。需要根据信号类型选择同步策略：

我见过一个案例：设计里有一个4比特的配置信号从慢时钟域传到快时钟域，工程师直接用了4组两级触发器。工具报了重汇聚，因为4比特信号的变化时间可能不同，导致目的域采到中间态。后来改成了DMUX同步器，问题解决。

5.4 复位域交叉的隐蔽问题

复位域交叉是重汇聚问题里最隐蔽的一类。VC Spyglass CDC默认会检查复位域交叉，但有些设计里复位信号被当作普通信号处理，工具可能漏报。

我建议在SDC里显式声明复位域：

# 复位域声明 create_clock -name rst_cpu_n -period 100 [get_ports rst_cpu_n] create_clock -name rst_peri_n -period 100 [get_ports rst_peri_n] set_clock_groups -asynchronous -group {rst_cpu_n} -group {rst_peri_n}

然后在VC Spyglass CDC里打开复位域检查：

set_option cdc_enable_reset_domain yes set_option cdc_reset_sync_check yes

复位域交叉的修复通常是在复位路径上增加复位同步器。但要注意，复位同步器的释放必须同步到目的时钟域，否则会产生亚稳态。

// 复位同步器示例 reg [1:0] rst_sync; always @(posedge clk_peri or negedge rst_peri_n) begin if (!rst_peri_n) rst_sync <= 2'b00; else rst_sync <= {rst_sync[0], 1'b1}; end assign rst_peri_sync_n = rst_sync[1];

这个复位同步器的原理是：异步复位、同步释放。当rst_peri_n拉低时，rst_sync立即清零；当rst_peri_n拉高时，rst_sync在clk_peri的上升沿逐级移入1，最终rst_peri_sync_n同步释放。

6. 常见问题与排查技巧实录

6.1 工具报了大量重汇聚但形式化都PASS

这种情况通常是约束不完整导致的。VC Spyglass CDC的形式化引擎依赖SDC里的时钟定义和伪路径约束。如果某些路径被错误地约束为伪路径，形式化引擎就不会检查这些路径。

排查方法：检查SDC里的set_false_path和set_clock_groups，确认没有把实际需要检查的路径约束掉。另外，检查cdc_formal_effort是否设得太低，导致形式化引擎没有穷举到问题场景。

6.2 路径追踪显示路径经过黑盒

如果设计里例化了第三方IP或模拟模块，VC Spyglass CDC可能无法穿透这些黑盒。路径追踪会在黑盒处中断，导致重汇聚路径不完整。

解决方法：为黑盒提供行为模型，或者在Spyglass里设置set_option cdc_blackbox_model，指定黑盒的同步器行为。如果黑盒内部确实有同步器，但工具看不到，可以在waiver里说明。

6.3 重汇聚问题在RTL仿真中不复现

这是正常的。重汇聚问题往往依赖特定的时钟相位关系和输入序列，RTL仿真很难穷举所有场景。形式化引擎的价值就在这里。不要因为仿真没复现就忽略工具报告。

6.4 修复后工具仍然报重汇聚

修复后要重新跑完整的CDC检查，不能只跑增量。有些修复会引入新的跨时钟域路径，或者改变原有的同步器结构。我习惯在修复后先跑结构分析，确认没有新增未同步路径，再跑形式化引擎确认收敛性。

6.5 常见问题速查表

6.6 独家避坑技巧

技巧一：先跑结构分析，再跑形式化。结构分析快，能快速定位可疑区域。形式化慢，但能抓深层问题。先用结构分析缩小范围，再对可疑模块开形式化，能节省大量时间。

技巧二：用cdc_reconvergence_depth控制路径深度。默认深度5对于大多数设计够用，但如果重汇聚路径经过多级模块，需要设到10以上。我一般先设5跑一轮，看报告里有没有被截断的路径，再决定是否加大。

技巧三：waiver要分类管理。我习惯把waiver分成三类：工具误报、设计意图允许、待修复。每类用不同的文件管理，定期review。待修复的waiver要设过期时间，避免遗忘。

技巧四：重汇聚修复后要跑回归。修复重汇聚可能会影响时序、面积、功耗。修复后要跑综合和时序分析，确认没有引入新的问题。

技巧五：建立重汇聚检查清单。每个项目结束后，把遇到的重汇聚问题、根因、修复方案整理成清单。下一个项目开始时，对照清单检查设计，能提前避免很多问题。

7. 修复验证与Sign-off流程

7.1 修复后的验证步骤

修复重汇聚问题后，不能只跑一次CDC就完事。我通常按这个流程验证：

1. 结构分析回归：确认修复没有引入新的未同步路径。
2. 形式化回归：确认修复后的路径收敛性PASS。
3. RTL仿真回归：跑基本功能测试，确认修复没有改变功能。
4. 综合和时序分析：确认修复没有引入时序违例。
5. 功耗分析：确认修复没有显著增加功耗。

这五步走完，才能把修复标记为完成。

7.2 Sign-off标准

CDC sign-off的标准因项目而异，但通常包括这几条：

• 所有High级别重汇聚问题已修复或已waiver并有充分理由。
• 所有Medium级别重汇聚问题已分析，确认无风险或已修复。
• 形式化引擎在所有时钟域对上PASS。
• 复位域交叉检查PASS。
• waiver文件经过review并签字。

我参与过的一个SoC项目，CDC sign-off时要求所有High和Medium问题必须修复，不允许waiver。结果多花了三周时间，但硅后没有出现任何CDC相关问题。另一个项目允许waiver，结果硅后出现了中断丢失，排查了两个月才定位到重汇聚。所以我的建议是：能修就修，waiver是最后手段。

7.3 持续集成中的CDC检查

对于大型SoC项目，CDC检查应该集成到持续集成流程中。每次RTL提交后自动跑CDC，发现问题立即通知提交者。这样能避免问题积累到sign-off阶段才爆发。

集成方法：在CI脚本里调用VC Spyglass CDC的批处理模式，生成报告后解析关键字段，如果有新增High级别问题就失败。waiver文件纳入版本管理，每次修改都要review。

# CI脚本示例 spyglass -project cdc_project.prj -goal cdc/cdc_run -batch if grep -q "Severity: High" ./reports/reconvergence.rpt; then echo "CDC check failed: new high severity reconvergence found" exit 1 fi

这个脚本很简单，但很有效。关键是报告格式要稳定，grep的匹配模式要准确。

7.4 团队协作与知识沉淀

CDC验证不是一个人的事。设计工程师、验证工程师、后端工程师都要参与。设计工程师负责修复，验证工程师负责确认，后端工程师负责时序和功耗。

我建议每个项目建立一个CDC问题库，记录每个问题的现象、根因、修复方案、验证结果。下一个项目开始时，先过一遍问题库，能避免很多重复劳动。

另外，VC Spyglass CDC的版本更新比较频繁，新版本可能增加新的检查规则或者改变报告格式。每次升级工具后，要跑一轮回归，确认没有误报或漏报。

8. 写在最后

重汇聚问题在CDC验证里算是硬骨头，但也不是无解。VC Spyglass CDC提供了结构分析、路径追踪、形式化收敛三套工具，配合合理的约束和waiver管理，大部分问题都能定位和修复。

我在实际项目里最大的体会是：不要迷信工具报告，也不要忽视工具报告。工具报出来的问题，要逐条分析，确认是真实问题还是误报。工具没报出来的问题，要结合设计意图和时钟关系，人工检查可疑区域。

还有一个经验：重汇聚问题往往不是孤立的。一个重汇聚点背后，可能隐藏着多个时钟域交叉问题。修复一个重汇聚，可能会暴露另一个。所以修复后要跑完整回归，不能只跑局部。

最后分享一个小技巧：VC Spyglass CDC的GUI里有一个Reconvergence Map视图，能把所有重汇聚路径以图形化方式展示出来。我习惯先用这个视图看全局，找出重汇聚最密集的区域，然后重点分析这些区域。这样比逐条看报告效率高得多。

这个内容后续还可以这样扩展：结合UPF做低功耗场景下的CDC检查，或者结合DFT做扫描链插入后的CDC验证。这两个方向在实际项目中越来越重要，值得单独写一篇。