高校和私企正在應(yīng)用分布式平臺(tái)，而不是安裝速度更快、耗電更大的超級(jí)計(jì)算機(jī)來(lái)解決日益復(fù)雜的科學(xué)算法，針對(duì)SETI@home 這樣的項(xiàng)目，他們則使用數(shù)以千計(jì)的個(gè)人計(jì)算機(jī)來(lái)計(jì)算它們的數(shù)據(jù)。[1，2] 當(dāng)前的分布式計(jì)算網(wǎng)絡(luò)一般用CPU 或 GPU 來(lái)計(jì)算項(xiàng)目數(shù)據(jù)。

FPGA 也正被像 COPACOBANA這樣的項(xiàng)目所采用，該項(xiàng)目使用 120個(gè)賽靈思 FPGA 通過(guò)暴力處理來(lái)破解DES 加密文件。[3] 不過(guò)在這個(gè)案例中，F(xiàn)PGA 都被集中布置在一個(gè)地方，這種方案不太適合那些預(yù)算緊張的大學(xué)或企業(yè)。目前并未將 FPGA 當(dāng)作分布式計(jì)算工具，這是因?yàn)樗鼈兊氖褂眯枰柚?PC，才能用新的比特流不斷地重新配置整個(gè) FPGA。但是現(xiàn)在有了賽靈思部分重配置技術(shù)，為分布式計(jì)算網(wǎng)絡(luò)設(shè)計(jì)基于 FPGA 的客戶端完全可行。

我們漢堡應(yīng)用技術(shù)大學(xué)的研究小組為這樣的客戶端創(chuàng)建了一個(gè)原型，并將其實(shí)現(xiàn)在單個(gè) FPGA 上。我們的設(shè)計(jì)由靜態(tài)和動(dòng)態(tài)兩大部分組成。其中靜態(tài)部分在 FPGA 啟動(dòng)時(shí)加載，與此同時(shí)用靜態(tài)部分實(shí)現(xiàn)的處理器從網(wǎng)絡(luò)服務(wù)器下載動(dòng)態(tài)部分。動(dòng)態(tài)部分屬部分重配置區(qū)域，提供共享的 FPGA資源。[4] 采用這種配置，F(xiàn)PGA 可以位于世界上的任何地方，用較低的預(yù)算就能夠?yàn)橛?jì)算項(xiàng)目提供強(qiáng)大的計(jì)算能力。

分布式 SOC 網(wǎng)絡(luò)
由于具有信號(hào)并行處理能力，F(xiàn)PGA能夠使用比微處理器慢 8 倍的時(shí)鐘，低 8 倍的功耗實(shí)現(xiàn)比其快三倍的數(shù)據(jù)吞吐量。[5] 為利用該強(qiáng)大的計(jì)算能力實(shí)現(xiàn)高數(shù)據(jù)輸入速率，設(shè)計(jì)人員一般將算法實(shí)現(xiàn)為流水線，比如 DES 加密。[3] 我們開(kāi)發(fā)分布式 SoC 網(wǎng)絡(luò) (DSN)原型的目的是加快算法的速度和使用分布式 FPGA 資源處理大型數(shù)據(jù)集。我們的網(wǎng)絡(luò)設(shè)計(jì)采用“客戶端- 代理-服務(wù)器”架構(gòu)，故我們可以將所有注冊(cè)的片上系統(tǒng) (SoC) 客戶端分配給每一個(gè)網(wǎng)絡(luò)參與方的計(jì)算項(xiàng)目（如圖 1所示）。這在將每一個(gè) SoC 客戶端連接到唯一的項(xiàng)目的“客戶端- 服務(wù)器”架構(gòu)中是無(wú)法實(shí)現(xiàn)的。

另外，我們選擇“代理- 服務(wù)器”架構(gòu)可以將每個(gè) FPGA 的 TCP/IP 連接數(shù)量減少到一個(gè)。DSN FPGA 負(fù)責(zé)運(yùn)算使用專用數(shù)據(jù)集的算法，而“代理-服務(wù)器”則負(fù)責(zé)管理 SoC 客戶端和項(xiàng)目客戶端。代理調(diào)度連接的 SoC 客戶端，讓每個(gè)項(xiàng)目在相同的時(shí)間幾乎擁有相同的計(jì)算能力，或者在 SoC 的數(shù)量少于計(jì)算請(qǐng)求的項(xiàng)目時(shí)分時(shí)復(fù)用soc客戶端。

