Im rechnerischen Bereich bezeichnen FPGAs sowie programmierbare SoCs eine Klasse von Geräten, die sich von CPU-, MCU-, DSP- und GPU-Geräten unterscheiden. FPGAs versorgen Entwickler mit Implementierungen, die höheren Durchsatz, geringere Latenz und verbesserten Determinismus bieten.
Im rechnerischen Bereich bezeichnen FPGAs sowie programmierbare SoCs eine Klasse von Geräten, die sich von CPU-, MCU-, DSP- und GPU-Geräten unterscheiden. FPGAs versorgen Entwickler mit Implementierungen, die höheren Durchsatz, geringere Latenz und verbesserten Determinismus bieten.
Sowohl FPGAs als auch programmierbare SoCs beinhalten programmierbare Logikzellen wie zum Beispiel Zuordnungstabellen, Register und Block-RAMs. Wenn ein Entwickler eine programmierbare Logiklösung kreiert, sind es die Konfiguration sowie die Verbindungen dieser Logikzellen, welche der Entwickler definiert.
Da der Entwickler die Konfiguration der Logikzellen beschreibt, und nicht etwa die Befehlsfolge zur Ausführung, führt dies zu einem deutlich anderen Entwicklungsablauf. Dieser Unterschied stellt Entwickler weiterhin vor neue Herausforderungen, wie etwa:
- Verifizierung — Wie debuggt und verifiziert der Entwickler die Funktionalität?
- Resourceverteilung — Hat das Gerät genug Logikresources, um das Design zu implementieren?
- Timing-Closure — Können die verwendeten Logikzellen nach Bedarf verbunden werden und immer noch die gewünschte Betriebsfrequenz erreichen?
- Verlustleistung — Ist die Verlustleistung des endgültigen Designs annehmbar für die Spannungsversorgungen und die thermische Umgebung?
Design-Erfassung
Seit ihrer Einführung im Jahr 1984 hat sich die Art und Weise, wie programmierbare Logik-Designs erfasst werden, maßgeblich verändert. Im Laufe dieses Fortschritts hat sich die Design-Eingabe von der Definition logischer Gleichungen für jede Logikzelle zur schematischen Erfassung von Logikschaltkreisen, dem Gebrauch von Hardwarebeschreibungssprachen sowie, in jüngerer Vergangenheit, High-Level-Synthese weiterentwickelt.
Einer der Hauptgründe für das steigende Abstraktionsniveau in der Geräteprogrammierung ist natürlich die größere Kapazität und Leistungsfähigkeit ebenjener Geräte.
Die meisten modernen Designs werden mittels einer Hardwarebeschreibungssprache (HDL) wie etwa Verilog oder VHDL beschrieben. Beide dieser Sprachen erlauben es dem Entwickler, die auf der Register-Transfer-Ebene (RTL) zu implementierende gewünschte Funktionalität zu beschreiben. Ein RTL-Design beschreiben heißt, dass der Entwickler ein synchrones Logik-Design sowie den Transfer von Informationen zwischen Registern beschreibt—etwa zwischen Zustandsmaschinen und Zählvariablen.
Während HDL-Fragen die Konstrukte, die von einer programmierbaren Sprache zu erwarten wären, beinhaltet (z.B. mit Dateien arbeiten), kann nur ein limitiertes Subset der Sprache dazu verwendet werden, eine programmierbare Logiklösung zu kreieren. Die restlichen Konstrukte werden während der Verifizierung des Designs verwendet.
In zunehmendem Maße jedoch verwenden Entwickler programmierbarer Logiklösungen Higher-Level-Sprachen wie etwa C, C++, OpenCL oder Matlab/Simulink zur Design-Erfassung. Diese Sprachen werden zusammen mit einem High-Level-Synthesewerkzeug verwendet, zum Beispiel Vivado HLx oder den Intel HLS Compiler, welches dafür verantwortlich ist, die High-Level-Sprache in eine VHDL- oder Verilog-Beschreibung umzuwandeln. Diese HDL-Beschreibung wird dann über den standardmäßigen FPGA-Entwicklungsablauf implementiert.
Wie bei allen anderen Entwicklungen, ob mit oder ohne Verwendung von HDL oder einer High-Level-Sprache, hat sich auch hier ein modularer Ansatz zum leichteren Verständnis sowie zur beliebigen Wiederverwendung bewährt.
Prüftisch
Während der Entwicklung jedes HDL- oder HLS-Moduls sind Tests erforderlich, um sicherzustellen, dass die Funktionalität wie gewünscht funktioniert. Der Prüftisch stimuliert hierbei die Inputs des Moduls und beobachtet die Resultate. In fortgeschrittenen Fällen erstellt er Berichte über das Verhalten der Outputsignale. Da wir die Transaktionen für jedes Register innerhalb des Designs simulieren, können Logiksimulationen viel langsamer ablaufen.
Obwohl er konzeptionell einem Software-Test-Harnisch ähnelt kann der Prüftisch eine detailliertere Interaktion verlangen, da jedes Signal und jede Datenleitung korrekt getrieben und geleitet werden müssen, um das Modul zu stimulieren. Am Prüftisch kommen die umfangreicheren Konstrukte der Sprache ins Spiel, während Stimulus-Einstellungen gelesen oder Resultate in Textdateien eingegeben werden.
Eins der Schlüsselelemente der Simulation ist der Test für Grenzwert-Situationen und Randbedingungen, die dazu führen können, dass das Modul nicht wie gewünscht funktioniert.
Um die fragliche Einheit am Prüftisch zu testen, wird ein HDL-Simulator wie der Vivado Simulator (der mit Vivado HLx geliefert wird) benötigt, da dieser es Entwicklern erlaubt, das Logikdesign zu simulieren.
Es ist allgemein üblich, das Design zu simulieren, bevor es innerhalb des Geräts implementiert wird. Dies bedeutet jedoch, dass die Zeitverzögerungen, die im implementierten Gerät auftreten (z.B. Rüst- und Wartezeiten), sich nicht in den Ergebnissen der Simulation niederschlagen. Daher wird lediglich die funktionale Leistung simuliert. Diese Informationen können zwar nach Implementierung des Designs rückwirkend in Simulationen eingetragen werden, doch dadurch verlängert sich die Simulationsdauer erheblich.
Implementierung
Wenn der Entwickler mit der funktionalen Performance zufrieden ist, folgt die letzte Entwicklungsstufe: die Implementierung.
Die Implementierung kann in vier verschiedene Stufen aufgeteilt werden: Synthese, Platzierung, Routing und Programmierdateierstellung. Obwohl die Implementierung in mehreren Stufen erfolgt, werden diese alle mit Hilfe eines vom jeweiligen Anbieter bereitgestellten proprietären Werkzeugs, z.B. Intel Quartus oder Xilinx Vivado, durchgeführt.
Bei der Synthese werden die HDL-Dateien zu einer Beschreibung der zu implementierenden Logikschaltkreise zusammengefasst. In dieser Hinsicht bestimmt die Synthese die Einstellungen der konfigurierbaren Logikzellen, Register und Block-RAMs sowie weiterer dedizierter Logikresources innerhalb des Zielgeräts. Während der Synthesephase findet der Großteil der Logikoptimierung sowie die Trimmung ungenutzter Signale und Variablen statt. Dies kann zu ungewollten Optimierungen oder Syntheseentscheidungen führen. Daher kann der Entwickler die Syntheseoptionen, -strategien und -optimierungen durch Syntheseeinschränkungen steuern. Die Einschränkungen sind textbasiert und lenken das Synthesewerkzeug bei seiner Ausführung.
Der Output der Synthese ist eine Netzliste, die das logische Verhalten des Designs beschreibt. Die nächste Phase der Implementierung besteht daraus, jede Logikfunktion physisch innerhalb des Geräts zu platzieren. Generell benutzt das Platzier-Tool dazu eingebaute Algorithmen, welche definieren, wie die Logikzellen in das Design passen. Falls dies jedoch gewünscht wird, kann der Benutzer die Platzierung der Logikzellen auch mit Hilfe von Platzierungseinschränkungen untersuchen und steuern. Dies ist sehr nützlich, wenn das Ziel ist, das Timing-Closure für das Design zu erfüllen.
Die zweitletzte Phase der Implementierung wird durchgeführt, nachdem die Logikfunktionen eingezeichnet worden sind. Diese eingezeichneten Resources müssen, wie vom Design angegeben, mit Hilfe der im Gerät verfügbaren Resources verbunden werden. Bei diesem Prozess, der sich „Routing“ nennt, verwenden die Routing-Algorithmen die gewünschte Timing-Performance, um zu versuchen, die gewünschte Betriebsfrequenz zu erreichen. Wird die gewünschte Betriebsfrequenz erreicht, nennt sich dies „Timing-Closure“, was bedeutet, dass jedes Register- und Taktelement in dem Design die erforderliche Rüst- und Wartezeit erreicht.
Sollte das Timing-Closure nicht erfüllt werden, bieten sich noch mehrere Ansätze an: die Auswahl einer anderen Implementierungsstrategie, das Updaten der Platzierungseinschränkungen, um Timing-kritische Blöcke näher aneinander zu rücken, sowie das Updaten des HDL-Designs, um eine optimalere Logikstruktur bei der Synthese zu implementieren.
Die letzte Stufe des Implementierungsprozesses ist die Erstellung einer Programmierdatei, die dazu dient, das Zielgerät zu konfigurieren. Nachdem dies erledigt ist, sind wir bereit, sie auf unser Gerät herunterzuladen und mit dem Spaß der Integration in das übergeordnete System zu beginnen.
Die Integration kann natürlich auch ihre ganz eigenen Herausforderungen für FPGA-Entwickler sowie Systemintegrierer mit sich bringen.
Fazit
Der FPGA-Entwicklungsprozess unterscheidet sich definitiv vom Prozess der Erstellung einer konventionelleren rechnerischen Lösung. Der Lernprozess in Bezug auf die Sprachen und Toolchains (insbesondere HLS) ist jedoch nicht so beschwerlich wie zunächst angenommen. Wenn sie genug Zeit darauf verwenden, diese Prozesse eingehend zu studieren, können Entwickler damit beginnen, FPGA-basierte Lösungen zu implementieren, die höheren Durchsatz, geringere Latenz und verbesserten Determinismus bieten.