1. DFT 概述：可测性设计到底是什么？

大家好，我是你们的 DFT 讲师。在芯片行业摸爬滚打了十几年，我见过太多「流片回来没法测」的惨案。今天咱们就从最基础的问题聊起——可测性设计，简称 DFT。

说白了，DFT 就是在设计阶段就给芯片装上「测试接口」。你想想看，一颗芯片几亿个晶体管，封装之后只有几十个引脚露在外面。你怎么知道里面每个管子都工作正常？靠的就是 DFT 加进去的那些额外电路。

1.1 为什么需要可测性设计？

我刚开始做设计时，总觉得 DFT 是「额外负担」。直到有一次，一颗 28nm 的芯片流片回来，功能仿真全过，但量产测试良率只有 30%。查了三个月，最后发现是某个扫描链的时钟门控逻辑有 bug——如果当初没加 DFT，这颗芯片就彻底废了。

没有 DFT 的芯片，就像一本没有目录的书。你只能从头翻到尾，而且翻到中间发现缺页了，你都不知道缺在哪里。

• 制造缺陷不可避免：晶圆上的颗粒污染、光刻对准偏差、金属桥接，这些物理缺陷在纳米工艺下是常态
• 测试成本占比越来越高：一颗 7nm 芯片的测试成本可能占到总成本的 30%-40%
• 功能测试不够用：跑一遍完整的应用软件可能需要几小时，而 DFT 测试只需几秒钟

1.2 DFT 在芯片开发流程中的位置

很多新人会问：DFT 是前端还是后端？我的回答是：DFT 贯穿整个流程。它既不是前端也不是后端，它是「夹在中间但哪都离不开」的角色。

从这张图你能看到，DFT 工程师在每个关键节点都要介入。我个人习惯把 DFT 工作分成三个阶段：

1. 设计阶段（规格→综合）：确定测试策略，插入扫描链、BIST、边界扫描等结构
2. 验证阶段（综合后→流片前）：跑 ATPG 生成测试向量，做仿真验证，检查覆盖率
3. 量产阶段（流片后→量产）：配合测试工程师调试 ATE 程序，分析良率，定位失效

1.3 DFT 工程师的核心职责

很多人以为 DFT 工程师就是「跑跑 ATPG 工具」。其实远不止这些。我列一下日常工作中最核心的几块：

职责领域	具体工作内容	常用工具/方法
测试策略制定	根据芯片规模、功耗、成本目标，选择扫描/BIST/MBIST 等方案	DFT Compiler, Tessent
DFT 逻辑实现	插入扫描链、时钟门控、测试模式控制逻辑	Synopsys DFT Compiler, Cadence Genus
ATPG 与仿真	生成测试向量，做故障仿真，分析覆盖率	TetraMAX, FastScan, TestKompress
DFT 验证	形式验证、时序检查、功耗分析	Formality, PrimeTime, RedHawk
ATE 支持	生成测试程序，配合测试工程师调试	STIL, WGL, ATE 平台
良率分析	分析测试失效数据，定位物理缺陷	Yield Explorer, 扫描链诊断

嗯，这里要注意一点：DFT 工程师是「翻译官」。你要把设计工程师的 RTL 语言，翻译成测试工程师能用的 ATE 程序。同时还要把测试发现的失效，翻译回设计工程师能理解的电路位置。

1.4 一个典型的 DFT 工作流

最后，我给大家画一个更具体的 DFT 工作流。这个流程我在多个项目中验证过，基本覆盖了 90% 的场景：

这个流程看起来简单，但每个环节都有坑。举个例子，覆盖率检查——你以为跑到 98% 就万事大吉了？我曾经遇到过一个案例，覆盖率 99.2%，但量产良率只有 60%。后来发现是时序相关的故障没被覆盖到。所以 DFT 工程师不能只看数字，要理解每个故障模型背后的物理意义。