当前位置：首页 > news >正文

Memory Repair (三)

news 2025/6/12 17:42:26

Top-Level Verification and Pattern Generation

本节涵盖 fuse box 编程、顶层 BISR（内置自修复）验证以及生产测试 pattern 的生成

Fuse Box Programming

通过 BISR controller 对 fuse box 进行编程的两种方法如下：
• 采用 Autonomous mode（自主模式），详见 “Autonomous Self Fuse Box Program” 章节。此默认模式用于存储 BISR registers 中的内存修复信息。
• 通过 TAP（测试访问端口）实现，详见 “FuseBox Access” 章节。此方法多用于诊断以及存储非内存修复类数据

“Verifying BISR at the Block Level” 章节详细阐述了这两种方法

Autonomous Self Fuse Box Program

在自主式self_fuse_box_program运行模式下，BISR控制器具备以下功能：可对BISR链进行循环移位、压缩其内容并将压缩后的数据写入熔丝盒(fuse box)。需要特别注意的是，在自主熔丝盒编程操作启动前，BISR链必须已存储正确的内存修复信息。目前有两种方法可将内存修复信息载入BISR链：
1. 先执行内存内建自测试(Memory BIST)，随后完成BIRA至BISR的数据传输
2. 通过测试访问端口(TAP)扫描输入BISR信息

FuseBox Access

当 BISR controller 在 FuseBoxAccess 模式下运行时，可通过 TAP 对 fuse box 进行读写访问。
在此运行模式下，通过芯片的 TDI 和 TDO 端口访问配置链（setup chain）。该配置链包含存储待写入 fuse box 地址的寄存器，单次仅写入熔丝盒的一个比特。每次对 fuse box 执行写入操作时，需通过 TAP 将熔丝地址值扫描输入至 BISR controller 的配置链中。随后 TAP 必须暂停操作以提供 fuse box 数据手册规定的足够延迟。通过连续扫描地址并暂停（直至写入持续时间延迟结束），可实现多个熔丝盒地址的写入。写入持续时间延迟由 PatternsSpecification 属性值 fuse_box_write_duration 控制，且在此模式下不监控 fuse box Interface 发出的完成信号（done signal）。

与写入操作类似，fuse box 的读取操作每次仅能读取单个比特位。执行读取时，需通过 TAP 将目标比特地址扫描输入 BISR controller。该比特值会被捕获至控制器的配置链（setup chain），并在下一条移位指令执行时扫描输出。需注意：通过 TAP 访问 fuse box 时不监控 done 信号，访问时长由测试平台（testbench）决定。

当 DftSpecification 属性 fuse_box_location 设为"internal"时允许2个时钟周期，设为"external"时则为3个时钟周期。用户可通过 PatternsSpecification 属性 test_time_multiplier 延长访问时间

在 FuseBoxAccess 模式下对 fuse box 进行编程时，必须先将 BISR chain 的内容扫描输出，并利用 Tessent 产品版本中提供的 CompressBisrChain 脚本进行外部压缩，随后逐个熔丝位写入。需要特别强调的是，BISR chain 初始必须已存储正确的内存修复信息。

执行该过程时，需使用 write_memory_repair_dictionary 命令生成运行 CompressBisrChain 脚本所需的配置文件。该配置文件同时可作为重要的验证参考，因其包含：

所有 fuse box 参数
按电源域分组排序的 BISR register ICL 实例列表

Verifying BISR at the Block Level

可修复存储器的验证涉及额外任务，这些任务在非自修复存储器中并不需要。可通过自底向上的设计流程，在设计模块层级执行以下验证任务实现。

需注意：下列任务清单默认模块中不存在BISR controller（内置自修复控制器）。若存在BISR controller，请参阅"验证顶层BISR"章节。

• 执行故障注入存储器BIST

• 完成BIRA至BISR捕获

o 将外部BISR链扫描至内部BISR链
具有串行BISR interface（接口）的存储器需要此额外步骤。需通过BISR链循环移位将外部BISR链内容复制到内部BISR链寄存器。对于采用并行BISR interface的存储器，此步骤可省略，因为外部BISR寄存器直接驱动存储器修复端口。但若设计中存在至少一个串行BISR interface存储器，则所有BISR寄存器（包括并行BISR interface存储器的寄存器）都必须执行移位循环。
访问带修复功能物理存储器的Shared Bus集群无论物理存储器采用何种修复interface，均需执行BISR移位步骤。此类集群会插入两组BISR寄存器：

