相信大部分人都遇到過這種情況，花大力氣改好了代碼與測試文件，滿心歡喜開始跑仿真，結果一仿全是錯，又開始花大力氣去debug。

本文總結兩點好習慣能夠提高開發的效率和體驗。之所以叫做“習慣”是因為這是一種做事方式，和FPGA技術不相關的，我甚至認為可以應用到所有的類似的開發過程中。

一 確認 baseline

這一點的意思是你要明確你工作的起點的現狀是什么樣的，最好能是一個干凈正確的起點。

假設現在我們要基于某個 code base 開發一個新的feature，那么我們要明確現在 code base 的情況。當我們準備開始開發寫代碼之前，很重要的一點是明確現有的 testbench 是不是能夠跑通。

假如我們不明確這一點，當改好代碼，增加完的新的feature，跑 testbench 發現仿真失敗了，我們沒法知道是原來就有的bug還是新加入的代碼導致的。debug的過程會很痛苦，尤其是當系統比較復雜的時候。

而如果我們明確之前的 testbench 是好的，那么仿真的錯誤必然是新加入的代碼導致的，那么我們可以直接定位相關的代碼進行debug。

二 積少成多

這一點的意思是每次處理的改動少一些，簡單一些，然后積少成多。

《獨角獸項目》這本書里面有這么一句話：

如果在做出每個小更改之后都進行檢查，那么永遠不回有什么大問題需要解決了

我們還是以開發一個新的 feature 為例，假設現在這個新的feature需要在code base有5處大的改動，我們可以在每做完一處大的改動就跑一次仿真，確認新的baseline。如果我們選擇另外一種做法，先完成全部的5出改動，再去跑仿真，仿真會有極大的概率出錯，而且我們也需要花費極大的力氣去debug。

另一個例子是做 code rebase。在整個項目的開發周期，可能會有好多次其他同事提交代碼更新code base。如果我們只是在項目的尾期去做 code rebase，可想而知conflict會非常多，我們做rebase也會更艱難更容易出錯，甚至導致項目的延期。比較好的習慣是，在 code base 有變化時，我們及時rebase，那么每次rebase的conflict沒那么多，我們也可以很快完成繼續下一步的開發。