項(xiàng)目客戶端提供部分重配置模塊(PRM) 和激勵(lì)輸入數(shù)據(jù)集。在連接到“代理- 服務(wù)器”之后，項(xiàng)目客戶端將PRM 比特文件發(fā)送給服務(wù)器，然后由服務(wù)器將它們分配給帶有空閑的部分可重配置區(qū)域 (PRR) 的 SoC 客戶端。SoC 客戶端的靜態(tài)部分是一個(gè)基于MicroBlazeTM 的微控制器，用接收到的 PRM 動(dòng)態(tài)重新配置 PRR。接下來(lái)，項(xiàng)目客戶端開(kāi)始通過(guò)“代理- 服務(wù)器”發(fā)送數(shù)據(jù)集并從 SoC 客戶端接收計(jì)算的結(jié)果。根據(jù)項(xiàng)目客戶端的需要，舉例來(lái)說(shuō)，它可以比較不同的計(jì)算結(jié)果，或根據(jù)計(jì)算目的評(píng)估計(jì)算結(jié)果。

MicroBlaze 處理器負(fù)責(zé)運(yùn)行客戶端軟件，客戶端軟件管理部分重配置以及比特流和數(shù)據(jù)交換。

SOC 客戶端
我們?yōu)殡S ML605 評(píng)估板配套提供的賽靈思 Virtex®-6 FPGA（XC6VLX240T）開(kāi)發(fā)了 SoC 客戶端。MicroBlazeTM 處理器負(fù)責(zé)運(yùn)行客戶端軟件，客戶端軟件負(fù)責(zé)管理部分可重配置以及比特流和數(shù)據(jù)交換（如圖 2 所示）。用戶邏輯封裝PRR 的處理器本地總線 (PLB) 外設(shè)用以連接靜態(tài)部分和動(dòng)態(tài)部分。在動(dòng)態(tài)部分駐留的是接收到的 PRM 提供的加速器 IP 核使用的 FPGA 共享資源。為存儲(chǔ)接收到的數(shù)據(jù)和計(jì)算完成的數(shù)據(jù)，我們選擇了 DDR3 存儲(chǔ)器而非CompactFlash，因?yàn)?DDR 存儲(chǔ)器有更高的數(shù)據(jù)吞吐量和無(wú)限制的寫入訪問(wèn)次數(shù)。PRM 存儲(chǔ)在專用數(shù)據(jù)段內(nèi)，以控制其大小，避免與其它數(shù)據(jù)集發(fā)生沖突。該數(shù)據(jù)段大小為 10 MB，足以存儲(chǔ)完整的 FPGA 配置。因此每一個(gè)PRM 都應(yīng)該與這個(gè)數(shù)據(jù)段的大小匹配。

我們還為接收及結(jié)果數(shù)據(jù)集創(chuàng)建了不同的數(shù)據(jù)段。這些數(shù)據(jù)段的大小有 50 MB，能夠?yàn)楸热鐖D像或加密文本文件等提供足夠的尋址空間。管理這些數(shù)據(jù)段主要依靠 10 個(gè)管理結(jié)構(gòu)。該管理結(jié)構(gòu)包括每個(gè)數(shù)據(jù)集對(duì)的起始/ 終點(diǎn)地址，以及指示結(jié)果數(shù)據(jù)集的標(biāo)志。

為將靜態(tài)部分連接到 PRR，我們對(duì)賽靈思EDK 提供的 IP 連接進(jìn)行評(píng)估，比如快速單向鏈路 (FSL)、PLB 從和PLB 主等。我們選擇將PLB 主/ 從結(jié)合使用，以取得便于配置的 IP，可以在無(wú)需 MicroBlaze 提供支持的情況下發(fā)送和接收數(shù)據(jù)請(qǐng)求，從而大幅降低每個(gè)字傳輸占用的時(shí)鐘周期。

