最近这几年芯片设计行业对DFTDesign for Test可测试性设计相关岗位的需求涨得很快但真正能把DFT讲明白的资料却不多。不少前端设计和验证的同学对DFT的印象还停留在“综合之后插一条scan chain”这个层面而很多刚转DFT的工程师面对Tessent、DFTCompiler这些工具和满屏的覆盖率报告也常常一头雾水。这篇博文我就从设计者的视角把DFT这摊事从头到尾捋一遍它到底是什么、为什么要做、完整流程长什么样、常见的坑有哪些。不管你是刚入行的工程师、还在读书的学生还是想了解芯片是怎么被“测试”出来的硬件爱好者这篇文章都能帮你建立一张清晰的地图。1. DFT不是在“测芯片”而是在“设计可测试性”很多人第一次接触DFT会把它理解成“测试芯片的工作”其实这是个误区。DFT严格来说是设计环节的一部分它的核心目标是在芯片还在设计阶段的时候就提前为后续的制造测试铺好路。换句话说DFT工程师交付的不是测试程序而是一个“容易被测试的芯片设计”。1.1 为什么芯片需要“专门设计”才能测芯片制造完成之后晶圆上会有成千上万颗die。制造工艺再成熟也难免出现金属连线的短路、断路晶体管的阈值电压漂移或者氧化层缺陷这类物理故障。一颗芯片要能可靠地出厂必须经过测试筛选问题在于芯片内部几百上千万个触发器、几十万条net你不可能用探针一个个去量。这时候就需要DFT登场了。它的核心思想很简单在芯片内部额外增加一些测试用的结构和逻辑让测试设备ATE自动测试设备能够从外部通过有限的引脚对芯片内部的每一个逻辑节点进行“观察”和“控制”。观察就是能读出某个节点的状态控制就是能把某个节点强行设置成指定电平。这两个能力一旦具备测试芯片内部的所有逻辑节点就变成了可能。这里有个很关键的概念叫“可观测性”和“可控制性”。没有DFT的芯片内部节点对测试机来说就是一个黑盒子只能通过功能引脚看最终输出内部任何一个门出了问题都可能被其他逻辑掩盖。而有了DFT结构内部节点的状态可以被间接“搬”到外部引脚上测试人员就可以像做B超一样把芯片内部的健康状况看得一清二楚。1.2 DFT的典型结构扫描链、BIST、Boundary ScanDFT并不是单一技术而是一组技术的集合。在数字逻辑测试领域最核心、最普及的是扫描链Scan Chain技术。它的原理是把芯片里所有普通触发器替换成带有测试端口的扫描触发器然后在测试模式下把这些触发器串联成一条或者多条移位寄存器链。测试时测试向量通过移位的方式灌入扫描链把内部状态设置好再切回功能模式打一拍最后再把结果移位出来跟预期值比对。除了扫描链DFT还包括内建自测试BIST它一般用于存储器如SRAM、DRAM测试原理是在芯片内部自己生成测试向量、自己压缩响应、自己判断对错不依赖外部ATE提供大量的测试向量还包括边界扫描Boundary Scan即JTAG它主要用于板级测试在芯片的每个IO引脚旁边加一个边界单元串联成链这样电路板上的芯片之间就可以通过标准JTAG接口来测试引脚连线的焊接是否正常。我个人的理解是DFT的本质是一种“设计冗余”——用面积、功耗和性能上不可避免的一点点牺牲换取制造之后的可测试性。这个取舍从商业角度看是完全划算的因为一颗不能被有效测试的芯片哪怕设计得再完美也无法以合理的良率成本走向市场。2. 扫描链和ATPGDFT大厦的两块基石扫描链是DFT的骨架ATPGAutomatic Test Pattern Generation自动测试向量生成则是DFT的灵魂。前者解决的是“怎么把状态搬出来”的问题后者解决的是“搬什么数据进去才能测出故障”的问题。这两者相辅相成缺一不可。2.1 扫描链工作原理解析把普通D触发器替换成扫描触发器通常叫muxed-D触发器之后触发器多了一个测试输入端口SI和一个测试使能端口SE。当SE为高电平时触发器的输入被切换到SI多个触发器首尾相连就形成了一个移位寄存器当SE为低电平时触发器恢复正常的D端输入芯片工作在功能模式。测试一条扫描链的基本流程可以概括为三步第一步把SE拉高进入移位模式将要施加的测试向量逐周期从扫描输入引脚scan_in灌入这个阶段就像往一条水管里注水第二步拉低SE进入捕获模式发一个或者多个功能时钟脉冲让组合逻辑在给定输入下计算出结果并把结果锁存到触发器里第三步再拉高SE进入移位模式把锁存的结果从scan_out引脚逐位移出来与预期的响应做比对如果发现不一致就说明该向量检测到了故障。这个流程听起来简单但真正实施起来有很多讲究。比如捕获模式的时钟数怎么选如果只打一拍那测的是组合逻辑的即时故障如果要测时序相关的故障比如transition fault就需要连续打两拍第一拍在触发器端建立一个跳变第二拍捕获跳变的传播结果。这也就是常说的“at-speed测试”的基础它要求在捕获模式下使用真实的功能时钟频率而不是低速的测试时钟。这一套操作下来需要DFT工程师在时钟控制、使能控制上有非常精细的设计。2.2 ATPG的故障模型和覆盖率逻辑ATPG工具比如Synopsys的Tessent、Siemens的Modus做的事情就是根据网表和故障模型自动生成一组测试向量。为什么不能直接随机灌向量因为随机向量能测到的故障非常有限覆盖率上不去。工程师们基于对物理故障的研究抽象出了一系列“故障模型”最经典的是固定故障Stuck-At FaultSAF它假设某条信号线固定为逻辑0或逻辑1。一个门电路有四个引脚每个引脚可能stuck-at-0或者stuck-at-1总共就有8个故障点。ATPG工具按照故障模型把网表里所有的故障点都列出来然后逐个分析用一个测试向量让故障点的正常值跟故障值产生差异并且把这个差异传播到某个可观察的扫描触发器上。这个向量就算“检测”到了这个故障。所有被检测到的故障数除以总故障数就是测试覆盖率Test Coverage。这里要注意覆盖率永远不可能是100%因为网表里有些节点是冗余逻辑或者有些故障本身不可观察覆盖率能做到95%~99%已经是非常优秀的水平。transition fault是另一种常用的故障模型它假设信号在时钟沿附近的变化太慢导致在捕获时采到了错误的值。测transition fault需要两个连续的时钟沿来“启动”和“捕获”一个跳变所以对时序控制的要求比stuck-at更高。这也是DFT flow中对时钟设计最挑剔的部分之一。3. 一个完整的DFT flow长什么样DFT的落地不是一个单点动作而是一条贯穿整个芯片设计流程的链路。从最开始的规格定义到RTL freeze到综合再到物理实现和流片前的signoffDFT工作在每个阶段都有不同的侧重点。理解这个flow你就知道DFT工程师和前端、后端、验证、封测团队之间要怎么协作。3.1 DFT Flow分阶段拆解第一阶段是DFT架构规划一般在芯片架构阶段就要启动。这个阶段要决定的事情包括采用全扫描还是部分扫描架构、扫描链条数和长度的分配、是否使用扫描压缩scan compression、哪些存储器用BIST、哪些IO需要boundary scan、测试时钟和测试复位怎么接、是否需要支持多种测试模式比如stuck-at模式、at-speed模式、memory BIST模式。这些决定会直接影响芯片的面积开销、测试时间、引脚占用还有后续物理实现的难度。第二阶段是RTL级别的DFT设计。DFT工程师要在RTL freeze之前把DFT相关的RTL代码写进去比如clock mux、reset mux、test mode控制信号、scan chain的连接声明、BIST controller和wrapper逻辑等。有些团队用工具自动插入有些团队手工写RTL但无论哪种方式都要保证在功能模式下这些额外的逻辑完全透明不影响正常功能。这里最怕的就是test mode信号在功能模式下受到干扰导致芯片在功能模式下也被强制切到了测试路径。第三阶段是综合后的scan insertion。综合工具比如Design Compiler或者Fusion Compiler在完成逻辑综合之后会把普通的DFF替换成扫描DFF然后按照你定义的规则把扫描链串起来。这个阶段要处理很多物理层面的问题比如链上触发器的物理位置、时钟树的平衡、congestion拥塞控制。因为scan chain本质上是在布线如果串链时完全不考虑物理位置两条相距很远的触发器被串在同一链上后端布线时就会绕很远的路既浪费走线资源又影响时序收敛。第四阶段是ATPG和仿真验证。scan insertion完成之后DTF工程师会跑一遍ATPG生成测试向量然后在仿真环境里跑仿真验证确保这些测试向量在仿真模型上是可以通过的否则就是DFT逻辑本身有问题。仿真验证通过之后测试向量会交给封测厂做ATE测试时的pattern。第五阶段是DFT signoff。在流片之前要确认所有的覆盖率指标达标、时序分析STA对测试模式也做了必要的检查、物理实现上没有DRC违例。这一关不通过芯片是绝对不能流片的否则回来一堆测不了的芯片整个项目就白干了。3.2 扫描压缩技术用更少的时间测更多的链早期的DFT设计每根扫描链对应一个scan_in和scan_out引脚芯片有多少根链就要占用多少引脚。随着设计规模越来越大引脚数成了瓶颈而且测试数据量也越来越大ATE的存储深度和测试时间双双告急。这时候扫描压缩scan compression技术就派上了用场。扫描压缩的原理是在芯片内部加一个解压缩器decompressor和压缩器compressor。外部ATE只需要提供很少的几根scan_in通道比如8根经过解压缩器展开成内部几十上百根内部扫描链测试响应从内部扫描链出来之后经过压缩器再压回少量scan_out通道返回到ATE。这样在ATE看来芯片的扫描链数量很少测的时间和数据量大大降低但内部逻辑的覆盖率却不受影响。这里有个关键问题压缩器不能是无损的它会把几百根的内部响应压成几根输出必须有办法通过数学方法还原出哪根链出了问题。所以压缩器的设计通常基于线性空间压缩的原理采用X-tolerant的架构能够容忍一定数量的未知态X态通过。这也是为什么DFT工程师要花大量精力处理X态源的原因——memory的输出、PLL锁定信号、未初始化的寄存器这些在测试模式下都可能产生X态如果X态进入了压缩器会污染整个响应比对。4. 可测性设计中的UDFM等高级话题标准的DFT flow已经能覆盖绝大多数数字逻辑的测试需求但实际芯片里总有那么一些“不听话”的电路用标准故障模型测不到或者覆盖率很难看。这时候就要引入更灵活的机制比如UDFMUser-Defined Fault Model用户自定义故障模型。这是Tessent工具里非常强大的一个功能也是DFT工程师进阶路上绕不开的知识点。4.1 UDFM是什么什么时候要用它UDFM的思路其实很直接标准故障模型stuck-at、transition是工具内置好的对于常规逻辑门电路非常有效。但芯片里有一些特殊的结构它们的失效行为并不能很好地用“某根线卡在0或1”来建模。比如说两根相邻的金属线之间发生了桥接bridging故障表现是两根线的逻辑值互相影响再比如某个模拟IP的数字控制接口在特定配置组合下才会失效又或者是某些定制的大容量memory内部有自己特有的缺陷模式。遇到这些情况默认的ATPG模型就无能为力了。UDFM允许你通过配置文件自己定义故障的行为模型——你可以声明两个节点之间的桥接故障、可以定义特定逻辑功能块的故障行为、也可以把多根线的特定逻辑组合定义为一个故障事件。定义好之后ATPG工具就能按照你定义的规则去生成测试向量并统计覆盖率。不过这并不意味着UDFM是万能的。它本质上要求你对电路的真实失效机理有相当深入的理解而且定义得不好会产生大量无效向量拖慢收敛速度。在实际项目中UDFM更多是作为标准DFT flow的补充手段用在那些覆盖率确实顶不上去的特殊模块上而不是一开始就引入。4.2 低功耗设计与DFT的协同挑战近几年芯片设计越来越强调低功耗电源关断power gating、多电压域multi-voltage domain、动态电压频率调节DVFS几乎成了SoC的标配。这些低功耗特性给DFT带来了巨大的挑战因为测试模式下芯片往往不是所有电源域都是打开的。比如某些逻辑在被测试时可能处于关断状态而这些逻辑的触发器在被重新唤醒时需要初始化到确定状态否则仿真模型里就会出现大量X态直接拖垮压缩器的有效性。处理办法之一是为每个电源域增加隔离单元isolation cell和复位保持逻辑在测试模式下统一管理电源域的开关时序。另外一个常见做法是采用“测试模式电源策略”——在测试模式下将全部电源域打开宁可多耗一些功耗也要保证DFT逻辑的可控性和覆盖率。这个决策需要DFT工程师和低功耗架构师反复拉通两边都要妥协一点才能取得平衡。5. 常见问题与实操避坑笔记最后这部分我整理了一些自己在实际项目中踩过的坑和排过的雷。DFT这个东西很多问题在一开始看起来都是“莫名其妙的覆盖率损失”或“仿真跑不过”但追根溯源之后原因往往并不复杂。5.1 X态问题覆盖率杀手第一名X态是DFT工程师职业生涯里绕不开的敌人。所谓X态就是仿真中信号的未知状态。在芯片正常工作里X态可能只会让人心烦但在DFT测试中X态是致命的如果一个X态在捕获模式下打进了扫描触发器然后通过压缩器传播出来整个比对逻辑就会被污染导致一个完全没有故障的芯片被判定为坏片或者掩盖掉真正的故障。X态的来源有很多没有被复位的存储器、上电时序未确定的锁存器latch、PLL的锁定指示信号、模拟IP的数字输出、跨时钟域同步器的第一级寄存器等。排查X态问题的标准动作是打开ATPG工具的报告找到X态的唯一传播路径然后顺着路径往回查看源头在哪里再针对性加约束或修改设计。如果是不可避免的X源就要在压缩器端设置X-masking把这些位屏蔽掉。我的经验是X态问题越早发现越好最好在RTL阶段就做X态仿真分析不要等到ATPG之后否则改起来成本高得多。5.2 复位和时钟测试模式下的两大命门时钟和复位是芯片正常工作的命脉在测试模式下更是如此。先说时钟扫描链移位时用的是测试时钟捕获时用的是功能时钟。这两个时钟之间如何切换、是否存在毛刺、切换时序是否满足触发器建立保持时间的要求都是必须通过专门仿真和STA检查验证的。我见过一个项目因为测试时钟和功能时钟的切换逻辑没有做glitch-free处理导致部分触发器在切换瞬间被毛刺打到了错误状态整条链的测试结果完全不可用。复位的问题同样棘手。扫描链移位模式下如果复位信号不受控地抖动扫描链里的数据就会被打乱。标准的做法是在测试模式下把复位信号强制拉成无效状态对高有效复位来说是拉低并增加test_reset信号来管理测试逻辑的初始化。这样既保证了移位模式下的稳定性又能在进入某个测试向量之前通过test_reset把所有测试相关的逻辑恢复到已知状态。5.3 覆盖率上不去的排查思路覆盖率不达标是项目后期最让人头疼的事。通常排查先从简单的开始先看是不是有大量时钟门控单元clock gating cell的使能信号不可控制导致某些触发器在捕获模式下没有时钟沿再看是不是有异步复位/置位信号在测试模式下来回翻转然后看有没有三态总线的冲突或者双向IO在测试模式下配置成了高阻导致逻辑悬空。如果这些常规检查都没有问题再考虑结构性的问题是否有些逻辑本身是冗余的属于不可测逻辑是否某些跨时钟域的逻辑没有加同步器导致亚稳态传播成X态是否某些带时钟门的寄存器需要额外的测试点test point来增强可控性和可观测性。插入测试点是DFT工程师的“终极武器”它本质上是在电路中额外加一些可控/可观逻辑把覆盖率再往上顶一顶但代价是面积和功耗的增加所以不宜滥用。从我个人经验来看DFT这个方向入门门槛说高不高、说低不低。高是因为它要求你同时懂RTL设计、时序分析、ASIC流程甚至还要了解一点半导体工艺和测试设备的知识低是因为它一旦形成体系规律性很强只要把flow跑顺遇到的问题大多有套路可循。如果你正在打算进入这个方向我建议先把手头设计的scan chain手工捋一遍搞清楚每个信号在测试模式下到底被谁驱动然后去读一读Tessent和DFTCompiler的fault model文档再找一个真实的模块把ATPG的flow完整跑一遍。踩过几个坑之后你对DFT的理解自然就能从“听说过”变成“真的懂”。