帳號:
密碼:
最新動態
產業快訊
CTIMES / 文章 /
嵌入式系統的跨平台技術挑戰
 

【作者: 誠君】   2004年06月28日 星期一

瀏覽人次:【4501】

隨著各種新穎的網路運算技術之不斷演進,不同嵌入式網路裝置之間的相互通訊問題變得越來越重要,因為消費者非常希望能夠買到可以互相傳遞資訊的電子產品,以提高可用資金的最佳效率。例如:可以將數位相機的影像輕易地儲存在電腦硬碟或CF卡中,而不受軟硬體不同的限制。因此,開發出可以跨越不同軟硬體標準、平台、和應用介面(API)的技術就變得越來越迫切了!


嵌入式系統的「基礎建設」

不過,「說比做容易」。過去許多業者都曾經努力想建立一個跨平台的API標準,而且這些標準至今都還存在著,例如:「網路處理論壇(Network Processing Forum)」制定的CPIX API,但是,到最後都因為商業利益談判的結果無法令各方滿意,而束之高閣。如今,嵌入式裝置多如牛毛,不讓它們相互溝通就等於切斷它們的未來發展。因此,許多人又開始回頭設想,企圖找出最有利的方法。


這就好像電話電纜一樣,在還沒有舖設好之前,任何有線電通訊應用都無法實現。因此,能跨越不同軟硬體標準的技術,其實就是嵌入式網路系統的「基礎建設(infrastructure)」。實現這種「基礎建設」的技術,能將具單一功能的裝置轉變成具有多種不同模式的裝置,並且能結合相機、語音、影像、無線電話的功能。它還能整合現在流行的個人網路技術(personal area network):IrDA、Bluetooth、802.11a WLAN...等;將來還可以結合UWB技術,支援需要高頻寬的多媒體行動應用。這對消費者而言是利多於弊,能讓他們擁有更多的選擇。但卻對設計與製造這類晶片的半導體公司,以及製造此類產品與銷售服務的公司帶來了挑戰。


消費性電子產品市場的特性

因為消費者的選擇機會增加了,所以,業者很難猜透消費者的真正心理。消費者過去習慣使用低廉的、黑白顯示的摺疊式設計,但是,兩、三個月之後,市場的主流可能轉向彩色、中等價位、WLAN連接的產品,可是消費者不會馬上就接受新事物,因此存在著一段新舊產品共存的過渡期。不過,一旦顧客選擇了新的產品,市場就會立即轉到正確的位置上。這就是目前消費性嵌入式電子產品市場的寫照。


許多工程師都承受著無比的壓力,因為他們要在消費者轉變心意之前,就完成新產品的開發工作。這個開發時間可能就只有兩、三個月而已。由於沒有共同的作業系統、工具、硬體標準或平台,因此這種高「揮發性」的市場幾乎每三個月就需要一種新的設計方案。


面對各種軟硬體平台的抉擇

就作業系統而言,目前業者有許多選擇,但居領導地位的有:微軟的WinCE專供小型的嵌入裝置使用;Linux具有許多特點和擁護者;Symbian以手機為主要平台,但目前正轉移到其它不同平台環境中。排名第二的是即時作業系統(real-time operating system;RTOS),包括:Wind River、Accelerated Nucleus、OSE、 QNX、和市場侷限於日本與遠東地區的其它廠牌。


就CPU而言,ARM和StrongARM位於中間的地位,此外還有至少六種常見的廠牌,從MIPS系列到X86架構。目前有一些新成立的處理器廠商(包括國內的部份廠商在內)是採用X86 CPU,他們堅信X86架構在市場上仍然有機會成功。


過去,產品開發商是單獨面對這個「排列組合」問題。現在,至少有六個相互競爭的工業團體各自擁護特定的架構、作業系統、和開發工具。雖然,這種趨勢能夠將風險降到一定的程度,不過,對工程師、開發商,尤其是小型公司而言,他們仍然處於艱峻的環境中。他們必須選擇一種設計方案,但是他們沒有其它安全的因應腹案。萬一發覺不行,他們也無法立即轉到其它平台上,並將大部份的工作、程式碼、硬體移植到新的環境中繼續開發。Linux之所以會盛行的原因之一,毫無疑問的,就是許多工程師、開發商將它視為逃離窘境的一條途徑。


嵌入式GigaEthernet網路處理器

業界需要的是能解決上述窘境的應用程式介面,這些API必須能適用於各種領域,相容於各種作業系統、應用程式,而且最重要的是,適用於各種CPU架構。


為什麼呢?這有兩個理由。首先,我們需要它來開發各種應用,而且其功能在多種架構中都要能夠實現。我們不能只是說說而已,必須盡力將它實現。


