Mikrocontroller.net - Benutzerbeiträge [de]

Benutzer:TheMason

2007-08-06T15:36:19Z

TheMason:

==Über mich==

Ich interessiere mich seit meiner Kindheit für Elektronik und Computer, und habe aus diesem Grund auch Elektrotechnik studiert.
Ich bin seit 2005 in diesem Forum, und beschäftige mich mit uC's, SW Design, VHDL Design und Platinen Design.

==Beiträge==

Die Audio-Platform mit dem Spartan 3 [[Audio-DSP_mit_Spartan_3-FPGA]] 
Der Audio-Codec TLV320AIC23b [[Audio_Codec_Board]]

==Leute gesucht==

Ich suche noch Leute die Lust und Zeit haben an dem Audio-Projekt mitzuwirken.

Audio Codec Board mit TLV320AIC23b

2007-07-14T18:52:37Z

TheMason: /* Version von TheMason */

Überlegungen zu Audio-Erweiterungsplatine mit TLV320AIC23b ([http://focus.ti.com/lit/ds/symlink/tlv320aic23b.pdf Datenblatt])

* Codec
* 12 MHz Quarz
* Analogbeschaltung wie in Eval-Board-Schaltplan
* 2x Cinch oder 1x Klinkenbuchse für Line In
* 2x Cinch oder 1x Klinkenbuchse für Line Out
* Klinkenbuchse für Kopfhörer
* Stiftleiste für I2S & I2C/SPI
* Jumper für MODE
* Jumper für Quarz/externe MCLK

Layout:
* getrennte Masseflächen für AGND und DGND, nur eine Verbindung? Wahrscheinlich mehr Aufwand als Nutzen.
* Masseflächen auf bottom layer
* siehe Hinweise in http://focus.ti.com/lit/ds/symlink/tlv320aic20k.pdf

==Version von TheMason==

Die Vorschläge sind tlw. realisiert. Z.B. Widerstandsbrücken statt Jumper, Masseflächen nicht getrennt sondern nur eine auf der Unterseite.

Schaltung in Anlehnung an das Referenz-Design von TI.

[[Media:Codec_eagle_dateien.zip|Codec_eagle_dateien.zip]]

Schaltplan als PNG :

[[Bild:Codec_sch.png|500px]]

Board Oberseite :

[[Bild:Codec_brd_top.png]]

Board Unterseite :

[[Bild:Codec_brd_btm.png]]

Bauteile Platzierung :

[[Bild:Codec_brd_partlocs.png]]

Fertige Platine (leider sehr unscharf) : 

[[Bild:Codec-board-top.jpg|thumb|pix=300|Oberseite]]

[[Bild:Codec-board-btn.jpg|thumb|pix=300|Unterseite]]

 
Es wurden 2 Boards (einer als Master, der andere als Slave) aufgebaut und tlw. getestet (Mikrofon und Headphone noch nicht getestet). Line In/Out und Konfig. funktionieren.
 

Kleiner Wermutstropfen : Die 220uF Elkos für den Kopfhörer haben das falsche Shape und sind zu klein. 
Auf dem Bild sind auch statt 0.47uF Elkos 470nF Kerkos verbaut. Passen sollten die 0.47uF aber schon, denn die 1uF sind ja schon recht klein. 

Bauteile Liste :

[[Bild:Codec_bom.zip]]

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

[[Category:Audio]]

Audio Codec Board mit TLV320AIC23b

2007-07-14T18:48:43Z

TheMason: /* Version von TheMason */

Überlegungen zu Audio-Erweiterungsplatine mit TLV320AIC23b ([http://focus.ti.com/lit/ds/symlink/tlv320aic23b.pdf Datenblatt])

* Codec
* 12 MHz Quarz
* Analogbeschaltung wie in Eval-Board-Schaltplan
* 2x Cinch oder 1x Klinkenbuchse für Line In
* 2x Cinch oder 1x Klinkenbuchse für Line Out
* Klinkenbuchse für Kopfhörer
* Stiftleiste für I2S & I2C/SPI
* Jumper für MODE
* Jumper für Quarz/externe MCLK

Layout:
* getrennte Masseflächen für AGND und DGND, nur eine Verbindung? Wahrscheinlich mehr Aufwand als Nutzen.
* Masseflächen auf bottom layer
* siehe Hinweise in http://focus.ti.com/lit/ds/symlink/tlv320aic20k.pdf

==Version von TheMason==

Die Vorschläge sind tlw. realisiert. Z.B. Widerstandsbrücken statt Jumper, Masseflächen nicht getrennt sondern nur eine auf der Unterseite.

Schaltung in Anlehnung an das Referenz-Design von TI.

[[Media:Codec_eagle_dateien.zip|Codec_eagle_dateien.zip]]

Schaltplan als PNG :

[[Bild:Codec_sch.png|500px]]

Board Oberseite :

[[Bild:Codec_brd_top.png]]

Board Unterseite :

[[Bild:Codec_brd_btm.png]]

Bauteile Platzierung :

[[Bild:Codec_brd_partlocs.png]]

Fertige Platine (leider sehr unscharf) : 

[[Bild:Codec-board-top.jpg|thumb|pix=300|Oberseite]]

[[Bild:Codec-board-btn.jpg|thumb|pix=300|Unterseite]]

[[Bild:Codec-board-btn.jpg|thumb|pix=300|Unterseite]]

 
Es wurden 2 Boards (einer als Master, der andere als Slave) aufgebaut und tlw. getestet (Mikrofon und Headphone noch nicht getestet). Line In/Out und Konfig. funktionieren.
 

Kleiner Wermutstropfen : Die 220uF Elkos für den Kopfhörer haben das falsche Shape und sind zu klein. 
Auf dem Bild sind auch statt 0.47uF Elkos 470nF Kerkos verbaut. Passen sollten die 0.47uF aber schon, denn die 1uF sind ja schon recht klein. 

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

[[Category:Audio]]

Audio Codec Board mit TLV320AIC23b

2007-07-14T18:48:19Z

TheMason: /* Version von TheMason */

Überlegungen zu Audio-Erweiterungsplatine mit TLV320AIC23b ([http://focus.ti.com/lit/ds/symlink/tlv320aic23b.pdf Datenblatt])

* Codec
* 12 MHz Quarz
* Analogbeschaltung wie in Eval-Board-Schaltplan
* 2x Cinch oder 1x Klinkenbuchse für Line In
* 2x Cinch oder 1x Klinkenbuchse für Line Out
* Klinkenbuchse für Kopfhörer
* Stiftleiste für I2S & I2C/SPI
* Jumper für MODE
* Jumper für Quarz/externe MCLK

Layout:
* getrennte Masseflächen für AGND und DGND, nur eine Verbindung? Wahrscheinlich mehr Aufwand als Nutzen.
* Masseflächen auf bottom layer
* siehe Hinweise in http://focus.ti.com/lit/ds/symlink/tlv320aic20k.pdf

==Version von TheMason==

Die Vorschläge sind tlw. realisiert. Z.B. Widerstandsbrücken statt Jumper, Masseflächen nicht getrennt sondern nur eine auf der Unterseite.

Schaltung in Anlehnung an das Referenz-Design von TI.

[[Media:Codec_eagle_dateien.zip|Codec_eagle_dateien.zip]]

Schaltplan als PNG :

[[Bild:Codec_sch.png|500px]]

Board Oberseite :

[[Bild:Codec_brd_top.png]]

Board Unterseite :

[[Bild:Codec_brd_btm.png]]

Bauteile Platzierung :

[[Bild:Codec_brd_partlocs.png]]

Fertige Platine (leider sehr unscharf) : 

[[Bild:Codec-board-top.jpg|thumb|pix=300|Oberseite]]

[[Bild:Codec-board-btn.jpg|thumb|pix=300|Unterseite]]

[[Bild:Codec-board-btn.jpg|thumb|pix=300|Unterseite]]

 
Es wurden 2 Boards (einer als Master, der andere als Slave) aufgebaut und tlw. getestet (Mikrofon und Headphone noch nicht getestet). Line In/Out und Konfig. funktionieren.
 

Kleiner Wermutstropfen : Die 220uF Elkos für den Kopfhörer haben das falsche Shape und sind zu klein. 
Auf dem Bild sind auch statt 0.47uF Elkos 470nF Kerkos verbaut. Passen sollten die 0.47uF aber schon, denn die 1uF sind ja schon recht klein. 

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

[[Category:Audio]]

Datei:Codec bom.zip

2007-07-14T18:39:57Z

TheMason:

Audio Codec Board mit TLV320AIC23b

2007-07-14T18:38:06Z

TheMason: /* Version von TheMason */

Überlegungen zu Audio-Erweiterungsplatine mit TLV320AIC23b ([http://focus.ti.com/lit/ds/symlink/tlv320aic23b.pdf Datenblatt])

* Codec
* 12 MHz Quarz
* Analogbeschaltung wie in Eval-Board-Schaltplan
* 2x Cinch oder 1x Klinkenbuchse für Line In
* 2x Cinch oder 1x Klinkenbuchse für Line Out
* Klinkenbuchse für Kopfhörer
* Stiftleiste für I2S & I2C/SPI
* Jumper für MODE
* Jumper für Quarz/externe MCLK

Layout:
* getrennte Masseflächen für AGND und DGND, nur eine Verbindung? Wahrscheinlich mehr Aufwand als Nutzen.
* Masseflächen auf bottom layer
* siehe Hinweise in http://focus.ti.com/lit/ds/symlink/tlv320aic20k.pdf

==Version von TheMason==

Die Vorschläge sind tlw. realisiert. Z.B. Widerstandsbrücken statt Jumper, Masseflächen nicht getrennt sondern nur eine auf der Unterseite.

Schaltung in Anlehnung an das Referenz-Design von TI.

[[Media:Codec_eagle_dateien.zip|Codec_eagle_dateien.zip]]

Schaltplan als PNG :

[[Bild:Codec_sch.png|500px]]

Board Oberseite :

[[Bild:Codec_brd_top.png]]

Board Unterseite :

[[Bild:Codec_brd_btm.png]]

Bauteile Platzierung :

[[Bild:Codec_brd_partlocs.png]]

Fertige Platine (leider sehr unscharf) : 

[[Bild:Codec-board-top.jpg|thumb|pix=300|Oberseite]]

[[Bild:Codec-board-btn.jpg|thumb|pix=300|Unterseite ]]

 
Es wurden 2 Boards (einer als Master, der andere als Slave) aufgebaut und tlw. getestet (Mikrofon und Headphone noch nicht getestet). Line In/Out und Konfig. funktionieren.
 

Kleiner Wermutstropfen : Die 220uF Elkos für den Kopfhörer haben das falsche Shape und sind zu klein. 
Auf dem Bild sind auch statt 0.47uF Elkos 470nF Kerkos verbaut. Passen sollten die 0.47uF aber schon, denn die 1uF sind ja schon recht klein. 

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

[[Category:Audio]]

Datei:Codec-board-top.jpg

2007-07-14T18:29:01Z

TheMason:

Datei:Codec-board-btn.jpg

2007-07-14T18:28:53Z

TheMason:

Audio-DSP mit Spartan 3-FPGA

2007-07-14T18:28:11Z

TheMason: /* Fotos */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshaper
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

In dem unten angegebenen Repository ist eine Version (ohne Speicheranbindung des Util-Cores) die auf dem Nexys Board lauffähig ist. 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).

==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.Z. nur über RS232 steuerbar). Neu bei der Version ist das das Speicherinterface generisch ausgelegt wurde und ein einfacher SRAM-Controller für das Nexys Board PSDRAM geschrieben wurde. Durch das generische Interface ist es möglich andere Speicherarten anzubinden.

* 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 Pin Belegung 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 1 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 

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

[[Bild:dap_nexys_v1.jpg|thumb|300px|left|Nexys Board mit 1 Audio-Codec]]
 

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

[[Bild:Nexys-board-codecs-1.jpg|thumb|300px|left|2 Audio-Codec-Boards (siehe Artikel "Audio-Codec-Board")]]
 

==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). PC Programm und Source folgen

[[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)]]

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

- Update 12.07.2007 :

Es wurde ein generisches Speicherinterfaces welches Wartezyklen im DAP erlaubt implementiert. Dadurch kann man auf die jeweilgen Speicher des Boards eingehen. Z.Z. ist nur ein einfaches Speicherinterface für den asynchronen Betrieb des PSDRAM des Nexys Boards implementiert. Das Interface ermögicht es einen RAM Controller anzuschließen 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]] [[Category:DSP]]

Datei:Nexys-board-codecs-1.jpg

2007-07-14T18:23:15Z

TheMason:

Datei:Nexys-board-gesamt.jpg

2007-07-14T18:22:51Z

TheMason:

Audio Codec Board mit TLV320AIC23b

2007-07-13T11:42:34Z

TheMason:

Datei:Codec brd partlocs.png

2007-07-13T11:38:37Z

TheMason:

Datei:Codec brd top.png

2007-07-13T11:38:31Z

TheMason:

Datei:Codec brd btm.png

2007-07-13T11:38:25Z

TheMason:

Datei:Codec sch.png

2007-07-13T11:37:11Z

TheMason:

Datei:Codec eagle dateien.zip

2007-07-13T11:35:54Z

TheMason:

Audio-DSP mit Spartan 3-FPGA

2007-07-13T11:05:47Z

TheMason: /* Nexys Board */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshaper
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

In dem unten angegebenen Repository ist eine Version (ohne Speicheranbindung des Util-Cores) die auf dem Nexys Board lauffähig ist. 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).

==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.Z. nur über RS232 steuerbar). Neu bei der Version ist das das Speicherinterface generisch ausgelegt wurde und ein einfacher SRAM-Controller für das Nexys Board PSDRAM geschrieben wurde. Durch das generische Interface ist es möglich andere Speicherarten anzubinden.

