FPGA oder Mikrocontroller?

| Autor / Redakteur: Christian Siemers * / Sebastian Gerstl

Speicherverteilung innerhalb eines FPGAs während der Planungsphase: Ab wann ist es sinnvoll, bei der Planung eines Designs auf ein FPGA statt einem reinen Mikrocontroller zu setzen?
Speicherverteilung innerhalb eines FPGAs während der Planungsphase: Ab wann ist es sinnvoll, bei der Planung eines Designs auf ein FPGA statt einem reinen Mikrocontroller zu setzen? ( MemoryPlanAhead2SergeMoutou / Wikimedia Commons / BY-SA 3.0)

FPGAs haben in vielen Applikationsbereichen den Mikroprozessor verdrängt. Aber ist so ein Umstieg immer sinnvoll? Wann lohnt sich der Einsatz eines FPGAs, und wann sollte man im Design besser beim klassischen Mikrocontroller bleiben?

Ist uns allen eigentlich klar, was in den letzten 70 Jahren an technischer Entwicklung passiert ist? Seit der Einführung des Rechnermodells (1946), der Entwicklung des Transistors (1948) und des integrierten Schaltkreises (1958), des Mikroprozessors (1969/71) und des PLDs oder Programmierbaren Logikbausteins (1977)? Wir sind von Elektronik, besser, programmierbarer Elektronik umgeben. Und von Produkten, die durch in Software implementierte Algorithmen optimiert wurden.

Programmierbarkeit steht für Mikroprozessor genauso wie Mikroprozessor für Programmierbarkeit steht. Eine Identität sozusagen? Scheint so, ist aber falsch. Denn es gibt da noch die FPGAs, deren Urahnen die bereits 1977 angebotenen PLDs darstellen. Nur ist die Frage, warum wir uns überhaupt mit diesen abgeben sollen, wo es doch die hochgetakteten, superschnellen Mikroprozessoren gibt. Diese Frage ist schnell beantwortet: Weil FPGAs den Mikrocontrollern in manchen Gebieten einfach drastisch überlegen sind.

Mikroprozessoren sind unschlagbar bei Algorithmen, die allein Rechnen, ohne ernsthaften Außenkontakt zu enthalten. So sind beispielsweise Produktoptimierung, Klimarechnungen, Schreibprogramme etc. so von der Echtzeit entkoppelt, dass ein Mikroprozessor sie mehr oder weniger bequem ausführen kann, ohne dass es zu Komplikationen kommen kann.

Echtzeit aber, harte Echtzeit, bei der die charakteristische Reaktion vielleicht auch noch im Bereich von unter Millisekunden liegt, bringt Mikroprozessoren und Softwareentwickler ins Schwitzen. Das zentrale Problem ist dabei, dass sich die Reaktionszeit zwar als formale Anforderung formulieren lässt. Sie kann aber nicht in einer Programmiersprache so eingegeben werden, dass ein Compiler in der Lage wäre, diese Anforderung auch umzusetzen. Man spricht dabei von extra-funktionalen Requirements – hört sich schön an, ist es aber nicht! Denn dies bedeutet, dass etwas realisiert werden soll, ohne dass man wirklich Werkzeuge dafür in der Hand hat.

Optimierungsziele für programmierbare Systeme

Aber noch einmal einen Schritt zurück: Welche Optimierungsziele für die Entwicklung von elektronischen Systemen existieren eigentlich, wobei mit Entwicklung alle Facetten, also die Tools, Sprachen, Vorgehensweisen, Zielverhalten etc. gemeint sind? Hier fallen einem sehr schnell 3 bis 4 wirkliche Zielfunktionen ein:

  • Möglichkeit zur Aufnahme großer, komplexer Algorithmen
  • möglichst hohe Reaktions- oder Ereignisdichte (Reaktivität),
  • einfache Entwicklung und Pflegbarkeit,
  • innere und äußere Sicherheit (Safety, Security)

