您可能已經習慣了芯片系統（SoC）的multicore處理器這一概念，而現實卻總是在不斷變化。8月份舉行的Hot Chips大會研討中，已經清楚的表明multicore正在向many-core發展：在SoC核心位置，密切相關的處理器內核的數量在不斷增長，從2個或者4個增加到8個、16個，甚至是很多，很多。

　　這種增長僅是摩爾定律發展的另一階段，系統開發人員還是能清楚的了解這一切嗎？從multicore發展到many-core是類型的變化，還是僅僅是規模的變化？這種轉變能解決系統開發人員面臨的問題嗎？

　　為找到這些問題的答案，我們與一些團隊進行了交流，他們已經在many-coreSoC開發上積累了一些設計經驗。我們向他們提出了一個簡單的問題：您的體驗與使用multicore有什么不同嗎？對于這一簡單的問題，我們得到了各種各樣的回答。

　　Many-core的發展

　　Hot Chips的論文列出了SoC體系結構向many-core領域發展的三條主要路線。我們從Cavium的Kin-Yip Liu在小規模無線基站SoC設計論文中闡述的路線開始，這些設計包括微基站、微微基站和毫微微基站。

　　名為Octeon Fusion CNF71xx的設計如 圖1 所示，包括兩個處理簇，含有四個一組的增強MIPS64內核，以及圍繞一個共享L2高速緩存的各種硬件加速器，還有6個為一組的數字信號處理（DSP）內核，每個內核都有很多硬件加速器，這些內核分布在共享存儲器交換架構周圍。

　　
圖1.Cavium的Octeon Fusion體系結構結合了CPU簇以及相連接的硬件加速器和分立的DSP內核簇。

　　四個CPU還很難說明是many-core設計。但是有兩個很好的理由讓我們的討論從這一芯片開始。首先，增加6個DSP內核使得芯片成為10核異構體系結構，表面上看已經進入many-core領域。其次，更多的是在理論上，Cavium使用內核的方式與傳統的multicore并不相同。

　　Multicore SoC將線程映射至內核的方式一般是靜態的。而隨著內核數量的增加，這種映射更具流動性。CPU和DSP可以按數據流來劃分，也可以構成虛擬流水線，每一個完成復雜任務的幾級任務。或者，處理器可以觀察任務序列，一旦空閑，就可以執行新任務。不斷增強一個處理器的能力來完成所有數據的處理，而這一概念正在轉向由很多處理器共同完成一項工作——從固定硬件到軟件與加速器的組合。這種概念上的變化確定了multicore與many-core計算之間的邊界。我們看到這種變化是從本地對稱的Octeon Fusion體系結構開始的。Cavium很顯然同意這一觀點。他們在Hot Chips上的研討表明，目前的芯片只是軟件兼容系列的開始，這些系列能夠從單核發展到48核。

　　作為對比，Fujitsu的Takumi Maruyama發表的論文介紹了公司的16核芯片SPARC64 X將成為服務器中心處理器。SPARC64 X與Octeon共享了一個重要的體系結構概念：16個SPARC內核簇圍繞一個大規模內核——24 Mbyte，共享L2高速緩存。但這也有很大的不同。這就是專用硬件加速器。Fujitsu將其稱之為“芯片軟件”。Fujitsu沒有在CPU之外開發松耦合加速器，來處理棘手的運算問題（在這個例子中，十進制數學運算、加密和數據庫函數等），而是開發了新的RISC類型指令來加速這些運算，在每一CPU的浮點單元流水線中增加了必要的執行硬件。因此，硬件加速并不能靈活的共享L2高速緩存，或者鏈接系統總線，而是成為CPU不可缺少的組成部分。實際上，這些加速器增加了指令，編譯器可以將其優化到CPU指令流中。

　　Intel和many-core

　　最后，考慮Intel的Xeon Phi，或者還可以考慮Intel資深首席工程師George Chrysos所介紹的Knights Corner，如 圖2 所示。在Chrysos有些含糊的描述中，該器件是采用了“50多個”x86處理器內核的協處理器，還含有四個GDDR存儲器控制器，以及與主處理器Xeon CPU連接的PCI Express? （PCIe?）接口。每一個處理器都有自己的專用矢量處理單元，以及自己的512 Kbyte L2高速緩存。L2高速緩存、GDDR控制器以及PCIe控制器不是由傳統的交換矩陣連接的，這樣會導致規模非常大而在物理上無法實現，而是由雙向環形總線連接。這一總線在每一方向上都有64字節數據通路，通過分布式標簽方案來實現所有L2之間的一致性。遵從體系結構的發展規律，Xeon Phi在內部與早期的multicore設計非常相似，即，在PlayStation 3中首次使用的IBM Cell協處理器。

　　
圖2.Intel的Xeon Phi是50多個x86內核構成的異構陣列，這些內核通過兩路跑道型互聯結構連接起來。

