白皮書
PCIe 數據採集
概述
高解析度感測器可以生成需要FPGA預處理的數據速率，以將其輸出降低到主機可以捕獲和處理的輸出。如果後FPGA數據速率超過約40 Gb/秒，則將該數據移動到主機需要專門的解決方案。
BittWare具有靈活的 架構概念 ，可以靈活地滿足客戶IP的需求並降低成本。
本白皮書涵蓋了BittWare高速數據採集和記錄器概念的數據捕獲元件。我們將介紹一些用於通過PCIe總線實現持續100 Gb/s 捕獲到主機 DDR4 的技術。
PCIe 數據採集的架構目標
該概念的目標是從 FPGA到主板中實現100 Gb/s ，客戶可以使用許多CPU內核處理數據。它通過PCIe和CPU將數據從FPGA卡移動到主機 DDR4。有一些可選元件可以記錄到持久記憶體（需要專用 CPU 來完成此任務），並添加第二個 PCIe，用於使用兩個 CPU 捕獲 200 Gb/s 到 DDR4。
BittWare Developer 網站上為使用 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/秒 （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 byes，原因將在後面討論。
在 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 區域。
Data Capture 的第一個版本位於 Xilinx XDMA 之上。第二個版本將過渡到我們自己的DMA傳輸，分層在Xilinx QDMA的橋接模式之上。
主機控制
我們的PCIe數據採集概念使用標準的Linux VFIO驅動程式。這使 CPU 的虛擬化硬體能夠提供進程保護和安全性。我們提供了一個 Python API 來控制卡片。我們使用 Python 程式將描述符載入到 FPGA 中，設置 DRAM 佇列，並啟動應用程式代碼。BittWare的工具包目前不支援VFIO作為驅動程式，但計劃在未來提供支援。
申請處理
BittWare在主機端的處理框架以 DPDK（數據平面開發工具包）為模型。我們在主機上使用單個目標佇列。專用內核分析傳入的 MBUF，將 MBUF 指標發送到工作線程集合。專用內核可以在任何 MBUF 大小下執行此任務。
我們計劃發佈範例工作程式，將內部數據結構重新格式化為 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的社交媒體渠道，瞭解最新出版物。
還有更多內容需要閱讀：獲取數據採集應用說明
請求 PDF 下載
您在此頁面上看到的是BittWare數據捕獲的介紹 。完整的應用說明中還有更多細節！填寫表格以請求訪問完整應用筆記的PDF版本。
“*”表示必填欄位
