FPGA

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

FPGA ist die Abkürzung für "Field Programmable Gate Array".

Es handelt es sich dabei um programmierbare digitale Bausteine mit denen eine Vielzahl von Schaltungen realisiert werden können.

Aufbau

Grundelemente

Ein FPGA besteht, ähnlich wie ein CPLD, aus vielen Logikelementen, hauptsächlich FlipFlops (FF) und davor gelagerten kombinatorischen Logikschaltungen. Diese sind entweder Verknüpfungen verschiedener Logikgatter (FPGAs der Firma Actel), die über elektronische "Schalter" entsprechend der vom Entwickler gewünschten Funktion miteinander verknüpft werden können oder es handelt sich um sogenannte LUTs (Look-Up-Table), mit denen die Logikfunktion explizit realisiert wird.

Eine LUT kann eine beliebige kombinatorische Funktion (NAND, XOR, AND, Multiplexer etc.) aus den Eingangssignalen realisieren. Die Anzahl der Eingangssignale pro LUT ist vom FPGA abhängig und liegt meist zwischen 4 und 6. Für Funktionen die mehr Eingänge erfordern als eine einzige LUT besitzt (hohes Fan-In), werden mehrere LUTs direkt miteinander verschaltet. Die FlipFlops dienen dazu, Signalwerte zwischenzuspeichern, um sie im nächsten Takt weiterverarbeiten zu können. Das Verhältnis zwischen der Anzahl der LUTs und der Anzahl der Flip-Flops ist meist 1:1. Aktuelle FPGAs bestehen aus bis zu einigen zehntausend Logikelementen.

Die logischen Schalter und Speicher sind in den meisten FPGAs durch SRAM-Speicherzellen realisiert, welche beim Bootprozess passend geladen werden. Das Laden dieser Konfigurationsdaten bzw. Verknüpfungsregeln geschieht dabei in der Regel aus einem speziellen Flash-ROM-Baustein heraus. Es kann aber auch ein Mikrocontroller benutzt werden. Die meisten FPGAs bieten daher für diesen Konfigurationsvorgang mehrere Modi an (seriell, parallel, Master/Slave). Da die SRAM-Zellen ihren Inhalt beim Abschalten der Versorgungsspannung verlieren, muss ein SRAM-basierter FPGA bei jedem Einschalten neu konfiguriert werden. Daher benötigt ein solcher FPGA einige Millisekunden bis zu einigen Sekunden, bevor er voll betriebsbereit ist.

Eine FPGA-Familie beinhaltet Typen mit unterschiedlicher Anzahl und Komplexität von Logikzellen. So enthält ein Spartan3-1000 ca. 2,5 mal so viel Logik (FF, LUTs) wie ein Spartan3-400.

FPGAs mit nichtflüchtigem Speicher basieren auf EEPROM-, Flash-Speicher (einige Familien von Lattice und Actel) oder AntiFuse- Technologie (Actel). Die sogenannten AntiFuse FPGAs sind nur einmalig programmierbar.

I/O Anschlüsse

FPGAs unterstützen als universal einsetzbare Digital-ICs eine Vielzahl von Signalstandards, um mit den unterschiedlichen Digitalbausteinen im Markt kommunizieren zu können.

Pegelstandards

Es existieren je nach FPGA-Familie verschiedene TTL-Pegel (5V, 3,3V, 2,5V), differentielle Signalstandards (LVDS, GTL, GTP) und im Hochpreisbereich serielle Hochgeschwindigkeitsstandards mit bis zu 28 Gbit/s. Oftmals sind weitere Eigenschaften wie Treiberstärke und Flankensteilheit für jeden benutzerdefinierbaren Anschluss (User-IO) einstellbar. Meist sind die Pins zu Bänken mit gleichem I/O Standard zusammengefasst. Innerhalb einer solchen Bank arbeiten alle Pins im gleichen I/O Standard und mit der selben I/O Spannung. Für hohe Taktraten wird sowohl für Daten als auch die Takte der LVDS IO-Standard verwendet. Hier sind zwei komplementäre Buffer in unmittelbarer Nachbarschaft angeordnet.

Signalrichtung

Innerhalb eines FPGAs gibt es nur eine Datenrichtung, d.h. der Ausgang eines Elementes kann nur mit Eingängen verbunden werden, da die FPGA-typischen Optimierungen nur so sinnvoll anwendbar sind. Rückwärtspfade zwischen internen Modulen müssen daher parallel und ausdrücklich aufgebaut werden. Bei den Ports hingegen kann zwischen den Optionen Eingang, Ausgang und Hochohmig gewählt werden. Die dazu benötigten Tristatebuffer werden implizit über VHDL definiert, indem einem Ausgang zeitabhängig der Zustand "Z" zugewiesen wird. Alternativ kann er explizit als Element eingefügt werden. Bei komplexeren FPGAs sind die Ein- und Ausgänge mit Verzögerungsgliedern versehen, die ein Anpassen des Timings bei Bussen wie z.B. schnellen Speichern ermöglichen.

Terminierung

Ebenso können je nach Hersteller und Typ interne Pull-Up und Pull-Down-Widerstände sowie Terminationswiderstände zugeschaltet werden, Terminierung wird ebenfalls unterstützt.

Test und Inbetriebnahme

Einige Pins übernehmen besondere Funktionen und sind somit vom Anwender nicht uneingeschränkt oder z.T. auch gar nicht nutzbar. Dazu zählen neben der JTAG-Schnittstelle z. B. die Pins zum Einlesen der Konfigurationsdaten. Zudem befinden sich hinter vielen IO-Pads sog. Boundary Scan Zellen.

Takteingänge

Einige wenige Pins (2 - 8) sind zum Einspeisen des Taktes für das Design vorgesehen. Für schnelle Schaltungen sollten diese reservierten Pins benutzt werden. Sie enthalten kein Eingangs-FF und wirken über instanziierbare Buffer direkt auf Taktnetze / PLLs. Bei leistungsfähigen großen Applikationen mit mehreren Takten müssen diese genutzt werden, da nur eine begrenzte Zahl von DCMs (Digital Clock Manager) zur Verfügung steht und benachbarte IO-Pins genutzt werden müssen. Für hohe Taktraten werden LVDS-Eingänge verwendet.

Verwendung

