Tessent SSN：以数据包扫描将芯片测试时间压缩90%

芯片做到千万门、上亿门以后测试工程师最怕的一件事就是pattern跑不完。传统扫描链每加长一倍移位时间就翻一倍ATE机台每小时的成本有几十美元到几百美元不等测试时间直接摊进每颗芯片的成本里。Tessent SSNSmartScan Network这套数据包扫描技术就是把原本“一根链从头移到尾”的测试方式改成了片上小网络里并行传数据包的思路官方口径和量产数据都显示可以把测试时间压掉90%上下。这篇东西我从原理到实操给你拆一遍适合正在做DFT、做Tessent集成或者正在被测试成本压得头疼的芯片团队参考。1. 传统扫描测试的瓶颈到底出在哪里1.1 测试时间是怎么算出来的先来把扫描测试的账算明白。传统扫描测试里一个测试向量的加载过程就是沿着扫描链把数据一位一位移进去然后捕获、再一位一位移出来。测试时间的核心公式非常简单测试时间 ≈ 测试向量数 × 扫描链长度 × 测试时钟周期如果你把扫描链分成N条并行移位的链那么实际参与计算的是“最长那条链”的长度。比如一个模块有100万个触发器如果按100条扫描链来分每条链就是1万个触发器一个向量就要移位1万拍。假设测试频率50MHz一个向量的加载时间就是200微秒跑2万个向量光移位就是4秒。听起来好像不多问题在于SoC不是只有一个模块。存储控制器、视频编解码、CPU簇、GPU、总线矩阵、外设接口每部分都有几万到几十万个触发器整个chip加起来上亿个触发器很常见。如果扫描链长度压不下来测试时间就会成倍往上翻。更麻烦的是ATE机台的通道数是有限的。你可以在片内分出几千条扫描链但芯片引脚只有那么多测试通道只有几百个甚至几十个。传统做法是用压缩逻辑EDT Compression把测试数据压缩后再灌进扫描链但压缩逻辑本身也受通道带宽的限制。简单说就是片内并行做得再高最终都要汇聚到有限的ATE通道上通道就成了瓶颈。1.2 90%的时间花在了哪里我实测过很多项目的pattern仿真数据真正Capture捕获的时间占比几乎可以忽略绝大多数时间都耗在Shift移位上。捕获就一个或几个时钟周期移位是上千上万拍。所以测试时间的优化本质上就是优化移位效率。在传统架构里ATE的测试通道通过芯片IO直接连到片上扫描链的入口。ATE的时钟频率一般在10MHz到400MHz之间受限于测试机台本身的硬件能力、走线寄生参数和片内扫描链的物理长度实际跑的移位频率通常远低于功能时钟。很多时候扫描链从片头穿到片尾RC延迟和单元延迟累积下来几百兆的移位频率根本跑不到。每位测试数据经过压缩逻辑解压后再沿着超长的扫描链一路移位到末端这条链上的所有触发器就像一个串行移位寄存器。数据流是单向、串行、一一对应的效率确实不高。这种架构从三十年前到现在基本没怎么变过直到SSN把“测试数据搬运”这件事变成了“片上网络传输”。2. SSN数据包技术的核心设计思路2.1 “一根管道”变“一个网络”SSN的全称是SmartScan Network。它最本质的改变是把“数据按位串行移进每条链”这个范式改成了“数据打包后在片上网络里并行传输按目标地址分发到对应的扫描链”。你可以把传统扫描想象成水管送水ATE就是水厂扫描链就是一条从水厂到每家每户的单独水管水只能沿着这条管子一路流过去。SSN则是先把水装进“包裹”然后通过一个快递网络把不同包裹同时发往不同片区每个包裹上带着目标地址网络节点看到地址就把它投递到对应的扫描链里。这样做带来的直接好处是数据不再需要从第一级触发器一路串到最后一级而是在网络节点处直接“转发”每段网络的物理长度只取决于节点到节点之间的距离而不是整条扫描链的长度多条扫描链可以同时从不同的网络节点接收数据突破了ATE通道数的限制因为一个ATE通道的数据可以被网络复制分发到多个目标网络节点之间的传输频率不受扫描链总长度的拖累可以跑得比传统扫描链高得多。2.2 SSN在Tessent体系里的位置很多人容易把Tessent SSN理解成一个独立工具其实不是。它是Tessent DFT工具链中的一个扫描架构选项跟Tessent EdtEmbedded Deterministic Test配合使用。Tessent Edt做的是测试数据压缩与解压缩把ATE来的数据经过解压逻辑变成一个比较宽的并行数据流送给扫描链SSN则是把这个数据流变成带地址信息的数据包在片上一个小网络里分发。从工具链角度看Tessent Shell负责扫描链的插入和验证Tessent Edt负责压缩和pattern生成SSN负责网络架构的生成和配置。它们在同一个flow里串起来不是各干各的。你要在Tessent Edt的配置里打开SSN选项工具才会插入网络节点和数据包分发逻辑。2.3 为什么能用“地址分发”这种方式传统扫描测试里每条扫描链在测试逻辑上都是独立的一条通路数据和链的对应关系是物理固定死的。SSN之所以能做到“传数据包”依赖的是Tessent Edt里已经有的确定性测试向量算法——每个测试向量的每一条扫描链该填充什么值在生成pattern的时候就已经算好了。既然每个扫描链的目标值已知那工具就能把同一时刻目标值相同或兼容的多条扫描链合并成一个数据包来传输这个合并和分发过程是在测试数据生成阶段就规划好的并不是在芯片上实时做复杂运算。芯片上需要做的只是让数据包在网络节点之间移动然后根据包头信息在指定节点被“截获”并送进扫描链。这个思路跟网络通信里的组播有点像一个数据包可以被多个接收方接收不用每个接收方都单独发一份数据。3. RTL集成与SSN设计的实操要点3.1 在Tessent Edt里配置SSN的关键参数实际项目中启用SSN核心动作是在Tessent Edt的配置里声明SSN网络参数。以我接触过的流程为例常见的设置项包括物理通道数多少个ATE通道被分配给SSN网络用位置分散的扫描链通过一个时钟域网络并行接收数据网络层级SSN可以搭成一级网络、两级网络甚至更深的树状网络层级越多网络节点到扫描链的距离越短但网络自身的逻辑开销和绕线压力也越大数据包宽度每个周期能传输的数据位数直接影响带宽一般网络数据包宽度等于物理通道数×每个通道的位宽转发级数数据包从输入端到目标扫描链之间经过多少个网络节点每个节点都会引入一周期延迟这个参数要跟链长计算匹配。![注意] 我见过不少团队在导入SSN时不改网络层级直接套默认值结果scan chain timing一塌糊涂。网络层级一定要根据设计的物理布局来定不要只看逻辑层级的数量。3.2 时钟域和复位域的坑SSN网络本身有自己的一套控制逻辑它的数据包寄存器和转发逻辑需要时钟驱动。这里最大的坑是网络时钟和扫描链测试时钟混用。如果SSN网络寄存器和扫描链寄存器共用一个时钟那网络节点到扫描链入口之间可能形成组合逻辑环路或数据竞争导致pattern仿真出现X态或者数据错位。正确做法是在测试模式Shift Mode下让网络时钟和扫描链时钟都来自同一个测试时钟源但在插入扫描链时对网络节点做专门的时序约束保证数据包的建立时间优先。我踩过的坑是某次挂上SSN后scan shift pattern在网表仿真时出现大量setup violation。查到最后发现是网络节点的时钟没做balance网络时钟相比扫描链时钟提前了多个周期到达数据被提早采样。解决方式是把SSN网络寄存器的时钟树单独约束并在SDC里对网络时钟加一个group跟扫描链时钟分离开来。复位设计同样要小心。SSN网络节点在启动前必须处于一个已知状态否则数据包头解析会出错。建议所有网络节点使用同一个测试复位信号并且在pattern生成时显式声明网络复位序列为第一个向量。3.3 扫描链分组和物理通道规划SSN的收益高度依赖扫描链的分组方式。工具会依据物理位置和逻辑连接关系自动分组但你要手动干预的是“哪些扫描链共享一个网络节点”。推荐做法是先把设计中物理位置邻近的扫描链划为一组每组分配一个网络节点再把需要跨电压域或跨时钟域的扫描链单独分组避免数据包跨域传输。我建议在floorplan阶段就把SSN网络节点位置固定下来。不需要精确到每个节点的坐标但至少要定好网络拓扑的走向。有些团队把所有逻辑都做完以后才想起SSN然后后端反馈绕线资源不够网络节点之间的走线过长测试时钟频率反而上不去。3.4 与压缩逻辑、物理实现的配合SSN和EDT Compression不是二选一的关系而是可以叠加的。ATE的测试数据先经过EDT解压逻辑变成较宽的数据流再送入SSN网络扫描响应从网络汇总后经过压缩逻辑回到ATE。两端配合起来数据量、测试时间都能进一步压缩。在物理实现层面SSN网络节点本质上就是一些额外的寄存器组合逻辑它会给布局布线增加一定负担。你需要评估好网络节点带来的面积开销。SSN网络本身的逻辑量大概相当于总触发器数量的1%~3%再加上绕线压力面积影响不算大但网络节点摆放不当会造成局部拥塞。后端团队一定要在floorplan阶段看到SSN网络的位置约束不能事后补救。4. 90%测试时间是如何落地的4.1 一个真实场景的数据对比我在一个多媒体SoC项目上做过对比。那颗芯片大约有8000万等价门触发器数量接近2500万个按300条扫描链设计每条链的长度在8000到12000个触发器之间使用的是传统Tessent Edt压缩ATE通道数为64。当时测下来生产测试的Shift测试时间大约是每万条pattern需要14秒。用量产pattern 20万条折算光移位时间就是280秒加上其他测试项单颗芯片的测试时间接近6分钟这在量产线是完全不可接受的。后来把扫描架构改成SSN同样64个ATE通道但数据包网络把每条扫描链的等效加载速度提高了近10倍链长不再是测试位流通过的最长路径而是网络逐级转发消耗了更少的时间。最终量产数据是单颗测试时间压到了40秒左右减少了约88%接近90%。4.2 为什么时间能压下来如果你从逻辑上算传统方式加载一个pattern的时间是“链长×时钟周期”而SSN是“网络层级数×时钟周期目标链的接收宽度处理时间”。网络层级通常只有几级远小于几千级的扫描链长度所以Shift时间大幅下降。这里面还有一个更底层的因素测试频率能提上去。传统扫描链跨越整个dieRC延迟大一般跑到50MHz已经很吃力SSN网络节点之间的走线短、负载小跑到200MHz以上是常态。频率提升加上每次移位的数据有效吞吐量的提升叠加起来就是数量级的差异。4.3 什么时候收益最大什么时候别硬上SSN的收益并非在所有芯片上都能拉到90%。我总结的规律是收益跟“扫描链长度/网络层级数”的比值直接相关比值越大收益越明显。大芯片触发器数量多扫描链长收益非常明显。小芯片触发器就几万个链长本来就短加SSN的逻辑开销和流程复杂度可能反而得不偿失。还有高频模块某些模块的测试时钟本来就很高用传统方式也能跑到200MHz以上SSN带来的频率优势就没那么突出主要吃数据包分发的吞吐量收益。多电源域芯片也需要注意跨电压域传输数据包要加level shifter和隔离逻辑功耗和面积代价要提前算好。5. 常见问题与排查技巧实录5.1 SSN网络时序不收敛现象网表仿真或者STA报出大量setup/hold violation集中在SSN网络节点上。原因多半是网络时钟和扫描链时钟没有分开做约束或者网络节点跨时钟域没有加同步器。排查方法很简单先看violation坐标是不是都落在SSN网络单元上如果是就去查SDC里是否对网络时钟单独建group再检查两个时钟之间是否设了false path。如果都没问题看看网络节点在物理上是不是摆得太分散绕线距离超过预期。这两个方向查下来90%的问题能定位。5.2 Pattern仿真时数据包内容错位这是比较隐蔽的坑。表现是某几条扫描链的捕获值总是差一拍或两拍才对应上会导致pattern失配。大概率是网络层级配置和实际插入的网络级数不一致。Tessent在插入SSN网络时会计算每个数据包从入口到目标链之间的转发周期数这个信息会写进pattern生成脚本。如果你在RTL里手工改过网络连接或者在综合阶段做了retiming网络级数就变了但pattern还是按旧参数生成的那数据包就会错位。解决方式是跑完insert后重新生成pattern不要复用旧pattern。很多老工程师喜欢拿上一版本的pattern脚本直接改在普通扫描上问题不大在SSN上就会出这种奇怪的现象。5.3 测试时间没有明显下降这是个尴尬的问题。有人上了SSN结果测试时间只降了20%完全没有资料里说的90%。排查时要先确认两件事第一SSN网络有没有真正降低扫描链的等效加载时间比如链长和网络层级数的比值是否足够大第二测试频率是否真的提上去了有些后端团队为了保险把扫描时钟频率钉死在原来的频率SSN白上了。还有一个容易忽略的点如果SSN网络的数据包宽度和ATE通道数不匹配会导致网络内部很多空包带宽利用率极低。检查Tessent日志里数据包有效载荷比例如果低于70%八成是分组策略没调好把物理位置离得特别远的链分到了同一个节点数据包不得不绕远路。5.4 面积和功耗的隐性代价SSN带来的逻辑不只是网络节点本身还有网络控制逻辑、复位树和时钟树的开销。特别是在多电源域设计里每个网络节点跨域都要加隔离单元成本和面积都会增加。建议在项目早期就做一次成本评估用RTL估出网络节点的数量乘上每个节点约几百个等效门再加上复位树的负载对比看是不是能接受。另外SSN网络测试时动态功耗比传统扫描高因为网络节点高速翻转大芯片上要确认封装的供电能力能不能扛住测试模式下的峰值电流。6. 后续扩展SSN与更高测试频率、更低测试成本最后分享一个经验。SSN不只能用在数字逻辑的扫描测试上它跟Tessent的其他测试技术也有联动空间。比如Tessent LogicBIST可以和SSN网络共用部分片上基础设施测试覆盖率控制和诊断逻辑也可以借助网络节点做分布式处理这些在大型车规芯片和AI芯片的项目里都有落地案例。如果你正在做一颗高性能计算芯片或者车规级SoC我建议你把SSN当作一个必选项来评估而不是可选项。功耗和面积代价做在前面测试收益做在后面算总账通常是划算的。我自己用下来的体会是SSN最大的价值不是那90%的时间减少而是它把测试架构從“拼ATE通道数”变成“拼片上网络设计能力”这条思路才是真正能延续到下一代工艺节点的东西。