Forum: FPGA, VHDL & Co. Aus dem Datenstreem Clock extrahieren


von Peter (Gast)


Lesenswert?

Ich suche eine Möglichkeit aus einem ankommenden Datenstrom (ohne 
Clock), ein Taktsignal zurück zu gewinnen. Es kann aber vorkommen, dass 
das Datensignal 42 Nullen oder Einsen aufweist. Hat jemand schon mit 
einem ähnlichen Problem zu tun gehabt? Kriegt man es in VHDL hin oder 
sind externe Bausteine unverzichtbar?

von Jan M. (mueschel)


Lesenswert?

Alles eine Frage der Geschwindigkeit. Wie hoch ist die Clock deiner 
Daten, wie hoch die der Logik?

Die Standard-Verfahren laufen meist so, dass beim Aufbauen der 
Verbindung ein festgelegtes Bitmuster gesendet wird, auf das dann 
synchronisiert wird. Besteht die Verbindung, kann ueberpruft werden, ob 
die Bitwechsel zu den berechneten Zeitpunkten passieren, falls nicht, 
muss neu synchronisiert werden. Das funktioniert natuerlich nur, wenn 
die Logik mehr als doppelt so schnell wie die Daten ist.

von Falk B. (falk)


Lesenswert?

@ Peter (Gast)

>Clock), ein Taktsignal zurück zu gewinnen. Es kann aber vorkommen, dass
>das Datensignal 42 Nullen oder Einsen aufweist. Hat jemand schon mit

Naja, nicht schön aber machbar. Ist alles eine Frage der Takttoleranzen.

>einem ähnlichen Problem zu tun gehabt?

Ja.

>Kriegt man es in VHDL hin oder
>sind externe Bausteine unverzichtbar?

Kommt auf die Datenrate an. 1 Mbit/s oder 100 Mbit/s?

MFG
Falk

von Stefan W. (wswbln)


Lesenswert?

Hmm, ein Datenstrom mit 42 aufeinanderfolgenden Nullen oder Einsen ist 
für die Taktrückgewinnung nicht sehr optimal. Normalerweise fährt man 
bei sowas noch mit einer zusätzlichen Codierung über die Leitung (8B/10B 
ist z.B. weit verbreitet). Bist Du mit Deinem Datenstrom evtl. schon 
hinter solch einem CoDec? Von welcher Datenrate sprechen wir überhaupt? 
Kommst Du ggf. an das codierte Signal ran?

Ansonsten bleibt fast nur via PLL den Takt zu regenerieren und beim 
Aufsynchronisieren eine kürzere Zeitkonstante des Filters zu verwenden 
(-> rascheres Einrasten) als beim Normalbetrieb, wo Du zur Überbrückung 
der langen Lücken eine recht träge Regelung brauchst. Bei bekannter 
(Norm-)Datenrate (PDH, SDH, OCx, ...) kann man evtl. mit einem 
Quarzoszillator mit Zieheingang (haben meist +/- ein paar -zig bis 
hundert ppm) arbeiten, wie sie in der Telekommunikationswelt gerne 
verwendet werden. Für die Regelung gibte es hier auch fertige Bausteine, 
die man mit den in der Telekommunikationsdatenströmen immer irgendwo 
drinsteckenden 8kHz füttert und die dann die benötigte Taktfrequenz (im 
-zig/-hundert MHz Bereich) liefern. Da die aber recht träge arbeiten, 
kommt man um eine FIFO im Datenpfad nicht herum (und generiert die 
schneller/langsamer Signale für die Taktrückgewinnung oft aus dem 
FIFO-Füllstand).

HTH,
Stefan

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Wikipedia bleibt ziemlich theoretisch:
http://de.wikipedia.org/wiki/Taktr%C3%BCckgewinnung
hilfreich ist vielleicht der Begriff Costas-Loop:
http://de.wikipedia.org/wiki/Costas_Loop
vielleicht noch das Datenblatt zum 74HC297 "Digital phase-locked-loop 
filter"
http://pdf1.alldatasheet.com/datasheet-pdf/view/15581/PHILIPS/74HC297.html

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

"Costas Loop" liefert viele Links:

Practical Costas loop design
http://rfdesign.com/mag/radio_practical_costas_loop/

Regenerate Coherent Carriers From PSK Signals
http://mwrf.com/Articles/Index.cfm?Ad=1&ArticleID=9366

von Peter (Gast)


Lesenswert?

