使用片上PLL优化跳变故障测试向量生成及其对压缩技术的影响

作者: Frederic HIEBEL (Texas Instruments Inc.) 会议: SNUG Europe 2008 页数: 17 源文件: SNUG_2008_Europe_Hiebel_How_to_build_a_million_gate_paper.pdf

Page 1

使用片上PLL优化跳变故障测试向量生成及其对压缩技术的影响

Frederic HIEBEL Texas Instruments Inc. f-hiebel@ti.com

Page 2

摘要

在SoC 系统级芯片的背景下，时钟架构的复杂性影响着ATPG 自动测试向量生成过程，特别是跳变故障向量生成策略。通常我们的SoC需要生成数百个由锁相环 PLL产生的内部时钟。所有这些时钟都必须用于和控制跳变故障测试。因此，从ATPG的角度来看，我们需要能够通过TI专有的时钟控制器（也称为时钟整形器 Clock Shaper）精确控制内部时钟。这种内部时钟生成需要完全符合整个SoC的静态时序分析 STA，以符合"允许的"时钟方案场景。TetraMAX中开发的新"时钟约束"功能允许处理多时钟定义以及所有这些时钟方案场景的描述。

本文展示了关于这一新功能及其与压缩技术结合的若干实验： - 时钟控制器由一个特定的扫描链（称为"时钟链"）管理。 - 我们研究了在有限测试通道和高压缩比的情况下时钟链的位置，以实现最高的测试覆盖率与最低的向量数量。 - 我们主要关注以下三种可能的流程： - 时钟链在压缩逻辑内部，随机链上 - 时钟链在压缩逻辑内部，特定链上 - 时钟链在压缩逻辑外部

本文涵盖从DFT Compiler MAX创建网表到TetraMax生成向量的整个流程。

Page 3

1.0 背景 1.1 市场约束 1.2 评估环境 1.3 设计约束 1.4 设计约束（续） 2.0 时钟链实现实验 2.1 流程1 2.2 流程2 2.3 流程3 3.0 使用TetraMax生成测试向量 3.1 新"时钟约束"功能的使用 3.2 不同流程获得的结果 4.0 结论与建议 5.0 致谢

图表目录

图1 — 流程1时钟链布局图2 — 流程1综合脚本图3 — 解压缩IP结构图4 — 流程2时钟链布局图5 — 流程2综合脚本图6 — 流程3时钟链布局图7 — 流程3综合脚本图8 — 2时钟域设计示例图9 — 测试覆盖率 vs 向量数量的结果图10 — 放大的测试覆盖率曲线 vs 向量数量图11 — CPU时间 vs 向量数量图12 — 建议限制：时钟链上无重叠

Page 4

1.0 背景

1.1 市场约束

我们开发的芯片面向无线终端市场。这要求我们遵守包括测试质量和测试成本（高产量）在内的多种约束。为了应对这些约束，我们利用了许多参数，例如： - 使用极低成本测试机（TI自研测试机） - 使用多站点策略（并行测试多个芯片） - 使用设计技术减少测试时间/测试成本

这类设计主要由数字模块组成，用于测试它们的基本技术是扫描测试。这占整体测试时间的重要部分。本演讲的目标是描述我们使用DFT Compiler MAX所做的试验，以通过使用内部锁相环 PLL提供高频时钟来减少跳变故障测试的测试时间。

1.2 评估环境

以下实验在生产芯片OMAP2430C上进行。这是一个复杂的SoC 系统级芯片。从扫描测试的角度来看，该设计的主要特征包括： - 数百万门 - 超过100,000个DFF - 约50个时钟域，有些是同步的，有些是非平衡的

1.3 设计约束

为了在OMAP2430C这类SoC上使用目标低成本测试机执行跳变故障测试，开发了一些特定的硬件。为了能够在扫描测试期间以正确的频率覆盖所有逻辑，实现了一个内部硬件模块。它用于控制移位时钟和不同的捕获时钟。后者经过整形以达到目标正确的频率，称为时钟整形器（Clock Shaper）。

该时钟整形器由以下信号驱动： - 来自焊盘的移位时钟 - 一个PLL时钟

