引言

今天的SoC（系統(tǒng)單芯片）處理器都集成了一系列的核心,、加速器和其它處理單元。這些異質(zhì)的多核架構(gòu)提供了更多的計算能力,，但其復(fù)雜性也為各種應(yīng)用中嵌入系統(tǒng)的開發(fā)人員帶來了新的挑戰(zhàn),，這些應(yīng)用包括控制層處理器、視頻服務(wù)器,、無線基站，以及寬帶網(wǎng)關(guān)等,。如果是分立的核心,，每個核心都能完全地訪問和控制自己的資源。這種可預(yù)測的訪問能夠做直接的管理,，而有實時約束的應(yīng)用也具備了確定的性能,。然而，在一個多核架構(gòu)中,，各個核心共享資源,，潛在的競爭使很多設(shè)計因素復(fù)雜化，例如處理延時以及可靠地中斷處理,。

為了提供與單核器件相當?shù)拇_定性能,，多核架構(gòu)開始采用已經(jīng)過網(wǎng)絡(luò)通信驗證的資源共享與管理技術(shù)。這些架構(gòu)使用已有的隊列與流量管理技術(shù),，在多個核心之間有效地分配資源,、使吞吐量最大化、盡可能減小響應(yīng)延時,，并且避免了不必要的擁擠,。

1 資源虛擬化

從架構(gòu)的角度看，SoC是多核心的復(fù)雜系統(tǒng),，它通過一個高速結(jié)構(gòu),，將各種控制與資源連接起來（圖1）。在很多方式上,，一片SoC內(nèi)部的無數(shù)交互操作都很像一個有很多資源（或核心）的通信網(wǎng)絡(luò),，這些資源與相同目的地做交互操作，包括內(nèi)存,、外設(shè)與總線,。顯然，設(shè)計人員用于提高網(wǎng)絡(luò)效率的帶寬管理技術(shù)（如虛擬化）也能用于管理多處理器核心以及共享外設(shè)之間的流量,。

圖1.下一代SOC是多核心訪問相同的共同資源的復(fù)雜系統(tǒng)

片上資源的虛擬化使各個核心能夠共享訪問權(quán),；這種共享的訪問權(quán)對應(yīng)用是透明的,。每個應(yīng)用都可以把一個資源看作像自己獨有一樣，而一個虛擬化管理器用于匯總共享的所有權(quán)（由所分配的帶寬量所測定）,。對資源的虛擬訪問和共享訪問都需要一個隊列管理器和一個流量管理器,。各應(yīng)用使用一個或多個隊列，緩存對某個資源的訪問,。虛擬化為隊列增加事件或事務(wù),，當資源可用時將它們從隊列中拉出。隊列包含了一個指向緩沖區(qū)中數(shù)據(jù)的緩存描述符（buffer descriptor）,，并且實現(xiàn)隊列可以有多種方式,，具體取決于應(yīng)用的需求。一只SoC所支持的隊列數(shù)是不定的,，從數(shù)百個到數(shù)萬個,，可滿足各種應(yīng)用的需求。

隊列管理器可刷新隊列的狀態(tài),，即：隊列大小,、頭指針、尾指針,，以及起始地址,，并且維護填充水平與閾值，包括全滿（full）,、將滿（almoST full）,、將空（almost empty）和全空（empty）。隊列管理器還為每個隊列提供完全的內(nèi)存管理,，包括空閑池的緩沖分配與回收,，以及當某個隊列中增加事件時的訪問權(quán)檢查（圖2）。多個請求者可以同時為一個或多個隊列增加描述符,，也能在等待某項服務(wù)的多個隊列中做出選擇,。

對于指向相同資源的多個隊列，管理器作為可用帶寬的仲裁器,。此任務(wù)不僅是在共享某個資源的各應(yīng)用之間,，也包括一個應(yīng)用可能必須使能QoS（服務(wù)質(zhì)量）的多個隊列之間。

