Hallo Leute, mich würde interessieren wie diese Trainsceiver in den FPGA's funktionieren? Was ich bisher weiss ist, dass man über Trainsceiver PIN sehr hoche Geschwindigkeiten fahren kann. Bei Xilinx sind es im Kintex beispielsweise 12,5Gbps. Dazu habe ich folgende fragen: 1. Was genau machen die Transceiver Blöcke dann? Was ich weiss ist das sie eine asynchrone Überabtastung können. Desweiteren können die glaub ich auch Endcoding/Decoding von z.b. 8B/10B signalen. Habe gesehen das ein so ein Block um die 500 Ports hat oO Die müssen wohl sehr mächtig sein 2. Ich hab gesehen das spezielle PINs zu den GT geführt sind. Warum ist das so? können diese PINs etwas besonderes? Kann man auch normale IO's zu den GT führen? Warum kann man diese Geschwindigkeiten nicht über normale IO's erreichen? Man kann doch auch mit interner Logic eine asynchrone Überabtastung realisieren? Danke vielmals :)
Paul schrieb: > 1. Was genau machen die Transceiver Blöcke dann? Im Wesentlichen stecken da Serializer/Deserializer drin. Vereinfacht gesagt: Schieberegister. Die Daten werden im FPGA mit einem langsamen Takt parallel verarbeitet und auf der Schittstelle mit einem vielfachen des langsamen Taktes übertragen. Duke
Paul schrieb: > 1. Was genau machen die Transceiver Blöcke dann? Ne ganze Menge, leitungscodierung, Preamplifier, Trainingssequenz. Fehlercodierung, Clock/data recovery, scrambling, channel Bonding, spread spectrum … der Userguide allein für die MGT hat nicht umsonst mehrere hundert Seiten. Du wirst dir keine Freunde machen, wenn du dir diese von Forum "vorlesen" lassen willst, da wirst Du dich schon selbst anstrengen müssen. https://www.xilinx.com/support/documentation/user_guides/ug576-ultrascale-gth-transceivers.pdf http://billauer.co.il/blog/2016/03/mgt-gtx-fpga/ https://www.testandmeasurementtips.com/multi-gigabit-serial-protocols-demystified/ https://www.design-reuse.com/articles/10541/multi-gigabit-serdes-the-cornerstone-of-high-speed-serial-interconnects.html https://www.groundai.com/project/optimization-of-multi-gigabit-transceivers-for-high-speed-data-communication-links-in-hep-experiments/1
Das Thema ist ziemlich umfangreich wenn mans im Detail anpacken will. UG476 deckt da eigentlich alles noetige ab. Ich persoenlich finde den analog Teil vom RX sehr spannend mit seinem adaptiven Equalizer (Stichwort: Decision Feedback Equalization - DFE). Das ist auch der Schluessel warum ueberhaupt solch hohe Daten fehlerfrei uebertragen werden koennen. Schau dir mal dies Slides an, die komprimieren doch das Thema nochmal ganz gut runter: http://formation.in2p3.fr/Numerique12/XILINX_HighSpeedTransceivers_IN2P3.pdf
Hallo, danke für die Antworten. Für mich ist es sehr schwierig diese Datenblätter zu verstehen. Ich wollte eigentlich nur wissen warum man solche Transceiver braucht? Warum kann man das nicht mit normalen IO's und FPGA interne logik lösen? Was genau limitiert die standart IO's? Gruß Paul
Paul schrieb: > Was genau limitiert die standart IO's? Die Datenrate. ;-) Mit MGTs kommt man auf mehrere Gb/s bei normalen I/Os ist bei ca einem Gb/s Schluss. Warum das geht, liegt an dem speziellen HArdware Aufbau und wie der aussieht ist den Datenblaettern zu entnehmen (zumindest der Teil den die Hersteller freigeben, die genauen Internas sind natuerlich Betriebsgeheimnis).
Aber was soll ich mit der schnellen Datenübertragung über Gigabit Transceiver, wenn die interne Schaltung nicht schnell genug ist, um so viele Daten zu verarbeiten?
Intern kann man mit mehreren 100GBit verarbeiten. Das geschieht dann parallel. Der MGT schiebt die Daten zB. mit 10GBit raus. Intern werden die Daten mit einem parallelen Bus verarbeitet, zB 64Bit. Bei 64Bit wären das eine Frequenz 156,25MHz. Da kann man einiges mit der Frequenz machen.
Nachtrag: Aktuelle Architekturen kommen problemlos mit Datenbussen von 1024Bit und breiter aus. Mit einem Takt von 300MHz hat man so eine interne Datenrate von ca. 300GBit.
Wodurch ergibt sich dieser Unterschied dass man intern mehrere 100 GBit verarbeiten kann, aber nur mit einem Bruchteil davon Daten von außen annehmen?
Weil man intern sehr viel parallele Logik erzeugen kann, aber nur wenige Transceiver hat.
:
Bearbeitet durch User
Intern ist man auf einem Silizium Chip. Dieser ist sehr schnell da die Quelle und das Ziel von Daten nur wenige Mikrometer auseinander liegen und die Leitungen dafür perfekt optimiert sind. Wenn man mit der Außenwelt kommunizieren will, hat man weite Entfernungen und keine optimalen Signalbedingungen mehr. --Stark vereinfacht--
Stefan schrieb: > Wenn man mit der > Außenwelt kommunizieren will, hat man weite Entfernungen und keine > optimalen Signalbedingungen mehr. --Stark vereinfacht-- Außerdem benötigt man relativ hohe Ströme um die Leitungskapazitäten schnell genug umzuladen. Ein Ethernet-GBit PHY z.B. genehmigt sich glatt ein Watt mehr, sobald ein Kabel angesteckt wird. Duke
Das große Problem bei der Übertragung eines digitalen Signals ist die Signalqualität. Wenn Du dir ein Signal bei einer Datenrate von in paar kBit mit einem Oszi anschaust, siehst du ein Rechtecksignal. Bei ein paar MBit sind es eher sinusförmige Signale, und im GBit-Bereich hast du nur noch ein Knistern und Rauschen, aber nichts mehr, in dem man noch einzelne Zustände erkennen könnte. Um aus diesem Gewitter noch Daten mit hoher Zuverlässigkeit zu erkennen, ist ein erheblicher Aufwand nötig. Die Signale werden analog gefiltert, dann mit einem sehr schnellen ADC digitalisiert, dann digital gefiltert und dann einer Reihe von digitalen Fehlerkorrekturen unterzogen. Dazu kommen dann noch Verfahren zur Synchronisation, so wie bei einem einfachen UART anhand der Start- und Stopbits die Position der Nutzdaten im Bitstrom gefunden wird. Dann kommt irgendwann die Parallelisierung, sodass Du in jedem Takt z.B. 256 Bits gleichzeitig aus dem Transceiver bekommst, die du dann im FPGA weiterverarbeiten kannst. Die Signalqualität ist zudem stark abhängig von den Übertragungseigenschaften des Verbindung zwischen Sende- und Empfangstransceiver. Die Eigenschaften dieses Kanals sind anfangs unbekannt und müssen erst mal ermittelt werden. Dazu werden spezielle Trainingspattern gesendet, die der Empfänger kennt. Aus dem Vergleich zwischen empfangenen und erwarteten Pattern kann auf die Charakteristik des Kanals geschlossen werden und daraus werden die Koeffizienten der ganzen Filter berechnet. Meistens wird das Signal schon im Sender verzerrt, sodass diese Verzerrung während der Übertragung durch den Kanal teilweise rückgängig gemacht wird. Oftmals muss das Equalizing im Betrieb angepasst werden, weil sich die Kanalqualität z.B. durch Temperatur oder Störungen von außen ändert. Alles das macht der GBit-Transceiver. Das ist also viel mehr als einfach nur eine schnelle IO-Zelle. Was da drinsteckt ist konzentrierte Highend-Nachrichtentechnik, entsprechend groß und teuer sind diese Blöcke auch, und bei kleineren FPGAs gibts daher nur weniger oder gar keine.
Kleine Nachfrage zum Prinzip: Hat der Serializer eine richtige PLL drin, d.h. kann ich mir das aussuchen, wie hoch ich übertakte? Ein Blick über die o.g. Dokumente zeigt z.B. ein Videobeispiel für 3 Farben. Der FPGA taktet mit 300 MHz 2 Pixel (plausibel) - aber der Port mit 6MHz. Läuft also 10x schneller. Soweit ich es sehe, nutzt er den 8/10 Leitungscode. Ohne den könnte man auch mit 600x8=4,8 fahren, oder? Das angestrebte design hat einen Pixeltakt von 150 x2 und ich käme mit 2,4G aus, was der Transceiver noch kann. Hat jeder dieser Serializer-Port eine eigene PLL? Irgendwie wird das nicht so richtig deutlich.
Moin, Manni T. schrieb: > Hat der Serializer eine richtige PLL drin, d.h. kann ich mir das > aussuchen, wie hoch ich übertakte? Ja, das ist eine "richtige" PLL drinnen - sogar eine fuer jede Richtung, aber du kannst da nicht so drauf zugreifen, wie du das von einer PLL erwartest. Gruss WK
D.h. dann auch, jeder Transceiver könnte mit einem anderen Takt-Schema, also auch mit einem anderen Standard arbeiten? Sagen wir einer macht Video, ein anderer SATA? Die Transceiver sind im Übrigen deshalb in der Diskussion, weil die IOs die gewünschte Bandbreite nicht bringen. Hier im Team hat jemand locker vom Hocker 1,2Gbps eingeplant, weil die PLL laut Spezifikation 1200MHz kann. Daraus resultierten dann 2,4Gps im DDR-Modus. Das Tolle: In der Simulation hat es wohl funktioniert. Tobias B. schrieb: > bei normalen I/Os ist bei ca einem Gb/s Schluss. Das würde mich interessieren, wie das geht. Das Testdesign im Hause liefert einen PLL-Takt von 350MHz als maximale Frequenz für das lokale design, nach dem FIFO. Der Port-Pin macht DDR, was zu allerhöchsten 700 führt. Werden wir aber nicht bauen, da 350 schon eine Plackerei ist und den höchsten (teueren) speed grade einfordert.
Moin, Manni T. schrieb: > D.h. dann auch, jeder Transceiver könnte mit einem anderen Takt-Schema, > also auch mit einem anderen Standard arbeiten? Sagen wir einer macht > Video, ein anderer SATA? Ist nicht ausgeschlossen. Kann halt auch so Sachen geben, dass immer 2 Transceiver sich irgendwelchen PLL-Krams teilen und man jetzt nicht ganz vogelwild drauflos programmieren/beschreiben kann. Vor zig Jahren hatte ich mal einen Spartan6 mit 2x GBit Ethernet und 1x PCIe am Laufen - dabei ist ja z.b. der Empfangstakt fuer die Ethernetze auch unterschiedlich... > Die Transceiver sind im Übrigen deshalb in der Diskussion, weil die IOs > die gewünschte Bandbreite nicht bringen. Hier im Team hat jemand locker > vom Hocker 1,2Gbps eingeplant, weil die PLL laut Spezifikation 1200MHz > kann. Daraus resultierten dann 2,4Gps im DDR-Modus. Das Tolle: In der > Simulation hat es wohl funktioniert. Vielleicht waer's nicht schlecht, einfach mal die Datenblaetter des betreffenden FPGAs zu konsultieren, da stehen manchmal ueberraschende Sachen drinnen... Gruss WK
Hab ich ja, daher ist mir der faux pas ja auch aufgefallen. Wieder ein bachelor-error, den keiner zuvor aufgedeckt hat. Der angedachte FPGA hat nun zu wenig Transceiver. Das wird ein Spass am Montag. Ich wollte nur schauen, ob wir einen schnellen Ausweg finden. Sich durch alle Dokumente zu wühlen und 100 Optionen abzugleichen ist kaum möglich.
Moin, Manni T. schrieb: > Ich wollte nur schauen, ob wir einen schnellen Ausweg finden. Sich durch > alle Dokumente zu wühlen und 100 Optionen abzugleichen ist kaum möglich. Dann ist halt die Wahrscheinlichkeit, mit dummem Gesicht dazusitzen, wenn nix geht, hoeher. Gibt ja auch noch zig andere Einschraenkungen bei FPGAs, wie z.b. Max. Anzahl an Clk-Netzen, -Buffern, Routing von/zu den Transceivern, etc., IO-Spannungen an Baenken... Gruss WK
Ich sehe schon, das Thema geht am Montag an den Entwicklungsleiter zurück! Schönes Wochenende!
Manni T. schrieb: > Sagen wir einer macht > Video, ein anderer SATA? Ja. Manni T. schrieb: > Hier im Team hat jemand locker > vom Hocker 1,2Gbps eingeplant Ja, das kann der Artix7 im schnellsten Speedgrade. Manni T. schrieb: > Daraus resultierten dann 2,4Gps im DDR-Modus. Nein! Wenn man 1,2 GHz nimmt und damit DDR macht, dann resultieren da 2,4 GBit/s (wenn man 1 Bit je Flanke überträgt). Aber deine 1,2 GBit/s sind schon in der Einheit GBit/s, da wird dann durch DDR nicht doppelt so viel draus. Nicht Frequenz und Bitrate verwechseln. Manni T. schrieb: > Das Tolle: In der > Simulation hat es wohl funktioniert. Da fehlen Details. Wenn tatsächlich mit den Hersteller Hardware Primitiven simuliert wurde, dann müsste es Fehler geben. Manni T. schrieb: > Der Port-Pin macht DDR, was zu allerhöchsten 700 > führt. Werden wir aber nicht bauen, da 350 schon eine Plackerei ist und > den höchsten (teueren) speed grade einfordert. Deinen 700 fehlt die Einheit. MHz? MBit/s? Wie geschrieben, am Artix7 kann ein normaler Pin 1250 MBit/s. Wenn man DDR LVDS macht und einen SerDes verwendet. Andere neuere FPGAs können da teilweise noch ein ganzes Stück mehr.
:
Bearbeitet durch User
Gustl B. schrieb: > Manni T. schrieb: >> Daraus resultierten dann 2,4Gps im DDR-Modus. > Nein! Doch, in der Simulation eben. Die Frequenz der PLL von 1200 (das war wohl das Maximale) wurde auf den Pin gegeben (DDR-Zelle) und dann das Doppelte getaktet. Zumindest war das die Schlussfolgerung. Dass das nicht sein konnte, war mir sofort klar. Die Frage ist nur: Wie hoch kann man konkret? Gustl B. schrieb: > 1250 ... wenn man DDR LVDS macht und einen SerDes verwendet. Das würde aber bedeuten, dass man den mit >600 MHz Takten muss, wenn ich richtig rechne. Nur zur Sicherheit: Wir reden nicht von diesen MGT mit integrierter PLL und 3/6/12 Gbps. Es geht wirklich um normale IOs. Wie kommt man da 600MHz durch das design?
Manni T. schrieb: > Das würde aber bedeuten, dass man den mit >600 MHz Takten muss, wenn ich > richtig rechne Der SerDes braucht zwei Takte, einen schnellen zum raustakten und einen langsamen mit dem die Daten gefüttert werden. Wenn du extern 1250 MBit/s schaffen willst und intern die Daten parallel mit 8 Bits gleichzeitig anlieferst, dann braucht der SerDes 1250/8 MHz mit den Daten im FPGA und zusätzlich noch 1250/2 MHz zum Raustakten. Manni T. schrieb: > Nur zur Sicherheit: Wir reden nicht von diesen MGT mit integrierter PLL > und 3/6/12 Gbps. Es geht wirklich um normale IOs. Richtig. Manni T. schrieb: > Wie kommt man da 600MHz durch das design? Der schnelle Takt wird nur zum Raustakten genutzt. Der kommt direkt von einer PLL. Anliefern kannst du dem SerDes die Daten mit geringerem Takt, eben ja nach Serialisierungsfaktor. Ich glaube die SerDes können bei Xilinx bis zu 14 Bit/Takt annehmen. Bedeutet also, dass du intern mit 1250/14 MHz anliefern musst.
Gustl B. schrieb: > Der SerDes braucht zwei Takte, einen schnellen zum raustakten und einen > langsamen mit dem die Daten gefüttert werden. ... und den man mitliefern muss, damit die Empfänger-PLL den Sampletakt rekonstruieren kann. Ansonsten gibt es gehacktes und man muss den Takt händisch rekonstruieren, z.B. mit einem Transceiver alles sampeln.
Auf dem Zybo Z7Board gibt es beispielsweise eine Implementierung für DVI, da ist die Serialisierung modular aufgebaut (SERDES, PLL, Taktverteilung einzeln instanziiert). https://digilent.com/reference/programmable-logic/zybo-z7/start Vielleicht hilft Dir das ja noch weiter.
Hallo zusammen, danke für die Beiträge. Mich würde interessieren, ob man die Xilinx Trainsceiver für eine schnelle/genaue Edge Detection verwenden kann, wenn man z. B. ein einzelnes Signal in das Vivado FPGA-Design einspeist? Wird sowas in der Praxis verwendet? Schönes Wochenende
TheInterestedOne schrieb: > Wird sowas in der Praxis verwendet? Im Forschungsbereich als TDC möglicherweise schon. Ich weiß aber nicht, ob die Transceiver ohne clock recovery funktionieren, da ja kein Takt mit übertragen wird.
Rick D. schrieb: > Ich weiß aber nicht, ob die Transceiver ohne clock recovery > funktionieren, da ja kein Takt mit übertragen wird. Die laufen doch auch mit einem internen Oszillator / bzw PLL oder? Müsste also funktionieren.
Die Transceiver lassen sich einwandfrei für Edge Detection nutzen mit internem Takt. Sie brauchen aber sinnvollerweise ein differentielles Signal. Je nach FPGA kann man auch die Comma Detect Einheit nutzen um gleich ein Triggersignal zur Flanke zu bekommen. Allerdings haben die Transceiver die Eigenschaft nach zu jedem Reset um einzelne Bits zu springen. Für die eigentliche Anwendung (PCIe & Co) ist das egal, weil da ein Bitalignment basierend auf dem Datenstrom gemacht wird. Aber für Zeitmessungen relativ zum FPGA-internen Takt könnte das nerven. Muss man ausprobieren.
Andreas H. schrieb: > Die Transceiver lassen sich einwandfrei für Edge Detection nutzen mit > internem Takt. Sie brauchen aber sinnvollerweise ein differentielles > Signal. Je nach FPGA kann man auch die Comma Detect Einheit nutzen um > gleich ein Triggersignal zur Flanke zu bekommen. > Allerdings haben die Transceiver die Eigenschaft nach zu jedem Reset um > einzelne Bits zu springen. Für die eigentliche Anwendung (PCIe & Co) ist > das egal, weil da ein Bitalignment basierend auf dem Datenstrom gemacht > wird. Aber für Zeitmessungen relativ zum FPGA-internen Takt könnte das > nerven. Muss man ausprobieren. Gibt es dazu Literatur oder hilfreiche Papers, die du empfehlen kannst? Bei AMD/Xilinx direkt habe ich zu dem Thema nichts gefunden.
Gesammelte Antworten: Die Transen laufen immer mit einer internen PLL, die Frage ist nur, ob diese sich a) auf einen externen Takt aufsynchronisiert, b) den gfs. zuvor rekonstruiert oder c) frei läuft. Fürs Sampeln von Signalen kann man probieren, sich auf einen externen Takt aufzusynchronisieren, wenn da Daten mit ausreichenden Sprüngen kommen, weil diese "digital" sind, -> "Eintrainieren", ansonsten gilt bei unbekannten Signalen eben die Analogbetrachtung und Nyquist, d.h. man muss überabtasten und auswerten. Literatur oder konkrete Papers kenne ich keine. Man muss eben die jeweiligen Transceiver aktivieren. Dazu gibt es Dokumente en masse. Fürs Sampeln gelten die allgemeinen Regeln. Die Transceiver funktionieren diesbezüglich nicht anders, nur schneller. Konkret: TheInterestedOne schrieb: > Mich würde interessieren, ob man die Xilinx Trainsceiver für eine > schnelle/genaue Edge Detection verwenden kann Das muss man sogar, weil man in der Regel die PLL justieren muss und das nach Schema b) oben anhand der Daten und deren Flanken passiert. > wenn man z. B. ein einzelnes Signal in das Vivado FPGA-Design einspeist? wenn du es als symmetrisches/differentielles Signal in den Port des FPGAs einspeist. Unter "FPGA-Design" versteht man in der Regel die SW = VHDL, das letztlich zur firmware führt sowie deren Erzeugungsprozess. > Wird sowas in der Praxis verwendet? Ja, in praktisch jedem design, das synchrone Transen benutzt. Die Inputs sampeln sozusagen schwebend auf Nyquist wobei die Abtastfrequenz die Taktflanken (oder beide!) sind. Was das Sampeln von "irgendwelchen" Daten angeht: Ja auch das wird gemacht. Es muss nur klar sein, dass das digitale Daten sind, von denen nur die Grundwelle erfasst wird, sofern diese 30%-40% der Abtastfrequenz nicht überschreitet. Und nur die kann auch rekonstruiert werden. Alles weitere an Oberwellen führt zu falschen Informationen. Will man ein digitales Signal mit seiner relativen Phase rekonstruieren, um es wieder auszugeben, geht das sinnvoll ab Faktor 1:2.5 (man bekommt immer 2 oder 3 Bits, maximal 2x 3in Folge) , besser und einfacher mit Faktor 1:3. Braucht etwas Schaltungsintelligenz. Mit einen GTX 12.5 habe ich einen 5Gbps sampler am Laufen.
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.