工程人員最怕遇到隨機出現的bug，尤其是IC廠的軟體工程師，既要懷疑自己的軟體流程，又要同時有能力區分是否為IC bug（因為硬體出錯的機率相較於PC平台來說高出很多...）。最近面對一個bug，竟然花了兩週的時間才整個釐清並解決...事後自己反省，覺得有很多值得改善的地方。 問題是這樣的：當系統開機時，發現我負責的模組在約40s~50s左右會隨機的timeout，或遭遇奇怪的錯誤情況，最後讓整個系統當掉。 由於單獨模組都已經通過了壓力測試，所以我第一個反應就是先檢查硬體。觀察了外部訊號，但沒有發現任何異樣。接著觀察相關registers，發現掛掉的時候讀到了非常奇怪的數值。由於該數值是controller直接從DRAM獲得，所以有可能是DRAM不穩嗎？不對，因為幾乎每次都掛在我這邊，如果是DRAM不穩，那應該到處都會著火。 那麼，是bus上出問題嗎？一想到這，心就涼了半截...但還是硬著頭皮觀察IC內部bus訊號（AHB signal，嗯，你不用在乎這是什麼 XD）結果，真的發現在發生問題時，bus signal非常的異常。這下designer緊張了，這可能會影響到是否已下單的wafer是否全部泡湯的問題。於是，一堆人開始出主意：有沒有試過ooo、有沒有試過xxx、＃＄％︿＆＊＊（！... 由於出意見的人都是有掛頭銜的，所以往往都要先確認他們的意見是否成立。嗯，這是我犯的第一個大錯： 花了太多時間應付長官的要求，而非處理事情的本質。 由於長官並不那麼清楚整個始末，但又因為可能是大問題，所以自然吸引人們出意見。但是我應該在當時就說明清楚，而不是默默承受無釐頭的要求（ 懂得何時說"No"就跟懂得何時說"Yes"一樣重要 ）。嗯...總之，這樣一個禮拜就過去了，客戶也開始著急了起來，質疑什麼問題需要一週還沒任何結論。 接著，長官們沒想法後，總算可以開始自己的實驗，很快地發現某個模組只要一發生錯誤，我的部份再過幾秒後就出問題。所以將重點移到該模組。詢問該模組負責人相關流程後，對於為何會出錯也很納悶，畢竟...嗯，他自己單獨跑也是經過了好幾天的測試...好了，所以問題是出在兩者間的交互作用導致bus出問題嗎？於是我們開始了這兩個模組的co-sim, FPGA CVT...這邊則是我的第二個錯誤：