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