多媒体芯片面临数据“交通堵塞”,消费电子设计者如何应对?
扫描二维码
随时随地手机看文章
在最近的消费电子展上,我和很多芯片及软件供应商交谈过,这里所展出的那些功能丰富的多媒体移动和嵌入式设备大多是采用了他们的设计。在交谈过程中,我总是会想起史蒂夫·马丁主演的《洛杉矶故事》中的一幕。
马丁在剧中扮演一个洛杉矶的电视气象预报员。一天早上他开车去上班,他没有走高速公路,因为那里堵车了,根本过不去,而是走了一条捷径:先穿过邻居的院子,经过一条小巷,穿越一片空地,经过一个洗车店,然后弯弯曲曲地驶过一个停车场……。
剧中的高速公路都是50年前设计的了,根本无法容纳今天的交通流量。这幕场景看起来很搞笑,因为它准确地反映出了真实世界中的情景,而且马丁的捷径方案也并不算很夸张,因为现实生活中洛杉矶的司机们有时也会遇到这样的情况。
嵌入式SoC的“交通堵塞”
在很多移动设备和便携式电子产品的嵌入式应用中,硅的开发者和构建者们就面临着同样的问题。消费者对于多媒体内容在高带宽有线和无线互联网上传播速度的要求越来越高,而MP3播放器、视频录象机和移动电视设备以及带视频功能的全功能手机的构建者们则不得不尽力去满足这种需求。但是,他们那过时的共享总线结构就成了大问题,因为它们已经根本无法承载如此高的数据流通负荷了。
在这些设计中使用多核CPU只能偶尔奏效,其它时候甚至会带来更大的麻烦,因为芯片中用来运输数据的“高速路”已经陈旧不堪,早已无法适应当今和未来的需求。
当然,也有新的高速系统,比如片上网络和片上点对点型串行交换光纤链接,这些在概念上有点类似于板到板和系统到系统级的Infiniband、PCI Express和RapidIO。在Giovanni De Micheli和Luca Benini二人合著的“Networks On Chips”一书中,就对这些芯片级替代方案及其产生的问题进行了描述。
使用这些多媒体优化型SoC至少有两个问题。第一,它们的种类太多了。这么多SoC,你该如何选择?你如何判断它们是否能和现有的“高速路”设计兼容?第二,软件开发方面的问题太多了。“Networks On Chips”一书也反复提到了这些问题。
读完这本关于各种复杂的软件问题的书之后,我得出了一个结论:即便我们能够在片上数据流通上达成一个通用的下一代高速系统,软件问题也能在很多年的时间里让这种系统迟迟无法被广泛采用。再看看软件开发的通用标准吧,创建这样的通用标准的呼声在业界已经响了很多年了,可是到现在为止,大家都是光说不做。[!--empirenews.page--]
迂回战术
在这样的困难面前,如果不仅仅是ARM、MIPS、Power和PowerPC的处理器而是有很多产品都会遇到这样的问题,那也不足为怪。他们把希望寄托在现有的技术,在恰当的时候使用现有的共享总线方法,在可以的时候进行更换,或者在解决不了时找一些能够避过这些问题的迂回方法和捷径。
比如,最近Atmel推出的专为带有图象、音频和视频的人机接口应用而设计的ARM926EJ-S微控制器,就把迂回方法发挥到了极致,以消除ARM架构中传统AMBA总线中常有的数据流通的瓶颈,将片上数据传输率提高到了41.6 Gbps。
另外一个同样采用了创新型迂回方法的公司是Digi,在它为蜂窝网关、WiFi设备服务器和无线视频设备而设计的几种专用I/O设备中,它所使用的 Netsilicon NS9360也采用了这样的方法。和Atmel所采用的方法类似,Digi也是依靠现有的AMBA AHB共享总线技术,但是对外围DMA结构作出了较大的改进。另外,它还采用了一种特别的方法,让开发者可以更改某个特定的寄存器,从而直接在软件中进行控制,而不管分配了多少带宽。
这样的例子还有很多。Faraday Technology公司选用了一个QoS-aware型非阻塞交叉开关以获得所需的芯片内数据流带宽,以及一个自己设计的智能DMA引擎。 PortalPlayer公司也采用了一个自己设计的交叉开关来代替AMBA,而NXP公司则对总线架构进行了改进,并保留AMBA用于可靠控制并处理各种任务,同时还添加了一个自行研发的用于提供各种多媒体功能的数据流总线。其它的公司则选择了和Cirrus Logic一样的方法。这种方法既直接又简单,仅仅是在同一张芯片上放置了两个AMBA总线,并将数据流分开,以使得每个处理单元都能获得尽可能多的带宽。
其它的例子,例如德州仪器的OMAP、NXP的Nexperia和东芝的Cell结构,则是采用了一个共享内存的方法,在最顶部添加了多种消息传递机制,尽可能多地依靠现有的标准,例如Open MPI。
尽管业界在向这种新的架构转变,我心中还是有很多疑问。这些迂回方法的作用能持续多长时间?各种新的NoC总线方案之间有没有开发者可以寻求的共同点,以便至少能将从现有的共享总线方法转向新方法的成本降至最低?
是否有任何新型NoC方法能够降低这一转变的难度?这些被我们考虑用来解决各种现有同类堆成多核环境中编程和调试问题的软件方案,是否能够在NoC所代表的更为复杂的不同类非对称多核环境中也能起作用?
你是如何认为的?你现在采取的是哪些方法?将来呢?最好的转变方法是什么?要知道,史蒂夫·马丁的方法终究不是长久之计。