* 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 Pin Belegung für die RS232 und den Audio-Codec ist wie folgt :

Header A : 

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 : 

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) 

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

[[Bild:dap_nexys_v1.jpg|thumb|300px|left|Nexys Board mit 1 Audio-Codec]]
 

==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). PC Programm und Source folgen

[[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)]]

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

- Update 12.07.2007 :

Es wurde ein generisches Speicherinterfaces welches Wartezyklen im DAP erlaubt implementiert. Dadurch kann man auf die jeweilgen Speicher des Boards eingehen. Z.Z. ist nur ein einfaches Speicherinterface für den asynchronen Betrieb des PSDRAM des Nexys Boards implementiert. Das Interface ermögicht es einen RAM Controller anzuschließen 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]] [[Category:DSP]]

Audio-DSP mit Spartan 3-FPGA

2007-07-13T10:59:30Z

TheMason: /* Fotos */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshaper
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

In dem unten angegebenen Repository ist eine Version (ohne Speicheranbindung des Util-Cores) die auf dem Nexys Board lauffähig ist. 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).

==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.Z. nur über RS232 steuerbar). Neu bei der Version ist das das Speicherinterface generisch ausgelegt wurde und ein einfacher SRAM-Controller für das Nexys Board PSDRAM geschrieben wurde. Durch das generische Interface ist es möglich andere Speicherarten anzubinden.

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

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

