www.mikrocontroller.net

Forum: FPGA, VHDL & Co. 100 MBit Manchester Decoder in FPGA


Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich möchte in einem FPGA ein 100 MBit Manchester Signal decodieren.
Das Grundlegende Prinzip ist klar. Mit dem ersten Wechsel des 
übertragenen Datums kann die relevante Flanke des codierten Signals 
erkannt werden (also die Flanke, die das Bit repräsentiert).
Für dieses Verfahren ist es allerdings nötig, bei jeder auftretenden 
Flanke des Signals für ca. 2/3 der Dauer eines Bits zu warten, und dann 
zu sampeln. So kann gewährleistet werden, dass man die Relevante Flanke 
"erwischt".
Mein Problem ist nun die Realisierung dieser Zeit. Bei 100 MBit sind das 
ca. 7ns. Das heisst, ich darf nach Erkennen eines Singalwechsels auf der 
Datenleitung erst ca. 7ns später den "Wert" von der Leitung lesen. Diese 
Zeit könnte man durch eine Verkettung von Invertern machen, was aber den 
Nachteil hat, dass die Zeit sehr instabil bei Temperatur ist. Ausserdem 
ist bei jedem neuen Routing die Zeit ein wenig anders, als davor. Also 
nicht stabil und nicht reproduzierbar.
Die zweite Möglichkeit wäre über einen kleinen Zähler. das Problem ist 
dann aber, dass der Zähler mit einer recht hohen Frequenz betrieben 
werden muss. Abtastung nach 5ns ist zu früh und Abtastung nach 10ns ist 
zu wenig.. Ausserdem muss beachtet werden, dass mit dem Abtasten des 
Eingangssignals sich ein Jitter von einer Periodendauer der 
Zählerfrequenz ergibt. Beachtet man alle Rahmenparameter, so kommt man 
darauf, dass es mur sinnvoll funktionieren kann, wenn die Zählerfrequenz 
mindestens 400 MHz ist (eher höher). Das ist natürlich schon recht flott 
für einen (billigen) FPGA.
Hat da jemand noch ne Idee für ne ganz andere Herangehensweise? Oder wie 
man vielleicht in einem FPGA einen Delay von ca. 7ns stabil hinbekommt?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ordendlich geht sowas meiner Meinung nach nur mit einer 
Abtast-Frequenz die ein ganzes Stück über der Signalfrequenz liegt. Hast 
du ja schon erkannt. Wobei man ein stabiles Delay auch mit einer DCM auf 
die Reihe bekommt. Da könntest du z.B. den um 270° phasenverschobenen 
100Mhz Takt benutzen, die Flanken sind dann 7,5ns auseinander.

