Notiezen und Information zu dem Entwiklungsstatus

Dies sind die Notizen zum aktuellen Stand der Umsetzung von IIR-Biquad-Filtern auf dem PYNQ-Z2.
Die Jupyter-Notebooks befinden sich im Verzeichnis jupyter.
Wichtig: Es kann sein, dass die Notebooks nicht vollständig in git angezeigt werden! Beim Öffnen mit einem externen Programm (z.B. VSCode) wird das gesammte Notebook angezeigt.

Stand : 09.06.2025

Filter:

Der derzeit implementierte Filter dient als funktionsfähiger Platzhalter. Es handelt sich um ein Butterworth-Hochpassfilter mit einer Grenzfrequenz von 1 kHz und einer Abtastrate von 48 kHz, abgestimmt auf den im PYNQ-Z2 integrierten Audiocodec ADAU1761.
Der Filter wurde mithilfe des HDL-Coders aus einem MATLAB/Simulink-Modell generiert und als IP-Core umgesetzt, um eine nahtlose Integration in Vivado zu ermöglichen.

JupiterNotebooks:

Filter_TransmissionTest/Matlab_Filter_Test_TransmissionTest_v2|v5

Diese beiden Notebooks dokumentieren die ersten erfolgreichen Versuche, zunächst simulierte Signale und anschließend beide Kanäle einer .wav-Datei zu filtern. Die Signale wurden dabei als np.array per DMA (Direct Memory Access) an den Filter übertragen, verarbeitet und anschließend wieder ausgegeben.
Vor der Übertragung werden die Arrays in Pakete von jeweils 262144 Elementen aufgeteilt. Diese Paketgröße entspricht der Größe des Output-Buffers der Filter-IP. Durch die automatische Paketaufteilung lassen sich auch Daten beliebiger Länge problemlos übertragen.
Der Ein- und Ausgangsbuffer des DMA wurde vorsorglich auf den Maximalwert von 67108864 gesetzt.

Beim Erstellen der DMA-Buffer in Python werden diese mit undefinierten Werten befüllt, die intern als NaN (Not a Number) oder nicht-initialisierte Daten erscheinen können. Beim Anzeigen per print() wirken sie zwar wie Nullen, enthalten aber tatsächlich keine gültigen, interpretierten Werte.
Wenn der Buffer größer ist als die tatsächlich zu übertragenden Daten und nicht vollständig mit gültigen Werten überschrieben wird, bleiben diese ungültigen Inhalte im Speicher. Werden diese vom DMA übertragen, kann dies zu internen Fehlerzuständen führen, wodurch der DMA blockiert wird und weitere Übertragungen nicht mehr möglich sind.
Um dennoch mit großen DMA-Frames arbeiten zu können, müssen die Buffer vollständig mit gültigen Daten gefüllt werden.

Lösung: Vor der Übertragung wird der gesamte Buffer initial mit Nullen befüllt (Padding). Anschließend werden die tatsächlichen Nutzdaten am Anfang des Buffers überschrieben. Dadurch enthält der komplette Buffer gültige, wohldefinierte Werte, was dem DMA eine fehlerfreie Übertragung ermöglicht.

Audio_Filter_Test_v2/Codec_Test_v6

Dieses Notebook ist eine erweiterung der Vorherigen. Das hier verwendete Design basiert vollständig auf dem des base.bit welches vom Pynq Github Repo stammt und auch in den Beispielen aus der Docs » PYNQ Libraries » Audio angewand wird. Dabei wurde praktisch nur der für den ADAU1761 Audio-Codec erstellte Teil des Designs übernommen.

Blockdiagramm_Referenz

Hinzugefügt wurde der im Vorheriegen Notebook erstellte Filter und DMA, um vom Board aufgenommende Audio direkt Filtern zu können.

Blockdiagramm_Referenz

Die angewanden Funktionen stammen aus dem pynq.lib.audio Module.

Bekannte Probleme:

