FPGA/CPLD Toolchain

Allgemein

Für die Erstellung eines FPGA-Designs aus einer Hardwarebeschreibungsprache wie VHDL wird eine Kette aus mehreren Tools abgearbeitet. Diese wird im folgenden beschrieben. Eine weitere Beschreibung findet sich im diesem Diplomarbeits-Auszug: Auszug aus DA FPGAküchle - Toolchain.

Synthese/Implementierung

Synthese Netzliste aus Beschreibungssprache

Xilinx: xst

Zusammfassen Netzlisten + Constraints

Xilinx: ngdbuild

Abbilden auf Chiparchitektur - Mapping

Map erzeugt eine architekturspezifische Netzliste. Diese Netzliste kann wie ein Kochrezept gelesen werden, Beispiel:

• Man nehme 3 slices, eine DCM und eine Handvoll Routing Kanäle (Netze).
• An der DCM knote man ein Ende eines Netzes an das Pin fout, ein anderes Ende verbindet man mit dem Pin Y1 eines Slices.
• Dann nehme man das zweite slice, knüppert ein Ende des netzes an Y2, ein weiteres Ende an A1 und noch ein Ende an CY
• ...

Also es steht nicht drin:

• Welches Slice von den Tausenden zu nehmen ist.
• Was als Netz zu nehmen ist (long line, slice interconnect, etc.)

aber der Schaltplan wird beschrieben (ohne zu verraten wie die Verbindungen zu realisieren sind).

Xilinx: map

Implementierung

CPLD: Fitter

Xilinx: cpldfit(?)

FPGA: Place and Route

Also was macht Place und route? Place Route bekommt eine Datei vom Mapper - die Netzliste.

Der Placer hat nun auszuwählen welches Slice und welche DCM zu nutzen sind.

In der niedrigsten Optimierungstufe denkt er dabei nicht viel nach (das kostet ja Rechenzeit) sondern beginnt in einer Ecke (meist links oben) und füllt von dort das FPGA. Das ist sehr gut an den DCMs zu beobachten, der Placer nimmt (fast?) immer die DCM links oben und (fast?) nie die DCMs aus der unteren Reihe, wenn er nicht muss. So geht er stur duch das Kochrezept (die Netzliste), er nimmt von oben die Komponente (slice, dcm, etc. ) und legt diese auf den nächsten freien Platz. ändert sich die Reihenfolge in der Liste (vielleicht weil man die Reihenfolge der Instanziierung der Komponenten ändert, oder einen anderen Signalnamen vergibt, oder das Voodoo des Synthesetools auf einen Vollmond fällt) ändert sich auch die Position der Komponente im FPGA.

Mit Optimierung "high" ist er ein bisschen schlauer. Allerdings ist mir unbekannt, was mit schlauer gemeint ist. Irgendwie versucht er nun die Komponenten so zu legen, das sie nicht weit verstreut sind. Vielleicht sortiert er das Kochrezept nach Komponentennamen? Das Problem ist, das die Tools nicht wissen, was sie machen sollen außer alle Komponenten irgendwie auszuwählen und zu verschalten.

Der Router ist dann ohne Timingconstraints ähnlich hilflos. Er macht sich die Arbeit leicht (und hält die Rechenzeit klein), indem auch er an einer Ecke (vom Slice) anfängt und von dort die Routingkanäle zur nächsten Komponente auswählt.

Ein echtes Routen (ziehen von Kupferbahnen, Drähten) ist bei FPGAs nicht möglich. Im FPGA ist das Kupfer ja schon fertig als Routingressourcen. Der router muss nur auswählen, welche er für die geforderte Verbindung aktiviert. Es gibt unterschiedlich schnelle und unterschiedlich lange Routingresourcen. Einige reichen von oben nach unten, davon ist ein Teil schneller als der andere. Es gibt kurze Verbindungen von einem Slice zum benachtbarten. Auch damit kann man durch den ganzen FPGA gehen, wenn dieses Slices in Durchfahrt geschaltet ist. Also eine LUT, bei der nur ein Eingang genutzt wird und er Ausgang immer den selben Wert wie der Eingang hat. (Solche LUTs werden im Map-report mit "route-through" gekennzeichnet).

