DFT测试压缩核心参数：SSN Bus Width与EDT Channels选型指南

1. 为什么要重新审视SSN Bus Width与EDT Channels做DFT做了快十年我见过太多项目在测试压缩配置上“能用就行”结果到了量产阶段被测试时间拖到怀疑人生。SSN Bus Width和EDT channels这两个参数表面上看只是工具里的几个下拉选项实际上它们直接决定了你的测试数据量、测试时间、甚至后端物理实现的收敛难度。先说清楚一个容易被混淆的概念SSNSmartScan Network是Synopsys TestMAX DFT工具里的高压缩扫描架构而EDTEmbedded Deterministic Test是DFTMAX里的核心确定性测试压缩引擎。两者都能实现测试压缩但在总线宽度、时钟方案、物理实现策略上完全是两套逻辑。SSN更强调“总线化”的扫描数据传输总线位宽可选1/2/4/8/16/32等EDT则更依赖channel通道数量与内部解压缩器decompressor的匹配关系。什么是SSN Bus Width简单说它是SSN架构里主机host与内部扫描链之间的并行数据传输宽度。位宽越大单个时钟周期能灌入的内部扫描数据就越多等效压缩比也随之提升。但千万别以为位宽越大越好——物理实现时布线拥塞、电源压降、串扰噪声都会随着位宽上升而变得棘手。我在一个28nm的项目上就吃过亏把SSN bus width从8调到16测试时间倒是砍了三分之一结果后端反馈timing收敛难了好几个量级最后只能回退。EDT channels则是指连接ATE自动测试设备通道与芯片内部EDT逻辑之间的外部测试通道数。channels的数量通常受限于封装的pin数和测试机的通道数一般项目中会设置为2/4/8/16。EDT channels和内部扫描链的比例决定了理论最大压缩比。比如你内部有100条扫描链外部只有4个EDT channels那么理论压缩比就是25倍但实际还要扣除test pattern的同步与响应采集开销。一句话总结SSN Bus Width管的是“内部总线多宽”EDT channels管的是“外部通道多少”两者共同决定了测试压缩系统的整体吞吐能力。这篇文章我会结合真实项目的配置过程把这两个参数的选型思路、配置命令、常见坑全部过一遍。2. 核心思路与选型逻辑先搞清楚你的瓶颈在哪里2.1 测试时间瓶颈计算公式从猜到算在动手配置之前我建议你先做一个简单的数学估算别凭感觉。测试时间T的估算公式可以简化为T (Pattern_Count × Pattern_Length) / (EDT_Channels × Shift_Frequency)每个变量背后都有实际意义。Pattern_Count是测试向量数量它受故障覆盖率目标影响Pattern_Length是每条向量的移位长度直接关联内部最长扫描链的长度Shift_Frequency是你的测试时钟频率受限于ATE能力、芯片功耗和SSN总线的时钟方案。举个例子假设你有10万条pattern每条长度10000个时钟周期EDT channels为8shift频率50MHz那么理想测试时间就是100000×10000/(8×50×10^6)2.5秒。听着不多那你得注意这只是scan test的一部分还有functional test、memory BIST、analog test等。一个复杂的SoCscan test经常占整体测试时间的50%以上。记住这个公式之后你就明白配置逻辑不是“网上说8就配8”而是“我要把测试时间压到多少需要多少channels配合多高的频率”。2.2 SSN Bus Width与EDT Channels的协同关系SSN Bus Width和EDT channels并不是独立变量它们之间存在强耦合关系。在TestMAX SSN架构下总线位宽会直接影响内部压缩引擎的工作模式。SSN支持独立的时钟域控制可以实现“高移位频率”但高频率与宽总线放在一起对物理实现的要求会指数级上升。我的经验是这样总线位宽较窄如4或8时SSN可以跑更高的shift频率如100MHz以上因为数据线的串扰和IR drop相对容易控制总线位宽较宽如16或32时单周期传输的数据量更大但频率通常得降下来否则后端时序和功耗验收很难过。EDT channels的选型则更多受封装和ATE资源约束。比如你在做一个小型MCU项目QFN封装pin资源紧张测试通道配到4就差不多了但如果是大型SoC用Flip-Chip封装IO资源丰富配到16甚至32也很常见。关键思路是先确定EDT channels的上限由封装和ATE通道数决定再根据目标压缩比反推SSN Bus Width最后权衡shift频率和物理实现难度。2.3 工具选型DFTMAX还是TestMAX SSN很多项目组还在用老版本的DFTMAX只配EDT channels不碰SSN。如果你的项目还在使用DFTMAX且测试压缩比已经够用那不需要折腾SSN。但如果你遇到以下情况就可以考虑SSN了内部扫描链长度过长导致pattern长度大、测试时间超标需要更高的shift频率来压测试时间但传统EDT架构在频率提升上有瓶颈后端反馈扫描链布线拥塞严重希望通过总线化结构缓解。SSN相对传统EDT的优势在于它可以在不同扫描链组scan group之间动态调整时钟支持更灵活的分组测试避免“木桶效应”——传统EDT架构中所有扫描链共享同一个shift频率最长链决定了所有pattern的长度而SSN可以通过分组和总线裁剪来打破这个限制。顺便提一句如果你拿到的项目是别人做过的老设计只有EDT配置没有SSN那评估迁移成本时要考虑扫描链结构是否要重排、后端约束是否要重做、测试向量是否需要重新生成。这些事看起来不大但在项目后期做政治成本和技术成本都不低。3. 实战配置详解从Dofile到Signoff全流程3.1 SSN Bus Width配置的黄金法则SSN Bus Width的选型不是拍脑袋定的。以下是几个我实测下来比较稳的经验值按项目规模分类项目类型内部扫描链数量建议SSN Bus Width预期压缩比备注小型MCU10-50条4或810-20倍优先保证时序收敛中规模SoC100-300条8或1620-50倍折中考虑功耗与拥塞大规模SoC500条以上16或3250-100倍需后端early flow介入评估配置命令在TestMAX环境下大致是set_config -type ssn -bus_width 16但实际操作中我通常不会直接从16起步而是按照“4 → 8 → 16”逐档往上试。每尝试一档跑一遍RTL级DFT插入insert_dft查看生成的扫描链报告和测试压缩比再交给后端跑一版快速布局估时序。如果不满足就回退一档。这样虽然多花几天时间但能避免后端孤注一掷后发现物理实现过不了再回头改DFT结构的窘境。还有一个细节SSN bus width和“SSN组”的数量SSN group也有关系。同样的总线位宽4个SSN组和8个SSN组意味着不同的内部数据通路布局。组数多可以支持更细粒度的时钟控制但控制逻辑和布线资源也会增加。3.2 EDT Channels设置别让ATE通道数成为隐形瓶颈EDT Channels的设置相对直接命令大致是set_config -edt_channels 8但这里有几个容易踩的坑我详细说一下ATE通道数不要配满。很多测试工程师以为EDT channels越多越好但ATE实际能分配给scan test的通道数有限还需要留一部分给其他测试项。我的建议是EDT channels的数量不要超过ATE可用通道的75%剩下的留作备份或flexible channel。考虑测试机台的channel mixing能力。有些ATE支持不同电压/频率的通道混搭你配了16个EDT channels但如果测试机台不够先进这16个通道必须拆成两组8通道分别在两个测试头上跑又涉及test program的改动得不偿失。EDT channels与内部解压缩器的匹配度。EDT的decompressor有固定的channel宽度约束channels数配了8内部压缩引擎会按8通道来设计测试数据流。如果内部扫描链的数量不能均匀映射到这8个通道上有些通道会闲着压缩比达不到理论值。所以设置完channels后一定要检查decompressor的利用率报告确保没有严重的不均衡。3.3 完整配置案例一个28nm SoC的实测调参过程下面是我去年做的一个28nm SoC项目给大家完整走一遍配置流程做参考项目背景芯片规模约2000万门内部扫描链约420条目标测试时间压缩到2秒以内ATE可用scan通道数为12个shift频率目标100MHz以上。第一步我先把EDT channels设成8SSN bus width从4开始试。插入DFT后测试压缩比报告显示为28倍Pattern Count约8万但最长扫描链长度达到8500个时钟周期。按公式估算测试时间大约是80000×8500/(8×100×10^6)0.85秒看起来已经达标了。但这个时候我注意到报告里有一个warning内部扫描链长度分布极不均匀最长链8500最短链只有1800负载均衡很差。这会导致pattern长度被最长链“绑架”即使压缩比好看实际测试时间也会偏长。于是我做了一个操作在TestMAX里启用扫描链重排scan chain rebalancing把所有扫描链长度压制到6000至6500范围。重新生成后Pattern Count变成了6.8万测试时间估算降到0.55秒左右。第二步我试着把SSN bus width从4升到8压缩比报告升到42倍测试时间估算降到约0.33秒。但后端反馈整体布线密度上升了约8%其中高密度区域的congestion从6%升到11%有两条扫描总线路径的时序接近violation。因为这个项目对面积和功耗要求很严格我最终选择了回退到4保留0.55秒的测试时间。第三步EDT channels从8升到10。压缩比没有变但pattern数略微下降。原因是通过增加通道数测试数据输入能力变强decompressor模式切换更灵活少生成了一些用于兼容模式的pattern。最终测试时间稳定在0.5秒左右全芯片扫描测试总时间约1.8秒满足spec。这个案例的教训是SSN bus width不是越大越好EDT channels也不是越多越好一切以物理实现和测试程序的综合平衡为准。4. 物理实现阶段的关键协同DFT工程师必须懂的后端知识4.1 高bus width对布局布线的真实冲击配置SSN bus width 32时你会在后端看到一个壮观但头疼的景象32条长距离并行总线从测试控制逻辑TCK/TP蜿蜒到每一组扫描链。这些总线需要占用额外的布线资源在28nm及以下的工艺节点上尤其敏感。我在多个项目上观察到的规律是SSN bus width每翻一倍相关区域的布线拥塞指标congestion会上升3-8个百分点具体取决于设计密度和标准单元库的布线资源。更麻烦的是总线信号由于长距离并行走线相邻信号线之间的串扰风险显著增加需要后端在约束文件里加上额外的spacing rule或shielding。所以在DFT阶段就要主动跟后端沟通扫描总线的布线层约束、最大绕线长度、clock skew容忍度。不能等后端出了violation再回头改DFT那时候改的不只是配置还有整个扫描链的RTL和网表代价极大。4.2 动态时钟控制SSN频率提升的关键开关SSN与老式EDT一个巨大的差异在于SSN支持动态时钟控制Dynamic Clock Control允许在测试过程中按组启用或关闭扫描时钟。这意味着不同扫描链组可以在不同的时钟周期进入移位模式打破同步扫描的“一刀切”限制。要充分发挥这个特性配置上需要打开动态时钟控制的开关。在TestMAX环境里大致涉及set_config -ssn_dynamic_clock_control enable但开了这个开关之后后端在时钟树综合时需要为每个SSN组单独做时钟树平衡时钟树上的buffer数量会明显增加。而它对测试时间的优化效果又很直接原本所有扫描链必须等最长的那个组完成移位才能进入下一拍现在短的组可以提前进入下一阶段整体时间自然缩短。我实测过一个项目开了动态时钟控制后最长链从9000周期压缩到6700周期因为长的时钟组和短的时钟组解耦了测试时间缩短了25%而后端时钟树面积只增加了约3%性价比非常高。4.3 IR Drop与功耗高压缩比背后的隐形成本总线位宽大、压缩比高意味着同一时刻进入移位状态的触发器数量更多瞬时功耗和IR drop问题就会凸显。尤其在at-speed测试Launch-on-Capture或Launch-on-Shift中IR drop过大会导致捕获时钟沿到达时触发器电压偏低出现假性时序violation也就是俗称的“电压塌陷”。处理方式有这么几种在SSN配置里限制同时移位的扫描链组数量牺牲一点压缩比换取功耗安全在测试pattern生成阶段通过EDA工具的功耗感知模式来约束测试功耗和后端确认power grid设计时预留足够的测试模式电流余量。记得有一次在7nm项目上我为了追求高压缩比把bus width配到32结果at-speed测试良率一直偏低。后来逐条排查发现就是IR drop问题——很多die在低电压拐角测试时捕获沿的电压已经低到无法可靠工作。后来把bus width降到16同时开了动态时钟控制的功耗限制模式良率恢复了测试时间只增加了12%。5. 常见问题与排查技巧实录5.1 压缩比上不去先查这几项有时候配置明明改大了压缩比报告却纹丝不动甚至下降。这类问题我排过不少大多数原因集中在以下三项内部扫描链数量无法被channels整除。比如EDT channels8内部扫描链却有420条那420/852.5余数会浪费一些解压缩状态机的编码空间。通常工具会做padding填充伪链但填充也占用通道压缩比就被拉低了。扫描链长度不均衡。前面说过最长链直接决定pattern长度链长差异超过50%时压缩比会被链长拖累。工具默认的test point插入。TestMAX在压缩模式下会插入一些test point来提高可测性这些点是额外的观察/控制点会放大pattern数量。你可以查看报告中test point的数量如果异常偏高检查是不是约束文件里设置了过于激进的覆盖率目标。针对这些我的习惯做法是先把EDT channels调小比如从8调到4看压缩比是不是反而提升了。如果提升了说明当前通道数大于内部扫描链的“最佳映射宽度”属于过配置。再往下调找到压缩比的峰值点然后从这个点往回调整。5.2 测试时间超标不要只盯着压缩比测试时间等于pattern数乘以每个pattern的长度压缩比高了不代表测试时间一定短。我在一个项目里遇到的情况是压缩比从20倍提到了35倍但测试时间反而多了10%。原因在于EDT的高压缩模式需要额外的“同步周期”来初始化解压缩器状态机。这些同步周期在一次pattern里占比很小但如果pattern数本身就少比如只有几千条同步开销就会被放大。另一个原因是工具为了兼容不同通道数的测试模式额外生成了很多“模式切换pattern”这些pattern的故障覆盖率贡献很低纯属浪费测试时间。解决办法是检查pattern report里的“useful pattern ratio”有效模式比例如果低于70%就得考虑关掉一些兼容模式或者调整pattern生成时的token选项。5.3 配置报错与约束冲突速查表报错/现象常见原因排查与解决bus width与scan chain数量不匹配内部链数无法按总线宽度均匀分配调整链重排选项或尝试±1档位宽度EDT channel被强制约束到1设计里可能存在某些不支持压缩的扫描链检查set_scan_compression_configuration禁用项SSN组时钟约束缺失缺少对应的时钟约束文件补充SSN组的时钟分组约束Pattern count暴增Test point插入过多或覆盖率约束过严放宽throwaway pattern选项检查test point报告后端congestion超标bus width过大或约束过紧降一档bus width或为总线指定专用布线层5.4 测试向量生成故障X态与响应不确定性EDT的响应分析response analysis会遇到一个经典难题未知态X态。内部总线上出现X态会污染签名分析器signature analyzer导致测试失败或误判。传统做法是插入X态抑制逻辑X-bounding但这会占用面积和影响性能。在SSN/EDT配置里有几个选项可以缓解启用X态容忍模式X-tolerant允许一定比例的X态透过通过多轮签名分析消除不确定性在RTL阶段通过约束把已知的X源信号做隔离防止X态传播到扫描链检查有没有三态总线三态总线在测试模式下极其容易产生X态。我之前遇到过一个大项目故障覆盖率卡在88%上不去查了一个多礼拜最后的元凶就是一条没有接上拉电阻的三态总线在测试模式下输出为高阻态导致大片X态传播。物理工程师加了一颗上拉电阻之后覆盖率直接跳到98%。6. 一些关于配置节奏与团队协作的个人心得最后分享一点经验不算是严谨的方法论更多是这些年踩坑踩出来的体会。SSN Bus Width和EDT channels的调整最好放在DFT插入阶段早期完成不要在flow中后期频繁改动。因为这两个参数牵一发动全身RTL测试逻辑结构、扫描链分组、测试时钟树、后端布局布线、ATE测试程序全都跟着变。我见过最强的操作是某个项目在tapeout前两个月还在改EDT channels结果整个后端的扫描链重排都推倒重来DFT工程师连续加班一个月才赶上deadline。比较稳妥的节奏是项目启动后三到四周内完成SSN/EDT的参数扫描选出一到两档候选配置结合后端early flow的反馈确定最终档位之后就不再动这两个参数。后续的工作重心放在test pattern优化、覆盖率分析和测试程序调试上。还有一点做DFT的一定要提前跟ATE测试工程师建立沟通。你的EDT channels配置得再漂亮最后要在tester上跑测试工程师对tester channel配置、电压电平、时序校准最有发言权。早一点对齐能让你的DFT方案从一开始就贴合实际测试环境少走很多弯路。说到底SSN Bus Width和EDT channels的配置没有标准答案每个项目都有自己的最优解。多算、多试、多沟通才是做好DFT压缩的硬道理。