3. 在线测试方法：启动测试、自适应比例测试、运行测试与硬件实现开销
在线测试，说白了就是让硬件随机数发生器（TRNG）在正常工作时，自己给自己做“体检”。它不像离线测试那样把数据导出来慢慢分析，而是边产生随机数边检查，一旦发现异常就立刻报警。我做过几个TRNG芯片项目，在线测试这部分往往是最后才被重视的，结果流片回来才发现面积超标或者时序跑不过——嗯，今天咱们就把这几个核心测试讲透。
3.1 启动测试（Repetition Count Test）
启动测试是最简单、最直观的在线测试方法。它的逻辑很朴素：如果连续出现太多次相同的比特值，那肯定有问题。
具体怎么做？
- 设定一个阈值 C（比如 10 或 16）
- 实时统计连续相同比特的个数
- 一旦计数达到 C，触发告警
我个人习惯把 C 设成 16，因为 2^16 的误报概率已经足够低。你想想看，一个理想的均匀随机源，连续出现 16 个相同比特的概率是 2^(-15) ≈ 0.003%，基本可以忽略。
核心公式：
误报概率 P = 2^(-(C-1))
当 C=16 时，P ≈ 3.05 × 10^(-5)
我的经验： 启动测试对“卡死”故障特别敏感。我曾经遇到一个案例，TRNG的振荡环因为电源噪声被锁住了，输出全0。启动测试在16个周期内就抓住了这个故障，比任何其他测试都快。
3.2 自适应比例测试（Adaptive Proportion Test）
自适应比例测试比启动测试复杂一些。它不只看连续重复，而是检查在一个窗口内，某个特定比特模式出现的比例是否异常。
基本原理：
- 取一个固定长度的窗口 W（比如 1024 比特）
- 统计窗口内“1”的个数（或者某个特定模式的出现次数）
- 如果比例偏离 50% 超过阈值，触发告警
为什么叫“自适应”？因为阈值会根据历史数据动态调整。我记得在 NIST SP 800-90B 标准里，这个测试的推荐参数是这样的：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 窗口大小 W | 1024 | 比特数 |
| 告警阈值 T | 655 | 窗口内“1”的最大允许数 |
| 误报概率 | ≈ 2^(-20) | 理想均匀源 |
注意： 自适应比例测试对“偏置”故障敏感，但对“周期性”故障不敏感。如果随机数发生器输出 01010101... 这种模式，自适应比例测试可能检测不出来，因为“1”的比例仍然是 50%。
3.3 运行测试（Run Test）
运行测试，也叫游程测试，它检查的是“连续相同比特的段”的长度分布是否正常。说白了，就是看“0的游程”和“1的游程”是不是符合随机序列的预期。
怎么做？
- 从数据流中提取所有游程（连续相同比特的段）
- 统计每个游程长度的出现次数
- 与理论分布做比较
举个例子，一个理想的随机序列中，长度为 L 的游程出现的概率大约是 2^(-L)。所以长度为 1 的游程应该占 50%，长度为 2 的占 25%，以此类推。
运行测试的硬件实现要点：
- 需要一个计数器记录当前游程长度
- 需要一个比较器检测比特翻转
- 需要一个查找表或比较器判断长度是否异常
我曾经在项目中用运行测试抓到一个很隐蔽的故障：TRNG 的采样时钟有抖动，导致某些游程长度系统性偏长。启动测试和自适应比例测试都没发现问题，但运行测试在 100 万个样本内就报警了。
3.4 在线测试的硬件实现开销
好了，讲完三种测试方法，咱们来聊聊实际落地的问题。在线测试是要占用芯片面积的，而且会影响功耗和时序。我见过不少团队在仿真时觉得没问题，结果综合出来面积超标 30%。
三种测试的硬件开销对比：
| 测试类型 | 逻辑门数（约） | 寄存器数 | 关键路径 |
|---|---|---|---|
| 启动测试 | 50-100 | 5-8 | 1 个比较器 |
| 自适应比例测试 | 500-1500 | 32-64 | 加法器 + 比较器 |
| 运行测试 | 300-800 | 16-32 | 计数器 + 比较器 |
我的建议： 如果面积预算紧张，优先实现启动测试 + 自适应比例测试。运行测试可以作为可选模块，在面积允许时再添加。三种测试一起上，覆盖率能达到 99.9% 以上。
另外，在线测试的时钟频率也很关键。如果 TRNG 的输出速率是 100 Mbps，那在线测试模块必须能在 10 ns 内完成一次检测。我习惯把在线测试的流水线深度控制在 3 级以内，否则时序容易崩。
最后说一句，在线测试的覆盖率不是越高越好。我见过有人把阈值设得太严，结果正常工作的 TRNG 频繁误报，导致系统不断复位。嗯，这里要注意：在线测试的目标是检测“硬件故障”，不是检测“统计偏差”。把这两个概念搞混了，设计就会走偏。