DFT项目交付前夜测试时间超标40%客户在电话里语气越来越沉。我盯着DFTMAX的report翻来覆去最后把SSN Bus Width从8调到16EDT input channels从8改成16重新跑完pattern测试时间直接砍掉一半。那一刻我才真正意识到SSN和EDT这两组参数不是随便填个整数那么简单。这篇文章就围绕DFT性能优化中最容易被低估的两个配置项——SSN Bus Width和EDT channels展开。我会讲清楚它们各自解决什么问题、为什么必须联合调整、配置时有哪些隐藏的坑并给出一套可以直接照着做的工程判断方法和实操案例。适合正在做DFT实现、遇到测试时间超标或ATE通道受限、想系统了解测试压缩配置的芯片设计工程师。1. DFT性能瓶颈与SSN、EDT的核心设计思路1.1 测试时间长了到底卡在哪个环节芯片DFT的测试时间主要由三部分决定pattern数量、每个pattern的shift周期数、以及shift时钟频率。这三者里pattern数量由故障覆盖率和测试压缩算法的确定性决定shift周期数取决于扫描链的长度而shift频率往往受制于ATE能力和芯片本身的功耗约束。很多团队一上来就陷入一个误区觉得pattern数量是固定的只能拼命提高shift频率。实际上在深亚微米工艺下shift频率抬到某个阈值之后再往上加就会触发严重的压降和时序问题测试良率反而下滑。真正值得优先优化的是扫描链的组织方式——也就是让有限的ATE通道在同样多的时钟周期里装载更多的测试数据。这里就是压缩技术的主场。EDT这类确定性压缩方案核心思路不是减少pattern本身而是通过片上解压缩器把少量ATE输入通道的数据扩展成大量内部扫描链的数据从而把长链拆成短链大幅缩短每个pattern的shift周期数。压缩率越高内部链越短测试时间越短但前提是外部通道能够喂饱所有内部链。SSN则解决的是另一个问题在测试引脚极其有限时怎么样用共享总线的方式把多个扫描通道的访问复用到一组物理引脚上。两者配合才是完整的性能优化路径。1.2 SSN Bus Width与EDT channels到底调的是什么先厘清概念。以Synopsys DFTMAX/DFTMAX Ultra流程为例EDT channels指的是嵌在芯片上的解压缩器/压缩器的外部数据通道数分为input channels和output channels。input channels越多每个shift周期能同时注入芯片的测试位就越多output channels同理决定观测数据回传的带宽。这个参数直接决定了外部ATE和内部扫描链之间的数据交换宽度。SSN Bus Width则是指SSNSuper Scan Network超级扫描网络内部共享总线的位宽。SSN的特点是把多个扫描通道的测试数据、时钟、控制信号做时分或空分复用通过更少的物理引脚连接到ATE。Bus Width决定了单个SSN控制器一次能同时驱动的扫描链组规模。简单理解EDT channels管的是“外部接口有多宽”SSN Bus Width管的是“内部通道怎么共享这条接口”。这两个参数描述的是不同层次但最终都指向同一个目标在有限的物理测试引脚和测试时钟下最大化单位时间内装入和移出芯片的数据量。实际工程里很多人把两组参数分开调只调EDT channels不管SSN Bus Width结果就是内部解压缩器虽然配了很宽的数据通路但外部引脚和SSN网络根本送不进那么多数据压缩率上去了实际测试时间却没有等比例下降。1.3 为什么这两组参数必须联合调优单独调任何一组参数都会碰到天花板。只加大EDT input channels数据进得多了但ATE的物理通道数量有限最终还是要做多路复用反而增加测试控制逻辑的复杂度只加大SSN Bus Width内部并行吞吐能力变强但如果EDT input channels不够宽解压缩器在每个周期能接收的确定性数据量就那么大总线再宽也只能空转。联合调优的本质是把三个约束条件同时放进坐标系里看ATE通道数、目标测试时间、可接受的功耗和面积开销。一味的“更大”不是答案而是要找到那个让三个约束同时满足的甜点区。我在后文会给出具体案例和计算公式帮助你理解如何从设计规模倒推参数而不是靠拍脑袋。2. SSN Bus Width配置实操从原理到参数选择2.1 共享总线带宽分配的工作机制用一个生活化的比喻理解SSN。假如一个测试引脚是一座机场的登机口内部扫描链是停靠的飞机SSN Bus Width就相当于同时开放的登机口数量。Bus Width越大同一时刻能上客的飞机就越多吞吐量越高但每个登机口都需要配套的地勤和廊桥资源对应到芯片上就是布线资源、控制逻辑和功耗开销。SSN在片上做的事情是把多个scan channel的数据流合并到一组共享总线上然后在测试控制器里通过slot分配的方式让每个channel轮流占用总线周期。这种设计显著减少了从ATE到芯片的测试引脚数量尤其适用于测试引脚紧张的SoC和量产测试效率敏感的项目。但它的代价是引入了总线切换的开销——channel之间切换需要额外的协议周期Bus Width太大时切换开销会侵蚀有效数据吞吐率。实际操作中SSN Bus Width的取值通常和芯片内部的scan channel数量、SSN控制器的数量、以及测试时钟频率强相关。Bus Width选得过大总线上的扇出和负载增加shift频率上不去切换等待周期也变长收益未必超过开销。这也是为什么不能只看“越大越好”的宣传口径。2.2 确定Bus Width的工程估算方法确定SSN Bus Width不能靠试要有一本账。第一步是统计设计里可用的测试IO数量。假设ATE分配到这颗芯片的测试引脚是32根其中8根用于时钟、复位和测试控制那么可用于扫描数据的引脚是24根。第二步是明确测试时间目标。比如设计要求在100MHz shift频率下总测试时间不超过2秒。假设压缩后pattern数量约2万条那么单条pattern允许的shift周期数约等于2秒除以2万条再乘以100MHz也就是10000个周期。第三步是反推扫描链的最大长度。内部扫描链长度若超过10000拍就必须提高压缩率。如果设计有400万位触发器要达到单链1万拍以内就需要至少拆成400条链。此时SSN Bus Width和EDT input channels的乘积关系就要能覆盖这400条链在有限引脚下的并行访问需求。这个推算过程看起来有点绕但实际操作时可以用工具的report辅助验证。DFTMAX的compile报告里会直接给出每个SSN controller下的channel数量和Bus Width建议值。我习惯先按上述方法粗算一个目标值再对照工具的floorplan和congestion报告调整而不是直接接受默认值。2.3 配置中的注意事项与边界条件SSN Bus Width配置中最常见的坑是忽略了多时钟域的影响。SSN总线在跨越不同时钟域的扫描通道时需要额外的同步和控制逻辑Bus Width越大跨时钟域切换的调度复杂度越高很容易在测试模式下引入hold time问题。碰到多时钟域设计我通常会把Bus Width保守设置优先保证DFT时序收敛再逐步提高。另一个容易被忽略的边界是EDT通道和SSN通道之间的匹配关系。如果EDT input channels是8而SSN Bus Width配到64解压缩器每个周期只能接收8个通道的确定性数据总线64位宽的利用率极低相当于花了面积和布线资源但没拿到收益。反过来说EBT input channels配到32SSN Bus Width只有8数据到不了内部扫描链同样浪费。两者必须保持在同一个数量级。功耗也是硬约束。测试模式下扫描链的活动因子远高于功能模式Bus Width越大单个时钟周期内同时翻转的扫描单元越多压降风险越高。在低功耗设计中这个约束往往比测试时间更优先。我在项目里遇到过一次shift频率从100MHz降到80MHz才让动态压降回到安全范围就是因为Bus Width加了一倍瞬时翻转电流暴增。3. EDT channels配置与测试压缩率调优3.1 EDT channels在压缩体系里的角色EDT的全称是Embedded Deterministic Test嵌入式确定性测试。它属于片上压缩技术核心是在被测芯片上放置解压缩器和压缩器。解压缩器把ATE输入的少量确定性数据扩展成高维的内部扫描链激励压缩器则把内部多条扫描链的响应信号压缩成少量输出通道送回ATE。EDT channels配置分为input和output两侧。input channels数量决定了解压缩器每个时钟周期能接收的“种子”位数直接关系到内部扫描链可以拆分出多少条、每条多短output channels数量决定测试响应回传的带宽如果输出侧太窄即使输入侧能高速注入观测数据也可能成为瓶颈导致某些故障不能被及时捕获。选择EDT channels的数量核心看两个数字一个是ATE物理通道的预算另一个是目标压缩率。压缩率的定义是内部扫描链总长度除以外部EDT输入通道数工程上常用“总内部chain数/总外部input channel数”来估算。举个例子内部扫描链拆分成了800条EDT input channels是16那么压缩率就是50倍。这里说的压缩率是理论值实际因为X态处理、pattern依赖等问题有效压缩率通常会打折扣。3.2 用实例配置通道数一个200万触发器的设计拿一个实际项目示意配置过程。假设设计里有200万个触发器flops目标是测试时间不超过1秒shift频率100MHzATE可用扫描数据引脚只有16根。未压缩方案下16个ATE引脚对应16条扫描链每条链平均125万拍。即使pattern数量只有1000条总测试时间也会达到125万拍乘以1000条再除以100MHz等于12.5秒完全不可接受。引入EDT压缩后把内部拆成2000条扫描链每条1000拍。EDT input channels取16正好用满ATE的16根数据引脚理论压缩率是2000除以16等于125倍。此时单条pattern的shift周期数是1000拍如果pattern数量因为care bit分布增加到2500条总测试时间就是1000拍乘2500条除以100MHz等于0.025秒。相比未压缩的12.5秒测试时间缩短了500倍。这个案例说明EDT channels的选择要匹配ATE物理通道。input channels取16不是因为16看起来顺眼而是因为可用引脚正好16根。如果ATE通道增加到32根就可以把input channels提到32内部扫描链进一步拆短测试时间还能再降一半。3.3 channels与pattern shift cycle的权衡EDT channels不是越多越好。input channels增加后单个时钟周期注入的数据量增大测试功耗随之上涨。更隐蔽的问题是通道数增加后解压缩器需要更复杂的线性反馈移位寄存器网络来控制确定性激励的产生这会让工具的pattern生成时间变长有时还会因为解空间约束变紧导致pattern数量反而增多。我遇到过一种典型情况把input channels从8提到32理论上压缩率翻了4倍但实际pattern数量增加了30%测试时间只缩短了10%。原因就是某些硬故障需要非常长的确定性序列才能激活通道变宽后单周期注入的约束变强反而让算法需要更多pattern去覆盖同样的故障。output channels的权衡同样存在。输出通道太宽压缩器每个周期采集的响应位数变多X态屏蔽逻辑的负担加重如果设计里X态源较多覆盖率可能下降。常用的经验值是output channels比input channels略宽一些因为测试响应里的care bit密度通常低于测试激励。具体数值还是建议通过工具跑一个小规模的corner实验来定避免照搬别人的配置。4. SSN Bus Width与EDT channels联合调优实战4.1 联合配置的基本流程联合配置的第一步是把约束写清楚。包括ATE物理通道数、测试时间目标、shift频率上限、功耗预算、以及可接受的面积开销。这五个数字在项目初期就要确定不然后面所有配置都是空中楼阁。第二步是确定EDT input/output channels。依据ATE可用数据引脚数预留出约10%的余量用于测试控制信号剩下的引脚数就是input channels的上限。output channels通常取input channels的1到1.5倍具体看响应数据的X态密度。这一步确定后内部扫描链的组织方式就有了基准。第三步是配置SSN Bus Width。此时要结合步骤二确定的EDT通道数和设计里的总扫描链数量确保“EDT通道数乘以SSN Bus Width”能够覆盖并行访问需求同时不超过SSN控制器的处理能力。工具一般会在compile阶段给出bus width建议但建议值通常偏保守可以根据实际congestion和功耗报告做适量上调。第四步是跑一轮完整的DFT DRC、ATPG、功耗评估和时序收敛根据结果回调整组参数。这个迭代过程是整个调优里最耗时的部分我自己通常会用脚本批量跑几个候选配置而不是一次只改一个参数效率会高很多。4.2 案例分析从128通道改造到256通道分享一个实际项目里的参数组合对比。某SoC设计有800万位触发器ATE通道64根原配置是EDT input channels32、output channels32、SSN Bus Width128测试时间9.8秒超过了客户要求的6秒。第一轮尝试只把EDT input channels提到64测试时间降到8.2秒收益有限原因是内部扫描链虽然进一步拆短了但SSN Bus Width还是128共享总线的吞吐量限制了实际数据到达扫描链的速率。第二轮把SSN Bus Width从128提到256同时保持EDT input channels64、output channels64测试时间一下子降到4.1秒。但代价也随之而来工具报告SSN控制器的面积增加了18%布线congestion从0.8%升到2.1%动态压降评估结果也接近上限。第三轮在第二轮基础上把shift频率从100MHz降到90MHz换来功耗裕量测试时间变为4.6秒仍然满足6秒目标。最终采用的配置是EDT input64、output64、SSN Bus Width256、shift频率90MHz。4.3 实测数据对比与性能收益同一颗设计三组配置的实测数据对比如下配置EDT input/output channelsSSN Bus Width测试时间Pattern增量面积开销DRC问题原始32 / 321289.8s基线基线无只加channels64 / 641288.2s4%6%无联合调优64 / 642564.1s8%18%2处congestion第三组配置虽然面积开销最高但测试时间收益最大最终通过降低shift频率解决了功耗问题。这个案例里最关键的一点是单独调EDT channels性能提升只有16%搭配SSN Bus Width一起调性能提升达到58%。两组参数确实是乘法关系而不是加法关系。工具的配置示意大概长这样具体语法取决于DFT Compiler版本。核心就是把edt和ssn的配置放在同一个dft_config块里确保综合时同时生效set dft_config [get_config] set_config -edt_input_channels 64 set_config -edt_output_channels 64 set_config -ssn_enable true set_config -ssn_bus_width 256 set_config -shift_frequency 90 compile_dft5. 常见问题与排查技巧实录5.1 覆盖率下降怎么办联合调优后覆盖率下降十有八九是X态屏蔽机制出了问题。测试压缩体系对X态非常敏感一个无约束的X态传播到压缩器可能污染多个输出通道的响应统计。解决办法是先找到X态源通常集中在异步复位、存储器读数据总线、未初始化的锁存器和时钟门控单元。我常用的排查路径是对比调优前后的coverage report找出丢失的fault集中在哪个模块再用工具的X-source分析功能定位传播路径最后针对性地加test point、插入shadow register或设置X态屏蔽约束。如果X态实在无法避免还可以考虑在EDT输出侧增加X态容忍机制但面积开销会明显上涨。覆盖率下降的另一个隐蔽原因是约束过紧。为了缩短pattern生成时间有些人会把动态转换约束加得非常严格结果限制了ATPG算法的搜索空间故障检测率自然下降。遇到这种情况建议先放宽动态转换约束或者把约束按时钟域分块设置而不是一刀切。5.2 测试功耗超标怎么排查测试模式下的功耗超标最明显的信号是shift阶段IR drop过大导致setup/hold检查失败。排查时先看report里每个SSN controller的activity profile确认功耗尖峰是出现在shift-in阶段还是capture阶段。如果是shift-in阶段功耗超标优先考虑降低SSN Bus Width或减小EDT input channels减少同时翻转的扫描单元数。另一种有效做法是把测试时钟分组让各组的shift时钟错开半个周期用时间差换取瞬时功耗的下降。这个技巧在多时钟域设计里尤其好用因为它不牺牲测试数据吞吐量。如果是capture阶段功耗超标问题往往出在测试约束不足导致大量路径在捕获瞬间同时翻转。此时建议检查capture时钟的约束设置必要时对关键时钟域做分拍捕获staggered capture。我在一个低功耗设计上用过这个办法动态压降从12%降到了7%覆盖率几乎没有损失。5.3 多时钟域设计的特有坑多时钟域设计在配置SSN Bus Width时最容易出问题的是跨时钟域扫描链的调度。如果几条不同时钟域的扫描链链接到了同一个SSN controller工具在插入同步逻辑后可能产生额外的延迟进而影响shift频率。我的经验是对跨时钟域边界做单独的DFT约束强制工具不要把不同时钟域的chain混在一个SSN bus里。另一个容易踩的坑是时钟门控单元在测试模式下的处理。如果时钟门控不受测试时钟控制扫描链里的数据可能在不该翻转的时候被门控掉导致覆盖率下降甚至功能校准失败。在DFT DRC阶段就要检查所有时钟门控的test_enable路径确保它们在shift和capture阶段都处于正确的使能状态。5.4 固化配置前的回归验证清单我把每次配置固化前要跑的验证项整理成一张清单直接用来当checklistDFT DRC全clean没有warning级别以上的violationATPG覆盖率满足签核目标且和调优前对比没有明显退化测试模式时序收敛setup/hold无violation动态功耗评估通过IR drop在安全范围测试引脚分配无冲突控制信号路径无拥塞pattern数量控制在目标范围内pattern生成时间可接受边界扫描和压缩模式兼容性验证通过对多时钟域设计额外检查跨域路径的同步逻辑无异常这张清单每个项目我都会跑一遍尤其是参数从其他项目移植过来时更要做全。即使参数组合看起来一样不同设计本身的扫描链组织、时钟结构、X态分布都会带来差异。6. 实操总结与经验速查6.1 参数选择的速查表根据我经手的项目经验不同设计规模有一个大致可参考的参数起点。这个表不是万能公式但作为初值能省不少时间设计规模触发器数量ATE数据引脚数EDT input channelsEDT output channelsSSN Bus Width50万以下84-8832-6450万-200万168-1616-2464-128200万-800万3216-3232128-256800万以上6432-6464256-512起始参数确定后围绕目标测试时间做两轮迭代基本就能找到当前设计的最优点。迭代时优先改SSN Bus Width因为它对测试时间的线性影响通常比EDT channels更直接但每次增加后都要重新确认功耗和congestion状态。6.2 上线前的检查清单除了前面提到的回归验证清单还有三件事我每次都会提醒团队。第一参数配置要写进版本管理不要只依赖工具脚本否则回溯时根本查不到当时为什么选这个值。第二配置变更前先跑一轮快速抽样ATPG确认pattern数量和覆盖率没有剧烈波动再跑全量。第三把功耗评估结果同步给后端团队让他们提前知道测试模式下的压降状况避免等到签核阶段再返工。我个人在参数配置上吃过不少亏最深的一点体会是SSN Bus Width和EDT channels这两个参数永远不要只看工具默认值也不要只看单个参数对指标的影响。它们是一组联动旋钮调整哪一个都会牵动其他约束。项目时间允许的话最好写一个简单的脚本批量跑几组参数组合把测试时间、面积、功耗、覆盖率四项结果汇总成一张表再决策比凭感觉调快得多也可靠得多。