mikrocontroller.net

Forum: FPGA, VHDL & Co. Hilfe zu Implementierung von I2S Interface in VHDL


Autor: Waldi3141 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen :=)

Bin kürzlich neu eingestiegen mit dem Konfigurieren von FPGAs in VHDL.
Mein Einsteigerboard: Arty - Artix 7 -xc7a35tcsg324-1
Entwicklungsumgebung: Vivado 2016.4

Nun habe ich einige Einsteigerkurse(Video und Lehrbuch) durchgearbeitet 
und sitze momentan fest.
Mein Ziel ist es das Mikrofon ADMP441 mit der I2S Schnittstelle 
auszulesen, finde aber keinen richtigen Einstieg/Ansatz dafür.

Eine Datenverbindung vom Board zum PC via Ethernet konnte ich bereits 
mit dem Code von Hamsterworks aufbauen.

Versuche:
Habe die Takte WS und SCK erzeugt und an 2 Ausgänge geschaltet. 
Oszilloskop zeigt Rauschen auf +2V Offset an.

Falls einer mal was in der Richtung I2S und FPGA in VHDL gemacht hat, 
würde mich sehr über Tipps freuen :)

Habe zwar Code zu I2S auf Opencores und anderen Seiten gefunden, aber 
konnte nicht viel damit anfangen.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Waldi3141 schrieb:
> Habe die Takte WS und SCK erzeugt und an 2 Ausgänge geschaltet.
> Oszilloskop zeigt Rauschen auf +2V Offset an.
Du misst offenbar einen offenen CMOS-Eingang. Kannst du diese 2V mit 
einem 10k Widerstand auf GND oder 3V3 ziehen?

Falls ja, dann hat vermutlich was mit der Pinzuordnung nicht geklappt.

: Bearbeitet durch Moderator
Autor: Waldi3141 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI , danke für die Antwort,

In Vivado habe ich mit dem Clock Wizard testweise ein 50 MHz Clock 
erzeugt und einfach an PIN U12 Header JC geschaltet mittels 
Constraint-File.

Dieses Rauschen ist tatsächlich eine Sinusschwingung mit +2V offset. 
Habe das jetzt getestet, nein ich kann dieses Signal (was eigentlich 50 
MHz sein sollten) nicht mit einem 10K Widerstand auf GND noch auf VCC 
ziehen.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Waldi3141 schrieb:
> Dieses Rauschen ist tatsächlich eine Sinusschwingung mit +2V offset.
Zeig mal ein Bild davon.
BTW: welche analoge Bandbreite hat denn dein Oszi?
Denn zum halbwegs rechteckigen Darstellen eines rechteckigen 50MHz 
Signals brauchst du mindestens 350MHz analoge Bandbreite und eine 
entsprechend schnelle Abtastung...

: Bearbeitet durch Moderator
Autor: Waldi3141 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
100MHz - Bandbreite

Dazu sei gesagt,  dass ich auch versucht habe immer geringere Output 
Clocks zu erzeugen und ab 3Mhz wurde das signal langsam zum Taktsignal 
(also rechteckig)

Siehe Bild zum 50Mhz Takt

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Waldi3141 schrieb:
> 100MHz - Bandbreite
Bei einer x1 Probe. Da sieht das Signal doch noch ganz gut aus.

> Dazu sei gesagt,  dass ich auch versucht habe immer geringere Output
> Clocks zu erzeugen und ab 3Mhz wurde das signal langsam zum Taktsignal
> (also rechteckig)
Nimm mal x10 Tastköpfe, du belastet den Pin mit den x1 Probes kapazitiv 
ziemlich stark...

> Siehe Bild
Ähm, das Ding kann doch Screenshots, oder nicht?

Autor: Waldi3141 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Nimm mal x10 Tastköpfe, du belastet den Pin mit den x1 Probes kapazitiv
ziemlich stark...
Ich habe jetzt mal ein 6,144 MHZ Takt mit dem Clock Wizard erzeugt
Bild 1 mit 1x Tastkopf , Bild 2 mit 10x