對(duì)客戶端- 服務(wù)器通信，F(xiàn)PGA 的內(nèi)部以太網(wǎng) IP 硬核是處理器系統(tǒng)靜態(tài)部分不可或缺的外設(shè)。借助本地鏈路TEMAC 對(duì)存儲(chǔ)器控制器的軟件直接存儲(chǔ)器訪問(wèn) (SDMA) 功能，可減輕數(shù)據(jù)和比特文件傳輸帶來(lái)的 PLB 載荷。在接收 1,518 個(gè)字節(jié)的幀后，SDMA生成中斷請(qǐng)求，調(diào)用 lwip_read() 函數(shù)來(lái)處理這段數(shù)據(jù)。Lwip_write() 函數(shù)告知 SDMA 通過(guò)到 TEMAC 的發(fā)送通道執(zhí)行 DMA 傳輸功能。

我們把 Xikernel（一種用于賽靈思嵌入式處理器的內(nèi)核），當(dāng)作 SoC客戶端軟件的底層實(shí)時(shí)操作系統(tǒng)加以實(shí)現(xiàn)，以便使用用于 TCP/IP 服務(wù)器連接的套接字模式發(fā)揮輕量級(jí) TCP/IP 棧(LwIP) 庫(kù)的作用。圖 3 概述了客戶端線程的初始化、建立、發(fā)送和處理順序。SoC 客戶端線程初始化到服務(wù)器的連接，并接收存儲(chǔ)在 DDR3 存儲(chǔ)器中的PRM 比特流（“pr”）， 從而應(yīng)用XILMFS 文件系統(tǒng)。隨后Xps_hwicap（硬件內(nèi)部配置接入點(diǎn)）用 PRM 重新配置 PRR。最后，由總線主外設(shè)設(shè)置一個(gè)狀態(tài)位，命令 SoC 客戶端向服務(wù)器發(fā)送請(qǐng)求。服務(wù)器用數(shù)據(jù)集（“dr”）做出響應(yīng)， SoC 客戶端把該數(shù)據(jù)集存儲(chǔ)在板載存儲(chǔ)器上。這些數(shù)據(jù)文件包含有內(nèi)容順序， 比如“output_length+“ol”+data_to_compute”。output_length 是字節(jié)長(zhǎng)度，用來(lái)保留結(jié)果數(shù)據(jù)的存儲(chǔ)范圍，后接字符對(duì)“ol”。對(duì)首個(gè)接收到的“dr”消息，會(huì)生成一個(gè)計(jì)算線程和一個(gè)發(fā)送線程。

計(jì)算線程將輸入- 結(jié)果數(shù)據(jù)集的地址發(fā)送到 PRR 外設(shè)的從接口，并啟動(dòng)PRM 的自動(dòng)數(shù)據(jù)集處理功能。管理結(jié)構(gòu)為每個(gè)數(shù)據(jù)集提供這些地址，并在確保結(jié)果數(shù)據(jù)完全可用后設(shè)置“完成”標(biāo)志。在目前的客戶端軟件概念版本中，計(jì)算線程和發(fā)送線程通過(guò)該結(jié)構(gòu)通信，由發(fā)送線程反復(fù)檢查完成位， 并將lwip_write() 調(diào)用存儲(chǔ)在存儲(chǔ)器中的結(jié)果。

在測(cè)試 SoC 客戶端時(shí)，我們發(fā)現(xiàn)如果在 PRR 重配置過(guò)程中啟用全部中斷，Xilkernel 的定時(shí)器會(huì)產(chǎn)生調(diào)度函數(shù)訪問(wèn) MicroBlaze，使重配置過(guò)程隨機(jī)發(fā)生卡住的狀況。如果禁用全部中斷，或在沒(méi)有 Xilkernel 的支持下，對(duì)SoC 客戶端的 MicroBlaze 處理器使用獨(dú)立的軟件模塊，就不會(huì)發(fā)生這種情況。

