MPEG-4/21 SoC 設計及新世代行動訊之研究-子計畫二：多媒體通訊數位基頻SoC加速架構及嵌入式作業系統界面的研究(III)

(1)

行政院國家科學委員會專題研究計畫成果報告

子計畫二：多媒體通訊數位基頻 SoC 加速架構及嵌入式作業

系統界面的研究(3/3)

計畫類別：整合型計畫計畫編號： NSC94-2220-E-009-008- 執行期間： 94 年 08 月 01 日至 95 年 07 月 31 日執行單位：國立交通大學資訊工程學系(所) 計畫主持人：蔡淳仁計畫參與人員：王岳宜、蕭哲民、蘇郁淵、李國丞、林君玲報告類型：完整報告處理方式：本計畫可公開查詢

中華民國 95 年 10 月 31 日

(2)

行政院國家科學委員會專題研究計畫成果報告

MPEG-4/21 SOC

設計及新世代行動通訊之研究-子計畫二：多媒體通訊數位基頻 SoC 加速架構及嵌入式作業系統

界面的研究(3/3)

計畫編號：NSC 94-2220-E-009-008

執行期限：94 年 8 月 1 日至 95 年 7 月 31 日

主持人：蔡淳仁國立交通大學資訊工程系

參與人員：王岳宜、蕭哲民、蘇郁淵、李國丞、林君玲

國立交通大學資

訊工程系

中文摘要

本子計畫的主要目的是在研究多媒體數位通訊基頻 SoC 的應用程式加速架構，以及異質多核心的作業系統分工排程器的設計。傳統的通訊基頻晶片，只提供 layer 2 以下的運算功能，以及語音壓縮解壓縮功能。但為了有效支援新一代多媒體通訊應用，許多基頻晶片大廠如 TI、Freescale、及 Qualcomm 都已經推出了整合多媒體甚至 Java 加速功能的單一基頻晶片。在三年的整合計畫中，本計畫主要的完成項目有下面幾項。首先是設計了一個多標準視訊編碼硬體加速 SoC 平台，以利軟硬體協同設計。這個平台有別於以往針對單一多媒體壓縮標準而做的純硬體佈線的設計。本平台的架構設計是以能直接支援 MPEG 正在發展中的 Reconfigurable Video Coding (RVC) 的技術為目標。其次本計畫在異質多核心的作業系統分工排程器的設計方面，完整地在 TI OMAP OSK5912 平台上發展完成了一套 Heterogeneous Multi-Processor (HMP) 的動態工作切割排程作業系統核心，以善用 arm 以及 dsp 雙核心效能，並證明在複雜的多媒體應用上，其效能會比業界慣用的動態工作切割排程雙核心系統好。最後，本計畫也研究了適用手機的 Java VM 環境的加速功能。本計畫以一套公開 RTL 程式碼的、功能類似 KVM 的 Java Processor －JOP 為出發點，設計了一套創新的 Dynamic Code Optimization 的加速機制，把 JOP 在 Spartan III FPGA 上的效能提昇超過 10%。整體而言，本子計畫大體完成了最初計畫提案中每一項提到的可以整合到基頻晶片的應用程式加速功能。

關鍵詞：多媒體通訊、嵌入式作業系統、數位基頻晶片、可動態調整視訊編碼器、Java 處理器

(3)

Abstract

The goal of this project is to design an application acceleration architecture that can be integrated into a multimedia communication baseband SoC, and a OS kernel scheduler for dynamic partitioning of tasks for heterogeneous multi-core systems. Conventional baseband processor only provides computational acceleration for speech codecs and network protocol stacks at layer-2 and below. However, in order to support new multimedia communication applications efficiently, new chip venders such as TI, Freescale, and Qualcomm have all announced baseband chipset with multimedia acceleration capabilities. For the past three years, our project team has completed the following major tasks. First of all, we have designed a multi-format video codec acceleration SoC platform. The platform is different from the conventional codec SoC that is hard-wired for a particular codec. Instead, we have followed the latest Reconfigurable Video Codec Framework Standard that is being developed within MPEG. Secondly, we have designed a dynamic task partitioning OS kernel scheduler for heterogeneous multi-processor (HMP) platforms. The design is completely implemented in a embedded prototyping board based on TI-OMAP 5912. We have also shown that for complex multimedia applications, this dynamic partitioning approach can outperform the traditional static partitioning approach. Finally, we have also investigated techniques to accelerate hardware-based Java Runtime environment. The project team developed an innovative Dynamic Code Optimization for Java processors. The proposed technique is implemented for an open source Java processor, JOP, on Spartan III FPGA and obtains over 10% performance gain. In summary, we have accomplished all the goals listed in the original project proposal.

Keywords: multimedia communication, embedded OS, digital baseband processor, reconfigurable video coding, Java processors

(4)

一、前言 ... 2 二、 研究目的 ... 2 三、 文獻探討 ... 4 四、 結果與討論 ... 4 五、 計劃成果自評 ... 4 附錄一、 可重組的視訊加速 SoC 平台 ... 6 附錄二、 異質多核心作業系統動態分工排程器 ... 12 1. 簡介 ... 12 2. 相關研究 ... 13 2.1 多核心平台排程演算法 ... 13 2.2 對稱式多核心平台與非對稱式多核心平台 ... 14 2.3 同質多核心平台系統下的非對稱式排程 ... 15 2.4 動態式分工及排程 ... 16 2.5 共享資源控制 ... 17 2.6 靜態式分工 ... 18 3. 理論與實作背景 ... 18

3.1 OMAP 5912 Application Processor ... 19

3.2 OMAP 5912 Starter Kit：OSK 5912 (OMAP 5912 OSK) ... 19

3.3 eCos ... 20

3.4 eCos Overview ... 20

3.5 Configure Tool ... 20

3.6 Component ... 20

i. HAL ... 21

ii. The Kernel ... 23

iii. The Scheduler ... 24

a. Multilevel Queue Scheduler ... 24

b. Bitmap Scheduler ... 24

iv. Synchronization Mechanisms ... 24

v. Threads and Interrupt Handling ... 25

vi. RedBoot ... 25

3.7 移植 eCos 到 OMAP 5912 ... 26

4. 異質多核動態分工排程器設計 ... 27

4.1 Scheduler API ... 27

4.2 Service Registrar 和 Core Service Table ... 28

4.3 Dispatcher ... 28 4.4 Task Dispatcher ... 29 4.5 Task Terminator ... 30 4.6 Loading Tables ... 30 4.7 雙核心溝通方法 ... 31 4.8 DSP API ... 32 5. 實驗結果 ... 32 5.1 實驗環境 ... 32 5.2 動態排程實驗 ... 33 5.3 相異處理器實驗 ... 34 5.4 相異 bit rate 實驗 ... 36 5.5 DSP delay 實驗 ... 37

(5)

6. 結論與展望 ... 38

7. 參考文獻 ... 39

附錄三、 Java 處理器加速機制的設計 ... 41

1. Introduction ... 41

1.1 Why Dynamic Code Optimization (DCO) ... 41

1.2 Dynamically-Typed OO Languages ... 41

1.3 Dynamic Message Sending ... 41

1.4 DCO for Java VM Using HW/SW Co-design Approach ... 43

