芯片可测试性设计（DFT）原理与实践：从扫描链到低功耗测试

1. 从一道周五小测验聊起：为什么芯片设计必须考虑“可测试性”？

又到了周五，对于很多工程师来说，这可能意味着即将到来的周末。但在我们这行，周五也常常是技术社区里一些有趣小测验发布的日子。我记得多年前在EE Times上看到过一篇由Martin Rowe发布的“周五测验”，主题正是“Design for Test”。当时那份测验由Mentor Graphics的Bruce Swanson等人提供，题目源自他们一个名为“DFT训练营”的系列文章。虽然只是一份简单的选择题测验，但第一个问题就直击核心：在数字集成电路中插入扫描单元和扫描链，主要是为了什么？

选项看起来都挺“合理”：A. 为了能够添加或更新固件程序；B. 为了实现向已制造器件自动化交付测试向量；C. 为了让电路能够执行上电复位；D. 以上所有。如果你对芯片测试稍有了解，就会知道正确答案是B。但这个问题背后，引出了一个远比答案本身更深刻、也更让每一位芯片设计者和测试工程师头疼的议题：当芯片的晶体管数量动辄数十亿、内部信号节点深藏于硅片之下时，我们该如何确信制造出来的每一颗芯片都能正常工作？这就是“可测试性设计”要解决的根本问题。

DFT绝不是设计完成后的“锦上添花”，而是贯穿芯片设计始末的“生存必需品”。没有良好的DFT，一颗功能再强大的芯片，也可能因为无法被有效测试而变成一块昂贵的“黑砖”，良率无法评估，故障无法定位，商业上注定失败。今天，我就结合自己这些年踩过的坑和积累的经验，来系统性地拆解一下DFT的核心思想、常用技术以及那些只有实际做过才知道的实操细节。

2. DFT的核心逻辑：把内部不可见变成外部可控可观

要理解DFT，首先要明白芯片测试面临的根本矛盾。一个复杂的片上系统，其内部绝大多数寄存器、组合逻辑节点都是无法通过外部引脚直接访问的。这就像试图在不打开引擎盖的情况下，诊断一台汽车发动机每个气缸的点火情况。传统功能测试只能通过有限的输入输出引脚来验证整体功能，其测试覆盖率对于制造缺陷（如金属线短路、开路、晶体管栅氧击穿等）往往很低，而且无法定位故障位置。

2.1 扫描测试的基本原理：串接起来的观察窗

扫描测试是DFT的基石技术，也是前面测验题的核心。它的核心思想异常巧妙：通过改造设计中的时序元件（通常是D触发器），让它们在测试模式下能够连接成一条或多条长长的移位寄存器链，即扫描链。

在正常功能模式下，这些触发器照常工作；在测试模式下，它们则变成了一串珍珠项链，数据可以从链的头部（扫描输入引脚）一位一位地“扫描”进去，填充到每一个触发器里。然后，电路运行一个测试时钟周期，触发器的输出经过组合逻辑传播，结果被捕获到下一级触发器。最后，再通过扫描链将捕获的结果一位一位地“扫描”出来（通过扫描输出引脚），与预期的“黄金响应”进行比较。

这个过程实现了什么？

1. 可控性：我们可以将任意特定的0/1值设置到芯片内部几乎每一个触发器上，从而能够激活那些深藏的逻辑路径和潜在故障。
2. 可观性：我们可以将内部触发器的状态移到外部进行观察，从而看到故障效应是否被传播到了可观测点。

这样一来，内部成千上万的节点就变得“透明”了。自动测试设备只需要关心少数几个扫描输入/输出引脚，以及控制测试模式的引脚，就可以通过自动化生成的测试向量，高效地检测制造缺陷。这就是为什么测验题的答案是“实现向已制造器件自动化交付测试向量”。

2.2 除了扫描，DFT还有哪些武器？

