Guten Tag,
für eine Audio-Anwendung (Hobbyprojekt) auf einem Artix-7 (Nexys 4)
benötige ich zwei Clock-Domänen:
* 100 MHz (vom ADC / 1 MSamples/s) - SYS_CLK
* 52,2 MHZ (zum Audio Codec / 200 kSamples/s) - AC_CLK
(Der AC hier ist ein CS4344, der beliebige Samplefrequenzen, also auch
die "krummen" 200 kSamples/s erlaubt).
Die 52,2 MHz werden mittels DCM (MMCME2) aus der SYS_CLK generiert und
dienen zur Ableitung weiterer für den AC benötigten Takte:
MCLK (Master Clock) = 25,6 MHz
SCLK (Bit Clock) = MCLK / 4
LRCLK (Channel Sel.)= SCLK / 32 bzw. MCLK / 128 = 200 kHz
Die Signale aus der ADC Clock-Domäne durchlaufen einen Dezimator-FIR
(M=5) - dessen Ausgang exakt die vom Audio Codec benötigten 200
kSamples/s liefert (die Synchronisation zwischen den Domänen erfolgt
über einen asynchronen FiFo)
Dieses Schema funktioniert in der Theorie wunderbar - nur die
(versteckte) Vorbedingung lässt sich so auf dem FPGA nicht
implementieren: Die vom DCM generierte Frequenz müsste exakt mit dem
berechneten Wert (52,2 MHz) übereinstimmen, damit die beiden genau
aufeinander abgestimmten Takte nicht auseinanderlaufen. In meiner
jetzigen Implementierung stolpert das Ausgabe-Signal ca. alle 260 us,
das Spektrum zeigt folgerichtig Nebenmaxima im Abstand von ca. 3,9 kHz.
Um max. einen Glitch pro Sekunde zuzulassen, müsste die AC_CLK bis auf 5
ppm genau den geforderten 52,2 MHz entsprechen (unter der Voraussetzung,
dass die Abweichung der SYS_CLK noch darunter liegt).
Lässt sich solche Genauigkeit erreichen? Im IP-Generator kann ich die
Ausgabefrequenz max. auf 1 KHz genau spezifieren. Leider habe keine
Möglichkeit die Ganggenauigkeit der DCM generierten Clock im ppm Bereich
zu messen. Der IP Generator gibt einen "Phase Error" von ca 260 ps an -
das entspräche ca 0,5 % - wäre also bereits um einen Faktor 100 größer
als die oben hypothetisch geforderten 5 ppm.
Gibt es - ausser den ADC in die Clock-Domäne des Audio Codecs zu
verlagern - noch eine anderen Lösung für obiges Dilemma?
Danke,
Burkhard
Angehängte Dateien:
-
glitch.png
68 KB
@ Burkhard K. (Firma: Own my own) (buks) > * 100 MHz (vom ADC / 1 MSamples/s) - SYS_CLK > * 52,2 MHZ (zum Audio Codec / 200 kSamples/s) - AC_CLK >Die 52,2 MHz werden mittels DCM (MMCME2) aus der SYS_CLK generiert Wirklich? Das wäre ein recht krummer Teilerfaktor. Kann das dein DCM WIRKLICH? Oder liegt die Frequenz nicht eher daneben? > MCLK (Master Clock) = 25,6 MHz >Die Signale aus der ADC Clock-Domäne durchlaufen einen Dezimator-FIR >(M=5) - dessen Ausgang exakt die vom Audio Codec benötigten 200 >kSamples/s liefert (die Synchronisation zwischen den Domänen erfolgt >über einen asynchronen FiFo) AHA! Hier wird also gemogelt! >Dieses Schema funktioniert in der Theorie wunderbar - nur die >(versteckte) Vorbedingung lässt sich so auf dem FPGA nicht >implementieren: Die vom DCM generierte Frequenz müsste exakt mit dem >berechneten Wert (52,2 MHz) übereinstimmen, damit die beiden genau >aufeinander abgestimmten Takte nicht auseinanderlaufen. Das kann nur eine PLL. >Um max. einen Glitch pro Sekunde zuzulassen, müsste die AC_CLK bis auf 5 >ppm genau den geforderten 52,2 MHz entsprechen (unter der Voraussetzung, >dass die Abweichung der SYS_CLK noch darunter liegt). PLL! >zu messen. Der IP Generator gibt einen "Phase Error" von ca 260 ps an - >das entspräche ca 0,5 % - wäre also bereits um einen Faktor 100 größer >als die oben hypothetisch geforderten 5 ppm. Vorsicht! Nicht statische Phasenfehler mit Frequenzfehlern vermischen! >Gibt es - ausser den ADC in die Clock-Domäne des Audio Codecs zu >verlagern - noch eine anderen Lösung für obiges Dilemma? So ganz hab ich dein Problem noch nicht verstanden. Wenn du aus 100 MHz 52,2 MHz ableitest und DARAUS per digitaler Teilung die Takte für deinen Audio-DAC, dann kann doch gar nix wegdriften. Denn dann sind alle Takte phasenstarr zueinander. Oder gibt es für den DAC eine extra Taktquelle?
>>Die 52,2 MHz werden mittels DCM (MMCME2) aus der SYS_CLK generiert, keine weitere Taktquelle. > > Wirklich? Das wäre ein recht krummer Teilerfaktor. Kann das dein DCM > WIRKLICH? Oder liegt die Frequenz nicht eher daneben? Der IP-Generator Dialog sagt: Ja. Allerdings nur wenn ich ein MMCME2 verwende, beim PLLE2_ADV bekäme ich 52,174 MHz:
1 | ------------------------------------------------------------------------------
|
2 | -- "Output Output Phase Duty Pk-to-Pk Phase"
|
3 | -- "Clock Freq (MHz) (degrees) Cycle (%) Jitter (ps) Error (ps)"
|
4 | ------------------------------------------------------------------------------
|
5 | -- CLK_OUT1____52.200______0.000______50.0______298.957____259.341
|
6 | --
|
7 | ------------------------------------------------------------------------------
|
8 | -- "Input Clock Freq (MHz) Input Jitter (UI)"
|
9 | ------------------------------------------------------------------------------
|
10 | -- __primary_________100.000____________0.010
|
> So ganz hab ich dein Problem noch nicht verstanden. Wenn du aus 100 MHz > 52,2 MHz ableitest und DARAUS per digitaler Teilung die Takte für deinen > Audio-DAC, dann kann doch gar nix wegdriften. Denn dann sind alle Takte > phasenstarr zueinander. Oder gibt es für den DAC eine extra Taktquelle? Nein, alle Takte sind von der SYS_CLK abgeleitet. Das Problem liegt tatsächlich im Wegdriften der AC_CLK - nur fehlen mir leider die Messmittel um diesen Fehler direkt zu messen. Interessanterweise rechnet die Simulation mit einer Periode, die 52,20569 MHz entspricht - und sagt das Wegdriften damit ziemlich exakt vorher. Gruß, Burkhard
@Burkhard K. (Firma: Own my own) (buks) >> phasenstarr zueinander. Oder gibt es für den DAC eine extra Taktquelle? >Nein, alle Takte sind von der SYS_CLK abgeleitet. Das Problem liegt >tatsächlich im Wegdriften der AC_CLK Ahhh!. Und warum? Warum nich aus AC_CLK? Weil die Frequenz zu klein ist? Wenn AC_CLK wirklich wegdriftet, arbeitet der DCM nicht nicht mehr als PLL und dann ist der Wurm drin. >- nur fehlen mir leider die >Messmittel um diesen Fehler direkt zu messen. Warum? Ein Oszi hast du doch hoffentlich! Teile SYS_CLK und AC_CLK auf eine gemeinsame Frequenz runter und schau dir die Phasenlage über Zeit an. Trigger auf das eine Signal und schau das andere dabei an.
nur mal so zur Überprüfung? wie sind deine Teiler und Multiplikatoren bei der DCM, kommt da etwas plausibeles raus. 52,2 MHz = 52,2/100 * 100 MHz = 522/1000 * 100 MHz = 261/500 * 100 MHz .. so richtig sehr ich das nur mit einer fractional-PLL machbar. Ggf. noch über einen digitalen Zählertaktteiler (vielleicht auch nicht). wie lange läuft der Codec? geht es vielleicht mit asynchronen domänen + fifo? ggf. schau dich nach externen PLLs um
http://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf Seite 70/71. Fractional divide kann 1/8, also du kannst beim Teiler jetzt in achtelschritten gehen. Aber aus 100 MHz 52.2MHz machen geht damit noch nicht. Aber wie ist das, Lothar hat ja eine DDFS auf seiner Seite, sagen wir wir machen jetzt mit DDFS 52.2 MHz oder 26.1 MHz, dann ist das natürlich kein sauberes Signal weil ich nicht viele Punkte habe. Aber wenn ich dieses Signal nehme das da rumjittert und es in eine PLL reistecke, würde die das dann korrigieren (ggf. multiplizieren bei 26.1 MHz) und hinten kämen 52.2 MHz raus? Fände ich sehr cool wenn das ginge. Muss ich mal ausprobieren irgendwann und gucken ob die PLL lockt.
Urgs, Peinlicher Rechenfehler, 2*25,6 gibt natürlich 51,2 MHz (und nicht etwa 52,2). 51,2 MHz sind wunderbar per PLL synthesierbar. Mit der richtigen Frequenz gibt es in der Simulation über 10 ms keine signifikante Verschiebung und die Implementierung auf dem FPGA zeigt keine Glitches mehr. Gruß, Burkhard
Gustl B. schrieb: > Seite 70/71. Fractional divide kann 1/8, also du kannst beim Teiler > jetzt in achtelschritten gehen. Aber aus 100 MHz 52.2MHz machen geht > damit noch nicht Es geht über einen Umweg und das sogar bis auf wenige ppm genau. Siehe die DCM-Konfiguration wie in meinem Drum Computer. Man benutzt den Eingangsteiler von 2/4 und eine zweite DCM, wenn man den hohen Audiotakt braucht. Bei mir reicht sogar eine. Die lässt sich sogar noch analog auf den Chip oder einen externen Takt synchen. 100 MHz / 4 -> 25 MHz 25 x 29 / 59 -> 12,288 MHz. Das ist die benötigte Audio-Frequenz, denn 1/64 davon sind fast genau 192kHz.
Wow cool das klappt sogar, mit DDFS was erzeugen und dann intern wirder in eine PLL füttern.
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.