Compression Algorithm and Fuse Box Organization

        通常情况下，这部分信息对于实现BISR（内置自修复）并非必需，但对于诊断问题可能有所帮助。

Compression and Fuse Box Organization Overview

        BISR controller采用的压缩算法基于两个事实：大多数存储器无需修复，且BISR寄存器中存储的值主要为0。因此，压缩后的修复信息由存储在fuse box中的两种字类型构成：Zero Count（零计数）和Repair Data（修复数据）。每个字的第一个比特（称为Opcode）标识其类型——Zero Count字的Opcode为0，Repair Data字的Opcode为1。
每个字的长度取决于从电路中自动提取的参数：Zero Count字的长度设定为1 + Log2(MaxChainLength)，其中MaxChainLength是BISR链的长度（可通过write_memory_repair_dictionary命令推导）；Repair Data字的长度则设定为最长的BISR寄存器长度（该值从电路中自动提取并记录在MBISR TCD文件中），如图5-27示例及"Single-Chain Case"章节所述。

                

        在Repair Data字中，第一个比特除了作为Opcode外，本身也是修复数据的一部分。Repair Data字不一定会与BISR寄存器边界对齐，因为controller无法预知这些边界的位置。正因如此，当Repair Data字作为BISR链中的最后一个字时，它可能是不完整的。

        图5-51(a)展示了一个典型示例，显示了fuse box中包含的针对只需单次修复电路的修复信息。这些字是从左向右逐位写入fuse box的，即fuse box地址0位于最左侧。controller默认每个熔丝都有其独立地址。对于面向字操作的fuse box，fuse box interface会将来自controller的fuse box地址转换为适合该特定fuse box的字地址，然后对该字中的某一位进行编程。

        如图所示为单个电源域组的示例，其中可能采用任意组合的Zero Count和Repair Data字。

        当存在多个电源域组时，工具会按照上述方式对每个组的数据进行压缩。此外，BISR controller会在fuse box中存储组指针，用于定位除第一个组外其他组的特定修复信息。如图5-51(b)所示，每个指针需要占用若干熔丝（记为NumberOfAddressBits），其数量等于fuse box地址位的位数。用户可通过TCD文件中的FuseBoxInterface/Interface address属性指定fuse box地址位的数量。组指针按照从最高有效位(MSB)到最低有效位(LSB)的顺序存储，这意味着指针的MSB位于fuse box中的较低地址处。图5-51(c)显示，在默认的单次编程会话配置(max_fuse_box_programming_sessions = 1)下，BISR controller将所有指针从地址0开始集中存放在fuse box的起始位置。

        当使用硬增量修复（max_fuse_box_programming_sessions > 1）时，fuse box 中会存储额外数据以指示 fuse box 被编程的次数以及每次编程会话的修复数据位置。图5-52展示了 max_fuse_box_programming_sessions = 4 的示例：前四位是会话标志位，当某次会话存在修复数据时，对应的会话标志位会被设为1。BISR controller 将第四次会话的标志位存储在 fuse box 的地址0处，而第一次会话的标志位则存储在地址3处。

        下一组 fuse 是测试插入指针（test insertion pointer）部分。除第一次会话外，每次会话都拥有一个 test insertion pointer，该指针位于 fuse box 中紧接会话标志位（session flag）之后的位置。与电源域组指针（power domain group pointer）类似，test insertion pointer 所需的 fuse 数量等于 fuse box 地址位数。fuse box 以从最高有效位（MSB）到最低有效位（LSB）的顺序存储 test insertion pointer，这意味着指针的 MSB 位于 fuse box 中的较低地址处。

        位于 test insertion pointer 部分之后的每个编程会话（programming session）内容均按图5-51所示方式组织。每个编程会话都是独立自包含的——换言之，当采用自主 fuse 编程方法（autonomous fuse programming method）时，系统不会复用之前任何会话的修复信息。