扫描测试主要针对的是时序逻辑和组合逻辑的固定型故障（如Stuck-at-0, Stuck-at-1）。但现代芯片的测试挑战远不止于此。一个完整的DFT方案通常是一个组合拳：

• 内建自测试：主要用于测试大规模的规则结构，如存储器（SRAM, DRAM）和逻辑内建自测试。其原理是在芯片内部集成测试向量生成器和响应分析器。测试时，BIST电路自动运行，无需ATE提供大量测试向量，极大降低了测试数据量和测试时间，特别适合在系统级进行定期健康检查。
• 边界扫描：主要解决板级互连测试和芯片引脚访问问题。遵循IEEE 1149.1（JTAG）标准，它在芯片的I/O单元上增加了一圈边界扫描寄存器。通过TAP控制器，可以控制芯片每个引脚的输出值，并采样其输入值，从而在不依赖物理探针的情况下，测试电路板上芯片之间的连接是否开路、短路，甚至可以对芯片进行编程和调试。
• 模拟/混合信号测试：对于ADC、DAC、PLL等模块，DFT思路不同。通常会引入测试总线、环回路径、可配置的测试模式，以便将模拟信号引导到可观测的引脚，或将已知的测试信号注入到模拟模块中。
• 功耗感知测试：扫描测试时，成千上万的触发器在短时间内同时翻转，会产生远高于正常功能的瞬时功耗，可能导致电压跌落、芯片过热甚至损坏。因此，需要采用诸如分时扫描、测试向量排序、低功耗扫描链架构等技术来平抑测试功耗。

实操心得：DFT的代价天下没有免费的午餐。DFT的所有好处都是用代价换来的：额外的电路面积（扫描触发器比普通触发器面积大5%-20%）、额外的布线资源（扫描链走线）、额外的引脚（扫描输入/输出、测试模式控制）、可能对时序和功耗产生的影响（扫描链切换带来的负载和延迟）。因此，DFT方案必须在测试覆盖率、测试时间、面积开销、性能影响之间做出精心的权衡。一个常见的经验法则是，DFT带来的面积开销通常控制在总芯片面积的1%-5%是可接受的，而测试覆盖率的目标则需达到98%甚至99%以上。

3. 扫描链插入与管理的实战细节

理解了原理，我们来看看如何把它付诸实践。扫描链的插入和管理是数字DFT工作的核心，其中充满了各种工程决策。

3.1 扫描单元的选择与替换

现代综合工具通常提供“扫描综合”流程。你首先需要定义一个扫描单元库。通常，我们会选择一种带多路选择器的D触发器作为扫描单元。在功能模式下，数据输入端D有效；在测试模式下，扫描输入端SI有效。工具会在综合后期，用这种扫描单元一对一地替换掉设计中所有的普通触发器。

这里有一个关键点：并非所有触发器都能被替换。例如，异步复位/置位端处理不当的触发器、时钟门控单元后面的触发器、以及某些用于模拟或时钟网络的特殊触发器，可能需要特殊处理或排除在扫描链之外。你需要准备一个“免扫描列表”。

3.2 扫描链的 stitching 与优化

替换完成后，工具会将扫描单元连接成链。这个过程叫做“stitching”。你需要决定：

1. 链的数量：是用一条长链，还是多条短链？单条长链测试时间最长（串行移入/移出数据），但占用引脚资源最少（一套Scan_in/Scan_out）。多条短链可以并行操作，大幅缩短测试时间（测试时间约等于最长链的长度+若干捕获周期），但需要多套扫描IO引脚。这需要在测试机台通道资源和测试成本之间权衡。
2. 链的排序：扫描单元按什么顺序连接？随机的顺序会导致扫描链在版图上绕来绕去，增加布线长度和时序问题。通常采用物理位置邻近的单元组成一条链，或者按时钟域划分（同一时钟域的触发器放在同一条链中），这样可以优化布线、减少时钟偏斜，并简化测试时钟控制。
3. 时钟与复位处理：测试模式下，所有扫描触发器的时钟必须由ATE精确控制，以确保移位和捕获操作正确。异步复位信号必须在测试期间被置于无效状态，或者被DFT逻辑所控制，防止其在移位过程中意外复位触发器。

