Programmierbare Logik Der FPGA-Design-Flow verändert sich

FPGAs durchliefen in den letzten Jahren wesentliche Veränderungen ihrer Architektur. Immer komplexere Designs verlangen eine neue Herangehensweise an das Design-in programmierbarer Logik.

Anbieter zum Thema

Heitec AG

ISH Ingenieursozietät GmbH

Cadlog Group

Lattice Semiconductor Corp.

Der Wandel bei FPGAs begann mit Hard-Blocks wie RAM und DSP, heute enthalten sie auch Transceiver sowie Hard-IP-Blöcke wie Ethernet und PCIe. Mit diesen neuen Funktionsblöcken können FPGA-Entwickler jetzt sehr komplexe Designs verwirklichen, die jedoch die Spezifikationsanforderungen des FPGA-Bausteins in punkto Kosten, Verlustleistungsaufnahme und Verarbeitungsleistung bis ans Limit treiben. In Consumer- und Mobilfunk-Anwendungen sind eine geringe Verlustleistung und niedrige Kosten wichtig, die sich durch folgende Maßnahmen erzielen lassen:

• Die Entwickler müssen unterschiedliche Einstellungen ihrer Tools ausprobieren, z.B. beim Place&Route. So ließe sich die Verarbeitungsleistung verbessern oder der Platzbedarf verringern.

• Eventuell muss das Design verändert werden, z.B. muss aus Performance-Gründen ein RAM-Block anstelle von verteiltem RAM gewählt werden.

• Vielleicht muss aber auch die Architektur des Designs verändert und ein paralleles Protokoll anstelle eines seriellen Protokolls gewählt werden.

Diese Design-Ansätze gehen die Entwickler meist nacheinander an, was die Kompilierungszeit erhöht, und den Zeitplan durcheinanderbringt. Entwickler müssen heute in kürzester Zeit die FPGA-Designphase abschließen, während sie gleichzeitig Design-Spezifikationen erfüllen, die eine Herausforderung darstellen. Entwickler begrüßen daher die Möglichkeit, mehrere Design-Implementationen oder Veränderungen der Architektur bereits in der FPGA-Design-Software innerhalb einer kurzen Zeitspanne zu untersuchen.

Kommt bei FPGA-Systemen der herkömmliche Design-Flow zum Einsatz, ist dieser sequenziell konzipiert: Jedes mal, wenn eine Änderung des Designs durchgeführt wird, muss es neu kompiliert werden, damit sich die Auswirkungen der Veränderung untersuchen lassen. Dieser Prozess wiederholt sich so lange bis die Design-Spezifikationen erfüllt werden. Dies kann den Zeitbedarf vergrößern, was allerdings aus Gründen der Wettbewerbsfähigkeit nicht akzeptabel ist. Eine Lösung ist erforderlich, welche die Gesamt-Kompilierungszeit innerhalb des Design-Flows verkürzt.

Optimierung in punkto Low-Power

Die FPGA-Design-Software brachte das Tool „Settings-Explorer“ mit sich, das Optimierungsvorgaben (Settings) bietet. Zu diesen Settings gehören das Re-Timing oder die Fanout-Regelung, die dann auf dem Design laufen und die Ergebnisse des gesamten Bereichs archivieren. So müssen alle Durchläufe durch Untersuchen der unterschiedlichen Settings erledigt werden oder nur der Durchlauf mit den besten Ergebnissen abgespeichert werden.

Der Entwickler kann das Tool automatisch die entsprechenden Voreinstellungen auswählen lassen; als Auswahlkriterien können höhere Ziele wie „Optimierung in punkto Low-Power“ oder „Verringerung des Platzbedarfs des Designs“ dienen, wobei der gesamte Bereich untersucht wird (Bild 1). Der Settings-Explorer verbessert die Möglichkeit, die Ziele auch zu erreichen. Allerdings nahm er nicht den gesamten Termindruck aus dem Projekt, weil jede Änderung des Designs dafür sorgen konnte, dass der Anwender das Tool erneut starten musste, so dass erneut die lang andauernde Kompilierungszeit abzuwarten war.

Eine weitere Neuerung wurde eingeführt, um die Vorteile von Computer-Architekturen zu nutzen, die jetzt aus mehreren CPU-Cores bestehen; die FPGA-Design-Software konnte eine beliebige Anzahl von Cores nutzen, um die Kompilierungszeit zu verringern. Jedoch würde eine weitere Veränderung des Designs immer noch einen weiteren Kompilierungsdurchlauf erfordern, der selbst dann mit zusätzlichem Zeitbedarf zu Buche schlägt, wenn die Kompilierungszeit einer Design-Iteration verringert wurde (Bild 2).

Laufzeitverkürzung und Design-Untersuchung

Die FPGA-Design-Software brachte noch eine weitere Funktion mit ins Spiel, die von der ASIC-Design-Methodologie kommt und einen inkrementalen Design-Flow (Bild 3) aufweist. Im Rahmen dieses Ablaufs lassen sich Designs auf Basis logischer Hierarchien partitionieren, um so eine kürzere Laufzeit zu erzielen und Timings fest einzuhalten. Damit lässt sich eine Partition auf den logischen Hierarchien erzeugen, in denen Veränderungen des Designs vorkommen können, die dann entsprechend neu kompiliert werden.Eine lokal durchgeführte Änderung wirkt sich dann nicht auf das gesamte Design aus.

Der inkrementelle Design-Flow liefert so einen Beitra, den Zeitaufwand für die Gesamtkompilierung zu verringern, während gleichzeitig die Verarbeitungsleistung des restlichen Designs erhalten bleibt. Dies war ein Schritt in die richtige Richtung; allerdings geht dieser Ansatz nicht die Tatsache an, dass der Design-Flow immer noch rein sequenzieller Natur ist. Die Anwender können zu einem gegebenen Zeitpunkt nur eine Implementierung des Designs aktiv vorhalten, und sie müssen auch darauf warten, dass zwei Kompilierungsvorgänge nacheinander ablaufen, um die Ergebnisse zu vergleichen.

(ID:35800960)