RTL 中的一個毛刺就可能導致 eFuse 控制器意外編程，從而永久磚掉昂貴的硅芯片。本文深入探討防御縱深（Defense-in-Depth）的 FSM 設計、冗余看門狗以及形式化 SVA 驗證策略。

在 SoC 設計領域，我們習慣了軟件的可修改性和寄存器的可復位性——發現 Bug 就能打補丁。然而，電子熔絲（eFuse）卻遵循完全不同的原則：永久性。

eFuse 是一次性可編程（OTP）元件，用于存儲關鍵且不可更改的數據，例如唯一設備 ID、密碼學根密鑰，或后硅制造微調值。編程 eFuse 是一個物理破壞性事件，如圖 1 所示。

圖 1：eFuse 熔斷前（左）與熔斷后實物示意，圖片基于知識共享協議 CC4.0 授權，取自 Rahman 等人文獻

如果你的 RTL 控制器出現毛刺，意外觸發燒錄或使編程電壓施加時間過長，你可能會在芯片還沒出廠前，就永久磚掉一塊價值 500 美元的處理器。

本文將深入講解如何為 eFuse 控制器設計防磚機（bricking-proof） 的穩健 RTL，包括必要的安全機制、有限狀態機（FSM）構建，以及使用 SystemVerilog Assertions（SVA）進行的關鍵前硅驗證策略。

挑戰：連接數字邏輯與物理永久性

eFuse 本質上是一個高風險的模數接口。數字控制器必須精確管理涉及高壓（VDDQ）和特定時序窗口（ T p r o g T_{prog}Tprog）的事件序列。

eFuse 通過施加高電流脈沖實現編程，該過程稱為電遷移（electromigration）——電流導致導電材料發生遷移，從而將熔絲從低阻態（未燒斷）永久變為高阻態（已燒斷）。

圖 2.用于 eFuse 編程的 RTL 控制器系統視圖 穩健 RTL 設計：防御縱深

為防止意外編程，我們在 RTL 中采用多層保護邏輯。只有當有意下達命令、經過正確時序且經過數學驗證后，才允許“燒錄”操作。

第 1 層：雙敲門（Double-Knock）解鎖序列最關鍵的保護機制是要求寫入特定的多比特“魔術密鑰”（Magic Key）。由于噪聲或宇宙射線導致的單個比特翻轉，絕不能讓控制器進入編程狀態。系統必須向安全寄存器寫入唯一且確定的模式后，才能使能編程。

第 2 層：FSM 狀態采用 Hamming / Gray 編碼如果 FSM 使用順序編碼（00、01、10、11），單個比特翻轉就可能導致狀態錯誤跳轉（如從 IDLE 直接跳到 BURN）。我們采用具有更高漢明距離（Hamming distance）的編碼或 Gray 碼，并設置默認的“Error”安全狀態來捕獲所有非法跳轉。

第 3 層：冗余硬件定時器（Watchdog）編程脈沖寬度（ T p r o g T_{prog}Tprog）極其關鍵。若時間過長，熔絲宏可能過熱并損壞周邊電路。因此，主定時計數器必須輔以一個獨立的冗余硬件看門狗，無論 FSM 處于何種狀態，一旦超過最大閾值就強制將編程信號拉低。

用 SystemVerilog 實現 FSM

以下是一個 6 狀態 FSM 的實現示例，涵蓋了“雙敲門”解鎖（需同時滿足 EFUSE_UNLOCK_KEY 和 prog_cmd）、Gray 相鄰編碼，以及 watchdog_kill 強制跳轉到 ERROR_SAFE 狀態。

endmodule

由于熔絲一旦燒斷就無法復位，前硅驗證必須極其嚴謹。

熔絲宏的行為模型驗證環境中的關鍵部分是一個 Verilog 行為級熔絲陣列模型。該模型需在多次仿真之間保持狀態（已燒/未燒），并記錄每個比特的累積編程時間。若檢測到同一比特被重復編程，或累積 T p r o g T_{prog}Tprog 超過規格，應立即報錯。

動態驗證（UVM Sequences）在 UVM 環境中，測試序列需超越常規寄存器訪問，必須注入錯誤情況：

1. 毛刺注入

   在 prog_cmd 或 magic_key_in 信號上引入單周期毛刺，FSM 必須保持在 IDLE 狀態不動。

2. 燒錄中復位

   在 burn_en 為高期間強制系統復位。行為模型需驗證熔絲狀態變為“不確定”，但控制器邏輯能安全復位。

形式驗證（Formal Verification）特別適合 eFuse 控制器這類安全關鍵邏輯。SVA 可以數學證明在設計約束下，危險情況不可能發生。

關鍵 SVA 示例：

burn_en 必須經過解鎖

必須保證編程使能信號（burn_en）只有在 FSM 經過特定解鎖狀態后才能置高。

  else $error("CRITICAL SAFETY VIOLATION: burn_en asserted without prior valid unlock sequence!");

T_ prog 最大時序限制

必須保證burn_en 信號高電平持續時間絕不超過物理規格允許的最大值。

  else $error("MAX TIMING VIOLATION: burn_en exceeded T_PROG_MAX_CYCLES! The fuse is bricked.");

eFuse 設計是數字 SoC 中集成模擬功能時復雜度與風險并存的典型代表。我們必須在 RTL 中應用防御縱深原則，包括嚴格的解鎖序列、安全的 FSM 編碼以及冗余看門狗。

遵循這些指南，我們能將一個本質上高風險的過程轉化為確定性、安全的操作。結合行為級宏模型和形式化驗證，我們可以自信地交付強大、安全、且真正防磚機 的最終硅芯片。

原文：

https://www.allaboutcircuits.com/technical-articles/bricking-proof-designing-safety-critical-rtl-for-efuse-controllers/

半導體/AI 技術大會

（報名通過 可享免費午餐）