工程人員最怕遇到隨機出現的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...這邊則是我的第二個錯誤: ...