FPGA-Leistung mit High-Level-Synthese freischalten

Field-Programmable Gate Arrays (FPGAs) haben traditionell ein umfassendes Fachwissen in Hardware-Beschreibungssprachen (HDLs) wie VHDL und Verilog gefordert. High-Level Synthesis (HLS) dreht dieses Modell um, so dass Entwickler Algorithmen in C, C++ oder SystemC schreiben und automatisch optimierten RTL-Code generieren können. Diese Verschiebung macht FPGA-Entwicklung für Softwareingenieure zugänglich, während Iterationszyklen vom Konzept zur Arbeitshardware gekürzt werden. Die Beherrschung von HLS-Tools kann Produktivitätssteigerungen von 10x oder mehr liefern, mit Leistung und Ressourcenauslastung, die oft mit handcodiertem HDL konkurrieren. Dieses Handbuch behandelt die wesentlichen Techniken, um HLS für Ihr nächstes FPGA-Projekt zu arbeiten, einschließlich einer detaillierten Durchsicht eines realen Beispiels.

Was ist High-Level-Synthese?

High-Level-Synthese ist ein Kompilierungsprozess, der eine nicht getaktete Verhaltensbeschreibung - typischerweise in C / C ++ - in eine zeitgesteuerte Hardwareimplementierung umwandelt. Im Gegensatz zu Software-Compiler, die auf einen festen Befehlssatz abzielen, muss HLS Operationen in Taktzyklen planen, funktionale Einheiten zuweisen, Operationen an bestimmte Hardwareressourcen binden und eine Finite-State-Maschine mit Datenpfad erzeugen. Der Prozess berücksichtigt die Logikblöcke, DSP-Slices und Speicherarchitektur des FPGA, geleitet von benutzerspezifischen Timing-Einschränkungen und Optimierungsrichtlinien.

Der entscheidende Vorteil ist die Abstraktion: Schleifen, Arrays und Funktionsaufrufe werden direkt synthetisiert, ohne dass man Zustandsmaschinen manuell fertigt oder Datenpfade pipeliniert. Das Tool schließt auf Parallelität, erzeugt Schnittstellenprotokolle und optimiert die Ressourcenfreigabe. Zum Beispiel kann dieselbe C-Funktion einer AXI4-Stream-Schnittstelle, einem speicherabgebildeten AXI4-Slave oder beiden einfach durch Änderung von Pragmen zugeordnet werden. Dies macht HLS besonders wertvoll für Videoverarbeitung, maschinelle Lerninferenz, digitale Signalverarbeitung und Netzwerkpaketverarbeitung, wo die Algorithmusverfeinerung schnell ist und die Hardwareleistung nicht verhandelbar ist. Durch die Erhöhung des Abstraktionsgrads ermöglicht HLS eine gründlichere Design-Space-Exploration zu Beginn des Entwicklungszyklus, wodurch das Risiko einer späten Nacharbeit reduziert wird.

Wählen Sie das richtige HLS-Tool

Es stehen mehrere ausgereifte HLS-Tools zur Verfügung, die jeweils eng in ein Anbieter-Ökosystem integriert sind oder von Drittanbietern angeboten werden. Die Auswahl hängt oft von der Zielgerätefamilie und der Komplexität des Designs ab.

  • AMD Vitis HLS (früher Vivado HLS): Das Flaggschiff für AMD Xilinx-Geräte, das C, C++ und OpenCL Kernelsynthese unterstützt. Es erzeugt RTL, das direkt in den Vivado IP-Integrator eingesteckt wird und nahtlos mit der Vitis Unified Software-Plattform für beschleunigte Anwendungen funktioniert. Weitere Details finden Sie auf der AMD Vitis HLS Produktseite.
  • Intel High-Level Synthesis Compiler (HLS Compiler): Integriert in Intel Quartus Prime, synthetisiert dieses Tool C++ für Intel Agilex, Stratix und Arria FPGAs. Es zeichnet sich durch datenpfadintensive Designs aus und unterstützt Aufgabenparallelität und feinkörniges Schleifenpipelining. Referenzmaterialien sind auf der Intel HLS Compiler Seite.
  • Siemens Catapult HLS: Ein herstellerunabhängiges Tool, das sowohl für ASIC- als auch für FPGA-Ziele aus SystemC oder C++ synthetisiert. Es wird in der Luft- und Raumfahrt und in Automobilanwendungen weit verbreitet eingesetzt und bietet eine formale Äquivalenzprüfung, wodurch es für sicherheitskritische Systeme geeignet ist.
  • Open-Source-Optionen: Das Bambu HLS-Tool von Politecnico di Milano ist ein aktiv gepflegtes Open-Source-Framework, das Standard C akzeptiert und Verilog generiert. Obwohl es nicht so leistungsorientiert ist wie Anbieter-Tools, ist es hervorragend für Lehre und Forschung geeignet und unterstützt die flexible Erforschung von HLS-Algorithmen.

