Mikrocontroller.net - Benutzerbeiträge [de]

Audio-DSP mit Spartan 3-FPGA

2017-02-13T08:01:08Z

213.61.254.68: /* Übersicht */

von [[Benutzer:TheMason]]

==Ziel==

Ziel dieses Projekts ist es der Aufbau einer FPGA-basierten Plattform, mit der es möglich ist Synthesizer, Effektgeräte, Mischpulte oder gar ein Harddiskrecording-System zu realisieren.

==Feature-Liste==

Eigenschaften des Audioprozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audioprozessors via SPI oder RS232
* 4 Mono Ein- und Ausgänge
* GPO (General-Purpose-Outputs) zur Konfiguration der Codecs

==Übersicht==
[[Bild:Overview_wo_uc.jpg|thumb|500px]]
Basis des Audiosystems ist das Spartan-3-Development-Board von Xilinx. An diesem Board werden zwei Audio-Codecs angeschlossen, von denen einer als Master und der andere als Slave agiert. Optional kann noch ein Mikrocontroller angeschlossen werden, welcher den FPGA per SPI steuert. Da dieses Projekt mittlerweile recht umfangreich geworden ist, kann ich hier nur einen kurzen Umriss des Systems geben. Dabei beschränke ich mich auf die grobe Funktionsweise des Audioprozessors, erläutere die Schnittstelle (welche ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man zwei Audio-Codecs, von denen einer als Master, der andere als Slave arbeitet, angeschlossen und konfiguriert hat) direkt genutzt werden, da der DAP per RS232 gesteuert werden kann. Der Audioprozessor startet mit einem Stereo-Tiefpassfilter, das sich auf den ersten Codec bezieht,
sodass man eine erste Demo hat (selbst wenn diese etwas unspektakulär ist)

 

==Nachbau==

Wer sich dieses System nachbauen möchte, benötigt zunächst ein FPGA-Board. Mit dem Spartan-3-Board von Digilent gestaltet sich der Nachbau einfach, weil die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xilinx) müssten zuerst die UCF-Datei für die Pins ihres jeweiligen Boards anpassen, und dieses Projekt neu synthetisieren (compilieren). Nutzer von Altera-Boards hingegen müssen die BlockRAM-Instanzen auf die Altera-Architektur anpassen (den Inhalt der RAMs dabei nicht vergessen :-). Vielleicht findet sich ja der eine oder andere der den VHDL Code für Altera-FPGAs portiert.
Der eigentliche wichtige Teil eines Nachbaus ist der Codec-Teil. Dieses System verwendet zwar zwei Codecs, aber es kann auch mit einem gearbeitet werden. Als Codec kommt der TLV320AIC23B von Texas Instruments zum Einsatz. Diesen kann man als kostenloses Muster bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUSS als Master laufen, sonst hat das System keine Audio-Clocks, da diese nicht vom FPGA generiert werden)
Die Initialisierung des Codecs wird vom PC aus gemacht. Dazu dienen die 4 GPO-Leitungen auf dem B1-Verbinder. Da der Codec nur "halbes" SPI unterstüzt (man kann nur schreiben, nicht lesen) gestaltet sich die Initialisierung recht einfach.
Die 4 GPO-Leitungen teilen sich folgendermaßen auf :

* Chip-Select Codec 2
* Chip-Select Codec 1
* SPI Data Out
* SPI Clock

==Audio-Prozessor (DAP)==

[[bild:Overview dap core.JPG|thumb|500px|right]]

Der FPGA beinhaltet in dem gesamten System einen Quasi-DSP. Quasi-DSP deshalb, da die Struktur im Gegensatz zu einem DSP bzw. Mikrocontroller keine Verzweigungen, Interrupts oder ähnliches zulässt. Der Audio-Prozessor besteht im wesentlichen aus 3 Teilen : einem Rahmen, einem SDSP (Small DSP)-Kern
sowie einem Utility-Kern. Beide Kerne können theoretisch parallel arbeiten, da jeder Kern einen eigenen Zustandsautomaten und einen eigenen Microcode-Speicher besitzen. Diese Möglichkeit ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audiodaten, einem Koeffizienten-Speicher, einem Adressgenerator und mehreren Muxern, sowie dem schon angesprochenen Zustandsautomaten und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackserfreies" Aktualisieren von Koeffizienten ermöglicht. Alle diese Komponenten werden vom Microcode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audiosignale zu bearbeiten. Zu Den Bearbeitungsmöglichkeiten zählen in erster Linie das Verändern der Lautstärke, Mischen, Filtern (Biquad) sowie Laden und Speichern von
Audiowerten.

