一種面向多核處理器的2 GHz片上網絡通信單元

摘要：提出了一種面向多核微處理器的2 GHz片上網絡通信單元設計方案，通信單元能夠在45 nm工藝下達到2 GHz的工作頻率，流水線級數為2，最多支持8個雙向通信接口，每個端口單向峰值帶寬32 GBps.構建了一種16核處理器片上網絡測試環境，測試結果表明：使用提出的通信單元構建的片上網絡能夠滿足16核處理器存儲系統對網絡帶寬的要求，在對訪存優化的情況下，聚合帶寬能夠隨著處理器核心與線程的增加而線性增加.另外，通信單元還具有可重用的特性，能夠通過優化與擴展進一步應用于眾核處理器片上網絡.研究成果已成功應用于某國產16核高性能微處理器，片上網絡實測頻率達到2 GHz.

關鍵詞：多核處理器；片上網絡；通信單元

中圖分類號：TP332 文獻標識碼：A

A 2 GHz Network-on-chip Communication Unit

for Multi-core Microprocessors

ZHOU Hong-wei1， ZHANG Li-xia2， DOU Qiang1， LI Yong-jin1， YAN Xiao-bo1， ZHANG Ying1

（1.College of Computer， National Univ of Defense Technology， Changsha， Hunan 410073， China；

2. College of Information Science and Engineering， Central South Univ， Changsha， Hunan 410083， China）

Abstract： A 2 GHz network-on-chip communication unit for multi-core microprocessors was proposed. A 2 GHz frequency in 45nm process technology can be reached and the pipeline stage is 2. There are eight bi-direction communication ports totally and the peak bandwidth is 32 GBps in each port. A test environment for network-on-chip which supports 16 high-performance processor cores was built. The test results show that network-on-chip constructed by the proposed communication unit can meet the requirements of network bandwidth by 16-core processor storage system. In the case that memory access is optimized， the aggregate bandwidth can be increased linearly with the number of the processor and thread increase. In addition， the communication unit has reusable features and can continue to be used for network-on-chip in many-core processor when it will be optimized and expanded in future. The idea of this paper has been used successfully in one of self-designed 16-core high performance microprocessors. The frequency of network-on-chip logic has been reached to 2 GHz.

Key words： multi-core processor； network-on-chip； communication unit

目前主流的多核處理器一般集成4～16個處理器核心，采用片上多處理器（Chip Multiprocessors，CMP）體系結構.多核處理器通常以總線、環和交叉開關作為片上互連網絡拓撲結構，當核數較少時，處理器內部數據通信的要求基本能夠得到滿足.由于總線能夠連接的結點數與工作頻率和總線接口電路的速度、驅動能力、總線長度以及負載有關，所以一般適用于對通信能力要求不高且規模較小的片上網絡，斯坦福大學的Hydra[1]多核處理器就是采用總線進行片上互連的典型實例.交叉開關具有選址方便、控制簡單的優點，但是所需的設備量大，通路的利用率較低，因此一般適用于對通信能力要求較高的片上網絡.Sun UltraSPARC T2[2]， Fujitsu SPARC64 VIIIFx[3]和IBM Cyclops64[4]等處理器均采用交叉開關進行片上互連.環網能夠支持相鄰結點間并行通信，具有比總線更高的網絡帶寬，比交叉開關更少的設備量，主要用于有一定的通信能力要求且規模中等的片上網絡，例如SONY CELL處理器[5]和ARM Cortex A15[6]處理器等采用環網進行片上互連.二維mesh互連網絡具有結點度高、可靠性好和易大規模實現等特點，通常用于構建規模較大的片上互連網絡，使用該互連網絡的多核或眾核處理器有RAW[7]和Tile64[8]等.隨著片上集成的處理器核數目越來越多，處理器核之間的通信距離不對稱、全局通信跳步數多、延遲大，二維mesh互連網絡也遇到了性能和功耗可擴展性瓶頸，必須減少片上網絡的通信開銷.對于并行應用，其通信必須盡量被限制在少量的臨近處理器核（結點簇）之間，具有簇內通信密集、但簇間通信稀疏的特性.