Autor: Lymangood (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hastdu ja schon erkannt. Wobei man ein stabiles Delay auch mit einer DCM auf
>die Reihe bekommt. Da könntest du z.B. den um 270° phasenverschobenen
>100Mhz Takt benutzen, die Flanken sind dann 7,5ns auseinander.

Wozu nützen ihm die 270° Grad Phasenverschiebung wenn das Signal von 
aussen kommt?

@Schrotty
Da reichen schon 300 Mhz Samplefrequenz. Anders kriegst du es nicht hin. 
Vergiss die erste Lösung.

Autor: bko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Schrotty

nur so ne schnelle Idee: evtl. ginge dies:
das Manchester Signal mit >=200 MHz in
Schieberegister schieben.
Die Schieberegisterausgaenge dann Parallel
auswerten etwa so:
 1x oder 2x gleicher wert = kein signal wechsel
 3x oder 4x gleicher wert = signal wechsel.

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da das Signal von aussen kommt, müsste man das nicht vorher 
synchronisieren, wegen Metastabilität? Mit welcher Frequenz müsste man 
dann den Synchronisierer betreiben?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig, die 270° sind dann sinnlos. Naja, war so ein Schnellschuss zum 
Feierabend. Wenn, dann müsste man die DCM irgendwie auf das Signal 
synchronisieren.

Bleibt, wie ich schon schrieb, als saubere Lösung die Überabtastung.

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal dür die rege Beteiligung.

@Lymangood:
ich würde interessieren, wie das mit 300 MHz funktionieren kann?
100 MBit bedeutet, dass ein Datum 10 ns "lang" ist.
Wenn ich nun im "hinteren" Drittel des Datums abtasten muss, dann muss 
das bei ca 7ns der Fall sein.
Bei 300 MHz könnte ich mit einer einer Auflösung von 3,3ns zählen.
Das heisst: Zählen: = 0 - 1 - 2  und beim Übergang von 1 nach 2 
abtasten.
Das wäre dann nach 6,6 ns.
Da aber der Zähler und die Daten nicht phasengleich kommen, muss ich 
davon ausgehen, dass u.U. nach dem Auftreten des Signalwechsels am 
Eingang erst eine komplette Zählperiode verstrecht (3,3ns) bis der 
Zähler gestartet wird.
Wennn das der Fall ist, dann taste ich am ganz am Ende des Bits ab.
Auch wenn das Signal vorher mit 300 MHz gesampled wird, tritt das 
Problem auf, nur dass sich hier eben die Dauer des Bits um eine 
Zählerperiode jittert.
Oder seh ich da was falsch?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich komme bei der Aussage "2/3" auch rechnerisch auf 300MHz mit 
Drittelteilung. Wenn das nicht geht -> Parallelabtasung mit 
phasenverschobenen Clocks und verzögerter Auswertung.

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klar rechnerisch kommt man da drauf, aber das gikt ja dann nur, wenn 
eingangssignal und Zählertakt in Phase sind. Das heisst, der zähler 
startet dann, wenn die Flanke am Eingangssignal erkannt wird.
Sind diese nicht in Phase, dann zählt der Zähler irgendwann zwischen 0 
un 3,3 ns NACH eintreten der Flanke los und genau diese Unschärfe wäre 
ja dann schon verhängnisvoll, denn dann ist der Zählerstand 2 in einem 
Zeitraum zwischen 2 x 3,3ns = 6,6ns und 2 x 3,3ns + 3,3ns (phasenlage) = 
9,9ns erreicht. Und bei 9,9 ns ist es zu spät.
Das ist mein Problem.

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Letztendlich geht es darum, aus einem 100 MBit Manchester-Code den Takt 
und die Daten zurückzugewinnen. Die Methode mit der Wartezeit (egal wie 
sie realisiert wird) ist sicher nur eine Methode.
Taktrückgewinnung ist ja aber auch über eine PLL möglich.
Hat da jemand Erfahrung damit, wie sowas in einem FPGA funktioniert?
Mein Problem ist dabei, dass mir nicht klar ist, wie sich die PLL 
verhält, wenn ich ihr als Eingangssignal den Datenstrom gebe. Denn der 
ist ja nicht immer gleich. Daher geh ich davon aus, dass die PLL auch 
nicht "brav" im Takt arbeitet, wenn ich ständige Datenwechsel etc am 
Eingang der PLL habe.

Weiss da jemand was drüber?

Autor: Jing G. (kelly2009)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schrotty schrieb:
> Letztendlich geht es darum, aus einem 100 MBit Manchester-Code den Takt
> und die Daten zurückzugewinnen. Die Methode mit der Wartezeit (egal wie
> sie realisiert wird) ist sicher nur eine Methode.
> Taktrückgewinnung ist ja aber auch über eine PLL möglich.
> Hat da jemand Erfahrung damit, wie sowas in einem FPGA funktioniert?
> Mein Problem ist dabei, dass mir nicht klar ist, wie sich die PLL
> verhält, wenn ich ihr als Eingangssignal den Datenstrom gebe. Denn der
> ist ja nicht immer gleich. Daher geh ich davon aus, dass die PLL auch
> nicht "brav" im Takt arbeitet, wenn ich ständige Datenwechsel etc am
> Eingang der PLL habe.
>
> Weiss da jemand was drüber?

hallo,

ich möchte dich gern fragen, ob du das problem schon gelöst hast. Wenn 
ja, wie hast du das gemacht? Ich habe jetzt das selber Problem.
Danke im Voraus.

mfg
kelly

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Kelly!

Da ich im letzten halben Jahr an was anderem dran war, hab ich mich 
nicht mehr weiter mit dem Thema befasst.. Allerdings kocht das gerade 
wieder hoch und ich hab immer noch keine gute Lösung.

Und du hast auch keinen "verwertbaren" Ansatz?

Autor: Jing G. (kelly2009)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Schrotty ,

ich habe was auf der Seite von xilinx gefunden. Ich weiss nun nicht, ob 
es wirklich funktioniert. Probiert habe ich schon, aber es gibt noch 
Fehler.
Vielleicht kannst du auch mal anschauen. Das ist das Paper von XAPP225

mfg
Kelly

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht interessant aus. Ich werd mir das mal bei Gelegenheit genauer 
anschauen..
Vielleicht lässt sich ja auch die Idee mit dem "aus eins mach vier" 
aufgreifen und somit eine "Zeitbasis" für die Abtastung generieren, die 
dann bei 2/3 des Bits liegt.
Kurzum: mit den vier Takten wird gesampelt und je nachdem, welcher der 
Takte die Daten-Flanke erkennt, entscheidet eine Logik, bei welcher 
Kombination aus den 4 Taktdomains dann letztendlich das Sampling der 
Daten vollzogen wird...

Kann man ja mal drüber nachdenken, wie sowas aussehen könnte

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

XAPP225 funktioniert nur dann, wenn du im FPGA, mittels dessen du den
Manchester-Datenstrom empfängst, auch Zugriff auf den Quelltakt (also 
den Takt, mittels dessen der Datenstrom generiert wurde) hast ?

Sobald du jedoch mit einer ppm-Abweichung (Ziel-Takt zu Quell-Takt) 
arbeiten musst (bspw. wurde der Mancher-Datenstrom auf einem anderen 
Board generiert, anderer Quarz), kommst du mit dem XAPP225-Ansatz nicht 
weit.

Gruß,
SuperWilly

Autor: Michael Sauron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mich auch mal mit dem Thema beschäftigt. von Xilinx gibt es 
noch das XAPP224 und das XAPP250.

Interesannt ist das XAPP250 dort wird ein VCO vom FPGA geregelt und 
somit auf den Takt synchronisiert. Im prinzip klappt das so: eine Flanke 
des Datensignals wird mit einer Flanke des VCO verglichen, je nach 
Ergebnis des Vergleichs wird der VCO dann nachgeregelt. Ist grad keine 
Flanke bei den daten, wird der VCO einfach so gelassen, wie er ist.

Sauron

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sauron,

konntest du das, was in XAPP250 beschrieben ist, auch tatsächlich 
implementieren ?

Gruß,
SuperWilly

Autor: Michael Sauron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das war mir zu viel Hardwareaufwand , ich übertrage einen seperaten Takt 
und kann mir deshalb den aufwand sparen. Wenn ich mal genug zeit habe, 
will ich mich damit weiter beschäftigen.

Wieso fragst du ?

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

war nur neugierig gewesen, ob das mit der zusätzlichen Hardware geklappt 
hat.
Hast du noch die VHDL-Ressourcen dazu ? Die wurden ja laut Change 
History
rausgenommen.

Gruß,
SuperWilly

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der APPNote ist auch von einer Delayline die Rede. Und das würde 
mich intressieren, wie man eine selbige im ns-Bereich so implementiert, 
dass sie einigermassen temperaturstabil ist etc.
Genau da liegt ja der Hase im Pfeffer....

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schrotty schrieb:
> Bei der APPNote ist auch von einer Delayline die Rede. Und das würde
> mich intressieren, wie man eine selbige im ns-Bereich so implementiert,
> dass sie einigermassen temperaturstabil ist etc.
> Genau da liegt ja der Hase im Pfeffer....

Wir machen das mit solchen Bausteinen: 
http://www.datadelay.com/asp/prog.asp übrigens auch im ps-Bereich.

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Christian,

Danke für deinen Hinweis. Ich hab auch schon über die Verwendung 
monolithischer Delaylines nachgedacht, aber auch da muss man beachten, 
dass der Delay von der synchronen Logik im FPGA über die Pins und 
zurück, sich zu dem Delay der Delayline addiert. Das Gesamte Delay 
sollte sich über die gesamte Temperatur in einem Bereich von 6,5.. 8,5ns 
bewegen, um noch ein wenig "Reserven" zu haben.
Die Pulsdauer des zu verzögernden Impuls ist nur ca. 5ns lang.

Das Problem ist einfach, dass ich im FPGA keine zuverlässige Aussage 
über den Zusammenhang von Temperatur und Laufzeit bekomme.
Und wenn der Hersteller z.B. irgendwann auf einen anderen (schnelleren) 
Prozess umstellt, dann wäre die von mir schön hingetrimmte Zeit wieder 
beim Teufel, ohne dass ich was davon mitbekomme..

Das sind mir einfach zu viele "Unbekannte" für ein Produkt, das nachher 
in großen Stückzahlen laufen wird.

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und das würde mich intressieren, wie man eine selbige im ns-Bereich so 
>implementiert, dass sie einigermassen temperaturstabil ist etc.

Also zumindest müsstest du die Platzierung der "Delay-LUTs" mit einem
Place-Constraint festnageln, und zwar so, dass die LUTS alle beisammen 
liegen. Dann sollten beim Routen keine seltsamen Umwege genommen werden.
Trotzdem injizierst du Jitter, da "Logic-Trees" beim Routen verwendet 
werden.
Der Delay-LUT-Block sollte weiterhin möglichst nahe am "Rand" platziert 
werden, da das Routing vom Pin kommend natürlich auch möglichst 
deterministisch sein muss.

Gruß,
SuperWilly

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja genau diese Gedanken hab ich mir auch schon gemacht und das 
funktioniert auch alles wunderbar in der Theorie und auch sogar bei mir 
hier auf dem Schreibtisch in Form eines Prototypen.

Wie gesagt, ich hab einfach nur Bauchschmerzen, was passiert, wenn der 
komplette Temperaturrange durchlaufen wird, welche Toleranzen die 
Laufzeiten der LUTS von Exemplar zu Exemplar haben und vorallem, dass 
ich es ja nichtmal mitbekomme, wenn der Hersteller durch 
prozessumstellung die LUTS schneller macht und auf einmal mein gesamtes 
Delay zu klein ist.

Daher suchte ich eben nach einer möglichkeit, sowas komplett synchron zu 
lösen, denn dann hab ich diese ganzen Sorgen los..

Oder ich geh gleich auf nen ASIC

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, das ist doch Bastelmurks mit solchen asynchronen Sachen. Leg das 
mal in den Klimaschrank, da wirst du dich wundern. Und bei der nächsten 
Version des ISE ist wieder alles anders.

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt Christian, das ist BASTELMURKS (das war mir schon bewusst, bevor 
ich den Beitrag hier verfasste) und genau deswegen such ich hier nach 
ner Lösung, die KEIN Bastelmurks ist..
Dein Vorschlag mit den externen Delaylines ist aber leider auch nur 
Bastelmurks, da genauso asynchron und ungenau. Okay, sie ist deutlich 
teurer als die reine FPGA-Lösung :-)

