CPU plus FPGA-Designflow für Softwareentwickler:Eine neue greifbare Realität

Vor kurzem organisierte Brian Bailey einen runden Tisch, der zu einem zweiteiligen Artikel mit dem Titel Supporting CPUs Plus FPGAs . führte . Die Experten diskutierten die sich entwickelnde Realität des Systemdesigns auf Basis von FPGAs und CPUs. Diese Diskussion befasst sich mit den jüngsten Entwicklungen im Designflow und wie der Einsatz neuer Technologien Softwareentwicklern dabei helfen kann, eine schnellere Markteinführungszeit für CPU- und FPGA-Plattformen zu erreichen.

Einführung
Angesichts des wachsenden Interesses an künstlicher Intelligenz (KI), des Aufkommens vernetzter Objekte (IoT) und des Trends zur Beschleunigung von Rechenzentren stellt sich die Frage:Was ist der gemeinsame Nenner der drei?

Softwareentwickler stehen im Mittelpunkt all dieser Trends und möchten ihre Programmierung und Berechnungen beschleunigen. Neueste technologische Durchbrüche, einschließlich geringer Kommunikationslatenz zwischen FPGAs und CPUs, gepaart mit dem relativ geringen Stromverbrauch heutiger FPGAs, machen FPGA- und CPU-basierte Systeme zur richtigen Wahl, um die gewünschte Leistung zu erzielen. Im Zentrum dieser Konvergenz werden Softwareentwickler jedoch durch die zugrunde liegende Komplexität der FPGA-Technologie behindert.

In den letzten Jahren haben sich High Level Synthesis (HLS)-Tools im Hinblick auf die Bewältigung der heutigen Systemkomplexität und die Verkürzung der Markteinführungszeit stark verbessert. HLS-Tools konzentrieren sich jedoch hauptsächlich auf IP-Blöcke (d. h. sie sind IP-zentriert). Es gibt eine Vielzahl von Entscheidungen/Optimierungen auf Systemebene, die von HLS-Tools nicht unterstützt werden können, um die Anforderungen zu erfüllen. Einige dieser Anforderungen umfassen das Finden der richtigen Balance zwischen Softwareaufgaben und Hardwarebeschleunigern, den Vergleich von Pipeline und paralleler Ausführung, das Erreichen der gewünschten Datengranularität, die Bewertung von Kommunikationsmechanismen und vieles mehr.

Um diese komplexen Systeme zu bauen, benötigen Softwareentwickler einen Designflow, der eine gemeinsame Unterstützung von Hardware und Software bietet. Ein solcher Flow muss einfach genug sein, um seine Verwendung (wie der Softwareentwickler-Flow) und die Übernahme durch Softwareentwickler zu gewährleisten. Der Flow muss auch aufschlussreiches Feedback zu den verfügbaren Optimierungsoptionen liefern, um die erforderlichen Leistungsziele zu erreichen. Einige Unternehmen haben kürzlich den Weg geebnet, um die Aufgabe für Softwareentwickler zu erleichtern, indem sie die technologischen Details des Hardware-Design-Flows abstrahiert haben. Diese Unternehmen lassen sich von den System-Level-Design-Ansätzen inspirieren, die in ESL-Modelle und ihre Anwendung:Electronic System Level Design and Verification in Practice . beschrieben sind .

Verstehen der Designflow-Methodik auf Systemebene
Design auf Systemebene konzentriert sich auf Bedenken auf höherer Abstraktionsebene. Während man sich auf das Gesamtbild konzentrieren muss, werden verschiedene Abstraktionsebenen verwendet, um verschiedene Teile des Systems zu validieren, zu verifizieren, zu verfeinern und zu integrieren, bevor es tatsächlich entwickelt wird. Auch wenn sich die Ingenieursgemeinschaft nicht auf eine gemeinsame Sprache einigen kann, beginnt die Mehrheit der Konstrukteure auf der algorithmischen Ebene. Designer validieren nicht-funktionale und funktionale Systemspezifikationen, indem sie Ausführungsmodelle erstellen, die in C/C++/SystemC-, MATLAB-, Simulink- und LabVIEW-Umgebungen geschrieben wurden. Diese Hochsprachen werden verwendet, um das Verhalten des gesamten Systems zu modellieren.

Für die Zwecke dieser Diskussion haben wir uns auf einen Designflow auf Systemebene konzentriert, der auf C/C++-Spezifikationen basiert (Abbildung 1). Der erste Block ist in drei Schritte unterteilt. Der erste dieser Schritte stellt die Anwendungsprofilierung (d. h. die Hardware-Software-Partitionierung) dar, bei der davon ausgegangen wird, dass Teile von C/C++-Code (Funktionen, Schleifen usw.) in die Hardware (FPGA) verschoben werden. Der nächste Schritt ist die Spezifikation der CPU/FPGA-Plattform (z. B. ARM53/FPGA, POWER8/FPGA) und die Konfiguration der Hardware-Plattformelemente (Systemtakt, Prozessor-Cache, Interconnection etc.). Der folgende Schritt besteht darin, die Anwendungsaufgaben (basierend auf der profilierten Anwendung) zwischen Hardware und Software (d. h. Hard- und/oder Soft-CPU) abzubilden und – ganz zum Schluss – die Generierung einer ausführbaren Architektur.

