Synchronisierung für FPGA Serdes

AMD Spartan 6

Nanu. Hab ich was verpasst? ☺

Ein Komparator ist sinnvoll um extern eine Triggerschwelle für Dein Signal festzulegen und differentiell an die FPGA Pins zu gehen. Sowas wie der MAX9378 reicht aber völlig https://www.analog.com/media/en/technical-documentation/data-sheets/max9377-max9378.pdf.

Mit welcher Zeitauflösung willst Du messen? 500 ps geht ganz gut. Genauer wird's mit den ISERDES eher nix.

Dein Analogsignal wird auch zum 500 MHz Takt asynchron sein. Also verlagerst Du das Problem mit verletzten Setup- und Hold-Zeiten nur auf ein anderes Bauteil.

Cartman E. schrieb:

AMD Spartan 6

Nanu. Hab ich was verpasst? ☺

Ja. Firmen werden aufgekauft. https://www.amd.com/de/products/adaptive-socs-and-fpgas/fpga/spartan-6.html

Andreas H. schrieb:

Ein Komparator ist sinnvoll um extern eine Triggerschwelle für Dein Signal festzulegen und ...

Die differentiellen Eingänge am FPGA sind doch schon als Komperatoren verwendbar...

Andreas H. schrieb:

Cartman E. schrieb:

AMD Spartan 6

Nanu. Hab ich was verpasst? ☺

Ja. Firmen werden aufgekauft. https://www.amd.com/de/products/adaptive-socs-and-fpgas/fpga/spartan-6.html

Ach so. ☺ Mein letzter Spartan war ein 3A.

Rick schrieb:

Die differentiellen Eingänge am FPGA sind doch schon als Komperatoren verwendbar...

Das stimmt natürlich. Der Vorteil liegt eher darin, dass die Input Common Mode Voltage der Komperatoren eventuell besser zum Eingangssignal passt. Der Spartan 6 hätte gerne 0,3 V - 2,35 V. Die MAX9378 gehen bis 50 mV an GND bzw. VCC. Hängt aber vom Eingangssignal ab, ob das relevant ist.

Außerdem sind sie schneller gewechselt, wenn man die Absolute Maximum Ratings doch mal überreizt hat. ;)

Und vielleicht will man schon dicht an der Signalquelle auf LVDS wechseln anstatt erst am FPGA.

