芯片良率救星：Tessent MBIST中Memory Repair的BIRA与BISR实战解析-北京尧图网络

芯片流片回来最怕的不是功能跑不通而是测试机台上那一片红——成千上万个存储单元里总有那么几个物理缺陷导致读写失败。如果因为几颗坏点就整片报废那良率数字会难看到让人怀疑人生。好在DFT领域有一套成熟的补救机制在芯片内部预留冗余的存储行列测试时发现坏点就自动切换过去把原本要报废的芯片救回来。这套机制在Tessent MBIST流程里就是Memory Repair核心支撑模块是BIRA和BISR。下面我从实际项目出发把这条链路拆开讲清楚。1. 为什么Memory Repair是良率生命线1.1 存储阵列的物理缺陷为什么不可避免先进工艺节点下SRAM阵列的密度极高一颗几平方毫米的芯片里可能集成几十甚至上百兆比特的存储单元。光刻、刻蚀、离子注入这些步骤里任何微小的随机扰动都可能在某个存储单元上造成桥接、开路或者晶体管参数漂移。这类缺陷有个特点分布随机无法通过设计规则完全消除。我在一个28nm项目上做过统计未做修复的SRAM良率在量产初期只有六成出头主要失效模式就是单比特和双比特的硬故障。而同一批次如果开启Memory Repair良率能拉到九成以上。这个差距直接决定了芯片能不能赚钱所以Memory Repair不是锦上添花的功能而是量产必备。从成本角度看每增加一点冗余面积芯片面积会略微增大但相比整片报废的损失这笔账非常划算。通常冗余行列占存储阵列总面积的比例在百分之几到百分之十几之间具体取决于工艺成熟度和目标良率。1.2 冗余修复的基本逻辑用空间换良率Memory Repair的本质思路很朴素在正常的存储阵列旁边额外放几列冗余列和几行冗余行。测试时如果发现某列里有坏点就把整列切换到冗余列如果坏点分散在不同列但同一行就切换到冗余行。切换通过熔丝或者寄存器配置完成对功能逻辑完全透明。这里有个关键设计选择冗余的粒度。列冗余适合修复同一列内的多个坏点行冗余适合修复同一行内的多个坏点。实际项目中通常行列冗余都放因为坏点的分布模式无法提前预知。冗余数量也不是越多越好每增加一组冗余面积和测试时间都会上升需要根据工艺的缺陷密度模型来定。我参与过的一个项目最初只放了两列冗余结果测试发现有些芯片的坏点集中在三列上只能报废。后来加到四列冗余良率提升了将近八个百分点而面积只增加了不到百分之二。这个权衡过程需要和工艺、产品团队一起反复迭代。1.3 BIRA和BISR在流程中的分工BIRA是Built-In Redundancy Analysis的缩写负责分析测试结果算出该用哪些冗余去替换哪些坏列或坏行。BISR是Built-In Self-Repair负责执行修复动作把BIRA算出的方案写入修复寄存器或者烧录熔丝。在Tessent流程里BIRA通常在MBIST控制器内部或者作为独立模块存在它接收MBIST的失败信息运行分析算法输出修复方案。BISR则根据方案控制多路选择器把访问地址重定向到冗余单元。两者配合的时机很关键有些方案是测试完所有存储再统一分析修复有些是边测边修。前者分析更全局后者对测试时间更友好。注意BIRA的分析算法直接决定了修复成功率。贪心算法速度快但可能不是最优解穷举算法能找到最优方案但面积和功耗代价大。实际选型要看存储规模和冗余数量。2. Tessent MBIST里Memory Repair的完整数据流2.1 从March测试到失败信息收集MBIST用March算法对存储阵列做读写遍历常见的March C-、March SS等算法能覆盖 stuck-at、transition、coupling 等故障模型。测试过程中如果某个地址读出的数据与预期不符MBIST控制器会记录下失败地址和失败数据。这些失败信息是BIRA的输入。在Tessent里失败信息通常以压缩形式存在控制器内部的失败寄存器里因为不可能为每个存储单元都留一个记录位。压缩方式有几种一种是记录失败的行列坐标一种是记录失败的bitmap。坐标方式存储开销小但可能丢失多个坏点的关联信息bitmap方式信息全但面积代价大。我一般建议在项目早期就用bitmap方式收集失败信息因为前期需要大量数据分析来优化冗余配置。等工艺稳定、缺陷模式摸清之后再切换到坐标方式节省面积。Tessent的MBIST控制器支持配置失败信息的收集粒度这个参数在生成RTL时就要定好后期改起来比较麻烦。2.2 BIRA分析引擎的输入输出接口BIRA模块的输入包括失败信息、冗余资源列表、修复约束条件。输出是修复方案通常表示为一组多路选择器的控制信号或者一组熔丝配置值。在Tessent的架构里BIRA可以放在MBIST控制器内部也可以作为独立的硬件模块。内部实现面积小但分析能力受限于控制器资源独立实现更灵活可以支持更复杂的分析算法但面积和验证工作量都会增加。我做过的一个大容量存储项目就选了独立BIRA因为存储阵列太大失败信息多需要更强的分析能力。接口设计上有个容易踩的坑失败信息的位宽和冗余资源的数量必须匹配。如果失败信息压缩得太狠BIRA可能无法区分某些坏点组合导致修复方案不是最优。这个位宽计算需要在设计初期就精确评估留够余量。2.3 BISR执行修复的两种时机BISR执行修复有两种典型时机一种是硬修复在测试阶段完成分析后把修复方案烧录到熔丝里芯片之后每次上电都从熔丝加载修复配置另一种是软修复每次上电时重新跑一遍MBIST和BIRA把修复方案写到寄存器里。硬修复的优点是上电快不需要每次跑测试缺点是熔丝烧录后不可更改如果分析有误就没法补救。软修复的优点是灵活可以适应老化引起的新的坏点缺点是上电时间长而且需要存储修复方案的寄存器一直保持供电。实际项目中我见过两种方案混用的关键存储用硬修复保证上电速度非关键存储用软修复降低成本。Tessent支持在同一个设计里配置不同的修复策略这个灵活性很实用。3. BIRA分析算法的选型与实现细节3.1 贪心算法为什么在多数场景够用贪心算法的思路是每次找到一个坏点就用当前可用的冗余去覆盖它直到所有坏点被覆盖或者冗余用完。这个算法实现简单分析速度快在坏点数量远小于冗余资源时通常能找到可行解。我在多个项目里对比过贪心和穷举的实际效果。当坏点数量在冗余资源的三成以下时贪心算法找到的解和穷举算法几乎一致。只有当坏点分布特别刁钻比如多个坏点恰好形成某种冲突模式时贪心才可能失败。但这种情况在随机缺陷模型下概率很低。Tessent默认的BIRA分析引擎用的就是改进的贪心算法它在每一步选择时不仅考虑当前坏点还会评估对后续坏点的影响。这个改进让它在保持速度优势的同时修复成功率接近穷举算法。3.2 穷举与启发式算法的适用边界穷举算法会尝试所有可能的冗余分配组合找到能覆盖最多坏点的方案。它的优点是理论上最优缺点是计算量随冗余数量指数增长。四组冗余时组合数还可控八组以上就基本没法在合理时间内完成。启发式算法介于两者之间比如遗传算法、模拟退火等。这些算法在冗余资源多、坏点模式复杂时能找到比贪心更好的解但实现复杂度和验证工作量都高很多。我个人的经验是除非存储阵列特别大、冗余特别多否则贪心加改进就足够了。有一个判断标准可以参考如果贪心算法在多次测试中的修复失败率超过百分之一就值得考虑更复杂的算法。如果失败率在千分之一以下那优化算法的投入产出比就不高。3.3 分析引擎的硬件实现资源评估BIRA分析引擎的硬件实现需要权衡面积、功耗和速度。纯组合逻辑实现速度快但面积大状态机实现面积小但分析时间长。Tessent允许配置分析引擎的并行度并行度高则速度快但面积大。在一个移动端芯片项目里我们对功耗很敏感所以选了低并行度的状态机实现。分析时间从原来的几十个周期增加到几百个周期但面积节省了将近四成。因为MBIST测试本身就要跑很多周期BIRA分析时间占比很小这个 trade-off 完全可以接受。资源评估时还要考虑失败信息的存储。如果失败信息很多存储本身就要占不少面积。这时候可以考虑分级存储先存压缩后的坐标分析时再展开。Tessent的失败信息压缩选项里就有这种分级模式。4. BISR修复执行的硬件设计与验证4.1 冗余切换的多路选择器设计BISR执行修复的核心硬件是多路选择器网络。每个冗余列或冗余行都对应一组多路选择器根据修复配置决定是否把访问重定向到冗余单元。多路选择器的设计要注意时序。冗余路径通常比正常路径长因为要经过额外的选择逻辑。如果时序余量不够可能需要插入流水级但这会影响访问延迟。我在一个高频项目里就遇到过这个问题最后通过在冗余路径上增加一级寄存器解决代价是冗余访问多一个周期延迟。另一个细节是冗余切换的粒度。列冗余切换通常以列为单位行冗余切换以行为单位。如果坏点只影响一个比特但切换整列会浪费冗余资源。有些设计支持更细粒度的切换比如半列或者四分之一列但这会增加多路选择器的复杂度。4.2 熔丝烧录与寄存器加载的配合硬修复方案里BISR需要把修复配置烧录到熔丝。熔丝烧录需要专门的编程电压和时序通常在测试的最后阶段进行。烧录完成后芯片每次上电时由熔丝读取电路把配置加载到修复寄存器。这里有个容易忽略的点熔丝读取电路的可靠性。如果熔丝读取出错修复配置就会错误可能导致正常存储也被错误切换。我在一个项目里遇到过熔丝读取电路的亚稳态问题后来在读取路径上加了施密特触发器才解决。软修复方案里修复配置存在普通寄存器里每次上电由MBIST重新分析生成。这种方式对寄存器可靠性要求高因为寄存器翻转会导致修复失效。通常会给修复寄存器加奇偶校验或者ECC保护。4.3 修复后的功能验证怎么做修复后的功能验证分两部分一是修复逻辑本身的验证二是修复后存储功能的验证。修复逻辑验证主要检查多路选择器的切换是否正确。可以用形式验证工具证明修复配置和访问重定向的对应关系也可以用定向测试用例覆盖各种修复组合。我一般会构造一批测试用例覆盖单列修复、多列修复、行列混合修复等场景。修复后存储功能验证是在修复生效的前提下重新跑一遍MBIST确认所有坏点都被覆盖且正常单元没有被误伤。这个验证必须在修复配置加载完成后进行否则测的还是未修复的存储。提示修复验证的测试向量要包含修复配置的加载过程不能只测修复后的存储。很多bug就出在配置加载的时序上。5. 实战中容易踩的坑与排查思路5.1 失败信息压缩导致的误判前面提到失败信息压缩可以节省面积但压缩过度会导致BIRA误判。我遇到过一种情况两个坏点在不同列但同一行压缩后的坐标信息丢失了行信息BIRA以为它们在不同行结果用了两组列冗余去修浪费了一组冗余。排查这类问题的方法是在BIRA分析前后打印失败信息和修复方案对比分析结果和实际坏点分布。Tessent支持在仿真时输出这些中间信息虽然会拖慢仿真速度但在调试阶段非常值得。解决方法是调整压缩策略保留足够的行列信息。如果面积实在紧张可以考虑动态压缩坏点少时不压缩坏点多时才压缩。Tessent的失败信息收集模块支持这种动态配置。5.2 冗余资源冲突的典型场景冗余资源冲突是指多个坏点竞争同一组冗余资源。比如两个坏点在不同列但同一行如果只有列冗余就需要两组列冗余如果同时有行冗余可以用一组行冗余修复两个坏点。冲突的根源是BIRA分析时没有全局考虑。贪心算法容易陷入局部最优先修的坏点占用了冗余后面的坏点就没资源了。改进方法是让BIRA在分析时评估多种分配方案选择冗余利用率最高的。我在一个项目里遇到过极端情况坏点分布恰好让贪心算法用了四组冗余而实际上两组就够了。后来把BIRA算法换成带回溯的贪心修复成功率明显提升。5.3 修复后时序变差的处理冗余路径的时序通常比正常路径差因为多了多路选择器的延迟。如果修复后时序不满足芯片可能在高频下工作不稳定。处理方法是在设计阶段就给冗余路径留足够的时序余量或者在修复后降低工作频率。前者需要面积代价后者影响性能。我一般建议在冗余路径上做时序预算时按正常路径的百分之一百二十来约束这样修复后基本不会出现时序问题。如果确实出现了时序违例可以在冗余路径上插入寄存器把组合逻辑切成两级。代价是冗余访问多一个周期延迟但功能不受影响。这个修改需要在RTL阶段就做好后期改版成本很高。5.4 测试时间与修复覆盖率的平衡MBIST测试时间和修复覆盖率是一对矛盾。测试时间越长发现的坏点越多修复覆盖率越高但测试成本也越高。量产阶段需要在两者之间找平衡。我的经验是先做一轮完整的MBIST测试收集坏点分布数据然后根据数据调整测试算法和修复策略。如果坏点主要集中在某些特定模式可以针对性地优化March算法用更短的测试覆盖主要故障。Tessent支持配置多种MBIST测试模式量产时可以选短模式工程验证时选长模式。这个灵活性对控制测试成本很有帮助。6. 从项目数据看Memory Repair的实际收益6.1 良率提升的量化分析我在一个40nm项目上做过完整的良率对比。未开启Memory Repair时SRAM良率约百分之六十二开启后良率提升到百分之九十一。其中单比特故障修复贡献了大部分提升多比特故障修复贡献了约五个百分点。从成本角度算冗余面积增加约百分之三但良率提升带来的收益远超面积成本。按当时的价格每片晶圆多产出约三十个百分点的好片这个数字非常可观。另一个项目在更先进的工艺节点上未修复良率只有百分之四十五修复后达到百分之八十五。先进工艺的缺陷密度更高Memory Repair的收益也更明显。6.2 修复失败案例的根因归类修复失败的原因主要有几类一是坏点数量超过冗余资源这是硬限制只能通过增加冗余或者提升工艺解决二是BIRA分析算法不够优导致冗余利用率低三是BISR执行出错修复配置没有正确加载。我统计过一个项目的修复失败案例其中坏点超限占六成BIRA分析不佳占三成BISR执行错误占一成。这个分布说明冗余资源要留够余量BIRA算法要持续优化BISR的验证要充分。BISR执行错误虽然占比低但影响大因为它是系统性问题可能导致批量失效。所以BISR的验证一定要做充分包括配置加载、多路选择器切换、修复后功能测试等环节。6.3 不同工艺节点下的策略差异成熟工艺节点下缺陷密度低坏点少可以用较少的冗余和简单的BIRA算法。先进工艺节点下缺陷密度高坏点多需要更多冗余和更强的BIRA分析能力。我在28nm和40nm项目上用的冗余配置就完全不同。28nm项目放了六列四行冗余BIRA用了带回溯的贪心算法40nm项目只放了两列两行冗余BIRA用标准贪心算法就够。还有一个差异是修复时机。成熟工艺下硬修复更常见因为工艺稳定坏点模式固定先进工艺下软修复更常见因为工艺还在优化坏点模式可能变化。7. 把Memory Repair做扎实的几个关键动作7.1 设计初期的冗余规划冗余规划要在设计初期就做不能等流片回来再补。规划的依据是工艺的缺陷密度数据和目标良率。缺陷密度可以从代工厂的PDK里拿到目标良率由产品团队定。规划时要考虑最坏情况如果缺陷密度比预期高冗余够不够用。我一般建议按预期缺陷密度的两倍来规划冗余留够余量。冗余面积虽然增加但相比良率风险这个代价值得。冗余的布局也有讲究。冗余列通常放在存储阵列的边缘方便布线冗余行可以分散放置减少局部缺陷导致冗余本身失效的风险。7.2 BIRA/BISR的验证覆盖策略BIRA/BISR的验证要覆盖正常场景和异常场景。正常场景包括单坏点、多坏点、行列混合坏点异常场景包括坏点超限、失败信息错误、修复配置加载失败等。我一般会构造一个验证矩阵横轴是坏点模式纵轴是冗余配置交叉点就是测试用例。这个矩阵能保证覆盖的完整性。验证时用仿真注入坏点观察BIRA分析结果和BISR执行效果。形式验证也很有用可以证明修复逻辑的正确性。比如证明任何修复配置下访问重定向都不会导致两个地址映射到同一个物理单元。7.3 量产阶段的测试流程整合量产阶段Memory Repair要和整体测试流程整合。通常的流程是先跑MBIST收集失败信息再跑BIRA分析然后BISR执行修复最后跑功能测试确认修复效果。这个流程要在测试程序里固化不能依赖人工干预。Tessent生成的测试向量可以直接嵌入测试程序配合测试机的流程控制完成自动化。测试时间要优化。MBIST测试、BIRA分析、BISR执行、功能确认每个环节都要计时找出瓶颈。我见过一个项目因为BIRA分析时间太长导致测试时间超标后来通过提高BIRA并行度解决。7.4 数据回传与持续优化量产测试的数据要回传分析包括坏点分布、修复成功率、修复失败原因等。这些数据是持续优化的依据。我一般会建议建立数据看板实时监控修复成功率。如果成功率下降说明工艺可能出现了新的缺陷模式需要调整BIRA算法或者冗余配置。数据回传还能帮助优化测试算法。如果发现某类坏点特别多可以针对性地加强March算法的覆盖。这个迭代过程是良率持续提升的关键。8. 写在最后Memory Repair这套机制说到底是在芯片内部建了一个小型的容错系统。BIRA负责诊断BISR负责治疗冗余资源是药。药够不够、诊断准不准、治疗对不对每个环节都影响最终的良率数字。我在多个项目里反复验证过一个结论Memory Repair的收益不是线性的而是非线性的。当坏点数量在冗余资源的一半以下时修复成功率接近百分之百超过一半后成功率快速下降。所以冗余规划一定要留够余量不能卡着预期坏点数来配。还有一个体会是BIRA算法的优化永无止境。每次觉得够用了总会遇到新的坏点模式挑战它。保持算法可配置、可升级比一次性做到最优更重要。Tessent的BIRA框架支持算法插件式替换这个设计很务实。最后分享一个小技巧在项目早期用仿真注入大量随机坏点跑BIRA分析统计修复成功率和冗余利用率。这个数据能帮你快速评估冗余配置是否合理比等流片回来再调要高效得多。

芯片良率救星：Tessent MBIST中Memory Repair的BIRA与BISR实战解析

相关推荐

多人多AI协同系统架构：从代理编排到权限控制的工程实践

TensorFlow.js 实战：从浏览器端机器学习到模型部署全解析

网络安全竞赛题库高效复习法：三遍刷题与知识域拆解

更多资讯

Linux runtime pm 深度解析：从功耗异常到驱动优化

工业交换机光模块选型：1X9与SFP的区别与工程实践

MOS管驱动自举电路详解：突破95%占空比限制的五个方案

Xilinx FPGA除法器IP核配置与优化实战指南

0603贴片电容选型指南：容量、耐压与偏压特性全解析

Livox Mid-360与ROS2相机联合标定实战指南

今日更新

Multisim仿真NE555 PWM控制器：从搭电路到调占空比全流程

S32K312 AUTOSAR BSW开发实战：从配置踩坑到烧录交付

双目视觉三维人脸重建：从视差图到点云粗配准全流程解析

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？