今天給大家推薦今年FCCM2021上的一篇文章，介紹了一種可以在線Xilinx FPGA內(nèi)部RAM內(nèi)容的工作，重點是論文相關(guān)的工作還是開源的。

摘要：XBERT是一個API和設(shè)計工具集，用于使用設(shè)備的配置路徑零成本訪問Xilinx體系結(jié)構(gòu)上的片上SRAM塊。XBERT API是高級別的，允許開發(fā)人員根據(jù)應(yīng)用程序源代碼中的邏輯內(nèi)存指定類似DMA的內(nèi)存內(nèi)容數(shù)據(jù)傳輸，因此基本上適用于任何針對Xilinx設(shè)備的設(shè)計。應(yīng)用程序開發(fā)人員可以廣泛地訪問XBERT，它隱藏了物理映射和比特流編碼的底層細節(jié)。XBERT是高效的，消耗的可重構(gòu)資源為零，對Fmax沒有影響。XBERT在Xilinx UltraScale+MPSoC Zynq上實現(xiàn)了每秒3–14兆字節(jié)（MB/s）的帶寬，并在不到0.5毫秒的時間內(nèi)完成了36Kb塊RAM中內(nèi)存的回讀和轉(zhuǎn)換。

1. 簡介

今天的FPGA結(jié)構(gòu)包括大量的分布式、嵌入式RAM塊。雖然這些嵌入式RAMs最常見的用途是在FPGA結(jié)構(gòu)上提供和存儲計算過程中使用的數(shù)據(jù)，但從結(jié)構(gòu)外部加載數(shù)據(jù)或輸入或檢索存儲為計算輸出的數(shù)據(jù)是必要的。

我們可以使用FPGA結(jié)構(gòu)資源和專用結(jié)構(gòu)輸入/輸出通道（例如AXI通道）來將數(shù)據(jù)移入和移出這些嵌入式存儲器，但這會消耗FPGA結(jié)構(gòu)資源以及嵌入式RAM原語上有限的讀/寫端口。而且，這種額外的邏輯可能會對滿足應(yīng)用程序計時要求帶來挑戰(zhàn)［1］。

這些嵌入式RAMs的內(nèi)容也可以通過現(xiàn)有的專用片上網(wǎng)絡(luò)（比特流重新配置路徑）訪問。因此，應(yīng)該可以使用比特流重新配置路徑來在不消耗任何FPGA結(jié)構(gòu)資源的情況下將數(shù)據(jù)移入和移出這些嵌入式RAM塊。此外，在具有嵌入式處理器的SoC FPGAs上，處理器可以作為系統(tǒng)計算的一部分來管理重構(gòu)。

然而，將原始設(shè)計源中的邏輯內(nèi)存映射到FPGA結(jié)構(gòu)上的物理內(nèi)存是一項具有挑戰(zhàn)性的任務(wù)。一旦實現(xiàn)工具將一個較大的邏輯內(nèi)存映射到多個較小的內(nèi)存上，那么識別哪個物理BRAM原語保存特定的邏輯數(shù)據(jù)對于應(yīng)用程序編程人員來說是不容易發(fā)現(xiàn)的，并且每次更改設(shè)計源并將其重新映射到FPGA時都可能發(fā)生變化。此外，用于比特流編程的數(shù)據(jù)格式與存儲數(shù)據(jù)的邏輯格式不同邏輯存儲器的位在BRAM初始化字符串中沒有整齊地按升序排列，并且這些初始化字符串中的位隨后分散在多個配置幀中。

為了滿足這些需求，我們創(chuàng)建了Xilinx Bitstream Embedded RAM Transmission（XBERT）API，以提供一個高級接口來讀取和寫入邏輯內(nèi)存的內(nèi)容，正如應(yīng)用程序開發(fā)人員在源代碼級（如RTL、HLS、IP塊）設(shè)計中看到的那樣［1］。

透析（Transfusion）操作是讀寫操作的結(jié)合，它提取舊的BRAM內(nèi)容并提供新的BRAM內(nèi)容。重要的是，這些合并的輸入操作可以比使用單獨的讀寫操作更有效。

我們的自動工具流提取有關(guān)邏輯內(nèi)存如何映射到物理嵌入式RAMs的信息，以允許XBERT API對這些內(nèi)存進行操作。我們的API能夠在幾分之一毫秒內(nèi)讀取結(jié)果數(shù)據(jù)并將其轉(zhuǎn)換為邏輯內(nèi)存格式，從而提供以MB/s為單位的有效數(shù)據(jù)傳輸速率。這不如專用高速鏈路（例如，5 GB/s的AXI通道）快，但對于不經(jīng)常訪問的內(nèi)存（例如，在啟動時使用唯一數(shù)據(jù)編程或在程序完成時恢復(fù)數(shù)據(jù)）或中等帶寬（例如，周期性參數(shù)調(diào)整）足夠，具體可見節(jié)II和III-F。值得注意的是，這是在不減少Fmax或FPGA資源消耗的情況下實現(xiàn)的。

我們的貢獻包括：

一個API，用于提供對存儲在FPGA結(jié)構(gòu)的嵌入式RAM中的內(nèi)存的邏輯訪問（第五節(jié)）

