Forum: FPGA, VHDL & Co. variable Delay-Line


von Marius W. (mw1987)


Lesenswert?

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

von Christian R. (supachris)


Lesenswert?

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.

von Marius W. (mw1987)


Lesenswert?

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

von OOO (Gast)


Lesenswert?

Schau dir mal das "variable phase shift" feature der DCM's an.

http://www.xilinx.com/support/documentation/user_guides/ug382.pdf

von Christian R. (supachris)


Lesenswert?

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.

von Marius W. (mw1987)


Lesenswert?

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

von Christian R. (supachris)


Lesenswert?

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?

von Marius W. (mw1987)


Lesenswert?

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

von Duke Scarring (Gast)


Lesenswert?

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

von Marius W. (mw1987)


Lesenswert?

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

von Matthias (Gast)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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.

von Marius W. (mw1987)


Lesenswert?

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

von Timon (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von Timon (Gast)


Lesenswert?

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ß

von Christian R. (supachris)


Lesenswert?

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?

von Marius W. (mw1987)


Lesenswert?

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

von berndl (Gast)


Lesenswert?

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...

von Timon (Gast)


Lesenswert?

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

von Purzel H. (hacky)


Lesenswert?

Digital Variable Delays : MC100EP196, ECL 100ps bis 10ns, soweit ich 
mich erinnere.
Mir scheint aber, man sollte das Design aendern.

von Johann (Gast)


Lesenswert?

Mann kann Glasfasern um einen Piezoring velegen und somit die Fasern 
über eine Spannung strecken, damit kann man auch einige ausgleiche 
machen. :-).

von Duke Scarring (Gast)


Lesenswert?

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

von Jimbo (Gast)


Lesenswert?

Nochmal für Doofe:

Ihr wollt einen seriellen Eingangsdatenstrom (8b10b-kodiert) dekodieren 
und habt hierzu keinen in richtiger Phase liegenden synchronen Takt?

von Marius W. (mw1987)


Lesenswert?

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

von Jimbo (Gast)


Lesenswert?

>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?

von Marius W. (mw1987)


Lesenswert?

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

von B.B. (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.