流量管理采用監(jiān)管與整形機制,，測量并控制指定給某個流或一組流的帶寬數(shù),。監(jiān)管機制用于控制流量管理器為某個隊列增加事件的速率，而整形機制則是流量管理器從隊列中去除事件的速率,。為了獲得最佳的控制,，以及管理隊列優(yōu)先權(quán)的能力，必須在每個隊列基礎(chǔ)上實現(xiàn)監(jiān)管與整形。流量管理器亦根據(jù)一個預(yù)設(shè)的服務(wù)算法,，將多個隊列映射到單一的共享資源,。

有了隊列和流量管理，就可以提供可靠的端至端QoS,。這種方案允許多個路徑共享一個資源,，而不會對帶寬的預(yù)訂產(chǎn)生負面影響。精細粒度QoS支持SLA（服務(wù)水平協(xié)議）,，保證了在每個流量基礎(chǔ)上的最小,、平均和最大帶寬。開發(fā)人員可以實現(xiàn)隊列水平的流量標記與度量,，以防止出現(xiàn)擁塞,。擁塞的早期通知使隊列管理器能夠采用正確的措施，通過向流量資源的反饋,，去除對可能丟棄數(shù)據(jù)包的不必要處理,，或理想情況下，能完全避免擁塞,。

舉例來說，一個基于隊列與流量管理的以太網(wǎng)驅(qū)動程序能防止任何一個處理器不公平地獨占端口帶寬,。它還能確保帶寬分配以及最大的延時約束,，而與其它隊列狀態(tài)無關(guān)。驅(qū)動程序支持對仲裁方法的選擇（例如：嚴格優(yōu)先級或帶權(quán)重的輪叫）,，有助于實現(xiàn)可靠的實時服務(wù),，如視頻流。最后,，多個資源還可以共享以太網(wǎng)端口,，而不會對帶寬預(yù)訂產(chǎn)生負面影響。像IP（互聯(lián)網(wǎng)協(xié)議）轉(zhuǎn)發(fā)這類任務(wù)很容易可靠地實現(xiàn),，而對延時敏感的應(yīng)用（如音視頻的發(fā)送）則受益于確定且可靠的端口管理,。另外，當用硬件實現(xiàn)了隊列和流量管理時,，驅(qū)動程序幾乎無需軟件開銷,，就可以維持端至端的QoS。

2 虛擬化層

早期的多核SoC與初期的網(wǎng)絡(luò)處理器類似,，都將虛擬化資源的全部工作留給了開發(fā)人員,。應(yīng)用在某種程度上必須判斷出自己在與其它應(yīng)用共享某個資源。當一個應(yīng)用使用某個共享資源時,，它必須以某種與其它應(yīng)用共存的方式這樣做,。操作系統(tǒng)也需要支持虛擬化。

圖2.基于硬件的虛擬化卸下了應(yīng)用處理器的隊列管理負擔，包括刷新隊列狀態(tài),，維持填充水平和閾值,，分配與重新分配緩沖區(qū)，以及當應(yīng)用要訪問某隊列時,，確認其訪問權(quán)限,。

在一個傳統(tǒng)架構(gòu)中，處理器通過一個軟件層,，管理著自己對共享資源的訪問（圖3a）,。處理器必須知道哪個資源是可用的，以及自己可以使用它們的頻率,。隨著處理數(shù)量的增加,，資源共享的復(fù)雜性也在增長?；谲浖摂M化的一個缺點在于,，它為數(shù)據(jù)包存儲以及接下來數(shù)據(jù)包獲取的每個事務(wù)都引入了一個開銷。這種開銷消耗了處理器周期,，為代碼處理帶來了復(fù)雜性,。它還給虛擬化軟件帶來了帶寬管理和滿足預(yù)訂保證的負擔。即使通過工具實現(xiàn)了虛擬化代碼的自動化創(chuàng)建,，開發(fā)者仍然必須在應(yīng)用交互通過虛擬化代碼時,，進行查錯調(diào)試。