配備例化PRM 的總線主控外設(shè)
為在 PRM 和外部存儲(chǔ)器之間實(shí)現(xiàn)自控激勵(lì)數(shù)據(jù)和結(jié)果的交換，我們將總線主外設(shè)構(gòu)建為一個(gè)帶數(shù)據(jù)路徑和控制路徑的處理器元件（如圖 4 所示）。在數(shù)據(jù)路徑中，我們?cè)趦蓚€(gè)深度均為16 個(gè)字的 FIFO 模塊之間嵌入 PRM接口，以補(bǔ)償通信和數(shù)據(jù)傳輸延遲。數(shù)據(jù)路徑的兩個(gè) FIFO 均直接連接到PLB 的總線主接口。這樣，我們通過(guò)有限狀態(tài)機(jī) (FSM) 的直接數(shù)據(jù)傳輸，大幅降低時(shí)間。由于不采用軟件，所以 MicroBlaze 的寄存器文件中不發(fā)生中間數(shù)據(jù)存儲(chǔ)。本 RISC 處理器的“加載- 存儲(chǔ)”架構(gòu)一直需要占用兩個(gè)總線傳輸周期，用于從某個(gè)地址加載 CPU 寄存器，然后將寄存器的內(nèi)容存儲(chǔ)到另一個(gè) PLB 連接的設(shè)備。由于從 MicroBlaze 到存儲(chǔ)器控制器的DXCL 數(shù)據(jù)高速緩存鏈路構(gòu)成 PLB 的旁路，因此這些“加載- 存儲(chǔ)”周期在時(shí)序上不能得到改善。這是因?yàn)榻邮盏降臄?shù)據(jù)和發(fā)送的計(jì)算結(jié)果都是逐字一次性處理，沒(méi)有發(fā)揮高速緩存的作用。由此 PRR 外設(shè)的活動(dòng)與 MicroBlaze 主軟件的處理脫鉤，因而 PRR 數(shù)據(jù)傳輸不會(huì)導(dǎo)致更多的 Xilkernel 環(huán)境切換。但仍然不可避免地出現(xiàn)兩個(gè)主設(shè)備競(jìng)爭(zhēng)總線訪問(wèn)的情況。

外設(shè)的從接口含有四個(gè)基于軟件驅(qū)動(dòng)的寄存器，可為控制路徑提供輸入和輸出數(shù)據(jù)集的起始地址和終點(diǎn)地址。另一個(gè)軟件寄存器為 FSM 設(shè)定“起始”位，用于初始化主數(shù)據(jù)傳輸周期。完整的數(shù)據(jù)處理周期的狀態(tài)經(jīng)第五個(gè)軟件寄存器的地址提供給客戶端軟件。

根據(jù)控制路徑的 FSM 的狀態(tài)圖可以看出，應(yīng)該采取讓到 PLB 的寫入周期優(yōu)先的策略（圖5）。從 OUT_FIFO 提取數(shù)據(jù)優(yōu)先于向 IN_FIFO 寫入數(shù)據(jù)，防止 OUT_FIFO 為滿時(shí)，阻止 PRM 處理算法。讀取或?qū)懭胪獠看鎯?chǔ)器可交替進(jìn)行，因?yàn)槊看沃荒苁褂靡环N總線訪問(wèn)方式。當(dāng)來(lái)自客戶端的計(jì)算線程的軟件復(fù)位啟動(dòng) FSM（圖 3）時(shí)，第一件事就是從外部存儲(chǔ)器讀?。顟B(tài) READ_REQ）。自此，總線主設(shè)備就受狀態(tài) STARTED 提供的轉(zhuǎn)換條件所提供的決策邏輯的控制（表 1）。

Mealy FSM 輸出（標(biāo)記Exit/）讓地址計(jì)數(shù)器在總線傳輸完成時(shí)遞增。這里兩個(gè)計(jì)數(shù)器都直接導(dǎo)入到 FSM代碼中。一般情況下我們傾向于將定時(shí)器和地址計(jì)數(shù)器分開(kāi)實(shí)現(xiàn)為僅用FSM 輸出使能的單獨(dú)時(shí)鐘進(jìn)程，以便讓計(jì)數(shù)器的保持小規(guī)模的轉(zhuǎn)換邏輯以及盡量避免將多路復(fù)用器輸入用于計(jì)數(shù)器狀態(tài)反饋。對(duì)于此點(diǎn)，XST 綜合編譯器的結(jié)果將 RTL 原理圖清楚地體現(xiàn)為并行于可加載計(jì)數(shù)器的 FSM 抽象，其中的時(shí)鐘使能輸入由預(yù)期狀態(tài)解碼邏輯驅(qū)動(dòng)。盡管行為級(jí)的 VHDL編碼方式更容易讓人理解，使用 FPGA資源和簡(jiǎn)單原語(yǔ)也不會(huì)影響功能。