其次,就長期而言,它必須很容易就能移植到未來的CPU架構中。雖然,目前居主導地位的微處理器架構是屬於「控制」與「資料」並重的RISC架構,但是,將來的網路運算環境勢必轉以「資料流(data flow)」和「資料移動」為主的架構。因此,這些API也必須能適用於這種環境中。


Broadcom的StrataXGS系列SoC是這種新架構的代表。圖一是可支援12個10/100/1000Mbps乙太網路通訊埠的BCM5690多層交換器(multilayer switch)的內部功能圖。它可藉由PCI外接32/66MHz CPU;或不需要CPU,單機(standalone)操作。它可以連接銅線或光纖的實體層,是傳統10/100Mbps乙太MAC的升級技術。不過,這種架構仍然需要軟體,而且會比過去更加仰賴軟體。因此,就會有如圖二所示的「ZebOS網路服務模組(network service module;NSM)」的出現,NSM專門提供網路第二層(layer 2)的功能。


在NSM上方是Broadcom的軟體開發工具(SDK),具有許多API;在最上方則是作業系統VxWorks。對需要轉送(forward)的封包而言,這種交換器架構不再依賴CPU的資料路徑(datapath)處理資料。因為它能夠以快速的速度過濾封包、對資料流分類,只要軟體設計得當,使用此交換器就好像資料鏈結層(layer 2)是使用硬接線(hardwire)的方式實現的一樣,因此轉送的速度會非常快,根本就不需要CPU插手。不過,當封包進入IP層(layer 3)之後,可能就需要CPU和作業系統來處理了,除非有使用「IP通訊協定處理器」來處理第三層的資料。


目前也有廠商使用CPU+MAC+DMA的方式來設計乙太網路SoC,例如:S3C4510B...等,但是和BCM5690相比,在資料鏈結層上,前者不具有VLAN、對資料流分類...等功能;而且前者的實體層只能連接銅線的RJ-45線路,因此傳輸速率就無法達到1000Mbps。


《圖一 GigaEthernet交換器(協同處理器)BCM5690的內部功能圖》
《圖一 GigaEthernet交換器(協同處理器)BCM5690的內部功能圖》
《圖二 ZebOS網路服務模組》
《圖二 ZebOS網路服務模組》

因為傳輸速度不需太快、對光纖通訊的需求不大...等因素,桌上型和各種小尺寸的無線電嵌入式消費性產品可能是最後一批採用上述網路處理器架構的裝置,其它裝置(路由器、閘道器...等裝置)將優先充斥於我們的週遭。不過,這種新型的設計方法,也帶來了新的挑戰。


「資料流」架構是新的挑戰

雖然,各種廠牌的新型嵌入式網路處理器都是以「資料流」和「資料移動」為主要設計原則。這些廠家包含Motorola、Intel、IDT、Xcelerated......等,他們各自具有設計網路處理器核心的能力,例如:Broadcom的StrataXGS系列SoC就是採用Xcelerated設計的網路ASIC。但是,他們對「資料流」的觀念不見得完全相同。因此,必須站在程式設計的制高點上,重新思考此架構。這也就是前面所提及的挑戰之所在。


直到最近,網路處理器的核心單元(network processor unit;NPU)大多數仍然是以序列式的RISC為設計基礎。而且設計的議題都被侷限在處理器之間的互連方法(平行、管線、矩陣)和硬接線(並藉由特殊指令或特殊的協同處理器來支援特殊的功能)的程度。


其實,資料流架構是和RISC架構迥然不同的。前者移動資料的效率要比後者高出許多。應用程式可以利用的平行運算或執行緒(thread)的數量,完全是由資料類別來決定,例如:影像資訊就要比一般的文字資訊佔用比較多的執行緒數量。假設新型的資料流架構能夠符合上述的目標,那剩下來的挑戰就是如何讓程式更容易設計,以發揮此架構的恢弘能力。同時要引進「完全可預期的(fully deterministic)」的觀念,絕不會有例外錯誤產生或陷入無窮迴圈之中,以符合硬體(網路高速度)的即時要求。


從純軟體工程的觀點來看,連Bill Gates也認為應該採用更「資料流」導向的方法。他的宏觀思維是,將所有可運算的裝置都連結起來,從桌上型電腦到伺服器到消費性電子裝置。


但是,一些桌上型電腦、手持式和嵌入式消費性電子裝置的開發商認為,就硬體技術而言,這在網路處理器的核心單元中雖然是可實現的,但是要消費者改變習慣,接受這種思維,進而使用這些新產品卻需要很漫長的時間。


歷史是否會重演?

從過去的歷史來看,要消費者改變習慣似乎是很困難的。Intel的8080和Zilog的Z80微處理器曾經是市場上的競爭敵手,它們是嵌入式處理器的始祖,不過,都採用CISC架構。它們是第一代電腦(1975年到1980年之間)的CPU。到1980年代中期起,雖然陸續出現了8086、80186、80286、80386,但是微處理器的地位一直都屹立不搖。直到1990年代中期,Intel轉向設計屬於RISC架構的微處理器80486、Pentium。這需要10或15年的時間,才能讓整個電子產業決定改變整個技術架構。