Die Auswahl des Audio-Eingangs ist nicht immer zuverlässig und muss teilweise mehrfach durchgeführt werden.
Der Python-Kernel stürzt bei größeren Datensätzen regelmäßig ab, wodurch die Verbindung zum Board verloren geht. → Die Abstürze treten scheinbar zufällig auf und folgen keinem erkennbaren Muster. Ein Hardreset ist anschließend erforderlich.
Beim Laden eines neuen Overlays wird dieses nicht immer korrekt übernommen: das vorherige Overlay wird manchmal nicht überschrieben. → Auch hier ist ein Hardreset notwendig.
Aufnahmen bei höherer Lautstärke können Störgeräusche oder Rückkopplungen verursachen.
Aufgenommene Audiodateien sind im Vergleich zur Ausgabe über das Board deutlich leiser.
Ausgabe rauscht, potenzielle Folge vom Filtertyp oder der Umrechnung vor dem Filtern

Echtzeitfiltrierung

Probleme mit Echtzeit

Ausgangslage

Um das I2S Signal Echtzeitfiltern zu können, muss der Filter zwischen dieses Signal gesetzt werden. In Vivado gibt es I2S Receiver/Transmitter Ip-Cores welche ein I2S Signal annehmen können und als AXI4-Stream ausgeben können und andersrum mit dem Transmitter. Der Filter kann als AXI4-Stream fähiger IP-Core in Matlab erstellt werden und wurde so auch bisher verwendet. Daher könnte der Filter über die I2S Receiver/Transmitter Blöcke an den I2S-Stream angebunden werden.

Problem mit I2S Receiver/Transmitter

Der Audio_Codec_Contrtoller Block ist ein vorgefertigter IP-Core aus dem Pynq Github Repo welcher bei der I2S Übertragung als Master funktioniert und damit bclk, lrclk und codec_addr vorgibt.
Das Problem mit den I2S Receiver/Transmitter Ip-Cores ist, dass diese in dieser Konfiguration als Slave arbeiten müssten. Die Funktion wird aber nicht unterstützt. Bedeutet das die IP-Cores nur als Master Arbeiten können. I2S Transmitter and I2S Receiver LogiCORE IP Product Guide
Also muss entweder eine andere IP mit Unterstützung als Slave her oder dies muss eigens entwickelt werden.
Alternativ könnte auch der Filter IP-Core so umgestaltet werden, dass dieser ein Eingangs I2S-Streams akzeptiert. Dadurch würde sie aber die voraussichtlich die Unterstützung von AXI4-Stream verlieren, wodurch diese auch nicht länger für Digitale Audioquellen wie .wav verwendet werden könnten, weshalb derselbe Filter zweimal erstellt werden mussen.
Es gibt eine Möglichkeit die I2S Receiver/Transmitter von Master in Slave umzuändern laut dieser Quelle: Audio Processing with the Snickerdoodle. Anderes Board aber änhliche SoC. Leider gelang es mir bisher nicht diese erfolgreich anzuwenden.

Takt-Daten-Desynchronisation bei Slave-Slave-Betrieb

Wenn Receiver und Transmitter beide Slave sind, verwenden sie bclk und lrclk vom codec_ctrl_0
Das Problem ist: Der i2s_receiver_0 wandelt das serielle Signal sdata_i in AXI-Wörter (z.B. 24 Bit). Diese passieren eine Verarbeitung, z.B. dein Filter. Danach gibt i2s_transmitter_0 sie zurück, synchron zu alten Taktsignalen (bclk, lrclk)
- Die Daten sind nun potenziell verzögert, und stimmen nicht mehr zur aktuellen lrclk/bclk-Phase.

Master-Transmitter bricht den Systemtakt

