Warum sind FPGAs nicht allgegenwärtig?

Wenn ich etwas über FPGAs verstehe, handelt es sich im Grunde genommen um vollständig konfigurierbare Logikgatterschaltungen. So kann man mit ihnen alles gestalten. Man kann alles so individuell wie möglich gestalten und somit die gleichen Ziele auf eine weitaus effizientere Weise erreichen, als dies mit einem Mikrocontroller möglich ist. Auf diese Weise sieht es so aus, als würde ein FPGA jeden Tag und zu jeder Zeit einen Mikrocontroller schlagen. Meine Frage ist also, ob FPGAs wirklich so großartig sind, was sie davon abhält, viel häufiger als Mikrocontroller zu sein. Aus dieser Sicht scheint es mir, dass FPGAs Mikrocontroller schon vor langer Zeit ausgemerzt haben sollten. Warum ist das nicht der Fall? Ist es der Preis, die Schwierigkeit, ein FPGA zu programmieren, oder etwas ganz anderes?

Sie ignorieren viele Faktoren, die bei der Auswahl des Designs eine Rolle spielen:

1. Kosten . FPGAs sind bei gleicher Komplexität der Logik teurer als Mikros.

2. Logische Komplexität . Ausführbarer Code kann eine weitaus kompliziertere Logik implementieren als die gleiche Anzahl von Gattern in dem direkt verwendeten Mikro.

3. Einfache Entwicklung . Es ist einfacher, ausführbaren Code zu schreiben, als Logik für alle außer kleinen Problemen zu definieren. Selbst bescheidene Mikrocontroller-Projekte enthalten Tausende von Codezeilen. Das Entwickeln der äquivalenten Logikdefinitionen würde viel länger dauern und das Debuggen und Überprüfen erheblich erschweren.

4. Leistungsaufnahme . Da FPGAs für Hochgeschwindigkeitsvorgänge vorgesehen sind, die von Mikros nicht verarbeitet werden können (sonst würden Sie ein Mikro verwenden), sind sie nicht für geringen Stromverbrauch optimiert. Dies macht sie für einige Niedrigenergieanwendungen ungeeignet. Einige Mikros haben Schlafströme unter 1 µA und können mit nur wenigen µA bei langsamen Taktraten betrieben werden. Versuchen Sie, ein FPGA zu finden, das dies ermöglicht.

Die Hauptvorteile von FPGAs gegenüber Mikros sind, dass sie schneller sind und mehr Dinge parallel erledigen können. Ansonsten verwenden Sie lieber ein Mikro. Daher beginnen Sie im Designprozess normalerweise mit einem Mikro und gehen dann widerwillig zu einem FPGA, wenn Sie wirklich die Geschwindigkeit und / oder den gleichzeitigen Hochgeschwindigkeitsbetrieb benötigen. Selbst dann implementieren Sie nur die geschwindigkeitskritischen Teile in einem FPGA und belassen die Funktionen zur Steuerung der niedrigeren Geschwindigkeit und dergleichen im Mikro.

Ein Unterschied, den ich hier nicht näher kennengelernt habe, ist, dass FPGAs ganz anders verwendet werden und sich anders verhalten als Prozessoren.

Ein FPGA ist wirklich gut darin, genau dieselbe Aufgabe immer und immer wieder zu erledigen. Zum Beispiel die Verarbeitung von Video-, Audio- oder HF-Signalen. Oder Weiterleiten von Ethernet-Paketen. Oder den Flüssigkeitsfluss simulieren. In jeder Situation, in der Ihnen sehr schnell viele Daten der gleichen Art zur Verfügung stehen und Sie alle auf die gleiche Weise behandeln möchten. Oder Sie möchten denselben Algorithmus wiederholt ausführen. Das FPGA hat nicht wirklich "Aufgaben", die starten und stoppen [1]. Seine gesamte Aufgabe besteht darin, dasselbe mit den erhaltenen Daten zu tun, solange diese aktiv sind. Es schaltet nicht, es macht nichts anderes. Es ist die ultimative produktionslinie arbeiter. Es wird immer wieder dasselbe tun, so schnell es kann, für immer.

CPUs hingegen sind der Inbegriff für Flexibilität. Sie können so programmiert werden, dass sie alles gleichzeitig erledigen. Sie haben Aufgaben, die beginnen und enden, sie schalten, erledigen mehrere Aufgaben und wechseln ständig Funktionen.

