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
Hallo Sauron, konntest du das, was in XAPP250 beschrieben ist, auch tatsächlich implementieren ? Gruß, SuperWilly
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
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.
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.
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.