Hallo, für ein größeres Forschungsprojekt bin ich derzeit in der FPGA-Programmierung mit Spartan-6-FPGAs beschäftigt. Aktuell arbeite ich dort an einer seriellen Datenübertragung mit bis zu 160 MHz. Die Daten sind 8b10b bzw. BPM-kodiert, sodass keine zusätliche externe Clock-Leitung benötigt wird. Für den Laufzeitausgleich benötige ich für jeden Kanal (insgesamt bis zu 8 Kanäle pro FPGA) eine variable Delay-Line, mit der ich eine Auflösung von 100 ps bei maximal 10 ns Delay erreichen kann. Aktuell haben wir folgende Ansätze ausprobiert, die aber nicht so schön sind, da beide den Duty-Cycle der Signale zu stark verzerren: 1. IODELAY2 als variables Output-Delay mit dem Workaround aus AR34276. 2. Ausnutzen von Gatterlaufzeiten im FPGA und setzen mit RLOC-Constraint. Kennt jemand noch andere (und eventuell besser geeignete) Verfahren, um diese Signale passend zu verzögern? Gruß Marius
Willst du ankommende oder ausgehende Signale verzögern? Normal nimmt man dazu schon die IDELAY bzw. IODELAY. Allerdings sind die beim Spartan nicht kalibriert (temperatur- und spannungsstabil)wie beim Virtex, du müsstest die immer mal nachstellen. RLOC und Gatterlaufzeiten gehört in die Kategorie Bastelmurks.
Sind abgehende Signale. Dass RLOC und Gatterlaufzeiten in die Kategorie Bastelmurks gehören, weiß ich... Deshalb suche ich ja nach einer "schönen" Version einer Delay-Line. Gruß Marius
Schau dir mal das "variable phase shift" feature der DCM's an. http://www.xilinx.com/support/documentation/user_guides/ug382.pdf
Was hast du gegen das IODELAY einzuwenden? Brauchst du denn ein zur Laufzeit verstellbares Delay? Meistens reicht ein fixes, und wenn du die Constraints ordentlich setzt, stellt der das eigentlich selber passend ein. 160MBit/s ist ja nun noch keine Hexerei. Mit der DCM Lösung kannst du dann nur alle an dem DCM hängenden Ausgänge global einstellen. Und auch für die IODELAY im variable Modus gibts meines Wissens nur eine begrenzte Anzahl Ressourcen. Jedenfalls wars beim Virtex 4 so.
Gegen das IODELAY habe ich prinzipiell gar nichts. Aber leider lässt es sich nicht direkt als variables Output-Delay einsetzen und der Workaround von AR 34276 verzerrt den Duty-Cycle des Signals. Damit ist im Empfänger kein sauberes Clock-Recovery mehr möglich. Da der FPGA auf einer Steckkarte sitzt, die nachher in eine Kleinserie gehen soll, müssen die Delays auch variabel einstellbar sein. Jeder Kanal und jede Karte müssen frei einstellbar sein. Ziel wäre eine Auflösung von 100 ps. Aber wenn es nicht anders geht wäre ich auch mit 500 ps zufrieden. Schlechter darf es aber auf keinen Fall sein. Gruß Marius
Hm, das wird dann mit dem Spartan 6 nicht gehen. Vielleicht mit externen Delaylines. www.datadelay.com wäre ein Anlaufpunkt. Was ist denn das für eine komische Datenübertragung, die auf sowas angewiesen ist? Und müssen einzelne "Lanes" dort gegeneinander verschoben werden oder wie soll man sich das vorstellen? Wäre da nicht vielleicht die GTP Sache im Spartan 6 LXT was passendes?
Die komische Datenübertragung gehört zum ATLAS-Pixel-Detektor am LHC-Teilchenbeschleuniger. Im Detektor gibt es viele Pixel-Module, die getaktet und mit Daten versorgt werden müssen. Dies geschieht mit einem BPM-Datenstrom. Die einzelnen Pixel-Module sind über Glasfasern mit den Steckkarten verbunden. Die Glasfasern sind natürlich unterschiedlich lang. Damit aber alle Module synchron arbeiten, müssen die Takt- und Datensignale (über die auch Trigger-Informationen gehen) ausgeglichene Laufzeiten besitzen. Gruß Marius
Marius Wensing schrieb: > Die einzelnen Pixel-Module sind über Glasfasern mit den Steckkarten > verbunden. Die Glasfasern sind natürlich unterschiedlich lang. Damit > aber alle Module synchron arbeiten, müssen die Takt- und Datensignale > (über die auch Trigger-Informationen gehen) ausgeglichene Laufzeiten > besitzen. In dem Fall würde ich eine externe programmierbare Delayline bevorzugen. Schließlich beeinflußt die Verzögerung in erheblichen Maße die Messung. Kannst Du Längenausgleich auch am Pixel-Modul machen? Schließlich ändern sich die Längen nach dem Einbau nicht mehr, oder? Und weißt Du schon, wie Du das ganze System Kalibrieren willst? Evtl. kommst Du um das Problem herum, in dem Du ganz bewußt gleich lange Fasern verwendest. Um welche Längenunterschiede handelt es sich denn? Duke
Habe gerade Rücksprache mit meinem Kollegen gehalten. Das Problem der Glasfaserlängen ist nicht das einzige, wurde mir gerade gesagt. Es kommt auch noch darauf an, wie weit das Pixel-Modul vom Interaktionspunkt (da stoßen die Teilchen zusammen) weg ist. Dort muss ebenfalls nochmal ~1ns/m Laufzeit gerechnet werden. Wichtig für das Delay ist: 1. Auflösung von mindestens 500 ps 2. Der Duty-Cycle darf nicht verändert werden. 3. Programmierbar Leider ist diese Steckkarte teil eines riesigen Projektes. Auch die Hardware ist bereits fast fertig vorgegeben (eigentlich nur noch eine Prototypen-Revision). Daher möchte ich die Delay-Line möglichst im Spartan 6 realisieren. Externe Delays wären natürlich schön und einfach, aber das Hardware-Design ist eben nicht dafür ausgelegt. Gruß Marius
Da haben wir ja bald denselben Arbeitsort ... :) . Ich hab von der Spartan Architektur keine Ahnung, weil ich seit JAhren nur mehr mit Altera Zeug arbeite aber wäre es vllt möglich, den AR34276 Ansatz so zuerweitern, dass man da einen Takt rausschickt, den am Input variabel verzögert und damit die Ausgangslogik taktet, wobei man die Werte per asynchroner FIFO übergibt? Sofern das Taktsignal nach dem Loopback noch verwendbar ist, müsste das Duty Cycle Problem dann egal sein. lg
max 500ps ergibt ca. 10cm Faser (wenn ich mich da nicht verrechnet habe bei n~1.5), das sollte man schon so schneiden können. Und bei max. 10ns Bereich jeden Strang 2m länger machen und dann entsprechend zurück schneiden. Außerdem gibt es auch optische Delay Lines. Habe allerdings keine Ahnung welche Datenraten Fasern ... die verwenden oder was es für Optionen da gibt.
Matthias schrieb: > wäre es vllt möglich, den AR34276 > Ansatz so zuerweitern, dass man da einen Takt rausschickt, den am Input > variabel verzögert und damit die Ausgangslogik taktet, wobei man die > Werte per asynchroner FIFO übergibt? Sofern das Taktsignal nach dem > Loopback noch verwendbar ist, müsste das Duty Cycle Problem dann egal > sein. Interessanter Ansatz, den ich wohl mal in die engere Auswahl ziehe. An der Faser-Länge kann ich wahrscheinlich nichts mehr ändern. Das ist auch leider etwas weiter außerhalb meines Zuständigkeisbereichs. Ich hätte das Delay-Line-Problem auch lieber vom Tisch, indem es über die Faser-Länge gemacht wird, aber das ist aussichtslos, vermutlich. Gruß Marius
Hi zusammen, ich bin der Kollege. Die Faserlänge anzupassen ist nicht wirklich realistisch. Bei einer Länge von ca. 80m und dem Routing aus der Maschinerie lässt sich die Faserlänge nur schwer präzise fertigen. Hinzu kommt, dass die Fasern am Optischen Modul in 12er Ribbons in einer MT Ferrule vergossen sind (Die optischen Module arbeiten mit 12er VCSEL arrays) was ein sehr kostspieliger Prozess ist. Man sollte vielleicht noch erwähnen, dass dieses Delay tatsächlich schon realisiert ist. Es gibt einen custom ASIC der BPM encoding, Duty Cycle Adjustment und ein feines Delay auf das Signal anwenden kann. Aber gerade von diesen ASIC möchten wir weg, da er beim BPM encoding und beim hinzufügen des Delays den Duty Cycle derart verstellt, dass für jedes Delay Setting ein extrem umständliches Tuning zur Korrektur des Duty Cycles nötig ist. Die oben beschriebene Variante haben wir schon komplett in einen FPGA umgesetzt (MUXer Elemente als Delay) und getestet, mit dem Ergebnis, dass auch die Realisierung im FPGA eine Änderung im Duty Cycle mit sich bringt (ca. 50ps pro 300ps Delay) und dies das Tuning nicht vereinfachen würde. Daher suchen wir gerade nach einer Möglichkeit ein variables Delay auf ein Signal anwenden zu können, dass den Duty Cycle nicht über den Bereich von 45-55% ändert (ansonsten gibt es Probleme mit der Clock die aus beiden Flanken des BPM Signals dekosiert wird). Das IODELAY war hierbei vielversprechend, da es mit einer Art Shiftregister und Ringoszillatoren arbeitet und Cleanroom Implementationen sahen auch sehr gut aus. Nachdem es nun jedoch in das große Projekt miteingefügt würde, zieht es den Duty Cycle auf gut 65% (aber konstant, bei den anderen Lösung war es vom Delay abhängig), was nicht mehr in der Toleranz ist.
Hm, irgendwie verstehe ich immer noch nicht den Gesamtzusammenhang. Zu welcher Basis sollen die Ausgänge denn verzögert werden? Und sollen verschiedene Verzögerungen auf einem FPGA erfolgen oder haben alle Ausgänge eines FPGA immer die gleiche Verzögerung? Ist der Spartan 6 der Sender? Und wer ist der Empfänger? Kann der kein Delay implementieren? Woher beziehen die verschiedenen Sender ihre Referenz? Wird da zu einem externen Takt oder Sync Signal verzögert? Wenn ja, dann könnte das mit dem DCM passen, falls mehr Ausgangsgruppen als verfügbare DCMs im Spiel sind, natürlich auch wieder nicht.
Das gesamte System (mehrere FPGAs auf verschiedenen Trägerkarten) arbeitet mit einer 40MHz Clock. Die Trägerkarten stecken in einem VME Crate und eine spezielle empfängt die 40MHz von der nächst höheren Stelle und verteilt sie im Crate an alle FPGAs. Diese 40MHz werden zusammen mit 40Mbit/s Daten in einen BPM Strom kodiert und optisch über ca. 80m versendet. Empfangen werden sie von einem ASIC, der die Daten und die Clock aus dem Strom dekodiert und sie final zu einem anderen ASIC (Dem Messgerät bzw. Sensor Auslesechip) sendet (elektrisch). Der Auslesechip des Sensors befindet sich in einer extrem radioaktiven Umgebung und muss in strahlenharten Prozessen gefertigt und mit strahlenharten Digital Designs entwickelt werden (bzw der ist fertig entwickelt und wird nun produziert). D.h. alles was nicht zwingenderweise auf dem Auslesechip stattfinden muss, soll auf unserer Trägerkarte gemacht werden. Das Delay ist nun deshalb so wichtig, weil all die Sensor Auslesechips synchron zu der 40MHz Clock laufen müssen (50% Duty Cycle für saubere BPM dekodierung), Laufzeitunterschiede in den Fasern müssen korrigiert werden und bestimmte Auslesechips abhängig von ihrer Position in der Maschiene ein verzögertes Signal bekommen müssen. Der Spartan 6 ist in diesem Fall der Sender bzw er kodiert das BPM Signal. Pro Spartan 6 werden 12 BPM Ströme versandt, wovon jeder einzeln variabel Verzögerbar sein sollte. Laut Datasheet hat der XC6SLX150T 8 DCMs wovon glaube ich der großteil aber schon zur Erzeugung von 4 verschiedenen Clock Domains genutzt wird. D.h. die DCM Lösung kann glaube ich nicht funltionieren. Derzeit orientiere ich mich an TDC Implementationen über Carry Chains, jedoch verstehe ich noch nicht so ganz wie es genau funktioniert. (Z.B.: Laut http://infoscience.epfl.ch/record/139431 erreichen sie eine Auslösung im 20ps Bereich) Danke vorraus und alle Vorposter für die Hilfestellungen. Gruß
Hm. Also was auch gehen würde, wären die OSERDES Ausgänge. Damit kannst du wie mit einem variablen Schieberegister mit etwas Trickserei die Ausgänge raussschieben. Allerdings sind damit im höchsten Speedgrade auch "nur" 1080 MBit/s möglich, was knapp unter 1ns Auflösung bedeutet und mehr als 8 Stufen gehen auch nicht. Wieso macht man denn eigentlich die Hardware bevor so ein grundlegendes Problem geklärt wird? Normal wird die HW erst gefertigt, wenn das Design im Simulator läuft. Dann minimiert die Überraschungen deutlich. Oder hast du das Projekt von jemandem aufgehalst bekommen?
Die Hardware stammt nicht von mir... ich bin auch erst seit November in dem Projekt tätig. Zu dem Zeitpunkt war die Hardware längst in Produktion. An den SERDES hatte ich auch schon gedacht. Reicht aber in der Auflösung nicht. Gruß Marius
hmm, nur mal gesponnen: Koenntet ihr einen Timestamp zu euren 'Aussenstellen' schicken? Und in den Daten die zurueck kommen diesen (oder einen Teil/Subset) des Timestams wieder empfangen? Das koennte man doch kallibrieren denke ich... Vlt. liege ich da ja komplett falsch, aber wenn ihr rauskriegen wollt, wie gross das Delay zwischen verschiedenen Stationen ist, dann muesst ihr auch einen 'Master'-Trigger zur Verfuegung stellen...
Als grundlegendes Problem kann man das nicht bezeichnen, prinzipiell wissen wir ja wie es geht, jedoch ist das genauso unpraktisch und kalibrierungstechnisch aufwendig wie die Vorgängerversion. Die Hardware in unserem Büro besteht ja auch nur aus einem/mehreren FPGAs. Das meiste davon hatten wir in Firmware auf Eval Boards schon getestet, jedoch wurde sich da schon damit zufrieden gegeben, dass wir eine Delay Line und Duty Cycle Korrektur bauen können. Das Ziel den derzeitigen ASIC in einem FPGA zu portieren war also erfüllt. Jedoch stellt mich persönlich dieses Ergebnis nicht ganz zufrieden, da ich die Hoffnung hatte mit den Spartanern etwas mehr bzw. besseres machen zu können. Timestamp mitschicken tuen wir prinzipiell schon, das ist die 40MHz Clock, jeder Takt entspricht der Itteration des Timestamps und der muss zum richtigen Zeitpunkt am Auslesechip ankommen, damit das richtige 25ns Zeitfenster ausgelesen wird. Grundsätzlich hätte ich kein Problem damit, den Duty Cycle im FPGA selbst zu tunen, jedoch benötige ich dafür wieder einen TDC mit genügend hoher Auslösung und dann steht man wieder vor dem selben Problem. Um das ganze nochmal zu fokussieren, die besten Möglichkeiten wären: - IODELAY workaround - hohe Auflösung, gute Präzision, versaut aber Duty Cycle - Mux Chain - hohe Auflösung, mittlere Präzision (Von Kanal zu Kanal unterschiedlich), versaut Duty Cycle, kann aber gleichzeitig zur Korrektur des Duty cycles genommen werden - Carry chain - hohe Auflösung, mittlere Präzision, noch nicht richtig getestet - Externer ASIC - ich hab multikanal ASIC gefunden die unseren Anforderungen genügen würden, Nachteil Kosten, muss erst noch auf die Trägerkarte/Layout und IOs könnten knapp werden
Digital Variable Delays : MC100EP196, ECL 100ps bis 10ns, soweit ich mich erinnere. Mir scheint aber, man sollte das Design aendern.
Mann kann Glasfasern um einen Piezoring velegen und somit die Fasern über eine Spannung strecken, damit kann man auch einige ausgleiche machen. :-).
Timon schrieb: > Laut Datasheet hat der XC6SLX150T 8 > DCMs wovon glaube ich der großteil aber schon zur Erzeugung von 4 > verschiedenen Clock Domains genutzt wird. D.h. die DCM Lösung kann > glaube ich nicht funltionieren. Du hast insgesamt 6 Clock Management Tiles (CMT), also 12 DCM und 6 PLL. Wobei jede PLL 6 Ausgänge hat, deren Phase sich unterschiedlich einstellen lassen soll. Vielleicht können Euch ja die PLLs weiterhelfen: UG382 und XAPP879 (PLL Dynamic Reconfiguration) Duke
Nochmal für Doofe: Ihr wollt einen seriellen Eingangsdatenstrom (8b10b-kodiert) dekodieren und habt hierzu keinen in richtiger Phase liegenden synchronen Takt?
Nein... Wir haben einen seriellen BPM bzw. 8b10b-kodieren Datenstrom, den wir verzögert abschicken müssen. Die Verzögerung muss mit einer Auflösung von mindestens 500 ps einstellbar sein. Das ganze für bis zu 12 voneinander unabhängige Kanäle. OT: Einen seriellen 8b10b-Eingangsdatenstrom ohne synchronen Takt zu dekodieren geht sehr wohl. Siehe dazu XAPP 224. Mit den SERDES-IOs im Spartan 6 geht das sogar noch einfacher. Gruß Marius
>und eine spezielle empfängt die 40MHz von der nächst höheren >Stelle und verteilt sie im Crate an alle FPGAs. Wird so nicht ohnehin Jitter in den Takt injiziert? An welcher Stelle überprüft ihr eigentlich, ob die individuelle Delay-Justierung richtig ist?
Den 40 MHz Takt aus dem Crate kann man über eine Delay-Line in Hardware auf jeder Platine einstellen. Das sollte also nicht das Problem sein. Die individuelle Delay-Justierung erfolgt über Berechnungen. Es werden also alle Verzögerungen addiert (elektrische und optische Leitungslängen, Abstand zum Interaktionspunkt usw.) und daraus ein Delay-Setting ermittelt. Das wird zunächst so eingestellt und dann über ein Fine-Tuning angepasst. Gruß Marius
Marius Wensing schrieb: > Kennt jemand noch andere (und eventuell besser geeignete) Verfahren, um > > diese Signale passend zu verzögern? Ja, gibt es, habe ich seinerzeit für einen Kunden entwickelt, wurde auch teilweise patentiert. Du brauchst für diese Lösung aber 2 Leitungen je Kanal und bei hohen Anforderungen etwas Umbeschaltung. Bauteilkosten je Kanal 65 Cent. Es ist von der Idee her teilweise patentiert - bzw im Verfahren, aber die Lösung wäre so umzustricken, dass sie Stand der Technik ist, weil ich zufällig weiss, dass etwas ähnliches in einem ASIC eines bekannten Analogherstellers gemacht wird. Das Verfahren funktioniert aber nur für digitale Kanäle und muss gfs kalibiert werden, wenn es in Serie bei unbekannten FPGA-Exemplaren (Streuung) funktionieren soll. Das erfordert dann nochmals 1 Leitung, sowie 2 weitere Leitungen für jede Gruppe von Signalen (Bus). Die damalige Anforderung war, ALLE FPGA Ausgänge (>200) auf eine Flanke zu bringen, was mir mit einer Auflösung von einzelkalibiert <5ps und summenkalibiert noch unter 10ps gelang. Es waren damals 602 Leitungen - bei einem Datenbus mit 32 Bit käme man auch genau 50! Ich habe dazu noch eine Billiglösung, die unkalibiert auf 100ps arbeitet und nur 2 Leitungen je Kanal braucht, sowie eine weitere, die noch Faktor 3-5 genauer werden könnte, aber jeweils noch 2 Analogschalter + 2 Zusatzbauteile braucht, samt einem Treiberkanal. Kosten ca 2,- je Kanal mit dann 5 Leitungen pro Kanal. Diese letzte Lösung ist noch nicht patentiert und ich suche eine Anwendung dafür.
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.