國
立
交
通
大
學
電機學院與資訊學院 資訊學程
碩
士
論
文
嵌入式系統開發之挑戰
以一數位照片儲存盒衍生至數位音樂儲存盒產品
為例
Challenges of the Embedded System
A Case Study of Music-Bank Evolve from Photo-Bank
研 究 生：顧夢澄
指導教授：張瑞川 教授
嵌入式系統開發之挑戰
以一數位照片儲存盒衍生至數位音樂儲存盒產品為例
Challenges of the Embedded System
A Case Study of Music-Bank Evolve from Photo-Bank
研 究 生: 顧 夢 澄 Student : Meng-Cheng Ku
指導教授: 張 瑞 川 Advisor : Reui-Chuan Chang
國 立 交 通 大 學
電機學院與資訊學院專班 資訊學程
碩 士 論 文
A Thesis
Submitted to Degree Program of Electrical Engineering and Computer Science College of Computer Science
National Chiao Tung University in Partial Fulfillment of the Requirements
for the Degree of Master of Science
in
Computer Science June 2006
Hsinchu, Taiwan, Republic of China
嵌入式系統開發之挑戰
以一數位照片儲存盒衍生至數位音樂儲存盒產品為例
學生: 顧夢澄 指導教授: 張瑞川教授
國立交通大學電機資訊學院資訊學程
論 文 摘 要
嵌入式系統(Embedded System)產品種類豐富，由早先單一應用功能發展至今 成為多樣應用功能，致使產品設計的複雜度快速增加，如果是從事消費性電子產 品的設計，則消費性電子產品通常具有產品週期短及為求其新穎性產品更新快速 的特性，所以產品設計的時程大都被嚴重的壓縮；近年來拜 ASIC 在製程上的長足 進展，使得嵌入式系統可以大量應用 SoC(System-On-Chip)之技術進行產品開發， 現今 SoC 的 IC 設計廠商在開發嵌入式系統晶片時能在有限的產品設計期間內， 針對產品市場需求規格，選擇適當的軟硬體開發策略，以致於能在產品開發階段 迅速且確實的開發新產品，最後達成產品及時上市之目標；所以能夠精準的掌握 整個 SoC 產品開發時程為其必須要具備的競爭能力。 本 論 文 就 以 一 數 位 照 片 儲 存 盒 (Photo-Bank) 衍 生 至 數 位 音 樂 儲 存 盒 (Music-Bank)產品為例，說明將已量的數位照片儲存盒，為增添下一代產品的新穎 性而在原產品中增加 MP3 數位音樂播放功能，而開發名為數位音樂儲存盒的衍生 性產品，文中將探討在衍生性產品在產品概念發展及規劃階段所面臨的挑戰，然 後將經由所提出之評估的指標及方法進行開發策略的評估流程，透過評估流程決 定對數位音樂儲存盒的開發策略，同時也提出測試及確認策略正確性的方法，其 最主要的目標就是要縮短開發時間然後達到即時上市(TTM-Time To Market)的目 的，最後也提出在縮短 SoC 產品開發時間，日後可以持續研究的方向。Challenges of the Embedded System
A Case Study of Music-Bank Evolve from Photo-Bank
Student : Dream Ku Advisors : Reui-Chuan Chang
Institute of Computer and Information Science National Chiao Tung University
Abstract
There comes a variety of embedded systems in the market. From signal function in early days to multiple functions today, the design complexity of the embedded system is increasing rapidly. If the embedded system is a consumer product then the product life cycle will be short. The next generation product emerges to the market in a very short period due to keep the fresh of a consumer product. Therefore, the product developing cycle of a consumer electronic product is squeezed seriously. For the sake of the progress of ASIC process, the SOC technologies are widely used in embedded products. How to develop a product in a limited developing cycle is required by an IC design company of consumer electronic product. It should be able to make a proper decision of product developing strategy for the software and hardware in order to have product TTM. The decision of product developing strategy is made by a well-defined evaluation process dependent on the resources of existed IPs and others from a previous product. The IC design company should have the capability to overcome issues encountered during the concept and plan phase of product developing life cycle.
This thesis will use a case study of evolved product from Photo-Bank to Music-Bank to deploy these challenges of an evolved product. The first generation product named Photo-Bank is required by the market to value-added a function of MP3 player function as a evolved product named Music-Bank. It will explore the challenges on the product developing life cycle of the evolved product and how to define the product developing strategy from a series of evaluation based on the previous product. It also proposes several directions of the SOC technologies in the end of the thesis for future research.
致謝
首先要感謝張教授瑞川先生，在論文寫作期間的指導與協助，讓本論文得以 順利完成；再者要感謝威盛電子長官林資深副總子牧先生及陳協理珉宏先生的成 全及提攜，我才得以在多年職場工作之後，重回校園進修；當然也要感謝台北、 北京一起工作的夥伴在此期間對任務的全心投入及全力支援，讓我得以在工作上 無後顧之憂，而後可以學業與工作兼顧。 電子資訊科技的快速進展，加速了全球化的腳步，近年來全球的產業結構發 生了劇烈的變化，IC 設計業在此同時也經歷了前所未有的震盪與起伏，所幸專班 彈性的修業年限讓我得以用六年的時間一面因應公司在環境上所面臨的變局，一 面也在學業的道路上匍匐前進，逐步的完成學業，感謝專班在課程上理論與現行 科技並重的課程設計，讓我可以經由學業上所開拓出的視野，用不同的角度面對 複雜的問題以及尋找答案的能力。 最後要感謝先生及女兒的支持，這麼多年來燈下的伴讀以及犧牲許多休閒共 聚的時光，還有感謝所有在我這趟求學之旅上曾經教導過我的老師及幫助我的 人，這是一趟豐富而有趣的知識之旅，讓我得以不同的方式來面對未來世界的變 化。目錄
中文摘要 i 英文摘要 ii 致謝 iii 目錄 iv 圖表目錄 v 第一章 緒論...1第二章 Photo Bank vs. Music Bank ...5
2.1 產品功能...5 2.2 消費產品研發之挑戰...7 第三章 MP3 簡介 ...13 3.1 MP3 解碼原理 ... 14 3.2 MP3 音質評估原理 ... 21 第四章 系統演進方法...24 4.1 軟體實現...24 4.1.1 MP3 解碼軟體流程 ... 25 4.1.2 MP3 解碼器軟體分析 ... 27 4.2 硬體實現...31 4.2.3 單數位訊號處理器系統架構...33 4.2.4 雙核處理器系統架構...39 4.2.5 MP3 硬體解碼器系統架構 ... 40 4.3 Music Bank系統架構評估 ... 42 4.4 硬體MP3 解碼器音質評估 ...50 第五章 結論與未來工作...54 參考資料...57
圖表目錄
圖表 1 VT6205A單晶片系統功能區塊圖... 6 圖表 2 產品開發時間縮短之後的現金流量分析圖 ... 8 圖表 3 MPEG-1 三等級音訊壓縮技術 ... 13 圖表 4 MPEG LAYER-3 聲音壓縮效能品質對照表... 14 圖表 5 MPEG-1 LAYER 3 位元流格式 ... 15 圖表 6 主要資訊格式圖... 15 圖表 7 MP3 解碼處理流程 ... 16 圖表 8 MPEG-1 LAYER 3 檔頭格式 ... 17 圖表 9 位元傳輸對照表... 18 圖表 10 MP3 位元流範例圖 ... 19 圖表 11 MP3 解碼細部流程區塊圖 ... 20 圖表 12 ISO/ICE 11172-4 MP3 解碼器三等級定義表 ... 23 圖表 13 複雜度評估平台資訊圖 ... 25 圖表 14 MP3 解碼軟體流程圖 ... 27 圖表 15 MP3 測試位元流檔案格式表 ... 28 圖表 16 MP3 軟體解碼流程區塊執行時間對照表 ... 29 圖表 17 MP3 解碼器混合濾波器示意圖 ... 31 圖表 18 MUSICBANK 可行三方案圖表... 32 圖表 19 單數位訊號處理器系統架構圖 ... 33 圖表 20 方案一開發環境資訊圖 ... 34 圖表 21 MICRODSP MP3 解碼流程區塊執行時間對照表 ... 35 圖表 22 MICRODSP MP3 解碼程式記憶體使用圖 ... 36圖表 23 OSCAR模擬播放MP3 歌曲所需MICRODSP TOTAL CYCLE圖 ... 37
圖表 24 OSCAR模擬播放MP3 歌曲CYCLE數(32SAMPLES PER UNIT)圖... 38
圖表 25 雙處理器系統架構圖 ... 39 圖表 26 MP3 硬體解碼器系統架構圖 ... 41 圖表 27 微控制器評估指標表 ... 43 圖表 28 記憶體評估指標表... 44 圖表 29 周邊評估指標表... 45 圖表 30 韌體評估指標表... 46 圖表 31 作業系統評估指標表 ... 47 圖表 32 演算法評估指標表... 48 圖表 33 應用軟體評估指標表 ... 49 圖表 34 開發工具評估指標表 ... 49 圖表 35 三方案系統架構評估指標總表 ... 50
圖表 36 受測MP3 解碼器RMS’及MAX’表... 52
圖表 37 受測MP3 解碼器ISO/11172-4 等級表... 53
圖表 38 產品概念及規劃階段相關步驟圖 ... 54
第一章 緒論
領先市場推出產品，並且頻繁地推出新的形式，將明顯地在數位電子 產品的世界裡，佔有某一產品類別的市場地位[21]，所以將新產品推到市場 上的速度，絕對是決定公司成敗的最關鍵因素。本論文將關注於尋求一個 好的方法(Methodology)讓產品開發的週期縮短，然後可以讓新產品可以提 早 上 市 ， 本 文 所 探 討 的 產 品 為 消 費 性 電 子 產 品 ， 特 別 是 以 SoC(System-On-Chip)型式所開發之嵌入式系統(Embedded System)，嵌入式 系統(Embedded System)是指一種為某特定應用之設備所設計製造的電腦系 統，通常包含一個處理器 (Processor)與儲存在ROM的程式組合而成，用來 控制設備或儀器，現今嵌入式系統最重要的應用是通訊、網路、計算密集 之演算法、控制、多媒體及娛樂領域，這些系統具有反應快、即時及自主 之特性[17]。 嵌入式系統有別於桌上型個人電腦之設計，其主要原因為嵌入式系統 是為特定用途而設計、無特定處理器之指定、通常具成本之敏感性、即時 要求之特性，而近年來ASIC在製程上的快速進展，使得消費性的嵌入式系 統產品得以大量應用SoC(System-On-Chip)之技術進行開發，因此SoC設計公 司得以在單晶片中加進更多樣的功能，使得單晶片設計的複雜度提高，所 以SoC的產品開策略及開發流程的成敗就是產品能否即時上市的關鍵因素。 針對縮短嵌入式系統開發時程的相關研究，一般會強調及早進行軟體 與硬體平行開的重要性，以期在開發模擬階段軟體及硬體的開發者能及早 發現問題同時進行修正，讓 IC 實體認證時之錯誤越少越好，以避免 IC 實 體進行重作所耗費的時間與開發成本，進而縮短開發設計時程，目前有幾 個研究的趨勢[1]，有提供抽象高階語言給設計者，透過抽象高階語言建立 模型，再將模型轉換成程式碼或中繼模型最後乃至產生實際的設計模型， 如 SystemC[8]及 SystemVerilog[18]；有晶片內部設計網路化，允許使用 IP區塊做平台模組及原件的設計；有更高層次的抽象高階語言等如 UML 語言 [15]，讓特定知識領域的應用者，以抽象高階語言專注於特定應用而非平台 之軟硬體本身；大多數的研究主要集中於產品開發執行階段方法的改善。 實際上，一個產品生命週期可分四個階段大致為概念發展及規劃階 段、執行階段、大量生產階段和產品生命結束階段[21]，本論文主要是研究 縮短開發概念及規劃階段時程的方法，特別是以嵌入式系統型式開發之消 費性電子產品，讓產品開發週期縮短，新產品提早上市為主要目標，本論 文不同於大多數論文集中於討論產品執行階段之研究，而是專注在產品生 命週期的概念發展及規劃階段的研究，因為產品的起始規劃是產品能否如 期或提早上市最重要的一環；本論文將以開發一衍生產品時在產品概念發 展及規劃階段，提出具體可行的方法用以迅速確實的決定產品的開發策略。 本論文的研究動機，是從研發的觀點探討嵌入式系統開發初期，從市 場需求規格定義後，研發單位在決定衍生性產品開發策略時，必需評估的 幾個關鍵項目，嵌入式系統開發的幾個關鍵項目為，訂定系統架構、選擇 系統軟體、選定開發工具等。當產品價格和功能規格已被市場部門定義之 下，如何對這些關鍵項目做出適當的決定，進而確定嵌入式系統開發之方 向，最後定訂有效的產品研發專案，進行執行階段之管理，最後縮短產品 開發週期，這是從事消費性電子產品開發之 IC 設計研發團隊在高度競爭的 市場之中，必須擁有的競爭利器。 本論文討論嵌入式系統開發關鍵項目時所採取之方法為，選用 VIA Technologies. Inc.[19] 已 量 產 之 SoC 晶 片 產 品 為 標 的 ， 其 晶 片 代 號 為 VT6205A；本款 SoC 晶片為量產產品，是市面上產品 Photo Bank 之主要核 心晶片。然而，依據市場之需求為增加其產品之新穎性，預計在原 SoC 晶 片組中保留原 Photo Bank 之功能外，同時也增加音樂 MP3 播放處理功能； 而後成為繼 VT6205A 後下一代 SoC 晶片產品，做為日後新產品 Music Bank 之主要核心晶片。針對此一衍生產品，本論文將探討於產品概念及規劃階
段，發展出幾項關鍵評估項目，以及針對這些關鍵項目進行評估，然後做 出適當產品開發策略之決策，最後對於此項產品開發策略進行品質的評 估，以確認產品開發策略合於市場需求規格。 第一章緒論將對嵌入式系統作一簡介，同時強調以 SoC 型式開發且定 位為消費性電子產品其正確開發策略對產品能即時上市之重要性，針對縮 短嵌入式系統開發時程的相關研究作一敘述，對於本論文的動機在於探討 縮短產品概念及規劃階段的時間與確定產品策略方向的方法也加以說明， 最後將本文所研究之衍生性產品案例的原由及所將採取的研究步驟作一描 述。 第二章將對研究案例中之已量產之數位照片儲存盒(Photo Bank)和衍 生產品之數位音樂儲存盒(Music Bank)的產品功能分別加以敘述，同時對於 開發消費性電子產品及時上市之重要性加以闡述，也提出在設計衍生性產 品時所將面臨的挑戰，特別是在規劃產品開發策略時所將遭遇到的挑戰， 如來自系統架構、韌體、軟體及開發工具等方面的挑戰。 第三章將對數位照片儲存盒及數位音樂儲存盒兩代產品之間最大之功 能差異項目也就是數位音樂播放功能的 MP3 作一說明，其中將針對 MP3 解碼原理及 MP3 音質評估原理作一介紹。 第四章將針對在衍生性產品中所新增之 MP3 功能，進行系統演進方法 的演繹，首先將以軟體實現 MP3 解碼功能，同時對 MP3 軟體解碼流程加以 說明，接著再依據 MP3 軟體功能模組進行複雜度分析，然後根據複雜分析 的結果提出三個硬體實現的可行性方案進行評估，也將提出系統架構評估 的方法對這三個方案進行評估，之後將依評估的數據決定數位音樂儲存盒 的系統架構研發策略，由於必須確認所選擇之研發策略的正確性，所以最 後將提出 MP3 硬體音質評估方法，對選定之方案進行評估以確保其符合市 場需求規格之要求。
第五章將對本論文所研究縮短產品概念及規劃階段所提出之方法作一 結論，同時也提出幾個未來在縮短產品開發時間上可以持續進行研究之方 向。
第二章Photo Bank vs. Music Bank
2.1 產品功能
數位照片儲存盒(Photo Bank)產品定位為一提供收納市面上常見儲存 記憶卡之數位資料儲存盒而且具有與 PC 做資料交換能力之消費性電子產 品，由於當今數位產品眾多，應用範圍琳瑯滿目，雖然應用面不盡相同， 但是通常都有儲存數位資料的需要，因此各家數位和消費性電子產品廠商 為其產品提供不同之儲存方案如硬碟、光碟、儲存記憶卡等，然而現今儲 存記憶卡並沒有統一的規格，市面上流通的儲存記憶卡大概有十餘種以上 不同的規格，所以消費者經常因為手中所擁有不同的消費性電子產品，以 致於手中經常擁有 3~4 種儲存記憶卡。因此，有數位照片儲存盒的產品開 發與上市，此產品內建一個微型硬碟；具有兩種操作模式，一種為單機操 作模式，另一種為與個人電腦(PC)連接操作模式。 數位照片儲存盒使用 VT6205A 單晶片為核心，此單晶片內嵌 8051 微 控 制 器 (Micro Controller, uC) ， 可 支 援 常 見 之 記 憶 儲 存 卡 如 CompactFlash(CF) 、 SmartMedia(SM) 、 MemoryStick(MS) 、 MemoryStick Pro(MS Pro) 、 SecurityDigital(SD) 、 MultiMediaCard(MMC) 、 xD PictureCard(xD)，支援 ATA/ATAPI 磁碟機介面、 UTM(USB 2.0 Transceiver Microcell)介面及 LCD 等介面。經由 LCD 面版及觸控紐之操作，單機使用 時可提供儲存卡與內建硬碟進行數位照片資料之交換，當成數位照片儲存 盒之用途；與個人電腦(PC)連接使用時，若搭配 USB 2.0 之傳輸線則數位照 片儲存盒與個人電腦(PC)可經由 USB 2.0 之傳輸線進行高速之資料交換，當 成 USB 2.0 磁碟機使用。 VT6205A 單晶片以 8051 微控制器為控制中心，它可經由內部系統匯 流排 (System Bus)透過媒體硬體引擎(Media Hardware Engine)可與外界記憶儲存卡及硬碟進行資料交換；它可經由系統匯流排控制 ROM、SRAM 及 EEPROM 記憶儲存單元；它可經由系統匯流排控制 FIFO、UDMAC 及 USBC；它可透過 UTMI 介面經由 USB 訊號線與 PC 的 USB 2.0 埠連接，當 成 USB 2.0 硬碟使用，詳細 VT6205A 系統功能區塊請參照圖表 1。 圖表 1 VT6205A 單晶片系統功能區塊圖 數位音樂儲存盒(Music Bank) 產品定位為一提供收納市面上常見儲存 記憶卡之數位資料儲存、資料交換及 MP3 數位音樂播放中心之消費性電子 產品。由於現今網路及通訊設備的普及和頻寬的加大，所以數位音樂及數 位照片擋廣泛流傳於消費性及通訊電子產品之中作為傳遞資訊之用途。為 維持數位照片儲存盒產品之新穎性，因此定義數位音樂儲存盒為數位照片 儲存盒下一代的衍生性產品；除了全數保留數位照片儲存盒(Photo Bank)功 能，也就是具有單機操作功能和與 PC 連線交換資料兩個主要操作模式之 外，同時也新增對儲存於硬碟或儲存記憶卡中之 MP3 數位音樂檔案進行資 料處理及播放的能力；例如經由 LCD 觸控面板及按鈕之操作，數位音樂儲 存盒可播放、操作及管理 MP3 數位音樂檔案之能力。
比較數位音樂儲存盒(Music Bank)與數位照片儲存盒(Photo Bank)兩者 產品功能之最大差異在於前者具有 MP3 數位音樂檔案播放及處理的能力， 而後者則不具備此項功能。
2.2 消費產品研發之挑戰
消費性電子產品為保持其新穎性，一般而言產品週期短，因此研發團 隊必須充分掌握開發時間以密切配合產品上市時程，而且將盡可能的縮短 產品開發週期讓產品得以提早上市，以便獲得較高的產品利潤；現在從產 品生命週期的四個階段也就是產品概念發展及規劃階段、產品執行階段、 產品大量生產階段和產品生命結束階段，來注意當產品開發時間縮短後對 現金流量的影響，詳細請參考圖表 2；在概念發展及規劃階段主要花費是 在人力資源上，在執行階段主要花費於樣本、測試、設備及人力資源上， 在大量生產階段將由產品銷售當中獲得收入，產品生命結束階段主要花費 在於處理原料及零件等，由圖中可得知，產品現金花費主要在前兩階段， 一旦進入大量生產後則可獲得收益，所以當縮短產品生命週期中的概念發 展及規劃階段和執行階段準備時間之後，將獲得的效益包含更高的產品打 擊率、更好的產品專案焦點、更高的市場佔有率和更高的市場價格[21]。 觀察開發新產品的四個階段，影響產品開發速度的前兩階段大部分屬 於技術性的領域，所以研發團隊如何掌握有效縮短研發流程的技術，將是 產品能否獲利之主要因素，然而，消費性電子產品一般具有價格及性能比 (Price/Performance)低之要求，所以單晶片成本也需要在產品開發概念發展 及規劃階段加以掌握及試算的項目。現 金 流 量 + 概念發展及 規劃階段 執行 階段 (原始) 執行 階段 (縮短後) 大量 生產 階段 (縮短後) 大量 生產 階段 (原始) 產品生命 結束階段 生產時間更長 上市前的處理時間縮短 上市前的處理時間縮短，產品得 以提早上市，將代表著： ‧更高的打擊率 ‧更好的專案焦點 ‧更高的市場佔有率 ‧更高的市場價格 梯形線：典型現金流量狀況(原始) 曲形線：累計現金流量狀況(縮短後) 損益兩平 最大風險
取材自：Lewis, P. James, Wong, Louis, 產品研發專案管理[21]
圖表 2 產品開發時間縮短之後的現金流量分析圖 衍生性產品期望是能維持前代產品的功能和增加衍生性產品的新穎 性，但主要的目的是能以衍生性產品提高售價及維持利潤，同時增加競爭 者進入之門檻，所以產品上市之速度是越快越好，因此產品在概念發展及 規劃階段，研發決策團隊必須能運用有限的人力資源及現有的研發智財 (IP-Intellent Property)規劃出正確且迅速之衍生性產品開發策略，然後遞交給 研發團隊進行產品的執行階段，所以產品概念發展及規劃階段的精確性與 否，幾乎就已決定了產品能否能達成如期上市的目標，如何做出正確的開 發策略通常是產品開發最困難的一部分，因此有必要尋找出一些客觀的評 估指標及方法。 在開發衍生性產品的概念發展及規劃階段，通常需先檢視現有可用資 源，就技術資源部份，首先會優先考量利用現行量產產品已開發之智財資 源，譬如先行評估原數位照片儲存盒系統架構及系統軟體，以確認是否能 在原數位照片儲存盒架構之下，進行小規模之改良，就可增添所需 MP3 數
位音樂播放之功能，而成為衍生性產品也就是數位音樂儲存盒。 現在對如何做出數位音樂儲存盒正確之開發策略，將提出一系列的步 驟進行評估的流程，首先將評估數位照片儲存盒之現有智財資源也就是現 有的系統架構及現存軟體是否可重新利用成為衍生產品開發時之基礎架 構，以節省在產品執行階段重做所耗費的時間，然後達到縮短研發執行時 間的目的，以下針對原已開發資源能否做為衍生性產品再開發利用之資源 時需要須評估的幾個重要項目，將對這些項目分別討論之。 微控制器或微處理器 數位照片儲存盒使用時脈為 60MHz 8 位元之 8051 微控制器，而數位 音樂儲存盒增加 MP3 數位音樂播放及檔案處理的能力，因此需評估原 8051 微控制器是否仍能滿足衍生性產品所新增數位音樂處理功能的要求，而且 除了能支援新增 MP3 數位音樂處理能力之外，同時也要能維持住原數位照 片儲存盒之資料儲存及資料傳輸的效能，如果原控制理器運算能力不符使 用時則需考慮更換微處理器或輔助性的增加另外一顆微控制器以提高整體 系統的運算能力。 數位訊號處理器 數位照片儲存盒之微控制器主要是負責整合及控制周邊模組，並沒有 配置數位訊號處理器；然而在新增 MP3 數位音樂處理功能上，需要對 MP3 數位音樂檔案進行一系列之解碼處理，其中運用大量的數值運算；然而 8051 微控制器只具備簡易之算術與邏輯運算指令，所以運算能力有限，因此需 評估是否有配置額外數位訊號處理器之必要，讓新增之數位訊號處理器能 專責於數位訊號處理工作。 記憶體 數位照片儲存盒所使用之 8051 微控制器，它的記憶體結構是程式記憶
體與資料記憶體分開，而且 ROM 和 RAM 的最大定址範圍各為 64Kbytes； 數位照片儲存盒內部配置一個 24KBytes Mask ROM 作為程式記憶體之用、 一個 2KBytes 及二個 256Bytes SRAM 作為資料記憶體之用，同時提供外 掛 64KBytes ROM 或 Flash 的能力，提供後續程式記憶體及資料記憶體之擴 充能力。然而對數位音樂儲存盒則需考量如果不更換微控制器的前提之 下，現行的記憶體定址範圍、記憶體大小及配置方式能否滿足所新增之數 位音樂處理之需求，如果變更微控制器設計則須考量記憶體定址、配置的 方式及應如何正確的估算記憶體使用之大小。 周邊 數位照片儲存盒提供兩種操作模式即單機操作模式及與個人電腦連接 之資料交換操作之模式，對外可經由媒體硬體引擎(Media Hardware Engine) 介面能與儲存記憶卡、硬碟和 LCD 等周邊硬體溝通，同時也可經由 UTMI 介面與個人電腦主機之 USB 埠連接，而因應數位音樂儲存盒所增加之 MP3 音樂播放功能，勢必需要增加新週邊介面之設計如常用連接音效編碼器 (Audio Codec)之 I2C 和 SPI 介面，以提供連接喇叭及耳機等新周邊硬體的能 力。
韌體
數位照片儲存盒使用 C51 作為主要設計語言，韌體以模組化設計，以 VT6205A 單晶片系統功能區塊圖中之 System Bus 為分割線將韌體分為上下 兩大模組區塊，上區塊為 USB 功能控制模組，下區塊包含讀卡機功能控制 模組、LCD 功能控制模組及 FAT32 檔案管理模組，詳細請參考圖表 1，韌 體可置放於內建 24KBytes Mask ROM 或置放於擴充外存 64KB ROM/Flash 空間中執行。數位音樂儲存盒所新增加數位音樂處理的功能，需考量原有 韌體之架構是否擁有容易加入處理數位音樂軟體模組及針對音樂檔案管理 軟體模組之擴充能力。如需更換處理器則需考量原有韌體模組可重覆使用 的比例，如需新增另一顆數位訊號處理器時則需考量將數位訊號處理器使
用之軟體嵌入原有韌體模組中之難易程度。 作業系統 數位照片儲存盒之韌體設計並沒有使用作業系統，因為產品定位於儲 存資料之交換用途，而且其應用範圍沒有即時性反應之需求，所以在給定 時脈為 60MHz 的 8051 微控制器作業環境下，使用無窮迴圈之韌體架構就 足以應付數位照片儲存盒所要求之功能；然而數位音樂儲存盒增加數位音 樂播放能力，基於音樂播放即時性之要求，因此必須考量原無窮迴圈之韌 體架構是否仍能滿足其及時性之需求，而且是否需引進使用小型作業系統 以滿足其音樂及時性和利用作業系統中成熟的檔案管理系統功能進行數位 音樂檔的管理與應用開發，以縮短軟體開發時程。 演算法 數位音樂儲存盒在處理 MP3 數位音樂檔案時，將需要具有 MP3 解碼 處理能力，其包含一連串之數值運算及音訊解碼演算法，在評估原系統能 否滿足 MP3 解碼器演算能力要求之前提下，都必須考量運用何種方式進行 MP3 解碼能力的實現，如以軟體實現、硬體實現或軟硬體混合體實現，不 論以何種方式實現 MP3 功能，都必須能夠對不同方式實現的 MP3 解碼器相 關之演算法進行的最佳化的工程，同時也要有方法能對開發中之修正過程 進行效能評估。 應用軟體 數位照片儲存盒提供單機操作模式及與個人電腦交換資料操作模式， 因此針對廠商及使用者分別提供相對應之應用軟體，如對廠商提供客製化 LCD 韌體、客製化檔案管理系統、工廠量產測試程式和韌體燒錄程式等， 對使用者提供韌體更新程式、單鍵拷貝程式、E-Mail 收發程式等應用程式， 因應新增之 MP3 數位音樂播放功能，需考量原開發之應用軟體可以重覆使 用的程度，同時針對新功能的需求須評估對原應用軟體必須重新設計所需
花費的時間以及對整體開發計畫時程所造成的影響程度。 開發工具
嵌入式系統之開發少有在同一套系統同時開發及除錯，通常需於主機 系統(Host System)先行摹擬開發，然後再於目標系統(Target System)進行規 格確認及除錯的工作[2]，因此一套易於使用及取得成本低的整合開發工 具，對嵌入式系統開發時程有相當程度的影響力，因此開發工具是在嵌入 式系統規劃之始必定要評估的重要項目之一。 通常變更處理器便意味著必須更換開發工具，所以在考慮變更處理器 設計時也應將開發工具之因素一並考量，必須考慮其整合開發工具使用之 方便性及取得成本和工程師重新學習及花費之學習成本，以及將對產品開 發時程所造成的影響。 數位音樂儲存盒相較於數位照片儲存盒增加了 MP3 數位音樂播放功 能。在評估原數位照片儲存盒系統架構是否能藉由小規模之改良而滿足這 項新的功能需求時，以上幾個項目將是評估原系統架構能否作為衍生產品 架構基礎時的幾個重要指標，必須面對其所帶來的問題和挑戰，在尋求最 佳的解決方案的同時也應將產品開發的速度作為衡量的重要依據。數位音 樂儲存盒將會是以數位照片儲存盒改良之衍生性產品形式進行開發或是以 新產品形式進行開發，在上述評估項目及相關的問題經由分析以及在產品 開發速度及成本取得權衡平衡後，就可以從分析數據中決定數位音樂儲存 盒產品開發之執行策略。
第三章 MP3 簡介
數位音樂儲存盒(Music Bank)與前一代產品的數位照片儲存盒(Photo Bank)，在產品規格上最明顯的差別就是新增 MP3 數位音樂解碼功能，首先 將對 MP3 做一簡介，MP3 源起於 1987 年 Fraunhofer IIS 所從事之數位音訊 廣播計畫(Digital Audio Broadcasting)中所發展出的音訊壓縮演算法，隨後於 1992 年為 ISO/IEC 採納成為 MPEG/Audio 標準(ISO/IEC 11172-3 及 ISO/IEC 13818-3)，MP3 實際上為 MPEG-1 Layer 3 之簡稱。 一般在音樂聆聽上都會要求 CD 音質，以 CD 音軌訊號取樣率為 44.1kHz、每個取樣為 16 bits、立體聲為例，一秒鐘 CD 品質的音訊大約需 使用 1.411Mbits 之資料量，以一首五分多鐘之歌曲為例則需使用 50MBytes 到 60 MBytes 之資料儲存空間，對如此大量空間之需求，不只在於大量消耗 儲存設備，同時也阻礙了數位音訊檔案透過網路進行資料傳輸的機會。因 此在維持一定的音訊品質要求下，數位音訊的壓縮能力為當前數位音樂能 否普遍應用最需解決的問題之一。
MPEG-1 定義三個音訊壓縮等級(Layer)，分別是 Layer-1、Layer-2 及 Layer-3，各自縮寫為 MP1、MP2 及 MP3。這三等級的壓縮比及取樣率[4] 如圖表 3： 等級 壓縮比例 立體音資料取樣率 Layer-1 1:4 384 kbps Layer-2 1:6 ~ 1:8 256kbps ~ 192kbps Layer-3 1:10 ~ 1:12 128kbps ~ 112 kbps
取材自：Fraunhofer IIS, http://www.iis.fraunhofer.de/amm/techinf/layer3/[4]
圖表 3 MPEG-1 三等級音訊壓縮技術
MP3 音訊壓縮方法，可將一般 CD 音軌訊號以 10 至 12 倍的壓縮比例 進行壓縮，因此五分多鐘之歌曲壓縮成 MP3 檔案後，則只需要 4Mbytes 到
5Mbytes 之資料儲存空間，而且聲音品質並無太大的失真。圖表 4 為 MPEG Layer-3 各種聲音品質等級(Sound Quality)、帶寬(Bandwidth)、種類(Mode)、 位元率(Bitrate)及壓縮比(Reduction Ratio)之相互對照表[4]，在立體聲帶寬為 15kHz 且位元率為 96kbps 時可以有近似於 CD 播放之音質。 音質等級 帶寬 種類 位元率 壓縮比 電話音質 2.5 kHz mono 8 kbps * 96:1 優於短波音質 4.5 kHz mono 16 kbps 48:1 優於 AM radio 音質 7.5 kHz mono 32 kbps 24:1 類似於 FM radio 音質 11 kHz stereo 56...64 kbps 26...24:1 近似於 CD 音質 15 kHz stereo 96 kbps 16:1 CD 音質 >15 kHz stereo 112..128kbps 14..12:1
* Fraunhofer IIS 為增加效能，使用非 ISO MPEG Layer-3 擴充標準 (MPEG 2.5) 取材自：Fraunhofer IIS, http://www.iis.fraunhofer.de/amm/techinf/layer3/[4]
圖表 4 MPEG Layer-3 聲音壓縮效能品質對照表 MP3 音訊壓縮方法是屬於失真壓縮(Lossy Compression)，其重建後之 資料會損失某些資訊，失真後之資料之所以能被接受，是因為 MP3 採用聲 響心理模型(Psychoacoustic Model)[20]來模擬人耳的聽覺特性，使得量化後 失真不被人耳察覺。MP3 以其優異的壓縮比且維持幾近不失真的音訊品 質，使得 MP3 成為最為流行的數位音樂格式，因而廣泛的應用於 PC、隨身 聽、手機、音響等電子消費性產品之中。
3.1 MP3 解碼原理
衍生產品之數位音樂儲存盒與原產品之數位照片儲存盒最主要功能上 的差別是在原產品功能中新加入MP3解碼功能，所以先將針對MP3解碼原理 加以介紹。MP3解碼器(MP3 Decoder)的工作原理是先接收經由任何MP3編碼器(MP3 Encoder)所壓縮編碼過之MP3位元流(Bitstream)；MP3位元流包含 檔頭(Header)、錯誤偵測碼(CRC)、附屬資料(Side Information)、主要資訊 (Main Data)及補充資訊(Ancillary Data)，請參照圖表 5。
檔頭記錄著MP3位元流的相關資訊，其中的第16個位元將記載是否使 用錯誤偵測碼，若此位元為零(protection_bit=0)則於檔頭之後，將使用16位 元之錯誤偵測碼(crc_check)；若為壹(protection_bit=1)則不使用錯誤偵測碼 [7]；使用錯誤偵測碼將可以對檔頭進行錯誤偵測及修正，以避免因檔頭錯 誤而無法進行解碼資料的情形發生。 檔頭 32 bits 錯誤偵測碼 0 or 16 bits 附屬資料 136 or 256 bits 主要資訊 補充資訊 取材自：ISO/IEC 11172-3[7] 圖表 5 MPEG-1 Layer 3 位元流格式 附屬資料主要是存放還原量化及霍夫曼編碼相關資訊，所以在對主要 資訊做還原量化及霍夫曼解碼之前必須要先解出附屬資料中之相關資訊， 附屬資料的長度因單聲道與雙聲道而有所不同，單聲道的音訊需使用136位 元的附屬資料，雙聲道的音訊需使用256位元的附屬資料。 主要資訊儲存著比例因子(Scalefactor)和經過量化、位元分配與無失真 霍夫曼編碼( Huffman Encoding)後的音訊資料[20]，詳細格式請參考圖表 6。 取材自：吳炳飛等著”Audio Coding 技術手冊-MP3 篇”[20] 圖表 6 主要資訊格式圖
MP3為了提高編碼時的壓縮率，因此在音訊量化之後又使用了無失真 且非固定長度的霍夫曼編碼，量化器將頻線分為三個區間，可以讓編碼器 依照不同的區間使用不同的霍夫曼表，請參考圖表 6 主 要 資 訊 格 式 圖，在高頻區間，編碼器將連續的零視為一個區間，稱為零區間(zero region)，第二個區間稱為count1區間，是由一連串的0和1組成，此區間的霍 夫曼碼是以四個取樣為一組來查表，第三個區間為big_value區間，此區間 會出現較大的數值，所以霍夫曼表是以兩個量化後的頻線為一組來編碼， 而此區間可以再分成三個區間，端看各區間的最大數值來決定適合的霍夫 曼表[20]。 補充資訊為使用者定義區，使用者可存放歌曲名稱等自行定義的資訊 於此區之中。 MP3解碼器處理流程大致可分為四個功能區塊[12]，也就是同步位元流 (Synchronization)功能區塊、解開編碼框(Frame Unpacking) 功能區塊、重建 (Reconstruction)和合成濾頻(Synthesis Filtering) 功能區塊，詳細資訊請參照 圖表 7。
取材自：Kim, Seonjoo, et al., Real Time MPEG1 Audio Encoder and Decoder…”[12]
圖表 7 MP3 解碼處理流程
同步位元流(Synchronization)功能區塊的主要功能是將輸入之編碼過後的 MP3位元流，依據檔頭及錯誤偵測碼進行同步及偵錯(Synchronization and Error Checking)的處理作業[16]，檔頭格式請參照圖表 8。
取材自：吳炳飛等著”Audio Coding 技術手冊-MP3 篇”[20] 圖表 8 MPEG-1 Layer 3 檔頭格式
同步化參考標記(Syncword)：連續12個位元，“1111 1111 1111”表示MP3歌曲 的開頭。
辨識碼(ID)：1位元，“1”表示為MPEG-1 Audio，“0”為保留值。
指定編碼層(Layer)：2位元，“11” 表示為Layer-1，“10” 表示為Layer-2，“01” 表示為Layer-3，“00” 表示為保留值。
錯誤偵測碼(Protection_bit)：1位元，表示是否需要加上額外16位元的錯誤偵 測碼，可提供檔頭的錯誤偵測碼及修正，“1”表示不需要額外16位元的錯誤 偵測碼，“0”表示需要額外16位元的錯誤偵測碼。
Bitrate Index Layer-1 Layer-2 Layer-3 ‘0000’ free format free format free format ‘0001’ 32kbit/s 32kbit/s 32kbit/s ‘0010’ 64kbit/s 48kbit/s 40kbit/s ‘0011’ 96kbit/s 56kbit/s 48kbit/s ‘0100’ 128kbit/s 64kbit/s 56kbit/s ‘0101’ 160kbit/s 80kbit/s 64kbit/s ‘0110’ 192kbit/s 96kbit/s 80kbit/s ‘0111’ 224kbit/s 112kbit/s 96kbit/s ‘1000’ 256kbit/s 128kbit/s 112kbit/s ‘1001’ 288kbit/s 160kbit/s 128kbit/s ‘1010’ 320kbit/s 192kbit/s 160kbit/s ‘1011’ 352kbit/s 224kbit/s 192kbit/s ‘1100’ 384kbit/s 256kbit/s 224kbit/s ‘1101’ 416kbit/s 320kbit/s 256kbit/s ‘1110’ 448kbit/s 384kbit/s 320kbit/s
取材自：ISO/IEC 11172-3[7] 圖表 9 位元傳輸對照表 取樣頻率(Sampling frequency)：2位元，用來指定這首歌的取樣率，“00” 表 示為44.1kHz，“01” 表示為48kHz，“10” 表示為32kHz，“00” 表示為保留值。 填塞位元(Padding bit)：1位元，只有在取樣頻率為44.1kHz時需要用到填塞 位元，使得每個編碼框可用來對音樂訊號編碼的位元數為8的倍數，使其可 以為位元組(bytes)為單位。 私密位元(Private bit)：1位元，可用作私人用途，但ISO未來版本已不作使用。 音訊模式(Mode)：2位元，“00” 表示為立體聲(stereo)，“01” 表示為雙聲合 一(joint_stereo)，“10” 表示對偶聲式(dual_channel)，“00” 表示為單聲式 (single_channel)。 模式延伸(Mode extension)：2位元，在第三層編碼中用來標記使用何種雙聲
合一(joint_stereo)的模式。 版權(copyright)：1位元，“0”表示為此位元流沒有版權限制，“1” 表示為此 位元流有版權限制。 原版/拷貝版(Orignal/Home)：1位元，“0”表示此位元流是拷貝過的版本，“1” 表示此位元流是原版。 加強模式(Emphasis)：2位元，指定加強模式，“00” 表示為無加強，“01” 表 示為50/15 microsec.加強模式，“10” 表示保留值，“11” 表示為CCITT J.17 加強模式。 解開編碼框(Frame Unpacking) 功能區塊的主要功能是解譯MP3位元流中 之檔頭(Header)及附屬資訊資料(Side Information)，同時依據針附屬資訊資 料中之資訊對主要資訊(Main Data)中之資料進行解碼；主要資訊包含編碼過 的霍夫曼碼及比例因子資訊，本區塊功能是將位元流中所包含的霍夫曼碼 (Huffman code)依據霍夫曼資訊(Huffman Information)進行解碼，同時也對比 例因子資訊(Scalefactor Information)進行解碼，MP3位元流格式請參考圖表 10，它為MP3位元流Layer-3的一個範例，這個範例中可以發現，一個編碼 框的主要資訊資料量大時則它的主要資訊可以跨越到其他的編碼框如編碼 框3。
取材自：Salomonsen, K.等著” Design and Implementation of an MPEG/Audio layer III …”[16] 圖表 10 MP3 位元流範例圖
重建(Reconstruction)功能區塊的主要功能是將解開後之位元流資訊，進行 還原量化(Inverse Quantization)、如有必要時進行之位元重組(Reordering)、 雙聲合一立體聲(Joint Stereo Decoding)解碼處理、降低失真(Alias Reduction) 處理、改良型餘弦反轉換(IMDCT)處理作業及頻域與時域轉換(Frequency Inversion)，細部資料請參照圖表 11流程區塊圖[16]。
合成濾頻(Synthesis Filtering) 功能區塊的主要功能是多相合成濾頻器 (Synthesis Polyphase Filter bank) 之處理程序，最後合成輸出PCM格式之音 樂資料位元流，細部資料請參照圖表 11流程區塊圖。如欲獲得更詳盡之技 術資料請參考[16]。
取材自：Salomonsen, K.等著” Design and Implementation of an MPEG/Audio layer III …”[16] 圖表 11 MP3 解碼細部流程區塊圖
當接受輸入之編碼過的MP3位元資料流，經由上述MP3四大解碼功能區塊處 理完畢之後，則將MP3編碼位元資料流解碼還原成PCM格式，以PCM音樂 輸出資料即可進行音樂播放。
3.2 MP3 音質評估原理
當在產品概念發展及規劃階段，針對MP3功能尋找一種音質評估方法 是有其必要性，然後用相同的評估方法對各種設計方法下所產生之MP3解 碼器做最初步的音質測試及驗證，將可依據量測數據迅速的評定各種設計 之MP3解碼器音質的等級而後再進行不斷的設計修正及驗証。 通常音質評估方法可分為主觀音質評估方法及客觀音質評估方法，一 般而言主觀音質評估方法須透過真人進行人耳聽覺感官測試，因此所得到 的測試結果純粹屬測試者對音樂品質主觀的感覺，所以測試的數據會因受 測對象的不同或經反覆測試後有數據結果上較大的差異，而且主觀音質評 估也比較耗費測試的時間；客觀音質評估方法大致上是依靠儀器量測或經 由數值分析之方式而取得數據，客觀的音質評估方法在評比數據上的變異 相對比較小，而且測試的時間也比較短，但其評估的結果是否與人耳感覺 相 近 ， 則 有 待 未 來 持 續 的 研 究 ， 如 聽 覺 品 質 的 感 官 音 質 評 估 方 法 (PEAQ-Perceptual Evaluation of Audio Quality)就是近年來被討論的一項客觀評 估方法[11]之一，雖然客觀音質評估方法到目前為止，無法以科學的數據衡 量其音質絕對的優劣，但是仍能以較快速的方式提供一客觀的音質衡量數 據做為設計修正方向之參考依據。本文將採用ISO/ICE 11172-4[10]所提出之MP3客觀音質評估方法，做為 對MP3解碼器音質等級之評估方法。ISO/ICE 11172-4 Part 4：Compliant Test 規 格 中 提 出 兩 個 MP3 解 碼 器 音 質 評 估 之 指 標 ， 指 標 一 為 RMS (Root-Mean-Square)，指標二為MAX(Maximum)；依據規格書中所建議之計 算方法加以整理後，分別列出RMS及MAX之計算公式，其詳細定義請參考 公式(1)及公式(2)。
1 0 ) ( 1 1 0 2 = − − =
∑
− = N to k For R T N RMS N k k k (1) 1 0 :=MaximumT −R For k= to N− MAX k k (2) : k T 受測 MP3 解碼器所輸出之 PCM 值 : k R 對照 MP3 解碼器所輸出之 PCM 值ISO/ICE 11172-4：Compliant Test Annex A，以 24 位元為例計算 RMS 值，本文使用 16 位元 PCM 輸出作為 RMS 的計算單位，因此將公式(1)和公 式(2)依據 16 位元系統加以正規化使得 和 介於(＋1,－1)之間，詳細定 義請參考公式(3)和公式(4)。 k T ' R'k 1 0 ) ' ' ( 1 ' 1 0 2 = − − =
∑
− = N to k For R T N RMS N k k k (3) 1 0 ' ' : ' =MaximumT −R For k= to N− MAX k k (4) 15 15 2 ' , 2 ' k k k k R R T T = = : 'k T 受測 MP3 解碼器所輸出正規化之後的 PCM 值 : 'k R 對照 MP3 解碼器所輸出正規化之後的 PCM 值 ISO/ICE 11172-4 所建議的測試方法是先選定當對照之用的MP3 解碼 器和當受測對象之用的MP3 解碼器，選定一個對照之用的MP3 解碼器做為 所有受測對象之MP3 解碼器的對照組，而受測解碼器就是接受評估測試的 MP3 解碼器，它可為軟體解碼器或硬體解碼器。將受測MP3 解碼器所輸出 之PCM值(Tk)與對照MP3 解碼器所輸出之PCM值(Rk)依公式(1)計算後可求 得RMS值，利用公式(2) 計算後可求得MAX值；RMS為受測MP3 解碼器與 對照MP3 解碼器兩者間之均方根值，而MAX則為二者訊號差絕對值最大之 值。 ISO/ICE 11172-4 規格中將 MP3 解碼器依照 RMS 及 MAX 所得到的數值，分成三個不同的 MP3 音質等級，以表示受測 MP3 解碼器符合 ISO/ICE 11172-3 MPEG-1 解碼規格要求之程度，詳細資料請參考圖表 12，圖表中之 第二行及第三行是依據公式(1)及公式(2)尚未經正規化之 RMS 及 MAX 值， 第四行及第五行為依據公式(3)及公式(4)經正規化後所得到 RMS’及 MAX’ 之值。
Compliant Level RMS MAX RMS’ MAX’
Full Compliance <2−15 12 14
2−
≤ <0.577 4
Limited Accuracy <2−11 12 No Required <9.237 No Required
Not Compliance >2−11 12 No Required >9.237 No Required
取材自： International Standard ISO/IEC 11172-4, Part 4[10] 圖表 12 ISO/ICE 11172-4 MP3 解碼器三等級定義表
ISO/ICE 11172-4 Compliant Test 將 MP3 解碼器符合 ISO/ICE 11172-3 規 格 的 程 度 大 致 區 分 為 三 個 等 級 ， 第 一 等 級 為 完 全 符 合 規 格 (Full Compliance)，第二等級為有限度的正確符合規格(Limited Accuracy)，第三 等級為不符合規格(Not Compliance)，本文將以此三個等級做為 MP3 解碼器 是否符合 ISO/ICE 11172-3 規格要求做為音質等級分類的標準。
第四章 系統演進方法
一個衍生性產品的開發，在產品概念發展及規劃的階段時，就要能夠 迅速有效的利用現有已開發之資源，來決定其系統架構主要組成元件，以 數位音樂儲存盒為例，其主要元件包含微控制器、數位訊號處理器、記憶 體、系統匯流排、記憶儲存卡介面、LCD 控制介面、磁碟機介面、USB 2.0 傳輸介面、MP3 解碼器、音樂收聽與播放介面和使用者操作介面等，本論 文將以二代產品間最大差異的 MP3 解碼器功能為探討的主軸，期望在經由 評估其系統架構的過程之中所發展出的開發策略評估方法及步驟，能歸納 出日後衍生性產品或新產品在產品概念發展及規劃階段時都能適用的評估 流程，一個有效率的評估流程對產品上市時間有緊迫性的衍生性產品尤其 顯得重要。 本文將依以下方式進行開發策略的評估步驟，首先將利用 MP3 軟體解 碼器進行 MP3 解碼器之複雜度分析，再經由複雜度分析數據提出三個數位 音樂儲存盒系統架構的可行性方案來進行評估，也將提出對此三方案之系 統架構進行評估的方法，所提出之方法主要是以效能與成本作為理想系統 架構之主要的評估指標，各方案將依照評估指標進行評量，所得到之最佳 化評估數據將被選定為數位音樂儲存盒的系統架構；最後也將依照 MP3 客 觀音質評估方法對所選定之數位音樂儲存盒進行音質評估與測試，以確認 MP3 解碼功能符合市場需求規格之要求，經過上述評估流程之後將決定本 項衍生性產品之最佳之產品開發策略。4.1 軟體實現
數位音樂儲存盒(Music Bank)系統功能與前一代產品數位照片儲存盒 最大的差異是增加 MP3 解碼及播放功能，因此在建構數位音樂儲存盒系統架構之前，必須對 MP3 解碼功能進行複雜度分析，經由複雜度分析的結果， 再決定 MP3 解碼功能應藉由何種設計方法實現；當決定 MP3 解碼功能實現 方法之後，緊接著就能對系統架構上之主要元件，依據市場規格書之要求， 逐步確認而後完成系統架構整體規劃。本章節將先使用軟體實現方式進行 MP3 解碼功能的設計，然後藉由複雜度分析，提出幾個設計可行性方案做 為後續評估之用。
4.1.1 MP3 解碼軟體流程
自從 1987 年 MP3 發源於 Fraunhofer IIS 實驗室，至今已是被廣泛應用 之技術，所以在自由軟體解領域中存在著許多 MP3 相關之軟體原始代碼。 本論文採用 Fraunhofer IIS 開發分享之 MPEG-1 Layer 3 解碼軟體進行 MP3 解碼功能複雜度分析。Fraunhofer IIS MP3 解碼原始碼可從 MP3’ Tech 網頁中的“Programmer’s corner”獲得下載[5]，版本為 4.1，開發與維護期間為 1991-1994；本論文採 用 Microsoft Windows XP SP2 及 Microsoft Visual Studio 6.0 SP5 為複雜度開 發平台的作業系統及開發軟體，開發平台及相關軟體詳細資料請參考圖表 13。原 Fraunhofer IIS MP3 解碼原始碼使用 C 語言撰寫所以原始碼作適度移 植之後就可以在評估平台上順利執行。
複雜度評估平台資訊 處理器 Intel Pentium® III 866MHz
作業系統 Microsoft Windows XP Professional SP2 開發工具 Microsoft Visual Studio 6.0 SP5
原始碼 Fraunhofer IIS MP3 Decode, Rev. 4.1
圖表 13 複雜度評估平台資訊圖
CPU 資源之步驟及其所相對應的 C 程式碼部份，然後在後面的章節中將再 繼續針對最消耗 CPU 資源之程式段，嘗試使用軟體或硬體將其最佳化之可 能性。所謂最消耗 CPU 資源的程式碼部份，也意味著程式執行的時間較長； CPU 資源之計算是以 MIPS(Million Instructions Per Second)為單位，MIPS 與 程式執行時間(Execution Time)及指令執行數(Instruction Count)之關係如下 列公式(5)，其中 MIPS 與程式執行時間成反比，與指令執行數成正比；在 MIPS 固定下指令執行數與程式執行時間成正比，也就是指令執行數值愈大 則程式執行時間愈長；將公式(5)整理後得到公式(6)，在 MIPS 數固定下， 指令執行數與程式執行時間成正比，所以程式執行時間將可視為 CPU 資源 消耗之參考指標[9]。 6 10 × = Time Execution Count n Instructio MIPS (5) 6 10 × = MIPS Count n Instructio ime ExecutionT (6) MP3 解碼器大致可分為同步位元流(Synchronization)、解開編碼框 (Frame Unpacking)、重建(Reconstruction)和合成濾頻(Synthesis Filtering) 四 個處理功能區塊，分析 MP3 軟體程式可將各功能區塊再詳細分成幾個軟體 處理程序[6]，詳細請參考於圖表 14 之 MP3 軟體解碼器流程圖。
取材自：ISO/IEC 11172-3[7] 圖表 14 MP3 解碼軟體流程圖 圖表之左方為 MP3 解碼軟體流程區塊圖，而右方則標示與 MP3 四大 功能區塊圖相對應之部分，詳細之功能區塊說明請參考 3.1。
4.1.2 MP3 解碼器軟體分析
依照 MP3 軟體解碼流程進行軟體區塊執行時間分析，MP3 音樂檔案採 用下載自網頁[14]之 MP3 檔案作為測試位元流輸入樣本，只選擇其中取樣 率為 44.1kHz 且為 MPEG-1 Layer-3 之 Funky.mp3、Spot2.mp3、Spot3.mp3 三檔案為輸入測試位元流；同時也擷取歌曲 Song1.mp3 及樂曲 Cello1.mp3 做為輸入測試位元流，各 MP3 位元流詳細檔案格式請參照圖表 15。檔名 (.mp3) 取樣頻率 (kHz) 位元速率 (kbit/s) 壓縮等級 (MPEG-1) 長度 (min.) 檔案來源
Funky 44.1 kHz 96 kbit/s Layer-III 1:02 J. Here (FhG) Spot2 44.1 kHz 96 kbit/s Layer-III 0:11 OMNI-MEDIASOUND Spot3 44.1 kHz 96 kbit/s Layer-III 0:11 OMNI-MEDIASOUND Song1 44.1 kHz 128 k bit/s Layer-III 5:08 Sacrifice by Elton John Cello1 44.1 kHz 48 kbit/s Layer-III 2:36 Abendlied by R.Schumann
圖表 15 MP3 測試位元流檔案格式表 首先，針對 Fraunhofer IIS MP3 解碼程式原始碼進行追蹤，紀錄所有軟 體程序(Procedure)個別之執行時間，再比較各 MP3 軟體程序之執行時間的 長短就可以篩選出確切消耗 CPU 資源較多的軟體程序段，這裡將列出那些 MP3 解碼軟體程序段，它們的執行時間總和佔 MP3 解碼程序執行時間約 99.56%者；詳細請參考圖表 16，第一行表示在 MP3 原始程式碼中，相關 之軟體程序名稱，第二行到第六行表示是各個 MP3 測試位元流經追蹤計算 後，在各個軟體程序上所所消耗總執行時間之百分比，第七行表示將所有 測試位元流的各個特定軟體程序執行時間加總後之平均值，依其所佔用總 執行時間的百分比表示之。
程序名稱/位元流 Funky Spot2 Spot3 Song1 Cello1 平均 Decode 3.89% 4.50% 5.67% 5.05% 5.23% 4.79% Dequantize 24.82% 26.25% 24.13% 26.03% 25.83% 25.41% Stereo 2.81% 2.38% 1.44% 0.40% 0.54% 1.51% Reorder 0.25% 1.06% 0.24% 0.35% 0.26% 0.30% Antialias 0.44% 0.26% 0.24% 0.34% 0.22% 0.30% Hybrid 47.75% 46.44% 42.07% 47.90% 47.52% 46.34% SubBandSynthesis 17.72% 16.98% 17.02% 17.74% 18.13% 17.52% 圖表 16 MP3 軟體解碼流程區塊執行時間對照表 Decode(解碼)軟體程序的執行時間用於解譯位元資料流中之檔頭、錯 誤偵測碼和附屬資料以及作 MP3 位元流同步的動作，而且將依據附屬資料 中所記載的霍夫曼(Huffman)資訊、比例因子(Scalefactors)資訊及位元儲藏 處(Bit reservoir)資訊去解碼位元資料流中之主要資訊，也依據霍夫曼資訊對 主要資訊中之霍夫曼碼之資料進行解碼功能；由實驗數據獲得，本軟體區 塊佔用 MP3 解碼程式的總執行時間約 4.79%。 Dequantize(還原量化) 軟體程序的執行時間主要用於重建經 MP3 編碼 非均勻量化器(Non-Uniform Quantization)量化後之數值， Fraunhofer IIS MP3 解碼軟體使用查表方式進行還原工作，由實驗數據獲得，本軟體區塊 佔用 MP3 解碼程式約 25.41%之執行時間。
Stereo(立體聲處理) 軟體程序的執行時間主要用於依據檔頭中所記錄 音 訊 模 式 (Mode) 為 立 體 聲 (stereo) 、 雙 聲 合 一 (joint_stereo) 、 對 偶 聲 式 (dual_channel) 或單聲式(single_channel)進行不同之處理，如為 Layer-3 之位 元流則搭配檔頭中之模式延伸(mode_extension)標記，然後決定使用何種雙
聲合一(joint_stereo)之模式，本軟體區塊佔用 MP3 解碼程式約 1.51%之執行 時間。
Reorder(重組) 軟體程序的執行時間主要是在回復短窗(short window) 之頻譜位置；因為改良型餘弦(MDCT)採用短窗(short window)及長窗(long window) 兩種區塊編碼型態，而它們在經MDCT 轉換之後，這兩種型態經 MDCT 轉換之後其頻譜的排列方式不同，為使霍夫曼編碼能更加有效率， 因而在進行霍夫曼編碼前，將短窗之頻譜的位置重新排列而長窗編碼則不 受影響，本軟體區塊佔用MP3解碼程式約0.30%之執行時間。 Antialias(逆假像) 軟體程序的執行時間主要是進行還原假像之處理程 序；在 MP3 編碼時，因為分析濾波器排(Analysis Filter Bank)會將原始輸入 的 PCM 音訊，轉換成 32 個等頻寬的子頻帶訊號(Subband Signals)；由於分 析濾波器排之特性，當原始音訊被分成 32 個子頻帶時，在頻譜上可見鄰近 的子頻帶間有明顯的重疊現象，所以在經過 MDCT 轉成頻線訊號時，需對 鄰近相對應的頻線訊號作假像處理，其方式是將處在相對應位置的頻線能 量做一定比例的增減；逆假像處理是做其反向步驟，本軟體區塊佔用 MP3 解碼程式約 0.30%之執行時間。 Hybrid(混合濾波) 軟體程序的執行時間主要是針對 Layer-3 所特有的 混合濾波器排進行反相處理程序；MP3 編碼動作，以單聲道而言，MP3 的 一個編碼框(Frame)有 1152 個聲音取樣，而一個編碼框又分成兩個單位 (Granule)，所以每個 Granule 有 576 個時域樣本；Layer-3 編碼為了要提高 頻譜之解析度，將原始音訊經過分析濾波器排所分成 32 個等寬的子頻帶訊 號；經由改良式離散餘弦轉換 MDCT(Modified Discrete Consine Transform)， 再細分成 18 個頻線訊號；MDCT 的運算包括 MDCT 窗框、DCT 及常窗框 假像處理三部分[20]。本軟體區塊就是將位元流進行 MP3 編碼時之處理程 序做還原處理動作，佔用 MP3 解碼程式約 46.34%之執行時間，詳細 MP3 解碼混合濾波器示意圖請參考圖表 17。
取材自：ISO/IEC 11172-3[6] 圖表 17 MP3 解碼器混合濾波器示意圖 SubBandSynthesis(多相濾頻器合成) 軟體程序的執行時間主要是將 IMDCT所產生之32組向量值，依序經由搬移、矩陣相乘及加總運算，最後 將原始PCM音訊還原回來，本軟體區塊佔用MP3解碼程式約17.52%之執行 時間。 由 MP3 軟 體 解 碼 流 程 區 塊 執 行 時 間 對 照 表 中 之 實 驗 數 據 得 知 ， Hybrid(混合濾波) 軟體程序之執行時間最長，佔整體執行時間之46.34%， Dequantize( 還 原 量 化 ) 軟 體 程 序 的 執 行 時 間 次 之 ， 佔 整 體 執 行 時 間 之 25.41%，SubBandSynthesis(多相濾頻器合成) 軟體程序的執行時間為第三， 佔整體執行時間之17.52%，這三個軟體程序的執行時間總和約佔MP3軟體 解碼程式執行時間之89.27%，也就是最消耗CPU使用率的軟體程序碼，因 此將列為最優先考量進行最佳化之MP3軟體解碼程式段。
4.2 硬體實現
從觀察Fraunhofer IIS MP3解碼軟體區塊流程圖可得知， 在MP3解碼軟 體中運用相當多的數學運算如Hybrid(混合濾波)及Dequantize(還原量化)，大 約消耗MP3軟體解碼程式71.75%的執行時間，然而在866MHz 32位元Intel Pentium III CPU的開發環境下，可以使用x86的浮點運算功能來完成與數學運算相關之處理程序；但是數位照片儲存盒是使用60MHz 8位元的8051微控 制器，而它只具備簡易之算術與邏輯運算指令的能力，如以CPU位元數相 差32/8=4倍與CPU速度相差866/60≅14.4粗略概算，其執行時間大約會增加 4×14.4=57.6倍，因此原數位照片儲存盒之8051微控制器之運算能力已明顯 不符合數位音樂儲存盒之需求，所以在盡量重覆使用原數位照片儲存盒設 計之智財(IP - Intelligent Property)、低成本及準時上市的前提之下，必須為 數位音樂儲存盒之系統架構尋求最佳之解決方案。 以下將提出三個方案進行可行性評估，同時在下文中進行各方案之分 析與評估： 方案 描 述 一 以 16 位元之數位訊號處理器取代 8 位元之 8051 微控制器，保留 原讀卡機之 IP 功能。 二 保留原數位照片儲存盒之 IP 功能，新加入 16 位元之數位訊號處 理器專門處理有關 MP3 解碼功能，即 8051 與數位訊號處理器雙 核心架構。 三 保留原數位照片儲存盒之 IP 功能，設計新硬體，使其專門處理 MP3 解碼相關功能。 圖表 18 MusicBank 可行三方案圖表 方案一的提出，主要是以數位訊號處理器取代8位元之8051微控制器， 以彌補8051微控制器運算能力不足的缺點，同時又能保留原讀卡機之IP功 能，減少軟體及硬體對讀卡機IP重新設計之開發時間，通常解決讀卡機相容 性問題在開發及測試階段往往是最耗費時間的程序之一。 方案二的提出，主要是基於完全保留原數位照片儲存盒之微處理器以 容易保留原硬體及軟體IP以縮短重新開發、測試及認證之時間，而以數位訊 號處理器由韌體提供MP3解碼器所需之能力以符合數位音樂儲存盒所要求 之功能，因此為一雙核心架構系統設計。
方案三的提出，主要是基於成本及提早上市之考量，期望完重覆使用 原數位照片儲存盒之硬體及軟體IP設計，而將重新設計之部分，僅只侷限於 MP3硬體相關之設計，以縮短開發及產品上市時程。
4.2.3 單數位訊號處理器系統架構
方案一：以 16 位元之數位訊號處理器取代 8 位元之 8051 微控制器，保留 原讀卡機之 IP 功能。 從 MP3 解碼器軟體分析中得知，8051 微控制器運算能力已不足以供 給 MP3 解碼軟體所需之運算能力；因此在系統架構設計之微控制器部分， 將以數位訊號處理器取代原 8051 微控制器，然後以數位訊號處理器所提供 之數位訊號處理相關指令，用來加速 MP3 解碼時所使用之大量數值運算； 在此架構下盡量保存原讀卡機之硬體 IP 以利重覆使用已開發測試完成之韌 體，縮短軟體開發、認證及測試時間。請參考方案一單數位訊號處理器圖 表 19。 圖表 19 單數位訊號處理器系統架構圖 數位音樂儲存盒為一SoC設計，本架構所採用內部代號MicroDSP Gen 1 特 定 應 用 可 程 化 之 數 位 訊 號 處 理 器 (ASPDSP – Application SpecificProgrammable DSP) IP為處理器，它提供16 Bits Fixed-Point資料格式及24 Bits指令集格式，具有16×16乘法器、算數/邏輯/移位執行單元、條件執行單 元、32K words/24Bits可分頁之程式記憶體(Program Memory)、最多64K words/16Bits資料記憶體(Data Memory)等；所搭配的開發工具內部名稱為 OSCAR環境，請參考圖表 20： 方案一開發環境資訊 處理器 VIA MicroDSP Gen. 1 作業系統 No OS
開發工具 Oscar Toolset
原始碼 Fraunhofer IIS MP3 Decode, Rev. 4.1
圖表 20 方案一開發環境資訊圖
依據 MP3 解碼器軟體分析之數據顯示，對於大量使用數值運算處理音 訊之軟體程序段如混合濾波(Hybrid)、還原量化(Dequantize)、多相濾頻器合 成(SubBandSynthesis)部分，則以 MicroDSP Gen. 1 數位訊號處理器之指令集 加以改寫，值得注意的是，原 Fraunhofer IIS MP3 解碼軟體是利用 x86 32Bits 浮點運算及 C 語言程式碼設計完成，而 MicroDSP Gen 1 數位訊號處理器本 身並不支援浮點運算功能，因此必須先將原 Fraunhofer IIS MP3 解碼軟體 32Bits 及 64Bits 浮點運算部份，以 MicroDSP Gen 1 之 16Bits 及 32Bits 固定 點整數運算重新加以改寫；因為 OSCAR 工具組可支援 C 及 Assembly 語 言，所以將進行兩階段的改寫工程，第一階段先將原 Fraunhofer IIS MP3 解 碼軟體以 C 語言將浮點運算部份以 MicroDSP C 語言之固定點整數運算改寫 完成，第二階段再以 MicroDSP C 語言改寫後之 MP3 解碼軟體與大量數值 運算有關的程式碼部份，以 MicroDSP Assembly 語言改寫使其能直接運用 MicroDSP Gen1 所提供之數值運算指令，以便增加 MP3 解碼器整體效能且 縮小程式記憶體(PM)及資料記憶體(DM)之使用量。
OSCAR 工具組提供軟體模擬(Simulation)功能，因此可以在軟體模擬 的環境下，先行估算韌體程式所需使用程式記憶體(PM)及資料記憶體(DM) 之大小及 MP3 解碼整體運作時微處理器所需之最小頻率，因此將原 Fraunhofer IIS MP3 解碼軟體以 MicroDSP C 及 Assembly 語言經兩階段改寫 後，在 OSCAR 工具組模擬環境下，所得到的 MP3 解碼流程區塊執行時間 之分析數據請參考圖表 21，第一行表示在 MP3 原始程式碼中，相關之軟 體程序名稱，第二行到第六行表示各測試位元流計算得到 MP3 解碼相關軟 體程序執行時間所占全部執行時間之百分比，第七行表示將所有測試位元 流的各個特定軟體程序執行時間加總後之平均值，依其所佔用總執行時間 的百分比表示之。
程序名稱/位元流 Funky Spot2 Spot3 Song1 Cello1 平均 Decode 15.60% 14.80% 16.50% 22.30% 22.40% 18.32% Dequantize 11.40% 11.10% 11.50% 12.30% 12.80% 11.82% Stereo 27.70% 27.20% 29.50% 24.60% 27.60% 27.32% Reorder 10.40% 13.20% 5.80% 3.80% 0.70% 6.78% Antialias 0.70% 0.60% 0.80% 0.80% 0.90% 0.76% Hybrid 16.00% 16.10% 16.00% 15.50% 15.70% 15.86% SubBandSynthesis 17.80% 17.00% 19.40% 20.00% 19.30% 18.70% 圖表 21 MicroDSP MP3 解碼流程區塊執行時間對照表 值得注意的是在經過兩階段程式改寫之後所消耗微處理器資源的 MP3 軟體程式區塊分布情形已與 x86 MP3 解碼程式所消耗微處理器資源不相 同，其微處理器資源消耗量較大的前三個 MP3 解碼軟體程序依序為 Stereo(立體聲處理) 軟體程序、SubBandSynthesis(多相濾頻器合成) 軟體程 序及 Decode(解碼) 軟體程序，消耗 CPU 使用率的軟體程序碼已由原先之數 值運算量大之軟體程序段在使用數位訊號處理器之後而變成資料處理軟體
程序段。 圖表 22 MicroDSP MP3 解碼程式記憶體使用圖 在 OSCAR 軟體擬環境下，可分別估算 MP3 解碼程式執行後其程式記 憶體(PM)、資料記憶體(DM)及暫存記憶體(TM)所使用的情形，請參考圖表 22，第一行表示 MP3 解碼程序名稱，第二行表示各程序程式記憶體(PM)所 使用的情形，第三行表示各程序資料記憶體(DM)所使用的情形，第四行表 示各程序暫存記憶體(TM)所使用的情形，圖中各欄位的數字以 word 為單 位，程式記憶體(PM)的一個 word 為 24Bits 即 3Bytes，資料記憶體(DM)及 暫存記憶體(TM) 的一個 word 為 16Bits 即 2Bytes，第一列 Total 則表示 MP3 解碼軟體程式記憶體(PM)、資料記憶體(DM)和暫存記憶體(TM)的總使用 量，經過換算程式記憶體(PM) 所使用的大小請參考公式(7)，資料記憶體 (DM)所使用的大小請參考公式 (8)及暫存記憶體(TM) 所使用的大小請參 考公式(9)。
KBytes Bytes words PM =11915 =35745 ≅34.91 (7) KBytes Bytes words DM =19321 =38642 ≅37.74 (8) KBytes Bytes words TM =10463 =20926 ≅20.44 (9) 在 OSCAR 軟體模擬環境下，可以估算播放某首歌時所需 MicroDSP 處理器之週期數(Cycle)，週期數是 MicroDSP 指令最小的執行單位，請參考 圖表 23。圖中第一行表示程序名稱，第二行表示執行週期數，第三行表示 所佔總執行週期數之百分比，第四行表示主程序與子程序週期數間之百分 比關係，第五行是該程序所執行的次數。
圖表 23 OSCAR 模擬播放 MP3 歌曲所需 MicroDSP Total Cycle 圖
依據 OSCAR 模擬環境所得之週期數，可以估算處理器所須之運算能 力，MP3 位元流定義 1 編碼框(Frame)有 2 個 Granules，每個 Granules 有 32 個等寬頻的子頻帶訊號，每個子頻帶訊號再細分為 18 個次頻帶，請參考公 式(10)，在單數位訊號處理器系統架構中的 MicroDSP 將設計以每一 Cycle 輸出 32 個 Samples，計算播放一歌曲以每 32 Samples 為一 Cycle 處理單位，
則所需之 Cycle 數如(11)公式。 Samples Subband per Samples Subband Granules Frame 1152 ) 18 32 ( 2 2 1 = × × = = (10) ) 32 / ) / ((
32Samples Total Cycles Frames Samples per Cycles = (11) 以下列 MP3 音樂檔為測試位元流輸入樣本，在 OSCAR 模擬環境所得 到的各項估計數值請參考圖表 24，第一列代表 MP3 測試位元流，第二列 代表各位元流所包含之編碼框(Frame)總數、第三列代表 MicroDSP 執行測 試位元流之總週期數(Total Cycles)及第四列代表將第三列之總週期數換算 成以 32 Samples 為 1Cycle 處理單元後之總週期數(Cycles(32S))。
Funky Spot2 Spot3 Song1 Cello1
Frames 2374 439 451 7533 5987
Total Cycles 615,594,659 564,231,618 502,411,953 560,101,079 504,306,245 Cycles (32S) 8.103×103 4.0164×104 3.4812×104 2.323×103 2.632×103 平均週期數(以 32 Samples為 1 Cycle) ：1.7607×104
圖表 24 OSCAR 模擬播放 MP3 歌曲 Cycle 數(32Samples per unit)圖
由以上平均週期數，可以估算所需處理器之頻率約 24.27MHz，請參考公式 (12)。 MHz Cycle Freq MicroDSP 27 . 24 .) sec / ( 875 . 24264646 ) 10 1 . 44 ( 32 10 7607 . 1 . 3 4 ≈ = × × × = (12) 在 OSCAR 模擬環境中所估算單數位訊號處理器系統架所需最小資源為，程 式記憶體(PM) 34.91KBytes，資料記憶體(DM) 37.74KBytes，暫存記憶體(TM) 20.44KBytes 及數位訊號處理器時脈 24.27MHz。
4.2.4 雙核處理器系統架構
方案二：保留原數位照片儲存盒之 IP 功能，新加入 16 位元之數位訊號處理 器專門處理有關 MP3 解碼功能，即 8051 與數位訊號處理器雙核心架構。 從 IP 重覆使用最大化之考量，最理想的狀況為維持原數位照片儲存盒系統 架構，然後加入數位訊號處理器專門處理 MP3 解碼器功能，也就是採用雙 核心架構，請參照圖表 25。 uDSP DM Bus PM Bus ROM SRAM SRAM SRAM SRAM SRAM SRAM SRAM DMAC SRAM SRAM ATA/ATAPI IF CF/LCD IF MS/MSPro IF SD/MMC IF SM/xD IF USB AudioI2C SPI LCD Key RTC
8051 MC IPC Bus System Bus 圖表 25 雙處理器系統架構圖 在 SoC 系統架構下，記憶體的大小和成本是成反比，所以在架構設計 上必須考量將記憶體大小的使用最小化，因此在雙核心系統架構中將採用 共 用 記 憶 體 控 制 模 組 (MC-Memory Controller) 及 DMA 控 制 模 組 (DMAC-DMA Controller)，以便共享記憶體，同時也設計處理器內部交換匯 流排(Inter-process Communication Bus – IPC Bus)做為雙核處理器之間訊息 交換的通道。
處理器為主處理器(Master Processor)，而 MicroDSP 數位訊號處理器為從處 理器(Slave Processor)，所以原數位照片儲存盒所開發之韌體則只需要小部 份的修改，仍然能持續運作於 8051 微處理器上；當遇到有 MP3 音樂檔案 解碼要求時 8051 則利用 IPC 介面通知 MicroDSP 做進一步之資料處理，而 MicroDSP 在處理動作結束之後就立即經由 IPC 介面，通知 8051 做後續之 處理；8051 在送出 MP3 音樂檔案解碼要求後，則可處理其他的要求，以增 加 8051 微處理器之使用率，直到接受到 MicroDSP 完成要求之回報。 雙核心處理系統架構中有 8051 微處理器及 MicroDSP 數位訊號處理器 各一顆，硬體及軟體規格維持與原位照片儲存盒幾乎相同之設計，除了設 計內部交換匯流排、加大記憶體、局部修改記憶體控制模組及 DMA 控制模 組之外，對使用 MicroDSP 數位訊號處理器設計 MP3 解碼部分之硬體需求 則可參考方案一中對記億體及微處理器時脈所作之預估值，本架構之目的 主要是期望能大幅縮短設計時間。
