简介：《JasperGold CDC Checks Reference》是Cadence公司形式验证工具JasperGold在时钟域交叉（CDC）检查方向的应用参考手册，面向IC设计验证工程师及芯片前端设计人员。手册聚焦多时钟域设计中因信号跨域传输导致的亚稳态、同步失效、延迟违例等问题，系统说明JasperGold CDC检查套件中各项规则的检测原理、适用场景与分析流程。包体为单个PDF文件，大小仅2.65MB，轻量便于随时查阅，内容以英文原文呈现，适合具备形式验证或CDC基础、希望深入掌握Cadence JasperGold工具的工程师对照学习。手册具体展开时钟域交叉检测、同步器与锁存器有效性检查、时钟树不平衡分析、数据路径延迟验证、跨时钟域状态机检查以及静态/动态电源域转换检查等多类规则，有助于验证工程师在流片前更早发现功能与时序风险、提升CDC验证收敛效率。截至目前已有244人浏览学习，适合验证工程师将其作为系统性掌握JasperGold CDC Checks规则体系与实际应用场景的实用参考。
1. 这本 CDC 参考文档为什么值得从“核对清单”而不是“工具手册”的角度去读
验证工程师看到 CDC 这三个字母就头大，因为其他逻辑 bug 在仿真环境大多能复现，CDC 问题却是少数能在芯片跑起来之后以“偶发、概率性、现场才出现”的形式暴露，回到仿真环境反而百试百灵的类别。jaspergold_cdc_reference.pdf 这本参考文档如果只看文件名，容易把它当成某个工具的附带手册；可一旦按章节吃透，会发现它真正解决的是三件事：把跨时钟域信号按单比特和多比特分开处理、把同步器结构变成检查对象而不是背景电路、把复位域和时钟域的关系摆到台面上。它适合验证工程师读前三章建立团队自己的检查脚本，也适合 RTL 设计者读中间章节反过来改代码，更适合项目负责人用最后一章判断哪份 CDC 报告可以无理由信任。
没有这份参考做底子，多数团队会拿仿真覆盖率替代 CDC 静态检查，最后一版网表比第一版更容易在某些时钟频率组合下出现系统性不稳定。而照着参考文档落地，通常第一周就能从黑盒的“没有警告”变成按代码行逐条给出合理解释的白盒结论，这也是我把它定义为“验证基建”而不是“分析工具说明书”的原因。
2. 把 CDC 验证从玄学变成清单：参考文档立项的分类前提
2.1 同步器，是最后防线也是首个检查对象
绝大多数逻辑错误，是逻辑跑起来之后才从波形里被挖出来的；CDC 问题不一样，它从静态结构上就能被定义。参考文档一上来并不急于教命令，而是先做了一件关键的事：把设计中所有跨时钟域的路径分成三类，并逐类给出检查原则。第一类是单比特控制信号，第二类是多比特总线，第三类是复位相关路径。这三类对应三种完全不同的检查策略，混在一起处理是新手最常见翻车点。
第一类单比特信号在源时钟域表现为一个脉冲，目的域通过两级同步器采样。参考文档对这类信号默认允许做两级同步，但同步器只是一个最低限度的隔离结构，它不保证电平在任意时刻都能被正确采样。文档里反复提一个细节：目的域第一级触发器的 D 端必须只连源域信号，中间不能插入其他组合逻辑；同步器输出也不能再进入组合逻辑绕一圈后才作为采样用的稳定信号。若设计里出现“同步之后再和别的信号做 OR”，那两级同步的保护窗口就被破坏了，此时工具即使不报错，也建议人工标高为风险点。
碰到这类情况，我一般会让工具把同步器输出单独拉一条 attribute 标记，比如sync_meta，然后在后续检查里对所有引用该标记的信号做额外审查。参考文档把它叫作“同步器可见性”：检查器不只能看到模块结构，还应该在报告里显示出是哪一条实例化链构成了同步器。若报告里同步器只是两行没有名字的寄存器，说明约束文件没有把单元定义传给工具，这时候就算跑出零告警，设计质量也不能据此判定健康。
2.2 单比特、多位总线与灰色码：先分类，再决定用什么策略
第二类多位总线信号是参考文档里最强调的部分。常见错误是设计者把所有位线一股脑送进两级同步器，认为“一位也是同步，八位也是同步”。实际上多位信号经过两条不同布线路径后，到达目的域的时延不会完全一致，目的域采样时可能读到三位的旧值和五位的新值，拼出来的向量既不是旧值也不是新值。参考文档明确建议：多位异步数据要么走异步 FIFO，要么走灰色码加多级同步，要么用握手机制逐拍传输，不能直接做总线级两级同步。
在工具配置上，文档对应给出总线识别属性和总线不检查属性两个方向。前者告诉检查器这条总线已经通过 FIFO 或灰色码处理，不需要再做同步器结构检查；后者用在数据通道上，本质是把它定性为异步数据，无论时序工具还是 CDC 工具都对其结构自动宽恕。我习惯把这两类属性分开维护：数据总线统一放进cfg/data_sync_only.tcl，控制信号单独放一页cfg/ctrl_sync_required.tcl，避免在同一个文件里一边豁免一边强校验，否则改了总线属性容易误伤控制信号的检查策略。
还有一类信号介于两者之间，比如灰色码计数器。灰色码本身保证相邻值只有一位跳变，所以很多团队会跳过 CDC 检查。参考文档给了一个补充：灰色码只解决采样的“跳变窗口”，不解决“目的域到底采到哪个安全值”的问题，因此灰色码路径上仍要确认源域更新频率远低于目的域采样频率，或者源域在输出灰色码前先有锁存。如果检查报告里灰色码路径出现“no sync cell”的告警，别急着关掉，先确认一下更新节奏和握手约束有没有写进 SDC。
2.3 复位在这里不是配角
很多工程师把异步复位直接交给时序约束工具，设成异步复位不检查，参考文档不建议这样处理。它把复位释放也看作一个跨时钟域事件：复位信号在天花板级由某个时钟域产生，传到目的域时，目的域的第一拍可能采到复位有效，第二拍就可能采到复位撤销，如果目的域里存在依赖复位释放顺序的寄存器群，会出现部分复位先释放、部分后释放的中间状态。文档的检查步骤是先找复位网络拓扑，区分同步复位与异步复位，再对不同复位源建立时钟传播关系。
参考文档对同步复位的要求是必须在目的域内至少保持两个目的时钟周期，确保所有寄存器组在同一拍离开复位状态。异步复位的处理则相反，一旦异步置位，它必须通过复位同步器做释放同步，而不能直接靠 SDC 里的 false path 豁免。这也是我在项目中必做的检查项：把所有set_false_path -from [get_ports reset_n]的约束单独收集，再和 CDC 报告里的复位路径交叉比对。两条记录同时出现时，短期是约束一致性冲突，长期就是芯片温度、电压变化下复位释放漂移的隐患。
3. 落地：用一份可复跑的最小检查集拿到第一条验证结果
3.1 一条最小命令集的可复跑结构
不同 CDC 工具的命令行长得不一样，但参考文档展示的最小动作集合是通用的：一份顶层配置、一份时钟约束、一份例外清单，三次调用后得到报告目录。我一般会把这套动作固化成脚本，避免每个人用不同参数跑出不可比的结果。
# cdc_ref/ch3/min_check.sh # 参考文档第三章对应的最小可复跑结构 # 变量来自环境，不回写绝对路径，保证换机器也能跑 mkdir -p runs/${TOP}_cdc cd runs/${TOP}_cdc config=../../config/top_cdc_config.tcl sdc=../../constraints/top_func.sdc exceptions=../../constraints/cdc_always_exceptions.sdc # 常见做法：先跑 multifast 模式，再视失败情况决定是否加例化深度 cdc_check -top ${TOP} \ -config ${config} \ -clock ${sdc} \ -exceptions ${exceptions} \ -mode multifast \ -report_dir ./report这里-top指定顶层模块，config里定义时钟域名字和同步器单元类型，sdc提供实际时序约束，exceptions集中放 CDC 的独家豁免。把-mode设为multifast表示先用最快模式扫一遍全平台架构关系，快速找结构性漏洞。第一次跑建议不要追求深度的形式化证明，先保证流程闭环。
参数说明：-clock传的是综合后的 SDC 或原始时序约束文件，单元名字必须和 RTL 实例化的同步器单元匹配。config文件里除了时钟域列表，往往还要指定同步器单元的前缀，比如sync2_*、async_fifo_*，这样工具才能把设计里的寄存器链识别成同步链而不是普通路径。如果 config 漏了单元前缀，工具会把同步器当成一段普通组合路径分析，后续所有结构检查都会失真。
跑完这步，报告目录里通常会有结构检查、协议检查、覆盖率三个子文件。我第一次跑出来的“结构检查零告警”让我高兴了三分钟，随后看了协议检查才发现，握手信号那条路径根本没建 expected 约束，属于“查了等于没查”。所以别只看第一份汇总。
3.2 手写一条带握手信号的 CDC 断言模板
结构检查是对电路拓扑提问，协议检查则是对行为提问。参考文档第三章后半段，用将近两页篇幅讲握手信号怎么写断言：请求信号从源域发出，同步到目的域后返回应答，源域看到应答才能撤销请求。这个循环如果缺少任何一拍，软件仿真可能等到天荒地老也发现不了，形式化工具却能在状态空间里直接给出反例路径。
// cdc_ref/ch3/assert/ctrl_handshake.sv // 带握手的多比特异步总线断言模板 module cdc_asserts ( input logic dst_clk, rst_n, input logic req_sync, ack_sync, input logic ctrl_data_valid ); // 握手成立帧：req 同步信号到来后，ack 必须在 2~10 拍内出现 property p_req_to_ack; @(posedge dst_clk) disable iff (!rst_n) req_sync |-> ##[2:10] ack_sync[->1]; endproperty assert property (p_req_to_ack) else $fatal(1, "CDC握手超时: req未在窗口内得到ack回应"); // 数据有效信号不能早于请求或晚于应答一个周期以上 property p_data_valid_window; @(posedge dst_clk) disable iff (!rst_n) ctrl_data_valid |-> req_sync or ack_sync; endproperty assert property (p_data_valid_window); endmodule逻辑说明：req_sync是请求信号经过同步器后的版本，ack_sync是响应回到目的域后的版本。第一条断言用##[2:10]限定应答窗口，防止设计者把应答周期做成无限等待；第二条把数据有效信号限制在握手中段，避免源域在握手未完成时就切换数据。disable iff(!rst_n)是 CDC 断言里的标配写法，复位阶段不检查。
参数说明：窗口上界 10 不是参考文档唯一推荐值，重点是“要给握手留出同步器对齐的时间”。两级同步器在最差情况下，请求信号要经历目的域两个时钟周期的亚稳态收敛，所以窗口下界设 2 拍，上界按实际端到端延迟放宽。做得太紧会在跨工艺角仿真里产生误报，放得太松又会让真正超时的问题被掩盖。建议先在 2~10 跑一版，再按最差条件把上界提升到 16 或 20，看报告差异。
3.3 把三个文件串成一次干净的回归任务
拿到单次报告之后，下一步是让它变成可回归的自动化流水线。参考文档在附录里给了一个建议：所有的例外和豁免不要直接写进主 SDC，而是单独维护成 cdc 例外文件。这样主时钟约束更新时，不会把历史豁免覆盖掉。我用一个三百行的 Python 脚本把这些文件串起来，日常只需要在合并请求触发后执行一次。
# cdc_ref/ch3/run_regression.py # 按参考文档建议组织的最小回归脚本 import subprocess, pathlib, sys top = sys.argv[1] if len(sys.argv) > 1 else "soc_top" base = pathlib.Path(__file__).parent exceptions = base / "constraints" / "cdc_always_exceptions.sdc" if not exceptions.exists(): raise SystemExit(f"缺少例外文件: {exceptions}") tasks = [ ["multifast", ["cdc_check", "-top", top, "-config", str(base/"config"/"top_cdc_config.tcl"), "-clock", str(base/"constraints"/"top_func.sdc"), "-exceptions", str(exceptions), "-mode", "multifast", "-report_dir", f"report_{top}_multifast"]], ["full", ["cdc_check", "-top", top, "-config", str(base/"config"/"top_cdc_config.tcl"), "-clock", str(base/"constraints"/"top_func.sdc"), "-exceptions", str(exceptions), "-mode", "full", "-report_dir", f"report_{top}_full"]], ] for name, cmd in tasks: ret = subprocess.run(cmd, cwd=base) if ret.returncode != 0: print(f"任务 {name} 失败，检查 report_{top}_{name} 目录") sys.exit(1)说明：multifast用于快速迭代，full用于合入主干前跑一次深度证明。脚本里最大的价值在倒数几行：失败时不是只看退出码，而是输出报告目录路径，让验证工程师可以直接进去翻反例波形。很多团队忽略这个细节，全部自动化却没人看失败明细，等于把检查工具用成了打卡机。参数说明：本例用了-mode full，不同工具对应的叫法可能不同，但思路一致，就是全状态空间证明而不是抽样分析，代价是运行时间暴涨，因此只能选择性用在关键路径模块。
4. 参数是最容易被误解的东西：报告与关键设置
4.1 启动检查前先确认的四个参数
拿到参考文档后的第一个误解，是以为把命令跑起来就等于配置正确。真正决定报告质量的往往是四个看起来不起眼的参数，我列成一张表保存在团队首页文档里，每次评审前挨个确认。
表格示例：
| 参数 | 常见默认值 | 为什么容易错 | 实践建议 |
|---|---|---|---|
| 同步器深度 | 2 级 | RTL 里写了 2 级，但综合后插了扫描链变成了 1 级 | 检查 netlist 前先 source 扫描链约束，确认同步路径仍是 2 级 |
| 异步总线豁免范围 | 无 | 把 FIFO 内部 gray code 误当普通数据全部豁免 | 只豁免 FIFO 输出侧，输入侧仍然做同步器存在性检查 |
| 复位释放窗口 | 1 周期 | 异步复位释放时没有考虑复位同步器延迟 | 设成 2 个目的时钟周期，并给复位释放路径单独建 clock 分组 |
| 例外文件优先级 | 主 SDC 在后 | 主 SDC 里的 false path 覆盖了例外文件的豁免意图 | 后 source 例外文件，并跑约束冲突检查确认无覆盖 |
这四项并不是参考文档的全部检查点，但属于最常影响结果有效性的参数。设计团队往往只改 SDC 里和功能相关的时钟频率，却不知道同步器深度在综合后可能被扫描链逻辑改写。若网表里的同步器深度从 2 变成 1，CDC 工具仍按原 RTL 深度检查，报告明明显示路径安全，实际上第一级寄存器在测试模式下被旁路，跨域信号等于直连。
4.2 报告里四级风险怎么读、怎么处理
参考文档在报告解读部分使用了一个分级模式，我没有按它的原话复述，但按我自己的项目经验总结成四级，按此分级处理起来更高效：结构级警告、协议级警告、时序冲突、综合失败。
结构级警告大多指向同步器缺失，属于必改项，特点是修改点明确，拉出顶层视图把缺少的同步器补上就能消除。协议级警告指向握手超时或数据窗口错位，需要结合仿真波形定位，存在灰色地带，可能需要在寄存器传输级架构上动手。时序冲突常出现在例外文件与主 SDC 冲突时，工具会标出“这条路径既被 false path 豁免又被 CDC 检查”，此时修改例外文件优先级，不修改 RTL。综合失败则回到网表版本，确定检查用的是否是综合后的最新网表文件，而不是简单重跑。
报告最容易误导人的地方在“所有告警清零”。参考文档反复在边注里提醒：告警清零只代表所有规则被满足，不代表设计里没有跨域信号。若一个模块根本没有被任何时钟域分组覆盖，它的 CDC 路径就不会出现在报告里。所以我每次评审时必看一眼报告开头的“覆盖面积”表格，确认顶层模块的实例化覆盖率达百分之百。单独报“零告警”的报告没有上下文参考意义。
4.3 报告不收敛时的收敛操作方向
深度证明模式跑太久不结束，是 CDC 项目里最常见的“黑匣子体验”。参考文档给出的倾向性观点是用边界修正而不是增加超时时间，也就是把模块级例外改成子模块级例外，让形式化判断集中到可能存在问题的边界上。
我处理不收敛的路子是：先把完整报告里所有含异常路径的源域-目的域组合列出来，然后看是哪一跳时钟域组合真正占据状态空间。常见做法是在约束文件里给无关紧要的跨域路径写上“不可比”属性，使其不参与协议检查。这不算作弊，因为结构检查仍然保留，只是去掉那些不需要形式化证明的数据路径。参数上先缩小到 1 对时钟域，再逐步扩大时钟域组合范围，找到不收敛点。这个过程中，报告里出现“路径不可达”提示时，先检查约束里是否误设了跨域时序，再怀疑工具能力。
5. CDC 排查与避坑：那几条让人反复翻车的检查习惯
5.1 坑一：CDC 报告零告警，芯片现场却出现偶发错误
现象：工具跑完所有模式，结构、协议检查结果全部为零告警，团队开始庆祝，但样品测试里仍出现多比特数据偶尔读错的现场反馈。
原因：报告只覆盖配置过的时钟域和模块。集成时引入的几个子模块没有绑定时钟域分组，它们的跨域路径完全不参与检查，零告警只是“查了个寂寞”。
解决：把config文件里的时钟域定义与设计里实际存在的所有命名时钟逐一比对，手工写一个脚本提取设计里的时钟定义，再对照检查配置里的时钟域列表，缺一个就补一个，直到两边集合完全相同。此后报告里的“已覆盖”标签才有资格挂到评审看板上。
5.2 坑二：扫描链模式给同步器深度打了折
现象：功能模式 CDC 检查全绿，进入 DFT 模式后发现同步器第一级寄存器被旁路，跨域路径变成直连，测试模式下出现大量随机不稳定现象。
原因：综合后的网表在插入扫描链时，同步器第一级触发器的数据端被接入了扫描输入选择器，状态保持能力被旁路。CDC 工具读取网表时默认按功能模式解析，不处理扫描配置信息。
解决：启动 CDC 检查前先导入 DFT 模式约束，把扫描使能信号定义为常值，工具便会回退到功能路径。更彻底的做法是把同步器单元在综合阶段设置成“不插入扫描旁路”，在单元库级加可综合性逻辑，让同步器在任何模式下都保持结构完整。这一步属于设计早期就要定的规则，等报告翻车再补约束属于后期补救。
5.3 坑三：异步 FIFO 当作普通灰色码模块被整体豁免
现象：检查报告里只要看到识别出的异步 FIFO 就默认安全，但协议检查里没有任何 FIFO 读写时序的确认信息，最终仿真里 FFO 空满标志偶发冲突。
原因：灰色码和 FIFO 结构避免的是读写地址竞争，不是所有跨域路径。模块里寄存器配置信号不管是否连接在读地址侧还是写地址侧，只要跨域就必须单独做同步处理。异步 FIFO 只解决了地址线和数据线的核心冲突，配套的控制、状态、可配置校准等旁路信号仍要逐条确认。
解决：配置文件中把 FIFO 识别连同配套控制信号一并无条件豁免，而是分成“FIFO 核心路径豁免”和“FIFO 旁路控制信号继续检查”两个集合。参考文档原文并没有提这个区分，但这属于项目实践中比原理更重要的一课，多一条旁路就多一条独立检查项。
5.4 坑四：例外文件和主 SDC 互相覆盖，告警时有时无
现象：同一个设计在上一次回归中报告干净，重新生成一次 SDC 后报告暴增，除了时钟频率改变没有任何其他设计变更。
原因：主 SDC 后写入的set_false_path覆盖了例外文件里设置的 CDC 豁免属性，有的例外文件又晚于主 SDC 加载，两种顺序在不同脚本流程里不统一，导致结果不可重复。
解决：约束加载顺序统一为“主 SDC 先行、例外文件后行”，并在脚本开头执行一次冲突检查命令。例外文件里对每条豁免都加注释线索，写清“为什么豁免、评估人、日期”，方便三个月后回看判断条件是否仍成立。这也能让异常文件新增时很快定位是谁悄悄加了豁免规则。
5.5 坑五：把不可达路径错当成安全路径放掉
现象：某些路径被标记为“不可达”，验证人员直接忽略，后来芯片测试中该路径又确实发生了跨域故障。
原因：不可达分为架构不可达和约束不可达，前者是逻辑上不可能，后者是约束条件太过理想导致的状态空间被剪枝后测不到。工具报告只画结果，不在结果旁边自动说明是哪一种原因。
解决：每次遇到“不可达”路径，先读它的约束来源。如果来自set_case_analysis或set_disable_timing，需要去设计里确认这个常值条件是否永远成立。若只是一次性测试模式，应该把该路径从正式结论中排除，避免把临时约束写进到期工业流程里造成误清账。这是参考文档里面最容易被一带而过但实际价值很高的一页。
6. 第一遍跑通之后，你还需要一份基线回归护栏
验证环境能出报告只是开始，真正让参考文档发挥长期价值的是把报告结果变成回归护栏，防止任何一次微小修改悄悄破坏跨域安全。我这里推荐一个我自己坚持了很久的习惯：每个大版本合入后，把报告里所有关键路径的结论导出成基线清单，后续每一次代码修改都对比基线，而不是对比上一版报告。
# cdc_ref/ch6/tag_baseline.sh # 每次通过评审后自动打一份基线文件，纳入版本管理 report=report_${TOP}_full if [ ! -f "$report/cdc_summary.csv" ]; then echo "缺少汇总文件，请确认报告目录是否完整" exit 1 fi # 把告警类型、路径、模块和结论抽成一行一条记录 python3 ./extract_summary.py $report/cdc_summary.csv > baseline_${TOP}_$(date +%Y%m%d).csv git add baseline_${TOP}_*.csv git commit -m "cdc baseline update for $TOP"这个脚本的意图不是保存报告本身，而是保存结论。两周后若有同事改动了一个无关模块，却发现 CDC 报告整体从零告警变成大量结构级警告，基线对比能立刻告诉你警告来自哪个新模块哪一类路径，而不是让整个人埋在几千行报告里重新做归因。基线文件不设版本号，完全依靠 Git 的历史记录回溯，避免手工维护一长串版本带来的混乱。
收尾时还有一个小习惯值得分享：无论报告跑成什么样，我都会让工具再输出一份“未覆盖路径清单”，然后要求设计人员在清单上逐一签字确认“这条路径不需要 CDC 检查”的原因。这东西不一定能立刻抓住漏网之鱼，但它逼着每一个模块负责人把跨域路径一次数清，而不是停在“工具报绿就合入”的侥幸心态上。我最初带第一个 CDC 项目时也在零告警里开心了好几天，吃过现场样品的亏后，才把这一套确认机制固化进流程，直到今天。希望帮到你。
本文还有配套的精品资源，点击获取