近年來，針對數據局部化通信特性進行片上網絡拓撲結構優化成為多核處理器片上網絡研究的熱點.目前提出的優化的片上網絡拓撲結構有集中式mesh（Concentrated mesh，Cmesh）[9]，展平butterfly （flattened butterfly， fbfly）[10]和混合拓撲結構[11].Cmesh中對局部化通信支持好，局部通信具有低延遲高帶寬的特性，盡管其中單個通信單元（路由器）的功耗比二維mesh中通信單元的功耗大，但是由于通信單元數目更少，因此總體上仍能夠降低功耗.Fbfly通過權衡通道位寬和路由器維度，能夠實現較好的能量效率，但是對局部化通信的支持不如Cmesh.混合拓撲結構通過總線互連6～12個節點，構成一個簇，簇間通過二維mesh網絡互連，該結構重點對互連網絡進行功耗優化，能發揮出總線的低功耗特性，局部化通信功耗低，能夠滿足對局部化通信功耗敏感且帶寬要求不高的應用.以上幾種網絡拓撲結構目前仍處于學術研究階段，并未在主流的高性能多核微處理器中大規模應用，主要原因如下：第一，傳統的二維mesh或者環網由于其結構簡單的優勢容易實現較高的頻率，所以仍被大多數多核處理器作為首選；第二， Cmesh和fbfly的路由器端口多，對物理設計提出了很高的要求，采用傳統的設計方法很難滿足延遲和功耗的要求，而混合拓撲結構由于存在多種異構的互連網絡拓撲結構，因此無論從報文格式還是路由算法上都提高了設計難度.另外，傳統多核處理器片上網絡還存在以下問題：由于片上網絡的工作頻率直接影響多核處理器通信帶寬，因此目前對于片上網絡的設計主要采用定制設計的方法，導致模塊化不足、設計難度大、周期長以及可重用性不強.

本文將重點針對以上問題提出以下解決方法：1）設計可配置通信單元，提高片上網絡的可重用性；2）采用源數據隊列和源路由技術簡化通信單元流水線結構，減少通信單元的數據傳輸時間；3）提出面向通信協議的通信單元內部互連時序優化方法，優化時序的同時減少通信單元的物理面積和功耗；4）提出面向物理布局的數據隊列優化方法，進一步優化通信單元的時序和功耗.

1 通信單元體系結構

對于面向局部性優化的應用來說，不同的網絡拓撲對性能、功耗或者能量延遲積具有不同的優化效果，選用何種互連結構取決于設計者對這些設計參數的具體要求，設計師希望具有可重用的片上網絡設計組件，能夠通過簡單裝配實現不同拓撲結構.通信單元是構建片上通信網絡的核心，它直接與需要進行片上通信的處理器各部件互連.本文提出一種可配置的通信單元設計方案，每個通信單元包括4個物理通道，每個物理通道包含8個通信接口，每個通信接口可以與處理器中的一個部件相連，例如1個二級Cache、1個Cache一致性控制器、1個IO控制器等，也可以作為級連接口（Link Port，LP）和另一個通信單元互連，構建更加復雜的網絡拓撲結構.所有部件的接口使用統一的通信報文格式，簡化設計的同時增強可重用性.通信單元設計為IP核（Intellectual Property core）的形式，其通信端口數、物理通道數、端口數據位寬均可配置，通過可配置性設計，能夠控制通信單元的規模和設計需要相匹配，保證性能的同時降低功耗.

圖1為通信單元中一個物理通道的數據通路流水線結構示意圖.網絡通信單元包含輸入輸出接口、兩級流水線結構和站間寄存器：輸入接口能夠接收來自最多8個源的報文微包（flip），采用基于信用的流控機制；輸出接口能夠發送微包到最多8個目的端口，也采用基于信用的流控機制；兩級流水線結構包括仲裁站和數據選擇站，前者用于仲裁輸入請求及緩存輸入微包數據，后者用于將被仲裁許可的微包數據進行選擇輸出.