Der Utility-Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adressgenerator, einem Wavetable-Speicher, einem Zufallszahlengenerator, einigen Muxern, (einem Adressgenerator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar, wenn man das ganze mit dem ISE 6.2 synthetisiert)
und dem schon angesprochenen Zustandsautomaten und dem Microcode. Der Microcode steuert (genau wie beim SDSP-Kern) dabei die einzelnen Komponenten des Utility-Kerns. Dieser Kern ist für das Erzeugen von Audiosignalen zuständig, und erlaubt ein Audiosignal zu verzögern, sofern man die ISE-Version 6.2 verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarer Pulsbreite), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur Verfügung.

Der Rahmen besteht aus einem Zustandsautomaten, einem Programmspeicher, einigen Muxern, sowie einem doppelten I2S-Sender/Empfänger (für 2 Stereo Ein- und Ausgänge). In den Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und vom Zustandsautomaten angesteuert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt, dass ein Befehl im Programmspeicher 32 Bit an Informationen enthält und der Audioprozessor max. 512 Befehle umfassen kann.

===SDSP-Core===

[[Bild:SDSP-Struct.jpg|thumb|300px|left|Struktur des SDSP-Kerns]]

Der eigentliche Kern des DAPs ist die MAC-Einheit. Mit ihr werden die grundlegenden Operationen Multiplikation und Addition durchgeführt. Es ist eine 32x32-Bit-Einheit.
Die Funktionsweise des Kerns ist eigentlich recht einfach.
Die MAC-Einheit hat 2 Eingänge. Einer dieser Eingänge kann ein Audiosignal, ein Wert aus dem Audiospeicher (AMEM-BlockRAM) oder ein zuvor berechnetes Ergebnis sein. Der andere Eingang kann ein Koeffizient aus dem CMEM-BlockRAM oder eine Konstante (1.000, 0.000 oder -1.000) sein.
Der Ausgang (32-Bit, hart geclippt) geht auf das AMEM-BlockRAM und zum Ausgangs-Clipping. Das Ausgangsclipping schneidet das Audiosignal auf 24-Bit zurecht.
Die Adressen für die Speicher (AMEM und CMEM) werden im Addressgenerator erzeugt. Dieser wird von außen mit einer 8-Bit-Basis-Adresse gespeist und erzeugt einen Offset zu den Eingangsadressen. Er besitzt 2 setzbare Zähler und einige Multiplexer.
Alle Steuersignale der Komponenten von einem weiteren aus BlockRAM (MMEM) versorgt. Weiterhin wird von außen eine Startadresse vorgegeben. Dadurch lassen sich quasi Opcodes mit von außen vorgegeben Parametern (Adressen) aufrufen.
Das MMEM-BlockRAM wird nun einfach nur linear ausgelesen bis ein Stopbit gesetzt ist.

 

===Util-Core===

[[Bild:Util-Core.jpg|thumb|300px|left|Struktur des Utility-Kerns]]

Beschreibung folgt

 

===Opcodes des DAP===

Diese 32 Bit eines Befehls teilen sich folgendermaßen auf :

* 4 Bit = Opcode (für SDSP und Utility Kern gleich)
* 2 Bit = noch leer
* 1 Bit = Core Select (SDSP oder Utility)
* 1 Bit = Ende des Programms
* 4 Bit = Eingangsrouting (Kanal 1 - 4, Ergebnis SDSP-Kern, Ergebnis Utility-Kern)
* 4 Bit = Ausgangsrouting (SDSP-Ausgang auf Kanal 1-4, Utility-Ausgang auf Kanal 1-4)
* 8 Bit = Adresse 1 (bei SDSP für Audio-Memory, bei Utility-Kern für Datenspeicher)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizientenspeicher, bei Utility-Kern unbenutzt)

Das Eingangsrouting bestimmt, mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 aber auch ein vorher berechnetes Ergebnis des SDSP- bzw. Utility-Kerns sein. Das Ausgangsrouting bestimmt, von welchem Kern das Signal auf welchen Ausgang geroutet wird.

Die Opcodes des DAPs sind:

