Artix 7 - Transceiver - Verdrahtung manuell möglich?

Rolf schrieb:

Ich hätte aber die Möglichkeit, die Transceiverbanken in Betrieb zu nehmen. Wäre das einen Versuch wert, die zu verbinden?

Ja, warum nicht.

Wie?

M.E. sind das immer(?) differentielle Pärchen. Davon braucht man mindestens zwei. Eins für den Takt und eins für die Daten. Falls der Artix-Transceiver schon CDR (clock data recovery) kann, reicht eine "Doppelader".

Falls der Datentransfer nicht nur in eine Richtung gehen soll, braucht man das Ganze für die Gegenrichtung nochmal.

Auch ist es hilfreich, wenn eine stabile Taktquelle zur Verfügung steht. Etwas einfacher wird es, wenn Sender und Empfänger aus der identischen Taktquelle versorgt werden...

Rick D. schrieb:

Rolf schrieb:

Ich hätte aber die Möglichkeit, die Transceiverbanken in Betrieb zu nehmen. Wäre das einen Versuch wert, die zu verbinden?

Ja, warum nicht.

Wie?

M.E. sind das immer(?) differentielle Pärchen. Davon braucht man mindestens zwei. Eins für den Takt und eins für die Daten. Falls der

Die meisten GT Transceiver Standarte übergeben kein clock

Artix-Transceiver schon CDR (clock data recovery) kann, reicht eine "Doppelader".

Alle AMD Transceiver können CDR

Falls der Datentransfer nicht nur in eine Richtung gehen soll, braucht man das Ganze für die Gegenrichtung nochmal. Auch ist es hilfreich, wenn eine stabile Taktquelle zur Verfügung steht. Etwas einfacher wird es, wenn Sender und Empfänger aus der identischen Taktquelle versorgt werden...

man braucht differentiellen clock an ref clock pins von den Transceiver Bank, wenn der nicht da ist geht nix

Da deine Datenrate unbekannt ist, schmeiss ich mal wahllos Bewährtes rein:

• i2s/SPORT über Transceiver getunnelt: Simpel, aber mir ist keine drop-in OpenSource-Lösung bekannt
• SATA: Da gibt es mehrere Refdesigns, die zumindest mit Gen1 schon auf dem Spartan6 ordentlich funktioniert haben, allerdings muss man sich dann mit dem migen-Geschnorze rumschlagen. Elektrisch muss es dann auch noch passen, und ohne CPU-Kern wird's allenfalls zäh.
• DVI (abgespeckt): Für Einweg ok, und wenn man nicht hoch takten muss, relativ simpel sowohl auf TX wie RX.

Wenn man die SERDES-Logik seines Ziel-FPGA soweit im Griff hat (Byte-Alignment!), kriegt man das Meiste wohl mit DVI und den 4 ControlWords für die Synchronisation erschlagen. Fahre aber allerdings lieber mit den Lattice-Serdes und bin mit den Details der Artix GTPs nicht mehr vertraut, your mileage may vary.

Eigentlich ein 'no-brainer':

https://www.amd.com/en/products/adaptive-socs-and-fpgas/intellectual-property/aurora8b10b.html

Nach Murphy sind aber die für Aurora nötigen "Spezial"-Pins auf dem Design des TO nicht zugänglich/angeschlossen ... Im Anhang ein Beispiel für die Komplexität des pin-outs.

Bradward B. schrieb:

Nach Murphy sind aber die für Aurora nötigen "Spezial"-Pins auf dem Design des TO nicht zugänglich/angeschlossen ...

Er schrieb:

Ich hätte aber die Möglichkeit, die Transceiverbanken in Betrieb zu nehmen. Wäre das einen Versuch wert, die zu verbinden?

Das ist alles was man fuer Aurora braucht.

Im Anhang ein Beispiel für die Komplexität des pin-outs.

Es ist ein FPGA pinout, schoen, und jetzt?

s ist ein FPGA pinout, schoen, und jetzt?

... könnte man die im pinout geforderten leitungen für den transceiver-block (data,clk,ref,cal) mit dem von TO als zugänglich (" ... mit Drähten an die FPGA-Pins der FBGA-Gehäuses, zumindest an einem Transciever-Transmitter-Paar ...") beschriebenen vergleichen und die implizit genannten Bedenken zur prinzipiellen Machbarkeit dieser Aktion still bestätigen.

Man kann auch mal ein Example design in die Designsourcen reinkloppen, das *.xcf entsprechend an die konkrete board-Verdrahtung erweitern und schauen, ob die toolchain durchläuft oder spätetestens beim routing wegen irgendwelcher MGT-spez. Design-rules das große Kotzen kriegt.

Statt Beispiel-design könnte man auch einen IBERT instanziieren und falls das alles einschliesslich bitgen durchläuft, mal mit aktivierten NearEnd Loopback schaun ob's prinzipiell möglich.

• https://adaptivesupport.amd.com/s/article/GT-IBERT-Loopback-Testing

Antti L. schrieb:

man braucht differentiellen clock an ref clock pins von den Transceiver Bank, wenn der nicht da ist geht nix

Wie macht er aber dann Clock Recovery?

Wie macht er aber dann Clock Recovery?

Da gibt es ein extra hardcore-sub-module innerhalb der schnellen Transceiver im FPGA namens CDR das das in Zusammenwirken mit den PLL's macht.

Letztens gabs da einen interessanten Vortrag dazu beim CERN, dort hat man das aber an einer modernenen Architekture gemacht (Ultrascale+), nicht Serie 7 wie der TO (vermutlich).

• https://indico.cern.ch/event/1467417/contributions/6393945/attachments/3063749/5418500/FDF25_frame_clock_recovery.pdf

Für die Serie 7 findet sich die Beschreibung in der UG482 (bspw.: https://0x04.net/~mwk/xidocs/ug/ug482_7Series_GTP_Transceivers.pdf) auf Seite 141 ff. .

Nach meinem Verständniss ist diese "Takt-Rückgewinnung" eher eine " gesteuerte Takt-Neugenerierung" und die Steuerung basiert auf einer Flankendetection und -verschiebung wie es eben eine PLL (phase locked loop) realisiert. Dazu hat es auch die Application-Note XAPP868 die das für die Vorgängerfamilien (ohne GTP-Block wie bspw. Spartan-6 und Virtex II) beschreibt: https://docs.amd.com/api/khub/documents/8xpkgnkZUvb_Gxka1kIcjA/content

In dem (re-aktivierten) thread: Beitrag "2 FPGAs bidirektional verbinden" gibt es auch Hinweise, wie man eine CDR ohne die GTP-Blöcke realisieren könnte.