1. 重汇聚问题到底在说什么CDCClock 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 yesdesignread_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: Path12FF, Path2Pulse 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展示在什么输入序列和时钟相位下会出现收敛失败。反例波形是调试重汇聚问题最有价值的线索。我通常会做这几步打开反例波形看源信号在什么时刻发生变化。看两条路径上的同步器输出在什么时刻出现差异。看汇合点的逻辑在差异出现时是否产生了非预期的翻转。回溯到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 1b0; sync_pulse_b_conv 1b0; 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 1b0; path_b_align 1b0; 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 未同步路径的修复未同步路径是最严重的情况。如果工具报告某条路径上完全没有同步器那意味着亚稳态会直接传播到目的域。修复方法就是加上合适的同步器。但加同步器不是随便加两级触发器就行。需要根据信号类型选择同步策略信号类型推荐同步策略注意事项单比特电平两级触发器源信号必须稳定至少两个目的时钟周期单比特脉冲脉冲同步器脉冲宽度必须大于目的时钟周期多比特数据异步FIFO或握手不能用多比特两级触发器多比特控制DMUX同步器需要源域产生使能信号复位信号复位同步器异步复位同步释放我见过一个案例设计里有一个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 2b00; else rst_sync {rst_sync[0], 1b1}; 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 常见问题速查表问题现象可能原因排查方法修复方案形式化FAIL但反例不合理约束不完整检查SDC伪路径补充约束或写waiver路径追踪中断黑盒未建模检查IP例化提供行为模型修复后仍报错新增路径跑增量CDC逐条分析新路径复位域交叉漏报复位未声明检查SDC复位定义显式声明复位域运行时间过长设计规模大检查资源占用分模块跑或降低effort6.6 独家避坑技巧技巧一先跑结构分析再跑形式化。结构分析快能快速定位可疑区域。形式化慢但能抓深层问题。先用结构分析缩小范围再对可疑模块开形式化能节省大量时间。技巧二用cdc_reconvergence_depth控制路径深度。默认深度5对于大多数设计够用但如果重汇聚路径经过多级模块需要设到10以上。我一般先设5跑一轮看报告里有没有被截断的路径再决定是否加大。技巧三waiver要分类管理。我习惯把waiver分成三类工具误报、设计意图允许、待修复。每类用不同的文件管理定期review。待修复的waiver要设过期时间避免遗忘。技巧四重汇聚修复后要跑回归。修复重汇聚可能会影响时序、面积、功耗。修复后要跑综合和时序分析确认没有引入新的问题。技巧五建立重汇聚检查清单。每个项目结束后把遇到的重汇聚问题、根因、修复方案整理成清单。下一个项目开始时对照清单检查设计能提前避免很多问题。7. 修复验证与Sign-off流程7.1 修复后的验证步骤修复重汇聚问题后不能只跑一次CDC就完事。我通常按这个流程验证结构分析回归确认修复没有引入新的未同步路径。形式化回归确认修复后的路径收敛性PASS。RTL仿真回归跑基本功能测试确认修复没有改变功能。综合和时序分析确认修复没有引入时序违例。功耗分析确认修复没有显著增加功耗。这五步走完才能把修复标记为完成。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验证。这两个方向在实际项目中越来越重要值得单独写一篇。