2. Related Work ... 43

2.1 Previous DCO Mechanisms ... 43

2.2 Lookup Cache Mechanism in Smalltalk-80 ... 43

2.3 Inline Cache Mechanism in Smalltalk-80 ... 44

2.4 Polymorphic Inline Cache in SELF System ... 45

2.5 Java Virtual Machine Reference Implementation ... 46

2.6 Sun’sK VirtualMachineReferenceImplementation ... 49

3. Proposed Dynamic Code Optimization System ... 50

3.1 Data Structure Using in Our Dynamic Code Optimization ... 50

i. Data Arrangement in the External Memory ... 50

ii. Method Cache ... 51

iii. Runtime Data Structure ... 52

a. Stack Frame ... 52

b. Data layout ... 53

c. Runtime Class Structure ... 53

3.2 The Proposed Dynamic Code Optimization Scheme ... 53

i. Analysis of Bytecode Execution Frequency ... 54

ii. Access Time of External Memory & Internal Memory ... 54

iii. Architecture Overview ... 55

3.3 Implementation Details ... 56

i. Hardware Modules ... 56

ii. Software Modules ... 57

4. Performance Study ... 58

4.1 Xilinx Spartan-3 Development Board ... 58

4.2 Java Benchmark Programs ... 58

i. Sieve of Eratosthenes ... 58

ii. Kfl ... 58

iii. UDP/IP ... 59

4.3 Experiment Results ... 59

i. Execution Time ... 59

ii. Power consumption ... 59

iii. Microcode Execution Cycles ... 60

iv. External Memory Access Times ... 61

5. Conclusion and Future Work ... 61

(6)

一、前言

本報告是過去三年的整合計畫的完整報告。在三年的整合計畫中，本子計畫大體完成了最初計畫提案中每一項提到的可以整合到基頻晶片的應用程式加速功能。首先，我們設計了一個多標準視訊編碼硬體加速 SoC 平台。並在 ARM Integrator 的 SoC Emulation Platform 上驗證了這個平台。這個平台有別於以往業界針對單一多媒體壓縮標準而做的純硬體佈線的設計。本平台的架構設計是以能直接支援 MPEG 正在發展中的 Reconfigurable Video Coding (RVC) 的技術為目標。其次本計畫在異質多核心的作業系統分工排程器的設計方面，完整地在 TI OMAP OSK5912 平台上發展完成了一套 Heterogeneous Multi-Processor (HMP) 的動態工作切割排程作業系統核心，以善用 arm 以及 dsp 雙核心效能，並證明在複雜的多媒體應用上，其效能會比業界慣用的動態工作切割排程雙核心系統好。最後，本計畫也研究了適用手機的 Java VM 環境的加速功能。本計畫以一套公開 RTL 程式碼的、功能類似 KVM 的 Java Processor－JOP 為出發點，設計了一套創新的 Dynamic Code Optimization 的加速機制，把 JOP 在 Spartan III FPGA 上的效能提昇超過 10%。

二、研究目的

未來行動通訊網路及相關應用一定會成為後 PC 時代的主要科技產業．雖然各種寬頻行動網路（CDMA-2000, WLAN, UMTS/WCDMA）的架設已慢慢成熟，電信業者也推出各種行動數據服務，但行動寬頻網的主要訴求：多媒體通訊應用,卻遲遲不能起飛。其中最主要的理由是多媒體手機的設計一直無法達到理想的境界。由於多媒體資料的傳輸及處理具有高運算量的特性，手機的體積又要越做越小，耗電量又要低，因此一個專為多媒體演算法及傳輸協定設計的低耗電整合式系統晶片（System-on- Chip, SoC）是手機及行動通訊設備的關鍵元件。而想要把複雜的數顆晶片整合到一顆系統晶片，最大的挑戰，除了硬體線路的整合，還包含了內嵌韌體的整合。以國外一流大廠的手機為例，最早的多媒體手機大概要用到十多顆晶片，而最新的手機大概只用到五、六顆晶片，最主要的關鍵，就是把不同網路的基頻晶片和應用處理器整合在一起。過去台灣工業界在 IC 元件設計方面算是具世界水準，但是對於高度整合系統晶片所需的複雜韌體的設計則較缺乏經驗。因此在系統設計上，有時甚至於會“棄軟從硬”，一些用韌體可達到的功能，反而用硬體線路來取代，這樣的做法，也許可以減少需要同時維護軟硬體的麻煩，但是卻阻礙了系統晶片的彈性和成長空間。 Audio interface Microphone ADC RF interface Analog baseband DSP ASIP Digital baseband GPP Receive Synthesizer Modulator Power antenna Display Keypad SIM Card Radio subsystem 圖一、二代手機架構傳統的二代手機包含了射頻模組、類比基頻模組、數位基頻模組、和耗電管控模組等等（圖一）。其中，數位基頻帶模組是負責語音編碼、容錯編碼、通訊協定處理、短訊服務處理、及使用者界面等工作。在架構上，一般是採用了双處理器核心的設計。也就是包含一個低效能嵌入式通用微處理器（GPP）核心加上一個訊號處理器（DSP）核心。其中 GPP 所執行的任務包含了 layer 2/3 通訊協定的處理、簡訊服務處理、人機界面、及簡單的手機作業系統等，而 DSP 所處理的工作包含 layer 1 通訊協定、語音壓縮解壓縮等等。這樣的架構應付傳統的語音通訊需求已經足夠，但卻不足以滿足多媒體通訊在效能上的要求。特別是如果把低耗電的要求再加上去，更是一個複雜的問題。為了在傳統手機架構上很快加入多媒體的功能，國外手機晶片大廠的做法是另外在系統中加入一顆應用程式處理器（Application Processor）（如圖二）。在這邊要特別強調的是，對多

(7)

媒體手機而言，應用程式處理器的存在只是一個過度時期的需求。如果我們仔細分析一下應用程式處理器的架構，其實跟（數位）基頻處理核心是十分接近的，除了有一個通用微處理器外，也常常包含一個 DSP 核心及一些多媒體加速邏輯。那麼，為什麼不乾脆擴充基頻處理核心的能力來取代掉應用程式處理器的功能呢？一開始的多媒體手機不這樣做，最主要的理由並不是硬體架構上難以達成這樣的目標，而是在韌體的整合上有其困難度。 Audio interface Microphone ADC RF interface Analog baseband DSP ASIP Digital GPP Receiver Synthesizer Modulator Power amp antenna Display Keypad SIM Card Radio subsystem Image sensor Multimedia Accelerator Processor cores bluetooth GPS transceiver receiver application processor 圖三、初期多媒體手機架構以現在的行動多媒體應用硬體架構而言，有以下的特點是過去嵌入式作業系統設計時所沒有考量到的。第一、現今的 GPP 核心（通常為 RISC 架構）效能比起早期的雙核基頻晶片的 GPP 核心要強多了，而且也常常內建一些訊號處理的加速指令，第二、新的嵌入式多媒體應用，常常要同時執行好幾個弱即時(soft real-time)的多媒體工作（包含視訊、音效、繪圖等等），因此，傳統上，針對單一時刻只執行單一耗計算量的工作的異質核心軟體分割方法 (software partition，如圖二)，常常在動態執行的狀況下不能達到最佳效能及工作分配(load balancing)，第三、多媒體應用的瓶頸往往是卡在記憶頻寬上，因此，新一代的嵌入式系統記憶體架構往往採用了異質分散式記憶體架構 (heterogeneous distributed memory blocks)，配合較有彈性的晶片內嵌元件的連結通道 (interconnect)，這也是在過去的作業系統的記憶體管控模組所沒有的設計。總結一下前面的討論，當嵌入式系統的設計越趨複雜，系統晶片的整合度越高，有效率的嵌入式系統和系統晶片的軟韌體開發將會是未來這個領域的技術重心所在。然而嵌入式軟體的開發並不能直接根據 PC 經驗而有樣學樣，必須根據新應用來思考新方向，特別是在嵌入式作業系統的設計上，不僅是要重新思考排程器 (scheduler) 和記憶體管控模組 (memory manager)的架構，甚至於應該重新設計程式設計模式，才能達到最佳效果。另外，在多媒體硬體加速架構方面，過去的業界習慣針對一個多媒體標準進行純硬體最佳化的設計。但是由於現在的數位多媒體的標準一直在演進中（如 video codec 從早期的 MPEG-1/2 到現在的 MPEG-4, H.264, 及 WMV 9，傳輸協定也會從早期的 MPEG-2 transport 慢慢往 IP network 的方向走，而 Java profiles 及 presentation scripting language 如 SMIL

