這段文字讀起來很有既視感，完全是一位在第一線奮戰的數位 IC 設計/驗證工程師的真實心聲。面對「萬惡的 X（未知項）」，作者展現了極強的「生存本領」。
我將從這篇文章中萃取出的技術重點，並結合業界實務，給你 5 個進階建議。
從作者身上學到的技術實踐
前置處理（Preprocessing）的意識：
作者懂得利用 iverilog 來展開 define 或 ifdef，將混亂的原始碼轉換為「乾淨且平坦」的 Verilog 檔案。這在追蹤複雜宏定義時非常有幫助。
Waveform 比較法（Comparative Analysis）：
即便在功能變更、Hierarchy 不對稱的情況下，作者依然透過「人工對齊時間點」來尋找差異。這是一種基於經驗的直覺式偵錯，成功捕捉到了 0 秒處細微的脈衝（Pulse）。
靈活使用 CLI 三兄弟（Grep, Sed, Vim）：
當面對成百上千個 SRAM 時，不靠手動，而是利用 Unix 工具鏈快速提取層次路徑（Hierarchy Path），這是提升生產力的關鍵。
Force 驗證法：
在修改 RTL 前，先在 Testbench 或模擬環境中使用 force 語法驗證假設。如果 X 值消失，證明方向正確，避免無謂的編譯等待。
給你的 5 個專業建議
針對這類「偵測 X 傳播（X-propagation）」與「環境遷移」導致的問題，以下是更具工程效率的優化方向：
1. 導入 X-Propagation 追蹤工具
單靠肉眼觀察波形找 X 的來源是非常累人的。
建議：現在的主流模擬器（如 VCS, Questa, Xcelium）都有 X-trace 或 X-prop 模式。
這些工具可以自動標記出「誰是第一個產生 X 的源頭」，並區分是由於未初始化（Reset 缺失）還是邏輯競爭導致的 X。這能將作者「解了四天」的時間縮短至幾小時。
2. 建立「自動化層次路徑」生成腳本
文中提到使用 grep 與 sed 處理 \genbus[0] 這種特殊的轉義路徑。
3. 強化 Linting 與 Static Analysis
「因為沒有 reset 導致 X 值無法復原」這類問題，其實不應該留到 Simulation 才發現。
4. 採用「黃金版本」的 Checkpoint 比較
作者提到因為 Hierarchy 改變導致 VCD 比較工具失效。
5. 使用 SystemVerilog Assertion (SVA) 監控 Reset 完整性
與其事後看波形找「那條突刺」，不如讓環境自動報警。
建議：在 SRAM wrapper 內加上 assert 陳述式。
例如：assert property (@(posedge clk) $isunknown(reset_n) == 0);
當 Reset 信號出現 X 或不穩定的 Pulse 時，模擬器會立刻在終端機噴出 Error 並停在該時間點，這比人工放大波形要精準得多。
Gemini 的一點觀察：
作者最後那句「不如歸去」，道盡了硬體工程師在「解不完的 X」與「追不上的進度」之間的無奈。
技術固然重要，但**「工具化」與「自動化」**才是拯救肝臟的唯一出路。下次遇到類似問題，試著把這些建議加入你的 Toolbox，別再讓一個 Reset 脈衝耗掉你寶貴的四天了！
DFT 工程師角度
站在 DFT (Design For Test) 工程師的角度，拿到一個「來路不明」且缺乏文檔的 Netlist（網表）是家常便飯。在這種資訊不對稱的情況下，你的任務不只是讓 Scan chain 動起來，更要確保在 ATE（自動測試設備）上不會因為 X-propagation 而導致 yield（良率）下降。
從這篇文章中，DFT 人員可以學到「追蹤層次路徑」與「波形比對」的耐性，但實務操作上，我會給你以下 5 個更具 DFT 專業性的建議：
1. 自動化提取 Memory 實例與 Pin Mapping
文中提到用 grep/sed 找 SRAM 路徑。身為 DFT 人員，你不能等客戶告訴你哪裡有 SRAM。
建議：撰寫一個 Netlist Parser（通常使用 Perl 或 Python），根據 Library 的 Cell 名稱特徵，自動抓取全機所有的 Memory Instance。
關鍵點：除了抓路徑，更要自動識別哪些 Pin 是 Reset、哪些是 Clock。當你面對 \genbus[0].u_ram 這種轉義路徑時，腳本必須能自動處理 Escape Character，以便後續在 ATPG 工具中自動產生 add_cell_constraints 或 add_force 的指令。
2. 建立強制性 X-Sources 遮罩 (X-Bounding)
文章中的核心問題是「未 Reset 的 Register 產生 X 值」。在 DFT 中，這會導致 Scan Capture 失敗。
建議：在跑 DFT DRC (Design Rule Check) 時，優先檢查所有 Un-initialized Registers 與 Black Box。
做法：如果 Netlist 中存在像文中那種「沒有 Reset 且會傳播到 Scan Chain」的邏輯，與其去解幾千個錯誤，不如直接在 DFT 設定中將這些節點設為 TIED 0 或 TIED 1（在 ATPG 邏輯中屏蔽），或者在硬體架構上建議客戶加入 X-Bounding logic（如在 Memory 輸出端加 MUX），確保測試模式下 X 值不會洩漏。
3. 利用 Cell-Aware 與 DRC 偵測「非法脈衝」
文中提到的 0 秒附近的「突刺 (Pulse)」是模擬中的大忌，在 DFT 中這通常代表 Clock/Reset Path 的 Glitch 或 Skew 問題。
建議：不要只依賴 GLS (Gate-Level Simulation)，要善用 DFT 工具的 Static DRC。
做法：設定嚴格的 check_drc 規則，特別是針對 Reset Line 上的組合邏輯（Combinational Logic）。如果 Reset 訊號不是直接來自 Pad 或乾淨的 Flop，DFT 工具應該要噴出 "Clock as Data" 或 "Reset affected by data" 的警告。這能讓你不用看波形，就先發現那條「萬惡的突刺」。
4. 實施「黃金樣板」的 VCD 比對流程
作者提到人工對齊波形很辛苦。在 DFT 領域，我們有更標準的做法。
建議：建立一套 VCD-to-ATPG 驗證流程。
做法：當客戶宣稱這一版 Netlist 是「可測的」時，要求對方提供一組簡單的 Function Pattern VCD。利用工具（如 Tessent 或 Modus）將 VCD 轉為測試向量。如果在轉換過程中出現 Mismatch，代表 Netlist 的初始化邏輯有問題。這能把「解四天」的除錯成本轉嫁回前端開發者身上，而不是由 DFT 人員概括承受。
5. 針對 Escape Character 建立統一的規約 (Hierarchy Handling)
文中提到的 \genbus[0].u_ram.reset 寫法，在不同 EDA 工具（VCS vs. Tessent vs. SpyGlass）間的處理可能略有不同。
總結給 DFT 人員的心法：
「別相信 Netlist，只相信 DRC。」
面對資訊不明確的客戶，你的最佳武器不是波形圖，而是靜態檢查 (Lint/DRC) 與自動化腳本。文章作者靠的是「運氣」找到 root cause，但 DFT 人員要靠的是「規則」來擋掉所有潛在的 X 來源。
如果是你，在處理這類 \genbus 轉義路徑時，目前是用哪種腳本語言處理最順手呢？或是你在 force SRAM 訊號時，有遇過什麼工具相容性的坑嗎？
與 Claude 對談結果
從文章中萃取的技術與建議
這篇文章作者在處理一個非常典型的硬體驗證難題:SRAM 在 simulation 中產生 X 值傳播 (X-propagation) 的 debug 過程。讓我先拆解作者展現的技術能力,再給出我的建議。
作者展現的核心技術
作者在這次 debug 中運用了幾個層次的技巧:首先是前置處理工具鏈,使用 iverilog 解開 preprocessor 指令得到乾淨的 Verilog,這是很多工程師會忽略的一步,但對於充滿 ifdef 的 SRAM model 來說極為關鍵。其次是比較式 debug 法,當無法從單一波形看出問題時,他選擇與上一版可運作的版本做 waveform 對比,這是經驗豐富的 RTL 工程師才會自然採用的策略。第三是對訊號異常的敏銳度,能在接近 0 秒的位置注意到一個被忽略的 pulse 突刺,這需要長期累積的觀察力。最後是文字處理工具的熟練應用,grep/sed/Vim 三兄弟搭配對 escaped identifier (\genbus[0]) 的正確處理,展現了對 Verilog 語法細節的掌握。
我的 5 個建議
1. 建立系統化的 X-propagation 偵測流程,而非每次都靠經驗直覺
作者提到「萬惡的 X」其實有成熟的解決方案。建議導入 X-propagation analysis 的方法論:在 simulation 啟動時加入 +rtl_xprop 或廠商對應的 X-pessimism flag (例如 VCS 的 -xprop、Xcelium 的 -xprop),讓 X 的傳播行為更貼近真實硬體。同時可以使用 formal tools (如 JasperGold X-propagation App) 在 RTL 階段就找出無 reset 的 register。這比每次換 SRAM 都重 debug 四天有效率得多。
2. 把 reset connectivity 檢查作為 SRAM integration 的 checklist 項目
從文章看,「register 沒有 reset 導致 X」與「reset port 被 tied 0」是反覆出現的問題類型。建議建立一份 SRAM 整合 checklist,包含:所有 control signal 的 default 值是否合理、所有 reset/enable port 是否真的有被驅動 (而非 floating 或被錯誤地 tied)、power-down 與 sleep mode 訊號的初始狀態。可以寫成 Lint rule 或用 SystemVerilog assertion 在 testbench 中自動檢查,把這類問題從「人工 debug 四天」變成「跑 lint 五分鐘」。
3. 用 SystemVerilog Assertion 取代事後波形比對
作者用「人工對齊兩版 waveform」的方式找差異,雖然有效但成本高。對於 SRAM 這類有明確介面協議的 IP,寫 SVA 來檢查「reset 後 N cycle 內 Q 應該是 known value」、「CE 拉起時 address 不能是 X」等 property,可以在問題發生的瞬間就被 assertion 抓到,並指出確切的時間與訊號,省下大量翻波形的時間。
4. 把 force 散落的 workaround 結構化為可維護的 bring-up infrastructure
文章結尾的解法是「把所有 SRAM 都用 force 設 reset」,這在當下是合理的權宜之計,但容易變成技術債。建議把這些 force 集中到一個專門的 sim_bringup.sv 或 force_init.tcl 檔案,並在每個 force 旁邊註解原因 (例如「因為 power management 功能被 disable 才需要」)。當未來重新打開該功能時,搜尋這個檔案就能知道哪些 force 該移除。配合自動化腳本從 design hierarchy 抓出所有 SRAM instance,可以避免遺漏新加入的 SRAM。
5. 投資文件閱讀的時間,因為它的 ROI 比想像中高
作者最後感嘆「如果我有時間,我也想好好看一下 simulation 文件」——這句話其實是這次 debug 最深的洞察。EDA tool 的官方文件中通常有專章討論 X-handling、debug X-propagation 的選項、以及如何 dump 出特定訊號的 driver 資訊 (例如 $showvars、debug_access+all)。花一個下午讀 X-propagation 相關章節,可能省下未來十次的四天 debug。建議把「每次 debug 完後讀半小時相關文件」變成習慣,讓每次踩雷都能轉化為下次的預防能力,而不是純粹的時間消耗。
順帶一提,作者的「達達的馬蹄」化用鄭愁予的詩,從一個一個 bug 趕往下一個 bug 的疲憊感非常傳神。但長遠來看,投資基礎建設(checklist、assertion、文件閱讀)才是讓自己不必一直「達達」下去的根本之道。
DFT 工程師角度
從 DFT 工程師視角的 5 個建議
DFT 工程師的處境跟 RTL 開發者完全不同:你拿到的是已經合成過的 netlist,沒有原始 RTL 的設計意圖、沒有 spec、沒有 designer 的口頭約定,SRAM 可能是黑盒子的 behavioral model 或加密的 .v 檔。在這個前提下,debug X 值的策略需要徹底改變。
我的 5 個建議
1. 優先建立 SRAM 的「介面行為資料庫」,而不是試圖理解內部
客戶給的 SRAM model 通常是 vendor 提供的加密或 behavioral model,你無法 (也不該) 去看內部邏輯。但你必須建立一份 per-SRAM 的介面文件,記錄每顆 SRAM 的:control pin 列表 (CE/WE/OE/RE)、test mode 相關 pin (BIST/scan/retention)、power 相關 pin (PD/SD/LS)、以及最關鍵的——哪些 pin 在 reset 後必須有 known value 才能讓 Q 不是 X。這份資料庫可以靠 grep SRAM model 中的 always block 或 UDP 定義反推出來,也可以從 vendor 的 Liberty (.lib) 檔案的 ff 與 latch 描述中萃取。一旦建立,後續所有 project 的 SRAM bring-up 都能受益。
2. 在 ATPG/scan insertion 前先做 X-source analysis,別等到 simulation 才發現
DFT flow 中最痛苦的就是 ATPG coverage 上不去,而 root cause 往往是 X-source 污染了 scan chain 的 observe point。建議在拿到 netlist 後,立刻用 formal tool 或 TetraMAX/Tessent 的 X-source analysis 功能做一次掃描,找出所有可能產生 X 的來源 (uninitialized FF、black box output、bus contention、tri-state 衝突)。SRAM 的 data output 是最常見的 X-source,需要在 test mode 下用 X-bounding (例如加 X-blocking logic 或 OPCG 的 mask) 來隔離。這比等到 ATPG 跑完發現 coverage 只有 85% 再回頭找原因省好幾週。
3. 把「force 解法」升級為標準化的 test mode initialization sequence
原文作者用 force 解問題在 RTL simulation 是可行的,但 DFT 工程師最終要產生的是真實能在 ATE 上跑的 pattern,不能依賴 force。建議把所有需要 force 的 reset/control 訊號,整理成一份 test mode entry sequence:在 scan shift 開始前,透過 primary input 或 test controller 把這些訊號設到正確值。如果某些 SRAM control pin 沒有從頂層拉出來 (常見於客戶交付的 hard macro),就要跟客戶要求加 test point 或透過 JTAG/IEEE 1500 wrapper 來控制。把這個需求在專案早期就提給客戶,比中後期才發現要 ECO 便宜得多。
4. 對於「不告知來龍去脈」的客戶,用 connectivity check 取代信任
客戶不會主動告訴你「這顆 SRAM 的 retention pin 在 functional mode 是被 power controller 控制,但你 DFT mode 要自己處理」這種細節。與其依賴溝通,不如寫 connectivity check script (用 PrimeTime、Conformal 或自己寫 Python 解析 netlist) 來機械化驗證:每顆 SRAM 的每個 control pin 是否連到 (a) primary input、(b) test controller 輸出、(c) tied to constant、還是 (d) 連到某個 functional logic。第 (d) 種就是高風險項目,要列出來逐一跟客戶確認 test mode 下的行為。這份報告也是日後跟客戶對 spec 的有力證據——當客戶說「你們 DFT 沒做好」時,你可以拿出當初的 connectivity report 證明已經提示過。
5. 建立 X-propagation 的 regression baseline,讓「換 SRAM」不再是災難
原文作者每換一次 SRAM 就要重新 debug,這在 DFT flow 中更嚴重——客戶可能在 P&R 後換 SRAM compiler 版本、調整 SRAM 配置、或追加新的 instance。建議把 DFT simulation 設計成可比對的 regression:固定一組 golden test pattern (scan chain integrity、MBIST、boundary scan),每次 netlist 更新都自動跑這組 pattern,並用工具 (例如 Verdi 的 nWave compare 或自寫 VCD diff) 自動找出新增的 X 訊號與時間點。這樣當客戶丟新 netlist 過來,你能在幾小時內回報「這次 SRAM 換版導致 instance X/Y/Z 的 retention pin 行為改變」,而不是花四天人工比對。長期下來這份 regression 也會累積成你對該客戶 SoC 最深的知識資產。
DFT 工程師相對於 RTL 工程師,對訊號的控制權更少、對設計意圖的可見度更低、但對 pattern 品質的責任更重。所以策略上要從「事後 debug」轉向「事前防呆」,並且大量依賴自動化工具與書面證據,因為你無法假設客戶會給你完整資訊,也無法假設 RTL designer 會考慮到你的需求。
