Memory Repair (六)

最爱干饭了

已于 2025-06-18 11:03:43 修改

阅读量769

点赞数 15

CC 4.0 BY-SA版权

分类专栏： # mbisr 文章标签： Repair Memory DFT 学习

于 2025-06-18 11:03:20 首次发布

本文链接：https://blog.youkuaiyun.com/wioooooo/article/details/148615217

mbisr 专栏收录该内容

8 篇文章

订阅专栏

Incremental Repair

可以采用增量修复（incremental repair）来提高制造良率或避免昂贵的现场系统维修。增量修复分为两种形式：软增量修复（soft incremental repair）和硬增量修复（hard incremental repair）。由于允许将BISR寄存器内容传输至BIRA寄存器的连接始终存在并支持增量修复，因此无需特别指定启用软增量修复的选项。

Incremental Repair Overview

可采用增量修复（incremental repair）提升制造良率或避免昂贵的现场系统维修。增量修复方案可通过软形式（soft form）或硬形式（hard form）实现。硬增量修复需在多个测试环节（如晶圆测试、封装测试、最终测试或系统测试）中对fuse box进行编程。默认情况下，硬增量修复仅针对单次测试环节启用。若需支持多次编程，可通过以下方式配置：在DftSpecification/MemoryBisr/Controller wrapper中将max_fuse_box_programming_sessions属性值设为大于1（默认值），或直接选择"unlimited"选项。

当通过整数值指定编程会话次数时，修复信息会按照"压缩算法与fuse box组织结构"章节所述方式，在存入fuse box前进行压缩处理。存储修复信息所需的fuse数量与指定整数值成正比，这是因为后续修复环节的数据会依次存储在fuse box未使用的剩余位置中。

当max_fuse_box_programming_sessions被指定为"unlimited"时，fuse box压缩功能将被禁用，此时来自BISR链的修复方案会以未压缩形式直接存储到fuse box中。

在此情况下，fuse box的组织结构与图5-52所示不同，其内部不存储会话标志、测试插入指针或电源域组指针，仅为每个电源域组存储BISR寄存器内容（包括BISR controller中的流水线寄存器）。来自不同电源域的后续修复方案可直接写入fuse box，而不会影响先前插入的修复结果。因此，每个电源域的修复方案可独立编程至fuse box，无需一次性全部写入。该方法支持无限次数的self_fuse_box_program自主模式编程会话。所需熔丝数量必须大于等于电源域组BISR链总位数加上所有电源域组流水线寄存器所需1位。在极少数预期使用超过50%修复寄存器的情况下，禁用fuse box压缩硬件同样有效——此时压缩算法效率降低，可能导致所需熔丝数量超过BISR链位数。

        软增量修复（Soft incremental repair）是指寻找一个与fuse box中已有修复方案互补的新方案，并在芯片通电期间持续应用最终修复方案。该方法适用于两种应用场景：
        • 主要应用是修复在制造阶段已完成修复但后期出现故障的系统芯片。虽然制造后故障较为罕见，但随着存储器老化或芯片在未经制造测试的条件下运行，此类故障仍可能发生。执行此类修复时无需专用编程电源，但缺点是每次系统上电时都必须重新计算修复方案。
        • 次要应用是量化硬增量修复（hard incremental repair）在制造阶段可能带来的额外良率提升（若存在）。

图5-56展示了软增量修复的流程，该流程对上述两种应用场景均适用。为简化图示，TP1和TP3未按时钟组细分，这更符合系统应用的实际场景——通常所有时钟都可用，因此单个pattern即可满足修复前和修复后的测试需求。TP2.2阶段会因存储器采用串行或并行BISR interface而存在差异：对于具有并行BISR interface的存储器，可通过load_bisr_chain操作模式快速完成BIRA至BISR的数据传输；而对于采用串行BISR interface的存储器，则需通过rotate_bisr_chain操作模式执行完整的BISR链轮转，并设置enable_bira_capture参数为on。