Mit Timing Constraints kann er nun dafür sorgen, dass schnelle Signale schnelle Routing-Ressourcen bekommen und langsame Signale auf den kurvigen Schleichpfaden zum Ziel kommen. Je nach Optimierungsschalter wird er nun unterschiedlich komplizierte Methoden anwenden, das Routing entsprechend dem Timing anzupassen.

Die Tools versuchen aber nicht "Optimal" sein, also das schnellste Design zu bauen. Sind z. B. 5 ns gefordert, wird er nicht unbedingt prüfen, ob er die schnellen Kanäle (z. B. 2 ns) nutzen kann, wenn er alles mit den langsameren (z. B. 4 ns) Kanälen schafft. In der Regel arbeitet das place und route nach der Devise "baue schnell ein korrektes Design" also "erfülle was gefordert und denke sowenig wie nötig nach". Den "Nachdenken" kostet Rechenzeit und kein User wartet gern stundenlang auf das Ende des Place und Route.

Die maximale Taktfrequenz kannst man durch Hochschrauben des Period-constraints, mehreren PAR Läufen und Ausprobieren der optimalen Syntheseschalter ermitteln. Oder kurz du musst es mühsam ausprobieren. Manchmal wird Overconstraining empfohlen, also eine utopische Taktfrequenz angeben (z. B. 500 MHz), tools laufen lassen und dann schauen was die Tools geschafft haben (z. B. 183 MHz). Aber dieser Wert ist auch nur geschätzt, denn:

• Bei Xilinx brechen die Tools ab, sobald ein Pfad entdeckt wird, für denn es absolut kein Routing mit der geforderten Zeit gibt.
• Nach meinen Erfahrungen ist die angegebene kleinste Taktperiode nach Overconstraining auch noch nicht das schnellste was möglich ist. Beispiel aus der Praxis:
  1. Constraint 53 MHz -> nicht geschafft, Angabe 50 MHz wären drin
  2. Constraint 50 MHz -> geschafft, Angabe 51 Mhz wären drin
  3. Constraint 51 MHz -> geschafft, Angabe 51 Mhz wären drin
  4. Constraint 52 MHZ -> geschafft, Angabe 52 MHZ sind drin

Also die Taktung angeben und schauen, ob's geroutet wird.

Warum das so ist? Ich tippe auf Traveling-Salesman-Problem: http://de.wikipedia.org/wiki/Traveling-Salesman-Problem

Die Aufgabe für die Tools ist es nicht, das schnellste Design zu implementieren (was ein extrem Rechenzeit-intensives Problem ist) sondern aus allen Lösungen, die die Funktion erfüllen (Netzliste) das Design zu finden/auszuwählen, das die Randbedingungen (engl. constraint), z. B. "Pfade zw. FF kürzer/gleich 2 ns, erfüllt.

Xilinx: par

Erzeugung Download-File

Xilinx: bitgen

Statische Timing-Analyse

Da ist die statische Timinganalyse:

Entscheidend für die max. Taktfrequenz ist die Signallaufzeit zwischen zwei FlipFlops, die durch die selbe Taktleitung getrieben werden. Diese Laufzeit besteht aus mehreren Teilzeiten (clock_to_Output_delay, setup_time, etc). Die max. Taktfrequenz ist der Kehrwert der größten Laufzeit.

Für eine genauere Darstellung siehe das oben genannte PDF.

Timing constraints

• Das "period" constraint bestimmt die Obergrenze dieser Laufzeit für zwei FF innerhalb des FPGA.

• Der Fall "ein FF auf dem FPGA, das andere ausserhalb des FPGA, beide am selben Takt" wird durch zwei weitere Constraints bestimmt.

• Bei diesen Constraints gibt man die Zeit, an die für den FPGA übrig bleibt, also für FPGA-Outputs: t_taktperiode - t_auf_dem_PCB - t_setup_externes_FF

• Für Ausgänge bestimmt "Clock to Pad" wieviel Zeit vergehen darf, die das Signal vom letzten FF bis zum FPGA-Pin wandert -> Wie weit darf das Letzte FF vom Pin wegliegen.

• Für Eingänge bestimmt "Pad to Setup" wieviel Zeit bleibt, um ein Signal vom Pin in ein FF zu transportieren. -> Wie weit darf das Erste FF vom Pin wegliegen.

Toolchain für Xilinx

Genauere Informationen zur Xilinx-Toolchain gibt der Artikel Xilinx ISE.