Ich bekomme aus einem AC97 encoder chip ein digitales Signal mit 48kHz,
das ich 44,1kHz umwandeln möchte. Mit einem FPGA sollte das machbar
sein, ich frage mich aber, wie ich das am Besten angehe.
Was mir bewusst ist, ist dass ich gfs etwas Bandbegrenzung einsetzen
muss, was aber kein Problem darstellen sollte. Ich dachte an ein 20kHz
Filter. So etwas habe ich schon implementiert.
Mir geht es aber um eine geschickte Erzeugung des 44,1 Taktes.
Im Grunde brauche ich eine PLL, die von 48kHz mit 441 auf 21,1 MHz
übersetzt und einen Teiler 48. Mit dieser Datenradte liesse sich dann
ein CIC Filter treiben, dass mit 480 zu 441 übersetzt.
Lässt sich das in einem FPGA bauen?
Was du suchst, steht in der Xilinx Application Note XAPP514
http://www.xilinx.com/support/documentation/application_notes/xapp514.pdf
und nennt sich Sample Rate Converter
Chapter 22 ff, wenn ich mich jetzt nicht irre.
Im schlimmsten Falle von außen einen Multiclock Generator
PLL1700/1705/1706
(TI) oder etwas moderneres anbinden.
Die Prinzipien sind mir natürlich geläufig, aber es scheint
komplizierter zu werden, als ich dachte. Wenn ich z.B. die asynchronous
rate conversion verwende, müsste ich éinmal von der externen 48kHz auf
meine interne Rate Konvertieren und dann nochmals auf die 44,1.
Ich meine, es müsste wohl möglich sein, die interne domain so zu wählen,
dass direkt 44,1 auszugeben sind, damit die Ratenkonversion nur einmal
zu geschehen hat. Oder wäre es passender, die domain auf die externe zu
synchronisieren?
Du brauchst beides, weil Dein Datentak ja von extern kommt. Ich würde zu
einer stabilen Taktfrequenz des FPGAs raten, aus der die 44,1 zu
erzeugen sind, oder falls nötig umschaltbar gehandhabt wird.
Um eine echte Ratenkonversion wirst Du nur herumkommen, wenn Du die 44,1
hart an der 48 ausrichten kannst und darfst. Dann solltest Du die 44,1
auf den externen Takt synchen. Da kann man komplett im FPGA machen und
auch für unterschiedliche Frequenzen einstellbar machen. Ich hatte mal
dies hier realisiert:
http://www.96khz.org/oldpages/frequencyconversion444896.htm
Die Schaltung synchronisiert sich auf jeweils den Datentakt und stellt
den digitalen Bittakt für s/PDIF passend in Frequenz und Phase ein.
Es ist aber fraglich, ob das bei Dir geht bzw sinnvoll ist, weil der
FPGA sicher noch andere aufgaben haben wird. Falls es gar kein FPGA sein
muss, weil der nur dafür benötigt wird, gibt es heute auch Chips, die
das direkt lösen und dies sehr gut, weil sie intern auf eine viel höhere
Oszillatorfrequenz kommen und damit das Resampling über Taktdomämen
hinweg genauer wird.
Ferner gäbe es noch die klassische Studiolösung: Man wandelt das Signal
der 48kHz auf analog und redigitalisiert es wieder. Das umgeht einige
Probleme des Resampling und des Jitters. Kommt drauf an, was von vorne
kommt.
Wenn es ein AC97-Typ ist, hat der ja seine Bitclock, an die Du Dich
dranhängen kannst. Mit etwas Gebiege kann man einen 25 MHz-Quarz so
ziehen, dass eine nachgeschaltete PLL mit 29/59 genau den 12.8MHz
Bittakt repräsentiert.
> Falls es gar kein FPGA sein> muss, weil der nur dafür benötigt wird, gibt es heute auch Chips, die> das direkt lösen und dies sehr gut,
Das würde ich auch empfehlen: schnell realisiert, sehr preiswert, sehr
hohe Funktionalität, erprobte Sache, garantiert fehlerfreie Funktion,
z.B. SRC 4382, um nur mal eine Hausnummer zu nennen.
Ich würde mir hier nicht das Leben schwerer machen, als es notwendig ist
-
außer dein Chef will es unbedingt. Der Zeitaufwand zur Realisierung
unter Berücksichtigung der erforderlichen Designverikation dürfte sich
wie 1 zu mindestens 1k verhalten.
Oder aber es ist, wie so oft und es muss was nachgerüstet werden, ohne
ein redesign der Platine zu machen :-)
Außerdem gibt es jaauch Quellen, wo man solche feinen Audio-VHDL-Sachen
preisgünstig einkaufen kann :-D
Danke schon einmal für Eure Tipps. Wenn es einen Chip gibt, der das
leistet, wäre das eine Alternative. Derzeit besteht aber die Intention,
es im FPGA zu lösen. Ich habe aber nun noch ein anderes Problem:
Ich musst / müsste auch die Umwandlung des codierten Datenstroms des
AC97 coders leisten. Dieser liefert mir das Signal aber nur seriell im
SPDIF Format. Das zu dekodieren sollte eigentlich einfach sein, dachte
ich, aber ein Blick auf das Datenformat macht mich unschlüssig, wie ich
da sicher einen Anfang erkennen kann.
Das Datenformat ist so eine Art Manchester Code, falls das jemand kennt
und hat im Wesentlichen 2 unterschiedliche Frequenzen, aber keinen Takt
und keinen richtigen Anfang. Wahrscheinlich muss ich einfach etwas
aufzeichnen und dekodieren um rauszubekommen, wo der Anfang ist?
Den Anfang eines Frames erkennt man an den drei gleichen Bits. Den
Anfang des ersten Frames im Datenblock erkennt man an der "B"-Präambel.
(Siehe http://www.hardwarebook.info/S/PDIF .)
Zur Umwandlung von S/PDIF in etwas 'normales' wie I²S gibt es natürlich
auch fertige Chips wie z.B. CS8416 oder WM8805.
So ganz bin ich da noch nicht durchgestiegen, aber auf den ersten Blick
sind es einmal eine 000 und einmal eine 111 Folge. Die können aber doch
in den Audiodaten ebenfals vorkommen?
Ein Audio-Bit wird als zwei Bits kodiert, von denen das erste immer den
vorherigen Zustand invertiert; im Zweiphasenmarkierungscode sind drei
gleiche Bits eigentlich nicht erlaubt.
PC-Verbinder schrieb:> Wenn es einen Chip gibt, der das> leistet, wäre das eine Alternative.
SRC4192 von Ti oder ähnliche von Ti.
Geht voll simpel und sogar mit angemessener Audioqualität ;)
Clemens L. schrieb:> Ein Audio-Bit wird als zwei Bits kodiert, von denen das erste immer den> vorherigen Zustand invertiert; im Zweiphasenmarkierungscode sind drei> gleiche Bits eigentlich nicht erlaubt.
Das verstehe ich nicht. Ich dachte ich muesste erstmal die Bis
dekodieren, dann fällt diese "Doppelfrequenzinformation" ja weg.
Ich habe dann doch nur wieder die ursprünglichen Datenbits und da
könnten doch 3 in Folge vorkommen ???
PC-Verbinder schrieb:
>Mir geht es aber um eine geschickte Erzeugung des 44,1 Taktes.
Mit einer PLL-Schaltung.
Einen VCO mit 44,1kHz aufbauen. Diese Frequenz durch 147 teilen = 300Hz.
Die 48kHz durch 160 teilen = 300Hz. Diese beiden 300Hz Frequenzen
mit einem Phasendetektor vergleichen. Die daraus entstandene Spannung
steuert den VCO. Der CD4046 enthält einen VCO und einen Phasendetektor.
Damit läßt sich das leicht realisieren. Man braucht dann nur noch
die Frequenzteiler.
Interessante Sache. Aber wie sieht das mit den Kosten aus. Kann ein FPGA
gegen ca. 20€ für SRC4392 + Oszillator antreten? Hatte nämlich auch
schon mal mit deinem Lösungsweg geliebäugelt.
Und von einer PLL aka PLL17xx würde ich abraten. Das sind
Jittergeneratoren. Damit machst du aus cd-Qualität fm-Radioqualität. Es
sei denn, du reclockst das Signal wieder mit einem ASRC.
Hameg schrieb:> ca. 20€ für SRC4392 + Oszillator
Aus eigener Erfahrung: mit einem guten Einkauf und einigermaßen
Stückzahlen bekommt man den SRC4392 für unter 7€. Wenn ein reiner SRC
ausreicht würde ich mal auf den SRC4190 bzw. SRC4192 schauen. Ersteren
beziehen wir für ca. 2,5€. Naja und den Oszillator gibt es für wenige
Cents...
Hameg schrieb:> Interessante Sache. Aber wie sieht das mit den Kosten aus. Kann ein FPGA> gegen ca. 20€ für SRC4392 + Oszillator antreten? Hatte nämlich auch> schon mal mit deinem Lösungsweg geliebäugelt.
Wenn der FPGA ohnehin da ist, zahlt man quasi nur die Chipfläche für den
Interface-Core und das ist minimal. Ein S/PDIf Interface in zwei
Richtungen kostet je nach Komplexität (ohne Wishbone oder Businterfaces)
rund 2k LEs bei Altera. Das sind anteilig eher 3-4 Euro. Extra einbauen
wird man einen FPGA aber nicht.
> Und von einer PLL aka PLL17xx würde ich abraten. Das sind
Jittergeneratoren.
Je nachdem, wie der FPGA eingesetzt wird, ist der Jitter ja ziemlich
egal. Oder, man muss das Signal direkt treiben, dann muss sich der
Jitter in Grenzen halten. Die SPEC nach S/PDIF einzuhalten ist bei einem
aktuellen FPGA aber kein Thema.