Das I/O Verhalten wird zusammen mit vielen anderen Parametern in einer Datei festgelegt (Xilinx *.ucf, Altera *.acf, Lattice *.lpf). Alternativ können diese auch als Syntheseoption im Kommentarfeld des Verilog/VHDL Codes mit angegeben werden. Die Hersteller bieten FPGAs mit gleicher Anzahl von Logikelementen in unterschiedlichen Gehäusen an. So kann der FPGA mit der passenden Anzahl von Pins eingesetzt werden. Das obere Ende markieren Chips mit über 1500 I/Os, die kleinsten bieten ca. 50 User-I/O. Oft werden nur BGA und QFP Gehäuse (bis ca. 240 Pins) angeboten. Umgekehrt kann innerhalb einer Gehäusefamilie hochmigriert werden, d.h. bei gleichbleibendem Pinout, kann ein komplexerer FPGA eingesetzt werden. Das Layout muss dann nicht verändert werden, um eine Schaltung mit mehr Funktionen auszustatten.

Besondere Funktionsblöcke

Neben den LUTs und den FlipFlops beinhalten FPGAs komplexe Routing- und Speicherkonfigurationsoptionen innerhalb und außerhalb der logischen Elemente, die es überhaupt erst gestatten, komplexe Schalt- und Rechenstrukturen aufzubauen. Aufgrund der gestiegenen Anforderungen geht man immer mehr dazu über, häufig benötigte Schaltungsteile fast in Hardware zu integrieren.

DSP-Elemente

Für rechenintensive Designs, z. B. in der Signalverarbeitung, enthalten inzwischen praktisch alle FPGAs dedizierte Multiplizierer auf dem Chip, die in sehr kurzer Zeit, z.B. auch einem einzigen Taktzyklus, breite Multiplikationen durchführen können. Diese müssen daher nicht mehr in Logik aufgebaut werden. Aktuelle MUL-Elemente können z.B. 18x25 Bit in einem Schritt multiplizieren. Außerdem treten noch Carry-Chains, Akkumulatoren und Speicher-FFs hinzu, um direkt lokal schnelle Summierer und Zähler realisieren zu können.

Block-RAMs

Ferner haben FPGAs oft einen von den LEs getrennt verfügbaren RAM-Bereich integriert, der sich in vielfältiger Weise ansprechen lässt. So können damit Single- oder Dualport-RAMs mit variabler Bitbreite erzeugt werden. Üblich sind mehrere (4 - 30) kleinere Dualport RAM-Blöcke von 4 - 16 kbit. Einige Familien besitzen einen größeren internen RAM, andere spezielle FIFO-Blöcke.

Taktgeneratoren

Zur Erzeugung der internen Takte sind PLLs (Phase Locked Loop) auf dem FPGA integriert. Einige Hersteller setzen eine Kombination aus statischen Taktmultiplizierer DLLs (Delay Locked Loop) ein. Mittels dieser Blöcke können aus einem Taktsignal weitere Takte abgeleitet werden. Typisch sind Taktverdopplung oder -vervielfachung. Ebenso kann der Takt bei gleicher Frequenz um eine einstellbare Phase verschoben erzeugt werden. Typische Anwendungen sind die Kompensation von Eingangsbufferverzögerungen, die Ansteuerung von DDR-RAMs oder die Kompensation von Laufzeitunterschieden zwischen Takt und mit diesem getakteten Steuersignalen. Meist sind 2 - 8 Taktnetzwerke und PLL/DLLs gleicher Anzahl integriert. Siehe auch Taktung FPGA/CPLD.

CPU im FPGA

Microprozessoren sind auch in FPGA-Designs immer häufiger anzutreffen. CPUs sind zwar im Allgemeinen langsamer und weniger effizient, als eine vollständige Implementation aus Logik-Primitiven - aber bei komplexen Abläufen deutlich einfacher, schneller und zielführender zu programmieren, da die Strukturen festgelegt und damit bekannt sind. Insbesondere bei langsamen sequentiellen Aufgaben (Benutzerinterface, komplexe Steueraufgaben etc.) wird gerne auf eine klassische CPU zurückgegriffen, weil ein eventueller Zeitnachteil wegfällt, aber das Testen des Systems vereinfacht wird. Die CPUs sind teilweise kompatibel zu etablierten Prozessorarchitekturen (MIPS, SPARC, AVR), zum Teil aber auch auf die FPGAs einzelner Hersteller hin optimiert.

Als Programmspeicher werden die FPGA-internen RAM-Blöcke oder externe Speicher (SDRAM, SRAM) genutzt. Für einige Prozessorkerne stehen Hochsprachen wie C, C etc. zur Verfügung, andere werden in Assembler programmiert.

Hardcores

Manche FPGAs haben dazu einen oder mehrere Prozessorkerne als HardCores physikalisch auf dem Chip integriert, entweder als Chipstruktur auf dem FPGA-kern selbst oder als gebondeter Chip im selben Gehäuse. So findet man z.B. AVR bei Atmels FPSLIC, PowerPC bei Xilinx' Virtex bzw Dual ARM A9 bei Xilinx' Zynq oder ARM Cortex-M3 bei Actel (Microsemi) SmartFusion, bzw. Dual ARM-CPUs bei Altera. Diese Kerne sind mehr oder weniger funktionell identisch mit den externen Modellen und oftmals mit denselben Werkzeugen zu programmieren und zu testen, d.h. man kann ein komplettes System extern entwickeln und dann auf den FPGA bringen.

Softcores

Auf der anderen Seite gibt es auch SoftCores (z. B. ARM-Cortex-M1 bei IGLOO-FPGA von ACTEL), Prozessorkerne die als Quelltext oder als vorsynthetisierte Netzliste vorliegen. In Abhängigkeit von den zur Verfügung stehenden Ressourcen können diese SoftCores beliebig oft instanziiert und auch in der Funktion konfiguriert werden, um sie zu optimieren. Es gibt eine Vielzahl verschiedener SoftCores. Einige sind sehr klein und platzsparend realisiert, damit kann man auch auf vergleichsweise kleinen aktuellen FPGAs problemlos eine 32bit-RISC-CPU integrieren. Der Nutzen der Softcores liegt vor allem darin, daß man vorhandene physische CPUs platzsparend integrieren und alte Systeme beschleunigen kann. Ferner können einfache Interfacefunktionen, die schon in SW vorliegen ohne Portierung in VHDL genutzt werden.

Eigenschaften

Chipausnutzung

Aufgrund des Umstandes, dass FPGAs eine Reihe von spezialisierten Funktionsblöcken, wie BRAMs, Multiplier und Transceiver beinhalten, die naturgemäß nicht in allen Designs genutzt werden können, bleibt ein Teil der Chipfläche des FPGAs immer ungenutzt. Auch die Beschränkung der routing-Resourcen führt aufgrund der Lage von IOs und spezialisierten Blöcken dazu, dass zur Erreichung der Wunschtaktfrequenz zusätzliche FlipFlops eingesetzt werden müssen, die dann nicht mehr zur Verfügung stehen. Schließlich sind die universellen routing-Resourcen selbst ein Erfordernis, welches Chipfläche kostet. Im Vergleich zu einem full custom asic gleicher Funktion benötigt ein FPGA daher erheblich mehr Chipfläche.

