一、DFT概述与重要性：什么是DFT，为什么需要DFT，DFT在芯片设计流程中的位置

1.1 什么是DFT？——别把它想得太玄乎

DFT，全称是Design for Test，中文叫可测性设计。说白了，就是你在设计芯片的时候，就得提前想好“这玩意儿流片回来怎么测”。

我经常跟刚入行的工程师讲：DFT不是芯片设计完成之后才贴上去的补丁，而是从一开始就要融入设计血液里的基因。你想想看，一颗芯片里可能有几千万甚至几十亿个晶体管，如果某个晶体管坏了，你怎么把它揪出来？靠肉眼？不可能。靠探针？也戳不到。这时候就需要DFT来帮忙。

DFT的核心思想其实很简单：给芯片内部电路装上“传感器”和“开关”。通过特殊的设计结构，让测试设备能从芯片外部控制内部节点、观察内部状态。这样一来，哪怕芯片封装好了，我们也能知道里面到底有没有坏。

1.2 为什么需要DFT？——血的教训

这个问题，我可以用一个亲身经历来回答。

大概十年前，我参与过一个通信芯片项目。那芯片功能设计得漂漂亮亮，仿真也全过了，流片回来一上电——嗯，能跑。但问题来了：良率只有30%。什么意思？就是十颗芯片里只有三颗是好的，剩下七颗全废了。

更惨的是，我们根本不知道坏在哪里。因为设计的时候没做DFT，测试只能测芯片的管脚功能，内部电路完全是个黑盒子。最后只能靠猜，猜哪块电路可能有问题，然后切芯片、用电子显微镜看……折腾了三个月，才找到问题根源——一个很隐蔽的短路。

从那以后，我养成了一个习惯：任何项目，DFT必须从第一天就开始规划。为什么？因为：

• 良率就是钱——一颗芯片的制造成本动辄几十上百美元，良率每提高1%，省下来的钱都是真金白银
• 测试就是命——汽车芯片、医疗芯片、航天芯片，你敢用没测过的吗？
• Debug就是时间——没有DFT，定位一个bug可能要几周；有了DFT，可能只需要几小时

1.3 DFT在芯片设计流程中的位置

很多人以为DFT是后端的事情，其实不是。我习惯把DFT贯穿在整个设计流程中：

从上面的流程图可以看到，DFT不是某个阶段的“专属任务”，而是贯穿始终的。我个人的经验是：

设计阶段	DFT相关活动	我的建议
规格定义	确定测试覆盖率目标、测试模式、测试接口	跟测试团队一起开会，别自己闷头想
架构设计	规划扫描链、BIST、边界扫描等结构	留出足够的测试引脚，别抠门
RTL设计	插入DFT逻辑，编写可测试的代码	写代码时就想着“这地方怎么测”
逻辑综合	优化DFT结构，确保时序满足	别为了省面积牺牲测试覆盖率
DFT插入	扫描链插入、BIST集成、ATPG	这是DFT工程师的主战场
后端实现	布局布线时考虑测试路径	跟后端工程师多沟通，别各干各的
芯片测试	ATE测试、良率分析、故障诊断	测试结果要反馈给设计团队

1.4 DFT的常见方法——三种主流手段

做DFT这么多年，我总结下来，主流的方法就三种：

1. 扫描链（Scan Chain）——把普通的触发器串成链，测试时可以把数据“灌”进去，再把结果“扫”出来。这是最基础、最常用的方法。
2. 内建自测试（BIST）——在芯片内部集成测试电路，让它自己测自己。特别适合存储器、SRAM这类规则结构。
3. 边界扫描（Boundary Scan / JTAG）——在芯片的输入输出管脚上加上测试寄存器，通过JTAG接口控制。板级测试的利器。

1.5 DFT的代价——天下没有免费的午餐

做DFT是要付出代价的，这个我得实话实说：

• 面积开销——通常会增加5%-15%的芯片面积。我见过最夸张的项目，DFT占了20%的面积。
• 性能影响——扫描链上的额外逻辑会引入延迟，可能影响芯片的最高工作频率。
• 设计复杂度——多了DFT逻辑，验证工作量会增加，时序收敛也更麻烦。
• 功耗增加——测试模式下的功耗往往比正常模式高，散热是个问题。

但是，你想想看：一颗芯片流片成本动辄几百万美元，如果因为没做DFT导致良率低、debug困难，那损失可比DFT的代价大多了。我见过太多项目因为省了DFT那点面积，最后赔了夫人又折兵。

1.6 总结——DFT不是选择题，是必答题

说了这么多，其实就一句话：DFT是现代芯片设计不可或缺的一环。它不是锦上添花，而是雪中送炭。从规格定义到芯片测试，DFT贯穿始终。

我个人习惯，每个项目开始前都会问三个问题：

1. 这颗芯片的测试覆盖率目标是多少？
2. 测试方案是什么？扫描链？BIST？还是组合？
3. 测试团队什么时候介入？

这三个问题想清楚了，DFT的框架也就搭好了。剩下的，就是一步步去实现。

---

公众号:蓝海资料掘金营，微信deep3321