「好文推薦」在實際硬體中實現浮點演算法：適應步驟

應用軟體在內部表示數字的方式是一個項目成敗的關鍵。這對於經驗豐富的數字信號處理(DSP)工程師而言並不是什麼新聞——他們每天都面臨這一問題。但是在傳統DSP範圍之外的很多應用——例如，機械控制、視頻和移動設備中的感測器處理等，越來越多的要依靠大量的數字計算，其設計流程的特點是具有大規模DSP設計。

在這一流程中，演算法開發從C、Java，或者MATLAB等行業專業語言開始，這些都使用了IEEE 754兼容浮點演算法。開發好的演算法被傳遞給硬體設計團隊(圖1)。然後，設計團隊的工作是在硬體中實現演算法，並滿足系統設計約束——無論硬體支持IEEE 754與否。在這一實現過程中，設計經理對任務的理解非常重要——還有風險。

圖1.我們希望能夠工作的實施流程

出發點

問題非常簡單。從計算中得到的結果取決於您怎樣表示數字。演算法開發人員通常採用一種能夠高效表示數字的語言和模擬環境進行工作，從而自己可以忽略怎樣表示數字。從C到MATLAB的所有語言都提供了IEEE 754浮點，在大動態範圍內有23個有效位。如果開發人員擔心這還不夠，那麼，他們可以設定雙精度，提供52位尾數。

利用浮點功能，演算法開發人員可以將精力集中在怎樣得到正確的運算順序。大部分時間裡，他們不用擔心在某一運算結束後，還會有多少有效位。實施工程師就是這麼幸運。

理解目標

當設計必須要實現需要大量數字計算的演算法時，關鍵是演算法要適應目標硬體，這在開發過程中會有風險，而且會是很耗時的任務。如果對此低估會很危險。因此，您應該在設計早期完成一些必要的任務，估算規模、資源需求，以及任務帶來的風險。

關鍵的首要問題是目標系統中算術硬體的特性。很明顯，知道目標硬體是否支持浮點演算法非常關鍵。如果支持，如果系統功耗和存儲器約束支持將數據保持為浮點格式，那麼，任務的實現只涉及到浮點實現的極端情況。但是，如果您選擇的硬體或者系統要求定點演算法，那麼，這就會是非常長而且需要特殊技巧、有風險的任務。

相對簡單的方法是導出至浮點硬體。在這種情況下，您需要注意演算法開發人員使用的浮點環境以及目標系統所提供的環境之間的差別。我們在這裡之所以使用了「環境」，是因為要在很多方面進行對比。

最明顯的是精度問題。演算法開發人員使用單精度還是雙精度數字?您的硬體能使用相同的精度嗎?如果您把雙精度演算法移植到單精度硬體，或者存儲器和功耗性能約束要求您使用單精度，那麼，您所處的情形與移植到定點硬體的設計人員一樣，稍後我們對此進行討論。

極端情況

假設演算法開發人員和硬體團隊在精度以及浮點需求上達成一致，也還有一些重要的問題。如果演算法開發人員使用了浮點，目標硬體提供的浮點演算法精度相當，那麼這就解決了很多適應性問題。目前，幾乎所有的硬體——或者知識產權庫，都宣稱浮點支持符合IEEE 754。這一標準在比特級定義了數字表示，還從加法、減法、乘法和除法等基本運算中提取出結果。以參考演算法的形式提出現在的定義：要達到兼容，您的實現必須與參考演算法有相同的結果。

因此，一般而言，如果您的演算法最初是在MATLAB中使用雙精度浮點開發的，那麼，您的IEEE 754雙精度硬體得到的結果應與MATLAB相同。演算法在系統中所起的作用應該與在模型中的相同。

但是，您還需要考慮幾個問題。MATLAB默認是雙精度，它也很容易使用其他格式。某些嵌入式系統設計只支持單精度。使用52位尾數和23位尾數的不同會體現在結果中，不同格式的演算法表現會完全不同。

處理雙精度或者單精度問題主要在於檢查某些不安全情況下的演算法。可以是很容易的問一下演算法開發人員，切換到單精度模式，檢查其結果。或者，需要與從浮點到定點適應相似的處理過程，我們會在下面進行解釋。

您還會問一些其他問題。一個是關於異常處理。IEEE 754支持計算產生不是實際數字的五種結果：上溢、下溢、被零除、無效以及不精確。對於演算法開發人員，這是很有價值的調試幫助。開發環境會找到它們，暫停，並提供診斷信息。

但是目標系統呢?理想情況下，您的演算法開發人員會保證實際沒有會產生這種狀態的輸入。如果沒有的話，您需要理解設計是怎樣響應這些非數字結果的，確定響應在應用軟體中是合理的。您一定不願意一系列事情因為下溢而停下來。

最後，還有庫的問題。大部分C編程環境都包括標有math.h的庫，它提供了很多種函數，從簡單的數字運算到超越函數。在軟體環境中庫是必須的：例如，MATLAB使用自己的函數，而這些函數在math.h中也有，而OpenCL?則需要70%的math.h函數。如果您的演算法含有對數學函數的調用，您的目標硬體支持math.h函數，精度和性能也符合要求，那麼，實現起來就會容易很多。沒有這些支持，您就不得不自己實現這些函數。

