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
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.
@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.
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.
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
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. ;)
Die analoge, aber digital steuerbare Delayline 100EP196 kennst du ? Einstellbar von 2 bis 12ns, mit 10ps Aufloesung.
:
Bearbeitet durch User
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.