Taktgeschwindigkeit

Die maximale „Geschwindigkeit“, eines FPGAs ist von der verwendeten Halbleitertechnologie (Prozess, Strukturgrößen), der internen Schaltungstopologie (Komplexität der LEs), dem Vorhandensein von harten Strukturen und vor allem vom Design abhängig. Dabei sind der sogenannte Datendurchsatz und die rein maximale Systemtaktfrequenz zu unterscheiden. Die erreichbare Taktfrequenz lässt sich ohne detaillierte Kenntnis des Designs nicht abschätzen; möglich sind je nach »Speed Grade« des ICs typischerweise Taktfrequenzen von 300-800 MHz für die Schaltgeschwindigkeit der reinen Logikelemente. Je nach der Anzahl und Komplexität der pro Takt durchzuführenden Operationen ergeben sich dann reale Systemtaktfrequenzen von meist 10-200 MHz für global operierende Einheiten und bis zu 400 MHz für schnelle lokale Module. Maßgeblich ist, in wieweit das Design auf Fläche bzw. Geschwindigkeit hin optimiert- und vom Tool synthetisiert wurde: Durch das Einbringen von zusätzlichen Registerstufen lassen sich z. B. zeitkritische Pfade (Pipelines) entschärfen, sodass die Frequenz des Chips angehoben werden kann und somit der effektive Datendurchsatz erhöht wird, mit dem Nachteil der gesteigerten Latenz durch das Mehr an Takten. Der Datendurchsatz insgesamt lässt sich wiederum durch die Nutzung paralleler Architekturen erhöhen.

Die Systemfrequenz kann, muss aber nicht der Frequenz entsprechen, mit der Daten zyklisch eingetaktet und verarbeitet werden; zudem sind Schaltungsteile mit unterschiedlichen Taktfrequenzen zu unterscheiden: Mit einem Systemtakt von 20 MHz lassen sich z. B. 18-Bit AD-Wandler auslesen, die so z. B. alle 1 µs neue Daten liefern, die verarbeitet werden müssen. Bei der Nutzung von 5 solchen Wandlern, die sequentiell verarbeitet werden, lägen 5 MHz Datenfrequenz vor. Für andere Schaltungsteile, die z. B. asynchron an die Peripherie andocken, sowie reine »state machines« können Schaltungsteile auf der 2-4 fachen Frequenz betrieben werden.

Generell sind Fläche und Geschwindigkeit konkurrierende Größen, zwischen denen ein Optimum gefunden werden muss. Für die preiswerten FPGA-Serien wie Spartan (Xilinx) und Cyclone (Altera) sind aufgrund technologischer Randbedingungen bei gleichem Design etwa 10-30% weniger Taktgeschwindigkeit zu erwarten, als bei den großen Brüdern der Virtex- (Xilinx) bzw. Stratix-Familie (Altera). Es muss mit mehr Verbrauch an Logikelementen und Taktzyklen gerechnet werden (weniger Routingreserven, geringere Zahl von LUT-Eingängen, langsamere Logikelemente). Dafür sind sie sehr preiswerter.

Funktionstechnisch identische Chips werden oft in mehrere Geschwindigkeitsklassen (speed grades) angeboten, die sich meist durch Bauteilselektion bei der Produktion ergeben. Grob kann man ca. 5%-15% höhere Taktung zwischen zwei speed grades erwarten. Teilweise werden durch produktionstechnische Maßnahmen wie veränderte Dotierung auch gezielt schnellere, bzw stromsparende Typen generiert, entsprechend klassifiziert und angeboten.

Herstellung

FPGAs heutiger Bauart sind hochkomplexe Strukturen, da sie einerseits sehr hochgetaktet werden müssen, umfangreiche Funktionen bewerkstelligen sollen und damit genügend Resourcen haben müssen, andererseits aber preisgünstig und flexibel sein sollen, was umfangreiche Umschaltmöglichkeiten erfordert. Damit sind FPGAs als universelles Bauteil vergleichsweise teuer. Umso problematischer ist deren Fertigung:

Herstellungsprozess

FPGAs werden letztlich als Analogschaltkreis unter Verwendung von sogenannten Standardbibliotheken entwickelt, indem fertige, mehrfach simulierte und getestete Blöcke zusammengeschaltet werden, die ihre Funktion mehrfach in Silizium bewiesen haben. Dies betrifft hauptsächlich die IO-Zellen, Schaltmatritzen und vor allem Controller, RAM-Blöcke und andere hard cores.

Deren Funktion wird zunächst in einer Logiksimulation im Zusammenwirken geprüft und anschließend mit einer Analogsimulation ausgewählter Baugruppen untermauert. Besonders die kritischen Bauteile PLLs, IO-Treiber und Taktleitungen werden dabei untersucht. Fertige FPGA-Prototypen werden dann mit unterschiedlichen Stress-Schaltungen auf ihr Leistungsvermögen hin geprüft.

Die auszuliefernden Exemplare für Kunden, werden mit dem boundary scan Verfahren getestet und mit einem Testdesign beladen.

Prozessqualifizierung

Das Entwickeln, fertigen und Testen der FPGAs führt zu einer Regelschleife, die es gestattet, ständige Verbesserungen vorzunehmen. Für den Anwender ist bedeutsam, dass im Zuge der Informationsgewinnung bezüglich Taktraten und Strombedarf für alle FPGAs und Fertigungsprozesse kontinuierlich Modelle entwickelt werden, welche sukzessive in die Entwicklungswerkzeuge einfließen. Im Laufe des Lebenszyklus eines Chips werden diese Modelle immer präziser und gestatten ein engeres Timing und eine exaktere Voraussage hinsichtlich des Leistungsbedarfs. Zu Beginn ist es daher oft so, dass die Modellierung eher konservativ erfolgt, was dazu führt, dass neue Chips bei der Simulation der Taktgeschwindigkeiten zunächst ihre realen Reserven nicht ausschöpfen können. Oftmals sind daher FPGA-Designs, welche das Timing gerade nicht getroffen haben, dennoch voll leistungsfähig. Umgekehrt gibt es immer wieder einzelne Exemplare, die das eigentlich simulierte Taktziel in Tests verfehlen.

Hersteller