本节剩余部分将阐述如何实现增量修复。虽然首先解释的是软增量修复（soft incremental repair），但其中大部分内容同样适用于硬增量修复（hard incremental repair）。若需获取仅针对硬增量修复的特殊注意事项，请参阅"硬增量修复专属考量"（Considerations Specific to Hard Incremental Repair）章节。

BIRA Initialization

运行PowerUp或PowerUpEmulation自主操作后，BISR链会加载fuse box中存储的当前修复方案。若芯片从未被修复过，则BISR链仅包含全0数据。当执行memory BIST并启用BIRA时，BIRA fuse寄存器会加载对应BISR寄存器的内容。

图5-57展示了BISR与BIRA寄存器间interface的高层级视图，其中红色标注了支持增量修复的寄存器连接与使能信号。寄存器PastRepair用于指示该备用资源已在先前的test setup中被分配过。

位于BIRA寄存器输入端的复用器（mux）负责存储修复使能信号和修复地址，它能够从对应的BISR寄存器加载初始修复使能和修复地址，而非直接清除寄存器内容。BISR到BIRA的传输默认自动执行。必要时，可通过在PatternsSpecification/Patterns/TestStep/MemoryBist/DiagnosisOptions封装中指定preserve_fuse_register_values参数来禁用该传输功能。

PastRepair寄存器用于校验那些看似被备用资源覆盖的缺陷是否实际存在于备用单元本身。若确认缺陷位于备用单元，则该存储器必须判定为不可修复；反之，若所有错误均被覆盖且无需新增修复，则系统将跳过MemoryBIST的后修复pattern测试流程。此条件下，故障备用单元可能被漏检。当多个备用资源可覆盖相同地址段（行或列）时，理论上可用已知良好的备用单元替换失效单元，但Tessent Shell MemoryBIST不支持备用单元替换功能。图5-57所示电路仅适用于具备修复使能输入端的存储器，对于无此输入的存储器则采用略微不同的电路结构。Tessent Shell MemoryBIST会自动为每个含备用资源的存储器选择并生成对应电路。

BISR至BIRA的传输功能会导致两组寄存器间需增加连线数量，因此建议将两组寄存器尽可能靠近布局以降低布线拥塞风险。

BIRA Repair Status Bits Checking

在常规生产流程中，BISR链会进行轮转（rotated），并通过TDO与0值比较来检测芯片是否需要修复——这一过程只需简单pattern即可完成，无需提取单个存储器的修复状态。然而，当采用增量修复（incremental repair）时，该机制将失效，因为BISR链可能因先前测试环节（test insertion）的修复操作而包含1值。

图5-58展示了通过连接至BAP的controller GO输出来观测每个存储器两个REPAIR_STATUS位的实现方案。此解决方案仅需一个额外的全局信号用于选择两个状态位，且无需扫描controller设置链即可判定"不可修复（Non-Repairable）"和"需修复（Repair Needed）"状态。该机制同样可应用于常规生产流程中以优化测试时间。

图5-58展示了实现该机制的硬件结构，包括控制信号CheckRepairNeeded。示例中包含两个controller，每个controller连接两个配备备用资源的存储单元和一个无备用资源的存储单元。虽然无备用资源的存储单元仅具备等效于REPAIR_STATUS[1]的状态寄存器（用于指示不可修复状态，如表5-7所示），但所有存储单元均设有修复状态寄存器。当该存储单元检测到错误时，此寄存器会立即置位，并迫使controller的GO输出信号拉低。

对于含备用资源的存储单元，若发现的错误导致存储器不可修复，则REPAIR_STATUS[1]将被置位——这两种情况均意味着芯片失效。从REPAIR_STATUS[0]到controller输出的路径采用组合逻辑实现，因为在执行状态检查时GO寄存器可能未被时钟驱动。

图5-41所示的BISR生产流程修复阶段中，GO输出信号的解读逻辑总结如表5-8所示。

