Warum sind FPGAs nicht allgegenwärtig?

Sie ignorieren viele Faktoren, die bei Designentscheidungen eine Rolle spielen:

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

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

3. Leichtigkeit der Entwicklung . Es ist einfacher, ausführbaren Code zu schreiben, als Logik für alle außer kleinen Problemen zu definieren. Selbst bescheidene Mikrocontroller-Projekte haben Tausende von Codezeilen. Die Entwicklung der äquivalenten Logikdefinitionen würde viel länger dauern und viel schwieriger zu debuggen und zu verifizieren sein.

4. Stromverbrauch . Da FPGAs für Hochgeschwindigkeitsoperationen gedacht sind, die Mikros nicht bewältigen können (sonst würden Sie ein Mikro verwenden), sind sie nicht für geringen Stromverbrauch optimiert. Dies macht sie für einige Anwendungen mit geringer Leistung ungeeignet. Einige Mikros haben Schlafströme unter 1 µA und können bei langsamen Taktraten mit nur wenigen µA betrieben werden. Versuchen Sie, einen FPGA zu finden, der dies kann.

Die Hauptvorteile von FPGAs gegenüber Mikros bestehen darin, dass sie schneller sind und mehr Dinge parallel erledigen können. Ansonsten nimmst du lieber ein Mikro. Daher beginnen Sie im Designprozess normalerweise mit einem Mikro und gehen dann widerwillig zu einem FPGA über, 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 langsameren Steuerfunktionen und dergleichen im Mikro.

Ein Unterschied, auf den ich hier nicht näher eingegangen bin, ist, dass FPGAs völlig anders verwendet werden und sich anders verhalten als Prozessoren.

Ein FPGA ist wirklich gut darin, immer wieder genau die gleiche Aufgabe zu erledigen. Zum Beispiel die Verarbeitung von Video-, Audio- oder HF-Signalen. Oder Routing von Ethernet-Paketen. Oder die Simulation von Flüssigkeitsströmungen. Jede Situation, in der Sie sehr schnell mit einer Menge gleicher Daten konfrontiert werden 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, mit allen Daten, die es erhält, dasselbe zu tun, solange es eingeschaltet ist. Es schaltet nicht die Gänge, es tut nichts anderes. Es ist der ultimative Arbeiter am Fließband. Es wird immer wieder dasselbe tun, so schnell es kann, für immer.

CPUs hingegen sind der Inbegriff von Flexibilität. Sie können so programmiert werden, dass sie überhaupt alles tun, und sie können so programmiert werden, dass sie mehrere verschiedene Dinge gleichzeitig tun. Sie haben Aufgaben, die beginnen und aufhören, sie wechseln die Gänge, multitasken, wechseln ständig und wechseln Funktionen.

Das FPGA und die CPU sind komplette Gegensätze. Das Gut der CPU ist Zeit – sie muss Dinge schneller erledigen. Je schneller Ihre Anwendung läuft, desto besser.

Die Ware des FPGA ist Raum. Ihr FPGA ist nur so groß, und es gibt nur so viele verfügbare Gatter, um die gewünschte Aufgabe auszuführen. Meistens geht es mehr um die Größe als um die Geschwindigkeit[2].

Es ist möglich, ein FPGA dazu zu bringen, sich wie eine CPU zu verhalten. Sie können einen CPU-IP-Kern in ein FPGA einbauen, es ist jedoch aufgrund der von anderen beschriebenen Gründe sehr schwer zu rechtfertigen[3]. Das FPGA und die CPU sind Gegensätze, die beide ihre eigenen Stärken und Schwächen haben und daher beide ihren eigenen Platz haben.

Anmerkungen:

1) Ein FPGA könnte entworfen werden, um verschiedene Aufgaben auszuführen, aber selbst dann wäre es eine bestimmte Anzahl, für die es vorab entworfen 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 wird relativ häufig durchgeführt, jedoch von Fall zu Fall, abhängig von den spezifischen Anwendungen. Zum Beispiel, wenn Sie einen wirklich winzigen Mikrocontroller benötigen und zusätzlichen FPGA-Platz haben.

