账号:
密码:
最新动态
产业快讯
CTIMES / 文章 /
嵌入式系统的跨平台技术挑战
 

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

浏览人次:【4548】

随着各种新颖的网络运算技术之不断演进,不同嵌入式网络装置之间的相互通讯问题变得越来越重要,因为消费者非常希望能够买到可以互相传递信息的电子产品,以提高可用资金的最佳效率。例如:可以将数字相机的影像轻易地储存在计算机硬盘或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加速器为企业生成式AI市场提供新选择
» 英特尔携手合作夥伴 助力AI PC创作新世代
» Intel成立独立FPGA公司Altera
» Intel Core Ultra透过新vPro平台将AI PC延伸至企业应用


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

Copyright ©1999-2024 远播信息股份有限公司版权所有 Powered by O3  v3.20.1.HK84S6VZVBQSTACUK6
地址:台北数位产业园区(digiBlock Taipei) 103台北市大同区承德路三段287-2号A栋204室
电话 (02)2585-5526 #0 转接至总机 /  E-Mail: webmaster@ctimes.com.tw