摘要提到 DFTDesign for Test很多工程师首先想到 Scan Chain、ATPG、MBIST、Test Compression或者一组用于插入和验证测试逻辑的 EDA 命令。但对大型 SoC 来说真正的问题远不止“插入测试逻辑并生成测试向量”而是如何让一个包含大量逻辑状态、时钟域、电源域、Memory、IP 和层次化模块的设计在制造完成后仍然能够以可控制、可观察、可访问、可诊断、可量产的方式被测试。现代 DFT 因而不是一个孤立的 implementation step而是一条横跨 RTL、综合、DFT insertion、形式验证、STA、APR、ATPG、仿真、ATE 与 silicon diagnosis 的工程链。本文从系统工程视角回答三个问题DFT 的第一性问题是什么为什么现代 SoC DFT 会演化成跨流程工程系统为什么 DFT 自动化最终必须走向可复现、可观察、可验证和可诊断的闭环0. DFT 真正解决的不是“有没有 Scan”在 RTL 仿真环境中我们可以方便地观察内部信号、初始化状态、施加激励并检查设计行为。但芯片制造完成后工程师面对的是一颗物理器件内部可能有数百万甚至更多状态节点而封装后能够直接访问的外部引脚数量非常有限。这形成了测试领域最基本的矛盾芯片内部 ├─ 海量寄存器与状态节点 ├─ 海量组合逻辑路径 ├─ 多个 Clock Domain ├─ 多个 Power Domain ├─ 大量 Memory / IP └─ 层次化设计结构 ↓ 芯片外部 ├─ 有限 I/O Pin ├─ 有限 Tester Channel ├─ 有限 Tester Memory ├─ 有限测试时间 └─ 有限功耗预算DFT 首先解决三个基本问题核心问题含义典型技术Controllability能否把内部逻辑设置到需要的测试状态Scan、Test Control、Clock ControlObservability内部错误是否能传播到可观察位置Scan、Compactor、Observation PointTest Access测试数据如何进入、结果如何输出Scan I/O、Compression、Wrapper、Test BusScan、Compression、Test Point、MBIST、Boundary Test、Embedded Instrument 等技术本质上都围绕这三个目标展开。但现代 SoC 又增加了大量新的约束多时钟、多电压域、低功耗结构、Memory、复杂 IP、层次化实现、片上时钟控制、物理布局以及量产测试成本。因此问题已经从怎样把寄存器连成 Scan Chain演化为怎样建立一个能够在真实芯片上稳定工作 同时满足覆盖率、测试时间、功耗、时序、 物理实现和量产约束的完整测试系统F01 – Modern SoC DFT Engineering Landscape1. 第一性问题让内部状态变得可测试1.1 为什么正常功能路径不足以完成制造测试对于普通时序逻辑如果希望检测某个内部故障首先要把相关寄存器驱动到特定状态再让故障被激活并传播到可观察输出。Primary Input │ ▼ Combinational Logic │ ▼ FF1 │ ▼ Combinational Logic │ ▼ FF2 │ ▼ Combinational Logic │ ▼ Primary Output在 functional mode 下这个过程可能需要很多时钟周期而且内部状态不容易直接控制和观察。Scan 的核心作用是把原本分散在芯片内部的寄存器转换为可访问测试状态Functional Mode D ─────► FF ─────► Q Scan Mode Scan In ─► Scan FF ─► Scan FF ─► Scan FF ─► Scan Out典型测试过程因此变为Shift In ↓ 设置内部状态 ↓ Capture ↓ 让组合逻辑响应测试条件 ↓ Shift Out ↓ 观察结果从系统角度看Scan 不是终点而是一套内部状态访问基础设施。1.2 ATPG 依赖的是“可测试结构”ATPGAutomatic Test Pattern Generation通常需要完成三个步骤Fault Activation ↓ Fault Propagation ↓ Fault Observation如果某个故障无法被控制条件激活或者故障效应无法传播到可观察点那么 ATPG 算法本身再强也无法凭空创造测试通路。因此逻辑关系更接近DFT Architecture ↓ Testability ↓ ATPG Efficiency ↓ Fault Coverage而不是Powerful ATPG Tool ↓ Automatically Solves Everything1.3 Memory 是另一类测试对象Memory 的测试方式与普通随机逻辑不同。大型 SoC 中 SRAM、ROM、Register File 等 Memory 宏数量可能非常大如果完全依赖普通 Scan Logic ATPG测试成本通常不可接受。于是形成专用 MBIST 路径Memory Array ↓ MBIST Controller ↓ Test Algorithm ↓ Read / Write / Compare ↓ Pass / Fail复杂产品还可能继续加入 Repair Analysis、Redundancy Control 与 Fuse Programming。因此一个完整 SoC 的测试架构往往同时存在多条路径测试对象主要机制主要目标Random LogicScan ATPG检测逻辑与互连故障MemoryMBIST检测 Memory FaultHigh-speed LogicAt-speed ATPG / OCC检测时序相关故障Embedded IPWrapper / Instrument Access访问 IP 内部测试资源Board / Package InterfaceBoundary Scan 等外部互连与接口测试2. 为什么现代 SoC DFT 会迅速变复杂2.1 规模增长直接推高测试数据量如果 Scan Cell 数量持续增加而外部 Scan Channel 数量不变Scan Cell Count ↑ Channel Count 不变 ↓ Average Chain Length ↑ ↓ Shift Cycle ↑ ↓ Test Time ↑为了控制测试时间需要增加并行度、使用 Compression、重新规划 Scan Architecture但这些又受到 I/O 数量、Tester Channel 和功耗预算限制。DFT 因而成为典型的多目标工程问题指标希望方向主要约束Fault Coverage越高越好Testability、X Source、结构限制Pattern Count越少越好Coverage、Compression 能力Test Time越短越好Channel、Shift Cycle、FrequencyTest Power越低越好Capture Activity、IR DropArea Overhead越低越好Compression、Test Point、ControllerPhysical Cost越低越好Placement、Routing、Congestion没有一个指标可以脱离其他指标单独最大化。2.2 Clock Domain 让 Scan 不再是一条简单链现代 SoC 往往包含多个功能时钟和测试时钟。Scan Chain 一旦跨越不同 Clock Domain就需要额外考虑 shift edge、skew、capture sequence、OCC、lockup 等问题。Clock Domain A FF ─► FF ─► FF │ ▼ Lockup / Boundary │ ▼ FF ─► FF ─► FF Clock Domain B逻辑连接正确并不代表测试时序一定正确。2.3 Power Domain 进一步限制测试结构多电压和低功耗设计要求 DFT 同时理解测试模式下哪些 Power Domain 打开Isolation 是否生效或被覆盖Retention Cell 如何处理Scan Path 是否跨 Voltage BoundaryLevel Shifter 是否满足测试模式Power Switch 如何被控制。因此Power Intent 本身就是 DFT 工程输入的一部分。2.4 Memory、IP 与 Hierarchy 改变了访问方式大型 SoC 通常不能按 flat design 思路处理所有对象。常见组织方式是Block ↓ Subsystem ↓ Top ↓ ChipBlock-level 已完成的 Scan、Compression、MBIST 和 Instrument需要在 Top-level 重新集成。这意味着 DFT 同时承担层次之间的接口 Contract 管理Block Test Port Clock Interface Wrapper Compression Interface Memory Test Access Configuration Pattern Reuse Top-level StitchingF02 – DFT Complexity Sources]3. 一个完整 DFT Flow 实际在解决七类工程问题把大量具体命令、脚本和报告抽象掉实际 DFT 工作可以归纳为七类问题。#工程问题关键问题典型输出1Architecture芯片准备怎样被测试Scan/Compression/Clock/MBIST 架构2Structural CorrectnessDFT 结构是否完整、合法DFT Check、Chain Check、Rule Report3TestabilityFault 能否被检测Coverage、Fault Classification4Test CostPattern 和 Test Time 是否可接受Pattern Count、Shift Cycle、Test Time5Test PowerShift/Capture 功耗是否安全Power Constraint、Activity Control6Physical FeasibilityDFT 结构物理上是否合理Scan Reorder、Physical Feedback7Silicon TestPattern 能否真正用于 ATE 和芯片Tester Pattern、Silicon Result、Diagnosis3.1 Architecture测试系统怎么组织首先要回答哪些寄存器进入 Scan 需要多少 Scan Channel 是否使用 Compression Test Clock 如何产生 Capture Clock 如何控制 Memory 如何组织 MBIST Block 如何向 Top 暴露 Test Interface这一步决定后续很多指标的上限。3.2 Structural Correctness结构是否真的成立Insertion 成功不代表结构正确。仍然需要检查Scan Chain Continuity Scan Clock Legality Scan Enable Connectivity Test Mode Control Compression Connectivity Memory Test Connectivity Clock-domain Crossing这里必须区分两个概念Command Success ≠ Engineering Success工具正常退出只说明程序没有异常结束它并不自动意味着测试结构满足工程目标。3.3 TestabilityCoverage 数字背后的原因低 Coverage 只是现象不是 Root Cause。典型原因可能包括Uncontrollable Clock Unobservable Logic Black Box Constant Logic Memory Boundary X Source Constraint Issue Unsupported Structure Aborted Fault因此真正需要回答的是Coverage Drop ↓ Which Fault Class? ↓ Which Structural / Constraint Cause? ↓ What Can Be Changed?3.4 Test Cost能够测不代表值得这样测制造测试时间直接影响成本。Pattern Count、Shift Cycle、Tester Memory、Tester Channel、Test Frequency 之间相互制约。因此一个 Coverage 很高但 Pattern 极多、Test Time 过长的方案并不一定是量产意义上的好方案。3.5 Test Power测试也必须满足电气安全边界Scan Shift 和 Capture 的切换行为与正常功能模式不同大量逻辑同时翻转可能导致Dynamic Power 上升IR Drop 增大Voltage Droop局部热点Capture 不稳定。因此 ATPG 不只是“Can detect fault?”还必须考虑“Can safely detect fault?”。3.6 Physical Feasibility逻辑正确还不够初始 Scan Stitching 可能在物理布局之后形成很差的连接顺序Before Placement FF1 ─────────────► FF9 ─────► FF3 ─────────► FF12经过 Placement 后更合理的物理顺序可能是After Physical Reorder FF1 ─► FF2 ─► FF3 ─► FF9 ─► FF12Scan Reorder 的目的通常不是改变测试功能而是改善物理局部性、Routing Cost 与 Timing Risk。3.7 Silicon Test真实芯片才是最终验证最终链路是ATPG ↓ Pattern ↓ Simulation ↓ Tester Format ↓ ATE ↓ Silicon ↓ Pass / Fail ↓ Diagnosis真正的终点不是“ATPG completed”而是Silicon can actually be tested.4. DFT 是一条从 Design 到 Silicon 的反馈闭环DFT 不应被理解成单向流程RTL → DFT → Done更接近真实工程的结构是Design ↓ DFT Architecture ↓ DFT Insertion ↓ Structural Verification ↓ ATPG ↓ Pattern Validation ↓ Physical Implementation ↓ Signoff ↓ Tester ↓ Silicon ↓ Diagnosis └──────────────────► Design / DFT Feedback不同阶段会不断向前后游产生反馈当前阶段发现的问题可能回退到DFT CheckChain/Clock/Test Mode 问题DFT Setup / ArchitectureATPGCoverage/Abort/X 问题DFT Constraint / Netlist / ArchitectureFormalFunctional mismatchDFT Insertion / SetupSTATest-mode Timing 问题Clock / Constraint / DFT StructureAPRCongestion / Scan Route 问题Scan Reorder / Physical ConstraintPattern SimulationPattern / Clock / Library 问题ATPG / Timing / Simulation SetupSiliconFail Signature / Yield 问题Pattern / Diagnosis / Design因此复杂 DFT 项目天然包含大量 iteration而不是“一次运行成功”。F03 – DFT Feedback Loop5. DFT 与其他 Flow 的接口比单个 DFT 命令更重要现代 DFT 的困难往往不是某条 Tcl 命令不会写而是多个 Flow 之间的输入、输出、模式和约束必须保持一致。5.1 DFT ↔ RTL / SynthesisDFT 依赖设计侧提供Clock Reset Test Mode Memory Hierarchy Power Control Black-box DefinitionDFT insertion 之后又把修改后的 Netlist、Constraint 和 Test Logic 交给后续实现。核心 Contract 是Design In ↓ DFT Transform ↓ Design Out 要求 Functional Intent Preserved Test Logic Correctly Inserted Constraints Updated Interface Stable5.2 DFT ↔ Formal VerificationDFT 会改变 Netlist 结构因此需要验证在规定的 functional condition 下修改后的设计仍保持功能等价。Reference Design │ │ Compare ▼ DFT-modified Design重点不是要求两个 Netlist 文本或结构完全相同而是验证规定条件下的功能行为一致。5.3 DFT ↔ STADFT 引入新的 Timing ContextScan Shift Mode Capture Mode Test Clock Scan Enable OCC Path Test Control Path因此DFT Structural Clean ≠ DFT Timing Clean5.4 DFT ↔ APRDFT 会影响Scan Cell Placement Compression Logic Test Point OCC MBIST Controller Routing Congestion TimingAPR 又反过来影响 Scan Reorder、Chain Length、Lockup Relationship 和 Physical Locality。所以更准确的关系是DFT ⇄ APR而不是简单的DFT → APR5.5 DFT ↔ Power / Verification / ATEPower Intent 决定测试模式下 Domain、Isolation、Retention、Level Shifter 和 Power Switch 的行为Verification 要验证 Scan Shift、Capture、MBIST Sequence 与 Pattern SimulationATE 则继续关心 Pin Mapping、Cycle、Waveform、Tester Memory 和 Frequency。因此DFT 的真正难点往往位于这些接口而不是单条命令本身。F04 – DFT Cross-Flow Interfaces6. 成熟 DFT Flow 真正管理的不只是 Command如果只看脚本DFT 自动化似乎是在管理命令但从工程系统角度看它至少需要管理六类对象。对象典型内容为什么重要ConfigurationTop、Clock、Scan、Compression、Memory、Mode决定运行语义DependencyNetlist、Library、Constraint、DFT Spec、Tool决定结果是否可复现ExecutionSetup、Insert、Verify、ATPG、Simulate执行过程本身ArtifactLog、Report、Netlist、Pattern、Database构成工程证据Contract输入条件、输出条件、PASS/FAIL 标准判断工程是否成功ProvenanceCommit、Tool Version、Time、Input、Config支持追溯与比较一次 Run 的真实身份不应只由脚本决定而更接近Run Identity Script Inputs Configuration Tool Version Environment6.1 为什么 Exit Code 不够例如Tool Exit 0只说明程序没有异常退出并不能证明Scan Chain 正确 Coverage 达标 Timing Clean Expected Report 已产生 Pattern 可用因此成熟 Flow 应定义自己的 Engineering ContractInput Valid ↓ Tool Started ↓ Expected Artifact Exists ↓ Required Check Completed ↓ Critical Error Absent ↓ Metric Meets Criteria ↓ PASS / FAIL这一步把“脚本跑完”升级成“工程条件满足”。7. DFT 自动化真正应该往哪里发展DFT 自动化可以看成一条逐层升级的路径。Level 1Command AutomationManual Command ↓ Tcl / Shell Script解决重复劳动和人工输入错误。Level 2Flow AutomationStage 1 ↓ Stage 2 ↓ Stage 3 ↓ Stage N系统开始理解 Stage Dependency、Input/Output、Restart Point。Level 3Contract-Driven ExecutionInput Contract ↓ Execution ↓ Output Contract ↓ PASS / FAIL系统开始判断“工程成功”而不仅仅是“命令结束”。Level 4Observable Flow成熟系统至少应该记录Run ID Stage Start / End Time Runtime Status Input Output Error Metrics否则自动化仍然只是“机器替人跑黑盒”。Level 5Diagnosis真正高价值的问题开始于FAIL ↓ Why?系统需要逐步建立Error Classification Log Parsing Report Parsing Metric Extraction Failure Signature Root-cause Candidate例如Coverage Drop ↓ Fault Classification ↓ Uncontrollable / Unobservable / X / Abort ↓ Related Clock / Constraint / Structure ↓ Candidate FixLevel 6Closed Loop最终目标是Execute ↓ Observe ↓ Diagnose ↓ Recommend ↓ Modify ↓ Re-run也就是Configuration ↓ Execution ↓ Observation ↓ Diagnosis ↓ Improvement └────────────► ConfigurationAI 在 EDA/DFT 中真正值得投入的地方更接近这一层而不是简单把自然语言翻译成几条 Tcl 命令。8. 从一个最小可复现 Run 开始如果要构建更高层的 DFT 自动化首先需要一个足够稳定的最小工程对象。可以把一次 EDA/DFT Run 抽象为INPUT ↓ CONFIGURATION ↓ EXECUTION ↓ ARTIFACT ↓ VALIDATION ↓ PASS / FAIL这个模型故意不绑定某一个商业 EDA 工具因为核心问题不是“怎样调用 Tool X”而是怎样定义一次可信、可复现、可验证的工程执行8.1 Input一次 execution 应明确知道输入是什么例如Design Input Configuration Script Environment Tool Executable而不是依赖当前 shell 中“碰巧存在”的状态。8.2 Execution执行入口应该唯一且明确run而不是要求使用者人工记住一长串命令和隐式前置条件。8.3 Artifact运行后应产生清晰的工程资产例如run.log summary status report output databaseArtifact 不是副产品而是 Run 的正式输出和后续诊断依据。8.4 PASS / FAIL Contract一个最小 Contract 可以抽象为Required Input Exists AND Tool Execution Completed AND Expected Output Exists AND Required Marker Found AND Fatal Condition Absent ↓ PASS任何关键条件不满足则进入 FAIL。这样一次运行才从“昨天好像跑成功了”变成“这个 Commit、这些 Inputs、这个 Configuration 对应的 Run 满足预先定义的 Contract。”9. D01Reproducible EDA/DFT Run作为本文对应的第一个工程 DemoD01 已完成一次实际执行验证并保留运行 Log 与版本提交记录。它不试图复刻一个完整 DFT Flow而是先验证一个更基础的问题能否把一次 EDA/DFT 工具运行定义成一个可复现、可检查、具有明确 PASS/FAIL Contract 的工程对象D01 的逻辑结构如下D01 Reproducible EDA/DFT Run Inputs ↓ Environment ↓ Execute ↓ Log ↓ Artifacts ↓ Contract ↙ ↘ PASS FAIL它建立的是一种可以继续复用的工程模式Input ↓ Execute ↓ Observe ↓ Validate ↓ Decide未来无论运行 DFT insertion、ATPG、Formal Verification、STA、APR 或 Physical Verification都可以复用同一类框架。10. 从“会用工具”走向“管理工程系统”现代 DFT 的目标显然已经不是单独完成Scan Insertion ATPG MBIST更完整的定义应该是Modern DFT Test Architecture Design Transformation Verification Physical Implementation Interface Pattern Generation Manufacturing Test Diagnosis Engineering Infrastructure从工程复杂度看它面对的是Many Objects Many Tools Many Modes Many Constraints Many Artifacts Many Iterations ↓ Engineering Complexity因此真正成熟的自动化不能停留在 Command 层Command ↓ Script ↓ Flow ↓ Contract ↓ Observable Execution ↓ Diagnosis ↓ Closed Loop如果底层流程本身不可复现、不可观察、没有统一输入、没有明确输出也没有 PASS/FAIL Contract那么在上面叠加 AI只会形成更难验证的黑盒。反过来如果底层已经具备Structured Input Structured Execution Structured Artifact Structured Validation Structured HistoryAI 才真正有机会参与Report Understanding Failure Classification Root-cause Analysis Knowledge Retrieval Cross-run Comparison Parameter Recommendation Flow Optimization11. 结语DFT 正在成为一种 Software Infrastructure ProblemScan、ATPG、MBIST、Compression、OCC 仍然是现代 DFT 的核心技术但随着 SoC 规模、层次、功耗模式、IP 数量和工具链复杂度持续上升仅仅掌握单个技术模块已经不足以解释整个 DFT Engineering Problem。更准确的视角是DFT Test Architecture Engineering Flow Cross-domain Integration Manufacturing Test Feedback Loop而从自动化角度Reliable DFT Automation Reproducibility Observability Validation Traceability Diagnosis Closed Loop最终形成的不是一组彼此孤立的 Tcl Script而是一条可以持续执行、观察、判断、诊断和改进的工程链Design ↓ Implement ↓ Test ↓ Observe ↓ Diagnose ↓ Improve └────────────► DesignDFT 已经不只是芯片设计流程中的一个步骤。它正在越来越接近一套贯穿设计、实现、验证、制造和数据反馈的工程基础设施。这才是现代 SoC DFT 真正需要解决的问题。工程落点从 C01 到 D01本文讨论的是Why为什么现代 DFT 应被视为一个跨设计、实现、测试和反馈的工程系统。D01 则验证第一个HowInput ↓ Controlled Execution ↓ Log / Artifact ↓ Validation Contract ↓ PASS / FAILD01 的价值不在于模拟完整商业 DFT Flow而在于先建立后续所有自动化都能复用的执行底座明确输入、受控执行、保留证据、自动验证、给出确定状态。后续 Demo 将在这个基础上逐步扩展到 Configuration Validation、Log / Report Parsing、Failure Classification、Cross-run Comparison、Flow Orchestration 与 Closed-loop Diagnosis。核心观点速览常见理解更完整的工程理解DFT Scan InsertionDFT Test Architecture Engineering FlowATPG Pattern GenerationATPG Testability Verification Pattern GenerationScript 跑完 成功Contract 满足 工程成功DFT → APRDFT ⇄ APRFlow 是单向流水线Flow 是跨阶段反馈闭环AI 自动生成命令AI 更适合 Diagnosis Closed-loop Improvement公开工程 DemoD01 — Reproducible EDA/DFT RunGitHubhttps://github.com/qiqixixi1001/dft-eda-engineering/tree/main/demos/D01_reproducible_run对应的首个公开版本https://github.com/qiqixixi1001/dft-eda-engineering/releases/tag/v0.1.0D01 提供可直接执行的最小示例以及 PASS/FAIL Contract、Manifest、Source Provenance、PASS Evidence 和 Controlled FAIL Evidence。下一篇将继续进入工程实现从 D01 的可复现执行与 PASS/FAIL Contract 出发讨论如何把 EDA/DFT Run 变成可追踪、可比较、可诊断的工程对象。