Suchen

Umstieg von (C)PLDs auf FPGAs – Migration programmierbarer Logik

| Autor / Redakteur: Prof. Dr. Christian Siemers * / Sebastian Gerstl

Immer mehr Hersteller programmierbarer Logikbausteine kündigen die Produktion von PLD-Bausteinen ab. Wer diese Bausteine noch in seinen Lösungen einsetzt, sollte auf die komplexeren FPGAs umsteigen. Was muss man dabei beachten?

Firmen zum Thema

Die-Ansicht eines Altera Cyclone EP1C3, eines der kleinsten und frühesten FPGAs von Altera (heute Intel PSG). Er verfügte über 2910 Logikelemente, eine PLL und 58.5 kibibits SRAM-Speicher. Für einfache Designs zog man noch den Einsatz von CPLDs gegenüber den komplizierteren FPGAs vor. Heute werden immer weniger PLDs hergestellt, ein Umstieg wird irgendwann unausweichlich.
Die-Ansicht eines Altera Cyclone EP1C3, eines der kleinsten und frühesten FPGAs von Altera (heute Intel PSG). Er verfügte über 2910 Logikelemente, eine PLL und 58.5 kibibits SRAM-Speicher. Für einfache Designs zog man noch den Einsatz von CPLDs gegenüber den komplizierteren FPGAs vor. Heute werden immer weniger PLDs hergestellt, ein Umstieg wird irgendwann unausweichlich.
(Bild: Altera-cyclone-1-fpga-Si-HD / Altera-cyclone-1-fpga-Si-HD / ZeptoBars / CC BY 3.0 / BY 3.0)

Die Welt der programmierbaren Logikbausteine – PLD, Programmable Logic Devices – hat sich schon früh in drei Architekturen aufgeteilt: Simple PLDs (SPLDs), Complex PLDs (CPLDs) und Field-Programmable Gate Arrays (FPGAs). Während die SPLDs im Angebot der Hersteller wohl schon ausgestorben sind und heute auch einen eher pädagogischen Wert in der Ausbildung hätten, wendet sich die Anwenderschar heute auch vermehrt den CPLS ab und den FPGAs zu. So kann es kommen, dass bewährte Designs mit einem CPLD zu einem FPGA migriert werden müssen, und da stellt sich die Frage, welche Schwierigkeiten man zu erwarten hat und wie man sie am Besten meistert.

PLD vs FPGA: Die historische Entwicklung Programmierbarer Logik

SPLDs gibt es seit 1977. Diese Bausteine sollten und konnten die festverdrahtete Logik, die oft in Form der 74xx-ICs daherkam, ersetzen, indem alle Eingänge in einer Art Verschaltungsmatrix geführt wurden. Die Kreuzungspunkte der Matrix waren programmierbar, konnten also von leitend auf isoliert umgestellt werden (zunächst nur einmalig, später auch löschbar). Bild 1 zeigt das Prinzip, die SPLDs wurden meist in einem Booleschen Assembler in der „disjunktiven Normalform“ entsprechend einem ODER von UND-Verknüpfungen von Variablen und deren negierten Werten programmiert.

Bildergalerie

Ein Problem zeigte sich sehr schnell: Bläht man diese Architektur immer weiter zu mehr Ein- und Ausgängen auf, dann wird die Hardware sehr ineffizient genutzt, d.h. viele Transistoren sind im Baustein, aber nur wenige werden pro Design genutzt. Diese Überlegungen führten in den 1980er Jahren zu den High-Density-PLDs (HDPLDs), und zwar zu zwei unterschiedlichen Optimierungen.

HDPLDs haben grundsätzlich folgende Bestandteile:

  • Einen Input/Output-Bereich mit einer Signalverteilung in den Innenbereich,
  • eine Anzahl von (unteilbaren) Logikblöcken, jeder nur komplett nutzbar und
  • einen Verdrahtungsbereich (Routing), um die Logikblöcke untereinander sowie mit dem Input/Output-Bereich zu verbinden.

