編寫良好的、可移植的、可重用的 HDL 代碼，使設計能夠以所需的頻率實現，這絕對是一個挑戰。

為此，許多（不是大多數）專業組織都有編碼標準。不過，編碼規則可能會成為戰場。一些公司的編碼規則非常復雜，不僅控制代碼結構，還控制格式和命名，而有些公司則稍微寬松一些。

但是，如果你是專業開發 FPGA，或者是作為愛好者，都應該有一些基本的編碼規則。當你來到項目的后端并且必須實現時序收斂時，遵守這些基本規則可以節省大量時間和精力。為此，我開始思考我的 HDL 開發的 10 大規則是什么？？

狀態機——只是單個進程。忘記關于組合部分和順序部分的學校和課程。所有狀態機都應該是單個進程。這有助于調試，防止鎖存器的出現，并確保所有輸出都是寄存器類型，從而減少毛刺并幫助我們實現時序收斂。

狀態機——盡可能多地從狀態機中解耦功能。這意味著確保計數器等位于它們自己的進程中（在 FSM 進程之外）并由來自 FSM 的信號控制。這種解耦使FPGA的實現對于 FSM 和計數器都更加優化，結果會得到更好的結果質量。

狀態機——理想情況下，狀態機應該在們自己的單獨文件中，與其他代碼元素分開。我會允許在同一個文件中解耦計時器和其他元素。

推斷——只要有可能，編寫代碼時，應使綜合工具能夠推斷出它所綁定的邏輯結構（例如，DSP48、BRAM 等）。這使得代碼可以隨著系列之間架構特性的變化（例如，DSP48 到 DSP58）而更方便移植。

實例化——當無法執行推理并且必須實例化組件時，應該在架構頂層的文件中。這使得替換或更新實例化的 IP 更容易。

實體/模塊——每個進入或離開模塊的信號都應該被注冊。這有助于解決時序收斂問題，尤其是當我們以更快的頻率運行時。

使用標準接口——使用 AXI4、AXIS、AXI4-Lite 或其他標準，如果是純 HDL 設計，例如使用wishbone總線在模塊之間進行通信。這簡化了架構元素對具有大量矢量端口和相關握手信號的需求，這些端口需要連接、布局和布線，并實現時序收斂。如果需要流水線實現時序收斂，這些接口通常也更加靈活。

不要將結構代碼和功能代碼混合——這使重用變得方便而簡單，因為功能代碼位于單獨的文件中可以輕松重用。同樣，結構代碼文件更容易理解，因為它們只是定義解決方案的配置。

命名——在整個設計中使用合理的變量名稱，這些名稱具有描述性，有助于提高可讀性。考慮使用 i_ o_ s_ v_ 等前綴來標識正在訪問或處理的變量的類型。前綴比后綴更有效，因為變量名稱的大小會發生變化。如果想要進行更改，使用前綴可以簡化批量編輯（豎選）。

文檔 – 可以讓閱讀正在使用的 IP 的文檔了解其工作原理（不要以為你知道它是如何工作的）。UltraFast 設計方法參考指南值得閱讀，可以學習編碼結構（例如，復位和控制信號）。同樣，在設計中包含自己的文檔也是一個好習慣。有幾種開源工具可以使用，例如用于時序圖的 WaveDrom、用于框圖的符號器、用于寄存器定義的位字段等。能夠將這些包含在源代碼中是理想的，因為它可以防止文檔丟失。在這種情況下，推薦TerosHDL 編輯器。

遵循這些規則，能夠創建優秀的 FPGA 設計，這些設計不僅可以以所需的速度實現，而且還具有靈活性并能夠實現大量重用。但是，我將添加兩個額外的規則：

仿真你的設計——在考慮實施之前，請確保頂層文件有一個測試臺，該測試臺可以證明設計按預期工作。設備上調試僅用于集成類型問題，而不是驗證設計是否有效。

使用 GIT 等版本控制系統，并認真使用問題跟蹤和發布功能。它真的可以幫助你，讓你擺脫困境。

這些是我的 HDL 開發的前 10 條（好吧，12 條規則）。我很想知道如果是你，你會考慮添加哪些規則？

審核編輯：劉清