Und zum Schluss: Diese Antwort ist eine große Vereinfachung - FPGAs werden auf enorm vielfältige und komplexe Weise verwendet, und dies ist ein sehr kurzer Überblick ü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 finden fast immer einen Mikro, der überall dort verwendet wird, wo ein FPGA auftaucht. Die verwendete Siliziumfläche (die 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, aber die Kosten und die Leistung eines solchen Mikros sind nicht gerade berauschend.

Einige moderne FPGAs enthalten einen oder mehrere "harte" Kerne, wie die allgegenwärtige ARM-Serie. Außerdem können sie dedizierte Speicherblöcke enthalten, da es wirklich ineffizient ist, Speicher aus Gattern zu machen. Ein 32-Bit-Mikrokern nimmt in einem typischen FPGA einen winzigen Teil der Siliziumfläche ein, was Ihnen eine Vorstellung von den relativen Kosten gibt.

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

Eine weitere Komplikation besteht darin, dass die meisten komplexen FPGAs für die Konfiguration RAM-basiert sind und die Prozesskosten so hoch sind, dass ein externer nichtflüchtiger Speicher erforderlich ist, um die Konfiguration und den Programmspeicher für jede MCU an Bord zu speichern. Dieser Speicher muss beim Einschalten in den RAM geladen werden.

FPGAs sind äußerst nützliche Werkzeuge in der Toolbox, aber sie werden MCUs oder ASICs in absehbarer Zeit nicht universell ersetzen.

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

Es gibt zwei Möglichkeiten, Flexibilität in einen Chip einzubauen. a) Haben Sie eine platzoptimierte ALU und verwenden Sie sie immer wieder für gespeicherte Daten. Dies wird als MCU bezeichnet und erfordert einen riesigen Siliziumbereich, der „nichts tut“, den Programmspeicher, breite Busse, die von Einheit zu Einheit verlaufen, und Buszugriffsschalter. b) Sie haben eine feinkörnige Logik mit einigen optionalen platzoptimierten Teilen wie Multiplikatoren, kleinen RAMs und einfachen CPUs. Dies wird als FPGA bezeichnet und erfordert eine riesige Siliziumfläche, die „nichts tut“, programmierbare Schalter und Verbindungsleitungen.

Offensichtlich funktionieren MCUs mit diesen Strukturen am besten für Aufgaben, die in serielle Blöcke zerlegt werden können, und FPGAs funktionieren am besten für Aufgaben, die einen parallelen Hochgeschwindigkeitsbetrieb erfordern. Wenn die Anwendung umfangreich ist und die Kosten von den Siliziumkosten dominiert werden, werden die beiden Typen natürlich so verwendet.

Wenn es sich um eine leichte, aber hochvolumige Anwendung handelt, werden die Kosten eher von der Verpackung als von Silizium dominiert, und beide Typen sind rentabel. Altera hat einige sehr kleine FPGAs mit sehr geringem Stromverbrauch, die mit Ein-Dollar-pro-Handvoll-MCUs konkurrieren können.

Bei Anwendungen mit geringem Volumen dominieren tendenziell 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ßteil seiner Siliziumfläche in der Logikkonfigurationsschaltung, was bei einem Mikro nicht zutrifft. Es müssen viel mehr Zwischenverbindungen verfügbar sein, als bei einer dedizierten Implementierung eines Mikroprozessors benötigt würden.

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 effizienter, billiger, mit geringerem Stromverbrauch, weniger Platz auf der Platine usw. in einem dedizierten ASIC ausgeführt werden. Dies setzt voraus, dass die Volumina groß genug sind, um die NRE auszugleichen.

Auf Mikroprozessoren basierende D-Systeme und später Mikrocontroller konnten durch ihre Fähigkeit, viele der darin enthaltenen einzelnen Schaltungsteile zu verwenden, um viele verschiedene Aufgaben zu unterschiedlichen Zeiten zu erfüllen, einen enormen Grad an Funktionalität erreichen. Ich denke, es ist aufschlussreich, den 1976 entworfenen Arcade-Automaten Tank mit dem Spiel Combat zu vergleichen, das auf dem zweiten mikroprozessorgesteuerten Spielautomaten der Welt, dem Atari 2600, läuft. Obwohl es einige Unterschiede im Gameplay gibt, wurde die Atari 2600-Hardware im Wesentlichen entwickelt Spiele wie Tank zu minimalen Kosten zu implementieren; Die Tatsache, dass durch Einlegen verschiedener ROM-Cartridges verschiedene Spiele gespielt werden konnten, war ein netter Bonus.

Das Spiel Tank ermöglicht es zwei Spielern, Panzer über den Bildschirm zu fahren und sich gegenseitig zu beschießen. Es hat "Schlupf"-Zähler für die X- und Y-Position jedes Panzers, die X- und Y-Position der Schüsse 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-Rasterstrahl -Positionszähler und jede Menge Steuerschaltkreise obendrauf. Es verfügt über Hardware, um Spielfelddaten aus dem ROM abzurufen und anzuzeigen, sowie über Hardware, um Formen für die Panzer der beiden Spieler und Ergebnisse aus dem ROM abzurufen und diese anzuzeigen.