Wenn man einmal den Punkt „Safety & Security“ fortlässt, der sich erst in jüngerer Zeit herausgebildet hat (jetzt aber natürlich massiv wichtig wird), zeigt sich das Spannungsdreieck der Optimierungsziele. Dies offenbart zugleich, dass weder Mikroprozessoren noch FPGAs eine optimale Abdeckung bewirken. Denn ihre Stärken liegen zum Teil in stark unterschiedlichen Bereichen.

Einfache Entwicklung

Die Programmentwicklungssprachen sind in diesem Dreieck eine außerordentlich wichtige Größe, denn sie stellen letztendlich das Interface für die Entwicklungsmannschaft dar. Hier ist die Welt der Von-Neumann-basierten Mikroprozessoren stark im Vorteil – zumindest solange man sich auf die Entwicklung für einen Prozessor beschränkt. In diesem Fall kann man nämlich von einem komplett sequenziellen Programmverhalten ausgehen. Soll heißen: was im Programmcode „weiter oben“ steht, wird auch vorher ausgeführt. Dieses Verhalten wird im- und explizit genutzt, so dass auch Variablen an mehreren Stellen im Programmcode einen neuen Wert zugewiesen bekommen können und dies auch bedingt erfolgen kann (was zu so genannten impliziten Haltebedingungen führt).

Um es klar zu sagen: Bei der Entwicklung für FPGAs gilt dieses Verhalten nicht! Nur in Ausnahmefällen kann z.B. zur Beschreibung von Algorithmen hiervon abgewichen werden. Das macht die Entwicklung definitiv komplexer, denn es wird zunächst einmal „alles zu allem parallel“ bearbeitet. Sind also jetzt Rechnungen voneinander abhängig, so dass sie in einer Reihenfolge durchgeführt werden müssen, reicht es nicht mehr, sie untereinander zu schreiben. Die Reihenfolge muss explizit erzwungen werden.

Allerdings: Ähnliches gilt auch für die Verteilung einer Applikation auf mehrere Prozessoren. Auch hier können einzelne Programmteile unabhängig voneinander ausführen, so dass keine Reihenfolge der einzelnen Programme eingehalten wird. Ist diese notwendig, dann muss man explizit synchronisieren, was die Entwicklung verkompliziert.

In einem gewissen Sinn kann man also FPGAs nicht nur als Multi- oder ManyCores bezeichnen; es sind dann gewissermaßen bereits HyperCores.

Komplexe Algorithmen

Mikroprozessoren rechnen in der Zeit („Computing in Time“), d.h., der Algorithmus wird auf die sequentielle Folge von fixierten Instruktionen abgebildet. Der Vorteil: Man benötigt nur genügend Speicher, der aktuell nicht besonders teuer ist – und spätestens bei 64-bit Adressen so groß ist, dass wir ihn kaum mehr füllen können. Hat man also genügend Zeit (eine scheinbar „freie Ressource“), kann der Algorithmus hier praktisch beliebig komplex werden.

FPGAs rechnen auf der Siliziumfläche („Computing in Space“), d.h. der Algorithmus wird hier auf eine einzelne, dann konfigurierbare Instruktion abgebildet, die mit wachsender Komplexität auch mehr Fläche benötigt. Fläche ist aber nur begrenzt vorhanden, eine „knappe Ressource“. Das bedeutet in der Praxis, dass FPGAs für komplexe, irreguläre Algorithmen weniger gut geeignet sind.

Eine gewisse Ausnahme bilden so genannte reguläre Algorithmen, bei denen der Algorithmus selbst nicht viele Verzweigungen besitzt und somit eher klein, die Datenmenge allerdings sehr groß ist. Typische Anwendungen sind Filteralgorithmen, Streaming oder Kommunikation im Allgemeinen. Hier können FPGAs gut mithalten, solange sie nicht allzu viele Daten speichern müssen. Genau diese Applikationsteile sind typisch für Kommunikation (input/outut, I/O) bzw. die Konnektivität.

Reaktivität bzw. Ereignisdichte

