在soc設(shè)計方法中加入低開銷、低功耗的音頻處理

1、在soc設(shè)計方法中加入低開銷、低功耗的音頻處理     關(guān)鍵詞：編解碼,音頻處理,有損壓縮,乘法器,模擬音頻,采樣位數(shù),算法處理,功耗如果你打算設(shè)計一個包含數(shù)字音頻的SoC系統(tǒng)，或者正在進行這樣一個項目，那么花幾分鐘時間閱讀本文可以幫助你在各種技術(shù)參數(shù)之間做出更好的平衡，避免設(shè)計方向出現(xiàn)偏差，提高流片的成功率，從而節(jié)省數(shù)周的開發(fā)時間。我們將為你逐一分析設(shè)計備選方案，評估中的關(guān)鍵因素以及由此做出的決策。消費類音頻產(chǎn)品的歷史消費類音頻產(chǎn)品的歷史最早可以追溯到130年前，在開始的100年間，音頻回放只能采用模擬技術(shù)。那時采用數(shù)字技術(shù)的產(chǎn)品體積龐大，價格昂貴，對

2、于消費類產(chǎn)品來說也過于復(fù)雜。直到1982年，CD光盤和CD播放器的出現(xiàn)徹底改變了這種局面，黑膠唱片設(shè)備似乎一夜之間就消失了。日趨復(fù)雜的音頻編解碼格式對性能的需求不斷增長，要求處理器的主頻也不斷提高。然而，提高主頻會給設(shè)計帶來一系列的問題，更高的主頻意味著更高的功耗，更多的發(fā)熱量，需要容量更大的電池，為了散熱而增加的風(fēng)扇也會增加產(chǎn)品成本，并會帶來令人討厭的噪音。SoC設(shè)計過程中，更高的處理器主頻同時會使時序收斂變得更困難。所有這些問題都應(yīng)該引起設(shè)計者的注意。迄今為止，銷量最大的數(shù)字音頻播放器是移動電話。除了撥打電話的功能，現(xiàn)在的移動電話實際上都是小型的多媒體終端，既可以播放音視頻內(nèi)容，又能運行包

3、含了復(fù)雜音效的游戲，這些功能要求移動電話具有強勁的音頻處理能力，同時功耗又要盡可能的低，因為消費者總是希望他們購買的手機有足夠長的待機時間，同時希望MP3播放器在提供優(yōu)秀音質(zhì)的同時也能長時間播放。伴隨著音頻的數(shù)字化，視頻也已經(jīng)完成了數(shù)字化。如今大多數(shù)的視頻播放設(shè)備都兼容多種音頻標準。在汽車音響領(lǐng)域，數(shù)字化也在如火如荼的進行中。多年以前，CD被作為標準裝備裝入汽車，近年來，隨著高保真衛(wèi)星廣播的普及，數(shù)字收音機也進入了汽車電子領(lǐng)域。在GPS導(dǎo)航設(shè)備中，需要文本到語音的轉(zhuǎn)換，某些GPS設(shè)備還兼具個人媒體播放器的功能。音頻編解碼編解碼格式是所有數(shù)字音頻應(yīng)用中的核心元素，它定義了模擬音頻信號如何數(shù)字化并

4、被壓縮成比特流，以及比特流如何被解壓并還原為模擬音頻信號。在消費類產(chǎn)品領(lǐng)域最流行的壓縮算法是MP3格式，它于1991年同MPEG-1視頻標準一起推出，90年代中期，誕生了第一臺MP3播放器。隨后，廠商們不停在推廣其他可以提供更高保真度和更低比特率的算法格式，但MP3仍然在音頻標準中占有重要地位，當前幾乎所有的消費類產(chǎn)品都支持MP3格式。大多數(shù)的音頻編解碼算法都采用有損壓縮來降低所需的比特率。有損壓縮可以減小數(shù)據(jù)交換和存儲的帶寬需求，從而降低成本，這也是廠商們采用有損壓縮的原因。然而，有損壓縮也會降低音頻的質(zhì)量，質(zhì)量下降的程度與壓縮算法有關(guān)。只要有足夠強大的處理能力，就可以將聲音損失控制在人耳無

5、法分辨的水平，因此壓縮算法研究人員依然在不斷改進他們的算法。不同的應(yīng)用需要根據(jù)自身特點在音頻質(zhì)量和帶寬需求之間作出平衡，造成了多種數(shù)字音頻編解碼格式并存的局面。當你開始考慮如何實現(xiàn)一種音頻編解碼算法時，你實際上有4種備選方案1. 在通用處理器上依靠軟件實現(xiàn)音頻編解碼。例如在PC上運行的MP3播放器程序。2. 利用專用的硬件實現(xiàn)音頻編解碼，早期的便攜MP3播放器采用這種方案。3. 在DSP處理器上依靠軟件實現(xiàn)音頻編解碼。4. 在基于通用處理器進行擴展的音頻專用處理器上用軟件實現(xiàn)音頻編解碼。方案1，用一個通用處理器來實現(xiàn)所有系統(tǒng)功能，包括用戶界面，I/O和數(shù)字音頻編解碼。這個方案有以下幾個優(yōu)點。首

