ich habe nach dem obligatorischen einstiegsprojekt counter mit Led-Ausgabe,
vor einen I2s receiver (pcm5102) anzusteuern und stecke dabei etwas fest,
ich habe für den schnellen einstig folgenden code mit chatgpt
generiert, und bin nicht komplett sicher ob der Fehler dort steckt oder auf der Hardwareseite... Ich habe sckl, lrck und sdata an die generellen GPIO pins
vom DE0-nano angeschlossen aber nichts passiert nach der Programmierung...
Der Code für den I2s-transmitter selbst ist folgendermaßen:
Der Rest ist eigentlich nur glue-code.
Und das ganze ist mit 1,4112 Mhz getaktet, also dem 32 fachen der audiofrequenz 44.1 khz die ich am Ende heraushaben möchte.
Kann mir jemand helfen, den Fehler zu finden.
Und mir vielleicht ein paar Tipps wie ich die Testbench zu schreiben habe. und wie ich am besten die Hardware debugge...?
Ich sehe da nicht, dass da geshifted wird, und das richtige Bit rauskommt.
Der LRCLK scheint um 1 CC verfrüht, zu spät - je nachdem welches Schema man fährt. Sieh dir mal die I2S-Spec genauer an, wie der LR CLOCK liegen muss.
Der SCLK ist nicht notwendigerweise identisch mit dem MLCK. Das hängt an dessen Definition und wie das devices da haben will: Manche fahren mit 128x,
mache mit 256x - mache brauchen gar keinen MCLOCK. In jedem Fall solltest du mal posten, was da hinten dran hängt.
und ja es kann auch die HW sein. Ich verwende fertige Module aus CN und in der Tat hatte ich von 4 Stück einer Lieferung schon mal 2 kaputte: Eins hat geplärrt, eins wollte gar nicht - jeweils an einem I2S-chip betrieben, der ein perfektes timing machte. Eine andere Charge war komplett ok.
Als weitere Problemquelle kommt hinzu, dass manche Empfänger immer 32 Bit haben wollen und verarbeiten, einige auch dann, wenn sie sie nicht verarbeiten.
Und es kann sein, dass dein Takt nicht exakt passt: 64x48 und 64x96 klappten super, 64x44,1 war nicht zum Laufen zu bekommen. War ein Wolfson ...
Und prinzipiell/workflow liegt einiges mehr daneben. Das da ne LED blinkt; bedeudet nicht das:
bekannt ist, wie Error/Warnings/Logik-Allokation bei Synthese, PAR, bitstream-gen angezeigt wird
eine Simulation gemacht wurde um die gröbsten Fehler zu finden
ein brauchbares Sys-Reset-Netzwerk exestiert
Aber wenigstens der Takt scheint ja zu tun.
So wie ich das Top-Blockbild verstehe ist keinerlei Reset angeschlossen und der Namensgebung nach erwartet die eine Komponente eine Reset auf '0', ein anderes auf '1'. Und das Ganze scheint ein Altera/intel-FPGA zu sein, bei dem man im Unterschied zu Xilinx/AMD nicht mit synthetisierbaren default auf signals arbeiten kann.
Also tut man IMHO gut daran, erstmal eine Testbench für die Simu des LED-Blinkers aufzusetzen und den Blinker um einen Reset-Eingang für einen Button zu erweitern. Bei der Simu hilft man sich u.U. viel, wenn man nur für die Simu die Bllinkperiode klein hält, um nicht ewig auf den simulierten Ablauf einer Echtzeit-Sekunde zu warten.
Dann erweitert man das Blinker-Design stückweise um die Komponenten fürs I2S. Wenn man dergestalt das Blinkerdesign mitschleppt, erkennt man sofort, wenn man etwas prinzipielles zerkloppt hat und kann dann stückweise zurück gehen.
Vielen Dank für die Antworten - leider bin ich zur Zeit gerade unterwegs und kann erst im neuen Jahr wieder hineinschauen...
Ursprünglich wollte ich auch eigentlich ein entsprechendes Project von OpenCore verwenden, habe da aber den login verloren, irgendwie schicken sie keine Email raus (?), und die angegebene email adresse ist auch falsch bzw. nicht vorhanden.
Er hat doch den I2S Empfänger genannt.
https://www.ti.com/lit/gpn/PCM5102
Auf Seite 14 steht wie das ankommen sollte. Wobei ich den Unterschied zwischen left justified und I2S nicht verstehe. Ist das wirklich nur ein invertiertes LRCK das einen Takt früher da ist?
Ich schätze ich sollte wohl erst einmal dieses Tutorial https://www.beyond-circuits.com/wordpress/tutorial/ durcharbeiten,
bevor ich daran denke I2s anzusteuern -leider ist das jedoch auf Xilinx zugeschnitten.
Ist aber im Grunde schon egal, weil die VHDL-Einarbeitung die gleiche wäre. Es gibt auch keinen FPGA der so alt sein kann, daß man damit kein I2S hinbekäme.
Wie bereits hingewiesen liegen Deine Probleme nicht in der Hardware sondern im KnowHow bezüglich dem Bereich FPGA-Entwicklung und insbesonders im Aufsetzen/Benutzen einer vollständigen Tool-Chain. Allerdings kann es schon sein, das man durch den Ersatz des D10-Nano (Cyclone V -SoC) mittels eines "reinem" (ohne ARM-SoC) FPGA-Board das Lern-Problem deutlich verringert. Allerdings ist dein "neues" Board (Terassic P0496 mit CycV) ebenfalls ein (IMHO für einen Einsteiger) unnötig komplexes Board.
Sinnvoll, weil ergänzende Neuanschaffungen wären an dieser Stelle im Lernprozess gescheite Bücher zum Thema und Debugtools (Aufsetzen SignalTap, Logicanalyzer an Test-Pins, ...).
Ist aber im Grunde schon egal, weil die VHDL-Einarbeitung die gleiche
wäre.
Der TO metzelt seinen Code allerdings in Verilog statt in VHDL. Und der Verilog-code sieht aus wie von einem C-Programmierer geschrieben dem jegliche Erfahrung mit Digitalen - Grundstrukturen (FF-Beschaltung, ROM als LUT) abgehen.
Es gibt auch keinen FPGA der so alt sein kann, daß man damit kein
I2S hinbekäme.
Ja, I2S vor über 25 Jahren mit einem Spartan/Spartan-XL
Im Audio-Bereich macht man es sich IMHO mit den in "jüngeren" FPGA's vorhandenen Hardware-Multiplizieren "leichter", wenn man umfängliche Frequenzfilter bspw. würde für Sample-Rate-Conversion realisiert. Aber das ist immer noch weit weg von einem ARM-Dual-Core SoC- Boliden wie dem CycV.
Da das DE10-nano board es mir bietet, werde ich erstmal die Audioschnittstelle über linux realisieren, bevor ich überhaupt an hardware code / schnittstellen denke. Das flacht die Lernkurve immens ab. Und ein embedded zum (rum)spielen ist eine lohnende Investition.
Später dann, wenn ich die Grundlagen drauf habe, kann ich mich an die Hardware setzen. Einziges Problem was ich noch sehe ist, dass ich kein günstige breadboard Variante von dem FPGA/ARM-SOC sehe, sollte ich später tatsächlich mal dazu kommen ein eigenes Produkt machen zu wollen...
Da das DE10-nano board es mir bietet, werde ich erstmal die
Audioschnittstelle über linux realisieren, bevor ich überhaupt an
hardware code / schnittstellen denke. Das flacht die Lernkurve immens
ab. Und ein embedded zum (rum)spielen ist eine lohnende Investition.
Später dann, wenn ich die Grundlagen drauf habe, kann ich mich an die
Hardware setzen. Einziges Problem was ich noch sehe ist, dass ich kein
günstige breadboard Variante von dem FPGA/ARM-SOC sehe, sollte ich
später tatsächlich mal dazu kommen ein eigenes Produkt machen zu
wollen...
Wann soll denn das spaeter sein? Bei einer flachen Lernkurve in
etwa 50 Jahren? Schwimmen lernt man nur im Wasser.
Wenn dir I2S zu kompliziert ist, nimm einfach erstmal einen PT8211.
"Algorithmen" auf dem FPGA, und dazu benutzt man den ja eigentlich,
sind dann aber auch nicht weit weg.
Ja, I2S vor über 25 Jahren mit einem Spartan/Spartan-XL
Au ja. Sparten XCS40XL :) Und Leonardo und ISE8.4.
Edith:
Im Audio-Bereich macht man es sich IMHO mit den in "jüngeren" FPGA's
vorhandenen Hardware-Multiplizieren "leichter", wenn man umfängliche
Frequenzfilter bspw. würde für Sample-Rate-Conversion realisiert. Aber
das ist immer noch weit weg von einem ARM-Dual-Core SoC- Boliden wie dem
CycV.
Auch ein aus LEs aufgebauter Multiplizierer in einem CycI ist sehr schnell.
Und den kann man ja fuer Audioanwendungen bequem "multiplexen".
Wann soll denn das spaeter sein? Bei einer flachen Lernkurve in
etwa 50 Jahren? Schwimmen lernt man nur im Wasser.
Nein,keine 50 Jahre aber ein paar Monate - momentan jongliere ich noch
andere Projekte nebenbei, genauer gesagt ein paar analoge module für einen eurorack synthesizer.
Wenn dir I2S zu kompliziert ist, nimm einfach erstmal einen PT8211.
"Algorithmen" auf dem FPGA, und dazu benutzt man den ja eigentlich,
sind dann aber auch nicht weit weg.
Inwiefern ist der PT8211 einfacher?
Was ich gerade suche ist eigentlich nur die pinbelegung für I2S auf z.B. dem
DE10-nano board.
Was ich gerade suche ist eigentlich nur die pinbelegung für I2S auf z.B.
dem
DE10-nano board.
Sehr verwunderlich.
Gibt es da vom Hersteller keine Dokumentation?
Ansonsten:
Ist dir das Altera University Programm ein Begriff?
Da wird viel "Audio" mit dem Cyc5/Soc gemacht.
Was ich gerade suche ist eigentlich nur die pinbelegung für I2S auf z.B.
dem
DE10-nano board.
Sehr verwunderlich.
Gibt es da vom Hersteller keine Dokumentation?
Da bin ich gerade dran, für den Raspberry Pi scheint es eine GPIO-Tabelle zu geben,was entsprechendes finde ich aber nicht im datenblatt bzw. user manual (hier ist das Datenblatt und Handbuch in einem PDF zusammen)...
Ansonsten:
Ist dir das Altera University Programm ein Begriff?
Da wird viel "Audio" mit dem Cyc5/Soc gemacht.
Nein, darum vielmals danke für den Hinweis!
Allerdings finde ich auf der Seite nur die Board beschreibungen und software toos anklickbar und login mit MyAltera funktioniert auch nicht :/
Allerdings finde ich auf der Seite nur die Board beschreibungen und
software toos anklickbar und login mit MyAltera funktioniert auch nicht
:/
Protipp: Das heisst "University Program" weil es an den Universitaeten
genutzt wird. Man muss also schon ein paar Links folgen...
Und ob die Inhalte "suchmaschinenverwurstet" sind, weiss ich nicht.
Inhalte des Lehrprogramms aendern sich dort™ oft.
Ein Link von gestern kann heute schon nichts mehr Wert sein.
Und suchen musst du schon selber.
Edith: Meinen Altera Account hab ich fuer meine Fundstellen gar
nicht gebraucht.
Im Audio-Bereich macht man es sich IMHO mit den in "jüngeren" FPGA's
vorhandenen Hardware-Multiplizieren "leichter", wenn man umfängliche
Frequenzfilter bspw.
Nun ja zunächst einmal braucht der TE ja nur ein Interface mit I2S und das ist gerade mal 60 LUTs groß :-)
i2s_transmitter.png
(36 KB)