Das FPGA und die CPU sind völlig gegensätzlich. Das Gut der CPU ist Zeit - es muss schneller erledigt werden. Je schneller Ihre Anwendung ausgeführt wird, desto besser.

Die Ware des FPGA ist der Weltraum. Ihr FPGA ist nur so groß und es gibt nur so viele verfügbare Gates, um die gewünschte Aufgabe auszuführen. In den meisten Fällen ist das Problem eher die Größe als die Geschwindigkeit [2].

Ein FPGA kann sich wie eine CPU verhalten. Sie können einen CPU-IP-Core in ein FPGA einbauen, dies ist jedoch aus den von anderen beschriebenen Gründen nur schwer zu rechtfertigen [3]. FPGA und CPU sind Gegensätze, beide haben ihre eigenen Stärken und Schwächen und haben dadurch ihren eigenen Platz.

Anmerkungen:

1) Ein FPGA könnte für verschiedene Aufgaben ausgelegt sein, aber selbst dann wäre es eine bestimmte Nummer, für die es vorkonstruiert wurde.

2) Geschwindigkeit ist auch eine FPGA-Designspezifikation. Es ist wirklich ein Kompromiss zwischen Geschwindigkeit und Größe.

3) Das Einsetzen einer CPU in ein FPGA erfolgt relativ häufig, jedoch von Fall zu Fall, abhängig von den spezifischen Anwendungen. Zum Beispiel, wenn Sie einen wirklich winzigen Mikrocontroller benötigen und über zusätzlichen FPGA-Speicherplatz verfügen.

Und zu guter Letzt: Diese Antwort ist eine große Vereinfachung - FPGAs werden auf äußerst vielfältige und komplexe Weise verwendet, und dies ist eine sehr kurze Übersicht über die Art und Weise, wie sie im Allgemeinen verwendet werden.

Wie Olin sagt, ist so etwas wie ein Mikro für viele Aufgaben effizienter, und Sie werden fast immer ein Mikro finden, das überall dort verwendet wird, wo ein FPGA erscheint. Die Fläche des verwendeten Siliziums (was sich nichtlinear in Kosten niederschlägt) und der Stromverbrauch sind viel geringer. Aus diesem Grund ist es nicht ungewöhnlich, eine "weiche" MCU auf einem FPGA zu implementieren. Die Kosten und die Leistung eines solchen Mikros sind jedoch überwältigend.

Einige moderne FPGAs enthalten einen oder mehrere "harte" Kerne, beispielsweise die allgegenwärtige ARM-Serie. Sie können auch dedizierte Speicherblöcke enthalten, da es wirklich ineffizient ist, Speicher aus Gates zu machen. Ein 32-Bit-Mikrokern nimmt in einem typischen FPGA einen winzigen Teil der Siliziumfläche ein, wodurch Sie eine Vorstellung von den relativen Kosten erhalten.

Die Entwicklung ist erheblich schwieriger, und IP ist in der Regel nicht so frei verfügbar wie für Mikros und dedizierte SOC-Lösungen, z. B. LCD-Controller, PCI-Schnittstellen und Ethernet-MACs. Der Grund ist zum Teil, dass sie durch die Offenlegung der HDL-Logikbeschreibungen das Design übertragen und nicht nur die Instanziierung des Designs. Ein weiterer Grund ist, dass die Leistung vom Layout der Logik im FPGA abhängt, was während der Entwicklung viel Aufwand erfordert.

Eine weitere Komplikation besteht darin, dass die meisten komplexen FPGAs für die Konfiguration auf RAM basieren und die Prozesskosten so hoch sind, dass ein externer nichtflüchtiger Speicher zum Speichern des Konfigurations- und Programmspeichers für eine beliebige MCU an Bord erforderlich ist. Dieser Speicher muss beim Einschalten in den RAM geladen werden.

FPGAs sind äußerst nützliche Werkzeuge in der Toolbox, werden jedoch in naher Zukunft MCUs oder ASICs nicht durchgängig ersetzen.

Die beste Verwendung von Silizium für einen Job ist ein ASIC, nichts Verschwendetes, aber sie haben eine enorme Lernkurve, NRE und Inflexibilität.

