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
Wenn FPGA dann kannst du es mit DDS oder DCM vesuchen. Damit lassen sich so ziemlich alle Frequenzen erzeugen! Gruss Stanko
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
Ein VCXO ist falsch fuer Datenuebertragungen, denn er bietet eine genauigkeit, die nicht gefragt ist. Ein LTC6900 ist moeglicherweise passender.
> 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.
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.