圖3.（a）隨著處理器數(shù)量的增長,，資源共享的復(fù)雜性與開銷也在增加

（b）除卸載了隊列與流量管理工作以外,，資源共享變得對應(yīng)用透明

2.1 虛擬化增加了開銷和復(fù)雜性，限制了多核SoC的使用

不過,，隊列和流量管理是一個相當確定性的過程,，可以采用硬件實現(xiàn)。開發(fā)人員為某個應(yīng)用配置一次隊列,，然后硬件機制就可以完整地卸下隊列管理負載,，因此將相當多的計算周期還給了應(yīng)用處理器。動態(tài)改變分配的能力使得可以在運行時修改配置,，以適應(yīng)不斷變化的工作負載,。

在一個采用基于硬件的隊列與同步機制的架構(gòu)中，每個處理器都獨立于其它處理器而運行（圖3b）,。通過資源的虛擬化,，共享就對應(yīng)用透明了。機制會分配每個處理器和每個任務(wù)的資源帶寬,，而每個處理器和任務(wù)運行時則像是資源唯一控制方,。盡管不同應(yīng)用實現(xiàn)隊列和流量管理的粒度并不相同,，但基于硬件的資源虛擬化與共享能顯著提高系統(tǒng)的效率。

2.2 基于硬件的虛擬化層去除或加快了軟件虛擬化層

虛擬化的卸載顯著增加了處理器的效率,。在某些情況下,，基于硬件的虛擬化完全不需要基于軟件的虛擬化，除了在初始配置期間,。還有一些情況下,，基于硬件的隊列與流量管理大大加快了數(shù)據(jù)路徑中虛擬化軟件的速度。

2.3 基于硬件的虛擬化層還降低了設(shè)計的復(fù)雜性,，加快了開發(fā)進度

因為它不需要開發(fā)人員圍繞虛擬化層作實現(xiàn)和設(shè)計,。這種方案簡化了設(shè)計，加快了上市時間,。

2.4 基于硬件的虛擬化層還提高了確定性

由于沒有了虛擬化開銷,，就減少了系統(tǒng)中斷的重要來源。于是降低了處理延時,，增加了系統(tǒng)的響應(yīng)能力,。

這種方案的另一個好處是簡化了調(diào)試工作。由于虛擬化和資源共享都是硬件功能,，虛擬化層本身就不是開發(fā)過程的一部分,。但如調(diào)試有要求，開發(fā)人員仍然擁有對隊列的完全訪問和控制能力,?；谟布奶摂M化層還增加了可靠性，因為硬件實現(xiàn)的隊列和流量管理不易受很多在軟件實現(xiàn)中容易出現(xiàn)的問題的影響,。例如，如果基于軟件的代碼處理虛擬化有所折衷,，則整個系統(tǒng)就很脆弱,。采用基于硬件的實現(xiàn)時，就不存在有受損危險的中心化控制例程,。

3 處理器卸載

所支持的隊列卸載水平與實現(xiàn)有關(guān),。例如，有些SoC可能提供鎖定機制,，但并不管理隊列的全部狀態(tài),。理想情況下，開發(fā)人員想要一個支持不同配置的靈活系統(tǒng),，能直接與軟件整合,，并盡可能減少為適應(yīng)SoC而做的軟件修改。一個虛擬化機制可能很有效,；但是,，如果要與傳統(tǒng)編程模型有大的變化,，則移植應(yīng)用代碼會增加系統(tǒng)成本，延遲上市時間,。