等標準也一直在增訂中）。在過去採用純硬體佈線（hardwired）的方式設計系統的年代，升級到支援新標準的平台往往只能透過購買全新的硬體設備來達成。在未來服務導向的時代，這樣的設計只會增加使用者的負擔而阻礙新服務的推出，因此現在一個設計完善的多媒體平台一定要具有高度使用者擴充性。換句話說，當新服務推出時，使用者不需要購買一個新的設備，只要升級現有平台的韌體或可程式化邏輯元件就可達到享用新服務的目的。基於以上的理念，配合 MPEG 正在制訂中中的 Reconfigurable Video Coding (RVC) 標準，在 FPGA 的發展板上設計一個具擴充性的多媒體加速平台。這個平台的開發採用先進的軟硬體協同設計（hardware/software co-design）概念．以最少的硬體設備達到最大的應用軟體效能。並維持軟硬體的可擴充性。另外，Java 幾乎已經是嵌入式系統的應用程式的標準環境了。在手機上，Java 應用程式必須符合 CLDC/MIDP/KVM 的規範。由於早期手機的 Java 環境都是用內嵌式處理器來執行軟體 VM 模擬器，所以效能不彰，而使得應用程式的開發受限。雖然目前有一些 Java 加速器的設計，但在手機上除了 ARM 的 Java 副處理器之外，

(8)

都不算成功。我們在此計畫中，也花時間研究一個接近手機用 KVM 的公開硬體程式碼的 Java 處理器，並研究手機 Java 環境的效能加速法。

三、文獻探討

本計畫的總合成果主要有三大方向，首先是以可擴充的視訊加速平台、在異質雙核心平台上設計的動態分工排程作業系統、以及手機用的 Java Processor 的加速。關於這三個研究方向的文獻探討，請參見綜合報告之後的成果報告一、二、和三。

四、結果與討論

在可擴充的視訊加速平台的架構設計方面，我們是以能直接支援 MPEG 正在發展中的 RVC Framework 的技術為目標。在 RVC 的架構中，視訊編碼的工具（如 IDCT、VLC）是獨立掛在（軟體或硬體）平台上的一些 Functional Units。而這些 Functional Units 可以透過一個

table-driven 的 Finite State Machine (FSM) 來控制組成一個特定的 data path 來處理某一個視訊標準。如果這個 FSM 是以軟體實作，那個這個加速平台就可以做到動態重組成 H.264 或 MPEG-4 等不同視訊標準的功能。至於我們在這部份研究的詳細報告，請參見附錄一。另外，在異質雙核心平台上設計的動態分工排程作業系統的設計方面。我們特別設計了一個程序排程器，可以動態根據 RISC core 和 DSP core 的負荷，來決定要叫用那一個版本的執行碼（RISC 或 DSP）來完成工作。另外，在動態分工的應用上，我們除了完成了 MPEG-4 的 encoder 和 decoder ，另外也完成了 H.264 的 Intra encoder。關於這個異質雙核心平台的動態分工排程器的詳細報告，請參見附錄二。最後，在 Java 處理器的加速研究方面，我們設計利用硬體記錄了每一個 byte code 的執行次數，對重覆執行，而且需要做動態 resolution 的指令，進行 dynamic code optimization 的動作。根據實驗，這樣的系統設計，可以得到相當不錯的加速。這部份的詳細報告，請參見附錄三。

五、計劃成果自評

總合三年的成果，和原計畫提出的目標相當吻合。在達成預期目標情況方面有以下數點： 1. 多媒體雙核心系統中，在 TI OMAP OSK5912 平台上發展一套 Heterogeneous Multi-Processor (HMP) 的動態工作切割排程作業系統核心。在開發這個技術的過程中，我們有以下成果： I. 發展自己的 DSP scheduler 來幫助作 task 的排程。

II. Porting eCos 到 TI omap 平台

上，並開發雙核心有效的溝通協定。 III. 設計一個可以配合 eCos MLQ scheduler 的動態分工模組。 IV. 設計新的異質多核心的新 Programming model。 V. 實作出支援動態分工應用程式的開發工具。 2. 視訊編碼硬體加速平台上，實作出以下 IPs： I. Motion-estimation：計算到達到 1/4 pel ，參考多個 reference frames 以及所有 sub block 模式

II. H.264 deblocking filter III. MPEG4 IDCT

IV. H.264 transform/inverse

transform unit

V. H.264 quantizer and

de-quantizer

VI. H.264 intra predictor

(9)

發展中的 Reconfigurable Video Coding (RVC) 的架構為主要的設計目標，以期能支援不同視訊壓縮法的解碼器的動態產生。由於 RVC 為目前 MPEG 工作中的項目，所以目前的設計都是以軟體（C model 或其它 behavioral model 的模擬平台，如 Moses for

CAL 來進行研究）。本團隊因為積極參與 MPEG 標準的制訂，所以能隨時根據最新的結果來修正設計這個平台。

3. 實作出 Java Dynamic Code

Optimization for Java Processor 的軟硬體系統。

(10)

附錄一、可重組的視訊加速 SoC 平台

I. INTRODUCTION

Most multimedia devices today have to support multiple codec standards. Take

video codecs for example, a portable

multimedia player usually supports the playback of the MPEG-1/2, MPEG-4 SP, WMV, and H.264/MPEG-4 Part 10 video contents. In order to reduce system cost, a single-chip SoC solution that supports all these standards is a sensible approach. From IC designers’ point of view this is not a serious problem since most (if not all)

附錄二、異質多核心作業系統動態分工排程器

