1. 内容整体设计与思路拆解1.1 为什么要单独做DFT架构设计很多刚接触DFTDesign for Test可测试性设计的工程师拿到一个芯片项目后第一反应是“先把功能跑通再说测试后面再弄”。这个想法在FPGA验证阶段还能勉强凑合但凡走ASIC流程尤其在先进工艺节点下测试策略没想清楚就开工后面至少要多熬两个月。我见过太多项目组在RTL freeze之后才临时拉人做DFT方案结果scan chain插不进去、时钟域切不开、memory没有BIST wrapper最后只能靠ATE硬测加人工补pattern成本翻倍不说覆盖率还不达标。所以DFT架构设计这件事必须在芯片架构阶段就同步介入它决定了你在流片后能不能快速、低成本地把芯片测清楚。从工具链角度目前行业里用得最多、最稳的就是两大阵营Synopsys的DFT Compiler、TetraMAX、VCS以及现在是Siemens EDA的Tessent系列包括Tessent Shell、Tessent Scan、Tessent MemoryBIST和Tessent LogicBIST。很多团队是混搭使用比如用Synopsys做综合和scan insertion用Tessent做memory BIST和pattern仿真。本文不会站队吹某一家而是把两套工具链配合使用时的架构设计思路、操作步骤和踩坑记录一并讲清楚。1.2 DFT架构设计的核心目标DFT架构设计说白了就三件事可控、可观测、可隔离。可控是指测试时能把芯片内部所有关键节点置成想要的逻辑状态可观测是指能把内部节点的响应值搬出来比对可隔离是指在测试模式下能切断功能逻辑之间的相互干扰让每条测试路径干干净净。围绕这三个目标我们通常要在芯片里加入test mode控制信号、scan chain、OCCOn-Chip Clock Controller电路、memory BIST controller、JTAG TAP控制器这些基础结构。听起来东西不少但架构设计的核心其实是做取舍哪些模块做full scan哪些做partial scan哪部分memory用BIST哪部分直接通过scan访问时钟和复位在test mode下怎么切换功耗约束在shift和capture两种状态下怎么平衡。以我个人的经验架构阶段至少要确定三张表DFT时钟方案表、DFT复位方案表、测试模式定义表。这三张表定了后面所有工具脚本和约束文件都是围绕它们展开的。很多新手拿到流程脚本直接跑跑了三天发现scan chain数目不对追根溯源都是因为这三张表没有提前定义清楚。2. 核心细节解析与实操要点2.1 两套工具链的分工与选型逻辑先说结论在我的项目经验里Synopsys和Mentor不是互斥关系而是“各管一段、接口对齐”的协作关系。常见的分配方式如下。设计环节推荐工具理由RTL综合、DFT logic insertionSynopsys Design Compiler DFT Compiler综合与DFT一体化约束统一脚本成熟Scan chain definition与insertionSynopsys DFT Compiler与综合网表强绑定时序优化方便ATPG pattern生成Synopsys TetraMAX图形界面友好debug定位速度快Memory BISTTessent MemoryBIST对各类SRAM wrapper支持到位自动生成RTLLogic BISTTessent LogicBIST内建自测架构成熟IP化程度高Pattern仿真Synopsys VCS 或 QuestaVCS跑TetraMAX出来的pattern最稳为什么要这样切因为DFT Compiler和TetraMAX在同一套数据库体系下从综合插入scan到生成pattern中间不需要做格式转换一致性最好。而Tessent MemoryBIST生成的BIST controller质量确实高尤其在memory种类多、位宽混杂的SoC里自动wrapper插入能力比Synopsys的BIST方案更灵活。所以实际项目经常是“Synopsys做主scanTessent做memory BIST”最终在网表层面把两边的DFT逻辑拼到一起。这套混搭流程最常见的坑是接口协议不一致。Tessent MemoryBIST的controller在测试模式下会通过JTAG接口去访问而Synopsys的scan chain也要挂到同一个TAP上去两者如果不在RTL阶段就约定好测试指令编码后面整合网表时就会出现JTAG指令冲突。2.2 Scan Chain架构的关键决策点Scan chain的架构设计是DFT里最基础也最容易被忽略的部分。很多新手以为就是把DFF串成链实际上没那么简单。第一个决策点chain数目怎么定。chain越多测试时间越短但需要的测试管脚和功耗也越高。业界有个经验公式总的scan cell数除以期望的测试时间再乘以cycle time能得到chain长度的上限。比如芯片有100万个scan cell你希望单条chain的pattern跑下来不超过100ms时钟频率50MHz——100万除以0.1秒乘以50M的结果大约是0.2意思是说这种情况下至少要分成5条chain才能满足时间要求。这个估算方法在架构阶段就能快速用来设定chain数量的目标具体逻辑是基于“每个shift操作移动一个bit”的原理。第二个决策点chain的连接顺序。建议按功能模块划分尽量把同一个时钟域的cell连在一起避免跨时钟域产生setup问题。另外要把物理位置相近的cell连在一起减少布线拥塞。这两个目标有时候会冲突我的建议是优先满足物理位置约束时钟域的问题交给OCC去解决。因为跨时钟域的scan cell在shift阶段是共享同一个scan clock的只要测试时钟统一功能时钟域的差异在shift阶段不敏感。第三个决策点test mode时钟方案。这里要专门设计test clock mux把功能时钟切换到测试时钟。实际项目里常见做法是给每个时钟域插一个OCCcapture时产生两拍或三拍脉冲shift时直接透传scan clock。OCC的架构直接决定了ATPG pattern能不能覆盖到hold-time问题这块一定要在DFT架构文档里写清楚。2.3 Memory BIST架构要点Memory在SoC里占比越来越高尤其是AI芯片SRAM面积可能占了60%以上。对这部分做DFT不可能全部靠scan绕进去因为memory单元不是standard cellscan cell控制不了内部的存储阵列。所以要用Memory BIST。Mentor Tessent MemoryBIST的典型做法是根据memory的端口类型单口、双口、伪双口、位宽、深度自动生成BIST controller和wrapper逻辑。架构阶段你要做的事情是决定哪些memory做BIST、用哪种算法March C-March LRMarch SS等、是否做redundancy repair。这里有个容易被忽略的点BIST controller本身的时钟和复位。BIST controller在功能模式下是不工作的但它的时钟树和复位网络如果不和功能逻辑隔离好跑功能pattern时BIST controller内部的状态机会乱跳导致芯片功能异常。所以在架构阶段要把所有BIST controller的时钟都接在测试时钟域下复位强制拉低只有进入BIST模式时才释放。2.4 共享总线的DFT处理思路最近不少人问共享总线在DFT架构下怎么处理。共享总线比如AHB、AXI总线在功能模式下是多个master和多个slave通过总线上同一组数据线和地址线通信。在测试模式下这些总线节点会产生大量“三态冲突”或者“总线竞争”。常见的处理思路有两种。第一种在总线的每个master接口处加isolation cell测试模式下把所有master隔离掉然后由外部测试逻辑驱动总线直接对slave进行scan或memory访问。第二种把总线当作一条特殊的功能路径在ATPG时生成基于总线的测试pattern但这要求总线上的仲裁逻辑能正确响应测试激励复杂度会比较高。我自己实际项目中更常用第一种。加isolation cell的代价是面积增加但对ATPG工具来讲约束条件清晰简单pattern生成稳定。另外对于AXI这种协议复杂的总线如果在架构阶段发现某条路径的测试覆盖率始终上不去不要硬抗直接在总线上切一刀加个test mode bypass逻辑把普通功能路径绕过去测完再切回来。这个思路和我用过的Synopsys AXI VIP在事务级打印控制方面类似都是通过控制层把复杂逻辑“黑盒化”只不过DFT这里不是控制transaction打印而是控制总线节点的可测试性配置。2.5 4A架构与DFT的类比再说一个题外话最近“4A架构设计”这个词在行业里很热。它讲的是从业务到技术的四层架构协同本质上和DFT架构设计有相通之处都强调顶层视角、分层分工、接口标准化。DFT架构同样不是单点工具能解决的它需要从系统架构、逻辑设计、物理实现、测试工程四个层面协同。你可以把ATE测试程序想象成“业务需求”把DFT逻辑当作“中间件”把扫描链当作“系统接口层”把工艺库当作“基础设施”。这样类比后你会发现DFT架构设计的核心挑战并不是某个工具用得好不好而是各层之间的接口是否清晰、有没有冗余依赖。3. 实操过程与核心环节实现3.1 环境准备与工具安装的避坑记录开工之前先把工具环境弄干净。Synopsys工具安装是很经典的坑位集中区尤其新手在Linux环境装VCS或DFT Compiler时最常见的报错是缺少Tcl/Tk库。我遇到的典型报错是这样的$ vcs -version vcs: error while loading shared libraries: libtcl8.4.so: cannot open shared object file: No such file or directory这个问题的根源是VCS运行时需要Tcl库但系统里要么没装要么路径不对。解决方法不是去网上乱下lib而是先确认你装的是哪个版本因为不同版本的VCS依赖的Tcl版本不一样。我第一次装VCS时图省事直接apt install tcl结果系统给我装的是Tcl 8.6而VCS找的是8.4还是报错。正确做法是先确认VCS发布包里的linux distribution说明看它对应支持哪几个Tcl/Tk版本。再把Tcl库的路径加到LD_LIBRARY_PATH环境变量里并且LD_LIBRARY_PATH的优先级要在PATH之前。实在找不到对应版本可以软链接顶上去但不保证所有功能都稳定。另一个高频坑是license配置。新手的习惯是拿到license文件直接设LM_LICENSE_FILE但Synopsys的license管理方式对hostname和MAC地址绑定很敏感。如果你换了网卡或者改过hostnamelicense就失效。建议把SNPSLMD_LICENSE_FILE和LM_LICENSE_FILE都设成指向同一个license server同时确认hostname和license文件里的SERVER行一致。Mentor Tessent这边相对干净它主要依赖Linux原生的libstdc和libX11装的时候重点检查32位兼容库是否装了因为部分老版本的Tessent GUI界面依赖32位库。如果你用的是新版本Tessent 2023以后对64位库的支持已经很完善了麻烦少很多。3.2 用DFT Compiler做Scan Insertion的完整流程以前项目里的经验用Synopsys DFT Compiler做scan insertion大致分四步。第一步读入设计数据。这里不建议直接用.v网表最好用综合后的.ddc格式因为它保留了逻辑综合时的时序约束和属性信息DFT Compiler对时钟、复位这些关键pin的理解更准确。如果没有ddc也可以读.v文件但要额外补充current_design、link这些命令来建立设计上下文。第二步配置DFT信号。用set_dft_signal命令把test mode、scan clock、scan enable、scan in、scan out这些端口定义清楚。这个阶段最重要的动作是告诉工具“哪些信号是测试专用的”。很多新手的错误是只定义scan clock和scan enable忽略了test mode结果工具默认所有功能模式也跑scan逻辑做DRC时冒出一堆violation。我自己常用的定义方式是这样set_dft_signal -view spec -type ScanClock -port clk_test -timing [list 10 20] set_dft_signal -view spec -type ScanEnable -port test_se -active 1 set_dft_signal -view spec -type TestMode -port test_mode -active 1 set_dft_signal -view spec -type ScanIn -port test_si -hookup_pin U_TOP/U_DFF/Q set_dft_signal -view spec -type ScanOut -port test_so这里的-view spec表示当前是规格定义阶段后续还要用-view existing_dft来告诉工具哪些DFT逻辑已经存在。两套视图不混淆是工具正常工作的前提。第三步配置scan chain。用set_scan_configuration设定chain数量、chain length、share scan in/out等参数。假如设计有4个clock domain我一般配置4条chain每条chain长度控制在2000到4000个scan cell之间这个范围是综合工具和布线工具都比较舒服的区间。第四步执行insert_dft然后跑DRC检查有没有scan chain broken、clock conflict、uncontrolled pin这类问题。DRC过了之后DFT Compiler会输出一个带扫描链信息的网表并且生成spf文件STIL Procedure Format的变体这个文件是后面TetraMAX生成pattern时的重要输入。3.3 用TetraMAX生成和仿真ATPG PatternTetraMAX的输入主要有三个DFT Compiler输出的网表、测试协议文件spf格式以及库文件。库文件指标准单元库里每个cell的测试模型通常在综合库目录下有个.v格式的测试库名字类似tcbn28hpcplusbwp7t30p140ssg0p81v125c_120a_ccs_test.v。这步别漏漏了TetraMAX报“cell not found in library”基本是必然的。TetraMAX推荐用脚本模式跑因为后端迭代时pattern数量大GUI点来点去效率太低。核心脚本如下read_netlist $env(DESIGN_NETLIST) run_build_model $env(DESIGN_NAME) add_clocks 0 clk_test -shift 0 add_clocks 0 clk_test -capture 1 add_scan_enable test_se -active 1 add_scan_groups $env(SCAN_GROUPS) run_drc run_atpg -auto_compression run_atpg -auto_compression -coverage estimate write_patterns output_pattern.wgl -format wgl write_patterns output_pattern.stil -format stil write_faults detected_faults.list -format list这里-format wgl是生成给Tessent/UltraFlex用的波形格式-format stil是通用标准测试接口语言格式给其他ATE设备用。实际项目里两种格式都要保留因为流片后可能换测试设备。TetraMAX跑完后要重点看两件事fault coverage和pattern count。fault coverage一般要求99%以上对可测故障如果达不到先不要急着加pattern而是去查DRC violation大概率是某些模块的约束没加全。pattern count决定测试成本压缩参数-auto_compression可以帮你把pattern数量压下来但它牺牲的是运行时间所以一次完整ATPG可能要跑好几个小时。3.4 用Tessent MemoryBIST搞定SoC里一堆SRAM如果说scan chain的难点在于时钟和物理布局那memory的难点就在于“数量多、类型杂”。一个中等规模的SoC里可能有几十上百个SRAM实例每个的端口、位宽、深度都不同。如果每个memory都手工包一个BIST wrapper累死不说还容易出错。Tessent MemoryBIST的价值就在这里——它能自动识别memory的类型并生成对应的controller和wrapper RTL。操作流程大致分三块第一块准备memory模型库。Tessent要求每个memory都有对应的.lib描述文件里面定义了memory的端口名、位宽、地址范围、读写时序。拿到foundry的memory compiler输出后需要转换成Tessent MemoryBIST认识的格式。这一步本质上是一个脚本化过程但新手第一次做很可能忘记检查memory是否支持“column mux”隐藏的冗余位导致生成的wrapper逻辑和多bit操作对不上。第二块定义BIST配置。通过Tessent shell交互式命令或者脚本方式指定哪些memory做BIST、用什么算法、group怎么分。典型脚本如下set_context dft_spec -from_specification create_bist_protocol -file bist_protocol.txt create_pattern -type memory set_bist_configuration -memory_list sram_a sram_b -algorithm march_cw run_bist_insertion其中march_cw是一种涵盖常见故障模型的算法适合快速分析。如果芯片测试要求更高就换march_ss或march_lr但pattern执行时间会长一些。第三块把生成的BIST RTL与主设计集成。这一步的重点是注意BIST controller的复位信号和时钟信号必须受test mode约束控制确保功能仿真时BIST逻辑完全关断。有些设计因为“最小改动”就把BIST clock直接接到功能clock上结果综合后clock tree有大量skew到测试阶段才暴露非常被动。3.5 共享总线场景下的DFT实现示例前面讲到共享总线DFT的思路这里补充一个可操作的流程。假设芯片内部有一条AHB总线两个master三个slave要在测试模式下直接把master隔离掉然后对slave做scan访问。第一步在master接口的地址、数据、控制信号上分别插入isolation cell。Tessent和DFT Compiler都有自动插isolation的标准命令DFT Compiler也可以用set_isolate_ports指定。第二步加test mode - 通过一个复用端口选择功能模式和测试模式。在测试模式下isolation cell输出固定为0master驱动不了总线避免总线竞争。第三步在总线的slave端接入scan test的观察点这样一来scan in的刺激可以通过测试端口直接进到slave内部slave的响应也能通过scan out直接观测。实际项目里AXI总线的DFT处理比AHB更复杂因为AXI有多个channel每个channel都有独立的valid/ready握手信号。处理不好的话ATPG工具生成的pattern在仿真时会出现握手超时导致覆盖率上不去。我的经验是AXI总线的DFT模式中要把valid信号拉高、ready信号拉低强制让总线进入“从设备响应”的稳定状态避免功能握手逻辑干扰测试路径。如果你在配合Synopsys AXI VIP做验证想关闭事务级的打印输出可以在VIP的配置里通过$s_axi_verbosity 0方法来降低打印量这和DFT中“屏蔽复杂协议、聚焦关键信号”的思路是一致的。4. 常见问题与排查技巧实录4.1 DRC Violation的三大高频原因DFT Compiler和TetraMAX都会跑DRC常见的高频violation基本集中在三类。第一类scan cell不受时钟控制。报错信息一般是“clock not controlled”或“clock can not propagate”。原因通常是测试时钟的约束没加完整或者功能时钟和测试时钟之间的mux没有被test mode信号控制。解决方法是返回set_dft_signal重新定义时钟关系同时检查dft_clock_controller是否已经插好。第二类scan enable路径存在组合逻辑。正常设计里scan enable信号必须是从端口直接进来的高扇出信号中间不能经过任何组合逻辑。如果综合时优化把scan enable路径上的buffer挪走或者合并就会出现这个报错。解决方法是在综合脚本里加set_dont_touch约束把scan enable路径保护起来。第三类share scan in/out的端口冲突。有的芯片引脚紧张会把多个scan chain的输入共享到一个端口。DFT Compiler支持share_scan_in配置但如果多个chain的长度不一样工具会插一个rebalance逻辑来对齐这块逻辑在DRC时容易报乱。建议项目前期规划好chain长度尽量等长。4.2 Pattern仿真失败的排查思路ATPG生成的pattern在VCS里仿真时最让人头大的就是“timing violation”和“X态传播”。X态传播的经典场景某个寄存器在shift阶段没有被正确初始化导致capture阶段产生的响应值是X最终和TetraMAX预测值比上不。排查这个问题的顺序我一般这样走第一步打开VCS的波形找出第一个出现X的节点往前推看它是从哪个FF传过来的。第二步查这个FF对应的scan cell有没有被正确串进chain。如果它没有在scan_group配置文件里TetraMAX会默认它“capture时不使能”所以输出是X。第三步确认scan enable信号在capture阶段真的拉低了。很多情况下test bench激励里的scan enable时序和真实的OCC控制时序不一致导致capture阶段scan enable仍处于active状态。Timing violation的排查相对直接就是看setup/hold是哪个时钟沿之间发生的。但有一种情况很隐蔽DFT Compiler在scan insertion后输出的网表里OCC电路是基于特殊cell库实现的它的时钟路径上可能有一个额外的delay。如果VCS仿真库里这个cell的行为模型没包含准确的timing信息仿真就报violation但真实芯片其实没问题。这个问题的标准解法是对OCC cell做set_false_path约束在仿真阶段不从OCC输出端检查timing而是直接看功能路径。4.3 工具安装和脚本运行的环境问题速查结合我自己的踩坑经历把Synopsys和Mentor工具环境问题整理成速查表项目遇到时直接对着查。症状可能原因解决方法libtcl8.4.so找不到系统Tcl版本不匹配安装对应版本Tcl/Tk或加入已有库路径license报错hostname/MAC地址不匹配统一hostname检查license server配置tessent图形界面起不来缺少32位兼容库安装libX11-32bit、libstdc-32bitdc_shell启动后命令卡住LD_LIBRARY_PATH里有冲突库精简路径优先保留Synopsys自带库路径VCS编译报undefined reference库文件版本不匹配重编译TEST bench或换用匹配版本DFT Compiler读不了ddc数据库版本不兼容用write -format ddc从原综合工具重新导出TetraMAX DRC全都不过测试协议文件里时钟/复位定义有误复查spf文件尤其是scan chain的spec部分这里要特别强调不同工具链之间传递文件时版本兼容性非常关键。比如DC 2022版本的ddc文件如果用DC 2020版本的DFT Compiler去读很大概率报“incompatible database”。实际项目里要么统一工具版本要么用.v格式做中间接口虽然会丢一些属性但至少能跑通。4.4 覆盖率优化的独家技巧新手的常见误区是一味增加run_atpg的迭代次数其实覆盖率瓶颈往往在信号可控制性上。我的经验是优先检查这三块复位信号、异步置位信号、输出使能。复位信号的问题如果某个模块的复位在测试模式下一直被拉高那么这个模块的DFF永远无法进入已知状态覆盖率肯定上不去。解决办法是在测试模式下把全局复位信号放开让TetraMAX能控制它。异步置位信号的问题某些DFF有异步preset端口如果测试模式下preset不受控可能会导致整个scan chain的值被强制翻转。建议对这类cell做set_dft_signal -view spec -type Reset约束明确指定它在shift阶段是无效的。输出使能的问题大量三态IO的逻辑会使ATPG工具很难控制总线上的驱动方向。可以给每个三态IO加一个测试模式下强制使能的MUX这样工具能直接看到输出值。4.5 shared bus DFT的边界条件处理shared bus DFT时除了常规的isolation cell还要特别注意仲裁器的测试覆盖。仲裁器本身是一个状态机如果测试模式下你把所有master都隔离掉了仲裁器实际上变成“无输入请求”状态它的状态转移就覆盖不到。解决方法是保留一个master通道作为测试通道测试模式下由外部测试逻辑模拟一个固定的请求序列驱动仲裁器走一遍状态转移把仲裁器内部的故障覆盖住。这块在架构设计文档里要写明“bus test observer policy”我在项目里一般会规定每个共享总线必须支持两种测试路径一是“旁路测试”路径bypass测试模式下直接访问slave二是“仲裁参与”路径通过固定请求序列测试仲裁逻辑。具体到Tessent和TetraMAX的实现前者靠isolation cell完成后者需要额外加一条测试专用的master接口。从物理实现角度看shared bus上的DFT逻辑往往会把几条原本很干净的bus线变成被隔离逻辑插碎的线网这会影响布线后的时序收敛。所以做bus DFT时DFT脚本里一定要加set_dft_signal -view spec -type Constant的约束让工具把测试专用的控制信号直接接到固定电平这样综合工具做逻辑优化时不会大量重复插入buffer。5. 从架构设计到测试落地的完整链路5.1 架构文档必须包含哪些内容DFT架构设计不是跑几个工具脚本就完事的它需要有文档沉淀。我建议架构文档里至少包含测试模式定义与转换机制、时钟/复位测试方案、扫描结构与chain规划、存储器BIST策略、IO/总线测试策略、测试功耗预算、覆盖率目标、ATE测试流程与pattern格式。其中测试模式定义这部分容易被忽略但它直接决定工具怎么理解设计。建议用下面的表格把每个模式的关键信号状态列清楚。测试模式test_modescan_enableMemoryBIST_en功能时钟/测试时钟用途Normal0X0功能时钟正常工作Scan shift110测试时钟移入/移出数据Scan capture100OCC脉冲捕获故障响应Memory BIST1X1测试时钟SRAM测试IO loopback1X0测试时钟引脚级测试5.2 从RTL到ATPG的集成流程完整流程可以串成一条链RTL设计 → 插入DFT逻辑DFT Compiler/Tessent → 逻辑综合DC → scan insertion验证 → ATPGTetraMAX → pattern仿真VCS → 物理实现ICC/Genus → signoff。这里的顺序非常重要如果你已经先做完了物理综合再回去插scan chain工具要做ECOEngineering Change Order修复效率极低。所以业界标准做法是DFT insertion放在逻辑综合之前的RTL阶段也就是pre-mask DFT。RTL阶段插入DFT逻辑的另一个好处是功能验证环境可以直接覆盖测试模式的某些路径。比如你可以写一个testbench在test_mode1时把scan chain当成一大串移位寄存器跑一遍验证明scan_in到scan_out的连接性。这个“连接性测试pattern”在流片后的bring-up阶段非常有用是判断芯片是否“活着”的第一条测试向量。5.3 与物理实现阶段的衔接要点很多DFT工程师对物理实现阶段没有太多感知但恰恰是物理实现阶段的时钟树综合CTS对DFT影响最大。由于scan chain上所有cell都需要共用一个测试时钟树如果测试时钟树的平衡做得不好shift阶段会出现大量的setup violation。我的经验是在CTS之前就告诉物理实现工程师哪些是测试时钟要求CTS时把测试时钟和功能时钟分开建立树并在PPA之外额外评估shift模式下测试时钟的skew。所有的OCC输出端要做set_clock_group -logically_exclusive约束从而在物理实现时综合工具会自动优先处理功能时钟路径。另外scan chain的物理走线最好位于芯片的中间层避开高速IO区域和模拟模块附近的噪声源这条经验对于混合信号芯片尤其重要。6. 新手实践路线与避坑提醒6.1 学习路径建议如果你是零基础开始学DFT不要一上来就把所有工具都装上我的建议是分三步走。第一步先把DFT的基本概念吃透比如scan cell的类型、OCC的工作原理、fault模型stuck-at、transition等。没有这些基础你写出来的set_dft_signal就是无源之水。第二步选一条最简单的设计比如一个3位的计数器用DFT Compiler完整跑一遍scan insertion再用TetraMAX生成pattern并在VCS仿真通过。这个“最小可用流程”能帮你建立对工具链的整体认知。一个计数器设计可能只需要几百个scan cell但流程切得越多越能暴露工具之间衔接的问题。第三步在此基础上逐步增加复杂度比如加入一个SRAM加Tessent MemoryBIST或者加入一条共享总线加isolation cell。每加一个模块就多跑一轮DRC和ATPG把错误类型记录下来形成自己的“DFT避坑手册”。我见过不少工程师跳过了前两步直接拿一个大型SoC练手结果调试了整整一个月连基础脚本都还没理顺。DFT是一个非常依赖经验积累的领域你需要大量的失败案例来建立“错误模式识别”的能力。6.2 时间规划与常见误判按一个中型芯片项目来算DFT的相关工作量大致分布如下架构设计约20%的时间RTL阶段DFT逻辑插入约25%scan insertion和ATPG约30%物理实现阶段的DFT约束同步约15%流片前pattern signoff约10%。如果你发现ATPG这一步占掉了50%以上的时间说明前面的DFT架构设计大概率出了问题。新人最常见的三个误判一是以为scan chain越多越好结果测试功耗爆掉二是以为DRC过了就万事大吉结果忽略了scan chain在物理实现阶段的布线拥塞三是以为memory BIST是一种“附加功能”结果没有提前考虑BIST controller的复位和时钟导致芯片流片后BIST一跑就复位抖动。6.3 流程自动化的经验我后来在团队里推行的做法是把整个DFT流程做成一个基于Makefile的自动化流水线每跑完一个步骤自动生成报告出现错误时自动存档日志。这个做法不一定适合所有团队但如果你经常要处理多版本、多项目花两天时间搭这套自动化是值得的。自动化流程的核心理念每个步骤的输出都要有明确的“可检查的中间产物”比如scan chain报告、DRC报告、coverage报告。不能只看最终生成网表有没有跑完因为工具“跑完”和“跑对”是两码事。7. 我的体验DFT架构设计的真正难点在哪里做DFT多年我越来越觉得工具命令和脚本只是术的层面真正难的其实是架构权衡。比如scan chain数目和测试时间的权衡需要你同时了解ATE测试成本、芯片量产数量和芯片面积预算。比如memory BIST到底做单bank还是多bank既影响故障覆盖率也影响测试时的并行度和功耗。再比如共享总线上的isolation粒度细了面积大粗了覆盖率低。这些决策没有一个公式能直接给出答案它依赖的是你对具体设计的理解和对最终产品的测试需求的判断。个人体感上和ATPG覆盖率相比你更应该关注的是“测试方案的可执行性”与“DFT逻辑对功能路径的侵入程度”。有些团队刻意追求99.9%的覆盖率为此插入了大量DFT逻辑结果功能路径上多了几百个mux时序收敛变得异常困难流片回来的芯片功能性能反倒退步了。DFT设计的目标是在合理面积、功耗和时序代价下拿到足够高的故障覆盖率而不是为了一个数字牺牲整个芯片的可用性。我建议刚入行的工程师不要只盯着TetraMAX跑出来的coverage数字多去想想“这条fault如果真在芯片上出现了它会被测试pattern抓到吗”这个问题才是DFT设计真正的起点。 DFT架构设计全流程解析：Scan Chain、ATPG与Memory BIST实战指南
1. 内容整体设计与思路拆解1.1 为什么要单独做DFT架构设计很多刚接触DFTDesign for Test可测试性设计的工程师拿到一个芯片项目后第一反应是“先把功能跑通再说测试后面再弄”。这个想法在FPGA验证阶段还能勉强凑合但凡走ASIC流程尤其在先进工艺节点下测试策略没想清楚就开工后面至少要多熬两个月。我见过太多项目组在RTL freeze之后才临时拉人做DFT方案结果scan chain插不进去、时钟域切不开、memory没有BIST wrapper最后只能靠ATE硬测加人工补pattern成本翻倍不说覆盖率还不达标。所以DFT架构设计这件事必须在芯片架构阶段就同步介入它决定了你在流片后能不能快速、低成本地把芯片测清楚。从工具链角度目前行业里用得最多、最稳的就是两大阵营Synopsys的DFT Compiler、TetraMAX、VCS以及现在是Siemens EDA的Tessent系列包括Tessent Shell、Tessent Scan、Tessent MemoryBIST和Tessent LogicBIST。很多团队是混搭使用比如用Synopsys做综合和scan insertion用Tessent做memory BIST和pattern仿真。本文不会站队吹某一家而是把两套工具链配合使用时的架构设计思路、操作步骤和踩坑记录一并讲清楚。1.2 DFT架构设计的核心目标DFT架构设计说白了就三件事可控、可观测、可隔离。可控是指测试时能把芯片内部所有关键节点置成想要的逻辑状态可观测是指能把内部节点的响应值搬出来比对可隔离是指在测试模式下能切断功能逻辑之间的相互干扰让每条测试路径干干净净。围绕这三个目标我们通常要在芯片里加入test mode控制信号、scan chain、OCCOn-Chip Clock Controller电路、memory BIST controller、JTAG TAP控制器这些基础结构。听起来东西不少但架构设计的核心其实是做取舍哪些模块做full scan哪些做partial scan哪部分memory用BIST哪部分直接通过scan访问时钟和复位在test mode下怎么切换功耗约束在shift和capture两种状态下怎么平衡。以我个人的经验架构阶段至少要确定三张表DFT时钟方案表、DFT复位方案表、测试模式定义表。这三张表定了后面所有工具脚本和约束文件都是围绕它们展开的。很多新手拿到流程脚本直接跑跑了三天发现scan chain数目不对追根溯源都是因为这三张表没有提前定义清楚。2. 核心细节解析与实操要点2.1 两套工具链的分工与选型逻辑先说结论在我的项目经验里Synopsys和Mentor不是互斥关系而是“各管一段、接口对齐”的协作关系。常见的分配方式如下。设计环节推荐工具理由RTL综合、DFT logic insertionSynopsys Design Compiler DFT Compiler综合与DFT一体化约束统一脚本成熟Scan chain definition与insertionSynopsys DFT Compiler与综合网表强绑定时序优化方便ATPG pattern生成Synopsys TetraMAX图形界面友好debug定位速度快Memory BISTTessent MemoryBIST对各类SRAM wrapper支持到位自动生成RTLLogic BISTTessent LogicBIST内建自测架构成熟IP化程度高Pattern仿真Synopsys VCS 或 QuestaVCS跑TetraMAX出来的pattern最稳为什么要这样切因为DFT Compiler和TetraMAX在同一套数据库体系下从综合插入scan到生成pattern中间不需要做格式转换一致性最好。而Tessent MemoryBIST生成的BIST controller质量确实高尤其在memory种类多、位宽混杂的SoC里自动wrapper插入能力比Synopsys的BIST方案更灵活。所以实际项目经常是“Synopsys做主scanTessent做memory BIST”最终在网表层面把两边的DFT逻辑拼到一起。这套混搭流程最常见的坑是接口协议不一致。Tessent MemoryBIST的controller在测试模式下会通过JTAG接口去访问而Synopsys的scan chain也要挂到同一个TAP上去两者如果不在RTL阶段就约定好测试指令编码后面整合网表时就会出现JTAG指令冲突。2.2 Scan Chain架构的关键决策点Scan chain的架构设计是DFT里最基础也最容易被忽略的部分。很多新手以为就是把DFF串成链实际上没那么简单。第一个决策点chain数目怎么定。chain越多测试时间越短但需要的测试管脚和功耗也越高。业界有个经验公式总的scan cell数除以期望的测试时间再乘以cycle time能得到chain长度的上限。比如芯片有100万个scan cell你希望单条chain的pattern跑下来不超过100ms时钟频率50MHz——100万除以0.1秒乘以50M的结果大约是0.2意思是说这种情况下至少要分成5条chain才能满足时间要求。这个估算方法在架构阶段就能快速用来设定chain数量的目标具体逻辑是基于“每个shift操作移动一个bit”的原理。第二个决策点chain的连接顺序。建议按功能模块划分尽量把同一个时钟域的cell连在一起避免跨时钟域产生setup问题。另外要把物理位置相近的cell连在一起减少布线拥塞。这两个目标有时候会冲突我的建议是优先满足物理位置约束时钟域的问题交给OCC去解决。因为跨时钟域的scan cell在shift阶段是共享同一个scan clock的只要测试时钟统一功能时钟域的差异在shift阶段不敏感。第三个决策点test mode时钟方案。这里要专门设计test clock mux把功能时钟切换到测试时钟。实际项目里常见做法是给每个时钟域插一个OCCcapture时产生两拍或三拍脉冲shift时直接透传scan clock。OCC的架构直接决定了ATPG pattern能不能覆盖到hold-time问题这块一定要在DFT架构文档里写清楚。2.3 Memory BIST架构要点Memory在SoC里占比越来越高尤其是AI芯片SRAM面积可能占了60%以上。对这部分做DFT不可能全部靠scan绕进去因为memory单元不是standard cellscan cell控制不了内部的存储阵列。所以要用Memory BIST。Mentor Tessent MemoryBIST的典型做法是根据memory的端口类型单口、双口、伪双口、位宽、深度自动生成BIST controller和wrapper逻辑。架构阶段你要做的事情是决定哪些memory做BIST、用哪种算法March C-March LRMarch SS等、是否做redundancy repair。这里有个容易被忽略的点BIST controller本身的时钟和复位。BIST controller在功能模式下是不工作的但它的时钟树和复位网络如果不和功能逻辑隔离好跑功能pattern时BIST controller内部的状态机会乱跳导致芯片功能异常。所以在架构阶段要把所有BIST controller的时钟都接在测试时钟域下复位强制拉低只有进入BIST模式时才释放。2.4 共享总线的DFT处理思路最近不少人问共享总线在DFT架构下怎么处理。共享总线比如AHB、AXI总线在功能模式下是多个master和多个slave通过总线上同一组数据线和地址线通信。在测试模式下这些总线节点会产生大量“三态冲突”或者“总线竞争”。常见的处理思路有两种。第一种在总线的每个master接口处加isolation cell测试模式下把所有master隔离掉然后由外部测试逻辑驱动总线直接对slave进行scan或memory访问。第二种把总线当作一条特殊的功能路径在ATPG时生成基于总线的测试pattern但这要求总线上的仲裁逻辑能正确响应测试激励复杂度会比较高。我自己实际项目中更常用第一种。加isolation cell的代价是面积增加但对ATPG工具来讲约束条件清晰简单pattern生成稳定。另外对于AXI这种协议复杂的总线如果在架构阶段发现某条路径的测试覆盖率始终上不去不要硬抗直接在总线上切一刀加个test mode bypass逻辑把普通功能路径绕过去测完再切回来。这个思路和我用过的Synopsys AXI VIP在事务级打印控制方面类似都是通过控制层把复杂逻辑“黑盒化”只不过DFT这里不是控制transaction打印而是控制总线节点的可测试性配置。2.5 4A架构与DFT的类比再说一个题外话最近“4A架构设计”这个词在行业里很热。它讲的是从业务到技术的四层架构协同本质上和DFT架构设计有相通之处都强调顶层视角、分层分工、接口标准化。DFT架构同样不是单点工具能解决的它需要从系统架构、逻辑设计、物理实现、测试工程四个层面协同。你可以把ATE测试程序想象成“业务需求”把DFT逻辑当作“中间件”把扫描链当作“系统接口层”把工艺库当作“基础设施”。这样类比后你会发现DFT架构设计的核心挑战并不是某个工具用得好不好而是各层之间的接口是否清晰、有没有冗余依赖。3. 实操过程与核心环节实现3.1 环境准备与工具安装的避坑记录开工之前先把工具环境弄干净。Synopsys工具安装是很经典的坑位集中区尤其新手在Linux环境装VCS或DFT Compiler时最常见的报错是缺少Tcl/Tk库。我遇到的典型报错是这样的$ vcs -version vcs: error while loading shared libraries: libtcl8.4.so: cannot open shared object file: No such file or directory这个问题的根源是VCS运行时需要Tcl库但系统里要么没装要么路径不对。解决方法不是去网上乱下lib而是先确认你装的是哪个版本因为不同版本的VCS依赖的Tcl版本不一样。我第一次装VCS时图省事直接apt install tcl结果系统给我装的是Tcl 8.6而VCS找的是8.4还是报错。正确做法是先确认VCS发布包里的linux distribution说明看它对应支持哪几个Tcl/Tk版本。再把Tcl库的路径加到LD_LIBRARY_PATH环境变量里并且LD_LIBRARY_PATH的优先级要在PATH之前。实在找不到对应版本可以软链接顶上去但不保证所有功能都稳定。另一个高频坑是license配置。新手的习惯是拿到license文件直接设LM_LICENSE_FILE但Synopsys的license管理方式对hostname和MAC地址绑定很敏感。如果你换了网卡或者改过hostnamelicense就失效。建议把SNPSLMD_LICENSE_FILE和LM_LICENSE_FILE都设成指向同一个license server同时确认hostname和license文件里的SERVER行一致。Mentor Tessent这边相对干净它主要依赖Linux原生的libstdc和libX11装的时候重点检查32位兼容库是否装了因为部分老版本的Tessent GUI界面依赖32位库。如果你用的是新版本Tessent 2023以后对64位库的支持已经很完善了麻烦少很多。3.2 用DFT Compiler做Scan Insertion的完整流程以前项目里的经验用Synopsys DFT Compiler做scan insertion大致分四步。第一步读入设计数据。这里不建议直接用.v网表最好用综合后的.ddc格式因为它保留了逻辑综合时的时序约束和属性信息DFT Compiler对时钟、复位这些关键pin的理解更准确。如果没有ddc也可以读.v文件但要额外补充current_design、link这些命令来建立设计上下文。第二步配置DFT信号。用set_dft_signal命令把test mode、scan clock、scan enable、scan in、scan out这些端口定义清楚。这个阶段最重要的动作是告诉工具“哪些信号是测试专用的”。很多新手的错误是只定义scan clock和scan enable忽略了test mode结果工具默认所有功能模式也跑scan逻辑做DRC时冒出一堆violation。我自己常用的定义方式是这样set_dft_signal -view spec -type ScanClock -port clk_test -timing [list 10 20] set_dft_signal -view spec -type ScanEnable -port test_se -active 1 set_dft_signal -view spec -type TestMode -port test_mode -active 1 set_dft_signal -view spec -type ScanIn -port test_si -hookup_pin U_TOP/U_DFF/Q set_dft_signal -view spec -type ScanOut -port test_so这里的-view spec表示当前是规格定义阶段后续还要用-view existing_dft来告诉工具哪些DFT逻辑已经存在。两套视图不混淆是工具正常工作的前提。第三步配置scan chain。用set_scan_configuration设定chain数量、chain length、share scan in/out等参数。假如设计有4个clock domain我一般配置4条chain每条chain长度控制在2000到4000个scan cell之间这个范围是综合工具和布线工具都比较舒服的区间。第四步执行insert_dft然后跑DRC检查有没有scan chain broken、clock conflict、uncontrolled pin这类问题。DRC过了之后DFT Compiler会输出一个带扫描链信息的网表并且生成spf文件STIL Procedure Format的变体这个文件是后面TetraMAX生成pattern时的重要输入。3.3 用TetraMAX生成和仿真ATPG PatternTetraMAX的输入主要有三个DFT Compiler输出的网表、测试协议文件spf格式以及库文件。库文件指标准单元库里每个cell的测试模型通常在综合库目录下有个.v格式的测试库名字类似tcbn28hpcplusbwp7t30p140ssg0p81v125c_120a_ccs_test.v。这步别漏漏了TetraMAX报“cell not found in library”基本是必然的。TetraMAX推荐用脚本模式跑因为后端迭代时pattern数量大GUI点来点去效率太低。核心脚本如下read_netlist $env(DESIGN_NETLIST) run_build_model $env(DESIGN_NAME) add_clocks 0 clk_test -shift 0 add_clocks 0 clk_test -capture 1 add_scan_enable test_se -active 1 add_scan_groups $env(SCAN_GROUPS) run_drc run_atpg -auto_compression run_atpg -auto_compression -coverage estimate write_patterns output_pattern.wgl -format wgl write_patterns output_pattern.stil -format stil write_faults detected_faults.list -format list这里-format wgl是生成给Tessent/UltraFlex用的波形格式-format stil是通用标准测试接口语言格式给其他ATE设备用。实际项目里两种格式都要保留因为流片后可能换测试设备。TetraMAX跑完后要重点看两件事fault coverage和pattern count。fault coverage一般要求99%以上对可测故障如果达不到先不要急着加pattern而是去查DRC violation大概率是某些模块的约束没加全。pattern count决定测试成本压缩参数-auto_compression可以帮你把pattern数量压下来但它牺牲的是运行时间所以一次完整ATPG可能要跑好几个小时。3.4 用Tessent MemoryBIST搞定SoC里一堆SRAM如果说scan chain的难点在于时钟和物理布局那memory的难点就在于“数量多、类型杂”。一个中等规模的SoC里可能有几十上百个SRAM实例每个的端口、位宽、深度都不同。如果每个memory都手工包一个BIST wrapper累死不说还容易出错。Tessent MemoryBIST的价值就在这里——它能自动识别memory的类型并生成对应的controller和wrapper RTL。操作流程大致分三块第一块准备memory模型库。Tessent要求每个memory都有对应的.lib描述文件里面定义了memory的端口名、位宽、地址范围、读写时序。拿到foundry的memory compiler输出后需要转换成Tessent MemoryBIST认识的格式。这一步本质上是一个脚本化过程但新手第一次做很可能忘记检查memory是否支持“column mux”隐藏的冗余位导致生成的wrapper逻辑和多bit操作对不上。第二块定义BIST配置。通过Tessent shell交互式命令或者脚本方式指定哪些memory做BIST、用什么算法、group怎么分。典型脚本如下set_context dft_spec -from_specification create_bist_protocol -file bist_protocol.txt create_pattern -type memory set_bist_configuration -memory_list sram_a sram_b -algorithm march_cw run_bist_insertion其中march_cw是一种涵盖常见故障模型的算法适合快速分析。如果芯片测试要求更高就换march_ss或march_lr但pattern执行时间会长一些。第三块把生成的BIST RTL与主设计集成。这一步的重点是注意BIST controller的复位信号和时钟信号必须受test mode约束控制确保功能仿真时BIST逻辑完全关断。有些设计因为“最小改动”就把BIST clock直接接到功能clock上结果综合后clock tree有大量skew到测试阶段才暴露非常被动。3.5 共享总线场景下的DFT实现示例前面讲到共享总线DFT的思路这里补充一个可操作的流程。假设芯片内部有一条AHB总线两个master三个slave要在测试模式下直接把master隔离掉然后对slave做scan访问。第一步在master接口的地址、数据、控制信号上分别插入isolation cell。Tessent和DFT Compiler都有自动插isolation的标准命令DFT Compiler也可以用set_isolate_ports指定。第二步加test mode - 通过一个复用端口选择功能模式和测试模式。在测试模式下isolation cell输出固定为0master驱动不了总线避免总线竞争。第三步在总线的slave端接入scan test的观察点这样一来scan in的刺激可以通过测试端口直接进到slave内部slave的响应也能通过scan out直接观测。实际项目里AXI总线的DFT处理比AHB更复杂因为AXI有多个channel每个channel都有独立的valid/ready握手信号。处理不好的话ATPG工具生成的pattern在仿真时会出现握手超时导致覆盖率上不去。我的经验是AXI总线的DFT模式中要把valid信号拉高、ready信号拉低强制让总线进入“从设备响应”的稳定状态避免功能握手逻辑干扰测试路径。如果你在配合Synopsys AXI VIP做验证想关闭事务级的打印输出可以在VIP的配置里通过$s_axi_verbosity 0方法来降低打印量这和DFT中“屏蔽复杂协议、聚焦关键信号”的思路是一致的。4. 常见问题与排查技巧实录4.1 DRC Violation的三大高频原因DFT Compiler和TetraMAX都会跑DRC常见的高频violation基本集中在三类。第一类scan cell不受时钟控制。报错信息一般是“clock not controlled”或“clock can not propagate”。原因通常是测试时钟的约束没加完整或者功能时钟和测试时钟之间的mux没有被test mode信号控制。解决方法是返回set_dft_signal重新定义时钟关系同时检查dft_clock_controller是否已经插好。第二类scan enable路径存在组合逻辑。正常设计里scan enable信号必须是从端口直接进来的高扇出信号中间不能经过任何组合逻辑。如果综合时优化把scan enable路径上的buffer挪走或者合并就会出现这个报错。解决方法是在综合脚本里加set_dont_touch约束把scan enable路径保护起来。第三类share scan in/out的端口冲突。有的芯片引脚紧张会把多个scan chain的输入共享到一个端口。DFT Compiler支持share_scan_in配置但如果多个chain的长度不一样工具会插一个rebalance逻辑来对齐这块逻辑在DRC时容易报乱。建议项目前期规划好chain长度尽量等长。4.2 Pattern仿真失败的排查思路ATPG生成的pattern在VCS里仿真时最让人头大的就是“timing violation”和“X态传播”。X态传播的经典场景某个寄存器在shift阶段没有被正确初始化导致capture阶段产生的响应值是X最终和TetraMAX预测值比上不。排查这个问题的顺序我一般这样走第一步打开VCS的波形找出第一个出现X的节点往前推看它是从哪个FF传过来的。第二步查这个FF对应的scan cell有没有被正确串进chain。如果它没有在scan_group配置文件里TetraMAX会默认它“capture时不使能”所以输出是X。第三步确认scan enable信号在capture阶段真的拉低了。很多情况下test bench激励里的scan enable时序和真实的OCC控制时序不一致导致capture阶段scan enable仍处于active状态。Timing violation的排查相对直接就是看setup/hold是哪个时钟沿之间发生的。但有一种情况很隐蔽DFT Compiler在scan insertion后输出的网表里OCC电路是基于特殊cell库实现的它的时钟路径上可能有一个额外的delay。如果VCS仿真库里这个cell的行为模型没包含准确的timing信息仿真就报violation但真实芯片其实没问题。这个问题的标准解法是对OCC cell做set_false_path约束在仿真阶段不从OCC输出端检查timing而是直接看功能路径。4.3 工具安装和脚本运行的环境问题速查结合我自己的踩坑经历把Synopsys和Mentor工具环境问题整理成速查表项目遇到时直接对着查。症状可能原因解决方法libtcl8.4.so找不到系统Tcl版本不匹配安装对应版本Tcl/Tk或加入已有库路径license报错hostname/MAC地址不匹配统一hostname检查license server配置tessent图形界面起不来缺少32位兼容库安装libX11-32bit、libstdc-32bitdc_shell启动后命令卡住LD_LIBRARY_PATH里有冲突库精简路径优先保留Synopsys自带库路径VCS编译报undefined reference库文件版本不匹配重编译TEST bench或换用匹配版本DFT Compiler读不了ddc数据库版本不兼容用write -format ddc从原综合工具重新导出TetraMAX DRC全都不过测试协议文件里时钟/复位定义有误复查spf文件尤其是scan chain的spec部分这里要特别强调不同工具链之间传递文件时版本兼容性非常关键。比如DC 2022版本的ddc文件如果用DC 2020版本的DFT Compiler去读很大概率报“incompatible database”。实际项目里要么统一工具版本要么用.v格式做中间接口虽然会丢一些属性但至少能跑通。4.4 覆盖率优化的独家技巧新手的常见误区是一味增加run_atpg的迭代次数其实覆盖率瓶颈往往在信号可控制性上。我的经验是优先检查这三块复位信号、异步置位信号、输出使能。复位信号的问题如果某个模块的复位在测试模式下一直被拉高那么这个模块的DFF永远无法进入已知状态覆盖率肯定上不去。解决办法是在测试模式下把全局复位信号放开让TetraMAX能控制它。异步置位信号的问题某些DFF有异步preset端口如果测试模式下preset不受控可能会导致整个scan chain的值被强制翻转。建议对这类cell做set_dft_signal -view spec -type Reset约束明确指定它在shift阶段是无效的。输出使能的问题大量三态IO的逻辑会使ATPG工具很难控制总线上的驱动方向。可以给每个三态IO加一个测试模式下强制使能的MUX这样工具能直接看到输出值。4.5 shared bus DFT的边界条件处理shared bus DFT时除了常规的isolation cell还要特别注意仲裁器的测试覆盖。仲裁器本身是一个状态机如果测试模式下你把所有master都隔离掉了仲裁器实际上变成“无输入请求”状态它的状态转移就覆盖不到。解决方法是保留一个master通道作为测试通道测试模式下由外部测试逻辑模拟一个固定的请求序列驱动仲裁器走一遍状态转移把仲裁器内部的故障覆盖住。这块在架构设计文档里要写明“bus test observer policy”我在项目里一般会规定每个共享总线必须支持两种测试路径一是“旁路测试”路径bypass测试模式下直接访问slave二是“仲裁参与”路径通过固定请求序列测试仲裁逻辑。具体到Tessent和TetraMAX的实现前者靠isolation cell完成后者需要额外加一条测试专用的master接口。从物理实现角度看shared bus上的DFT逻辑往往会把几条原本很干净的bus线变成被隔离逻辑插碎的线网这会影响布线后的时序收敛。所以做bus DFT时DFT脚本里一定要加set_dft_signal -view spec -type Constant的约束让工具把测试专用的控制信号直接接到固定电平这样综合工具做逻辑优化时不会大量重复插入buffer。5. 从架构设计到测试落地的完整链路5.1 架构文档必须包含哪些内容DFT架构设计不是跑几个工具脚本就完事的它需要有文档沉淀。我建议架构文档里至少包含测试模式定义与转换机制、时钟/复位测试方案、扫描结构与chain规划、存储器BIST策略、IO/总线测试策略、测试功耗预算、覆盖率目标、ATE测试流程与pattern格式。其中测试模式定义这部分容易被忽略但它直接决定工具怎么理解设计。建议用下面的表格把每个模式的关键信号状态列清楚。测试模式test_modescan_enableMemoryBIST_en功能时钟/测试时钟用途Normal0X0功能时钟正常工作Scan shift110测试时钟移入/移出数据Scan capture100OCC脉冲捕获故障响应Memory BIST1X1测试时钟SRAM测试IO loopback1X0测试时钟引脚级测试5.2 从RTL到ATPG的集成流程完整流程可以串成一条链RTL设计 → 插入DFT逻辑DFT Compiler/Tessent → 逻辑综合DC → scan insertion验证 → ATPGTetraMAX → pattern仿真VCS → 物理实现ICC/Genus → signoff。这里的顺序非常重要如果你已经先做完了物理综合再回去插scan chain工具要做ECOEngineering Change Order修复效率极低。所以业界标准做法是DFT insertion放在逻辑综合之前的RTL阶段也就是pre-mask DFT。RTL阶段插入DFT逻辑的另一个好处是功能验证环境可以直接覆盖测试模式的某些路径。比如你可以写一个testbench在test_mode1时把scan chain当成一大串移位寄存器跑一遍验证明scan_in到scan_out的连接性。这个“连接性测试pattern”在流片后的bring-up阶段非常有用是判断芯片是否“活着”的第一条测试向量。5.3 与物理实现阶段的衔接要点很多DFT工程师对物理实现阶段没有太多感知但恰恰是物理实现阶段的时钟树综合CTS对DFT影响最大。由于scan chain上所有cell都需要共用一个测试时钟树如果测试时钟树的平衡做得不好shift阶段会出现大量的setup violation。我的经验是在CTS之前就告诉物理实现工程师哪些是测试时钟要求CTS时把测试时钟和功能时钟分开建立树并在PPA之外额外评估shift模式下测试时钟的skew。所有的OCC输出端要做set_clock_group -logically_exclusive约束从而在物理实现时综合工具会自动优先处理功能时钟路径。另外scan chain的物理走线最好位于芯片的中间层避开高速IO区域和模拟模块附近的噪声源这条经验对于混合信号芯片尤其重要。6. 新手实践路线与避坑提醒6.1 学习路径建议如果你是零基础开始学DFT不要一上来就把所有工具都装上我的建议是分三步走。第一步先把DFT的基本概念吃透比如scan cell的类型、OCC的工作原理、fault模型stuck-at、transition等。没有这些基础你写出来的set_dft_signal就是无源之水。第二步选一条最简单的设计比如一个3位的计数器用DFT Compiler完整跑一遍scan insertion再用TetraMAX生成pattern并在VCS仿真通过。这个“最小可用流程”能帮你建立对工具链的整体认知。一个计数器设计可能只需要几百个scan cell但流程切得越多越能暴露工具之间衔接的问题。第三步在此基础上逐步增加复杂度比如加入一个SRAM加Tessent MemoryBIST或者加入一条共享总线加isolation cell。每加一个模块就多跑一轮DRC和ATPG把错误类型记录下来形成自己的“DFT避坑手册”。我见过不少工程师跳过了前两步直接拿一个大型SoC练手结果调试了整整一个月连基础脚本都还没理顺。DFT是一个非常依赖经验积累的领域你需要大量的失败案例来建立“错误模式识别”的能力。6.2 时间规划与常见误判按一个中型芯片项目来算DFT的相关工作量大致分布如下架构设计约20%的时间RTL阶段DFT逻辑插入约25%scan insertion和ATPG约30%物理实现阶段的DFT约束同步约15%流片前pattern signoff约10%。如果你发现ATPG这一步占掉了50%以上的时间说明前面的DFT架构设计大概率出了问题。新人最常见的三个误判一是以为scan chain越多越好结果测试功耗爆掉二是以为DRC过了就万事大吉结果忽略了scan chain在物理实现阶段的布线拥塞三是以为memory BIST是一种“附加功能”结果没有提前考虑BIST controller的复位和时钟导致芯片流片后BIST一跑就复位抖动。6.3 流程自动化的经验我后来在团队里推行的做法是把整个DFT流程做成一个基于Makefile的自动化流水线每跑完一个步骤自动生成报告出现错误时自动存档日志。这个做法不一定适合所有团队但如果你经常要处理多版本、多项目花两天时间搭这套自动化是值得的。自动化流程的核心理念每个步骤的输出都要有明确的“可检查的中间产物”比如scan chain报告、DRC报告、coverage报告。不能只看最终生成网表有没有跑完因为工具“跑完”和“跑对”是两码事。7. 我的体验DFT架构设计的真正难点在哪里做DFT多年我越来越觉得工具命令和脚本只是术的层面真正难的其实是架构权衡。比如scan chain数目和测试时间的权衡需要你同时了解ATE测试成本、芯片量产数量和芯片面积预算。比如memory BIST到底做单bank还是多bank既影响故障覆盖率也影响测试时的并行度和功耗。再比如共享总线上的isolation粒度细了面积大粗了覆盖率低。这些决策没有一个公式能直接给出答案它依赖的是你对具体设计的理解和对最终产品的测试需求的判断。个人体感上和ATPG覆盖率相比你更应该关注的是“测试方案的可执行性”与“DFT逻辑对功能路径的侵入程度”。有些团队刻意追求99.9%的覆盖率为此插入了大量DFT逻辑结果功能路径上多了几百个mux时序收敛变得异常困难流片回来的芯片功能性能反倒退步了。DFT设计的目标是在合理面积、功耗和时序代价下拿到足够高的故障覆盖率而不是为了一个数字牺牲整个芯片的可用性。我建议刚入行的工程师不要只盯着TetraMAX跑出来的coverage数字多去想想“这条fault如果真在芯片上出现了它会被测试pattern抓到吗”这个问题才是DFT设计真正的起点。