表5-9展示了针对compare_go、compare_go_id、compare_memory_go、check_repair_status和extract_repair_fuse_map所有参数组合所执行的操作。其中最高效的参数组合为：compare_go: On，compare_go_id: Off，check_repair_status: non_repairable。在此配置下，系统无需访问controller的设置链（对应表5-10中的操作A2）来检查所有存储器的修复状态寄存器，因为仅需将GO信号与1进行比较即可判断存储器是否可修复。

部分涉及操作A3的参数组合可能存在潜在问题，表中已用"*"标出。当工具扫描那些已禁用反馈路径的GO_ID寄存器时会产生警告提示，这种情况常见于用于测试带备用资源存储器的共享或本地比较器中的GO_ID寄存器。这些寄存器中包含的数值无实际意义，且始终与预期值"0"相匹配。

GO_ID Register Behavior

当MemoryBist controller执行Go/NoGo测试时，GO_ID寄存器的内容会在每个选通周期累积比较器的结果。算法完成后，GO_ID寄存器将为每个在测试期间检测到故障的比较器保留'1'值。GO_ID寄存器的这种累积特性被称为"sticky"（粘滞性）。

启用内置冗余分析（BIRA）模式时（通过设置RepairOptions/check_repair_status为"on"或"non_repairable"激活），GO_ID寄存器的行为取决于修复类型和比较器位置（详见表5-11）。对于采用本地比较器的不可修复存储器，以及在表5-11注2条件下采用本地比较器及IO修复的存储器，其GO_ID寄存器在BIRA操作期间保持sticky特性；其余存储器的GO_ID寄存器仅反映controller最后一次运行的比较结果。使用共享比较器时，这对应最后运行的BIST controller步骤的最终选通值；对于可修复存储器的本地比较器，则对应当前存储器的最终选通值。

当启用check_repair_status（'on'或'non_repairable'）且MemoryBist controller包含非sticky型GO_ID寄存器时，工具将返回警告。sticky型GO_ID寄存器的状态可在MBIST预修复的同一controller运行周期采集，但代价是无法实施图5-41的简易流程——此时需要完整controller setup，且tester必须对扫描数据进行释义，而非使用简易的通过/失败标准决策后续步骤。

Sticky（粘滞）条件：
- MemoryBIST controller在DftSpecification中仅配置了单个controller Step
- 该controller Step内的所有存储器均满足Note 2中针对Local Comparators列出的条件
  否则为非Sticky
Sticky（粘滞）条件：
- 存储器采用IO替换修复方案
- 存储器TCD中RedundancyAnalysis/ColumnSegment/NumberOfSpareElements属性值为"1"
- 存储器TCD未在RedundancyAnalysis/ColumnSegment封装中指定SegmentCountRange属性（即修复单元未分段）
  否则为非Sticky

Sticky（粘滞模式）
GO_ID寄存器的内容累积了MemoryBIST运行期间所有选通(strobe)周期的比较器结果。若GO_ID寄存器值为1，表示对应比较器在算法运行期间的任意时刻检测到故障。

Non-Sticky（非粘滞模式）
GO_ID寄存器仅包含最后一个选通周期的比较器结果。若GO_ID寄存器值为1，则精准指示最后一个选通周期中失效的存储器输出。该信息将被工具用于存储器诊断(ESOE)和冗余分析(BIRA)。

Examples

以下是与图5-56所示的预修复模式TP1流程对应的配置文件示例片段：

“Repair needed”状态通过专用pattern TP2进行检测，该pattern包含对所有controller的GO信号进行采样。所有WTAP和TAP需扫描两次——第一次设置CheckRepairNeeded信号，第二次采样GO信号。若出现不一致则表明芯片需要repair，否则芯片正常。所有判断均基于简单的pass/fail准则完成。该状态检查使用以下wrapper属性实现：

Absence of Fuse Programming Step

当确定需要修复（repair）时，若采用软增量修复（soft incremental repair）方式，则仅执行BIRA-to-BISR传输操作后即可重新测试芯片，期间不进行任何熔丝编程步骤（fuse programming steps）。必须进行修复后测试（post-repair testing），因为新分配的备用单元尚未经过验证。此外，通过软增量修复流程分配的备用单元未在全工况下接受测试，可能因电压微小波动或温度时变特性导致故障。