Die größten Hersteller von FPGAs sind Altera und Xilinx. Weitere Hersteller sind Lattice, Actel und Atmel.

Einige Hersteller wie Altera verfügen über keine eigene Fabrik (-> "fabless"), sondern lassen ihre entwickelten FPGAs und ASICs bei wechselnden Halbleiterherstellern fertigen. Dies führt zu jeweils günstigen Produktionskosten, allerdings auch zu Qualitätsschwankungen. Auch Liefergarantien sind schwerer zu erhalten, besonders, wenn man darauf angewiesen ist, dass ein Chip auch in 25 Jahren noch zu bekommen ist.

Anwendung und Programmierung

Erstellung der FPGA firmware

Design Flow

Die Erstellung des Programmier-Datenstroms für den FPGA, um die oft komplizierten Funktionen heutiger Applikationen zu erreichen, wird inzwischen ausschließlich durch automatische Routing- und Synthesewerkzeuge erledigt, welche mit einer funktionellen- bzw strukturellen Beschreibung der gewünschten Architektur in einer sogenannten Hardwarebeschreibungssprache wie z.B. VHDL oder Verilog "gefüttert" werden. Die Hardwarebeschreibung gelingt ihrerseits entweder ausdrücklich durch Texteditoren indem Logikstrukturen, hardwarenahe Strukturen, Ablaufdiagramme und Zustandsautomaten formuliert werden, oder mit Code-generierenden Werkzeugen. Mit deren Hilfe sind komplexe IO-Interfaces, mathematische Funktionen wie Regelalgorithmen und ganze Rechnerarchitakturen formulierbar.

Während und nach der Erstellung der Schaltungsteile, wird die Korrektheit der Funktion einzelner Blöcke sowie der gesamten Schaltung mit Simulationswerkzeugen theoretisch geprüft und gfs im Rahmen der Qualitätsmanagementprozesse auch formell nachgewiesen und geeignet dokumentiert. Danach folgt eine Integration und ein praktischer Schaltungstest Generell unterscheidet man folgende formelle Schritte während des Entwicklungsprozesses:

Validierung: Die gewünschte Funktion der Schaltung wird theoretisch geprüft. Dies betrifft im Wesentlichen die komplizierten Funktionsblöcke wie state machines, CPU-Firmware und Rechenpipelines / Algorithmen und Codierungen wie CRC und AES. Hierbei wird untersucht, ob die Funktion grundsätzlich richtig ist. Das Prüfen erfolgt meist theoretisch mit MATLAB, EXCEL oder einer Programm-analyse-Software. Ziel ist der Nachweis der Richtigkeit des Konzeptes.

Verifikation: Hierbei wird die konkrete Art der Umsetzung geprüft. Dies betrifft alle Schaltungsteile die einer bestimmten Funktion zuzuordnen sind. Praktisch wird die gesamte Schaltung blockweise dahingehend simuliert, ob alle Funktionen berücksichtigt wurden und das Verhalten in allen erdenklichen Situationen stimmig ist. Dazu werden Testfälle generiert und in die Schaltung eingespeist. Hierbei wird auch auf das logische Timing infolge des synchronen Designs Rücksicht genommen. In einigen besonderen Fällen wird auch das platizerte Design, so wie es letztlich im FPGA realisiert ist, zurückgelesen und das timing näher unterucht, um bestimmte Nachweise in Grenzsituationen zu führen.

Test: Das fertig programmierte FPGA wird real in der Hardware getestet. Dazu können Testszenarien und -mittel aus der Validierungs- und Verfikationssphase herangezogen werden und/oder ein Testplan abgearbeitet werden. Hierbei ist in aller Regel umgebende Peripherie beteiligt, weil der FPGA alleine schlecht testbar ist. Bei diesem Schritt kommt dann auch die Elektronik mit ins Spiel, d.h. das Verhalten des Ladevorgangs, Probleme mit Spannungsstabilität, Pegeln, Leitungen etc. Da so ein konkretes Exemplar des Chips zur Anwendung kommt, wird ein solcher Test meist mit mehreren Baugruppen durchgeführt. In aller Regel sind Normabweichungen hier aber nicht durch den FPGA- sondern durch das Layout des PCB bestimmt. Diese Tests offenbaren demgemäß, dass ein und dasselbe Programmierfile in einem FPGA-System funktinoniert und aufgrund geringer Unterschiede der Elektronik in einem anderen gfs nicht.


Ein wichtiger Punkt bei der Validierung, der Verifikation und auch dem Test ist dabei die Vollständigkeit der Testfälle, also die Abdeckung der Realität, in der sich das System bewegt. Um bereist bei der Validierung des Konzeptes eventuelle Fehler und Grenzen des Systems ausloten und das FPGA entsprechend fehlertolerant machen zu können, werden theoretische Modelle der Peripherie, der Physik, der Bedieneraktivität und der Randbedingungen / Abläufe erzeugt und in die Simulation eingefügt. Dies passiert sowohl bei der formellen Verfikation mit z.B. MATLAB, als auch der funktionellen Verifikation mit VHDL-Simulationswerkzeugen wie ModelSIM. Durch geeignete Modellierung von PLLs, Jitter, Variation der Signale von Aussen, können dadurch quasi alle erdenklichen Szenarien durchgespielt werden. Dies ist besonders wichtig bei Fällen, die sich in der Realität nur schwer nachstellen lassen, wie z.B: dem Auftreten zufälliger Fehler in RAMs, Störungen auf Leitungen oder Drahtbrüche.

Wiederverwendbarkeit

Durch die Standardisierung der Architektur einerseits sowie die Entkopplung von applikationsorientierter Beschreibung und Chip- und Hersteller-spezifischer Synthese andererseits, wird die Hardware quasi durch Software gebaut. Dies wiederum schafft alle Optionen der Wiederverwendung und dem flexibleb Austausch von "Hardwareteilen". So stehen inzwischen komplette Schaltungen für serielle Bausteine, RAM-Controller und vieles mehr zur Verfügung - teilweise sogar in Form von Open Source Projekten.

Andererseits ist eine Tendenz erkennbar, dass Hersteller ihre Software und die damit erstellbare VHDL, speziell bei IP-Cores, immer stärker schützen und abkapseln. Diese produzieren kaum noch allgemeine VHDL, sondern nur noch herstellerspezifische Scripte. Diese lassen sich in aller Regel nicht übertragen. Zudem führen auch immer grösser werdende Unterschiede in den Chipstrukturen und Resourcen in modernen FPGAs dazu, dass die Portierbarkeit weiter eingeschränkt wird. Dies ist besonders bezüglich der Integration von Peripherie-Controllern oder ganzer Mikrocontroller der Fall. Bei SOPC-Systemen sind die generierten Strukturen praktisch überhaupt nicht mehr von einem FPGA-Hersteller zum anderen zu portieren und oftmals nicht einmal mehr zwischen FPGA-Familien desselben Herstellers untereinander kompatibel.