sieht eigentlich, besser aus :)... aber weiß nicht ob die Rundungen 
jetzt am FPGA-Board liegen oder ich meinem Oszi nicht mehr trauen darf 
:S


>Ähm, das Ding kann doch Screenshots, oder nicht?
Doch das kann auch Screenshots aber habe gerade kein USB Stick zur Hand.

Autor: Waldi3141 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Waldi3141 schrieb:
> Bild 1 mit 1x Tastkopf , Bild 2 mit 10x -> 20170213_162321.jpg

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seite 9 im Datenblatt zeigt doch sehr schön wie man die Samplewerte aus 
dem Stein herausbekommt. Das lässt sich auch prima simulieren.

Autor: Waldi3141 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:D ich bedanke mich jetzt erst mal,
verstehe nicht warum ich vorher ein viel stärkeres Rauschen hatte, auch 
bei niedrigeren Frequenzen, aber die Taktraten 3,072 Mhz und 48KHz sehen 
jetzt zumindest gut aus. Auch bei x1 Tastkopf

Autor: Stefan K. (sdwarfs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Waldi3141 schrieb:
> :D ich bedanke mich jetzt erst mal,
> verstehe nicht warum ich vorher ein viel stärkeres Rauschen hatte, auch
> bei niedrigeren Frequenzen, aber die Taktraten 3,072 Mhz und 48KHz sehen
> jetzt zumindest gut aus. Auch bei x1 Tastkopf

Ich habe festgestellt, dass bei meiner FPGA IDE (Quartus II) manchmal 
doppeltes Compilieren/Synthetisieren nötig war, bis das das Ergebnis 
gestimmt hat.

Ich habe da verschiedene Vermutungen, die aber nicht stimmen müssen. 
Evtl. liegt evtl. darin, in welcher Reihenfolge die VHDL-Dateien 
kompiliert werden, die aufeinander verweisen und dass bei der ersten 
Runde ggf. alte Versionen von Komponenten landen die in Dateien 
referenziert werden, die kompiliert werden, bevor diese Komponenten mit 
dem Kompilieren dran sind. Ein Grund dafür könnte auch sein, dass der 
Optimierer teilweise zufällig arbeitet und ein falsch optimiertes Timing 
zu einer Fehlfunktion führen kann - normalerweise sollte sowas aber nur 
externe Pins betreffen, falls man die Timing Constraints nicht oder 
nicht richtig konfiguriert hat.

Wie auch immer: Wenn was nicht funktioniert, wie man vermutet und es die 
Zeit erlaubt: am besten nochmal kompilieren und schauen, obs evtl. dann 
geht... sicher ist sicher!

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Das kenne ich so aber nicht. Ist das bei den neueren Versionen so? So 
ein Verhalten (Nutzung von altem Müll) kannte ich bisher nur von den 
früheren ISE-Versionen. Dort musste man regelmässig die files löschen um 
Unfug zu verhindern.

Hat sich Altera da etwa angeglichen?

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Wie auch immer: Wenn was nicht funktioniert, wie man vermutet und es die
> Zeit erlaubt: am besten nochmal kompilieren und schauen, obs evtl. dann
> geht... sicher ist sicher!

Das kann ich so erstmal nicht glauben, es gibt aber ein aehnliches 
"Phaenomen". Zumindest bei Xilinx ist es so, dass der Random Seed fuer 
die Logik Platzierung ueber das Design berechnet wird. Bei gleichen 
Design gilt daher: gleicher Seed und damit ist auch das Resultat immer 
das gleiche.

Wenn ich jetzt jedoch kleine Aenderungen habe, z.B. Signalumbenennung, 
fuehrt das dazu, dass ein neuer Seed generiert wird und allen damit 
verbundenen Timing Konsequenzen.

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Wenn ich jetzt jedoch kleine Aenderungen habe, z.B. Signalumbenennung,
> fuehrt das dazu, dass ein neuer Seed generiert wird und allen damit
> verbundenen Timing Konsequenzen.

Das ist ja eigentlich logisch, bedingt aber nicht, dass damit einmal 
gute und einmal schlechte Ergebnisse erzielt werden und das scheint das 
Problem des TE zu sein.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. W. schrieb:
> Das ist ja eigentlich logisch, bedingt aber nicht, dass damit einmal
> gute und einmal schlechte Ergebnisse erzielt werden und das scheint das
> Problem des TE zu sein.

Der Punkt den ich Nahe legen wollte ist, dass es keine "guten" oder 
"schlechte" Ergebnisse gibt. Sondern nur "erfuellen meine Anforderungen" 
oder "erfuellen meine Anforderungen nicht".

Und wenn man das Gefuehl hat, es ist eine Art Voodoo im Spiel, dann hat 
meine Erfahrung bisher immer gezeigt, dass fehlende Timing Constraints 
das Problem sind und nicht-deterministisches Verhalten der Tools 
ausgeschlossen werden konnte.

Daher bricht die obige Fragestellung runter zu: "Anforderungen 
voellstaendig spezifiziert" oder "Anforderungen nicht vollstaendig 
spezifiziert". Die Tools koennen nunmal nur so gut Arbeiten, wie den 
Input den sie vom Anwender bekommen (auch wenn uns die Werbeversprechen 
der FPGA Hersteller manchmal was anderes weissmachen wollen).

: Bearbeitet durch User
Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Das sind aber mehrere unterschiedliche Dinge:

- Signal hinzufüegen -> Designänderung
- Neue Compiulation  -> Programmierfileänderung
- neuer Seed         -> neues Programmierfile
- Neue Anforderung   -> anderes Design
- anderes Constrain  -> anderes Ergebnis

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Bemerkung zur eigentlichen Fragestellung:

Waldi3141 schrieb:
> Falls einer mal was in der Richtung I2S und FPGA in VHDL gemacht hat,
> würde mich sehr über Tipps freuen :)
Falls das noch eoin Thema für jemanden ist, hätte ich da etwas.