时钟整形器内部的一组扫描寄存器用于选择启动（launch）和/或捕获（capture）时需要脉冲的时钟。在由时钟整形器控制的不同时钟中，我们可以选择仅一个或几个用于启动脉冲，也许其他几个用于捕获脉冲。这提供了对不同时钟域的完全控制和混合能力。

此能力对于处理多时钟域（其中一些是同步的，另一些则不是）是必需的。

Page 5

1.4 设计约束（续）

在保持高测试质量的同时减少测试时间是DFT工程师面临的最大挑战之一。使用压缩逻辑/IP（如DFTMAX）现已成为必须。压缩引擎的挑战在于从少量测试机引脚（称为扫描通道）驱动大量扫描链（OMAP2430C中有数百条）。

DFTMax压缩建立在纯组合逻辑技术之上。这意味着内部扫描链通过配置多路复用器从外部扫描输入接收值。这些多路复用器有不同的配置，但对于所选择的某一配置，只有一个扫描输入被广播到多条内部扫描链。因此，如果我们必须约束加载到某条内部扫描链（用于编程时钟整形器）的值，这可能会减少工具在填充扫描链和加载care bits方面的自由度，从而影响向量数量（测试成本）和测试质量。

这就是我们在OMAP2430C上进行实验的关注点。使用时钟整形器的压缩跳变故障测试向量生成为压缩工具带来了巨大挑战。在生成过程中，工具必须管理时钟链上的约束。在捕获周期期间，加载到内部时钟控制器的约束将决定施加在目标时钟域上的波形。

我们一直在思考时钟链应放置在何处才能使对测试时间的影响最小化。

Page 6

2.0 时钟链实现实验

研究在三种不同实现上进行： - 流程1：时钟链随机放置（OMAP2430C初始配置） - 流程2：时钟链是解压缩IP寻址的第一批扫描链的一部分 - 流程3：时钟链由测试通道直接驱动

2.1 流程1

流程1对应OMAP2430C上使用的初始配置。由测试机使用和控制的N个扫描通道分为3组： - C个通道用于控制扫描链 - A个通道用于控制解压缩器内部的仲裁（模式位） - 1个通道用于在压缩输出级处理"X"屏蔽

其中C+A+1=N。目标是使C尽可能高，以达到最大的理论压缩比。

这是运行扫描插入时Design Compiler插入DFTMax IP的标准用法。当进行顶层综合时，时钟链随机放置在其他扫描链之中。

Page 7

以下脚本展示了使用Design Compiler进行标准DFTmax插入。从综合中加载芯片的"ddc"模型。该模型嵌入了一个CTL模型，其中包含设计中所有扫描链的描述：

#################################
Read initial OMAP2430C model ###
#################################
free -des
read_ddc  ./omap2430c_2007.03.ddc
link
read_test_model -f ctl ./omap2430c_core_ES2.ctl -design omap2430c_core
use_test_model -true omap2430c_core
set_dft_signal -type ScanClock -view existing_dft  -timing { 45 55 } -port  temp_shift_capt_clk_1_in
set_dft_signal -type ScanEnable -view spec -active_state 1 -port temp_scan_en
define_test_mode SCAN -usage scan
################################
Insertion of the compression IP ###
################################
define_test_mode COMPRESSED  -usage scan_compression
N Channels defined ###
set_scan_configuration -chain_count N -test_mode SCAN
set_scan_compression_configuration -base_mode SCAN -test_mode COMPRESSED
Use IP able to handle X masking and define scan chain length max to be MAX_LENGTH
set_scan_compression_configuration -max_length  -test_mode COMPRESSED  -xtol high
set_dft_configuration -scan_compression enable
create_test_protocol
run DRC checks in TetraMax ###
dft_drc
preview_dft -show all > preview_dft_flow1.all
Run IP insertion###
insert_dft
Write out result models-netlists###
write -f ddc -hier -out  ./omap2430c_flow1.ddc
write_test_protocol -out ./omap2430c_flow1.spf -test_mode COMPRESSED
write_test_protocol -out ./omap2430c_flow1_scan.spf -test_mode SCAN
write -f verilog -hier -out ./omap2430c_flow1.v