• 一组位于集群外部，连接至BIRA逻辑

• 另一组位于集群内部，连接至物理存储器
内外BISR寄存器长度相同。BIRA-to-BISR捕获将修复方案从BIRA逻辑传输至外部BISR寄存器，再通过BISR寄存器循环移位将修复方案传递至内部BISR寄存器。

• 执行修复后存储器BIST
如图5-31所示，这些验证任务在PatternsSpecification配置文件中定义，适用于带BISR硬件的memory BIST controller（存储器内建自测试控制器）。完整配置文件语法请参阅《Tessent Shell参考手册》中"基于配置的规范"章节。此外，write_memory_repair_dictionary命令生成的配置文件可作为验证参考，该文件按电源域组排列了BISR寄存器ICL实例的有序列表。

Figure 5-31. Example PatternsSpecification to Verify BIRA and BISR

Running Fault-Inserted Memory BIST

在此任务中，将按照存储器供应商提供的文档流程注入故障，通常需要在启动仿真时添加命令行选项。如图5-31所示，TestStep（PreRepair）会调用MemoryBIST（存储器内建自测试）。由于MemoryBIST算法对存储器进行验证，BIRA模块会收集故障信息并计算存储器的修复方案。若存储器可修复，当MemoryBIST controller（控制器）完成运行后，即可从BIRA模块获取修复解决方案。

Performing BIRA-to-BISR Capture

在此任务中，BIRA（内置修复分析）数值将被捕获至外部BISR（内置自修复）寄存器。该步骤通过图5-31所示的TestStep（CaptureBiraRotate）实现。无论存储器采用串行还是并行修复interface（接口），从BIRA到BISR寄存器的传输方式均相同。完成捕获后，系统将执行BISR链的完整循环移位——该操作既实现了串行BISR interface存储器从外部到内部BISR寄存器的修复信息传输，同时也验证了并行与串行BISR interface存储器可混合使用的兼容性。

对于底层模块的BISR链仿真，需通过PatternsSpecification中的SimulationOptions/emulate_bisr_chains_in_lower_physical_blocks属性进行配置，并配合LowerPhysicalBlockInstances属性指定设计视图。关于auto（默认）模式下这些属性的交互作用及最终仿真视图，请参阅emulate_bisr_chains_in_lower_physical_blocks属性的详细说明。需特别注意：当底层模块包含串行修复interface存储器时，若BisrChainAccessOptions/select_bisr_registers属性设为"internal"或"internal_only"，或DftSpecification AdvancedOptions/power_up_chain_select属性设为"internal"，采用ijtag_graybox视图的仿真可能失败。这是因为ijtag_graybox视图未包含存储器内部修复链，可能导致BISR链出现未知值。解决方案是为相关底层模块指定完整设计视图，但这可能增加仿真时间。

Running Post-Repair Memory BIST

此任务将重新运行首个测试步骤中使用的 MemoryBIST（存储器内建自测试）算法。在此过程中，可修复存储器将运用修复信息，使用冗余单元替换故障存储单元。若存储器修复成功，MemoryBIST controller（控制器）输出的 GO 信号在仿真结束时应为高电平。假设所有注入故障的存储器均可修复，那么此测试阶段出现的比对失败通常表明存储器库文件存在问题。

Verifying Top-Level BISR

带有BISR硬件的芯片签核流程通过TAP验证BISR控制器的FuseBoxAccess模式、BisrChainAccess模式和自主操作模式。

FuseBox Access Mode章节的示例展示了为TAP Access模式生成的默认PatternsSpecification配置文件片段，而Autonomous Modes章节的示例则展示了用于自主模式的默认PatternsSpecification配置文件片段。

无需在芯片顶层对插入故障的存储器运行MemoryBIST，此类验证更适合在模块级执行——此时MemoryBIST能覆盖所有存储器的完整地址空间。在顶层，MemoryBIST只需在reduced_address_count开启且BISR寄存器复位为0的状态下运行，这是默认验证memory BIST、BIRA与BISR间交互的唯一类型。

因此默认推荐的顶层BISR验证流程假定BIRA寄存器与BISR寄存器之间、以及BISR寄存器与存储器修复端口之间的连接已在组装级完成验证，故顶层生成的测试平台仅验证BISR寄存器、BISR controller、TAP与fuse box之间的连接。

用户可随时修改PatternsSpecification配置文件以验证额外连接。write_memory_repair_dictionary命令生成的配置文件可作为重要验证参考，其中包含所有fuse box参数以及按电源域组排列的BISR寄存器ICL实例有序列表。

