企业官网建设流程全解析

芯片流片回来，最怕的不是功能跑不通，而是测试机台上那一片红——成千上万个存储单元里，总有那么几个物理缺陷导致读写失败。如果因为几颗坏点就整片报废，那良率数字会难看到让人怀疑人生。好在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分析，统计修复成功率和冗余利用率。这个数据能帮你快速评估冗余配置是否合理，比等流片回来再调要高效得多。