2. 可测试性设计基础
随着集成电路制程不断微缩、单芯片集成度持续攀升,测试成本在芯片总成本中的占比已从早期的5%左右飙升至某些复杂SoC的30%以上。与此同时,3D IC通过TSV(硅通孔)和堆叠工艺将多个裸片(Die)集成于一体,使得测试访问路径更短、物理可探测节点更少,传统的外部ATE(自动测试设备)直接接触式测试面临严峻挑战。在这样的背景下,可测试性设计(Design for Testability, DFT)不再只是后端工程师的“附加任务”,而是贯穿芯片架构定义、RTL设计、物理实现到量产测试全流程的核心设计方法学。本章将系统阐述DFT的定义与目的、三大核心度量指标(故障覆盖率、测试时间、面积开销),并明确DFT在IC设计流程中的具体位置与交付物。
上图展示了DFT在IC设计流程中的嵌入位置以及三大核心度量指标的关系。从架构定义阶段开始,DFT工程师就需要与架构师、前端设计工程师协同,规划扫描链结构、测试访问端口(TAP)、内建自测试(BIST)等策略。在RTL设计阶段,可测性代码被插入;逻辑综合阶段完成扫描链的映射与优化;DFT验证阶段通过ATPG工具生成测试向量并评估故障覆盖率;最终在物理实现阶段确保DFT逻辑满足时序与布线要求。测试数据流则从ATPG工具出发,经过故障仿真验证,生成标准格式测试向量,最终在ATE上执行量产测试。对于3D IC,TSV测试、堆叠良率管理和测试访问机制成为额外关注重点。
2.1 DFT的定义与核心目的
DFT(Design for Testability)是一系列设计方法学的总称,其核心思想是在芯片设计阶段就考虑后续测试的可行性,通过增加额外的测试逻辑和结构,使芯片内部节点能够被外部测试设备有效控制和观测。DFT并非单一技术,而是包括扫描链(Scan Chain)、内建自测试(BIST)、边界扫描(Boundary Scan, IEEE 1149.1)、测试压缩(Test Compression)等多种方法的集合。
DFT的根本目的可以归纳为以下四个层面:
- 提升故障覆盖率:通过扫描链将时序逻辑转化为可控可观测的移位寄存器,使得ATPG工具能够对组合逻辑故障进行高效测试。对于深亚微米工艺,固定故障(Stuck-at Fault)覆盖率通常要求达到98%以上,而延迟故障(Transition Fault)覆盖率也需达到90%以上。
- 降低测试成本:测试成本主要由测试时间决定。DFT通过测试压缩技术(如EDT、OCC)将测试向量数量减少10-100倍,从而显著缩短ATE测试时间。例如,一个原本需要200万向量的设计,经过压缩后可能只需20万向量。
- 提高故障诊断能力:DFT结构不仅用于量产测试,还支持失效分析。通过扫描链的移位输出,工程师可以定位到具体的故障逻辑单元,加速良率提升和失效根因分析。
- 支持3D IC堆叠测试:对于TSV和堆叠芯片,DFT需要提供裸片级(Die-Level)和堆叠级(Stack-Level)的测试访问机制。IEEE 1838标准定义了3D IC的测试访问架构,确保每个裸片在键合前可测(KGD概念),堆叠后整体可测。
核心原理说明:DFT的本质是“可控制性”和“可观测性”的工程化实现。可控制性指通过测试端口将内部节点置为特定逻辑值的能力;可观测性指将内部节点状态传输到外部可观测端口的能力。扫描链技术通过将触发器串联成移位寄存器,同时实现了这两个属性——在移位模式下,测试数据从扫描输入(Scan In)注入,在捕获模式下,组合逻辑响应被捕获到触发器,再通过移位模式从扫描输出(Scan Out)读出。
2.2 可测试性度量:三大核心指标
可测试性的优劣需要量化评估,业界普遍采用以下三个核心指标:
| 度量指标 | 定义与计算公式 | 典型目标值 | 影响因素 | 优化手段 |
|---|---|---|---|---|
| 故障覆盖率(FC) | FC = (检测到的故障数 / 故障总数) × 100% | Stuck-at ≥ 98% Transition ≥ 90% |
扫描链结构、ATPG算法、测试向量数量 | 增加扫描链、改进测试点插入、使用确定性ATPG |
| 测试时间(TT) | TT = (测试向量数 × 扫描周期数) / 测试时钟频率 | 单芯片测试时间 ≤ 数秒至数十秒 | 向量数量、扫描链长度、测试时钟频率 | 测试压缩、并行测试、提高测试时钟 |
| 面积开销(AO) | AO = (DFT逻辑面积 / 芯片总逻辑面积) × 100% | 逻辑面积开销 ≤ 5% 存储器BIST开销 ≤ 1% |
扫描触发器替换、BIST逻辑、测试压缩逻辑 | 共享BIST控制器、优化扫描链分组 |
三个指标之间存在相互制约关系:提高故障覆盖率通常需要增加测试向量或改进DFT结构,这会增加测试时间或面积开销;测试压缩技术可以在不显著增加面积的前提下减少测试时间,但压缩逻辑本身会带来约1%-3%的面积开销。因此,DFT工程师需要在项目初期就设定明确的量化目标,并在设计过程中持续评估。
2.3 DFT在IC设计流程中的位置与交付物
DFT活动贯穿IC设计的完整生命周期,每个阶段都有明确的输入、活动和输出:
- 架构定义阶段(Pre-silicon):DFT工程师参与制定测试策略,确定扫描链数量与长度、BIST架构、测试端口方案。此阶段输出DFT架构文档和测试计划。对于3D IC,还需规划TSV测试策略和堆叠测试访问机制。
- RTL设计阶段:在RTL代码中插入可测性逻辑,包括扫描触发器替换、测试点插入、BIST控制器例化。输出可测性RTL代码和DFT约束文件(如SDC中的test_mode设置)。
- 逻辑综合阶段:综合工具根据DFT约束完成扫描链的映射、优化和连接。输出扫描链网表和扫描链定义文件(如SPF/STIL)。
- DFT验证阶段:使用ATPG工具(如Tessent、Modus)生成测试向量,进行故障仿真验证。输出测试向量集(WGL/STIL格式)、故障覆盖率报告和测试时间估算。
- 物理实现阶段:确保DFT逻辑满足时钟树综合、布线、时序收敛要求。输出DFT物理验证报告和最终测试向量。
- 量产测试阶段:将测试向量加载到ATE执行测试,收集测试数据用于良率分析。输出测试良率报告和失效日志。
实战经验:在3D IC设计中,DFT的介入时间需要更早。由于TSV的物理尺寸和间距限制,测试访问路径的设计必须在堆叠架构确定前完成。建议在项目启动后的第2周内,DFT工程师与3D集成工程师共同完成TSV测试方案评审,明确每个裸片的测试引脚分配和堆叠后的测试调度策略。
2.4 案例拆解:某AI加速芯片的DFT度量权衡
以一款28nm工艺的AI加速芯片为例,该芯片包含4个处理器核、2MB SRAM和大量组合逻辑,总逻辑门数约1200万门。项目初期设定的DFT目标为:Stuck-at故障覆盖率≥98%,测试时间≤15秒,面积开销≤5%。
初始方案与问题:采用传统全扫描设计,共配置8条扫描链,每条链长度约5000个触发器。ATPG生成测试向量约180万条,在50MHz测试时钟下,测试时间计算如下:
测试时间 = 180万向量 × (5000周期 + 1捕获周期) / 50MHz
= 180万 × 5001 / 50,000,000
≈ 180秒
测试时间远超15秒的目标,且故障覆盖率仅达到96.5%,未满足98%的要求。
分析与优化过程:DFT团队进行了三轮优化:
- 第一轮:增加扫描链数量。将扫描链从8条增加到32条,每条链长度缩短至约1250个触发器。测试时间降至约45秒,但故障覆盖率提升至97.2%,仍不达标。
- 第二轮:引入测试压缩技术。采用EDT(Embedded Deterministic Test)压缩,压缩比设为50:1。测试向量数量降至约4万条,测试时间降至约1.2秒,故障覆盖率提升至98.5%。但压缩逻辑引入了约2.5%的面积开销,总面积开销达到6.8%,超出5%的预算。
- 第三轮:优化压缩配置与测试点插入。将压缩比调整为30:1,减少压缩逻辑面积;同时在RTL中插入12个测试点(Test Point),改善难测故障的可控性。最终面积开销降至4.8%,故障覆盖率稳定在98.3%,测试时间约2.5秒。
结果对比与复盘:最终方案在满足所有约束的前提下,实现了98.3%的故障覆盖率、2.5秒的测试时间和4.8%的面积开销。复盘经验表明:测试压缩是解决测试时间瓶颈的最有效手段,但需要与面积开销进行精细权衡;测试点插入对于提升覆盖率边际效果显著,但需要避免过度插入导致面积失控。
常见误区提醒:许多设计团队在项目后期才考虑DFT,导致扫描链插入不完整、测试端口不足、时序收敛困难等问题。DFT必须从架构阶段就纳入设计约束,否则后期返工成本极高。对于3D IC,若未在裸片设计阶段预留TSV测试通道,堆叠后将面临无法访问内部节点的困境,甚至导致整个堆叠芯片不可测。
2.5 总结与设计要点
DFT是连接设计与测试的桥梁,其核心价值在于用可控的面积开销换取可接受的故障覆盖率和测试时间。在实际项目中,DFT工程师需要关注以下要点:
- 早期介入:DFT架构规划必须在RTL冻结前完成,特别是3D IC的TSV测试方案。
- 量化目标驱动:每个项目都应设定明确的FC、TT、AO目标值,并在设计各阶段持续跟踪。
- 工具链协同:综合工具、ATPG工具、物理实现工具之间的数据格式(如STIL、SPF)必须无缝衔接。
- 3D IC特殊考量:TSV测试需要区分预键合(Pre-bond)和后键合(Post-bond)阶段,每个阶段都需要独立的测试访问机制。
- 功耗与热约束:测试模式下的功耗可能比功能模式高2-3倍,需要评估IR Drop对测试可靠性的影响。
DFT不是一项孤立的设计任务,而是需要与前端设计、后端物理实现、测试工程师紧密协作的系统工程。只有将可测试性作为设计的一等公民,才能在量产阶段实现高质量的测试覆盖和可控的测试成本。