一種面向多核處理器的2 GHz片上網(wǎng)絡(luò)通信單元

摘要：提出了一種面向多核微處理器的2 GHz片上網(wǎng)絡(luò)通信單元設(shè)計(jì)方案，通信單元能夠在45 nm工藝下達(dá)到2 GHz的工作頻率，流水線級(jí)數(shù)為2，最多支持8個(gè)雙向通信接口，每個(gè)端口單向峰值帶寬32 GBps.構(gòu)建了一種16核處理器片上網(wǎng)絡(luò)測(cè)試環(huán)境，測(cè)試結(jié)果表明：使用提出的通信單元構(gòu)建的片上網(wǎng)絡(luò)能夠滿足16核處理器存儲(chǔ)系統(tǒng)對(duì)網(wǎng)絡(luò)帶寬的要求，在對(duì)訪存優(yōu)化的情況下，聚合帶寬能夠隨著處理器核心與線程的增加而線性增加.另外，通信單元還具有可重用的特性，能夠通過優(yōu)化與擴(kuò)展進(jìn)一步應(yīng)用于眾核處理器片上網(wǎng)絡(luò).研究成果已成功應(yīng)用于某國(guó)產(chǎn)16核高性能微處理器，片上網(wǎng)絡(luò)實(shí)測(cè)頻率達(dá)到2 GHz.

關(guān)鍵詞：多核處理器；片上網(wǎng)絡(luò)；通信單元

中圖分類號(hào)：TP332 文獻(xiàn)標(biāo)識(shí)碼：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個(gè)處理器核心，采用片上多處理器（Chip Multiprocessors，CMP）體系結(jié)構(gòu).多核處理器通常以總線、環(huán)和交叉開關(guān)作為片上互連網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，當(dāng)核數(shù)較少時(shí)，處理器內(nèi)部數(shù)據(jù)通信的要求基本能夠得到滿足.由于總線能夠連接的結(jié)點(diǎn)數(shù)與工作頻率和總線接口電路的速度、驅(qū)動(dòng)能力、總線長(zhǎng)度以及負(fù)載有關(guān)，所以一般適用于對(duì)通信能力要求不高且規(guī)模較小的片上網(wǎng)絡(luò)，斯坦福大學(xué)的Hydra[1]多核處理器就是采用總線進(jìn)行片上互連的典型實(shí)例.交叉開關(guān)具有選址方便、控制簡(jiǎn)單的優(yōu)點(diǎn)，但是所需的設(shè)備量大，通路的利用率較低，因此一般適用于對(duì)通信能力要求較高的片上網(wǎng)絡(luò).Sun UltraSPARC T2[2]， Fujitsu SPARC64 VIIIFx[3]和IBM Cyclops64[4]等處理器均采用交叉開關(guān)進(jìn)行片上互連.環(huán)網(wǎng)能夠支持相鄰結(jié)點(diǎn)間并行通信，具有比總線更高的網(wǎng)絡(luò)帶寬，比交叉開關(guān)更少的設(shè)備量，主要用于有一定的通信能力要求且規(guī)模中等的片上網(wǎng)絡(luò)，例如SONY CELL處理器[5]和ARM Cortex A15[6]處理器等采用環(huán)網(wǎng)進(jìn)行片上互連.二維mesh互連網(wǎng)絡(luò)具有結(jié)點(diǎn)度高、可靠性好和易大規(guī)模實(shí)現(xiàn)等特點(diǎn)，通常用于構(gòu)建規(guī)模較大的片上互連網(wǎng)絡(luò)，使用該互連網(wǎng)絡(luò)的多核或眾核處理器有RAW[7]和Tile64[8]等.隨著片上集成的處理器核數(shù)目越來越多，處理器核之間的通信距離不對(duì)稱、全局通信跳步數(shù)多、延遲大，二維mesh互連網(wǎng)絡(luò)也遇到了性能和功耗可擴(kuò)展性瓶頸，必須減少片上網(wǎng)絡(luò)的通信開銷.對(duì)于并行應(yīng)用，其通信必須盡量被限制在少量的臨近處理器核（結(jié)點(diǎn)簇）之間，具有簇內(nèi)通信密集、但簇間通信稀疏的特性.

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

