引言
今天的SoC（系统单芯片）处理器都集成了一系列的核心、加速器和其它处理单元。这些异质的多核架构提供了更多的计算能力，但其复杂性也为各种应用中嵌入系统的开发人员带来了新的挑战，这些应用包括控制层处理器、视频服务器、无线基站，以及宽带网关等。如果是分立的核心，每个核心都能完全地访问和控制自己的资源。这种可预测的访问能够做直接的管理，而有实时约束的应用也具备了确定的性能。然而，在一个多核架构中，各个核心共享资源，潜在的竞争使很多设计因素复杂化，例如处理延时以及可靠地中断处理。
为了提供与单核器件相当的确定性能，多核架构开始采用已经过网络通信验证的资源共享与管理技术。这些架构使用已有的队列与流量管理技术，在多个核心之间有效地分配资源、使吞吐量最大化、尽可能减小响应延时，并且避免了不必要的拥挤。
1 资源虚拟化
从架构的角度看，SoC是多核心的复杂系统，它通过一个高速结构，将各种控制与资源连接起来（图1）。在很多方式上，一片SoC内部的无数交互操作都很像一个有很多资源（或核心）的通信网络，这些资源与相同目的地做交互操作，包括内存、外设与总线。显然，设计人员用于提高网络效率的带宽管理技术（如虚拟化）也能用于管理多处理器核心以及共享外设之间的流量。
图1.下一代SOC是多核心访问相同的共同资源的复杂系统
片上资源的虚拟化使各个核心能够共享访问权；这种共享的访问权对应用是透明的。每个应用都可以把一个资源看作像自己独有一样，而一个虚拟化管理器用于汇总共享的所有权（由所分配的带宽量所测定）。对资源的虚拟访问和共享访问都需要一个队列管理器和一个流量管理器。各应用使用一个或多个队列，缓存对某个资源的访问。虚拟化为队列增加事件或事务，当资源可用时将它们从队列中拉出。队列包含了一个指向缓冲区中数据的缓存描述符（buffer descriptor），并且实现队列可以有多种方式，具体取决于应用的需求。一只SoC所支持的队列数是不定的，从数百个到数万个，可满足各种应用的需求。
队列管理器可刷新队列的状态，即：队列大小、头指针、尾指针，以及起始地址，并且维护填充水平与阈值，包括全满（full）、将满（almoST full）、将空（almost empty）和全空（empty）。队列管理器还为每个队列提供完全的内存管理，包括空闲池的缓冲分配与回收，以及当某个队列中增加事件时的访问权检查（图2）。多个请求者可以同时为一个或多个队列增加描述符，也能在等待某项服务的多个队列中做出选择。
对于指向相同资源的多个队列，管理器作为可用带宽的仲裁器。此任务不仅是在共享某个资源的各应用之间，也包括一个应用可能必须使能QoS（服务质量）的多个队列之间。
流量管理采用监管与整形机制，测量并控制指定给某个流或一组流的带宽数。监管机制用于控制流量管理器为某个队列增加事件的速率，而整形机制则是流量管理器从队列中去除事件的速率。为了获得最佳的控制，以及管理队列优先权的能力，必须在每个队列基础上实现监管与整形。流量管理器亦根据一个预设的服务算法，将多个队列映射到单一的共享资源。
有了队列和流量管理，就可以提供可靠的端至端QoS。这种方案允许多个路径共享一个资源，而不会对带宽的预订产生负面影响。精细粒度QoS支持SLA（服务水平协议），保证了在每个流量基础上的最小、平均和最大带宽。开发人员可以实现队列水平的流量标记与度量，以防止出现拥塞。拥塞的早期通知使队列管理器能够采用正确的措施，通过向流量资源的反馈，去除对可能丢弃数据包的不必要处理，或理想情况下，能完全避免拥塞。
举例来说，一个基于队列与流量管理的以太网驱动程序能防止任何一个处理器不公平地独占端口带宽。它还能确保带宽分配以及最大的延时约束，而与其它队列状态无关。驱动程序支持对仲裁方法的选择（例如：严格优先级或带权重的轮叫），有助于实现可靠的实时服务，如视频流。最后，多个资源还可以共享以太网端口，而不会对带宽预订产生负面影响。像IP（互联网协议）转发这类任务很容易可靠地实现，而对延时敏感的应用（如音视频的发送）则受益于确定且可靠的端口管理。另外，当用硬件实现了队列和流量管理时，驱动程序几乎无需软件开销，就可以维持端至端的QoS。
2 虚拟化层
早期的多核SoC与初期的网络处理器类似，都将虚拟化资源的全部工作留给了开发人员。应用在某种程度上必须判断出自己在与其它应用共享某个资源。当一个应用使用某个共享资源时，它必须以某种与其它应用共存的方式这样做。操作系统也需要支持虚拟化。
图2.基于硬件的虚拟化卸下了应用处理器的队列管理负担，包括刷新队列状态，维持填充水平和阈值，分配与重新分配缓冲区，以及当应用要访问某队列时，确认其访问权限。
在一个传统架构中，处理器通过一个软件层，管理着自己对共享资源的访问（图3a）。处理器必须知道哪个资源是可用的，以及自己可以使用它们的频率。随着处理数量的增加，资源共享的复杂性也在增长。基于软件虚拟化的一个缺点在于，它为数据包存储以及接下来数据包获取的每个事务都引入了一个开销。这种开销消耗了处理器周期，为代码处理带来了复杂性。它还给虚拟化软件带来了带宽管理和满足预订保证的负担。即使通过工具实现了虚拟化代码的自动化创建，开发者仍然必须在应用交互通过虚拟化代码时，进行查错调试。
图3.（a）随着处理器数量的增长，资源共享的复杂性与开销也在增加
（b）除卸载了队列与流量管理工作以外，资源共享变得对应用透明
2.1 虚拟化增加了开销和复杂性，限制了多核SoC的使用
不过，队列和流量管理是一个相当确定性的过程，可以采用硬件实现。开发人员为某个应用配置一次队列，然后硬件机制就可以完整地卸下队列管理负载，因此将相当多的计算周期还给了应用处理器。动态改变分配的能力使得可以在运行时修改配置，以适应不断变化的工作负载。
在一个采用基于硬件的队列与同步机制的架构中，每个处理器都独立于其它处理器而运行（图3b）。通过资源的虚拟化，共享就对应用透明了。机制会分配每个处理器和每个任务的资源带宽，而每个处理器和任务运行时则像是资源唯一控制方。尽管不同应用实现队列和流量管理的粒度并不相同，但基于硬件的资源虚拟化与共享能显着提高系统的效率。
2.2 基于硬件的虚拟化层去除或加快了软件虚拟化层
虚拟化的卸载显着增加了处理器的效率。在某些情况下，基于硬件的虚拟化完全不需要基于软件的虚拟化，除了在初始配置期间。还有一些情况下，基于硬件的队列与流量管理大大加快了数据路径中虚拟化软件的速度。
2.3 基于硬件的虚拟化层还降低了设计的复杂性，加快了开发进度
因为它不需要开发人员围绕虚拟化层作实现和设计。这种方案简化了设计，加快了上市时间。
2.4 基于硬件的虚拟化层还提高了确定性
由于没有了虚拟化开销，就减少了系统中断的重要来源。于是降低了处理延时，增加了系统的响应能力。
这种方案的另一个好处是简化了调试工作。由于虚拟化和资源共享都是硬件功能，虚拟化层本身就不是开发过程的一部分。但如调试有要求，开发人员仍然拥有对队列的完全访问和控制能力。基于硬件的虚拟化层还增加了可靠性，因为硬件实现的队列和流量管理不易受很多在软件实现中容易出现的问题的影响。例如，如果基于软件的代码处理虚拟化有所折衷，则整个系统就很脆弱。采用基于硬件的实现时，就不存在有受损危险的中心化控制例程。
3 处理器卸载
所支持的队列卸载水平与实现有关。例如，有些SoC可能提供锁定机制，但并不管理队列的全部状态。理想情况下，开发人员想要一个支持不同配置的灵活系统，能直接与软件整合，并尽可能减少为适应SoC而做的软件修改。一个虚拟化机制可能很有效；但是，如果要与传统编程模型有大的变化，则移植应用代码会增加系统成本，延迟上市时间。
实现队列的方式也会影响到系统的性能。例如，队列的位置影响着哪些处理器可以访问这些队列。有些队列必须以内存类型存在，在整个芯片上分布，或者被捆绑到某个资源上。动态分配的队列使开发人员拥有某种灵活性，能恰当地将队列划分给应用和资源。对于采用多只多核SoC的系统，如拥有通过一个系统总线（如PCIe）管理队列的能力，则资源的共享不仅能在同一SoC的不同核心之间，而且能在不同SoC之间。例如，一个处理簇可以共享单个转发数据库。另外，一个多SoC系统可能拥有一个单一的深层数据包检查引擎，而运行在不同SoC上的应用必须访问该引擎。这种多芯片的资源共享能够实现更进一步的系统资源虚拟化。
多芯片架构中最大的设计挑战之一是用某种方式的分区工作，以将资源需求平均地分配给所有处理器。在基于软件的虚拟化中，这个过程可能非常耗时，为设计人员增加了负担，包括高效管理空闲内存池的挑战。另外，软件的任何修改都可能为资源需求带来变化，这就需要开发人员重新划分系统分区。非对称和对称多处理器架构都有很多这类问题。
采用基于硬件的虚拟化时，大多数分区管理任务放在硬件上，而操作系统则处理少量剩余任务。由于采用这种抽象分区，开发人员于做系统修改时，无需对系统做手工的重新分区。这种方案亦卸载了应用与操作系统的一些任务，如管理空闲的内存池。
4 带宽保证
对一个资源的控制亦扩展了一只处理器可以接受的最大分配限度，解决了接收端的处理瓶颈问题。例如，对于很多通信、音视频、数据采集以及测试与测量应用，接收处理器都有预期或可以处理的最大传输数据速率。在这些情况下，即使外设拥有更多的能力（因为其它处理器当前未使用它们的分配额），应用也不希望队列以更快的速率刷新，因为这种刷新可能超出接收处理器的能力，造成数据损失。
很多开发人员在设计时会采用最差情况方法；他们要确认有足够的容量支持最差情况的负载。但是，在典型工作条件下，这种方法无法用到全部的资源容量。例如，一个典型的轮转仲裁算法仅支持最低的配额。如果系统对某个资源有多达10个请求方，则每个请求方总是可以期望拥有至少10%的带宽。然而，如果仅有一个请求方活动，则该请求方可以获得100%的带宽。
虚拟与透明的资源分配方法意味着一个应用并不知道自己可能获得多少带宽。对于接收端存在瓶颈的应用，为某个资源设定最大配额的能力对系统的稳定非常重要。这个最大值使开发人员能够控制每个应用的资源带宽（无论采用了何种分配算法），以防止淹没接收端的处理器，并且防止了数据损失。开发人员还拥有用标准机制去管理拥塞的选择，如IEEE 802.1Qav或802.1Qau。
5 系统稳定性
一个应用有时可能会尝试使用某个并不具备访问权的资源。程序中的错误可能造成这种情况的出现，此时只有部分刷新的应用在使用中，或者当代码或数据内存出现被覆盖情况时。必须防止一个应用干扰到其它应用，即：写入到其它应用的内存空间；或对性能产生负面影响，例如，获取对某个共享资源的控制。在基于软件的资源共享实现中，一个损坏的应用可能忽视自己的带宽配额，而去独占一个共享资源。同样，如果掌控虚拟化的处理器损坏，则队列机制就会失效，使整个系统宕机。
基于硬件的队列管理能在系统的各个部件之间提供保护。最基本的故障隔离方式是阻止对分配给其它应用的内存与资源带宽的访问。为了使虚拟化资源对应用完全透明，队列和流量管理器必须只对损坏的应用采取行动。换句话说，必须要将应用与其它应用的活动屏蔽开来，并且要适应其它应用的故障，以维持稳定性。就其特性而言，专用队列可隔离故障，防止其它处理器和应用受到影响。这类队列还有利于有效的错误恢复；专用队列可以完全地清除错误，而不会使其它应用的数据受到损失。
一个队列与流量管理控制器可以实现对非法资源访问的多级响应。最简单的响应是阻止访问，并给应用生成一个警报，通常是通过一个中断。这个警报告诉应用，它试图做了一些不应做的事。第二种方法是由开发人员记录下使用的违背情况，帮助在现场查错。队列与流量控制器亦必须能够通过触发一个复位，并重新初始化一个可能损坏的应用，逐步升级其响应。理想情况下，开发人员可以创建一个控制此响应的策略。例如，开发人员可以设定一个阈值，如果某个应用做了三次非法访问，就认为它是一个已损坏的应用，必须重新启动。
6 部分虚拟化
当一系列事务必须依次发生时，这种要求就成为了一个阻塞实例，因为其它请求方必须等待此事务的完成，然后才能获得资源的控制权。考虑一个典型的SATA（串行先进技术连接）事务，此时首先要配置SATA端口，然后执行一个指令序列。与数据包都是单个事件的以太网端口不同，SATA端口必须锁定给某个应用，直到事务完成时为止；否则，两个应用会相互覆盖，致使谁也无法完成自己的任务。
图4.（a）硬件实施的虚拟化在有完全宽带管理的SOC中也能实现资源分配
（b）这种方案能够在整个系统上高效地共享资源
尽管各个应用无法完全共享支持这种事务特性的资源，但对配额可以做部分虚拟化。首先，等待使用资源的应用必须确认端口空闲可用，然后在使用期间锁定端口。对锁定的支持要求在操作系统中有一个薄的软件层，这样就能相互通信，看哪个应用拥有对锁的控制权。不过，硬件的使用可以管理锁，并加快锁的获得速度。必须用硬件实现锁的获取，从而为资源提供一种失效恢复机制；或者，也可以用一个加锁处理器去锁定资源。
根据应用情况，系统必须支持可以完全虚拟化的共享资源，以及需要锁定的共享资源。例如，一片SoC可以提供一个不共享的SATA端口，但只有一个处理器可以使用它，而资源的共享必须在软件中实现。另外通过对可锁定资源的支持，SoC中的核心仍能够以一种对所有应用透明的方式，共享资源，具有失效恢复的可靠性。
多核架构的一个重要方面是易于集成。将多个处理器做到一只芯片上的能力，需要应用软件的直接迁移；否则，开发人员还不如去设计一个新的系统。
在确定迁移到虚拟化架构是否方便时，必须考虑一系列因素。例如，架构必须支持多操作系统，因为根据需要支持的应用情况，多处理器经常会在多个核心上使用多个操作系统。仅支持一个操作系统的多核架构会使开发人员被迫采用该操作系统，然后将所有代码移植到它上面。而支持多个操作系统时，一片多核SoC就简化了代码迁移工作。
另外，还需要考虑到QoS问题，因为各个应用有不同的带宽需求。延时敏感型应用（如视频流）需要实时访问共享资源，而数据型的应用（如内容下载）可以容忍延迟，充分利用未使用的带宽。为不同带宽需求提供服务的能力使开发人员能够在相同的处理簇下整合异质的应用。
还要考虑架构是否包含了透明的资源共享，因为透明性能让开发人员同时迁移支持虚拟化的应用以及不支持虚拟化的应用。另外一个方面是去除软件虚拟化层。虽然在做SoC之间的移植时，某些代码的重写是必要的，但对很多应用来说，当转向采用硬件资源共享的SoC时，大多数的变动并不是修改软件，而是消除软件虚拟化层。去掉这一层可简化系统设计与查错工作，增加了系统的效率。对于制造商已取得虚拟化代码许可的情况，去掉此层还可以降低系统成本。
还有一个要考虑的因素，即架构是否整合了系统资源。当一个系统采用多只芯片和操作系统时，每个都有自己的存储资源。通过资源的硬件管理，所有任务都可以共享对资源的访问。例如，一块硬盘或一个以太网端口可以服务于整个系统（甚至跨各个SoC），而不是像传统架构那样需要多块硬盘。这种方案可节省设备成本，降低系统部件的总数。
SoC之间的通信也很重要。各个应用可以通过一个大带宽系统总线（如PCIe）共享资源，从而实现了SoC之间的共享。传统架构会给每个处理器分配一个固定带宽，这种方法限制了各核之间的有效QoS管理，难以超额申请（图4a）。采用基于硬件的虚拟化时，即使在SoC之间，资源的分配也是灵活的（图4b）。通过速率监管、流量整形，以及队列仲裁，反映并平衡着每个处理器与应用的需求，从而能够实现全带宽管理。同样，这种方案还能够获得资源（如一块硬盘或一个安全引擎）在整个系统上的有效共享，而不仅是一只处理器。
另外还应考虑的是处理器之间的通信，因为多处理器系统经常要在各处理器之间传输相当多的数据。队列管理机制为SoC上各处理器之间以及多个SoC之间的通信提供了一种简单而有效的加速方法。
7 结语
今天的下一代SoC是复杂的多处理器环境，它必须共享片上资源，而不会带来额外开销，降低系统的效率。队列管理有助于芯片资源的虚拟化，通过一种可靠的机制，分配带宽、隔离故障，以及促进可靠的错误恢复，简化了资源共享工作。流量管理通过一种满足不同应用对延时和流量需求的方式，控制流量进出队列的速率，从而确保了系统公平地共享资源。通过硬件实现的虚拟化，开发人员可以卸载队列与流量管理工作，从而增强应用的效率、获得最大的资源吞吐量、减少延时，增加系统的可靠性。