用 PLANAHEAD 設(shè)置動(dòng)態(tài)部分
FPGA 中靜態(tài)和動(dòng)態(tài)部分的配置這一設(shè)計(jì)流程是一個(gè)復(fù)雜的開(kāi)發(fā)過(guò)程，需要用 PlanAheadTM 物理設(shè)計(jì)約束工具進(jìn)行多步操作。第一步就是給在ML505 開(kāi)發(fā)板上實(shí)現(xiàn)的由 PetaLinux驅(qū)動(dòng)的動(dòng)態(tài)重配置平臺(tái)編寫設(shè)計(jì)流程腳本。[6] 就當(dāng)前迭代而言，將 PRR直接集成到外設(shè)的用戶邏輯中的設(shè)計(jì)步驟與過(guò)去通過(guò)添加總線宏和器件控制寄存器(DCR) 用作 PRM 的 PLB接口、添加 PLB-DCR 橋接器實(shí)現(xiàn)總線宏的做法相比更實(shí)際。

下面的代碼摘自 PlanAhead 項(xiàng)目的 UCF 文件，說(shuō)明我們?nèi)绾问褂肁REA_GROUP 約束確定動(dòng)態(tài)部分的大小和位置：

內(nèi)部的部分重配置區(qū)域的命名方法通過(guò)為其指定實(shí)例名 PRR，并將實(shí)例名相連（prm_interface.vhd）。對(duì)我們希望囊括在所需的 PRR 中的全部 FPGA 資源而言，我們用設(shè)置左下方坐標(biāo)和右上方坐標(biāo)的方法來(lái)劃定一個(gè)矩形區(qū)域。

這種特殊的方法只能覆蓋 Slice和 BRAM，因?yàn)榭捎玫?DSP 元件屬于專用時(shí)鐘區(qū)域，歸多端口存儲(chǔ)器控制器 (MPMC) 設(shè)計(jì)使用（表 2）。

為避免 ISE® 生成的 PRM 網(wǎng)表使用專屬資源，我們將綜合選項(xiàng)設(shè)置為：dsp_utilization_ratio = 0；use_dsp48 = false；iobuf = false。最后，從 FPGA 編輯器觀察到靜態(tài)部分的布局完全與 PRR 分開(kāi)，PRR 在本例中占用的資源極少（圖 6）。

配備圖像處理 PRM 的 SOC 客戶端
我們使用在 PRM 中實(shí)現(xiàn)的 Sobel/ 中值過(guò)濾器驗(yàn)證 SoC 客戶端的運(yùn)算能力及其 TCP/IP 服務(wù)器通信功能（圖7）。我們使用賽靈思系統(tǒng)生成器（System Generator）開(kāi)發(fā)圖像處理鄰域運(yùn)算。賽靈思系統(tǒng)生成器讓我們享有 Simulink® 仿真和自動(dòng) RTL 代碼生成的便利。解串器將輸入的像素流轉(zhuǎn)換成 3x3 像素陣列，然后依次排列成一個(gè)覆蓋整個(gè)圖像的掩膜，為濾波器的并行乘積加總提供輸入，或?yàn)楹罄m(xù)的中值過(guò)濾器比較提供輸入。[7] 過(guò)濾器的輸入和輸出像素向量的寬度為 4 位，故我們插入一個(gè) PRM 封裝器，以多路復(fù)用同步 FIFO 提供的 32 位輸入向量的 8個(gè)四位元。使用MATLAB® 腳本，我們將 800 x 600 PNG 圖像轉(zhuǎn)換為四位灰度像素，用作 PRM 的輸入激勵(lì)。在過(guò)濾器的輸出端，8 個(gè)四位寄存器順序?qū)懭牒图?jí)聯(lián)，將字傳輸給 OUTFIFO（圖 4）。