1. 簡介 在街頭上，隨處可見用手機在聊天談事情的人們；或是掛著耳機，利用 mp3 播放器在聆聽音樂的青少年；上班族也幾乎用 PDA 取代了以往紙本記事的習慣。如此廣大流行的手持式裝置，如今越來越擴展它的應用層面，例如手機支援百萬像素的拍照功能，使手機也有了數位相機的能力；3G 的影像電話功能，不只是對話，也能同時看到對方的表情，讓遠距溝通變得更生動；mp3 播放器的文字瀏覽，秀圖系統甚至影片播放功能，令單純聽音樂的 mp3 播放器提高其附加價值，搖身一變成為微形的數位娛樂中心；另外 PDA 的衛星定位導航功能，打破了我們一向認為 PDA 只不過是個可以帶著走的超小型桌上電腦的既有想法，發揮了在移動力上的特性。相信未來必定會推出更強大更高品質的應用，使得嵌入式系統的複雜度迅速地提升，相對的嵌入式系統的工作效能也必需提高。為了諸如此類眾多新的功能，以多媒體應用來說，嵌入式系統必需完成極大量的多媒體資料處理工作；換句話說，嵌入式系統要在相同甚至更短的時間內，處理更大量的資料，做更多的運算工作。提高嵌入式系統的能力是必要的。就過去電腦系統的發展史來看，提高系統的能力不外乎是提高處理器的能力為主，而處理器的能力就直接關係到它每秒可以運算的次數，每秒可以執行的計算量，亦即處理器的頻率。然而目前利用此一概念發展的單一核心嵌入式平台己不敷使用。考慮手持裝置的特性：輕巧以及移動力佳。嵌入式平台便有了體積上的限制，其中便影響到一個重要的耗電量的問題。體積上的考量，手持裝置無法配置大容量大體積的電池，同時顧及其移動的特性，也無法接受一再需要補充電力的要求。提高核心頻率會消耗大量電力，這一點會成為嵌入式平台的致命傷，再者，高核心頻率相伴而來的是產生許多的熱量，散熱方面也是一個難題。在現今市場上，整體行動裝置效能的提升不是利用提高核心頻率的方法，而是以增加核心數(處理器數量) 來平衡高核心頻率需求及大耗電量和高熱能產生的缺點。這種多個處理器的架構，我們稱之為多核心架構 (multiprocessor architecture)。事實上，異質多核心架構在嵌入式系統的發展己被業界廣泛地使用，例如德州儀器公司的 OMAP(Open Multimedia Application Platform)，以及 Freescale 的 MXC 。在非對稱式多核心系統晶片 (system-on-chip: SoC)架構裡，會有顆一般功能的處理器(general purpose processor: GPP)核心，做為嵌入式系統作業系統的控制核心，配上一顆數位訊號處理器(digital signal processor: DSP)核心。DSP 可以大量即時處理多媒體資料，如 MPEG 1、MPEG 2、MPEG 4 或是音訊資料等等。以德州儀

器公司的 OMAP 5912 OSK (OMAP

Starter Kit)為例 [1]，其 GPP 採用 ARM 公司 ARM926EJS，DSP 則是德儀自行研發的 TMS320C55X。研發人員可以依照資料處理的性質，將工作分配給 OMAP 架構微處理器中的 ARM 微處理器或者是 DSP 微處理器去處理。非對稱式多核心架構可有效率利的處理嵌入式系統上的工作 (task)，發揮系統的最大效能，特別是對於多媒體的應用程式有令人亮眼的表現。現存的即時作業系統 (real-time operating system)對於非對稱式多核心架構大部份是採用靜態式分工 (statically partitioned)的方法。所謂靜態式分工方法是系統設計時研發人員就做好工作的分配，屬於控制流程的工作就交由 GPP 執行，屬於多媒體運算處理的工作多交由 DSP 執行。在這種分工架構之下，有兩個不同的 schedulers 為兩顆核心獨立運行已分配好的工作。換句話說，兩顆核心各自處理已分配好份內的工作，完成之後，在下一個工作來臨之前是閒置的狀態，因為

(17)

在獨立的視野裡，已是最好的效能發揮。這類型的分工方式在傳統行動通訊平台及應用程式環境下是相當有效的法。過去常用的 GPP 核心在特殊工作處理的功能性和速度都有所不足，意即 GPP 沒辦法勝任 DSP 的工作。並且過去的嵌入式應用程式環境通常是單純的前景/背景(foreground/ background)工作模式，所以不需用到複雜的動態排程。但是新一代多媒體應用會拓展到更寬廣的層面，再加上硬體裝置上有了新的提升。首先，多媒體應用程式已經複雜到一個境界，為了提升系統效能和減低能量的消耗，必需用動態調整兩顆核心的工作量取代系統設計時做好的工作分配。其次是 GPP 的能力已被大幅提高，可以幾乎和 DSP 等速地處理某些多媒體資料，換句話說，在這些情況下，GPP 可以用來分擔 DSP 的工作負載。接著是多媒體應用程式在記憶體和計算量的需求己經大大超越過往，多媒體資料經常會被包裝成運輸串流 (transport stream)，往返於兩顆核心之間，但是在執行時核心之間溝通的成本並非固定，譬如傳輸時電力的消耗與總電量的關係、工作有沒有完成時間的限制(deadline) 等……，有太多因素要考量，是不可能在系統設計時就預測到並且做好資料傳輸的設定。著眼於系統效能，靜態式分工系統設計不再合適，即時作業系統排程器在設計上要有新的突破。考慮以上種種原因，我們便提出一種新的動態精細分工式(tightly-coupled)作業系統排程器[21]，[22]，這種新的排程法會由單一排程器監控各顆異質核心的工作狀態，並能動態地分配工作給當下最合適的處理器核心。排程視野的廣度上，由系統設計時就定好的靜態工作分配延伸到執行時的動態分配；而深度上，考量整個系統即時的狀況，做出最適當的工作分配並減少微處理器的閒置浪費，取得比靜態式分工系統更大的效能發揮。 2. 相關研究 這一章將會介紹此領域的相關研究。依順會介紹多核心平台著名的排程演算法，對稱多核心平台及非對稱式多核心平台，非對稱式多核心平台系統的排程，動態排程，共享資源的控制，非對稱式系統晶片 SoC，和靜態式分工系統。 2.1 多核心平台排程演算法 多核心處理器架構排程器的研究越來越受到重視。過去十多年來，在實用上，多核心排程演算法的發展重點是放在對稱式多核心系統 (symmetric multiprocessor system)上。多核心排程技巧在同質多核心平台部份可以被分成兩類， partition

scheduling 和 global scheduling[23] 。

Partition scheduling 是指每一個核心有自己的工作駐列(task queue)，包括 ready 駐列和 wait 駐列。工作排程的考慮會以各自區域的 priority 為主，與其他處理器獨立。每一個工作一旦被分配到一個處理器，在其生命週期內都不會移到別的處理器。 Global scheduling 則是將所有準備完成的工作放在一個共同的 priority 駐列。最高 priority 的工作會被挑選放到一個工作量較低的處理器執行。這種 scheduling 模式在同質多核心的系統上表現較前者佳。以下簡單列出一些常用的多核心排程演算法[3]:  Rate monotonic：每一個週期性的工作有固定的 priority，priority 的順序是根據該工作的執行頻率高低而定，例如要等待 interrupt 的工作，其 priority 相對較低。在 1973 年，Liu 和 Laylan 證明這個演算法是固定 priority 演算法中最理想的一種。

 Earliest Deadline First：這種演算法可將週期性和非週期性的工作一起排程，主要概念是越早結束的工作越先執行。M. L. Dertouzos 在 1974 年證實當瞬間有許多工作等待執行時，此演算法是最有效率的。  Deadline Monotonic： D.M.結合上述兩種演算-- priority的給定除了根據該工作的執行頻率外，另外會再考慮 deadline 越早，priority 越高。  Background Scheduling：此種演算法同時處理 soft real-time aperiodic task

