引言
今天的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是復雜的多處理器環境，它必須共享片上資源，而不會帶來額外開銷，降低系統的效率。隊列管理有助于芯片資源的虛擬化，通過一種可靠的機制，分配帶寬、隔離故障，以及促進可靠的錯誤恢復，簡化了資源共享工作。流量管理通過一種滿足不同應用對延時和流量需求的方式，控制流量進出隊列的速率，從而確保了系統公平地共享資源。通過硬件實現的虛擬化，開發人員可以卸載隊列與流量管理工作，從而增強應用的效率、獲得最大的資源吞吐量、減少延時，增加系統的可靠性。