Jedes Tool hat seine eigene Pragma-Syntax und Optimierungsphilosophie, aber die Kernkonzepte von HLS bleiben konsistent. Die Beispiele in diesem Artikel konzentrieren sich auf vom Anbieter bereitgestellte Tools, gelten jedoch breit über Plattformen hinweg.

Der HLS-basierte Design-Flow

Die Einführung von HLS bedeutet die Umstellung von einem RTL-zentrierten Workflow auf einen softwareähnlichen Zyklus der Codierung, Simulation und schrittweisen Verfeinerung.

Schritt 1: Algorithmusspezifikation und C-Level-Validierung

Beginnen Sie damit, Ihren Algorithmus vollständig in C oder C++ als "goldenes Modell" zu implementieren. Dieses Modell sollte bitgenau und selbstüberprüfend sein, mit Testvektoren, die alle Eckfälle abdecken. Da die HLS-Synthese empfindlich auf den Codierungsstil reagiert, trennen Sie die synthetisierbare Funktionalität von nicht synthetisierbarem Test-Nutzcode - normalerweise indem Sie den Kernalgorithmus in eine dedizierte Funktion einfügen. Vermeiden Sie dynamische Speicherzuweisung, Rekursion und Systemaufrufe innerhalb eines synthetisierbaren Codes. Verwenden Sie Arrays mit fester Größe, Festpunktdatentypen, wo erforderlich, und Compiler-Zeitschleifengrenzen. Achten Sie besonders auf Datentypen: Verwenden Sie , oder aus der HLS-Bibliothek anstelle von oder , es sei denn, dies ist absolut notwendig, da Gleitkomma hohe Ressourcenkosten verursacht.

Validieren Sie das goldene Modell mit Standard-C-Kompilation und Simulation (z. B. mit GCC oder MSVC). Dies fängt algorithmische Fehler frühzeitig, lange bevor die Hardware-Simulation beginnt. Das HLS-Tool verwendet später den gleichen Testbench für die C/RTL-Co-Simulation, so dass sich der Investitionsaufwand hier gut auszahlt.

Schritt 2: Werkzeugkonfiguration und Zielspezifikation

Erstellen Sie ein neues HLS-Projekt in Ihrem gewählten Tool (Vitis HLS, Intel HLS Compiler usw.).

  • Die Top-Funktion zum Synthetisieren.
  • Das Ziel-FPGA-Teil oder -Board, das die verfügbaren Ressourcen, die Taktfrequenz und die Gerätearchitektur bestimmt.
  • Die Taktperiodeneinschränkung, typischerweise in Nanosekunden, treibt die Planungs- und Pipelining-Entscheidungen an.
  • Simulationseinstellungen und, für Vitis HLS, ob C-Simulation oder Co-Simulation mit einem externen RTL-Simulator verwendet werden soll.

Die richtige Konfiguration stellt sicher, dass die Optimierungen des Tools mit den physikalischen Timing-Fähigkeiten übereinstimmen. Ein häufiger Fehler ist die Einstellung einer zu optimistischen Taktperiode, was später zu Syntheseausfällen führt. Beginnen Sie mit einem konservativen Ziel (z. B. 10 ns / 100 MHz) und straffen Sie nach der Überprüfung der Terminplanungsberichte schrittweise.

Schritt 3: Codeoptimierung mit Pragmas und Direktiven