Die von den Anbietern verwendeten Mixturen waren nun, entweder auf eine vollständige Verdrahtung (Routing) zu setzen oder die Logik vollständig zu machen. Die vollständige Verbindbarkeit bedeutet dann, dass die Anzahl der Signale N, die geroutet werden muss, eingeschränkt ist, da die Komplexität des Netzwerks mit N2 wächst. Also sind die (unteilbaren) Blöcke recht groß und beinhalten etwa 4 bis 16 erzeugte Signale pro Block. Diese Architektur wird CPLD genannt, wobei es noch wichtig ist, dass die Logik in einem Block unvollständig ist: Nicht jede Funktion der Eingänge ist in einem Block abbildbar.

Die andere Fraktion, die FPGAler, wählten vollständige Logik in den Blöcken, wobei dann der Transistorbedarf mit 2N bei N Eingängen wächst. Somit ist die Größe der Blöcke auf 3 bis 5 Eingänge beschränkt, und das Routing hat nun das Problem eine große Anzahl von (Zwischen-)Signalen im Baustein routen zu müssen. Die klassische Lösung hierfür ist ein hierarchisches (aber natürlich unvollständiges) Routing.

Konsequenzen einer Migration von einer Logik-Lösung zur anderen

Der kurze Abriss der Historie dient nur dazu, die gewachsenen Konsequenzen bei einer Migration zu verstehen. In der sehr schönen Zusammenfassung der Unterschiede zwischen CPLD und FPGA [1] sind viele Unterschiede aufgeführt, aber gemeinsam ist den beiden Architekturen zunächst, dass sie – mit Ausnahme der Endlichkeit der Ressourcen – für alle berechenbaren Probleme geeignet sind: Es sind universelle Rechenmaschinen. Neben dieser grundsätzlichen Austauschbarkeit müssen also weitere Eigenschaften betrachtet werden: Grundsätzlich sind dies die Ressourcen, die Zeit zur Ausführung (oder auch Taktrate), die elektrischen Eigenschaften und die Pinouts.

Ressourcen

FPGAs haben auf den ersten Blick sehr viel mehr Ressourcen, auch besondere dezidierte Hardwareteile wie interner Speicher, Mikroprozessoren oder Blöcke für Signalverarbeitung, CPLDs nicht. Für die Migration spielt das natürlich keine Rolle (vielleicht mit Ausnahme des Preises), denn zusätzliche Ressourcen werden einfach nicht genutzt.

Für die eigentliche Logik ist ein Ressourcenvergleich zunächst schwierig. FPGAs haben deutlich mehr interne Zwischensignale und dadurch auch Register, das Verhältnis kann um Größenordnungen unterschiedlich sein. Das ist eine gute Nachricht für die Migration, nur kosten viele Register eben auch viel, so dass eine möglichst minimale Ausprägung der internen Ressourcen vorzuziehen ist. Der ideale Weg für die Migration besteht in der Compilierung (einschließlich Placement & Route) des Designs für das neue Zielsystem, das Sie natürlich variieren können.

Die Schätzung der benötigten Ressourcen ist natürlich möglich, aber schwierig und fehleranfällig. Nehmen wir an, es sind 16 Signale im Eingang eines Teildesigns, die im CPLD einen Block und darin ein Ausgangssignal belegen. Im FPGA mit einer 4:1-Struktur im Logikblock (LB) können diese mithilfe von 4 LBs zu 4 Zwischensignalen und mittels eines 5. LB zum gewünschten Signal zusammengefasst werden – wenn es denn im Algorithmus keine Verzweigungen gibt. Ein IF/ELSE-Paar erzeugt zwei Wege, im Zweifelsfall wird die benötigte Hardware mehr als verdoppelt. Wenn Sie also schätzen wollen, müssen Sie die unabhängigen Wege bestimmen (z.B. nach McCabe, siehe [2, Kapitel 13]) und für jeden Weg die benötigten Logikblöcke.

Taktrate und Rechengeschwindigkeit

Die wohl größte Ungewissheit besteht bei der erreichbaren Taktrate. Nominell liegt die Taktrate bei FPGAs höher als bei CPLDs, in der Praxis dreht sich das aber um. CPLDs erreichen oft die vom Hersteller angegebene maximale Clockrate, da ihr Timing sehr deterministisch ist. Verantwortlich hierfür ist die globale Routingstruktur, die jedes interne Signal mit einem „Hops“ an jeden anderen Punkt im CPLD bringt, außerdem strebt man an, die komplette Rechnung innerhalb eines Logikblocks durchzuführen.

