Fix make build

果不其然，今天要推 Code 時又 Gone 了，明明昨天早上還檢查過（後記：push 時跑的驗證跟第一次檢查環境跑的不是同一個！）。

為了這個，也是搞得我心煩意亂，害我 Debug 時不能靜心，浪費了快兩個小時。

凡事要靠自己，我又不像陳平安有齊聖人照看XD

檢討一下，下次不要再犯錯了！

1. 雖然看出 UVM 有錯誤，但還是懶得問 AI，畢竟要自己打字也是心累。

我的 Debug 方向是對的，因為心煩所以想岔了路，一直想要將缺少的 interface 檔案，透過 BUILD_OPTION 傳進去，也就是想要餵給 XRUN，所以我透過 Makefile 修改問題，有符合我的解題思路。

但因為 Verilog 本質上比較像 C 語言，所以找不到的 interface 檔案，應該要放在同檔案上方用 include 解決。

2. 不要在未確定客戶後續是否還有 commit 未 pull，就先執行 make build。

誠如上次我猜的那樣，客戶的 Makefile 相依性有問題，明明執行完 make build，後續還有 commit 且 commit 中有包含 DV 相關的 testbench 裡的檔案，但因為 git push 判斷 make build 已成功，故並未重新執行 make build。

3. 同前，既然無法確定客戶後續是否還有 commit ，我應該要嚴格執行之前訂定的 SOP。

不過此番看來，PM 4:00 過後還是太趕，改成 PM 8:00？

希望下一次推 Code 可以順利一些﹍

2026/05/10 更新

還好今天母親節聚餐延後，不然我還真的沒辦法繼續了。

昨天晚上好不容易解決掉 make build 問題，你他媽的跑驗證又有問題，重點還不只 1 個問題。

但這次嚴守紀律，不為了這個熬夜，還是準時在 12 前上床。

現在再來盡最後一次的努力。

首先，我以下的理解應該無誤：

- 客戶透過 .git/hooks/pre-push 強制我跑驗證才能 push。

- 驗證跑的 test 跟平常跑的不一樣，至少跟第一次驗證環境的不一樣。

- 驗證要跑的東西是放在真正跑驗證那層的 testfiles 資料夾內，由 Makefile 決定是哪個。

- 跑驗證時，是透過跑驗證那層的上一層裡的 bin 資料夾裡的 perl 程式來 dispatch。

- 跑驗證的 log 在哪我還找不到，但有錯的 log 是放在驗證那層所有 fail 開頭的檔案。

但奇怪的點是我兩個錯誤的測試，其中一個在 test list 裡卻是註解狀態，理論上不應該被 random 挑選到才對？

還有就是在目前這個時間點，星期日早上 7 點，看起來都還有人 commit。

前幾次不知道，我想那個人內心一定很幹，怎麼有人放假在推 Code！如果我的速度比他快，他就會遇到我之前平日推 Code 遇到的死結一樣，因為我比他先 push，導致他推 Code 會失敗。

重點他的 commit 還有持續 fix 驗證問題，難道驗證失敗是因為他的問題？

總之，是否要為此調整 SOP？

另外，屋漏偏逢連夜雨，所有的 Server 目前都已停擺，工作無法 dispatch，就不知道是真的掛點還是接近 +0 時區的午夜，Server 正在重開機或是執行什麼任務？

如果最後真的是因為 Server 無法推 Code，那我也真的沒轍了！

我可以改 Verilog、Makefile、Script，甚至是 Perl 檔案，只為了讓整個 flow 打通，但是遇到 IT 問題我就沒辦法了，畢竟孤臣無力可回天呀！

2026/05/10 下午更新

Server 還是斷斷續續的工作，整個進度非常緩慢。

全部 4 台只有一台恢復正常，至少剛剛檢查情況是這樣。

另外，驗證清單確實是放在 testfiles，只是要注意裡面還有 INCLUDE 其他 test 檔案。

這樣一來我的疑惑完全打通了。