Der zweite Block von Abbildung 1 beinhaltet die Architekturoptimierung (auch bekannt als Architekturexploration oder Leistungsüberprüfung). Dies ist in Abbildung 2 genauer dargestellt.

Der Architekturoptimierungsprozess befasst sich mit den folgenden Schätzern:

• Hardwareschätzung bewertet Metriken der Hardwarepartitionierung (d. h. C/C++-Code, der auf dem FPGA verschoben wurde). Sie kann nach Ressourcen, Leistung (z. B. Schleifenlatenz) und Leistungsschätzungen aufgeschlüsselt werden. Die Hardwareschätzung wird durch HLS-Tools (High-Level-Synthese) gesteuert.
• Softwareschätzung wertet Metriken für den C/C++-Partitionscode aus, der auf der CPU (d. h. Hard- und/oder Soft-CPU) ausgeführt wird. Dieser Prozess ist komplementär zum Hardwareschätzschritt. Beispiele für Leistungskennzahlen sind Prozessorlast, Taskwechsel und Cache-Misses.
• Datentransferschätzung besteht aus der Modellierung der Schnittstellen (d. h. Memory-Map- und Streaming-Schnittstellen), über die die Hardware und Software kommunizieren. Beispiele für gesammelte Metriken sind Busleistung (z. B. Latenz und Durchsatz), Warteschlange und Speichernutzung.

Diese Schätzungen werden in einer Datenbank aggregiert und dem Entwickler wird eine Systemleistungsanalyse vorgelegt, um zu beurteilen, ob die Anforderungen des Systems erfüllt werden. Architekturen, die die Anforderungen erfüllen, fahren mit dem Architekturimplementierungsprozess fort; andernfalls werden zusätzliche Optimierungsversuche auf Systemebene verarbeitet.

Der letzte Block von Abbildung 1 bezieht sich auf die Architekturimplementierung, bei der Systemarchitekturen mit Implementierungstools wie Xilinx Vivado oder Intel Quartus Prime in einen Bitstream (für die FPGA-Implementierung) konvertiert werden, um die endgültige und vollständige Systemgenerierung auf der spezifischen physischen Plattform auszuführen. Dieser Schritt muss qualitativ hochwertigen Code erzeugen und sollte für den Softwareentwickler transparent sein.

Optimierung auf Systemebene
Der Mangel an automatisierten Werkzeugen zur Architekturoptimierung wurde lange Zeit als eine der Hauptschwächen des FPGA-basierten Computings wahrgenommen. Die Entwicklung solcher Tools war aufgrund der Komplexität und der damit verbundenen Herausforderungen schwierig.

Um diese Herausforderungen zu veranschaulichen, zeigt Abbildung 3 einen typischen Optimierungsprozess auf Systemebene während einer Architekturuntersuchung für eine Bildverarbeitungsanwendung, die aus sechs Funktionen (Stücken von C/C++-Code) besteht und auf einer Zynq-7000-Plattform implementiert werden soll. Hier listen wir acht mögliche Architekturen auf, die auf der Plattform implementiert werden können. Da die Time-to-Market nicht die Implementierung jeder Architektur zulässt, muss schnell die am besten zu implementierende Lösung bestimmt werden. Diese Abfolge von Optimierungen kann selbst für erfahrene Hardware-Designer eine Herausforderung darstellen.

FPGA-Softwareentwicklungstools wie SDSoC/SDAccel (Xilinx), Merlin Compiler (Falcon Computing Solutions) und SpaceStudio (Space Codesign Systems) sind kommerzielle Lösungen, die Softwareentwickler beim Design von FPGA/CPU-Systemen unterstützen und gleichzeitig eine Optimierung auf Systemebene erzielen. Diese Tools verwenden einen ähnlichen Ablauf wie in den Abbildungen 1 und 2 beschrieben und demonstrieren damit die Existenz einer neuen Generation von Tools auf Systemebene mit unterschiedlichen Ansätzen.

SDSoC schätzt die Systemleistung in einem zweistufigen Ansatz. Zunächst schätzt SDSoC Latenzen für die Hardwarefunktionen (von HLS-Tools) und die interne Charakterisierung (d. h. Datenübertragung) der anvisierten physischen Plattform und ihrer Kommunikationsschnittstellen. Später wird diese Schätzung mit einer reinen Softwareversion der Anwendung verglichen, die auf der physischen Plattform ausgeführt wird.