Wenn ich den Transmitter als Master einstelle, erzeugt er eigene bclk und lrclk. Damit erzeugt er ein I²S-Signal mit eigenem Timing, und der audio_codec_ctrl_0 (und damit der Codec) müssten nun als Slave arbeiten.
- Der Controller ist als Takt-Master hart konfiguriert, also: Kann bclk/lrclk nicht extern empfangen, sondern erzeugt sie.

Gleichzeitige Audio-Wiedergabe und -Ausgabe

In dem Pynq-Z2 ist ein ADAU1761 Audio-Codec verbaut. In dem Datenblatt wird nicht expleziet erwähnt ob eine gelcihzeitige Aufnahme und Wiedergabe möglich ist, technisch währe es aber. Wenn die Funktionen aus dem pynq.lib.audio Module verwendet werden wird, ist es nicht möglich. Sobald eine Aufnahme .record(Time) gestart wird, wird die Ausgabe .play() blockiert bis die Aufnahme vollendet ist.
Mit dem Base-Design, sowie auch diesem hier, ist so direckt die gleichzeitige aufnahme und wiedergabe nicht möglich.

Alternative Design Möglichkeiten

Es gibt andere Projekte welche es ermöglichen gelichzeitig Audio Aufzunehmen und Widerzugeben. Inwieweit diese hier verwendet werden können muss noch weiter unteruscht werden.
Hier eine Liste von Projekten die bereits ausprobiert wurden:

Pynq_Z2-Audio
Audio Processing with the Snickerdoodle
pynq-audio
Pynq-Z2-Audio-Video-Pipelines

Stand : 11.06.2025

Filter:

Zwei neue Filter wurden entworfen und jeweils in Kombination mit einer eigenen AXI-DMA implementiert. Die Filterdesigns basieren auf dem MATLAB Filter Designer, wobei die entsprechenden Koeffizienten ins Workspace exportiert wurden: - Hochpass: Butterworth, 4. Ordnung, FC: 2500 Hz - Tiefpass: Butterworth, 4. Ordnung, FC: 1000 Hz

Das Simulink-Modell (biquad_Filter_v7_IP) wurde entsprechend angepasst: Die Gain-Faktoren (g) werden nun direkt in die Numerator-Koeffizienten integriert. Da der MATLAB Filter Designer für jeden Biquad-Block einen eigenen Gain-Wert erzeugt, liegen nun entsprechend mehr Gain-Faktoren vor.

Diese Änderung wurde vorgenommen, da beim Tiefpassfilter die nachträgliche Anwendung des Gains dazu führte, dass die Werte zu klein wurden. Aufgrund des 32_16 Fixed-Point-Formats im Simulink-Modell kam es dadurch zu Rundungsfehlern bzw. zum Wegfallen relevanter Werte. Durch das Vorab-Einrechnen der Gains in die Numerator-Koeffizienten wird dieses Problem vermieden, ohne dass sich das Filterverhalten ändert.

Vivado Design:

Im Zuge der neuen Filter wurde auch das Design in Vivado angepasst. Als Grundlage diente das überarbeitete Referenzdesign v2, das eine angepasste Takterzeugung für den Audio-Codec beinhaltet. Jeder der beiden Filter erhält eine eigene AXI-DMA-Schnittstelle, wobei beide Schnittstellen identisch konfiguriert wurden.

Beim ersten Versuch der Bitstream-Generierung trat ein Synthese-Fehler auf. Nach erneutem Ausführen des Generierungsprozesses konnte der Bitstream jedoch erfolgreich erstellt werden. Ein solches Verhalten wurde bereits in der Vergangenheit bei größeren Designs beobachtet und hatte bislang keine Auswirkungen auf die Funktionalität des erzeugten Bitstreams.

Die Timings im Design wurden erfolgreiuch eingehalten.

JupiterNotebooks:

Audio_duo_Filter_v1

Das Notebook basiert auf einer früheren Version und unterscheidet sich hauptsächlich in der Anzahl der implementierten Filter. Es wurde dahingehend erweitert, dass einer der beiden Filter zur Laufzeit ausgewählt werden kann. Das Notebook diente zur Überprüfung der Funktionalität des Designs – der Test verlief erfolgreich, die korrekte Funktion konnte bestätigt werden.