不過,也有人不同意這種「歷史決定論」的觀點。他們認為歷史本身並不會重演。他們指出,網路的特性會自然地將新型的消費性家電裝置連同其所承載的多媒體資訊一同連結起來。這將導致技術架構的轉變,其焦點將放在「資料串流」和「資料移動」上。


共通的API

目前已經有廠商提出一些共通性的(common)API,其目的是想讓連結各種嵌入式裝置的腳步加快。例如:Nokia的Series 60、Microsoft的CE.NET、和Java。不過,大多數仍然是和傳統的電腦架構結合。


最近,一種新的API被提出,它可能會成為未來的必需工具,它就是「萬用的家庭應用程式介面(Universal Home Application Programming Interface;UH-API)」。UH-API是由Philips和Samsung提出的,起初是著重在目前常用的作業系統和CPU上。它被宣稱為:穩定性高、與硬體無關(hardware-independent)的API,是中介軟體(middleware)、應用軟體和晶片架構之間的橋樑。當然要擔任這樣的角色並不容易,因為它必須獲得獨立的軟體供應商(independent software vendor;ISV)和晶片設計製造商的同意。如圖三所示。


Philips和Samsung這兩家公司相信:一個嶄新的「運算典範(computing paradigm)」正在轉變中,而且其轉變的速度可能超出我們的想像。因此,UH-API或許是一個很好的起點。不過,有關UH-API的技術資料至今都沒有對外公開,這難免讓人懷疑UH-API到底有多大的功效;而軟體供應商和晶片設計製造商的合作意願到底有多高,仍然讓人起疑竇。


萬一UH-API最後也失敗了,那電子業界就必需再發明更適合的機制來取代它。否則我們就得面臨下一回合的市場混戰,直到新一代共通的、與硬體無關的新技術出現為止。


《圖三 UH-API的簡易架構》
《圖三 UH-API的簡易架構》

結論

尋找「聖杯(Holy Grail)」一直是西洋文化中的傳奇性傳統;而尋找可以連結各種嵌入式網路裝置的新技術已經是日漸急迫的任務了。不管OEM/ODM廠商願意跟隨或不願意跟隨,這種「運算典範」的變遷是跟潮流一樣無法抵擋的。


其實,以目前的技術來設計嵌入式網路產品已經不是什麼大問題了,換句話說,系統廠商一定會認為:「何必一定要將它們連結在一起呢?」話雖如此,但是,我們絕不能只考慮現在的情況,因為市場會隨著「運算典範」漸漸地改變。國外大廠思考的是10、20年後的大戰略、大方向,這是一種宏觀的思維,不只是看現在,更要看未來。(作者聯絡方式:su2b08@saturn.seed.net.tw)


延 伸 閱 讀

嵌入式系統之驗證與最佳化
嵌入式設計在SoC時代的重要性與重要性日益提升,EDA設計工具所扮演的角色也越加吃重,透過不同功能性的工具,提供設計者一個直接與綜合的環境,包含建構設計平台、驗證與分析來精簡嵌入式系統,以解決開發軟體/硬體時各階段所遭遇的問題。

嵌入式媒體處理器功能簡介
整合型的嵌入式媒體處理器架構,實現MCU與DSP設計方法上的優點,即為將媒體與微控制器功能最佳化,工程師在選擇微處理器的應用上,明顯傾向能結合多成整合性的功能為主,面對功能強大、用於嵌入式媒體應用的「整合型」微處理器的需求就變得很明顯。
從拼圖遊戲談嵌入式系統產品的開發
嵌入式系統產品不只是在軟硬體的技術標準或規格上可自成一個市場,更在設計方法上,除基本原則(baseline)和限制條件相同外,各說紛紜。只要在規格上或設計上做一點點小小的更改,就能獨樹一格,使市場不斷地被區隔開來,讓差異化行銷、甚至「小蝦米對抗大白鯊」的現象變成可能。

相關組織網站
Network Processing Forum
UHAPI Forum
相關文章
Intel OpenVINO 2023.0初體驗—如何快速在Google Colab運行人臉偵測
零信任資安新趨勢:無密碼存取及安全晶片
API讓模流分析自動化
鄰近人體感測功能應用在工作場域
5G、毫米波雷達和UWB加速自駕車佈局
comments powered by Disqus
相關討論
  相關新聞
» 英特爾攜手合作夥伴 助力AI PC創作新世代
» Intel成立獨立FPGA公司Altera
» Intel Core Ultra透過新vPro平台將AI PC延伸至企業應用
» 英特爾宣布晶圓代工諮詢委員會成員 因應AI時代的挑戰
» 聯電和英特爾宣布合作開發12奈米製程平台


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.3.234.212.253
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw