四、自刷新操作时的保持时间要求

好，我们进入第4章。
前面聊了自刷新的基本时序结构，现在来啃最硬的骨头——保持时间。
说实话，我刚入行那会儿，总觉得保持时间是个“相对好满足”的参数。毕竟时钟频率降下来，保持余量应该更大才对？
但在自刷新场景下，这想法让我栽过跟头。

4.1 保持时间的本质

保持时间，是数据在时钟沿后还要稳定一段时间。
为什么需要？因为寄存器内部需要时间来完成数据锁存。
你想想看，时钟沿来了，D触发器开始采样。但采样不是瞬间完成的——内部有个“传输门”开关，开关关闭需要时间。在这期间，数据如果变了，锁存的结果就不可靠。

我对团队里的新人常说一句话：
“建立时间看时钟到得早不早，保持时间看数据走得快不快。”
在自刷新模式下，这两点都被颠覆了。

4.2 自刷新的特殊之处

正常操作时，数据和时钟走的是同步路径。
自刷新时呢？

• 时钟路径变了：外部时钟可能被门控，内部振荡器接管。
• 数据路径没变：命令/地址仍然要从外部输入（至少部分这样）。
• 相位关系不确定：内部时钟和外部时钟没有固定相位。

说白了，保持时间验证的核心问题就是——
当DRAM切换到自刷新模式时，时钟域交叉了。
外部输入的CKE信号，要进入内部时钟域。而CKE的下降沿，恰好是触发自刷新的关键事件。

4.3 一个让我印象深刻的案例

我记得有个项目，在实验室里跑自刷新测试。
跑几百万次没问题，但跑到将近一亿次时，突然挂掉。
排查了整整两周。

最后发现是什么问题？
CKE信号的下降沿，恰好落在内部振荡器的时钟沿附近。
保持时间不够了。
外部CKE的路径有延迟补偿，但内部振荡器的时钟沿是自由跑的。两者之间没有同步关系。

那修起来也很简单——加了一级同步器，再加一个保持时间检查器。
但问题是：怎么在仿真里提前发现？

4.4 保持时间的计算公式

时序约束里，保持时间检查长这样：

// 保持时间检查基本公式
// data_path_delay  -  clock_path_delay  >=  hold_time

// 在正常模式下：
// launch clock + data_path + setup_margin <= capture clock + period

// 保持时间检查：
// launch clock + data_path >= capture clock + hold_time

// 自刷新模式下，capture clock换成内部时钟：
// internal_clk_delay + data_path >= internal_clk_delay + hold_time
// 关键点：internal_clk_delay是未知的

看出问题了吗？
公式两边都有 internal_clk_delay，理论上可以抵消。
但抵消的前提是——数据路径和时钟路径的延迟相关性一致。
在跨时钟域场景下，这个假设不成立。

4.5 验证方法

我建议用三步走：

1. 第一步，找边界
   找出所有在自刷新模式下仍然有效的输入信号。
   重点是CKE，因为它是触发自刷新进入/退出的关键。
2. 第二步，建模型
   对内部振荡器建模，标出它的频率范围、抖动、起始相位不确定性。
3. 第三步，跑蒙特卡洛
   把外部时钟和内部时钟的相位差，作为一个随机变量。
   跑足够多的样本，覆盖所有相位对齐情况。

4.6 核心参数表格

下表总结了自刷新保持时间相关的参数：

4.7 自刷新保持时间验证流程

4.8 避坑指南

我从过往经验里，整理了几个容易踩的坑：

我曾经犯过第三个错误。当时觉得加了三级触发器，肯定万无一失。
结果呢？第三级触发器的保持时间还是违例了。因为前面两级只是做同步，数据本身的延迟并没有变。
所以你看，同步器只能防“亚稳态传播”，不能防“保持时间违例”。
这两个问题，要分开验证。

4.9 小结

自刷新的保持时间验证，说白了就是一句话：
把内部时钟的不确定性当作变量处理，而不是常量。
只要做到这一点，你的验证就覆盖了99%的边界情况。剩下1%靠什么？
靠你在实验室里反复测试，靠你在流片前多做几轮蒙特卡洛仿真。

好，这章就到这里。
记住今天讲的那个案例——我会在上亿次测试才暴露的问题。
你如果能在仿真阶段就抓住，那才是真本事。