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內容和執行修復后測試的流程步驟如下：