3. CDC规则集与检查流程

SpyGlass CDC 的检查能力并不是由一个“大而全”的规则包一次性完成的，而是按验证目标拆分成多个规则集（rule set），每个规则集内部又包含若干条具体规则（rule）。理解规则集与规则的关系、如何选择规则集、如何用 goal 组织检查目标，以及如何做增量分析和解读报告，是搭建一条可复用 CDC 验证流程的基础。

规则集与规则的关系

在 SpyGlass 中，规则集是规则的逻辑分组，通常按验证意图划分。CDC 相关最常用的几个规则集包括：

• cdc：CDC 检查的基础集合，覆盖跨时钟域信号的基本结构检查，例如缺少同步器、组合逻辑跨越时钟域、多比特信号直接跨域等。
• cdc_verify_struct：偏结构性的 CDC 验证，重点检查同步器结构是否完整、是否被正确例化、是否存在旁路路径，以及复位、使能等控制信号是否与数据路径一致地跨域。
• cdc_verify_glitch：针对毛刺与组合逻辑跨域的检查，识别可能因组合路径产生的窄脉冲被目标时钟采样的情况。
• cdc_verify_scheme：验证同步方案本身是否被正确实现，例如握手、格雷码、异步 FIFO 等方案的结构约束。
• cdc_setup：用于建立时钟、复位、约束等 CDC 分析所需的环境信息，本身不产生大量检查结果，但为其他规则集提供输入。

规则集与规则是“集合与元素”的关系：一个规则集包含多条规则，每条规则有唯一的规则名（如 Ac_unsync01、Ac_glitch01 等），并带有默认的严重级别（Error/Warning/Info）。规则集可以整体启用，也可以只启用其中某几条规则。实际项目中，通常先启用规则集，再根据项目阶段和噪声情况对个别规则做开关或级别调整。

goal 与 rule 的关系

goal 是比规则集更高一层的“验证目标”抽象。一个 goal 可以绑定一个或多个规则集，也可以只绑定若干条规则。它的作用是让验证流程围绕“我要证明什么”来组织，而不是围绕“我开了哪些规则”来组织。例如：

• goal cdc_struct 绑定 cdc_verify_struct，目标是证明所有跨时钟域路径都有合法的同步结构。
• goal cdc_glitch 绑定 cdc_verify_glitch，目标是证明没有组合逻辑毛刺被目标时钟采样。
• goal cdc_scheme 绑定 cdc_verify_scheme，目标是证明握手、格雷码等同步方案实现正确。

goal 与 rule 的关系可以理解为：goal 是“验证意图”，rule 是“具体检查项”，规则集是两者之间的组织层。一个 goal 可以包含多条 rule，一条 rule 也可以被多个 goal 引用。这样在报告和回归时，可以按 goal 汇总通过率，而不是只看单条规则的告警数量。

规则集选择策略

规则集选择不是越多越好。全开会导致大量与当前设计无关的告警，掩盖真正的问题。建议按阶段选择：

• RTL 早期：先跑 cdc_setup 建立时钟和复位约束，再启用 cdc 和 cdc_verify_struct，快速发现缺少同步器、多比特直接跨域等结构性问题。
• 结构稳定后：加入 cdc_verify_glitch，检查组合逻辑跨域和毛刺风险。
• 方案实现阶段：启用 cdc_verify_scheme，验证握手、格雷码、异步 FIFO 等方案是否满足结构约束。
• 回归阶段：只保留与项目相关的规则，关闭已知误报规则，用 goal 汇总结果。

选择时还要注意规则之间的重叠。例如 cdc 中的某些规则与 cdc_verify_struct 有交集，同时启用可能产生重复告警。此时应通过规则级开关去重，而不是简单关闭整个规则集。

增量分析与报告生成

增量分析的核心是只重新检查受影响的模块或路径，而不是每次全芯片重跑。SpyGlass 支持基于文件变更、模块变更或约束变更的增量模式。实际使用时，通常先做一次全量分析建立基线，之后在 RTL 修改后只对变更模块及其跨域路径重新分析。增量分析的关键是保证约束和时钟定义同步更新，否则会出现“旧约束配新 RTL”的假结果。

报告生成通常按 goal 或规则集输出，包含：规则名、严重级别、违规对象、时钟域、路径、建议修复方式。解读报告时，先看 Error 级别，再看 Warning；对每条告警要判断是真实问题、约束缺失还是工具误报。真实问题必须修 RTL 或加同步器；约束缺失要补时钟、复位或 false path；误报则通过 waiver 或规则开关处理，并记录原因。

结果解读与闭环

结果解读要形成闭环：报告中的每条 Error 都要有对应的处理动作——修 RTL、补约束、加 waiver 或确认误报。处理后再跑增量分析，确认该条告警消失且没有引入新告警。对于 Warning，可以按风险排序，优先处理涉及多比特跨域、复位跨域和握手路径的告警。最终以 goal 为单位输出通过/不通过结论，作为 CDC 验证的签核依据。

整个流程可以概括为：选规则集 → 绑 goal → 跑分析 → 读报告 → 处理告警 → 增量复跑 → 按 goal 签核。每一步都要有明确的输入和判断依据，避免把 CDC 检查变成“跑完看数量”的形式化动作。