SDSP-Kern:
* Biquad rechnen
* Audiowert speichern
* Audiowert laden
* Move eines Wertes im Audiospeicher
* Summe rücksetzen
* Eingang zu Summe addieren
* Wert aus dem Audiospeicher zu Summe addieren
* Eingang zu Summe mischen (mit Lautstärkekoeffizient)
* Wert aus dem Audiospeicher zu Summe mischen (mit Lautstärkekoeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshaper
* Verzögerung

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestoßen. Es wird dabei jeweils ein Befehl geladen und Daten wie Opcode und Adressen liegen dabei an beide Kernen gleichermaßen an. Ist das Programm-Ende-Bit nicht gesetzt, so wird der jeweilige Kern (mit dem im Opcode angegeben Routing) angesteuert. Legt der betreffende Kern sein Ready-Signal auf 1, so wird der nächste Befehl abgearbeitet. Dieses Verhalten (Laden und Verteilen von Opcode-Daten sowie die Ablaufsteuerung, also das Ansteuern des Programms, Ansteuern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programmende) wird vom Rahmen übernommen.

===Speicherorganisation===

Alle Speicher die vom DAP angesprochen werden, haben eine Wortbreite von 32 Bit, der Zugriff erfolgt aber ausschließlich über eine Breite von 8 Bit (Interface).

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

SDSP
* Audiospeicher (AMEM) von außen nicht zugänglich
* Koeffizientenspeicher (CMEM) 0x2000 - 0x2023 (man "sieht" nur den Hidden Write -> später mehr dazu)
* Microcodespeicher (MMEM) 0x4000 - 0x47ff

Utility-Core
* Datenspeicher (DMEM) 0x6000 - 0x67ff
* Wavetable-Speicher (WMEM) 0x8000 - 0x87ff
* Microcodespeicher (UMEM) 0xa000 - 0xa7ff

===Hidden-Write===
Um bei Änderung der Koeffizienten Knackser zu vermeiden (die dadurch entstehen, dass der Koeffizient nur teilweise [durch 8-Bit-Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft" und mit "falschen" Zwischenwerten gerechnet wird), ist ein Mechanismus implementiert, der die zu ändernden Koeffizienten im Hintergund in den Speicher schreibt. Um diesen Mechanismus zu nutzen, müssen zuerst die Koeffizienten in interne Register
geschrieben werden. Die Register (es sind 8 32-Bit-Register) liegen im Speicherbereich 0x2000 bis 0x201f. Die Speicherstelle 0x2020 gibt die Startadresse innerhalb des Koeffizientenspeichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an, wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 löst den Kopiervorgang aus. Hier reicht es, ein Dummy-Byte zu schreiben. Um den Kopiervorgang zu beenden (MUSS GEMACHT WERDEN, sonst können keine weiteren Koeffizientenupdates gemacht werden), schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy-Byte.

===I/O Register===

Es gibt noch einen 8-Bit breiten Adressbereich innerhalb des DAPs, mit dem der I2S-Teil stummgeschaltet werden kann. Weiterhin hat man die Möglichkeit, die Anzahl der Systemtakte pro Sample und die Anzahl der aktiven Systemtakte (also die Zeit die der Audioprozessor beschäftigt ist) zu ermitteln. Dadurch lässt sich eine Auslastungsanzeige des DAPs realisieren.

===Interface===

Um von außen nun ein Programm (bzw. Koeffizienten und Daten) zu laden, ist eine einfach zu handhabende und erweiterbare Schnittstelle implementiert. Die Schnittstelle kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird hardwaremäßig eingestellt) angesteuert werden. Die Schnittstelle in ihrer Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Daten-Dispatcher. Dieser Daten-Dispatcher entscheidet (nachdem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Entwurf ein Gerät namens "StdIO" und der Audioprozessor verfügbar.

Das "StdIO"-Gerät steuert die 7-Segment-Anzeige (16-Bit-Hexadezimalanzeige oder 32-Bit-Einzelsegmentanzeige) sowie die 8 Leuchtdioden, und erlaubt es, die 3 Drucktaster sowie die 8 Schiebeschalter auszulesen.

Der Audioprozessor besteht (schnittstellenseitig) nur aus einer Speicherzugriffsschnittstelle. Diese Schnittstelle entscheidet mit dem ersten Byte (sobald es selektiert wurde), ob in den Speicher geschrieben, von diesem gelesen, ein I/O-Schreib- oder -Lesezugriff erfolgen soll.
Die folgenden 2 Bytes (im Falle eines I/O-Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicherbereich des Audioprozessors, auf den zugegriffen werden soll. Die Speicherschnittstelle besitzt einen Autoinkrementierer,
mit dem fortlaufende Bytes einfach hintereinander geschrieben werden können, ohne dass jedes mal wieder der FPGA, das Gerät und die neue Adresse neu geschrieben werden müssen, was den Zugriff erheblich beschleunigt.

Ursprünglich basierte das System auf einem SPI-Interface. Dabei wurde die Chip-Select-Leitung als "globaler" Interface-Reset betrachtet, d.h. war die Leitung auf High, war der FPGA deselektiert und und alle Interface-Zustandsautomaten wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das ausgewählte Gerät). Weiterhin hat SPI die Eigenschaft, dass mit jedem gesendeten Byte auch eines empfangen wurde. Der Umstand, dass RS232 weder eine Chip-Select Leitung benötigt noch eine synchrone Übertragung erzwingt, führt zu dem Umstand, dass man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezialfunktion" das Byte 0x1b übertragen werden, so wird dieses einfach erneut gesendet. Soll die Chip-Select-Leitung gesetzt bzw. gelöscht werden, so wird die Sequenz 0x1b 0x00 (Selektieren) bzw.
0x1b 0x01 (Deselektieren) gesendet. Soll ein zuvor im Ausgangsregister gesetztes Byte gesendet werden, so muss die Sequenz 0x1b 0x02 gesendet werden.

Beispiele:

0x121b auf dem 7-Segment-Display per RS232 anzeigen:

*- ESC 0x00 (FPGA selektieren)
*- 0xf0 (StdIO selektieren)
*- 0x00 (Hi-Byte der 7-Segment-Hex-Anzeige wählen)
*- 0x12 (Wert 12)
*- ESC 0x01 (FPGA deselektieren)

*- ESC 0x00 (FPGA selektieren)
*- 0xf0 (StdIO selektieren)
*- 0x01 (Lo-Byte der 7-Segment-Hex-Anzeige wählen)
*- 0x1b 0x1b (Wert 1b -> zu beachten: wenn der Wert 0x1b übertragen werden soll, muss dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA deselektieren)

Beispiel, um in den Programmspeicher des Audioprozessors an Adresse 0x0010 das Langwort 0x12233445 zu schreiben:

*- ESC 0x00 (FPGA selektieren)
*- 0xf1 (DAP selektieren)
*- 0x00 (Speicher schreiben)
*- 0x00
*- 0x10 (Adresse 0x0010 -> PMEM-Adresse 0x010)
*- 0x12 (Adresse 0x0010 -> 0x12)
*- 0x23 (Adresse 0x0011 -> 0x23, autoincrement)
*- 0x34 (Adresse 0x0012 -> 0x34, autoincrement)
*- 0x45 (Adresse 0x0013 -> 0x45, autoincrement)
*- ESC 0x01 (FPGA deselektieren)

Auslesen der 8 Schalter:

*- ESC 0x00 (FPGA selektieren)
*- 0xf0 (StdIO selektieren)
*- 0x04 (Schalter auslesen)
*- 0x00 (dummy byte -> überträgt Schalterstellung in Ausgaberegister)
*- ESC 0x02 (Ausgaberegister übertragen, danach empfängt man die 8 Schalterstellungen binärcodiert)
*- ESC 0x01 (FPGA deselektieren)

Der Datendispatcher (welcher mit dem ersten Byte nach dem Selektieren des FPGAs [0x1b 0x00] angesprochen wird) hat weiterhin einige nützliche Funktionen, die in ihrer Gesamtheit allerdings noch nicht ausführlich getestet wurden. Darunter sind Funktionen, mit denen Informationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Diese Funktion kann dazu genutzt werden, um zu ermitten, welche Geräte im FPGA implementiert sind und an welchen Ports welche Geräte angeschlossen sind.

Anzahl der Ports des Daten-Dispatchers liefern:

*- ESC 0x00 (FPGA selektieren)
*- 0xed (Anzahl Ports lesen)
*- 0x00 (dummy byte -> überträgt Inhalt des Ausgaberegisters)
*- ESC 0x02 (Ausgaberegister übertragen, danach empfängt man 0x22)
*- ESC 0x01 (FPGA deselektieren)

===DAP-Modul-Schnipsel===

Um mal "eben" mit dem DAP zu spielen, ein paar Schnipsel die sich recht leicht zu kompletten Funktionsblöcken zusammenschließen lassen.
Es werden hier nur die RS232-Sequenzen mit einer kurzen Erklärung aufgelistet.

*Dual Mono Biquad

*ESC 0x00 - FPGA selektieren
*0xF1 - DAP auswählen
*0x00 0x00 0x00 - Memory Write (Adresse 0x0000 -> Program Memory)
*0x10 0x00 0x00 0x08 - Biquad mit Kanal 1 (0) rechnen (AMEM = 0x00;CMEM = 0x08) und auf Kanal 1 (0) ausgeben
*0x10 0xf0 0x08 0x10 - Biquad mit vorherigem Ergebnis (0xf) rechnen (AMEM = 0x08; CMEM = 0x10) und auf Kanal 1 (0) ausgeben
*0x01 0x00 0x00 0x00 - Audioprogramm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, dass ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet, dass Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister, welches nach Fertigstellung des Ergebnisses benutzt werden soll, ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, dass die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden in den Audiospeicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur dass hier statt Kanal 1 des Codecs das voher vom SDSP berechnete Ergebnis verwendet werden soll (Kanal 0xf, wenn man so will). Ausgangsregister ist auch hier wieder Kanal 1. Da dieser Biquad unabhängig vom ersten (d.h. mit anderen Parametern) gerechnet werden soll, sind hier logischerweise auch andere Adressen für AMEM (0x08) und CMEM (0x10) angegeben. Die CMEM-Adresse ist dabei etwas unkritischer, da es ja durchaus sein kann, dass ein Audiosignal zweimal mit den selben Biquad-Werten gerechnet werden soll, bzw. unterschiedliche Kanäle mit den selben Biquad-Werten, z.b. bei einem Stereo-Equalizer. Kritischer ist allerdings die Verwendung der AMEM-Adresse. Diese sollte für jede Operation (sofern AMEM denn verwendet wird) unterschiedlich sein, vor allem bei der Berechnung von Biquads. Dies hat den Grund, dass bei Operationen, die dieselben AMEM Adressen haben, die vorher berechneten Werte überschrieben werden. Dies ist bei Biquads gaanz böse (kann u.U. SEHR laut werden), und vom Ergebnis her nicht vorhersagbar.

==Hardware==

[[bild:Fpga_ext_board_schematic_no_uc.JPG|thumb|500px]]

Wie eingangs erwähnt, benötigt das System eine (bzw. zwei) Audio-Codecs. Im aktuellen Schaltplan wird auf einen Mikroprozessor verzichtet. Dieser diente im System primär zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE-6.2-Version 4 Leitungen herausgeführt wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte, kann entweder die TLV320AIC23B-Codecs oder auch beliebige andere Codecs verwenden, solange einer als Master und der andere als Slave arbeitet und beide auf den I2S-Modus mit 64FS und 20-Bit-Wortlänge eingestellt sind. Die Initialisierung dieser Codecs muss dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drumrum kommt). Um das System zu testen (Programme und Koeffizienten in den DAP einzuspielen), wird lediglich eine serielle Schnittstelle verwendet. Wer will, kann aber genausogut den SPI-Modus verwenden und den DAP direkt von einem Mikrocontroller aus steuern. Zur Auswahl der verwendeten Schnittstelle (RS232 oder SPI) wird Pin 13 des B1-Connectors benutzt. Liegt dieser Pin auf GND, so wird der FPGA per RS232 gesteuert. Liegt dieser Pin auf 3.3V, so wird der FPGA per SPI gesteuert.

Hier der Schaltplan meines verwendeten Audio-Boards.
 

Hier noch die Pinbelegung des B1-Erweiterungssteckers:

*01 GND
*02 VCC 5V
*03 VCC 3.3V
*04 N.C.
*05 SPI_CS - Chip Select (von uC nach FPGA)
*06 N.C.
*07 SPI_DI - SPI Data In (von uC nach FPGA)
*08 BCLK - Bit Clock (von Master Codec)
*09 SPI_CLK - SPI Clock (von uC nach FPGA)
*10 LRCLK - LR-Clock (von Master Codec)
*11 SPI_DO - SPI Data Out (von FPGA nach uC)
*12 SDOUT1 - zum D/A Wandler (Codec) 1
*13 IF_SEL - Interface Select (GND = RS232; VCC3.3 = SPI)
*14 SDIN1 - vom A/D Wandler (Codec) 1
*15 RXD_OUT - RS232 Signal vom MAX232 zum uC
*16 SDIN2 - vom A/D Wandler (Codec) 2
*17 TXD_IN - RS232 Signal vom uC zum MAX232
*18 SDOUT2 - zum D/A Wandler (Codec) 2
*19 GPO 3 - Chip-Select Codec 2
*20 N.C.
*19 GPO 2 - Chip-Select Codec 1
*20 N.C.
*19 GPO 1 - SPI-Data out
*20 N.C.
*19 GPO 0 - SPI-Clock Out
*20 N.C.

==Nexys Board==

Im SVN-Repository (s.u.) gibt es eine Version des DAPs für das Nexys-Board.
Diese ist voll SW-kompatibel zum alten Spartan-3-Board (allerdings z.Zt. nur über RS232 steuerbar). Neu bei der Version ist, dass das Speicherinterface generisch ausgelegt wurde und ein einfacher SRAM-Controller für das PSDRAM des Nexys-Boards geschrieben wurde. Durch das generische Interface ist es möglich, andere Speicherarten anzubinden. Der verwendete Codec ist wie schon im bisherigen Projekt der TLV320AIC23B. Dieser wird via RS232 (6-pin Port A des Nexys-Boards) über die GPO Leitungen (6-pin Port D des Nexys-Boards) initialisiert. Die eigentlichen Datenleitungen des Codecs liegen an Port B (BCLK, LRCLK, DIN, DOUT).

* Download des DAP als MCS-File für das Nexys-1000 Board : [[Media:Nexys_dap.zip]]

Diese Version ist voll lauffähig (wurde mit den Demos getestet).
Die Pinbelegung für die RS232 und den Audio-Codec ist wie folgt:

Header A : RS232-Schnittstelle 

Pin 1 : RxD von MAX232 
Pin 2 : TxD von MAX232 
Pin 3 : - 
Pin 4 : - 
Pin 5 : GND 
Pin 6 : VCC (3.3V/5V für MAX232/MAX3232) 

Header B : I2S-Schnittstelle für einen Codec 

Pin 1 : BitClk 
Pin 2 : L/R Clk 
Pin 3 : SDIN 
Pin 4 : SDOUT 
Pin 5 : GND 
Pin 6 : VCC (3.3V für den Codec) 

Header D : Codec-Konfiguration via SPI 

Pin 1 : Codec 2 CS 
Pin 2 : Codec 1 CS 
Pin 3 : Codec SPI Data 
Pin 4 : Codec SPI Clk 
Pin 5 : GND 
Pin 6 : VCC 

==DAP mit selbstgelötetem FPGA-Board==

Auf einen Beitrag von Thomas Pototschnig hin bin ich auf sein selbstentworfenes Spartan-3-FPGA-Board (Grafikkarte) aufmerksam geworden. Thomas hat mir die Erlaubnis gegeben, dieses Board für den DAP zu verwenden und die Schaltpläne hier zu veröffentlichen. Nachdem ich von ihm noch einige Vorversionen (nur die Platinen) ergattern konnte und diese erfolgreich aufgebaut (mit Spartan 3-200 und -400) habe, bin ich von diesem Board echt begeistert. Danke nochmals.

[[Bild:FPGA-Board.jpg|thumb|300px|left]]

Hier Schaltplan und Layout.

[[Media:miniFPGA-Board.zip]]

Das Board ist zweiseitig und die "schlimmsten" zu lötenden Bauteile sind lediglich der FPGA (QFP-144) und die beiden RAMs (SOJ36, ekelig). Der Rest ist recht einfach. Auch die Inbetriebnahme des Boards gestaltete sich problemlos.

Den Quellcode für den DAP musste ich etwas ändern und abspecken. Durch den ineffizienten VHDL-Code der MAC-Einheit gestaltete es sich schwierig, den Entwurf synthetisierbar zu machen. Das Synthetisieren auf einem FT256 gestaltete sich einfacher. Hier ist noch dergestalt Handlungsbedarf, dass die MAC-Einheit überarbeitet werden muss.
Der abgespeckte Entwurf läuft auf dem FPGA-Board mit einem Spartan 3-400 sowie auf einem Spartan 3-200.
Den Audio-Codec, das FPGA Board, einen AVR und noch etwas IO-Kram habe ich auf eine Lochrasterplatine aufgebaut. Was noch fehlt, sind MIDI- und SD/MMC-Karten-Schnittstellen. Dann hat man eine schöne Plattform für Synthesizer und Effektgeräte.

 

==Anmerkung==

Da, wie schon gesagt, das Projekt komplett auf meinem "Mist" gewachsen ist, wird es wohl noch eine Weile dauern, bis alles, was den DAP betrifft, hier in diesem Artikel (und auch in einem Dokumentations-PDF) eingearbeitet ist. Ich werde (sofern ich Zeit dazu habe) noch ein Delphi-Programm mit Sourcecode einstellen, welches den DAP richtig nutzbar macht, so dass man dann direkt damit "spielen" kann. Eine umfangreiche und vollständige Dokumentation würde momentan einfach zu viel Zeit in Anspruch nehmen, und ich möchte langsam das Projekt vorstellen, um Anregung, Kritik und Verbesserungsvorschläge ernten zu können. Ich hoffe, weitere Leute zu finden, um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Ursprüngliche Version:

[[Bild:Gesamt_wo_uc.jpg|thumb|200px|left|Spartan.3-Board und Expansion-Board]]
[[Bild:Codecs.jpg|thumb|200px|left|Expansion Board]]
 

Nexys-Board:
[[Bild:dap_nexys_v1.jpg|thumb|200px|left|Nexys-Board mit 1 Audio-Codec]]
[[Bild:Nexys-board-gesamt.jpg|thumb|200px|left|Nexys-Board mit Lochraster-Board und 2 Audio-Codec-Boards (siehe Artikel [[Audio Codec Board]])]]
[[Bild:Nexys-board-codecs-1.jpg|thumb|200px|left|2 Audio-Codec-Boards (siehe Artikel [[Audio Codec Board]])]]
 

Aufbau von [[Benutzer:Andreas]]:
[[Bild:Nexys-Audio-DSP-Foto-Andreas.jpg|thumb|600px|left|Nexys + Breadboard + 1 [[Audio Codec Board]]]]
 

[[Bild:Synth-gesamt-klein.jpg|thumb|500px|left|Aufbau des DAPs mit FPGA-Board (entworfen von Thomas Pototschnig) auf Lochraster an AVR, Codec und weiterer IO]]

 

[[Bild:Dap-Synth-01.jpg|thumb|300px|left|Synth Board. DAP mit AVR,Codec, MIDI-Interface, RS232 (schaltbar) und LCD]]

 

[[Bild:Dap_Synth_Ansicht_02.jpg|thumb|300px|left|Synth Board. Komplettansicht]]

 

[[Bild:Dap_Synth_klein_3.jpg|thumb|600px|left|Synth Board. Synth-Board]]

 

[[Bild:DAP mit Touch-Display-Mainboard-Oben.jpg|thumb|300px|left|Selbstgeroutetes DAP-Board]]

 

[[Bild:DAP mit Touch-Display-Mainboard-Unten.jpg|thumb|300px|right|Selbstgeroutetes DAP-Board]]

 

[[Bild:DAP mit Touch-Display-Träger-und-Mainboard.jpg|thumb|600px|left|Selbstgeroutetes DAP-Board auf Trägerplatine]]

 

[[Bild:DAP mit Touch-Display-Seite.jpg|thumb|300px|left|DAP-Board mit Touch-Display Seitenansicht]]

 

[[Bild:DAP mit Touch-Display.jpg|thumb|600px|left|DAP-Board mit Touch-Display]]

Diese Version des DAP hat ein Grafikdisplay incl. Touchpanel. Die Ansteuerung übernimmt der FPGA. Dort ist einer kleiner "Grafik-Prozessor" integriert, der das Update des Displays und das Kopieren der Bitmaps übernimmt.

 

[[Bild:DAP Synthesizer Ansicht 1.jpg|thumb|600px|left|]]
Synth-Board. Komplettansicht in einem Cherry-Tastaturgehäuse (wie dafür gemacht :-)) im Synthesizer-Stil

 

[[Bild:DAP Synth Komplett.jpg|thumb|600px|left|Fertige Version des DAP als Synthesizer]]

Der komplette Synthesizer mit schicker Frontplatte und passendem (oben schon erwähnten :-)) Cherry-Tastatur-Gehäuse.

 