實現(xiàn)隊列的方式也會影響到系統(tǒng)的性能,。例如，隊列的位置影響著哪些處理器可以訪問這些隊列,。有些隊列必須以內(nèi)存類型存在,，在整個芯片上分布，或者被捆綁到某個資源上,。動態(tài)分配的隊列使開發(fā)人員擁有某種靈活性,，能恰當?shù)貙㈥犃袆澐纸o應(yīng)用和資源。對于采用多只多核SoC的系統(tǒng),，如擁有通過一個系統(tǒng)總線（如PCIe）管理隊列的能力,，則資源的共享不僅能在同一SoC的不同核心之間，而且能在不同SoC之間,。例如,，一個處理簇可以共享單個轉(zhuǎn)發(fā)數(shù)據(jù)庫。另外,，一個多SoC系統(tǒng)可能擁有一個單一的深層數(shù)據(jù)包檢查引擎,，而運行在不同SoC上的應(yīng)用必須訪問該引擎。這種多芯片的資源共享能夠?qū)崿F(xiàn)更進一步的系統(tǒng)資源虛擬化,。

多芯片架構(gòu)中最大的設(shè)計挑戰(zhàn)之一是用某種方式的分區(qū)工作,，以將資源需求平均地分配給所有處理器。在基于軟件的虛擬化中,，這個過程可能非常耗時,，為設(shè)計人員增加了負擔，包括高效管理空閑內(nèi)存池的挑戰(zhàn),。另外,，軟件的任何修改都可能為資源需求帶來變化，這就需要開發(fā)人員重新劃分系統(tǒng)分區(qū),。非對稱和對稱多處理器架構(gòu)都有很多這類問題,。

采用基于硬件的虛擬化時，大多數(shù)分區(qū)管理任務(wù)放在硬件上,，而操作系統(tǒng)則處理少量剩余任務(wù),。由于采用這種抽象分區(qū)，開發(fā)人員于做系統(tǒng)修改時,，無需對系統(tǒng)做手工的重新分區(qū),。這種方案亦卸載了應(yīng)用與操作系統(tǒng)的一些任務(wù)，如管理空閑的內(nèi)存池,。

4 帶寬保證

對一個資源的控制亦擴展了一只處理器可以接受的最大分配限度,，解決了接收端的處理瓶頸問題,。例如，對于很多通信,、音視頻,、數(shù)據(jù)采集以及測試與測量應(yīng)用，接收處理器都有預(yù)期或可以處理的最大傳輸數(shù)據(jù)速率,。在這些情況下,，即使外設(shè)擁有更多的能力（因為其它處理器當前未使用它們的分配額），應(yīng)用也不希望隊列以更快的速率刷新,，因為這種刷新可能超出接收處理器的能力,，造成數(shù)據(jù)損失。

很多開發(fā)人員在設(shè)計時會采用最差情況方法,；他們要確認有足夠的容量支持最差情況的負載,。但是，在典型工作條件下,，這種方法無法用到全部的資源容量,。例如，一個典型的輪轉(zhuǎn)仲裁算法僅支持最低的配額,。如果系統(tǒng)對某個資源有多達10個請求方,，則每個請求方總是可以期望擁有至少10%的帶寬。然而,，如果僅有一個請求方活動,，則該請求方可以獲得100%的帶寬。

虛擬與透明的資源分配方法意味著一個應(yīng)用并不知道自己可能獲得多少帶寬,。對于接收端存在瓶頸的應(yīng)用,，為某個資源設(shè)定最大配額的能力對系統(tǒng)的穩(wěn)定非常重要。這個最大值使開發(fā)人員能夠控制每個應(yīng)用的資源帶寬（無論采用了何種分配算法）,，以防止淹沒接收端的處理器,，并且防止了數(shù)據(jù)損失。開發(fā)人員還擁有用標準機制去管理擁塞的選擇,，如IEEE 802.1Qav或802.1Qau。

5 系統(tǒng)穩(wěn)定性

一個應(yīng)用有時可能會嘗試使用某個并不具備訪問權(quán)的資源,。程序中的錯誤可能造成這種情況的出現(xiàn),，此時只有部分刷新的應(yīng)用在使用中，或者當代碼或數(shù)據(jù)內(nèi)存出現(xiàn)被覆蓋情況時,。必須防止一個應(yīng)用干擾到其它應(yīng)用,，即：寫入到其它應(yīng)用的內(nèi)存空間；或?qū)π阅墚a(chǎn)生負面影響,，例如,，獲取對某個共享資源的控制,。在基于軟件的資源共享實現(xiàn)中，一個損壞的應(yīng)用可能忽視自己的帶寬配額,，而去獨占一個共享資源,。同樣，如果掌控虛擬化的處理器損壞,，則隊列機制就會失效,，使整個系統(tǒng)宕機。