Stand : 12.06.2025

JupiterNotebooks:

Audio_duo_Filter_v2

Aktualisierte Version von Audio_duo_Filter_v1.
Erweitert wurde das Projekt um eine Dokumentation der verwendeten Funktionen, sowohl der Pynq-eigenen als auch der selbst entwickelten.
Zudem wurde die Filterverarbeitung von 16-Bit auf vollständige 24-Bit erweitert.
Zur Überprüfung wurden die Phasenantworten des Hochpass- (HP) und Tiefpassfilters (TP) analysiert.

Audio_duo_Filter_v3

Die Funktionen wurden in eine separate Python-Datei (my_Overlay.py) ausgelagert, um die Übersichtlichkeit des Notebooks zu verbessern. Zusätzlich wurde eine neue Funktion integriert, die den gesamten Filterprozess, einschließlich Übertragung, Einlesen, Speichern sowie Filterauswahl, in einem einzigen Aufruf zusammenfasst.
Alle bisherigen Funktionen bleiben unverändert und funktionieren weiterhin wie zuvor.

Bemerkungen:

Die Audioaufnahme über das Board ist nicht immer fehlerfrei.
In seltenen Fällen tritt bei der Filterung ein Problem auf, bei dem starke Frequenzspitzen im Bereich von 10–20 kHz entstehen. Die Ursache dafür ist bislang unbekannt: beobachtet wurde dieses Verhalten bisher nur einmal beim Tiefpassfilter.
Die Filterwirkung des Hochpassfilters bei einer Grenzfrequenz von 2500 Hz ist unbefriedigend, es werden zu viele Frequenzanteile abgeschnitten, was zu einem unsauberen Klang führen kann.
Beim Einsatz von Python-Bibliotheken wie matplotlib kommt es bei längeren Aufnahmen zu Instabilitäten im Python-Kernel. Eine Auslagerung der Auswertungen in ein separates Notebook ist daher geplant.

Stand : 13.06.2025

JupiterNotebooks:

Lerndemo_v1_Audio

Neues Notebook sowie eine aktualisierte Version von my_Overlay_v2.py mit erweiterten Funktionen für grafische Darstellung der Ergebnisse. - Enthält eine Funktion zur Darstellung eines einfachen Frequenzspektrums beider Audiokanäle auf Basis einer FFT. - Zusätzlich wurde eine Funktion integriert, die die Audiodaten im Zeitbereich visualisiert.

Bemerkungen:

Die maximale Aufnahmezeit beträgt 60 Sekunden und ist durch den Audio-Codec-Treiber begrenzt.
Die Ursache für Instabilitäten liegt vermutlich in einer Speicherüberlastung, bedingt durch die maximale Aufnahmezeit in Kombination mit zahlreichen geladenen Bibliotheken und Plot-Ausgaben, die gemeinsam den RAM überfüllen.
Eine empfohlene Aufnahmezeit von 30 Sekunden hat die Stabilität deutlich verbessert und auch die allgemeine Verarbeitungszeit des Notebooks reduziert.

Stand : 17.06.2025

Echtzeitfiltrierung 2

Analyse zur Anbindung des I2S RX/TX

Es ist gelungen, die LogiCORE I2S Transmitter (TX) und Receiver (RX) IPs gemäß dem Product Guide PG308 korrekt in den I2S-Audiostream des Audio-Codecs einzubinden.
Entgegen der offiziellen Dokumentation, die den Slave-Modus nicht unterstützt, konnten sowohl RX als auch TX im Slave-Modus betrieben werden, indem innerhalb von Vivado entsprechende Block-Property-Einstellungen vorgenommen wurden. Der Audio-Codec-Controller agiert dabei als Master für bclk und lrclk.
Die Initialisierung der RX/TX-IPs erfolgte aus einem Jupyter Notebook, indem spezifische Registeradressen gemäß dem Datenblatt gesetzt wurden. Der RX erhielt dabei Samplerate und Enable, beim TX reichte das Setzen des Enable-Registers.