该脚本执行的工作： - 从之前执行的综合中加载ddc文件 - 告诉工具使用CTL模型理解扫描结构 - 定义用于扫描插入的标准约束：扫描使能和扫描时钟 - 定义压缩IP设置：N个通道/每条链最大MAX_LENGTH个触发器/所需的X容忍度 - 插入IP并在TetraMax下运行检查 - 没有对扫描链位置采取特别的关注

Page 8

2.2 流程2

如果我们仔细观察解压缩模块的结构，可以看到在我们的案例中，有C条链是由驱动压缩IP的C个通道直接驱动的。如前所述，A个通道用于通道路由的内部仲裁。有一个例外情况：前C条扫描链是控制通道值的复制。

流程2考虑了解压缩逻辑的内部结构。如果时钟链是前C个通道的一部分，它将使ATPG工具的生成过程更加容易。因为时钟链上所需的约束将直接从控制通道复制。仲裁通道仍将保持独立，这将增加工具在生成过程中的自由度。下图描述了这一点：

Page 9

以下展示了通过Design Compiler的处理方式。时钟链最初在第84条扫描链上。以下脚本通过约束综合工具在插入压缩逻辑时将第84条链作为第一条链来重新排序扫描链：

################################# Read initial OMAP2430C model ### ################################# free -des read_ddc ./omap2430c_2007.03.ddc link read_test_model -f ctl ./omap2430c_core_ES2.ctl -design omap2430c_core Define scan clocks and scan-enable signals ### set_dft_signal -type ScanClock -view existing_dft -timing { 45 55 } -port temp_shift_capt_clk_1_in set_dft_signal -type ScanEnable -view spec -active_state 1 -port temp_scan_en ################################ Insertion of the compression IP ### ################################# define_test_mode SCAN -usage scan define_test_mode COMPRESSED -usage scan_compression set_scan_configuration -chain_count N -test_mode SCAN set_scan_compression_configuration -base_mode SCAN -test_mode COMPRESSED set_scan_compression_configuration -max_length -test_mode COMPRESSED -xtol high set_dft_configuration -scan_compression enable create_test_protocol dft_drc

set_scan_path 1 -dedicated_scan_out true -test_mode COMPRESSED -ordered_elements { \ "i_omap2430c_core/84" \ } insert_dft write -f ddc -hier -out ./omap2430c_flow2a.ddc write_test_protocol -out ./omap2430c_flow2a.spf -test_mode COMPRESSED write_test_protocol -out ./omap2430c_flow2a_scan.spf -test_mode SCAN write -f verilog -hier -out ./omap2430c_flow2a.v

该流程与第一个类似，只是添加了加粗显示的命令来指定内部扫描链的重新排序。OMAP2430C有数百条扫描链。时钟链在第84条扫描链内。该命令强制工具使用CTL文件中描述的第84条扫描链作为压缩IP看到的第一个扫描链。

Page 10

2.3 流程3

控制触发器的最简单方法是将它们移出压缩方案。这就是流程3所实验的内容。时钟链由测试通道直接驱动。当ATPG确定要移位到时钟链中的值时，不需要管理任何压缩约束。但我们仍需要考虑低引脚数策略。因此，驱动压缩逻辑的通道数减少了一个，这会影响目标压缩比，从而我们可以预期对向量数量产生负面影响。

Page 11

以下展示了通过Design Compiler的处理方式：

free -des read_ddc ./omap2430c.ddc link create_port -dir in test_si0 create_port -dir out test_so0 read_test_model -f ctl ./omap2430c_core_ES2.ctl -design omap2430c_core set_dft_signal -type ScanClock -view existing_dft -timing { 45 55 } -port temp_shift_capt_clk_1_in set_dft_signal -type ScanEnable -view spec -active_state 1 -port temp_scan_en define_test_mode SCAN -usage scan define_test_mode COMPRESSED -usage scan_compression set_scan_configuration -chain_count N -test_mode SCAN set_scan_compression_configuration -base_mode SCAN -test_mode COMPRESSED set_scan_compression_configuration -max_length -test_mode COMPRESSED -xtol auto set_dft_signal -view spec -type ScanDataIn -port test_si0 -test_mode all_dft set_dft_signal -view spec -type ScanDataOut -port test_so0 -test_mode all_dft set_scan_path external -dedicated_scan_out true -test_mode all_dft -ordered_elements { \ "i_omap2430c_core/84" \ } -complete true -view spec -scan_data_in test_si0 -scan_data_out test_so0