Wie du ja selbst sagtest: Alles asynchrone ist in diesem Zusammenhang 
Murks.

BTW: Was die ISE macht, ist mir egal, ich werd nicht auf ein 
Xilinx-Target gehen :-)

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man müsste zusätzlich noch Delay-Constraints definieren, die Min- und 
Max-Delays überprüfen. Bin mir aber nicht sicher, ob man diese 
Constraints überhaupt definieren kann, zumal sie "nicht-getakteter" 
Natur sind.

Gruß,
SuperWilly

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja das müsste man auf jeden Fall festlegen. Na ja ich überleg mal 
weiter, ob´s vielleicht doch ne tricky Lösung gibt, die synchron ist.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schrotty schrieb:

> Dein Vorschlag mit den externen Delaylines ist aber leider auch nur
> Bastelmurks, da genauso asynchron und ungenau. Okay, sie ist deutlich
> teurer als die reine FPGA-Lösung :-)

Naja, so instabil wie interne Gatter-Laufzeiten sind die nicht. Aber die 
Synchronisierung ist weiterhin das Problem. Sowas ähnliches bereitet mir 
hier auch Kopfzerbrechen: Ein ADC-Takt soll mit Delay-Line variabel 
verschoben werden können. Allerdings muss dazu ein Stück Logik im FPGA 
mit dem verschobenen Takt laufen, und ein anderes Stück Logik mit dem 
Ursprungstakt.