Funktionstest & Filtereinbindung

Zunächst wurde eine direkte Verbindung zwischen RX und TX über AXI-Stream hergestellt, was zu korrekter Audioausgabe führte, unabhängig davon, ob RX/TX vor oder nach dem Codec-Controller eingebunden wurden.
Als nächstes wurde der eigene Biquad-Filter-IP zwischen RX und TX eingefügt. Ab diesem Punkt war die Audioausgabe zwar noch vorhanden, jedoch kaum hörbar und scheinbar ungefiltert. Die eigene Biquad-Filter-IP nutzt dabei den fertigen Biquad Filter aus DSP HDL Toolbox / Filtering in Matlab.
Um den Fehler einzugrenzen, wurde eine neue, vereinfachte IP mit HDL Coder in Simulink erstellt, ein reiner Bypass ohne jegliche Filterlogik. Dennoch blieb die Ausgabe gleich leise. Dies deutet darauf hin, dass der Filter selbst nicht Ursache des Problems ist.

Weitere Tests

Verschiedene Datenformate wurden getestet: int32, uint32, ufix inkl. Shifts und Gains – ohne nennenswerte Wirkung.
Ein Gain-Block in der IP änderte die Lautstärke nicht.
Ein AXI4-Stream Data FIFO zwischen RX und TX hingegen führte zu normaler Lautstärke – auch ohne Verarbeitung.
Eine eigene IP als Bypass und gleicher Puffergröße wie der FIFO führte nicht zum selben Ergebnis: Der Fehler liegt nicht nur an der Puffergröße.

Vermutete Ursache

Die durch HDL Coder erzeugte AXI-Stream-Implementierung scheint in ihrer minimalen Version (TVALID, TDATA, generiertes TREADY) nicht alle Timing- oder Handshakebedingungen zu erfüllen, wie sie vom TX erwartet werden.
Das optionale Signal TID[2:0], das bei RX und TX zur Unterscheidung der Kanäle dient, wird von der eigenen IP nicht verarbeitet. Auch das externe Durchreichen von TID brachte keine Verbesserung.
Da die Filter-IP in Kombination mit AXI-DMA korrekt funktioniert, liegt das Problem wahrscheinlich in der AXI-Kommunikation, nicht im Filter selbst.

Fazit der Echtzeitfiltrierung

Die Umsetzung der Audio-Echtzeitverarbeitung , zeigte deutliche Einschränkungen. Zwar funktionierten der I2S Receiver und Transmitter einwandfrei in einer Direktverbindung, doch beim Einschleifen der eigenen IP kam es unabhängig von Datentyp oder Filterlogik zu einem stark gedämpften Ausgangssignal. Auch bei Verwendung eines einfachen Bypasses ohne jegliche Verarbeitung blieb das Signal zu leise, ein Hinweis darauf, dass nicht die Filterimplementierung, sondern die AXI-Stream-Schnittstelle der IP selbst das Problem darstellt.
Um das Verhalten korrekt umzusetzen, wäre eine vollwertige, AXI-konforme Implementierung nötig, inklusive Pufferung, Signalweiterleitung und detaillierter Kontrolle über die Handshake-Logik.
Die Erstellung einer solchen IP erfordert jedoch fortgeschrittene Kenntnisse im AXI-Protokoll sowie zusätzliche manuelle Anpassungen, die über die Möglichkeiten der automatisierten HDL-Generierung hinausgehen.
Da der Schwerpunkt auf der Implementierung des Filters liegt und nicht auf der Low-Level-AXI-Implementierung, wurde entschieden, für weitere Tests und Anwendungen den bewährten Weg über AXI DMA zu nutzen.

Stand : 23.06.2025