　　Xeon Phi代表了從multicore向many-core的深入發展。這里，與Cell不同，沒有專門的加速器或者專用存儲器結構，只有相對簡單的x86處理器，連接了矢量處理單元和高速緩存、DRAM控制器以及PCIe接口。所有這些芯片都專門用于執行x86指令代碼。Intel展望了Xeon Phi將用于物理、化學、生物和金融分析等應用中。

　　編程模型

　　這三種芯片代表了系統軟件開發人員三種完全不同的模型。Octeon Fusion非常專用：它是芯片基站。編程人員使用它時，將基站應用線程映射到CPU、加速器和DSP上，通過中心共享高速緩存來同步線程。雖然可以在CPU之間或者在DSP之間動態映射任務，還是需要在不同類型的處理器之間來回遷移一些任務。

　　對于軟件設計人員，16核SPARC64在兩方面是完全不同的。所有這些處理器都是一樣的，都共享一個L2，因此，不需要將線程鎖定某一CPU。硬件加速器位于指令級，由編譯器推斷其使用，而不是由編程器進行調用。您不需要在分立的硬件加速器之間輸入輸出數據，確定正確的線程位于正確的CPU上，或者與松耦合輔助處理器同步。

　　Xeon Phi在數量上與Fujitsu SPARC64芯片不同，北向有50個CPU，而不是16個。其互聯結構也明顯不同，連貫環上有適度的專用L2，而不是完全共享的L2。毫無疑問，對于與以前IBM相似的Intel體系結構，雙環是最高效的芯片實現方式。

　　Intel和Fujitsu芯片都具有同構體系結構的優點，不需要專門調用硬件加速器，性能與具體位置無關，沒有跑道方式那么復雜。軟件設計人員可以按照自己的方式，將任何混合數據流、多線程或者數據并行機映射到CPU中。

　　那么，這到底意味著什么？

　　很顯然，這三種完全不同的many-core芯片對軟件開發人員提出了不同的需求。但是，如果是這樣，這些SoC究竟給系統開發人員帶來了哪些問題呢？由于這些芯片是新出現的，因此，我們向其他公司中有many-core應用經驗的用戶提出了我們的問題。

　　他們建議我們應深入了解幾個不同的問題。一是配置：SoC需要多大的I/O帶寬、總線帶寬以及外部存儲器帶寬？第二，密切相關的問題是性能建模。芯片到底需要多大帶寬與它使用數據和產生數據的速度有關。第三是控制問題：SoC怎樣處理中斷？芯片初始化調試操作、電源管理和按序關斷時，都需要什么條件？還有功耗問題，在另一篇文章中專門解決了這一問題。

　　有經驗的用戶還提出了另一個有用的建議：明確Octeon Fusion等異構專用SoC與Xeon Phi等同構芯片之間的不同。專家說，這兩方面代表了完全不同的挑戰。

　　數據之后

　　異構many-coreSoC盡管在內部組織上是圍繞共享存儲器和總線進行構建，而實際上用作數據流機。在某一工作模式下，已知數據流通過芯片的各種處理器來傳送，一般是固定的數據無關碼型。這些約束簡化了系統級分析。

　　全球研究組織IMEC （比利時Leuven）的軟件無線電（SDR）研究部科學項目總監Liesbet Van der Perre解釋說：“這些系統的存儲器數據流有很高的可預測性。在這些系統中，數據流定義了處理器和通路。在某些共享總線或者存儲器結構中的某些點上，您會看到瓶頸，但這通常是可以預測的。”

　　Van der Perre的計劃是采用可重新定義的粗粒度處理器陣列來實現移動SDR。芯片配置會隨著射頻工作模式而變化，但是，當射頻保持在某一模式上時，配置會保持穩定。那么，在某一模式下，陣列的行為實際上與靜態異構體系結構非常相似。一旦您理解了數據流之后，就比較容易對帶寬需求和功耗進行建模。其實施要求主要來自算法級模型。

