目前，在單系統、單電路板乃至單晶片上的多核心處理器以更低功率提供更多功能和更快速度的發展趨勢，解決了嵌入式硬體設計某些問題。但對軟體開發人員和供應商來說，嵌入式多處理意味著更艱鉅的挑戰。
與通用伺服器及大型電腦系統之均衡對稱的同類多處理環境相反，嵌入式和行動應用領域則可能需要開發人員對包括不對稱執行的RISC、DSP及網路架構的異質非均衡混合環境開發程式。
近年來，硬體開發商頻頻抱怨缺乏適用於多核心環境的軟體開發工具和建構模組。儘管許多嵌入式軟體供應商紛紛表示已開發出針對大多數迫切問題的解決方案，但目前的最大問題是，隨著多處理設計中所用核心的數量和異質性的增加，下一步該何去何從。
“隨著越來越多的處理單元被嵌入到矽晶片中，在有效開發應用軟體程式碼並管理系統方面，軟體複雜程度已遠遠超過傳統的嵌入式軟體工具的能力範圍，”PolyCore Software公司總裁兼CEO Sven Brehmer表示。
在TI DSP部門的軟體工程經理Robert O'Shanna看來，問題並不是工具和建構模組短缺，反而是過多了。“由於各式各樣的解決方缺乏共同性，在方法和過程上沒有產業標準，供應商們已開始推出各種針對特定作業系統(OS)和特定硬體的解決方案，”O'Shanna表示，“而且，那些提供一定程度平台獨立性的方案又需要使用眾多工程師根本不熟悉的框架和方法學。”
供應商也正對開發人員提出的多種多樣的問題做出響應，如在OS層、多CPU環境以及應用程式層，如何高效地為多個目標編寫程式碼？什麼才是在多個CPU上管理多個OS的最好機制？在這種環境中如何進行除錯？
針對前兩個問題，答案本身是多方面的：使用消息傳遞機制來隱藏必須被管理的CPU及分區；使用公共的應用程式介面(API)作為目標；透過系統級建模工具的開發或匹配來解決軟體實現的複雜度；從傳統的、熟悉的順序程序編程語言轉向函數程式及更高級別的抽象。
飛思卡爾半導體開發商技術組織的多核心軟體產品經理Joseph Dubin認為，這些問題儘管複雜，但一直存在，必須及早面對。
“多CPU環境在電路板和底板級是相同的，許多用於管理該環境中軟體的技術已經湧現。”他表示，“現在不同的是，某些應用，如手持式和一些嵌入式消費領域的應用，正轉向在同一顆晶片上使用多個CPU。儘管它必須對技術做一些修改，但路線是清晰的，幾乎沒有什麼不能解決的未知問題。”
另一種意見
不過，PolyCore公司的Brehmer卻認為，對微型化的消費設備而言，採用異質多處理器會引起與其它情況不同的一系列問題，在問題種類和程度都有所不同。
“在多處理器環境中，包括網路與刀鋒型環境可能會以具備相容工具而存在著大量應用，而許多消費性與行動領域的嵌入式設計卻因為必須使用非對稱模型操作，以便更高效地使用矽晶片來滿足功率需求而受到限制，”Brehmer說。“此外，這些嵌入式應用還必須將難以操作在對稱式多處理器(SMP)模式中之不同類型的RISC與DSP等多種處理器加以實體化。”
另外，還存在對多處理器設計至關重要的軟體分割的問題。“多個CPU之間過多的通訊會抹殺多處理的優勢，”Brehmer表示，“目前在主流應用中，多數軟體分割都採用子處理器配置，其中應用程式空間被分割為兩個部份，分別為控制與用戶介面，以及不間斷訊號處理部份。”
 |
