可测试性分析

可测试性分析

随着电路设计的规模越来越大，工艺尺寸越来越小，集成度越来越高，测试的成本也越来越高。为了降低测试的成本和难度，提高芯片质量和成品率，需要在为芯片进行可测性设计（Design For Testability），简称DFT。

可测性设计包含了很丰富的内容，它包含了DFT电路的设计和测试向量的生成（ATPG）。

常用的DFT技术

目前常用的DFT技术有：扫描链插入（scan chain）、存储器BIST插入（mbist）、逻辑BIST插入和边界扫描插入。其中扫描链插入是最常用的DFT技术。 Synopsys的DFT Compiler就是包含在DC内的用于可测性设计的工具。具有强大的功能，如：为逻辑模块进行“扫描就绪（scan-ready）”的编辑、检查已综合电路是否满足扫描规则、用top-down或 bottom-up方法插入扫描链、对扫描模块预览测试覆盖率等。

scan register

 DC综合的时候的扫描链(DFT)：检测代工厂生产过程中出现的问题，例如某些地方短路或者开路，用带选择器的触发器替代一般触发器。

如果综合时不考虑该问题，在DFT时，由于寄存器前加了mux，插入mux后寄存器间的组合逻辑多了mux，时序可能变差，面积会变大，为了评估插入扫描链带来的影响，综合的时候会采用compile -scan选项，让DC在综合的时候把普通的触发器替换成带mux 的触发器，重新评估时序能否达到要求，插入mux后，时序可能不能满足要求。

如果计划插入扫描链，则必须在合成过程中考虑扫描寄存器对设计的影响，以避免扫描插入后出现负面意外:附加扇出和容性负载；更大的setup time要求；面积增加，大于非扫描寄存器；线负载模型选择。见下图

scan register和扫描链插入

Scan Chain将芯片中的所应用的普通寄存器替换成带有扫描功能的扫描寄存器，首尾相连成串，从而可以实现附加的测试功能。我们从它的结构图来看一下：

从上图中可以看出，它比普通存储器多了SI，SE，SO这3个端口。

1. 其中SI，SO也就是scan_in与scan_out端，定义了一条scan chain的input和output端。通常情况下，每一个input会驱动一条scan chain，一个ouput也是用来观察一条scan chain的。

2. SE是scan enable信号，它控制着scan cell的工作模式。从图中可以看出，SE，SI，D端通过一个Mux实现工作模式的切换。当SE输入为0时，scan cell工作在普通模式下，相当于是普通的flop；当SE输入为1时，scan cell就进入scan模式，相当于一个移位寄存器。

Test-ready synthesis

Test-ready synthesis ( solution )：在综合的时候，还没有真正做DFT的时候，通过-scan选项只是把寄存器换一下，但寄存器功能不变，没有把所有寄存器功能连起来形成一个链。

优点：精确的area , timing , and loading modeled up front；通过-scan在译步骤中执行扫描和插入。

在约束脚本文件中包括扫描形式，见下图：

set_scan_configuration -style<multiplexed_flip_flop |checked_scan |lssd | aux_clock_lssd>

compile_ultra-scan  #AND

compile_ultra-incremental-scan

扫描寄存器在初始编译期间使用，但不链接！额外扇出负载在内部建模。如果想要连起来形成一个链，需要DFT compiler工具。Test ready synthesis需要DFT compiler license。

潜在的Scan-Shift问题，影响无风险scan的设计方案包括：

由于时钟门控，在scan触发器处没有时钟脉冲；由于时钟分频，没有时钟脉冲；在触发器处断言意外的异步复位

ATE必须完全控制到达所有scan路径触发器的时钟和异步置位和复位线

无风险scan要求：每个scan触发器必须接收ATE产生的同步时钟脉冲；由于时钟的门控，不应阻止时钟脉冲到达scan触发器，时钟边缘必须有规律的到达scan触发器，而不会被分频或倍频；

在scan-shift过程中，不会意外set或异步reset scan触发器

结论:尽早并经常运行建议的DRC检查，以确定并修复大多数问题

 自动移位寄存器识别