FPGAs arbeiten da komplett anders. In der Regel muss eine Operation auf mehrere Logikblöcke hintereinander verteilt werden, so dass sich Laufzeiten im LB mit denen im Routing summieren. Meist weiß man nicht, wie viele Schichten mit welchem Routing hintereinander liegen, und so gibt es nur einen Ausweg: Die Timing-Analyse der Entwicklungswerkzeuge. Nutzen Sie diese unbedingt, die Analyse wird auf Worst-Case-Zeiten durchgeführt, so dass die Angaben der maximalen Taktrate in der Regel verlässlich sind. Wenn diese Taktraten zu niedrig für den Anwendungsfall sind, sollten Sie mithilfe von Experten oder Foren versuchen, das Placement&Route so zu beeinflussen, dass bestimmte Signale deutlich beschleunigt werden.

Im Allgemeinen ist die erreichbare Taktrate eine der kritischeren Größen bei der Migration.

Elektrische Eigenschaften und Programmspeicher

CPLDs haben in der Regel einen Festwertspeicher auf EEPROM-Basis im Baustein und sind somit sofort nach Power-On betriebsbereit. Diese Eigenschaft wird manchmal sehr geschätzt, und zugleich ist der Energiebedarf beim Booten, d.h. beim Laden des Programms aus dem Speicher nicht extra zu berücksichtigen, denn es gibt kein Laden, der Speicher ist verteilt über den Baustein.

FPGAs sind fast ausschließlich SRAM-basiert: Das Programm muss beim Start aus einem (fast immer externen) Speicher geladen werden, was bis zu 100 ms dauert und einen erheblichen Energiebedarf zeigt: Die Verlustleistung beim Booten kann schon mal das Zwei- bis Dreifache derjenigen im Normalbetrieb betragen. FPGAs mit internem Speicher sind selten und bringen, das Zeit- und Energieverhalten betreffend auch keine Vorteile.

Ansonsten weisen CPLDs meist sehr viel geringere Verlustleistung im Betrieb auf als FPGAs, die Energieversorgung muss zumeist auch die Spannungswerte betreffend für FPGAs bei einer Migration komplett neu geplant werden.

Pinout

Schön wäre es ja, wenn man einen IC in einem bestehenden Design einfach austauschen könnte. Wie schon dargestellt ist dies bei der Versorgung mit elektrischer Energie schon kaum möglich, und auf der Ebene des Pinout-Designs gibt es keine Kompatibilität. Zusammengefasst kommen Sie an einem Redesign der Platine nicht vorbei.

Migration von (C)PLDs auf FPGAs: Der Königsweg

Gibt es ihn, den Königsweg? Na ja, die Empfehlung lautet einfach, sich zunächst die Möglichkeiten bei den elektrischen Eigenschaften und dem Speicher anzuschauen. Kritische Fragen sind, ob man mit der Verzögerung beim Power-On (max. 100 ms) leben kann, und ob die Verlustleistung etwa bei Batteriebetrieb tragbar ist.

Ist das akzeptabel für die Migration, sollte das Design in das neue Entwicklungssystem eingegeben werden. Ressourcen- und Timingschätzung sind auf diese Weise gleichzeitig möglich. Und ein Tipp am Rande: Auch das Pin-Layout des Designs sollte festgelegt werden, denn beliebig frei ist es bei FPGAs auch nicht. So sind z.B. Verlustleistungen bei Ausgängen pro einem Pin-Block oftmals begrenzt, wodurch auch die Anzahl der Ausgänge begrenzt werden kann.

Literatur

[1] Numato Lab Help Center: “CPLD vs FPGA: Differences between them and which one to use?

[2] Siemers, Christian: “Handbuch Embedded Systems Engineering “.

* Prof. Dr. Christian Siemers lehrt an der Technische Universität Clausthal und arbeitet dort am Institut für Elektrische Informationstechnik (IEI).

(ID:45544397)