哈哈。你一定不知道debug的最高境界是什麽，是猜。對於總工程超過五十萬行，內部程式碼上萬行的模組，丟到FPGA上跑是不可能有波形看的，只能抓debug訊號，通常要看的訊號太多，debug介面太少會耗費大量時間進行叠代，邏輯分析儀的操作也很耗時，而且很多訊號不在debug介面上，沒法看。有時候想用chipscope看，需要編多版bit，每編一版大半天就過去了。所以對於極難偵錯的問題，一般就靠猜，猜準了再抓。一般來講，拿FPGA跑，上來20秒內掛掉的都是比較明顯的bug，成因不會很復雜，容易解決，真正怕的是那種跑幾十分鐘或者幾小時沒事，然後掛掉的。我昨天剛經經歷這個過程。我們在用FPGA測SSD讀寫的heavy loading，開十個執行緒同時對flash進行讀寫，然後比較讀出來的結果和寫進去的結果，結果發現跑半個小時沒事，但是此後大約幾分鐘，傳到1KB對齊的末尾地址的時候，有可能會錯幾個byte，我當時由這個現象，根據對design的了解，開始有了某些懷疑方向，然後就開始想象，各個模組存取我的模組之間是如何互動，在何種情況下可能出現這種錯誤，想了半天想到在某種極其巧合的情況下可能會存在存取沖突，導致出錯，這種沖突只有幾個周期的時鐘視窗，必須周邊的模組恰巧都在那時候按照一定的順序動作才會出現，於是讓firmware臨時修改了一個寄存器的配置，果然再跑就沒有問題了，接著開始修改design。前幾天還是調FPGA，測試power mode，每兩秒鐘就會進一次睡眠然後再恢復傳數據，跑二十多分鐘會出現進低功耗出不來，當時我用邏輯分析儀抓了幾個狀態機，看完之後大概明白了現象，然後就開始看 code，發現一個復位訊號可能導致出錯，然後一跟蹤，發展這個復位居然有七八個源，而且每個源又有五六層邏輯。當時就根據code一點點推斷，由於沒有波形，所以很多訊號是0是1就靠猜和推斷，最後我們釘選了一個訊號，這個訊號沒有引出到debug介面，所以編了版bit，用chipscope抓，一看果然是它。hack了一下之後，跑了一晚上沒有出錯，而且還抓到了一個華碩主機板的bug。這種方法，說起來還是受到我們team leader的啟發，他負責的code有八萬行以上，因為design太大，所以沒有定位之前就抓基本無益，再加上這些design經過的驗證不少，相對簡單的bug早就修幹凈了，所以一出問題他就會先猜，好幾回都讓他直接命中。
