Hallo, ich habe vor eine kleine Übertragungsstrecke aufzubauen und hänge ein wenig an der Taktrückgewinnung aus dem digitalen Signal. Zusammengefasst: Ich habe das Signal empfangen, AC-gekoppelt, verstärkt und in Komperatoren gejagt, die mir dann digitale Signale auswerfen. Das ganze sollte irgendwie drei-Stufig (z.B. mit AMI-Code) codiert werden, sprich ich habe sicher alle paar Takte nen Wechsel, aber eben nicht immer. Bedeutet: ich brauche eine Taktrückgewinnung. Mir ist klar, dass da tendenziell ne PLL für zu verwenden ist, aber wie baut man diese am besten auf? Das ganze soll irgendwie durch einen CPLD/FPGA gehen, aber soweit ich das bislang verstanden habe kann ich die internen Hardware-PLLs eines FPGAs dafür nicht verwenden, da der Eingangstakt zu unregelmäßig und zu verjittert ist. Eine weitere mir bekannte Alternative ist es das halb analog mit einem DAC und einem VCO zu bauen. VCOs mit ausreichend hoher Taktrate sind jedoch relativ teuer (das System soll 10MBits schaffen) und dann muss ich das ja auch noch mit der Phasenverschiebung für den richtigen Abtastzeitpunkt hinbiegen. Also ein recht hoher Hardwareaufwand. Gibts da noch andere Möglichkeiten? Bin für konstruktive Ideen offen.
Mit einem sehr schnellen FPGA in Software lösen. Eine PLL lässt sich manuell leicht programmieren. Welche Ausgangsgenauigkeit brauchst Du? Wenn die Verarb im FPGA gemacht werden soll, ist das ab dann einfach möglich. Wenn der Takt nochmal draussen gebraucht wird, wird es komplex.
Falls ich nicht was übersehe sollte das viel elichter sein als mit pll etc. 10 Mbit -> 10 Mhz als grober Takt ist bekannt. -> Im FPGA z.b. mit 100 MHz abtasten. -> immer in der "Bitmitte" (in dem Fall nach fünf 100 MHz Takten) sampeln -> bei jeder Flanke im reinkommenden Datenstrom den Bitcounter counter resetten sodass man wieder in der bitmitte sampeln kann. solange die Trifft deiner beiden Takte im Verhältnis zu der Zeit ohne Flankenwechsel ist sollte das schon ausreichen. Hab was vergleichbares schonmal mit 50Mhz sampling und 3-4 Mhz Datensignal gemacht, hat zuverlässig funktioniert.
G. H. schrieb: > Mit einem sehr schnellen FPGA in Software lösen. Eine PLL lässt sich > manuell leicht programmieren. Welche Ausgangsgenauigkeit brauchst Du? > > Wenn die Verarb im FPGA gemacht werden soll, ist das ab dann einfach > möglich. > > Wenn der Takt nochmal draussen gebraucht wird, wird es komplex. Das hatte ich mir auch mal überlegt, aber die PLL ist dann doch nur so genau wie der schnelle Takt, den der FPGA zur Verfügung hat, also z.B. 100MHz. Also ich meine der Teiler der PLL kann doch dann nur ganzzahlig sein oder? Sehe ich da noch was falsch? @abc: Das nimmt sich ja jetzt nicht sooo viel von der Idee des Freiburgers. Aber das klingt auf jeden Fall einfach und würde wohl auch noch in einen kleinen CPLD passen :)
Fabian S. schrieb: > da der Eingangstakt zu unregelmäßig und zu verjittert ist. Was heißt das in Zahlen? Klar ist, dass du immer wieder mal z.B. für bis zu 3 Bits keine Taktflanke hast, aber woher kommt der Jitter?
Naja ich hab ne Übertragungsstrecke, da ist Rauschen drauf und das wird mit verstärkt und kommt auf die Komperatoren, die dann mal etwas früher und etwas später (jenachdem wie das Rauschen ist) einen Pegel-Wechsel durchführen. Also habe ich Jitter. Wie groß der genau ist kann ich leider nicht sagen, da ich das System noch nicht aufgebaut habe.
Hallo, das Zauberwort ist CDR (Clock and Data Recovery). Such mal nach "CDR FPGA"! Da gibt es jede Menge Treffer. Tom
Na das ist doch mal was handfestes. Da gibts sogar ein paar AN von Xilinx (XAPP250). Frage dir bei mir noch bleibt (habe die AN noch nicht gelesen) ist, ob das auch auf einem kleinen CPLD funktioniert. Hatte da so z.B. den XC2C64A im Auge.
Du brauchst doch den Takt garnicht außer zur Datengewinnung, demnach wäre eher Xapp224 hier angebracht, oder? Aber das geht im (klassischen) CPLD nicht, weil es eine pll vorraussetzt. Zudem ist das völlig mit Kanonen auf Spatzen geschossen bei 10 Mbit. Bei einer Uart käme auch niemand auf die Idee da den Takt zurückgewinnen zu wollen. Fabian S. schrieb: > Das nimmt sich ja jetzt nicht sooo viel von der Idee des Freiburgers. > Aber das klingt auf jeden Fall einfach und würde wohl auch noch in einen > kleinen CPLD passen von Software hatte ich im Post oben nie gesprochen, von Pll genausowenig, keine Ahnung wie es die gleiche Idee sein kann. Und in ein CPLD passt das oben genannte problemlos. Würde auf unter 10 Makrozellen schätzen.
Lothar Miller schrieb: > Fabian S. schrieb: >> da der Eingangstakt zu unregelmäßig und zu verjittert ist. > Was heißt das in Zahlen? > Klar ist, dass du immer wieder mal z.B. für bis zu 3 Bits keine > Taktflanke hast, aber woher kommt der Jitter? Jitter kommt von Rauschen auf dem Taktsignal und daher dass die Taktflanken nicht unendlich steil sind, die Eingangsstufen und Schmitt-Trigger schalten dann mit Jitter. PLL geht nicht, da der Takt unregelmäßig ist. DCMs und PLLs brauchen viele Takte um aufzusynchronisieren und zu locken. Fehlt der Takt rasteten die Dinger aus und es geht in die Hose Tackrückgewinnung fällt mir nur im Zusammenhang mit Serdes ein. Ist aber vermutlich übertrieben hier mit Gigabit Links anzufangen. Ich würde wie abc vorgeschlagen hat überabtasten und wie bei ner UART auf Start Bits aufsynchronisieren. Ich mache das gerade sehr erfolgreich mit 3-facher Überabtastung mit 100 MBit über 40 cm. Aber Quelle und Senke mit dem gleichen Takt gespeist, bei unterschiedlichen Takten ist höhere Überabtastung gefragt. Man kann ausrechenen wann man mit Start Bits neu aufsynchronisieren muss.
abc schrieb: > Bei einer Uart käme auch niemand auf die Idee da den Takt zurückgewinnen > zu wollen. Bei einer asynchronen Übertragung wie einer UART (das A steht für asynchron) gab es aber mal die Faustregel der 16fachen Überabtastung. Durch Einsynchronisieren kommt man 8fach vielleicht 4fach aus. Viele Grüße Tom
Thomas Reinemann schrieb: > gab es aber mal die Faustregel der 16fachen Überabtastung. > > Durch Einsynchronisieren kommt man 8fach vielleicht 4fach aus. Benötigt werden 2x, oder? - Einsynchronisieren kostet aber keine Frequenzreserve. ?
Ich hab zum Beispiel in einer Anwendung 8Mbit/s Nutzdaten Manchester codiert, also dann 16 Mbit/s mit 64Mhz abgetastet laufen. Als Sync für ein Bit alle 32 Bit die Manchester Codierung verletzt. Das geht zuverlässig über zig m Glasfaser.
Da aufgrund verschiedener Faktoren eine 8B10B oder sonstige Kodierung nicht möglich ist und ich ja mal den Anfang finden muss. Außerdem laufen Sender und Empfänger völlig asynchron.
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.