(18)

和 hard real-time periodic task。兩種型式的工作分別置入兩個不同的駐列。此演算法實用上雖沒有很高的利用性，但其優點在於實作很簡單。  Pooling Server： P.S.可處理非週期性的工作。每個時間區塊一過，server 便服務下一個時間區塊可以執行的工作。若沒有工作在等待被執行，則會閒置 server，等到下一個時間間隔再甦醒。  Deferrable Server：此演算法類似上一個，但是若下一個時間區塊沒有等待被執行的工作，則 server 服務可能被服務的工作，而不是閒置 sever。  Sporadic Server： S.S.使用於非週期性工作，可以增進其反應時間，使得非週性工作的效能追上週期性工作的效能。

 Dynamic Sporadic Server：這個演算法利用 deadline 調整 priority，增進 Sporadic Server 的效能。

 Robust Earliest Deadline：這是 1995 年 Buttazzo 和 Stankovic 發展的演算法，作用於 over loading 環境中的非週期性工作。此演算法不只可以減少 deadline 預測錯誤，也可降低系統 over loading 的程度。

 Constant Bandwidth Server：這是在 1998 年 Buttazzo 和 Abeni 發展的演算法，用來解決即時多媒體應用的問題。例如在串流影音的系統中，對串流資料的傳輸和處理的 delay 和 jitter，必須要控制在一定的範圍內。  Adaptative Bandwidth Reservation ： Abeni 和 Buttazzo 在 1999 年提出對 constant bandwidth server 的改良。對於執行時間未知的工作所能分配到的處理器的頻寬可以經由 Adaptative Bandwidth Reservation 來控制。在這裡，頻寬(bandwidth)一詞指的是處理器分配給工作的時間或是工作被執行的週期。 2.2 對稱式多核心平台與非對稱式多 核心平台 前面提到目前實用上多核心作業系統的排程演算法大部份都是以對稱式的多核心平台為目標，比方說，Satoshi Kaneko et al 在 2004 提出的一個多核心平台[4]。這個 600MHz 單晶片多核心平台包括兩個 M32R 32-bit CPU 核心，一個 512-KB 共用的 SRAM，和一個內部分享的 pipeline bus。

這個平台是由 0.15um CMOS 製程製造，適用於嵌入式系統。此多核心平台是對稱式的多程序處理平台，並且支援 modified-exclusive-shared-invalid (MESI) 的快取統一協定。該系統繼承了先前單晶片多核心平台的諸項優點，並針對嵌入式處理器做了最佳化，以使得系統效能增加的同時也能減低電力的消耗。為了增加核心的效能，他們在平台內部置入一個共享的 pipeline bus。此 bus 的特性是低延遲和每秒 4.8 G-bit 的大頻寬。此外也用多個低耗電技術，例如擁有不同使用電力的模型選擇: 睡眠模式、工作模式、和等待模式。不同系統情況下，不同核心甚至週邊有不同的模式選擇，以達到最高的省電約 18.4%。使得此多核心平台在 600MHz 1.5V 之下功作僅消耗 800 mW，待機時更只耗 1.5mW。有些應用，如 3G 通訊和嵌入式多媒體應用，會同時執行控制的工作和大量資料處理的工作。一般實作上，為了逹到最佳的性能／秏電量比值，異質多核心 (Heterogeneous Multi-Processor)的架構是一般業界常用的設計方法[1], [13]。例如飛利浦半導體部門發展了一套 Silicon System Platform (SSP)。SSP 是零件的工具箱，是一種一般性、開放性和可程式化的架構。主要用來產生有軟體和硬體 IP blocks 的特定應用產品領域。過往研發新產品，可能必需打造整個新平台架構，付多相當的成本花費。利用 SSP 概念，為新應用產品而修改的架構會比試著去產生整個新架構更有實作的效率。使用 SSP 設計產品的速度很快而且技術風險低，因為架構中軟體硬體的功能性己經驗證過，而且還可以結合其他工作元件更容易達到設計的目標。同時其中有很大的空間讓設計團隊創造不同市場需求的產品；一系列的產品由入門到進階的產品，只需在平台上增

(19)

減功能區塊，就可有效地減少開發時間及成本花費。日後使用者甚至可以隨著更新軟體的版本來增強或增加產品的功能性。飛利浦的 Nexperia 平台是一個單晶片系統的 SSP，用來開發數位視訊產品。Nexperia 平台上主要包括 MIPS 處理器和飛利浦的 TriMedia VLIW 媒體處理器，及其他 IP 元件。結合 MIPS 及 TriMedia 兩種不同的計算核心，整合成單晶片系統。飛利浦利用此平台創造出多功能的機上盒，它可以即時解碼多個視訊串流、執行數位錄製、壓製訊號用於視訊電話、瀏覽網站和收發電子郵件等多項功能。其他如德州儀器(TI), 飛思卡爾(Freescale)和 Toshiba 等知名大廠都有自己的異質多核心平台，本論文在 TI OMAP 上實作，稍後章節將會詳細介紹 OMAP 平台。在軟體的開發過程中，軟體測試是很重要而且很昂貴的一部份。有一種軟體測試的方法稱之為資料流測試(Data Flow Testing)，使用資料流測試可以決定一個軟體的測試是否充份且完整。Harrold 提出一個新的方法把整個資料流測試工作量切割成適當的大小[5]。這些測試的工作量可以靜態地也可以動態地接受排程。也可以改變成適合共用式記憶體或分散式記憶體的環境。在[5]中把資料流測試演算法實作出單一核心平台的版本和多核心平台的版本，並根據大量的軟體實驗來驗證資料流演算法的正確性。另外，這些實驗也可證實多核心平台的效能優於單核心平台。平均效能上多核心平台比單核心平台加速 1.7 倍。 Annavaram 等人討論過非對稱式多核心系統的效能優於對稱式多核心系統的看法[6]。激發此篇論文的研究動機有下例三點：首先，單晶片多核心平台上 CPU 核心的數目增加，同時間可以執行的運算量上升。第二，可以利用單晶片多核心架構優點的多執行緒軟體變得更流行。因為演算法的性質，這些多執行緒程式被分階段連續的執行。然而Amdahl’slaw指出平行化程式的加速將會被計算的連續部份限制。第三，不斷增加的晶片整合層級和逐步降低使用的電壓結合使得如何減少電量的耗損成為首要注重的設計限制。此論文的目標是最小化多執行緒程式的執行時間。該執行緒包含平行處理和連續處理的階段，同時也保要有多核心單晶片的電力消耗限制。為了減少 Amdahl’s law 影響，在論文中對於電量花費的計算是根據可獲得的平行度來決定處理的指令數，並以這些指令花費的電量為準。使用該等式，電力 = 每個指令的能量(Energy per Instruction: EPI) * 每秒指令數(Instructions per second: IPS)。假設電力固定的情況下，因此限制平行量的多核心單晶片是低 IPS，會花較多的 EPI。相反地，高平行量時，會花較少的 EPI。根據[6]的實驗，在相同的耗電量前題下，一個複雜的系統在使用非對稱式多核心、多執行緒執行時，會比對稱式多核心系統增加百分之三十八的效能。隨著近年來多媒體裝置的流行，多執行緒平台研究關注的焦點已由對稱式多核心系統轉移到非對稱式多核心系統。非對稱式多核心系統比對稱式多核心系統有更佳的效能/時脈比，因此在多不同工作執行時非對稱式多核心系統更適合嵌入式裝置。 2.3 同質多核心平台系統下的非對稱 式排程 前面提過，異質多核心平台在處理通訊及多媒體相關工作時可以得到最佳的效能/時脈比，但目前並沒有論文是針對異質多核心平台探討動態自動排程的設計。不過倒是有不少論文是針對同質多核心平台研究非對稱式動態自動排程的可行性。 Wendorf 等人提出多個工作分配和排程方法[7]，範圍由非對稱 master/slave 排程到對稱式排程。他們在許多情況下測試這些分配和排程方法。對於非對稱系統，結果顯示 OS Preempt 策略幾乎在所有的清況下都有最高的效能。作業系統的工作的 priority 相對高於一般應用程式，而在兩者有相同 priority 時，作業系統的工作可以較優先得到處理器的使用權，稱之為 OS Preempt。相對於其他策略 OS Preempt 可以減少時間耗損百分之三十到百分之六十。在許多測試情況下非對稱的系統和對

