极客工场

Appearance

共 1,860 字预计阅读约 6 分钟

CDC/RDC 报告分诊：跨时钟域与复位域违例怎么判断真伪 ​

更新时间：2026-09-14。本文是数字验证系列第 11 篇。CDC 原理见 跨时钟域 CDC 基础，复位设计见 复位设计，已有 RDC 基础见 复位域交叉 RDC。这一篇聚焦“报告怎么分诊、什么能 waiver”。

一、为什么报告不能只看 count ​

CDC/RDC 工具基于结构推断，不知道设计意图，所以报告里会同时出现：

  • 真正缺少同步器的跨域信号；
  • 已有同步器但工具未识别；
  • qualifier/使能互斥导致的安全路径被误报；
  • 多 bit 已走握手/FIFO，但没有被识别成协议；
  • 测试、调试、常量路径需要 mode 约束；
  • reset assert/deassert 混在一起导致 RDC 大量噪音。

签核目标不是“零违例数字”，而是每类未修复项都有可复现证据和批准。

二、CDC 违例分类 ​

类型风险常见修复
single-bit data 无同步亚稳态传播目的域 2-FF 同步
同步器中间插组合逻辑吃掉收敛时间组合逻辑移到同步后
pulse 未展宽目的域漏采toggle/边沿检测或握手
multi-bit bus 逐位同步采到中间组合值Gray、握手、异步 FIFO
reconvergence多路径偏斜重新汇聚同源同步、使能限定、协议保证
async reset crossing复位撤离不可预测各域同步释放
glitch/data dependency组合毛刺跨域先寄存再跨域
黑盒边界工具看不到内部模型/约束/IP 保证文件

三、推荐分诊顺序 ​

  1. 先修时钟和复位定义：确认时钟、generated clock、分频时钟、电源关闭模式；时钟分组错，后面全是噪音。
  2. 按结构而非数量分组：同一 FIFO、同一握手模块的违例合并看。
  3. 单 bit 看同步器：是否两级、是否同源、中间是否有逻辑、是否被综合打散。
  4. 多 bit 看协议：Gray 每次一位；req/ack 期间数据稳定；FIFO 指针与空满判断正确。
  5. 看 reconvergence：多个跨域信号之后是否又进入同一组合判断；即使各自同步，偏斜仍可能产生错误周期。
  6. 隔离 mode/test/debug：scan、DFT、bring-up 模式要单独 case，不允许用功能模式掩盖测试违例。
  7. 最后写 waiver：对已由协议、IP、qualifier 证明的项精确豁免。

四、RDC 报告重点 ​

RDC 关注一个复位域的信号进入另一个复位域，尤其复位撤离阶段：

  • 复位源是否异步断言、同步释放；
  • 每个时钟域是否用本域时钟同步释放；
  • 复位信号是否有组合毛刺；
  • 多 bit 配置在复位释放时是否可能被部分采样；
  • scan/debug reset 是否绕过 reset synchronizer；
  • 电源域上电/掉电复位与全局复位次序是否冲突。

低功耗电源门控的复位次序还应结合 电源门控、隔离与保持 与 电源域 bring-up 案例。

五、waiver 应该写什么 ​

bash
CDC_WAIVER
rule: Ac_unsync01
path: u_pmu.pwr_ack -> u_cpu.pwr_ack_sync[0]
reason: 目标端使用本域 2-FF 同步器；工具未识别为标准单元因中间插入 dont_touch buffer
evidence: schematic page 12, SVA cdc_pwr_ack_sync, synth netlist scan result
modes: func; not valid in scan mode
owner: dv_li / approved: ic_lead
expire: after top netlist rerun at TA

不要写“仿真没出错”“以前项目也这样”“IP 厂商说没问题”这种无证据 waiver。

六、一个典型握手违例的分诊过程 ​

假设报告报出四条 32 位数据信号从 CPU 域跨到 PMU 域。第一步不是立刻加四个同步器，而是沿路径看是否有 req/ack：源端先写数据、再拉 req，目的域同步 req 后采样整组总线，处理完再回 ack，源端在收到 ack 前保持数据不变。若这些条件成立，多 bit 数据本身不需要逐位同步，真正跨域的是单 bit req 和 ack。

第二步检查协议实现是否完整：req 是否由源域寄存器输出、目的端是否两级同步、数据采样是否只发生在同步后的请求周期、源端是否可能提前改变数据。任何一个条件不满足，就不能按安全握手豁免。第三步把协议登记给工具或添加结构约束，使四条 data 违例归并为一个已审计握手，而不是对每根线分别 waiver。最后在网表阶段重跑，确认综合没有复制、重排或优化同步器。

反过来，若四条信号是“状态向量”，源端任何时刻都可能改变，即使每根线后面都打了两拍，也仍是错误设计。此时应改成保持寄存器加握手、异步 FIFO，或让源端输出一次性更新的稳定配置。CDC 评审必须坚持看时序和数据稳定窗口，不能只因为报告里出现了“sync cell”就判定安全。

七、复位域常见误判 ​

RDC 噪音最多的来源是把“异步断言”和“同步释放”混为一谈。复位按下时所有触发器立即清零，本就不依赖时钟；工具若在断言阶段报告数据不可预测，需要结合设计模式过滤。真正要严格检查的是复位释放：各域是否用本域时钟同步，撤离时是否存在部分触发器先退出复位、另一部分仍在复位的窗口。

另一个常见误判是上电后只写一次的配置寄存器。设计上若保证配置写入发生在所有域退出复位之后，并且写入期间从域不采样，可作为例外；但证据必须包含复位序列和接口状态，而不能只写“固件之后会配置”。测试模式下 scan reset 常常与功能复位拓扑不同，必须单独建模式签核。功能模式 clean、scan 模式未看，是 DFT 插入后最容易漏掉的 RDC 风险。

八、签核门禁 ​

  • [ ] 所有真实时钟、生成时钟、异步关系和 reset mode 已定义。
  • [ ] unwaired single-bit violation = 0。
  • [ ] 多 bit 路径均由 Gray/握手/FIFO/已审计协议承载。
  • [ ] reconvergence 逐条分析，不把“各 bit 已同步”当充分条件。
  • [ ] RDC 复位释放路径与上电次序有波形和 SDC recovery 检查支持。
  • [ ] IP/黑盒有厂商 CDC/RDC 安全文档或内部模型。
  • [ ] Waiver 精确到实例/模式，有 owner、证据和过期条件。
  • [ ] 网表重跑结果与 RTL 一致，同步器未被优化。

相关与延伸 ​

Lint waiver 管理见 Lint 与 SpyGlass waiver 签核；异步 FIFO 见 异步 FIFO 与 Gray 码；SDC 异步约束见 SDC 约束实战。

总结 ​

CDC/RDC 签核不是把报告清成零，而是先把时钟/复位/模式定义对，再按单 bit、多 bit、汇聚、复位释放逐类证明；凡是工具看不见的安全设计，必须用协议、波形、SVA、网表和 IP 文档支撑 waiver。