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

本文總結(jié)兩點(diǎn)好習(xí)慣能夠提高開發(fā)的效率和體驗(yàn)。之所以叫做“習(xí)慣”是因?yàn)檫@是一種做事方式，和FPGA技術(shù)不相關(guān)的，我甚至認(rèn)為可以應(yīng)用到所有的類似的開發(fā)過程中。

一 確認(rèn) baseline

這一點(diǎn)的意思是你要明確你工作的起點(diǎn)的現(xiàn)狀是什么樣的，最好能是一個(gè)干凈正確的起點(diǎn)。

假設(shè)現(xiàn)在我們要基于某個(gè) code base 開發(fā)一個(gè)新的feature，那么我們要明確現(xiàn)在 code base 的情況。當(dāng)我們準(zhǔn)備開始開發(fā)寫代碼之前，很重要的一點(diǎn)是明確現(xiàn)有的 testbench 是不是能夠跑通。

假如我們不明確這一點(diǎn)，當(dāng)改好代碼，增加完的新的feature，跑 testbench 發(fā)現(xiàn)仿真失敗了，我們沒法知道是原來就有的bug還是新加入的代碼導(dǎo)致的。debug的過程會很痛苦，尤其是當(dāng)系統(tǒng)比較復(fù)雜的時(shí)候。

而如果我們明確之前的 testbench 是好的，那么仿真的錯(cuò)誤必然是新加入的代碼導(dǎo)致的，那么我們可以直接定位相關(guān)的代碼進(jìn)行debug。

二 積少成多

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

《獨(dú)角獸項(xiàng)目》這本書里面有這么一句話：

如果在做出每個(gè)小更改之后都進(jìn)行檢查，那么永遠(yuǎn)不回有什么大問題需要解決了

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

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