企业官网建设流程全解析

1. 为什么要重新审视SSN Bus Width与EDT Channels

做DFT做了快十年，我见过太多项目在测试压缩配置上“能用就行”，结果到了量产阶段被测试时间拖到怀疑人生。SSN Bus Width和EDT channels这两个参数，表面上看只是工具里的几个下拉选项，实际上它们直接决定了你的测试数据量、测试时间、甚至后端物理实现的收敛难度。

先说清楚一个容易被混淆的概念：SSN（SmartScan Network）是Synopsys TestMAX DFT工具里的高压缩扫描架构，而EDT（Embedded 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为8，shift频率50MHz，那么理想测试时间就是100000×10000/(8×50×10^6)=2.5秒。听着不多？那你得注意，这只是scan test的一部分，还有functional test、memory BIST、analog test等。一个复杂的SoC，scan 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的选型不是拍脑袋定的。以下是几个我实测下来比较稳的经验值，按项目规模分类：

配置命令在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

但这里有几个容易踩的坑，我详细说一下：

1. ATE通道数不要配满。很多测试工程师以为EDT channels越多越好，但ATE实际能分配给scan test的通道数有限，还需要留一部分给其他测试项。我的建议是：EDT channels的数量不要超过ATE可用通道的75%，剩下的留作备份或flexible channel。

2. 考虑测试机台的channel mixing能力。有些ATE支持不同电压/频率的通道混搭，你配了16个EDT channels，但如果测试机台不够先进，这16个通道必须拆成两组8通道分别在两个测试头上跑，又涉及test program的改动，得不偿失。

3. 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设成8，SSN 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 压缩比上不去，先查这几项

有时候配置明明改大了，压缩比报告却纹丝不动，甚至下降。这类问题我排过不少，大多数原因集中在以下三项：

1. 内部扫描链数量无法被channels整除。比如EDT channels=8，内部扫描链却有420条，那420/8=52.5，余数会浪费一些解压缩状态机的编码空间。通常工具会做padding（填充伪链），但填充也占用通道，压缩比就被拉低了。

2. 扫描链长度不均衡。前面说过，最长链直接决定pattern长度，链长差异超过50%时，压缩比会被链长拖累。

3. 工具默认的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 配置报错与约束冲突速查表

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压缩的硬道理。