Delay Time Measurement

Ich würde mir mittels eines "Oszilloskops" erst mal einen Überblick über 
die Zeiten verschaffen, bevor ich den Aufwand eines TDCs überhaupt in 
Betracht ziehe.

Wenn du dir bspw. ein Eval-Kit beschaffst, ich denke da an den GP22 von 
ACAM, dann hast du praktisch keinen Aufwand, sondern kannst mit der 
Umgebung sofort mit der eigentlichen Aufgabe loslegen, dem Messen.

Ich muss das ARRIA V GT Development Kit benutzen, weil wir das hier in 
der Firma haben.

@ Erwin: Ich muss die Delay Zeit ja auf jeden Fall messen und 
kompensieren. Die Zeiten wurden mit einem Oszilloskop gemessen und die 
Delay Zeit beträgt 15 ns. Da das ist System aber dauerhaft laufen soll, 
verändert sich diese Zeit ja durch Temperatur.

> Signal 1 geht über mehrere Treiber Entstufen und Leistungstransistoren
> an den Laser. Dadurch entsteht ein gewisses Hardware Delay.
Also Signal 1 ist langsamer als 2,3 & 4
> Signale 2,3 und 4 sind direkt mit dem Sensor verbunden. Vorgabe ist,
> dass die Signale 2,3 und 4 am Sensor anliegen, sobald das Laser
> eingeschaltet ist.
2,3 & 4 sind schneller liegen also vor dem Laser Signal an.
Sind doch alle bedingungen erfüllt, oder verstehe ich hier was falsch.

Miss die Laufzeiten über den relevanten Temperaturbereich, dann kannst 
du gut abschätzen wieviel du kompensieren müsstest und ob es überhaupt 
notwendig ist.

Ich verstehe noch so recht nicht wieso du unbedingt mit einem TDC die 
Zeit messen willst. Was spricht gegen das Sampeln mittels FPGA? In einem 
genaueren Raster kannst du dein Ausgangssignal doch sowieso (auf 
einfache Weise) nicht verschieben.
Wenn es doch genauer sein soll: Nutz die LVDS SERDES Blöcke des AV - die 
gehen bis zu 1.6 Gbits/s. Dazu kannst du einen LVDS <> CMOS 
Pegelwandlerbaustein nehmen...
Du sparst dir damit den TDC Baustein und machst alles innerhalb des 
FPGAs.

Hat es hiermit zu tun?

Beitrag "Erzeugen hochfrequenter sychroner Taktsignale"

@lattice User: Ja das hat der Diplomant vor mir gemacht. Meine Aufgabe 
ist nun das Projekt zu beenden.

Ich muss das ganze nicht unbedingt mit einem TDC realisieren. Ziel ist 
es das, Signal 1 und Signale 2 & 3 gleichzeitig am Laser/Sensor anliegen 
müssen. Das Signal 1 jedoch durch die Endstufen verzögert wird. Und 
diese Verzögerungszeit sich immer ändert z.B. durch Temperatur. Das 
heißt ich kann die nicht vorher fest einstellen sondern muss sie messen 
und dann kompensieren.

Eine andere Idee ist das Signal über einen hochfrequenten Zähler 
abzutasten und dann die Signale 2 & 3 zu verschieben.

Was genau bedeutet "gleichzeitig"? -> Welcher Jitter ist erlaubt?

1-2 ns als jitter sind erlaubt.

Ich würde es mal mit den oben beschriebenen SERDES Blöcken versuchen. 
Die Ausgagnssignale alle wieder auf den FPGA zurückführen und dann 
gleichzeitig sampeln.
Die Ausgabe würde ich auch über die SERDES machen, bei den beschriebenen 
1.6Gbps wäre das ein Raster von 625ps.

OK vielen dank für die Hilfe!
Ich werde das ganze jetzt mal realisieren.

Schwieriges Thema.
Aber dazu sollten ein paar Rahmenbedinungen geklärt werden.
- Ist diese Anordung starken Temperaturschwankungen unterworfen?
- Muss das nur auf diesem einen FPGA laufen? Oder muss das auf 
verschiedenen Exemplaren so eines FPGAs laufen?

Man könnte das Signal durch ein Schieberegister schieben, welches mit 
maximalem Speed läuft (z.B. 500 MHz), dann wäre man ungefähr in der von 
dir geforderten Genauigkeit.

Man könnte sich auch eine Art Delay-Line bauen, die aus manuell 
platzierten LUTs besteht, durch die das Signal muss. Abhängig von dem 
einzustellenden Delay entscheidet man, wo man das Signal einspeist.
Allerdings ist das Ganze temperatur- und exemparabhängig. Muss also 
vorher getestet werden, wie groß der Drift auf EXAKT diesem Baustein 
ist.

Die Synchrone Lösung über ein maximal schnelles Schieberegister 
(vielleicht lässt sich da ja auch was mit 2 Registern machen, die auf 
der steigenden bzw. fallenden Flanke arbeiten) ist eine mehr oder 
weniger exempar- und temperaturunabhängige Lösung, aber ist eben 
gebunden an die maximale Geschwindigkeit des FPGA.

Eine Lösung über manuell platzierte LUTs, Messungen des Temperaturdrifts 
etc ist auf den ersten Blick sicher "unsauber", aber vielleicht für so 
eine spezielle Anwendung auch irgendwie spannend. Auf jeden Fall gibt 
sie "Stoff" für ne Abschlussarbeit.

Und dann wären da noch die programmierbaren Delays der OUT-Buffer. 
Allerdings sind die im Bereich bis maximal 150ps einstellbar. Und ob das 
"zur Laufzeit" geht, weiss ich nicht.

Schlumpf schrieb:
> Man könnte das Signal durch ein Schieberegister schieben, welches mit
> maximalem Speed läuft (z.B. 500 MHz)
Genau das hat man ja mit den SERDES-Blöcken.
Und die gefordert Genauigkeit von 1-2 ns sollte damit auch erreichbar 
sein.

Duke

Guten Morgen,

also die Anwendung soll für die Diplomarbeit nur auf diesem speziellen 
Chip laufen.

Wenn ich die Zeit mittels Zähler detektiere der über einen SERDES getakt 
ist, müsste ich ja die 1,6 Gps bekommen, sprich die 625 ns Genauigkeit.

Wenn ich das ganze durch eine Delay-Line realiseren würde, müsste ich 
aber doch vorher auch die Zeit bestimmen und immer wieder neu 
einstellen. Ist das überhaupt möglich?

Gruß Jan

der SERDES nimmt dein Eingangssignal und tastet es pro interner 
Taktperiode 10mal ab. Du bekommst dann einen Bitvektor mit Breite 10. 
Signale die früher ankommen haben dann natürlich etwas früher eine 1 als 
die anderen.
ebenso kannst du bei der Ausgabe die Verzögerung für die 
unterschiedlichen Pfade eingeben.

Um es genau zu bekommen musst du alle Ausgabesignale wohl auf den FPGA 
zurückführen und so dann messen wie die Laufzeiten / Zeitbeziehungen bei 
der aktuellen Temperatur denn sind. Dabei solltest du auch auf die 
Flankensteilheit achten, denn wenn man nicht aufpasst vermisst man 
diese. ;)

Ja mit den Serdes Blöcken müsste ich das einbekommen:)

Nein kenne ich nicht, habe mir aber grade mal das Datenblatt 
durchgelesen und die fällt leider raus, da 12 ns einstellbares Delay 
sehr wahrscheinlich nicht ausreichen werden... Beim Einschalten 
gemessenes Delay baträgt 15 ns und über die Dauer wird ein Delay von 
ungefähr 30 ns erwartet.