尧图网站建设 
做DFT这么多年经常遇到有人把这三个字母和密度泛函理论、离散傅里叶变换搞混。但在芯片设计圈DFT只有一个含义——Design for Test可测试性设计。你流片回来的芯片没法测试或者测试覆盖率不达标产线良率分析一团糟这时候你就明白DFT有多重要了。这篇东西我结合自己做过的项目把DFT设计绪论这个题目拆开揉碎讲清楚从核心原理到实际流程再到UDFM这种统一流程工具链怎么用给刚入行或者准备做DFT的工程师一份能直接上手的参考。这篇文章适合三类人准备做数字IC后端或DFT方向的学生刚接手DFT任务的芯片设计工程师以及想搞清楚测试覆盖率为什么这么低、该怎么优化的验证或产品工程师。1. 内容整体设计与思路拆解1.1 为什么DFT不是可有可无的附加项先说一个让我印象深刻的教训。刚入行那年团队做了一颗MCU芯片功能仿真全过时序收敛也顺利RTL freeze之后直接丢给后端根本没规划DFT。结果晶圆回来ATE测试工程师拿着测试程序跑了三天三夜发现有一半的芯片没法判断好坏——芯片内部没有可控可观测的结构测试向量根本生成不出来只能测管脚上的有限信号内部逻辑完全是个黑盒子。这件事直接导致项目延期两个月额外烧了上百万的测试与筛选成本。从那以后我就明白DFT不是产品经理拍脑袋加的选项而是芯片能不能量产、能不能保证良率的刚需。一颗芯片几百万门甚至上亿门靠物理探针一根根去测内部节点根本不现实唯一可行的办法就是在设计阶段把测试结构提前放进去让芯片自己把内部状态暴露出来这就是DFT存在的全部意义。从本质上看DFT是把测试这个动作从制造后端前移到设计前端。它做的事可以用一句话概括在RTL设计里插入额外的逻辑电路使芯片内部的触发器flip-flop能够被串成扫描链使内存模块能被BIST控制器驱动起来跑自检使芯片外部能够通过标准接口注入测试向量并读出响应。做完这些之后测试机台才能在短短几秒钟内判断一颗芯片的好坏。1.2 核心指标故障覆盖率、测试时间与面积开销的三角博弈做DFT设计你永远绕不开三个指标故障覆盖率fault coverage、测试时间test time和面积开销area overhead。这三个指标互相拉扯设计师的所有工作本质都是在它们之间找平衡点。故障覆盖率指的是所有可能发生的物理故障里测试向量能检测到的比例。行业里的常规目标是stuck-at故障覆盖率做到97%以上transition故障覆盖率做到90%左右。低于这个数芯片出厂后的失效率会明显偏高车规级芯片甚至要求DPPM每百万颗缺陷数控制在个位数这对覆盖率的要求就更苛刻了。但覆盖率不是越高越好的每往上推一个百分点测试向量的数量可能就要翻倍测试时间随之暴涨产线测试成本直线上升。测试时间直接和钱挂钩。ATE测试机台的租金按小时算高端机台一小时几百美金一颗芯片在机台上多待一秒钟摊到百万颗芯片上都是一笔巨款。这也是为什么DFT工程师要想尽办法做测试压缩把一个测试向量同时喂给多条扫描链复用测试激励而不是一条链一条链地串行扫。面积开销也一样DFT逻辑一般会增加5%到10%的芯片面积多了封不住少了覆盖率上不去只能精细化设计。1.3 方案选型结构性测试、BIST和边界扫描怎么搭配DFT方案不是单一技术而是一套组合拳。项目里最常见的搭配是结构性测试scan-based ATPG做主菜BIST和边界扫描做配菜正式流程里三种技术各司其职。结构性测试用于数字逻辑做法是把所有触发器接成扫描链通过ATE输入测试激励、捕获输出响应再交给自动测试向量生成工具ATPG算出覆盖率和向量集。BISTBuild-In Self-Test主要用于存储器测试因为存储器的单元结构规整、故障模式固定用片上生成的伪随机序列反复读写再用特征分析器比对签名不需要外部测试机台就能完成自检。边界扫描Boundary ScanJTAG标准IEEE 1149.1则是板级和芯片级测试的桥梁通过五根专用管脚TCK、TMS、TDI、TDO、TRST把芯片外围的IO寄存器串起来用来测试芯片与PCB之间的连接是否开路短路。选择哪种方案取决于芯片的类型。数字逻辑占比高的SoC扫描链设计是重中之重Flash或SRAM容量大的芯片必须上memory BIST面向板级应用或多芯片模组的芯片JTAG边界扫描必不可少。三类方案可以共存它们共享同一个TAP控制器通过不同的指令来切换测试模式。2. 核心细节解析与实操要点2.1 扫描链设计几万个触发器怎么串成一条龙扫描链是DFT的绝对核心。它的原理是把芯片内所有的时序单元触发器在测试模式下重新配置成移位寄存器链测试向量从链头扫入测试结果从链尾扫出。工作模式有两种shift模式移位状态所有触发器首尾相连和capture模式捕获状态触发器恢复正常功能捕获组合逻辑的响应。实际项目中扫描链的插入远不止把触发器连起来这么简单。首先要考虑的是链长度平衡。比如一个模块有2000个触发器设计成10条链每条链200个触发器那么测试向量的长度就是200拍shift如果有的链300个、有的链100个长链会成为瓶颈测试时间按最长的链计算短的链就得空等。所以scan insertion工具比如业内常用的DFT Compiler在布线时会用算法自动优化链分配尽量让各链长度均衡。还有一个关键点是扫描链的物理布局约束。这一步如果不在综合阶段处理后端布线时就会崩溃。触发器A和触发器B在逻辑上是前后级关系但物理位置可能一个在芯片左上角、一个在右下角连线会绕很远时序也容易出问题。处理方案是在综合阶段把scan chain的物理约束传给布局布线工具让工具优先把同一扫描链上的触发器摆放在相邻区域也就是Fusion compiler之类工具提供的physical-aware scan chain recovery能力。2.2 时钟域与异步复位测试模式下的头号杀手扫描链工作要正常时钟必须可控。functional mode下芯片有多个时钟域PLL分频出来的、外部直接给的、门控时钟分出来的这些时钟如果在测试模式下同时乱跑capture阶段就完全乱套了。所以正统做法是测试模式下所有触发器统一用测试时钟ATPG clock或经过OCCOn-Chip Clocking电路选择的时钟保证扫描移位和捕获动作严格同步。异步复位在DFT里也是个大坑。芯片正常工作时异步复位管脚拉低就能立刻复位所有触发器这没问题。但scan shift阶段如果复位信号毛刺或抖动链上的数据会被瞬间清掉测试向量全报废。解决办法是测试模式下把异步复位信号钳位到无效电平或者通过reset synchronizer统一管理。更彻底的做法是在触发器内部做async reset synchronization让复位信号在测试模式下不直接作用于触发器。我踩过最深的坑是门控时钟。为了降低功耗设计里到处都是clock gating cell。功能模式下这没问题但测试模式下门控信号如果不受控某些触发器的时钟可能会被关断导致scan shift时数据传不过去。所以每个clock gating cell的enable端在测试模式都要被钳住强制时钟永远打开。忘记处理哪怕一个门控时钟DRC检查就会报出一大片violation。2.3 压缩技术一根ATE通道怎么驱动一千条扫描链早期的DFT设计一根ATE通道对应一条扫描链That means测试向量位数等于扫描链数乘以链长度测试时间根本压不下来。后来出现了EDTEmbedded Deterministic Test压缩方案一根ATE通道能同时驱动几百上千条内部扫描链因为内部链非常短每条链几十个触发器整体测试向量长度大幅缩短。EDT的思路是在芯片上内置一个解压器decompressor把ATE送来的压缩数据展开成多路喂给内部扫描链响应端则用一个压缩器compactor把上千条链的响应压缩成几十位输出给ATE对比。解压器和压缩器的结构都是固定的线性反馈移位寄存器网络它们能识别哪些位是无关项X态从而有效压缩数据量。使用压缩技术之后测试时间可以缩短一个数量级这是当前几乎所有先进工艺芯片的标配。但压缩也带来了新的DFT难点。最典型的问题是X态污染。功能逻辑里总有一些节点的值是不确定的比如未初始化的RAM输出这些X值一旦被压缩到响应里会导致整个体内的测试响应不可判定。解决方案是插X-block逻辑在扫描链输出到压缩器之前、以及组合逻辑输出到触发器之前做X态拦截或者用X-tolerant压缩器让压缩算法能够容忍部分X位。2.4 测试向量生成ATPG工具背后的故障模型逻辑ATPG工具是DFT流程里最智能的环节。它的工作方式是先对网表做故障注入列出所有可能的物理故障然后为每个故障生成一个测试向量。这个过程完全靠算法驱动常见的故障模型有三种stuck-at fault固定故障假设某个节点逻辑值固定为0或固定为1不随输入改变。这种模型最简单覆盖率高。transition fault跳变故障假设某个节点的信号变化太慢无法在时钟周期内完成0到1或1到0的跳变用来检测时序相关的延迟故障。path delay fault路径延迟故障检查某一条组合逻辑路径上的总延迟是否超出时钟周期常用于高速接口或关键时序路径的测试。工具生成向量的过程是先做故障仿真fault simulation把每个故障动态地映射到netlist上然后采用D算法、PODEM算法或更先进的面向扫描的算法去自动推导输入激励。运行ATPG时我会重点关注report里各项数据生成的pattern数、fault coverage百分比、未检测故障数。如果覆盖率不达标优先检查是否有未约束的起点、是否有阻塞节点、是否有X态从未处理的锁存器中间传递。3. 实操过程与核心环节实现3.1 从RTL到DFT网表一份完整的DFT Flow路线图一个完整的DFT设计流程通常遵循目前业界主流的统一DFT流程UDFMUnified DFT Flow Methodology这套流程的核心思路是从RTL阶段就开始规划测试结构而不是等综合完成后才补插。UDFM把设计输入、综合、DFT插入、验证和ATPG统一在一个环境里避免了每个阶段来回切换格式和工具导致的适配成本。按照UDFM的思路RTL代码写完之后第一步是跑可测试性分析检查RTL里有没有不可控、不可观测的逻辑结构比如没有复位的锁存器、内部生成的时钟、不受控的三态总线等。第二步是在逻辑综合阶段同时规划扫描链结构工具会生成一个dft_config文件定义扫描链的时钟域、链数量、链长度目标、压缩方案。第三步才是真正的scan insertion把RTL网表转换成带扫描结构的测试网表。第四步做DFT DRC和ATPG确认测试网表符合制造测试要求并生成最终的测试向量集。最后一步走sign-off流程把测试网表和testbench一起交给后端。3.2 DFT规格定义决定成败的第一步动手插入任何DFT逻辑之前先要把规格定义清楚。一份完整的DFT spec至少包含以下内容测试管脚规划TDI、TDO、TCK、TMS等JTAG管脚分配到哪个pad测试模式使能信号test_mode和scan_enable怎么产生是否需要单独的test_rst引脚。扫描链结构规划全芯片要设多少条扫描链每条的时钟域归属是否采用压缩方案如果采用EDT目标压缩比是多少。存储器测试策略所有SRAM、Flash的BIST控制器怎么划分是否共享控制器测试模式下的时钟频率是多少自检完成后结果怎么输出到片外。时钟和复位策略测试模式下芯片时钟如何切换PLL是否旁路异步复位如何处理门控时钟如何强制旁路。覆盖率目标不同故障模型的coverage目标值通常stuck-at97%transition90%。这部分工作必须在写RTL的同时同步进行等到RTL freeze之后再改就太晚了。比如某个IP内部是第三方提供的黑盒可测性结构是否齐备只能提前和IP供应商确认。提前把IP的DFT行为约定好落在spec里后面整个流程才顺。3.3 扫描链插入与DRC检查跑一次完整流程以UDFM流程标准的工具操作来看scan insertion的配置通常在综合脚本里定义。关键命令模式如下逻辑完全可以直接迁移到自己的项目里。set_scan_configuration -chain_count 100 -clock_mixing mix_clocks set_dft_signal -view existing_dft -type ScanClock -port CLK set_dft_signal -view existing_dft -type ScanEnable -port test_mode set_dft_signal -view existing_dft -type ScanIn -port TDI set_dft_signal -view existing_dft -type ScanOut -port TDO insert_dft dft_drc这几行脚本的意思很明确先设定全芯片扫描链数量是100条允许同一扫描链内混用不同的时钟域clock_mixing把CLK管脚指定为测试时钟test_mode指定为scan enable信号TDI和TDO分别是扫描输入和扫描输出。insert_dft执行扫描链的插入dft_drc则跑设计规则检查。跑完DRC之后要仔细看report重点检查这几类问题violation_count非零的模块逐个排查修复未连接的扫描链端口多个时钟域混用后产生的时钟冲突门控时钟模块的使能端没有被测试模式钳住仿真验证这一步也不能漏。工具生成的测试网表要在仿真器里跑一遍带边界扫描的testbench验证scan shift和capture两个阶段的行为都正确。有些工程师只做静态检查不做动态仿真结果流片后测试机台上发现shift失败这种教训我见过不止一次。3.4 ATPG与故障覆盖率分析把覆盖率拉上去的实战手法扫描链正确插入后就该跑ATPG了。这一步的核心命令是ATPG工具如TetraMAX的run流程主要分四步读入门级网表、构建故障模型、执行test pattern generation、生成最终向量文件。实际跑法通常会迭代好几轮。第一轮直接用默认配置跑出来的覆盖率如果低于目标先去报告里看哪一类故障没测到。故障未检测的原因多数是三类X态问题输出端出现X值导致故障不可判定。解决方法是在扫描链输出处加X态拦截器或者把工具配置成ignore X模式。未约束输入某些输入端口在测试模式下是悬空的导致组合逻辑输出不可预测。解决方法是把所有功能输入在测试模式下强制钳位到固定值。阻塞点某些节点的逻辑锥太深或者存在冗余逻辑导致激励无法作用到目标节点。这种只能改RTL或者调整约束。覆盖率调整到目标值之后再做一步非常重要的事生成pattern的同时把测试向量用在故障仿真里做一次全量验证确保向量在实际网表上时序行为正确。这一步通过后把最终的WGL或者STIL格式的向量文件导出交给ATE测试工程师拿去转成机台格式。3.5 多电压域与低功耗设计的DFT处理先进工艺节点下低功耗设计是常态多电压域multi-voltage domain、电源关断power gating和后端电源切换逻辑在DFT里都是大麻烦。测试模式下某些电压域可能被关断扫描链正好穿过两个电压域数据从关断域传到开启域结果会完全不可预测。解决思路有两种。一种是在设计中为DFT专门保留独立的测试供电域测试模式下强制所有电压域都上电测试完成后再恢复低功耗状态。另一种是加电平转换器level shifter和隔离单元isolation cell在电压域交接处做信号转换与钳位。同时跨电压域的扫描链需要被特殊标记工具在链分配时避免跨域串链或者用独立的测试时钟域对隔离。这些约束必须在后端实现之前就和物理设计团队对齐。我见过一个项目DFT工程师没提前告知物理设计团队需要为测试模式的电源保持单独走线结果后端做电源规划时没留出测试用的常开电源域后期只能重新做floorplan整个项目进度毁了三个月。4. 常见问题与排查技巧实录4.1 覆盖率不达标时先查什么覆盖率不达标是DFT项目里最让人头疼的事。根据经验排查顺序建议按下面这张表来能省掉大量找bug的时间。症状常见原因排查命令/操作stuck-at coverage低两个内部三态总线冲突report_buses -unresolvedtransition coverage低门控时钟在测试模式下未钳住report_clock_gating -detail某模块覆盖率极低该模块有未初始化锁存器report_latches -alltest mode下功能跑飞test_mode信号未连接到所有控制点report_signals -unsetDFT DRC报大量violation扫描链上存在组合环report_loops -all排查的第一个动作永远是看DFT DRC报告里面会列出所有违规点。绝大多数覆盖率问题都能追溯到DRC违规只是违规点藏得比较深比如某个小锁存器被CDFG优化掉了导致测试不可控、某个门控逻辑在测试模式被误判为多余逻辑被综合工具优化掉这类问题要开GUI模式的原理图界面慢慢追。4.2 X态传播压缩芯片最头疼的bugX态是DFT压缩的大敌。仿真的时候波形里一个X可能看起来无关紧要但经过压缩器的线性逻辑之后一个X完整的能污染掉一整片响应数据。要解决X态首先在RTL编写阶段就要从源头控制所有latch必须有明确的复位/置位路径所有同步器输出必须加两级FF打拍所有未初始化RAM在测试模式下必须有BIST预处理流程。如果源头上控制不住就在测试结构上加X态拦截电路。典型的方案是在每个扫描链输出端和compactor之间加一个X-masking网络根据工具给出的mask数据把有X的位在响应比对前屏蔽掉。选择X-tolerant的compactor结构也很重要它可以容忍一定比例的X位从而减少mask的配置量。4.3 时钟和复位问题的经典现场现场最常见的报错是clock conflict during capture。功能模式有多个时钟比如AHB总线的HCLK和CPU核的CLK在capture阶段两个时钟如果同时触发跨时钟域路径上的数据会捕获到不确定值。实测下来最有效的处理方式是在每个clock domain的capture时钟路径上加OCC电路用专门的测试时钟发生模块在capture阶段产生单脉冲每个时钟域按顺序被捕获。仿真阶段把所有时钟域的capture窗口错开就能避免跨时钟域数据冲突。复位的问题也类似。我之前处理过一颗chip用异步复位用得很彻底几乎每个触发器都带了ARSTN。扫描插入后跑ATPGcoverage一直卡在85%上不去。最后定位到原因用于扫描链复位钳位的信号没有接到所有复位端有一组触发器的复位端在shift阶段可以直接被scan_in信号影响导致链上数据不稳定。补上复位钳位逻辑之后覆盖率轻松就上了97%。4.4 测试时间优化的几个杠杆测试时间不达标优先从三个方向压增加压缩比。EDT压缩比从10倍提到50倍pattern数量基本不变测试时间能直接缩到五分之一成本是增加了一点压缩器面积。减少pattern数量。工具里可以用动态pattern compaction选项让工具将多个故障的测试向量合并到一个pattern里能压缩15%到30%的pattern数量。降低测试时钟频率要求。有时候测试时间的问题不是因为pattern多而是因为ATE跑测试时钟太慢从50MHz提到100MHz测试时间直接减半。前提是扫描链上的时序满足高速shift的要求这需要后端SDC约束里把test clock的约束做对。4.5 异步FIFO和模拟IP测试策略模拟IP的测试比数字逻辑麻烦得多。PLL、ADC、DAC这类模块没有扫描结构需要在芯片里设计专用的analog test wrapper。常见方案是把模拟IP的输出通过模拟MUX引到测试管脚在ATE上用数字化仪直接测量输出电压或频率同时把模拟IP的配置寄存器连成一条短扫描链方便配置参数。异步FIFO的测试也会让人栽跟头。两个时钟域之间的FIFO读写指针分别由不同时钟驱动扫描链插入时如果直接把两个时钟域的触发器串在一条链上任何跨时钟域的同步路径都会产生亚稳态风险。处理办法是把异步FIFO的读指针触发器和写指针触发器分别插入各自时钟域的扫描链跨时钟域的握手信号在测试模式下直接bypass掉不进行数据传输。5. UDFM与DFT Flow的融合实践5.1 UDFM的核心理念与价值UDFMUnified DFT Flow Methodology不是一个工具而是一套解决DFT和数据孤岛问题的流程方法论。传统的DFT实现里RTL设计、逻辑综合、DFT插入、ATPG、物理实现分别由不同团队使用不同工具完成格式转换、约束传递和数据同步存在大量手工作业任何一个环节出错都要返工。UDFM的核心思路是在同一个设计环境中把RTL分析和修改、约束管理、DFT规则检查、扫描插入和向量生成全部串联起来测试意图在综合阶段就已经被嵌入网表而不是在综合完成后再去修修补补。这样DFT问题就能在设计早期暴露而不是等到sign-off前才手忙脚乱应对。我从实际项目中得到最深的体会是UDFM最大的价值在于约束的一致性。DRC脚本使用的约束和综合工具使用的是同一份SDCconstraint不会再出现两套互相矛盾的情况。早些年综合用一套SDC、DFT用另一套SDC结果scan enable信号在前者里没有约束在后者里被命令强制赋值时序对不上call flow乱得不行。5.2 脚本化与自动化的DFT回归体系UDFM流程要实现效率最大化脚本化必不可少。我的推荐是用Makefile或Tcl脚本把整个DFT flow串起来设好target后一键跑通RTL parse → dft_drc → scan insertion → ATPG → coverage report。这在做大型SoC的时候特别有用因为一个顶层芯片可能要迭代几十个RTL版本手跑一遍至少两三天脚本化之后每次回归只要几个小时。自动化体系里最重要的一个组件是详细的log解析和result汇总工具。ATPG运行之后会不会自动读取coverage数字对比上一次的结果如果覆盖率倒退会不会自动报警测试向量数量异常增多时有没有自动通知将这些信号全部纳入持续集成流水线团队的DFT人效能提升50%以上。启动脚本建议按下面模式组织#!/bin/bash # DFT full flow runner set -e source ./setup.env run_dft_compile run_dft_drc_check run_atpg_patterns -coverage 97 run_fault_sim if [ $? -ne 0 ]; then echo DFT flow failed at pattern simulation exit 1 fi gen_stil_patterns -o output_dir/chip_top.stil这段脚本的核心价值不在命令本身而在set -e和if [ $? -ne 0 ]这两句检查——任何一个环节出错整个flow立刻停下来并给出失败点而不是带着错误继续往下跑否则最后出了无效向量还找不到是哪个环节出的问题。5.3 DFT Flow与后端流程的衔接注意事项DFT完成之后测试网表要交给物理设计团队做布局布线。这条交接线往往是项目delay的重灾区。我的经验是必须提前定义好以下移交资料测试网表test netlist和标准约束SDC文件这份约束要包含所有测试模式下的时钟约束、scan enable约束和复位钳位约束。DFT DRC clean report证明扫描结构正确。测试模式下的功耗预估报告。测试模式往往是全速翻转功耗可能比功能模式高出一倍后端做IR drop分析时必须要用这个数据。扫描链物理约束文件比如某些特定链的触发器摆放区域建议、跨电压域的链隔离要求等。尤其要强调IR drop的问题。高速测试模式下成千上万个触发器同时翻转瞬间电流很大IR drop严重时会导致capture阶段时序不满足测试良率骤降。所以后端设计时必须在测试模式do功耗仿真把电源网络做宽或者在floorplan阶段就预留足够的power strip。DFT工程师要主动push后端做这一步不管他们有多忙不然流片回来coverage再高测试良率也不会好看。6. DFT设计的常见误解与趋势展望6.1 四个容易误导新人的认知偏差第一个误解是DFT就是插扫描链。扫描链只是DFT的一部分真正的DFT还包括BIST、边界扫描、模拟IP测试、良率分析、诊断测试、在线测试等多个维度是个系统性工程。第二个误解是覆盖率越高越好。覆盖率只是手段不是目的客户的真实目标是出厂DPPM满足可靠性要求。覆盖率主要看对故障模型的覆盖率99%的coverage和97%的coverage在实际出货DFT中只要DPPM达标差别不大。反而为了那2%的覆盖率投入的pattern数量和测试时间往往得不偿失。第三个误解是DFT是后端的事。这一点在UDFM流程里尤其不成立。RTL阶段不规划DFT等后端再补救轻则面积增加重则覆盖率达不到甚至需要重新改设计。第四个误解是只要工具能过DRC就没问题。工具不是万能的DRC通过只代表结构没有违规不代表芯片在ATE上能测出良品。流片前一定要做动态仿真、时序分析、低功耗仿真的交叉验证。6.2 从当前趋势看DFT下一步演进先进封装和chiplet成为趋势之后DFT的复杂度又上了一个台阶。多个芯粒die封装在一起每个die都有自己的测试结构die与die之间的互连也需要可测试性设计。标准组织正在推动chiplet测试的标准化目前业界讨论较多的是在UCIe接口标准框架下增加测试功能让整个封装可以作为一个整体来做测试和老化筛选。车规芯片和高可靠性应用领域DFT和功能安全FuSa的结合正在加深。比如ISO 26262要求在芯片运行过程中周期性做LBISTlogic BIST在线自检DFT结构和功能安全诊断逻辑要协同设计这在以前是没有的。这意味着未来的DFT工程师不仅要懂测试结构还要了解安全机制的冗余和故障覆盖率要求。AI芯片和异构计算芯片的崛起也给DFT带来新挑战。大算力芯片里动辄几百个计算核心每个核心都可能有自己的时钟和电源域。DFT设计的关键挑战是如何在不增加太多面积的前提下保持每个核心的高覆盖率同时让所有核心能被并行测试缩短全芯片测试时间。目前比较热的方向是利用芯粒的并行性做分层DFT和并行测试架构。不管技术怎么变DFT的核心目标不会变用最低的成本在最短时间内最大程度地筛选出不良品。这个朴素的目标值得每一个做芯片的人认真对待。 芯片可测试性设计DFT全解析：扫描链、ATPG与UDFM流程
做DFT这么多年经常遇到有人把这三个字母和密度泛函理论、离散傅里叶变换搞混。但在芯片设计圈DFT只有一个含义——Design for Test可测试性设计。你流片回来的芯片没法测试或者测试覆盖率不达标产线良率分析一团糟这时候你就明白DFT有多重要了。这篇东西我结合自己做过的项目把DFT设计绪论这个题目拆开揉碎讲清楚从核心原理到实际流程再到UDFM这种统一流程工具链怎么用给刚入行或者准备做DFT的工程师一份能直接上手的参考。这篇文章适合三类人准备做数字IC后端或DFT方向的学生刚接手DFT任务的芯片设计工程师以及想搞清楚测试覆盖率为什么这么低、该怎么优化的验证或产品工程师。1. 内容整体设计与思路拆解1.1 为什么DFT不是可有可无的附加项先说一个让我印象深刻的教训。刚入行那年团队做了一颗MCU芯片功能仿真全过时序收敛也顺利RTL freeze之后直接丢给后端根本没规划DFT。结果晶圆回来ATE测试工程师拿着测试程序跑了三天三夜发现有一半的芯片没法判断好坏——芯片内部没有可控可观测的结构测试向量根本生成不出来只能测管脚上的有限信号内部逻辑完全是个黑盒子。这件事直接导致项目延期两个月额外烧了上百万的测试与筛选成本。从那以后我就明白DFT不是产品经理拍脑袋加的选项而是芯片能不能量产、能不能保证良率的刚需。一颗芯片几百万门甚至上亿门靠物理探针一根根去测内部节点根本不现实唯一可行的办法就是在设计阶段把测试结构提前放进去让芯片自己把内部状态暴露出来这就是DFT存在的全部意义。从本质上看DFT是把测试这个动作从制造后端前移到设计前端。它做的事可以用一句话概括在RTL设计里插入额外的逻辑电路使芯片内部的触发器flip-flop能够被串成扫描链使内存模块能被BIST控制器驱动起来跑自检使芯片外部能够通过标准接口注入测试向量并读出响应。做完这些之后测试机台才能在短短几秒钟内判断一颗芯片的好坏。1.2 核心指标故障覆盖率、测试时间与面积开销的三角博弈做DFT设计你永远绕不开三个指标故障覆盖率fault coverage、测试时间test time和面积开销area overhead。这三个指标互相拉扯设计师的所有工作本质都是在它们之间找平衡点。故障覆盖率指的是所有可能发生的物理故障里测试向量能检测到的比例。行业里的常规目标是stuck-at故障覆盖率做到97%以上transition故障覆盖率做到90%左右。低于这个数芯片出厂后的失效率会明显偏高车规级芯片甚至要求DPPM每百万颗缺陷数控制在个位数这对覆盖率的要求就更苛刻了。但覆盖率不是越高越好的每往上推一个百分点测试向量的数量可能就要翻倍测试时间随之暴涨产线测试成本直线上升。测试时间直接和钱挂钩。ATE测试机台的租金按小时算高端机台一小时几百美金一颗芯片在机台上多待一秒钟摊到百万颗芯片上都是一笔巨款。这也是为什么DFT工程师要想尽办法做测试压缩把一个测试向量同时喂给多条扫描链复用测试激励而不是一条链一条链地串行扫。面积开销也一样DFT逻辑一般会增加5%到10%的芯片面积多了封不住少了覆盖率上不去只能精细化设计。1.3 方案选型结构性测试、BIST和边界扫描怎么搭配DFT方案不是单一技术而是一套组合拳。项目里最常见的搭配是结构性测试scan-based ATPG做主菜BIST和边界扫描做配菜正式流程里三种技术各司其职。结构性测试用于数字逻辑做法是把所有触发器接成扫描链通过ATE输入测试激励、捕获输出响应再交给自动测试向量生成工具ATPG算出覆盖率和向量集。BISTBuild-In Self-Test主要用于存储器测试因为存储器的单元结构规整、故障模式固定用片上生成的伪随机序列反复读写再用特征分析器比对签名不需要外部测试机台就能完成自检。边界扫描Boundary ScanJTAG标准IEEE 1149.1则是板级和芯片级测试的桥梁通过五根专用管脚TCK、TMS、TDI、TDO、TRST把芯片外围的IO寄存器串起来用来测试芯片与PCB之间的连接是否开路短路。选择哪种方案取决于芯片的类型。数字逻辑占比高的SoC扫描链设计是重中之重Flash或SRAM容量大的芯片必须上memory BIST面向板级应用或多芯片模组的芯片JTAG边界扫描必不可少。三类方案可以共存它们共享同一个TAP控制器通过不同的指令来切换测试模式。2. 核心细节解析与实操要点2.1 扫描链设计几万个触发器怎么串成一条龙扫描链是DFT的绝对核心。它的原理是把芯片内所有的时序单元触发器在测试模式下重新配置成移位寄存器链测试向量从链头扫入测试结果从链尾扫出。工作模式有两种shift模式移位状态所有触发器首尾相连和capture模式捕获状态触发器恢复正常功能捕获组合逻辑的响应。实际项目中扫描链的插入远不止把触发器连起来这么简单。首先要考虑的是链长度平衡。比如一个模块有2000个触发器设计成10条链每条链200个触发器那么测试向量的长度就是200拍shift如果有的链300个、有的链100个长链会成为瓶颈测试时间按最长的链计算短的链就得空等。所以scan insertion工具比如业内常用的DFT Compiler在布线时会用算法自动优化链分配尽量让各链长度均衡。还有一个关键点是扫描链的物理布局约束。这一步如果不在综合阶段处理后端布线时就会崩溃。触发器A和触发器B在逻辑上是前后级关系但物理位置可能一个在芯片左上角、一个在右下角连线会绕很远时序也容易出问题。处理方案是在综合阶段把scan chain的物理约束传给布局布线工具让工具优先把同一扫描链上的触发器摆放在相邻区域也就是Fusion compiler之类工具提供的physical-aware scan chain recovery能力。2.2 时钟域与异步复位测试模式下的头号杀手扫描链工作要正常时钟必须可控。functional mode下芯片有多个时钟域PLL分频出来的、外部直接给的、门控时钟分出来的这些时钟如果在测试模式下同时乱跑capture阶段就完全乱套了。所以正统做法是测试模式下所有触发器统一用测试时钟ATPG clock或经过OCCOn-Chip Clocking电路选择的时钟保证扫描移位和捕获动作严格同步。异步复位在DFT里也是个大坑。芯片正常工作时异步复位管脚拉低就能立刻复位所有触发器这没问题。但scan shift阶段如果复位信号毛刺或抖动链上的数据会被瞬间清掉测试向量全报废。解决办法是测试模式下把异步复位信号钳位到无效电平或者通过reset synchronizer统一管理。更彻底的做法是在触发器内部做async reset synchronization让复位信号在测试模式下不直接作用于触发器。我踩过最深的坑是门控时钟。为了降低功耗设计里到处都是clock gating cell。功能模式下这没问题但测试模式下门控信号如果不受控某些触发器的时钟可能会被关断导致scan shift时数据传不过去。所以每个clock gating cell的enable端在测试模式都要被钳住强制时钟永远打开。忘记处理哪怕一个门控时钟DRC检查就会报出一大片violation。2.3 压缩技术一根ATE通道怎么驱动一千条扫描链早期的DFT设计一根ATE通道对应一条扫描链That means测试向量位数等于扫描链数乘以链长度测试时间根本压不下来。后来出现了EDTEmbedded Deterministic Test压缩方案一根ATE通道能同时驱动几百上千条内部扫描链因为内部链非常短每条链几十个触发器整体测试向量长度大幅缩短。EDT的思路是在芯片上内置一个解压器decompressor把ATE送来的压缩数据展开成多路喂给内部扫描链响应端则用一个压缩器compactor把上千条链的响应压缩成几十位输出给ATE对比。解压器和压缩器的结构都是固定的线性反馈移位寄存器网络它们能识别哪些位是无关项X态从而有效压缩数据量。使用压缩技术之后测试时间可以缩短一个数量级这是当前几乎所有先进工艺芯片的标配。但压缩也带来了新的DFT难点。最典型的问题是X态污染。功能逻辑里总有一些节点的值是不确定的比如未初始化的RAM输出这些X值一旦被压缩到响应里会导致整个体内的测试响应不可判定。解决方案是插X-block逻辑在扫描链输出到压缩器之前、以及组合逻辑输出到触发器之前做X态拦截或者用X-tolerant压缩器让压缩算法能够容忍部分X位。2.4 测试向量生成ATPG工具背后的故障模型逻辑ATPG工具是DFT流程里最智能的环节。它的工作方式是先对网表做故障注入列出所有可能的物理故障然后为每个故障生成一个测试向量。这个过程完全靠算法驱动常见的故障模型有三种stuck-at fault固定故障假设某个节点逻辑值固定为0或固定为1不随输入改变。这种模型最简单覆盖率高。transition fault跳变故障假设某个节点的信号变化太慢无法在时钟周期内完成0到1或1到0的跳变用来检测时序相关的延迟故障。path delay fault路径延迟故障检查某一条组合逻辑路径上的总延迟是否超出时钟周期常用于高速接口或关键时序路径的测试。工具生成向量的过程是先做故障仿真fault simulation把每个故障动态地映射到netlist上然后采用D算法、PODEM算法或更先进的面向扫描的算法去自动推导输入激励。运行ATPG时我会重点关注report里各项数据生成的pattern数、fault coverage百分比、未检测故障数。如果覆盖率不达标优先检查是否有未约束的起点、是否有阻塞节点、是否有X态从未处理的锁存器中间传递。3. 实操过程与核心环节实现3.1 从RTL到DFT网表一份完整的DFT Flow路线图一个完整的DFT设计流程通常遵循目前业界主流的统一DFT流程UDFMUnified DFT Flow Methodology这套流程的核心思路是从RTL阶段就开始规划测试结构而不是等综合完成后才补插。UDFM把设计输入、综合、DFT插入、验证和ATPG统一在一个环境里避免了每个阶段来回切换格式和工具导致的适配成本。按照UDFM的思路RTL代码写完之后第一步是跑可测试性分析检查RTL里有没有不可控、不可观测的逻辑结构比如没有复位的锁存器、内部生成的时钟、不受控的三态总线等。第二步是在逻辑综合阶段同时规划扫描链结构工具会生成一个dft_config文件定义扫描链的时钟域、链数量、链长度目标、压缩方案。第三步才是真正的scan insertion把RTL网表转换成带扫描结构的测试网表。第四步做DFT DRC和ATPG确认测试网表符合制造测试要求并生成最终的测试向量集。最后一步走sign-off流程把测试网表和testbench一起交给后端。3.2 DFT规格定义决定成败的第一步动手插入任何DFT逻辑之前先要把规格定义清楚。一份完整的DFT spec至少包含以下内容测试管脚规划TDI、TDO、TCK、TMS等JTAG管脚分配到哪个pad测试模式使能信号test_mode和scan_enable怎么产生是否需要单独的test_rst引脚。扫描链结构规划全芯片要设多少条扫描链每条的时钟域归属是否采用压缩方案如果采用EDT目标压缩比是多少。存储器测试策略所有SRAM、Flash的BIST控制器怎么划分是否共享控制器测试模式下的时钟频率是多少自检完成后结果怎么输出到片外。时钟和复位策略测试模式下芯片时钟如何切换PLL是否旁路异步复位如何处理门控时钟如何强制旁路。覆盖率目标不同故障模型的coverage目标值通常stuck-at97%transition90%。这部分工作必须在写RTL的同时同步进行等到RTL freeze之后再改就太晚了。比如某个IP内部是第三方提供的黑盒可测性结构是否齐备只能提前和IP供应商确认。提前把IP的DFT行为约定好落在spec里后面整个流程才顺。3.3 扫描链插入与DRC检查跑一次完整流程以UDFM流程标准的工具操作来看scan insertion的配置通常在综合脚本里定义。关键命令模式如下逻辑完全可以直接迁移到自己的项目里。set_scan_configuration -chain_count 100 -clock_mixing mix_clocks set_dft_signal -view existing_dft -type ScanClock -port CLK set_dft_signal -view existing_dft -type ScanEnable -port test_mode set_dft_signal -view existing_dft -type ScanIn -port TDI set_dft_signal -view existing_dft -type ScanOut -port TDO insert_dft dft_drc这几行脚本的意思很明确先设定全芯片扫描链数量是100条允许同一扫描链内混用不同的时钟域clock_mixing把CLK管脚指定为测试时钟test_mode指定为scan enable信号TDI和TDO分别是扫描输入和扫描输出。insert_dft执行扫描链的插入dft_drc则跑设计规则检查。跑完DRC之后要仔细看report重点检查这几类问题violation_count非零的模块逐个排查修复未连接的扫描链端口多个时钟域混用后产生的时钟冲突门控时钟模块的使能端没有被测试模式钳住仿真验证这一步也不能漏。工具生成的测试网表要在仿真器里跑一遍带边界扫描的testbench验证scan shift和capture两个阶段的行为都正确。有些工程师只做静态检查不做动态仿真结果流片后测试机台上发现shift失败这种教训我见过不止一次。3.4 ATPG与故障覆盖率分析把覆盖率拉上去的实战手法扫描链正确插入后就该跑ATPG了。这一步的核心命令是ATPG工具如TetraMAX的run流程主要分四步读入门级网表、构建故障模型、执行test pattern generation、生成最终向量文件。实际跑法通常会迭代好几轮。第一轮直接用默认配置跑出来的覆盖率如果低于目标先去报告里看哪一类故障没测到。故障未检测的原因多数是三类X态问题输出端出现X值导致故障不可判定。解决方法是在扫描链输出处加X态拦截器或者把工具配置成ignore X模式。未约束输入某些输入端口在测试模式下是悬空的导致组合逻辑输出不可预测。解决方法是把所有功能输入在测试模式下强制钳位到固定值。阻塞点某些节点的逻辑锥太深或者存在冗余逻辑导致激励无法作用到目标节点。这种只能改RTL或者调整约束。覆盖率调整到目标值之后再做一步非常重要的事生成pattern的同时把测试向量用在故障仿真里做一次全量验证确保向量在实际网表上时序行为正确。这一步通过后把最终的WGL或者STIL格式的向量文件导出交给ATE测试工程师拿去转成机台格式。3.5 多电压域与低功耗设计的DFT处理先进工艺节点下低功耗设计是常态多电压域multi-voltage domain、电源关断power gating和后端电源切换逻辑在DFT里都是大麻烦。测试模式下某些电压域可能被关断扫描链正好穿过两个电压域数据从关断域传到开启域结果会完全不可预测。解决思路有两种。一种是在设计中为DFT专门保留独立的测试供电域测试模式下强制所有电压域都上电测试完成后再恢复低功耗状态。另一种是加电平转换器level shifter和隔离单元isolation cell在电压域交接处做信号转换与钳位。同时跨电压域的扫描链需要被特殊标记工具在链分配时避免跨域串链或者用独立的测试时钟域对隔离。这些约束必须在后端实现之前就和物理设计团队对齐。我见过一个项目DFT工程师没提前告知物理设计团队需要为测试模式的电源保持单独走线结果后端做电源规划时没留出测试用的常开电源域后期只能重新做floorplan整个项目进度毁了三个月。4. 常见问题与排查技巧实录4.1 覆盖率不达标时先查什么覆盖率不达标是DFT项目里最让人头疼的事。根据经验排查顺序建议按下面这张表来能省掉大量找bug的时间。症状常见原因排查命令/操作stuck-at coverage低两个内部三态总线冲突report_buses -unresolvedtransition coverage低门控时钟在测试模式下未钳住report_clock_gating -detail某模块覆盖率极低该模块有未初始化锁存器report_latches -alltest mode下功能跑飞test_mode信号未连接到所有控制点report_signals -unsetDFT DRC报大量violation扫描链上存在组合环report_loops -all排查的第一个动作永远是看DFT DRC报告里面会列出所有违规点。绝大多数覆盖率问题都能追溯到DRC违规只是违规点藏得比较深比如某个小锁存器被CDFG优化掉了导致测试不可控、某个门控逻辑在测试模式被误判为多余逻辑被综合工具优化掉这类问题要开GUI模式的原理图界面慢慢追。4.2 X态传播压缩芯片最头疼的bugX态是DFT压缩的大敌。仿真的时候波形里一个X可能看起来无关紧要但经过压缩器的线性逻辑之后一个X完整的能污染掉一整片响应数据。要解决X态首先在RTL编写阶段就要从源头控制所有latch必须有明确的复位/置位路径所有同步器输出必须加两级FF打拍所有未初始化RAM在测试模式下必须有BIST预处理流程。如果源头上控制不住就在测试结构上加X态拦截电路。典型的方案是在每个扫描链输出端和compactor之间加一个X-masking网络根据工具给出的mask数据把有X的位在响应比对前屏蔽掉。选择X-tolerant的compactor结构也很重要它可以容忍一定比例的X位从而减少mask的配置量。4.3 时钟和复位问题的经典现场现场最常见的报错是clock conflict during capture。功能模式有多个时钟比如AHB总线的HCLK和CPU核的CLK在capture阶段两个时钟如果同时触发跨时钟域路径上的数据会捕获到不确定值。实测下来最有效的处理方式是在每个clock domain的capture时钟路径上加OCC电路用专门的测试时钟发生模块在capture阶段产生单脉冲每个时钟域按顺序被捕获。仿真阶段把所有时钟域的capture窗口错开就能避免跨时钟域数据冲突。复位的问题也类似。我之前处理过一颗chip用异步复位用得很彻底几乎每个触发器都带了ARSTN。扫描插入后跑ATPGcoverage一直卡在85%上不去。最后定位到原因用于扫描链复位钳位的信号没有接到所有复位端有一组触发器的复位端在shift阶段可以直接被scan_in信号影响导致链上数据不稳定。补上复位钳位逻辑之后覆盖率轻松就上了97%。4.4 测试时间优化的几个杠杆测试时间不达标优先从三个方向压增加压缩比。EDT压缩比从10倍提到50倍pattern数量基本不变测试时间能直接缩到五分之一成本是增加了一点压缩器面积。减少pattern数量。工具里可以用动态pattern compaction选项让工具将多个故障的测试向量合并到一个pattern里能压缩15%到30%的pattern数量。降低测试时钟频率要求。有时候测试时间的问题不是因为pattern多而是因为ATE跑测试时钟太慢从50MHz提到100MHz测试时间直接减半。前提是扫描链上的时序满足高速shift的要求这需要后端SDC约束里把test clock的约束做对。4.5 异步FIFO和模拟IP测试策略模拟IP的测试比数字逻辑麻烦得多。PLL、ADC、DAC这类模块没有扫描结构需要在芯片里设计专用的analog test wrapper。常见方案是把模拟IP的输出通过模拟MUX引到测试管脚在ATE上用数字化仪直接测量输出电压或频率同时把模拟IP的配置寄存器连成一条短扫描链方便配置参数。异步FIFO的测试也会让人栽跟头。两个时钟域之间的FIFO读写指针分别由不同时钟驱动扫描链插入时如果直接把两个时钟域的触发器串在一条链上任何跨时钟域的同步路径都会产生亚稳态风险。处理办法是把异步FIFO的读指针触发器和写指针触发器分别插入各自时钟域的扫描链跨时钟域的握手信号在测试模式下直接bypass掉不进行数据传输。5. UDFM与DFT Flow的融合实践5.1 UDFM的核心理念与价值UDFMUnified DFT Flow Methodology不是一个工具而是一套解决DFT和数据孤岛问题的流程方法论。传统的DFT实现里RTL设计、逻辑综合、DFT插入、ATPG、物理实现分别由不同团队使用不同工具完成格式转换、约束传递和数据同步存在大量手工作业任何一个环节出错都要返工。UDFM的核心思路是在同一个设计环境中把RTL分析和修改、约束管理、DFT规则检查、扫描插入和向量生成全部串联起来测试意图在综合阶段就已经被嵌入网表而不是在综合完成后再去修修补补。这样DFT问题就能在设计早期暴露而不是等到sign-off前才手忙脚乱应对。我从实际项目中得到最深的体会是UDFM最大的价值在于约束的一致性。DRC脚本使用的约束和综合工具使用的是同一份SDCconstraint不会再出现两套互相矛盾的情况。早些年综合用一套SDC、DFT用另一套SDC结果scan enable信号在前者里没有约束在后者里被命令强制赋值时序对不上call flow乱得不行。5.2 脚本化与自动化的DFT回归体系UDFM流程要实现效率最大化脚本化必不可少。我的推荐是用Makefile或Tcl脚本把整个DFT flow串起来设好target后一键跑通RTL parse → dft_drc → scan insertion → ATPG → coverage report。这在做大型SoC的时候特别有用因为一个顶层芯片可能要迭代几十个RTL版本手跑一遍至少两三天脚本化之后每次回归只要几个小时。自动化体系里最重要的一个组件是详细的log解析和result汇总工具。ATPG运行之后会不会自动读取coverage数字对比上一次的结果如果覆盖率倒退会不会自动报警测试向量数量异常增多时有没有自动通知将这些信号全部纳入持续集成流水线团队的DFT人效能提升50%以上。启动脚本建议按下面模式组织#!/bin/bash # DFT full flow runner set -e source ./setup.env run_dft_compile run_dft_drc_check run_atpg_patterns -coverage 97 run_fault_sim if [ $? -ne 0 ]; then echo DFT flow failed at pattern simulation exit 1 fi gen_stil_patterns -o output_dir/chip_top.stil这段脚本的核心价值不在命令本身而在set -e和if [ $? -ne 0 ]这两句检查——任何一个环节出错整个flow立刻停下来并给出失败点而不是带着错误继续往下跑否则最后出了无效向量还找不到是哪个环节出的问题。5.3 DFT Flow与后端流程的衔接注意事项DFT完成之后测试网表要交给物理设计团队做布局布线。这条交接线往往是项目delay的重灾区。我的经验是必须提前定义好以下移交资料测试网表test netlist和标准约束SDC文件这份约束要包含所有测试模式下的时钟约束、scan enable约束和复位钳位约束。DFT DRC clean report证明扫描结构正确。测试模式下的功耗预估报告。测试模式往往是全速翻转功耗可能比功能模式高出一倍后端做IR drop分析时必须要用这个数据。扫描链物理约束文件比如某些特定链的触发器摆放区域建议、跨电压域的链隔离要求等。尤其要强调IR drop的问题。高速测试模式下成千上万个触发器同时翻转瞬间电流很大IR drop严重时会导致capture阶段时序不满足测试良率骤降。所以后端设计时必须在测试模式do功耗仿真把电源网络做宽或者在floorplan阶段就预留足够的power strip。DFT工程师要主动push后端做这一步不管他们有多忙不然流片回来coverage再高测试良率也不会好看。6. DFT设计的常见误解与趋势展望6.1 四个容易误导新人的认知偏差第一个误解是DFT就是插扫描链。扫描链只是DFT的一部分真正的DFT还包括BIST、边界扫描、模拟IP测试、良率分析、诊断测试、在线测试等多个维度是个系统性工程。第二个误解是覆盖率越高越好。覆盖率只是手段不是目的客户的真实目标是出厂DPPM满足可靠性要求。覆盖率主要看对故障模型的覆盖率99%的coverage和97%的coverage在实际出货DFT中只要DPPM达标差别不大。反而为了那2%的覆盖率投入的pattern数量和测试时间往往得不偿失。第三个误解是DFT是后端的事。这一点在UDFM流程里尤其不成立。RTL阶段不规划DFT等后端再补救轻则面积增加重则覆盖率达不到甚至需要重新改设计。第四个误解是只要工具能过DRC就没问题。工具不是万能的DRC通过只代表结构没有违规不代表芯片在ATE上能测出良品。流片前一定要做动态仿真、时序分析、低功耗仿真的交叉验证。6.2 从当前趋势看DFT下一步演进先进封装和chiplet成为趋势之后DFT的复杂度又上了一个台阶。多个芯粒die封装在一起每个die都有自己的测试结构die与die之间的互连也需要可测试性设计。标准组织正在推动chiplet测试的标准化目前业界讨论较多的是在UCIe接口标准框架下增加测试功能让整个封装可以作为一个整体来做测试和老化筛选。车规芯片和高可靠性应用领域DFT和功能安全FuSa的结合正在加深。比如ISO 26262要求在芯片运行过程中周期性做LBISTlogic BIST在线自检DFT结构和功能安全诊断逻辑要协同设计这在以前是没有的。这意味着未来的DFT工程师不仅要懂测试结构还要了解安全机制的冗余和故障覆盖率要求。AI芯片和异构计算芯片的崛起也给DFT带来新挑战。大算力芯片里动辄几百个计算核心每个核心都可能有自己的时钟和电源域。DFT设计的关键挑战是如何在不增加太多面积的前提下保持每个核心的高覆盖率同时让所有核心能被并行测试缩短全芯片测试时间。目前比较热的方向是利用芯粒的并行性做分层DFT和并行测试架构。不管技术怎么变DFT的核心目标不会变用最低的成本在最短时间内最大程度地筛选出不良品。这个朴素的目标值得每一个做芯片的人认真对待。