Dadurch entsteht ein immer weiter wachsender Design- und Pflegeaufwand, dem viele Firmen inzwischen dadurch begegnen, daß sie - soweit als möglich - herstellerunabhängige Beschreibungen verwenden. Z.B. können RAM-Beschreibungen und State Machine, rein in VHDL-Text generiert werden, anstatt sie mit den mitgelieferten Code-Generatoren zu erzeugen.

Anbindung an Mikrocontroller

Es gibt unterschiedliche Arten, wie ein FPGA mit einem Controller verbunden sein kann. In der Regel ist der Controller der Master und arbeitet auf den FPGA. Dabei ist zwischen direkten impulsiven Zugriffen auf den FPGA nach Massgabe des internen Ablaufs im Prozessor, die jederzeit und wortweise an irgendeine Adresse erfolgen können und blockweisem Schreiben, also permanentem Datenfluss ohne Adressierung zu unterscheiden.

Das wortweise Schreiben und Lesen erfolgt in Form eines klassischen Speicherinterfaces durch aktiven Zugriff auf den FPGA oder den FPGA hindurch auf einen RAM-Bereich, in den der FPGA seinen Speicher einblendet.

Memory Mapped

Hierunter versteht man den Zugriff des Mikrocontrollers auf das FPGA in Form eines Speichers. Dabei muss der FPGA ein klassisches Speicherinterface zur Verfügung stellen. In einzelnen Fällen reicht es auch, wenn dieser ein internes Blockram im dual ported Modus an die Ports des Mikrocontrollers heranführt.

Streaming IO

Liefert ein Mikrocontroller häufig grosse Datenmengen an einen FPGA, ist es mitunter sinnvoll auf einen aktiven Zugriff mit Wortadressierung zu verzichten und einen pipeline-Zugriff zu implementieren. Der FPGA "hört" dazu den Datenbus des Mikrocontroller ab und erkennt anhand z.B. der Aktivierung nur einer Schreibleitung den Beginn des Sendens und empfängt dann mit jedem Takt ein Wort. Was die Daten zu bedeuten haben und wohin sie zu schreiben sind, muss dann in den Daten codiert werden. Auch ist es denkbar den FPGA so zu konfigurieren, dass beim Schreiben auf eine ganz bestimmte Adresse ein grösserer Datenblock übergeben wird.

In beiden Fällen wird im FPGA ein FIFO eingesetzt, der synchron mit dem Mikroprozessortakt beschrieben wird. Auf der Seite des FPGAs muss eine FSM überwachen, ob Daten ankommen und diese geeignet verarbeiten.

Indirekte Busverbindung

Oftmals sind FPGAs und MCUs in grösseren Systemen über Busse verschaltet. So kann der FPGA an einem klassischen Daten-Adress-Bus parallel zu einem RAM und anderen Bausteinen über Adressdekodierung und Chip-Select betrieben werden, oder er wird über ein logisches Interface wie SPI angebunden.

Anbindung an RAMs und ROMs

DDR2 / DDR3 - RAM

Während die Ansteuerung eines normalen SRAMS mittels eines klassischen memory mapped interface recht einfach ist, bedürfen DRAMS- speziell mit DDR-Funktion einer aufwändigeren Schaltung, welche die komplizierte Kommandostruktur der DDR-Ansteuerung versteht, pipelining und gfs caching praktiziert und das RAM entsprechend bedient. Dabei sind RAM-spezifische Randbedingungen (refresh / self refresh) zu beachten. Für FPGAs existieren hier eine Reihe von konfigurierbaren IP-Cores.

In jüngster Zeit beobachtet man hier einen Umstieg auf prozessorähnliche Funktionen und Stukturen, d.h. die RAMs werden nicht mehr nativ sondern über eine Prozessorinterface angesteuert. Die Firma Xilinx z.B. bietet keine nativen Mehrportlösungen mehr an. DDR-Controller mit den in FPGAs meistens benötigten Multiportfunktionen, also Zugriffen durch mehrere Module, sind damit praktisch nur noch über AXI-Interface zu realisieren.

SPI-Flash

Die Anbindung über SPI erfolgt meist über serielle Verbindungen wie I2C, da nur wenig Bandbreite benötigt wird. In selteneren Fällen werden FPGAs parallel mit einem Flash verbunden, z.B. bei grossen FPGAs mit umfangreichem image, welches aus einem Flash schnell geladen werden soll.

Anbindung an Peripherie

Typische Anwendungen für FPGAs sind die breitbandige (grosse Busbreite und/oder hohe Taktfrequenz) Gewinnung und Verarbeitung von Daten, bei denen DSPs oder MCUs nicht mehr (effektiv) eingesetzt werden können. Typische Beispiele dafür sind:

Videotechnik

Bildsensoren produzieren traditionell die grössten Datenmengen je Zeiteinheit und sind ohne FPGAs praktisch nicht mit der Aussenwelt in Kontakt zu bringen. FPGAs arbeiten hier entweder auf der Kunden- oder auch der Herstellerseite, um die komplexen Datenströme anzunehmen, vorzuverarbeiten und in eine reduziertes, praktikableres Datenformat umzusetzen. Auch die Annahme eines Videoformates ist praktisch nur mit FPGAs möglich.

Die benötigten Datenschnittstellen können mit Hilfe von Transceiver-Ports / LVDS manuell realisiert werden, oder es werden Umsetzer-Chips verwendet. Beispiele:

  • HDMI-Transceiver für FPGAs ohne Gigabit-Transceiver
  • SERDES-Transceiver für mittelpreise FPGAs ohne SERDES / sehr hohe Frequenzen
  • Camera-Link-Deserializer (für langsame FPGAs)
  • LVDS-Buffer-Deserializer (für langsame FPGAs ohne LVDS buffer)
  • DVI-Buffer

Für Analoge Daten benötigt man selbstredend noch Video-ADCs / Video-DACs, die überhaupt erst ein digitales Signal erzeugen.

Gigabit-Ethernet

Für die Umsetzung auf den (praktisch analogen) Ethernet-Standard braucht es immer einen sogenannten PHY, also einen physikalischen Zusatzchip. Dieser vollzieht die 5PAM-Modulation und die Codierung im 10/8-Format. Die Ankopplung an den FPGA erfolgt direkt.