FuseBox Access Mode

FuseBox Access模式通过TAP对fuse box进行写入和读取操作，该模式会测试fuse box interface（自主模式同样使用此接口）。当fuse box与其他应用共享时（即DftSpecification中设置为fuse_box_location: External），该模式也可用于功能验证。

在图5-32中，第一个TestStep（FuseBoxProgram）对地址0和15的两个熔丝进行编程。这些地址是任意的，必要时可轻松添加更多地址以测试fuse box的更多地址线。接下来的TestStep（FuseBoxRead）读取fuse box内容，并预期除地址0和15（预期值为1）外所有位置均为0。读取地址范围可通过read_address命令限定，若未指定范围，则默认范围为0至number_of_fuses。

Autonomous Modes

        自主模式（Autonomous modes）实现的功能包括：
        • 计算BISR链长度
        • 压缩BISR链包含的 bit pattern
        • 编程熔丝（Programming fuses）
        • 读取熔丝（Reading fuses）
        • 解压缩修复信息
        • 将其与BISR链的原始内容进行对比

BISRChainAccess模式在验证自主模式时同样会被调用，用于在TestStep(SelfFuseBoxProgram)前加载比特pattern，并在TestStep(VerifyFuseBox)后卸载相同比特pattern：

• 图5-33中的首个TestStep（BisrLoaderReset）初始化BISR链并计算其长度，该长度将用于后续测试步骤；

• 第二个TestStep执行BisrChainAccess操作，向BISR链加载任意比特pattern（本例仅设置BISR寄存器的第0和第4位，这些位代表该寄存器内的虚拟修复方案）。需注意BISR链的比特索引以最接近TDO的位为0。在加载比特pattern时，BISR链值会通过TDO移出并进行比对。当存在多条BISR扫描链时，默认会将所有链级联以移入比特模式；

• 第三个TestStep（SelfFuseBoxProgram）对BISR链的任意比特pattern进行循环移位、压缩并编程对应熔丝。由于编程如此简单的比特pattern所需时间远低于制造允许的最大时长，故通过max_repair_count属性缩短仿真时间（该属性仅用于验证，不包含在制造用配置文件中）。SelfFuseBoxProgram模式不会破坏BISR链内容。若fuse box interface具有内部缓冲区（例如接口带有write_buffer_transfer属性的端口），可通过设置inhibit_buffer_to_fuse_transfer为On来延迟最终熔丝编程至后续测试步骤；

• 第四个TestStep（VerifyFuseBox）验证解压后的fuse box内容是否与初始加载至BISR链的比特pattern一致。由于已知SelfFuseBoxProgram步骤后BISR链内容未被破坏，从fuse box解压的值应与BISR链内容匹配。与所有自主模式相同，操作成功时GO和DONE输出信号将置1。

Figure 5-33. PatternsSpecification Configuration for Autonomous Modes

Autonomous Mode for Memory BIST-Only Verification

在以下示例中，控制器的一种自主模式 clear_bisr_chain 会初始化 BISR 链中的所有触发器，而无需计算其长度。这使得在执行 MBIST 验证时，能够快速初始化存储器修复输入。对于测试可修复存储器的 MBIST 控制器，TestStep (bisr_clear) 会自动添加到 PatternsSpecification 文件中。

Functional Mode Verification

BISR controller具备一种功能操作模式，可使存储器在系统中被修复。您必须验证正确的功能输入信号是否施加到BISR controller上，并确认您的系统能否在该功能操作模式下准确解析BISR controller的各类输出。此项验证需通过手动创建的功能pattern来完成。

本节描述了系统逻辑与BISR controller之间的通信协议，以及估算修复时间的计算公式。同时本节还演示了如何结合其他BISR生产测试项目，通过ProcedureStep对功能操作模式进行局部验证。

BISR Protocol (Single Power Domain Group)

下图及后续章节概述了单电源域组的BISR协议流程。controller通过系统时钟读取、解压缩fuse box内容，并将其移入BISR链。假设TAP已复位，当resetN功能输入信号出现低到高跳变时将触发修复流程。controller的Done输出信号指示修复操作完成，Go输出信号则表明操作是否成功。第三个输出信号bisrCEDis用于标识实际存储器修复发生的时刻，该信号也可用于禁用带有串行修复interface的存储器。图5-35展示了单电源域的协议时序。