[[Bild:dap_nexys_v1.jpg|thumb|300px|left|Nexys Board mit 1 Audio-Codec]]
 

==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). PC Programm und Source folgen

[[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)]]

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

- Update 12.07.2007 :

Es wurde ein generisches Speicherinterfaces welches Wartezyklen im DAP erlaubt implementiert. Dadurch kann man auf die jeweilgen Speicher des Boards eingehen. Z.Z. ist nur ein einfaches Speicherinterface für den asynchronen Betrieb des PSDRAM des Nexys Boards implementiert. Das Interface ermögicht es einen RAM Controller anzuschließen 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]] [[Category:DSP]]

Datei:Dap nexys v1.jpg

2007-07-13T10:58:39Z

TheMason:

Audio-DSP mit Spartan 3-FPGA

2007-07-13T00:25:33Z

TheMason: /* To do ... */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshaper
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

In dem unten angegebenen Repository ist eine Version (ohne Speicheranbindung des Util-Cores) die auf dem Nexys Board lauffähig ist. 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).

==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.Z. nur über RS232 steuerbar). Neu bei der Version ist das das Speicherinterface generisch ausgelegt wurde und ein einfacher SRAM-Controller für das Nexys Board PSDRAM geschrieben wurde. Durch das generische Interface ist es möglich andere Speicherarten anzubinden.

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

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==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). PC Programm und Source folgen

[[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)]]

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

- Update 12.07.2007 :

Es wurde ein generisches Speicherinterfaces welches Wartezyklen im DAP erlaubt implementiert. Dadurch kann man auf die jeweilgen Speicher des Boards eingehen. Z.Z. ist nur ein einfaches Speicherinterface für den asynchronen Betrieb des PSDRAM des Nexys Boards implementiert. Das Interface ermögicht es einen RAM Controller anzuschließen 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]] [[Category:DSP]]

Audio-DSP mit Spartan 3-FPGA

2007-07-13T00:24:40Z

TheMason: /* SVN-Repository */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshaper
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

In dem unten angegebenen Repository ist eine Version (ohne Speicheranbindung des Util-Cores) die auf dem Nexys Board lauffähig ist. 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).

==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.Z. nur über RS232 steuerbar). Neu bei der Version ist das das Speicherinterface generisch ausgelegt wurde und ein einfacher SRAM-Controller für das Nexys Board PSDRAM geschrieben wurde. Durch das generische Interface ist es möglich andere Speicherarten anzubinden.

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

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==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). PC Programm und Source folgen

[[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)]]

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

- Update 12.07.2007 :

Es wurde ein generisches Speicherinterfaces welches Wartezyklen im DAP erlaubt implementiert. Dadurch kann man auf die jeweilgen Speicher des Boards eingehen. Z.Z. ist nur ein einfaches Speicherinterface für den asynchronen Betrieb des PSDRAM des Nexys Boards implementiert. Das Interface ermögicht es einen RAM Controller anzuschließen welcher z.B. ein quasi-Multiport RAM darstellt.
Getestet wurde der Stand mit dem Nexys-1000 Board.

==To do ...==

--nähere Zukunft--
* Eine neue 9.1'er ISE Version uploaden die dann alle fehlenden Features (Delay, Lesen, Codecs initialisieren) gegenüber der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
* 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.
* Ein einfaches Synth Demo (Oszillatoren und Filter)
* 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]] [[Category:DSP]]