Merlin Compiler schlägt eine Source-to-Source-Transformation vor. Das Ziel der Source-to-Source-Transformation besteht darin, die Designabstraktionslücke zwischen der Software-/Algorithmusentwicklung und bestehenden HLS-Designabläufen zu reduzieren oder zu beseitigen. Der Merlin Compiler stützt sich auf vier Pragmas, um spezifische FPGA-Designs abzuleiten. Zusätzlich zu den vier Hauptoptimierungen, die durch explizite Pragmas ausgelöst werden, enthält der Merlin-Compiler auch verschiedene implizite Optimierungen (dh Transformationsdurchgänge des Compilers), die zusammen mit den Pragmas durchgeführt werden, um die Ergebnisse der Pipeline und der Parallelisierung zu verbessern.

SpaceStudio generiert nahtlos eine ausführbare virtuelle Plattform (VP) für jeden Architekturkandidaten (Mapping). Ein typischer VP besteht aus Prozessorkernsimulatoren, die mit verschiedenen Busmodellen, Speichercontrollern und anderen Datenperipheriemodellen verbunden sind. Es modelliert die anvisierte Plattform samt Datenübertragung in einer co-simulierten Umgebung, die speziell auf die Anwendung zugeschnitten ist. Dies bedeutet, dass der ausführbare VP eine genauere Leistungsvorhersage und Algorithmusvalidierung der Anwendung ermöglicht. Es integriert auch Überwachungs- und Analysefunktionen für die nicht-intrusive Leistungsprofilierung sowohl von Hardwarefunktionen als auch von Softwareaufgaben. VP verlässt sich auf HLS-Tools für Hardware-Schätzer, während Verzögerungen (z. B. Latenzen) von Hardware-zugeordneten Funktionen automatisch annotiert werden, um die Genauigkeit des Simulationsprozesses zu erhöhen. Der VP kann vom Softwareentwickler inspiziert werden, um zu verstehen, wie die Optimierungsaufgaben implementiert werden. Ein solches Feedback hilft dem Softwareentwickler, das beabsichtigte Design für die spezifischen angewendeten Optimierungen zu erreichen.

Eine Möglichkeit, das kommerzielle Ökosystem zu sehen
Abbildung 4 bietet einen Überblick über das kommerzielle Ökosystem, das sich rund um die Welt des plattformbasierten Designs von CPUs und FPGAs bewegt. Das erste (obere) Kästchen stellt den Hauptentwurfseintrag auf Algorithmusebene dar. Der zweite Kasten enthält Umgebungen, die die algorithmische Synthese (d. h. vom Algorithmus bis zur Implementierung) unterstützen. Die fett markierten Tools unterstützen die C/C++-Designeingabe und führen Optimierungen auf Systemebene durch. Die dritte Box stellt Werkzeuge dar, die verwendet werden, um die Architekturimplementierung zu erreichen, hauptsächlich Werkzeuge von FPGA-Herstellern, die die Low-Level-Synthese und die Bitstream-Generierung durchführen. Unten in der Abbildung sind Beispiele für CPU/FPGA-Plattformen dargestellt.

Darüber hinaus listet Tabelle 1 einige der wichtigsten kommerziellen Tools auf, die beim Design von CPU/FPGA-Plattformen verwendet werden.

Schlussfolgerung
Das ultimative Ziel besteht darin, die Entwicklung von CPU- und FPGA-Plattformen für eine breitere Benutzergruppe, wie beispielsweise die Softwareentwickler-Community, zu demokratisieren. Betrachtet man die Analogie zu Programmiersprachen, hat die IT-Branche über 50 Jahre gebraucht, bis sich Programmiersprachen zu benutzerfreundlichen Sprachen wie Python oder neuerdings Swift entwickelt haben. Ein ähnlicher Evolutionsprozess findet in der FPGA-Programmierindustrie statt. Es dauerte einige Zeit, bis die Akzeptanz von HLS-Tools von den Systemdesignern bestätigt wurde. Heute, mit dem Aufkommen von Lösungen auf Systemebene für Softwareentwickler, treten wir in eine neue Phase ein. Kommerzielle Tools wie SpaceStudio, SDSoC und Merlin Compiler zeugen von diesem Akzeptanzprozess. Es bleibt jedoch noch viel zu tun, um einen vollständig automatisierten und optimierten Prozess für alle Compiler zu haben, die auf CPU- und FPGA-Plattformen abzielen.

Guy Bois, Ing., PhD ist Gründer von Space Codesign Systems und Professor am Department of Software and Computer Engineering der Polytechnique Montréal. Guy hat an vielen F&E-Projekten in Zusammenarbeit mit Branchenführern wie STMicroelectronics, Grass Valley, PMC Sierra, Design Workshops Technologies und Cadabra Systems teilgenommen. Guys Forschungsexpertise im Bereich Hardware-/Software-Codesign führte zur Kommerzialisierung der Lösung und zur Gründung von SpaceStudio von Space Codesign Systems Inc.