UltraScale+MPSoC Zynq的XBERT API的開源實現(xiàn)，包括提取邏輯?單個內(nèi)存位的物理映射和運行時支持讀取和寫入正在運行的FPGA內(nèi)存內(nèi)容（在［2］處在線）

邏輯到物理位映射的定制壓縮技術(shù)，將轉(zhuǎn)換表大小從兆字節(jié)減少到千字節(jié)（第七節(jié)）

基于表格的加速，可減少單個BRAM轉(zhuǎn)換時間，與DMA傳輸時間（第八節(jié)）

API實現(xiàn)性能的表征（第九節(jié)）

2. 用場景

XBERT提供的一般功能有許多用例。編程BRAM配置的覆蓋架構(gòu)是不經(jīng)常修改嵌入式RAM內(nèi)容的一個明顯需求，包括更新嵌入式軟處理器中的程序內(nèi)存內(nèi)容，如RISC-V處理器核［3］、［4］、自定義VLIW［5］、自定義的VLIW［5］、［6］和向量［7］、［8］處理器。這種需要加載的指令也適用于更專業(yè)的覆蓋結(jié)構(gòu)的加載配置，如專用的FSM評估器［9］、［10］和神經(jīng)網(wǎng)絡(luò)［11］或模擬器［12］。

另一個用例是FPGA構(gòu)建塊的高速單元測試，在這里需要以全速率向被測模塊提供數(shù)據(jù)并捕獲結(jié)果。這可以用一個存儲器將數(shù)據(jù)源輸入被測模塊，用另一個存儲器記錄結(jié)果。類似地，在使用內(nèi)部邏輯分析器（ILA）或跟蹤緩沖區(qū)［13］、［14］進行實時調(diào)試以在操作期間捕獲數(shù)據(jù)時，我們在測試后卸載這些數(shù)據(jù)的速度通常并不重要。

最后，在極端情況下，XBERT功能可以提供一種廉價的方式來支持當(dāng)前FPGA上的高級抽象，如CoRAM［15］。CoRAM提議增加專用的基礎(chǔ)設(shè)施來管理嵌入式RAMs和中央內(nèi)存之間的數(shù)據(jù)移動，并演示了在FPGA上構(gòu)建覆蓋網(wǎng)絡(luò)的原型。使用XBERT，可以使用現(xiàn)有的重配置路徑硬件支持提供相同的功能，而無需增加覆蓋邏輯。

3. XBERT：概述、挑戰(zhàn)和解決方案

本節(jié)介紹XBERT，包括XBERT這樣的系統(tǒng)面臨的挑戰(zhàn)和操作要求，以及解決這些問題的方法和由此帶來的好處。

》3.1 基本單BRAM操作

首先，考慮一下將映射到單個36Kb BRAM的簡單邏輯內(nèi)存的內(nèi)容進行更改的簡單用例。如果邏輯內(nèi)存恰好是XPM實例化的內(nèi)存，那么在主機上運行的Xilinx的UpdateMem程序可以更改完整比特流中的BRAM。運行Update Mem需要4秒來更改比特流以反映新的BRAM內(nèi)容，而將完整的比特流加載到XCU3EG需要9毫秒。這既慢又需要使用單獨的主機。

使用XBERT中最簡單的write API（bert_write），我們可以在Zynq的嵌入式APU內(nèi)核上運行代碼時執(zhí)行更新，并在1.04毫秒（快3900倍）內(nèi)編寫B(tài)RAM。這包括0.71 ms用于轉(zhuǎn)換位（將邏輯存儲器位描述轉(zhuǎn)換為部分比特流）和0.25 ms用于通過Zynq PCAP將部分比特流寫入設(shè)備；寫入速度達到3.9MB/s帶寬。重要的是，這個XBERT寫操作適用于任何邏輯內(nèi)存，而不僅僅是那些用XPM實例化的內(nèi)存。

》3.2 基于表的轉(zhuǎn)換、壓縮和加速

UpdateMem運行時使用完整的Xilinx設(shè)備數(shù)據(jù)庫（用于部件）和完整的設(shè)計檢查點數(shù)據(jù)集（用于設(shè)計），XBERT將此信息替換為一個最小的轉(zhuǎn)換表，該表描述每個邏輯內(nèi)存位映射到比特流的位置。XBERT中的原始轉(zhuǎn)換表最初需要238KB，但是使用壓縮可以將其減少到2.3KB（第七節(jié)）。

上述1.04 ms XBERT時間的主要組成部分是翻譯（0.71 ms），主要包括從邏輯存儲器圖像計算各個位的比特流位置。當(dāng)我們向XBERT（第八節(jié)）添加一個加速的、基于表的多位翻譯功能時，我們可以將其減少到0.28毫秒，因此整個寫操作在0.62毫秒內(nèi)完成，吞吐量為6.59 MB/s—大約是未加速情況下的兩倍。

》3.3 Transfusion-組合操作以提高性能