# 一个典型的DFT编译脚本片段（Synopsys DFT Compiler风格） set_scan_configuration -style multiplexed_flip_flop \ -chain_count 4 \ -clock_mixing no_mix \ -add_lockup true create_test_protocol dft_drc preview_dft insert_dft

3.3 测试向量生成与故障模拟

扫描链插入后，就可以使用ATPG工具生成测试向量了。工具会基于设定的故障模型（最常用的是固定型故障模型），自动计算需要什么样的扫描输入值，才能激活故障并将其传播到可观测的扫描单元。

1. 故障列表生成：工具首先提取设计中的故障点，通常每个逻辑门的输入输出端都会考虑固定为0和固定为1两种故障。
2. 向量生成：ATPG算法（如D算法、PODEM）尝试为每个故障生成测试向量。一个高效的向量集能够覆盖多个故障。
3. 故障模拟：生成向量后，工具会进行故障模拟，计算这些向量能检测到多少故障，从而得出测试覆盖率。公式很简单：测试覆盖率 = (检测到的故障数 / 总故障数) * 100%。
4. 向量压缩：原始的测试向量集可能非常庞大。工具会采用各种压缩算法，在保持覆盖率不变的前提下，减少向量数量，从而降低ATE存储需求和测试时间。

注意事项：测试覆盖率的陷阱不要盲目追求99.9%的覆盖率数字。首先，要关注“未检测故障”的类型和位置。它们是否集中在某些模拟模块、嵌入式存储器或时钟生成电路周围？这些地方可能本来就不适合用扫描测试。其次，要分析“不可控/不可观测故障”。这些故障往往揭示了DFT结构上的缺陷，比如某个逻辑模块被隔离了，或者扫描链存在逻辑上的断点。最后，ATPG工具报告的覆盖率是基于理想情况的，实际ATE测试时，由于时序、噪声等因素，有效覆盖率可能会打折扣。通常，我们会留出1%-2%的余量。

4. 高级DFT技术与低功耗测试挑战

随着工艺演进和设计复杂度的爆炸式增长，传统的DFT方法遇到了新的挑战，也催生了一些高级技术。

4.1 压缩技术

当扫描链很长时，移入移出数据的时间占用了测试时间的大头。测试数据压缩技术应运而生，其核心是在芯片内部加入一个解压缩器（位于扫描输入与多条扫描链之间）和一个压缩器（位于多条扫描链与扫描输出之间）。

• 输入解压缩：允许ATE加载较少的测试数据，在芯片内部通过线性反馈移位寄存器或广播网络等结构，扩展成填充所有扫描链所需的数据模式。这减少了ATE存储深度和传输时间。
• 输出压缩：将多条扫描链的输出响应通过一个压缩器（如XOR网络、MISR）进行实时压缩，变成一个或几个签名输出。测试结束时，只需比较最终签名是否与预期一致，无需比较每一位数据。这极大地减少了需要传输和比较的数据量，并能容忍输出响应中的未知态。

4.2 测试功耗管理

如前所述，测试模式下的开关活动率可能是功能模式的数倍。过高的测试功耗会导致：

• IR Drop：电源网络上的电压降过大，导致触发器采样错误，产生假故障。
• 热损坏：局部过热可能对芯片造成永久性损伤。
• 测试可靠性下降：即使芯片没坏，在IR Drop影响下，好的芯片也可能被误判为坏片。

应对策略包括：

• 测试向量排序：调整向量移入的顺序，避免相邻向量导致大规模的同时翻转。
• 时钟门控扫描：在移位过程中，分批次地启用不同扫描链的时钟，避免所有触发器同时动作。
• 低功耗扫描架构：如采用时钟双沿触发扫描、或带门控的扫描单元。
• 基于捕获的功耗控制：在捕获周期，只允许故障传播路径上的逻辑活动，抑制其他不必要的翻转。

