Forum: FPGA, VHDL & Co. Delay Time Measurement


von Jan (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich bräuchte einige Hilfestellungen für meine Abschlussarbeit.

Ich habe 4 Signale auf einem FPGA erzeugt. Signal 1 soll einen Laser 
betreiben und die Signale 2,3 & 4 einen Sensor ansteuern.
Signal 1 geht über mehrere Treiber Entstufen und Leistungstransistoren 
an den Laser. Dadurch entsteht ein gewisses Hardware Delay.
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.
Das heißt, ich muss auf dem FPGA das Hardware Delay messen und die 
Signale 2,3 & 4 um diese Zeit verschieben. Pulslängen der Signale 
betragen 20 ns und das zu erwartende Hardware Delay zwischen 10-30 ns.

Meine überlegung ist nun, die Zeit mit einem Time-to-digital Converter 
zu messen, wobei ich überhaupt nicht einschätzen kann wie viel Aufwand 
das ganze ist.

Habt ihr Ideen wie das ganze am sinnvollsten realisiert werden kann, bzw 
wie ich am besten anfange. Im Anhang ist noch eine Skizze des Aufbaus 
angehängt.

P.S. Projekt läuft auf einem ARRIA V GT Development Board und Quartus II 
13.1

Gruß Jan

von Erwin (Gast)


Lesenswert?

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.

von Tinto (Gast)


Lesenswert?

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.

von Jan (Gast)


Lesenswert?

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.

von uwe (Gast)


Lesenswert?

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

von Erwin (Gast)


Lesenswert?

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.

von Lattice User (Gast)


Lesenswert?


von Jan (Gast)


Lesenswert?

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

von Erwin (Gast)


Lesenswert?

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

von Jan (Gast)


Lesenswert?

1-2 ns als jitter sind erlaubt.

von Erwin (Gast)


Lesenswert?

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.

von Jan (Gast)


Lesenswert?

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

von Thomas R. (Firma: abaxor engineering) (abaxor)


Lesenswert?

Jan schrieb:
> Ziel ist
> es das, Signal 1 und Signale 2 & 3 gleichzeitig am Laser/Sensor anliegen
> müssen.

Dann benutze doch mit Signal 1 also etwas wie ein OE, rein 
kombinatorisch. Dann hast du gar kein Jitter.

Was heißt eigentlich anliegen müssen? Am Laser liegt immer an 2 & 3 ein 
Signal an.

Tom

von Schlumpf (Gast)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Jan (Gast)


Lesenswert?

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

von Erwin (Gast)


Lesenswert?

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

von Pandur S. (jetztnicht)


Lesenswert?

Die analoge, aber digital steuerbare Delayline 100EP196 kennst du ? 
Einstellbar von 2 bis 12ns, mit 10ps Aufloesung.

: Bearbeitet durch User
von Jan (Gast)


Lesenswert?

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.

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.