Pragmas sind der primäre Mechanismus für die Führung des HLS-Tools. Ohne sie synthetisiert das Tool ein sicheres, aber unteroptimiertes Design - Sequenzschleifen, vollständig gemeinsame Ressourcen, minimale Parallelität.

  • Looppipelining: bewirkt, dass sich Schleifen-Iterationen überschneiden und jede II (Initiationsintervall)-Zyklen eine neue Iteration initiieren. Eine II=1-Pipeline liefert nach anfänglicher Latenz ein Ergebnis pro Taktzyklus und maximiert den Durchsatz.
  • Loop-Entrollung: repliziert Schleifenkörper, um mehrere Iterationen parallel auszuführen, indem sie den Bereich gegen die Leistung austauschen.
  • Array-Partitionierung und Umformung: teilt Arrays in kleinere Speicherbänke für den parallelen Zugriff. kombiniert geteilte Daten zu einem breiteren einzelnen Speicherwort.
  • Funktionsinlining: verschmilzt Funktionshierarchien und gibt dem Tool mehr Spielraum für grenzüberschreitende Optimierungen.
  • Interface-Pragmen: Geben Sie an, wie sich die Top-Funktion verbindet— für Streaming, für eine speicherabgebildete Steuerschnittstelle, für externen DDR-Speicherzugriff usw.
  • Dataflow: ermöglicht die Parallelität auf Task-Ebene, so dass eine Abfolge von Funktionen oder Schleifen gleichzeitig als Pipeline mit Streaming-Kanälen ausgeführt werden kann.
  • Ressourcenzuweisung: oder Direktiven können die Anzahl der DSPs oder Speicherports begrenzen und so Ressourcenkonflikte verhindern.

Gut gewählte Pragmas können den Unterschied zwischen einem Design bedeuten, das kaum den Durchsatz erreicht und einem, das Ressourcen im Leerlauf lässt. Der Optimierungsprozess ist iterativ: Direktiven anwenden, synthetisieren, Leistungs- und Nutzungsberichte überprüfen und verfeinern. Führen Sie ein Protokoll, welche Pragmas ausprobiert wurden und ihre Auswirkungen auf Fläche und Latenz.

Schritt 4: Synthese und Analyse

Führen Sie die HLS-Synthese aus, um RTL-Code und umfassende Berichte zu erstellen. Der wichtigste Bericht ist das Leistungsprofil, das die Latenz, das Initiierungsintervall und die Pipelinetiefe jeder Schleife anzeigt. Der Ressourcennutzungsbericht bricht LUTs, Flip-Flops, DSPs und die Block-RAM-Nutzung auf. Querverweisen Sie diese mit der Kapazität und der Taktbeschränkung Ihres Zielgeräts.

Moderne HLS-Tools erzeugen auch einen Zeitplan-Viewer (ein Gantt-Diagramm) und eine Bindungskarte, die Ihnen hilft zu visualisieren, wie Operationen über Taktzyklen und Funktionseinheiten verteilt sind. Wenn das erreichte Initiationsintervall oder die Latenz höher als gewünscht ist, suchen Sie nach "Loop-carried Dependencies" oder Speicherportkonflikten, die im Bericht markiert sind. Oft verhindert ein subtiles C-Konstrukt - wie ein Akkumulator, der von seinem vorherigen Wert abhängt - das Erreichen von II = 1, ohne Umcodierung oder Array-Partitionierung. Verwenden Sie den Zeitplan-Viewer, um Stände zu lokalisieren.

Schritt 5: C/RTL Co-Simulation

Vor der Integration der erzeugten RTL in ein größeres FPGA-Design ist die funktionale Äquivalenz durch Co-Simulation zu überprüfen. Das Tool kompiliert den ursprünglichen C-Testbench mit der erzeugten RTL mit einem gebündelten Simulator (z. B. Xcelium, ModelSim oder Vivado-Simulator). Es führt die gleichen Eingangsvektoren durch und vergleicht die Ausgaben Zyklus für Zyklus. Co-Simulation bestätigt nicht nur die Logikkorrektheit, sondern zeigt auch Zeitabweichungen auf, wie z. B. wenn das C-Modell sofortiges Speicherschreiben annimmt, während die RTL Schreibverzögerungen aufgrund von BRAM-Latenz aufweist.

Wenn Fehlanpassungen auftreten, überprüfen Sie die Wellenform oder Transaktionsprotokoll. Passen Sie das C-Modell oder die Pragmen an (z. B. Hinzufügen von mit entsprechender Latenz) an, bis das RTL-Verhalten genau mit dem Goldenen Modell übereinstimmt. Es ist eine gute Praxis, Co-Simulationen auf kleinen Subfunktionen durchzuführen, bevor Sie auf das vollständige Design skalieren und Debug-Iterationen reduzieren.

Schritt 6: IP exportieren und in den FPGA Design Flow integrieren

