账号:
密码:
最新动态
 
产业快讯
CTIMES / 文章 /
多媒体当道32位元处理器趁势而起
 

【作者: David Katz】2005年02月01日 星期二

浏览人次:【5830】

随着嵌入式系统的复杂度迅速地提高,设计者在处理器的选择上必须面对新的挑战。在许多先进的应用中,具备弹性与低成本特性的8位元和16位元微控制器(MCU)不断将地盘拱手让给32位元的系统单晶片(SoC)。当然,8位元和16位元处理器仍然在嵌入式应用中居于稳固的地位。然而在某些方面,由于系统成本、产品扩充性与性能等需求,使得这股32位元的趋势其来有自。以下本文将使用多媒体市场为讨论背景,检视MCU转向32位元的主要动机。


32位元MCU优势何在?

要了解为何32位元MCU在多媒体领域成长如此快速的原因,首先要考虑的是8位元MCU并不能提供在这些系统中保证即时操作所需的频宽与运算功率。而有一个明显的问题是:「那何不升级到16位元微控制器呢?」毕竟这些元件真的可以提升传输量与效能;此外,它们所消耗的待机电流也很低,而且一般可以提供比8位元竞争产品更大容量的内建记忆体。


结果,答案是相当简单的。实现一个以32位元MCU为基础的系统,它的实际的成本与许多今天使用的16位元解决方案是差不多的,但它的效能远大过16位元MCU却是显而易见的;如(图一)。以下有多个理由说明两者成本其实相差无几。



《图一 多样化的 MCU领域》
《图一 多样化的 MCU领域》

<本图表示,在32位元MCU中整体朝向亲和性多媒体之SoC形式整合的趋势,而低效能8位元与16位元MCU则是典型适用在以控制为主的周边。 >


制程技术

由于矽晶制程持续微缩化,32位元架构变得不再昂贵。更小的元件制程产生更小的裸晶片,因此在每片晶圆上具有更多的裸晶。这直接转换成更低的每个单位晶片成本。除此之外,随着32位元元件转成0.18微米或0.13微米(对比8位元元件一般使用0.25微米)所能达到的操作速度就更快。举例来说,大部分8位元和16位元MCU的运行速度多在100MHz以下,但采用0.13微米制程设计的32位元元件可以达到的速度是前者的好几倍。


有二大理由说明为何以更小的制程来设计8位元元件是不具成本效益的:


  • (1)8位元元件由于整体缺乏频宽,任何从制程微缩来达到的额外速度都可能是浪费的。


  • (2)一般8位元元件的目标价格约在2美元左右,对以某些更小几何制程实现的元件而言,这个价格太低了。



当更小的制程可能对8位元元件的成本结构造成负面的冲击时,它对32位元MCU却是有好处的,除了微缩它们的晶片尺寸外,还有空间挪出位置给SoC适用的一整组周边用。甚至于如此在效能上的大跃进,成本仅约5美元左右,足以与16位元MCU成本结构相抗衡。


可编程模式

另一项与成本有关的考量在于与32位元架构相关的编程模式。由于处理器的资料路径中有更多位元以及新增加的由32位元资料与位址暂存器所构成的暂存器档案,编译器支援因此大幅提升。此外,32位元元件常会支援16与32位元运算码,这使得指令集架构的弹性更大,改善程式码密度,并允许许多运算在单一核心时脉周期内完成。


换句话说,这二项特性减少对人工撰写的组合语言程式的依赖,因此开发者可主要以高阶语言像C语言来撰写程式。以C为基础的编程模式直接转换为更低的开发与维护成本。它也让公司内现有的应用程式能被转译成从未想像到的MCU环境领域。


扩充的周边支援

如前所述,多媒体系统中MCU的角色通常是作为系统的控制器。它们不适用在密集资料处理上──这是数位信号处理器(DSP)擅长的工作──相反地,MCU会用来控制DSP的动作,并且管理人机介面、作业系统以及与其他系统元件的连接。


就是这种与外面世界的连接关系,推动朝向32位元MCU发展的趋势。许多普遍存在的周边(高速USB2.0、PCI...等)支援如此高的资料率,使得在8与16位元MCU上处理这些资料流变得很困难甚至不可能。例如,在网路连结性的领域,最大的资料暂存器若为8位元甚至是16位元,将无法支援一整组网路协定。


8/16位元MCU在高速下运行的基本问题来自于它们受限的处理能力与较小的记忆体定址范围。有些8位元MCU只有一些资料暂存器,并没有单独的累加器。完整的暂存器档案存在是非常重要的,因为它能省却在记忆体与累加器之间频繁转换资料的需求。此外,有多重32位元资料位址产生暂存器,效能就能大幅提升。这些32位元MCU的特性造成编译码的密度更高,连续频宽更大,还有如我们讨论过的,更加有弹性的编程模式。