[[Bild:DAP Version 1.5.jpg|thumb|600px|left|Heue Hardwareversion der DAP-Hauptplatine]]

Diese Version beinhaltet folgendes : :-)

- Xilinx XC3S400
- ATmega2561

- 16 MByte (8Mx16) SDRAM
- µSD Card Slot
- AT45DB321 DataFlash
- 24C512 EEProm

- TLC320AI23B Audio Codec mit Kopfhörer Ausgang
- CS5343 A/D Wandler
- CS4344 D/A Wandler

- MIDI
- RS232
- etlichen IO-Pins vom AVR und FPGA
- 2 separaten Clock-Oszillatoren (nicht bestückt)

... und weiterem Kleinkram (Level-Shifter, LDO, Platform-Flash, usw ... und vielen 100nF-Kondensatoren)

Ideal zum Aufbau einer Audioplattform.

 

==Audio-Demos==

Ein EQ-Demo mit rosa Rauschen. Klingt wie eine Meeresbrandung.

[[Media:eq_demo1.zip]]

Der DAP als Synth. Der DAP wird komplett vom PC aus gesteuert (Hüllkurve, Sequencer und Filterberechnung werden im PC gemacht).

[[Media:synthdemo1.wav.zip]]

=== MC505-Demos ===

Die folgenden Demos stammen von meiner Roland MC505 Groovebox. Es wird einfach nur ein Werkspreset abgespielt und durch den DAP gejagt.

