最近半個月，做個的項目。開始做測試，機器跑著，整個項目前後做了半年，有些小想法，分享於諸位：

1.前期的設計工作應該做到面面俱到，否則在未來的開發中，大概率將會遇到一些問題：

一，性能不滿足需求，然後為了提升性能，資源又成了瓶頸；

二，功能設計頻繁變更；

三，各個模塊之間的耦合性問題，導致系統大了之後，bug無法及時收斂。然後就是不斷的返工。

2.及時溝通。

與pcb的制作人員多溝通，減少外部走線對FPGA開發的負面影響；與軟件測試人員溝通，一個對於FPGA需要加N個模塊綜合三四個小時才可以測試的單元，對於軟件人員來說可能就十幾行代碼二十秒鐘load進去就可以完成工作；一個算法人員的新思路，可能幫你在開發FPGA時節省一半的資源消耗。

3. 多思考，再動手。

出現bug一定不要慌，先找原因：

一.看物理模型這樣的bug可能產生的原因；

二.看仿真，是否有沒想到的特殊情況導致一些邏輯的實現偏離自己的設計；

三.看布線，是否是設計電路時組合邏輯使用不當、寄存器扇出問題等。

思考完之後，再去想辦法驗證問題，使用debug手段。

4.數字電路在時鐘同步的設計原則下，其功能通過simulation就可以驗證。

這也是為什麽各種入門的FPGA書籍裏面推薦大家使用時序邏輯，並且關註時鐘同步性。因為這是為了保證仿真結果和最後實現結果的一致性。正因為有這樣的一致性，才可以進行測試調試。

5.壓力上移。

leader將任務分解下發是一種壓力下移，而對於具體的執行者來說，在適當的時候也需要壓力上移。

當發現出現的問題自己已經無法cover的時候，及時匯報，尋求資源、探討方案甚至是修改既定計劃，是非常必要的。但是要註意，不可以推卸責任，而是提前想好可行性方案之後，再尋求上級的支持。

6.關註外部接口以及器件本身。

FPGA工程師不能僅關註自己的芯片，當設計外部接口時，因為仿真困難，沒有工具分析外部器件的情況，會導致在這方面的調試經常陷入困境。

這就需要工程師仔細閱讀器件的datasheet，關註其瓶頸、性能、接口電氣屬性等，我們一般通過假定的 input-delay和output-delay來對接口部分進行約束。

有時甚至可以去官網尋找該器件的仿真module，然後加入到自己的仿真中，通過仿真來保證設計的可控。

7.對於一些大的工程，最後的編譯報告可能會有大量信息，不但要關註error，因為error的存在，意味著時鐘同步的大前提已經被破壞，這時，simulation取得的結果和FPGA是不等價的。另外還需要關註warning的情況，其中大部分的warning的確是可以忽略不計的，關鍵的是以下幾個：：unused ports, removal of redundant logic, latch inference，simulation mismatch等等。在報表中輸入關鍵字查找即可。

8.測試應該充斥整個開發周期。

包括方案設計時，對整個框架選用接口帶寬性能的測試；編寫模塊時，對小模塊的自測（一般在仿真時完成），生成可執行文件後的demo測試，集成測試。

建議所有的模塊由專門的測試人員進行測試，因為一些出現自己思維盲區的錯誤部分，有可能很容易被別人通過測試發現。

但是對於一些小公司可能只有一到兩個FPGA開發人員，那麽我建議由軟件開發人員或者系統測試人員協助進行測試 。

原則起始很簡單，就是盡量避免自己即當運動員又當裁判員。

版權所有權歸卿萃科技 杭州FPGA事業部，轉載請註明出處

作者：杭州卿萃科技ALIFPGA

原文地址：杭州卿萃科技FPGA極客空間 微信公眾號

掃描二維碼關註杭州卿萃科技FPGA極客空間

最近做項目的一點想法