當您把演算法移植到浮點實現時，所有這些考慮都非常重要。但是，也有目標系統使用定點演算法硬體的情況，例如，使用傳統的硬體、能耗或者成本約束，或者使用缺少浮點硬體的FPGA。這又增加了新的演算法適應任務(圖2)。

圖2.實際流程

從浮點到定點

有一種容易的方法。如果演算法開發人員知道目標硬體只使用32位整數算術，那麼，他們可以從一開始就調整演算法，使其能夠在硬體中正確工作。使用保護位，組織運算以避免減掉幾乎完全一致的大數字，或者不採用極端的數字進行乘法或者除法等方法有助於保證演算法能夠正確的工作。

在這種任務中，為演算法開發人員提供了幫助工具。例如，Simulink為定點變數提供了很多幫助。利用工具，您可以定義輸入範圍，當變數通過模型中的處理單元時，監視變數的變化。其他工具可以進行靜態分析，或者根據某些輸入模式進行動態分析，逐節點觀察您的模型。工具甚至可以提出關於合適數據類型的建議。

對於有經驗的演算法開發人員，這一層面的支持進一步提高了實施工程師的能力。他們可以一起工作，定製目標系統中的數據通路寬度，從而切實滿足演算法需求，節省FPGA或者ASIC實現所需的邏輯門、功耗以及存儲器數量等。當邏輯門級動態功耗以及邏輯門成本都是主要考慮因素時，這是非常重要的功能。目前，這可能不如設計中的其他定點和變數成本重要，因此，還不是主要問題。

當您遇到問題時

更難的情形是在開發人員把浮點演算法交付給實現團隊時。現在，是工程師要解決適應問題，而他們不一定詳細理解演算法。

Altera研發工程師Bogdan Pasca建議：「對此專業的方法是從輸入到輸出工作。您的輸入數據一般來自模數轉換器等器件，為您提供了確切但是非常低的定點精度」。

Pasca說，從輸入開始，您的工作是逐節點實現演算法，每一次運算都要注意信號大小，因此，需要整數數據類型、定製數據通路寬度，或者軟體搜索來保持數據的有效位。

Pasca補充說，在這一過程中應融入您對演算法的所有理解，這非常重要。他說：「例如，假設您針對逆平方根等函數，為Newton-Raphson迭代實現一個數據通路。每一次迭代將前面的結果與隨機查找數據通路中計算的數字相乘。如果您理解這一演算法，那麼，您知道乘法總是接近1：這看起來並不明顯。

完成了從輸入到輸出的工作後，需要檢查您的工作。Pasca說，在信號處理應用中，設計人員經常會使用統計指標進行衡量，例如，信噪比(SNR)等，而不是要求結果完全在取整誤差內。這樣，測試過程更關注混合信號電路的驗證。設置模擬，然後把您想到的所有測試信號都進行模擬，特別是對數據通路有壓力的碼型。不要忽略原理上無效但是物理上仍然有效的測試信號——您不希望一個雜訊連接器破壞整個系統。監視輸出SNR，一旦超出您的要求，那就需要去解決問題。

然而，這不是一個分析過程。這需要技巧和經驗才能很好的完成，甚至經常是多次迭代。單步調試節點，觀察動態範圍，選擇數據類型。然後，把測試信號輸入到模型中，設置一些中斷。跟蹤運算中觸發有效位丟失的問題，或者如果需要，對實現過程和演算法進行調整，然後再次測試。沒有人會覺得這很容易。就像混合信號驗證，很難預測什麼時候才能完成這些工作。

自適應或者優化

如果您需要適應浮點演算法和定點CPU或者DSP，您的自由度是有限的：選擇單精度或者雙精度整數，或者嘗試在演算法中重新組織計算。但是，如果您面向ASIC或者FPGA，您可以建立其寬頻就是您所需要的定製數據通路。

某些FPGA對您的支持更大——您可以使用FPGA邏輯單元結合晶元的嵌入式乘累加模塊，構建半軟浮點演算法模塊，代價是速度和功耗。這些單元會佔用FPGA的部分邏輯容量，可能要比同一晶元上的整數DSP慢一些，但是，要比完全在可編程邏輯中構建的浮點數據通路快得多。正如我們在前面所看到的，它們會大幅度簡化實施工程師的適應過程。

某些FPGA工具不但具有這一功能，而且在數據通路中能夠很好的傳送融合鄰近運算，每次計算後，不需要IEEE 754強制歸一化。這種融合過程能夠有效的減少浮點的硬體需求，有趣的是，雖然計算不是754兼容，但實際上要比754精度高。至少一種GPU工具，CUDA，也能夠產生融合運算。

更進一步發展，一家FPGA供應商發布了完全符合IEEE 754的浮點硬體DSP的FPGA系列。這一特性提供了單精度浮點加法器和乘法器，能夠有效的減少，某些情況下甚至不需要從其浮點開發環境到目標硬體的適應過程。

我們研究了從開發環境到各種目標硬體環境的浮點演算法適應任務。我們看到，即使是最好的情況，也不太容易完成這一任務。對於目標硬體不支持IEEE 754動態範圍、解析度和異常處理的情況，則需要適應，而且不可預測。

需要提醒的是，設計經理在其項目規劃中，應把管理這類適應任務作為非常重要的因素。在很多情況下，當首先要選擇目標硬體，做出決定時要考慮這一任務的風險和資源。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！