resetN输入信号通过系统时钟输入clk进行同步。resetN输入必须保持足够时长的低电平，以异步复位同步器电路中的四个触发器，具体时长取决于用于电路综合的单元库。BISR controller输出采用功能时钟输入的门控版本进行同步初始化，当resetN上检测到确定的高电平后，初始化过程将在3个时钟周期内完成。

在修复完成前，Done与Go输出始终保持低电平。修复完成后Done输出变为高电平，若修复成功则Go输出也跳变为高电平，否则保持低电平。bisrCEDis输出在初始化完成后的第1个周期变为高电平，并在修复完成时恢复低电平。

对于具有串行修复interface的存储器，在bisrCEDis信号变为低电平后可能无法立即使用。您应当等待数个时钟周期，以确保该信号有足够时间传播至所有与BISR controller不在相同时钟域的存储器。在这种情况下，时序脚本（SDC和STA）会将其视为伪路径处理，必须通过功能仿真来验证这个异步interface的正确性。

BISR Protocol (Multiple Power Domain Groups)

当存在多个电源域组时，BISR协议会有细微差异。图5-36展示了包含三个电源域组的电路BISR协议。其中clk（修复时钟）、resetN（修复使能）、Done和Go信号与图5-35相同。图5-36新增的信号包括：一个3位输入总线PwrDomGrpEn（对应DftSpecification/MemoryBIST PowerDomainName(pdg_name)/enable_from_pmu_connection属性），以及为三个电源域组分别配置的一组输出信号。

与各电源域组关联的信号名称均带有相同后缀，该后缀即为您在DftSpecification步骤中指定的电源域组名称。这三个电源域组分别为：

对于每个电源域组，图5-36展示了四个关键信号：
• toBisrSi_Gx - 作为BISR链的串行输入信号
• bisrClk_Gx - 驱动BISR链的专用时钟信号
• PDGDone_Gx（对应AdvancedOptions/bisr_done_connection属性）- 用于指示第x组存储器已完成修复并准备就绪
• bisrCEDis_Gx（关联PowerDomainOptions/PowerDomainName(pdg_name)/busy_to_pmu_connection属性）- 表示该组正处于修复过程中

每组还包含未在图中显示的专属信号，包括链串行输出信号fromBisr_Gx和复位信号bisrRstn_Gx。

PwrDomGrpEn输入总线决定修复哪些内存组，该总线的每个比特位对应一个组，且允许任意组的组合。总线的最低有效位对应组G0。在示例中，比特位0和2被设为1，表明组G0和G2将被修复，而组G1的状态则保持不变。组G1此前已被修复，因为PDGDone_G1信号的值为1。

PwrDomGrpEn输入必须在resetN下降沿前保持稳定。这两个输入信号通过组合控制触发器的异步复位，因此建议使用同一时钟的不同边沿从触发器生成这两个信号。选定组的PDGDone_Gx信号会在resetN下降沿立即变为低电平。

PwrDomGrpEn与resetN的关系不受时序脚本（SDC和STA）约束，这些脚本默认将其视为false path。必须通过功能仿真来验证此interface。

与单电源域组的情况相同，BISR controller会在resetN上升沿后的几个周期启动。各组修复顺序由DftSpecification的power_domain_priority_order属性决定。在本示例中，组G0首先被修复，随后是组G2。各组的toBisrSi_Gx和bisrClk_Gx信号活动显示了对应组的修复时机。当组G1修复完成时，PDGDone_G0信号立即置为1。

若全局输出Done和Go呈现Done=Go=1状态，则表明修复成功。

Repair Time Calculation

进行修复操作期间禁止访问memory。修复操作持续时间可变，其边界条件如下：
最小修复时间 Trepair_min = Tclk × bisrChainLength
最大修复时间 Trepair_max = Trepair_min + (readDuration × Tclk × numberFuses)
其中：
• Tclk —— 修复时钟clk的周期
• bisrChainLength —— BISR链的长度
• readDuration —— fuse box interface向BISR controller返回熔丝值所需的时钟周期数
• numberFuses —— fuse box中为memory修复分配的熔丝数量

实际应用中极少会使用全部熔丝，且BISR链长度通常远大于memory修复分配的熔丝数量，因此修复时间往往更接近下限值Trepair_min。但修复时间实际上不会达到理论下限，因为即使无需memory修复，电路初始化和部分熔丝读取操作也会产生固定开销。