Nach der Überprüfung wird das Design als verpackter IP-Core exportiert, typischerweise im IP-XACT- oder Intel Qsys-Format. Dieser IP-Block kann dann in einem Blockdesign (z. B. Vivado IP Integrator) neben anderen RTL-Modulen, Soft-Prozessoren oder Speichercontrollern instanziiert werden. Die HLS-generierte IP enthält Timing-Einschränkungen und ist bereit für Platzierung und Routing.

Im traditionellen FPGA-Flow führen Sie dann Synthese und Implementierung (Place-and-Route) aus, um den endgültigen Bitstream zu generieren. Überwachen Sie das Implementierungs-Timing sorgfältig. HLS-Tools liefern geschätztes Timing basierend auf Vorplatzierungsmodellen; echte Platzierung kann längere Routing-Verzögerungen aufzeigen, die es erforderlich machen, die Zieluhr zu entspannen oder die HLS-Beschränkungen zu überdenken. Wenn das Ziel II einer Schleife in Hardware nicht erreicht werden kann, wird das Tool die Uhr herunterfahren oder das Design wird fehlschlagen Timing, also ist diese Feedback-Schleife wichtig. Budget zusätzliche Lücke (10-20%) während HLS, um physikalische Effekte zu berücksichtigen.

Praktisches Beispiel: Implementierung eines FIR-Filters mit HLS

Um diese Konzepte zu verfestigen, betrachten Sie einen FIR-Filter (Finite Impulse Response) - einen gemeinsamen digitalen Signalverarbeitungsbaustein. Der C-Code unten implementiert einen 16-Tap-FIR-Filter mit Fixpunktkoeffizienten. Wir werden Pragmen anwenden, um einen hohen Durchsatz auf einem AMD Xilinx FPGA zu erzielen.

#include <ap_fixed.h>
#include <hls_stream.h>

typedef ap_fixed<16,8> data_t;
typedef ap_fixed<16,8> coeff_t;

void fir(hls::stream<data_t> &in, hls::stream<data_t> &out, coeff_t coeffs[16]) {
#pragma HLS INTERFACE axis port=in
#pragma HLS INTERFACE axis port=out
#pragma HLS INTERFACE s_axilite port=coeffs
 static data_t shift_reg[16];
#pragma HLS ARRAY_PARTITION variable=shift_reg complete dim=1
 data_t acc = 0;
 // Shift and accumulate
 ShiftLoop:
 for (int i = 15; i > 0; --i) {
#pragma HLS PIPELINE II=1
 shift_reg[i] = shift_reg[i-1];
 acc += shift_reg[i] * coeffs[i];
 }
 shift_reg[0] = in.read();
 acc += shift_reg[0] * coeffs[0];
 out.write(acc);
}

Wichtige Pragmen in diesem Beispiel:

  • INTERFACE-Achse: Verwendet AXI4-Stream für Ein- und Ausgang, ideal für den kontinuierlichen Datenfluss.
  • ARRAY PARTITION complete: Splittet das Schieberegister in einzelne Register, wodurch ein paralleler Zugriff auf alle Abgriffe ermöglicht wird.
  • PIPELINE II=1: Stellt sicher, dass pro Taktzyklus nach anfänglicher Latenz ein neues Sample verarbeitet wird.

Nach der Synthese sollten die Berichte überprüft werden: Die Schiebeschleife sollte II = 1 erreichen, und der Ressourcenverbrauch (DSPs für Multiplikationen) sollte mit 16 Multiplikatoren übereinstimmen. Dieses Design wird dann als IP-Kern exportiert und in ein größeres System integriert, zum Beispiel verbunden mit einem AXI DMA, um Daten von einem Sensor zu streamen. Dieses Beispiel zeigt, wie einige wenige Pragmas eine einfache C-Funktion in einen Hochleistungs-Hardwarebeschleuniger übersetzen.

Optimierungsstrategien für Performance und Area