　　這種實現方法是應用異構多處理器常用的方法，能夠以同樣的方式來使用同構many-core系統。對于某一工作模式，可以將任務固定映射至處理器和存儲器，明確設計團隊的配置需求，能夠解釋數據。由于這種映射，分析SoC體系結構和算法描述體現了系統設計人員是否具有這方面的設計技巧。這也是Mercury計算機公司成名的原因之一，該公司是高端嵌入式計算公司，在PowerPC早期就使用了multicore和many-core體系結構，并率先使用了圖像處理單元（GPU）進行信號處理。Mercury公司的技術總監Scott Thieret說：“這成為我們增值的主要來源，使我們能夠與客戶一起工作，將數據流映射到硬件中。”

　　通過固定映射，至少有信心在理論上對數據流和功耗建模。但這并不意味著很容易實現。Thieret說：“對這些系統建模和優化來自于經驗。您需要進行很多測試。有一些重要的指南，例如，讓數據盡可能靠近處理器，利用芯片最佳數據移動模型等。但這要依靠經驗。”

　　動態挑戰

　　一些規劃人員認為many-core系統的未來是在另一方向：不是將任務靜態映射至處理器，而是流動的、虛擬化系統，其中任何線程都可能隨時占用任何資源。在這一環境中，預測帶寬需求、處理負載甚至是功耗都會成為很復雜的任務。

　　一家經驗豐富的many-core系統開發公司內部人士評論說：“出于這一原因，發售的很多系統性能都不是太好。開發人員能夠對系統平均帶寬需求進行建模，但是，他們低估了峰值需求，遇到了無法預測的瓶頸問題。使其能夠正常工作的唯一方法是降低系統性能。”

　　他繼續解釋說：“很難預測這些系統中的總線競爭或者峰值帶寬。設計人員一般甚至都不會進行嘗試；他們只是盡量做好總線和外部存儲器配置。他們設計，測試，并不斷重復。”

　　這種不確定性意味著，在工程開始時，如果缺少工作參考設計，則無法知道某一many-coreSoC是否能夠滿足一些特殊的要求。解決的唯一方法是為系統提供過多的資源，使得資源競爭不會超出能夠使用的資源范圍。

　　這樣做必然的結果就是增大了功耗。如果不能提前預測哪些處理器會全速運行，哪些會降速工作，哪些會在某些時刻關斷，那么，很難估算SoC和DRAM的功耗或者溫度。Thieret認為：“很難預測功耗。總功耗等數據指標幾乎與系統中的實際功耗不相干。您最好的做法是借鑒以前工程的經驗，進行大量的測試。在FPGA行業以外，還沒有很好的工具來進行早期功耗估算。”

　　誰在控制？

　　如果理解了many-coreSoC的性能和功耗是很大的挑戰，那么，也就知道這些芯片的系統控制同樣是棘手的問題。與前兩個問題不同，對于異構、靜態映射的系統，系統控制并不那么簡單。也不能通過過度設計來解決這一問題。Thieret提醒說：“系統控制是一個基本問題，隨著處理器數量的增加，會越來越復雜。但是，您必須解決這一問題。”

　　最基本的難點在于將不同處理器中的任務與外部異步事件同步，例如，中斷、調試信號或者掉電等。即使是以清晰數據流模型為主的靜態系統，如果需要對某一處理器中的任務進行中斷，以響應某一事件，那么，也很難弄清楚應該啟動、暫停或者重新同步哪些任務。

　　在同構虛擬系統中，只有系統管理程序知道某一任務所在的位置，幾乎不可能在正確的地方及時執行中斷，在嵌入式操作系統中，會很難完成這一過程。系統設計人員可能要考慮中斷的替代方案，例如，讓一個處理器專門用于輪詢外部事件，或者使用中斷信號來啟動新服務線程，而不是中斷現有線程。這些方法都不能很好的解決SoC內部和外部之間復雜的仲裁問題。

　　初始化和關斷是同樣的難題。只是停止所有處理器上的所有線程，并不是一種好選擇，這可能會破壞數據結構，或者使得受控機處于危險狀態中。在出現電源完全失效等情況時，也會很難理解系統是怎樣工作的。一開始就會很難。一些設計團隊已經證實，能夠設計無法初始化的芯片。一些設計支持有序啟動，但是不在系統要求的時間范圍內。Thieret看到：“不同的應用有不同的需求。有時候，您有一個小時的重新啟動時間，而有時候，只有四秒的時間。” Many-core計算的前景很直觀：這是摩爾定律向前發展的唯一途徑。而采用many-core SoC來實際實現系統時，在系統理解、估算、配置和控制等方面會帶來很多新問題。SoC設計人員和系統設計人員一般通過參考設計來互相理解，這樣才能夠推動向前發展。