Audio-DSP mit Spartan 3-FPGA

2007-07-13T00:18:23Z

TheMason: /* ISE6.2 vs. ISE9.1 */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshaper
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

In dem unten angegebenen Repository ist eine Version (ohne Speicheranbindung des Util-Cores) die auf dem Nexys Board lauffähig ist. 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).

==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.Z. nur über RS232 steuerbar). Neu bei der Version ist das das Speicherinterface generisch ausgelegt wurde und ein einfacher SRAM-Controller für das Nexys Board PSDRAM geschrieben wurde. Durch das generische Interface ist es möglich andere Speicherarten anzubinden.

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

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==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). PC Programm und Source folgen

[[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)]]

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

==To do ...==

--nähere Zukunft--
* Eine neue 9.1'er ISE Version uploaden die dann alle fehlenden Features (Delay, Lesen, Codecs initialisieren) gegenüber der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
* 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.
* Ein einfaches Synth Demo (Oszillatoren und Filter)
* 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]] [[Category:DSP]]

Datei:Nexys dap.zip

2007-07-13T00:17:51Z

TheMason: ZIP File des MCS-Files für den DAP auf dem Nexys-1000 Board

ZIP File des MCS-Files für den DAP auf dem Nexys-1000 Board

Audio-DSP mit Spartan 3-FPGA

2007-04-20T20:27:09Z

TheMason: /* To do ... */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==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). PC Programm und Source folgen

[[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)]]

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

==To do ...==

--nähere Zukunft--
* Eine neue 9.1'er ISE Version uploaden die dann alle fehlenden Features (Delay, Lesen, Codecs initialisieren) gegenüber der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
* 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.
* Ein einfaches Synth Demo (Oszillatoren und Filter)
* 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Audio-DSP mit Spartan 3-FPGA

2007-04-20T20:26:13Z

TheMason: /* Audio Demos */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==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). PC Programm und Source folgen

[[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)]]

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

==To do ...==

--nähere Zukunft--
* Eine neue 9.1'er ISE Version uploaden die dann alle fehlenden Features (Delay, Lesen, Codecs initialisieren) gegenüber der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
* Einen Kofigurationsdialog 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.
* Ein einfaches Synth Demo (Oszillatoren und Filter)
* 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Datei:Synthdemo1.wav.zip

2007-04-20T20:24:38Z

TheMason:

Audio-DSP mit Spartan 3-FPGA

2007-04-17T19:52:46Z

TheMason: /* To do ... */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==Audio Demos==

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

[[Media:eq_demo1.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)]]

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

==To do ...==

--nähere Zukunft--
* Eine neue 9.1'er ISE Version uploaden die dann alle fehlenden Features (Delay, Lesen, Codecs initialisieren) gegenüber der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
* Einen Kofigurationsdialog 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.
* Ein einfaches Synth Demo (Oszillatoren und Filter)
* 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Audio-DSP mit Spartan 3-FPGA

2007-04-17T19:51:53Z

TheMason: /* Delphi Tools */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==Audio Demos==

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

[[Media:eq_demo1.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)]]

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

==To do ...==

--nähere Zukunft--
* Eine neue 9.1'er ISE Version uploaden die dann alle fehlenden Features (Delay, Lesen, Codecs initialisieren) gegenüber der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
* Einen Kofigurationsdialog in die Demo-Programme einarbeiten mit denen man mit den Codecs etwas spielen kann (Line-In Level, Mikrofon-Level, Bypass, Head-Phone Volume)
* Ein einfaches Synth Demo (Oszillatoren und Filter)
* Sources der Demo-Programme uploaden
* 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Datei:Dap demos plus delphi source.zip

2007-04-17T19:46:01Z

TheMason:

Audio-DSP mit Spartan 3-FPGA

2007-04-04T17:47:22Z

TheMason: /* Audio Demos */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==Audio Demos==

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

[[Media:eq_demo1.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-eq-demo.wav.zip|Delay-Demo (137BPM [657ms & 876 ms]/Chorus)]]

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

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

==To do ...==

--nähere Zukunft--
* Eine neue 9.1'er ISE Version uploaden die dann alle fehlenden Features (Delay, Lesen, Codecs initialisieren) gegenüber der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
* Einen Kofigurationsdialog in die Demo-Programme einarbeiten mit denen man mit den Codecs etwas spielen kann (Line-In Level, Mikrofon-Level, Bypass, Head-Phone Volume)
* Ein einfaches Synth Demo (Oszillatoren und Filter)
* Sources der Demo-Programme uploaden
* 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Datei:Mc505-filter-demo.wav.zip

2007-04-04T17:45:22Z

TheMason:

Datei:Mc505-delay-demo.wav.zip

2007-04-04T17:43:53Z

TheMason:

Datei:Mc505-eq-demo.wav.zip

2007-04-04T17:43:12Z

TheMason:

Audio-DSP mit Spartan 3-FPGA

2007-04-01T19:52:16Z

TheMason: /* In Kürze ... */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==To do ...==

--nähere Zukunft--
* Eine neue 9.1'er ISE Version uploaden die dann alle fehlenden Features (Delay, Lesen, Codecs initialisieren) gegenüber der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
* Einen Kofigurationsdialog in die Demo-Programme einarbeiten mit denen man mit den Codecs etwas spielen kann (Line-In Level, Mikrofon-Level, Bypass, Head-Phone Volume)
* Ein einfaches Synth Demo (Oszillatoren und Filter)
* Sources der Demo-Programme uploaden
* 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
* Synthesizer realisieren (in Verbindung mit uC, MSP430 oder ARM7)
* 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/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Audio-DSP mit Spartan 3-FPGA

2007-04-01T19:28:39Z

TheMason: /* ISE6.2 vs. ISE9.1 */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]] (noch die alte Version -> Kein Delay, Kein Lesen und vor allem : Kein Initialisieren der Codecs)

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==In Kürze ...==

... werde ich noch die geänderten PC-Demos hochladen, damit man alles vom PC aus machen kann. Die neue ISE 6.2'er Version unterstützt das Ansteuern der Codecs.
 

... werde ich eine neue 9.1'er ISE Version uploaden die dann alle Features der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
 

==Diskussion==
* http://www.mikrocontroller.net/topic/65205
* http://www.mikrocontroller.net/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Audio-DSP mit Spartan 3-FPGA

