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

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

本文介紹的系統(tǒng)級建模和仿真方法，可以用來在設(shè)計流程早期為軟件無線電或高速通信調(diào)制解調(diào)器設(shè)計信號處理平臺的架構(gòu)。

問題

先進的高速信號處理平臺等大多數(shù)復(fù)雜系統(tǒng)都會經(jīng)歷昂貴的重復(fù)設(shè)計，超過70%的重復(fù)時間是由于設(shè)計決策錯誤或?qū)π枨蟮恼`解。此外，影響這些復(fù)雜系統(tǒng)的因素有很多，如低處理時延、低功耗、可配置能力和資源限制等。早期的設(shè)計探索有助于克服這些問題。

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

解決方案

利用離散事件仿真，設(shè)計師和架構(gòu)師可在較短的時間內(nèi)根據(jù)成百上千個使用案例、任務(wù)調(diào)度和系統(tǒng)配置，對目標(biāo)系統(tǒng)進行評估。離散事件建模和仿真不僅有助于構(gòu)建特別復(fù)雜的仿真模型，而且能夠幫助架構(gòu)師和設(shè)計師運行更多的用例。

此外，硬件架構(gòu)組件與框架的預(yù)構(gòu)建和有效庫有助于軟件架構(gòu)的建模。它們可以提高系統(tǒng)模型的精度，縮短構(gòu)建仿真模型的時間。

這種方法允許設(shè)計師：

● 專注于結(jié)果的分析和解釋，而不用關(guān)心模型的構(gòu)建；

● 采用不同的應(yīng)用配置來執(zhí)行仿真， 以便進行平臺選擇，做出軟硬件決策，了解外設(shè)、性能以及目標(biāo)架構(gòu)上軟件線程的分配，從而優(yōu)化產(chǎn)品架構(gòu)。

解決方案實現(xiàn)

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

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

·4個5MHz的ADC通道；

·512字節(jié)和1024字節(jié)長度的數(shù)據(jù)包；

·233MHz的FIFO；

·深度為1024的緩沖器；

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

·運行在167MHz的外部DDR內(nèi)存；

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

在這個系統(tǒng)設(shè)計中，我們?yōu)槊總€函數(shù)都考慮了抽象細節(jié)。利用這些細節(jié)，通過集成matlab/simulink/C/ C++模塊，可以創(chuàng)建精細模型。對每個函數(shù)來說，我們已經(jīng)考慮了運行在系統(tǒng)發(fā)生器中的現(xiàn)有Verilog代碼的時序值和標(biāo)準(zhǔn)發(fā)布值。加權(quán)輸入總和被轉(zhuǎn)發(fā)給數(shù)字信號處理器進行顯示處理和浮點FFT，處理后的結(jié)果數(shù)據(jù)被寫進幀緩沖器用于顯示。建議的系統(tǒng)平臺框圖如圖1所示，VisualSim仿真模型如圖2所示。

圖1：系統(tǒng)框架(來源：Mirabilis設(shè)計項目報告)。

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

分析與報告

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

分析1

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

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

圖4：系統(tǒng)功耗(來源：Mirabilis設(shè)計項目報告)。

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

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

圖6：系統(tǒng)功耗(來源：Mirabilis設(shè)計項目報告)。

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

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

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

表1，緩沖器要求

分析2

在這次探索中，我們?yōu)槊總€ADC通道的每個函數(shù)建立了專用資源模型。

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

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

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

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

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

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

小結(jié)

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

在研究過程中我們發(fā)現(xiàn)，系統(tǒng)架構(gòu)師可以通過“分析1”做出平衡系統(tǒng)性能和功耗的設(shè)計決策。“分析2” 則表明，即使用較低的時鐘速率也可以實現(xiàn)系統(tǒng)性能，但要求更多的FPGA資源，并且功耗要求增加了幾乎一倍。

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