Der Atari 2600 hat einen Rutschzähler für die horizontalen Positionen von jedem von zwei Spielerobjekten, jedem von zwei Raketenobjekten und einem zusätzlichen Objekt namens "Ball", das nicht im Kampf verwendet wird, aber in einigen anderen Spielen verwendet wird. Für jedes der Player-Objekte verfügt es über Hardware zum Ausgeben eines in einem 8-Bit-Latch gespeicherten Musters sowie eines "verzögerten" 8-Bit-Latch für jeden Player, der immer dann in den primären 8-Bit-Latch kopiert wird, wenn der andere Spieler ist Form wird aktualisiert. Es hat auch einen horizontalen Strahlpositionszähler und einen 20-Bit-Latch in Spielfeldform, der zweimal pro Abtastzeile an den Bildschirm ausgegeben wird, wobei die rechte Kopie entweder als Wiederholung oder als Reflexion der linken erscheint. Es verfügt über Hardware, um Kollisionen zu erkennen, aber nichts als Folge davon zu unternehmen. Das tut es nichthat keine Hardware für die vertikalen Positionen von Objekten, noch die vertikale Position des Rasterstrahls (!), noch hat es irgendeine Hardware, die mit der Punktespeicherung, Punkteanzeige, Spieldauer usw. verbunden ist.

Alle Funktionen, für die der 2600 auf Hardware verzichtet, werden von der Software in der Kassette übernommen. Es ist nur erforderlich, die vertikale Position jedes Objekts gegen die Rasterstrahlposition einmal pro Scanlinie zu überprüfen, es ist nur erforderlich, die Punktzahl des Spielers und die verbleibende Spielzeit höchstens einmal pro Frame zu aktualisieren, die Punktzahlen der Spieler werden auf Scanlinien über dem Spielfeld gespeichert und können daher dieselbe Hardware verwenden, die für das Spielfeld usw. verwendet wird.

Der normale Ansatz zur Implementierung eines Spiels wie "Tank" in einem FPGA wäre die Verwendung separater Schaltkreise für verschiedene Funktionen, ähnlich wie es der Arcade-Automat von 1976 tat. Ein solcher Ansatz würde funktionieren, aber eine beträchtliche Menge an Hardware verwenden. Ein mikroprozessorbasierter Ansatz könnte mehr als die Hälfte dieser Hardware eliminieren und dafür einen Mikroprozessor hinzufügen, der wahrscheinlich weniger Schaltkreise enthalten würde als die Hardware, die er ersetzt (der 2600 könnte weit ausgefeiltere Spiele implementieren als Tank, was viel mehr Hardware erfordern würde). wenn sie keinen Mikroprozessor verwenden).

FPGAs eignen sich hervorragend für Fälle, in denen ein Gerät benötigt wird, das viele einfache Aufgaben gleichzeitig ausführen kann . Mikroprozessorbasierte (oder mikrocontrollerbasierte) Systeme sind jedoch im Allgemeinen besser, wenn viele Aufgaben ausgeführt werden müssen, die jedoch nicht gleichzeitig verarbeitet werden müssen, da sie es einfach machen, eine kleine Menge zu verwenden von Schaltkreisen, um eine große Anzahl unterschiedlicher Zwecke zu erfüllen.

Nur um die anderen sehr guten Antworten zu ergänzen, denke ich, dass die Einführung von FPGA auch eine Frage der Domäne ist: Beispielsweise werden FPGA-Boards für neuromorphe Geräte ziemlich allgegenwärtig, weil ein enormer Bedarf an Parallelität besteht, was eine Stärke ist von FPGA.

Wenn Sie den Trend extrapolieren, den wir für neuromorphe Geräte sehen, kann man sich vorstellen, dass andere Bereiche, die auf Parallelität basieren oder diese unbedingt erfordern, wahrscheinlich viel mehr FPGAs übernehmen werden. Vielleicht wird FPGA für Verbraucherprodukte nicht allgegenwärtig, aber es kann für bestimmte Bereiche sein, wie es derzeit für neuromorphe Geräte scheint.

Es sind ausschließlich die Kosten. Wenn ein Mikro nur 30 Cent kosten kann, bewegt sich ein billiges FPGA im 5-Dollar-Bereich. Die Kosten mögen nicht so hoch erscheinen, aber wenn Sie eine Million von einem furzenden Spielzeug machen, das Sie für 10 US-Dollar verkaufen können, dann macht der Preis des FPGA Ihr Endergebnis zunichte.