(20)

稱式的系統幾乎有一樣的效能，甚至前者有優於後者的情況。重要的是，在對稱式系統中，作業系統工作因 functionality partition 仍需在全部可以使用的處理器中選擇執行者，相較之下非對稱式系統指定單一處理器微理作業系統工作，更容易實作。結果也指出，在不同工作分配和排程演算法下，process switch overhead 和多處理器之間的對於分享資源的競爭是決定系統效能的因素中相對較不重要的。

Greenberg 提出了一個簡單的

master-slave 架構[8]。在一些電腦作業系統下，一個程序(process)可以在 user mode 或是 system mode 的模式下執行。一個 user mode 的程序可以在執行中進行一個系統呼叫(system call)變成 system mode。這個程序在結束這些呼叫後便回到 user mode。在 master-slave 的多核心架構下，系統呼叫如 kernel call 只可以在 master 核心執行，剩下的呼叫就被視為如 user call，和其它工作一樣可以在 master 核心或 slave 核心執行。當 slave 核心上的 user mode 程序欲使用 kernel call，slave 核心會將該程序交給 master 核心處理，而非由 slave 核心處理。在 Greenberg 提出的設計中，工作會先在兩個駐列等待。一個駐列稱為 master 駐列，另一個則稱為 slave 駐列。Master 駐列的工作都是在系統模式，而 salve 駐列上的工作都是在使用者模式。如前所述 master 駐列是只在 master 核心執行的駐列，slave 駐列卻是可在 master 核心或 salve 核心執行。此論文利用兩種簡單又實作的排程演算法來平衡排程的彈性和 queue-switching 的成本花費。最後並提出一個分析公式，用來測量硬體和 work load 參數，同時考量 master-slave 系統的電力和限制，並進而尋找到非對稱式多核心系統中最佳 slave 核心的數量。 2.4 動態式分工及排程 許多對時間有嚴格要求的應用都需要動態排程方能達到預定的效能。 Manimaran 等人把一個系統的效能定義為該系統能在 deadline 之前完成的工作所佔的百分比[9]。在這篇論文中，他們提出在多核心系統上使用的一種演算法，可以動態地對可執行的即時工作進行排程，並具有容錯的功能。系統的運作是基於以下兩個限制條件: 一、每一個工作一旦分配給處理器以後，是不會被打斷的 (non-preemptive)。二、每個工作有兩種版本，這個假設是用來改善處理器錯誤的問題並可以得到較高的效能。系統的內有 N 個處理器和 N+1 個駐列，其中包含了 N 個 local 駐列和一個 global 駐列。每一個處理器和一個 local 駐列為一個組合。排程器自 global 駐列中取得最高 priority 的工作，動態地依系統狀態和各個處理器的狀態，決定將置入哪一個 local 駐列。提出的演算法有下列三個技巧: 1)距離概念：決定 task 駐列中兩個工作版本的相對位置。 2)彈性的系統復原：在效能和容錯等級的取捨。 3) 資源的回收：回收被判定為 deadlock 的工作和己完成的工作所分配到的資源。利用動態排程方法和上述技巧系統的效能和容錯性達成應用上時間的限制。 Avritzer 等人發展出一個效能分析模組[10]。該模組對使用 load sharing 演算法的高度非對稱系統做效能的評估。load sharing 演算法是基於全系統的狀態進行排程工作。load sharing 演算法有兩種實作的層級，第一種層級在作業系統內部，稱為 kernel 層級或 shell 層級。第二種層級為使用者層級，在 shell 的前端。前者雖有效率上的優點，但是異質機器之間的相容性使得實作上十分困難。雖然後者的 overhead 比前者大，但有三個理由令此論文決定使用後者實作。第一、不必考慮異質機器的相容性，容易實作。第二、對機器和使用者 load sharing 會透明化。第三、使用者利用 shell 前端控制可以決定要不要加入負載分享的機制當中。 Load sharing 的主心概念是要儘可能

(21)