* [[Media:mc505-eq-demo.wav.zip|EQ-Demo]]
* [[Media:mc505-filter-demo.wav.zip|Filter-Demo (Tiefpass/Hochpass/Notch)]]
* [[Media:mc505-delay-demo.wav.zip|Delay-Demo (137BPM [657ms & 876 ms]/Chorus)]]

=== Synth-Board Audio-Demos ===

Die folgenden Demos stammen vom DAP in Verbindung mit einem AVR, der die Filterkoeffizientenberechnung sowie eine komplette Synthesizersteuerung beinhaltet, also quasi einen Synthesizer aus dem DAP macht (inkl. MIDI-Steuerung).

MIDI-Sequenz und Tiefpassfilter (Filter und Modulation über MIDI gesteuert) :

[[Media:Dap-syn-demo-01.mp3]]

Dieselbe MIDI-Sequenz mit Hochpassfilter (Filter und Modulation ebenfalls über MIDI gesteuert) :

[[Media:Dap-syn-demo-02.mp3]]

Eine eher Techno-ähnliche Demo, welche die Auflösung des Systems (DAP+AVR+MIDI) ein wenig zeigt.

[[Media:Dap_syn_demo_03.mp3]]

==Delphi Tools==

Um den DAP nutzbar zu machen benötigt man entweder ein uC Programm oder ein PC Programm. Da das verwenden von PC-Programmen einfacher fürs Spielen und Experimentieren ist, werde ich hier im Laufe der Zeit kleine Demo-Programme aber auch komplette Front-Ends für den DAP reinstellen. Die Delphi-Programme sind allesamt in Turbo-Delphi geschrieben und die dazugehörigen Quellcodes werden ebenfalls im Laufe der Zeit geuploaded. Ich werde allerdings zuerst noch das Feature des Konfigurierens der Codecs vom PC aus einbauen.
Nachtrag zum Konfigurieren des Codecs : Prinzipiell funktioniert es, allerdings ist das mit häßlichen Nebengeräuschen verbunden, da ich bei jeder Änderung der Lautstärke im Codec, diesen auch Resetten muß, da sonst immer beide Codecs beschrieben werden, was unschön ist. Warum dies so ist kann ich leider nicht sagen, da ich keine Möglichkeit habe die SPI-Leitungen mitzusniffen (bräuchte dafür einen kleinen LA, den ich nicht habe).

