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