高校和私企正在應用分布式平臺，而不是安裝速度更快、耗電更大的超級計算機來解決日益復雜的科學算法，針對SETI@home 這樣的項目，他們則使用數以千計的個人計算機來計算它們的數據。[1，2] 當前的分布式計算網絡一般用CPU 或 GPU 來計算項目數據。

FPGA 也正被像 COPACOBANA這樣的項目所采用，該項目使用 120個賽靈思 FPGA 通過暴力處理來破解DES 加密文件。[3] 不過在這個案例中，FPGA 都被集中布置在一個地方，這種方案不太適合那些預算緊張的大學或企業。目前并未將 FPGA 當作分布式計算工具，這是因為它們的使用需要借助 PC，才能用新的比特流不斷地重新配置整個 FPGA。但是現在有了賽靈思部分重配置技術，為分布式計算網絡設計基于 FPGA 的客戶端完全可行。

我們漢堡應用技術大學的研究小組為這樣的客戶端創建了一個原型，并將其實現在單個 FPGA 上。我們的設計由靜態和動態兩大部分組成。其中靜態部分在 FPGA 啟動時加載，與此同時用靜態部分實現的處理器從網絡服務器下載動態部分。動態部分屬部分重配置區域，提供共享的 FPGA資源。[4] 采用這種配置，FPGA 可以位于世界上的任何地方，用較低的預算就能夠為計算項目提供強大的計算能力。

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

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

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

MicroBlaze 處理器負責運行客戶端軟件，客戶端軟件管理部分重配置以及比特流和數據交換。

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

我們還為接收及結果數據集創建了不同的數據段。這些數據段的大小有 50 MB，能夠為比如圖像或加密文本文件等提供足夠的尋址空間。管理這些數據段主要依靠 10 個管理結構。該管理結構包括每個數據集對的起始/ 終點地址，以及指示結果數據集的標志。

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

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

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

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

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

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

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

根據控制路徑的 FSM 的狀態圖可以看出，應該采取讓到 PLB 的寫入周期優先的策略（圖5）。從 OUT_FIFO 提取數據優先于向 IN_FIFO 寫入數據，防止 OUT_FIFO 為滿時，阻止 PRM 處理算法。讀取或寫入外部存儲器可交替進行，因為每次只能使用一種總線訪問方式。當來自客戶端的計算線程的軟件復位啟動 FSM（圖 3）時，第一件事就是從外部存儲器讀取（狀態 READ_REQ）。自此，總線主設備就受狀態 STARTED 提供的轉換條件所提供的決策邏輯的控制（表 1）。

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

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

下面的代碼摘自 PlanAhead 項目的 UCF 文件，說明我們如何使用AREA_GROUP 約束確定動態部分的大小和位置：

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

這種特殊的方法只能覆蓋 Slice和 BRAM，因為可用的 DSP 元件屬于專用時鐘區域，歸多端口存儲器控制器 (MPMC) 設計使用（表 2）。

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

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

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

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

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

部分重配置的力量
在運算復雜算法時，發揮分布式計算網絡的力量是理想的選擇。這些網絡的流行設計目前僅限于使用 CPU 和GPU。我們的基于 FPGA 的分布式SoC 網絡架構原型運用 FPGA 的并行信號處理特性來計算復雜算法。

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

為管理 SoC 客戶端， 使用與LwIP 鏈接的 Xilkernel 確保重配置驅動程序、動態部分的總線接口及其它應用的線程保持同步。我們進一步重點分析客戶端- 服務器系統的時序和動態部分的處理周期，以期發現有更高數據吞吐量和可靠通信能力的軟件/RTL 模型配置。

我們的 SoC 客戶端的下一階段的設計必須考慮 AXI4 總線功能。一般來說 PRM 交換可視為與一組軟件任務共同執行的額外硬件任務。最后且同樣重要的是，我們仍然在優化服務器的軟件設計，以期達到更高的客戶滿意度。