Hochauflösende Sensoren können Datenraten erzeugen, die eine FPGA-Vorverarbeitung erfordern, um ihre Ausgabe auf etwas zu reduzieren, das ein Host-Computer erfassen und verarbeiten kann. Wenn die Post-FPGA-Datenrate etwa 40 Gb/s übersteigt, erfordert die Übertragung dieser Daten in den Host-Computer spezielle Lösungen.
BittWare verfügt über architektonische Konzepte, die flexibel auf die Bedürfnisse der IP des Kunden abgestimmt sind und die Kosten reduzieren.
Dieses Whitepaper befasst sich mit der Datenerfassungskomponente von BittWares High-Speed Data Capture und Recorder-Konzepten. Wir erläutern einige der Techniken, die verwendet werden, um eine anhaltende 100 Gb/s-Erfassung in Host-DDR4 über einen PCIe-Bus zu erreichen.
Das Ziel dieses Konzepts ist es, 100 Gb/s aus dem FPGA in ein Motherboard zu bringen, wo die Kunden diese Daten mit vielen CPU-Kernen verarbeiten können. Es überträgt Daten von der FPGA-Karte über PCIe und die CPU zum DDR4-Host. Es gibt optionale Komponenten für die Aufzeichnung im persistenten Speicher (was eine dedizierte CPU für diese Aufgabe erfordert) und das Hinzufügen eines zweiten PCIe-Anschlusses für die Erfassung von 200 Gb/s auf DDR4 mit zwei CPUs.
Das Data Capture Konzept ist auf der BittWare Developer Website für Kunden mit Xilinx-basierten Produkten verfügbar. Es verbraucht 12% des Xilinx Virtex UltraScale+ VU9P FPGA. Die Anpassung des Projekts an eine andere BittWare UltraScale+ Karte ist für Kunden relativ einfach zu bewerkstelligen. BittWare plant, diese IP auf Intel Agilex und Achronix SpeedSter7t FPGAs zu portieren.
Benötigen Sie noch mehr Details als in diesem Whitepaper beschrieben? Fordern Sie die App Note an, die die Dokumentation für unser Data Capture-Konzept enthält. Klicken Sie hier >>
Theoretisch kann PCIe Gen 3 985 MB/s pro Lane übertragen. Bei 16x bedeutet das 15,760 GB/s (126 Gb/s) in jeder Richtung - also weit mehr als die angestrebten 100 Gb/s. Es gibt jedoch Protokollschichten und Puffermanagement entlang des Pfades. Ein ausgezeichnetes akademisches Papier, das dies untersucht, ist Understanding PCIe performance for end host networking von Rolf Neugebauer.
In der Praxis konnte die PCIe-Datenerfassung von BittWare 12,8 GB/s (102 Gb/s) vom FPGA in den Host-DRAM übertragen. Das sind etwas mehr als 80 % der theoretischen maximalen Übertragungsgeschwindigkeit von PCIe.
Die tatsächliche PCIe-Übertragung ist in der Praxis viel geringer und hängt stark von dem jeweiligen Ansatz zur Optimierung des Systems ab. Das Erreichen von 100 Gbit/s ist eigentlich ein guter Weg, um PCIe zu belasten - bei sehr großen Paketen erreicht 100 Gb Ethernet (GbE) 12,5 GB/s und lässt 300 MB/s Spielraum für Metadaten. Wenn jedoch ein gesättigtes 100 GbE aus lauter kleinen Paketen besteht, ist die Gesamtdatenrate viel niedriger, aber die Anzahl der PCIe-Bustransaktionen kann steigen, wodurch PCIe auf andere Weise belastet wird.
Wir verwenden Ethernet als Ersatz für die proprietären Sensoren, die BittWare-Kunden üblicherweise verwenden. Unsere Lösung kann sowohl große als auch kleine Pakete weiterleiten, ohne sie zu verwerfen. Als nächstes werden wir erklären, wie wir das gemacht haben.
Wenn Daten mit hoher Bandbreite über PCIe übertragen werden, liegt eine Optimierung nicht im FPGA, sondern auf der Softwareseite des Hosts. Sehen Sie sich die interne Architektur der CPU an.
Um unser Leistungsziel zu erreichen, muss jeder CPU-Kern, der sich zwischen der PCIe-Schnittstelle des Chips und der DRAM-Schnittstelle befindet, mit voller Taktfrequenz laufen (kein Stromsparmodus), auch wenn dieser Kern keine andere Arbeit verrichtet. Anders ausgedrückt: Jeder CPU-Kern muss sich im C-Zustand Null und im P-Zustand Null befinden. Unter Linux lässt sich dies unter anderem mit dem Befehl "tuned-adm" und der Option "latency-performance" erreichen.
Auf der FPGA-Seite kommt es vor allem darauf an, die Anzahl der PCIe-Transaktionen zu minimieren, die erforderlich sind, um die Daten über den Bus zu übertragen. Dies bedeutet, dass mehrere Pakete in einem Pufferverwaltungsschema konsolidiert werden, das so konzipiert ist, dass jede PCIe-Transaktion die vom System ausgehandelte "Maximum Payload"-Größe erreichen kann, in der Regel 256 Byte in modernen, Intel-basierten Systemen.
Eine primäre Funktion des BittWare-Angebots besteht also darin, diese Konsolidierungsfunktion auszuführen. Wir konsolidieren die Pakete in einem Puffer fester Größe, den wir MBUF nennen.
Die MBUF-Größe kann bei der FPGA-Initialisierung geändert werden. Wie wir bereits erwähnt haben, muss der MBUF ein festes Vielfaches der maximalen PCIe-Nutzlastgröße sein. Wir empfehlen die Verwendung von 4k Byes aus einem Grund, der später erläutert wird.
Bei der FPGA-Verarbeitung ist es sehr üblich, Pakete für die Verarbeitung durch separate Threads der Steuerung zu gruppieren. Wir nennen diese Gruppierungen "Warteschlangen", und jede Warteschlange muss zu einem anderen Verarbeitungskern auf der Host-Seite fließen. Die Konsolidierung der Pakete muss also auf der Basis der einzelnen Warteschlangen erfolgen.
Unsere Konsolidierungsfunktion ist in HLS geschrieben und läuft über einer Funktion zur Verwaltung von Warteschlangen, die wir im Folgenden besprechen.
Unser IP sendet seinen Strom von MBUFs in den Host-DRAM. Wie alle anderen, die dies tun, verwenden wir zirkuläre Warteschlangen im DRAM. Bei Xilinx verwenden wir jedoch nicht die QDMA-Warteschlangen, sondern erstellen unsere eigene Alternative über die Überbrückungsfunktion von QDMA.
Die QDMA-Warteschlangen von Xilinx basieren auf RDMA-Datenstrukturen. RDMA ist eine dynamischere Umgebung als wir brauchen. Unsere Version hat Deskriptor-Ringe, aber unser Host-Treiber lädt die Deskriptoren zur FPGA-Initialisierungszeit und wir verwenden sie wieder. Auf diese Weise wird das Senden von Deskriptoren über PCIe zur Laufzeit vermieden. Eine noch größere Abweichung ist, dass wir keine Warteschlangen für die Fertigstellung haben. Stattdessen verwenden wir nur Deskriptoren wieder und lassen die Host-Software herausfinden, ob das FPGA Daten schneller bewegt, als der Host diese Daten verarbeiten kann. Anders ausgedrückt: Anstatt Daten im FPGA abzulegen, legen wir Daten auf dem Host ab. Im Sinne von RDMA sendet der Host-Treiber niemals CIDX-Updates an das FPGA.
Unsere Queue-Implementierung verwendet Polling auf der Host-Seite anstelle von Interrupts. Der Grund dafür ist, dass Interrupts mehr PCIe-Bandbreite verbrauchen, da das FPGA in beiden Ansätzen PIDX-Updates an den Host senden muss. Experimente haben gezeigt, dass bei einer modernen CPU PIDX-Updates nach der Übertragung einer Sequenz von MBUFs mit insgesamt 4k Bytes erfolgen müssen. Deshalb empfehlen wir, nur ein einziges MBUF mit 4k Bytes zu übertragen.
Auf der Host-Seite erlauben wir unseren Warteschlangen-Deskriptoren, auf große Seiten zu zeigen. Auf diese Weise werden CPU-TLB-Fehlgriffe minimiert. Außerdem können wir unsere riesigen Seiten je nach Standort der FPGA-Karte bestimmten NUMA-Zonen des Hosts zuweisen, um den Durchgang für FPGA-DMA-Übertragungen im Verhältnis zu Host-Verarbeitungsthreads zu steuern, die ebenfalls an bestimmte NUMA-Regionen gebunden sind.
Die erste Version von Data Capture ist über Xilinx XDMA geschichtet. Die zweite Version wird zu unserem eigenen DMA-Transport über Xilinx QDMAs Bridging-Modus übergehen.
Unser PCIe Data Capture-Konzept verwendet den Standard-Linux-VFIO-Treiber. Dies ermöglicht es der Virtualisierungshardware der CPU, Prozessschutz und Sicherheit zu bieten. Wir bieten eine Python-API zur Steuerung der Karte(n). Wir verwenden ein Python-Programm, um die Deskriptoren in das FPGA zu laden, die DRAM-Warteschlangen einzurichten und den Anwendungscode zu starten. Das Toolkit von BittWare unterstützt VFIO derzeit nicht als Treiber, aber eine Unterstützung ist für die Zukunft geplant.
Das BittWare-Verarbeitungsframework auf der Host-Seite ist dem DPDK (Data Plane Development Kit) nachempfunden. Wir verwenden eine einzige Zielwarteschlange auf dem Host. Ein dedizierter Kern analysiert die eingehenden MBUFs und sendet MBUF-Pointer an eine Sammlung von Worker-Threads. Ein dedizierter Kern kann diese Aufgabe bei jeder MBUF-Größe übernehmen.
Wir planen die Veröffentlichung von Beispiel-Arbeitsprogrammen, die unsere internen Datenstrukturen in das PCAPng-Format umformatieren. Für die Neuformatierung sind etwa vier Arbeitskerne erforderlich, um mit der Leitungsrate von 100 GbE bei jeder Paketgröße Schritt zu halten.
Es gibt zwei optionale Komponenten des Konzepts, eine fügt ein Aufzeichnungselement für SSD hinzu und die andere nutzt die Fähigkeit des XUP-P3R, eine zweite PCIe-Schnittstelle zu haben, um eine Erfassung mit bis zu 200 Gb/s zu ermöglichen.
Mit einem Motherboard mit zwei Sockeln ist es möglich, einen 100-GbE-Paketstrom aufzuzeichnen. Die BittWare IP erfasst die Pakete im Host-DRAM, der an einen der Sockel angeschlossen ist. Die Anwendungssoftware verschiebt dann die MBUFs über die QPI-Links zwischen den Prozessorsockeln in das RAID 0 NVMe, das mit dem PCIe des anderen CPU-Sockels verbunden ist. Ein zukünftiges White Paper wird erklären, wie dies geschieht. Zusammenfassend lässt sich sagen, dass viel mehr NVMe-Laufwerke erforderlich sind, als Sie vielleicht denken. Das liegt daran, dass die Datenblätter der NVMe-Laufwerke für die beliebten TLC-SSDs dazu neigen, die Schreibleistung in ihren Pseudo-SLC-Caches anzugeben. Wenn dieser Cache überläuft, nimmt die Schreibleistung drastisch ab. Die allerneuesten QLC-SSDs können bei langen, endlosen Streaming-Schreibvorgängen sogar langsamer sein als herkömmliche Festplattentechnologie!
Für Kunden, die mehr als 100 Gb/s benötigen, besteht eine weitere Möglichkeit darin, die SEP to PCIe-Zusatzkarte des XUP-P3R zu verwenden. Damit lassen sich bis zu 200 Gbit/s zum Host-Speicher erreichen. Die zweite Verbindung erfolgt über einen benachbarten PCIe-Steckplatz. Beachten Sie, dass diese Option eine zweite CPU in Anspruch nimmt, ohne die Möglichkeit, auch mit Leitungsrate in den permanenten Speicher aufzuzeichnen.
Die Kunden könnten auch einfach zwei FPGA-Karten auf einem Motherboard mit zwei oder mehr CPUs verwenden.
Die heutigen Sensoren werden immer schneller, was zu zwei CPU-Herausforderungen führt. Erstens die Übertragung der E/A an die CPU und zweitens die Umwandlung der Sensordaten in verwertbare Informationen. FPGAs werden oft eingesetzt, um diese Lücke mit Hardware-Vorverarbeitung zu schließen, aber selbst das reduzierte Datenvolumen ist in vielen Fällen immer noch genug, um die CPU zu belasten.
In diesem Whitepaper haben wir untersucht, wie die PCIe-Bandbreite maximiert werden kann, um bis zu 100 Gb/s zu erfassen, einschließlich der Nutzung der CPU-Erfassung auf DRAM. Das lässt immer noch die Möglichkeit offen, die CPU zu belasten. Im nächsten Whitepaper werden wir daher die CPU für die Aufzeichnung direkt auf NVMe vollständig umgehen.
BittWare nutzt seine jahrelange Erfahrung darin, Kunden dabei zu helfen, Daten in eine CPU zu quetschen, um architektonische Konzepte zur Lösung dieser Probleme zu entwickeln. Mit diesen Konzepten und der Möglichkeit, sie in großem Umfang einzusetzen, indem sie BittWares breites Portfolio an FPGA-Karten und integrierten Servern nutzen, können Kunden problemlos Datenerfassungs- und -aufzeichnungsgeräte für spezifische Anwendungsfälle konstruieren. Folgen Sie den Social-Media-Kanälen von BittWare, um über die neuesten Veröffentlichungen auf dem Laufenden zu bleiben.
Was Sie auf dieser Seite sehen, ist die Einführung in die Datenerfassung von BittWare. In der vollständigen App Note finden Sie noch viel mehr Details! Füllen Sie das Formular aus, um Zugang zu einer PDF-Version der vollständigen App Note anzufordern.
"*" kennzeichnet Pflichtfelder
White Paper Vergleich von FPGA-RTL mit HLS C/C++ anhand eines Netzwerk-Beispiels Übersicht Die meisten FPGA-Programmierer glauben, dass High-Level-Tools immer größere Bitströme ausgeben als
White Paper FPGA-Beschleunigung von Convolutional Neural Networks Übersicht Convolutional Neural Networks (CNNs) haben sich bei komplexen Bilderkennungsproblemen als äußerst effektiv erwiesen.
BittWare Partner IP NVMe Bridge Platform NVMe Intercept AXI-Stream Sandbox IP Computergestützte Speichergeräte (CSD) ermöglichen Speicherendpunkte zur Bereitstellung von computergestützten Speicherfunktionen (CSF) für
FPGA-Server TeraBox 2000D Zuverlässiger, bewährter 2U-FPGA-Server Übersicht Wir haben einen der beliebtesten 2U-Rechenzentrumsserver von Dell EMC mit