本文將重點(diǎn)針對(duì)以上問題提出以下解決方法：1）設(shè)計(jì)可配置通信單元，提高片上網(wǎng)絡(luò)的可重用性；2）采用源數(shù)據(jù)隊(duì)列和源路由技術(shù)簡(jiǎn)化通信單元流水線結(jié)構(gòu)，減少通信單元的數(shù)據(jù)傳輸時(shí)間；3）提出面向通信協(xié)議的通信單元內(nèi)部互連時(shí)序優(yōu)化方法，優(yōu)化時(shí)序的同時(shí)減少通信單元的物理面積和功耗；4）提出面向物理布局的數(shù)據(jù)隊(duì)列優(yōu)化方法，進(jìn)一步優(yōu)化通信單元的時(shí)序和功耗.

1 通信單元體系結(jié)構(gòu)

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

圖1為通信單元中一個(gè)物理通道的數(shù)據(jù)通路流水線結(jié)構(gòu)示意圖.網(wǎng)絡(luò)通信單元包含輸入輸出接口、兩級(jí)流水線結(jié)構(gòu)和站間寄存器：輸入接口能夠接收來自最多8個(gè)源的報(bào)文微包（flip），采用基于信用的流控機(jī)制；輸出接口能夠發(fā)送微包到最多8個(gè)目的端口，也采用基于信用的流控機(jī)制；兩級(jí)流水線結(jié)構(gòu)包括仲裁站和數(shù)據(jù)選擇站，前者用于仲裁輸入請(qǐng)求及緩存輸入微包數(shù)據(jù)，后者用于將被仲裁許可的微包數(shù)據(jù)進(jìn)行選擇輸出.

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

在數(shù)據(jù)選擇站，輸出報(bào)文有效信號(hào)和微包選擇信號(hào)由仲裁站的仲裁結(jié)果產(chǎn)生.輸出報(bào)文有效信號(hào)在路由控制邏輯的控制下，產(chǎn)生到輸出接口各接收部件的報(bào)文有效信號(hào).微包選擇信號(hào)用于控制微包選擇器，從微包數(shù)據(jù)隊(duì)列輸出的多個(gè)微包數(shù)據(jù)中進(jìn)行選擇，選出的微包與報(bào)文有效信號(hào)一起經(jīng)過寄存后，發(fā)送給輸出接口中某個(gè)接收設(shè)備或者級(jí)連的通信單元.

圖2為采用通信單元構(gòu)建的多核處理器片上網(wǎng)絡(luò)的示意圖.圖2（a）是構(gòu)建環(huán)形網(wǎng)絡(luò)的示意圖，每個(gè)通信單元配置為8個(gè)雙向接口，使用4個(gè)物理通道（分別傳輸請(qǐng)求、響應(yīng)、監(jiān)聽和監(jiān)聽?wèi)?yīng)答報(bào)文）.通信單元使用接口6和接口7進(jìn)行級(jí)連.每個(gè)通信單元連接4個(gè)私有的L2Cache（L2C）、1個(gè)目錄控制部件（Directory Control Unit，DCU），通信單元1通過5號(hào)端口連接了1個(gè)IO控制器（IO Controller，IOC）.圖2（b）為使用通信單元構(gòu)建二維mesh網(wǎng)絡(luò)的示意圖，每個(gè)通信單元配置為連接三個(gè)處理器核，一個(gè)存儲(chǔ)單元，剩余端口用于互連，每個(gè)通信單元及其連接的處理器核構(gòu)成“結(jié)點(diǎn)簇”.

2 通信單元時(shí)序和功耗優(yōu)化

為了在45 nm工藝下實(shí)現(xiàn)2 GHz時(shí)鐘頻率，我們對(duì)通信單元進(jìn)行了專門的時(shí)序和功耗優(yōu)化，主要優(yōu)化內(nèi)容包括面向通信協(xié)議的內(nèi)部互連優(yōu)化和面向數(shù)據(jù)隊(duì)列的優(yōu)化.

2.1 面向通信協(xié)議的內(nèi)部互連優(yōu)化

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

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

2.2 面向數(shù)據(jù)隊(duì)列的優(yōu)化

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

3 實(shí)驗(yàn)及結(jié)果分析

3.1 測(cè)試環(huán)境

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

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

3.2 測(cè)試及數(shù)據(jù)統(tǒng)計(jì)方法

3.2.1 帶寬的測(cè)試與數(shù)據(jù)統(tǒng)計(jì)

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

