再探嵌入式處理平台
作者：Robert Cravotta，技術編輯 ，EDN雜誌
在 2002 年的第 4 季時，我以TI 公司的 OMAP（Open Mobile Application Processor，開放式行動應用處理器）平台進行了一項實做計畫，並採用了Innovator 的開發工具組。本文正是源自上述工作的一項成果，介紹了我在使用該平台以及 TI 公司圍繞它所構建起開發生態系統方面的經驗，而且還簡要地討論到了在使用矽晶片和軟體相關的事前準備工作（preproduction）之問題。本質上，這是一篇關於早期採用者的報導（參考文獻 1）。
時間快速推回到 2005 年 10 月，TI 宣佈了它的 Davinci 技術產品，並宣佈將在該技術首次展示後的幾個月內，進行實用產品展示。Davinci 器件與 OMAP 器件共用一個相似的架構：它們都在單一器件中整合了 ARM 核心和 TI DSP 核心。用這種新型平台來進行實做計畫，使人們有機會再次嘗試在類似的複雜處理平台上進行開發，並瞭解支援它的開發生態系統在最近幾年的發展。複雜的處理平台並非 TI 獨有，因此我還為該計畫去瞭解其他半導體公司所提供的平台，以便明瞭用這些複雜處理平台進行開發的新興潮流。
我從中瞭解到的一件事情是：對於這些平台而言，雖然矽晶片整合是整個行銷訴求中的一個重要部分，但平台供應商所提供的軟體資產和工具正逐漸使其黯然失色，或者將會使矽晶片黯然失色，以贏得夢寐以求的設計任務。上述聲明並非企圖貶低硬體整合工作的價值和複雜性，而是要認識到軟體資產和工具日益增加的重要性。這種軟體簡化了軟體工作日益提高的複雜性，是各款整合情況和功能越來越相似的矽晶片之間的主要差異性。
根據 iSuppli 的資料顯示，到 2010 年，整個半導體市場（不包括記憶體、類比器件、顯示器驅動器）將從目前略微超過 1,080 億美元的規模，成長到 1,630 億美元，而以處理器為基礎的產品將擁有該市場 88% 左右的佔有率（參考文獻 2）。所有這些基於處理器的設計都需要軟體的協助。TI 公司 DSP 首席院士及業務開發經理 Gene Frantz 在一份新貼在部落閣中的文章中提出：“對SOC（systems on chip，系統單晶片）的一項新的詮釋是：S 更可能是代表軟體 （software）而不是系統 （system)。”
Xilinx公司的嵌入式處理產品行銷經理 Jay Gould 表示：“特定專案的軟體工程師數量也許是硬體工程師的二至五倍或更多。”NXP Semiconductors 公司標準 IC 業務產品創新總監 Ata Khan 和 Atmel 公司 BiCMOS 產品總監 D Chris Baumann 也都指出：“對於複雜處理應用而言，我們客戶的軟體發展工作占其專案發展全部時間和預算資源的 70% 至 80%。”這個比例意味著軟體發展資源相當於這些複雜處理應用的硬體開發資源的 2.5 至 4 倍。
對軟體越來越重視的部分原因是在於：隨著處理器技術的每一次進步，就有更多的軟體指令週期可用來為特定應用在每個樣本週期（per sample period）執行新的增值處理。例如，據 Frantz 表示，在 1982 年，電信系統借助 5MIPS 的處理器，能在每個樣本週期利用 625 個指令週期。現今的 DSP 能在每個樣本週期執行數十萬個指令週期。接下來，他還提到了音頻和視頻應用的情況，雖然每個樣本週期的指令週期較少，但也有類似的進步。
軟體所提供的靈活性是這些平台為開發者所提供的一項重要機制，以便可以讓他為為其設計增添差異化的特性和功能。另一項促使嵌入式系統軟體資源分配量日益增加的因素是我作為嵌入式軟體和系統設計師所學到和採用的一則公理。對於任何問題，無論其根源如何，如果軟體能檢測出狀況，能針對它進行調整，能把它的影響減到最低程度，或者甚至改正這種狀況，那麼根據定義，它就是一個軟體問題。這則公理的真實性源於以下事實：除了在執行複雜的串列操作方面比純硬體實施有更高效率以外，一旦有硬體存在，軟體在更改方面也幾乎總是比硬體來得更容易、更快、也更便宜。
該公理的結果就是，在設計計畫的後期階段出現的多數故障，都會直接進入並消極地影響軟體的發展工作。這個事實提高了軟體的複雜性，使它遠不僅只是要滿足原始產品的規格，這是因為軟體現在必須盡可能在不改變硬體的前提下，適應意料之外的環境和製造變化因素。軟體發展團隊在化解該公理的挑戰方面的成敗，經常代表著成功設計和失敗設計之間的區別。
Davinci 與 OMAP 的比較
Davinci 器件和 OMAP 器件都有一些相似之處。它們都採用結合 ARM 核心與 TI DSP 核心的異類處理（heterogeneous-processing）架構。它們都支援標準應用編程介面（application- programming interface，API），這些 API 把駐留在每個核心的代碼的開發和執行都封閉（encapsulate）和隔離起來。對於這兩個器件家族，應用程式設計工程師可以使用他們熟悉的、以 ARM 核心為目標的工具，不必成為 DSP 專家就能利用整合的 DSP 核心。同樣，DSP 程式設計工程師可以使用他們熟悉的、針對 DSP 核心的工具，而不必去瞭解 ARM 核心。Davinci 和 OMAP 器件都使用屬於 TI 第三方網路的一部分、且符合 eXpressDSP 的演算法，並且都支援一種主要的執行模式，它讓 ARM 扮演主控者（master）的角色，把 DSP 代碼當作輔助運算器或一種從屬的角色。
但是，Davinci 技術與 OMAP 平台的區別是在於，Davinci 的目標是數位視頻和音頻應用，而不是行動應用，並且在軟體發展支援方面，它是超越 OMAP 的革命性的一步。由於目標應用不同，這兩種平台使用不同的 DSP 核心。OMAP 採用功率效率高的 C55x DSP 核心，而 Davinci 採用高性能的 C64x DSP 核心。另外，OMAP 器件使用 ARM925 核心，而 Davinci 器件使用 ARM926 核心。兩組器件都整合了適合各自目標應用領域的不同周邊組（peripheral set）。Davinci 器件中的整合式周邊組包括視頻處理子系統、串列介面和連接介面，以及幾個記憶體介面和儲存設備介面（圖 1）。目標應用領域的不同，讓這兩種平台之間產生了上述的差別。
Davinci 平台建立在 TI 公司從 OMAP 系統所學到的技術和商業教訓基礎。例如，Davinci 平台用 xDM 或 xDAIS-xDM（數位媒體專用 xDAIS）介面擴充了 xDAIS（eXpressDSP 演算法互通性標準）。 該介面影響著每個程式設計工程師對 Davinci 或 OMAP 系統的職責：對 ARM 的應用職責和對 DSP 的信號處理職責。但是，該介面是應用程式設計工程師用來載入、卸載和使用裝載在 DSP 核心的演算法的機制。xDM 的一個重要目標是在各類演算法和來源或廠商之間，為多媒體編解碼器實現一種隨插即用的架構。它為每種多媒體編解碼器定義了公共狀態和參數，以便在無須改變應用程式原始碼的前提下，用一種編解碼器來代替另一種編解碼器，只有編解碼器的配置代碼需要改變。
xDM 標準為視頻、影像、語音、音頻這四種編解碼器類別定義，並為 xDAIS 規範增添了一組統一的 API。xDM 的 8 個普通介面是由上述各個編解碼器類別的編碼器和解碼器所組成。xDM 還支援元資料解析（metadata parsing）、檔案格式、定制處理等要求的擴充。這些 xDM API 為 xDAIS 定義的函數組增添了兩個新函數——process（）和 control（)。xDAIS 和 xDM 元件中的介面函數之呼叫命令（call order）很相似，唯一的例外是 xDM 取消了 algControl（）方法。在和 xDM 演算法一起使用 xDAIS 演算法時，xDM control（）方法代替了 algControl（）方法。
與 OMAP 的首次展示不同的是，Davinci 評估模組包括三種預先接線的（prewired） DSP/編解碼器組合，開發者可在工作中使用它們。內含這些預先接線的編解碼器，使開發者不必等待支援生產的（production- supported）編解碼器的實現，就能評估系統的功能。這種評估模組包含一套工具組，它包括照相機、LCD、紅外線遙控器、揚聲器、硬碟驅動器（圖 2）。該工具組包括了已儲存在硬碟驅動器上的實用展示，以便能立即使用系統的編碼、解碼和聯網功能。
Davinci 和 OMAP 平台在首次展示方面的另一個區別是 ARM 核心的晶片級和板級開發資源的立即使用能力。Davinci 評估模組還包含開發工具和文件，以便讓這些展示可以開始與運作。TI 公司之所以能包含這些元件，部分的原因是在於把開發環境限制在 Linux。DSP 核心專用開發工具是 Code Composer Studio 工具套件的一部分。TI 公司在 2006 年 9 月底發佈了兩種工具來支援那些借助 Davinci 器件進行的開發。eXpressDSP 配置工具可幫助開發者把 xDM 編解碼器整合到編解碼引擎中，而在以前，系統整合商是人工的方法來執行該過程。另一種新工具是侵入性最小的 TMS320DM644x SOC 可視分析儀，它為單一時間線上的 ARM 核心和 DSP 核心擷取和顯示資料，以便提供應用行為的系統視圖（system view）。
任何數量的文件都無法取代直接以這些複雜平台來工作：該計畫說明了期望和現實之間的某些無關聯性。藉著我從前一個平台實做計畫中所學到的教訓，我去參加了一場 Davinci 技術研討會。我以為這場一整天的會議將是一場實做研討會，但是，我錯了。（第一場為 Davinci 舉行的實做技術研討會是在我完成該計畫之後，並且就在本文英文稿付印之前舉行的。）該技術研討會介紹了此一平台在技術和商業方面的訊息，但卻沒有實做部分的內容。我對這次研討會上介紹的 Linux 實施細節的數量感到驚訝。後來，當我在辦公室裡拿到一片 Davinci 評估模組供工作使用時，我明白其中的原因了。
該研討會的上半部分充份地說明了系統元件和各種周邊的概況，特別是視頻處理子系統使用的一些編碼實例。我們瞭解了 Davinci Framework API 以及各個處理層的高層級部分（high-level portion）：應用、信號處理、編解碼引擎、第三方軟體。概況的說明還包括了支援每個編程層的內部以及第三方開發工具。當天的其餘時間是第三方授權軟體供應商所發表的演講。
數個星期之後，我收到了一組 Davinci 評估模組，可在工作中使用。讓系統各個部分連接起來以及讓各展示正確地運行，是一個快速而又輕鬆的過程。我之所以能讓展示迅速地開始運作，一個重要的原因是，所有軟體都駐留在硬碟驅動器中。而好事就是我在設定自己的工作台之前，能確認每個元件和介面恰當連接並且正確地運行。
當我去設定自己的工作場所時，我嚇到了。我做過很多跨平台的開發工作。對於該計畫，我知道自己將以 Linux 作為開發的目標。但是，我當時不知道自己將在 Linux 開發主機上工作，我以為自己將能在 Windows 開發主機上工作。評估模組最初的所有工具都只在 Linux 主機上工作。Montavista 公司供應該開發工具，因此我在 Montavista 公司的網站上找了一下，以便確認它還支援除了 Linux 之外的主機環境。該公司的開發工具支援 Linux、Solaris、Windows 開發主機。
TI 公司的支援人員告訴我：Davinci 工具只支援 Linux 開發主機。我不想在自己的電腦上安裝 Linux。這件事和不喜歡 Linux 無關，畢竟，Linux 將是目標作業系統。它完全是關於在為該計畫的低價值工作所花的時間、精力和思考。我不打算在我的主機系統上繼續使用 Linux，並且我需要充分瞭解針對該目標的 Linux 配置。但是，我沒有時間來重新學習主電腦的作業系統。在 Linux 主機環境中工作將加長我的學習曲線，不會幫助我瞭解目標上的 Linux。
幸運的是，TI 支援部門寄給我一份 Red Hat Linux 映射，並授予我一份用於此一計畫的授權許可，這樣我就能在自己的電腦上以 VMware 播放器來模擬 Linux。這個幫助讓我可以不用以人工的方式來設定自己電腦的雙重啟動（dual boot），並能以更快的速度來進行該計畫。
我知道如何在運行 Windows 的電腦上找出資料檔案和應用程式。這些應用程式按照我的期望運行和互通（interoperate）。關於這些應用程式如何表現，我在過去多年來學到了很多的經驗。模擬 Linux 並不是一件會讓人人精疲力竭的經歷，但它的行為與 Windows 應用程式還是有一些不同。例如，我使用 Gnome Ghostview 來閱讀所提供的 Adobe Acrobat 文件。我一直想不出我是否能在這個瀏覽器中執行簡單的文字串（text-string）搜索。我本來可以在網上搜索不同的瀏覽器，但既然我已經有了一種完全可接受的瀏覽器，那為什麼還要這麼做呢？
評估模組只支援 Linux 主機，這是因為 Davinci 工具團隊想讓這些工具與評估模組同時就緒。另外，TI 也預期多數早期採用者都使用 Linux 目標，並且具有 Linux 作為開發主機環境方面的經驗。TI 工具部門承認：對其他主機開發作業系統的支援是下一步工作。正如結果所顯示的那樣，對於 TI 支援團隊而言，使用 Linux 也是一次重要的學習過程，這是因為它以前在工作中沒用過 Linux，並且在該公司開始在將Davinci 評估模組付運給客戶之前，該團隊需要熟練掌握 Linux 系統。
專案計畫是利用編碼、解碼、聯網展示代碼來設計一款初步的視頻電話。有一個問題是：我只有一片 Davinci 評估模組，因此無法即時執行展示。我只好在每次運行時模擬系統的一端或另一端。第一塊評估模組的獲得是一次挑戰，TI 公司只提供有限的數量。並且沒有足夠的時間來獲得第二塊模組。另一個問題是，隨著該模組的編碼和解碼範例，要嘛處理語音資料，要嘛處理視頻資料，就是不同時處理兩者，因此我沒有關於如何使兩者同步的範例。在與 TI 的工具部門交涉時，我得知該公司正在研究把 GStreamer 媒體處理庫作為框架來幫助實現音頻和視頻同步以及其他功能。GStreamer 高於普通庫（library）的水平。在該計畫的後期，我利用它的視頻電話展示，開始在工作中使用 Ittiam。
對於該專案，我還嘗試了 Green Hills Software 公司的 Davinci 專用之 Probe 和 Multi 開發環境。Probe 是一種連接到 Davinci 的硬體除錯設備。儘管 Green Hills Software 公司的 Multi 正常情況下支援在 Windows、Linux、Solaris、HP-UX 主機系統上的開發工作，但在該計畫進行期間，各種 Davinci 工具只在 Linux 下工作。Multi 整合開發環境支援從應用、DSP、到系統每個編程層次的需要。借助 Probe，Multi 讓使用者能觀察 ARM 核心和 DSP 核心，並支持 Linux 內核感知（awareness）。我能夠直接追蹤進入 Linux 內核，方法是在除錯資訊開啟的前提下構建 Linux 內核映射，然後用 Green Hills 公司的 dblink 工具來翻譯DWARF 除錯資訊，此一除錯資訊是GCC (GNU Compiler Collection)所產生的一種Multi可以理解的除錯格式。
Multi 把進程除錯分隔成若干視窗，每個視窗都有自己的背景顏色。該特性在使用處理內容中斷點（process-context breakpoint）時很有用，這時，只有當代碼的中斷點行作為規定處理過程的一部分在執行時，才會停止代碼的執行。我還能使用 Time Machine 功能。在讓處理器核心停止運行後，該功能讓使用者能向後和向前步進（step）各指令。Green Hills 最近為 Time Machine 增添了一種始終開啟（always-on）的特性，這大幅地提高了它的可用性，並能幫助開發者，這是因為他們再也不用去記得要開啟 Probe 來記錄事件。
平台之外
Davinci 和 OMAP 平台生態系統的另一項不同點是，TI 現在自願為第三方硬體和軟體 IP（知識財產）的技術支援和授權充當第一線聯絡點。此一措施簡化了設計團隊取得和使用第三方 IP 的工作，並使支援團隊能追蹤各種問題，並可以更快的速度在具有相似問題的團體之間，共用相關資訊。它還使 TI 能更容易地看到技術和商業挑戰中的趨勢以及對特性支援的請求，這樣該公司就能迅速地回應新興的機會。
Davinci 評估模組還包含與 OMAP 開發工具組之間的另一個不太明顯的區別，它與嵌入式設計領域的一個日益明顯的趨勢是一致的。兩種平台都是異類多核心系統。但是，Davinci 模組在板上還包括了第三個執行支援功能的不同處理器核心，它就是超低功率 16 位元 MSP430 RISC 混合信號微控制器，它可與系統板上的 9 個 LED、紅外線介面、即時時鐘一起工作並控制它們。設計者透過讀寫片上的 I2C 暫存器來使用 MSP430。該模組採用三種軟體處理架構來提供系統功能。
對於複雜的嵌入式系統應用而言，採用多種處理架構是一個越來越明顯的趨勢。NXP 公司的 Nexperia 平台就是其中的一例，它結合了 MIPS 核心和 TriMedia 核心，以及硬體加速器和媒體處理周邊。Nexperia 平台採用一個與 Davinci 和 OMAP 平台類似的 API。NEC Electronics 公司的 EMMA （Enhanced Multimedia Architecture）平台配備的器件具有多達 16 個處理器核心，其中包括 32 位元 RISC、帶 DSP 的 32 位元 RISC、64 位元的 RISC 架構，並在同一器件中配備了硬體加速器和串流處理器。越來越多的工具能夠簡化或幫助自動建立和使用定制的硬體加速器和輔助運算器，以便與應用處理器和 DSP 一起使用（參考文獻 3 和參考文獻 4）。
在單一設計中使用多種異類處理架構的複雜嵌入式設計不斷發展，這為軟體發展工具提供了機會，以便來協助軟體中的系統級分區、識別和實現同作（concurrency），以及驗證所有處理引擎的運行和互通性。它還使人們能大致瞭解該產業如何能夠最終構建和配送可重複使用的軟體元件，這是因為開發者可以設計各種處理架構或核心來限制與其他核心上軟體之間的互動。平台供應商可以為願意冒打破封閉（encapsulation）風險的客戶鎖住對這些專用處理器的存取，從而在專用處理器上，以安全的方式提供以軟體形式實現之有用功能。
對於軟體複雜性的抽象和調整（scaling）而言，那些可以支援軟體元件更輕鬆地重複使用和可靠互通性的機制，是關鍵性的能力。迄今為止，實現這個目標的工作只獲得了有限的成功，但特定領域的組織正努力為軟體元件之間的互通性，設計和建立一種好用的模式。這樣的組織包括 CE Linux Forum、Digital Living Network Alliance、SDR Forum 等等。
對於平台供應商、合作夥伴以及使用這些平台的設計團隊而言，隨著這些處理平台的複雜性持續提高，支援它們的生態系統對於各方的成功將更加關鍵。這些早期生態系統正印證了一個重要的概念：在某個領域問題的背景下，大量應用級設計者如何能迅速安全地充分利用、並融合某種處理架構的幾個專家使用者之工作成果。
Click here for Figures:
Figure 1, Figure 2
參考文獻
1. Cravotta, Robert, "Forge Ahead?" EDN, March 6, 2003, pg 50.
2. "Market Forecast Database," iSuppli, June 2006, www.isuppli.com.
3. Cravotta, Robert, "EDN hands-on project: Accelerate your performance," EDN, 2004-11-11, pg 50.
4. Cravotta, Robert, "EDN hands-on project, part 2: Automate your acceleration," EDN, 2004-12-7, pg 55.
