Ich habe in der LogiCoreLib von Xilinx einen I2S entdeckt, den ich gerne nutzen möchte. Den scheint es kostenlos zu geben. Allerdings unterstützt er offiziell nur 16/24 Bit Daten. Wie könnte ich den aufbohren, um auch 32 Bit zu übertragen? Leider ist der Core wie andere verkrüppelt und kann nicht ohne weiteres selber bearbeitet werden. Kann das irgendwie multiplexed werden?
:
Verschoben durch Admin
Moin, Da wirds doch weniger Arbeit sein, den gschwind' selber zu schreiben, wuerd' ich mal vermuten. I2S ist doch wirklich kein Hexenwerk. Vielleicht gibts ja auch was auf opencores. Gruss WK
Dergute W. schrieb: > Da wirds doch weniger Arbeit sein, den gschwind' selber zu schreiben, vermutlich, nur ist mir noch nicht klar, wie ich die 32 Bit ins Spiel bringe. Das Verhältnis der Abtastsrate (L/R clock) lässt nur 64 bit zu und laut Spezifikation werden maximal 24 Bit übertragen. Bei 16 Bit wird aufgefüllt, aber was passiert bei 32 Bits? Wir das gefiltert? Ich meine, es muss ja einen Grund geben, warum Xilinx in seinem offiziellen Core das nicht anbietet. i2s schrieb: > https://github.com/YetAnotherElectronicsChannel/FPGA-Class-D-Amplifier/blob/master/i2s_rxtx.vhd auch dort entdecke ich keine 32 Bit (?)
Moin, Hm, ja also aeh - was hast du denn vor? Ich denk mal, du hast irgendeinen IC, aus dem dein 32bit I2S raus/reinkommt und das willst du mit deinem FPGA verbinden, oder? Wenn dem so ist, dann sollte doch im Datenblatt des IC beschrieben sein, wie er's gerne haette. Gruss WK
24 Bit audio heißt, dass du im Regelfall automatisch 32-Bit samples überträgst. Beispiel 48 khz sample-rate -> macht 2*32*48000 clocks -> 3.072 MHz bitclock Die 24 Bit sind left-alligned in dem 32-Bit Frame drinnen. Die letzten 8 Bits sind einfach 0. So gut wie jeder 24 Bit ADC/DAC unterstützt diese 32-Bit form der Kommunikation und im DSP kann man direkt als 32-Bit integer dann damit rechnen. Das VHDL Modul oben arbeitet genau mit den 32-Bit frames
Dergute W. schrieb: > Hm, ja also aeh - was hast du denn vor? Ich denk mal, du hast > irgendeinen IC, aus dem dein 32bit I2S raus/reinkommt Was der Chip so kann, ist mir natürlich bewusst. Es ging mir darum, zu verstehen, warum der Core das nicht kann. i2s schrieb: > So gut wie jeder 24 Bit ADC/DAC unterstützt diese 32-Bit form der > Kommunikation und im DSP kann man direkt als 32-Bit integer dann damit > rechnen. Ja, denke ich auch. Ich habe einen 5102-DAC und 9023, die das beide können (sollen). i2s schrieb: > Das VHDL Modul oben arbeitet genau mit den 32-Bit frames Ich sehe da nur:
1 | out_l <= signed(in_shift(62 downto 39)); |
2 | out_r <= signed(in_shift(30 downto 7)); |
der cropped das also weg. Warum wird das gemacht? Gibt es ein SPEC mit 48 Bits pro sample? Meines Erachtens sind es bei I2S immmer 32 Bits, die übertragen werden. Man überträgt also Nullen, wenn man weniger Eingang hat. Nun habe ich aber einen 32 Bit Eingang und frage mich, warum die Xilinx-IP das nicht kann? Es wäre doch ein Leichtes, diese am Eingang des Cores anliegenden Bits mitzuübertragen, oder denke ich da falsch? Klar kann ich mir I2S selber stricken, nur gibt es ja verschiedene Formate und es wäre ja elegant, wenn ich einen validierten und varifizierten CORE aus der LIB nehmen könnte, den man nur parametriert, statt selber was zu tippen.
Mark B. schrieb: > Warum wird das gemacht? Gibt es ein SPEC mit > 48 Bits pro sample? Du kannst mit dem Word-Takt festlegen, wann eine Bitfolge anfängt und wann sie aufhört. Damit wird Stereo, 8-Kanal und TDM unterschieden, je nach Wandler. Man kann also ohne weiteres auch nur 24 Bit übertragen und dann direkt wechseln und das eben auch auf anderen Freuenzen. Allerdings kann nicht jeder Empfänger alle Formate. Mark B. schrieb: > Ja, denke ich auch. Ich habe einen 5102-DAC und 9023, die das beide > können (sollen). Dabei spielt auch eine Rolle, ob der Wandler das überhaupt verarbeiten kann. Dass er 32 Bit annimmt, heisst nicht, dass die Qualität besser ist. Letzt kommt das ja alles in einen Interpolations / Dezimationsfilter / Vorverzerrer, der von der DAC-Arcitektur abhängt.
Die meisten 08-15 ADCs / DACs oder I2S-Class-D Verstärker erreichen einen SNR von um die 120 dB wenn sie gut sind. Das wären dann +/- 20 bits Auflösung. Ich denke, dass sogar 100 dB SNR als allgemeine Richtlinie für "high-quality" Audio akzeptiert ist -> wären dann bisschen mehr als 16 bits. Ein Wandler der wirklich 24 bit kann, müsste dann 146 dB SNR erreichen. Das Problem bzw. das Kritische bei den DACs ist die Überführung vom "digitalen" ins "analoge". Aber auf eine andere Art als du jetzt denkst. Im Regelfall kommt nach dem Eingang ein Upsampling-Filter der die sample-rate intern ziemlich weit hochpusht - je nachdem wie viel oversampling der Chip macht, kann das irgendwas zwischen 64 - 256* die input-sample rate sein und danach kommt ein digitaler sigma-delta Wandler entweder mit single-bit output (also PDM out) oder als multi-bit output (irgendwas zwischen 3-6 bit output) und das ganze wird dann auf ein Widerstands-array geführt. Bei mir in der Firma hat man so etwas mal mit einem FPGA entwickelt, also i2s input auf PDM out. Wenn man den PDM Ausgang digital gesampled hat und dann in den spectrum-anaylzer geht kommt man da durchaus auf 140dB SNR und mehr. Leider scheitert es dann eher an den digitalen I/Os an die das analoge Ausgangsinterface angebunden wird -> da reichen leichteste Assymetrien in den output-buffern aus und man landet schnell mal 20-30 dB unter dem, was der sigma-delta Modulator wirklich kann.
i2s schrieb: > Bei mir in der Firma hat man so etwas mal mit einem FPGA entwickelt dito > also i2s input auf PDM out. Wenn man den PDM Ausgang digital gesampled > hat und dann in den spectrum-anaylzer geht kommt man da durchaus auf > 140dB SNR und mehr. bei 1kHz Sinus oder Rauschen? Delta-Sigma ist ja stark frequenzabhängig. > Leider scheitert es dann eher an den digitalen I/Os an die das analoge > Ausgangsinterface angebunden wird Inwiefern? -> da reichen leichteste Assymetrien > in den output-buffern aus Die müssen natürlich elektrisch entkoppelt werden, z.B. mit einem Gate-Transistor und 'ner PLL. Ein Kunde von mir benutzt meinen PDM-Core mit 24 Bit Eingang und hat hinter den FPGAs nur einen Analog-Switch mit komplementären GaAs-Schaltern, danach kommt die Power-Elektronik mit Filter. Da sind eher Einstreuungen von EMI und Netzteil sowie kleine Nichtlinearitäten die aus dem PCB-Design kommen relevant und die werden durch Vorverzerrung im Core kompensiert.
Klingt sehr interessant mit der Vorverzerrung. Gibt es da ne AppNote oder eine Arbeit dazu im Netz? Bzw. nach welchen Stichworten müsste ich dafür sinnvoll googeln? Leider erfolglos bisher :(
i2s schrieb: > Klingt sehr interessant mit der Vorverzerrung. > Gibt es da ne AppNote oder eine Arbeit dazu im Netz? Bzw. nach welchen > Stichworten müsste ich dafür sinnvoll googeln? > > Leider erfolglos bisher :( Nee, dass darf mal seber machen, weil jedes System seine eigene Übertragungsfunktion hat. Ultraschallsender tuten anders, als Lautsprecher. Für letztere ist das aber ein weit verbreitetes Thema. Die meisten Autohersteller fahren ihre Lautsprecher mit entsprechend präparierten Datenströmen und deren Macken zu reduzieren. Dabei geht es vor allem um Resonanzen. Das Thema Resonnzkompensation widerum ist im Tontechnikbereich auch bekannt und in mehreren Ansätzen behandelt. Es gibt Aktiv-Resonanzabsorber zu kaufen, darunter auch welche, die patentiert sind und andere die die Patente umgehen (oder sie ignorieren!). Ein System, das im Conumerbereich weit verbreitet ist, ist DIRAC.
Mark B. schrieb: > Nun habe ich aber einen 32 Bit Eingang und frage mich, warum die > Xilinx-IP das nicht kann? Es wäre doch ein Leichtes, diese am Eingang > des Cores anliegenden Bits mitzuübertragen, oder denke ich da falsch? Ich habe mir die fertig integrierte XI-IP mal angesehen. Der Core arbeitet (mal wieder) mit AXI, Taktübergängen und einem asynchronen FIFO, um für die Nutzung in einem SOC ready zu sein. Damit werden ein wertvolle BRAM verbraten und obendrein 1700 FFs beansprucht. Das hier ist der minimale Verbrauch in einem Artix 100 FPGA: LUT 577 63400 0.9100947 FF 1706 126800 1.3454258 BRAM 0.5 135 0.37037036 IO 150 210 71.42857 BUFG 3 32 9.375 Und das ist nur der Transmitter. Der Receiver kommt nochmal auf ein weiteres halbes BRAM und insgesamt 3000 FFs. Man kann den Core noch etwas verschlanken, wenn man auf das Standard AXI-IF verzichtet und es nur als streaming betreibt. Aber selbst bei idealen Taktkonstellationen (AXI und AXI Audio als Vielfach des Bittaktes) will er unbedingt ein BRAM verschwenden. Das ist ein Haufen overhead, der Chipfläche verbrät ohne Ende und dies für eine Funktion, welche im Wesentlichen aus einem Schieberegister besteht, wenn man klug designed und mit massiven Takten arbeitet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.