白皮書
PCIe 數據採集
概述
高解析度感測器可以產生需要FPGA預處理的數據速率，以將其輸出減少到主機可以捕獲和處理的內容。如果後 FPGA 數據速率超過約 40 Gb/秒，則將該數據移動到主機需要專門的解決方案。
BittWare具有 靈活的架構概念 ，可以靈活地滿足客戶的IP需求並降低成本。
本白皮書涵蓋了BittWare高速數據採集和記錄器概念的數據採集元件。我們將介紹一些用於通過PCIe總線將100 Gb/s持續捕獲到主機 DDR4 的技術。
PCIe 數據採集的架構目標
這一概念的目標是從 FPGA中實現100 Gb/s的速度，並進入主機板 ，客戶可以使用許多CPU內核處理該數據。它將數據從 FPGA 卡通過 PCIe 和 CPU 放在主機 DDR4。有一些可選元件可以記錄到持久記憶體（需要專用 CPU 才能完成此任務），並添加第二個 PCIe，以便使用兩個 CPU 將 200 Gb/s 捕獲到 DDR4。
數據採集概念可在 BittWare 開發人員網站上 為使用基於 Xilinx 的產品的客戶提供。它消耗 Xilinx Virtex UltraScale+ VU9P FPGA 的 12%。對於客戶來說，將專案改編為另一個BittWare UltraScale+卡相對容易。BittWare計劃將此IP移植到Intel Agilex和Achronix SpeedSter7t FPGA中。
請求應用說明
需要比本白皮書 提供的更多詳細資訊 ？索取應用說明，其中提供了有關我們的數據採集概念的文檔。 點擊這裡 >>
我們如何實現 100 Gb/s PCIe 數據採集
PCIe理論與實踐
理論上，PCIe Gen 3 每條通道可以傳輸 985 MB/s。對於 16 倍，這意味著每個方向為 15.760 GB/s（126 Gb/s），遠遠超過我們的 100 Gb/s 目標。但是，沿路徑有協定層和緩衝區管理層。一篇探討這個問題的優秀學術論文是Rolf Neugebauer的《瞭解終端主機網路的PCIe性能》。
在實踐中，BittWare的PCIe數據採集能夠將12.8 GB / s（102 Gb / s）從FPGA推送到主機DRAM。這剛剛超過PCIe理論最大傳送速率的80%。
PCIe傳輸在實踐中的現實情況要低得多，並且對用於優化系統的特定方法有很大影響。實現 100 Gb/s 實際上是強調 PCIe 的好方法 — 對於非常大的數據包大小，100 Gb 乙太網 （GbE） 接近 12.5 GB/s，為元數據留出了 300 MB/s 的餘量。但是，當飽和的 100 GbE 由所有微小數據包組成時，總體數據速率要低得多，但 PCIe 總線事務的數量可能會增加，從而以不同的方式給 PCIe 帶來壓力。
我們使用乙太網來代替BittWare客戶常用的專有感測器。我們的解決方案可以傳遞大數據包和小數據包，而不會丟棄任何數據包。接下來，我們將解釋我們是如何做到的。
實現第1部分：優化主機
當通過PCIe推送高頻寬數據時，一種優化實際上不是在FPGA內部，而是在 主機的軟體端。查看 CPU 的內部體系結構。
為了實現我們的性能目標，位於晶元的PCIe介面和DRAM介面之間的 每個CPU內核 都必須 以全時鐘速度運行（無省電模式），即使該內核不執行其他工作。換句話說，每個 CPU 內核都需要處於 C 狀態為零，P 狀態為零。在Linux中，實現此目的的一種方法是使用“tuned-adm”命令並選擇其“延遲性能”選項。
實施部分 2：優化 PCIe
通過整合優化PCIe事務
FPGA方面最重要的是最大限度地減少通過總線移動數據所需的 PCIe事務數 。這意味著將多個數據包整合到 一個緩衝區管理方案 中，該方案旨在允許每個PCIe事務實現系統協商的「最大有效負載」大小，在基於Intel的現代系統中通常為256位元組。
因此，BittWare產品的主要功能是執行此整合功能。 我們將數據包合併到 一個固定大小的緩衝區中，我們稱之為MBUF。
MBUF 大小可以在 FPGA 初始化時更改。正如我們所說，MBUF 必須是PCIe最大有效負載大小的固定倍數。我們建議使用 4k 再見，原因將在後面討論。
在 FPGA 處理中，將數據包分組以通過單獨的控制線程進行處理是很常見的。我們將這些分組稱為「佇列」，每個佇列都需要流向主機端的不同處理核心。因此，數據包合併需要基於每個佇列進行。
我們的合併函數是用HLS編寫的，它運行在我們接下來討論的佇列管理函數之上。
主機佇列
我們的IP將其MBUF流發送到主機DRAM。像其他所有這樣做的人一樣，我們在 DRAM 中使用迴圈佇列。但是，在 Xilinx 上，我們不使用 QDMA 佇列，而是在 QDMA 的橋接功能之上創建自己的替代方案。
Xilinx QDMA 佇列基於 RDMA 數據結構。RDMA 是一個比我們需要的更動態的環境。我們的版本具有描述符環，但是我們的主機驅動程式在 FPGA 初始化時載入描述符，我們重用它們。這樣做 可以避免在運行時通過PCIe發送描述符。此外，作為更大的偏差， 我們沒有完成佇列。相反，我們只是重用描述符，讓主機軟體確定FPGA移動數據的速度是否快於主機處理該數據的速度。換句話說，我們不是在FPGA中丟棄數據，而是 在主機上丟棄數據。在 RDMA 術語中，主機驅動程式從不將 CIDX 更新發送到 FPGA。
我們的佇列實現 在主機端使用輪詢，而不是中斷。這是因為中斷會消耗更多的PCIe頻寬，因為 FPGA 需要以這兩種方法向主機發送 PIDX 更新。實驗表明，使用現代CPU，PIDX更新需要在傳輸總計4k位元組的MBUF序列後進行。這就是為什麼我們建議只製作單個 MBUF 4k 位元組的原因。
在主機端，我們允許佇列描述元指向大頁面。這樣做可以最大限度地減少 CPU TLB 未命中。根據 FPGA 卡的位置，我們還可以在特定的主機 NUMA 區域中分配我們的大頁面，以控制相對於主機處理線程的 FPGA DMA 傳輸的路由，這些線程也被鎖定到特定的 NUMA 區域。
第一版 數據採集 位於 Xilinx XDMA 之上。第二個版本將過渡到我們自己的 DMA 傳輸，該傳輸層高於 Xilinx QDMA 的橋接模式。
主機控制
我們的 PCIe 數據採集概念使用標準的 Linux VFIO 驅動程式。這使 CPU 的虛擬化硬體能夠提供進程保護和安全性。我們提供了一個Python API來控制卡。我們使用Python程式將描述符載入到FPGA中，設置DRAM佇列，並啟動應用程式代碼。BittWare的工具包目前不支援VFIO作為驅動程式，但計劃在未來提供支援。
申請處理
BittWare在主機端的處理框架以 DPDK（數據平面開發套件）為藍本。我們在主機上使用單個目標佇列。專用內核解析傳入的MBUF，將MBUF指標發送到工作線程的集合。專用內核可以在任何 MBUF 大小下執行此任務。
我們計劃發佈範例 worker 程式，將我們的內部數據結構重新格式化為 PCAPng 格式。對於任何數據包大小，重新格式化都需要大約四個工作線程核心才能跟上 100 GbE 的線速。
PCIe 數據採集架構概念的其他選項
該概念有兩個可選元件，一個向SSD添加錄製元素，另一個使用XUP-P3R具有第二個PCIe介面的功能，以允許高達200 Gb / s的捕獲。
100 Gb/s 記錄
使用雙插槽主機板，可以記錄100 GbE數據包流。BittWare IP將數據包捕獲到連接到其中一個套接字的主機DRAM中。 然後，應用程式軟體將 MBUF 透過處理器插槽之間的 QPI 鏈路移動到連接到另一個 CPU 插槽上的 PCIe 的 RAID 0 NVMe 中。未來的白皮書將解釋如何做到這一點。總之，需要的 NVMe 驅動器比您想像的要多得多。這是因為流行的TLC SSD的NVme驅動器數據表傾向於指定其偽SLC緩存的寫入性能。溢出緩存和寫入性能會急劇下降。最新的QLC SSD實際上可能比老式磁碟技術在長時間，無休止的流式寫入中更慢！
200 Gb/s 通過雙PCIe
通過在帶有兩個 CPU 的 TeraBox 中添加第 3 個插槽附加卡，XUP-P3R 可以通過兩個 Gen3 x16 PCIe 介面實現 200 Gb/s 的速率！
雙 PCIe 數據採集
對於需要超過 100 Gb/s 捕獲的客戶，另一種選擇是使用 XUP-P3R 的 SEP 到 PCIe 附加卡。這可以實現高達約200 Gb / s的主機記憶體。第二個連接進入相鄰的PCIe插槽。請注意，此選項將消耗第二個CPU，但不能同時以行速率記錄到持久記憶體。
客戶還可以在具有兩個或更多CPU的主機板上使用兩個FPGA卡。
結論
如今的感測器速度越來越快，這導致了兩個CPU挑戰。首先將 I/O 輸入 CPU，然後將感測器資料轉換為可操作的資訊。FPGA通常用於通過硬體預處理來縮小這一差距，但是即使減少的數據量也足以在許多情況下仍然給CPU帶來壓力。
在本白皮書中，我們研究了如何最大化PCIe頻寬以捕獲高達100 Gb/s的速率，包括使用CPU捕獲到DRAM。這仍然有可能給CPU帶來壓力，因此在下一份白皮書中，我們將完全繞過CPU直接記錄到NVMe。
BittWare正在利用其多年的經驗幫助客戶將數據壓縮到CPU中，以生成架構概念來解決這些問題。有了這些，以及通過利用BittWare廣泛的FPGA卡和集成伺服器產品群組進行大規模部署的能力，客戶可以很容易地為特定用例構建數據採集和記錄器設備。關注BittWare的社交媒體渠道，隨時瞭解最新出版物。
還有更多內容可供閱讀：獲取數據採集應用說明
請求下載
您在此頁面上看到的是BittWare數據採集的介紹 。完整的應用程式說明中還有更多詳細資訊！填寫表單以請求訪問完整 App Note 的 PDF 版本。
“*”表示必填欄位
