應用通信調制解調器構建信號處理平臺的系統級建模及仿真實驗

軟件無線電或通信調制解調器等信號處理系統的質量取決于所選用的硬件平臺性能。早期在設計方面的探索使設計師可以在寄存器傳輸級(RTL)和軟件實現之前洞悉面臨的挑戰，了解性能與功耗改善所需的架構決策以及軟硬件的劃分。

另外，早期的設計探索還有助于架構方面的設計決策，從而為規劃當前和未來需求提供便利。設計師還可以進一步拓展這些設計探索，以便開展故障分析，并確定進行驗證的測試用例。

本文介紹的系統級建模和仿真方法，可以用來在設計流程早期為軟件無線電或高速通信調制解調器設計信號處理平臺的架構。

問題

先進的高速信號處理平臺等大多數復雜系統都會經歷昂貴的重復設計，超過70%的重復時間是由于設計決策錯誤或對需求的誤解。此外，影響這些復雜系統的因素有很多，如低處理時延、低功耗、可配置能力和資源限制等。早期的設計探索有助于克服這些問題。

設計師和架構師有幾種開展設計探索和分析的方法可供選擇。雖然分析法可以提供有關最壞情況下執行時間的重要信息，但多數情況下這在實際應用中并不會發生。物理測試方法也許能提供精確的信息，但對于軟件無線電或高速通信調制解調器等復雜系統來說是不可行的。

解決方案

利用離散事件仿真，設計師和架構師可在較短的時間內根據成百上千個使用案例、任務調度和系統配置，對目標系統進行評估。離散事件建模和仿真不僅有助于構建特別復雜的仿真模型，而且能夠幫助架構師和設計師運行更多的用例。

此外，硬件架構組件與框架的預構建和有效庫有助于軟件架構的建模。它們可以提高系統模型的精度，縮短構建仿真模型的時間。

這種方法允許設計師：

● 專注于結果的分析和解釋，而不用關心模型的構建；

● 采用不同的應用配置來執行仿真， 以便進行平臺選擇，做出軟硬件決策，了解外設、性能以及目標架構上軟件線程的分配，從而優化產品架構。

解決方案實現

對信號處理平臺的設計進行探索，目的是為了了解處理延時、現場可編程門陣列(FPGA)緩沖器要求、數據包長度對性能的影響以及硬件平臺配置的識別。進一步擴展這種探索，可以理解每個信號處理函數的資源使用情況，比如尋峰、相關器、加權乘法和累加器。

離散事件仿真模型使用以下組件：

·4個5MHz的ADC通道；

·512字節和1024字節長度的數據包；

·233MHz的FIFO；

·深度為1024的緩沖器；

·初始時鐘速率為125MHz的FPGA。改變FPGA時鐘速率可滿足延時要求；

·運行在167MHz的外部DDR內存；

·運行在260MHz的ADSP TS201。使用VisualSim Architect的預構建可配置庫以圖形化的方式構建模型。使用Visual Sim的“System- Resource”庫塊對處理器、內存、FPGA資源、總線和互連進行建模。模數轉換器(ADC)被建模為流量發生器，負責產生5MHz的數字樣本。

在這個系統設計中，我們為每個函數都考慮了抽象細節。利用這些細節，通過集成matlab/simulink/C/ C++模塊，可以創建精細模型。對每個函數來說，我們已經考慮了運行在系統發生器中的現有Verilog代碼的時序值和標準發布值。加權輸入總和被轉發給數字信號處理器進行顯示處理和浮點FFT，處理后的結果數據被寫進幀緩沖器用于顯示。建議的系統平臺框圖如圖1所示，VisualSim仿真模型如圖2所示。

圖1：系統框架(來源：Mirabilis設計項目報告)。

圖2：信號處理平臺的VisualSim模型(來源：Micabilis設計項目報告)。

分析與報告

模型的構建花了兩個人時，仿真在擁有4GB RAM的2.6GHz微軟Windows 10平臺上執行，仿真的實際時間為900ms。VisualSim花了25s完成一次仿真。根據數據包大小得出算法處理結束的時間，并在功耗和性能之間做出折衷，是設計時要重點考慮的問題。

分析1

這個設計將緩沖器深度選為“數據包長度的”兩倍，長度為512字節的包的信號處理時延有望在20ms以下。

圖3顯示的仿真報告表明，最大處理延時是24.52ms，這說明在FPGA上實現信號處理功能需要花更多的周期?？朔@個挑戰的解決方案是要么提高FPGA的時鐘速率，要么修改算法。我們決定提高FPGA的時鐘速率作為初步的解決方案。

圖4：系統功耗(來源：Mirabilis設計項目報告)。

隨著后續的研究，我們發現如果將FPGA的時鐘速率從125MHz提高到170MHz，系統就能滿足20ms的延時要求，而且我們發現平均功耗(6.2W) 只增加了1.1W。

延時圖形如圖5所示，功耗圖形如圖6所示。

圖6：系統功耗(來源：Mirabilis設計項目報告)。

考慮到有可能需要支持增加包長，我們將數據包長度從512字節增加到了2048字節以作進一步分析。我們發現，功耗沒有明顯的變化，但最大處理延時從期望的20ms左右增加到了76ms，系統的平均功耗為7.8W。

圖7：處理延時(來源：Mirabilis設計項目報告)。

我們還觀察了某些函數的緩沖器占用情況。表1表明,針對上述所有場景,每個函數緩沖器占用情況是一致的( 緩沖器占用以包數計量)。這意味著這種算法實現沒有為了支持不同的數據包大小而進行優化，而且如果設計要求不同的包大小，這種實現也是不可行的。

表1，緩沖器要求

分析2

在這次探索中，我們為每個ADC通道的每個函數建立了專用資源模型。

我們通過查看處理延時圖形和平均功耗圖形來評估系統配置。

處理延時如圖8所示，平均功耗如圖9所示。

圖8：處理延時(來源：Mirabilis設計項目報告)。

由于每個ADC通道的每個函數都有專門的FPGA資源，因此，與分析1 所示的平均系統功耗相比，這次系統的功耗增加了很多。不過平均的端到端延時小于10.8ms，尋峰延時為11.1ms。

圖9：平均功耗(來源：Mirabilis設計項目報告)。

這表明，如果每個ADC 通道都考慮使用專門的FPGA資源， 即使FPGA時鐘速率較低也能滿足性能要求。不足之處就是FPGA資源要求更高了，而且平均功耗增加了100%。

小結

使用建模和仿真方法進行早期的設計探索可以驗證實現信號處理的硬件能力和效率，從而確保所選的架構有足夠的處理能力來滿足系統在性能、功耗和可靠性方面的要求。利用VisualSim性能建?？梢詭椭覀児烙嬞Y源要求、性能和功耗統計數據， 進而做出正確的設計決策。

在研究過程中我們發現，系統架構師可以通過“分析1”做出平衡系統性能和功耗的設計決策?！胺治?” 則表明，即使用較低的時鐘速率也可以實現系統性能，但要求更多的FPGA資源，并且功耗要求增加了幾乎一倍。

通過構建硬件資源的周期精確模型并進行微架構級的研究，上述探索還能進一步擴展。
編輯：hfy