談到單個BRAM內(nèi)存的最小DMA傳輸時間，我們注意到它很大（0.25毫秒），部分原因是寫入發(fā)生在幀中，需要為UltraScale+體系結(jié)構(gòu)中共享一幀的所有12個內(nèi)存寫入數(shù)據(jù)（圖3）。如果我們需要在一個幀中寫入多個BRAM，或者因為一個邏輯內(nèi)存使用多個BRAM，或者因為我們需要寫入多個恰好共享一個物理幀的邏輯內(nèi)存，那么我們可以減少每個BRAM的DMA傳輸時間。在極端情況下，我們將每BRAM DMA傳輸成本降低了12倍，約為0.021 ms，因此每BRAM總寫入成本約為0.32 ms（或11.75 MB/s的吞吐量，約為單次加速吞吐量的兩倍）。因此，有一個scatter-gather接口是非常有效的，它允許我們指定要作為單個操作寫入的完整邏輯內(nèi)存集，這樣API就可以最小化所需的幀寫入次數(shù)。我們的transfuse API接口提供了此功能（第五節(jié)）。

雖然有寫使能允許我們一次在一個幀中寫入一個36Kb的BRAM，但是沒有寫使能控制在一個36Kb的BRAM中獨立地寫入兩個18Kb的內(nèi)存。要單獨寫入一個18Kb內(nèi)存，我們可能需要先讀取整個幀，以便在塊中保留伙伴18Kb內(nèi)存的值。XBERT transfuse API可以將此回讀與同一物理幀（秒）中其他邏輯內(nèi)存的讀取結(jié)合起來（第五節(jié)）。

》3.4 處理較大內(nèi)存-邏輯到物理內(nèi)存映射

為了簡單起見，上面的示例使用了只映射到單個BRAM的邏輯內(nèi)存。在實踐中，邏輯記憶常常映射到多個物理內(nèi)存。當(dāng)這種情況發(fā)生時，有很多選擇如何將位打包到內(nèi)存中。例如，在一個32×10000內(nèi)存，我們已經(jīng)看到Vivado將內(nèi)存的底部18b（［17:0］）映射為5個18×2048RAMB36s，下一個9b（［26:18］）到三個9×4096RAMB36s，下一個4b（［30:27］）到兩個4×8192 RAMB36s，最后一位（［31］）為1×16384RAM36s；這種非均勻映射只使用11個RAMB36，而在其他設(shè)計中，我們看到Vivado將一個大小類似的內(nèi)存映射到一組16個RAMB36內(nèi)存，每個內(nèi)存寬2位，深16K個字。

最后，對于小于單個BRAM的內(nèi)存，Vivado可能會將高階地址位綁定到0以外的值，這意味著內(nèi)存的邏輯0位置不會從正常預(yù)期的位置（物理BRAM的幀集的第一幀）開始。

為了解決這些復(fù)雜而繁瑣的物理映射問題，XBERT工具流自動從Vivado Design CheckPoint（DCP）文件或項目中提取這些映射細節(jié)，作為其邏輯到物理內(nèi)存映射功能的一部分。因此，應(yīng)用程序開發(fā)人員不需要處理這些問題，他們能夠?qū)ｉT處理邏輯內(nèi)存內(nèi)容，XBERT對他們隱藏了許多映射細節(jié)（第五節(jié)）。

》3.5 XBERT設(shè)計流程摘要

圖1示出了XBERT的主機側(cè)準備工具流程。從頂部開始，對用戶的設(shè)計（以設(shè)計檢查點的形式最少地表示）進行處理，以提取原始設(shè)計源中包含的邏輯內(nèi)存的信息，從而生成一個MDD文件（第4-D節(jié)）。然后將其與從Xilinx生成的.ll文件中提取的比特流信息結(jié)合起來，為設(shè)計創(chuàng)建邏輯到物理內(nèi)存映射信息的完整表示（mydesign_uncompressed.{c，h}）。然后對其進行壓縮和可選的加速，以生成一個mydesign.c文件，其中包含作為c數(shù)據(jù)結(jié)構(gòu)的該信息的壓縮版本。

在圖的底部，最終的XBERT應(yīng)用程序由三組源代碼組成：（1）XBERT運行時源代碼（bert.c），（2）mydesign.c文件，以及（3）用戶的應(yīng)用程序代碼（application.c）。

這與XBERT的擴展xilfpga庫（第六節(jié)） 進入最終可執(zhí)行的應(yīng)用程序。

圖1:XBERT工具流程

》3.6 一個充分激勵的例子

考慮開發(fā)一個包含四個獨立存儲器的哈夫曼編碼加速器。這個哈夫曼編碼器接收字節(jié)流，并通過將每個字節(jié)映射到一個可變長度的代碼來壓縮它。而且，為了獲得好的壓縮效果，哈夫曼碼應(yīng)該調(diào)整到被編碼的數(shù)據(jù)。

我們將編碼器設(shè)計為使用編碼表（內(nèi)存#1）進行任何編碼，并且可以在更改編碼時使用XBERT更新其內(nèi)容。HDL源代碼中的編碼表是只讀的，但是我們可以使用bert_write來加載它的內(nèi)容。加載表需要1.1毫秒。如果沒有XBERT，我們將需要使用AXI端口來執(zhí)行加載，這樣會更快，但會在設(shè)計中添加LUT和寄存器（表1）。

