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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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