set_dft_configuration -scan_compression enable create_test_protocol dft_drc preview_dft -show all > preview_dft_flow3.all insert_dft write -f ddc -hier -out ./omap2430c_flow3.ddc write_test_protocol -out ./omap2430c_flow3.spf -test_mode COMPRESSED write_test_protocol -out ./omap2430c_flow3_scan.spf -test_mode SCAN write -f verilog -hier -out ./omap2430c_flow3.v

命令set_scan_path external -dedicated_scan_out true -test_mode all_dft -ordered_elements { "i_omap2430c_core/84" } -complete true -view spec -scan_data_in test_si0 -scan_data_out test_so0指定了第84条链将插入在输入通道0和输出通道0之间。工具现在知道压缩IP只有N-1个通道可用（并将使用C-1个通道来驱动内部扫描链）。

Page 12

3.0 使用TetraMax生成测试向量

3.1 新"时钟约束"功能的使用

当我们使用片上锁相环 PLL生成跳变故障向量时，必须符合静态时序分析 STA的结果。这给出了所有可能时钟方案场景的列表（例如在clk1上启动，在clk1、clk2和clk3上捕获...）。TetraMax不具备时序感知能力，无法识别在时钟方案方面什么是允许的、什么是不允许的。新的"时钟捕获过程"功能在TetraMax内部提供了一种新的形式化方法，列出所有可能的时钟方案场景，以及如何通过时钟整形器获取和编程它们。

能够描述我们希望ATPG 自动测试向量生成工具使用的不同内部时钟波形具有以下优势： - ATPG将只生成与指定时钟关系一致的测试向量 - 简化静态时序分析 STA反馈关于可测试的跨时钟域通信的翻译

这些"时钟约束"的定义在.spf文件（TetraMax的STIL 标准测试接口语言协议文件）中完成。

以下是使用此新功能的示例：

在以下案例中，2个内部时钟由时钟整形器控制。在这种情况下，静态时序分析组指定只有从域2到域1的通信在域1的频率下满足时序。

Page 13

在通常用于描述引脚时序、扫描链和设备设置的SPF文件中，需要添加新语句来指定这些"时钟约束"：