Stream copy程序的實(shí)質(zhì)是大塊數(shù)據(jù)拷貝，能夠衡量處理器的片上網(wǎng)絡(luò)和存儲(chǔ)系統(tǒng)在壓力訪問下的性能和可擴(kuò)展性.在stream copy程序測(cè)試時(shí)，L2C按照先發(fā)送2個(gè)讀請(qǐng)求、再發(fā)送1個(gè)寫請(qǐng)求、1個(gè)替換請(qǐng)求這樣的發(fā)送序列發(fā)送報(bào)文.每個(gè)讀響應(yīng)數(shù)據(jù)為64 Byte，因此每一組發(fā)送序列可以獲得128 Byte的讀響應(yīng)數(shù)據(jù).假設(shè)在t的模擬時(shí)間內(nèi)發(fā)送了K組發(fā)送序列，stream copy程序的讀響應(yīng)帶寬（BWstream）可以按照式（3）計(jì)算.

3.2.2 延遲的測(cè)試與數(shù)據(jù)統(tǒng)計(jì)

延遲統(tǒng)計(jì)在L2C_model中完成.L2C_model每發(fā)出一個(gè)請(qǐng)求報(bào)文，則啟動(dòng)對(duì)應(yīng)該請(qǐng)求報(bào)文的時(shí)鐘周期計(jì)數(shù)器，當(dāng)該請(qǐng)求報(bào)文對(duì)應(yīng)的響應(yīng)報(bào)文返回到L2C_model時(shí)，停止計(jì)數(shù)器，計(jì)數(shù)器的值即為從發(fā)出請(qǐng)求報(bào)文到接收到響應(yīng)時(shí)整個(gè)過程的時(shí)鐘周期數(shù).通過將每個(gè)訪問延遲按照一定的延遲區(qū)間進(jìn)行統(tǒng)計(jì)，統(tǒng)計(jì)落在設(shè)定的延遲區(qū)間內(nèi)的訪問延遲的個(gè)數(shù)，可以得到訪問延遲的分布情況.為了測(cè)試不同規(guī)模配置下的帶寬和延遲情況，我們對(duì)單核單線程（1C1T）、8核64線程（8C64T）、12核96線程（12C96T）和16核128線程（16C128T）4種典型配置進(jìn)行測(cè)試，分析不同規(guī)模下片上網(wǎng)絡(luò)的帶寬和延遲情況.

3.3 測(cè)試結(jié)果及分析

3.3.1 最大壓力測(cè)試

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

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

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

3.3.2 單獨(dú)的IO DMA測(cè)試

我們?cè)O(shè)置L2C不執(zhí)行任何程序，進(jìn)行單獨(dú)的DMA讀和DMA寫測(cè)試.測(cè)試結(jié)果表明，DMA讀帶寬最大為6.40 GBps，DMA寫帶寬最大為6.65 GBps，已經(jīng)到達(dá)IOC部件的最大有效帶寬.根據(jù)前面最大壓力測(cè)試的結(jié)果，即使在最大壓力下，DMA寫帶寬也接近IOC部件所能達(dá)到的最大有效帶寬，因此DMA讀寫帶寬的瓶頸在于IOC部件本身，通信單元接口所能提供的有效帶寬大于IOC實(shí)際的帶寬.

3.3.3 單獨(dú)的stream copy程序測(cè)試

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

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

寬分別隨線程數(shù)增加而變化的趨勢(shì).圖7（a）為最壞情況下的試驗(yàn)結(jié)果，當(dāng)線程數(shù)從8（8-worst）增加到96（96-worst）時(shí)，聚合帶寬隨著線程數(shù)的增加而增加，當(dāng)線程數(shù)達(dá)到96時(shí)，聚合帶寬達(dá)到最高值29.88 GBps，為理想飽和帶寬的62.1%，當(dāng)超過96時(shí)，隨著線程數(shù)繼續(xù)增多，聚合帶寬反而略有下降.圖7（b）為最優(yōu)情況下的試驗(yàn)結(jié)果，Cache系統(tǒng)聚合

帶寬隨線程數(shù)的增多呈線性增長(zhǎng)，在不同線程數(shù)目時(shí)均接近理想飽和帶寬.測(cè)試表明不同地址流模式下stream copy程序的性能差異較大.對(duì)于1線程到96線程，片上Cache系統(tǒng)具有較好的可擴(kuò)展性，超過96線程，Cache帶寬可能達(dá)到飽和.綜上，通過優(yōu)化設(shè)計(jì)，片上網(wǎng)絡(luò)帶寬沒有成為片上存儲(chǔ)系統(tǒng)的瓶頸，其聚合帶寬能夠隨著處理器核與線程的增加而線性增加，訪存調(diào)度優(yōu)化是能夠發(fā)揮出片上網(wǎng)絡(luò)和存儲(chǔ)系統(tǒng)性能的關(guān)鍵.

4 結(jié) 論

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

參考文獻(xiàn)

[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.