表1：在HUFFMAN示例中添加AXI訪問對內(nèi)存的影響

當(dāng)我們第一次設(shè)計編碼器時，我們通常希望在將數(shù)據(jù)源和數(shù)據(jù)使用者添加到設(shè)計中之前測試它的功能和速度。我們可以通過添加一個內(nèi)存來保存輸入數(shù)據(jù)（內(nèi)存2）和一個內(nèi)存來存儲輸出數(shù)據(jù)（內(nèi)存3）。使用XBERT我們不需要其他東西。我們可以使用bert_write將編碼器要壓縮的新數(shù)據(jù)加載到輸入存儲器中，并使用bert_read恢復(fù)壓縮的輸出。

我們還添加了一個直方圖內(nèi)存，使用256個元素的內(nèi)存（內(nèi)存4）捕獲輸入數(shù)據(jù)的特征。使用bert_read，我們可以在0.45毫秒內(nèi)讀回這個內(nèi)存的內(nèi)容。如果我們每個周期壓縮一個字節(jié)，這個直方圖需要在每個周期上執(zhí)行讀寫操作，這意味著它的兩個端口都被使用。對于提供回讀的非XBERT設(shè)計，它需要共享一個端口或復(fù)制內(nèi)存以有效地提供另一個讀端口。對于XBERT，兩者都不是必需的。

使用XBERT我們可以讀取或?qū)懭朐O(shè)計中的四個存儲器中的任何一個。我們可以讀取直方圖內(nèi)存內(nèi)容，根據(jù)輸入數(shù)據(jù)流計算新的編碼表，然后將新的編碼表寫回到設(shè)計中，所有這些都在1.2ms內(nèi)完成。

選項卡。我展示了在設(shè)計中添加AXI接口的影響（面積，F(xiàn)max）。我們在AXI子系統(tǒng)和Huffman解碼器之間使用MMCM，這樣后者就可以以最大時鐘速率運行，而不受最大AXI時鐘速率333MHz的限制。由于這個Huffman示例很小，因此提供對BRAMs的訪問的Fmax影響很小。在更大、高度擁擠的設(shè)計中，［1］聲稱消除AXI-BRAM訪問可以實現(xiàn)高達63%的Fmax改進（第4-C節(jié)）。

4. 相關(guān)工作

》4.1 物理BRAM操作應(yīng)用程序和工具

許多工具都利用了這樣的情況，即它們可以提供有用的功能來處理原始BRAMs，而不需要映射或轉(zhuǎn)換回邏輯級別。早在2000年，Xilinx就為嵌入式RAM的部分重新配置回讀和重新加載提供了實驗性的低級別支持［16］，［17］，主要用于內(nèi)存回讀和清理［18］。最近，ReconOS使用比特流讀寫進行多任務(wù)處理［19］（通過比特流加載和卸載BRAM內(nèi)容）。Metawire使用比特流將數(shù)據(jù)從BRAM移動到BRAM，以提供片上網(wǎng)絡(luò)（NoC）功能；由于它們控制著BRAM映射并從一個BRAM轉(zhuǎn)移到另一個BRAM，因此它們避免了從物理映射到邏輯映射的轉(zhuǎn)換［20］。

類似地，有幾部著作將直接BRAM寫入特定的應(yīng)用程序，包括［21］-［23］。

》4.2 物理比特流API

最近的工作希望為物理層的比特流操作提供一個API。BITMAN pro提供了一個通用的物理層訪問機制，可以訪問BRAM內(nèi)容通過change_BRAM_content（X，Y，new_config）API［24］。與上述工具一樣，它需要一些更高級別的接口或手動開發(fā)操作干預(yù)來確定哪些BRAM位置需要更改，并格式化配置數(shù)據(jù)，包括將邏輯位洗牌到它們在物理配置映射中的位置。

類似地，最近在［25］中的工作提倡使用比特流回讀和編輯來讀寫B(tài)RAM內(nèi)容的方法，并演示了如何在BRAM之間復(fù)制數(shù)據(jù)。但是，它不涉及識別哪些物理內(nèi)存用于特定的邏輯內(nèi)存。它也沒有提供完整的描述或高級工具，允許開發(fā)人員將其HLS或RTL邏輯內(nèi)存內(nèi)容映射到比特流中，或者提取比特流內(nèi)容并重建HLS或RTL內(nèi)存的狀態(tài)。

》4.3 專用邏輯內(nèi)存操作

Maxeler探索使用比特流路徑來加載和讀取他們的“映射內(nèi)存”，而不是單獨的低速總線［1］。他們表明，去掉低速總線及其對結(jié)構(gòu)資源的相關(guān)需求，可以將他們設(shè)計的性能提高高達63%。他們的比特流接口實現(xiàn)了高達2MB/s的數(shù)據(jù)傳輸帶寬。

