Der HLS-Ansatz für die FPGA-Entwicklung besteht darin, nur die Teile der Anwendung zu abstrahieren, die sich leicht in einer C/C++-Umgebung ausdrücken lassen. Der HLS-Toolflow ist durch die Verwendung von Vivado- (Xilinx) oder Intel- (Quartus) Tools für praktisch jede BittWare-Karte verfügbar.
Um an der HLS erfolgreich zu sein, ist es wichtig, die Teile Ihrer Bewerbung zu erkennen, die gut zu Ihnen passen werden. Die Leitlinien umfassen:
- Zielanwendungen sind im Allgemeinen IP-Blöcke, die zunächst in einer Hochsprache definiert werden. Ein mathematischer Algorithmus würde sich gut eignen oder, wie in unserem RSS-Block, die Verarbeitung eines Netzwerkprotokolls.
- Eine weitere Kategorie von Anwendungen sind Blöcke, die schlecht definiert sind und daher mehrere Implementierungsrunden erfordern können. Der größte Vorteil besteht hier darin, dass das HLS-Tool den resultierenden nativen FPGA-Code automatisch in eine Pipeline einbinden kann, wodurch oft weniger Stufen entstehen als bei einer schnellen manuellen Codierung einer Pipeline. Wenn es an der Zeit ist, die handkodierte Pipeline zu modifizieren, können sich Verzögerungsänderungen an einem parallelen Pfad auf alle anderen auswirken. Die Verwendung des HLS-Tools zur automatischen Erstellung einer zweiten Pipeline von Grund auf beseitigt diese Probleme.
- Schließlich erleichtert ein HLS-Flow die Portierung von Code zwischen FPGA-Marken und Geschwindigkeitsstufen. Das liegt daran, dass HLS automatisch die entsprechende Anzahl von Pipeline-Stufen generiert - etwas, das Sie bei der Arbeit mit Verilog oder VHDL manuell festlegen müssen.
Die derzeitigen Beschränkungen von HLS liegen eindeutig darin, dass sein Anwendungsbereich auf IP-Blöcke beschränkt ist. Das Anwendungsteam benötigt nach wie vor RTL für andere Komponenten, obwohl ein Benutzer durch den Einsatz von Produkten wie der SmartNIC Shell von BittWare für die RTL-Teile in der Lage sein könnte, seine einzigartige Anwendung vollständig in HLS zu definieren. Es sollte auch beachtet werden, dass HLS eine schlechte Wahl für die einfachsten Codes oder größere Designs ist, die hauptsächlich aus voroptimierten Komponenten bestehen.
Unsere Anwendung: RSS-Vernetzung auf einem FPGA
Was ist RSS? RSS steht für "Receiver Side Scaling". Es handelt sich um einen Hash-Algorithmus zur effizienten Verteilung von Netzwerkpaketen auf mehrere CPUs. RSS ist eine Funktion moderner Ethernet-Karten und implementiert im Allgemeinen den von Microsoft definierten Toeplitz-Hash.
Die Umgebung, in der unsere RSS-Anwendung läuft, ist die SmartNIC Shell von BittWare. Die SmartNIC Shell wurde entwickelt, um Anwendern einen Vorsprung bei der Entwicklung einer FPGA-basierten Netzwerkanwendung zu verschaffen. Sie bietet den Benutzern eine optimierte FPGA-basierte 100G-Ethernet-Pipeline, einschließlich DPDK für die Host-Interaktion. Alles, was der Anwender tun muss, ist, seine Anwendung als IP-Block einzubinden.
In diesem Fall war BittWare auch der Anwender, der als unsere Anwendung eine FPGA-Implementierung von RSS erstellt hat. Sowohl das Team, das RSS mit dem traditionellen RTL-Ansatz erstellte, als auch das HLS-Team konnten SmartNIC Shell als FPGA-Ethernet-Framework verwenden und sich auf die RSS-Anwendung selbst konzentrieren.
Die RSS-Implementierung von BittWare
Unsere FPGA-basierte RSS-Implementierung basiert auf C-Code, der im DPDK-Quellcodebaum zu finden ist, wobei die Testfunktion für diesen Code ebenfalls im Baum verfügbar ist. Unsere RSS-Anwendung verwendet außerdem eine Umleitungstabelle mit 64 Einträgen anstelle der üblichen Tabelle mit 128 Einträgen. Wichtig für diese HLS-Studie ist, dass die Funktion, die wir in das FPGA übertragen, zunächst in C definiert ist. Damit ist unser wichtigstes Kriterium für den HLS-Erfolg erfüllt - eine Definition in C oder C++.
Pakete mit Tupeln gruppieren
Ziel der RSS-Funktion ist es, die Pakete auf die CPUs zu verteilen und dabei zusammengehörige Paketströme zusammenzuhalten. Verschiedene Toeplitz-Schlüsselmengen bieten unterschiedliche Verteilungsmuster. Unabhängig vom Schlüsselsatz verwendet unsere RSS-Funktion jedoch die Quell- und Ziel-IP-Adresse sowie die Quell- und Ziel-Ports eines jeden Pakets als Eingabe. Diese vier Komponenten zusammen werden als 4-Tupel bezeichnet.
Beachten Sie, dass wir für unsere RSS-Anwendung davon ausgehen, dass das 4-Tupel bereits geparst und zu den Metadaten des Pakets hinzugefügt wurde. Ein anderes SmartNIC-Shell-Modul übernimmt diese Funktion der Paketklassifizierung. Wir nennen dieses Modul unseren "Parser" und es wird Gegenstand eines separaten BittWare-Whitepapers sein.
Unsere RSS-Implementierung akzeptiert derzeit ein 96-Bit-Feld zur Klassifizierung - genug für das 4-Tupel aus IPv4-Quelle/Ziel und Port. Der Parser liefert Null für Felder, die im Paket nicht vorhanden sind; wenn ein Paket keine IP-Nutzlast enthält, ist das volle 96-Bit-Tupelfeld Null.
Viele RSS-Implementierungen verwenden ein 5er-Tupel anstelle eines 4er-Tupels. Dies würde zusätzliche 8-Bits erfordern, um die Protokollnummer unterzubringen. HLS-Benutzer von RSS können diese Änderung mit geringfügigen Änderungen am Quellcode leicht umsetzen. Diese Fähigkeit zur schnellen Anpassung von 4-Tupel auf 5-Tupel ist ein Beispiel für das zweite Kriterium für den Erfolg von HLS - eine Voraussetzung für mehrere Implementierungsrunden.