受到32位元MCU竞争压力,16位元MCU业者也有其因应对策,他们试图扩充MCU内部的汇流排大小,好使得作业的速度​​更快,而不用增加解决方案的最终成本。虽然这类型方案多少有点助益,但效能上的基本鸿沟仍然存在。


32位元MCU系统趋势

与32位元MCU成长的另一新兴趋势在于倾向结合更多DSP功能在同一晶片上。虽然今天大部分多媒体的设计使用由MCU主控的DSP,为了成本,空间与节省耗电考量,开发者却总是想将此一功能整合成一颗晶片。促成此一趋势的是一般在32位元元件才有的更快的时脉速度:更高的MHz代表能进行信号处理的空间更多。


不过,先天上MCU的架构并非针对高效率信号处理。因此,制造商尝试用多种技术来降低此一缺点。


其中一个做法是以单一封装中生产一种包含一颗DSP和MCU的多晶片模组(MCM)。这种做法的缺点是设计者必须以“50/50”比例去分割控制与DSP功能。举例来说,一旦DSP“用爆了”MCU并不能接手未完成的运算。同时,当DSP与MCU核心都存在时,就需要二组开发工具。


另一种选择是将DSP功能内建到MCU中。这种做法只适合简单的信号处理应用。 MCU时脉速度与运算架构基本上并不很适用在密集的数字处理。有些MCU想要用增加乘法/加法(MAC,DSP的主要特征)单元加以补偿。但这种做法仍然缺乏较前瞻应用所需的基本架构设计。


最后一种选择是将MCU和DSP功能整合成一颗处理器。这类处理器呈现一种统一的架构,不仅适合做为数位运算,而且也能执行以控制为主的工作任务;以ADI的Blackfin系列处理器为例,它同时具备一颗16位元DSP与32位元MCU的功能。经由平衡决定性控制任务与复杂计算能力两边的需求,这种做法可依系统的即时需要,允许达到执行100%控制或100%运算。


结语

未来32位元MCU将继续以更低的成本来提供更大的处理资料量与更多的特性。同时,系统单晶片技术也将持续把微控制器功能,普及的连接性以及强大的运算能力整合在一起,以实现真正的单晶片解决方案。很明显地,这些32位元SoC已经宣告了自己在多媒体领域中的地盘,而它们对这些市场所造成的革命性改变将会日趋明显。 (作者任职于美商亚德诺Blackfin应用事业群)


延 伸 阅 读

应用广泛的 MCU (微控制器),在简单的家电设施、复杂的多媒体产品以及汽车、工业控制等领域都可见其身影。相关介绍请见「综观台湾MCU产业现况」一文。

随着汽车IA 化的到来,车体内的微控制器越来越多,从早期的20 多颗,到近年来的50 多颗,甚至高阶车种已经达到100 多颗, MCU 对车体的重要性将日益壮大。你可在「全球车用微控制器趋势演进」一文中得到进一步的介绍。

目前全球 MCU 仍以 8 位元为主力产品;根据 Instat 统计资料显示, 8 位元 MCU 在 2001 年仍以消费性应用产品为主。在「MCU应用分布趋势」一文为你做了相关的评析。

市场动态

混合讯号 IC 业者 Silicon Laboratories 在 2003 年底并购 MCU 厂商 Cygnal Integrated Products 之后,随即在 2004 年以推出 8 位元通用型 C8051F 系列新产品正式宣布跨入 MCU 市场。相关介绍请见「结合类比功能 8位元MCU挑战更高阶应用」一文。

在竞争激烈的 8 位元 MCU 市场中, MicroChip 推出了体积最小、 SOT-23 封装的 6 针脚快闪 MCU ,抢下 8 位元 MCU 盟主的企图心非常明显。你可在「小体积大效益 挑战MCU设计极限」一文中得到进一步的介绍。

盛群半导体新推出 8 位元精简型 MCU 内建 8~9 位元 ADC ,适用于家电、车用周边及其他智能控制的产品,其精简的架构提供使用者一个具有优异性价比的解决方案。在「盛群推出8位元精简型MCU」一文为你做了相关的评析。

相关文章
70美元为第五代树莓派添加AI套件
突破局限!三款多核心微控器同时支援 Arduino与MicroPython
ChipLink 工具指南:PCIe® Switch 管理变得如此简单
医疗用NFC
嵌入式系统的创新:RTOS与MCU的协同运作
comments powered by Disqus
相关讨论
  相关新闻
» 宜鼎二期研发制造中心正式启用,以「AI加速、视觉驱动、客制整合」 为技术核心
» 英飞凌为客户提供产品碳足迹资料 助力低碳化转型
» DigiKey《数位城市》第四季影片系列以智慧AI为主题
» Molex探讨全新连接器设计兼具加固化与微型化
» 贸泽连续第六年获Molex颁发年度亚太区电子型录代理商大奖


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

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