Servus, ich möchte gerne eine 50 MHz getaktete FSM auf einem FPGA-Board mit einer Genauigkeit von +-2ns durch ein externes galvanisch-getrenntes Signal triggern bzw. starten. Eine deterministische Latenz wäre kein Problem. Ich hatte mir vorgestellt eine Taktleitung und synchron eine Signalleitung, die ich einfach runterziehe. So hätte es zumindest auf einer normalen Drahtverbindung funktioniert, jedoch was unternimmt man bei galvanischer Trennung? Optokoppler, Trafo oder Glasfaser? Hat jemand Erfahrung für eine elegante Lösung?
@ Tim (Gast) >ich möchte gerne eine 50 MHz getaktete FSM auf einem FPGA-Board mit >einer Genauigkeit von +-2ns Also +/-2ns Jitter. > durch ein externes galvanisch-getrenntes >Signal triggern bzw. starten. Eine deterministische Latenz wäre kein >Problem. Dann geht fast jeder etwas schnellere Optokoppler, wenn die Frequenz des Triggers nicht zu hoch ist. 6N137 & Co. Oder was neues von Ratiopharm, ähhh, Analog Devices. >Ich hatte mir vorgestellt eine Taktleitung und synchron eine >Signalleitung, die ich einfach runterziehe. Wozu 2 Signale? Das Triggersignal reicht. Man muss es halt einsynchronisieren.
Danke für die ersten Hinweise. Ich bin jedoch noch nicht überzeugt :) Falk B. schrieb: > Dann geht fast jeder etwas schnellere Optokoppler, wenn die Frequenz > des Triggers nicht zu hoch ist. 6N137 & Co. Oder was neues von > Ratiopharm, ähhh, Analog Devices. Der 6N137 hat eine Rise-Time von 50 ns. Ich kann mir nicht vorstellen da +-2ns Jitter zu erreichen. Oder seh ich das falsch? Falk B. schrieb: > Wozu 2 Signale? Das Triggersignal reicht. Man muss es halt > einsynchronisieren. Durch abtasten mit einem 200 MHz Takt (Periodendauer 5ns) hätte man immer noch +-5ns. Wie würde man das besser einsynchronisieren?
Eine 50MHz FSM kann man gar nicht mit +-2ns Jitter "triggern". Die hat in sich ja eine Zykluszeit bon 20ns, und somit muss unbedingt da etwas mit +-10ns oder schlechter herauskommen...
@ Tim (Gast) >Der 6N137 hat eine Rise-Time von 50 ns. Ich kann mir nicht vorstellen da >+-2ns Jitter zu erreichen. Stimmt, die Zahl hatte ich so nicht vor Augen. > Oder seh ich das falsch? Nein. Da muss man wohl einen deutlich besseren Optokoppler nutzen. Wobei die +/-2ns Jitter bei 20ns FSM-Takt akademisch sind. Ausserdem ist die fall time nur 12ns typisch, da kriegt man +/-5ns Jitter problemlos hin. Denn man kann durch einen Inverter (im FPGA) auf die schnelle Flanke triggern, anstatt auf die langsame. >> Wozu 2 Signale? Das Triggersignal reicht. Man muss es halt >> einsynchronisieren. >Durch abtasten mit einem 200 MHz Takt (Periodendauer 5ns) hätte man >immer noch +-5ns. Wenn deine FSM sowieso nur mit 50 MHz (20ns) läuft, ist das doch OK! Ein Trigger ist im allgemeinen so oder so ASYNCRON zum Takt des Empfängers, da geht es so oder so nicht anders oder besser! > Wie würde man das besser einsynchronisieren? Keine Ahnung, IMO geht es nicht wirklich besser. Sonst müsste ja die Triggerquelle synchron zu deinem 50 MHz Takt arbeiten. Kann man machen, ist aber oft nicht möglich.
:
Bearbeitet durch User
Falk B. schrieb: > Keine Ahnung, IMO geht es nicht wirklich besser. Sonst müsste ja die > Triggerquelle synchron zu deinem 50 MHz Takt arbeiten. Kann man machen, > ist aber oft nicht möglich. Richtig, arbeiten wir synchron zu Triggerquelle. Scheint doch schon knifflig zu sein. Aber ja, das war mein Gedanke. Ich schleppe den Takt mit und erstelle per PLL den 50 MHz Takt. Damit kann ich source-synchron abtasten. Durch schieben der externen Taktphase erreicht man auch weit unter 20ns Genauigkeit. Schlimm ist nur, was man nicht rausjustieren kann. Lothar M. schrieb: > Eine 50MHz FSM kann man gar nicht mit +-2ns Jitter "triggern". Die > hat > in sich ja eine Zykluszeit bon 20ns, und somit muss unbedingt da etwas > mit +-10ns oder schlechter herauskommen... Dies gilt bei Überabtastung. Aber nicht bei synchroner Eintaktung. Natürlich kann das Datum in der Periode variieren. Falls man die Periode jedoch genau bestimmen kann, dann lässt sich das Event über die Taktphase feiner setzen. Ich habe jetzt einen Optokoppler mit 2-4ns rise time gefunden. http://www.ti.com/lit/ds/symlink/iso7840.pdf Sieht schon gut aus. Vom Gefühl her relativ knapp. Gibt es noch andere Ansätze/Verbesserungsvorschläge?
@Tim (Gast) >Richtig, arbeiten wir synchron zu Triggerquelle. >Scheint doch schon knifflig zu sein. Aber ja, das war mein Gedanke. Ich >schleppe den Takt mit und erstelle per PLL den 50 MHz Takt. Damit kann >ich source-synchron abtasten. Durch schieben der externen Taktphase >erreicht man auch weit unter 20ns Genauigkeit. Schlimm ist nur, was man >nicht rausjustieren kann. Dann braucht man aber keine +/-2ns Jitter. Da kann man sich ggf. mehr leisten. >> in sich ja eine Zykluszeit bon 20ns, und somit muss unbedingt da etwas >> mit +-10ns oder schlechter herauskommen... >Dies gilt bei Überabtastung. Aber nicht bei synchroner Eintaktung. Davon wußten wir bis jetzt nichts. >Ich habe jetzt einen Optokoppler mit 2-4ns rise time gefunden. >http://www.ti.com/lit/ds/symlink/iso7840.pdf Isokoppler, kein Optokoppler. Den OPTISCH arbeitet der nicht.
Falk B. schrieb: > Dann braucht man aber keine +/-2ns Jitter. Da kann man sich ggf. mehr > leisten. Gut, Jitter ist jetzt vielleicht wieder zu speziell. Ich meinte damit auch Schwankungen im Betrieb wie Temperatur (Raumtemperatur +-5°C) oder auch Alterung. Mein Ziel wäre es einmal die absolute Latenz mit dem Oszi zu messen und abzulegen im Speicher. Alle Ungenauigkeiten sollten nur noch im Rahmen von +/-2 ns liegen. Falk B. schrieb: >>Ich habe jetzt einen Optokoppler mit 2-4ns rise time gefunden. >>http://www.ti.com/lit/ds/symlink/iso7840.pdf > > Isokoppler, kein Optokoppler. Den OPTISCH arbeitet der nicht. Das hatte ich übersehn. Nettes Prinzip jedoch. Bis jetzt mein Favorit. Wäre auch eine Lösung mit Glasfaser denkbar? Wahrscheinlich müsste ich mich von niederfrequenten Steuersignalen trennen und dieses in verschiedene Bitfolgen modulieren. oder ist das aussichtslos?
@ Tim (Gast) >Gut, Jitter ist jetzt vielleicht wieder zu speziell. Ich meinte damit >auch Schwankungen im Betrieb wie Temperatur (Raumtemperatur +-5°C) oder >auch Alterung. Dann sollte man das auch sagen. >Mein Ziel wäre es einmal die absolute Latenz mit dem Oszi zu messen und >abzulegen im Speicher. Alle Ungenauigkeiten sollten nur noch im Rahmen >von +/-2 ns liegen. >Wäre auch eine Lösung mit Glasfaser denkbar? Denkbar schon, sinnvoll nein. > Wahrscheinlich müsste ich >mich von niederfrequenten Steuersignalen trennen und dieses in >verschiedene Bitfolgen modulieren. oder ist das aussichtslos? Was soll der Quark? Glasfaser nimmt man bestenfalls, wenn man in EXTREM gestörter Umgebung ein Signal über große Strecken (viele Meter!) übertragen muss.
Danke für die zahlreichen Anregungen, damit kann ich schonmal gut loslegen. Falk B. schrieb: > Was soll der Quark? Glasfaser nimmt man bestenfalls, wenn man in EXTREM > gestörter Umgebung ein Signal über große Strecken (viele Meter!) > übertragen muss. Mit 5 bis 10m ist zu rechnen. Verzeihung, das war bis jetzt auch nicht zu ahnen. Trotzdem nochmal danke für die Tipps!
@Tim (Gast) >> Was soll der Quark? Glasfaser nimmt man bestenfalls, wenn man in EXTREM >> gestörter Umgebung ein Signal über große Strecken (viele Meter!) >> übertragen muss. >Mit 5 bis 10m ist zu rechnen. Verzeihung, das war bis jetzt auch nicht >zu ahnen. Trotzdem nochmal danke für die Tipps! Denk dran, 10m Glasfaser haben allein schon ~50ns Laufzeit. Dazu kommen noch die Tranceiver.
Das Ganze dürfte nur dann funktionieren, wann man die FSM von aussen taktet, weil sie wie schon angeklungen, zu grob abtastet und komplett asynchron ist. Um es mal informationstheoretisch zu formulieren, braucht die interne FSM eine Zeitinformation von aussen. Gewöhnlich löst man solche Themen so, dass man mit einem time code arbeitet und Ereignisse in die Zukunft legt, oder das steuernde System von aussen muss entsprechend voraus denken, inklusive eventueller Latenzen bei Übertragung und Berechnung im Zielsystem.
Wenn die FSM mit 50 MHz arbeitet, dann kann nur alle 20ns "was passieren".. Und wenn du das Triggersignal synchron zum Takt der FSM erzeugst, dann muss doch nur gewährleistet sein, dass das Signal mit dem darauffolgenden Takt in die FSM übernommen wird. Dazu kann das Signal eine Laufzeit von 0ns bis 20ns abzüglich der Setup-Zeit haben. Ok, ggf muss der CLK-Skew zwischen Quelle und Senke noch mit betrachtet werden. Aber letztendlich bringt dir doch so kleiner Jitter gar nichts.
Schlumpf schrieb: > Wenn die FSM mit 50 MHz arbeitet, dann kann nur alle 20ns "was > passieren".. > Und wenn du das Triggersignal synchron zum Takt der FSM erzeugst, dann > muss doch nur gewährleistet sein, dass das Signal mit dem > darauffolgenden Takt in die FSM übernommen wird. > Dazu kann das Signal eine Laufzeit von 0ns bis 20ns abzüglich der > Setup-Zeit haben. > Ok, ggf muss der CLK-Skew zwischen Quelle und Senke noch mit betrachtet > werden. > Aber letztendlich bringt dir doch so kleiner Jitter gar nichts. Das stimmt so nicht. Die Vorredner liegen da schon richtig. Wenn du den Eingangstakt beispielsweise um 5 ns verschiebst, mit der auch die FSM getaktet ist, dann verschiebst du auch das Event um 5ns. Auch wenn das Raster 20ns ist, wird halt das ganze Raster verschoben.
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.