多核心SoC改变互连要求2

多核心SoC改变互连要求2file:///C:\DOCUME~1\Steve\LOCALS~1\Temp\msohtml1\01\clip_image001.jpg
图1：当系统只包含一个运算系统时，系统级的通讯串流数目很有限。在多核心SoC中，由于每个核心分别处理各自的通讯串流，有可能实现每芯片多个通讯串流。
QoS考虑
过去，为了提高系统性能，每一个功能采用一个专用处理器。随着多个并行通讯通讯串流的出现，这种做法导致服务质量(QoS)问题急剧增加。为了最佳化频宽并防止各个通讯串流之间产生干扰，在许多情况下都使用了三种单独的互连。在这些系统中，每一个处理器执行一个功能，并分别负责单一或最多很少几个通讯串流。
然而，多核心SoC的问世使这种局面大为改观。由于每个核心均可分别处理各自的通讯串流，故有可能在每颗芯片上实现多个通讯串流。
平行地执行现有程序代码，在单颗多核心SoC上实现控制、数据和管理面功能融合的这一近期目标，预计将作为多核心架构的权宜之计。这种方法可在一个四核心组件上产生至少三个以上的通讯串流。长远来看，软件将支持多核心，并回复到运用众多核心执行离散数据或控制面板功能。在任一种情况下，不论何处采用多核心SoC都将出现多个通讯串流。随着使用8、16甚至更多核心的下一代SoC问世，未来2-4年间，单颗组件所能支持的通讯串流数目将大幅增加。
目前的互连支持多个通讯串流吗?答案是肯定的。透过在单一互连传输之前进行多任务，可支持任何数目的通讯串流。但仍存在两大挑战：在目的节点如何对通讯串流进行多任务分离，如何赋予每一个通讯串流独特的服务参数，如保证频宽和平均或最坏延迟?
要解决这些问题，协议需要具备好几个功能。首先，这个协议必须能够对各个通讯串流进行差异化。换言之，应该能够检查缆在线的数据封包，并决定其属于哪一个通讯串流?其次，当数据封包透过互连传输时，必须能够执行服务参数。这一点可透过控制仲裁和流量控制来实现。例如，稳健的SoC需要多个通讯流量控制机制，以限制互连上的一系列拥塞事件。这些机制可能包括链路到链路、端到端和进/出流量管理。
嵌入式系统中应用最广泛的互连也许是以太网络。以太网络的可扩展性已在多年服务中得到了充分的证实。基本的Layer 2以太网络讯框只支持数据报类型(datagram-style)的处理，而且没有已定义的流量差异化头字段。但之后，从Layer 2的VLAN标签到更广泛的Layer3 IP报头中的‘5Tuples(五元组)’，各种流量差异化方法被放在最高层。其中，‘五元组’方案可支持数百万个通讯串流。
不幸的是，对以太网络而言，QoS已证实是一个更大的挑战。这是因为只有一个有限的链路级PAUSE-讯框协议可被采用，而缺乏广获采纳的流量控制机制所致。在链路级之外，有少数可解决此一问题的解决方案正在获得更多支持，其中包括在Layer 2采用VLAN优先级标签(802.1Q)，或在Layer 2和Layer 3之间采用MPLS报头。流量管理也是常用方法。通常，在封闭式嵌入式系统中仅能发现一部份的这类方案；针对以太网络，目前尚未有特定的完整与一贯性的方法。
另一个问题的出现，是由于大部份在以太网络上分层的方案往往采用软件来实现。由于硬件支持较少，可获得的QoS参数受通讯串流通过软件堆栈时产生的延迟和延迟抖动所限制。
1999年定义的RapidIO互连规格代表了一种更先进的系统互连方案。在该规格的开发过程中，QoS曾是一个重要考虑事项，包含了好几种流量控制机制，如重试(retry)和基于信用(credit-based)的链路级流量控制、端到端XON/XOFF和流量控制协议。
在嵌入式系统中广获采用的另一种互连技术是PCI Express (PCIe)。PCIe最初瞄准PC和服务器市场，支持配置、事件消息发送和读写处理。这种技术在系统级的QoS支持很有限。在per-VC basis上有稳健的基于信用的链路级流量控制，足以实现点对点通讯。
在实际应用中，以太网络可以实现稳健的流量差异化，但缺乏稳健的QoS特性。大多数PCIe实现方案都没有流量差异化能力。PCIe的流量控制有限，似乎是针对未来多核心组件准备最不足的组件。三者中RapidIO潜力最大，因为它支持三个具有优先级之通讯串流上的数百万个差异化流量，并支持稳健的QoS特性。
幸运的是，许多新兴的多核心SoC都支持多个外部互连协议。如飞思卡尔的8核心QorIQP4080就可针对此处提到的所有协议进行配置。
作者：Greg Shippen
网络系统部系统架构师
飞思卡尔半导体

[转载自电子工程杂志]

Base_RFKIT08.10.000_lnx86_4of4.tar (494.17 MB)

2# zhoujin0
谢谢分享

thanks