CompressBisrChain Script Usage

        CompressBisrChain脚本主要用于集成eFuse且无法通过BISR controller的autonomous run mode进行片上编程、必须依赖外部编程的设计方案。使用该脚本的次要优势体现在：对于多会话fuse编程（硬增量修复），当存在具有相同BISR chain长度的Power Domain Groups（PDGs）时，其内置优化技术可减少fuse用量——此情况下，优化机制会尽可能复用之前会话的fuse。采用CompressBisrChain脚本会使制造流程略微复杂化，因为需要先提取修复数据，经脚本处理后重新载入芯片进行fuse编程，具体流程将在本节后续详述。

        CompressBisrChain脚本通过复用指针来减少fuse用量——若特定Power Domain Group（PDG）无需新修复，则直接复制前次编程会话的PDG数据指针。该指针可跨多个会话重复使用。在所示范例实现中，首个组别通过DftSpecification的PowerDomainOptions/power_domain_priority_order属性定义，这带来一项限制：该组指针已在BISR controller中硬编码且不可修改，因此不同会话无法共享该组的修复信息。为降低此限制的影响，建议将最小PDG设为最高优先级，从而减少该PDG需要修复的概率。

        图5-53针对图5-52所示示例，对比了FuseBox Access与Autonomous Self Fuse Box Program两种方法的差异。在Session 1阶段，假设所有PDG长度均不相同，两种方法产生的结果完全一致。进入Session 2时，由于PDG2组无需新修复操作，其修复数据可被复用——此时PDG2的指针被复制到Session 2中并指向Session 1的原始修复信息（实际修复数据未被复制）。

        但PDG1的情况则有所不同。由于前文所述的限制，即使数据完全相同，其修复数据也必须被完整复制。而PDG3由于需要新增修复内容，因此需写入新的修复数据块。进入Session 3时，仅PDG1需要更新数据——PDG2指针继续指向Session 1的原始数据，PDG3指针则指向Session 2的修复数据（二者均通过指针复制实现复用）。

        在图5-53中，所有指向现有数据的指针均以红色标示，并反向指向fuse box的地址空间。本示例中仅使用了四个可用会话中的三个，这意味着系统中仍存在可编程fuse的空间。虽然您很可能会选择使用autonomous mode进行fuse编程（因其操作比使用CompressBisrChain脚本更简便），但两种方法均可选用。二者的核心区别在于：autonomous mode不会复用之前任何会话的修复信息。

        当使用CompressBisrChain脚本进行第二次或后续fuse编程会话（增量修复）时，必须在制造流程中增加一个步骤：在写入新fuse之前读取现有fuse box内容。如图5-55所示，该步骤通过BISR controller的fuse_box_access运行模式实现——在确定需要修复后，系统将逐位读取整个fuse box。为节省测试时间，建议仅读取预留存储内存修复信息的fuse box部分，这可通过在PatternsSpecification MemoryBisr controller的FuseBoxAccessOptions封装中指定read_address（范围）属性来实现。例如：当fuse box具有1024个fuse但仅512个预留用于内存修复时，可按以下方式配置。

        

TDO引脚上的误匹配信号标示了fuse box中哪些位置被编程为1值，该信息将被脚本用于以下关键操作：

1. 定位包含修复信息的最后一个会话指针

2. 当存在多个组时识别所有PDG指针

3. 确定每个组关联的修复信息

4. 计算可供写入新修复信息的下一可用fuse位置

随后通过常规BIRA-to-BISR转换流程提取新修复方案：在旋转BISR chain时持续比对TDO与0值，从而定位BISR chain中值为1的触发器。脚本据此比对各组新压缩修复数据，并判断现有修复数据是否可被复用。

CompressBisrChain

        CompressBisrChain脚本随Tessent产品版本提供，专门用于根据您设计的压缩算法和fuse box架构来压缩BISR chain的内容。

        在采用Tessent BISR控制器的可修复存储器设计中，提供两种内存修复方法：第一种采用autonomous run_mode fuse box编程方式，通过片上执行BISR chain压缩及fuse box编程；第二种则使用TAP access模式（通过fuse_box_access run_mode属性指定），该模式需配合CompressBisrChain脚本实现自动化操作。

TAP access模式下的fuse box编程需执行以下步骤：

1. 从测试模式输出提取BISR chain信息

2. 压缩BISR chain数据

3. 通过TAP access模式编程fuse box

        CompressBisrChain脚本会读取描述设计BISR chain设置的配置文件（如-configFile参数说明所述），同时解析由PatternsSpecification生成的仿真日志文件（参见示例章节）。该脚本将在当前工作目录生成四个*.pattern_spec文件，其内容可直接嵌入PatternsSpecification。这些文件定义的独立测试步骤(TestSteps)可用于：

• fuse box编程

• fuse box数据读取

• BISR chain编程

• BISR chain数据移出

        以下 PatternSpecification 示例遵循 CompressBisrChain 脚本的制造流程（如图5-55所示），仅展示单个pre-repair pattern (TP1.1) 和 post-repair pattern (TP2.3)。后续修复会话需包含 FuseBox Access (Read fuses) 流程步骤（如图5-54所示），但此示例中未予体现。

        在 MemoryBist_PreRepair 测试步骤 (TP1.1) 中，MemoryBIST 会测试所有存储器，并判断是否存在无法修复的故障——若存在，则芯片将被判定为不良品。在此过程中，BIRA controller 会收集故障信息，并为可修复的存储器计算修复方案。随后，MemoryBist_CheckRepairNeeded 测试步骤 (TP1.3) 通过检测所有存储器的 Repair_Status[0] 寄存器是否为高电平，来判断是否需要修复。

        若需修复存储器，则需在 tester 上运行 BisrChainAccess 测试模式。BiraToBisr 测试步骤会将 BIRA 计算的修复方案加载到 BISR registers 中，并循环移位寄存器。在移位过程中，tester 会将 TDO 输出与零进行比较，并记录不匹配的情况。随后，需将这些不匹配数据转换为符合红色标注格式的 “simulation.log” 文件。

        您运行CompressBisrChain脚本，并将创建的"simulation.log"文件作为脚本输入，同时通过-configFile开关指定BISR参数配置文件。该脚本会解析"simulation.log"文件，提取红色高亮显示的信息，并生成四个*.pattern_spec输出文件。您使用由CompressBisrChain脚本创建的FuseBoxProgram.pattern_spec文件中的TestStep，在制造流程的TP2.2阶段编写fuse box。此步骤的示例pattern以及后续验证fuse box内容和执行修复后测试的流程步骤如下：