EEPW论坛

可测试性设计 （DFT） 在市场上所有的电子设计自动化（EDA） 工具中是最不被重视的，纵然在设计阶段提高芯片的可测试性将会大幅缩减高昂的测试成本，也是如此。最近的分析数据表明，在制造完成后测试芯片是否存在制造缺陷的成本已增至占制造成本的 40%，这已达到警戒水平。

DFT 可以降低通过问题器件的风险，如果最终在实际应用中才发现器件有缺陷，所产生的成本将远远高于在制造阶段发现的成本。它还能避免剔除无缺陷器件，从而提高良率。插入 DFT 亦能缩短与测试开发相关的时间，并减少测试装配好的芯片所需的时间。

DFT 是电子行业的警钟，它采用自动测试模式生成器 （ATPG） 和存储内置自测试 （MBIST），是在芯片上插入测试结构（例如扫描链、MBIST 结构或压缩/解压逻辑）。扫描链通过串行移位寄存器增加了可控性和可观察性。借助扫描链，测试电路的工作得到简化和缩减。使用 ATPG 工具自动生成测试模式能够减少耗时繁琐的测试向量创建任务。

当设计经过功能验证后，片上测试架构（或扫描链）会在门级的基础上被插入，执行此操作时必须小心谨慎，因为这可能会影响芯片的功能正确性。设计更改需要进行门级验证，以确保设计完整性未受影响。测试将由测试模式的长序列执行，这是一项计算密集型任务，比寄存器传输级 （RTL） 验证繁琐得多。

值得一提的是，从设计角度而言，创建并插入 DFT 结构是一项十分简单的工作。不过，从密度和规模的层面来看，设计规模会增加，同时测试设计所需的测试模式数量也会使设计规模大大增加。

DFT 验证

当设计尺寸达到数亿门时，基于软件仿真器的验证对于门级检查而言速度过于缓慢。DFT 方法只会让事情变得更糟。如果这些负担还能够应付，那么优先使用软件仿真阵列来推进流片有助于设计工程师的工作，但会为测试工程师带来阻碍。芯片通常只进行极少的 DFT 验证就进行流片，而在流片后才执行彻底的 DFT 测试，这时要修复设计缺陷为时已晚。

DFT 验证具有多种形式，包括需要验证的自定义初始化模式。它可以是由自动测试模式生成器工具插入的片上时钟控制器，这需要在模式执行期间进行动态验证；也可以是为 MBIST 添加的逻辑，这通常需要对测试模式的相关逻辑进行功能验证。SoC 可能包括一个自定义初始化模式，此模式能够配置测试并完成从功能模式到测试模式的转换。其他测试模式可能会采用低功耗技术，测试期间，芯片的一部分将进入低功耗模式，这就需要在适当情况下的有效测试结构。

使用 DFT App 进行硬件加速仿真

硬件加速能够缩短执行彻底 DFT 验证所需的仿真周期。同时还能验证各种规模和复杂性的芯片的功能。

30 年来，人们一直使用硬件加速仿真部署可重复编程的硬件来增加验证周期，而新的部署模式使这项技术成为更可行的验证工具，同时也为“App”的方法奠定基础。对于仍受困于基于软件仿真器进行验证的芯片设计团队而言，近期推出的一些硬件加速仿真应用程序无疑是个好消息。DFT App 能够加速需要进行全面门级仿真的芯片设计进程。借助自动生成的模式，设计团队能够缩短整个模式开发周期。

这类硬件加速仿真的可扩展硬件和编译器能够对嵌入了扫描和其他测试结构的大型门级设计进行测试模式验证。它具有出色性能，能够运行更多仿真周期，加快 DFT 分析。DFT App 支持行业标准 STIL 格式文件，可以与其他工具协同工作，STIL 文件可用于生产测试程序以便在制造过程中发现受损芯片。

用于硬件加速仿真的 DFT App 改变了硬件加速器在开发阶段的编译流程和运行时间。这将为编译流程和运行时间带来重大变化。具有扫描和 MBIST 结构的门级设计被载入硬件加速仿真的编译器。编译器创建了用于读取STIl文件中测试向量的测试结构，然后将这些向量应用到可综合的待测器件 （DUT） 以及进行输出比较。编译器将用户网表重新编译并合成到一个能够兼容硬件加速仿真的结构化描述中。编译器创建了用于读取STIl文件中测试向量的测试结构，然后将这些测试向量用到可综合的待测设计上，再将网表重新编译并合成到一个能够兼容硬件加速仿真的结构化描述中。测试控制架构还包括比较输出的机制。参见图 1。

图 1：经 DFT App 修改后的编译流程。

调用时，设计和测试平台被映射到硬件加速器中。在运行期间，硬件加速仿真从 STIL 文件中提取测试向量，然后将其应用于 DUT 并比较输出，这一切都是以硬件加速仿真的速度完成。