Maxeler的用法可能與XBERT提供的最為相似。然而，Maxeler（a）僅將此BRAM路徑用于編譯器內(nèi)部生成的內(nèi)存的特定用途，（b）不提供可供開發(fā)人員用于任何內(nèi)存或任何工具鏈的通用API（c）他們的工具必須控制邏輯內(nèi)存到BRAMs的映射，因為他們沒有足夠的信息來確定Xilinx工具如何將邏輯內(nèi)存映射到物理內(nèi)存。

類似地，Xilinx Vivado提供了對更改比特流中配置存儲器初始值的支持，主要是為了支持微LAZE處理器的指令存儲器［26］。這包括一個BRAM內(nèi)存映射信息（MMI）文件，該文件記錄用于支持MicroBlaze和Xilinx參數(shù)化宏（XPM）內(nèi)存的物理BRAM，以及一個UpdateMEM工具，該工具可以使用邏輯內(nèi)存文件中的數(shù)據(jù)更新比特流［27］。Vivado生成的MMI并沒有覆蓋設(shè)計中的所有邏輯內(nèi)存，UpdateMEM只生成一個完整的比特流。

XBERT通過提供對比特流讀寫路徑的開源邏輯級訪問，填補了上述相關(guān)工作中的所有空白。它容納了所有的設(shè)計，所有的記憶，以及所有通過DCPs的工具流。

》4.4 現(xiàn)有的比特流操作支持

有許多工具可用于創(chuàng)建比特流操作工具。XBERT系統(tǒng)在一定程度上是基于其中一些。

Xilinx工具長期以來一直為內(nèi)存生成邏輯位置（LL）文件，作為比特流回讀生成的一部分［28］。LL文件包含物理BRAM中每個數(shù)據(jù)位的幀和位位置，但不提供有關(guān)邏輯內(nèi)存以及如何將邏輯內(nèi)存映射到多個物理BRAM塊的映射信息。盡管如此，LL文件對于破譯XBERT內(nèi)的BRAM的幀和位位置是有用的，如圖1所示。

X-Ray項目［29］和最近的U-Ray項目［30］提供了將Xilinx 7系列和UltraScale+設(shè)備中的配置位映射到幀和位位置的數(shù)據(jù)庫。它們不包含特定設(shè)計中邏輯到物理內(nèi)存映射的信息，但提供了用于比特流編碼的信息和工具（了解比特流中物理內(nèi)存位的位置）。

在X-Ray項目的基礎(chǔ)上，BYU開發(fā)了一個開源工具prjxray-bram-patch［31］，它的作用與Vivado的UpdateMEM類似，但適用于設(shè)計中的所有邏輯內(nèi)存和所有設(shè)計流。bram-patch工具定義了一個內(nèi)存描述數(shù)據(jù)（MDD）文件，該文件的作用與Xilinx MMI文件類似。MDD文件源自使用Tcl的Vivado設(shè)計，它為設(shè)計中的每個邏輯內(nèi)存描述了邏輯內(nèi)存映射到的物理內(nèi)存集合、邏輯內(nèi)存位在物理內(nèi)存之間的分區(qū)方式以及位如何打包到物理RAMB原語的INIT字符串中。XBERT系統(tǒng)將此信息用作邏輯到物理映射步驟的一部分（圖1）。

5. XBERT API

XBERT設(shè)計用于在Zynq SoC上的嵌入式APU內(nèi)核上運行。如圖2所示，它提供了邏輯級接口，高于由xilfpga提供的接口或由諸如BITMAN的物理級比特流操作工具提供的接口［24］。它通過擴展xilfpga來實現(xiàn)這一點，并為BRAM寫入提供部分重新配置支持和命令生成（第六節(jié)）。

圖2:XBERT的API分層

注：Xilinx提供的淺紅色；本工程提供淺藍色；來自［24］的淺綠色。

入門級XBERT接口是一對簡單的例程，提供一個類似DMA的接口來讀取或?qū)懭胝麄€邏輯內(nèi)存。

這些例程處理內(nèi)存的幀格式和邏輯格式之間的位洗牌，以及執(zhí)行所需的部分重新配置讀寫。

為了支持這些API調(diào)用，XBERT預(yù)處理工具處理MDD文件（第IV-D節(jié)）生成文件mydesign.h和mydesign.c（圖1）。其中包括設(shè)計中特定內(nèi)存的C代碼定義，包括邏輯到物理的轉(zhuǎn)換表。

上述簡單API的一個限制是，每個讀或?qū)懻{(diào)用首先執(zhí)行邏輯到物理內(nèi)存的轉(zhuǎn)換，然后對設(shè)備執(zhí)行比特流讀或?qū)懖僮鳌Ｈ绻麘?yīng)用程序需要讀取或更新映射到同一配置幀的多個不同邏輯內(nèi)存，則這可能是低效的。

為了實現(xiàn)更高效的傳輸，XBERT還提供了一個API，可以讀寫一組多個內(nèi)存，就像分散-聚集DMA操作一樣。這是bert_transfuse（）調(diào)用，允許XBERT執(zhí)行一組幀讀取、轉(zhuǎn)換，然后執(zhí)行一組幀寫入，覆蓋可能共享一組幀的所有邏輯內(nèi)存：