> Habe zwar Code zu I2S auf Opencores und anderen Seiten gefunden, aber
> konnte nicht viel damit anfangen.
Was daran liegt, dass auch OC meistens Anfänger publizieren, die sich 
etwas ausdenken, es reinhäcken und dann undokumentiert und ungetestet 
die Welt mit buggy files versorgen, um schließlich wegzurennen und das 
Projekt aufzulassen.

Genau das also, was in der Industrie niemand gebrauchen kann.

Die Industrie meidet OC als Quelle von Cores wie der Teufel das 
Weihwasser.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. W. schrieb:

> Was daran liegt, dass auch OC meistens Anfänger publizieren,
Nein.

> es reinhäcken und dann undokumentiert und ungetestet
> die Welt mit buggy files versorgen, um schließlich wegzurennen und das
> Projekt aufzulassen.
Nein.

> Genau das also, was in der Industrie niemand gebrauchen kann.
Nein.

> Die Industrie meidet OC als Quelle von Cores wie der Teufel das
> Weihwasser.
Nein.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. W. schrieb:
> Was daran liegt, dass auch OC meistens Anfänger publizieren, die sich
> etwas ausdenken, es reinhäcken und dann undokumentiert und ungetestet
> die Welt mit buggy files versorgen, um schließlich wegzurennen und das
> Projekt aufzulassen.
Nunja, ich kann mich da dunkel an eine Appnote von Xilinx erinnern, wo 
das wohl ähnlich lief. Der Student/Praktikant war dann auch nicht mehr 
greifbar...

Duke

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
M. W. schrieb:
> Was daran liegt, dass auch OC meistens Anfänger publizieren, die sich
> etwas ausdenken, es reinhäcken und dann undokumentiert und ungetestet
> die Welt mit buggy files versorgen, um schließlich wegzurennen und das
> Projekt aufzulassen.
Ob es Anfänger sind, weiß ich nicht, aber "undokumentiert" ist 
weitgehend richtig.