Effektive HLS erfordern einen Ausgleich von Durchsatz, Latenz und Ressourcenverbrauch.

  • Bevorzugen Sie die Festpunktarithmetik: Floating-Point-Operationen verbrauchen erhebliche Ressourcen und Grenzfrequenz. Sofern der dynamische Bereich nicht kritisch ist, verwenden Sie Festpunkttypen (z. B. in Vitis HLS), um die DSP- und LUT-Zahlen zu reduzieren und gleichzeitig die Präzision zu erhalten.
  • Stream-Daten statt zufälligen Speicherzugriffs: Hardware ist am effizientesten, wenn Daten durch eine Pipeline fließen.
  • Strukturschleifennester für perfekte Schleifennester: Das Tool kann eine innerste Schleife automatisch verschicken. Stellen Sie sicher, dass Schleifen keine Schleifenabhängigkeiten haben, die über bekannte Muster (z. B. Reduktion) hinausgehen.
  • Verwenden Sie Template-Metaprogrammierung für die Konfigurierbarkeit: C++-Vorlagen ermöglichen die Compiler-Zeit-Parametrierung von Array-Größen und Datenbreiten, wodurch die gleiche HLS-Quelle geräteübergreifend ohne Leistungsverlust wiederverwendbar ist.
  • Balance Resource Sharing and Latency: Die -Direktive kann die gemeinsame Nutzung teurer Operatoren wie Teiler erzwingen.
  • Bitgenaue Typen sinnvoll nutzen: Die Verwendung von fest eingegebenen Fixpunktdarstellungen minimiert die Hardwarekosten. Zum Beispiel verwendet für Pixeldaten minimale Ressourcen, während die notwendige Präzision beibehalten wird. Immer Profilquantisierungsfehler gegen algorithmische Toleranz.

HLS-Tools bieten auch "Lösungsverzeichnisse", in denen Sie mehrere Optimierungssets (z. B. "niedriger Bereich", "hoher Durchsatz") verwalten und vergleichen können. Dies ist von unschätzbarem Wert, um den Designraum zu erkunden, ohne frühere Ergebnisse zu verlieren.

Debugging und Verifizierung Best Practices

Das Debuggen von HLS-Designs unterscheidet sich sowohl von Software als auch von RTL-Debugging. Da der Quellcode C++ ist, können herkömmliche Debugger die Funktionalität validieren, aber keine Hardware-Parallelität oder Timing-Bugs aufdecken.

  • Behalten Sie ein zyklusnahes reines C++-Modell bei, das die gleichen Schnittstellenprotokolle (z. B. Streaming) verwendet, damit Sie schnell simulieren können.
  • Implementieren Sie selbstprüfende Prüfstände mit randomisierter Eingangserzeugung und goldenen Referenzausgängen.
  • Verwenden Sie die Protokoll- und Pragma-Warnungen des HLS-Tools aggressiv.Behandeln Sie nicht synthetisierbare Konstrukte oder suboptimale Schleifenstrukturen als Fehler.
  • Beginnen Sie die Co-Simulation frühzeitig mit einem kleinen Submodul, bevor Sie auf das vollständige Design skalieren, wodurch Syntheseprobleme schnell isoliert werden.
  • Verwenden Sie die integrierte Leistungsanalyse des HLS-Tools, um Initiierungsintervallengpässe anzuzeigen, bevor Sie lange RTL-Simulationen ausführen.
  • Überprüfen Sie den generierten RTL-Code auf unerwartete Strukturen: Zum Beispiel zeigen große Multiplexer oft zu komplexe bedingte Zweige an. Vereinfachen Sie Bedingungen, indem Sie, wenn möglich, verschachtelte -Anweisungen verflachen.

Häufige Fallstricke und wie man sie vermeidet

Selbst erfahrene Ingenieure stoßen beim Umzug in die HLS auf wiederholte Probleme. Wenn sie im Voraus erkannt werden, wird der Übergang erleichtert.

  • Unbounded loops: Loops mit variablen Fahrtenzahlen, die zum Kompilierzeitpunkt nicht kalkulierbar sind, können nicht richtig geplant werden.
  • Große Speicherschnittstellen mit schlechter Bandbreite: Eine einzelne AXI4-Lite-Masterschnittstelle für große Datenarrays wird Engpassleistung.
  • Reset und Initialisierung ignorieren: Anders als reine RTL geht HLS manchmal davon aus, dass Register in einem gültigen Zustand starten können. Stellen Sie sicher, dass Sie eine saubere Reset-Strategie haben und vermeiden Sie uninitialisierte lokale Arrays, die auf uninitialisierte RAMs schließen können (verwenden Sie wo nötig).
  • Verlasst sich überaus auf die Autooptimierung von Werkzeugen: Obwohl HLS-Tools leistungsstark sind, können sie die Designabsicht nicht erraten. Ein einfaches Handshake-Protokoll benötigt möglicherweise eine explizite -Schnittstellenauswahl, um das erwartete Verhalten zu entsprechen; die Abhängigkeit von Standardeinstellungen kann zu nicht übereinstimmenden Schnittstellen führen.
  • Vernachlässigung der realen Zeiteinschränkungen: Die HLS-Zeitplanung verwendet ein einfaches Zeitmodell. Die physische Platzierung von Netzen mit hohem Fanout oder großen Multiplexern kann zu unerwarteten Zeitverstößen führen.
  • Vergessen, Pipeline-Stollen zu verifizieren: Wenn der Eingangsstrom in einer Pipeline-Schleife abwürgt, muss die Pipeline in der Lage sein, ohne Deadlock zu entwässern.

