Mikrocontroller.net - Benutzerbeiträge [de]

STM32 für Einsteiger

2017-06-27T13:01:07Z

2003:D2:3C8:5D00:224:8CFF:FE80:C59: /* Weitere Randbedingungen für die Entscheidung */

Immer wiederkehrend hier im Forum "Mit welchem Mikrocontroller anfangen?". Es gibt eine große Auswahl und eben so viele Empfehlungen. In diesem Artikel soll zu erst geholfen werden ob ein Cortex-M3/M4 Kern überhaupt der Richtige für den Start ist.
Nicht für jeden ist der [[Cortex]] zu empfehlen, denn die Anforderungen und Wünsche die man realisieren möchte, sowie die eigenen Fähigkeiten sind verschieden.

Es werden meist die Prozessoren [[AVR]], [[PIC]], [[Arduino]], [[MSP430]], [[LPC1xxx]] und [[STM32]] empfohlen. Seltener auch 8051 und M16C. Alle haben Vorzüge und ebenso auch Nachteile.

[[Bild:STM32F407SB.jpg|thumb|right|340px|STM32F417 auf einem Selbstbau-Board]]

= Eigene Fähigkeiten und Wünsche =

Dieser Artikel geht davon aus, dass bereits Elektronikkenntnisse vorhanden sind. Wenn nicht dann sollte man erst einmal den Artikel "[[Absolute Beginner]]" durcharbeiten, sowie die anderen Artikel aus der Kategorie "[http://www.mikrocontroller.net/articles/Kategorie:Grundlagen Grundlagen]".
 Weitere Artikel die andere Prozessoren näher darstellen da sich dieser Artikel hauptsächlich auf [[STM32]] konzentriert: [[Entscheidung Mikrocontroller]] und [[Mikrocontroller Vergleich]]. Die Seiten [[AVR]], [[MSP430]], [[LPC1xxx]] und [[PIC]] zeigen mehr Details über diese µC. Hier werden nur grob ein paar Tabelle zum Vergleichen gezeigt.