Es gibt zwei Möglichkeiten, Flexibilität in einen Chip einzubauen. a) Besitzen Sie eine platzoptimierte ALU und verwenden Sie sie immer wieder für gespeicherte Daten. Dies wird als MCU bezeichnet und erfordert eine große Menge Silizium, das „nichts tut“, den Programmspeicher, breite Busse, die von Gerät zu Gerät verkehren, und Buszugriffsschalter. b) Genaue Logik mit einigen optionalen platzoptimierten Teilen wie Multiplikatoren, kleinen RAMs und einfachen CPUs. Dies wird als FPGA bezeichnet und erfordert eine große Fläche an Silizium, die nichts zu tun hat, programmierbare Schalter und Verbindungsleitungen.

Mit diesen Strukturen eignen sich MCUs am besten für Aufgaben, die in serielle Blöcke unterteilt werden können, und FPGAs eignen sich am besten für Aufgaben, die einen Hochgeschwindigkeits-Parallelbetrieb erfordern. Wenn die Anwendung schwer ist und die Kosten von den Siliziumkosten dominiert werden, werden die beiden Typen auf natürliche Weise verwendet.

Wenn die Anwendung leicht, aber großvolumig ist, dominieren die Kosten eher durch Verpackung als durch Silizium, und jeder Typ ist rentabel. Altera hat einige sehr kleine FPGAs mit sehr geringem Stromverbrauch, die mit nur einem Dollar pro Handvoll MCUs konkurrieren können.

Bei Apps mit geringem Volumen dominieren in der Regel die Entwicklungskosten, und dort gewinnen MCUs, vorausgesetzt, sie haben die Geschwindigkeit

In Bezug auf Stromverbrauch und Siliziumnutzung ist ein FPGA im Vergleich zu einem Mikroprozessor sehr schlecht.

Ein FPGA verbraucht einen großen Teil seiner Siliziumfläche in der Logikkonfigurationsschaltung, was für ein Mikro nicht gilt. Es müssen viel mehr Verbindungen verfügbar sein, als für eine dedizierte Implementierung eines Mikroprozessors erforderlich wären.

Das FPGA verbraucht mehr Strom als ein dedizierter ASIC wie ein Mikroprozessor, da die Logik nicht so effizient implementiert ist.

Jede Funktion, die in einem FPGA implementiert werden kann, kann in einem dedizierten ASIC effizienter, kostengünstiger, mit geringerem Stromverbrauch, kleinerem Platinenplatz usw. ausgeführt werden. Dies setzt voraus, dass die Volumina groß genug sind, um das NRE auszugleichen.

Mikroprozessorbasierte d-Systeme und spätere Mikrocontroller haben einen enormen Funktionsumfang erreicht, indem sie viele der darin enthaltenen einzelnen Schaltkreise verwenden konnten, um viele verschiedene Aufgaben zu unterschiedlichen Zeiten zu erfüllen. Ich denke, es ist aufschlussreich, den 1976 entworfenen Arcade-Automaten Tank mit dem Game Combat zu vergleichen, der auf dem zweiten mikroprozessorgesteuerten Spielautomaten der Welt, dem Atari 2600, ausgeführt wird. Obwohl es einige Unterschiede im Gameplay gibt, wurde die Atari 2600-Hardware im Wesentlichen entworfen Spiele wie Tank zu minimalen Kosten zu implementieren; Die Tatsache, dass es möglich war, durch Einsetzen verschiedener ROM-Kassetten verschiedene Spiele zu spielen, war ein netter Bonus.

Das Spiel Panzer ermöglicht es zwei Spielern, Panzer über den Bildschirm zu fahren und Schüsse aufeinander abzufeuern. Es hat "Slip" -Zähler für die X- und Y-Position jedes Panzers, die X- und Y-Position jedes Spielers, einen Aufwärts- / Abwärtszähler für den Winkel jedes Spielers und den Schusswinkel jedes Spielers, einen Zähler für die Punktzahl jedes Spielers, X- und Y-Raster -Positionszähler und viele Steuerschaltkreise über diesen Dingen. Es verfügt über Hardware zum Abrufen und Anzeigen von Spielfelddaten aus dem ROM sowie über Hardware zum Abrufen und Anzeigen von Formen für die Panzer der beiden Spieler und Punktzahlen aus dem ROM.

