硬件仿真验证的可测试性设计具有以下作用：

确保检测出电路中所有的故障 减少测试开发相关的成本和时间 减少测试制造芯片所需的执行时间

总体而言，随着时间的推移，行业内出现两种形式的 DFT：ad-hoc DFT 和结构化 DFT。

Ad-hoc DFT 包括一套提倡“良好”设计规范的规则，旨在简化和加速测试流程。例如，提供置位和复位信号，使得所有触发器均可初始化；避免引起振荡的异步逻辑反馈；逻辑门设计应注意避免扇入数过大（扇入数过大会导致难以观察输入和控制输出），或是为难以控制的信号提供测试控制。例如，长计数器产生的信号需要很多个时钟周期进行控制，这就需要增加测试序列的长度。一般而言，ad-hoc DFT 不会增加逻辑，即不会在设计中消耗硅。

结构化 DFT：扫描和 BIST

在一些流程中，结构化 DFT 将引入额外的测试逻辑。最常用的结构化方法是扫描和内置自测试 (BIST)。

1973 年，Williams 和 Angell 首次提及“扫描”一词。相较于组合设计，时序电路通常难以测试。扫描方法的主要原理是将内部存储元件作为一个移位寄存器链的一部分，从而通过串行移位进行控制和观察。在扫描链中，测试任何电路的主要问题是减少寄存器之间的组合逻辑。基本操作是将每个触发器转变为扫描寄存器。唯一的成本是额外增加一个多路复用器。在正常模式下，触发器将以常规方式运作。在扫描模式下，触发器将用作移位寄存器。可以扫描输出触发器中的内容，也可以扫描输入新的值。更重要的是，该方法支持开发自动测试模式生成器 (ATPG)，并且可减少耗时繁琐的测试向量创建工作。

随着时间推移，电路复杂程度不断增加，与测试程序开发成本相同，90年代的VLSI设计以及千禧年的SoC芯片，其测试设备成本和软件开发成本都大幅飙升。只需考虑：

超高且依旧不断增加的芯片逻辑/管脚比例使得我们更加难以准确控制和观察器件内部的工作状况，对于测试而言尤为如此

SoC 器件越来越密集，工艺技术节点间的压降更快 测试模式生成和应用变得极长 大量的测试数据必须存储在 ATE 中 全速测试（GHz 级）越来越困难，价格极其昂贵 不熟悉被测设计 (DUT) 门级结构，这是由于硬件描述语言HDL的逻辑自动被综合，因而带来了可测试性插入问题。 专业测试工程师严重缺乏

为应对这一不可阻挡的趋势，业内将部分测试仪的功能集成到芯片上，并命名为 BIST。BIST 降低了复杂度，继而又通过以下两种方式降低成本和减少对外部（已编程模式）测试设备的依赖：

减少测试周期持续时间 减少由测试仪控制驱动/检查的 I/O 信号数目，从而降低测试/探查设置的复杂度。

然后，BIST 就可实现全速（GHZ 级）测试电路，而后进行更为彻底的检查。

基本方法是将“优良”测试结果（响应）压缩成一个“标志”，并将伪随机（伪穷举）模式生成器 (PRG) 应用到芯片上。BIST 本质上是将模式生成和响应评估集成到芯片上。

最主流的 BIST 方法中，为逻辑模块施加输入时，经修改的扫描单元生成伪随机测试向量，并接着收集输出标志（借助一个线性反馈移位寄存器）。BIST 示例包括用于生成伪随机序列的 LFSR（线性反馈移位寄存器）和用于生成所测电路标志的 MISR（多输入特性寄存器）。

虽然 BIST 占用更多的硅片面积和验证周期（伪随机），但节省了测试向量的生成和存储成本。而且，由于其常常在全时钟频率下运行，BIST 通常占用的运行时间会较少。

DFT 验证

扫描和 BIST 设计通常是在设计的功能验证正确之后被合并到设计中。遗憾的是，片上测试架构（即扫描链、BIST 结构和压缩/解压逻辑）的插入可能影响到其自身的功能正确性。因而，必须在植入 DFT 之后执行门级设计验证。

而 HDL 仿真无法马上完成此项工作。考虑到设计复杂度，门级仿真可能需要几个月（假定为几年）才能完成全面完整的验证。

可以说，硬件仿真平台为此任务量身打造。

使用 DFT App 进行硬件仿真

Mentor Graphics 最近发布了用于硬件仿真的 DFT“App”，其中包含了完成硬件加速仿真所需的所有功能。

其编译器可创建必要的测试架构，以便从 STIL 文件读取测试向量，然后将这些向量输入到可综合的DUT以及进行输出比较。编译器还可将用户网表重新编译综合到一个能够兼容硬件仿真的结构化描述中。参见图 1。

借助 DFT App，可以将用户输入传入硬件加速器的编译器中。硬件加速器将DUT的数据综合。信息来源：Mentor Graphics

在运行期间，Veloce 硬件仿真平台从 STIL 文件中提取测试向量，然后将其应用于 DUT 并以硬件仿真速度比较输出。信息来源：Mentor Graphics。

硬件仿真执行速度比软件仿真高出几个数量级，根据表格中总结的DFT App性能表，可以看出运行DFT模式较之前提高了四到五个量级。对于需要三个月方能完成的软件仿真任务，若使用硬件仿真，实际上仅需几个小时就能完成。信息来源：Mentor Graphics。

结论

DFT App 实现在合理时间内完成 DFT 验证模式设置，从而缩短模式开发周期。可扩展的硬件和编译器可以支持规模较大的门级扫描的有效性测试以及嵌入到设计中的测试结构。DFT App 支持标准 STIL 格式文件，可与其他工具协同工作。

一个硬件仿真过程提供充足的验证能力，确保在项目管理安排的时间内完成 DFT 安排，从而加快上市时间、提高产量并最终增加利润。