Es gibt auf mikrocontroller.net das Unterforum FPGA ( https://www.mikrocontroller.net/forum/fpga-vhdl-cpld ) da ist mehr Know-How zu diesem Thema zu erwarten.

Metastabil kann man nicht verhindern, was man aber verhindern kann ist das metastaboile Zustände im FPGA weiterpropagieren und dort für Chaos sorgen. Man wird das also einsynchronisieren müßen, das kann man mit einem von der Quelle mitgelieferten Taktsignal (source-synchronous) machen. Das ist wohl das was du mit phasenstarren Clock meinst. Bei manchen Kommunikationskanälen wie bei den MGT kann man den Takt aus dem eigentlcihen Signal zurückgewinnen, vielleicht schaust du dir das mal an (clock recovery). Und dann gibt es oft delay elemente in den Eingängen mit denen man das signal um Bruchteile einer nanosekunde verschieben kann um do eine setup/hold-Verletzung zu verhindern (IO-Delay).

Am besten mal das Datenblatt zu diesen Blöcken durchstudieren und die passenden Application Notes dazu, Das wird zwar ein Wochenende Zeit kosten ist aber nötig wenn man ein Verständnis für das was man mit dem FPGA tut erlangen will:

• https://cdn.hackaday.io/files/21333912711072/ug381-%20spartan%206%20select%20io%20resources.pdf (UG381) bspw. S.70 ff u. S.77ff

• https://docs.amd.com/api/khub/documents/9TuR8zuWNIUpLp0XvdEZDg/content (XAPP1064)

Da ein paar deutschsprachige Schnipsel zum Thema: https://www.ib-dck.de/hauptseite/fpga/

Bradward B. schrieb:

Metastabil kann man nicht verhindern, was man aber verhindern kann ist das metastaboile Zustände im FPGA weiterpropagieren und dort für Chaos sorgen.

Danke für die Hilfe soweit. Die Clock für das Startsignal kann ich per PLL phasenstarr zur SERDES Clock machen. Das wäre möglich, da dieses Signal periodisch ist. Das Stopsignal wird aber immer asynchron bleiben. Du hast also recht, dass es darum geht metastabile zustände am Eingang des FPGA für das Stopsignal zu erlauben aber eben nicht auf weitere Stufen zu übertragen. Das SelectIO Datenblatt habe ich mir schon angesehen. Wenn man den ISERDES Block benutzt kann man da keine Synchronisationslogik vorschalten.

Extern eine Flip-Flop Kette zur Synchronisation vorschalten wäre schon schwierig bei 500MHz wird die Auswahl schon eng.

Ich würd hier ein Gray encoded counter für die eigentliche Messung verwenden, damit ist der Fehler durch Metastabilität/Synchronsiereffekte gering, da nur 2 FF auf das mglw. asynchrone Stoppsignal regieren müßen.

https://www.eetimes.com/gray-code-fundamentals-part-2/

Nochmal eine Idee. Im Grunde ist der SERDES Empfänger schon eine Synchronisierungskette. Wenn ein paar bits metastabil sind kann ich damit leben das erwarte ich ja auch wenn ein Stopsignal asynchron kommt. Es darf eben nur nicht der ganze FPGA völlig undefiniertes tun. Man senkt mit einer FF Kette ja eben nur die wahrscheinlichkeit für metastabile zustände. Hat hier jemand Erfahrung ob es eben reichen kann das asynchrone Signal einfach auszuwerten? Mit dem entsprechenden Jitter muss ich dann eben leben.

Die Stopps asynchron mit ISERDES zu samplen funktioniert einwandfrei. Die ISERDES haben intern schon mehrstufige Flipflops. Die Ausgabe ist mit 4 oder 8 Bit parallel. 500 ps Auflösung funktioniert mit dem richtigen Speedgrade und Interleaving zweier ISERDES. Das langsamere Speedgrade kann offiziell nur irgendwas um 925 MHz Samplerate am Pin. Die Warnung kann man aber auch ignorieren.

Der Stopppuls sollte halt sicher breiter als 500 ps sein, damit man keinen verpasst.

Andreas H. schrieb:

Die Stopps asynchron mit ISERDES zu samplen funktioniert einwandfrei. Die ISERDES haben intern schon mehrstufige Flipflops. Die Ausgabe ist mit 4 oder 8 Bit parallel. 500 ps Auflösung funktioniert mit dem richtigen Speedgrade und Interleaving zweier ISERDES. Das langsamere Speedgrade kann offiziell nur irgendwas um 925 MHz Samplerate am Pin. Die Warnung kann man aber auch ignorieren.

Der Stopppuls sollte halt sicher breiter als 500 ps sein, damit man keinen verpasst.

Die Stopevents sind im Bereich 10ns breit aber wichtiger ist nur die Auflösung der Zeit zwischen Start und Stop.

David schrieb:

damit das (nicht) metastabil wird.

Meta ist (hier) aus drei Gründen kein Problem:

1. Der Effekt spielt sich im Bereich von ps ab und ist hier kaum relevant
2. Bei der Anwendung ist ein falsch gesameltes Signal irrelevant
3. du sampelst bei SERDES ohnehin mit verketteten FlipFlops, hast also "mehrfach" einsynchronisiert.

In Summe führt ein sich tatsächlich falsch verhaltendes FF nur zu einem falschen Sample, man sieht also eine Flanke etwas zu früh oder zu spät - hier nur zu spät. Wenn du das eliminieren willst, kannst du auf die gesamelten Bits einen Mehrheitsentscheid machen, um einen einzelnen Impuls zu unterdrücken.

Dein Problem wird aber eh die geringe Abtastrate sein. Die 500ps machen bis zu 1ns Fehler, da an zwei Stellen wirkend. Hinzu kommt das Phasenrauschen, wenn du nur in internen Komparatoren benutzt, weil im Moment des Überschreitens des threasholds ein paar Mikrovolt auf der Leitung entscheiden, ob es schon eine 1 ist oder noch eine Null.

David schrieb:

Eine weitere Möglichkeit wäre die Serdes Clock Phasenstarr zum Start Signal zu machen, das immer periodisch ist und eine feste Frequenz hat.

Spart eine Unsicherheit an der linken Seite.

Ich würde statt das Spartan den Artix nehmen. Mit dem Spartan geht das zwar, aber die Qualität ist nicht sehr hoch. Reicht nur fürs Audio: http://www.96khz.org/htm/fpgaiopdmadc.htm

Wenn es ein interner Komparator sein muss, sollte der symmetriert werden. Braucht einen Tiefpass an einem FPGA-Pin (hier sher tieffrequent), der den Kombi-Eingang schieben kann. Dann noch eine entsprechende Auswertung.

J. S. schrieb:

Dein Problem wird aber eh die geringe Abtastrate sein. Die 500ps machen bis zu 1ns Fehler, da an zwei Stellen wirkend. Hinzu kommt das Phasenrauschen, wenn du nur in internen Komparatoren benutzt, weil im Moment des Überschreitens des threasholds ein paar Mikrovolt auf der Leitung entscheiden, ob es schon eine 1 ist oder noch eine Null.

Jede analoge Signalverabeitung kommt vor dem FPGA. Es muss sowieso verstärkt werden und ein Threshold festgelegt werden. Das passiert aber nicht im FPGA. Zum FPGA wird nur LVPECL gelangen.

David schrieb:

Jede analoge Signalverabeitung kommt vor dem FPGA. E

Ja und nein. Ich bezog mich auf den auch von anderer Seite geäußerten Vorschlag den LVDS-Komparator im FPGA zu nutzen.

Im Weiteren hätte auch ein Komparator vor dem FPGA das Problem des Jitters infolge von Rauschen und Einflüssen.

Eine echte analoge Verarbeitung gibt es hier ja eigentlich nicht, da das TDC-Signal ja ebenfalls digital ist. Es muss ja nur verstärkt oder abgeschächt werden, wobei es idealerweise steilflankiger wird. In jedem Fall aber wird ein Signal, das nicht sehr steilflankig vor dem Komparator erscheint, IMMER mit diesem zusätzlichen Phasenrauschen behaftet sein. Das Rauschen verschiebt das Signal in Y und damit indirekt in t.

Beim FPGA und genau genommen jedem anderen Komparator hat man zudem noch das generelle Schaltschwellenproblem. Auch der steilste Anstieg ist in ps-Betrachtung eine Rampe und braucht daher eine Y-Kalibierung. Da ist auch regelmäßig die Herausforderung bei solchen Schaltungen.

Wie gesagt würde ich - wenn es die "Nur-FPGA-Lösung" sein soll, in jedem Fall zu einem Artix raten. Dessen Eingänge sind um Klassen besser, als die des Spartan 6. Hinsichtlich der digitalen Auflösung sollte man zudem mal nachdenken, ob nicht die Transceiver (min 3Gbps!) der richtige Ansatz wären.