文章来源：FPGA技术联盟
为什么系统“偶尔起不来”？
如果你做过一定规模的 FPGA / SoC 项目， 一定遇到过这样一种非常折磨人的问题：
• 系统偶尔起不来
• 重新按一次 reset，又好了
• 单板测试没问题，系统联调开始暴雷
• 逻辑看起来完全正确，时序也收敛
最后大家往往会得出一个“经验结论”：“可能是复位有点问题。”
这句话对了一半。
更准确的说法是：复位，本身就是一种非常危险、 但又极容易被忽略的 CDC。
一、先说结论：
大多数“偶发起不来”的系统，根因都在 reset
原因很简单：
• 跨时钟域的
• 大量寄存器
• 比数据信号更难控制
而更要命的是：
reset 问题，90% 的情况下仿真跑不出来。
二、一个“看起来完全没问题”的 reset 写法
这是你在工程中几乎一定见过的代码：
1 always @(posedge clk or negedge rst_n) begin
2 if (!rst_n)
3 state <= IDLE;
4 else
5 state <= next_state;
6 end
在单时钟、小模块里，这段代码没有任何问题。
但一旦放进真实系统，就会出现隐患：
• rst_n 来自芯片外部
• 或来自另一个时钟域
• 或经过了一堆组合逻辑
于是问题来了：
这个 reset， 是在什么时候被“释放”的？
三、reset 的真正风险，不在“拉低”，而在“释放”
工程上有一个非常重要、但常被忽略的事实：
异步 reset 的“assert”是安全的， “deassert” 是危险的。
看一个典型场景：
1 rst_n _________|‾‾‾‾‾‾ 2 clk ↑ ↑ ↑ 3
如果 rst_n 的释放：
• 落在 clk 的建立/保持窗口附近
• 或不同寄存器看到的释放时间不一致
你会得到什么？
• 有的寄存器已经开始工作
• 有的寄存器还停留在 reset 状态
• 非法组合状态启动
这就是：
系统“偶尔起不来”的经典成因。
四、更隐蔽的问题：
多时钟域，共用一个 reset
很多系统为了“简单”，会这么做：
• 一个全局 reset
• 拉到所有时钟域
• 每个 always 块都用它
逻辑上看，很干净。 工程上看，极其危险。
因为这等价于：
用一个异步信号，同时去控制多个不相关的时钟域。
结果通常是：
• A 域已经完全退出 reset
• B 域还在 reset 边缘抖动
• 两个域之间的 CDC 路径立刻失控
五、工程上正确的 reset 思路（不是写法）
先说结论：
reset 本身可以是异步的， 但 reset 的释放，必须是“各域同步的”。
也就是说：
正确模式是：
1 外部 reset 2 ↓ 3 每个时钟域 4 各自同步 5 ↓ 6 域内 reset 使用 7
典型实现方式：
1 // clk 域 reset 同步 2 always @(posedge clk or negedge rst_n_async) begin 3 if (!rst_n_async) begin 4 rst_sync1 <= 1'b0; 5 rst_sync2 <= 1'b0; 6 end else begin 7 rst_sync1 <= 1'b1; 8 rst_sync2 <= rst_sync1; 9 end 10 end 11 12 assign rst_n = rst_sync2;
重点不在代码，而在原则：
• reset 的释放
• 必须满足该时钟域的时序要求
六、为什么 reset CDC 特别容易被忽略？
因为 reset 具备几个“反工程直觉”的特性：
• 不参与功能逻辑
• 不依赖激励
• 仿真里几乎永远是“理想释放”
• 出问题直接影响整个系统
更现实的一点是：
reset 通常是最后才接的信号。
等你发现问题时， 系统已经很难再大改结构了。
七、工程中的真实场景：
reset + CDC 的组合拳
下面这些情况，单独看没问题，组合起来就致命：
• 异步 reset
• CDC 控制信号
• 状态机依赖 reset 后的默认状态
• FIFO / RAM 的初始化时序
结果往往是：
• FIFO 指针起始不一致
• ready / valid 状态错位
• 系统刚启动就进入死状态
八、那工程上是怎么兜 reset 这类问题的？
成熟团队通常不会只靠“写法规范”， 而是分两层来兜底。
1. 用 Lint 把“高风险 reset 写法”挡在门外
例如：
• reset 同时作为异步和同步信号使用
• reset 驱动组合逻辑
• reset 未被明确同步就跨域使用
• reset 与 enable / control 混用
这些问题，在代码层面其实是有规律的。
这正是 VIGIL-Lint 的典型使用场景：
• 在 RTL 阶段
• 不依赖仿真
• 提前标出高风险 reset / CDC 编码模式
解决的是：
“这些 reset 写法，从工程经验上就不该存在。”
2. 用 CDC 工具验证 reset 是否真的“被约束住了”
即使你：
• 给 reset 加了同步
• 用了双触发器
• 觉得结构“看起来很标准”
真正的问题仍然是：
它在这个设计里， 是否真的对所有 CDC 路径都安全？
这正是 VIGIL-CDC 的价值所在：
• 将 reset 作为 CDC 路径的一部分进行分析
• 识别 reset 的跨域使用情况
• 验证 reset 的同步是否正确、是否完整
• 标出 reset 释放后仍可能失控的 CDC 路径
很多团队第一次跑 CDC 时都会震惊一句：
“原来 reset 也算这么多条 CDC。”
九、一个工程总结
• 最高风险 CDC 之一
• deassert
• 多时钟域绝不应该“共享一个未同步 reset”
• 时序 + CDC + 架构问题
结语
如果你只记住这一篇的一句话：
系统“偶尔起不来”， 几乎从来不是偶然。
工程补充：reset + CDC，工程上怎么兜底？
在真实项目中：
• reset 的问题，往往不是“没同步”
• 而是“某一条路径、某一个域没同步好”
工程上常见的成熟做法是：
• VIGIL-Lint
• 在 RTL 阶段约束 reset / CDC 的高风险写法
• VIGIL-CDC
• 系统性分析 reset 相关的所有跨时钟路径
• 验证 reset 释放是否真正受控
最终形成共识的一句话是：
reset 不是靠“习惯”保证的， 而是靠“流程”兜住的。
VIGIL-CDC 数字电路跨时钟域设计验证管理平台
概述
VIGIL-CDC 是一款面向 ASIC 与 FPGA 设计的数字电路跨时钟域（CDC）设计验证管理平台，专注于解决多时钟系统中最隐蔽、也最危险的同步失效问题。CDC 问题往往**难以通过仿真复现**，却可能在硬件中引发偶发死机、数据错误甚至系统失效。
VIGIL-CDC 采用强大的静态分析技术，在 RTL 和/或门级阶段，无需依赖仿真激励，即可自动识别设计中的所有 CDC 路径，对同步结构进行系统性验证与分类，评估整体同步可靠性，并给出清晰的问题定位与修复建议，帮助团队在流片或上板之前，将 CDC 风险真正“控制”。
核心功能
全自动 CDC 路径识别：无需测试向量，完整提取并分析所有跨时钟域信号；
同步结构智能验证：支持标准同步器、自定义逻辑、第三方 IP 及 FPGA 原语 ；
异步 reset 与复杂场景覆盖：系统性分析 reset、脉冲、多比特、FIFO 等工程常见用法；
风险分类与可靠性评估：区分正确/错误同步路径，给出可量化的设计可靠性结论；
高效调试与闭环修复：图形化 CDC 关系展示，一键回溯 RTL，并提供可靠修复建议。