高校和私企正在應(yīng)用分布式平臺,而不是安裝速度更快、耗電更大的超級計算機來解決日益復(fù)雜的科學(xué)算法,,針對SETI@home 這樣的項目,,他們則使用數(shù)以千計的個人計算機來計算它們的數(shù)據(jù)。[1,,2] 當(dāng)前的分布式計算網(wǎng)絡(luò)一般用CPU 或 GPU 來計算項目數(shù)據(jù)。
FPGA 也正被像 COPACOBANA這樣的項目所采用,該項目使用 120個賽靈思 FPGA 通過暴力處理來破解DES 加密文件,。[3] 不過在這個案例中,F(xiàn)PGA 都被集中布置在一個地方,,這種方案不太適合那些預(yù)算緊張的大學(xué)或企業(yè),。目前并未將 FPGA 當(dāng)作分布式計算工具,這是因為它們的使用需要借助 PC,,才能用新的比特流不斷地重新配置整個 FPGA,。但是現(xiàn)在有了賽靈思部分重配置技術(shù),為分布式計算網(wǎng)絡(luò)設(shè)計基于 FPGA 的客戶端完全可行,。
我們漢堡應(yīng)用技術(shù)大學(xué)的研究小組為這樣的客戶端創(chuàng)建了一個原型,,并將其實現(xiàn)在單個 FPGA 上。我們的設(shè)計由靜態(tài)和動態(tài)兩大部分組成,。其中靜態(tài)部分在 FPGA 啟動時加載,,與此同時用靜態(tài)部分實現(xiàn)的處理器從網(wǎng)絡(luò)服務(wù)器下載動態(tài)部分。動態(tài)部分屬部分重配置區(qū)域,,提供共享的 FPGA資源,。[4] 采用這種配置,F(xiàn)PGA 可以位于世界上的任何地方,,用較低的預(yù)算就能夠為計算項目提供強大的計算能力,。
分布式 SOC 網(wǎng)絡(luò)
由于具有信號并行處理能力,F(xiàn)PGA能夠使用比微處理器慢 8 倍的時鐘,,低 8 倍的功耗實現(xiàn)比其快三倍的數(shù)據(jù)吞吐量,。[5] 為利用該強大的計算能力實現(xiàn)高數(shù)據(jù)輸入速率,設(shè)計人員一般將算法實現(xiàn)為流水線,比如 DES 加密,。[3] 我們開發(fā)分布式 SoC 網(wǎng)絡(luò) (DSN)原型的目的是加快算法的速度和使用分布式 FPGA 資源處理大型數(shù)據(jù)集,。我們的網(wǎng)絡(luò)設(shè)計采用“客戶端- 代理-服務(wù)器”架構(gòu),故我們可以將所有注冊的片上系統(tǒng) (SoC) 客戶端分配給每一個網(wǎng)絡(luò)參與方的計算項目(如圖 1所示),。這在將每一個 SoC 客戶端連接到唯一的項目的“客戶端- 服務(wù)器”架構(gòu)中是無法實現(xiàn)的,。
另外,,我們選擇“代理- 服務(wù)器”架構(gòu)可以將每個 FPGA 的 TCP/IP 連接數(shù)量減少到一個。DSN FPGA 負(fù)責(zé)運算使用專用數(shù)據(jù)集的算法,,而“代理-服務(wù)器”則負(fù)責(zé)管理 SoC 客戶端和項目客戶端,。代理調(diào)度連接的 SoC 客戶端,讓每個項目在相同的時間幾乎擁有相同的計算能力,,或者在 SoC 的數(shù)量少于計算請求的項目時分時復(fù)用soc客戶端,。
項目客戶端提供部分重配置模塊(PRM) 和激勵輸入數(shù)據(jù)集。在連接到“代理- 服務(wù)器”之后,,項目客戶端將PRM 比特文件發(fā)送給服務(wù)器,然后由服務(wù)器將它們分配給帶有空閑的部分可重配置區(qū)域 (PRR) 的 SoC 客戶端,。SoC 客戶端的靜態(tài)部分是一個基于MicroBlazeTM 的微控制器,,用接收到的 PRM 動態(tài)重新配置 PRR。接下來,,項目客戶端開始通過“代理- 服務(wù)器”發(fā)送數(shù)據(jù)集并從 SoC 客戶端接收計算的結(jié)果,。根據(jù)項目客戶端的需要,舉例來說,,它可以比較不同的計算結(jié)果,,或根據(jù)計算目的評估計算結(jié)果。
MicroBlaze 處理器負(fù)責(zé)運行客戶端軟件,,客戶端軟件管理部分重配置以及比特流和數(shù)據(jù)交換,。
SOC 客戶端
我們?yōu)殡S ML605 評估板配套提供的賽靈思 Virtex®-6 FPGA(XC6VLX240T)開發(fā)了 SoC 客戶端。MicroBlazeTM 處理器負(fù)責(zé)運行客戶端軟件,,客戶端軟件負(fù)責(zé)管理部分可重配置以及比特流和數(shù)據(jù)交換(如圖 2 所示),。用戶邏輯封裝PRR 的處理器本地總線 (PLB) 外設(shè)用以連接靜態(tài)部分和動態(tài)部分。在動態(tài)部分駐留的是接收到的 PRM 提供的加速器 IP 核使用的 FPGA 共享資源,。為存儲接收到的數(shù)據(jù)和計算完成的數(shù)據(jù),,我們選擇了 DDR3 存儲器而非CompactFlash,因為 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,,能夠為比如圖像或加密文本文件等提供足夠的尋址空間。管理這些數(shù)據(jù)段主要依靠 10 個管理結(jié)構(gòu),。該管理結(jié)構(gòu)包括每個數(shù)據(jù)集對的起始/ 終點地址,,以及指示結(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客戶端軟件的底層實時操作系統(tǒng)加以實現(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)部配置接入點)用 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”消息,會生成一個計算線程和一個發(fā)送線程,。
計算線程將輸入- 結(jié)果數(shù)據(jù)集的地址發(fā)送到 PRR 外設(shè)的從接口,并啟動PRM 的自動數(shù)據(jù)集處理功能,。管理結(jié)構(gòu)為每個數(shù)據(jù)集提供這些地址,,并在確保結(jié)果數(shù)據(jù)完全可用后設(shè)置“完成”標(biāo)志。在目前的客戶端軟件概念版本中,,計算線程和發(fā)送線程通過該結(jié)構(gòu)通信,,由發(fā)送線程反復(fù)檢查完成位, 并將lwip_write() 調(diào)用存儲在存儲器中的結(jié)果,。
在測試 SoC 客戶端時,我們發(fā)現(xiàn)如果在 PRR 重配置過程中啟用全部中斷,,Xilkernel 的定時器會產(chǎn)生調(diào)度函數(shù)訪問 MicroBlaze,,使重配置過程隨機發(fā)生卡住的狀況。如果禁用全部中斷,,或在沒有 Xilkernel 的支持下,,對SoC 客戶端的 MicroBlaze 處理器使用獨立的軟件模塊,就不會發(fā)生這種情況,。
配備例化PRM 的總線主控外設(shè)
為在 PRM 和外部存儲器之間實現(xiàn)自控激勵數(shù)據(jù)和結(jié)果的交換,,我們將總線主外設(shè)構(gòu)建為一個帶數(shù)據(jù)路徑和控制路徑的處理器元件(如圖 4 所示)。在數(shù)據(jù)路徑中,,我們在兩個深度均為16 個字的 FIFO 模塊之間嵌入 PRM接口,,以補償通信和數(shù)據(jù)傳輸延遲。數(shù)據(jù)路徑的兩個 FIFO 均直接連接到PLB 的總線主接口。這樣,,我們通過有限狀態(tài)機 (FSM) 的直接數(shù)據(jù)傳輸,,大幅降低時間。由于不采用軟件,,所以 MicroBlaze 的寄存器文件中不發(fā)生中間數(shù)據(jù)存儲,。本 RISC 處理器的“加載- 存儲”架構(gòu)一直需要占用兩個總線傳輸周期,用于從某個地址加載 CPU 寄存器,,然后將寄存器的內(nèi)容存儲到另一個 PLB 連接的設(shè)備,。由于從 MicroBlaze 到存儲器控制器的DXCL 數(shù)據(jù)高速緩存鏈路構(gòu)成 PLB 的旁路,因此這些“加載- 存儲”周期在時序上不能得到改善,。這是因為接收到的數(shù)據(jù)和發(fā)送的計算結(jié)果都是逐字一次性處理,,沒有發(fā)揮高速緩存的作用。由此 PRR 外設(shè)的活動與 MicroBlaze 主軟件的處理脫鉤,,因而 PRR 數(shù)據(jù)傳輸不會導(dǎo)致更多的 Xilkernel 環(huán)境切換,。但仍然不可避免地出現(xiàn)兩個主設(shè)備競爭總線訪問的情況。
外設(shè)的從接口含有四個基于軟件驅(qū)動的寄存器,可為控制路徑提供輸入和輸出數(shù)據(jù)集的起始地址和終點地址,。另一個軟件寄存器為 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)行,,因為每次只能使用一種總線訪問方式,。當(dāng)來自客戶端的計算線程的軟件復(fù)位啟動 FSM(圖 3)時,第一件事就是從外部存儲器讀?。顟B(tài) READ_REQ),。自此,總線主設(shè)備就受狀態(tài) STARTED 提供的轉(zhuǎn)換條件所提供的決策邏輯的控制(表 1),。
Mealy FSM 輸出(標(biāo)記Exit/)讓地址計數(shù)器在總線傳輸完成時遞增,。這里兩個計數(shù)器都直接導(dǎo)入到 FSM代碼中,。一般情況下我們傾向于將定時器和地址計數(shù)器分開實現(xiàn)為僅用FSM 輸出使能的單獨時鐘進(jìn)程,以便讓計數(shù)器的保持小規(guī)模的轉(zhuǎn)換邏輯以及盡量避免將多路復(fù)用器輸入用于計數(shù)器狀態(tài)反饋,。對于此點,,XST 綜合編譯器的結(jié)果將 RTL 原理圖清楚地體現(xiàn)為并行于可加載計數(shù)器的 FSM 抽象,其中的時鐘使能輸入由預(yù)期狀態(tài)解碼邏輯驅(qū)動,。盡管行為級的 VHDL編碼方式更容易讓人理解,,使用 FPGA資源和簡單原語也不會影響功能。
用 PLANAHEAD 設(shè)置動態(tài)部分
FPGA 中靜態(tài)和動態(tài)部分的配置這一設(shè)計流程是一個復(fù)雜的開發(fā)過程,,需要用 PlanAheadTM 物理設(shè)計約束工具進(jìn)行多步操作,。第一步就是給在ML505 開發(fā)板上實現(xiàn)的由 PetaLinux驅(qū)動的動態(tài)重配置平臺編寫設(shè)計流程腳本。[6] 就當(dāng)前迭代而言,,將 PRR直接集成到外設(shè)的用戶邏輯中的設(shè)計步驟與過去通過添加總線宏和器件控制寄存器(DCR) 用作 PRM 的 PLB接口,、添加 PLB-DCR 橋接器實現(xiàn)總線宏的做法相比更實際。
下面的代碼摘自 PlanAhead 項目的 UCF 文件,,說明我們?nèi)绾问褂肁REA_GROUP 約束確定動態(tài)部分的大小和位置:
內(nèi)部的部分重配置區(qū)域的命名方法通過為其指定實例名 PRR,,并將實例名相連(prm_interface.vhd)。對我們希望囊括在所需的 PRR 中的全部 FPGA 資源而言,,我們用設(shè)置左下方坐標(biāo)和右上方坐標(biāo)的方法來劃定一個矩形區(qū)域,。
這種特殊的方法只能覆蓋 Slice和 BRAM,因為可用的 DSP 元件屬于專用時鐘區(qū)域,,歸多端口存儲器控制器 (MPMC) 設(shè)計使用(表 2),。
為避免 ISE® 生成的 PRM 網(wǎng)表使用專屬資源,我們將綜合選項設(shè)置為:dsp_utilization_ratio = 0,;use_dsp48 = false,;iobuf = false。最后,,從 FPGA 編輯器觀察到靜態(tài)部分的布局完全與 PRR 分開,,PRR 在本例中占用的資源極少(圖 6)。
配備圖像處理 PRM 的 SOC 客戶端
我們使用在 PRM 中實現(xiàn)的 Sobel/ 中值過濾器驗證 SoC 客戶端的運算能力及其 TCP/IP 服務(wù)器通信功能(圖7)。我們使用賽靈思系統(tǒng)生成器(System Generator)開發(fā)圖像處理鄰域運算,。賽靈思系統(tǒng)生成器讓我們享有 Simulink® 仿真和自動 RTL 代碼生成的便利,。解串器將輸入的像素流轉(zhuǎn)換成 3x3 像素陣列,然后依次排列成一個覆蓋整個圖像的掩膜,,為濾波器的并行乘積加總提供輸入,,或為后續(xù)的中值過濾器比較提供輸入,。[7] 過濾器的輸入和輸出像素向量的寬度為 4 位,故我們插入一個 PRM 封裝器,,以多路復(fù)用同步 FIFO 提供的 32 位輸入向量的 8個四位元,。使用MATLAB® 腳本,我們將 800 x 600 PNG 圖像轉(zhuǎn)換為四位灰度像素,,用作 PRM 的輸入激勵,。在過濾器的輸出端,8 個四位寄存器順序?qū)懭牒图壜?lián),,將字傳輸給 OUTFIFO(圖 4),。
表 3 是 SoC 客戶端三個運算步驟(接收 PRM 比特文件,、重配置PRR、圖像處理序列)的時序測量結(jié)果,。我們用數(shù)字示波器在XGpio_WriteReg() 調(diào)用觸發(fā)的 GPIO 輸出處測量第一次到最后一次數(shù)據(jù)傳輸周期,,采集接收與圖像處理周期。
重配置時間間隔都是一樣的,因為沒有 Xilkernel 調(diào)度事件干擾基于軟件的 HWICAP 操作,。受 FSM 控制的HWICAP 操作在沒有 MicroBlaze 互動的情況下,,可以超過 112 KBps 的重配置速度實現(xiàn)更短的用時,甚至在啟用中斷的情況下也不例外,。
在從代理向 SoC 客戶端發(fā)送PRM 的過程中,,連接很快中斷。因為每傳輸 100 個字節(jié)僅 1 毫秒的延遲,,SoC 客戶端的通信非常暢通,。由于與圖像處理周期同步,正常的 Xilkernel線程導(dǎo)致 PLB 訪問競爭,,因此 SoC客戶端在典型狀態(tài)下運行,。二值化序列的用時為 600 x 800/100MHz=4.8毫秒,因為只需要進(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ì)分析,。
部分重配置的力量
在運算復(fù)雜算法時,發(fā)揮分布式計算網(wǎng)絡(luò)的力量是理想的選擇,。這些網(wǎng)絡(luò)的流行設(shè)計目前僅限于使用 CPU 和GPU,。我們的基于 FPGA 的分布式SoC 網(wǎng)絡(luò)架構(gòu)原型運用 FPGA 的并行信號處理特性來計算復(fù)雜算法。
賽靈思部分重配置技術(shù)是運用分布在世界各地的 FPGA 共享資源的關(guān)鍵,。在我們的架構(gòu)中,,SoC 客戶端的靜態(tài)部分用更新的加速器以自控方式對 FPGA 的動態(tài)部分進(jìn)行重配置。我們必須改進(jìn) SoC 客戶端,,使之能夠使用使能中斷運行 HWICAP,,以實現(xiàn)完全的反應(yīng)能力。這個方向的第一步是實現(xiàn) FSM 控制的重配置,,不給處理器帶來負(fù)擔(dān),。不過我們還需要分析PLB 傳輸影響以及 MPMC 瓶頸問題。
為管理 SoC 客戶端,, 使用與LwIP 鏈接的 Xilkernel 確保重配置驅(qū)動程序,、動態(tài)部分的總線接口及其它應(yīng)用的線程保持同步。我們進(jìn)一步重點分析客戶端- 服務(wù)器系統(tǒng)的時序和動態(tài)部分的處理周期,,以期發(fā)現(xiàn)有更高數(shù)據(jù)吞吐量和可靠通信能力的軟件/RTL 模型配置,。
我們的 SoC 客戶端的下一階段的設(shè)計必須考慮 AXI4 總線功能。一般來說 PRM 交換可視為與一組軟件任務(wù)共同執(zhí)行的額外硬件任務(wù),。最后且同樣重要的是,,我們?nèi)匀辉趦?yōu)化服務(wù)器的軟件設(shè)計,以期達(dá)到更高的客戶滿意度,。