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