Während althergebrachte 100MBit-Verbindungen dabei oft noch mit UCs und softcores zu bedienen waren, können 1GBit-Netzwerke nur noch mit FPGAs sinnvoll angesteuert werden. Umgekehrt ist das Gigabit-Netzwerk eine gute Lösung, um Daten effektiv und billig in einen PC zu transportieren, da moderne PCs alle eine GBit-Karte besitzen und die Datenrate bei schnellen CPUs auch weitgehend ausgenutzt werden kann. Typische Bandbreiten bewegen sich für Linux mit unmodifizierten Treibern bei 700MBit-800MBit.

Der MAC, bzw MAC-ähnliche Funktionen, sind im FPGA direkt implementierbar (z.B. mit IP-Cores) und können mit einfachen FSMs angesteuert werden. Für die Verwendung von C-Software ist es notwendig, einen hardcore zu verwenden, da mit softcores die Bandbreite kaum erreicht werden kann. Besonders das Verpacken der Daten, die Abarbeitung des Protokolls sowie die Bildung der Ethernet-header mit Checksummen, CRC und zusätzlichen Prüf- und Steuerinformationen sind in VHDL sehr einfach und entspannt zu erzeugen, weil parallel gearbeitet werden kann.

Die Bandbreite einer typischen GMII-Verbindung mit DDR beträgt 2x150MHz x 8 Bit, was mit mittleren FPGAs gut zu machen ist. Die interne Bandbreite ohne header beträgt dann typisch etwa 800MBit, z.B. 50MHz x 16 Bit für die Daten. Ab diesem Punkt ist dann wieder ein schneller softcore einsetzbar.

High-Speed-USB

Für die Übersetzung auf den immer schnelleren USB-Bus (inzwischen bis 5Gb Bandbreite!) stehen Chips zur Verfügung, die sich in vergleichsweise einfacher Weise ansteuern lassen. Eine passende Sende- und Empfangsarchtiktur ist in FPGAs relativ rasch zu implementieren.

Implementierung von Steuerfunktionen

In den meisten FPGA-Applikationen sind mehr oder weniger komplizierte Abläufe zu integrieren, die den Datenfluss steuern und die einzelnen Komponenten so mit einenander verschalten, dass sie wunschgemäss aufeinander reagieren.

Mit nativem VHDL sind einfache sequenzielle Abläufe mit überschaubaren Verschachtelungstiefen und Schleifen direkt in Form von Zählersteuerungen oder abstrakten State Machines realisierbar. Dazu kann auf die automatische Codegeneration aus state machine designern heraus oder die halbautomatische Erzeugung von Code mit z.B. Excel zurückgreifen, die die Enumeration von states, die Abfragen und die Sprünge zu den nächsten states automatisch vollzieht. Dies hat aber seine Grenzen, weil dies früher oder später unübersichtlich wird und nicht mehr so gut pflegbar ist. Zudem kann sich der Code stark aufblähen und die Zusammenfassung etwaiger Redundanz durch die Synthese zu hohen Synthesezeiten führen.

Applikationen, die nicht ganz so zeitkritisch sind, sollten lieber mit einer flexiblen, verschachtelten Struktur von 2 state machines abgearbeitet werden, bei denen der Ablauf von der Generation des Timings für die Hardware getrennt ist. In reinen Ablaufsteuerung stehen dann wie in einem Befehlsspeicher abstrakte Codes hintereinander und werden mittels einer intelligenten Struktur sequenziell abgearbeitet werden. Diese agiert wie ein Befehlsinterpreter und stösst eine untergeordnete state machine an. Damit wird zwar mehr Zeit für die Verwaltung benötigt, es führt aber letztlich zu quantitav weniger Steuer-Code. Die Befehlsfolgen lassen sich z.B. günstig in einem ROM realisieren. Die gesamte Steuerung wird intelligenter und insgesamt kleiner.

Eine deartige Steuerlogik lässt sich soweit ausbauen, dass untergeordnete state machines wie Unterprogramme ablaufen und durch ein flexibles Hauptprogramm gesteuert werden, womit sie sich immer mehr einer Prozessorarchitektur annähert.

Wenn die Komplexität viele "Befehle" erfordert, gfs noch gerechnet und viel entschieden werden muss, lohnt der Rückgriff auf einen vorgefertigen Softcore. Dies hat den Vorteil, dass eine Standardstruktur verwendet wird, für die es erweiterte Entwicklungs- und Debugging-Software gibt. Spätestens, wenn man mit virtuellen Datenstrukturen und rekursiven Funktionen arbeitet, oder z.B. Zeichenkettenverarbeitung braucht, ist ein Softcore unerlässlich, weil dann alle Methoden-, Variablen und sonstige Aspekte der jeweiligen Hochsprache verwendet werden können.

Beispiele von VHDL Code

Siehe VHDL_Softwarepool

Einsatz in elektronischen Schaltungen

Der Einsatz von modernen FPGAs erfordert neben dem grundsätzlichen Wissen im Bezug auf den design flow und den für FPGAs optimierten Schaltungs- und Rechenstrukturen auch grosses Knowhow im Bereich der analogen Schaltungstechnik sowie auch der effektiven Vorgehensweise beim Design.

FPGA aus analoger Sicht

FPGAs bedürfen heute eines perfekten Layouts, um mit RAMs und externen Chips zusammenarbeiten zu können, da sowohl die internen, als auch externen Taktfrequenzen rapide angestiegen sind. Ferner ist grosses Augenmerk auf die Spannungsversorgungen zu legen.

Integration ins PCB

Weiter ist es heute kaum noch möglich, FPGA-Design vom board-Design funktionell zu trennen, wie man es mit Blick auf den scheinbar rein logischen Schaltungsentwurf glauben könnte und früher auch der Fall war. Da FPGAs heute stark dedizierte Funktionen enthalten, die nicht in jeder IO-Zelle zur Verfügung stehen oder spezielle Bank-Konfigurationen erforden, muss der Schaltungsentwurf und das Layouten des FPGAs und des Boards einhergehen.

Entwicklungsboards und Starter-Kits

Von mehreren Seiten gibt es im Markt eine ganze Palette von sogenannten Entwicklungs- und Evaluierungsboards. Diese eignen sich nicht nur zum Kennenlernen des Chips, bez. zur Validierung der Lösung (ob die Schaltung wie gebaut auch im konkreten Ziel-FPGAs arbeitet) sondern werden immer öfter auch in bestehenden Systemen verbaut, weil aufgrund einer geringen Stückzahl die Selbstentwicklung nicht lohnt.