> Die Industrie meidet OC als Quelle von Cores wie der Teufel das
> Weihwasser.
Was aber vor allem an rechtlichen Fragestellungen liegt.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Ich habe festgestellt, dass bei meiner FPGA IDE (Quartus II) manchmal
> doppeltes Compilieren/Synthetisieren nötig war, bis das das Ergebnis
> gestimmt hat.
Bevor man Vermutungen bezüglich eventueller Fehler anstellt, wäre die 
vorab zu stellende Frage, wie das denn festgestellt wurde, dass das 
"Ergebnis stimmt". Es kann auch gut sein, dass unterschiedliche 
Versionen mit der gleichen Funktion bei unterschiedlichem 
Compilationläufen deshalb anders arbeiten, weil es grundsätzliche 
Timingfehler gibt, die mal auftreten und mal nicht, weil die contraints 
zu schwach- oder nicht richtig gesetzt waren.

D.h. ein minimal anderes Timing an einem Ausgang oder Eingang führt zu 
irgendwelchen internen Fehlern. Das sieht dann durchaus soaus, als ob es 
ein Problem des grundsätlzichen Compilierens wäre. In Realität ist es 
nur ein Problem von zu vielen Freiheitsgraden.

Und diese Thema verschärft sich mit jedem Schritt hin zu einer 
abstrakteren Schaltungsunktionsbeschreibung, weil diese immer indirekter 
wird.

Autor: Burkhard K. (buks)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
>> Was daran liegt, dass auch OC meistens Anfänger publizieren,
> Nein.
>
>> es reinhäcken und dann undokumentiert und ungetestet
>> die Welt mit buggy files versorgen, um schließlich wegzurennen und das
>> Projekt aufzulassen.
> Nein.
>
>> Genau das also, was in der Industrie niemand gebrauchen kann.
> Nein.