縮短整個系統的反應時間，執行方法是把工作分配給利用率低的機器。動態的 load sharing 可分成由傳送者初始化的型態和由接收者初始化的型態兩種。傳送者初始化的型態使用時機是系統負載不高時，接收者初始化的型態是系統呈現高負載時使用。此論文提出了一個分界型(threshold type)的 load sharing 演算法，此演算法會隨著某些分界值的變動而調整最適當的工作參數，例如每個機器上的工作數量。實作上該演算法的模型是建立以全系統為視野的全系統狀態馬克夫鏈和並計算出能在最差狀況下逹到最小 latency 的系統。此論文的結論指出在非對稱式的環境下，小心地動態調整 load sharing 的演算法，會比靜態設定 load sharing 的演算法的效能有大幅增進。 2.5 共享資源控制 Majumdar 提到多核心系統上程序之間會有競爭分享的資源[11]，例如變數就會儲存在分享記憶體上。保持資料一致性的機制不可缺少，如此才能確保系統的正確性。可是這種機制又通常會降低系統效能。這篇論文研究以多核心平台為基礎的應用程式為對象，如電話交換器和即時資料庫，控制分享資源的競爭以達到高度 throughput 及高度 scalability。將己存在的程式改成 re-entrance 或是將程序做適當的排程是兩種可實行的控制記憶體競爭方法。此論文著重於第二種方法。對數種控制資源競爭的排程演算法量化其結果，可以了解系統內部的行為和每一種演算法最重要的特性。結合數種排程演算法的特性的優點，衍生出混合式的控制資源競爭排程演算法： Hybrid-K。Hybrid-K 可以把所有程序執行時間縮短為依序執行每個程序所花費執行時間的 1/K。參數 K 代表系統增加的處理器數目。因此增進的效能會依 K 的增加而上升。然而需要注意的一點是實驗使用的處理器數目最大只到 10，因此 K 大於 10 的情況尚待驗證。 Saewong 等人指出如何安排同時存取多個資源[12]，這是眾所皆知的一個 NP complete 的問題。在分散式即時系統之中，通常都是用 Decoupling 的方法來管理點對點延遲的系統。不幸地，當利用單獨的核心來管理多個資源時，Decoupling 的方法就會失敗。利用單獨核心管理資源方式的優點是可以減少衝突以全系統的觀點來分配資源的使用。例如控制核心可以利用裝置驅動程式、檔案系統或協定服務 (protocol service)來控制相關的資源。控制核心我們稱之為 host 核心。Host 核心具有兩個角色：其一，host 核心如一般的核心可執行應用程式。其二，host 核心可以控制和管理其他 time-shared 的資源。此論文研究協同排程的控制和受控制資源的問題，提出合作排程伺服器 (Cooperative Scheduling Server :CSS)。 CSS 是一個專用的伺服器，利用固定的一個處理器來控制眾多可以分享的資源，例如：磁碟機和程序之間的溝通。下列兩個概念是 CSS 的目標基礎。首先，在一個控制器上(如 CPU)先執行一個非週期性的伺服器，該伺服器可以處理所有局部資源的使用要求。這表示 conjunctive admission control 是在控制端和受控制端一起實行的。接著，在應用程式層級的時間限制被分割進入多個階段，每一個階段都會被保證在一個特定的資源上完成。 Real time file system (RTFS)是一個即時的檔案系統，它可以提供在 CPU 低負載時，對磁碟頻寬的保證。有了 file system CSS (FSCSS) ，磁碟頻寬的保證也可以在高 CPU 負載和高磁碟工作量下達成。以下列出協同排程演算法設計需要考慮到的因素。第一、資源異質性產生的排程失誤問題。依受控資源的觀點，host 核心必須確保這些資源相對活動不能被其他更高 priority 的活動過份地延遲。依 CPU 的觀點，native CPU application 又必須保有完成的時間限制。因此會有 confliction 和

scheduling miss 。第二、 conjunctive

admission control；每一個受控制資源的 admission control 必須不只是考慮自己擁有資源的存取，還有 host 核心的可獲得性。因此，要保證即時的服務，協同排程的允許控策略需要搭配資源存取資料的反應時間和處理器排程器去分配 CSS 程序的反應時間。第三、分享資源的同步問題。資源的存取可以平行化處理。資源和 host

(22)

