Hallo zusammen,
Ich will eine Datenübertragung mit 20 Mbit in einen fpga einlesen
Dazu muss ich den Takt aus den Daten wiedergewinnen.
Ich will das so realisieren:
http://www.xilinx.com/support/documentation/application_notes/xapp250.pdf
Ich finde jedoch nirgends einen VCO der mir 20 Mhz Liefert bei max 3,3 V
Ich binn noch über den TLC1799 gestolpert, der wäre ideal, lässt sich
aber nicht mit spannung einstellen, sondern einem widerstand.
Kennt jemand einen Passenden Baustein ?
Wie wär's mit einem MAX2606?
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2323
Die VCO-Frequenz ist zwar einiges höher aber es sollte ja kein Problem
sein, diesen z.B. auf 80 MHz laufen zu lassen und den Tackt im FPGA
durch vier zu teilen...
=> Exaktes 50 :50 DutyCycle
=> Reduziertes PhaseNoise
Richtig, maximal 18 Mhz und das auch nur bei 6 Volt, der geht nicht
Hab aber folgendes gefunden: MK3721
http://www.idt.com/products/getDoc.cfm?docID=7957305
Da kommt noch ein Quarz dran, und schon hab ich einen VCXO. Hat noch
jemand eine andere Idee ? wenn nicht nehm ich den
Michael Sauron schrieb:
> Da kommt noch ein Quarz dran, und schon hab ich einen VCXO.
Du sprachst von VCO. Genügen dir denn die ±1.1E-4 als Ziehbereich?
Der sender sendet auf 20 Mhz, die von einem Quartz kommen. Der VCXO
bekommt auch einen 20 Mhz Quartz, und sollte sich dann auf eine
Definierte Phasenlage Regeln lassen. So zumindest meine Theorie. Ich
denke das der VCXO für meinen Anwendungsfall sogar besser geeignet ist,
als ein VCO, da ich ja nur die Differenz der Beiden Quartze nachregeln
muss.
Praktisch habe ich jedoch noch nie etwas mit vco/vcxo gemacht, und binn
mir daher ein wenig unsicher
> Wenn FPGA dann kannst du es mit DDS oder DCM vesuchen.
Ich muss ja aus einem Datenstrom den Takt wiedergewinnen, das geht mit
einem DCM nicht, da ich nicht mit jedem Takt eine Änderung auf der
Datenleitung habe.
Hallo Michael,
ein VCXO, z.B. mit dem MK3721, ist schon der richtige Ansatz für Dein
Problem. Du solltest mit einer digitalen PLL im FPGA den eintreffenden
Bittakt mit dem Takt des VCXOs vergleichen, ein digitales Loop-Filter
rechnen (z.B. IIR 1. Ordnung) und die Stellgröße zum Nachziehen per PWM
über ein Pin des FPGAs ausgeben. Dieses PWM-Signal mußt Du natürlich
über ein analoges Filter zu einer analogen Stellspannung für den VCXO
umwandeln. Achte bitte darauf, daß die Zeitkonstante der Regelschleife
durch das interne Loop-Filter bestimmt wird, so bleibt sie
programmierbar. Die Grenzfrequenz des externen analogen Filters sollte
höher liegen und nur der Unterdrückung des PWM-Taktes dienen. Dieser
Takt muß daher hoch genug sein, damit das analoge Filter nicht die
Zeitkonstante der Regelschleife bestimmt.
Viele Grüße und viel Erfolg!
Gerrit, DL9GFA
> den eintreffenden> Bittakt mit dem Takt des VCXOs vergleichen
Meiner Meinung nach, liegt genau hier die Herausforderung, denn der
Datenstrom kann max 5 takte lang den selben Pegel haben.
Über die Realisierung im FPGA muss ich mir noch mal ordentlich den Kopf
zerbrechen.
Hallo Michael,
jetzt habe ich erst gesehen, daß Du eine Application Note angegeben
hattest, die bereits eine digitale PLL vorschlägt, ähnlich wie ich es
beschrieben habe...
Wenn Du die Synchronisation nur für die Abtastung des eintreffenden
Bitstromes benötigst, also um immer die "Mitte" des Bits zu treffen,
aber auf der anderen Seite keine Zeit für "echte" Signalverarbeitung
hast, könntest Du mit einem sogenannten "early/late"-Ansatz weiter
kommen. Hierbei geht es darum, die Flankenwechsel zu beobachten (Takte
dazwischen zählen) und den tatsächlichen Wechsel im zeitlichen
Erwartungsfenster auszuwerten. Wenn der Wechsel zu früh kommt, wird die
angenommene Bitperiode (Taktzahl) um einen Takt verkürzt. Wenn die
Flanke zu spät kommt wird sie um einen Takt verlängert. Wenn kein
Flankenwechsel stattfindet, wird nichts verändert und auf das nächste
Erwartungsfenster gewartet. Nach der Hälfte der aktuellen Bitperiode
(Anzahl Takte zwischen den Flanken) wird das Bit abgetastet (hoffentlich
in der Mitte ;o).
Dieser Ansatz lebt davon, daß der Bitstrom schön Gleichanteilsfrei ist,
also Nullen und Einsen ziemlich gleichverteilt sind (eigentlich sollen
vor allem viele Wechsel stattfinden), was durch eine entsprechende
Kodierung üblicher Weise sicher gestellt ist.
Deine fünf Takte pro Bitperiode sind allerdings auch für diesen Ansatz
sehr knapp; oft findet man sechzehn. Wenn die Flankenwechsel im
schlimmsten Fall, bzw. in der ungünstigsten Bitfolge, nicht zu weit
auseinander liegen, könnte es dennoch funktionieren. Wenn zu lange kein
Flankenwechsel kommt, läuft der Abtastzeitpunkt davon durch die
Akkumulation des zeitlichen Abtastfehlers über mehrere Bits, ohne
Möglichkeit der Korrektur.
Was hälst Du davon?
Viele Grüße!
Gerrit, DL9GFA
Hallo Michael,
das von Gerrit vorgeschlagene Verfahren zur Taktrückgewinnung habe ich
vor einiger Zeit selbst eingesetzt; mit acht Takten pro Bit funktioniert
es bereits ziemlich gut, der Schritt auf 16 Takte pro Bit bringt aber
noch eine erkennbare Verbesserung. Die weitere Verbesserung bei einer
Steigerung der Auflösung auf 32 Takte pro Bit fiel im Vergleich dazu
deutlich kleiner aus.
Der klassische "Early/Late"-Ansatz bringt übrigens von sich aus einen
merklichen Jitter in die Abtastung ein, weil der Algorithmus
prinzipbedingt jeden Flankenwechsel entweder als "zu früh" oder als "zu
spät" erkennt, der Abtastzeitpunkt also mit jeder Flanke um einen Takt
springt. Oft macht das viel mehr aus als das zeitliche
Auseinanderdriften von Sendertakt und Empfängertakt. Deshalb ist es
sinnvoll, den Algorithmus so zu erweitern, daß er zwischen "zu früh" und
"zu spät" auch ein Zeitfenster für "paßt gut" hat, d.h. die Phase des
Abtasttaktes unverändert läßt, wenn die erkannte Flanke in dieses
Fenster fällt. Den Nutzen dieser Erweiterung kann man im Augendiagramm
sehr gut erkennen.
Grüße
Thomas
Hallo Michael und Thomas,
Danke, Thomas, für die Ergänzungen. Das Hin- und Herspringen der
Taktanzahl pro Bitperiode ist natürlich größer als die Abweichung von
Sende- und Empfangstakt, aber nicht wirklich ein Problem. Bei fünf
Takten Zeitauflösung pro Bit wirst Du wahrscheinlich kein sinnvolles
"paßt gut"-Zeitfenster finden. Weil die Abweichung durch die groben
Quantisierungsschritte zu groß sind, wird schon in den nächsten 1...2
Bit eine Korrektur nötig sein.
Ich kenne Michaels Applikation nicht, aber manchmal benötigt man diesen
Takt auch für weitere Zwecke, z.B. wenn AD- oder DA-Wandler-Takt an
diesen Bittakt geknüpft sind (weil Abtastwerte des Senders übertragen
werden). Der große Jitter würde die Dynamik der Wandlung ruinieren. Die
genaue Bitperiode ist durch Tiefpaßfilterung der jitternden
Periodendauern ermittelbar (das Hin- und Herschalten ist quasi eine PWM
mit dem genauen Wert). Mit einem IIR-Filter 1. Ordnung (nur eine
Multiplikation und Addition, ggf. mit 2^x-Koeffizient auf Bitshift und
Addition vereinfachbar) kann das auch mit den wenigen Zyklen pro Bit
realisiert werden. Da die Takte von Sender und Empfänger einen
konstanten Versatz haben, der sich höchstens über Temperatur sehr
langsam ändern, kann die Zeitkonstante der Mittelung ruhig sehr groß
sein (Wortbreite des IIR beachten!). Das initiale Einschwingen dauert
dann aber entsprechend lang, oder man schaltet die Grenzfrequenz zum
Einschwingen hoch.
Ob mit diesen Mitteln der Takt jitterarm genug wird, hängt von der
geforderten Dynamik der AD- oder DA-Wandlung ab. An die 100dB wird man
bestimmt nicht kommen.
Viele Grüße!
Gerrit, DL9GFA
Michael Sauon schrieb:
>...der Datenstrom kann max 5 takte lang den selben Pegel haben.
Aha ich verstehe, es handelt sich hierbei um einen 8B10B Decoder!
Wenn dies der Fall sein sollte dann wirst du einen VCO mit einem LPF
dahinter in VHDL realisieren müssen. Schau mal bei Xilinx auf der
Homepage nach "8B10B" glaube unter der Rubrik CPLD.