2007-04-01T19:27:43Z

TheMason: /* Hardware */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 erstmal nur zu Initialisierung der Codecs. Dieser Vorgang kann nun vom PC aus gesteuert werden, da in der neuen ISE 6.2 Version 4 Leitungen herausgeführtz wurden, welche per RS232 gesetzt und gelöscht werden.
Wer das System nachbauen möchte kann entweder die TLV320AIC23B Codecs, aber 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 muß dann aber separat vorgenommen werden (wobei man dann wahrscheinlich nicht um einen uC drum herum 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]]

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left|Spartan3 Board und Expansion Board]]
 

[[Bild:Codecs.jpg|thumb|300px|left|Expansion Board]]
 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==In Kürze ...==

... werde ich noch die geänderten PC-Demos hochladen, damit man alles vom PC aus machen kann. Die neue ISE 6.2'er Version unterstützt das Ansteuern der Codecs.
 

... werde ich eine neue 9.1'er ISE Version uploaden die dann alle Features der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
 

==Diskussion==
* http://www.mikrocontroller.net/topic/65205
* http://www.mikrocontroller.net/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Audio-DSP mit Spartan 3-FPGA

2007-04-01T10:49:47Z

TheMason: /* In Kürze ... */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 hier vorgestellten Schaltplan ist ein MSP430 enthalten der allerdings nur die Initialisierung und Konfiguration der Codecs übernimmt. Wer das System nachbauen möchte kann beliebige 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. Um das System zu Testen wird lediglich eine serielle Schnittstelle verwendet. Wer will kann aber genausogut den SPI-Modus verwenden und den DAP direkt von einem Mikrocontroller aus steuern. Ansonsten benötigt das System nur den Pin 13 des B1-Connectors. 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]]

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

Spartan3 Board und Expansion Board
 

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left]]

 
Expansion Board

[[Bild:Codecs.jpg|thumb|300px|left]]

 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==In Kürze ...==

... werde ich noch die geänderten PC-Demos hochladen, damit man alles vom PC aus machen kann. Die neue ISE 6.2'er Version unterstützt das Ansteuern der Codecs.
 

... werde ich eine neue 9.1'er ISE Version uploaden die dann alle Features der 6.2'er ISE Version enthält. (sofern es mit ISE 9.1 machbar bzw. compilierbar ist)
 

==Diskussion==

http://www.mikrocontroller.net/topic/65205

http://www.mikrocontroller.net/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Audio-DSP mit Spartan 3-FPGA

2007-04-01T10:48:31Z

TheMason: /* ISE6.2 vs. ISE9.1 */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 hier vorgestellten Schaltplan ist ein MSP430 enthalten der allerdings nur die Initialisierung und Konfiguration der Codecs übernimmt. Wer das System nachbauen möchte kann beliebige 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. Um das System zu Testen wird lediglich eine serielle Schnittstelle verwendet. Wer will kann aber genausogut den SPI-Modus verwenden und den DAP direkt von einem Mikrocontroller aus steuern. Ansonsten benötigt das System nur den Pin 13 des B1-Connectors. 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Ise6.2_gpo.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]]

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

Spartan3 Board und Expansion Board
 

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left]]

 
Expansion Board

[[Bild:Codecs.jpg|thumb|300px|left]]

 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==In Kürze ...==

... werde ich noch eine kleine Erweiterung des DAP einbauen, die es erlaubt die Codecs vom PC aus zu konfigurieren. Dadurch entfällt der uC, und ich hoffe dadurch mehr Leute zum ausprobieren dieses Projekts zu bringen.
 

... werde ich eine neue 9.1'er ISE Version uploaden die dann alle Features der 6.2'er ISE Version enthält.
 

==Diskussion==

http://www.mikrocontroller.net/topic/65205

http://www.mikrocontroller.net/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Datei:Ise6.2 gpo.zip

2007-04-01T10:47:57Z

TheMason:

Audio-DSP mit Spartan 3-FPGA

2007-04-01T10:47:08Z

TheMason: /* Fotos */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 hier vorgestellten Schaltplan ist ein MSP430 enthalten der allerdings nur die Initialisierung und Konfiguration der Codecs übernimmt. Wer das System nachbauen möchte kann beliebige 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. Um das System zu Testen wird lediglich eine serielle Schnittstelle verwendet. Wer will kann aber genausogut den SPI-Modus verwenden und den DAP direkt von einem Mikrocontroller aus steuern. Ansonsten benötigt das System nur den Pin 13 des B1-Connectors. 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Dap Ise6.2.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]]

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

Spartan3 Board und Expansion Board
 

[[Bild:Gesamt_wo_uc.jpg|thumb|300px|left]]

 
Expansion Board

[[Bild:Codecs.jpg|thumb|300px|left]]

 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==In Kürze ...==

... werde ich noch eine kleine Erweiterung des DAP einbauen, die es erlaubt die Codecs vom PC aus zu konfigurieren. Dadurch entfällt der uC, und ich hoffe dadurch mehr Leute zum ausprobieren dieses Projekts zu bringen.
 

... werde ich eine neue 9.1'er ISE Version uploaden die dann alle Features der 6.2'er ISE Version enthält.
 

==Diskussion==

http://www.mikrocontroller.net/topic/65205

http://www.mikrocontroller.net/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Audio-DSP mit Spartan 3-FPGA

2007-04-01T10:46:32Z

TheMason: /* Hardware */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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 hier vorgestellten Schaltplan ist ein MSP430 enthalten der allerdings nur die Initialisierung und Konfiguration der Codecs übernimmt. Wer das System nachbauen möchte kann beliebige 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. Um das System zu Testen wird lediglich eine serielle Schnittstelle verwendet. Wer will kann aber genausogut den SPI-Modus verwenden und den DAP direkt von einem Mikrocontroller aus steuern. Ansonsten benötigt das System nur den Pin 13 des B1-Connectors. 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 Pin-Belegung des B1-Expansion Connectors:

Pin

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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Dap Ise6.2.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]]

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

Spartan3 Board und Expansion Board
 

[[Bild:Gesamt.jpg|thumb|300px|left]]

 
Expansion Board

[[Bild:exp-board1.jpg|thumb|300px|left]]

 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==In Kürze ...==