当 fuse_box_location 设置为 internal 时，readDuration 参数标准值为 2；若 fuse_box_location 设置为 external 且 align_access_en_with_address 设置为 on 或 auto 时，该参数值为 3。这些数值通常能较准确地估算修复时间，但根据 fuse box 的时序特性及 fuse box interface 设计，实际计算得出的修复时间可能略低于理论上限值。

在某些情况下（尤其是高频场景），从 fuse box 读取熔丝可能需要超过 2（或 3）个时钟周期。但 fuse box 单次访问可读取一整行熔丝，并将结果暂存于 fuse box 输出端。由于 BISR controller 每次仅请求单个熔丝值，若数据已存在于 fuse box 输出端，则 fuse box interface 可快速返回数值；仅当必要时才会触发较慢的 fuse box 访问操作。

例如，某包含 1024 个熔丝的 fuse box 支持单次读取 32 个熔丝，则仅约 3% 的 BISR controller 请求需执行实际 fuse box 访问：
（32 次访问请求 / 1024 总熔丝数）× 100 = 3.13%

若单次 fuse box 访问需消耗 10 个时钟周期，则实际 readDuration 因子会从基准值 2 提升至 2.25，计算逻辑如下：

fuse box 总访问次数：32 次（每次获取 32 个熔丝值）
单次访问的时钟周期分解：
- 熔丝 1：10 周期（首次访问开销）
- 熔丝 2-31：各 2 周期（readDuration = 2 时）
- 合计：每 32 个熔丝值消耗 72 周期
实际 readDuration = (32 × 72 周期) / 1024 熔丝 = 2.25 周期/熔丝

但由于修复时间主要受 BISR chain 加载时间主导，此误差对修复时间上限的影响仅几个百分点。

对于多电源域组电路，前述公式中的 bisrChainLength 应为 PwrDomGrpEn 输入总线指定待修复组的所有 BISR chain 长度之和。

Time Out Condition

每次电源域上电时，系统会通过异步复位 BISR chain 并在修复数据前端插入标志位 1 的方式，验证 BISR chain 的完整性并计算其长度。BISR controller 会持续计数时钟周期，直到该标志位 1 出现在链输出端或达到最大计数值。无论哪种情况，Done 输出都会置高，但 Go 输出在第一种情况下为高电平（链正常），第二种情况下为低电平（链故障）。

默认情况下，最大计数值设置为当前计算得出的最长 BISR chain 长度的 4 倍。此宽松阈值旨在兼容 BISR controller 生成后可能发生的 BISR chain 配置变更（例如 ECO 修改），使控制器无需重新生成即可自动适配新配置。用户可通过 DftSpecification 的 max_bisr_chain_length 属性修改该阈值，且所有电源域组共享同一最大计数值。

Combining Functional Mode with Manufacturing Tests

可以将功能运行模式与其他制造测试模式相结合。这种方法能够利用自动化验证基础设施，验证系统逻辑是否正确控制 BISR controller 的功能输入信号。但需注意，该方法无法验证系统逻辑对 BISR controller 各类输出信号的响应行为。

该方法通过在pattern集中使用ProcedureStep封装器来描述用户自定义的BISR controller输入序列。通常，这类用户自定义序列会调用SVF文件或iProc来修改引脚设置，并结合iRunLoop或ProcedureStep的tester_cycles、tck_cycles或wait_time属性。在修复后模式规范(Post-repair PatternsSpecification)中，用于验证BISR controller功能上电操作模式的用户自定义序列可以替代默认生成的上电仿真模式测试步骤。该上电仿真模式测试步骤默认由以下属性标识生成，并在图5-46所示的修复后测试pattern示例中使用：

图5-37展示了一个名为custom_init_bisr_chains的iProc示例，当功能复位引脚"bisr_rstn"作为器件主输入且该主输入已在ICL中定义为DataInPort时，此示例可作为模板使用。其中绿色高亮代码表示用户自定义创建的功能上电序列：该序列首先将BISR controllers的resetN端口置0，然后切换为1以启动BISR controller，并串行加载fuse box中的修复数据至BISR chain。

如图5-38所示，此iProc可通过ProcedureStep调用来初始化BISR chain。需注意，该iProc需要以BISR controller的ICL实例名称作为参数。当通过"bisr_rstn"功能输入完成BISR chain初始化后，即可对已修复memory执行post-repair memory BIST测试。

Creating Multiple Load Scan Patterns With Repairable Memories

可采用多重加载扫描pattern的方式，通过ROM和RAM memory生成扫描pattern。在对可修复memory执行多重加载pattern生成前，必须将MemoryBIST运行产生的修复信息加载至memory修复端口。需特别注意：由于test_enable信号在扫描pattern结束时解除断言可能导致修复信息被清除，因此每次运行多重加载pattern前都必须重新加载修复信息。

