Forum: FPGA, VHDL & Co. Synchronisierung für FPGA Serdes


von David (ds2000)


Lesenswert?

Ich möchte mittels der ISERDES2 Blöcke in einem AMD Spartan 6 FPGA einen 
Time to Digital Converter realisieren. Dazu habe ich extern eine externe 
Clock von 500MHz und ein, aus einem Analogsignal erzeugtes, Stop event, 
sowie ein Start event. Das Start Signal, sowie das Stop Signal sind 
nicht Phasenstarr zur 500MHz Serdes Clock. Nun möchte der FPGA aber 
gewisse Hold Zeiten haben und die müssen eingehalten werden, damit das 
mit metastabil wird.

Meine Idee wäre nun sowas wie einen ADCMP561 vorzuschalten wo ich Latch 
Enable dann jeweils an die 500MHz verbinde.

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

Wären das Lösungsansätze die Sinn machen?

: Verschoben durch Moderator
von Cartman E. (cartmaneric)


Lesenswert?

> AMD Spartan 6

Nanu.
Hab ich was verpasst? ☺

von Andreas H. (signore_rossi)


Lesenswert?

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.

: Bearbeitet durch User
von Andreas H. (signore_rossi)


Lesenswert?

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

von Rick (rick)


Lesenswert?

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

von Cartman E. (cartmaneric)


Lesenswert?

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.

von Andreas H. (signore_rossi)


Lesenswert?

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.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

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/

von David (ds2000)


Lesenswert?

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.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

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/

von David (ds2000)


Lesenswert?

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.

von Andreas H. (signore_rossi)


Lesenswert?

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.

von David (ds2000)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von David (ds2000)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

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.