... werde ich noch eine kleine Erweiterung des DAP einbauen, die es erlaubt die Codecs vom PC aus zu konfigurieren. Dadurch entfällt der uC, und ich hoffe dadurch mehr Leute zum ausprobieren dieses Projekts zu bringen.
 

... werde ich eine neue 9.1'er ISE Version uploaden die dann alle Features der 6.2'er ISE Version enthält.
 

==Diskussion==

http://www.mikrocontroller.net/topic/65205

http://www.mikrocontroller.net/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Datei:Fpga ext board schematic no uc.JPG

2007-04-01T10:44:25Z

TheMason:

Datei:Codecs.jpg

2007-04-01T10:44:00Z

TheMason:

Datei:Gesamt wo uc.jpg

2007-04-01T10:43:46Z

TheMason:

Audio-DSP mit Spartan 3-FPGA

2007-04-01T10:42:55Z

TheMason: /* Übersicht */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors 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 Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß 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- Connector. 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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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:Schematic.JPG|thumb|500px]]

Wie Eingangs erwähnt benötigt das System eine (bzw. zwei) Audio-Codecs. Im hier vorgestellten Schaltplan ist ein MSP430 enthalten der allerdings nur die Initialisierung und Konfiguration der Codecs übernimmt. Wer das System nachbauen möchte kann beliebige 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. Um das System zu Testen wird lediglich eine serielle Schnittstelle verwendet. Wer will kann aber genausogut den SPI-Modus verwenden und den DAP direkt von einem Mikrocontroller aus steuern. Ansonsten benötigt das System nur den Pin 13 des B1-Connectors. 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 Pin-Belegung des B1-Expansion Connectors:

Pin

*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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Dap Ise6.2.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]]

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

Spartan3 Board und Expansion Board
 

[[Bild:Gesamt.jpg|thumb|300px|left]]

 
Expansion Board

[[Bild:exp-board1.jpg|thumb|300px|left]]

 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==In Kürze ...==

... werde ich noch eine kleine Erweiterung des DAP einbauen, die es erlaubt die Codecs vom PC aus zu konfigurieren. Dadurch entfällt der uC, und ich hoffe dadurch mehr Leute zum ausprobieren dieses Projekts zu bringen.
 

... werde ich eine neue 9.1'er ISE Version uploaden die dann alle Features der 6.2'er ISE Version enthält.
 

==Diskussion==

http://www.mikrocontroller.net/topic/65205

http://www.mikrocontroller.net/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Datei:Overview wo uc.jpg

2007-04-01T10:42:07Z

TheMason:

Audio-DSP mit Spartan 3-FPGA

2007-03-29T19:09:31Z

TheMason: /* Übersicht */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features der Audio-Hardware:

* 2 Stereo-Codecs (also 4 Mono Audio-Ein- und Ausgänge)
* Mikrocontroller (MSP430)
* MIDI-Interface (noch nicht implementiert)

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors via SPI oder RS232
* 4 Mono Ein- und Ausgänge

==Übersicht==
[[Bild:Overview.JPG|thumb|500px]]
Basis des Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==Nachbau==

Derjenige der sich dieses System nachbauen möchte benötigt erstmal ein FPGA-Board. Mit dem Spartan 3 Board von Digilent gestaltet sich der Nachbau dadurch einfach, als das die Programmier-Dateien für den FPGA direkt für dieses Board verwendet werden können. Nutzer anderer Boards (Xlinx) 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 Sample bei TI direkt bekommen.
Des weiteren benötigt man noch eine handvoll (oder bei SMD Fingernagelbreite :-) Bauteile wie Kondensatoren, Widerstände und einen Quarz. (Ein Codec MUß als Master laufen)
Die Initialisierung des Codecs wird momentan zwar noch von einem uC übernommen, aber in Kürze wird eine geänderte Version hochgeladen, mit der der Codec vom PC aus Initialisiert wird, wodurch der Mikroprozessor entfallen kann und den Nachbau deutlich vereinfacht.

==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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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:Schematic.JPG|thumb|500px]]

Wie Eingangs erwähnt benötigt das System eine (bzw. zwei) Audio-Codecs. Im hier vorgestellten Schaltplan ist ein MSP430 enthalten der allerdings nur die Initialisierung und Konfiguration der Codecs übernimmt. Wer das System nachbauen möchte kann beliebige 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. Um das System zu Testen wird lediglich eine serielle Schnittstelle verwendet. Wer will kann aber genausogut den SPI-Modus verwenden und den DAP direkt von einem Mikrocontroller aus steuern. Ansonsten benötigt das System nur den Pin 13 des B1-Connectors. 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 Pin-Belegung des B1-Expansion Connectors:

Pin

*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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Dap Ise6.2.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]]

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

Spartan3 Board und Expansion Board
 

[[Bild:Gesamt.jpg|thumb|300px|left]]

 
Expansion Board

[[Bild:exp-board1.jpg|thumb|300px|left]]

 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==In Kürze ...==

... werde ich noch eine kleine Erweiterung des DAP einbauen, die es erlaubt die Codecs vom PC aus zu konfigurieren. Dadurch entfällt der uC, und ich hoffe dadurch mehr Leute zum ausprobieren dieses Projekts zu bringen.
 

... werde ich eine neue 9.1'er ISE Version uploaden die dann alle Features der 6.2'er ISE Version enthält.
 

==Diskussion==

http://www.mikrocontroller.net/topic/65205

http://www.mikrocontroller.net/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Audio-DSP mit Spartan 3-FPGA

2007-03-29T18:50:07Z

TheMason: /* Delphi Tools */

von [[Benutzer:TheMason]]

==Ziel==

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

==Update==

Da ich seit geraumer Zeit an diesem Projekt alleine arbeite, ist recht viel Arbeit angefallen und ich versuche diese nun Vorzustellen und zu Gliedern.

==Feature-Liste==

Features der Audio-Hardware:

* 2 Stereo-Codecs (also 4 Mono Audio-Ein- und Ausgänge)
* Mikrocontroller (MSP430)
* MIDI-Interface (noch nicht implementiert)

Features des Audio-Prozessors:

* Oszillatoren
* Biquads (Filter)
* Addierer, Schalter, Verstärker (Multiplizierer)
* Delays
* Steuerung des Audio-Prozessors via SPI oder RS232
* 4 Mono Ein- und Ausgänge

