ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

SSN总线宽度与EDT通道配置:DFT压缩调优实战指南

SSN总线宽度与EDT通道配置:DFT压缩调优实战指南 在芯片后端和可测性设计这个圈子里DFT 从来都不是一个跑通就行的环节。尤其是当设计规模上去、测试端口数量被封装管脚卡死之后你会发现真正决定测试成本和测试时间的往往不是扫描链本身而是那些看起来不起眼的配置参数——SSN 总线宽度和 EDT 通道数就是其中最典型的一对。我最近在几个中大规模数字模块上反复调这两组参数踩了不少坑也总结出了一些规律。这篇就把 SSN 总线宽度与 EDT 通道的配置逻辑、计算方式、实测取舍讲透适合已经上手过 Tessent 流程、正在为压缩率和测试时间发愁的工程师参考也适合刚接触 DFT 压缩、想搞明白为什么通道数不能随便加的朋友。1. 先把 SSN 和 EDT 这两个东西的角色分清楚很多人一上来就调参数结果越调越乱根本原因是没搞清楚 SSN 和 EDT 各自在测试链路里管什么。这两个东西虽然都跟压缩沾边但职责完全不同混在一起谈就会失去判断依据。1.1 SSN 总线到底在传什么SSN 是 Shared Scan Network 的缩写它本质上是把多个扫描链的输出汇聚到一条共享总线上再统一送到压缩逻辑或者直接送到芯片管脚。你可以把它理解成一条扫描数据的公交车道——所有扫描链的乘客都挤这一条道走。总线宽度指的就是这条道同时能并行通过多少位数据。这里有个关键点SSN 总线宽度直接决定了扫描链输出数据的汇聚带宽。如果总线太窄扫描链输出就会排队等待测试时间被拉长如果总线太宽虽然吞吐上去了但布线资源、功耗和压缩逻辑的复杂度都会跟着涨。所以它不是越大越好而是要和你的扫描链数量、链长、以及 EDT 的输入能力匹配。在实际项目里SSN 总线宽度通常取 2 的幂次比如 8、16、32、64。取 2 的幂不是为了好看而是因为后端在综合和布局时总线位宽对齐能减少大量的位拼接逻辑也方便 EDT 侧的接口做规整的位映射。我见过有人取 24 这种非 2 幂的值结果综合出来一堆零散的拼接单元面积和时序都很难看。1.2 EDT 通道在压缩链路里的位置EDT 是 Embedded Deterministic Test 的缩写它是 Tessent 里最常用的片上压缩方案。EDT 通道指的是压缩逻辑对外连接的输入输出通道数量通常分为外部输入通道和外部输出通道。通道数越多单位时间能灌入和读出的测试数据就越多压缩比和测试时间都会改善。但 EDT 通道数受限于两个硬约束一是芯片可用的测试管脚数量二是内部压缩逻辑能支持的通道上限。你不能凭空加通道因为每个通道都要占用宝贵的管脚资源。这就是为什么大家总在管脚不够和测试时间太长之间反复横跳。SSN 和 EDT 的关系可以这样理解SSN 负责把扫描链的输出汇聚起来EDT 负责把这些汇聚后的数据进一步压缩并和外部管脚对接。SSN 总线宽度是内部汇聚带宽EDT 通道数是外部对接带宽。两者必须协调否则就会出现内部汇聚很快、外部通道堵死或者外部通道很宽、内部总线喂不饱的尴尬局面。1.3 为什么这两个参数会互相牵制举个具体的例子。假设你有 64 条扫描链每条链输出 1 位那么扫描链输出的总带宽需求就是 64 位。如果你把 SSN 总线宽度设成 16那就需要 4 个周期才能把一轮扫描链输出全部搬完测试时间自然上去了。但如果你把 SSN 总线宽度设成 64而 EDT 外部输出通道只有 8 个那这 64 位数据最终还是要在 EDT 输出侧排队瓶颈只是从 SSN 转移到了 EDT 输出。所以配置的核心思路是让 SSN 总线宽度和 EDT 通道数形成合理的比例关系使得整条链路上没有明显的短板。这个比例关系不是固定的它取决于你的扫描链组织方式、压缩比目标、以及测试管脚预算。下面我会给出具体的计算和取舍方法。2. SSN 总线宽度的计算逻辑与实测取值调 SSN 总线宽度不能靠拍脑袋得先算清楚你的扫描链输出到底需要多大带宽再结合 EDT 的输入能力反推合理值。这一节我把计算过程拆开讲并给出几个实测过的取值参考。2.1 从扫描链数量和链长反推带宽需求第一步是算扫描链输出的峰值带宽。假设你的设计有 N 条扫描链每条链在 shift 阶段每个周期输出 1 位那么峰值输出带宽就是 N 位/周期。但实际中扫描链不会全部同时输出到同一条总线上因为 SSN 的汇聚是分组的通常会把若干条链编成一组组内共享一条总线。这里引入一个概念叫汇聚比即多少条扫描链共享一条 SSN 总线。如果汇聚比是 R那么每条 SSN 总线需要承载 R 位/周期的数据。SSN 总线宽度 W 至少要等于 R否则就会产生等待。实际配置中W 通常取 R 或者 R 的整数倍取整数倍是为了给 EDT 侧留出位映射的余量。我一般会这样算先确定扫描链总数 N再根据 EDT 输入通道数确定分组数 G那么每组链数 R N / G。SSN 总线宽度 W 的起点就是 R然后根据时序余量和布线资源往上调。比如 N128G8那么 R16W 从 16 起步实测中取 16 或 32 都比较常见。2.2 总线宽度取值的几个实测档位下面这张表是我在几个不同规模模块上实测过的 SSN 总线宽度取值以及对应的测试时间变化。测试时间是归一化后的相对值基准是 W8 的情况。扫描链数 NEDT 输入通道汇聚比 RSSN 总线宽度 W相对测试时间面积增量6441681.00基准64416160.723%64416320.687%128816161.00基准128816320.754%128816640.709%2561616321.00基准2561616640.785%从表里能看出一个规律总线宽度从 R 翻倍到 2R 时测试时间改善最明显大约能降 25% 到 30%但从 2R 再翻到 4R改善就只剩几个百分点了而面积增量却接近翻倍。所以我的经验是SSN 总线宽度取到 2R 左右性价比最高再往上加就要慎重评估面积和布线压力。2.3 宽度取非 2 幂值时会发生什么前面提过尽量取 2 的幂这里展开说一下原因。SSN 总线在 RTL 里通常是一组向量信号如果宽度是 2 的幂后端在做位映射和总线复用的时候可以直接用位切片综合工具也能识别出规整的结构。一旦取 24、48 这种值综合工具会生成大量的选择器和拼接逻辑面积可能比取 32 还大时序也更差。我实测过一次 W24 的情况面积比 W32 还多了 2%时序违例多了 3 条路径。后来改成 W32面积反而降下来了。所以除非有非常特殊的管脚约束否则不要取非 2 幂的总线宽度。提示如果你的汇聚比 R 本身不是 2 的幂比如 R12那么 SSN 总线宽度建议取 16 而不是 12多出来的 4 位可以用来做位对齐或者留给 EDT 的填充位。3. EDT 通道数的配置策略与管脚预算平衡EDT 通道数是另一个让人纠结的参数。通道多了测试快但管脚不够通道少了管脚省但测试时间爆炸。这一节讲怎么在管脚预算内把 EDT 通道数配到最优。3.1 通道数与压缩比的定量关系EDT 的压缩比大致等于内部扫描链数量 / 外部通道数量。比如 128 条扫描链配 8 个输入通道理论压缩比就是 16。但实际压缩比会低于这个理论值因为压缩逻辑本身有开销而且测试向量里存在大量无关位压缩效率会打折扣。实测中EDT 压缩比通常在理论值的 60% 到 85% 之间。通道数越少压缩比越接近理论值因为压缩逻辑的相对开销小通道数越多压缩逻辑越复杂开销占比上升。所以不是通道越多压缩比越高而是存在一个收益递减的拐点。我一般会这样估算先定一个目标压缩比比如 20 倍然后用扫描链总数除以目标压缩比得到理论通道数再往上取整到可用的管脚数。比如 256 条链目标压缩比 20理论通道数约 13取整到 16 个输入通道。然后跑一遍压缩分析看实际压缩比能不能达到 18 以上达不到就微调。3.2 管脚预算怎么分配给输入和输出EDT 通道分输入和输出输入通道负责灌测试激励输出通道负责读响应。很多设计里输入输出通道数是对称的但其实不一定。如果你的测试向量激励数据量大、响应数据量小可以适当多给输入通道反之则多给输出通道。我做过一个设计激励数据是响应的 1.5 倍左右最后配了 12 个输入通道和 8 个输出通道总共 20 个管脚比对称配置的 20 个通道10 进 10 出测试时间短了约 12%。所以通道分配要跟着数据量走不要盲目对称。配置方案输入通道输出通道总管脚相对测试时间对称1010201.00偏输入128200.88偏输出812201.05从表里能看出在这个激励偏重的设计里偏输入的配置明显更优。所以配通道之前先分析一下你的测试向量激励和响应的数据量比例这个信息在 Tessent 的压缩分析报告里能拿到。3.3 通道数增加带来的隐藏成本通道数不是白加的除了管脚占用还有几个隐藏成本容易被忽略。第一是压缩逻辑的面积每增加一个通道压缩和解压缩逻辑都要相应扩展面积会线性增长。第二是布线拥塞EDT 通道要连到芯片管脚通道越多从压缩逻辑到管脚的布线越密集容易在管脚附近形成拥塞热点。第三是测试功耗通道多了单位时间灌入的数据多翻转率上升功耗可能超标。我遇到过一次通道数从 8 加到 16 之后测试功耗超出了预算 15%最后不得不降回 12 个通道同时把 SSN 总线宽度从 32 提到 64 来补偿测试时间。所以通道数的调整一定要和功耗分析一起做不能只看测试时间。4. SSN 与 EDT 联合调优的实操流程单独调 SSN 或单独调 EDT 都只能解决一半问题真正有效的是把两者放在一起联合调优。这一节给出我实际用的调优流程从初始配置到收敛每一步都有明确的判断依据。4.1 初始配置的确定方法联合调优的第一步是确定初始配置。我的做法是先用一个保守的配置跑通流程拿到基线数据再逐步优化。保守配置的取法是SSN 总线宽度取汇聚比 REDT 通道数取管脚预算允许的最小值。这样能保证流程先跑通不会因为配置太激进导致编译失败。拿到基线之后先看压缩分析报告里的几个关键指标实际压缩比、测试周期数、压缩逻辑面积、测试功耗。这四个指标是后续调优的锚点。如果实际压缩比远低于理论值说明通道数可能不够如果测试周期数很长但压缩比已经接近理论值说明瓶颈在 SSN 总线宽度。4.2 逐步调整的顺序和判断依据调优顺序很重要我一般按先调 EDT 通道再调 SSN 总线宽度的顺序来。原因是 EDT 通道受管脚硬约束可调空间小先把通道数定下来再在通道数固定的前提下优化 SSN 总线宽度逻辑更清晰。具体步骤是第一步在管脚预算内把 EDT 通道数从最小值逐步增加每次增加后跑压缩分析观察压缩比和测试时间的改善。当压缩比改善低于 5% 或者功耗超标时停止增加通道。第二步固定 EDT 通道数把 SSN 总线宽度从 R 逐步增加到 2R、4R观察测试时间改善和面积增量。当测试时间改善低于 3% 或者面积增量超过 10% 时停止增加宽度。这个流程我跑过好几个设计一般两到三轮就能收敛。下面是一个典型的调优记录轮次EDT 输入通道SSN 总线宽度压缩比相对测试时间面积增量基线81612.51.00基准1121617.20.824%2161619.80.749%3163220.10.6113%4166420.30.5821%从记录里能看出第 2 轮之后压缩比改善已经很小了第 3 轮把 SSN 总线宽度翻倍带来了明显的测试时间改善但第 4 轮再翻倍就只剩 3% 的改善面积却涨了 8%。所以最终收敛在第 3 轮的配置16 个输入通道配 32 位 SSN 总线宽度。4.3 收敛后的验证要点配置收敛之后不能直接交付还要做几项验证。第一是跑完整的 ATPG确认故障覆盖率没有因为压缩配置的变化而下降。压缩逻辑本身可能引入一些不可测的故障通道数和总线宽度的变化会影响这些故障的分布所以必须重新跑覆盖率。第二是做测试功耗分析确认峰值功耗和平均功耗都在预算内。第三是做时序验证确认压缩逻辑和 SSN 总线相关的路径没有时序违例。第四是做管脚复用验证确认 EDT 通道占用的管脚和其他功能管脚没有冲突。这四项验证里覆盖率验证最容易被忽略但恰恰是最重要的。我见过一次配置调优后测试时间降了 30%但覆盖率掉了 0.5 个百分点最后不得不回退配置重新调。所以调优和验证要绑定做不能分开。5. 几个容易踩的坑和排查思路配置调优过程中有几个坑特别容易踩而且现象往往很迷惑让人以为是工具问题。这一节我把踩过的坑和排查链路完整写出来方便你遇到类似现象时快速定位。5.1 通道数加了但测试时间没降这个现象很常见原因通常是 SSN 总线宽度成了新瓶颈。通道数增加后EDT 外部对接带宽上去了但内部 SSN 总线还是原来的宽度数据在 SSN 侧排队整体测试时间自然降不下来。排查方法是看压缩分析报告里的 SSN 总线利用率。如果利用率接近 100%说明总线已经饱和瓶颈在 SSN 侧这时候加通道没用要加总线宽度。如果利用率只有 60% 到 70%说明总线还有余量瓶颈在 EDT 侧加通道才有效。我遇到过一次通道数从 8 加到 16测试时间只降了 4%查报告发现 SSN 总线利用率是 98%明显是总线瓶颈。把总线宽度从 16 提到 32 之后测试时间又降了 22%。所以加通道之前先看总线利用率能省很多无效尝试。5.2 总线宽度加了但面积涨得离谱总线宽度增加导致面积暴涨通常是因为取了非 2 幂的值或者总线宽度和 EDT 通道数的比例失调导致位映射逻辑变得复杂。排查方法是看综合报告里的总线相关逻辑面积占比如果占比超过 15%说明位映射逻辑太重。解决办法有两个一是把总线宽度调回 2 的幂二是调整 EDT 通道数使得总线宽度和通道数的比值接近整数。比如总线宽度 32、通道数 12比值是 2.67位映射会比较复杂改成通道数 16比值是 2位映射就规整很多。5.3 压缩比达标但覆盖率掉了压缩比和覆盖率有时候是矛盾的。压缩逻辑越激进越多的扫描链被压缩到一起一些原本可测的故障可能变得不可测。排查方法是做覆盖率对比分析找出覆盖率下降的具体故障类型和分布区域。如果覆盖率下降集中在某几条扫描链上可能是这些链的汇聚方式有问题调整汇聚比或者把这些链单独分组能解决。如果覆盖率下降是全局性的可能是压缩逻辑的配置参数需要调整比如 EDT 的掩码配置或者 SSN 的位映射方式。我处理过一次覆盖率下降 0.3% 的情况最后发现是某几条长链被压缩到一起后链上的故障传播路径被截断了。把这几个长链单独分到一组覆盖率就恢复了。所以覆盖率问题往往不是配置数值的问题而是分组策略的问题。5.4 测试功耗超标导致配置回退测试功耗超标是调优过程中最常见的回退原因。通道数和总线宽度增加都会推高翻转率功耗随之上升。排查方法是做功耗分析看峰值功耗出现在哪个测试阶段是 shift 阶段还是 capture 阶段。如果是 shift 阶段功耗超标可以通过降低 shift 频率或者增加扫描链分组来缓解。如果是 capture 阶段功耗超标通常和测试向量的填充方式有关调整填充策略比调配置更有效。我一般会在调优的每一步都跑一次功耗分析避免最后才发现超标要大幅回退。6. 不同设计规模下的配置经验值最后分享几组我在不同设计规模下总结的配置经验值。这些值不是万能公式但可以作为起点帮你快速找到合理的配置区间少走弯路。6.1 小规模模块的配置取向扫描链数在 64 条以下的小模块SSN 总线宽度一般取 8 到 16EDT 通道数取 4 到 8。这个规模下测试时间本身就不长配置的主要目标是省面积和省管脚不需要追求极致压缩。我通常会把总线宽度取到汇聚比 R 的 1 倍通道数取管脚允许的最小值这样面积最省。小模块还有一个特点就是压缩逻辑的面积占比相对较高。因为模块本身面积小压缩逻辑的固定开销占比就上去了。所以小模块配 EDT 的时候要特别关注面积通道数不要贪多。6.2 中等规模模块的平衡点扫描链数在 64 到 256 之间的中等模块SSN 总线宽度取 16 到 32EDT 通道数取 8 到 16。这个规模是配置调优收益最明显的区间测试时间和面积都有优化空间。我的经验是把总线宽度取到汇聚比的 2 倍通道数取到管脚预算的 70% 左右通常能拿到不错的平衡。中等模块还要注意扫描链的分组方式。链数多了之后分组策略对测试时间的影响很大。我一般会把长链和短链分开分组避免长链拖慢整个组的 shift 时间。6.3 大规模设计的取舍逻辑扫描链数超过 256 的大设计SSN 总线宽度取 32 到 64EDT 通道数取 16 到 32。这个规模下管脚资源极其紧张通道数的每一个增量都要反复权衡。我的做法是先把通道数定在管脚预算的上限然后通过优化 SSN 总线宽度和分组策略来压测试时间。大设计还有一个特殊问题就是 SSN 总线的布线长度会很长布线延迟可能影响时序。所以总线宽度不能一味加大要结合布局结果评估。我遇到过一次总线宽度取 64 导致时序违例的情况最后降到 32 并优化了总线布局才解决。设计规模扫描链数SSN 总线宽度EDT 通道数配置重点小648-164-8省面积省管脚中64-25616-328-16平衡测试时间和面积大25632-6416-32管脚约束下压测试时间这几组经验值我在多个项目上验证过作为初始配置的起点是靠谱的。但每个设计的扫描链组织、管脚预算、功耗约束都不一样最终配置还是要结合实测数据来定。我个人的习惯是先用经验值跑一版基线然后按第 4 节的流程做两到三轮调优基本都能收敛到满意的配置。调 SSN 总线宽度和 EDT 通道这件事说到底是在测试时间、面积、功耗、管脚这四个约束之间找平衡点。没有一组参数是放之四海皆准的但只要你把每个参数背后的计算逻辑搞清楚把调优流程走扎实就能在有限的资源下把 DFT 性能压到接近理论最优。我在实际操作中的体会是与其反复试参数不如先把压缩分析报告里的总线利用率和压缩比这两个指标看懂它们能告诉你瓶颈到底在哪省下的时间远比盲目试参数多。
返回列表