Der I2C Controller Core von Herveille 
(https://opencores.org/projects/i2c) ist durchaus brauchbar, gut 
dokumentiert - und bei mir im Dauereinsatz (nachdem ich ihn vom nicht 
benötigten Wishbone-Overhead befreit habe).

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> M. W. schrieb:
>> Was daran liegt, dass auch OC meistens Anfänger publizieren, die sich
>> etwas ausdenken, es reinhäcken und dann undokumentiert und ungetestet
>> die Welt mit buggy files versorgen, um schließlich wegzurennen und das
>> Projekt aufzulassen.
> Ob es Anfänger sind, weiß ich nicht, aber "undokumentiert" ist
> weitgehend richtig.

"Weitgehend" ist genau das Stichwort, je nachdem was der "OC-Downloader" 
gerade in seiner Selbstgerechtigkeit als "gut dokumentiert" ansieht, ist 
jeder Core mehr oder weniger schlecht dokumentiert.
Aber abgesehen davon , das schon mal die Offenlegung des Quelltextes 
eine Art der Dokumentation ist, insbesonders wenn man die 
Dokumentiert-sich-Selbst Eigenschaft des geschwätzigen VHDL nutzt, sind 
die Interface der Obencores-Module -der Wishbone-Anteil- m.E. umfassend 
beschrieben.

Weil eben OpenCores mit der Spezifikation einer standardisierten 
Schnittstelle für alle Module begann. Aber ich befürchte, die wenigstens 
OC-Downloader haben dieses Dokument gesehen oder durchgearbeitet: 
https://cdn.opencores.org/downloads/wbspec_b4.pdf

Und die andere Seite der Schnittstelle I2S, I2C, DDR, etc. pp. ist auch 
dokumentiert, nur muss man sich eben die Mühe machen, die 
Standardbeschreibung ausfindig zu machen.

Hinzu kommt, das, egal wieviel "Papier" ein Zulieferteil von sich aus 
mitbringt, derjenige, der es in sein System integriert, diesen, seinen 
eigenen, Integrationsschritt (also welchen Funktionsumfang er nutzt, wo 
die Source-files abgelegt sind, wie die Funktion und Qualität der 
Integration getestet wurde, Testbench, Testcases, 
Entwicklungshistorie,..)" nachvollziehbar, konkret aber nicht 
ausschweifend beschreibt. Aber dazu kommt es auch eher selten, 
jedenfalls seltener als die Neignung bei jedem "geschenkten" Gaul 
erstmal kräftig schimpfend über das geistige Vermögen des Spenders 
herziehen. (Wohl aus einem Reflex des Feilschens heraus, wobei sich die 
Frage stellt, an welchen Preis man hier feilschen will - Monty Python 
lässt grüssen Youtube-Video "Basar Verhandlung "zehn für diese Flasche!?"" )

Da hat man das Konzept des "Open Source" meines Erachtens gründlich 
missverstanden. Open Source bedeutet nicht "Rundum sorglos Pakt", eher 
im Gegenteil.
"Offener Quelltext " sieht sich nicht als Fertigproduct wie 
"Freeware", sondern als "Werkzeug" das der User mach eigenen Vorgaben 
selbst benutzen kann, um das für ihn passende Produkt selbst zu bauen. 
Und Open Source schliesst den Gedanken ein, das der "Open Source" Autor 
(oder jemand anders der sich darin eingearbeitet hat) durch den Support 
also der Unterstützung des Kunden bei der Integration seinen Unterhalt 
verdient. Aber die Bereitschaft diese entgeltliche Zuarbeit überhaupt 
anzufragen, ist wohl eher nicht von "Downloadern" zu erwarten die 
pauschal loswettern, die Autoren wären unfähig, testen nix und rennen 
weg sobald sich Nachfragen ergeben könnten.

BTW:
IMHO ist eine Diskussion wie man bei der Integration von Fremdcores, 
bspw die von OC, sinnvollerweise vorgeht sehr wohl angebracht, aber das 
sprengt den Rahmen dieses I2S-Threads.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> IMHO ist eine Diskussion wie man bei der Integration von Fremdcores,
> bspw die von OC, sinnvollerweise vorgeht sehr wohl angebracht,
Bei mir gibt es jeweils pro Projekt ein Verzeichnis "contrib", wo 
Fremcode fein säuberlich sortiert aufbewahrt wird.
Da braucht man doch keine Diskussion dafür...

Duke

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burkhard K. schrieb:
> Der I2C Controller Core von Herveille

Ich denke, es ging hier um I2S, oder?

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. W. schrieb:
> Was daran liegt, dass auch OC meistens Anfänger publizieren, die sich
> etwas ausdenken, es reinhäcken und dann undokumentiert und ungetestet
> die Welt mit buggy files versorgen, um schließlich wegzurennen und das
> Projekt aufzulassen.
>

Mit etwas genau hingucken sollte eigentlich jeder die Spreu vom Weizen 
trennen können. Und sonst schreibt man die Autoren mal eben an.

> Genau das also, was in der Industrie niemand gebrauchen kann.
>
> Die Industrie meidet OC als Quelle von Cores wie der Teufel das
> Weihwasser.

Das kann ich nicht bestätigen. Es gibt einige sehr gute Cores auf OC. 
Und halt auch etwas Schrott, den kann man aber auch von namhaften Firmen 
geliefert kriegen. Als erstes steckt man das Zeug sowieso in den 
Simulator.

Was schlicht immer wieder - sogar von den grosse 
Drei-Buchstaben-Siliziumhirschen missverstanden wird: Opensource heisst 
nicht: Kostenlos.

Viele Opensource-Provider ziehen sich irgendwann auch einfach zurück, 
weil sie nicht Lust haben, der 20-ten "ich hätte gern kostenlosen 
Support" -Anfrage nachzugeben, oder sich bei einer klaren 
Aufwandsabschätzung (wenn sich der kommerzielle Hintergrund des 
Fragestellers erst mal offenbart) anmaulen zu lassen: "Aber das ist doch 
Opensource!".

Zum Thema I2S: Wo steckt genau das Problem? Wir wollen ja gerne helfen, 
aber ich zumindest würde vorher auch gerne eine Simulation/Modell oder 
wenigstenz Block-Konzept sehen. Wenn du gute Doku zu I2S-Betriebsarten 
suchst, schau dir mal z.B. die Blackfin BF537-Hardware-Referenz an. So 
einen Core nachzustricken ist keine Riesen-Arbeit (BTDT), mal von der 
DMA-Geschichte abgesehen.

P.S. Beim Blackfin heisst das Ding 'SPORT'.

: Bearbeitet durch User
Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Blackfin BF537-Hardware-Referenz an. So
> einen Core nachzustricken ist keine Riesen-Arbeit (BTDT), mal von der
> DMA-Geschichte abgesehen
DMA und die Vermittlung der Datenpakete ist aber doch das Thema bei 
der Verwendung von Mikrocontrollern und DSPs wie dem blackfin, weil 
diese noch andere Dinge tun müssen und viel davon zeitkritisch ist. Das 
bläht die Anwendung auf und führt nicht selten zu hektischem 
Interruptgefummel, wenn der DSP nicht ein I2S fest eingebaut hat.

Deshalb schiebt man ja das lolevel-Gedöhns nicht umsonst in einen 
digitalen Baustein. I2S im FPGA sollte kein Problem sein. Mehr, als ein 
paar Zähler und Schieberegister sind es nicht. Die Probleme liegen 
meistens im Verständnis des Datenformats und der richtigen 
Interpretation der Verschiebung beim z.B. dem LJ-Mode.

Habe mir den Code von Drange auf open Cores mal angesehen: Das meiste 
davon ist wishbone-Interface und zum Ankoppeln an z.B. SOC-Systeme 
gedacht. Das mag nutzvoll sein für Leute, die unsbedingt mit DSPs 
arbeiten wollen und nur Software können, aber bei einer harten 
Verarbeitung der Daten ist das alles overhead und kann weggelassen 
werden.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> DMA und die Vermittlung der Datenpakete ist aber doch das Thema bei
> der Verwendung von Mikrocontrollern und DSPs wie dem blackfin, weil
> diese noch andere Dinge tun müssen und viel davon zeitkritisch ist. Das
> bläht die Anwendung auf und führt nicht selten zu hektischem
> Interruptgefummel, wenn der DSP nicht ein I2S fest eingebaut hat.

Der Gag ist doch grade an DMA, dass es ohne IRQ-Handling läuft. Kennst 
du einen DSP, der I2S nicht hardwaremässig und ohne DMA macht? Ich würde 
behaupten: es gibt keinen.
Optimale DMA-Queues schmeissen nur dann einen Interrupt, wenn ein Fehler 
auftritt. Beim Blackfin ist das optimal gelöst, ich kann nur empfehlen, 
sich das Konzept fürs FPGA zu 'kopieren'.

Das Interface als solches zu implementieren ist ja nicht das Knifflige, 
sondern die Klassiker:
- Übergang in andere Taktdomänen
- Abrissfreier Datentransfer
- Allenfalls Clock-Synchronisation zw. Sender/Empfänger

Um jetz aber nich zig Sachen zusammenzuwerfen, würde ich halt mal mit 
den I2S-Optionen anfangen, erst mal Testsignale generieren, simulieren, 
simulieren...

Wie dann die obigen Klassiker vernudelt werden, muss jeder selber 
wissen. Ich würde auf jeden Fall sowas nie von Hand in HDL giessen 
(ausser, wenn unbedingt erforderlich), mit einer embedded CPU und 
sauberen SGDMA-Engine hat man die beste Kontrolle über Datenfluss, 
Protokolle und Timeouts und es ist für alle möglichen Protokolle (GigE, 
USB, ...) wiederverwertbar.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.