网络意识形态实施方案:利用工具充分发挥多内核的能量

',1)">
目前，在单系统、单电路板乃至单芯片上的多核处理器以更低功率提供更多功能和更快速度的发展趋势，解决了嵌入式硬件设计的某些问题。但对软件开发人员和提供商来说，嵌入式多处理意味着艰巨的挑战。
与通常的服务器及大型计算机系统的均衡对称的同类多处理环境相反，嵌入式和移动应用领域则可能需要开发人员对包括不对称运行的RISC、DSP及网络架构的异类非均衡混合环境进行编程。
最近，硬件开发商频频抱怨缺乏适于多内核环境的软件开发工具和构建模块。而今许多嵌入式软件提供商纷纷表示已开发出了针对大多数迫切问题的解决方案。目前的最大问题是，随着多处理设计中所用内核的数量和异质性的增加，下一步该何去何从。
“随着越来越多的处理单元被嵌入到硅片中，在有效开发应用软件代码并管理系统方面，软件复杂程度已远远超过传统的嵌入式软件工具的能力范围，” PolyCore Software 公司总裁兼CEO Sven Brehmer表示。
在TI DSP部门的软件工程经理Robert O‘Shanna看来，问题并不是工具和构建模块短缺，反而是过多了。“由于解决方案形形色色，彼此间又缺乏共同性，在方法和过程上没有行业标准，提供商们已开始推出各种各样的针对特定操作系统(OS)和特定硬件的解决方案，” O‘Shanna表示，“而且，那些提供一定程度平台独立性的方案又需要使用众多工程师根本不熟悉的框架和方法学。”
图1: 典型的多核处理器架构。
提供商自身也在对开发人员提出的多种多样的问题做出响应，如在OS层，多CPU环境中，以及在应用程序层，如何高效地为多个目标编写代码？什么才是在多个CPU上管理多个OS的最好机制？在这种环境中如何进行调试？
对前两个问题，答案本身是多方面的：使用消息传递机制来隐藏必须被管理的CPU及分区；使用公共的应用编程接口(API)作为目标；通过系统级建模工具的开发或适配来解决软件实现的复杂度；从传统的、熟悉的顺序过程编程语言转向函数编程及更高级别的抽象。
飞思卡尔 半导体公司开发商技术组织的多内核软件产品经理Joseph Dubin认为，这些问题尽管复杂，但一直存在，必须面对。
“多CPU环境在电路板和底板级是共同的，许多用于管理该环境中软件的技术已经涌现。”他表示，“现在不同的是，某些应用，如手持式和一些嵌入式消费领域的应用，正转向在同一块芯片上使用多个CPU。尽管它需要对技术做一些修改，但路线是清晰的，几乎没有什么不能解决的未知问题。”
另一种意见
不过，PolyCore公司的Brehmer却认为，对微型化的消费设备而言，采用异类多处理器会引起与其它情况不同的一系列问题，在问题种类和程度上都有所不同。
“在多处理器环境有可能与现有设计工具兼容的网络和刀片环境中可存在大量应用，但许多嵌入式设计在消费和移动领域却受到限制，这是由于功率要求工作在不对称的模型，以及要求硅片得到最大效率的利用，” Brehmer表示。“除此之外，它们需要不同类型的处理器――RISC 和 DSP的多例化，这是很难以SMP(对称多处理)模式工作的。”
另外，还存在对多处理器设计至关重要的软件划分的问题。“多个CPU之间过多的通信会使多处理的优势被抹杀掉，” Brehmer提到，“目前在主流应用中，大多数软件划分都采用子处理器配置，其中应用程序空间被划分为两个部分——即控制与用户接口部分，以及不间断信号处理部分。”
这种模型是围绕共享存储架构而建立的，划分在早期即已完成。在许多消费电子设计中，划分都将RISC引擎作为主处理器，而将DSP配置为外设。Brehmer指出：“这种方式的缺点是，尽管子处理器(DSP)负责了相当大部分的计算任务，却更经常被阻塞，处于等待主处理器命令的状态。因而，使用多处理器而获得的并行处理优势大都被抹杀掉了。”
Express Logic公司市场副总裁John Carbone承认，由于应用需求和制造技术的限制，迫使在一块芯片上使用两三个以上的CPU，嵌入式软件行业长时间内将不得不解决大量的问题。“但近期，我们可以利用已知技术，通过精心选择使用的硬件平台和编程模型来做很多事情。” 他表示。
例如，虽然很多应用都要求使用让不同种类的CPU分担特定工作的不对称多处理(AMP)编程技术，但仍然有许多嵌入式移动应用可以采用发展成熟的且更好理解的SMP编程模型，Carbone解释说。
DSP 和 RISC引擎混合的环境有一个问题就是，采用SMP在多个CPU之间来均衡负载并共享应用处理是很困难的。Carbone认为，在硬件级，这个问题可以通过两种具有发展趋势的处理架构得以改善。第一种是由ADI、Atmel、飞思卡尔和TI等公司创建的所谓融合型架构，该架构中把DSP和RISC的操作整合在一个架构中。第二种是强力(brute-force)RISC架构，它具有更多的DSP指令和流水线操作，并以每秒数百万条指令的执行速度来解决上述问题。
是SMP抑或AMP，还是合二为一？
这两种方法都允许采用一个很好的SMP环境，在其中，编程人员分配任务时无需关心这些任务是针对RISC内核还是DSP内核的。在brute-force架构中，使用三个或四个CPU处理众多DSP的需求，虽然效率较低，性能的提高没有达到三至四倍，但也有两到三倍的提高。
图2: ARM的MPCore能够处理最高达4个处理器。
在这类准SMP环境中，现有的一些OS和RTOS都可以保留，虽然需要做一些修改，Carbone表示。比如，这些增强功能被整合到Express Logic公司的ThreadX RTOS中，使其工作在两个、三个甚至四个CPU SMP环境中，其中一个CPU作为网关，通过它管理所有的操作。如果第一个CPU忙碌，它就把任务传递给任何一个空闲的CPU。
即使性能和功耗方面的改进无法像完全使用AMP的环境可能获得的那样多，但经ThreadX实现的改进型SMP配置仍然有60%到85％的提高，Carbone称。而且这样做时，编程人员可以不必放弃熟悉的单CPU和单一编程环境。
不过，并非所有的实时操作系统“都能够进行这类修改，” Green Hills 软件公司的工程部副总裁 Dave Kleidermacher提到，“如果它们的业务和功能已过于臃肿，并已在竭力维持确定性操作，就没有来处理这些必要修改的空间了。”
“所需要的是具有极小内核以及线程和中断结构的备用精简RTOS，非常适宜于在硬实时环境中工作。”
最终，Express Logic的 Carbone指出，嵌入式软件行业将必须开发能有效工作在异类、不对称计算环境中的适合于代码编写的工具。“我们别无选择，”他表示，“我们必须唯CPU硬件开发商马首是瞻，通过适当的开发工具和框架，使开发人员能够尽享单CPU编程模型的简单化，并使他们能够编写能有效工作在多处理环境中任何CPU上的代码。”
然而，在更好的方法出现之前，趋势仍是消息传递中间件框架，该框架管理多个CPU和多个RTOS或者是单RTOS的多个实例化(instantiation)或映像(image) 间的相互活动。但对开发人员而言，只是一个单一、公共的API接口。
各种框架方案
例如，QNX软件系统公司实施了依赖于消息的均衡式多处理(BMP)环境。Enea公司即将推出的 OSE RTOS版将整合该公司的单元消息传递框架。而PolyCore公司则提供独立于RTOS 的PolyMessenger框架。
其它公司，包括风河系统公司和Linux联盟内的众多公司，都选择一种称为透明进程间通讯(TIPC)的消息传递中间件标准，这是一种源于互联网TCP/IP的协议，专门为基于SMP的服务器的群集间通信而设计的。
随着基于多内核和多处理器的系统级芯片变得越来越普遍，基于消息的通信系统将通过每内核多任务的方式帮助管理系统的复杂度，Quadros Systems公司总裁Tom Barrett表示。“这种方法也让应用开发人员摆脱了硬件方面的工作，使他们可以将精力集中在实际应用代码上面，”他说，“这是因为IPC框架使用消息把应用从硬件中屏蔽出来，同时把运行不同OS的不同类型处理器也连接了起来。”
Brehmer指出， PolyCore公司支持的模型是一种对等(P2P)框架，其内核并行工作，彼此无关。这种方法提供了较高的性能，这是因为，即使某一内核在等待数据，而其余的内核也都在继续工作。
此外，通过把任务重新编译到一个不同的内核上，开发人员能够对不同的划分方案进行测试，以确定最佳配置。
PolyCore公司希望在这一领域领先于竞争对手，目前正在致力于开发下一代对等机制，旨在使开发人员能够以常规的顺序方法编写代码，并通过在一个单独的配置文件中详细指定划分点来实现代码自动划分。Brehmer表示，这样一来，几部分代码可以并行运行，运行时由系统自动处理通信。“这就让开发人员可以继续使用标准的C语言，同时还能以不同的方式来划分代码。”
面向多内核的适当开发工具
众多纷争焦点之一是目前这一代软件工具和构建模块是否适合于基于多内核SoC和多处理器设计的应用软件代码需求。Express Logic公司的Carbone尤其关注调试工具。
“它们和代码开发及系统划分问题同样复杂，在调试级上非常麻烦。” Carbone指出，“多个CPU就意味着有多个OS或者是同一个OS的多个实例化，而且在每一个目标对象上都存在调试问题，也意味着管理并协调各CPU间工作的中间件的开发中的调试问题。”
另一方面，飞思卡尔公司的Dubin则认为，在目前这一代多内核芯片设计中，开发人员面临的代码开发和调试方面的许多问题是能够解决的，即使不是利用现有工具，也可以利用现有技术的直接衍生方法。
TI 的O‘Shanna的意见介于上述观点之间。他认为，目前的调试方法学已足够，并可扩展来解决短期内将出现的众多问题，但随着处理器数目的增加，它们将不够用。“一块芯片上有两三个处理器的设计已经出现，眼下众多CPU架构获授权者已开始讨论具有六七个内核的SoC设计了。”
但O‘Shanna指出，必须解决这个问题的不是软件提供商，而是相应的硬件商。实际上，他相信整个行业都将不得不对现在作为标准的JTAG 和 Nexus调试接口规范进行延伸扩展。
写作项目
“我们目前缺乏对芯片内部的足够了解，无法收集到足够的所需信息以便于在这样一个复杂环境中进行调试。”他表示，“TI正在积极寻求许多替代方案，但这需要整个行业的努力。”
的确，行业似乎在往这个方向发展。例如，Eclipse 社群已经承担了风河系统公司提议的旨在建立一个共同调试模型的设备软件开发平台(Device Software Development Platform) 项目下面的一个子项目，风河系统公司CTO首席技术专家Martin Konig表示。
这项工作的目的是设计出能够与许多支持传统的RISC、DSP和网络处理器的调试引擎共同工作的接口和观察方案。
多处理发烧友组织(Multi Processing Aficionado)也在进行另一项尝试性努力，即讨论与多处理架构一起使用的某些公共、行业性标准及API的可行性， PolyCore公司的 Brehmer介绍说。该组织计划不久后举行一个为期三天的会议，目的在于就多内核和多处理器设计对工程社群进行培训。
然而，多内核DSP供应商Cradle Technologies公司的产品开发总监Koursh Amiri却认为，所有这些努力都是徒劳的。Amiri的结论是，独立性平台工具及方法只在一定程度上有用；在下一代技术中，可能必需把它们更紧密地与特定硬件甚至是特定应用相联结。他认为：“尽管有可能使用熟悉的语言、方法和开发工具，但针对具体底层基础架构和应用，它们仍将需要专门的多内核挂接(multicore hook)。比如调试时，典型的方案即一个处理器、一个OS、一个工具的方案是不切实际的。”
例如，他解释，在多内核环境中，必需设置多个断点，并让某个特定处理器或全部处理器来响应这些断点。
“在某些情况下，开发人员需要知道哪一个处理器或哪几个处理器已到断点，”Amiri表示，“故开发人员有时需要这个内核来单步运行，所有其它内核一致响应或逐个响应。”
“性能分析期间，除了每一过程所需周期数目、每代码行所需数目等传统参数外，多内核开发人员还需要了解处理器之间的交互作用、等待时间以及存储利用率等。”
这就要求在特定工具和特定硬件架构之间的连接应该更加紧密得多。因此， TI和飞思卡尔等已进入第二代多内核设计的公司，投入大量努力来开发特别适于其架构的特定工具，并收购软件公司来获取这种能力， Amiri对此并不感惊讶。
作者：柯伯南