芯片测试工程师的日常，基本就是在“覆盖率”和“测试时间”两堵墙之间找缝隙。最近我调了一个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时的思路。
