如何在跨时钟域分析中处理好复位信号？

为什么系统"偶尔起不来"？

如果你做过一定规模的 FPGA / SoC 项目， 一定遇到过这样一种非常折磨人的问题：

• 系统偶尔起不来

• 重新按一次 reset，又好了

• 单板测试没问题，系统联调开始暴雷

• 逻辑看起来完全正确，时序也收敛

最后大家往往会得出一个"经验结论"：

"可能是复位有点问题。"

这句话对了一半。

更准确的说法是：

复位，本身就是一种非常危险、 但又极容易被忽略的 CDC。

一、先说结论：

大多数"偶发起不来"的系统，根因都在 reset

原因很简单：

• 跨时钟域的

• 大量寄存器

• 比数据信号更难控制

而更要命的是：

reset 问题，90% 的情况下仿真跑不出来。

二、一个"看起来完全没问题"的 reset 写法

这是你在工程中几乎一定见过的代码：

在单时钟、小模块里，这段代码没有任何问题。

但一旦放进真实系统，就会出现隐患：

• rst_n 来自芯片外部

• 或来自另一个时钟域

• 或经过了一堆组合逻辑

于是问题来了：

这个 reset， 是在什么时候被"释放"的？

三、reset 的真正风险，不在"拉低"，而在"释放"

工程上有一个非常重要、但常被忽略的事实：

异步 reset 的"assert"是安全的， "deassert" 是危险的。

看一个典型场景：

如果 rst_n 的释放：

• 落在 clk 的建立/保持窗口附近

• 或不同寄存器看到的释放时间不一致

你会得到什么？

• 有的寄存器已经开始工作

• 有的寄存器还停留在 reset 状态

• 非法组合状态启动

这就是：

系统"偶尔起不来"的经典成因。

四、更隐蔽的问题：

多时钟域，共用一个 reset

很多系统为了"简单"，会这么做：

• 一个全局 reset

• 拉到所有时钟域

• 每个 always 块都用它

逻辑上看，很干净。 工程上看，极其危险。

因为这等价于：

用一个异步信号，同时去控制多个不相关的时钟域。

结果通常是：

• A 域已经完全退出 reset

• B 域还在 reset 边缘抖动

• 两个域之间的 CDC 路径立刻失控

五、工程上正确的 reset 思路（不是写法）

先说结论：

reset 本身可以是异步的， 但 reset 的释放，必须是"各域同步的"。

也就是说：

✅ 正确模式是：

   典型实现方式：

重点不在代码，而在原则：

• 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 不是靠"习惯"保证的， 而是靠"流程"兜住的。