Der Atari 2600 verfügt über einen Schlupfzähler für die horizontalen Positionen von jeweils zwei Spielerobjekten, von jeweils zwei Raketenobjekten, und über ein zusätzliches Objekt namens "Ball", das im Kampf nicht verwendet wird, aber in einigen anderen Spielen verwendet wird. Für jedes der Spielerobjekte verfügt es über Hardware, um ein in einem 8-Bit-Latch gespeichertes Muster sowie einen "verzögerten" 8-Bit-Latch für jeden Spieler auszugeben, der jedes Mal in den primären 8-Bit-Latch des anderen Spielers kopiert wird Form wird aktualisiert. Es hat auch einen horizontalen Strahlpositionszähler und ein 20-Bit-Latch in Form eines Spielfelds, das zweimal pro Abtastzeile auf dem Bildschirm ausgegeben wird, wobei die Kopie auf der rechten Seite entweder als Wiederholung oder als Reflexion der linken Seite erscheint. Es hat Hardware, um Kollisionen zu erkennen, aber nichts als Folge davon zu tun. Das tut es nicht Hardware für die vertikalen Positionen von Objekten, die vertikale Position des Rasterstrahls (!) sowie Hardware für die Punktezählung, die Punkteanzeige, die Spieldauer usw.

Alle Funktionen, bei denen der 2600 die Hardware auslässt, werden von der Software in der Kassette ausgeführt. Die vertikale Position jedes Objekts muss nur einmal pro Scan-Zeile mit der Raster-Beam-Position verglichen werden. Die Punktzahl des Spielers und die verbleibende Spielzeit müssen nur einmal pro Frame aktualisiert werden. Die Punktzahlen der Spieler werden in Scan-Zeilen über dem Spielfeld gespeichert und kann daher die gleiche Hardware verwenden, die für das Spielfeld usw. verwendet wird.

Der normale Ansatz zur Implementierung eines Spiels wie "Tank" in einem FPGA besteht darin, getrennte Schaltkreise für verschiedene Funktionen zu verwenden, ähnlich wie es der 1976er Arcade-Automat tat. Ein solcher Ansatz würde funktionieren, aber eine erhebliche Menge an Hardware verwenden. Ein mikroprozessorbasierter Ansatz könnte mehr als die Hälfte dieser Hardware für das Hinzufügen eines Mikroprozessors einsparen, der wahrscheinlich weniger Schaltkreise enthält als die ersetzte Hardware (der 2600 könnte Spiele implementieren, die weitaus ausgefeilter sind als Tank, für die viel mehr Hardware erforderlich wäre) wenn sie keinen Mikroprozessor benutzen).

FPGAs eignen sich hervorragend für den Fall, dass ein Gerät benötigt wird, das viele einfache Aufgaben gleichzeitig ausführen kann . Mikroprozessor-basierte (oder Mikrocontroller-basierte) Systeme sind im Allgemeinen jedoch besser, wenn viele Aufgaben ausgeführt werden müssen, diese jedoch nicht gleichzeitig verarbeitet werden müssen, da sie die Verwendung einer kleinen Menge vereinfachen der Schaltung eine große Anzahl von unterschiedlichen Zwecken zu erreichen.

Es sind nur die Kosten. Wenn ein Mikro nur 30 Cent kosten kann, liegt ein billiger FPGA im Bereich von 5 US-Dollar. Die Kosten scheinen vielleicht nicht so hoch zu sein, aber wenn Sie eine Million eines furzenden Spielzeugs für 10 US-Dollar verkaufen, dann ist der Preis für das FPGA unter dem Strich das Gegenteil.

Um die anderen sehr guten Antworten zu ergänzen, denke ich, dass die Einführung von FPGA auch eine Frage der Domäne ist: Zum Beispiel werden FPGA-Boards für neuromorphe Geräte immer allgegenwärtiger, weil ein großer Bedarf an Parallelität besteht, was ein starker Punkt ist von FPGA.

Wenn Sie den Trend, den wir für neuromorphe Geräte sehen, extrapolieren, können Sie sich vorstellen, dass andere Felder, die auf Parallelität basieren oder diese kritisch erfordern, wahrscheinlich viel mehr FPGAs verwenden werden. Vielleicht wird FPGA für Consumer-Produkte nicht allgegenwärtig sein, aber es kann für bestimmte Domänen sein, da es derzeit für neuromorphe Geräte zu sein scheint.