Bert_transfuse例程使用一個數(shù)組來描述邏輯內(nèi)存集合上的操作。為了描述每個transfusion操作，它使用了一個結(jié)構(gòu)（bert_meminfo）。結(jié)構(gòu)指定了內(nèi)存、操作（讀或?qū)懀┮约拔覀冋趦?nèi)存中讀或?qū)懙倪壿嫷刂贩秶?。為了支持?4b更寬的數(shù)據(jù)，這支持一個數(shù)組，每個數(shù)組槽有多個數(shù)據(jù)字。并且，通過指定起始地址和長度，我們允許對邏輯內(nèi)存中的字子集進行操作。這允許訪問和更新與保存邏輯存儲器的數(shù)據(jù)的BRAMs相關(guān)聯(lián)的幀的子集，當(dāng)僅需要讀取或?qū)懭氪鎯ζ鞯囊徊糠謺r，這是更有效的。傳輸操作還將寫入數(shù)據(jù)集與PCAP控制指令一起排列，以便可以使用單個DMA寫入傳輸來執(zhí)行這些操作，從而最小化DMA設(shè)置的開銷。

APIs假定執(zhí)行讀寫操作是安全的。應(yīng)用程序負責(zé)將計算置于安全狀態(tài)，即在讀或?qū)戇^程中不寫入內(nèi)存。例如，使用Vivado/VitisHLS生成的標(biāo)準Xilinx IP塊級接口協(xié)議［32］，可以監(jiān)視要完成的塊（ap_done），執(zhí)行XBERT操作，然后重新啟動模塊（ap_start）。

6. 部分重構(gòu)

部分重配置是在不影響剩余資源運行的情況下加載一部分FPGA資源的配置數(shù)據(jù)。在現(xiàn)代Xilinx設(shè)備中，配置的原子單元是沿FPGA列組織的幀。在Xilinx UltraScale+系列中，每幀有93個32b字。由于BRAM數(shù)據(jù)只占總比特流的一小部分，因此使用部分重新配置僅訪問BRAM幀與完整的比特流讀寫相比減少了比特流讀寫時間。

在現(xiàn)代FPGA設(shè)備中，嵌入式ram被放置在列中。UltraScale+系列具有36Kb內(nèi)存（RAMB36），每個內(nèi)存可以交替配置為一對18Kb內(nèi)存（RAMB18）。Xilinx UltraScale+系列設(shè)備中的每個幀包含12個RAMB36存儲器［33，第8章，配置幀］，每個RAMB36具有144b，兩個RAMB18中的每個具有72b。覆蓋BRAM組需要256幀（參見圖3）。幀中每個BRAM的144b組被分組為240b塊。在大致位于240b塊中間的幀中，每個144b RAMB36組有一個寫使能位。寫入允許一次更新單個BRAM36，但始終需要以幀為單位傳輸數(shù)據(jù)。BRAM數(shù)據(jù)幀與保持路由或LUT配置的幀是分開的。

Zynq設(shè)備包括一個處理器配置訪問端口（PCAP），允許嵌入式處理器讀寫配置幀。對于高速接入，處理器可以配置DMA數(shù)據(jù)傳輸?shù)絇CAP以執(zhí)行部分重新配置操作。UltraScale+PCAP的帶寬為4B，峰值工作頻率為200 MHz，最高支持800 MB/s［33，第8章，配置時間］。

Xilinx提供了xilfpga庫［34］（圖2），用于在Zynq UltraScale+組件上執(zhí)行DMA比特流傳輸。它允許對包含到PCAP的控制命令頭的.bit文件進行完全比特流加載、回讀和部分比特流加載。

圖3:UltraScale+BRAM內(nèi)容的框架組織

XBERT提供了xilfpga API中例程的擴展版本（圖2）。xilfpga沒有提供一個基本的比特流回讀操作，因此我們修改了讀操作以同時接收幀地址和幀數(shù)。XBERT還提供了write的一個版本，它接受原始幀數(shù)據(jù)并填充配置命令來設(shè)置幀地址和指定寫操作，因為將原始幀數(shù)據(jù)轉(zhuǎn)換為適當(dāng)?shù)牟糠直忍亓餍枰@些命令。這種擴展是支持寫操作所必需的，因為我們正在生成自己的幀集，并且沒有通常由Vivado生成比特流時生成的比特流配置命令頭。

由于缺乏流量控制，F(xiàn)PGA讀回操作只能以低于200 MHz峰值操作（秒）的速率可靠運行（第六節(jié)。2019.2 xilfpga版本中的默認配置使用PCAP時鐘發(fā)生器配置（PCAP _CTRL（CRL _APB）寄存器）將時鐘設(shè)置為23.8 MHz，最高吞吐量為95 MB/s。我們的經(jīng)驗表明，150MHz可能工作可靠，最高吞吐量為600MB/s。

7. 壓縮轉(zhuǎn)換表

邏輯到物理轉(zhuǎn)換表（第三節(jié)） 可能很大。如果我們簡單地在一個BRAM中為每個位存儲一個32b幀地址和一個16b位位置，那么轉(zhuǎn)換表至少是48位× 比我們希望繪制的BRAM數(shù)據(jù)總量還要大。幸運的是，有一些結(jié)構(gòu)。通常情況下，當(dāng)多個位在同一幀中時，我們不需要為每個位存儲幀。這樣可以節(jié)省3倍。

