DFT 是一种在设计阶段将可测试性置入集成电路 (IC) 的方法,可以降低测试成本并提高制造良率,多年来以不同方式得到广泛应用。Ad-hoc 和结构化这两种方法能够有效地检测出电路中所有的故障,减少测试开发相关的成本和时间,以及减少测试制造芯片所需的实际时间。
Scan 和 MBIST 是两种最常用的 DFT 工具,在功能验证后可插入到设计中。这些工具绝对物有所值,因为在制造完成后,通过测试大量芯片是否存在制造缺陷的成本可能高达制造成本的 40%。此外,它们可以规避将失效器件推广到市场的风险,因为召回该批次失效器件的成本远远大于在测试工厂发现该问题的成本,而且容易对商誉产生不可估量的负面影响。
但是,片上测试架构(例如扫描链、MBIST 结构和压缩/解压逻辑)的插入可能影响到其自身的功能正确性。因而必须在植入 DFT 之后执行门级设计验证。然而,如今的设计规模已涉及数亿个逻辑门,完全超过了硬件描述语言 (HDL) 所能达到的性能,使其在应对当前任务时几乎毫无用处。
只有硬件加速仿真能够验证各种规模和复杂芯片的功能。硬件加速仿真的执行速度要比软件仿真高出几个数量级,例如,硬件加速仿真在数小时内就能完成需要花费约 3 个月时间的设计仿真。
新的 DFT“App”可用于硬件加速仿真*,以执行一项艰巨的任务——根据既定排程测试植入 DFT 的被测设计 (DUT),这一任务有严格的时间规定,可能没有多余的浮动时间。它给硬件加速器开发流程带来了两大改变,第一个是编译流程的改变,第二个是运行时间的变化。
首先,包含 Scan 和 MBIST 测试结构的网表与工业标准 STIL 格式文件一起传入硬件加速仿真编译器,包括设计 I/O 配置、时钟信息和测试向量。
编译器可创建必要的架构,即流量生成器和检查器,以便从 STIL 文件读取测试向量,然后将包含 DFT 逻辑的 DUT 门级网表综合成一个能够兼容硬件加速仿真的结构化说明中,最后生成 DFT 验证平台。测试逻辑还包含了 DUT 输出的对比机制(图 1)。
图 1.经 DFT App 修改后的编译流程。
在调取时,设计和验证平台映射到硬件加速器中。在运行期间,硬件加速器通过由编译器创建并在主机 PC 上运行的流量生成器从 STIL 文件读取测试向量,然后通过验证平台应用到合成 DUT 中。检查器以硬件加速仿真速度比较 DUT 的输出(图 2)。
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