Dokumentation

Es wurde mit der Dokumentation der verwendeten Hard- und Software begonnen. Relevante Informationen dazu wurden aus geeigneten Quellen recherchiert, gesammelt und nachvollziehbar festgehalten.
Die Dokumentation des Filterdesigns und dessen Implementierung wurde ebenfalls begonnen. Dabei wird das strukturierte Vorgehen einschließlich der gewählten Einstellungen und Werkzeuge detailliert beschrieben..

Filterdesign

Alle vier Basisfilter wurden gemeinsam in einem Overlay implementiert, wobei das Design im weiteren Verlauf noch angepasst werden kann. Ursprünglich bestand jeder Filter aus zwei kaskadierten Biquads; diese wurden vorerst auf jeweils einen Biquad reduziert. Statt der zuvor verwendeten Direct Form II Struktur kommt nun die transponierte Direct Form II zum Einsatz, da diese sich besser für Hardwareimplementierungen eignet.
Zudem wurde die Größe des Output-Buffers der Filter-IP von 2^18 auf 2^16 Werte reduziert. Durch die kleinere Puffergröße wird eine verbesserte Stabilität und geringere Latenz im Jupyter Notebook erwartet.

Stand : 26.06.2025

Filterdesign und Notebooks

Beim Reduzieren der Outputpuffergröße der Filter-IP von 2^18 auf 2^16 wurde ein ungewöhnliches Verhalten bei der Filterung festgestellt.
Die Lautstärke des Ausgangssignals zeigte sich nach der Filterung inkonsistent und veränderte sich auf unvorhersehbare Weise.
Besonders auffällig war, dass sich bei der Aufnahme über das Mikrofon das Hintergrundrauschen in Sprechpausen mit jeder weiteren Pause zunehmend aufschaukelte. Dieses Verhalten trat bei allen vier implementierten Filtern gleichermaßen auf.

Das beobachtete Verhalten lässt sich auf das Einschwingverhalten von IIR-Filtern zurückführen. IIR-Filter besitzen eine rekursive Struktur, bei der die Filterausgabe nicht nur vom aktuellen Eingangswert, sondern auch von früheren Eingangs- und Ausgangswerten abhängt. Diese Rückkopplung führt zu einem typischen Einschwingen beim Start einer neuen Filterung.
In der praktischen Umsetzung wurde die Audioaufnahme durch die begrenzte Puffergröße der Filter-IP in mehrere kleine Datenblöcke unterteilt. Dadurch wurde der Filter mehrfach separat auf jeweils kurze Abschnitte angewendet, ohne Zustandsübernahme zwischen den Blöcken. Für jeden dieser Blöcke musste sich der Filter erneut einschwingen.
Dieses wiederholte Einschwingen in kurzen Abständen kann dazu führen, dass numerische Restwerte oder Quantisierungsrauschen im Signal verstärkt werden. In der konkreten Anwendung führte das dazu, dass bei jedem neuen “stillen” Segment das Hintergrundrauschen zunehmend stärker hervortrat.
Das ständige Einschwingen bei blockweiser Verarbeitung erklärt somit auch das inkonsistente Lautstärkeverhalten bei der Filterung.

Durch das Erhöhen der Outputpuffergröße der Filter-IP auf 2^20 wird das Eingangssignal nun in deutlich weniger Datenpakete aufgeteilt. Dadurch muss der Filter seltener neu ansetzen, was wiederum dazu führt, dass das Einschwingen weniger häufig auftritt und in der gefilterten Ausgabe weniger stark wahrnehmbar ist.
Da die Größe des Ausgangspuffers hardwareseitig begrenzt ist, lässt sich die Paketaufteilung nicht vollständig vermeiden. Um das Einschwingverhalten vollständig zu kontrollieren oder zu eliminieren, müsste der Filter grundlegend anders implementiert werden – beispielsweise durch eine Struktur mit Zustandspersistenz zwischen den Übertragungsblöcken oder durch eine Streaming-Architektur ohne harte Blockgrenzen.

