什么是dsp技術
數字信號處理(DigitalSignalProcessing,簡稱DSP)是一門涉及許多學科而又廣泛應用于許多領域的新興學科。20世紀60年代以來,隨著計算機和信息技術的飛速發(fā)展,數字信號處理技術應運而生并得到迅速的發(fā)展。在過去的二十多年時間里,數字信號處理已經在通信等領域得到極為廣泛的應用。
數字信號處理是利用計算機或專用處理設備,以數字形式對信號進行采集、變換、濾波、估值、增強、壓縮、識別等處理,以得到符合人們需要的信號形式。
數字信號處理是圍繞著數字信號處理的理論、實現和應用等幾個方面發(fā)展起來的。數字信號處理在理論上的發(fā)展推動了數字信號處理應用的發(fā)展。反過來,數字信號處理的應用又促進了數字信號處理理論的提高。而數字信號處理的實現則是理論和應用之間的橋梁。
數字信號處理是以眾多學科為理論基礎的,它所涉及的范圍極其廣泛。例如,在數學領域,微積分、概率統(tǒng)計、隨機過程、數值分析等都是數字信號處理的基本工具,與網絡理論、信號與系統(tǒng)、控制論、通信理論、故障診斷等也密切相關。近來新興的一些學科,如人工智能、模式識別、神經網絡等,都與數字信號處理密不可分。可以說,數字信號處理是把許多經典的理論體系作為自己的理論基礎,同時又使自己成為一系列新興學科的理論基礎。
世界上第一個單片DSP芯片應當是1978年AMI公司發(fā)布的S2811,1979年美國Intel公司發(fā)布的商用可編程器件2920是DSP芯片的一個主要里程碑。這兩種芯片內部都沒有現代DSP芯片所必須有的單周期乘法器。1980年,日本NEC公司推出的μPD7720是第一個具有乘法器的商用DSP芯片。
在這之后,最成功的DSP芯片當數美國德州儀器公司(TexasInstruments,簡稱TI)的一系列產品。TI公司在1982年成功推出其第一代DSP芯片TMS32010及其系列產品TMS32011、TMS320C10/C14/C15/C16/C17等,之后相繼推出了第二代DSP芯片TMS32020、TMS320C25/C26/C28,第三代DSP芯片TMS320C30/C31/C32,第四代DSP芯片TMS320C40/C44,第五代DSP芯片TMS320C5X/C54X,第二代DSP芯片的改進型TMS320C2XX,集多片DSP芯片于一體的高性能DSP芯片TMS320C8X以及目前速度最快的第六代DSP芯片TMS320C62X/C67X等。TI將常用的DSP芯片歸納為三大系列,即:TMS320C2000系列(包括TMS320C2X/C2XX)、TMS320C5000系列(包括TMS320C5X/C54X/C55X)、TMS320C6000系列(TMS320C62X/C67X)。如今,TI公司的一系列DSP產品已經成為當今世界上最有影響的DSP芯片。TI公司也成為世界上最大的DSP芯片供應商,其DSP市場份額占全世界份額近50%。
DSP處理器與通用處理器的比較
考慮一個數字信號處理的實例,比如有限沖擊響應濾波器(FIR)。用數學語言來說,FIR濾波器是做一系列的點積。取一個輸入量和一個序數向量,在系數和輸入樣本的滑動窗口間作乘法,然后將所有的乘積加起來,形成一個輸出樣本。
類似的運算在數字信號處理過程中大量地重復發(fā)生,使得為此設計的器件必須提供專門的支持,促成了了DSP器件與通用處理器(GPP)的分流:
1、對密集的乘法運算的支持
GPP不是設計來做密集乘法任務的,即使是一些現代的GPP,也要求多個指令周期來做一次乘法。而DSP處理器使用專門的硬件來實現單周期乘法。DSP處理器還增加了累加器寄存器來處理多個乘積的和。累加器寄存器通常比其他寄存器寬,增加稱為結果bits的額外bits來避免溢出。
同時,為了充分體現專門的乘法-累加硬件的好處,幾乎所有的DSP的指令集都包含有顯式的MAC指令。
2、存儲器結構
傳統(tǒng)上,GPP使用馮.諾依曼存儲器結構。這種結構中,只有一個存儲器空間通過一組總線(一個地址總線和一個數據總線)連接到處理器核。通常,做一次乘法會發(fā)生4次存儲器訪問,用掉至少四個指令周期。
大多數DSP采用了哈佛結構,將存儲器空間劃分成兩個,分別存儲程序和數據。它們有兩組總線連接到處理器核,允許同時對它們進行訪問。這種安排將處理器存貯器的帶寬加倍,更重要的是同時為處理器核提供數據與指令。在這種布局下,DSP得以實現單周期的MAC指令。
還有一個問題,即現在典型的高性能GPP實際上已包含兩個片內高速緩存,一個是數據,一個是指令,它們直接連接到處理器核,以加快運行時的訪問速度。從物理上說,這種片內的雙存儲器和總線的結構幾乎與哈佛結構的一樣了。然而從邏輯上說,兩者還是有重要的區(qū)別。
GPP使用控制邏輯來決定哪些數據和指令字存儲在片內的高速緩存里,其程序員并不加以指定(也可能根本不知道)。與此相反,DSP使用多個片內存儲器和多組總線來保證每個指令周期內存儲器的多次訪問。在使用DSP時,程序員要明確地控制哪些數據和指令要存儲在片內存儲器中。程序員在寫程序時,必須保證處理器能夠有效地使用其雙總線。
此外,DSP處理器幾乎都不具備數據高速緩存。這是因為DSP的典型數據是數據流。也就是說,DSP處理器對每個數據樣本做計算后,就丟棄了,幾乎不再重復使用。
3、零開銷循環(huán)
如果了解到DSP算法的一個共同的特點,即大多數的處理時間是花在執(zhí)行較小的循環(huán)上,也就容易理解,為什么大多數的DSP都有專門的硬件,用于零開銷循環(huán)。所謂零開銷循環(huán)是指處理器在執(zhí)行循環(huán)時,不用花時間去檢查循環(huán)計數器的值、條件轉移到循環(huán)的頂部、將循環(huán)計數器減1。
與此相反,GPP的循環(huán)使用軟件來實現。某些高性能的GPP使用轉移預報硬件,幾乎達到與硬件支持的零開銷循環(huán)同樣的效果。
4、定點計算
大多數DSP使用定點計算,而不是使用浮點。雖然DSP的應用必須十分注意數字的精確,用浮點來做應該容易的多,但是對DSP來說,廉價也是非常重要的。定點機器比起相應的浮點機器來要便宜(而且更快)。為了不使用浮點機器而又保證數字的準確,DSP處理器在指令集和硬件方面都支持飽和計算、舍入和移位。
5、專門的尋址方式
DSP處理器往往都支持專門的尋址模式,它們對通常的信號處理操作和算法是很有用的。例如,模塊(循環(huán))尋址(對實現數字濾波器延時線很有用)、位倒序尋址(對FFT很有用)。這些非常專門的尋址模式在GPP中是不常使用的,只有用軟件來實現。
6、執(zhí)行時間的預測
大多數的DSP應用(如蜂窩電話和調制解調器)都是嚴格的實時應用,所有的處理必須在指定的時間內完成。這就要求程序員準確地確定每個樣本需要多少處理時間,或者,至少要知道,在最壞的情況下,需要多少時間。
如果打算用低成本的GPP去完成實時信號處理的任務,執(zhí)行時間的預測大概不會成為什么問題,應為低成本GPP具有相對直接的結構,比較容易預測執(zhí)行時間。然而,大多數實時DSP應用所要求的處理能力是低成本GPP所不能提供的。
這時候,DSP對高性能GPP的優(yōu)勢在于,即便是使用了高速緩存的DSP,哪些指令會放進去也是由程序員(而不是處理器)來決定的,因此很容易判斷指令是從高速緩存還是從存儲器中讀取。DSP一般不使用動態(tài)特性,如轉移預測和推理執(zhí)行等。因此,由一段給定的代碼來預測所要求的執(zhí)行時間是完全直截了當的。從而使程序員得以確定芯片的性能限制。
7、定點DSP指令集
定點DSP指令集是按兩個目標來設計的:
·使處理器能夠在每個指令周期內完成多個操作,從而提高每個指令周期的計算效率。
·將存貯DSP程序的存儲器空間減到最?。ㄓ捎诖鎯ζ鲗φ麄€系統(tǒng)的成本影響甚大,該問題在對成本敏感的DSP應用中尤為重要)。
為了實現這些目標,DSP處理器的指令集通常都允許程序員在一個指令內說明若干個并行的操作。例如,在一條指令包含了MAC操作,即同時的一個或兩個數據移動。在典型的例子里,一條指令就包含了計算FIR濾波器的一節(jié)所需要的所有操作。這種高效率付出的代價是,其指令集既不直觀,也不容易使用(與GPP的指令集相比)。
GPP的程序通常并不在意處理器的指令集是否容易使用,因為他們一般使用象C或C++等高級語言。而對于DSP的程序員來說,不幸的是主要的DSP應用程序都是用匯編語言寫的(至少部分是匯編語言優(yōu)化的)。這里有兩個理由:首先,大多數廣泛使用的高級語言,例如C,并不適合于描述典型的DSP算法。其次,DSP結構的復雜性,如多存儲器空間、多總線、不規(guī)則的指令集、高度專門化的硬件等,使得難于為其編寫高效率的編譯器。
即便用編譯器將C源代碼編譯成為DSP的匯編代碼,優(yōu)化的任務仍然很重。典型的DSP應用都具有大量計算的要求,并有嚴格的開銷限制,使得程序的優(yōu)化必不可少(至少是對程序的最關鍵部分)。因此,考慮選用DSP的一個關鍵因素是,是否存在足夠的能夠較好地適應DSP處理器指令集的程序員。
8、開發(fā)工具的要求
因為DSP應用要求高度優(yōu)化的代碼,大多數DSP廠商都提供一些開發(fā)工具,以幫助程序員完成其優(yōu)化工作。例如,大多數廠商都提供處理器的仿真工具,以準確地仿真每個指令周期內處理器的活動。無論對于確保實時操作還是代碼的優(yōu)化,這些都是很有用的工具。
GPP廠商通常并不提供這樣的工具,主要是因為GPP程序員通常并不需要詳細到這一層的信息。GPP缺乏精確到指令周期的仿真工具,是DSP應用開發(fā)者所面臨的的大問題:由于幾乎不可能預測高性能GPP對于給定任務所需要的周期數,從而無法說明如何去改善代碼的性能。
評論
查看更多