当设计包含MemoryBISR模块时，运行process_dft_specification流程会自动创建初始化memory修复端口所需的修复信息文件。该文件生成于Tessent instrument容器中，其路径为：

<tsdb_outdir>/<design>_<design_id>_mbisr.instrument/
<design>_<design_id>_tessent_mbisr.pdl

该文件包含一个必须作为 test setup 部分调用的 iTopProc，用于在生成多个 load pattern 前初始化 BISR 链。图5-39 和图5-40 展示了如何利用该 iProc 初始化 BISR 链，随后创建并输出多个 load pattern 的示例。

在芯片层级调用 set_test_setup_icall 时，必须指定 “-front” 命令行选项以确保内存修复流程在 pattern 起始阶段运行。若不执行此操作，将导致 pattern generation 报错，因为在此状态下，扫描测试信号会阻断对修复逻辑的访问。为满足 E14 设计规则要求，必须在 pattern generation 阶段提供 eFuse 的 ATPG 模型。若该模型不可用，作为替代方案，可对 eFuse interface 模块的 fuseValue 输出引脚施加输入约束。具体操作是：为 fuse box interface 实例的 fuseValue 输出引脚创建关联的伪端口，并在该伪端口上添加值为 0 的常量输入约束，如下例所示：

Generating Your Manufacturing Test Patterns

可能存在多种变体，但唯一区别在于部分 test pattern 可合并为单一 test pattern。图5-41展示了一个 BISR 制造流程示例，其中 test pattern 被划分为四个组别——分别以 TP0、TP1、TP2 和 TP3 作为前缀标识的初始化（initialization）、修复前（pre-repair）、修复（repair）及修复后（post-repair）阶段。后续章节将详细描述各组别，并展示示例制造配置文件片段。这些 test pattern 组别均在 TestStep 封装内的 MemoryBisr 与 MemoryBist 封装中进行定义。

Initialization Test Pattern

Initialization test pattern 会清除所有 BISR 寄存器，确保在运行 Pre-Repair 测试模式组时不使用可修复存储器的备用资源。该 pattern 还用于确定 BISR 链的长度并验证其完整性。下图展示了一个 Initialization test pattern 的示例。

Pre-Repair Test Patterns

Pre-Repair 测试模式组会对所有存储器进行测试，并判断是否存在无法修复的存储器——无论是由于存储器本身不具备备用资源，还是备用资源数量不足以修复所有检测到的故障。

• 对于仅测试无备用资源存储器的 controller，需将 memory BIST controller 的 GO 输出与“1”进行比对（设置 compare_go:on）。同时可通过检查 GO_ID 寄存器收集诊断信息（设置 compare_go_id:on）。

• 对于测试至少一个带备用资源存储器的 controller，需使用 check_repair_status:non_repairable 参数判断是否存在不可修复存储器。根据需求，compare_go 和 compare_go_id 存在多种可选配置（详见表5-9）。所有配置组合最终均需验证所有存储器的 REPAIR_STATUS[1] 是否为0，否则 pattern 将判定失败。需注意：无备用资源的存储器同样具备 REPAIR_STATUS 寄存器——当设置 compare_go:on 和 compare_go_id:off 时，无需扫描 GO_ID_REGs 即可快速定位故障存储器。

• 若设计包含由 software version 7.0-SP03 或 Tessent v9.0 生成的 memory BIST controller，则不带内建自修复功能（BIRA）的存储器将不会在 Pre-Repair memory BIST pattern 中进行测试。针对此类 controller，需额外执行验证步骤来检测无 BIRA 的存储器。若设计中存在任何由 7.0-SP03 或 Tessent v9.0 生成的 memory BIST controller，建议运行 Post-Repair memory BIST pattern 进行检测。

• 若设计包含由 software version 7.0-SP01 或更早版本生成的 memory BIST controller，系统将默认关闭 compare_go_id 属性，且不带 BIRA 的存储器不会在 Pre-Repair memory BIST pattern 中进行测试。若设计中存在任何由 7.0-SP01 或更早版本生成的 memory BIST controller，建议运行 Post-Repair memory BIST pattern 进行检测。