==Übersicht==
[[Bild:Overview.JPG|thumb|500px]]
Basis des Audio-Systems ist das Xilinx Spartan 3-Development Board. An diesem Board werden 2 Audio-Codecs angschlossen 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 Audio-Prozessors, erläutere das Interface (welches ich als Basis für weitere Projekte bereits nutze) und gebe einen kleinen Überblick über die Hardware.

Das System kann (sofern man 2 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 Audio-Prozessor startet mit einem Stereo-Tiefpass-Filter der sich auf den ersten Codec bezieht,
sodass man ein erstes Demo hat (selbst wenn es etwas unspektakulär ist)

 

==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 eine eigene Statemachine und einen eigenen Mikro-Code Speicher besitzen. Dieses Feature ist allerdings noch nicht implementiert.

Der SDSP-Kern besteht im wesentlichen aus einer MAC-Einheit, einem Speicher für Audio-Daten, einem Koeffizienten-Speicher, einem Adress-Generator und mehreren Muxern, sowie der schon angesprochenen Statemachine und dem Microcode. Weiterhin ist ein Hidden-Write- (bzw. Shadow Register) Mechanismus integriert,
welcher ein "knackser-freies" Updaten von Koeffizienten ermöglicht. Alle diese Komponenten werden vom MicroCode aus gesteuert (genau wie bei einem Mikrocontroller). Mit diesem Kern ist es möglich, Audio-Signale 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
Audio-Werten.

Der Utility Kern besteht aus einem Akkumulator (für DDS), einem Shaper, einem Adress-Generator, einem Wavetable-Speicher, einem Random-Number Generator, einigen Muxern, (einem Adress-Generator für SRAM, einem SRAM-Controller; diese sind allerdings nur nutzbar wenn man das ganze mit dem ISE 6.2 synthetisiert)
und der schon angesprochenen Statemachine 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 Audio-Signalen zuständig, und erlaubt ein Audio-Signal zu verzögern, sofern man die ISE-Version 6.2 Verwendet (später dazu mehr). Als Wellenformen stehen Sägezahn, Rechteck (mit veränderbarem Puls/Pausen-Verhältnis), Rauschen sowie benutzderdefinierbare Wellenformen (Wavetable) zur verfügung.

Der Rahmen besteht aus einer Statemachine, einem Programm-Speicher, einigen Muxern, sowie einem doppelten I2S Sender-Empfänger (für 2 Stereo Ein- und Ausgänge). In dem Rahmen werden die beiden Kerne "eingehängt". Die Kerne werden vom Programmspeicher aus mit Daten versorgt, und von der Statemachine angetriggert. Der Programmspeicher (PMEM) ist als 512x32 Bit organisiert. Das heißt das ein Befehl im Programmspeicher 32 Bit Informationen enthält und der
Audio-Prozessor max. 512 Befehle umfassen kann.

==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 = Eingangs-Routing (Kanal 1 - 4, Ergebnis SDSP Core, Ergebnis Utility Core)
* 4 Bit = Ausgangs-Routing (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 Data Memory)
* 8 Bit = Adresse 2 (bei SDSP für Koeffizienten-Memory, bei Utility Kern unbenutzt)

Das Eingangsrouting bestimmt mit welchem Signal der gewählte Kern arbeiten soll. Dies können die Eingänge 1-4 sein, 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
* Audio Wert speichern
* Audio Wert laden
* Move eines Wertes im Audio-Speicher
* Summe resetten
* Eingang zu Summe addieren
* Wert aus dem Audio-Speicher zu Summe addieren
* Eingang zu summe mischen (mit Lautstärke Koeffizient)
* wert aus dem Audio-Speicher zu Summe mischen (mit Lautstärke Koeffizient)
* Lautstärke

Utility-Kern:
* Oszillator (DDS-Teil)
* Waveshapter
* Delay

Der Ablauf eines Audio-Programms ist folgender:

Sobald ein neues Sample anliegt, wird die Abarbeitung des Programms von Adresse 0x0000 an im PMEM angestossen. 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) angetriggert. 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 Antriggern des Programms, Antriggern der einzelnen Kerne, warten auf dessen Abarbeitung und das Programm-Ende) wird vom Rahmen übernommen.

==Speicherorganisation==

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

DAP
* Programmspeicher (PMEM) 0x0000 - 0x07ff

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

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