如圖1所示，來自各個請求源的請求有效信號構成“請求組”，仲裁站中的仲裁控制器按照公平輪轉的仲裁算法產生仲裁許可信號.當“請求組”內的有效信號超過1個時，由于每個時鐘周期只有一個請求能夠獲得仲裁許可，未被許可的請求需要在后續的時鐘周期繼續請求以獲得許可，因此一個“請求組”可能需要多次通過仲裁控制器才能完全獲得對組內各請求的仲裁許可.若“請求組”中某個請求被仲裁許可，則將產生一個到產生該請求的部件的信用釋放信號，經過寄存后返回給請求部件，用于釋放該請求部件的發送信用.當一個“請求組”需要多個時鐘周期才能通過通信單元時，來自輸入接口的新的“請求組”會由于仲裁控制器忙而無法被立即進行仲裁，這些新的“請求組”被記錄到“檢查板”邏輯中以避免丟失.由于只有當同一時刻產生的“請求組”中的所有請求全部被仲裁許可后，仲裁器才會處理下一個“請求組”，而且“檢查板”按照先入先出的順序依次保留待仲裁的“請求組”，因此仲裁器最終按照請求的到達時間進行仲裁，保證了服務質量（Quality of Service，QoS）.檢查板的深度能夠根據輸入接口的數目和每個請求部件發送微包的信用值進行配置.當檢查板為空時，新的“請求組”可以通過檢查板旁路直接被仲裁控制器仲裁.對于從輸入接口到仲裁站的來自各接口的輸入報文微包數據，仲裁站不做任何處理，直接送入微包數據隊列.

在數據選擇站，輸出報文有效信號和微包選擇信號由仲裁站的仲裁結果產生.輸出報文有效信號在路由控制邏輯的控制下，產生到輸出接口各接收部件的報文有效信號.微包選擇信號用于控制微包選擇器，從微包數據隊列輸出的多個微包數據中進行選擇，選出的微包與報文有效信號一起經過寄存后，發送給輸出接口中某個接收設備或者級連的通信單元.

圖2為采用通信單元構建的多核處理器片上網絡的示意圖.圖2（a）是構建環形網絡的示意圖，每個通信單元配置為8個雙向接口，使用4個物理通道（分別傳輸請求、響應、監聽和監聽應答報文）.通信單元使用接口6和接口7進行級連.每個通信單元連接4個私有的L2Cache（L2C）、1個目錄控制部件（Directory Control Unit，DCU），通信單元1通過5號端口連接了1個IO控制器（IO Controller，IOC）.圖2（b）為使用通信單元構建二維mesh網絡的示意圖，每個通信單元配置為連接三個處理器核，一個存儲單元，剩余端口用于互連，每個通信單元及其連接的處理器核構成“結點簇”.

2 通信單元時序和功耗優化

為了在45 nm工藝下實現2 GHz時鐘頻率，我們對通信單元進行了專門的時序和功耗優化，主要優化內容包括面向通信協議的內部互連優化和面向數據隊列的優化.

2.1 面向通信協議的內部互連優化

由于通信單元共支持8個雙向端口，因此單元內部的連線資源非常多，給物理設計帶來了很大的困難.考慮到多核處理器片上網絡主要用于傳輸Cache一致性報文，雖然使用4個物理通道分別用于傳輸請求、響應、監聽和監聽應答四類報文，但是根據協議的特點，并不是任何兩個部件間均需要進行報文傳輸.以圖2（a）的片上網絡為例，對于監聽通路，只有DCU會主動發出監聽請求，另外級連端口6和7（LP6和LP7）也會發送來自級連的其他通信單元的監聽請求.接收監聽請求的部件為4個L2Cache，以及級連端口LP6和LP7.級連端口5（LP5）既不發送也不接收監聽報文，因此不需要監聽數據通路.

根據以上特點，可以僅在具有通信需求的部件間設計通路，節省內部互連線資源，例如對監聽通路內部互連通路的簡化如圖3所示.簡化后共使用6個仲裁器（ARB0～ARB5），每個仲裁器最多僅需要3個輸入報文緩沖隊列，互連通路共16條.若使用標準的8端口全交叉方式設計，則需要8個仲裁器，每個仲裁器7個輸入報文緩沖隊列，互連通路56條.基于同樣的思想，可以對其他物理通道進行優化設計，總體上降低整個通信單元的邏輯和連線資源.

2.2 面向數據隊列的優化

數據隊列緩存來自各個請求源的待仲裁的報文.每個源到每個目的都有對應的數據隊列.數據隊列的深度取決于能夠緩存的報文的個數及報文類型.為了減少數據隊列的面積開銷，同時盡量避免帶數據報文由于信用耗盡被迫發送中斷，數據隊列被設計為能夠緩存3個報文，其中2個是不帶數據的報文，1個是帶數據的報文（1個命令微包+4個數據微包）.為了滿足時序要求，數據隊列為一個先進先出的FIFO結構，使用寄存器搭建，以7深度的數據隊列為例，其結構示意圖如圖4所示.為了使FIFO的輸出盡量靠近輸出接口，減少數據選擇站中報文數據的長距離傳輸延遲，Q0寄存器固定為FIFO的輸出.每個寄存器的D端具有以下3個來源：1）來自新的報文的輸入（pkg_in）；2）來自后一個寄存器的輸出；3）自己的輸出.FIFO讀寫過程如下：當某一個寄存器作為FIFO尾之后的第一個無效寄存器時，新的數據寫入該寄存器；當Q0被讀出后，其后所有保存有效數據的寄存器的值將同時移動到各自的前一個寄存器中；當Q0未被讀出時，FIFO中所有的寄存器均保持當前值.多路選擇器的控制信號包括：選擇（sel），移位（shift）和保持（hold），分別控制從新輸入報文、后繼寄存器的輸出和自己的輸出中選擇一個.數據隊列也可以設計為固定Q6為輸入，輸出從Q0～Q6中選擇的方式.具體選擇哪一種方式取決于FIFO的時序關鍵路徑是報文從輸入接口寄存器輸入到FIFO的路徑還是從FIFO輸出到輸出接口寄存器的路徑.

3 實驗及結果分析

3.1 測試環境

考慮到處理器核心在芯片上按照上下對稱的方式排列，芯片中間的面積用于片上網絡通道時更容易布局，我們構建了如圖5所示的16核處理器片上網絡測試結構.處理器具有16個處理器核心，每個核心擁有私有的L2Cache，8個處理器核及對應的L2Cache位于芯片上部，另外8個位于芯片下部.片上網絡位于芯片中部，4個通信單元通過端口5和端口6級連，由于通信單元0～3在拓撲結構上一字排開，因此位于兩側的通信單元相互通信需要經過中間的兩個通信單元，造成跳步數多、延遲增加、帶寬受限.為了解決該問題，我們使用配置為僅具有兩個端口的通信單元（通信單元4和5）分別連接通信單元1和通信單元2，通信單元0和通信單元3，以提高非相鄰通信單元之間的通信效率.為了對構建的多核處理器片上網絡進行測試，我們設計了L2Cache模型L2C_model、目錄控制單元的模型DCU_model和IO單元的模型IOC_model.

L2C_model的基本功能如下：1）每個L2C最多可以緩存8個未收到響應的請求報文，否則不能發送新的請求報文；2）由于流拷貝（stream copy）程序具有較高的訪存壓力，因此L2C模型支持stream程序的發送序列模式：為了獲得接近真實情況下L2C已經充滿時的情況，L2C平均每發送兩個讀請求會發送一個寫回或者替換請求，且寫回和替換請求發送概率相同；3）每個L2C可以緩存發出請求的特征信息，如標識（tag），等待響應回來后通過匹配特征信息確認是哪一個請求的響應，從而獲得從請求發出到接收到響應之間的訪問延遲.DCU_model的基本功能如下：1）根據實際的邏輯設計數據，DCU的訪存延遲平均為25個時鐘周期；2）根據DCU的體系結構，設置DCU的緩沖和流水線中最多可以容納50個請求.IOC_model可以在有信用的前提下連續發送DMA讀或寫請求，4個DCU體采用低位交叉方式編址，因此DMA請求依次輪轉訪問各DCU模型.

3.2 測試及數據統計方法

3.2.1 帶寬的測試與數據統計

對于L2C和IOC部件，統計發送請求的平均帶寬，對于DCU部件，統計發送響應的平均帶寬.假設模擬系統的時鐘周期為T（ns），總模擬時間為t（ns），通信單元的目標工作頻率為f（GHz），期間發送的微包數目為N，微包有效位寬為128位（16 Byte），則發送時的峰值帶寬（BWpeak）和實際帶寬（BWreal）可以分別按照式（1）和式（2）計算，單位為GBps.

Stream copy程序的實質是大塊數據拷貝，能夠衡量處理器的片上網絡和存儲系統在壓力訪問下的性能和可擴展性.在stream copy程序測試時，L2C按照先發送2個讀請求、再發送1個寫請求、1個替換請求這樣的發送序列發送報文.每個讀響應數據為64 Byte，因此每一組發送序列可以獲得128 Byte的讀響應數據.假設在t的模擬時間內發送了K組發送序列，stream copy程序的讀響應帶寬（BWstream）可以按照式（3）計算.

3.2.2 延遲的測試與數據統計

延遲統計在L2C_model中完成.L2C_model每發出一個請求報文，則啟動對應該請求報文的時鐘周期計數器，當該請求報文對應的響應報文返回到L2C_model時，停止計數器，計數器的值即為從發出請求報文到接收到響應時整個過程的時鐘周期數.通過將每個訪問延遲按照一定的延遲區間進行統計，統計落在設定的延遲區間內的訪問延遲的個數，可以得到訪問延遲的分布情況.為了測試不同規模配置下的帶寬和延遲情況，我們對單核單線程（1C1T）、8核64線程（8C64T）、12核96線程（12C96T）和16核128線程（16C128T）4種典型配置進行測試，分析不同規模下片上網絡的帶寬和延遲情況.

3.3 測試結果及分析

3.3.1 最大壓力測試

壓力測試是指使片上網絡和片上存儲系統的帶寬達到飽和的測試，使用的測試激勵為每個核的每個硬件線程執行一個獨立的stream copy線程，同時IOC在不受IO部件帶寬限制的前提下，以通信單元端口的峰值帶寬連續發送DMA寫請求.表1是不同規模配置下執行壓力測試時的帶寬測試結果.64線程時，請求聚合帶寬（L2C請求總帶寬和IO DMA寫請求帶寬之和）為104.43 GBps，每個DCU平均響應帶寬為24.50 GBps，繼續增加線程數，請求聚合帶寬和DCU平均響應帶寬基本保持不變，達到飽和.隨著線程數增多，DMA寫帶寬逐步減小，線程數達到最大規模時，IO寫帶寬達到下限6.26 GBps.我們另外測試了16C128T配置下stream copy程序和IO DMA讀同時執行時的帶寬.測試結果為：每個L2C的平均請求帶寬為2.68 GBps，IO DMA讀請求帶寬為16.63 GBps，請求聚合帶寬為59.51 GBps，DCU的平均響應帶寬為27.73 GBps.由于DCU帶寬已經飽和，IO DMA讀訪問影響了stream copy的帶寬.

L2C14進行延遲統計，充分考慮到位于兩邊的通信單元上的L2C的訪問延遲比位于中間通信單元上的L2C的訪問延遲更大的特點，統計最壞情況下的延遲分布情況.

分析帶寬和延遲測試結果可以看出：1）在沒有競爭的情況下，互連網絡的訪問延遲低，例如在單核單線測試時，L2C報文延遲在64周期以下，且有50%以上小于64周期；2）L2C報文延遲主要由L2C請求在DCU中的等待時間構成，DCU的響應帶寬達到飽和是導致L2C請求在DCU中排隊時間長的主要原因，當線程數超過64時，隨著線程數的增加，落在較大訪問延遲區間內的訪問個數所占的比例逐漸增加；3）對于12C96T配置，DMA寫請求能夠獲得的帶寬下限為22.13 GBps，對于16C128T配置，DMA寫請求能夠獲得的帶寬下限為6.26 GBps，超過96線程后，L2Cache的訪問對DMA寫帶寬影響顯著增加；4）對于16C128T配置，DMA讀請求能夠獲得的帶寬最低為16.63 GBps，相對于DMA寫時的6.26 GBps，DMA讀請求受L2Cache訪問的影響較小，主要原因是4個DCU體采用低位交叉方式編址，DMA寫依次串行向4個DCU發送寫請求報文，與16個L2Cache同時競爭請求通道，在公平優先級的情況下DMA寫請求和L2Cache請求的帶寬比約為1∶16，而DMA讀的數據通過響應通道從4個DCU獲得，在公平優先級的情況下DMA讀響應和L2Cache響應的帶寬比約為4∶16，因此能夠獲得較大的帶寬.

3.3.2 單獨的IO DMA測試

我們設置L2C不執行任何程序，進行單獨的DMA讀和DMA寫測試.測試結果表明，DMA讀帶寬最大為6.40 GBps，DMA寫帶寬最大為6.65 GBps，已經到達IOC部件的最大有效帶寬.根據前面最大壓力測試的結果，即使在最大壓力下，DMA寫帶寬也接近IOC部件所能達到的最大有效帶寬，因此DMA讀寫帶寬的瓶頸在于IOC部件本身，通信單元接口所能提供的有效帶寬大于IOC實際的帶寬.

3.3.3 單獨的stream copy程序測試

當多個線程各自以未優化的方式執行stream copy程序時，雖然每個線程內源地址和目的地址互不交疊，但是起始地址訪問均落在同一個DCU中，且按跨步為1的方式依次訪問各DCU.各線程同時啟動，每個線程訪問DCU的行為相同，所有線程的第一個讀請求同時到達通信單元，某個DCU將接收到各線程的第一個讀請求.由于不同L2C訪問同一個DCU時通過片上網絡的路徑不同，訪問延遲具有差異，因此各線程開始基本保持同步，之后延遲差異對各線程執行速度的影響逐漸顯露，各線程執行速度的差異越來越大.

DCU流水線處理地址相關時，由于資源沖突，需要阻塞相關的地址.DCU流水線地址相關性處理方式是影響性能的一個重要因素.Stream copy程序訪存可能出現兩種極端情況：a）最壞情況（worst）：各線程訪問DCU中同一個目錄組，造成大量DCU流水線處理相關，只能串行訪問；b）最優情況（opt）：調整線程訪問地址，使不同線程訪問DCU的不同目錄組，能夠減少DCU沖突.我們對這兩種情況分別進行了試驗，測試結果如圖7所示，圖中折線反映了單核帶寬、Cache系統的聚合帶寬和理想飽和帶

寬分別隨線程數增加而變化的趨勢.圖7（a）為最壞情況下的試驗結果，當線程數從8（8-worst）增加到96（96-worst）時，聚合帶寬隨著線程數的增加而增加，當線程數達到96時，聚合帶寬達到最高值29.88 GBps，為理想飽和帶寬的62.1%，當超過96時，隨著線程數繼續增多，聚合帶寬反而略有下降.圖7（b）為最優情況下的試驗結果，Cache系統聚合