表 3 是 SoC 客戶端三個(gè)運(yùn)算步驟（接收 PRM 比特文件、重配置PRR、圖像處理序列）的時(shí)序測(cè)量結(jié)果。我們用數(shù)字示波器在XGpio_WriteReg() 調(diào)用觸發(fā)的 GPIO 輸出處測(cè)量第一次到最后一次數(shù)據(jù)傳輸周期，采集接收與圖像處理周期。

重配置時(shí)間間隔都是一樣的，因?yàn)闆](méi)有 Xilkernel 調(diào)度事件干擾基于軟件的 HWICAP 操作。受 FSM 控制的HWICAP 操作在沒(méi)有 MicroBlaze 互動(dòng)的情況下，可以超過(guò) 112 KBps 的重配置速度實(shí)現(xiàn)更短的用時(shí)，甚至在啟用中斷的情況下也不例外。

在從代理向 SoC 客戶端發(fā)送PRM 的過(guò)程中，連接很快中斷。因?yàn)槊總鬏?100 個(gè)字節(jié)僅 1 毫秒的延遲，SoC 客戶端的通信非常暢通。由于與圖像處理周期同步，正常的 Xilkernel線程導(dǎo)致 PLB 訪問(wèn)競(jìng)爭(zhēng)，因此 SoC客戶端在典型狀態(tài)下運(yùn)行。二值化序列的用時(shí)為 600 x 800/100MHz=4.8毫秒，因?yàn)橹恍枰M(jìn)行一次比較。這個(gè)序列嵌套在兩次經(jīng) PLB 的圖像傳輸中，根據(jù)功能性總線仿真的結(jié)果，每個(gè)字至少需要使用五個(gè)時(shí)鐘周期，故：2 x 5 x 600 x 800/(8 x100MHz)=6 毫秒。由于所有測(cè)量的數(shù)據(jù)傳輸值都大于我們先前的預(yù)估值，我們需要對(duì)由總線讀取、FIFO 寫入和清空、圖像處理流水線和總線寫入組成的完整時(shí)序鏈條的構(gòu)成進(jìn)行詳細(xì)分析。

部分重配置的力量
在運(yùn)算復(fù)雜算法時(shí)，發(fā)揮分布式計(jì)算網(wǎng)絡(luò)的力量是理想的選擇。這些網(wǎng)絡(luò)的流行設(shè)計(jì)目前僅限于使用 CPU 和GPU。我們的基于 FPGA 的分布式SoC 網(wǎng)絡(luò)架構(gòu)原型運(yùn)用 FPGA 的并行信號(hào)處理特性來(lái)計(jì)算復(fù)雜算法。

賽靈思部分重配置技術(shù)是運(yùn)用分布在世界各地的 FPGA 共享資源的關(guān)鍵。在我們的架構(gòu)中，SoC 客戶端的靜態(tài)部分用更新的加速器以自控方式對(duì) FPGA 的動(dòng)態(tài)部分進(jìn)行重配置。我們必須改進(jìn) SoC 客戶端，使之能夠使用使能中斷運(yùn)行 HWICAP，以實(shí)現(xiàn)完全的反應(yīng)能力。這個(gè)方向的第一步是實(shí)現(xiàn) FSM 控制的重配置，不給處理器帶來(lái)負(fù)擔(dān)。不過(guò)我們還需要分析PLB 傳輸影響以及 MPMC 瓶頸問(wèn)題。

為管理 SoC 客戶端， 使用與LwIP 鏈接的 Xilkernel 確保重配置驅(qū)動(dòng)程序、動(dòng)態(tài)部分的總線接口及其它應(yīng)用的線程保持同步。我們進(jìn)一步重點(diǎn)分析客戶端- 服務(wù)器系統(tǒng)的時(shí)序和動(dòng)態(tài)部分的處理周期，以期發(fā)現(xiàn)有更高數(shù)據(jù)吞吐量和可靠通信能力的軟件/RTL 模型配置。

我們的 SoC 客戶端的下一階段的設(shè)計(jì)必須考慮 AXI4 總線功能。一般來(lái)說(shuō) PRM 交換可視為與一組軟件任務(wù)共同執(zhí)行的額外硬件任務(wù)。最后且同樣重要的是，我們?nèi)匀辉趦?yōu)化服務(wù)器的軟件設(shè)計(jì)，以期達(dá)到更高的客戶滿意度。