Im Konnektivitätsbereich, sprich im Anschluss an die Außenwelt, zeigen die FPGAs dann einen enormen Vorteil. Während ein Mikroprozessor nur eine Aktivität pro Takt durchführen kann – und damit auch nur auf einen Außenkontakt reagieren kann - stellt dies für FPGAs überhaupt kein Problem dar, solange die Fläche ausreicht: Jeder Außenkontakt, jedes Peripherieteil wird unabhängig von den anderen bedient, auch parallel zueinander.

Ist diese Erkenntnis wichtig für die Entwicklung? Ein Blick auf typische Mikrocontroller verrät, dass dort sehr viel konfigurierbare Peripherie eingebaut ist, aus eben dem gleichen Grund: Ein konfigurierbares Peripherieelement arbeitet nämlich unabhängig vom Mikroprozessor. Studien haben bereits vor Jahren gezeigt, dass ein Mikroprozessorkern in einem Mikrocontroller um mehr als dreifach höher getaktet werden müsste, wenn er auch noch alle Arbeiten der Peripherie durchführen würde, also z.B. Serialisierung, USB, Timer etc.. Ansonsten wäre er nicht in der Lage, auch noch die Performance zu halten, von Echtzeit einmal ganz abgesehen. Dies wird im folgenden Bild dargestellt: Das Verhältnis I/O zu µP besagt, wie viel Arbeit der Mikroprozessor mehr übernehmen müsste, wenn die Abläufe in der Peripherie im Programm selbst übernommen werden müssten.

Nun ist die Peripherie bei Mikrocontrollern ja durchaus vorhanden und braucht nur noch konfiguriert zu werden; ist das Problem aber nicht mit einer Konfiguration lösbar, muss der Teilalgorithmus auf dem Mikroprozessor laufen und belastet diesen, denn Konfigurierbarkeit ist bei weitem nicht mit Programmierbarkeit gleichzusetzen.

Wann also FPGA, wann Mikrocontroller?

Setzen wir FPGAs für unsere Applikationen ein, erhalten wir eine stark verbesserte Reaktivität – und leider auch mehr Entwicklungsarbeit, zumindest andere Sprachen, die gewöhnungsbedürftig sind. Im Zeitalter von MATLAB/Simulink, das VHDL-Code generieren kann und zumindest für Prototypen gut geeignet ist, von Ansätzen, C/C++-Programme in VHDL zu transformieren [1] oder FPGAs für Speicherprogrammierbare Steuerung (SPS) einzusetzen und diese Applikationen in der (imperativen) Sprache ST (Strukturierter Text) entwickeln zu können [2] zeigt sich jedoch, dass die Frage der Entwicklungssprache zumindest in Teilbereichen angegangen wird.

Die Antwort lautet also: Benötigen Sie starke Reaktivität, ziehen Sie FPGAs ins Kalkül.

Literaturhinweise:

[1] http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_3/ug902-vivado-high-level-synthesis.pdf[2] Christian Siemers, René Fritzsche, Alfons Austerhoff, Marco Zander: „High-Speed-SPS arbeitet zykluszeitenfrei und ist gut vernetzbar.“ ElektronikPraxis 50(21), 2014, S. 32-35

* Prof. Dr. Christian Siemers lehrt am Institut für Informatik an der TU Clausthal und an der Fachhochschule Nordhausen. Kontakt:siemers@fh-nordhausen.de.

Kommentar zu diesem Artikel abgeben
Nach meiner Erfahrung macht sich eine Kombination aus MC und FPGA am besten. Ich arbeite seit 1995...  lesen
posted am 17.06.2019 um 09:19 von gschoenfelder

In 1977 gab es zwar schon Progr.bare ICs, die waren aber nicht vergleichbar (waren FPLAs, extrem...  lesen
posted am 11.06.2019 um 18:05 von Unregistriert

vielleicht eine geeignete Ergänzung: VHDL schien mir (und Studenten) ein Graus, bis ich The...  lesen
posted am 23.09.2015 um 17:47 von Unregistriert


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 43604579 / FPGA)