芯片测试工程师的日常基本就是在“覆盖率”和“测试时间”两堵墙之间找缝隙。最近我调了一个Tessent Shell环境下的Hybrid TK/LBIST流程花了整整三个晚上才把覆盖率从93%拉到99.1%同时让ATE上的每颗芯片测试时间压掉了差不多三分之一。写这篇文章的起因就是这三天把思路、结构、命令骨架和踩过的坑都记下来给后面做同类项目的朋友当个参照。先说明一个容易混淆的点这里的TK指的是Tessent TestKompression也就是测试压缩技术不是Linux桌面上那个Tk图形库。在Tessent Shell环境下把TestKompression和Logic BIST放进同一个DFT架构里跑就是标题里说的Hybrid TK/LBIST流程。它解决的问题很直接DFT工程师在项目量产阶段既想保住覆盖率又不想让测试时间失控。成本压力一上来单纯堆scan pattern这条路走不通就得换一种组合思路。这种流程适合谁一个是做大SoC或车规芯片的DFT工程师一个是正在评估BIST方案但不敢把确定性测试全部丢掉的团队。如果你只是做几十万门的小芯片老实跑scan加压缩就够了没必要把LBIST控制器的面积背上去。但如果芯片有几百个时钟域、功耗又敏感LBIST带来的片上自测能力是贵价ATE和普通压缩测试都替代不了的。下面我按“为什么做、怎么准备、怎么实操、怎么排查”四块展开。1. 为什么把TK和LBIST放在一起做Hybrid流程的思路拆解1.1 拆开看TK是“精测”LBIST是“粗筛”测试压缩TK本质上是把ATE提供的压缩激励在片上展开又把几百根扫描链的响应压回很少的观察端口。它仍然是确定性测试知道每一条向量在测哪个故障所以覆盖率按点收敛没有回旋余地。具体到Tessent里TK用的是channel和解压器、压缩器这套结构pattern从ATE进来是压缩过的在芯片内部展开后灌进扫描链响应再从compactor压回ATE端。它对测试仪带宽的节省非常直接。Logic BIST的逻辑完全不同。它靠片上PRPG生成伪随机向量MISR把响应压缩成签名几乎不依赖ATE适合高速启动、系统自检和老化监控。但伪随机向量测随机抗性故障的效率很低覆盖率到一定水平就上不去了。我见过很多项目跑到92%到94%就开始停住再加几百万条pattern也只能涨零点几个点性价比极低。所以两者解决的问题其实不是一个维度。TK要的是覆盖率可预期、可收敛LBIST要的是脱离ATE也能跑、能以低成本快速筛掉明显坏片。Hybrid流程就是把“粗筛”和“精测”放进了同一套扫描资源和同一次Tessent Shell流程里而不是做两张网表、两套逻辑、两次时序收敛。如果分开插先不说面积翻倍光两个DFT结构在扫描链上的争抢就会把后端同事逼疯。我一开始上Hybrid的动机很朴素新项目良率还不太稳想在生产测试的早期阶段先用LBIST的快速模式做粗筛把明显坏的芯片尽早打掉再做几轮TK的确定性压缩测试把覆盖率顶到目标值。这个顺序在Tessent Shell里可以用同一个common DFT环境表达不需要维护两套独立的插入流程项目后期的ECO也不会把两边改得不一致。1.2 节省测试时间是怎么算出来的这是一个经常被想简单的地方。LBIST粗筛一条pattern不依赖ATE装载速度快慢主要看片内时钟频率和pattern cycle数。假设LBIST跑一段200万cycle的子序列片内测试时钟100MHz那段测试就是20ms。TK模式看起来压缩比高但每条pattern还是要通过ATE加载遇到数据率受限的测试仪时间立刻显形。我常用的粗算模型是看ATE上每颗芯片的pattern volume乘上行带宽再对比LBIST的cycle count和片内时钟频率。假设TK压缩比做到100倍但pattern volume仍然是20Mbit级别在200Mbps单通道上就是100ms以上。如果LBIST能在20ms内先粗筛掉一批坏片剩下只有一部分芯片需要跑完TK精测那么平均测试时间就能大幅下降。这里的关键结论是Hybrid方案不是用LBIST顶掉TK而是用LBIST快速吃掉容易测的故障把TK pattern集中打剩余故障。等到了覆盖率99%的阶段TK向量量会比单独跑TK少很多因为相当一部分故障已经被伪随机模式覆盖掉了。知道了这个计算逻辑你才不会对着覆盖率报告拍脑袋也不会盲目地把LBIST sequence拉到巨长。1.3 不是所有项目都适合上Hybrid一定要把“适合”二字放在前面讲因为我在多个项目里见过为了追热点把面积和流程复杂度一起背上身的情况。LBIST控制器、PRPG、MISR、相位器、观察点这些硬件不是白送的面积可能增加百分之几在小芯片上占比尤其明显。如果测试接口带宽已经很富裕、测试时间又不敏感那TK单独跑可能是最优解。反过来如果项目有在线自检、安全启动或车规在系统诊断需求LBIST几乎是绕不开的如果芯片管脚非常紧张test port不够用那么TK压缩和LBIST共用观察端口的Hybrid结构就显得很划算。我自己的判断标准是量产数量大、良率不稳定、ATE资源按小时计费的项目Hybrid值得做研发样片、量级不大、覆盖率压力主要在scan那一边的先把TK做好就够了。2. Tessent Shell环境下搭建Hybrid流程的硬件与配置准备2.1 Tessent Shell在流程里的定位Tessent Shell不是一个单独的测试工具而是整个Tessent DFT环境的交互入口。你可以把它理解成一个以Tcl为骨架的“总装车间”读入网表、定义内部扫描模式、插入LBIST/TK结构、生成pattern都在同一个shell session里完成。对Hybrid流程来说最大的好处是TK和LBIST共享同一个顶层配置、同一组时钟约束不用在两个工具之间导CTL文件再对齐。由于Tessent Shell依赖Tcl/Tk这一层实操里经常遇到Linux环境问题。很多服务器上缺libtk或版本不对GUI起不来命令行模式倒是没事。这个我放到最后专讲但提前说一句真到量产项目能不依赖GUI就别依赖GUI脚本化跑批才是常态。在开始插入之前我建议先把netlist的读入顺序固定下来。最稳的做法是先读库再读RTL或网表最后读已有的DFT结构。如果设计里有memory我会单独加memory BIST的替换库防止LBIST模式里黑盒memory的输出跑到MISR里去污染签名。2.2 动手前要确认的5个结构项第一扫描链分配。TK和LBIST共用物理扫描链所以扫描链的数量、长度和测试时钟域划分要提前统一。链长差异不要超过两倍否则短的链在等长的链跑完之前一直在空转。第二复位策略。LBIST要求可控的异步复位MISR必须在一开始清零。如果复位依赖某个不可控的PLL锁定信号那LBIST模式里就会冒出一堆X态。第三时钟控制。TK用ATE时钟LBIST可能用片上PLL的慢速分频时钟二者之间要有一个可靠的时钟切换结构最好在仿真里能覆盖到。第四X态屏蔽。TK模式下需要x-tolerant压缩器LBIST模式下需要屏蔽逻辑或观察点隔离否则黑盒逻辑会毁掉MISR签名。第五是shadow register与wPPI观察点用来把内部状态搬到观察端口。这对覆盖率收敛非常关键因为很多内部节点的故障只能通过观察点检测到只靠扫描链捕获是远远不够的。这5项里最容易漏的是复位。我见过不止一次LBIST跑出来的signature每次都不同查了半天是某个复位信号在BIST模式下没有固定死。复位问题不解决后面所有覆盖率数据都没有意义。2.3 我建议的插入顺序我的推荐顺序是先把TK需要的channel和compressor、decompressor结构建好再把LBIST控制器和PRPG挂在它旁边最后才去接观察点。理由很简单TK插入时要做比较严格的X态分析和时序收敛后插入的东西越多分析越乱LBIST的插入重点是控制器的状态机和安全逻辑对扫描链的影响相对可控。先难后易报错少。另一个容易被忽略的顺序问题是pattern generation的顺序。TK和LBIST的pattern虽然可以在同一个Tessent Shell里出但建议先出LBIST的伪随机pattern。用LBIST先跑一遍用报告确认哪些故障是随机抗性的再让TK做针对性确定向量能省掉大量无效pattern。顺序反过来TK向量会庞大到你怀疑人生。3. 实操一次Hybrid TK/LBIST流程的关键步骤与脚本骨架3.1 启动Tessent Shell并读入设计下面这个脚本是流程骨架不是某个版本的完整可用文件命令名在不同版本里可能有细微差异。核心是让第一次看的人知道每一步在干什么。# 1. 启动Tessent Shell后先建session set_session_mode dft # 2. 读工艺库和目标网表 read_library -file ./data/tsmc28_base.lib read_verilog -file ./data/top_netlist.v set_top_design top # 3. 设计目录和报告输出 set_output_dir ./output/hybrid_run1这里有个实际经验不要把set_output_dir放太晚。我就吃过亏在脚本最后才设输出目录导致中间生成的insertion报告散落在一堆默认路径里排查问题时非常头疼。Tessent的中间结果本来就散越早把工作目录固定下来越好。另外如果服务器上有多个Tessent版本环境变量没设置好的话可能读到旧版本的库文件。养成在脚本开头打印version的习惯能省掉很多“为什么报告格式不一样”的疑问。3.2 时钟、复位和扫描链的配置接下来是定义时钟和扫描模式。这一步在Hybrid流程里尤其重要因为最终要同时产生TK模式、LBIST模式两组内部模式。# 4. 定义时钟和复位示意 add_clocks -name func_clk -period 10.0 add_clocks -name atpg_clk -period 20.0 add_async_reset -name main_reset # 5. 定义扫描链 add_scan -name scan1 -clock func_clk -flop 4000 # 6. 定义模式 add_pattern_mode -name hybrid_tk add_pattern_mode -name lbist_mode注意我给的是示例真实版本里命令选项会更多。实操时你会在add_clock下面看到一堆SDF、库单元、锁存器相关的选项不要偷懒跳过因为TK对时钟沿非常敏感。LBIST模式下如果时钟不是均匀分频的覆盖率报告会骗人因为很多capture沿其实是坏的。时钟和复位定义完之后我习惯先跑一次report_clocks确认每个时钟域的时钟组关系。Hybrid流程最大的坑之一就是时钟域之间没有约束好导致LBIST模式里A域的scan enable到了B域还没稳定。3.3 插入TK和LBIST结构插结构时先插TK再插LBIST原因前面说过。可以简写为# 7. 插入TestKompression insert_tk -channels 8 -compactor xcompact -mask_mode auto # 8. 插入LogicBIST insert_lbist -controller ctrl_lbist -clock func_clk \ -prpg primary,secondary -misr top_misr \ -phase_shift auto # 9. 建立TK和LBIST共享的测试接口 connect_test_interface -port tdi -used_by {tk lbist} connect_test_interface -port tdo -used_by {tk lbist}我的实际经验是insert_lbist的选项里务必确认phase_shift不是默认disable。相位器是LBIST覆盖率的关键之一PRPG pattern如果没做好相位偏移多根扫描链之间会高度相关覆盖率掉好几个点。可以在生成结构后先跑一次短pattern用LFSR correlation报告看扫描链之间是否足够独立。channel数量的选择也要讲究。8个channel看着不多但如果内部有800条scan chain那么每条chain的装载率会被拉得很低压缩比上去了pattern数量可能反而涨。我会先用工具默认值跑一版然后按覆盖率增长速度决定是加channel还是减channel。3.4 生成pattern并收敛覆盖率结构插完生成pattern就相对机械# 10. 先生成LBIST pattern做粗筛 run_lbist_pattern -length short -save_signature true # 11. 分析未覆盖故障生成TK确定性pattern run_tk_pattern -target_faults remaining -max_volume 2M # 12. 汇总覆盖率报告 report_coverage -mode hybrid_tk -detail report_coverage -mode lbist_mode -detail真正要花时间的不是命令而是覆盖率收敛。第一次跑完大概率看到LBIST模式覆盖93%左右、TK模式补几个点但离99%还有距离。这时候我会先看uncovered fault report里面有大量的随机抗性故障集中在某个模块或某条总线。绝大多数情况下加几十个内部观察点要比加几百万条pattern划算得多。观察点设在哪些寄存器输出上核心原则是覆盖率贡献大、布线代价小、不会引入X态往后传的点。设计里的译码器输出、状态机次态寄存器、跨时钟域同步器的输出都是好的候选。反过来带预置位或清位的寄存器输出要小心它们的初始化行为可能在不同的test mode里不一样。另外覆盖率报告里的test pattern count要留意。LBIST的pattern count对应的是sequence数量TK的pattern count对应的是compressed vector数量两个数量级完全不同。给项目组汇报时不要混着说否则别人会以为LBIST只跑了几十条pattern不靠谱。4. 覆盖率不增长测试时间变长排查与调优实录4.1 典型问题速查表这张表是我在Hybrid流程里遇到频率最高的几类问题按出现概率排序现象可能原因排查思路与解决LBIST覆盖率卡在93%附近不动PRPG伪随机pattern对随机抗性故障失效增加观察点/控制点更换seed启用phase shift对关键模块做约束细化TK向量数量爆炸剩余故障太多且缺少X态约束先查uncovered report排除X态问题给memory和模拟模块设黑盒提高观察点覆盖率TK和LBIST模式时序互相冲突两个模式对scan enable和时钟约束不一致分开定义mode给各自时钟做set_case_analysis不要用一个SDC硬扛MISR签名每次都不一样复位不可控或黑盒逻辑产生X态检查复位与时钟同步在LBIST模式里加X态屏蔽确认读入memory的行为模型同一条扫描链在TK里正常、LBIST里抖动链上时钟门控或低速时钟切换异常加仿真波形比对两条链的launch/capture时序检查clock controller配置这张表不能当万能药但能让排查少走弯路。尤其第一行我几乎每两个项目就能遇到一次而且每次原因各不相同。有时是观察点加太多反而引入相关性这个坑很大观察点太多意味着PRPG随机pattern被约束得过了头覆盖率不仅不涨反而掉。4.2 我自己的三层调试顺序我习惯的调试流程分三步顺序不能反。第一层先查硬件结构跑report_scan和report_lbist看扫描链长度、观察点数量、PRPG项数先排除最笨的配置错误。以前有段时间我怀疑覆盖率上不去结果是某条扫描链长度是别人的三倍导致整个pattern volume失衡方向一开始就错了。第二层查时序和X态跑带仿真波形的short pattern确认MISR里的首个值不是X确认scan enable在capture edge前有足够的建立时间。如果这一层有问题后面所有覆盖率数据的可信度都要打折。先定“测量是否可信”再谈“为什么低”。第三层才做优化根据uncovered fault在模块上的分布决定加观察点、加约束还是换seed。顺序反过来会很浪费时间我在早期就干过先换来换去seed最后发现是X态污染的坑。覆盖率问题一旦涉及X态你不先堵住它怎么调都是白费。我还会用一个更直觉的判断方法看覆盖率曲线的斜率。如果LBIST跑到一半斜率急速下降说明随机pattern已经接近饱和再用LBIST去堆pattern没有意义如果斜率从头到尾都很平那往往不是随机抗性故障问题而是结构性问题比如相位器配置错误或扫描链分组不合理。4.3 Linux环境与Tcl/Tk库版本问题最后说一下热度很高的Linux和Tcl/Tk问题。Tessent Shell本身是Tcl驱动的某些操作界面会用到Tk。很多项目在安装或迁移服务器后启动tessent -shell时报错常见关键词是libtk、libXft、symbol lookup error之类。我处理这类问题的顺序是先看是不是32位/64位库混装然后确认LD_LIBRARY_PATH里没有把另一个版本的Tcl/Tk目录放在Tessent自带库之前最后是干脆不开GUI全部在脚本模式跑。实际项目里90%的这类问题可以用命令行模式绕过去。我没见过哪家产线每天开着GUI去点按钮跑DFT的脚本化才是正经出路。你在共享服务器上尤其要注意系统管理员装的Tcl/Tk和Tessent需要的版本经常不一致。处理手段是写一个干净的env脚本把Tessent需要的PATH、LD_LIBRARY_PATH、LM_LICENSE_FILE固定下来别让用户自己改。这个问题看着小但真能把排产排到一半的流程卡死。Tessent Shell执行过程中如果遇到dofile路径里有中文或带空格也会出现一些奇怪的加载错误。虽然看起来和Tcl/Tk无关但本质上都是命令解析环境的问题。项目目录命名我一般强制用英文加下划线日志会干净很多。写在最后的一点个人体会回到Hybrid TK/LBIST我最大的体会是不要把它当成一个“二选一”的技术博弈而是一个如何分配资源的问题。TK是你手里最高精度的武器LBIST是最快的大范围清场工具让谁先上、让谁补枪完全看你当前项目的覆盖率缺口和测试成本公式。我在实际项目里最后固定下来的组合是LBIST短跑粗筛低覆盖率区间TK在88%到99%这个区间针对性补跑出来效果比单独跑任何一边都稳。最后再分享一个小技巧在Tessent Shell里做Hybrid时把观察点的选择和覆盖率报告放在同一个session里反复迭代不要每次改动都从头读网表。Tessent Shell的增量更新能力比想象中好用能省下大量调试时间。覆盖率这活本质上比的是耐心和定位问题的顺序技术细节大家都在同一水平线差的只是那几天debug时的思路。