如何將算法翻譯成Verilog

這期內容當中小編將會給大家帶來有關如何將算法翻譯成Verilog，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

我是一名數字前端IP設計工程師，方向為通信芯片IP設計，我的工作主要就是將算法C代碼手工轉換為RTL，尤其是通信芯片的設計，算法主要是將浮點運算近似成定點運算，定點的精度決定了系統的性能，所以一種開發模式就是，用C平臺生成的case數據和RTL仿真的數據進行對比，保證定點化后的仿真性能。

所以對于單個計算模塊的開發來說，可以說就是體力活了，算法的計算過程已經擺在那里，單就是純翻譯。

然而再復雜的算法，在設計工程師的眼里，也就是一堆數學公式，算法設計者也應該盡量做簡單的算法實現，比如除法，求冪次方、開平方等復雜運算到了設計工程師這里都已經轉化成了簡單的乘法和加法運算。更復雜的就是累加、累乘（我所能接觸到的）。

做芯片第一應該關注的是芯片的PPA（Performance， Power， Area），如何設計的出更高性能的電路，占用更少的資源/面積，更低的功耗。這才是我們的專業知識。

通過學習算法代碼和文檔以及協議，了解算法的計算意圖。然后進行數據通路的分析，整體的數據流走向。哪些需要計算的數據可以用寄存器存儲，哪些數據需要用RAM存儲。模塊的劃分可拆解，哪些計算單元是功能類似的，可以做成一個小IP，乘法器同時使用的最大數量，是否能在整個大模塊中分時復用。

算法的設計中沒有時序的概念，也沒有計算時間的長短。需要設計工程師去整理整個模塊的計算流水，流水線排的時間長，需要的計算邏輯就越少，反之，面積越大。面積與速度互換思想，貫穿始終。現成乘法器的數量有限，是否能加上幾個乘法器而獲得模塊整體運算速度提高30%的收益，都需要去折中（Trade off）考慮。

排好計算流水，控制通路，一般都使用狀態機去做，當然，狀態機怎么設計算法可不會教你。整個模塊與更高層模塊的交互，接口控制時序需要討論確定。數據通路可能還需要用到RAM/Regfile去緩存中間數據的結果，RAM/Regfile的讀寫地址控制也是常見設計。數據通路的運算，是主要消耗資源的部分，所以一個好的詳細設計方案非常重要，同樣的設計，別人可以用比你小30%的面積和少30%的時間來實現。這可能就是設計工程師真正的價值體現之處。

對于通信算法中，矩陣運算也是比較常見的，復雜矩陣的運算是最耗費資源的，矩陣運算的拆解也需要很多技巧，比如矩陣的乘法是A的第一行乘以B的第一列，累加得到第一個元素，這部分的運算電路可以復用流水起來做。一個矩陣需要拆解合并成數個小矩陣，想要保持并行，用寄存器存儲，就會消耗的資源多。存在RAM中就是串行流水做會消耗的時間長，所以這都需要在模塊架構設計階段去計算處理時間和評估消耗資源、折中是否采取（Trade off）。

這種大型矩陣運算動輒幾百上千bit的寄存器輸出，連線選擇運算，可能會造成后端congestion問題，所以方案設計的重要性又體現出來了。組合邏輯的運算，如果路徑過長，時序會出現問題，插寄存器的位置也非常重要，消耗的寄存器的數量也是不同的，甚至可以通過手動retimming，找個寄存器把打拍的位置換一下，消耗的資源還是相同的。

對于芯片的功耗前端能做的就是，去加一些時鐘門控，模塊不用時候可以關掉，組合邏輯計算單元不用的時候避免翻轉，乘法器的使能信號的控制，避免無效翻轉，數據通路寄存器帶著使能打拍，工具也會自動插時鐘門控，這些就和算法沒關系了。

至于算法，當然不同領域的相關知識不同，雖然設計方法是完全類似的，但是在一個領域深扎，成為這個領域的專業的人，可以更好的理解算法到硬件的實現。

IP設計工程師經常調侃自己是算法“翻譯官”，雖然也沒什么問題，但是自嘲歸自嘲，如果感興趣的話，還是應該去想著如何更好的做好自己的設計，做好芯片。即使是“翻譯官”也是一個十分有價值的“翻譯官”。

上述就是小編為大家分享的如何將算法翻譯成Verilog了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。