圖1: 典型的多核心處理器架構。 |
這種模型是圍繞共享儲存架構而設立的，分割在早期即已完成。在許多消費電子設計中，分割都將RISC引擎作為主處理器，而將DSP配置為週邊設備。Brehmer指出：“這種方式的缺點是，儘管子處理器(DSP)負責了相當大部份的運算任務，卻經常被阻塞，處於等待主處理器命令的狀態。因而，使用多處理器而獲得的平行處理優勢大都被犧牲掉了。”
Express Logic公司市場副總裁John Carbone承認，由於應用需求和製造技術的限制，迫使在一顆晶片上使用兩三個以上的CPU，嵌入式軟體產業長時間內將不得不解決大量的問題。“但近期，我們可以利用已知技術，透過精心選擇使用的硬體平台和程式模型來做很多事情。”他表示。
例如，雖然很多應用都要求使用讓不同種類的CPU分擔特定工作的不對稱多處理(AMP)程式技術，但仍然有許多嵌入式行動應用可以採用發展成熟且更容易瞭解的SMP程式模型，Carbone解釋說。
DSP和RISC引擎混合的環境中的一個問題就是，採用SMP在多個CPU之間均衡負載並共享應用處理是很困難的。Carbone認為，在硬體級，這個問題可以透過兩種發展中的處理架構來改善。第一種是由ADI、Atmel、飛思卡爾和TI等公司製作的所謂融合型架構，該架構把DSP和RISC作業整合在一個架構中。第二種是強行式(brute-force)RISC架構，它具有更多的DSP指令和管線作業，並以每秒數百萬條指令的執行速度來解決上述問題。
SMP或AMP？
這兩種方法都允許採用一種良好的SMP環境，在其中，程式設計師分配任務時無需關心這些任務是針對RISC核心還是DSP核心。在brute-force架構中，使用三個或四個CPU處理眾多DSP需求雖然效率較低，但性能的提升即使沒有達到三至四倍，也有兩到三倍。
在這類準SMP環境中，現有的一些OS和RTOS都可以保留，雖然必須做一些修改，Carbone表示。舉例來說，這些增強功能被整合在Express Logic公司的ThreadX RTOS中，使其工作在兩個、三個甚至四個CPU SMP環境中，其中一個CPU作為網路閘道，透過它管理所有的作業。如果第一個CPU忙碌，它會把任務傳遞給任何一個空閒的CPU。
即使性能和功耗方面的改善無法像完全使用AMP的環境可能獲得的那樣多，但經ThreadX實現的改進型SMP配置仍然有60%到85%的提高，Carbone稱。而且採用這種做法，程式設計師可以不必放棄熟悉的單CPU和單一程式環境。
不過，並非所有的即時作業系統“都能夠進行這類修改，”Green Hills軟體公司的工程部副總裁Dave Kleidermacher提到，“如果它們的業務和功能已過於臃腫，並已在竭力維持確定性作業，就沒有處理這些必要修改的空間了。”
“所需要的是具有極小核心以及執行緒和中斷結構的備用精簡RTOS，非常適宜於在硬即時環境中工作。”
最終，Express Logic的Carbone指出，嵌入式軟體產業將必須開發能在異質、不對稱運算環境中有效工具且適合於程式碼編寫的工具。“我們別無選擇，”他表示，“我們必須唯CPU硬體開發商馬首是瞻，透過適當的開發工具和框架，使開發人員能夠享有單CPU程式模型的簡單化，並使他們能夠編寫能在多處理環境中任何CPU上有效工作的程式碼。”
然而，在更好的方法出現之前，主流趨勢仍是消息傳遞中介軟體框架，該框架管理多個CPU和多個RTOS或者是單RTOS的多個實體化(instantiation)或映像(image)間的相互活動。但對開發人員而言，只是一個單一、公共的API介面。
各種框架方案
例如，QNX軟體系統公司實施了依賴於消息的均衡式多處理(BMP)環境。Enea公司即將推出的OSE RTOS版將整合該公司的單元消息傳遞框架。而PolyCore公司則提供獨立於RTOS的PolyMessenger框架。
其它公司，包括WindRiver公司和Linux聯盟內的眾多公司，都選擇一種稱為透明進程間通訊(TIPC)的消息傳遞中介軟體標準，這是一種源於網際網路TCP/IP的協議，專門為基於SMP的伺服器的叢集間通訊而設計。
隨著基於多核心和多處理器的系統單晶片變得越來越普遍，基於消息的通訊系統將透過每核心多任務的方式協助管理系統複雜度，Quadros Systems公司總裁Tom Barrett表示。“這種方法也讓應用開發人員擺脫了硬體方面的工作，使他們可以將精力集中在實際應用程式碼上面，”他說，“這是因為IPC框架使用消息把應用從硬體中屏蔽出來，同時也連接了執行不同OS的不同類型處理器。”
 |