Potentielles Problem bei der Echtzeitfilterung

Ein möglicher Grund, warum die Echtzeitfilterung derzeit nicht funktioniert, könnte ebenfalls mit dem Einschwingverhalten des IIR-Filters zusammenhängen. Bisher wurde die Filter-IP so betrieben, dass sie in Blöcken über den DMA angesteuert wurde, d. h. jedes Filtersegment begann und endete kontrolliert mit einem Datenpaket.
In einer Echtzeitanwendung hingegen liefert der I2S Receiver (RX) einen kontinuierlichen Datenstrom über AXI4-Stream, ohne klar abgegrenzte Blockstruktur. Wenn der Filter jedoch jedes eingehende Sample oder Bit wie den Beginn einer neuen Filterung interpretiert, also jedes Mal erneut einschwingt führ das dazu, dass der Filter bei jedem einzelnen Bit erneut mit seiner Einschwingphase beginnt. Dadurch wird das Ausgangsignal an den I2S Transmitter weitergeben bevor der Filter stabil arbeiten konnte.
Besonders am Anfang ist das Filterverhalten stark gedämpft oder verzerrt. Diese anfänglich starke Dämpfung die bisher beobachtet wurde war konstant und könnte daher so erkläert werden.

Jedoch wurde die Filter IP auch im reinen Bypass-Modus getestet, also ohne aktive Filterfunktion. Dabei zeigte sich, dass das gleiche stark dämpfende Verhalten wie im regulären Filterbetrieb auftrat. Dies spricht deutlich gegen die Annahme, dass das Einschwingen des Filters die Ursache des Problems ist.
Der Test diente gezielt dazu, den Filter selbst als Fehlerquelle auszuschließen.
Auch wenn das Einschwingverhalten nicht die direkte Ursache für das aktuelle Problem zu sein scheint, sollte es in der weiteren Entwicklung der Echtzeitfilterung als potenzielle Fehlerquelle im Blick behalten werden, insbesondere, falls in Zukunft Fortschritte in diesem Bereich erzielt werden.

Noch offene Punkte:

❌ Finales Design mit Audiofilterung und Einlesen digitaler Audiodateien (.wav)
❌ Dokumentation zu: DSP, IIR-Filter, Biquad-Strukturen, ~~Matlab HDL-Coder~~ + Simulink, ~~Vivado~~, ~~IP-Cores~~, ~~I2S~~, (I2C), ~~Pynq und Pynq-Z2 Board~~, finales Notebook + Funktionen
❌ ~~Umrechnung der Samplerate für externe .wav-Datein (44.1 -> 48kHz)~~
❌ Schematische Beschreibung der Funktionsweise der Filter IP anhand eines Beispieles
❌ Aufräumen des Git Reposetories

Bereits erledigt:

✅ Design eines digitalen IIR-Biquad-Filters mit Fixpunktkonvertierung der Koeffi- zienten für den FPGA.
✅ Erstellung und Einbindung des Filters als AXI-fähiger IP-Block in Vivado 2022.1
✅ Erstes Design mit Zynq-Processing-System und DMA-Block (Direct Memory Access) für das erste Filtern simulierter Werte.
✅✅/❌ JupiterNotebooks für Demonstration
✅✅/❌ Skript zur Steuerung des Filters auf PYNQ.
✅✅✅✅ Realesierung der 4 Basisfilter (HP, TP, BS, BP)
✅ Erstes Design einer Lerndemonstration mit Visualisierung der Signalverarbeitung.
✅ Dokumentation zu: AXI, I2S, Matlab HDL-Coder, Vivado, IP-Cores, Pynq und Pynq-Z2 Board

Zusatz:

❔Vergleich Filtertypen und Ordnung (Ellip, Butter, Chebyshev)
❔Design für die Echtzeit-Audiofilterung mit Audiocodec über I2S