為了進一步壓縮，我們利用了位位置在幀間重復(fù)的方式。為了說明這一點，我們先來考慮一個簡單的BRAM設(shè)計案例。單個幀將在其144位中保存一定數(shù)量的邏輯字。在72b寬的邏輯存儲器的情況下，這可以是2個邏輯字；對于8b寬的邏輯內(nèi)存，這可能是16個邏輯字。將Wframe定義為該值（上面的2或16）。對于每個連續(xù)的Wframe字組，幀內(nèi)的偏移位置是相同的，這允許我們通過算法確定幀偏移量（邏輯地址/Wframe），并重用幀內(nèi)（最多144）位到幀內(nèi)偏移量的單個位映射。對于這種單BRAM設(shè)計，這意味著我們只需要存儲一個幀地址（基址）和（最多）144位偏移地址（對于一幀中的2976位可以使用12b，但是我們舍入到16b）。所以，我們最多需要32+144×16=2336b而不是48×36864=1.7 Mbits，無壓縮。

一般來說，我們必須支持邏輯內(nèi)存映射到物理內(nèi)存的各種方法。這可能意味著并行組織多個BRAMs以支持邏輯字寬度（例如，8個BRAMs，每個BRAMs提供32b字的4b），多個BRAMs覆蓋不同的地址范圍以處理深度內(nèi)存（例如，2個BRAMs覆蓋36x2048內(nèi)存，其中一個處理地址0到1023，另一個處理地址1024到2047），或其組合。甚至在某些情況下，組件BRAMs具有不均勻的子寬度和子深度（例如第三節(jié)） 是的。因此，一般的壓縮情況更需要處理這些額外的不規(guī)則性。盡管如此，幀之間還是有規(guī)律性的，可以用算法來描述。這使我們能夠概括單個BRAM觀測值，形成一個通用的壓縮策略。利用這些觀察，我們顯著地壓縮了翻譯表（表3）。

8. 加速翻譯

正如我們在表4中看到的，一旦我們加快了讀DMA的速度，翻譯時間就比DMA傳輸時間慢。即使使用預(yù)編譯的表，代碼仍然是一次提取和插入一位。我們實現(xiàn)了一種多位加速轉(zhuǎn)換，其中我們預(yù)先計算字（或幀）中的位序列（例如，一個字節(jié)）的影響，以創(chuàng)建要應(yīng)用于幀（或字）的位向量，并將它們存儲在表中。

這減少了處理器周期，但需要更大的轉(zhuǎn)換表。我們目前的實現(xiàn)支持這些針對單個BRAM存儲器的轉(zhuǎn)換表。

9. 評價

如第三章和貫穿本文的重點，XBERT傳輸?shù)拇笮『托阅芨叨纫蕾囉谠O(shè)計，依賴于API的使用，并且受到我們的優(yōu)化的影響。在本節(jié)中，我們將評估API在多個場景中的性能，以具體描述這些不同場景的性能影響。

》9.1 方法論

我們的實驗使用Vivado 2018.3，包括SDK。嵌入式ARM處理器代碼編譯-O3。實驗在Ultra96 v2板上進行，該板包括一個包含216個RAMB36的XCZU3EG。設(shè)計是在裸機配置上運行的。我們集成了2019.2版的xilfpga源代碼，原因是2018.3版的xilfpga存在缺陷。

一個主要的性能指標(biāo)是有效吞吐量。有效吞吐量解釋了這樣一個事實，即有用的數(shù)據(jù)只是在幀中傳輸?shù)臄?shù)據(jù)的子集。例如，如果我們只想在UltraScale+設(shè)備幀中包含一個RAMB36的內(nèi)容，則每幀可獲得144個相關(guān)位，但必須傳輸整個2976位幀。

為了說明典型的應(yīng)用場景，我們提供了兩個完整的設(shè)計。這些給出了幀如何從多個邏輯存儲器共享BRAMs的一些指示。

哈夫曼編碼-我們的Verilog設(shè)計來自第三章F節(jié)。它有4個邏輯內(nèi)存，消耗4個18和3903個LUT。每個邏輯內(nèi)存都可以放在一個內(nèi)存中。

翻譯-演示用的網(wǎng)表來自于Rosetta HLS基準電路 ［35］。它有11個邏輯存儲器，消耗41個ramb36、9個ramb18和11109個LUTs。一些內(nèi)存是大的，需要很多的BRAMs。有些內(nèi)存在沒有定義位的地方有間隙。

》9.2 結(jié)果

① 原始比特流數(shù)據(jù)傳輸

表2顯示原始比特流傳輸時間和原始有效吞吐量。這將顯示DMA傳輸性能和含義，而不需要翻譯所需的時間，這將在下一節(jié)中分開。注意，訪問一個幀中的所有BRAM（單個BRAM幀集行）可以提供最高的有效吞吐量。由于BRAM幀中的大多數(shù)位是BRAM數(shù)據(jù)位，因此有效帶寬超過原始帶寬的一半。請注意，即使我們關(guān)心芯片上所有BRAM中的每一位BRAM，該有效帶寬也高于完整的比特流讀寫，因為部分讀取只是讀取保存BRAM數(shù)據(jù)的幀。

