雜訊

今天本來準備要來做一個之前因為 design 還未 ready 的 block，好不容易比對好 sram 種類，正準備插入測試電路，就遇到 read design 的第一個問題，還在思考要如何解的時候，同事問了我一個問題，他的環境跑 synthesis 似乎出了問題，無法產生該有的檔案。

沒想到就是這個問題，花了我快 3 個小時才找到 root cause，確實值得好好記錄下來。

我們登入的環境，會隨機分配，大部分都是分到前兩台，似乎從昨天開始，開始有機會被分配到第 3 台！

本來只是不同主機，並沒什麼大不了，偏偏就只有該位同事在那一台工作會出事！

這是第一個誤區，也是追查問題過程中的雜訊。

既然同事有問題就是有問題，應該要想辦法試著在我這裡也重現問題，而不是一直往該位同事的環境或資料夾方向去確認問題！

雖然這只是事後諸葛，我也不確定早上真的這樣做就可以更快找到問題？畢竟這個問題非常神奇XD

總之，就在我嘗試從環境，變數，資料夾等方向去解決問題，但仍然無法收斂問題後，因為我也沒招了，便請同事發個郵件給 IT，詢問到底哪裡出了問題？

就在我上廁所的當下，突然覺得還有一個可以嘗試的步驟，於是便請同事確認執行後是否有額外的錯誤訊息可參考。

可惜的是，錯誤訊息還是那些原本就從 console 可以看到的，執行這個步驟並沒有更多的資訊可供回饋！

就在我回位子嘗試的當下，我居然也撞出跟他一樣的問題了，真是恭喜老爺，賀喜夫人。

Debug 最怕的不是不知如何解題，而是無法重現問題！

有了一樣的問題那就好辦，雖然當下我也覺得跟事實衝突，明明那個步驟我也曾經成功產生檔案過？

還好後來馬上發現，那個檔案原來是一天前就產生的，換句話說，過去的一天內，我跟其他貌似成功的同事其實都已經發生問題而不自知！

我們之所以可以成功，那是因為該步驟只檢查檔案在不在，並不在意檔案是不是當下產生的！

所以那些一天前的檔案，其實有點 cache 的意思在？

剛好在幫同事確認問題的過程中，有看到登入的 script 被強制指定到第三台主機，修改的同事也有寫了註解，敘述修改時間為一天以前。

於是真相大白了，問題就是發生在第三台主機，雖然我同事環境還是有他的問題在XD

所以同事的環境問題是第二個雜訊，浪費了我不少時間。

總之，Debug 的同時，也要避免被雜訊影響，這是我今天學到的教訓！

不過，雜訊發生的當下，其實你很難知道那就是雜訊本人？

所以，以後要 Debug 時，應該還是要以重現問題為優先才對？

直到寫作當下，本人也還沒有正確解答就是了？

好不容易解決了同事的問題，快下班前終於可以好好的來看我自己的問題。

沒想到解決了第一個問題後，後續又冒出了好多個問題，解決第二個問題後，我也累了，決定下班打東東了XD

2026/04/10 更新

給 Gemini 的提示詞：工程師 debug 時最怕遇到雜訊，一不小心往往容易陷入死胡同而不自知。一個有經驗的工程師 debug 應該要像古人庖丁解牛般的抽絲剝繭，手起刀落，真相自然也就浮出水面。

使用 Pro 重生。