• 在 TSDB 目录中生成制造测试图形（manufacturing patterns）时，若 Tessent Shell 检测到部分不带 BIRA 的存储器未在 Pre-Repair memory BIST patterns 中进行测试，系统将发出警告。若出现此警告，必须运行 Post-Repair manufacturing pattern 以验证这些不带 BIRA 的存储器。

由于多数 tester 一次只能生成一个时钟周期及其整数倍频，系统默认会为每个时钟组生成独立的 Patterns 或 MemoryBist 封装模块。每个封装模块会生成单独的测试图形文件（例如 WGL 文件）。通常，每个测试图形文件开头会包含 TAP 复位操作，但 Pre-Repair patterns 除外（通过设置 exclude_initial_ireset_from_patterns:on 实现）。这是因为必须保持所有时钟组的所有 BIST controller 状态不变，直到完成 Repair 测试图形组的操作为止。

若在 Pre-Repair 测试图形组中的任何测试图形执行期间出现故障，则该芯片将被判定为不良品，tester 可立即转入测试下一颗芯片。但如果所有 Pre-Repair 测试图形均通过检测，tester 将继续执行 Repair 测试图形组。下图展示了 Pre-Repair test patterns 的典型示例。

Repair Test Patterns

Repair 测试组包含以下四个测试步骤：
• 第一步（TP2_1_CheckRepairNeeded）：检查所有带备用资源存储器的 RepairStatus[0]。若该值不为0，则 pattern 判定失败并触发修复流程。需注意，此步骤仅允许设置 check_repair_status 和 split_patterns_file 属性（例外情况请参阅“Pre-Repair Test Patterns”章节中关于 software version 7.0-SP03 和 Tessent v9.0 生成的 controller 的说明）。若出现比对失败，tester 将自动执行下一步测试。

• 第二步（TP2_2_CaptureBira）：将内建修复分析寄存器（BIRA registers）的内容传输至 BISR registers。推荐采用 load_bisr_chain 自主操作模式执行此步骤，该模式可在单时钟周期内完成，从而显著优化测试时间。

• Repair组的第三步编程操作（TP2_2_SelfFuseBoxProgram）将BISR链的内容进行压缩并编程到fuse中。此步骤所需时间是写入持续时间（fuse_box_write_duration: time）和可用于内存修复的fuse数量（number_of_fuses_for_repair: int | auto）的函数，这两个参数分别在PatternsSpecification和DftSpecification中指定。例如，如果有256个fuse可用，且每个fuse编程需要10us，则测试pattern大约需要1.3ms运行，因为平均假设只有50%的fuse需要编程。此后，将BISR控制器的Go和Done输出与1进行比较，不匹配则表明芯片不良。否则执行下一步。需要注意的是，如果需要调整单个fuse的编程时间，可以在PatternsSpecification的TestStep/MemoryBisr/Controller封装中覆盖fuse_box_write_duration参数。

• 第四步验证操作（TP2_3_VerifyFuseBox）读取fuse box内容，将其解压缩，并将解压后的修复信息应用到BISR链的输入端，同时将该输入与BISR链的输出端进行比对（输出端仍包含由BIRA电路计算的修复信息）。需注意，对于具有串行修复接口的存储器，内部BISR链被选作与解压修复信息比对的参考基准。该BISR链在Repair组第一步操作（TP2_2_CaptureBiraRotate）后即包含修复信息的副本。值得注意的是，如图5-41所示，此测试步骤并不总是生成单独的测试pattern（TP2.3）。更多详细信息请参阅"Tester Settings Considerations"章节。

Post-Repair Test Patterns

修复后测试模式组（Post-Repair group）与修复前测试模式组（Pre-Repair group）类似，主要区别在于所有测试模式（test patterns）中均不允许出现存储器故障，且需检查所有memory BIST控制器的GO输出（compare_go: on）。另一显著差异是每个测试模式（每时钟组对应一个）均为独立模块——芯片可在各时钟组测试间断电，而BISR链则通过预先编程至fuse box的修复信息完成初始化。默认配置文件指定通过power_up_emulation操作读取修复信息，这意味着fuse box的读取操作使用TAP时钟完成。但您也可选择在电源启动阶段改用系统时钟执行power_up_emulation操作。如"功能模式验证"章节所述，可通过在配置文件中添加ProcedureStep（可调用SVF文件或iProc修改引脚设置）并结合ProcedureStep的tester_cycles、tck_cycles或wait_time属性组合来实现该需求。

Test Time Reduction Options

测试程序中仅包含针对可修复存储器的控制器（controllers）测试。对于采用多电源域组的存储器，您只需为每个时钟组加载必要的BISR链。下图展示了修复后测试模式（Post-Repair test patterns）的示例。