* Demo eines 3 Band Stereo Equalizers. (Der Knopf "MoveIt!" bringt Leben ins Demo): [[Media:dap_eq_demo.zip]]
* Demo eines 4 Kanal Mono Mixers mit Monitor (Vorhör)-Ausgang: [[Media:dap_mix_demo.zip]]
* Demo eines Synthesizer-Filters: [[Media:dap_filter_demo.zip]]
* Demo eines 2 Kanal Delays (Der Button "MoveIt!" macht daraus einen Chorus :-))): [[Media:dap_delay_demo.zip]]

* Quellcodes für das EQ-Demo, das Filter-Demo und das Delay-Demo : [[Media:dap_demos_plus_delphi_source.zip]]

Es folgen noch der Quellcode für den Mischer (hab ich gerade nicht zur Hand) und weitere Demos (ein Synthesizer und eine 4x4 Patchbay mit EQ und was mir sonst noch einfällt. Dann natürlich mit Source-Codes).
Anhand dieser Beispiele wird auch eine grobe Doku erstellt.

== SVN-Repository ==

svn co svn://mikrocontroller.net/audiodsp

Ein automatisch aktualisiertes Paket mit den Daten aus dem Repository gibt es unter http://www.mikrocontroller.net/download/audiodsp-snapshot.tar.gz.