6、先，音頻編解碼只是通用處理器上運行的一段軟件程序，唯一的硬件開銷也許只是增加少量的指令內(nèi)存。其次，由于采用了軟件實現(xiàn)編解碼，可以實現(xiàn)多種編解碼算法。最后，當出現(xiàn)新的編解碼算法時，只需要升級軟件就可以支持。這種方案也的缺點也很明顯。數(shù)字音頻對于暫時失靈很敏感，因為人耳可以捕捉到非常細小的錯誤。在這一點上音頻應(yīng)用比視頻應(yīng)用的要求更苛刻。在視頻應(yīng)用中，一個錯誤的像素往往不會被注意到，而音頻應(yīng)用中則不然。采用通用處理器來進行音頻編解碼，由于處理器還會執(zhí)行其他的任務(wù)，其帶寬并非音頻專用，這樣增加了音頻編解碼暫時失靈的概率。 除此以外，大多數(shù)的通用處理器沒有音頻專用指令，不能高效的執(zhí)行音頻編解碼程序，從而

7、不得不提高處理器的主頻，在單位時間里執(zhí)行更多的指令來達到性能要求。硬件實現(xiàn)編解碼方案2，采用一顆性能相對較低的處理器搭配專門的音頻處理硬件，所有的音頻處理任務(wù)都由專用硬件來完成。通常，這塊硬件作為外設(shè)掛在系統(tǒng)總線上。音頻采樣由處理器通過總線送給編解碼硬件，或者由編解碼硬件通過DMA直接從內(nèi)存中讀取。在這種方案中系統(tǒng)總線也是共享的。圖1：在使用專用編解碼硬件的方案中，每種編解碼格式都需增加硬件模塊來支持。方案3，在通用DSP處理器上通過軟件來實現(xiàn)音頻編解碼，系統(tǒng)中同時包括一顆用來作控制的主處理器(這里的通用DSP處理器是指沒有專門針對音頻處理做過優(yōu)化的DSP處理器)。采用DSP處理器的方案有很多

8、優(yōu)點。首先，DSP處理器中都有硬件乘法器，可以極大提高音頻編解碼程序的執(zhí)行效率。其次，因為采用軟件方式實現(xiàn)，只增加少量的存儲器開銷就可以支持多格式音頻編解碼。實現(xiàn)新的編解碼算法也僅僅需要編寫新的軟件，不必重新流片，從而延長產(chǎn)品的生命周期。采用DSP的方案也有缺點。大多數(shù)DSP的C編譯器效率都比較低，所以一般不用DSP來做控制。系統(tǒng)的控制需要通用處理器來完成。而且，16或32位的DSP處理器對音頻處理來說并不是最理想的。雖然當前大多數(shù)編解碼算法采用16位采樣，但在運算的中間過程中為了避免舍入錯誤，需要留有一定余量。所以16位DSP處理器在實現(xiàn)復(fù)雜音頻算法時會帶來問題。使用雙精度整數(shù)計算可以避免問

9、題，但效率又不夠高導(dǎo)致需要更高的處理器主頻。反過來，32位DSP處理器又不能被充分利用。實際上，對于音頻算法而言，24位DSP處理器是最適合的。音頻專用RISC處理器基于上述考慮，我們提出了第4種方案，即采用音頻專用處理器?；谕ㄓ锰幚砥鬟M行音頻處理的擴展，使處理器在高效執(zhí)行音頻編解碼程序的同時，保持C編譯器的效率。圖2所示就是一個采用音頻專用處理器進行編解碼的系統(tǒng)。圖2：采用音頻專用處理器進行編解碼的系統(tǒng)。 這種設(shè)計方案有很多優(yōu)點。首先，音頻專用擴展使處理器更加高效的執(zhí)行音頻算法，在較低的主頻下提供算法所需的性能，從而顯著降低系統(tǒng)功耗。與基于DSP的方案一樣，此方案便于實現(xiàn)多格式的音頻編解碼

10、，也可以通過升級軟件來支持新的編解碼算法。它的不足之處在于大家對于音頻專用處理器的概念還很陌生，下面我們就來介紹一下音頻專用處理器。Tensilica Hi-Fi2音頻處理引擎是基于32位Tensilica Xtensa RISC處理器經(jīng)過配置和擴展得到的，它可以非常高效的完成音頻處理任務(wù)。顧名思義，Hi-Fi2音頻處理引擎是Tensilica第二代音頻處理器。Hi-Fi2音頻處理引擎中最關(guān)鍵的擴展就是增加了兩個24位的硬件乘法器，它們可以大大提高音頻計算的速度。然而，乘法器本身并不會減少執(zhí)行音頻算法需要的周期數(shù)，周期數(shù)減少是因為Hi-Fi2音頻處理引擎每個周期可以執(zhí)行1到2條指令。48位或5

11、6位寬的寄存器可以存放2個24位的采樣值。利用這些寄存器文件可以高效的處理立體聲音頻數(shù)據(jù)。Tensilica總共在Xtensa RISC處理器上添加了300條音頻專用指令，創(chuàng)建了一個靈活高效的音頻算法處理引擎。一套優(yōu)秀的音頻SOC解決方案不僅限于高性能的硬件，還需要有編解碼軟件，而由于時間的原因，你可能并不打算自己編寫程序。雖然從互聯(lián)網(wǎng)上可以找到一些音頻處理程序，但是這些程序并沒有經(jīng)過優(yōu)化，執(zhí)行起來效率不高。其次，像Dolby音頻編解碼這樣需要授權(quán)的程序是很難在互聯(lián)網(wǎng)上找到的。目前流行的音頻編解碼算法都已經(jīng)移植到了Tensilica的Hi-Fi2音頻處理引擎上，而且支持的格式還在不斷增加，如圖3所示，所有這些編解碼程序都是用C語