核心做好同步，可以允許每個資源達到最大平行化。第四、有效的資源利用。即時排程的主要目標是達到高利用率和對於應用程式的 deadline 保證。因此，除了保證多資源存取的 deadline 之外，系統應該提供整個系統資源的高利用率。 2.6 靜態式分工 一般的異質雙核心系統架構(比如由 Ferrari 等人提出的 The Janus system[14]，是由一個一般功能處理器和一個特殊功能處理器所組成。這兩個運算單元共同使用一個公用匯流排(bus)，而且可以自由地使用 RAM 和 ROM 等記憶體。而其他週邊輸出輸入設備則由一般功能處理器控制。通常這兩顆處理器是建構在單一晶片上，可以完全分享整個架構上的記憶體空間，也可以將處理器之間的溝通所需的成本忽略成極小。如此的設計通常會將一般功能處理器視為 master 處理器，而特殊功能處理器便視為 DSP。然而這些系統大多是設計成靜態式分工的方法。Gai 等人曾討論由 GPP 和 DSP 非對稱架構多核心排程的問題[15]。在這篇論文中，DSP 被當成是類似有計算能力的資源，在 DSP 上執行的工作，都是由 GPP 一次一個分配過去。等到 DSP 完成工作，再回到 GPP 繼續下一個工作。如此設計是因為 DSP 對某些工作的能力比 GPP 有效率很多，DSP 在這些工作上所省下的時間和單獨由 GPP 執行整個工作所花的時間相較，會大於 GPP 的閒置和兩個核心的溝通所需的時間。這種方式的實作方法是由兩個 task 駐列來完成。一個是 GPP 駐列，存放一般的工作，並由 GPP 負責執行。另一個則是 DSP 駐列，存放給 DSP 執行的工作。當 DSP 閒置時即是可以接受新工作，排程器選擇在這兩個駐列的頂端有最高 priority 的工作。若是選擇到 GPP 駐列，就由 GPP 來執行工作，反之 GPP 便將 DSP 駐列上的工作傳給 DSP 執行。而當 DSP 正在工作，排程器只選擇 GPP 駐列上最高 priority 的工作交由 GPP 執行。由過去的研究顯示，非對稱式多核心平台的優點及可行性十分明顯，而且同一個工作如果能動態根據不同核心來排程，也會大大提昇效能。下一章，我們將提出精細分工的工作模型和相關背景。 3. 理論與實作背景 我們以動態精細分工工作模型為概念，實作出非對稱式異質多核心平台排程器。所謂動態精細分工系統和目前廣為使用的靜態式分工(statically partitioned)系統是相對的。在靜態式分工系統中，一項工作會分配到哪一個處理器是在系統設計時就決定好的。為了提高整體系統的效能，我們提出了動態精細分工工作模式。假設在系統平台上有兩個處理器核心，分別是 GPP 核心以及 DSP 核心。新的工作被執行前，在 GPP 上的排程器將監看每個處理器核心的執行時期狀態，和決定哪一個核心較適合執行該工作，再動態地分配給 GPP 或 DSP 執行，減少處理器核心閒置的時間，提高處理器核心利用率，進而縮短全部工作執行時間，增加整個系統平台的效能，這種工作模式我們稱之為精細分工工作模型。本篇論文提出的排程器是實作於 OMAP5912 OSK 平台上，使用的作業系統在 ARM 處理器核心部分是以 eCos 2.0 版本為基礎進行修改，在 DSP 處理器核心的排程核心是由我們自行設計的。在本章中，我們會介紹 OMAP 5912 應用處理器 (OMAP 5912 Application Processor)和 OMAP 59120 發展板(OMAP 5912 Starter Kit: OSK 5912) ，以及嵌入式作業系統 eCos 2.0 版本。過去，本驗室也曾開發過在 Linux 下利用 DSP Gateway 及 TI 發展的 DSP/BIOS 排程器[21]。根據過去的實驗結果，利用 DSP Gateway 的溝通機制成本太高，每秒傳輸只有 3 MBytes，不合乎精細分工系統的需求，因此我們在本論文中改用較為精簡的 eCos 作業系統，並提出有效率的 mailbox 和 shared memory 的溝通機制，以證實精細分工系統可以得較高的效能。所有 eCos 移植到 5912 OSK 的過程將在下一章說明。本論文研究實作的細節會在第五章詳細介紹。

(23)

3.1 OMAP 5912 Application Processor

OMAP5912 應用處理器是一塊高度整合的 SoC ，包括的重要元件有 : GPP-ARM 核心、DSP 核心、和 Traffic controller 等等。OSK 5912 為使用 OMAP 5912 應用處理器的發展平台。 OMAP5912 應用處器整合 ARM 926 EJ-S RISC 核心和 TI TMS320C55x DSP 核心。ARM9 RISC 核心在嵌入式系統被廣為使用，C55x DSP 核心對於數位訊號處理展現高效能和低耗電的特性。因此 OMAP5912 應用處理器適合多媒體嵌入式裝置，經由切割每個應用程式為眾多工作和適切地分配工作給兩個處理器核心執行可以有優秀的效能表現。 Fig. 6 為 OMAP 5912 功能區塊圖

[1] 。 MPU(ARM9) 、 MPU peripheral

bridge 、 Memory traffic controller 以及 system DMA 四者透過 MPU BUS 溝通。 MPU 由 MPU bridge 透過 public/ private peripheral bus 和其週邊溝通。DSP 透過

public/ private peripheral bus 和其

peripheral 溝通。此外 DSP 可藉由 DSP MMU 或是 MPU Interface 和系統其他部份做溝通。

Fig. 6. OMAP 5912 功能區塊圖

OMAP5912 應用處理器 DSP 的記憶體包括內部記憶體 DARAM 和 SARAM。 ARM 定義一個 word 等於 4 個 byte，採 byte addressing，所有週邊和擴充的 memory 以及 control register 都由 32 位元來定位。DSP 定義一個 word 等於 2 個 byte，是採 word addressing。當 ARM 對應一塊實體記憶體到 DSP 的記憶體空間，DSP 可以透過 DSP MMU 來存取該塊記憶體，同時在 ARM 的虛擬記憶中有一塊配置為 DSP 記憶體空間，也會被對應到該塊實體記憶體。在 OMAP5912 應用處理器上 Memory traffic controller 是一個很重要的內外部記憶體存取元件。Memory traffic controller 可以令 DSP 和 ARM 利用 TI OCP (Open Core Protocol)存取內部共用記憶體或週邊裝置，存取外部記憶體可利用兩種高速記憶介面來完成，分別為 External Memory Interface Fast(EMIFF)和 External Memory Interface Slow(EMIFS)。 EMIFF 相較 EMIFS 是較快速的記憶體裝置，在 OSK 5912 發展板上對應 EMIFF 配置的記憶體是 SDRAM，最大可支援到 64 M Bytes。存取資料的寬度和位址的寬度都是 16 bits，也提供了兩個 bank 選擇位元，亦即可以將 SDRAM 分成四個區域來使用。使用者的應用程式預設是諸存到此 SDRAM。 EMIFS 所連接的外部裝置記憶是 NOR FLASH。透過介面可以 8 bits / 16 bits / 32bits 的寬度在每個 NOR FLASH 晶片上存取資料，其使用的位址寬度為 25 bits。 OSK 5912 發展板上共有四塊外部 FLASH 晶片，每塊晶片最大容量為 64 M Bytes，所以可使用的總記憶體容量為 128 M Bytes。此四塊 NOR FLASH 分別為 CS0, CS1, CS2, 和 CS3。Boot ROM 位於 CS0，系統開發者設計的 boot-loader 或作業系統則是存放在 CS3。經過設定，啟動的模式可以利用 CS0 的 boot ROM 或是 CS3 的 boot-loader 開機。

3.2 OMAP 5912 Starter Kit：OSK 5912 (OMAP 5912 OSK) OSK 5912 是對軟體和硬體做高度整合的平台，主要可做為視訊圖片訊號處理裝置和行動溝通裝置。可以使用一般的嵌入式作業系統做為 OSK 5912 上 ARM 處理器的作業系統，而 TI 提供 DSP/BIOS 做為 DSP 處理器的即時核心 (real-time kernel)。Fig. 7 為 OSK 5912 正視圖[19]：

(24)

Fig. 7. OSK 5912 正視圖 Hardware Features 如下：  ARM 926EJS 處理器核心運行於頻率 192 MHz。  Texas Instruments TMS320C55x 運行於頻率 192 MHz。  內建音訊編碼解碼器 TLV320AIC23 codec

 64 Mega Bytes DDR RAM

 256 Mega Bytes on board Flash ROM  10 MBPS Ethernet port

 On board IEEE 1149.1 JTAG connector for optional emulation

 Software Features 如下：

 Compatible with MontaVista's Linux for OSK5912

 Compatible with OMAP Code

Composer Studio from Texas

Instruments 3.3 eCos OSK 5912 所採用的原始作業系統是 MontaVista Linux，但是根據我們去年的經驗，Linux 配合 DSP Gateway 的效能表現無法達到精細分工系統所需的要求，故本論文沒有採用原始發展系統所採用的整合軟體。接下來介紹 ARM 端採用的 eCos 作業系統。在下一章我們會討論如何將 eCos 移植到 OSK5912 的平台下。 3.4 eCos Overview eCos 是一個開放程式碼，可設定 (configurable)，可移植和免費的嵌入式即時作業系統。eCos 的一項重大的技術革新是設定系統(configuration system)。設定系統允許應用程式設計者對 run time 元件加入或調整所需的功能和實作方式。傳統上，作業系統會限制實作的方法，無法選擇。設定系統使得 eCos 開發者創造符合特定應用程式的特定作業系統，也使得 eCos 適合更大範圍的嵌入式應用。設定系統的使用可以保證資源的最小化，和其他不需要的功能和特徵都可以被移除。如此便利性的因素是 eCos 它是一個元件架構的系統。eCos 被設計為可以移植到許多目標架構和目標平台，包括 16 32 64 位元架構和 MPU, MCU, DSP。eCos 支援許多不同平台架構，如 ARM、Intel StrongARM 及 XScale、Fujitsu FR-V、Hitachi SH2/3/4、 Hitachi H8/300H 、 Intel x86 、 MIPS 、 Matsushita AM3x 、 Motorola PowerPC 、 Motorola 68k/Coldfire、NEC V850 和 Sun SPARC，其他尚包括許多流行的架構和發展板。 3.5 Configure Tool 嵌入式系統正被推動朝著更小更快更便宜更精緻，所以更需方便地控制系統內所有的軟體。有不同的方法可以控制應用程式內元件的特性。eCos 元件控制的哲學是為了減少系統大小，對資源最自由的配置。持著此設計哲學，最小化的系統不必支援某些複雜系統上才有的強大功能。有一種在 run time 控制軟體元件的方法，例如動態連結程式庫 (Dynamic Link Libraries)，不必預先對元計做設定，但是這個方法會會導致程式大小增加。另一種方法是在 link time 時，當需要某個特殊功能元件就會被包入，反之則除去，例如 GNU linker。這方法的特性是擁有某元件的全部功能或都不擁有。Compile time 的元件控制，使得系統開發者可以建立特定應用程式需要的元件，可以保持所有的程式碼都是系統所需要的。對於嵌入式系統來說，這是解決程式碼多寡的好方法。eCos 有一套十分方便的 configure tool，讓系統開發者在 compile time 決定所需的元件和元件的能力，而不必動手修改元件的程式本體。 3.6 Component 要了解 eCos，則了解元件的基礎架構非常重要。元件基礎架構專為滿足嵌入式系統和嵌入式設計的相關需求而存在。設計的 eCos 元件基礎架構可以控制元件達