ClockStructures {
ClockController controller1 {
  Clocks {
"FXXXXX/Domain1/CKModuleCtrl/CKOUT" Internal {OffState 0;} //Clock domain_1
"FXXXXX/Domain2/CKModuleCtrl/CKOUT" Internal {OffState 0;}//Clock domain_2
}
InstructionRegister CLKIR {
"FXXXXX/clock_shaper/u0_ck_conf_registers/\test_ck_conf_reg[0]/Q"; // ck_conf[0] launch domain1
"FXXXXX/clock_shaper/u0_ck_conf_registers/\test_ck_conf_reg[1]/Q"; // ck_conf[1] launch domain2
"FXXXXX/clock_shaper/u0_ck_conf_registers/\test_ck_conf_reg[2]/Q"; // ck_conf[0] capture domain1
"FXXXXX/clock_shaper/u0_ck_conf_registers/\test_ck_conf_reg[3]/Q"; // ck_conf[1] capture domain2
}
ClockContraints constraints1 {
ClockingProcedure one   {
"FXXXXX/Domain1/CKModuleCntrl/CKOUT" =11 ;
//launch & capture on domain1 nothing
//happen on domain2
CLKIR=1010;}
ClockingProcedure two   {
"FXXXXX/Domain2/CKModuleCntrl/CKOUT" =11 ;
//launch & capture on domain2 nothing
//happen on domain1
CLKIR=0101;}
ClockingProcedure three   {
"FXXXXX/Domain1/CKModuleCntrl/CKOUT" =11 ;
//launch on domain1 and domain2 & capture
//on domain1
"FXXXXX/Domain2/CKModuleCntrl/CKOUT" =10 ;
//launch on domain1 and domain2 & capture
//on domain1
CLKIR=1110;}
               }
}

该语句首先声明了2个由时钟整形器控制的内部时钟。然后向工具提供属于时钟链的内部寄存器列表，在上例中命名为"CLKIR"。最后，列出了用户定义的时钟过程。对于每个时钟波形，定义了相关联的时钟链值。

在此示例中，可以认为生成跳变故障测试向量的设计人员已经收到了静态时序分析 STA团队的反馈，即域2到域1的路径在域1频率下满足时序（在这种情况下，时钟过程一甚至可能不需要）。

Page 14

为了在TetraMax中使用SPF文件中的这一新语句，需要向工具指定几条命令：

Set delay -launch_cycle system_clock
Launch off capture used
Set fault -model transition
Set drc -num_pll_cycles 2
number of PLL clock cycles supported
per load. Must be defined before defining
internal clock.
Set delay -nocommon
default
Set drc -clock -dynamic
default

Set drc -clock_constraints constraints1
constraint1 is define in the SPF file
needed for "clocking constraints" use
Run drc
Run atpg -auto

"时钟过程"不处理"launch off shift"方法学，这就是为什么必须使用命令Set delay -launch_cycle system_clock。它告诉工具数据启动将在捕获时钟脉冲上完成。Set delay -nocommon应确保工具不会尝试交替时钟过程。Set drc -clock_constraints constraints是调用使用之前在SPF文件中定义的捕获约束的命令。

Page 15

3.2 不同流程获得的结果

三个TetraMax运行以相同的设计设置约束、时钟过程数量、定义的时钟数量以及应用的TetraMax约束启动。

结果表明，流程2是在测试覆盖率与测试时间之间取得最佳折衷的方案。

就跳变故障测试而言，流程2和流程3在我们的设计中差距不大。但流程3的向量数量增加也将在所有其他类型的扫描向量（固定故障、IDDQ、路径延迟等）中出现，因此可能比仅跳变故障测试对测试时间产生更大的影响。此外，在不同的理论压缩比目标下（通道数 vs 内部扫描链数），这种增加可能更加显著。

在运行时间方面，流程3的生成过程非常快，因为工具很容易管理在时钟链上设置的约束。流程2的向量生成时间约为流程3的3倍。流程1是最复杂的，它再次花费了大量的时间。下图展示了流程1与其他两个流程之间的巨大差异。

Page 16

4.0 结论与建议

正如我们最初的想法，当目标为压缩ATPG 自动测试向量生成时，时钟链的插入对覆盖率与向量数量有很大影响。时钟链随机放置在压缩逻辑中可能导致测试时间大幅增加，还会影响向量生成时间。

在设计并集成压缩IP以面向片上锁相环 PLL跳变故障测试时，这是需要注意的事项。所有情况都可以通过Design Compiler使用目标核心的CTL模型轻松处理。可以使用少量命令来选择最有效的时钟链位置。

该解决方案可能存在一个限制：时钟链长度不应超过定义的最大扫描链长度。在多个时钟链的情况下，该解决方案可能不是最优的。如果使用多个时钟控制器，则不同的时钟链可能位于不同的扫描链上。本文的结果适用，只要时钟链之间没有重叠：

Page 17

时钟链重叠可能导致向量数量增加，即使两个时钟链都在压缩逻辑寻址的第一批扫描链内。控制通道上将存在更多约束，从而对工具在加载care bits方面的自由度产生更多限制。这只是一个潜在问题。在OMAP2430C上的快速实验并未显示向量数量有显著增加。

5.0 致谢

非常感谢Synopsys支持团队的持续激励和帮助。特别感谢Jean-Pierre Popieul和Kuba Smieciuszewski，他们花费了大量时间与我们一起进行各种试验。感谢Synopsys研发团队信任我们的设计来开发和测试"时钟约束"功能。

使用片上PLL优化跳变故障测试向量生成及其对压缩技术的影响

📑 目录