Das Datenblatt des SSM2603 Codecs (hier integriert auf einem ZyBo mit
Zynq 7010 Grade -1) fordert eine Master Clock (MCLK) mit max. 50 ps
Jitter. ("When using an external
clock source to drive the MCLK pin, great care should be taken
to select a clock source with less than 50 ps of jitter.")
Wenn ich per MMCM aus der 125 MHz SYS-Clock des FPGA eine MCLK mit
12.288 MHz erzeuge, dann hat diese laut Instantiation Template 195 ps
peak-to-peak Jitter und 100 ps Phase-Error, s.u. Drehen an verschiedenen
Stellschrauben führt höchstens zu einer Erhöhung des Jitter-Wertes.
Heisst das, dass ich mit der genannten Hardware keine Chance habe, die
Codec Spezifikation einzuhalten? (In diesem Fall müsste ich wohl von
Slave auf Master Mode umsteigen und es dem Codec überlassen, die MCLK in
geeigneter Weise zu generieren).
Gruß,
Burkhard
50ps p-p oder RMS?
ist grosses Unterschied.
Aber mit dem MMCM clock für audio ADC zu machen ist keine gute idee!
1) sehr gutes clock >> FPGA nur durch keine logic >> clock out
kannst schon 50ps p-p !
2) MMCM, PLL jitter > 50ps immer alleine, das ist aber nicht das ganze
jitter was du hast
das beste was ich gemessen habe:
Si5338 > differential >> Kintex >> lvds out, SMA >> DSO
14 ps RMS
man muss immer denken das die FPGAs JITTER generatoren sind alles
jittert da immer mehr oder weniger.
Einen sauberen clock vom FPGA zu bekommen ist so einfach.
Eine PLL sollte schon einen kleineren Jitter verursachen bzw. Jitter
ausbügeln können, als die DCMs in MMCMs. Frag mal den Clock Wizard, was
er davon hält...
"50ps p-p oder RMS?"
Darüber schweigt sich Analog Devices schamvoll aus - da steht nur:
"Jitter tolerance: 50 ps." Was wäre denn für eine Audio Anwendung
typisch?
Die Zahl 197 ps pk-pk stammt vom Clocking Wizard - messen kann ich
nicht, da intern geführtes Signal.
PLL (statt MMCM) habe ich auch schon versucht, da sind es dann ca. 135
ps pk-pk. Dafür ist die generierte Frequenz 4kHz niedriger als
gefordert. Welche Möglichkeiten - wenn nicht PLL oder MMCM- habe ich
sonst noch?
Gruß,
Burkhard
Burkhard K. schrieb:> Wenn ich per MMCM aus der 125 MHz SYS-Clock des FPGA eine MCLK mit> 12.288 MHz
Ich nehme an, das wird eine S/PDIF clock? Warum muss der so genau sein?
Die Hardware, die ich so kenne, kommt mit deutlich grösseren
Schwankungen aus, als mit 50ps!
T. W. schrieb:> Ich nehme an, das wird eine S/PDIF clock? Warum muss der so genau sein?>> Die Hardware, die ich so kenne, kommt mit deutlich grösseren> Schwankungen aus, als mit 50ps!
Nein, der SSM2603 hat ein simples I2S kompatibles interface. Das
Requirement 50 ps für die MCLK stammt unmittelbar aus dem Datenblatt
(http://www.analog.com/media/en/technical-documentation/data-sheets/SSM2603.pdf).
Die Bitclock wird aus der MCLK abgeleitet, letztere steuert aber auch
die im Codec enthaltenen ADCs und DACs.
Burkhard
Den Jitter am FPGA-Ausgang kann man mittels einer PLL, eines keramischen
Oszillators oder einer Schaltung, die einen schnellen Transistorschalter
steuert, kontrollieren. Das sollte hier aber nicht nötigt sein.
Eigentlich sollte man im Fall entsprechender Anforderungen einen
Taktgenerator nutzen, der den FPGA steuert und parallel die Wandler
triggert. Der FPGA muss sich eben auf den Takt synchen. Die Bitclock
kommt in solchen Systemen auch regelmässig vom Chip.
Ansonsten kann man in frei laufenden Systemen mit einem FPGA ohne
Weiteres 192kHz Audio stabil ausgeben. Siehe die VHDL Schaltung für den
Spartan6:
http://96khz.org/htm/drumcomputerspartan6.htm
Man muss aber berücksichtigen, dass die aus exakten 1(25)MHz gewinnbaren
12,88 MHz nicht ganz exakt dem S/PDIF Takt 64x96x2 entsprechen. Bei
einer externen Synchronisation kann man den OSC etwas ziehen.
Für die generelle Funktion wäre der Jitter egal. Allerdings produziert
er eine Art FM auf dem Ausgangssignal und erhöht damit recht drastisch
das Rauschen. Bei 16Bit ist das (heute...) kein Problem, bei 20-24Bit
muss man sich aber schon anstrengen, dass das einem der Jitter die
zusätzlichen Bits nicht ruiniert.
Allerdings hat der SSM2603 jetzt nicht wirklich Werte, die mich so vom
Hocker hauen, dass ich da grossen Aufwand wegen dem Jitter treiben würde
;)
Hab grad mal nachgeschaut: Das letzte Mal, wo der Taktjitter beim
Sparten6 gemessen wurde, kam 20 bis 40 ps RMS raus. Dabei wurde ein von
der PLL regenerierter Takt vermessen. Für die Umrechnung RMS zu
peak-peak kann man Faktor 7 bis 10 ansetzen.
Duke
Vielen Dank für Eure Beiträge,
ich nehme mal folgendes davon mit nach Hause:
* Lesson learned: den Audio Codec besser im Master-Mode betreiben
* zur Not (16 bit Daten) darf es auch etwas mehr Jitter sein
* wenn es darauf ankommt - lieber PLL statt DCM/MMCM/...
* FPGAs jittern
* und last not least: Datenblätter verschweigen manchmal gerade die
wichtigen Informationen (Jitter peak-to-peak oder RMS???)
Gruß,
Burkhard
Burkhard K. schrieb:> * FPGAs jittern
Alle Taktquellen jittern!
Die Frage ist, auf welchen Jitter (Frequenzbereich) die gewünschte
Applikation empfindlich reagiert.
> * Datenblätter verschweigen manchmal gerade die> wichtigen Informationen (Jitter peak-to-peak oder RMS???)
Ja, und oft wird auch verschwiegen, wie der Jitter gemessen wurde.
Jitter ist das integrierte Phasenrauschen und dabei interessieren
natürlich die Integrationsgrenzen (im Beispiel die roten Linien).
Duke
Burkhard K. schrieb:> * FPGAs jittern
Die FPGAs als solche jittern nicht mehr, als andere equivalente
Schaltungen. Problematisch sind ohnehin mehr die gleichzeitig
schaltenden Ausgänge.
Thread beobachten
Seitenaufteilung abschalten