Diese Seite ist der vierte Beitrag einer Artikelserie, die den Multi-Gigabit-Transceiver (MGT) vorstellt. Die vorherigen Seiten haben den MGT und einige Protokolle behandelt, die mit ihm verwendet werden, sowie einige Kodierungsverfahren.
Einführung
Wie bereits auf der ersten Seite dieser Serie erwähnt, ist ein MGT nur eine hochentwickelte Art von SERDES. Zu den Gründen, warum er so hochentwickelt ist, gehört, dass sich in einem MGT einige Funktionsblöcke befinden, die bei der Implementierung bestimmter Protokolle helfen. Diese Seite erläutert die Gedanken hinter einigen dieser Funktionsblöcke.
Der Teil des MGTs, der diese Einheiten enthält, wird üblicherweise als PCS (Physical Coding Sublayer) bezeichnet. Dieser Name ist irreführend, denn ein Teil der Logik innerhalb des PCS hat weder mit Kodierung noch mit Dekodierung zu tun.
Dies ist ein Blockdiagramm eines typischen MGTs, das die Position des PCS im größeren Zusammenhang zeigt.
Der PCS-Block umfasst alles zwischen dem PMA und der Anwendungslogik. Ich werde die Ausdrücke Tx-PMA und Tx-PCS für die Teile des MGTs verwenden, die zum Senden von Daten dienen. Entsprechend stehen Rx-PMA und Rx-PCS für die Teile, die zum Empfangen von Daten verwendet werden.
Der Tx-PCS beginnt an den Eingangsports, an denen die Anwendungslogik die Daten zur Übertragung an den MGT übergibt. Seine Rolle endet, wenn ein paralleles Wort vorliegt, das aus den Bits besteht, die zur Übertragung über die physikalischen Leitungen bereit sind. Dieses parallele Wort wird dem Tx-PMA-Teil übergeben, der es serialisiert und in ein elektrisches Signal umwandelt.
Der Rx-PCS beginnt analog dazu mit dem parallelen Datenwort, das der Rx-PMA empfangen und deserialisiert hat, und endet an den Ausgangsports, an denen der MGT die Daten an die Anwendungslogik übergibt.
Da der PCS aus Logik besteht, die ausschließlich mit dem parallelen Wort arbeitet, ist es offensichtlich, dass die gesamte Funktionalität des PCS auch in der Logikstruktur implementiert werden kann. Diese Logik ist trotzdem im MGT untergebracht – aus demselben Grund, aus dem viele Funktionsblöcke als Hard-IP implementiert sind. Manche Protokolle nutzen die Kodierungsfähigkeiten des PCS. Andere Protokolle (z. B. xillyp2p) stützen sich auf eigene Methoden zur Verarbeitung des Datenstroms, was die Nutzung des MGTs viel einfacher macht, wie in diesem Beispiel-Design gezeigt wird.
Da jedes MGT einen anderen internen Aufbau hat, ist es unmöglich, den detaillierten Datenfluss im PCS eines MGTs so zu beschreiben, dass er alle MGTs abdeckt. Die Beschreibungen und Erläuterungen unten konzentrieren sich deshalb darauf, was die Funktionsblöcke des PCS bewirken sollen. Eine detaillierte Beschreibung eines PCS und seiner Bausteine findet sich nur in der Dokumentation des jeweiligen MGTs. Mit den folgenden Erläuterungen sollte das Lesen dieser Dokumentation hoffentlich leichter fallen.
Kodierung und Dekodierung
Auf der vorherigen Seite wurden mehrere Kodierungsverfahren vorgestellt: 8b/10b, 64b/66b, 64b/67b, 128b/130b und 128b/132b.
Die Implementierung der 8b/10b-Kodierung ist in allen FPGA-MGTs innerhalb ihres PCS enthalten. Die Implementierung umfasst das Kodieren und Dekodieren der 8-Bit-Wörter in 10-Bit-Wörter und umgekehrt sowie die weiteren Merkmale, die auf der vorherigen Seite erwähnt wurden: K-Symbole, Synchronisierung und Ausrichtung auf ein Comma-Symbol (K28.5) sowie die Reaktion auf Skip-Symbole (K28.0).
Was die anderen Kodierungsverfahren betrifft, so implementiert jedes MGT eine andere Auswahl davon. Außerdem unterscheiden sich die MGTs darin, welche Merkmale der Kodierungen implementiert sind. Manchmal implementiert der PCS des MGTs nur die erforderliche Gearbox, manchmal ist auch der Mechanismus zur automatischen Synchronisierung enthalten. Es gibt keinen Standardumfang an Merkmalen.
Gearboxen
Im gesamten PCS sowie an der Schnittstelle zur Anwendungslogik wird der Datenstrom auf dem physikalischen Kanal durch ein paralleles Wort repräsentiert. Die Breite dieses parallelen Worts kann sich ändern, während die Daten die verschiedenen Verarbeitungsschritte im PCS durchlaufen. Wenn die Daten beispielsweise einen 8b/10b-Kodierer durchlaufen, ändert sich die Wortbreite von 8 Bit auf 10 Bit.
Die Schnittstelle zum Senden und Empfangen von Anwendungsdaten zum MGT besteht allerdings aus Eingangs- und Ausgangsports, deren Breite immer ein Vielfaches von 8 ist. Typischerweise ist diese Breite eine der folgenden: 16, 32, 40, 64, 80, 128 oder 160 Bit.
Was passiert aber zum Beispiel, wenn die 64b/66b-Kodierung verwendet wird? Bei dieser Kodierung besteht der Datenstrom auf dem physikalischen Kanal aus Segmenten von jeweils 66 Bit. Wenn diese Daten mit einem parallelen Wort der Breite 64 Bit dargestellt werden, erscheint der Anfang jedes Segments bei jeder Übertragung an einer anderen Position in diesem Wort. Keine der zulässigen Breiten für die Schnittstelle zur Anwendungslogik vermeidet dieses Problem.
Genau dafür ist eine Gearbox da. Sie ist ein Logikmodul, das die an ihrem Eingangsport ankommenden Daten in ein paralleles Wort mit anderer Breite umorganisiert.
Angenommen, wir möchten Daten übertragen, die mit 64b/66b kodiert wurden, und zwar mithilfe eines MGTs, wobei der Kodierer in der Anwendungslogik implementiert ist. Der Ausgang des Kodierers ist 66 Bit breit, aber der Eingang des MGTs kann entweder 64 oder 80 Bit breit sein (oder andere, noch weniger relevante Alternativen). Um das zu lösen, müssten wir eine Gearbox implementieren, die das vorhandene parallele Wort (66 Bit breit) in ein Wort umwandelt, das das MGT akzeptieren kann (64 Bit breit). Diese Situation ist besser zu vermeiden.
Aus diesem Grund enthalten MGTs häufig eine oder mehrere Gearboxen in ihrem PCS-Teil. Insbesondere wenn das MGT einen 64b/66b-Kodierer (oder ähnliche Kodierer wie 128b/130b) enthält, ist auch eine passende Gearbox im MGT vorhanden. Auf diese Weise übernimmt das MGT alle Aufgaben, die für die Übertragung kodierter Daten notwendig sind: Zuerst werden die Daten mit dem Kodierer des MGTs kodiert, dann ändert die Gearbox die Breite des parallelen Worts, sodass dieses Wort dem Tx-PMA-Teil zur Übertragung übergeben werden kann. Eine ähnliche Lösung wird beim Empfang von Daten verwendet.
Da die Wörter auf beiden Seiten der Gearbox unterschiedlich breit sind, unterscheidet sich die Anzahl der Bits, die in die Gearbox hineingehen, von der Anzahl der Bits, die aus ihr herauskommen. Ist das parallele Wort am Eingang breiter, muss die Gearbox gelegentlich die Annahme eines Worts verweigern, um das auszugleichen. Ist umgekehrt das parallele Wort am Ausgang breiter, hat die Gearbox nicht immer gültige Daten an ihrem Ausgang. Wenn die Gearbox also nur mit einem einzigen Takt arbeitet, muss es auch ein Flusskontrollsignal (Flow Control) geben, das die unterschiedliche Bitmenge auf beiden Seiten ausgleicht. In der Terminologie von Xilinx / AMD wird dies als synchrone Gearbox bezeichnet.
Alternativ kann die Gearbox von zwei Takten abhängen. Die Frequenzen dieser Takte werden so gewählt, dass sie das Verhältnis zwischen den Wortbreiten auf beiden Seiten der Gearbox ausgleichen. Der Vorteil dieser Methode ist, dass der Datenfluss auf keiner Seite der Gearbox jemals angehalten wird. Eine solche Gearbox erfordert allerdings zwei Takte und arbeitet in zwei Taktdomänen (Clock Domains). Diese Lösung wird als asynchrone Gearbox bezeichnet.
Tx-Puffer (Tx-FIFO)
Der Tx-Puffer (häufig als Tx-FIFO bezeichnet) ist ein kleiner FIFO im Tx-PCS. Seine Tiefe beträgt üblicherweise 16 oder 32 Datenelemente, und unter normalen Betriebsbedingungen ist er in der Regel halbvoll. Der Grund für diesen FIFO ist etwas kompliziert und wird unten erläutert. Diese Erklärung beantwortet jedoch nicht die einzige Frage, die bei der Konfiguration eines MGTs meist relevant ist: Soll der Tx-Puffer aktiviert werden oder nicht?
Die Antwort lautet, dass der Tx-Puffer in den meisten Fällen aktiviert sein sollte. Der einzige Grund, den Tx-Puffer nicht zu verwenden, ist, wenn seine Verzögerung ein Problem darstellt: Die Verwendung eines Tx-Puffers bedeutet eine unbekannte Verzögerung zwischen dem Augenblick, in dem ein paralleles Wort an das MGT übergeben wird, und dem Augenblick, in dem dieses Wort auf der physikalischen Schicht gesendet wird. In den meisten Anwendungen bedeutet das eine Unsicherheit von etwa 0,1 μs oder weniger, sodass das Protokoll dieser Verzögerung gleichgültig gegenübersteht.
Warum dieser FIFO benötigt wird, wird im Folgenden erklärt.
Innerhalb eines Tx-PCS gibt es mindestens zwei Taktdomänen: Der erste Takt wird für die Schnittstelle zur Anwendungslogik verwendet. Der zweite Takt (manchmal XCLK genannt) wird dort verwendet, wo der Tx-PCS das parallele Wort zur Übertragung an den Tx-PMA übergibt.
Das Thema der Taktversorgung innerhalb eines MGTs wird auf einer eigenen Seite behandelt. Für jetzt genügt es zu verstehen, warum es zwei getrennte Takte geben muss. Um dies zu erklären, vergleichen wir das MGT mit einem gewöhnlichen SERDES.
Angenommen, wir möchten Daten mit einer Rate von 1000 Mbit/s über einen gewöhnlichen Ausgangspin übertragen. Die meisten heutigen FPGAs haben zu diesem Zweck einen SERDES an jedem Ausgangspin. Nehmen wir für dieses Beispiel an, dass die Anwendungslogik den SERDES mit einem parallelen Wort speist, das 8 Bit breit ist. Der Takt für dieses parallele Wort hat folglich 125 MHz.
Entsprechend wird der SERDES mit zwei Takten gespeist: einem 125-MHz-Takt und einem zweiten Takt mit einer Frequenz von 500 MHz. Der SERDES verwendet beide Taktflanken des 500-MHz-Takts, sodass die Daten mit der gewünschten Rate von 1000 Mbit/s übertragen werden.
Die beiden Takte, die der SERDES erhält, müssen zueinander ausgerichtet sein. Beispielsweise muss die steigende Flanke des 500-MHz-Takts gleichzeitig mit der steigenden Flanke des 125-MHz-Takts auftreten. Das ist für den ordnungsgemäßen Betrieb des SERDES notwendig. Diese Ausrichtung wird erreicht, indem man zur Erzeugung beider Takte einen einzigen PLL verwendet und Taktpuffer einsetzt, die dieselbe Ausbreitungsverzögerung (Propagation Delay) haben. Das ist eine übliche Methode, um sicherzustellen, dass Takte ausgerichtet sind: Siehe die Erläuterung über verwandte Takte (Related Clocks).
Aber was, wenn wir 5000 Mbit/s übertragen wollen? Das ist für einen gewöhnlichen Ausgangspin zu viel, also wird ein MGT benötigt. Auch im MGT befindet sich ein SERDES. Nehmen wir an, dass das parallele Wort, das zu diesem SERDES geht, eine Breite von 32 Bit hat. Der zugehörige Takt hat demnach eine Frequenz von 156,25 MHz. Nehmen wir ferner an, dass die Schnittstelle zur Anwendungslogik ebenfalls aus einem parallelen Wort von 32 Bit Breite besteht. Die Taktfrequenz für diese Schnittstelle beträgt also ebenfalls 156,25 MHz. Aber ist es dasselbe Taktsignal?
Um das parallele Wort zu übertragen, muss der SERDES im MGT mit einem 2500-MHz-Takt verbunden werden (auf beiden Taktflanken wird ein neues Bit übertragen). Diese Frequenz ist für die allgemeinen PLLs des FPGAs zu hoch. Ebenso ist es unmöglich, für diesen Takt die Taktpuffer oder anderen Verdrahtungsressourcen des FPGAs zu verwenden. Das MGT muss daher über eigene PLLs und Leitungen verfügen, um die beiden ausgerichteten Takte zu erzeugen, die der SERDES benötigt. Weitere Einzelheiten finden sich auf der Seite über die Taktversorgung des MGTs.
Jetzt sind wir in der Lage zu verstehen, warum es im Tx-PCS mindestens zwei Taktdomänen gibt. In diesem Beispiel übergibt der Tx-PCS dem Tx-PMA ein paralleles Wort von 32 Bit Breite. Der zugehörige Takt ist 156,25 MHz. Dieser Takt wird vom PLL des MGTs erzeugt, um die Ausrichtung mit dem 2500-MHz-Takt sicherzustellen. Die Schnittstelle zwischen Anwendungslogik und MGT verwendet zwar exakt dieselbe Taktfrequenz, dennoch kann die Anwendungslogik nicht dasselbe Taktsignal verwenden: Der Takt der Anwendungslogik muss durch einen Taktpuffer in der Logikstruktur laufen, damit er alle Logikelemente ohne Taktversatz (Clock Skew) erreicht. Wegen der Verzögerung dieses Taktpuffers ist der Takt der Anwendungslogik nicht von Natur aus mit dem 2500-MHz-Takt ausgerichtet.
Der einfachste Weg für einen Taktdomänenübergang (Clock Domain Crossing) ist die Verwendung eines FIFOs (wie auf einer Seite zu diesem Thema erwähnt). Der Tx-Puffer ist dieser FIFO.
MGTs, die die Möglichkeit bieten, den Tx-Puffer zu umgehen, bieten auch andere Methoden an, um die notwendige Ausrichtung zwischen den Takten im Tx-PCS sicherzustellen. Diese Methoden sind jedoch kompliziert und fehleranfällig.
Rx-Puffer (Rx-FIFO)
Der Rx-Puffer (häufig als Rx-FIFO bezeichnet) ist ein kleiner FIFO im Rx-PCS. Im Prinzip ist dieser Puffer dasselbe wie der Tx-Puffer, sodass alles, was oben über den Tx-Puffer gesagt wurde, auch für den Rx-Puffer gilt. Insbesondere ist die Antwort auf die Frage, ob dieser Puffer aktiviert werden sollte, dieselbe: In den meisten Anwendungen sollte der Rx-Puffer aktiviert sein, außer wenn die dadurch verursachte Verzögerung nicht akzeptabel ist.
Der Rx-Puffer hat jedoch einen zusätzlichen Zweck: Er erlaubt dem Rx-PCS, mit zwei Takten zu arbeiten, deren Frequenzen geringfügig voneinander abweichen. Wir wollen uns nun ansehen, warum eine solche Abweichung auftreten kann.
Zunächst sollten wir uns daran erinnern, dass sich diese Diskussion auf den Teil des MGTs konzentriert, der einen Datenstrom empfängt. Dieser Datenstrom wird jedoch von einem anderen MGT erzeugt, das sich auf einen anderen Referenztakt stützt (in den meisten Szenarien). Das MGT, das den Datenstrom empfängt, hat oft keinen Zugang zu dem Takt, den der Sender verwendet. Stattdessen erzeugt der Empfänger eine Kopie dieses Takts ausschließlich auf der Grundlage des Datenstroms (das wird CDR, Clock Data Recovery genannt).
Dadurch arbeitet der Rx-PMA mit einem Takt, der sich an die Datenrate des Senders anpasst. Die Frequenz dieses Takts ist innerhalb einer definierten Toleranz ungewiss. Das Protokoll legt stets fest, wie stark die Frequenz von einem bestimmten Nennwert abweichen darf, aber es gibt immer eine gewisse Unsicherheit.
Die Schnittstelle zur Übergabe paralleler Wörter vom Rx-PMA an den Rx-PCS hängt daher von einem Takt ab, der sich an den Sender anpasst. Der Rx-PCS muss also synchron zu einem fremden Takt arbeiten.
Warum unterscheidet sich das vom Tx-PCS? Erinnern wir uns an die Diskussion über den Tx-Puffer: Im Tx-PCS gibt es zwei Taktdomänen. Obwohl diese beiden Takte nicht dasselbe Taktsignal sind, haben sie exakt dieselbe Frequenz, weil sie auf demselben Referenztakt basieren.
Ebenso gibt es im Rx-PCS zwei Taktdomänen. Einer dieser Takte hat eine unbekannte Frequenz. Wie steht es mit dem anderen Takt? Die Antwort ist, dass es von den Anforderungen der Anwendungslogik abhängt: In den meisten Szenarien wird ein MGT verwendet, um ein bidirektionales Protokoll zu implementieren. Dieses Protokoll beinhaltet das Senden von Daten als Antwort auf empfangene Daten. Es ist daher praktisch, dass die gesamte Anwendungslogik synchron zu einem einzigen Takt ist. Konkret ist die gebräuchlichste Lösung, dass die gesamte Anwendungslogik synchron zu dem Takt ist, der für das Senden verwendet wird. Das bedeutet, dass die Schnittstelle zwischen dem Rx-PCS und der Anwendungslogik synchron zu demselben Takt ist wie beim Tx-PCS.
Mit diesem Ansatz haben die beiden Takte im Rx-PCS nicht dieselbe Frequenz. Infolgedessen empfängt der Rx-PCS die Daten vom Rx-PMA mit einer anderen Rate, als er sie an die Anwendungslogik weitergibt. Der Rx-Puffer kann diesen Unterschied vorübergehend aufnehmen: Wenn die Anwendungslogik die Daten langsamer abholt, sammelt der Rx-Puffer den Überschuss an. Wenn die Anwendungslogik die Daten schneller abholt, entleert sich der Rx-Puffer allmählich.
Das ist natürlich eine sehr vorübergehende Lösung. Der Rx-Puffer wird früher oder später überlaufen (Overflow) oder leer laufen, wenn nichts unternommen wird, um seinen Füllstand bei etwa der Hälfte seiner Kapazität zu halten. Es gibt verschiedene Mechanismen für diesen Zweck. Erinnern wir uns zum Beispiel an die vorherige Seite: Wenn die 8b/10b-Kodierung verwendet wird, können Skip-Symbole eingefügt werden, um Unterschiede zwischen den Taktfrequenzen auszugleichen. Der Mechanismus zur Nutzung der Skip-Symbole ist im Rx-PCS implementiert: Ist der Rx-Puffer mehr als halbvoll, schreibt der Rx-PCS keine Skip-Symbole in den Rx-Puffer. Dadurch sinkt der Füllstand. Ist der Rx-Puffer dagegen weniger als halbvoll, liest der Rx-PCS die Skip-Symbole wiederholt aus dem Rx-Puffer. Dadurch füllt neuer Daten den Puffer, während dieser nicht entleert wird. Folglich steigt der Füllstand des Rx-Puffers.
Der Rx-Puffer wird wegen dieser Fähigkeit, vorübergehende Unterschiede in seinem Füllstand aufzunehmen, oft als elastischer Puffer bezeichnet. Es ist wichtig zu beachten, dass diese Fähigkeit nicht immer benötigt wird: Wenn die Anwendungslogik mit dem Rx-PCS über einen Takt verbunden ist, der dieselbe Frequenz hat wie der Takt des Rx-PMA, verhält sich der Rx-Puffer im Prinzip genauso wie der Tx-Puffer. Bei diesem Ansatz ist die Anwendungslogik dafür verantwortlich, den Taktdomänenübergang (Clock Domain Crossing) zu implementieren, falls ein solcher notwendig ist. Dieser Ansatz erlaubt es auch, den Rx-Puffer bei Bedarf zu deaktivieren (insbesondere um die Verzögerung zu vermeiden). Xillyp2p ist ein Beispiel für eine Anwendungslogik, die die Daten mit dem Takt des Rx-PMA empfängt, aber die Verwendung des Rx-Puffers erlaubt, um die Taktversorgung zu vereinfachen.
Funktionen im Zusammenhang mit pseudozufälligen Bitfolgen
Eine pseudozufällige Bitfolge (PRBS) ist eine Bitfolge, die zufällig erscheint, es aber nicht wirklich ist: Eine PRBS wiederholt sich periodisch. Da es einfach ist, eine PRBS mit sehr langen Perioden (mehrere Millionen Bits) zu erzeugen, ähneln die statistischen Eigenschaften einer PRBS denen einer wirklich zufälligen Bitfolge.
Die gebräuchlichste Methode, eine PRBS zu erzeugen, ist ein lineares rückgekoppeltes Schieberegister (Linear-Feedback Shift Register, LFSR). Diese Logik besteht aus einigen Flip-Flops und XOR-Gattern, sodass ein LFSR nicht viele Ressourcen für die Implementierung benötigt. Ein Beispiel für ein häufig verwendetes LFSR findet sich auf einer eigenen Seite, die ein mit LFSRs zusammenhängendes mathematisches Thema behandelt.
Der PCS-Teil eines MGTs verfügt üblicherweise über einige Funktionen im Zusammenhang mit PRBS. Insbesondere kann der MGT über eine Implementierung für einen Verwürfler (Scrambler) verfügen. Wenn die Synchronisierung des Verwürflers im Rx-PCS implementiert ist, kann das viel Arbeit sparen.
Eine weitere sehr häufige Anwendung einer PRBS ist das Testen des physikalischen Kanals auf Fehler. Das ist eine nützliche Methode, weil der Empfänger die korrekte Bitfolge mithilfe eines LFSR leicht selbst erzeugen kann. Fehler auf dem physikalischen Kanal werden erkannt, indem die lokal erzeugte Bitfolge mit dem ankommenden Datenstrom verglichen wird. Dieser Mechanismus ist in der Logikstruktur nicht schwer zu implementieren, aber einige MGTs besitzen diese Fähigkeit dennoch eingebaut.
Leider kann der physikalische Kanal nicht für die Übertragung von Daten genutzt werden, während mit Hilfe der PRBS ein Fehlertest durchgeführt wird. Es ist daher unmöglich, die Qualität des Kanals zu überwachen, während er tatsächlich verwendet wird. Einige Protokolle haben Mechanismen zur Fehlermeldung, aber normalerweise wird ein Fehler nur gemeldet, wenn er übertragene Daten gestört hat. Eine Ausnahme ist xillyp2p, das auch Fehler meldet, die auftreten, während die Verbindung im Leerlauf ist.
Damit ist die vierte Seite in dieser Serie über MGTs abgeschlossen. Die nächste Seite beginnt mit der Diskussion des PMA und seiner Fähigkeiten, schwierige physikalische Kanäle auszugleichen, sowie seiner Fähigkeit, ein Augendiagramm abzutasten (Eye Scanning).