== Änderungen ==

* 12.07.2007: Es wurde ein generisches Speicherinterfaces implementiert, welches Wartezyklen im DAP erlaubt. Dadurch kann man auf die jeweilgen Speicher des Boards eingehen. Z.Zt. ist nur eine einfaches Speicherschnittstelle für den asynchronen Betrieb des PSDRAM des Nexys-Boards implementiert. Die Schnittstelle ermöglicht den Anschluss eines RAM-Controller, welcher z. B. ein Quasi-Multiport-RAM darstellt. Getestet wurde der Stand mit dem Nexys-1000-Board.

==To do==

* nähere Zukunft
** Einen Konfigurationsdialog in die Demo-Programme einarbeiten mit denen man mit den Codecs etwas spielen kann (Line-In Level, Mikrofon-Level, Bypass, Head-Phone Volume) tlw. erledigt. Funktioniert aber nicht richtig, und daher noch nicht eingebaut. Quellcodes dazu sind vorhanden.
** Doku anhand der Demo-Programme erstellen
** C-Code schnipsel erstellen

* fernere Zukunft
** Front-End des DAPs machen, mit dem sich DAP-Programme erstellen lassen, der Koeffizienten-, Daten- und Wellenform-Speicher beschrieben und gelesen werden kann, der Mikro-Code editierbar gemacht wird und noch ein paar Sachen mehr machbar sind
** weitere Module für den Rahmen (HDD-Core, weitere Routing-Möglichkeiten innerhalb der bisherigen Cores SDSP und Util)

==Diskussion==
* http://www.mikrocontroller.net/topic/65205
* http://www.mikrocontroller.net/topic/34376

Falls Interesse an einer Sammelbestellung für die Platinen und Bauteile besteht

* http://www.mikrocontroller.net/topic/144288

[[Kategorie:FPGA-Projekte]]
[[Kategorie:Audio]]
[[Kategorie:DSP]]

FPGA

2017-02-13T07:39:04Z

213.61.254.68: /* FPGA-Design aus Projektsicht */ Englisches Wort ausgetauscht mit Deutschem und das Wort ersetzt.

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

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

[http://www.abaxor.de/produkte.html abaxor.de-Webseite]

==== 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 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 nicht als bare Münze zu nehmen:

* 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]]