Eine Kodierung wie 8B/10B kann ich ausschließen, da die Daten ohne 
zusätzliche Vergewaltigung gesendet/empfangen werden müssen. Die 
Datenrate beträgt ca. 200 Mbit/s (SRD). Den 74HC297 kann man 
ausschließen, ist leider zu langsam. Wobei ich das Ganze eigentlich ohne 
externe Bausteine lösen wollte (habe dabei an Schieberegister, FFs und 
XORs gedacht).

von Falk B. (falk)


Lesenswert?

@ Peter (Gast)

>Eine Kodierung wie 8B/10B kann ich ausschließen, da die Daten ohne
>zusätzliche Vergewaltigung gesendet/empfangen werden müssen.

Warum?

> Die
>Datenrate beträgt ca. 200 Mbit/s (SRD).

SRD?

> Den 74HC297 kann man
>ausschließen, ist leider zu langsam.

;-)

> Wobei ich das Ganze eigentlich ohne
>externe Bausteine lösen wollte (habe dabei an Schieberegister, FFs und
>XORs gedacht).

???
Kann es sein, dass du ein bisschen naiv bist? Bii 200 Mbit/s kannst du 
den ganzen 74xx Kram vergessen. Selbst ein FPGA wird da zu kämpfen 
haben, nicht wegen der hohen Datenrate, sondern wegen der Nachbildung 
der Taktrückgewinnung in Logik. Ein Vollprofi könnte das hinbekommen, 
wobei das einiges an Zeit kosten wird. Alle anderen nehmen besser 
fertige ICs dafür, so es sie gibt.

MFG
Falk

von Peter (Gast)


Lesenswert?

Hallo Falk.

>> Warum?
Weil es eine Vorgabe ist.

>> SRD?
Ich meinte natürlich SDR und nicht SRD :)

>> ;-)
Ja Sorry 74 sagt mehr als 1000 Worte, habe mir das Datenblatt trotzdem 
angeschaut.

>> ???
Wieso naiv, eher neugierig. Klar findet man für sowas genug Chips. Was 
die Geschwindigkeit angeht, habe ich mir auch schon überlegt. Wenn es 
8B/10B kodierten Daten wären, wäre so eine Taktrückgewinnung an sich 
kein Problem und würde sich in der Tat mit wenig Logikaufwand 
realisieren. Ich habe mir schon viele Ansätze durch den Kopf gehen 
lassen, z.B. ein halber Takt, denn man durch eine DCM wieder verdoppeln 
könnte etc.

Aber ok, das Thema hat sich dann erledigt, ein externer IC ist 
wahrscheinlich die beste Lösung.

von Falk B. (falk)


Lesenswert?

@ Peter (Gast)

>Ich meinte natürlich SDR und nicht SRD :)

SDR? Software Defined Radio?

>die Geschwindigkeit angeht, habe ich mir auch schon überlegt. Wenn es
>8B/10B kodierten Daten wären, wäre so eine Taktrückgewinnung an sich
>kein Problem und würde sich in der Tat mit wenig Logikaufwand
>realisieren. Ich habe mir schon viele Ansätze durch den Kopf gehen

Haha, selten so gelacht. Auch das ist alles andere als trivial, wenn 
gleich man um eiiges bessere Startbedingungen hat.

MFG
Falk

von T.M. (Gast)


Lesenswert?

>>Ich meinte natürlich SDR und nicht SRD :)

>SDR? Software Defined Radio?

Single Data Rate? ;-)

von high_speed (Gast)


Lesenswert?

200Mbit/s sind schon eine ganze Menge für eine rein digitale
Taktrückgewinnung in einem FPGA.

Für ein Projekt habe ich auf einem Cyclone FPGA EP1C12F324C7
(f_max = 320MHz) eine maximale Datenrate von 144Mbit/s abtasten können.

Eine Nachsynchronisation im Frame war aus Geschwindigkeitsgründen
allerdings nicht mehr möglich, die Logikfade für den Abtastpunkt
ließen es nicht zu. Mehr als eine Vierfachabtastung mit
phasenverschobenen Takten konnte auch nicht realisiert werden.

Um die Phasenlage der Daten zu Rekonstruieren hatte ich vor den 
Datenframe eine Preamble, und der Frame war auf eine maximale Länge 
beschränkt.

Wenn eins von den beiden Dingen schon nicht möglich ist, und man muss
auf unbekannte Daten Synchronisieren vergesse es gleich, oder
bestelle schon einen "Hochleistungs-FPGA".

Ansonsten gibt es spezielle FPGAs mit eingebauter CDR (Clock Data 
Recovery).

http://www.xilinx.com/products/design_resources/highspeed_design/resource/cdr.htm
ist aber 8B/10B

MfG
Holger

Bitte 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
Noch kein Account? Hier anmelden.