Tester Settings Considerations

本节将讨论关于正确配置测试设备（tester）和运行修复测试模式（repair patterns）的重要注意事项。在执行修复前测试模式（Pre-Repair Test Patterns）和修复测试模式（Repair Test Patterns）期间，被测电路必须保持持续供电且不得中断。各测试模式（test patterns）之间的输入引脚状态应维持不变，且BIRA与BISR寄存器状态必须在模式切换时保留。而为每个时钟组生成的修复后测试模式（Post-Repair Test Patterns）具有独立性——被测电路可在不同测试模式间断电，BISR寄存器状态会在每个测试模式开始时自动恢复。

在执行修复测试模式（Repair test patterns）时，可能需要通过专用电源驱动fuse box的编程电压引脚。这种情况适用于需要编程电流超过测试设备（tester）数据通道驱动能力（通常为20mA）的熔丝。在PatternsSpecification的TestStep中，若需更改专用电源设置，可通过可选属性force_voltage(pin_name):value实现，这将导致测试模式分割（如图5-41所示）。

具体而言，测试模式TP2.2（包含测试步骤TP2_2_CaptureBira和TP2_2_SelfFuseBoxProgram）运行时，需将专用电源电压设置为fuse box编程所需值；而TP2_1_CheckRepairNeeded和TP2_3_VerifyFuseBoxTP2.3则需将电压调整为fuse box读取模式。测试模式文件（如WGL格式）会包含注释，明确提示需要更改电源设置。

修复测试组（Repair group）的第一步（TP2_1_CheckRepairNeeded）必须独立为一个单独的测试模式（test pattern），以便通过简单的通过/失败标准筛选出合格芯片与需要修复的芯片。这种方法在某些情况下能显著节省测试时间。由于该测试步骤是MembistPVerify封装器的首个步骤，测试模式的起始点已被预先定义。但该测试模式的结束点需要通过两种方式之一来标识：按照前文所述的force_voltage属性进行设置，或在后续测试步骤（TP2_2_CaptureBira）中插入split_patterns_file: on属性设置。

Manufacturing Flow Variations

制造流程可以有多种变化以优化良率和测试时间。图5-41所示流程的一种变体在“Testing Repair Solution Before Fuse Programming”章节中描述，该方案支持在fuse programming之前测试修复方案。而“Performing Fuse Programming During Any Test Insertion”章节则描述了另一种变体，只要fuse array从未被编程过，就允许在任何测试环节（例如final test）执行fuse programming。

Testing Repair Solution Before Fuse Programming
对于采用编程时间较长的fuse的电路，在programming fuse前测试修复方案可节省部分测试时间。如图5-47所示，该方案需在fuse programming pattern（TP2.3）之前插入Post-Repair pattern块（TP3.n）。Post-Repair patterns中已移除BISR Power up操作（AutonomousOption/operation: power_up_emulation），因此在运行这些pattern时不得断电，且必须像Pre-Repair pattern块（TP3.n）一样禁止初始TAP复位（exclude_initial_ireset_from_patterns: on），以保持BISR chain状态。

若运行此新pattern块时出现比对失败，则表明至少一个存储器在修复后仍未功能正常，原因可能是备用资源故障，此时应废弃该电路。若未出现比对失败，则修复方案有效，可执行fuse programming。

对于具有串行或并行BISR interface的存储器，TP2.2步骤存在差异：

并行BISR interface存储器可通过load_bisr_chain操作模式快速完成BIRA至BISR的数据传输；
串行BISR interface存储器需使用rotate_bisr_chain操作模式并设置enable_bira_capture: on，执行完整的BISR chain轮转。

Performing Fuse Programming During Any Test Insertion

图5-41和图5-47的测试流程通常用于首次测试环节（即晶圆测试以提高良率）。在后续测试环节（例如final test）中，会重新应用Post-Repair测试pattern（即TP3.n），可能在不同测试条件下验证电路质量。此环节失效的电路将被废弃。由于失效电路数量通常较少，良率不会受到显著影响。

然而，若需在任何测试环节执行修复（前提是电路此前未被修复），需首先检查fuse box是否已被编程。具体方法是从地址0开始读取若干fuse，读取数量由MemoryBisr/Controller/AdvancedOptions/repair_word_size和zero_counter_bits中的较大值决定（通常小于32）。以下示例展示通过TestStep封装器读取fuse box前32个地址并预期值为0的操作：