www.mikrocontroller.net

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


Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht 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/15...

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: T.M. (Gast)
Datum:

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

>SDR? Software Defined Radio?

Single Data Rate? ;-)

Autor: high_speed (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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/hi...
ist aber 8B/10B

MfG
Holger

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.