在扫描插入期间自动识别移位寄存器(compile_ultra -scan)；寄存器之间的buffer或inv不影响识别；当很多触发器连在一起，中间可能插入buffer或者反相器，DC默认只会把第一级的触发器用带mux的触发器替换，其他触发器不替换。见下图。

可以改善面积和减小扫描使能扇出；默认情况下，此功能处于开启状态。可通过以下命令禁用：

set_app_var compile_seqmap_identify_shift_registers  false

图8 Test-ready synthesis图9 自动移位寄存器识别

集成Design for Test

(1).如何进行manufacturing test：制造测试

自动测试设备（Automatic test equipment ：ATE）向被测设备（Device Under Test :DUT）施加输入激励并测量输出响应，如果ATE观察到与预期响应不同的响应，则DUT未通过制造测试。产生输入激励和相应输出响应的过程称为自动测试模式生成(Automated Test Pattern Generation：ATPG)。

图1制造测试

图2 （左）stuck-at fault model(SAF)    图3  （右）检测SAF的算法

(2).stuck-at fault model(SAF)：固定故障模型,表示潜在物理缺陷影响的逻辑模型。

(3)检测SAF的算法:如果存在SA0故障，则U1/Y保持在逻辑0,如果不存在SA0故障，则U1/Y被驱动到其正常值.可以利用此“either/or行为”来检测故障。

如果A接1，C,D都接0，则正常情况下，z=B，若发生SA0处短路到0，则不管B输入是1还是0，z的结果都是0.接入的信号需要确保故障能传输到输出端，与门的无关测试项接1，或门的无关测试项接0.将芯片生产过程中引入的短路，开路以及其他逻辑问题测试出来。

(4).测试多级流水线设计的故障：测试SA0故障，需要将输入引脚设置为特定值，以便pipeline中的网线可以设置为测试故障的值的组合。还需要在设计输出处观测结果，每一个被测试的故障都需要一个预测方法来控制输入和观察故障导致的输出的结果。

若存在时序电路需要测试时，把测试信号一点点挪到待测试电路部分，将寄存器串成一个链，利用移位寄存器将需要的信号移进去。再把测试结果一点点挪出去。

图4测试多级流水线设计的故障

Scan chain initializes nets within the design(adds controllability)

Scan chain captures results from within the design (adds observability )

inserting a scan chain involves replacing all Flip-flops with scannable Flip-flops

综合后的形式验证

在综合完成之后，可以进行形式验证。此外这里不是专门讲解formality的使用的，因此只会简单地实践一下它的用法。formality是Synopsys公司的形式验证工具，当我们得到了综合后的设计，就要验证综合后的设计和我们的RTL代码是否一致。

• 准备好RTL文件、综合优化后的文件以及带有优化映射信息的SVF文件：

• 书写相应地流程文件：

•  启动formality：fm_shell，对上面脚本不清楚的或者不懂的，可以使用man命令查看它的用法。
  • set_svf filename:设置用于验证的自动设置文件（svf）
  • set_top architecture_name :解析cell引用并elaborate rtl设计
  • match:将implementation design与基于比较点的reference design相匹配，运行match命令时，工具将更改为match，并将implementation design中的比较点与reference design中的比较点进行匹配。
  • 匹配完成后，命令将报告匹配结果。
  • 可以增量执行比较点匹配。当自动匹配由于reference design和implementation design之间的名称和结构的差异而失败时，这非常有用。
  • 如果打断匹配过程，工具将保留部分匹配结果，请再次运行match命令以恢复匹配
  • 如果匹配完成时reference design中仍存在不匹配的点，则可以发出控制匹配的命令，如set_compare_rule或set_user_match命令。再次运行match命令，直到reference design中的所有比较点都匹配为止。verify命令与以前匹配的比较点不匹配。
  • 无需在verify命令之前执行此命令，如果未执行匹配，则工具将在验证之前自动匹配比较点。
  • verify designID_1 designID_2:验证两个指定设计或两个比较设计对象之间的功能等效性
• 执行我们写的脚本:fm_shell -f ./scripts/fm.tcl |tee -I fm_run.log
• 得到结果如下,说明验证通过了：