基于硬件的隊列管理能在系統(tǒng)的各個部件之間提供保護,。最基本的故障隔離方式是阻止對分配給其它應(yīng)用的內(nèi)存與資源帶寬的訪問,。為了使虛擬化資源對應(yīng)用完全透明，隊列和流量管理器必須只對損壞的應(yīng)用采取行動,。換句話說,，必須要將應(yīng)用與其它應(yīng)用的活動屏蔽開來，并且要適應(yīng)其它應(yīng)用的故障,，以維持穩(wěn)定性,。就其特性而言，專用隊列可隔離故障,，防止其它處理器和應(yīng)用受到影響,。這類隊列還有利于有效的錯誤恢復(fù)；專用隊列可以完全地清除錯誤,，而不會使其它應(yīng)用的數(shù)據(jù)受到損失,。

一個隊列與流量管理控制器可以實現(xiàn)對非法資源訪問的多級響應(yīng)。最簡單的響應(yīng)是阻止訪問,，并給應(yīng)用生成一個警報,，通常是通過一個中斷。這個警報告訴應(yīng)用,，它試圖做了一些不應(yīng)做的事,。第二種方法是由開發(fā)人員記錄下使用的違背情況，幫助在現(xiàn)場查錯,。隊列與流量控制器亦必須能夠通過觸發(fā)一個復(fù)位,，并重新初始化一個可能損壞的應(yīng)用，逐步升級其響應(yīng),。理想情況下,，開發(fā)人員可以創(chuàng)建一個控制此響應(yīng)的策略。例如,，開發(fā)人員可以設(shè)定一個閾值,，如果某個應(yīng)用做了三次非法訪問，就認為它是一個已損壞的應(yīng)用,，必須重新啟動,。

6 部分虛擬化

當一系列事務(wù)必須依次發(fā)生時,，這種要求就成為了一個阻塞實例，因為其它請求方必須等待此事務(wù)的完成,，然后才能獲得資源的控制權(quán),。考慮一個典型的SATA（串行先進技術(shù)連接）事務(wù),，此時首先要配置SATA端口,，然后執(zhí)行一個指令序列。與數(shù)據(jù)包都是單個事件的以太網(wǎng)端口不同,，SATA端口必須鎖定給某個應(yīng)用,，直到事務(wù)完成時為止；否則,，兩個應(yīng)用會相互覆蓋,，致使誰也無法完成自己的任務(wù)。

圖4.（a）硬件實施的虛擬化在有完全寬帶管理的SOC中也能實現(xiàn)資源分配

（b）這種方案能夠在整個系統(tǒng)上高效地共享資源

盡管各個應(yīng)用無法完全共享支持這種事務(wù)特性的資源,，但對配額可以做部分虛擬化,。首先，等待使用資源的應(yīng)用必須確認端口空閑可用,，然后在使用期間鎖定端口,。對鎖定的支持要求在操作系統(tǒng)中有一個薄的軟件層，這樣就能相互通信,，看哪個應(yīng)用擁有對鎖的控制權(quán),。不過，硬件的使用可以管理鎖,，并加快鎖的獲得速度,。必須用硬件實現(xiàn)鎖的獲取，從而為資源提供一種失效恢復(fù)機制,；或者,，也可以用一個加鎖處理器去鎖定資源。

根據(jù)應(yīng)用情況,，系統(tǒng)必須支持可以完全虛擬化的共享資源,，以及需要鎖定的共享資源。例如,，一片SoC可以提供一個不共享的SATA端口,，但只有一個處理器可以使用它，而資源的共享必須在軟件中實現(xiàn),。另外通過對可鎖定資源的支持,，SoC中的核心仍能夠以一種對所有應(yīng)用透明的方式,，共享資源,，具有失效恢復(fù)的可靠性,。

