ATPG之debug

转自：http://www.blogbus.com/bb2hh-logs/60237492.html

 Author：pythonlong

以下根据资料和个人体会整理，如果错误，疑问欢迎请指正，讨论！！

ATPG debug要熟悉TetraMAX工具的一些功能。

STIL文件中定义的各种procedure与dft测试原理的对照。

一般shift过程之前有一个force Pi的过程。

由上图可以知道最主要的过程就是shift和capture，所以在自动向量生成过程中

最常见而必要解决的错误是shift错误和capture错误。

为了便于分析这些错误，TetraMAX提供了几个常见的视图，这些视图可以对照上图分析。

1、test_setup视图：主要用于查看分析在test_setup阶段出现的error

2、load_unload视图：主要用于分析查看load_unload阶段的问题

3、shift视图，主要用于分析查看shift阶段出现的问题

4、clock cone，clock off， clock on视图，主要用于查看和分析capture阶段出现的问题。

5、constraint视图：主要用于分析查看在fore pi以及其他约束情况下出现的error

常见ATPG rules错误分析。

1、scan chainblockage.（S1）

具体原因是因为clk或者reset，set或者数据不确定（x状态），导致数据无法向后传输。

如：reset没声明，或者reset在shift状态下没有稳定

scan的一些端口没有声明或者不稳定：

数据端口不稳定：

S1问题可以通过修改spf文件或者修改scan脚本解决。另外一些pad库也会导致这个问题。

2、BidirectionalContention Problem（Z4）

这个问题一般发生在test_setup状态，由于双向总线上要求输入输出以及输出驱动至少有一个处于Z状态才算稳定，

所以在test_setup状态一些信号的初始化没有设置好，容易导致冲突：

如下：

这个问题可以修改spf文件的test_setupprocedure，将双向的io force成z状态

3、bidi busdriver enable affected by scan cell(Z9)

这个问题的原因是因为总线的使能信号受到scan cell的影响，导致使能信号不稳定。

如下:

 如果是顶层pad，可以将这个警告忽略不计。

或者可以加入MUX在测试模式下固定其为输入或者为输出。

或者调整工具的contention检查（set_contentionbus -capture),让工具只检测clock前后的冲突

通常一些Z问题是因为io和输出驱动没有一个在Z状态（初始化或者在运行过程中）。

常见ATPG faults分析

1、AN - atpguntestable - notdetected

这个是由于一些TCS导致或者黑盒子的blockage或者latch不透明，导致观测端无法观测数据。

如：constraint引起的AN：

如：latch不透明引起的AN 

lath引起的AN可以通过run_justification调整

2、UB-undetectable-blocked

UT-undetectable-tied

由于constraint导致的无法检测问题