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?
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.
>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.
@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.
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?
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.
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?
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.
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.
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?
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
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?
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
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
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
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
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 ?
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
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....
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.
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.
>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
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
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.
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 :-)
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
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.
>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..
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....
>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...
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.
>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.