4.3 小延迟缺陷测试与良率学习

在先进工艺节点（如28nm以下），互连线延迟与门延迟的占比发生变化，并且工艺波动性增大。一些不会导致逻辑错误，但会使路径延迟超过时钟周期的“小延迟缺陷”成为影响良率的主要因素。针对此，需要采用更精确的测试方法：

• 时序感知ATPG：不再只考虑固定型故障，而是生成针对特定路径的过渡延迟故障或路径延迟故障的测试向量。
• 更快的测试时钟：在ATE上使用高于功能频率的时钟进行测试，以暴露延迟缺陷。
• 片上测量：集成片上传感器来监测实际路径延迟、电压和温度，用于良率分析和芯片分级。

5. DFT工程师的日常：从设计到硅后的完整流程

DFT工作不是孤立的，它紧密嵌入芯片开发的全流程。一个典型的DFT工程师周期会经历以下阶段：

1. 设计规划阶段：

   • 与架构和设计团队讨论，确定DFT策略：需要哪些测试（扫描、BIST、JTAG）？目标覆盖率是多少？
   • 规划测试引脚：需要多少扫描IO？是否需要独立的测试时钟和复位？如何复用功能引脚？
   • 制定DFT设计规则，并写入设计文档。

2. RTL设计阶段：

   • 编写DFT友好的RTL代码。避免使用门控时钟、异步逻辑、锁存器等不利于DFT的结构，如果必须使用，则需要特殊处理。
   • 插入可测试性逻辑，如测试模式控制模块、BIST控制器、JTAG TAP控制器等。
   • 进行早期的DFT规则检查，确保RTL代码没有违反DFT规则。

3. 综合与物理实现阶段：

   • 在逻辑综合后，执行扫描链插入。
   • 进行DFT规则检查，修复DRC违例（如时钟混用、异步复位控制、扫描链断开等）。
   • 在物理布局布线后，进行带时序信息的DFT规则检查和修复，确保测试模式下时序也能收敛。

4. 验证与向量生成阶段：

   • 生成测试协议，验证测试模式切换功能是否正确。
   • 运行ATPG，生成测试向量，并评估测试覆盖率。
   • 进行故障模拟，并生成ATE可用的测试程序文件（如STIL, WGL格式）。

5. 硅后调试与良率提升阶段：

   • 分析首批硅片的测试结果，识别测试失败的模式。
   • 利用扫描链的调试模式，进行故障诊断，定位到具体的门级网表甚至物理位置。
   • 根据诊断结果，分析是设计缺陷、制造缺陷还是测试向量本身的问题，并指导下一轮设计改进或工艺调整。

踩坑实录：一个时钟域交叉的DFT问题我曾遇到一个项目，在ATE测试时，某条扫描链的失败率异常高，但功能测试却基本正常。经过漫长的诊断，发现问题出在时钟域交叉处理上。设计中有一个信号从快时钟域同步到慢时钟域，在功能模式下，同步器工作良好。但在测试模式的捕获周期，我们为了同时捕获两个时钟域的数据，使用了“锁存+捕捉”的方式，导致快时钟域的数据在慢时钟域捕获时，恰好处于亚稳态窗口，被不同扫描单元以不同值捕获，造成了响应比对失败。教训是：对于跨时钟域的信号，在DFT模式下必须格外小心。要么将其排除在扫描链外，要么在测试模式下强制其路径不活动，要么采用更稳健的测试时钟控制方案。

6. 常见问题与排查思路速查表

在实际项目中，DFT相关的问题五花八门。下面这张表整理了一些典型问题及其排查思路，希望能帮你快速定位：

DFT的世界远不止一道选择题那么简单。它是一门在芯片复杂性、测试成本、产品上市时间和最终良率之间寻求最佳平衡的艺术与科学。每一次扫描链的插入，每一组测试向量的生成，都是对这颗硅晶粒生命质量的一次郑重承诺。