Siehe Liste von FPGA Eval boards

FPGA als Ersatz von alten digitalen ICs und Prozessoren

Es gibt vielfach den Wunsch, ICs, die nicht mehr direkt zu beschaffen sind, durch FPGAs (oder wenn möglich CPLDs) zu ersetzen. Gerade ältere Schaltungen basieren aber durchaus noch auf 5V TTL und CMOS Logik. Oft sind die Systeme nicht ohne sehr hohen Aufwand und Verlust der Wirtschaftlichkeit zu ersetzen (wie ältere, produktive Industrieanalagen oder komplexe Rechensysteme - aber auch wenn es um die Erhaltung alter Hardware bei "retro-computing" geht).

Nun bieten heute erhältliche (und günstige) FPGAs - aufgrund ihrer verwendeten Technologie - keine direkte 5V Kompatibilität mehr. FPGAs wie die Spartan II (nicht IIe), erlauben zumindest noch "5V Toleranz" auf den I/O-Pins. Das heißt: das FPGA wird zwar mit 3.3V versorgt und kann daher nur 3.3V am Ausgang treiben, erlaubt aber 5V von externen Bausteinen am Pin - dies ist nach wie vor TTL kompatibel, aber auch viele CMOS-Schaltungen können so durchaus noch betrieben werden.

Für neueste 3.3V (oder weniger) FPGAs kann man Levelshifter-Schaltungen verwenden, die entweder bidirektional ausgeführt sind und ein "open-drain-artiges" Verhalten zeigen (also beide Seiten können die Leitung nur auf Lowpegel treiben, der Highpegel wird durch pull-up Widerstände erreicht) oder die unidirektional (mit optionaler Richtungsumkehr und/oder Treiberdeaktivierung über Kontrolleingänge) gebaut sind. Verwendung von Spannungsteilern, Zenerdioden-Schaltungen oder Ausnutzung von Diodenlimitierungen der I/O Treiber des FPGAs (und Verwendung eines Serienwiderstands zur Stromlimitierung) sind zumeist nur für niedrige Schaltfrequenzen gut geeignet und sorgen für eine erhöhte Stromaufnahme.

Siehe auch: Pegelwandler

FPGA als Erweiterung von ICs und Prozessoren

In jüngster Zeit ist immer öfters zu beobachten, dass in ASICs und CPUs FPGA-Strukturen eingesetzt werden, um deren Funktion im Nachhinein zu optimieren und im Einzelfall Fehler auszugleichen.

1) Bei Kundenspezifischen ASIC-Schaltungen bieten einige Hersteller inzwischen an, einen kleinen FPGA als IO-Vorsatz zusammen mit einem EEPROM zu integrieren, um ein und denselben ASIC an unterschiedliche Baugruppen anpassen zu können.

2) Bei modernen Rechen-Cubes, die mit CUDA arbeiten, werden FPGAs mit integriert, um die Verschaltung zu optimieren und Nebenrechnungen durchzuführen. Einige Chips werden mit FPGA-ähnlichen RAM-Strukturen ausgestattet und beim Start geladen, um harte Schaltungen während des Betriebs zu ernmöglichen.

3) Zumindest der CPU-Hersteller Intel integriert FPGAs in seine CPUs, um langfristig längere Prozessorlaufzeiten zu ermöglichen, weil diese sich so einfacher an neue RAMs und andere Peripherie anpassen zu können. Gleichzeitig kann man so CPUs mit geringerem Reifestand produzieren und ausliefern.

Debugging-Hilfen

Soft-Debugging

Logikanalysatoren

Gerade beim Debugging größerer FPGA-Designs ist es oft notwendig, auf interne Signale und Busse zuzugreifen, die aus routing- oder Platzgründen nicht an Pins des FPGAs gelegt - und mit konventionellen Analysatoren beobachtet werden können. Nebst den einschlägigen Tools der Hersteller, welche Signal probing über JTAG gestatten (z. B. ChipsScope und SignalTap), werden in FPGAs oft mehr oder weniger komplexe Logic Analyzer integriert, welche die internen Signale in vielfältiger Weise aufzeichnen. Diese werden in Block-RAMs oder FIFOs gespeichert und durch externe Master ausgelesen. Hier kommen auf der Platine befindliche MCUs oder fremd zugreifende FPGAs / CPUs in Betracht, welche über unterschiedliche Kommunikationsverbindungen (seriell, parallel, LVDS) angeschlossen sind. Dazu werden in die FPGAs entsprechende Cores und state machines instanziiert und mit Software auf PC-Seite ausgelesen.

Nachfolgend einige Beispiele:

Automatisch instanziierte Logic Analyzer

Praktisch alle FPGA-Hersteller bieten die Möglichkeit, mit einem internen Tool ein script zu erzeugen, welches der Synthese übergeben wird, welche dann anhand von Signallisten und diversen Randbedingungen einen LA automatisiert aufbaut und verdrahtet. SampleZeit und -Takt sind dabei genauso einstellbar, wie RAM-Tiefe und -Breite. Die so generierten Datenpakete können dann mittels JTAG ausgelesen werden. Im Continous-Betrieb können so sogar permanente Datenausgaben wie bei einem Oszilloskop vorgenommen werden.

Proprietärer serieller Logic Analyzer

Die einfachste Möglichkeit ist die direkte Instanziierung eines Blockrams als FIFO mit "breitem" Busanschluss: Linksseitig besitzt das FIFO eine Breite von z. B. 256 Bit (Xilinx-Rams lassen sich ohne weitere Umbeschaltung über den Wizzard mit bis zu 1024 Bits deklarieren und nutzen). Rechtsseitig einen 16- oder 32 Bit breiten Busanschluss für einen Prozessor bzw Parallelinterface oder einen 1 Bit breiten Anschluss für ein serielles streaming interface. Mit einem FiFo-enable können die zu sampelnden Zeiten (Busphasen) festgelegt werden, z. B. anhand eines Kriteriums wie die Erfüllung einer bestimmten mathematischen Bedingung, die man in VHDL formuliert, oder es wird einfach ein Trigger gesetzt. Solange das FiFo nicht voll ist, kann geschrieben werden, was durch die interne FiFo-Verwaltung selbst bereits komplett geregelt wird.

Beim einfachen seriellen Logic Analyzer benötigt man nur noch einen kleinen Core, der permanent das FiFo liest, und den seriellen Overhead (Startbit, Stoppbit, Parity und gfs CRC) hinzufügt. Mit einem einfach Pegelwandler kann so ein PC direkt angeschlossen werden.