Zu erst einmal die Randbedingungen, mit der man sich selbst zu erst einmal einschätzen sollte:
{| {{Tabelle}}
|- bgcolor="#d0d0ff"
! Fähigkeit || [[Cortex]] || [[AVR]] || [[Arduino]] || colspan="3" | [[PIC]] || [[MSP430]]
|-
| Bitbreite, jedoch unwichtig für Einsteiger || align="center" | 32-bit || colspan="2" align="center" | 8-bit || align="center" | 8-bit (PIC18) || align="center" | 16-bit (PIC24) || align="center" | 32-bit (PIC32) || align="center" | 16-bit
|-
| Neueinsteiger, kaum Elektronikkenntnisse, noch nie programmiert
| align="center" | O
| align="center" | O <ref name="AVR_TUT1">[http://www.rn-wissen.de/index.php/AVR-Einstieg_leicht_gemacht], RoboterNetz: AVR-Einstieg leicht gemacht</ref><ref name="AVR_TUT2">[http://www.avr-asm-tutorial.net/avr_de/], Tutorial für das Erlernen der Assemblersprache von AVR-Einchip-Prozessoren</ref>
| align="center" | X
| colspan="3" align="center" | O
| align="center" | O
|-
| Wunsch ist SD-Card oder Grafik-Display
| align="center" | X
| colspan="2" align="center" | O
| align="center" | O <ref name="PIC_SD">[http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en537999], Microchip Memory Disk Drive File System for PIC18 PIC24 dsPIC PIC32</ref> || align="center" | X<ref name="PIC_SD" /><ref name="PIC_LCD">[http://www.microchip.com/pagehandler/en-us/technology/graphics/], Microchip Graphics Library</ref> || align="center" | X<ref name="PIC_SD" /><ref name="PIC_LCD" />
| align="center" | X
|-
| Wunsch ist TCP/IP Netzwerk
| align="center" | X
| colspan="2" align="center" | O
| colspan="3" align="center" | X <ref name="PIC_TCP">[http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2505&param=en535724], Microchip TCP/IP stack</ref>
| align="center" | O
|-
|-
| Wunsch ist Kamera und Video-/Bildbearbeitung
| align="center" | X
| colspan="2" align="center" | -
| align="center" | - || align="center" | - || align="center" | X
| align="center" | -
|-
| Möchte die Erkenntnisse beruflich nutzen
| align="center" | X
| align="center" | X
| align="center" | -
| colspan="3" align="center" | X
| align="center" | X
|-
| Strom sparende Anwendungen
| align="center" | - 300 nA Sleep<ref name="STM_Power">[http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1295], [[STM32]] L1 series of ultra-low-power MCUs</ref> 230 μA/MHz
| align="center" | - 100 nA Sleep<ref name="AVR_Power1">[http://www.atmel.com/technologies/lowpower/default.aspx], Atmel picoPower Technology</ref> <ref name="AVR_Power2">[http:/www.futurlec.com/News/Atmel/PicoPower.shtml], Atmel Releases New picoPower AVR Microcontrollers</ref> 340 μA/MHz
| align="center" | -
| colspan="2" align="center" | X 9 nA Sleep<ref name="PIC_XLPvsTI">[http://ww1.microchip.com/downloads/en/DeviceDoc/39989A.pdf], The Truth about Power Consumption in PIC® MCUs with
XLP Technology vs. TI’s MSP430</ref><ref name="PIC_XLP">[http://ww1.microchip.com/downloads/en/DeviceDoc/30009941F.pdf], nanoWatt XLP eXtreme Low Power PIC® Microcontrollers</ref> 35 μA/MHz || align="center" | -
| align="center" | X 100 nA Sleep<ref name="TI_Power1">[http://www.ti.com/lit/wp/slay015/slay015.pdf], Texas Instruments: Ultra-Low Power Comparison: MSP430 vs. Microchip XLP</ref><ref name="TI_Power2">[http://www.ti.com/ww/mx/multimedia/webcasts/Aspectos_Generales_MSP430.pdf], Texas Instruments: Meet MSP430</ref> 100 μA/MHz
|-
| Multithreading, RTOS, Schedulern
| align="center" | X
| align="center" | - <ref name="AVR_RTOS1">[http://www.freertos.org/a00098.html], Atmel AVR freeRTOS port</ref><ref name="AVR_RTOS2">[http://www.femtoos.org/], Femto OS: RTOS for small MCU's like AVR</ref>
| align="center" | -
| align="center" | - <ref name="PIC_RTOS2">[http://www.freertos.org/a00097.html], Microchip PICmicro (PIC18) freeRTOS Port</ref> <ref name="PIC_RTOS3">[http://www.pumpkininc.com/], Salvo RTOS</ref>|| align="center" | X<ref name="PIC_RTOS">[http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en531543&redirects=rtos], 3rd Party RTOS selection guide</ref> || align="center" | X<ref name="PIC_RTOS" />
| align="center" | X <ref name="TI_RTOS">[http://processors.wiki.ti.com/index.php/MSP430_Real_Time_Operating_Systems_Overview], TI Wiki: MSP430 Real Time Operating Systems Overview</ref>
|-
| Besonders große, speicherintensive Programme z.B. Grafiken, Fonts
| align="center" | bis 2MB Flash bis 256kB SRAM <ref name="STM32Ueb">[http://www.st.com/web/en/catalog/mmc/FM141/SC1169], Übersicht aller verfügbaren [[STM32]] µC von ST</ref>
| colspan="2" align="center" | bis 256kB Flash bis 16kB SRAM
| align="center" | bis 128kB Flash bis 4kB SRAM || bis 2MB Flash bis 98kB SRAM || bis 2MB Flash bis 512kB SRAM
| align="center" | bis 512KB Flash bis 66kB SRAM
|-
| Sehr viel PWM mit komplexem Timing
| align="center" | X
| align="center" | AT90Spwm
| align="center" | -
| align="center" | - || align="center" | X || align="center" | X
| align="center" | O
|-
| Deutschsprachige Community
| align="center" | O
| align="center" | X
| align="center" | X
| align="center" | X <ref name="PIC-Projekte">[http://pic-projekte.de/], pic-projekte.de</ref> <ref name="SPRUT">[http://www.sprut.de/], sprut.de</ref> || align="center" | - || align="center" | -
| align="center" | -
|-
| Anzahl möglicher HW-Breakpoints
| align="center" | 4 bis 6
| colspan="2" align="center" | 2
| align="center" | 1 bis 5 <ref name="PIC_HWBP">[http://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en556761.pdf], PIC Hardware Breakpoints (Seite 6)</ref> || align="center" | 1 bis 10 <ref name="PIC_HWBP"/> || align="center" | 6<ref name="PIC_HWBP"/>
| align="center" | 2
|}
* X = ja
* O = Teilweise, Einschränkungen
* - = nicht empfohlen
Nur um nicht zu verwirren, auch wenn Teile "nicht empfohlen" sind, heißt das nicht dass es mit dem Prozessor nicht geht, vielmehr dass es mehr Aufwand ist das zu realisieren oder mehr Einschränkungen hat.
Viele Eigenschaften weisen nur bestimmte Modelle einer Mikrocontrollerfamilie auf. Der Wechsel innerhalb einer Familie gestaltet sich jedoch oft einfach (z.B. innerhalb [[STM32]] oder innerhalb PIC24).

Die Spalte Cortex zeigt die Prozessorfamilie von STM32F0xx bis STM32F4xx mit einem Cortex-M0 oder M3/M4 Kern. Die technischen Daten sind ähnlich anderer Hersteller die auch einen Cortex-Mx Kern verbauen wie z.B. NXP ([[LPC1xxx]]), Freescale, Atmel, TI, Toshiba, usw. Jedoch bietet ST mit dem [[STM32]] eine hohe Flexibilität an Gehäuse-Variationen (vergleichbar mit NXP [[LPC1xxx]]) und ist privat recht leicht beschaffbar. Übersicht aller verfügbaren [[STM32]] µC von ST<ref name="STM32Ueb">[http://www.st.com/web/en/catalog/mmc/FM141/SC1169], Übersicht aller verfügbaren [[STM32]] µC von ST</ref>.

Der STM32 ist in der Tat nicht der beste in der Kategorie "Stromsparend", jedoch um eine Alternative mit Cortex-Mx Kern auf zu zeigen:
 "EFM32" von Silabs<ref name="EFM32">[http://www.silabs.com/products/mcu/lowpower/Pages/efm32-energy-modes.aspx], EFM32, der Stromsparende mit Cortex-Mx Kern</ref> benötigt nur 0,9 µA im Sleep Mode.

Die Spalte PIC zeigt die Eigenschaften der 8-Bit PIC18 (vergleichbar mit [[AVR]]), 16-Bit [[PIC24]]/[[dsPIC]] (vergleichbar mit [[MSP430]]) und 32-Bit [[PIC32]] (vergleichbar mit [[STM32]]). Ein Wechsel des Mikrocontrollers innerhalb der Familien ist Codetechnisch problemlos möglich. <ref name="PIC_codeswitch">[http://www.elektor.nl/Uploads/Files/PIC24FIntro_5f082806.pdf], Microchip: Introduction to the 16-bit PIC24F Microcontroller Family</ref> Hardwaretechnisch sind verschiedene Modelle gleicher Familie zudem auch meist Pin-Kompatibel <ref name="PIC_PinCompatibility">[http://ww1.microchip.com/downloads/en/DeviceDoc/00148m.pdf], Microchip: 2007 Product Selector Guide (Seite 114 ff.)</ref> sodass ohne Design-Änderung zwischen verschiedenen Modellen gewechselt werden kann.
Ein Wechsel zwischen den Familien ist Architekturbedingt aufwendiger, vor allem von 8-Bit auf 16/32-Bit. <ref name="PIC_8to16Migration">[http://ww1.microchip.com/downloads/en/DeviceDoc/39764a.pdf], Microchip: PIC18F to PIC24F Migration: An Overview</ref> Aufgrund gleichbleibender IDE (Mplab) sowie gleichbleibenden Libraries bei Verwendung einer Hochsprache (C) jedoch vor allem zwischen 16-Bit und 32-Bit ohne weitere Probleme möglich <ref name="PIC_16to32Migration">[http://www.embedded.com/design/mcus-processors-and-socs/4007683/Practical-migration-from-8-16-to-32-bit-PIC], Artikel: Practical migration from 8-/16- to 32-bit PIC</ref>.
 Ein PIC10/12/16 ist für den Einstieg nicht empfohlen, da diese Architekturbedingt viele Einschränkungen haben, die eher hinderlich für das Lernen sind.

Der "[[Arduino]]" ist kein eigenständiger Prozessor, sondern ein fertiges Board mit einer "[[Arduino]]" Programmierumgebung (und einem AVR Prozessor), extra geschaffen für Einsteiger. Allerdings ist da der Lerneffekt viel geringer da man den Prozessor mit der [[Arduino]]-Software programmiert und nicht direkt die Register. Anderseits ist der Arduino besser für jemanden geeignet, der eigentlich nicht lernen möchte, sondern nur mal schnell etwas steuern/basteln will und so ohne großartige µC Kenntnisse zum Ziel kommt. Für diese Zielgruppe ist der Arduino perfekt.

<references />

= Unwichtige Randbedingungen =

Oftmals werden fälschlicherweise Argumente für oder gegen eine µC-Familie ausgesprochen, die in der Praxis '''zum Einstieg''' (bei konkreten Anwendungen kann das anders aussehen) eher unwichtig sind.

* Spannungsversorgung 3,3V / 5V (Wobei z.B Atmel XMega keine 5V Tolerante Eingänge besitzt)
* 8 (z.B. [[AVR]]), 16 (z.B. [[MSP430]]) oder 32 (z.B. [[STM32]]) Bit
* Prozessorkern Cortex-M0/M3/M4, MIPS, ARM7/9/..., AVR-RISC, PIC-RISC, 8051, ...
* Interrupt System mit mehr oder weniger Features
* Programmiersprache (Assembler, Basic, C, C++, Pascal)
* Programmierumgebung - ist ohnehin Geschmackssache
* Assembler verstehen (Sollte nur theoretisch verstanden werden, ein Programm sollte in einer Hochsprache geschrieben sein)
* DIL Gehäuse - steckbretttauglich ([[STM32]]-Prozessoren gibt es auch fertig gelötet auf einem steckbretttauglichen Board)
* Programmieradapter - solange er auch debuggen kann
* zu 90% reicht doch ein kleiner Prozessor ([[AVR]]/PIC) - und für die restlichen kann man immer noch einen großen nehmen. Warum also nicht gleich einen großen nehmen?

= Kosten =

Grobe Abschätzung was das alles denn kosten wird. Hier sind nur einige Beispiele gezeigt (Einzelpreise bei Bezugsquellen in Deutschland).

{| {{Tabelle}}
|- bgcolor="#d0d0ff"
! Board || [[STM32]] || [[AVR]] || PIC18/24/32 || [[MSP430]] || [[Arduino]]
|-
| Demo-Board
| align="center" | <ref name="STM32F4DISCOVERY">[http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252419], ST STM32F4DISCOVERY Demoboard</ref> 9..20€ (incl. Programmieradapter und Debugger)
| align="center" | 5..500€, z.B. [[Arduino]] || align="center"| <ref name="PICDEMOBOARD">[http://www.microchipdirect.com/ProductDetails.aspx?Catalog=BuyMicrochip&Category=Starter%20Kits&mid=1&lmid=610], Microchip Demoboard</ref> durchschnittlich 18€ .. 50€ (Für 16 und 32bit auch mit integriertem Debugger + Programmer)
| align="center" | <ref name="MSP430DEMOBOARD">[http://www.ti.com/tool/msp-exp430fr5739], MSP430 Demoboard</ref> ~35€
| align="center" | 20€
|-
| Steckbrettaugliches Board
| align="center" | s.o. oder <ref name="STM32F405Board">[http://re.reworld.eu/de/produkte/s64dil-405/index.htm], S64DIL-405 mit STM32F405</ref>S64DIL-405 30€, STM32F103C8 4€ (China)
| align="center" | DIP IC
| align="center" | DIP IC oder Microstick
| align="center" | DIP IC
| align="center" | ab ca. 1.50€ (Pro Mini, China)
|-
| Einzelchip (Einzelstückpreise)
| align="center"| 2..15€ nur SMD (TSSOP..LQFP..BGA)
| align="center"|0,6–5€ SMD + DIP
| align="center"|0,5-15€ SMD + DIP
| align="center"|??
| align="center"|siehe AVR
|-
| Programmieradapter
| align="center" | 0€ da Bootloader (ROM) UART / USB usw. unterstützt
| align="center" | ab 4€
| align="center" |
| align="center" |
| align="center" |
|-
| Programmieradapter mit Debugger
| align="center" | s.o. oder z.B <ref name="JLINKEDU">[http://www.segger.com/j-link-edu.html], Segger J-LINK EDU</ref> Segger J-LINK EDU 50€ (sehr schnell und unterstützt viele Prozessoren)
| align="center" | <ref name="AVRDragon">[http://www.atmel.com/tools/AVRDRAGON.aspx], Atmel AVR Dragon</ref> AVR Dragon 40€ <ref name="JTAGICE3">[http://www.atmel.com/tools/JTAGICE3.aspx], AT JTAG ICE3</ref> AT JTAG ICE3 99€
| align="center" | <ref name="PICKIT3">[http://www.microchipdirect.com/ProductSearch.aspx?keywords=PG164130], Microchip PICkit 3</ref> PICkit 3 30€
| align="center" | z.B. Dragon 50€
| align="center" | 20€ (Man muss DebugWire aktivieren)
|}

Das Demo-Board sollte ein Board sein, nicht zu teuer, um die ersten Erfahrungen zu sammeln. Wenn einem der Prozessor gefällt, so kann man später immer noch mit einem zweiten Demo-Board, z.B. mit Display aufrüsten.

Wenn man gerne mit einem Steckbrett sich die Schaltung zusammen stecken möchte, so kann man entweder die benötigten Drähte am Demo-Board anlöten oder bei z.B. [[AVR]]/[[PIC]] Prozessoren gibt es Ausführungen im DIL Gehäuse, die direkt steckbar sind.

Ein Programmieradapter sollte unbedingt auch einen Debugger beinhalten. Denn für den Start ist es ungemein hilfreich zu sehen was im Prozessor gerade geschieht. Die JTAG-Adapter für einen [[STM32]] Prozessor sind alle Debugger-Tauglich. Für die [[AVR]] Controller gibt es auch oft reine Programmer (AVR ISP oder Selbstbau-Lösungen über die serielle oder parallele Schnittstelle) welche den Mikrocontroller nur beschreiben können. Für die [[PIC]] Controller werden solche reinen Programmer vereinzelt auch noch angeboten. Sinvoller sind hingegen Debugger, die die Ausführung eines Mikrocontrollers anhalten können um die aktuelle Position im Programmcode, Variableninhalt, Register, ... auszulesen bzw. zur Laufzeit zu ändern.

Der für den [[STM32]] empfohlene Segger J-LINK EDU ist zwar nicht der günstigste (z.B. auf einem STM32F4DISCOVERY Board ist ein ST-LINK/V2 mit drauf, den man für andere [[STM32]] nutzen kann) aber eines der besten, mit sehr guten Software-Tools und nutzbar für alle Prozessoren mit ARM-Kern (ARM7/9/11/... Cortex-Mx der Hersteller Atmel, Energy Micro, Freescale, Holtek, TI, NXP, Nuvoton, ST, Toshiba, ... unter Windows, Linux und MAC). Niemals am Werkzeug sparen und man hat viel mehr Freude bei der Arbeit.

<references />

= Programmierumgebungen=

Bei den Programmierumgebungen gibt es zu allen Prozessorfamilien kostenlose und Leistungsfähige Software

{| {{Tabelle}}
|- bgcolor="#d0d0ff"
! Betriebssystem || [[STM32]] || [[AVR]] || [[PIC]] || [[MSP430]] || [[Arduino]]
|-
| Windows
| align="center"|[http://www.coocox.org/CooCox_CoIDE.htm CooCox, EmBitz, Eclipse]
| align="center"|Atmel-Studio
| align="center"|[http://www.microchip.com/pagehandler/en-us/family/mplabx/ MPLAB X] (IDE inklusive compiler)
| align="center"|TI Code Composer Studio
| align="center"|[[Arduino]] IDE
|-
| Linux
| align="center"|[http://eclipse.org/downloads/ Eclipse IDE for C/C++ Developers]
| align="center"|z.B. [http://eclipse.org/downloads/ Eclipse IDE for C/C++ Developers]
| align="center"|[http://www.microchip.com/pagehandler/en-us/family/mplabx/ MPLAB X] (IDE inklusive compiler)
| align="center"|TI Code Composer Studio
| align="center"|[[Arduino]] IDE
|-
| MacOS
| align="center"|[http://eclipse.org/downloads/ Eclipse IDE for C/C++ Developers]
| align="center"|??
| align="center"|[http://www.microchip.com/pagehandler/en-us/family/mplabx/ MPLAB X] (IDE inklusive compiler)
| align="center"|TI Code Composer Studio
| align="center"|[[Arduino]] IDE
|}

natürlich gibt es noch viele weitere (für [[STM32]] siehe [[STM32#Programmierung]]), es sollte jedoch nur die jeweils einfachste kostenlose (und ohne Codebegrenzung) für den ersten Einstieg gezeigt werden.

* [http://www.coocox.org/CooCox_CoIDE.htm CooCox] Anleitung wie man innerhalb einer Stunde die LED eines Nagel neuen STM32F4DISCOVERY Boards zum blinken bekommt, Artikel: [[STM32 CooCox Installation]]. Diese Anleitung ist eine Schritt-Für-Schritt Anleitung um den aller ersten Start zu vereinfachen.
* Mit [http://www.coocox.org/CooCox_CoIDE.htm CooCox] können sehr viele Prozessoren mit Cortex-M0, M3 und M4 Kern programmiert werden. Unter anderem der Firmen Atmel, Energy Micro, Freescale, Holtek, TI, NXP, Nuvoton, ST und Toshiba. Somit hat man eine Entwicklungsumgebung und ist damit nicht an einen Hersteller der µC gebunden.
* Mit [http://www.microchip.com/pagehandler/en-us/family/mplabx/ MPLAB X] können alle Prozessoren von Microchip (z.B. PIC18, PIC24, PIC32, dsPIC) programmiert werden.

= Dokumentation=

Bevor man sich für einen Prozessor entscheidet, sollte man unbedingt deren Dokumentation mal zumindest überfliegen und auch deren Errata lesen. Nicht dass man eine Anwendung erstellen möchte und stellt hinterher fest, dass genau dieser Teil so buggy ist, dass er nicht genutzt werden kann.

Beim [[STM32]] hat die Dokumentation doch recht viele Seiten, viel mehr als bei einem [[AVR]] oder PIC, dabei ist vieles eher knapp beschrieben. Der Aufbau der [[STM32]] Dokumentation ist [http://www.mikrocontroller.net/articles/STM32#Struktur_der_Dokumentation: hier] beschrieben.
 Bei den PICs ist die Dokumentation wiederum anders strukturiert, [http://www.mikrocontroller.net/articles/PIC#Dokumenatation siehe im PIC Artikel].

Für die [[STM32]], [[AVR]] und [[PIC]] Mikrocontroller gibt es zudem viele, auch deutschsprachige Einsteigerhilfestellungen und Tutorials.

Parallel zur Dokumentation sollte man sich auch die Demo-Beispiele der Hersteller anschauen, dann wird vieles gleich verständlicher.

Eine Übersicht über die Funktionen gibt es im Artikel: [[STM32]]

= Die Arbeit mit dem [[STM32]]=

Zu erst einmal SOOO groß sind die Unterschiede zwischen den einzelnen Prozessoren nicht. Alle haben Ein-/Ausgänge und um mittels einem Port-Pin eine LED ansteuern zu können, muss bei jedem Prozessor der Pin erst einmal parametriert werden, egal ob das jetzt ein [[STM32]] oder ein [[AVR]] oder ein [[MSP430]] ist. Nur hat man bei einem [[STM32]] doch einige Funktionen mehr, z.B. zuschaltbarer Pull-Up oder Pull-Down Widerstand und spezielle Setz-Rücksetzregister, die andere Prozessoren nicht haben, jedoch das Programmieren vereinfachen.
Der Haupt-Unterschied zu den anderen Prozessoren ist, dass der [[STM32]] so viele Peripherie-Module beherbergt, dass man die einzeln immer mit einem Clock aktivieren muss, denn damit lässt sich viel Strom sparen.

Und mal ganz ehrlich die Diskussion, welcher µc einfacher zu konfigurieren ist, ist doch absoluter Unsinn. Der Weg ist immer der Gleiche:
*1. Blick ins Datenblatt, welche Register für diese Funktion benötigt werden.
*2. Werte ermitteln, die in die Register eingetragen werden.
*3. Werte ins Register schreiben. Da machte es GAR KEINEN UNTERSCHIED, ob es ein [[AVR]], 8051/2, [[ARM]],...... ist.

Stimmt schon, es gibt Unterschiede. Die Register haben anderen Namen, andere Adressen, andere Bitbedeutungen,...
Aber es steht doch alles im Datenblatt. Und ob ich jetzt einen [[AVR]] oder einen [[ARM]] das erste Mal vor mir liegen hab. Ich brauch in allen Fällen die oben beschriebenen Schritte.

Das Interruptsystem ist bei einem [[STM32]] zusätzlich priorisiert. Damit kann man festlegen, welcher Interrupt vorrangig bearbeitet wird. Die Prioritätenvergabe ist auch kein Hexenwerk.

Zu allen Prozessoren liefern die jeweiligen Hersteller umfangreiche Demo-Codes und Libraries mit. Meist sind alle in C geschrieben, daher sollte auch die Programmiersprache C verwendet werden. Vor allem auch wenn man berufliche Absichten verfolgt.

Und wenn man einen [[STM32]] kann, dann ist ein Umstieg auf einen [[LPC1xxx]] (NXP) oder andere Hersteller überhaupt kein Problem (*), denn die bieten ebenfalls Prozessoren mit Cortex-M3 Kern und man kann diese mit der gleichen Programmierumgebung programmieren. Somit ist man nicht zwingend herstellerabhängig. (* jeder Hersteller verbaut seine eigene Peripherie, die andere Funktionalitäten haben.)

Mit einem [[STM32]] kann man als Hobby-Baster und professionell nahezu alle Anwendungen realisieren. Der hat genügend RAM und FLASH Speicher und auch genügend Geschwindigkeit. Viele Gehäuse-Varianten, um kleine bis hin zu größere Geräte zu erstellen. Viele Schnittstellen sind im Artikel [[STM32]] beschrieben.

Für den Einstig gibt es diverse, auch deutschsprachige, Tutorials im Netz. Eine Übersicht ist [http://www.mikrocontroller.net/articles/STM32#Weblinks.2C_Foren.2C_Communities.2C_Tutorials hier auf der STM32 Seite]. (Beispiel: [http://diller-technologies.de/stm32_wide.html STM32 Tutorial in Deutsch von Diller Technologies])
 Wobei dazugesagt werden muss, dass diese meist auf die Standard ST-Libs aufbauen. Diese Libs vereinfachen zum einen das Ansteuern/die Benutzung der Peripheriefunktion zum anderen muss man diese erst mal kennenlernen. Vereinfacht wird das da ALLE [http://www.st.com/stonline/stappl/productcatalog/app?page=partNumberSearchPage&levelid=SS1577&parentid=1743&resourcetype=SW ST-Demo-Codebeispiele] ebenfalls auf diesen Lib's basieren und somit wird der Wechsel innerhalb des [[STM32]] deutlich vereinfacht.
 STM32F4xx Library von ST: [http://www.st.com/web/en/catalog/tools/PF257901# "STSW-STM32065 STM32F4 DSP and standard peripherals library"] incl. Dokumentation und Demo-Projekte zu allen CPU-Funktionen.

Der einzige Nachteil beim [[STM32]]: Man muss etwas mehr lesen, da eine Peripherie doch viel mehr Funktionalität hat (sofern man das Modul überhaupt benötigt). Ansonsten kenne ich nicht wirklich einen Grund, warum man als Neueinsteiger keinen [[STM32]] nehmen sollte.

= Programmiersprachen =
* Wie bei vielen anderen Controllern wird beim [[STM32]] auch hauptsächlich C und C++ verwendet. Kennen sollte man die Programmiersprache C schon, wenn man davon noch keine Ahnung hat dann sollte man erst mal mittels einem Tutorial auf einem PC ein Konsoleprogramm schreiben, sodass man es einigermaßen kennen lernt. Hier im Forum gibt es ebenfalls Artikel dazu. Zielt man auf die (spätere) Anwendung in der Industrie, sollte aufgrund der Verbreitung auf jeden Fall C (oder C++) gewählt werden; außerdem sind die meisten verfügbaren Libraries in C geschrieben.
* Assembler sollte man nur grob verstehen, Details wie ein Befehl arbeitet ist unwichtig. Selbst wenn man die Zyklen für einen Funktionsaufruf wissen will, so bietet der [[STM32]] (Cortex-M3) einen Cycle-Counter den man auslesen kann; durch die komplexere Pipeline und Cache-Effekte sind die Laufzeiten allerdings nicht genau vorhersehbar. Wird zyklengenause Timing benötigt, sollten Timer verwendet werden - davon hat der [[STM32]] genug.

Der 32bit-Adressraum, der RAM, Flash, I/O-Register vereinheitlicht ansprechen kann (im Gegensatz zu z.B. [[AVR]]) ist ideal für eine Verwendung durch Hochsprachen; bei Pointern muss keine zusätzliche Information verwaltet werden, in welche Art Speicher sie zeigen. Die Adresse gibt dies eindeutig an (es gibt nur '''eine''' Adresse 42, und nicht 2 wie z.B. beim [[AVR]] (Flash, RAM & I/O)) und die Hardware spricht automatisch den richtigen Speicher an. Die Möglichkeiten zur Offset-Adressierung, der Barrel-Shifter, Divsions-Einheit, die FPU (bei STM32F4), Interrupt-Modell etc. begünstigen ebenfalls die Erzeugung effizienteren Codes. Außerdem haben die [[STM32]] einfach mehr "rohe Leistung", d.h. mehr Flash/RAM-Speicher und höhere Taktfrequenzen. 
 
'''Folgerung''': Die Programmierung in Hochsprachen ist '''bequemer als bei 8-Bittern''', denn man muss sich einfach weniger Gedanken machen, ob der Compiler ein Programm nun effizent umsetzen kann (kann man natürlich trotzdem machen, um noch mehr Leistung "herauszuquetschen", wenn man will).

= Weitere Randbedingungen für die Entscheidung=

Der wichtige Punkt, der oftmals auch vergessen wird: die Beschaffbarkeit. Wenn jemand einen Renesas M16C oder Fujitsu empfiehlt, dann sucht man erst mal und findet nur wenige vereinzelte die man privat kaufen kann.

Oder auch die Unterstützung im Internet - ist bei einigen Exoten spärlich. Dieses Forum bietet die beste Hilfe für [[AVR]], PIC, [[MSP430]], [[LPC1xxx]] und [[STM32]].

Andere Prozessoren sind schon sehr alt, bzw. nicht mehr modern da deren Peripherie zum Teil doch recht eingeschränkte Funktionalität bietet. z.B. viele 8051 Typen oder PIC16 (oder auch dsPIC30). Die mögen für Mini-Anwenungen gut sein, aber wer will den schon gerne sich extra für eine Kleinanwendung mit einem kleinen µC auseinandersetzen, wenn er schon einen [[STM32]] kennt, mit dem er alles machen kann (und sich bereits gute Funktionen geschrieben hat)?

Daher mein Resümee: wer nicht gerade auf den Kopf gefallen ist, der kann getrost mit einem [[STM32]] starten. Ein [http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252419?s_searchtype=keyword STM32F4DISCOVERY] Board kostet nur ca. 20 EUR - und mehr muss für den ersten Start nicht investiert werden - wenn es doch zu komplex sein sollte gibt es hier im Forum auch viel Hilfe. Jedenfalls sind diese 20 EUR wirklich keine große Investition.
 Wer berufliche Absichten verfolgt, sollte zu einem späteren Zeitpunk sich unbedingt auch mit einem zweiten, anderen Prozessor beschäftigen um so die nötigen Erfahrungen zu gewinnen.

Ein paar Forenbeiträge:
* [http://www.mikrocontroller.net/topic/317792#3481048 "Klein anfangen!" heisst die Devise]
* [http://www.mikrocontroller.net/topic/312330#3483218 Einen 8-Bitter nehme ich nur noch aus "Nostalgiegründen"]

= Übersicht CPU Funktionalitäten=

In diesem Abschnitt ist kurz gezeigt welche Möglichkeiten die CPUs bei den oben empfohlenen Einsteigerboards haben

=== STM32F407 - vom STM32F4DISCOVERY Board ===

{| class="wikitable"
|-
| [[Datei:STM32F407.png|mini|x400px]]
| [[Datei:stm32f4_discovery2.png|mini|x400px]]
|-
| [http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN11/PF252140?s_searchtype=partnumber Blockdiagramm STM32F407]
| [http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252419 STM32F4DISCOVERY Demoboard]
|}

Es sind sehr viele Peripheriemodule im µC implementiert. Jedes einzelne Peripherie-Modul (z.B. Ethernet, USB, CAN, Timer, AD-Wandler, usw.) kann aktiviert werden, indem der Clock freigeschaltet wird. So lange der Clock nicht aktiviert wurde verhält sich das Modul so als ob es nicht vorhanden wäre und beeinträchtigt in keinster Weise die Bearbeitung vom Prozessor. Somit lässt sich der Stromverbrauch senken.

Eine ganze Auflistung der Einzelmodule steht im Artikel: [[STM32]] und [http://www.st.com/web/en/catalog/mmc/FM141/SC1169 auf der Homepage von ST]

Zu Anfang mag vielleicht die interne Busstruktur verwirren, jedoch braucht man diese nicht beachten. Wenn nun die CPU auf UART4 zugreifen möchte, so gehen die Daten durch die Busse "AHB1" > "ABH/APB1-Bridge" > "APB1". Dies erledigt der µC ganz von alleine. Diese Unterteilung ist technisch nötig, da die Peripheriebusse nicht mit dem gleichen Prozessortakt betrieben werden (wie z.B. bei [[MSP430], siehe Schaubild unten), die "Bridge" managt ganz alleine das Handling und generiert automatisch Wait-Befehle für die CPU.
 Die "AHB-Bus-Matrix" ist ebenfalls für den Anwender meist uninteressant. ST hat damit ein System geschaffen, damit die CPU, DMAs und Displaycontroller gleichzeitig auf die verschiedenen RAM-Bereiche zugreifen können um mehr Daten parallel zu verarbeiten. Somit braucht man diese Matrix erst mal nicht beachten.

Ebenso braucht man zu Anfang sich auch keine Gedanken um den Prozessortakt machen, wenn man nichts initialisiert so läuft der STM32F4xx mit dem internen RC-Oszillator von 16MHz und die Peripheriebusse laufen ebenfalls mit der gleichen Geschwindigkeit. Erst wenn man später umfangreichere Applikationen schreibt, bei der die 16MHz nicht mehr reichen, so kann man die PLL aktivieren und die Taktrate flexibel bis auf 168MHz hochsetzen. (Siehe Demo-Projekt von [[STM32 CooCox Installation]].)

=== [[AVR]] ([[Arduino]])===

Details können im Artikel [[AVR]] gelesen werden.

=== PIC18, PIC24, PIC32===

Details können im Artikel [[PIC]] gelesen werden.

=== MSP430 - vom MSP-EXP430FR5739 Experimentier-Board===

{| class="wikitable"
|-
| [[Datei:MSP430FR5739.gif|mini|450px]]
| [[Datei:MSP-EXP430FR5739.jpg|mini|x350px]]
|-
| Blockdiagramm MSP430FR5739
| MSP-EXP430FR5739 Demoboard
|}

Details können im Artikel [[MSP430]] gelesen werden.

=== LPC1x d.h. Cortex -M0 & -M3 Familie von NXP ===
Details können aus dem Leitartikel [[LPC1xxx]] und den darin verlinkten Artikeln entnommen werden.

= Tipps und Tricks bei der Programmierung=

===Interruptcontroller vom Cortex-M3/M4===

Der "Nested Vectored Interrupt Controller" (NVIC) ist eine Funktion der ARMv7M Architektur und ist über die CMSIS verwendbar.

Beim STM32 hat jeder Interrupt eine Priorität von 4 Bit (bei ARMv7M je nach Implementation bis 8bit möglich). Diese 4 Bit können in eine "pre-emption priority" und "subpriority" unterteilt werden.

Beispiel 2 Bit zu 2 Bit Unterteilung:
<syntaxhighlight lang="c">
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2); // 2 Bits für pre-emption priority
</syntaxhighlight>

Somit kann "pre-emption priority" den Wert 0..3 und "subpriority" auch 0..3 erhalten. Um so kleiner die Zahl ist um so höherwertig ist der Interrupt.

Beispiel:
 ISR1 Pre 2 / Sub 1
 ISR2 Pre 1 / Sub 1
 ISR3 Pre 1 / Sub 2

Wenn jetzt ISR1 kommt, dann wird der aufgerufen. Kommt während dem ein ISR2 dann darf der den ISR1 unterbrechen, da er eine höhere "pre-emption priority" Wertigkeit hat.

Wenn ISR2 bereits aktiv ist, so darf ISR3 diesen nicht unterbrechen, ISR1 ebenfalls nicht.

Wenn ISR2 und ISR3 gleichzeitig kommen, so wird zu erst ISR2 bearbeitet, anschließend ISR3 da beide die gleiche "pre-emption priority" haben fällt die Entscheidung anhand der "subpriority".

Beispiel Interrupt Konfiguration für USART1 mittels CMSIS-Funktionen:
<syntaxhighlight lang="c">
NVIC_InitTypeDef NVIC_InitSt;
NVIC_InitSt.NVIC_IRQChannel = USART1_IRQn;
NVIC_InitSt.NVIC_IRQChannelPreemptionPriority = 3; // << Tiefe Prio
NVIC_InitSt.NVIC_IRQChannelSubPriority = 1;
NVIC_InitSt.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitSt);
</syntaxhighlight>

=== Taktzeitberechnung und Überwachung===

Bei zeitkritischen Applikationen stellt sich immer wieder die Frage wie viele Prozessortakte nun die Funktion verbraucht. Ist der Interrupt auch wirklich nicht zu lange und wie viel Reserve gibt es noch?
 Der ARMv7M -Kern hat dafür extra einen Takt-Zähler in der DWT-Einheit implementiert, den man mittels der CMSIS nutzen kann:

<syntaxhighlight lang="c">
#include <stdint.h> // Für die Standard-Typen uint32_t etc.
#include <stm32f4xx.h> // Hier die Header-Datei der CMSIS für die jeweilige Familie verwenden.

// DWT-Einheit aktivieren
inline void DWT_Enable() {
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
}
// Takt-Zähler - Messen der Anzahl der Befehle des Prozessors:
inline void DWT_CycCounterEn () {
DWT->CTRL = 0x40000001;
}
inline void DWT_CycCounterDis () {
DWT->CTRL = 0x40000000;
}
inline uint32_t DWT_CycCounterRead () {
return DWT->CYCCNT;
}
inline void DWT_CycCounterClear () {
DWT->CYCCNT = 0;
}

int main () {
// ... Programmcode ...

// Systick-Zähler benutzen
DWT_Enable(); // DWT-Einheit aktivieren
DWT_CycCounterEn (); // Zähler aktivieren
DWT_CycCounterClear (); // Zähler löschen
// ... Programmbearbeitung ...
uint32_t iZ = DWT_CycCounterRead (); // Zähler auslesen

// ... weiterer Programmcode ...
}
</syntaxhighlight>

In iZ steht nun wie viele Maschinentakte der Prozessor für die Bearbeitung benötigt hat und kann mit folgender Formel umgerechnet werden:

Zeit in µSec = iZ / CPU-Takt in MHz

= FAQ - Anfängerfragen=

* Muss ich, wenn ich die Debugging-Funktionen nutzen möchte einen JTAG Adapter anschließen? - Ja. Auf dem STM32F4DISCOVERY ist jedoch bereits einer mit drauf.
* Mit diesem kann ich dann den µC auch programmieren? - Ja, programmieren und debuggen.
* Ich möchte eine eigene Platine entwickelt, jedoch der 20polige [[JTAG]]-Anschluss ist mir zu groß, gibt es eine Alternative? - Ja, [http://www.mikrocontroller.net/articles/JTAG#Der_10-polige_JTAG_Stecker_von_mmvisual "Der 10-polige JTAG Stecker von mmvisual"]

= Weblinks, Foren, Communities, Tutorials =
* [[STM32]] Hauptartikel, [http://www.mikrocontroller.net/articles/STM32#Weblinks.2C_Foren.2C_Communities.2C_Tutorials dortige Linksammlung]
* [http://www.mikrocontroller.net/topic/319328 Diskussion zum Artikel]
* [[STM32 CooCox Installation]]
* [[STM32 Eclipse Installation]]
* [https://www.mikrocontroller.net/topic/423300#new Totzeitrechner für STM32]
* [[LPC1xxx für Umsteiger]]
* [http://stefanfrings.de/stm32/index.html Notizen zu ARM Cortex M3 Mikrocontrollern der STM32F1 Serie]

<references/>
[[Kategorie:ARM]]
[[Kategorie:STM32]]
[[Kategorie:Mikrocontroller]]

FPGA

2017-06-27T11:26:06Z

2003:D2:3C8:5D00:224:8CFF:FE80:C59: /* Anbindung an Peripherie */

FPGA ist die Abkürzung für "'''F'''ield '''P'''rogrammable '''G'''ate '''A'''rray".

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 [[FlipFlop]]s (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 [[FlipFlop]]s 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 [[Speicher#SRAM | SRAM]]-Speicherzellen realisiert, welche beim Bootprozess passend geladen werden. Das Laden dieser Konfigurationsdaten bzw. Verknüpfungsregeln geschieht dabei in der Regel aus einem speziellen [[Speicher#Flash | 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 [[Speicher#EEPROM | EEPROM]]-, [[Speicher#Flash | 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
[[Ausgangsstufen Logik-ICs | 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, [[Wellenwiderstand | 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| 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 [[IC-Geh%C3%A4useformen#BGA|BGA]] und [[IC-Geh%C3%A4useformen#QFP|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 [[Speicher#BRAM | 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 '''PLL'''s (Phase Locked Loop) auf dem FPGA integriert. Einige Hersteller setzen eine Kombination aus statischen Taktmultiplizierer '''DLL'''s (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 [[Speicher#DDR-RAM | 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 ===

Programmierbare Prozessoren 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 auch deutlich einfacher und zielführender zu programmieren, da die Strukturen festgelegt und damit bekannt sind. Insbesondere bei sequentiellen Aufgaben (Benutzerinterface, komplexe Steueraufgaben etc.) wird man gerne auf eine klassische CPU zurückgreifen. 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 [[Speicher#BRAM | 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 (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 ) als ''HardCores'' physikalisch auf dem Chip integriert, entweder als Chipstruktur auf dem FPGA-kern selbst oder als gebondeter Chip im selben Gehäuse.

==== Softcores ====
Auf der anderen Seite gibt es auch [[FPGA Soft Core | SoftCores]] (z. B. ARM-Cortex-M1 bei IGLOO-FPGA von [http://www.actel.com 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 instanziiert werden. 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.

== 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 [http://www.altera.com Altera] und [http://www.xilinx.com Xilinx]. Weitere Hersteller sind [http://www.latticesemi.com/ Lattice], [http://www.actel.com Actel] und [http://www.atmel.com 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 ====
Der Aufbau komplizierter, applikationsnaher Strukturen wird meist durch automatische Routing- und Synthesewerkzeuge erledigt, welche mit einer logischen, funktionellen Beschreibung der Architektur in einer Hardwarebeschreibungssprache wie z.B. [[VHDL]] oder [[Verilog]] "gefüttert" werden. Die Hardwarebeschreibung gelingt ihrerseits z.B. mit Code-generierenden Werkzeugen, mittels derer zuvor Logikstrukturen, hardwarenahe Strukturen, Ablaufdiagramme und Zustandsautomaten formuliert wurden.

Die Korrektheit der Funktion einzelner Blöcke sowie der gesamten Schaltung wird mit Simulationswerkzeugen theoretisch geprüft und im Rahmen der Qualitätsmanagementprozesse formell nachgewiesen und geeignet dokumentiert. Vor Auslieferung des FPGA-Designs erfolgt meist ein praktischer Schaltungstest. Generell unterscheidet man folgende formelle Schritte während des Entwicklungsprozesses:

Validierung: Die gewünschte Funktion der Schaltung wird geprüft. Dies betrifft im Wesentlichen die komplizierten Funktionsblöcke wie state machines, CPU-Firmware und Rechenpipelines. Das Prüfen erfolgt meist theoretisch mit MATLAB, EXCEL oder einer Programmsoftware. Ziel ist der Nachweis des richtigen Konzeptes.

Verifikation: Die Art der Umsetzung wird geprüft. Dies betrifft alle Schaltungsteile. Praktisch die gesamte Schaltung wird blockweise dahingehend simuliert, ob alle Funktionen berücksichtigt wurden. Dazu werden Testfälle generiert und in die Schaltung eingespeist. Hierbei wird auch auf das Timing eines Chips Rücksicht genommen.

Test: Das fertige System 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. Bei diesem Schritt kommt auch die Elektronik mit ins Spiel, d.h. das Verhalten des Ladevorgangs, Probleme mit Spannungsstabilität, Pegeln, Leitungen etc. Das eine reales Exemplar des Chips zur Anwendung kommt, wird ein solche Test meist mit mehreren Baugruppen durchgeführt.

==== Wiederverwendbarkeit ====
Durch die Standardisierung der Architektur einerseits und die Entkopplung von applikationsorientierter Beschreibung sowie Chip- und Hersteller-spezifischer Synthese andererseits, wird die Hardware quasi als Software gebaut. Dies wiederum schafft alle Optionen der Wiederverwendung und Austausch von "Hardwareteilen". So stehen inzwischen komplett nutzbare Schaltungen wie 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. Zudem führen 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 kompatibel.

=== 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 ====
[[Bildsensor]]en 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 [[Glossar#p|PHY]], also einen physikalischen Zusatzchip. Dieser vollzieht die [[Glossar#p|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 [[Glossar#m|MAC]], bzw MAC-ähnliche Funktionen, sind im FPGA direkt implementierbar (z.B. mit IP-Cores) und können mit einfachen [[Glossar#f|FSM]]s 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 [[Glossar#g|GMII]]-Verbindung mit [[Glossar#d|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]]

== 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.

[http://de.sump.org/projects/analyzer/ 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 ==
* [[Hardwarebeschreibungssprachen]]
* [[Reset für FPGA/CPLD]]
* [[Taktung FPGA/CPLD]]
* Projekt [[Audio-DSP mit Spartan 3-FPGA]]
* Projekt [[FPGA Lab]]

== Forumlinks ==
* [http://www.mikrocontroller.net/topic/274159 Tonleiter im PLD] - Beispiel einer einfachen Musikapplikation
* [http://www.mikrocontroller.net/topic/326462?goto=3564346#3564346 Kopierschutz] für FPGAs und programmierbare ICs
* [http://www.mikrocontroller.net/topic/392278 Verfikationsumgebung] Verfikation beim FPGA-Design
* [http://www.mikrocontroller.net/topic/381136 FPGA-Standards] bezüglich Codierung
* [https://www.mikrocontroller.net/topic/382356#4357686 Inferred True Dual Port RAM für Xilinx und Altera]
* [https://www.mikrocontroller.net/topic/252255#2595360 Dual Port Block RAM - Gleichzeitiges lesen und schreiben]

== Weblinks ==
* [http://www.fpga4fun.com/index.html FPGA4Fun] - FPGA-Projekte, größtenteils mit Altera und Verilog
* [http://marcowuen.wordpress.com/2014/09/08/overview-cheap-fpga-development-boards/ Übersicht Development Boards] - Zusammenstellung günstiger FPGA Boards unter 100$
* [http://video.google.com/videoplay?docid=-4969729965240981475 Ein Vortrag, auf Englisch: General Purpose, Low Power Supercomputing Using Reconfiguration Logic]
* http://www.opencores.org - FPGA-Projekte, Opensource, jeder kann seine Eigenen einstellen und an anderen mitarbeiten. U.a. gibt es verschiedene CPUs für FPGAs.
* [http://pin4.at/pro_misc.php#fdil Projekt "FDIL v2"]: 5V DIL-Ersatz mit 100kGates Spartan II FPGA (Englisch)
* [http://members.optushome.com.au/jekent/FPGA.htm John's FPGA Page]
* [http://www.embedded.com/columns/whatsnew/197003073 More about designing with embedded FPGAs] by Bernard Cole, Embedded.com
* [http://chaosradio.ccc.de/cre117.html Chaosradio Express - FPGA]
* [http://www.pin4.at/pro_custom.php Custom IC replacements] - DIL / TTL-Replacements mit FPGA (Englisch)

[[Category:FPGA und Co|Grundlagen|Bauteile]]

FPGA

2017-06-27T11:23:18Z

2003:D2:3C8:5D00:224:8CFF:FE80:C59: /* DDR2 / DDR3 - RAM */

FPGA ist die Abkürzung für "'''F'''ield '''P'''rogrammable '''G'''ate '''A'''rray".

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 [[FlipFlop]]s (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 [[FlipFlop]]s 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 [[Speicher#SRAM | SRAM]]-Speicherzellen realisiert, welche beim Bootprozess passend geladen werden. Das Laden dieser Konfigurationsdaten bzw. Verknüpfungsregeln geschieht dabei in der Regel aus einem speziellen [[Speicher#Flash | 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 [[Speicher#EEPROM | EEPROM]]-, [[Speicher#Flash | 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
[[Ausgangsstufen Logik-ICs | 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, [[Wellenwiderstand | 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| 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 [[IC-Geh%C3%A4useformen#BGA|BGA]] und [[IC-Geh%C3%A4useformen#QFP|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 [[Speicher#BRAM | 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 '''PLL'''s (Phase Locked Loop) auf dem FPGA integriert. Einige Hersteller setzen eine Kombination aus statischen Taktmultiplizierer '''DLL'''s (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 [[Speicher#DDR-RAM | 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 ===

Programmierbare Prozessoren 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 auch deutlich einfacher und zielführender zu programmieren, da die Strukturen festgelegt und damit bekannt sind. Insbesondere bei sequentiellen Aufgaben (Benutzerinterface, komplexe Steueraufgaben etc.) wird man gerne auf eine klassische CPU zurückgreifen. 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 [[Speicher#BRAM | 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 (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 ) als ''HardCores'' physikalisch auf dem Chip integriert, entweder als Chipstruktur auf dem FPGA-kern selbst oder als gebondeter Chip im selben Gehäuse.

==== Softcores ====
Auf der anderen Seite gibt es auch [[FPGA Soft Core | SoftCores]] (z. B. ARM-Cortex-M1 bei IGLOO-FPGA von [http://www.actel.com 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 instanziiert werden. 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.

== 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 [http://www.altera.com Altera] und [http://www.xilinx.com Xilinx]. Weitere Hersteller sind [http://www.latticesemi.com/ Lattice], [http://www.actel.com Actel] und [http://www.atmel.com 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 ====
Der Aufbau komplizierter, applikationsnaher Strukturen wird meist durch automatische Routing- und Synthesewerkzeuge erledigt, welche mit einer logischen, funktionellen Beschreibung der Architektur in einer Hardwarebeschreibungssprache wie z.B. [[VHDL]] oder [[Verilog]] "gefüttert" werden. Die Hardwarebeschreibung gelingt ihrerseits z.B. mit Code-generierenden Werkzeugen, mittels derer zuvor Logikstrukturen, hardwarenahe Strukturen, Ablaufdiagramme und Zustandsautomaten formuliert wurden.

Die Korrektheit der Funktion einzelner Blöcke sowie der gesamten Schaltung wird mit Simulationswerkzeugen theoretisch geprüft und im Rahmen der Qualitätsmanagementprozesse formell nachgewiesen und geeignet dokumentiert. Vor Auslieferung des FPGA-Designs erfolgt meist ein praktischer Schaltungstest. Generell unterscheidet man folgende formelle Schritte während des Entwicklungsprozesses:

Validierung: Die gewünschte Funktion der Schaltung wird geprüft. Dies betrifft im Wesentlichen die komplizierten Funktionsblöcke wie state machines, CPU-Firmware und Rechenpipelines. Das Prüfen erfolgt meist theoretisch mit MATLAB, EXCEL oder einer Programmsoftware. Ziel ist der Nachweis des richtigen Konzeptes.

Verifikation: Die Art der Umsetzung wird geprüft. Dies betrifft alle Schaltungsteile. Praktisch die gesamte Schaltung wird blockweise dahingehend simuliert, ob alle Funktionen berücksichtigt wurden. Dazu werden Testfälle generiert und in die Schaltung eingespeist. Hierbei wird auch auf das Timing eines Chips Rücksicht genommen.

Test: Das fertige System 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. Bei diesem Schritt kommt auch die Elektronik mit ins Spiel, d.h. das Verhalten des Ladevorgangs, Probleme mit Spannungsstabilität, Pegeln, Leitungen etc. Das eine reales Exemplar des Chips zur Anwendung kommt, wird ein solche Test meist mit mehreren Baugruppen durchgeführt.

==== Wiederverwendbarkeit ====
Durch die Standardisierung der Architektur einerseits und die Entkopplung von applikationsorientierter Beschreibung sowie Chip- und Hersteller-spezifischer Synthese andererseits, wird die Hardware quasi als Software gebaut. Dies wiederum schafft alle Optionen der Wiederverwendung und Austausch von "Hardwareteilen". So stehen inzwischen komplett nutzbare Schaltungen wie 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. Zudem führen 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 kompatibel.

=== 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 ====
[[Bildsensor]]en 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 [[Glossar#p|PHY]], also einen physikalischen Zusatzchip. Dieser vollzieht die [[Glossar#p|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 [[Glossar#m|MAC]], bzw MAC-ähnliche Funktionen, sind im FPGA direkt implementierbar (z.B. mit IP-Cores) und können mit einfachen [[Glossar#f|FSM]]s 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 [[Glossar#g|GMII]]-Verbindung mit [[Glossar#d|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]]

== 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.

[http://de.sump.org/projects/analyzer/ 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 ==
* [[Hardwarebeschreibungssprachen]]
* [[Reset für FPGA/CPLD]]
* [[Taktung FPGA/CPLD]]
* Projekt [[Audio-DSP mit Spartan 3-FPGA]]
* Projekt [[FPGA Lab]]

== Forumlinks ==
* [http://www.mikrocontroller.net/topic/274159 Tonleiter im PLD] - Beispiel einer einfachen Musikapplikation
* [http://www.mikrocontroller.net/topic/326462?goto=3564346#3564346 Kopierschutz] für FPGAs und programmierbare ICs
* [http://www.mikrocontroller.net/topic/392278 Verfikationsumgebung] Verfikation beim FPGA-Design
* [http://www.mikrocontroller.net/topic/381136 FPGA-Standards] bezüglich Codierung
* [https://www.mikrocontroller.net/topic/382356#4357686 Inferred True Dual Port RAM für Xilinx und Altera]
* [https://www.mikrocontroller.net/topic/252255#2595360 Dual Port Block RAM - Gleichzeitiges lesen und schreiben]

== Weblinks ==
* [http://www.fpga4fun.com/index.html FPGA4Fun] - FPGA-Projekte, größtenteils mit Altera und Verilog
* [http://marcowuen.wordpress.com/2014/09/08/overview-cheap-fpga-development-boards/ Übersicht Development Boards] - Zusammenstellung günstiger FPGA Boards unter 100$
* [http://video.google.com/videoplay?docid=-4969729965240981475 Ein Vortrag, auf Englisch: General Purpose, Low Power Supercomputing Using Reconfiguration Logic]
* http://www.opencores.org - FPGA-Projekte, Opensource, jeder kann seine Eigenen einstellen und an anderen mitarbeiten. U.a. gibt es verschiedene CPUs für FPGAs.
* [http://pin4.at/pro_misc.php#fdil Projekt "FDIL v2"]: 5V DIL-Ersatz mit 100kGates Spartan II FPGA (Englisch)
* [http://members.optushome.com.au/jekent/FPGA.htm John's FPGA Page]
* [http://www.embedded.com/columns/whatsnew/197003073 More about designing with embedded FPGAs] by Bernard Cole, Embedded.com
* [http://chaosradio.ccc.de/cre117.html Chaosradio Express - FPGA]
* [http://www.pin4.at/pro_custom.php Custom IC replacements] - DIL / TTL-Replacements mit FPGA (Englisch)

[[Category:FPGA und Co|Grundlagen|Bauteile]]