Integration von HLS mit heterogenen Systemen

Moderne FPGA-Plattformen koppeln programmierbare Logik mit Hard-Prozessor-Systemen (z. B. ARM Cortex in Zynq, Agilex SoC). HLS passt natürlich in diese Architekturen. Ein gängiges Muster ist die Verwendung des Prozessors zur Steuerung und Konfiguration eines HLS-generierten Beschleunigers über AXI-Lite, während Datenströme mit hoher Bandbreite über AXI4-Stream- oder AXI4-Master-Ports fließen. Die Vitis HLS-Dokumentation bietet umfassende Anleitung zur Integration in die Xilinx Runtime (XRT) und OpenCL-APIs. In ähnlicher Weise ermöglicht Intels HLS-Compiler innerhalb des oneAPI-Frameworks den gleichen C++-Kernel-Code, um sowohl CPUs als auch FPGAs anzusprechen, was die Entwicklung rekonfigurierbarer Beschleuniger vereinfacht.

Für Echtzeit-Steuerungssysteme kann HLS eine benutzerdefinierte RTL-Peripherie erzeugen, die mit der AXI-Verbindung des Prozessors verbunden ist und zeitkritische I/O verarbeitet, während der Prozessor Richtlinien und Netzwerkstapel verwaltet. Diese Arbeitsteilung maximiert die Leistung, ohne die Flexibilität zu beeinträchtigen. Achten Sie bei der Gestaltung solcher Systeme auf die Datenbreitenabstimmung: Ein AXI4-Master mit einer 64-Bit-Schnittstelle erfordert möglicherweise eine Burst-Alignment-Logik im HLS-Kernel.

Die Zukunft der High-Level-Synthese

HLS entwickelt sich rasant weiter, mit Verbesserungen in der Compiler-Heuristik, der formalen Verifikation und den Bibliotheks-Ökosystemen.

  • Maschinenlernen für HLS im AutoML-Stil: Werkzeuge beginnen, ML-Modelle zu integrieren, die optimale Pragma-Konfigurationen vorhersagen und die manuelle Abstimmung reduzieren. Forschung sowohl aus der Wissenschaft als auch aus der Industrie zielt darauf ab, eine "Push-Button" -Synthese aufzubauen, die mit fachkundigen Designs konkurriert.
  • Standardisierung um C++17 und darüber hinaus: Da HLS-Front-Ends moderne C++-Standards übernehmen, können Designer Constexpr, Lambdas und Template-Metaprogrammierung nutzen, um hochparametrisierte, wiederverwendbare Hardwarebibliotheken zu schreiben.
  • Eine engere Integration mit einer Verifikation auf hoher Ebene: Universal Verification Methodology (UVM) und SystemC Transaktionsmodellierung werden mit HLS kombiniert, um einheitliche Design- und Verifizierungsflüsse zu schaffen und den Verifizierungsengpass zu verringern.
  • Open-Source-Hardware-Stacks: Projekte wie die CHIPS Alliance fördern offene HLS-Frameworks und Bibliotheken und machen HLS über die großen FPGA-Anbieter hinaus zugänglicher.
  • Erhöhte Unterstützung für dynamische Rekonfiguration: Zukünftige HLS-Flows können das Laufzeit-Swaping von Kernel ermöglichen, wodurch adaptive Systeme, die als Reaktion auf sich ändernde Workloads neu konfigurieren, ermöglicht werden.

Da die FPGA-Dichte weiter wächst, wird das Management der Komplexität auf RTL-Ebene nicht mehr nachhaltig. HLS bietet eine Möglichkeit, diese Komplexität zu bewältigen, indem es die Abstraktionsebene erhöht und gleichzeitig die Hardwareeffizienz beibehält. Die Beherrschung von HLS versetzt Ingenieure nun in die Lage, die nächste Generation von leistungsstarken, rekonfigurierbaren Systemen zu bauen, von Edge-AI-Beschleunigern bis hin zu Hochgeschwindigkeits-Netzwerkgeräten.