==Hidden-Write==
Um bei Änderung der Koeffizienten "Knackser" zu vermeiden (die dadurch entstehen das der Koeffizient nur teilweise [durch 8 Bit Zugriffe] geändert wird, währenddessen aber Audio trotzdem noch "weiterläuft", und mit "falschen" Zwischenwerte 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 Start-Adresse innerhalb des Koeffizienten Speichers an. Diese Adresse ist nur 8 Bit breit. Die Speicherstelle 0x2021 gibt an wieviele der 8 Register übertragen werden sollen. Die Speicherstelle 0x2022 triggert den Kopier-Vorgang an. Hier reicht es ein Dummy byte zu schreiben. Um den Kopiervorgang zu beenden (MUß GEMACHT WERDEN!!, sonst können keine weiteren Koeffizienten Updates gemacht werden) schreibt man an Speicherstelle 0x2023 ebenfalls ein Dummy Byte.

==I/O Register==

Es gibt noch einen 8-Bit breiten Adress-Bereich innerhalb des DAPs mit dem der I2S-Teil gemutet werden kann. Weiterhin hat man die Möglichkeit die Anzahl der System-Takte pro Sample und die Anzahl der aktiven System-Takte (also die Zeit die der Audio-Prozessor 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 ein Interface implementiert, welches einfach zu handhaben ist und einfach erweitert werden kann. Das Interface kann per RS232 (fest eingestellt auf 115,2kBaud) oder per SPI (wird Hardware-Mässig eingestellt) angesteuert werden. Das Interface in seiner Gesamtheit ist schichtweise aufgebaut und beginnt mit einem Data-Dispatcher. Dieser Data-Dispatcher entscheidet (nach dem dieser selektiert wurde) mit dem ersten Byte, an welches angeschlossene Gerät der weitere Datenstrom geleitet wird.

Als angeschlossene Geräte sind im aktuellen Design ein Gerät namens "StdIO" und der Audio-Prozessor angeschlossen.

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

Der Audio-Prozessor besteht (Interface-seitig gesehen) nur aus einem Speicher-Zugriffs-Interface. Dieses Speicher-Interface entscheidet mit dem ersten Byte (sobald es selektiert wurde) ob in den Speicher geschrieben, von diesem gelesen, ein I/O Schreib oder Lese Zugriff erfolgen soll.
Die Folgenden 2 Bytes (im Falle eines I/O Zugriffs nur 1 Byte) bestimmen die Adresse und damit den Speicher-Bereich des Audio-Prozessors auf den Zugegriffen werden soll. Das Speicherinterface besitzt einen Autoincrement,
mit dem fortalufende Bytes einfach hintereinander weggeschrieben werden können, ohne das jedesmal 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-Statemachines wurden im Reset gehalten. Erst mit dem Setzen dieser Leitung wurde der FPGA angesprochen. (erstes Byte -> Daten-Dispatcher, folgende Bytes gehen an das Gerät, wenn eines ausgewählt wurde). Weiterhin hat SPI die Eigenschaft das mit jedem gesendeten Byte auch eines Emfpangen wurde. Der Umstand das RS232 weder eine Chip-Select Leitung benötigt, noch eine synchrone Übertragung erzwingt führt zu dem Umstand das man bei Nutzung von RS232 einige Befehle zusätzlich benötigt. Diese Befehle werden durch das Zeichen 0x1b (ESC) eingeleitet. Soll statt der "Spezial-Funktion" 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 muß 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 muß, muß dieser doppelt gesendet werden !!)
*- ESC 0x01 (FPGA Deselektieren)

Beispiel um in den Programmspeicher des Audio-Prozessors 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 Schalter-Stellung in Ausgabe-Register)
*- ESC 0x02 (Ausgabe Register übertragen, danach empfängt man die 8 Schalterstellungen binär-codiert)
*- 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 Inrformationen über die an den Ports des Daten-Dispatchers angeschlossenen Geräte zu ermitteln. Dieses Feature kann dazu genutuzt 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 Ausgabe-Registers)
*- ESC 0x02 (Ausgabe Register ü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 - Audio Programm Ende (wichtig !!!)
*ESC 0x01 - DAP & FPGA deselektieren

Erklärung :

Der Aufbau des Opcodes 0x100008 deutet an, das ein Biquad durchgerechnet werden soll. Das Eingangsregister 0 bedeutet das Kanal 1 des 1. Codecs verwendet wird. Das Ausgangsregister welches nach Fertigstellung des Ergebnisses benutzt werden
ist 0 (-> Kanal 1 des 1. Codecs). Der Teil 0x00 0x08 bedeutet hierbei, das die Biquad-Koeffizienten im CMEM ab Adresse 0x08 stehen. Die Audio-Zwischenwerte werden im Audio-Speicher AMEM ab Adresse 0x00 gelegt.
Der zweite Opcode (0x10f00810) rechnet ebenfalls ein Biquad durch. Nur das 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 das ein Audio-Signal 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 das 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:Schematic.JPG|thumb|500px]]

Wie Eingangs erwähnt benötigt das System eine (bzw. zwei) Audio-Codecs. Im hier vorgestellten Schaltplan ist ein MSP430 enthalten der allerdings nur die Initialisierung und Konfiguration der Codecs übernimmt. Wer das System nachbauen möchte kann beliebige 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. Um das System zu Testen wird lediglich eine serielle Schnittstelle verwendet. Wer will kann aber genausogut den SPI-Modus verwenden und den DAP direkt von einem Mikrocontroller aus steuern. Ansonsten benötigt das System nur den Pin 13 des B1-Connectors. 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 Pin-Belegung des B1-Expansion Connectors:

Pin

*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

==ISE6.2 vs. ISE9.1==

Das Design wurde mit der ISE6.2 Version synthetisiert. Da ich auf eine neuere version umsteigen wollte, ergab sich das Problem das sich das Design nicht vollständig Routen lässt. Erst wenn bestimmte Teile des 6.2'er Designs rausgenommen werden (dazu zählen die Lese-Funktionen des Speichers, des Usage Registers, und die SRAM-Ansteuerung im Utility Kern) damit es sich auf der 9.1'er routen lässt. Nimmt man aber einen Größeren FPGA (XC3S400) so lassen sich auch diese Funktionen implementieren (was allerdings mangels passendem FPGA Board nicht getestet werden konnte).

* Download des DAP für ISE 6.2: [[Media:Dap Ise6.2.zip]]
* Download des DAP für ISE 9.1: [[Media:Dap Ise9.1.zip]]

==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 Source-Code einstellen, welche den DAP richtig nutzbar macht und 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 noch Leute zu finden um diesem Projekt noch mehr Leben und Möglichkeiten einhauchen zu können.

==Fotos==

Hier mal in paar Fotos (Gemacht mit meiner unscharfen Handy-Kamera :-x) der Hardware.

Spartan3 Board und Expansion Board
 

[[Bild:Gesamt.jpg|thumb|300px|left]]

 
Expansion Board

[[Bild:exp-board1.jpg|thumb|300px|left]]

 

==Audio Demos==

Ein EQ-Demo mit Rosa Rauschen. Klingt wie eine Meeresbrandung.
Es wurde nur ein Rosa Rauschen auf den Eingang gegeben und das EQ-Demo gestartet. Dann auf "MoveIt!" klicken und é voilá ...

[[Media:eq_demo1.zip]]

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

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

==In Kürze ...==

... werde ich noch eine kleine Erweiterung des DAP einbauen, die es erlaubt die Codecs vom PC aus zu konfigurieren. Dadurch entfällt der uC, und ich hoffe dadurch mehr Leute zum ausprobieren dieses Projekts zu bringen.
 

... werde ich eine neue 9.1'er ISE Version uploaden die dann alle Features der 6.2'er ISE Version enthält.
 

==Diskussion==

http://www.mikrocontroller.net/topic/65205

http://www.mikrocontroller.net/forum/read-9-238211.html

[[Kategorie:Projekte]] [[Kategorie:Audio]] [[Category:FPGA und Co]]

Datei:Dap delay demo.zip

2007-03-29T18:49:56Z

TheMason: