最近應該可以專心在這一塊，記錄一下避免忘記。
01. netlist simulation 時，除非 cell 有 power port，不然不要誤用帶 power port 的 Verilog，因為需要有電，buf 的 output 才不會 x，不確定是特殊 cell 還是通例，也許之後可以看有無 define 可以設定。
02. simulation 時，如果吐出一堆 ASSERT，比如說 IEEE package，xrun 可以在 dump Tcl 檔案裡面加上 assertion -off -vhdl -all 便可以關掉 ASSERT，simulation 速度也會加快。
03. top simulation 時，如果 file_list 檔案過多時，可能只是更改幾個檔案，比如將 memory 檔案從 fast_func 改成正常版本，有可能會發生 unresolved object，此時砍掉編譯暫存檔整個重來即可。
上面不確定是 xrun 參數有問題還是怎樣？也有可能跟之前 liborder 等問題類似？
2026/09/25 更新
現在都是使用 force 來 gen clock，因為我是全部打開開關，故在某個 clock 打開後，會印出一堆錯誤訊息增加測試時間，（正常在此階段不能使用 force，但客戶更改測試架構，故請我先用此方法驗證）。
雖然我已寫成 testarg 可以傳參數決定何時開啟關閉，但我的 script 可以一次跑全部 pattern 或依使用者輸入決定測試哪支 pattern，為了這個問題，我要將 script 大幅改寫才能動態改變開關。
不是做不到，但不值得在這裡投入過多心力，故我改將 pattern 一樣用類似 testarg 傳進我的 force Verilog 中，然後利用字串比對決定是否要開啟該 clock，沒想到就這樣引入臭蟲。
剛在測試這個星期第一次有機會跑的 pattern，沒想到 clock 不符預期，感覺就是我的 pattern 名稱有錯誤，因為懶得查 display 參數就直接印出，故得到一個很大的數字，原本以為這是 16 進位數字，於是便請 AI 直接幫我解析，沒想到 AI 居然還知道我講的是錯的？真是太意外了。
當初沒有想到 pattern 名稱會有哪麼多字，只宣告 256 bit，難怪會不符預期。
2026/09/27 更新
不常寫 Verilog 有時會反應不過來，今天在計算記憶體修復資訊，直接問 AI 比較快。
所以當我注入錯誤是 bit 5 時，我的 TCD 如下：
PinMap {
SpareElement {
RepairEnable : repair_en ;
FuseMap[0] : repair_info[0];
FuseMap[1] : repair_info[1];
FuseMap[2] : repair_info[2];
FuseMap[3] : repair_info[3];
FuseMap[4] : repair_info[4];
}
}
FuseMap[4:0] {
ShiftedIO(Q[5]) : 5'b00101;
}
回到上面的 SpareElement，對應到那一段 bisr chain 就會是 001011，
也就是 bit0, bit1, bit3。
2026/10/09 更新
真是受不了某家的 memory，每次一跑模擬就會吐出一堆 ERR，之所以會有這些 ERR，都是因為出現在已經不在 BIST 測試階段的訊號 unknown 導致，每次看了就是心累，還得多檢查第一個發生點是否發生在 BIST 之後。
雖然他有 define 可以關掉，但應該有另一個 define 決定你是為了 MBIST 還是 Function 做測試，這樣 Verilog Model 也好判斷。
2026/10/10 更新
翻了一下客戶工作站 Simvision 的文件，沒看到有什麼可以快速得到 instance 的方法。
雖然我可以用 Tessent 打開 netlist 下 command 得到我要的記憶體列表，但是兩邊 EDA 工具顯示的方式不同，再加上客戶使用 escaped identifier 的命名方式亦或是 generate 語法的鍋？
導致我無法無腦的將 Tessen 的斜線替換成點！
目前只有折衷的方式，先從 log 挑出錯誤行數中的字串，再用 sed 切出我要的 instance name，再補上我要的訊號名稱，再丟進我的 Tcl 檔案產生一個 add.tcl，最後在 Simvision 的 console 視窗 source 該檔案，我才能在 waveform 視窗看到我要觀察的訊號。
另外，之前在 Design Windows 直接打關鍵字搜尋貌似都不成功？但最近似乎又沒問題了？
馬的，需要花錢的 EDA 工具，比 GTKWave 還難用是怎樣？
2026/10/15 更新
這個星期開始 top netlist simulation，沒想到連 ICLNetwork 都過不了，感覺涼涼的？
一開始以為是不是又是哪邊 constraint 沒下好導致？
再加上 block 某幾版 netlist 也有問題。
最後就是 top MBIST 時，RTL block 的版本是否有跟 netlist 一致？
太多未知數讓人很難靜下心來 debug？
最後還是只能用笨方法，一個一個 module 慢慢對過去，既然是 ICLNetwork，重點當然是 SI 和 SO 訊號。
搞了老半天，都不是前面想的原因，而是因為客戶電源域過多，跨電源域的地方都會被加上 isolation cell，故我必須確定這些 cell 都有被控制到。
客戶的 cell 是屬於 AND Gate 型態，找到源頭控制即可。
像我這次的錯誤是屬於預期 0 實際 1 的錯誤，亦或是反過來的錯誤。
這種錯誤，我之前的經驗都是版本不符導致，沒想到只是訊號不對，看起來的錯誤態樣也是很相似，算是學了一課。
另外，top netlist 模擬時間太久，應該要找到 EDA 工具增量編譯的說明，無奈嘗試了一下，還是無法成功，目前卡在針對 Testbench 單獨編譯的階段會有權限問題，可能是我的心同時還在 debug 前面問題導致！
後來發現，當我更換 pattern 時，xrun 自動判斷是否要重編譯時不是很聰明，導致時間花費過久（觀察結果約需要一個多小時？）。
相反，如果每次換 pattern 時，把原本編譯好的暫存檔資料夾整個砍掉，編譯反而不用 20 分鐘？
目前先以清空編譯檔方式來加速，下次有機會再改進。
2026/10/16 更新
今天開會前突然想到，如果用軟體工程師的角度來解釋昨天發現到的現象，感覺還挺合理？
所謂的增量編譯，原則上就是檢查當前檔案是否有更新過？最合理的方法就是做 hash，然後跟資料庫的同個檔案 hash 做比較，如果不一樣，就表示檔案有變更，於是就要重新編譯。
感覺 simulation 是以 module 為單位？
因此當在 top 跑模擬時，因為 module 數過多，導致 hash 計算時間被放大？
這也可以解釋為什麼砍掉資料夾所花的時間還比較少，因為不需要花時間去做 hash？
睡覺前有跟 AI 討論，不能單以 hash 來看，但總之就是花在檢查的時間大於完全重來的成本。
2026/10/17 更新
大概試出來增量編譯的方法了，但以 MBIST 來說，不同 pattern 裡面需要權限的訊號不同，如果沒有全跑一遍，無法知道 autoref.txt 裡面需要定義多少訊號？
以方便度來說，我還是覺得砍掉編譯資料庫比較簡單，以這個專案的複雜度來說還算可以接受。
如果真的有比較花時間的 pattern，把整個 testbench 資料夾一分為二，分別執行 xrun 即可。算是手動 for process 加速吧XD
2026/10/18 更新
下面是我最後搞定增量編譯的比較時間，雖然只看 log 建立時間有點不準，但我們在意的是相對性。
左邊是使用增量編譯的版本，可以看出整整節省了 2 個小時的時間，更何況右邊還是使用砍掉編譯資料夾加速的方法，如果是我最早的版本，我想編譯浪費的時間一定更多。