Handling of Blocks Without Incremental Repair Capability

        不具备增量修复（incremental repair）功能的模块在使用增量修复流程时需特殊处理，主要差异如下：
        • 非增量修复模块必须置于不同的电源域组（Power Domain Group, PDG）。PDG可以是同一电源域的子分区，其核心目的是对支持/不支持增量修复的模块分别控制BISR时钟。
        • 非增量修复模块必须在TP1 pattern中以Go/NoGo模式运行，其处理方式等同于无备用资源的存储器。若TP1测试过程中出现故障，则直接判定芯片不可修复（non-repairable）。
        • 非增量修复模块在TP2.2 pattern运行期间无法执行BIRA-to-BISR传输，否则会导致这些模块的修复方案丢失。因此，支持增量修复的模块必须按PDG逐个执行BIRA-to-BISR传输。

Considerations Specific to Hard Incremental Repair

        硬增量修复是软增量修复的扩展，主要区别如下：
        • 硬件支持——通过在DftSpecification/MemoryBisr/Controller封装中设置max_fuse_box_programming_sessions属性为"unlimited"、或1（默认值）及以上的整数值，可启用硬增量修复所需的硬件。仅顶层BISR controller的硬件会受影响，BISR链的实现保持不变，这意味着现有模块可同时支持软硬增量修复。
        • fuse box容量——使用硬增量修复时，内存修复所需的熔丝数量会增加。
        • fuse box组织结构——修复数据在fuse box中的存储方式有所不同，但当max_fuse_box_programming_sessions设为整数值时，基础压缩算法不变；若设为"unlimited"则禁用压缩。
        • 修复流程——基本与无硬增量修复的流程相同，核心区别在于制造或系统运行时可根据max_fuse_box_programming_sessions属性值重复执行流程。以下展示两个示例：第一个针对整数值设定，第二个针对"unlimited"设定。

如图5-59示例，一个时钟组在TP1.1（LVcc）和TP1.2（HVcc）两组不同pattern条件下测试。运行TP1.1时，BIRA电路通过TP0 pattern加载BISR链的值初始化，且将PatternsSpecification/Patterns/TestStep/MemoryBist/DiagnosisOptions/preserve_fuse_register_values配置属性设为Off以计算新修复方案（需考虑fuse box中已编程的修复方案）；而运行TP1.2时该属性设为On以累积BIRA结果。TP1.1和TP1.2均需检查所有Tessent MemoryBIST controller的Go输出来判断是否存在不可修复内存。完成所有内存测试后运行TP1.3 pattern确认是否需要修复，再次通过Go输出决定是否用TP2.2 pattern执行熔丝编程。后续的熔丝编程、验证及修复后步骤与《顶层验证与pattern生成》描述的流程完全一致，且假设整个流程中芯片始终未断电。

在图5-60的示例中，进行熔丝编程前可能需要额外步骤来重置BISR链中与初始修复方案对应的某些位（具体取决于所用非易失性存储器的类型）。大多数eFuse宏不允许对相同熔丝重新编程（eFuse数据手册会注明此特性），若不允许重编程，则必须执行TP2.2的Verify步骤以避免重复编程熔丝。

当max_fuse_box_programming_sessions设为unlimited时，BISR controller的Verify自主模式会禁用压缩功能，其工作原理有所不同：Verify步骤通过XOR运算比对BISR链内容与fuse box中解压后的存储值，结果仅将eFuse中未编程过的位重新加载回BISR链。这既能防止eFuse位的重复编程，也可避免fuse box损坏。需注意，该步骤在编程前执行时会报错，但编程后必须通过验证。

若编程成功，BISR链在TP2.4结束时将全部置0。当BISR controller支持有限次修复会话时，TP2.3的Verify步骤会从fuse box解压出正确修复数据加载到BISR链；而DftSpecification中max_repair_sessions设为unlimited时，TP2.4的Verify步骤行为则不同——此时TP2.4被拆分为两个TestStep执行以下操作：