> Wie du ja selbst sagtest: Alles asynchrone ist in diesem Zusammenhang
> Murks.

In der Regel ja. Da es nicht 100% vorhersagbar ist.

> BTW: Was die ISE macht, ist mir egal, ich werd nicht auf ein
> Xilinx-Target gehen :-)

Naja, das ist ja mal unabhängig davon. War ja nur ein Beispiel.

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Naja, so instabil wie interne Gatter-Laufzeiten sind die nicht.

Nichtmal darüber haben wir eine gesicherte Aussage aus dem 
FPGA-Datenblatt. Und selbst, wenn das so wäre, dann addiert sich der 
Delay ja immer noch aus den Laufzeiten im FPGA (Pins) und der Delayline. 
Und bei 7ns "Wunschdelay" splielt die Laufzeit durch die Pins schon eine 
nicht unerhebliche Rolle.

um 7ns delay zu bekommen, darf ich z.B. nur eine 5ns delayline nehmen, 
wenn die Pins je 1ns delay haben. Und über diese 2x 1ns delay kann man 
wiederum keine vernünftige Aussage machen --> voll doof :-(

Zu deinem Problem:
Wenn die beiden Logiken im FPGA nachher nicht miteinander verknüpft 
werden müssen, dann mach doch einfach zwei unterschiedliche clock 
domains auf..

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schrotty schrieb:

> um 7ns delay zu bekommen, darf ich z.B. nur eine 5ns delayline nehmen,
> wenn die Pins je 1ns delay haben. Und über diese 2x 1ns delay kann man
> wiederum keine vernünftige Aussage machen --> voll doof :-(

Naja, zumindest bei Xilinx steht im Datenblatt, wie lange ein Signal vom 
IOB FlipFlop zum Pin benötigt. Und für die inneren FFs steht auch so 
einiges in den Tabellen.

> Zu deinem Problem:
> Wenn die beiden Logiken im FPGA nachher nicht miteinander verknüpft
> werden müssen, dann mach doch einfach zwei unterschiedliche clock
> domains auf..

Natürlich sind die Logiken verknüpft, und auch bidirektional. Da muss 
ich mir noch was schlaues ausdenken....

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Natürlich sind die Logiken verknüpft, und auch bidirektional. Da muss
>ich mir noch was schlaues ausdenken....

Herzliches Beileid :-(

Und wahrscheinlich sind dei Takte so schnell, dass Sampeln nicht mehr in 
Frage kommt...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schrotty schrieb:
>>Natürlich sind die Logiken verknüpft, und auch bidirektional. Da muss
>>ich mir noch was schlaues ausdenken....
>
> Herzliches Beileid :-(
>
> Und wahrscheinlich sind dei Takte so schnell, dass Sampeln nicht mehr in
> Frage kommt...

Natürlich. Wenn´s einfach wäre, könnte es ja jeder, und wir wären 
arbeitslos. Zum Glück ist das keine essentielle Funktion, bis mir was 
schlaues einfällt, gehts trotzdem. Ist mehr ein akademisches Problem.

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Natürlich. Wenn´s einfach wäre, könnte es ja jeder, und wir wären
>arbeitslos. Zum Glück ist das keine essentielle Funktion, bis mir was
>schlaues einfällt, gehts trotzdem. Ist mehr ein akademisches Problem.

Stimmt auch wieder :-)
Bei mir ist es leider so, dass es DIE Funktion ist, mit der das ganze 
Verfahren steht und fällt :-( Da sollte das gut durchdacht sein.

Ich geh jetzt aber mal raus und lüft mir mein Hirn bei dem schönen 
Wetter.

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.