4、BIST（内建自测试）的陷阱：时钟、综合与覆盖率

BIST 这东西，听起来很美——芯片自己测自己，省了ATE测试时间，多好。但我见过太多项目，BIST 做完了，流片回来却发现根本跑不起来，或者测了半天啥也没测出来。

说白了，BIST 不是加个模块就完事的。它有三个最常见的坑：时钟不同步、逻辑被优化掉、覆盖率虚高。咱们一个一个说。

4.1 陷阱一：BIST控制器与系统时钟域不同步

这是最隐蔽的问题。BIST 控制器通常有自己的时钟，或者复用系统时钟。但很多设计里，BIST 启动时系统时钟还没稳定，或者 BIST 控制器和被测逻辑不在同一个时钟域。

我遇到过一回，项目都快 tape out 了，仿真时 BIST 一直报错。查了三天，发现 BIST 控制器用 PLL 的输出时钟，而被测逻辑用 PLL 的反馈时钟——相位差 90 度。仿真时没体现，但实际芯片上就是采样错误。

⚠️ 关键风险点：
  • BIST 启动时序与系统时钟域复位释放顺序不一致
  • BIST 控制器与被测逻辑使用不同时钟源（如 PLL 与 RC 振荡器）
  • 时钟门控（Clock Gating）在 BIST 模式下未被旁路

怎么解决？我个人习惯在原理图审查时，专门检查 BIST 模式的时钟路径：

  1. 确认时钟源：BIST 控制器和被测逻辑必须使用同一时钟源，且该时钟在 BIST 模式下不能被门控
  2. 检查复位同步：BIST 控制器的复位释放必须晚于系统时钟稳定时间
  3. 添加时钟旁路：在 BIST 模式下，所有时钟门控单元必须被强制打开
💡 我的经验： 在原理图上用不同颜色标注 BIST 模式的时钟路径，一眼就能看出有没有跨域问题。我曾经用这个方法在审查时发现了一个隐藏的时钟 mux 选择错误。

4.2 陷阱二：BIST的测试向量生成逻辑被综合优化掉

这个坑更气人。你辛辛苦苦写好了 BIST 控制器，综合工具觉得“这段逻辑没用”，直接给你优化掉了。

为什么会这样？因为综合工具很聪明，它会分析哪些逻辑在“正常模式”下永远不会被触发。BIST 控制器只在测试模式下工作，如果综合时没有正确设置 set_case_analysis，工具就会认为那些逻辑是冗余的。

我见过一个案例：某芯片的 BIST 控制器里有 128 位的 LFSR（线性反馈移位寄存器），综合后只剩 8 位。流片回来，BIST 覆盖率只有 6%，等于白做。

🔍 审查要点：
  • 综合约束中是否对 BIST 模式设置了 set_case_analysis 或 set_dont_touch
  • BIST 控制器的所有状态机是否在综合时被保留
  • 测试向量生成逻辑（如 LFSR、计数器）是否被工具识别为“不可达”

你想想看，综合工具把 BIST 逻辑优化掉，仿真时还能通过——因为仿真用的是 RTL 代码，不是综合后的网表。等到芯片回来才发现，那就晚了。

我的建议是：在综合后网表上跑一遍 BIST 仿真，确认所有测试向量生成逻辑都还在。这一步不能省。

4.3 陷阱三：BIST的故障覆盖率评估不足

很多人觉得，BIST 跑通了，覆盖率报告显示 95%，那就没问题了。其实不然。

BIST 的故障覆盖率评估，说白了就是看你的测试向量能覆盖多少种故障模型。但这里有几个常见的“注水”手法：

覆盖率注水方式 实际风险
只统计可测节点，忽略不可测节点 实际覆盖率可能只有报告的一半
使用单一故障模型（如 stuck-at） 桥接故障、延迟故障完全没覆盖
忽略 BIST 控制器自身的故障 控制器坏了，测试结果全是假的
测试向量长度不足 某些故障需要特定序列才能激活

我在项目中遇到过，某芯片的 BIST 覆盖率报告显示 97%，但量产测试时良率只有 60%。后来一查，BIST 只覆盖了逻辑单元的 stuck-at 故障，而芯片的实际失效模式是信号线之间的桥接短路。

⚠️ 避坑指南：
  • 要求提供“不可测节点”列表，并分析为什么不可测
  • 至少使用 stuck-at 和 transition delay 两种故障模型
  • BIST 控制器本身需要独立的测试机制（如 IDDQ 或扫描链）
  • 测试向量长度必须满足故障激活的序列要求

嗯，这里要注意：覆盖率不是越高越好，而是“够用”就好。但“够用”的标准是什么？我个人习惯是：对于汽车级芯片，stuck-at 覆盖率 > 98%，transition delay 覆盖率 > 90%；对于消费级芯片，可以适当放宽，但至少不能低于 85%。

4.4 知识体系：BIST 陷阱全景图

下面这张图总结了 BIST 设计的三个核心陷阱及其关联关系。你可以把它贴在原理图审查的 checklist 旁边。

BIST 设计三大陷阱全景图 BIST 设计 陷阱1：时钟域不同步 BIST控制器与系统时钟不同源 陷阱2：逻辑被综合优化 测试向量生成逻辑被工具删除 陷阱3：覆盖率评估不足 故障模型单一、不可测节点被忽略 后果：BIST 失效 → 芯片测试良率下降 → 流片失败 解决方案 ① 统一时钟源 + 时钟旁路 ② 综合约束保留BIST逻辑 ③ 多故障模型评估 ④ 综合后网表仿真验证 ⑤ 不可测节点分析 审查时重点关注：时钟路径、综合约束、覆盖率报告中的不可测节点列表

4.5 审查清单：BIST 部分

最后，我整理了一份 BIST 原理图审查的快速清单。你可以在审查时逐项核对：

📋 BIST 审查清单：
  1. 时钟域检查：BIST 控制器与被测逻辑是否同源？时钟门控是否被旁路？
  2. 复位时序：BIST 复位释放是否晚于时钟稳定？
  3. 综合约束：是否对 BIST 逻辑设置了 set_dont_touch 或 set_case_analysis？
  4. 后综合仿真：是否在综合后网表上跑过 BIST 仿真？
  5. 覆盖率报告：是否包含不可测节点分析？是否使用多种故障模型？
  6. BIST 控制器自检：控制器本身是否有测试机制？
  7. 测试向量长度：是否满足故障激活的最小序列要求？

说实话，BIST 这东西，做对了能省很多测试成本，做错了就是白费功夫。我见过太多项目在 BIST 上栽跟头，归根结底就是这三个陷阱没避开。希望这份清单能帮你少走弯路。

← 上一章 📖 返回目录 下一章 →