多核架構(gòu)的一個重要方面是易于集成。將多個處理器做到一只芯片上的能力,，需要應(yīng)用軟件的直接遷移,；否則，開發(fā)人員還不如去設(shè)計一個新的系統(tǒng),。

在確定遷移到虛擬化架構(gòu)是否方便時,，必須考慮一系列因素。例如,，架構(gòu)必須支持多操作系統(tǒng),，因為根據(jù)需要支持的應(yīng)用情況，多處理器經(jīng)常會在多個核心上使用多個操作系統(tǒng),。僅支持一個操作系統(tǒng)的多核架構(gòu)會使開發(fā)人員被迫采用該操作系統(tǒng),，然后將所有代碼移植到它上面。而支持多個操作系統(tǒng)時,，一片多核SoC就簡化了代碼遷移工作,。

另外，還需要考慮到QoS問題,，因為各個應(yīng)用有不同的帶寬需求,。延時敏感型應(yīng)用（如視頻流）需要實時訪問共享資源，而數(shù)據(jù)型的應(yīng)用（如內(nèi)容下載）可以容忍延遲,，充分利用未使用的帶寬,。為不同帶寬需求提供服務(wù)的能力使開發(fā)人員能夠在相同的處理簇下整合異質(zhì)的應(yīng)用。

還要考慮架構(gòu)是否包含了透明的資源共享,，因為透明性能讓開發(fā)人員同時遷移支持虛擬化的應(yīng)用以及不支持虛擬化的應(yīng)用,。另外一個方面是去除軟件虛擬化層。雖然在做SoC之間的移植時,，某些代碼的重寫是必要的,，但對很多應(yīng)用來說，當轉(zhuǎn)向采用硬件資源共享的SoC時,，大多數(shù)的變動并不是修改軟件,，而是消除軟件虛擬化層。去掉這一層可簡化系統(tǒng)設(shè)計與查錯工作,，增加了系統(tǒng)的效率,。對于制造商已取得虛擬化代碼許可的情況，去掉此層還可以降低系統(tǒng)成本,。

還有一個要考慮的因素,，即架構(gòu)是否整合了系統(tǒng)資源。當一個系統(tǒng)采用多只芯片和操作系統(tǒng)時，每個都有自己的存儲資源,。通過資源的硬件管理,，所有任務(wù)都可以共享對資源的訪問。例如,，一塊硬盤或一個以太網(wǎng)端口可以服務(wù)于整個系統(tǒng)（甚至跨各個SoC）,，而不是像傳統(tǒng)架構(gòu)那樣需要多塊硬盤。這種方案可節(jié)省設(shè)備成本,，降低系統(tǒng)部件的總數(shù),。

SoC之間的通信也很重要。各個應(yīng)用可以通過一個大帶寬系統(tǒng)總線（如PCIe）共享資源,，從而實現(xiàn)了SoC之間的共享,。傳統(tǒng)架構(gòu)會給每個處理器分配一個固定帶寬，這種方法限制了各核之間的有效QoS管理,，難以超額申請（圖4a）,。采用基于硬件的虛擬化時，即使在SoC之間,，資源的分配也是靈活的（圖4b）,。通過速率監(jiān)管、流量整形,，以及隊列仲裁,，反映并平衡著每個處理器與應(yīng)用的需求，從而能夠?qū)崿F(xiàn)全帶寬管理,。同樣,，這種方案還能夠獲得資源（如一塊硬盤或一個安全引擎）在整個系統(tǒng)上的有效共享，而不僅是一只處理器,。

另外還應(yīng)考慮的是處理器之間的通信,，因為多處理器系統(tǒng)經(jīng)常要在各處理器之間傳輸相當多的數(shù)據(jù)。隊列管理機制為SoC上各處理器之間以及多個SoC之間的通信提供了一種簡單而有效的加速方法,。

7 結(jié)語

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