表2:XCZU3EG上的原始比特流讀寫時間

注：“幀集”是包含單個BRAM的內(nèi)容的256幀的集合（圖3）。

24MHz是xilfpga中的讀取速度；150MHz是我們能夠可靠運行DMA回讀的最高速度。

② 翻譯

表III報告了轉(zhuǎn)換表的大小和時間，以及在邏輯和框架表示之間進行轉(zhuǎn)換的有效吞吐量。

表3:XCZU3EG上的翻譯時間

表III表明我們可以將大約兩個數(shù)量級的轉(zhuǎn)換表縮減到千字節(jié)范圍內(nèi)（第七節(jié)）。壓縮會稍微減慢翻譯速度。加速度（第八節(jié)） 大約減半翻譯時間，同時添加大約與未壓縮表一樣大的表。在渲染的11個內(nèi)存中，有7個是單BRAM內(nèi)存，但是這些內(nèi)存只占4%的位，所以在轉(zhuǎn)換所有內(nèi)存時，加速的影響很小。

③ BERT API操作

單內(nèi)存：表4總結(jié)了讀寫一篇簡單的文章的表現(xiàn)×64個內(nèi)存，填充一個36塊。第一行顯示默認的讀取速度（第六節(jié)） 第二個顯示了將PCAP DMA讀取速度提高到150mhz（600MB/s）的影響。第三行顯示壓縮的影響；在這種情況下，它會稍微減慢翻譯速度。第四行顯示了加速度的影響，這大約是平移時間的一半。

表4：基于XZCU3EG的BERT-API單RAM36性能

注：24MHz是xilfpga中的讀取速度；150MHz是我們能夠可靠運行DMA回讀的最高速度。

接下來的三行（標(biāo)記為“Frameset”）查看傳輸共享同一幀集的所有12個內(nèi)存。第一種情況捕獲對每個內(nèi)存執(zhí)行分離 bert_read和bert_write操作的總時間；這大約需要12倍于單個BRAM情況的時間，因為它只是單個時間的總和，并且實現(xiàn)了相同的帶寬。中間一行使用bert_transfuse在一次操作中讀取或?qū)懭胨?2個存儲器；結(jié)果，DMA傳輸時間與每個BRAM讀取中的傳輸時間相當(dāng)，而轉(zhuǎn)換時間幾乎是12倍，因為每個存儲器必須單獨轉(zhuǎn)換。由于DMA傳輸時間與單個RAMB36讀寫中的轉(zhuǎn)換時間大致相當(dāng)，因此這將導(dǎo)致大約兩倍的凈吞吐量。幀集的最后一行顯示了執(zhí)行單個傳輸操作的影響，該操作同時讀取和寫入所有內(nèi)存。

表中的最后一行顯示從RAMB36中讀寫一幀（兩個64b字）。這比讀或?qū)懻麄€記憶和翻譯所有的框架要花更少的時間。這里的翻譯時間可以很短。然而，由于在設(shè)置DMA操作時有相當(dāng)多的固定時間，因此凈吞吐量很低。

④ BERT API操作

應(yīng)用層：單個BRAM和所有BRAM在Tab中的幀集cases中的轉(zhuǎn)換，在表4中預(yù)期典型表現(xiàn)。表5表示當(dāng)我們讀取或?qū)懭胨写鎯ζ鲿r應(yīng)用程序的透析性能。哈夫曼展示了一個2-3×透析操作的改進。渲染幾乎沒有什么好處，在轉(zhuǎn)換的情況下，轉(zhuǎn)換需要更多的時間，這可能是由于緩存效果對于容納所有內(nèi)存所需的大幀內(nèi)存造成的。由于主導(dǎo)時間通常是在翻譯中，所以在讀寫數(shù)據(jù)時，總輸入時間基本上是線性的。

表5：基于XZCU3EG的BERT-API應(yīng)用性能

注：150MHz是我們能夠可靠運行DMA回讀的最高速度。

10. 結(jié)論

現(xiàn)代FPGA上的配置路徑提供了對嵌入式存儲器的訪問。就FPGA資源而言，它是一個輕量級接口，用于從嵌入式存儲器中獲取數(shù)據(jù)。XBERT提供了一個用戶級API，使應(yīng)用程序開發(fā)人員可以輕量級地使用此功能。使用XBERT訪問邏輯內(nèi)存就像API調(diào)用一樣簡單。這有助于在程序啟動時加載初始內(nèi)存狀態(tài)，在程序完成、調(diào)試時恢復(fù)最終數(shù)據(jù)和狀態(tài)，以及在FPGA結(jié)構(gòu)和嵌入式內(nèi)核之間進行不頻繁的數(shù)據(jù)傳輸。XBERT API負責(zé)邏輯到物理的轉(zhuǎn)換，包括壓縮必要的轉(zhuǎn)換信息和最小化必須傳入和傳出FPGA的數(shù)據(jù)的優(yōu)化。XBERT工具流自動生成API所需的翻譯信息。