Auch denkbar ist die Anbindung an ein fremdes FPGA-board mit viel Speicher über (LV-)DS-Kommunikation. In komplexeren Systemen wird ein CAN- oder USB-Core eingesetzt.

Wenn mittels des Kriteriums nur ganz bestimmte kritische Phasen herausgesampelt werden (z. B. das Auftauchen eines bestimmten Rechenfehlers im FPGA) und so das Datenaufkommen je Zeiteinheit über längere Zeit betrachtet eher gering ist, kann bei geeignetem Datendurchsatz in Echtzeit dauerhaft mitprotokolliert werden.


BusProbe

Mit der BusProbe, dem Debugging Core von abaxor engineering, kann der Entwickler den Signalfluss im FPGA-Design auch über einen längeren Zeitraum überwachen und am PC aufzeichnen. Der Core verarbeitet an jedem Eingang einen kompletten Bus.

Die Daten werden gemultiplext zum PC geschickt und dort per Software demultiplext. Im PC erfolgt auch die Auswertung mit beliebigen Analyse-Tools.

Gegenüber dem Betriebssystem verhält sich die BusProbe wie eine Festplatte, von der die Daten mit gewöhnlichen Zugriffen gelesen werden können.

  • Streaming der Daten zum PC mit mehr als 20 MByte/s
  • keine Treiber im PC da Nutzung von Standardschnittstellen (USB oder IDE)
  • Hot-Plugging
  • Visualisierung mit beliebigen Programmen
  • geringer Logikaufwand

open source Logikanalysator

sump.org

Ein einfacher, übersichtlicher Logikanalysator findet sich auf sump.org. Er liegt im Quelltext vor wird mit ins Design einsynthetisiert. Als Speicher dient wahlweise SRAM oder internes RAM. Es können 32 Kanäle mit 100 MHz (oder weniger) gesampelt werden. Die Bediensoftware läuft platformunabhängig unter Java und benötigt eine serielle Schnittstelle (auch über USB-seriell Wandler) zum Core.

sump.org-Webseite

Weitere

http://www.mikrocontroller.net/articles/Logic_Analyzer

FPGA-Design aus Projektsicht

Vielfach wird die Auffassung vertreten, die FPGA-Entwicklung gehöre allein zur Hardwareentwicklung, da es sich um ein elektronisches Bauteil handle, welches lediglich konfiguriert werde. Man spricht bei der FPGA-Entwicklung oft auch ausdrücklich nicht vom "Programmieren" sondern "Beschreiben" der Hardware. Beides ist aus folgenden Gründen unrichtig:

  • Die Vorgehensweise, die Struktur einer Schaltung durch virtuelle Konstrukte wie Logikgatter, Multiplexer und Schalter zu definieren, die in der Praxis so gar nicht exisiteren, sondern später in Form von LUTs realisiert wird, ist zwar formell eine Beschreibung einer Struktur, jedoch ist es eine sehr abstrahierte Form, da äquivalente Funktionen definiert werden. Die Sollhardware wird demnach in weicher Form beschrieben.
  • Der output des Designers besteht aus Grafiken, Skripten, Anweisungen, Einstellungen der Synthesesoftware und Strukturvorgaben, die nicht selbst Hardware sind, sondern Anweisungen an eine Erzeugersoftware und stellen damit ein Programm (lat. "Vorschrift") dar.
  • Neben den allein schon durch die Nutzung bestimmter Funktionen wie RAMs, MCBs und Soft-Cores implizit vorgegebenen Abläufen im FPGA, werden fast immer auch noch weitere, explizite Handlungsabläufe mit Reaktionen auf äussere Einflüsse implementiert, die als klassische Software aufzufassen sind.
  • Der erzeugte Code der Erzeugersoftware wiederum ist selbst ein Programm und wird zusammen wie die Quellinformation des Designers archiviert, versioniert und wie übliche Software gehandhabt.

Damit erfüllt die FPGA-Entwicklung formell mehrere Bedingungen, die als Softwareentwicklung aufgefasst und eingruppiert zu werden. Andererseits ergeben sich durch die weiter oben erwähnten, sehr ausgeprägten Themen im Bereich der Elektronik (z.B. der Nachrichten- und HF-Technik) sowie der Physik eine Vielzahl von harten Anforderungen, der klassischen Hardwareentwicklung.

Zusammengefasst kann man daher 2 grundlegende Aspekte des FPGA-Designs konstatieren, die je nach Anwendungsfall als mehr oder weniger unabhängig von einander gesehen werden können.

Logikdesign

Das funktionslogische Design besteht aus dem Entwurf des Systems, der benötigten Abläufe und der zu realisierenden Protokolle und Berechnungsverfahren. Hierbei sind Kenntnisse im Systementwurf, gfs. von SOPC-Systemen, der üblichen Bussysteme und der Software generell nötig. Hinzu treten Kenntnisse in der elementaren und/oder der komplexen abstrakten Mathematik und der Signalverarbeitung sowie der theoretischen Nachrichtentechnik. Ferner sind Methoden des Script- und Softwareentwurfes, sowie Handhabung von Software nötig.

Dies alles stellt den Anteil dar, der klassischerweise als Softwareentwicklung aufgefasst wird. Es ist die Schnittstelle zur Funktionsschicht, also der grundsätzlichen Funktion eines Gerätes.

Schaltungsdesign

Das praktische, hardwaretechnische Anteil des Designens erstreckt sich zudem über die physikalischen Themen der Temperatur- und Betriebsstabilität, der Strahlungs- und Störsicherheit, der Produzier- und Herstellbarkeit, des Wirkens und der Fehleranfälligkeit interner Schaltungsstrukturen, der Art und Weise der Ressourcennutzung bei unterschiedlichen Realisationsformen - besonders, wenn es auch Kostenoptimierung ankommt, des Analogverhalten der IOs und internen Strukturen im Bezug auf Frequenz und Pegel, der Signalintegrität der FPGAs und der Leiterbahnen sowie alle Anfordernisse im Umfeld der anzubindenen Chips.

Dies ist der Anteil der gerne als Hardwareentwicklung eingestuft wird. Er stellt die Schnittstelle zur Physik und der Fertigung dar.

Fazit

Die Verwendung von FPGAs ist heute komplexer denn je und erfordert in aller Regel starke Kenntnisse in beiden Feldern. FPGA-Entwicklung kann praktisch wie die Einbindung eines komplexen Evaluierungsboards oder einer programierbaren Steuerplatine mit festgelegten Funktionen aufgefasst werden.

Siehe auch

Forumlinks

Weblinks

Abgerufen von „https://www.mikrocontroller.net/index.php?title=FPGA&oldid=104776“