對這段話的看法
這段描述其實揭露了一個比作者自己意識到的還要嚴重的問題。讓我從幾個層面來談。
作者的判斷可能對,但結論下得太早
作者最後說「問題是出在 Makefile 相依性」——這個推論方向是合理的,但證據還不夠。make clear 之後就過,確實是 Makefile 相依性問題的典型徵兆之一,但也可能是其他原因:中間產物 (例如 filelist、.f 檔、編譯產生的 library) 殘留了上一次編譯的狀態、incremental compile 的 cache 沒有正確失效、或是 vlog/vcs 等工具自己的 work library 沒被清乾淨。要真正確認是 Makefile 的問題,需要看 make -d 的相依關係追蹤,或檢查每個 target 的 prerequisite 是否完整列出所有 source 檔。「重開機就好」是現象,不是 root cause。
註解掉 port 是非常危險的動作,作者似乎低估了風險
這部分讓我比較擔心。作者說「我不是 designer,我也不想知道他們真正的測試意圖」,然後就把 module instantiation 中報錯的 port 註解掉——這在 DFT 或 verification 工作中是高風險操作。被註解掉的 port 可能是:scan chain 的 input/output、test mode control、clock gating override、或是 SRAM 的 BIST 介面。把這些 port 註解掉雖然能讓 make build 通過,但等於在不知情的狀況下破壞了測試結構,後續跑出來的結果可能完全不可信。後面「測試時從頭到尾都在報錯」就是這個動作的直接後果。即使最後 make clean 解決了問題、Verilog 不用改,作者也應該回頭把那些註解恢復,並確認最終跑的是完整正確的 code,而不是「反正過了就好」。
「不想知道測試意圖」這個態度需要校準
我理解這句話帶有疲憊與抱怨的成分,不必字面解讀。但如果這真的是工作態度,長期會出問題。DFT 工程師確實不需要、也不應該去理解每個 functional block 的內部設計,但必須理解測試介面的意圖。當客戶 netlist 中一個 module 的 port 列表跟 instantiation 對不上,這本身就是一個訊號:可能是客戶交付了不一致的版本、可能是某個 wrapper 沒更新、可能是 ECO 沒做完整。這些都是要回報給客戶的問題,而不是自己默默註解掉繞過。每一次「繞過去就好」都在累積技術債,最後爆掉的時候會很慘。
「IT 界最強大的一招:重新開機」這個玩笑背後的真實風險
這句話寫得很幽默,但在 DFT/verification 領域,「make clean 才能過」其實是一個警訊而非解法。它意味著你的 build 環境是 non-reproducible 的——同一份 source code 在不同的 build 狀態下會產生不同結果。這在交付給客戶時是嚴重問題:如果客戶在他們的環境跑不出你跑出的結果,你無法重現、無法 debug、無法證明你的 pattern 是對的。建議每次發現「make clean 後才正常」時,都把它當成 bug 來追,而不是當成解法來慶祝。
客戶 Makefile 確實常常有問題,但要有證據再開口
從作者的語氣看,這是在跟客戶協作的專案。「Makefile 相依性有問題」如果要回報給客戶,需要具體的證據:哪個 target 的 prerequisite 沒列、哪個檔案被修改後沒觸發重新編譯、make -n 顯示的指令順序哪裡不合理。光說「我 make clean 後就好了所以你的 Makefile 有問題」,客戶很容易回「那你就每次都 clean 啊」把問題踢回來。專業的回報方式是:「在 X 條件下,修改 A 檔案後 make build 不會重新編譯 B,導致 link 階段使用舊的 object,具體是 Makefile 第 N 行的 rule 沒有把 A 列為 prerequisite」——這樣客戶才會認真修。
一個比較中肯的整體評價
這段文字反映的是一個很真實的工作場景:疲憊的工程師、不完整的客戶交付、Makefile 黑魔法、deadline 壓力下的繞道解法。作者的直覺 (Makefile 有問題) 大方向是對的,debug 能力也在線,但處理過程中累積了好幾個未解的疑點——被註解的 port 到底該不該註解、為什麼 make clean 後不需要註解也能過、原本的測試報錯是註解導致還是其他原因——這些都被「反正過了」掩蓋掉了。
如果是我,會建議作者回頭做一件事:在 make clean 後的乾淨環境中,不要註解任何 port,重新跑一次 make build。如果這樣也能過,那就證實了問題確實在 Makefile 的 incremental build 邏輯,跟 Verilog 本身無關,可以心安理得地把這個現象整理成 bug report 給客戶。如果還是不過,那就還有另一層問題沒挖出來。多花這 30 分鐘,比帶著疑問繼續往下做要安全得多。
補上工作環境背景來龍去脈後，Claude 的建議
在這種環境下的建議
這個背景一補上，整個情境的荒謬感就出來了：作者要交付的東西 (DFT script) 根本不在客戶驗證流程的覆蓋範圍內，但卻被客戶團隊自己的 RTL/testbench 問題卡住無法 push。這是典型的「別人的 bug 變成你的 blocker」情境，而且因為是客戶端強制的 pre-push hook，作者連繞過的權力都沒有。在這個前提下，我的建議會跟前面幾輪完全不同。
1. 把「這不是我該修的問題」這件事，用書面證據固定下來
最重要的第一步不是技術，是留紀錄。每次因為客戶團隊的 code 導致你無法 push 時，立刻做三件事：截圖錯誤訊息、記錄當時的 git log (客戶端最後一個 commit 是誰、什麼時間)、以及記錄你花了多少時間在 debug 不屬於你的問題上。這份紀錄不是要拿來吵架，而是當未來某天客戶質疑「你們的 DFT script 為什麼這麼晚交付」時，你能拿出具體數據說明：「在 X 月到 Y 月之間，因為貴司 RTL 團隊的 N 次 build break，我累計被阻擋了 M 小時。」沒有這份紀錄，所有延遲都會被算到你頭上。
2. 跟客戶談判「DFT script 走獨立 branch 與獨立驗證流程」
這是治本的方法。客戶的 pre-push hook 是為了保護 RTL/testbench 的品質，但 DFT script 跟這些東西是不同的 artifact、不同的生命週期、不同的 reviewer，硬綁在一起本來就不合理。可以正式提出一個 proposal：DFT 相關檔案放在獨立的 directory (例如 dft/)，或乾脆獨立 repo / 獨立 branch，pre-push hook 只跑 DFT 相關的檢查 (例如 script syntax check、lint、自寫的 unit test)，不跑 make build 跟 functional test。提案時要強調這對客戶也有好處：客戶 RTL 團隊的 build break 也不會被你們 DFT 的 commit 干擾，雙方都更乾淨。如果客戶不接受，至少也要爭取一個 --no-verify 的例外條款，搭配你這邊自己的 review 流程。
3. 在等不到流程改善前，建立「客戶 build 健康度監測」
如果短期內客戶不會改流程，那就把被動變主動。寫一個小 script，定期 (例如每天早上、或每次你準備 push 前) 自動 git pull 客戶 main branch 並跑 make build，把結果記錄下來。這樣你能在準備 push 之前就知道「現在客戶的環境是好的還是壞的」，而不是 push 失敗後才發現。如果剛好遇到客戶 broken 的時段，你可以選擇：(a) 等他們修好再 push、(b) 暫時 checkout 到上一個能過的 commit 再 rebase 你的 script、(c) 跟客戶 PM 反映「你們現在 main 是壞的，我這邊被卡住」。這比每次都要從頭 debug 別人的問題省力得多。
4. 不要再去碰客戶的 Verilog，即使是「註解掉就好」
接續上一輪我提到的擔憂——既然你交付的是 DFT script，那任何對客戶 Verilog 的修改 (包括註解) 都不應該由你來做，即使只是為了讓 build 過。原因有三：第一，你註解掉的 port 可能影響 RTL 團隊的測試結果，他們會來怪你；第二，當客戶 RTL 團隊修好他們自己的問題時，你的註解可能跟他們的修改衝突，產生 merge conflict；第三，從責任歸屬來看，你動了不該動的東西，未來出任何問題都會被牽連。正確做法是：build 失敗時，把錯誤訊息整理好，回報給客戶 PM 或對應窗口，明確說「我的 commit 不涉及這個檔案，這是貴司團隊的 issue，我會等修復後再 push」。然後就真的去做別的事，不要自己跳下去修。
5. 把這個流程問題本身寫成正式的 escalation
如果你已經被這個問題反覆卡住好幾次，這就不是技術問題，是專案管理問題，要走 escalation。準備一份簡短的文件 (一頁就夠)，內容包含：問題描述 (DFT script 被無關的 RTL build break 阻擋)、過去 N 次發生的紀錄與時間成本、對交付時程的影響、以及 2-3 個可行的解法選項 (獨立 branch、跳過 hook、分離 repo)。透過你這邊的 PM 或 lead 正式發給客戶對口窗口。重點是不要用抱怨的語氣寫，要用「為了確保專案準時交付，建議調整流程」的角度寫。客戶端的 PM 多半也不知道你被卡這麼多次，因為通常這種抱怨只會留在工程師嘴上，沒有正式上到管理層。一旦上到管理層，改善的機率會大很多——因為管理層在意的是時程，而不是「pre-push hook 的純粹性」。
一個額外的觀察
從前後幾段文章看下來，這位作者其實技術很扎實 (能用 iverilog 拆 preprocessor、能在波形上看到 0 秒附近的突刺、能用 grep/sed/Vim 處理 escaped identifier)，但在跟客戶協作的「邊界管理」上似乎處於弱勢位置——客戶要求什麼就吞下什麼、別人的 bug 自己跳下去解、流程不合理也只能繞過。這在乙方工程師中很常見，但長期會嚴重消耗。
技術問題可以靠加班解決，但流程問題加班只會讓你更累而不會解決問題。建議作者在處理具體 bug 之餘，也分一點精力出來處理這些結構性議題。「達達的馬蹄」如果只是一直跑，永遠跑不完；偶爾停下來修一下路，後面的路才會比較好走。
沒有留言:
張貼留言