B.1 研究目的
無線通訊在目前電子產業中已漸趨普及，其中於多媒體方面的應用更是愈來愈重要，現 今多媒體的應用主要包括視訊、音訊和語音，其品質主要取決於本身訊源壓縮的效率，希望 能在有限的傳輸速率或是容易受到雜訊干擾的環境下，盡可能降低失真的程度，便是此部分 主要的研究方向之一；在語音部分，3GPP 制訂了 Adaptive Multi-Rate(AMR)語音編碼標準 [5][6]，規定了八種不同的傳輸速率下去做編碼。目的在於能夠根據各種不同的傳輸環境，
來調整語音與錯誤修正編碼之間的比例，以有效率的提升語音品質，同時降低傳輸環境所造 成的影響。G.723.1 為 3GPP 所制訂的前一代語音標準，在相似的傳輸速率下，藉由 AMR 編 碼可以得到較 G.723.1 佳的語音品質。
本研究部分所使用的 AMR reference software 為 3GPP 所提供，使用 C++語言撰寫，我 們最終目的要將 AMR 的編碼與解碼器實現至德州儀器 C6416 的 DSP 平台上。因此我們的 主要工作首先要考慮此實現平台的硬體架構，藉此減低程式的複雜度。待其運算速度達到 real time 的目標之後，進而實現至 DSP 平台上，使得程式能夠更有效率的執行，同時也盡 可能發揮硬體的最大功效。
B.2 文獻探討
參考 TI 出版之 Programmer’s Guide[7]，TI 所建議的 DSP 程式設計及最佳化流程可先進 行程式的 Profile，也就是利用 TI DSP 專用之程式編譯器 Code Composer Studio (CCS)進行編 譯後。執行內附之 Profiler 功能後，分析所產生之檔案 Profile，觀察出程式中各個部分功能 運行時所消耗的資源(或是運算時間)，進而對佔據最多運算時間的部分來做改善。
一般來說，初步從演算法著手可以得到較為顯著的改善，接著可以配合 DSP 的硬體架 構，繼續對 C 語言的撰寫方式去做改進，使得編譯器能夠編譯出更有效率的程式。此方面 可以利用 CCS 編譯器回報(Compiler’s Feedback)部分，觀察到我們所設計的程式在 DSP 硬體 中的資源使用情形，以及 TI DSP 特別支援的 Software Pipelining(SP)功能的運作情況，由資 源使用的分佈平均與否以及 SP 的平行化效率，來判斷我們的程式撰寫是否可以適應 DSP 特 殊的硬體架構，亦可使執行效率提升。
若是單單只有在 C 語言上去做調整，所能得到的改進幅度有限。在 TI 的 Programmer’s Guide 中還有提供了線性組合語言(Linear Assembly)的層級來供程式撰寫者來做進一步的改 善，雖然從組合語言著手能夠對每個指令做最佳的調整，以符合 DSP 的運算架構。但其層 級相對於 C 較低，因此採用這種最佳化的手段是比較繁瑣而且耗費時間的，只有在以上方 法皆無法使效能顯著提升時，才考慮對此部分做調整。
由於我們所使用的 reference software 是由 3GPP 所提供，其 C 語言的程式撰寫方式已做 過 某 個 程 度 上 的 最 佳 化 ， 因 此 繼 續 對 C 語 言 做 調 整 並 非 最 有 效 率 的 改 善 方 式 。 在 Programmer’s Guide 中還提供了 intrinsic function。此為 TI C6000 系列編譯器所支援的特別 指令，在編譯時會自動被取代為 C64 的組合語言指令，使得在不增加指令數目的情況下，
善用 DSP 的特殊架構來做運算。此改善方法顯然能夠極有效率地降低程式在 DSP 上的執行 時間，因此接下來便以此方式配合 C 語言細部的一些調整來做改善。
19%
圖 B.1. 3GPP Reference Software 的 Profile 資料 (右方所列為前九個最耗運算時間的算數運算函數)
B.3 研究方法
B.3.1 改善程式運算效率
依據 Programmer’s Guide 中所建議的改善步驟，我們先對 reference software 做 Profile，
藉此得知哪一個部分需要最多的執行時間，進而從該部分著手改善。經過 Profile 後所得到的
中討論各種改善方式的結果，使用 intrinsic function 將是最快速，且改善效果最顯著的方式。
雖然 TI DSP 提供了許多 intrinsic function，但 AMR 編碼程式中所使用的算數運算函數 種類繁多。因此有時仍須對 intrinsic function 做些調整來達到我們所要的運算，舉例如下：
首先以 intrinsic function「_abs2」為例，此用於將兩個 16 位元的數值取絕對值並一同存 入一個 32 位元的變數中。若我們希望將一個 32 位元的數值取絕對值並截取為一 16 位元的 數值，我們便可以同時將 0 與此 32 位元的數值作為其輸入，再取其輸出數值的最低 16 位元 即可達成我們所要的運算。
接下來假設要對某 16 位元的變數取負號，溢位(overflow)則做 saturation 的動作。我們 知道，對某數取負號相當於用 0 減去該數值，因此我們可以使用 intrinsic function 中的
「_ssub」—兩數相減並判斷是否溢位，溢位則做 saturation，將 0 減去此輸入的 16 位元數值。
但是_ssub 的減法與判斷溢位皆為 32 位元運算，所以我們可以改為先將該 16 位元的輸入值 向左位移成 32 位元的數值。待 0 與此 32 位元數值相減後，再將結果向右位移 16 位元，取 其最低 16 位元即為我們所要的數值，經過調整之後的效果便會相當於我們要的運算。
另外，以函數「saturate」為例，即將 32 位元的輸入值截取為 16 位元，並判斷其是否 溢位，若溢位則做 saturation。在此我們有兩種實現方式，第一，可以使用類似前例的實現 方法，我們使用 intrinsic function 中的「_sshl」。其作用為將輸入數值向左位移所要的位元數，
並根據溢位情形來決定是否做 saturation，亦為 32 位元運算。同理，我們可以先利用_sshl 將 32 位元的輸入值向左位移 16 位元，待其判斷是否做 saturation 後，再將輸出向右位移 16 位元，最低的 16 位元即為我們所要的結果。另一方法可使用「_spack2」來實現。此 intrinsic function 是用來將兩個輸入值截取為 16 位元，並分別判斷是否需做 saturation，最後再將個 別的結果一起存入一個 32 位元的變數中。因此我們可以直接將 0 以及要做運算的 32 位元數 輸 介 面 可 分 為 三 種 ： Packetized Message Interface、Busmaster Interface 與 Block Mode Streaming。Packetized Message Interface 主要用於傳輸命令與訊號，由於其傳輸速率較低，
一次可傳輸的資料量也較少，不適於用來傳輸運算資料。Busmaster Interface 為最快的傳輸 模式，其適用於連續性的資料傳輸，也因此可以減少主機與 DSP 平台之間的訊號傳遞。但 由於我們的 AMR 編碼與解碼器皆以一個框架(frame)為單位，所以在此我們選擇 Block Mode Streaming 的傳輸模式來做實現。其可支援不同大小的資料區塊(data block)為單位去做傳輸，
由於可以一次傳送大量資料，因此亦為一有效率的高速傳輸模式。 部分，主機端從要做編碼的語音檔中擷取一個框架，再利用 Block Mode Streaming 的傳輸方 式將框架資料與指定的編碼模式一起送至 DSP 端。待由 DSP 完成編碼工作後，再將編碼過
如「研究方法」中所述，我們在加速程式的部分主要使用 intrinsic function 來改善佔據 大量運算時間的算數運算函數。經過改進之後，最大的改進幅度高達 91.31%，部分函數的 程式量更是大大的降低。這是由於有許多原本需要數行指令才能完成的動作，用單獨一個 intrinsic function 即可取代並達到相同的效果。但其中仍有些算數函數的改善幅度並不顯著，
原因在於在這些函數當中，除了算數運算之外，有些還需要做旗標(flag)運算。以「L_add」
函數為例，做相加並判斷是否溢位後，除了要對相加結果作調整，還要判斷溢位的旗標是否 要設為一。前者可以完全用 intrinsic function 取代，但後者的運算卻不行，以致於判斷是否 溢位的動作(會造成 branch 的運算)也無法消除。因此主要耗費運算時間的部分沒有被消除，
改善的幅度也就有限。
最後，我們再使用 CCS 編譯器所提供的最佳化選項來為我們的程式做改善。在此我們 直接將最佳化的層級調至最高，所測得的運算時間如下表 B.1
Encoder Version Code Size Cycles Improvement Percentage (%)
Original 31,791,683 24,673,217 N/A
Modification with Intrinsics 31,790,850 22,656,174 8.18 File-Level Optimization 31,757,874 7,678,555 66.11
(a)
Decoder Version Code Size Cycles Improvement Percentage (%)
Original 31,681,519 3,412,267 N/A
Modification with Intrinsics 31,680,687 3,190,223 6.51 File-Level Optimization 31,662,943 1,155,983 63.76
(b)
表 B.1. (a) AMR 編碼器 Profile 資料， (b) AMR 解碼器 Profile 資料
上表中最後所得到的處理速度，編碼器為 12.80ms/frame，解碼器為 1.93ms/frame。同時 我們測得在未使用 intrinsic function 做改善的情況下，直接使用編譯器來為程式做最佳化，
則編碼器處理速度降為 23.85ms/frame。由於輸入的語音每個框架的時間長度為 20ms，所以 便達不到 real time 的目標，解碼器方面則會降為 3.25ms/frame。而經過 intrinsic function 改 進後的編碼器與解碼器皆可符合 real time 的要求。
實際在 DSP 平台上執行，所測得編碼器最終的處理速度為 14.05ms/frame，總改進幅度 為 65.94% 。若扣除主機與 DSP 端之間傳送資料耗費的時間，則可得到編碼時間為 13.77ms/frame；解碼器方面的處理速度則為 2.43ms/frame。總改進幅度為 61.31%，扣除資 料傳輸時間後，所得的解碼時間為 2.15ms/frame，無論 AMR 編碼器或解碼器皆可達到 real time 的目標。