帶寬隨線程數的增多呈線性增長，在不同線程數目時均接近理想飽和帶寬.測試表明不同地址流模式下stream copy程序的性能差異較大.對于1線程到96線程，片上Cache系統具有較好的可擴展性，超過96線程，Cache帶寬可能達到飽和.綜上，通過優化設計，片上網絡帶寬沒有成為片上存儲系統的瓶頸，其聚合帶寬能夠隨著處理器核與線程的增加而線性增加，訪存調度優化是能夠發揮出片上網絡和存儲系統性能的關鍵.

4 結 論

本文提出了一種用于多核微處理器的2 GHz片上網絡通信單元設計方案，通信單元能夠在45 nm工藝下達到2 GHz的工作頻率，流水線級數為2，最多支持8個雙向通信接口，每個端口單向峰值帶寬32 GBps.測試結果表明：構建的片上網絡能夠滿足16核處理器存儲系統對網絡帶寬的要求，在對訪存優化的情況下，聚合帶寬能夠隨著處理器核與線程數的增加而線性增加.通信單元還具有可重用的特性，能夠通過優化與擴展進一步在眾核處理器中使用.本文的研究成果已經成功應用于某國產16核高性能微處理器，片上網絡的實測頻率達到2 GHz.在今后的工作中，我們將進一步考慮支持不同優先級的仲裁策略，緩解多個通信單元級連時位于不同通信單元上的設備所獲得的通信帶寬和延遲不均衡的問題.

參考文獻

[1] HAMMOND L， HUBBERT B A， SIU M， et al. The stanford hydra CMP[J]. IEEE Micro， 2010， 20（2）：71-84.

[2] SHAH M， BARREH J， BROOKS J， et al. UltraSPARC T2： a highly-threaded， power-efficient，SPARC SOC[C]//Proceedings of the IEEE Asian Solid-State Circuit Conference. Jeju， Korea： IEEE Asian Publications，2007：22-25.

[3] MARUYAMA T. SPARC64 VIIIfx： Fujitsu's new generation octo-core processor for petascale computing[J]. IEEE Micro， 2010， 30（2）： 30-40.

[4] DEL CUVILLO J， ZHU W， HU Z， et al. FAST： a functionally accurate simulation tool set for the Cyclops64 cellular architecture[C] //The First Annual Workshop on Modeling， Benchmarking， and Simulation （MoBS-1）. Wisconsin， USA： ISCA Conference Publications， 2005：14-24.

[5] AINSWORTH T W， PINKSTON T. Characterizing the cell EIB on-chip network[J]. IEEE Micro， 2007，27（5）：6-14.

[6] ARM Limited company. Cortex-A15 Processor[EB/OL] http：//www.arm.com/products/processors/cortex-a/cortex-a15.php，2012-04-18/2013-02-12.

[7] TAYLOR M B， KIM J， MILLER J， et al. The raw microprocessor： a computational fabric for software circuits and general-purpose programs[J]. IEEE Micro， 2002， 22（2）：25-35.

[8] TILERA Company. TILERA： Tile64 processor[EB/OL]. [2010-06-12] http：//www.tilera.com/products/processors/TILE64，2010-06-12/2012-11-15.

[9] BALFOUR J， DALLY W J. Design tradeoffs for tiles cmp on-chip networks[C]// Proceedings of the 20th Annual International Conference Supercomputing. New York： ACM， 2006： 187-198.

[10]KIM J， BALFOUR J， DALLY W. Flattened butterfly topology for on-chip networks[C]// Proceedings of the 40th Annual IEEE/ACM International Symposium on Microarchitecture. New York： ACM， 2007： 172-182.

[11]DAS R， EACHEMPATI S， MISHRA A K， et al. Design and evaluation of a hierarchical on-chip interconnect for next-generation CMPs[C]//Proceedings of IEEE 15th International Symposium on High Performance Computer Architecture. Washington， DC： IEEE Computer Society， 2009：175-186.