圖2: ARM的MPCore能夠處理最高達4個處理器。 |
Brehmer指出，PolyCore公司支援的模型是一種對等(P2P)框架，其核心平行工作，彼此無關。這種方法提供了較高的性能，這是因為，即使某一核心在等待數據，而其餘的核心也都在繼續工作。
此外，透過把任務重新編譯到一個不同的核心上，開發人員能夠對不同的分割方案進行測試，以確定最佳配置。
PolyCore公司希望在這一領域領先於競爭對手，目前正致力於開發下一代對等機制，旨在使開發人員能夠以常規的順序方法編寫程式碼，並透過在一個單獨的配置文件中詳細指定分割點來實現程式碼自動分割。Brehmer表示，這樣一來，幾部份程式碼可以平行執行，執行時由系統自動處理通訊。“這就讓開發人員可以繼續使用標準的C語言，同時還能以不同的方式來分割程式碼。”
針對多核心的開發工具
眾多紛爭焦點之一是目前這一代軟體工具和建構模組是否適合基於多核心SoC和多處理器設計應用軟體程式碼需求。Express Logic公司的Carbone尤其關注除錯工具。
“它們和程式碼開發及系統劃分問題同樣複雜，在除錯級上非常麻煩。”Carbone指出，“多個CPU就意味著有多個OS或者是同一個OS的多個實體化，而且在每一個目標對象上都存在除錯問題，也意味著管理並協調各CPU間工作的中介軟體的開發中的除錯問題。”
另一方面，飛思卡爾公司的Dubin則認為，在目前這一代多核心晶片設計中，開發人員面臨的程式碼開發和除錯方面的許多問題是能夠解決的，即使不是利用現有工具，也可以利用現有技術的直接衍生方法。
TI的O'Shanna則提出了介於上述觀點之間的意見。他認為，目前的除錯方法學已足夠，並可擴展以解決短期內將出現的眾多問題，但隨著處理器數目的增加，它們將不夠用。“一顆晶片上有兩三個處理器的設計已經出現，眼下眾多CPU架構獲授權者已開始討論具有六七個核心的SoC設計了。”
但O'Shanna指出，必須解決這個問題的不是軟體供應商，而是相關的硬體供應商。實際上，他相信整個產業都將不得不對現在作為標準的JTAG和Nexus除錯介面規格進行延伸擴展。
“我們目前缺乏對晶片內部的足夠瞭解，無法收集到足夠的所需資訊以便於在這樣一個複雜環境中進行除錯。”他表示，“TI正積極尋求許多替代方案，但這需要整個產業的努力。”
的確，整個產業似乎正往此一方向發展。例如，Eclipse社群已經負責了WindRiver公司提議的旨在設立一個共同除錯模型的設備軟體開發平台(Device Software Development Platform)計劃下的一項子計劃，WindRiver公司CTO辦公室的首席技術專家Martin Konig表示。
這項工作的目的是設計出能夠與許多支援傳統的RISC、DSP和網路處理器的除錯引擎共同工作的介面和觀察方案。
另外，許多多處理迷(Multi Processing Aficionado)也在進行另一項嘗試性努力，即討論與多處理架構一起使用的某些公共、產業性標準及API的可行性，PolyCore公司的Brehmer介紹說。該組織計劃不久後舉行一個為期三天的會議，目的在於就多核心和多處理器設計對工程社群進行培訓。
然而，多核心DSP供應商Cradle Technologies公司的產品開發總監Koursh Amiri卻認為，所有這些努力都是徒勞的。Amiri的結論是，獨立性平台工具及方法只在一定程度上有用；在下一代技術中，可能必須把它們更緊密地與特定硬體甚至是特定應用相聯結。他認為：“儘管有可能使用熟悉的語言、方法和開發工具，但針對具體底層基礎架構和應用，它們仍將需要專門的多核心連接(multicore hook)。例如除錯時，即一個處理器、一個OS、一個工具的標準方案方案是不切實際的。”
舉例來說，他解釋，在多核心環境中，必須設置多個中斷點，並讓某個特定處理器或全部處理器來響應這些中斷點。
“在某些情況下，開發人員必須知道哪一個處理器或哪幾個處理器已到達中斷點，”Amiri表示，“因此，開發人員有時會希望以單一步驟執行這個核心，而所有其它核心則一致或逐一進行響應。”
“在性能分析期間，除了每一過程所需週期數目、每行程式碼所需數目等傳統參數外，多核心開發人員還必須瞭解處理器之間的互動、等待時間以及記憶體利用率等。”
這就要求在特定工具和特定硬體架構之間的連接應該更加緊密。因此，TI和飛思卡爾等已進入第二代多核心設計公司，正投入大量努力來開發特別適合其架構的特定工具，並收購軟體公司來獲取這種能力，Amiri對此並不感驚訝。
作者：柯伯南
