Hallo Leute,
ich habe eine nicht ganz triviale Frage. Mit einem FPGA muss ich extrem
jitter-armes Signal generieren. Zum FPGA geht eine Clockleitung von
einem Clock-generator mit einem Jitter von ca. 1 ps. Was dann aus dem
FPGA kommt mag ich gar nicht denken (300 ps Jitter) ;-)
Jetzt möchte ich das Signal, welches aus dem FPGA kommt wieder mit der
jitter-armen Clock eintakten (Flip-Flop). Kann mir da jemand sagen, ob
diese Vorgehensweise annährend funktioniert? Hat da jemand schon
Erfahrung damit gemacht? Wie habt ihr das gemacht, falls ihr das mal
gemacht habt?
Danke im Voraus,
Kest
> Jetzt möchte ich das Signal, welches aus dem FPGA kommt wieder mit der> jitter-armen Clock eintakten (Flip-Flop).
Mit einem externen FF?
Bei welcher Taktfrequenz?
Hast du vor dem FPGA-Ausgang noch irgendwelche Kombinatorik (MUX...)?
Eigentlich sollte es funktionieren, wenn du direkt das Ausgangs-FF des
FPGAs verwendest, und das mit dem jitter-armen Clock taktest. Wobei 1ps
schon recht sportlich ist...
Also als Ausgang ist ein Mal NRZ-Signal und ein Mal halt die (im FPGA)
generierte Clock.
Das blöde ist, dass ich keine Möglichkeit habe den Jitter wirklich zu
messen. Deshalb möchte ich eine Lösung, die nachrechenbar ist (so wie
z.B. externes FF). Wenn ich das nur mit FPGA mache, also so, wie Du
vorgeschlagen hast, dass FPGA-FF mit der jitterarmen clock getaktet
wird, wird mich der Kunde später fragen (und sicherlich dann später
nachmessen), wie hoch der Jitter des FPGAs ist -- die Antwort ist RTFM
und da steht 300 ps :-(
1 ps ist wirklich sehr sportlich und mir ist auch klar, dass das ganze
nicht ohne ist. Mal schauen, was daraus wird.
Grüße,
Kest
Hallo Kest,
ich würde einmal behaupten, dass Du Dir alleine der Schmutz auf der FPGA
intern geführten VCCIO-Versorgung im FPGA mehrere PS Jitter einbringt
und vor allem nicht spezifiziert werden kann ohne das Design im Bereich
der betreffenden IO-Bank genauer zu untersuchen...
Aber auch bei externem FF dürfte es Dir schwierig fallen 1ps zu
garantieren, wenn in dem gleichen Baustein mehrere FFs wären die
unterschiedliches tun...
Aus der Hüfte geschossen würde ich sagen, untauglicher Ansatz...
Gruss
Andreas
Die Clock wird nicht von einer DCM abgeleitet -- das FPGA arbeitet schon
mit der jitterarmen-Clock. Die ausgangsclock ist gleich der
Eingangsclock (und durch 2 geteilt). Die Hauptaufgabe ist eigentlich die
Ausgagnssignale mit der jitterarmen Clock einzutakten.
Dass VCCIO-Versorgung mit Probleme einbringt ist ja klar, sonst würde
ich nicht nach einer externen Lösung suchen ;-)
Eine Clock kann man "ent"-jittern, dafür gibt es spezielle Bausteine von
TI/AD. Ich suche nach einer Möglichkeit die Signale, die zw. 5 und 20
MHz liegen jitterarm zu halten.
Grüße,
Kest
Auf die Gefahr hin eine lange Diskussion über Pro und Contra bzw. Sinn
und Unsinn auszulösen -- das ganze kommt aus dem Audio-Bereich...
Extremanwendung ist es aber schon ;-)
Die Vorgaben sehen Signale von unter 1ps Jitter vor. Aus dem digitalen
Datenstrom wird Clock rückgewonnen, die Daten zum DAC müssen aber
jitterarm sein (samt Clock). Das Board soll sowohl digitale als auch
analoge Schnittstellen haben (und dann auch noch alles asynchron (44.4
kHz, 48 kHz, 88 kHz, 96 kHz, 192 kHz). Es kann auch sein, dass die Clock
von Außen kommt (Master/World-clock), die muss dann auch noch
"ent"-jittert werden.
Grüße,
Kest
Ach Gottchen, die Audiophilen, die sich einbilden, den Unterschied
zwischen 1ps und 300ps Jitter bei 192kHz Abtastrate zu hören. Naja.
Also wir geben hier einen Takt mit einem Jitter von 5ps
(Jauch-Oszillator) auf einem Spartan 3e und direkt wieder aus, der
Spartan fügt etwa 50ps Jitter hinzu.
Und ich hab schon gedacht du willst einen Laser-Entfernungsmesser oder
ein Radar bauen... aber natürlich geht es mal wieder nur um
Pseudo-Anforderungen.
Das sind keine "Pseudo"-Anforderungen ;-) Wenn die ADC/DACs bei
unterschiedlichen Jittern unterschiedliches Verhalten aufweisen, das man
messen kann (und unter Umständen auch hören kann), dann ist das gerade
gut genug was im Datenblatt steht.
Davon mal abgesehen, die Audiophilen bezahlen dafür viel Geld -- die
sollen dafür auch was bekommen :-)
Danke für das mit 50ps Jitter beim Spartan -- gut zu wissen.
Grüße,
Kest
Kest wrote:
> Davon mal abgesehen, die Audiophilen bezahlen dafür viel Geld -- die> sollen dafür auch was bekommen :-)
Jeden Tag steht ein dummer Mensch auf. Man muss ihn nur finden.
> Danke für das mit 50ps Jitter beim Spartan -- gut zu wissen.
Naja, das ist aber von Design zu Design unterschiedlich. über 100ps
hatten wir auch schon mal, kommt halt auf´s Routing an.
Das mit dummen Menschen gebe ich Dir Recht :-) Das sollte man aber dem
Kunden nicht sagen ;-)
Andererseits, wenn man ein riesiges Tonstudio anschaut, mit Unmengen an
Equipment (sowohl digital, als auch analog), mit diversen Bussen, wie
AES3, MADI, ADAT, SPDIF und was weis ich noch, dann liegt der Gedanke
nahe, dass eine jitterarme Clock (und auch Daten) nicht verkehrt sein
kann.
Ich glaube, manche vergleichen Autos, andere diverse Körperteile -- aber
im Audiobereich vergleicht man Jitter ;-)
Zurück zum Jitter: ich lese mich gerade da ein und muss sagen, dass die
ganze Thematik doch kein Voodoo ist, auch wenn mein Weltbild nun hinüber
ist :-/ Aber ich glaube, das passt hier nicht ganz rein.
Grüße,
Kest
Hallo Kest, kann man mehr dazu erfahren? Ich komme aus dem
Tonstudiobereich und kann dazu sagen, daß Jitter der inzwsichen
Leistungsbegrenzungsfaktor Nummer 1 ist. Freilich reden wir hier nicht
von ps, da die Geräte selber eingangsseitig auch nicht genauer sind. Man
muss nämlich sehen, daß gute Geräte Wandler verwenden, die eine eigene
PLL haben- wodrich der Jitter im Signal NUR von diesem einen Bauelemen
abhängt - es kommt einzig darauf an, daß die Clock stabil genug ist, daß
es zu keinen Phasenbedingten Übernahmefehelrn kommt. Und: Die Clock muss
von aussen kommen, damit die Zahl der Samples stimmt und nicht resampelt
werden muss.
"Naja, das ist aber von Design zu Design unterschiedlich. über 100ps"
"hatten wir auch schon mal, kommt halt auf´s Routing an."
Wieso hängt der Jitter am Routing? Wenn nichts dran hängt jitter auch
nicht mehr. Es kommt ja einzig auf die Clockbelastung an. Daher:
PLL und WordClock-Eingang / Clockausgänge auf eine eigene Bank mit
eigener Versorgung.
@Frager:
Es gibt eigentlich nicht sehr viel mehr zu erfahren, als ich schon
geschrieben habe, sorry. Die Daten müssen halt mit der ("dem" für Falk)
neuen Clock eingetaktet werden und dann weiter geleitet werden. Wichtig
ist, dass so wenig Jitter dazu kommt wie nur möglich.
Grüße,
Kest
Etwas OT:
> ... mit der ("dem" für Falk) neuen Clock ...
Für mich ist es bisher (wie für Falk)
auch schon immer der Clock bzw. Takt und er wird es auch bleiben :-/
the clock = die Uhr
the clock = der Takt
Ach so, Du schaltest die Takte nur durch? Dann bekommst du Abtastjitter
- da ist natürlich aergerlich, weil die PLLs in den Endgeräten dann
Gemüse sehen! Leider ist das besonders bei mixed-freq-Applikationen (44
+ 96 gleichzeitig) aergerlich.
Noch mal:
rein kommt DER Master-Clock (ich lerne schnell! :-))
Auf dem Board ist ein Quarzoszillator mit unter 1ps Jitter +
Distribution --> Der Master-clock und der Quarz laufen idealerweise
synchron (tun sie natürlich nicht, aber das ist jetzt ein anderes
Problem) Die Daten müssen nun entjittert werden. Der MasterClock wird
nur zur Einsynchronisierung gebraucht, aus dem Gerät (bzw. zu den DACs
und ADCs und so weiter) soll dann sowohl der saubere Clock (dann als
MasterClock) und die Daten geschickt werden.
Der Master-Clock ist zwar jitter-arm, aber eben dann nicht mehr die
Signale, die aus dem FPGA rauskommen sollen. Deshalb war meine Idee die
Signale noch Mal extern durch ein FF zu jagen, um den Jitter zu
minimieren.
Die ganze Clock-distribution wird ganz schön kompliziert (und teuer).
Dazu kommt noch dass es mehrere Kanäle geben soll (ggf. mit
unterschiedlichen Frequenzen).
Grüße,
Kest
>Die Daten müssen nun entjittert werden. Der MasterClock wird>nur zur Einsynchronisierung gebraucht,
Dort genau produzierst Du den zusaetzlichen Jitter. Wenn die Masterclock
wirklich Master ist, darf sie nicht entjittert werden, sondern alle
Geräte muessen damit mitlaufen!
Aus dem FPGA wirst du niemals was Besseres rausbekommen, da eine gute WC
aus einem kompensieren AD-Design stammt.
@Kest (Gast)
>Okay, mich habt ihr überzeugt -- der Clock.>rein kommt DER Master-Clock (ich lerne schnell! :-))
Einbildung ist auch ne Bildung. Manchen seine Einzige.
Es heisst entweder "der Takt" oder "the clock". Aber schwachsinniges
Denglisch ist ja "in" :-(
@Falk Brunner
>Es heisst entweder "der Takt" oder "the clock". Aber schwachsinniges>Denglisch ist ja "in" :-(
Richtig, das habe ich auch gerade gedacht.
Aber da fällt mir wieder etwas ein, was ich von Dir gestern gelesen
hatte:
>Der Nutzen steht in keinem Verhältnis zum Aufwand.
Von den üblichen, meist namenlosen Dummschwätzern ist man Käse ja
gewohnt, von dir eher weniger.
Was sagt obiger Satz nun aus?
Aufwand/Nutzen >> 1
willst Du wahrscheinlich zum Ausdruck bringen.
Ah, jetzt fällt mir sogar wieder ein, um was es ging: BGA löten.
Also was schreiben wir in Zukunft? Vielleicht: Der Aufwand übersteigt
(überwiegt) bei weitem den Nutzen.
Gruß
Stefan
Offtopic:
Tja, wenn man englischshprachige Literatur liest und dann was schreibt
ist es halt so, dass man der World-Clock, der Master-Clock, der Clock
schreibt und nicht der World-Takt, der Master-Takt, der Takt. Ich selber
finde es zwar blöd (Denglisch), sehe aber nicht ein, wieso die Sache
meinen kreativen Prozess (und das ist er wohl) beeinflussen soll.
Wenn ich hier auch noch die Rechtschreibung und Grammatik, Schreibstil
und so weiter beachten müsste, dann würde ich nie zu Potte kommen. Ich
finde solche Kommentare einfach kontraproduktiv. Das gehört einfach hier
nicht rein, sondern entweder nach Offtopic (ups, was schreibe ich da?)
oder nach www.duden.de, wie Du, Falk, schon selber vorgeschlagen hast.
Das ganze "Der Dativ ist dem Genitiv sein Tod"-Gelaber macht mich
langsam müde.
Grüße,
Kest
>finde solche Kommentare einfach kontraproduktiv.
Ja, die meisten Leute hier sind eh lernresistent.
Ab und zu mal ein Tippfehler -- damit kann ich leben, die mache ich auch
selber. Aber wer seine Postings nur einfach so dahin schmiert, der denkt
und arbeitet meist auch so. Darauf kann ich verzichten.
Daher ist mein Algorithmus beim Lesen vom Postings:
if voller name then
counter = 3
elsif sinnvolle Abkürzung then
counter = 2
else
counter = 1
end
If gruss counter++
For each error #(Rechtschreibe- Grammatik-Fehler, schlechte
Formulierung)
counter--
end
if counter <= 0 return
Damit endet das Lesen oft schon bei der zweiten Zeile, man spart viel
Zeit und hat in der Regel nichts verpasst.
