Flusskontrolle: Methoden und Protokolle für den Einsatz mit MGTs

Diese Seite ist der achte und letzte Beitrag einer Artikelserie, die den Multi-Gigabit-Transceiver (MGT) vorstellt.

Einführung

Die Flusskontrolle (Flow Control) ist ein Mechanismus, der bei verschiedenen Arten von Datenverbindungen häufig eingesetzt wird. Ihr Zweck besteht darin, eine Situation zu verhindern, in der die Menge der gesendeten Daten größer ist, als die Empfängerseite verarbeiten kann.

Protokolle im Zusammenhang mit MGTs bieten unterschiedliche Grade der Unterstützung für diese Funktion. Beispielsweise akzeptiert Logik, die das PCIe-Protokoll implementiert, niemals ein Paket zur Übertragung, wenn die Puffer auf der Empfängerseite voll sind. Die Anwendungslogik, die das PCIe-Protokoll nutzt, braucht diesbezüglich nichts zu implementieren. Vielmehr erlaubt die Schnittstelle zwischen der Anwendungslogik und der PCIe-Protokoll-Logik dem Protokoll, vorübergehend die Annahme neuer Daten zu verweigern (beispielsweise mithilfe von AXI-S-Ports wie VALID und READY). Ebenso ist es der Anwendungslogik erlaubt, vorübergehend die Annahme von Daten zu verweigern, die von der anderen Seite ankommen. Dadurch schützt sich die Anwendungslogik vor einem Überlauf (Overflow).

Es ist wichtig, die Flusskontrolle nicht mit den Mechanismen zu verwechseln, die den Überlauf im eigenen elastischen Puffer des MGTs verhindern. Die Flusskontrolle hat nichts mit den Skip-Symbolen zu tun, die auf der Seite über die eigenen Puffer des MGTs erwähnt werden. Vielmehr schützt die Flusskontrolle die Puffer der Anwendungslogik. Und da es oft mehrere Datenkanäle gibt, die das MGT als gemeinsame Ressource nutzen, wird die Flusskontrolle für jeden dieser Kanäle getrennt und unabhängig durchgesetzt.

Allgemein gesprochen kümmern sich Protokolle, die die Kommunikation mit einem Computer definieren, selbst um den Flusskontrollmechanismus. Die Anwendungslogik muss lediglich über einfache Handshake-Ports mit der Protokoll-Logik kommunizieren, so wie bei vielen anderen Logikblöcken. Neben PCIe kümmern sich auch SuperSpeed-USB und SATA eigenständig um die Flusskontrolle.

Leider unterstützen Protokolle für die Kommunikation zwischen FPGAs die Flusskontrolle auf dieser Ebene üblicherweise nicht. Das einzige Protokoll, das die Flusskontrolle vollständig übernimmt, ist Xillyp2p. Andere Protokolle für FPGAs haben nur einige wenige Funktionen, die bei der Implementierung der Flusskontrolle in der Anwendungslogik helfen können.

Diese Seite stellt einige Techniken zur Implementierung der Flusskontrolle vor. Später wird kurz zusammengefasst, wie Aurora und Interlaken bei der Flusskontrolle helfen. Es ist dennoch wichtig, sich daran zu erinnern, dass – außer bei der Verwendung von Xillyp2p – die Anwendungslogik dafür verantwortlich ist, einen Überlauf zu verhindern.

Techniken der Flusskontrolle

Das oberste Ziel der Flusskontrolle ist es, die Situation zu verhindern, in der die Daten empfangende Seite mehr Daten erhält, als sie verarbeiten kann. Normalerweise speichert die Empfängerseite die ankommenden Daten in Puffern (oder einem FIFO), sodass es im Kern darum geht, sicherzustellen, dass in diesen Puffern für alle ankommenden Daten Platz bleibt.

Die Flusskontrolle ist bei MGTs schwieriger zu implementieren, vor allem weil der physikalische Kanal eine beträchtliche Verzögerung aufweist. Daher dauert es eine Weile, bis die Aufforderung, das Senden von Daten einzustellen, beim Sender ankommt. Zudem vergeht eine gewisse Zeit von dem Moment, in dem der Sender das Senden einstellt, bis keine Daten mehr am Empfänger ankommen.

Eine weitere Schwierigkeit bei MGTs besteht darin, dass Bitfehler auf dem physikalischen Kanal zum Verlust einer Aufforderung zum Stoppen der Datenübertragung führen können.

Zu diesen beiden Schwierigkeiten kommt hinzu, dass die Datenrate von MGTs hoch ist und man in der Regel erwartet, dass dieser physikalische Datenkanal effizient genutzt wird.

Im Vergleich zu einfacheren Kommunikationskanälen, etwa einer seriellen Schnittstelle (RS-232), muss die Flusskontrolle für ein MGT ausgefeilter sein, um zu gewährleisten, dass kein Überlauf auftritt. Die folgenden drei Techniken werden im Folgenden erläutert:

• XON / XOFF
• Zeitlich begrenztes XOFF („Pause“)
• Kredite (Credits)

Bei der Auswahl eines Protokolls für ein Projekt ist es wichtig, sich die folgenden beiden Fragen zu stellen:

• Was muss die Anwendungslogik im Zusammenhang mit der Flusskontrolle implementieren? Die Antwort lautet möglicherweise, dass nichts implementiert werden muss, wie etwa bei PCIe, SuperSpeed USB und Xillyp2p.
• Wenn die Anwendungsdaten zu verschiedenen Kanälen gehören: Erlaubt der Flusskontrollmechanismus, die Kommunikation auf jedem Kanal getrennt zu unterbrechen, oder betrifft er den gesamten Verkehr über den physikalischen Kanal?

In-Band- und Out-of-Band

Bevor wir diese drei Techniken einzeln besprechen, ist es wichtig, zwischen In-Band- und Out-of-Band-Flusskontrolle zu unterscheiden.

Bei jedem Flusskontrollmechanismus muss die Empfängerseite Anforderungen oder Informationen an die Senderseite senden, um den Datenfluss zu regeln. In vielen praktischen Anwendungsszenarien gibt es einen physikalischen Datenkanal in beide Richtungen. Mit anderen Worten: Auch die Empfängerseite verfügt für das Senden von Daten über einen entsprechenden physikalischen Kanal in der Gegenrichtung.

Wenn ein solcher physikalischer Kanal in der Gegenrichtung existiert, stellt sich die Frage, ob dieser Kanal zum Senden von Flusskontrollanforderungen verwendet wird. Wird der Kanal auf diese Weise genutzt, nennt man den Mechanismus In-Band-Flusskontrolle. Andernfalls wird Out-of-Band-Flusskontrolle angewendet.

Allgemein gesprochen ist die Out-of-Band-Flusskontrolle eine weniger elegante Lösung, insbesondere weil dafür separate physikalische Leitungen erforderlich sind. Wenn der Kanal des MGTs jedoch unidirektional ist, ist dies die einzige Möglichkeit.

Dieses Thema wird weiter unten im Zusammenhang mit der Flusskontrolle bei Interlaken erörtert.

Und nun zu den drei Flusskontrolltechniken.

XON / XOFF

XON / XOFF steht für „transmit on / off“ (Senden ein/aus). Dies ist der einfachste Flusskontrollmechanismus, hat jedoch einige erhebliche Nachteile.

Diese Methode kann auf viele Arten implementiert werden, aber die Idee ist immer dieselbe: Der Empfänger sendet eine Nachricht an den Sender, die bedeutet „Stoppe das Senden jetzt“, wenn der Empfänger keine Daten mehr annehmen kann. Das bedeutet XOFF. Später, wenn der Empfänger wieder Daten annehmen kann, wird ein XON gesendet, um die Wiederaufnahme des Datenflusses anzufordern. Da diese Anforderungen einfach sind, eignen sie sich sowohl für die In-Band- als auch für die Out-of-Band-Übertragung.

Alle oben genannten Schwierigkeiten im Zusammenhang mit der Flusskontrolle bei einem MGT lassen sich anhand der XON/XOFF-Methode zeigen. Die erste Schwierigkeit besteht darin, dass es einige Zeit dauert, bis die XOFF-Anforderung beim Sender ankommt: Der Sender sendet weiterhin Daten, bis diese Anforderung eintrifft. Außerdem treffen die Daten, die sich beim Eintreffen der Anforderung bereits auf dem physikalischen Kanal befinden, weiterhin am Empfänger ein.

Daher muss der Empfänger ein XOFF früh genug senden, damit die anschließend ankommenden Daten noch verarbeitet werden können. Doch wie früh ist früh genug? Das hängt von der Umlaufzeit (Round-Trip-Zeit) des physikalischen Kanals ab. In manchen Szenarien ist dieser Parameter bekannt, oder zumindest weiß man, dass die Umlaufzeit kurz ist.

Beispielsweise verwendet das SATA-Protokoll XON/XOFF. Das ist sinnvoll, da dieses Protokoll für die Kommunikation mit Festplatten gedacht ist, die sich physisch in der Nähe des SATA-Controllers befinden. Wenn die Entfernung zwischen den beiden Verbindungspartnern unbekannt und möglicherweise groß ist, kann es schwierig sein, einen optimalen Zeitpunkt für die Anforderung eines XOFF festzulegen.

Ein weiterer Faktor ist, ob der Sender sofort anhalten kann, wenn er ein XOFF empfängt. Wenn der übertragene Inhalt beispielsweise aus Paketen besteht, erlaubt das Protokoll möglicherweise nicht, die Übertragung mitten in einem Paket zu unterbrechen. Alle Szenarien müssen berücksichtigt werden, wenn die Bedingung für das Senden eines XOFF oder XON festgelegt wird.

Ein weiteres Problem ist, was geschieht, wenn die XOFF-Nachricht durch einen Bitfehler oder einen anderen Fehler des physikalischen Kanals verloren geht. In diesem Fall setzt der Sender den Datenfluss möglicherweise fort und verursacht einen Überlauf. Das Protokoll muss daher sicherstellen, dass die Übertragung angehalten wird, wenn die Möglichkeit besteht, dass eine XOFF-Anforderung verloren gegangen ist. Weiter unten wird beschrieben, wie Interlaken dieses Problem angeht.

Zusammenfassend lässt sich sagen: XON/XOFF beruht auf einem einfachen Konzept, aber mit dieser Methode sicherzustellen, dass nie ein Überlauf auftritt, ist leider schwierig und erfordert sorgfältige Beachtung unerwarteter Szenarien. Die Kreditmethode (Credits), die weiter unten besprochen wird, ist das genaue Gegenteil: Sie ist kompliziert zu verstehen, erreicht ihr Ziel aber leicht.

Zeitlich begrenztes XOFF („Pause“)

Die zeitlich begrenzte XOFF-Variante ist eine Abwandlung der XON/XOFF-Methode: An die Flusskontrollanforderung wird eine Zahl angehängt. Diese Zahl gibt an, wie lange der Sender die Datenübertragung ab dem Empfang dieser Anforderung pausieren soll. Genauer gesagt ist es die Anzahl der Taktzyklen, während derer der Sender keine Daten senden soll. Diese Methode ähnelt einem Ethernet-Pause-Frame.

Der Vorteil dieser Methode ist, dass danach kein XON erforderlich ist. Das kann in einigen spezifischen Situationen nützlich sein, aber selbst dann ist der Vorteil recht gering.

Der einzige Grund, warum das zeitlich begrenzte XOFF hier erwähnt wird, ist, dass diese Methode Bestandteil des Aurora-Protokolls ist.

Kredite (Credits)

Der Kredit (Credits) begrenzt, wie viele Datenelemente seit der Initialisierung des Kommunikationskanals übertragen werden dürfen. Diese Zahl wird vom Empfänger über eine Art Steuerkanal, den das Protokoll definiert, an den Sender übermittelt. Auf diese Weise steuert der Empfänger die Menge der an ihn gesendeten Daten.

Am besten lässt sich das anhand eines einfachen Beispiels erklären: Angenommen, der Puffer des Empfängers kann zunächst 1000 Datenelemente aufnehmen. Entsprechend sendet er dem Sender die Mitteilung, dass der Kredit 1000 Datenelemente beträgt. Der Sender darf sofort 1000 Datenelemente senden oder auch erst später. Solange der Kredit nicht aktualisiert wird, überschreitet die Gesamtzahl der vom Sender gesendeten Datenelemente jedoch nicht 1000.

Es vergeht einige Zeit, und 500 Datenelemente sind beim Empfänger eingetroffen. In der Zwischenzeit hat die Anwendungslogik 100 Datenelemente verbraucht. In dieser Situation befinden sich 400 Datenwörter im Puffer, sodass noch Platz für weitere 600 Datenelemente im Puffer ist.

An diesem Punkt sendet der Empfänger eine weitere Mitteilung und aktualisiert den Kredit auf 1100. Das trägt der Tatsache Rechnung, dass 500 Datenelemente bereits eingetroffen sind und 600 weitere erlaubt sind, selbst wenn die Anwendungslogik keine Daten aus dem Puffer verbraucht. Der Puffer ist also dann gefüllt, wenn der Sender seit Beginn insgesamt 1100 Datenelemente gesendet hat. Man kann es auch so betrachten: Der Empfänger erhöht den Kredit immer um die Anzahl der Datenelemente, die aus dem Puffer verbraucht werden.

Dieser Mechanismus stellt sicher, dass ein Überlauf verhindert wird, denn der Sender sendet niemals mehr Daten, als der Empfänger erlaubt. Es gibt jedoch zwei heikle Punkte bei dieser Methode.

Der erste Punkt ist, dass sich Empfänger und Sender auf einen Ausgangspunkt einigen müssen, an dem die Anzahl der gesendeten Datenelemente null ist. Dafür ist eine Art Initialisierungsprozedur erforderlich, bei der beide Seiten ihre Zähler zurücksetzen. Alle Protokolle, die Kredite verwenden, haben eine solche Startprozedur. Das verkompliziert das Protokoll, da beide Seiten gleichzeitig von einem Zustand in einen anderen wechseln müssen.

Der zweite Punkt ist, dass der Datenfluss unbegrenzt weiterlaufen können soll. Der Kredit wächst ständig. Wie lässt sich der Kredit als Zahl mit einer begrenzten Anzahl von Bits übertragen? Die Antwort ist, dass es genügt, den unteren Teil der binären Darstellung des Kredits zu senden (also nur die niederwertigsten Bits). Der Sender verwendet dieselbe Anzahl von Bits, um die Anzahl der von ihm gesendeten Datenelemente darzustellen.

Das genügt, weil der Sender den Kredit nur dazu verwendet, die Anzahl der für die Übertragung erlaubten Datenelemente zu berechnen. Diese Zahl ergibt sich aus dem Kredit abzüglich der bereits gesendeten Datenelemente. Das Ergebnis kann nicht größer sein als die Größe des Puffers beim Empfänger. Ist diese Zahl kleiner als 2ⁿ, sind alle Bits oberhalb der n niederwertigsten Bits null. Es ist daher sinnlos, sie zu berechnen. Es reicht, die Subtraktion nur mit n Bits durchzuführen. Deshalb werden in den Flusskontrollanforderungen nur die n niederwertigsten Bits der binären Darstellung des Kredits benötigt.

Beispielsweise beruht die Flusskontrolle von PCIe darauf, den Kredit als Binärwort mit 8 oder 12 Bit zu übertragen, je nachdem, welche Art von Puffer die Flusskontrolle schützt.

Die Verwendung von Krediten hat viele Vorteile:

• Wenn eine Flusskontrollanforderung verloren geht, besteht keine Überlaufgefahr: Der Kredit erteilt die Erlaubnis, mehr Daten zu senden, im Gegensatz zu XON/XOFF, das ein Anhalten der Übertragung verlangt. Wenn also ein Kreditupdate verloren geht, sendet der Sender weniger, als erlaubt ist. Dadurch kann kein Überlauf entstehen.
• Der Kreditmechanismus ist effizient, selbst wenn die Verzögerung des physikalischen Kanals unbekannt und möglicherweise groß ist. Es ist nicht nötig, den Datenfluss früher zu unterbrechen, um die Verzögerung der Flusskontrollanforderungen auszugleichen.
• Der Sender weiß im Voraus, ob er ein Paket ohne Unterbrechung durch die Flusskontrolle übertragen kann. Dadurch lässt sich sicherstellen, dass Pakete zusammenhängend gesendet werden.

Flusskontrolle mit Interlaken

Das Interlaken-Protokoll wird auf einer anderen Seite kurz vorgestellt.

Für die Diskussion der Flusskontrolle ist wichtig: Dieses Protokoll ordnet jedem Datenburst eine Kanalnummer (üblicherweise zwischen 0 und 255) zu. Mit anderen Worten basiert das Protokoll auf dem Konzept mehrerer Anwendungsdatenströme, die sich den physikalischen Kanal teilen. Dementsprechend steuern die Flusskontrollmechanismen jeden Anwendungsdatenstrom unabhängig.

Dieses Protokoll bietet zwei Arten von Flusskontrollmechanismen: In-Band-Flusskontrolle und Out-of-Band-Flusskontrolle (OOBFC). Beide sind XON/XOFF-Mechanismen. Der Status wird über ein einzelnes Bit pro Kanal übermittelt. Dieses Bit ist „1“, wenn der Kanal bereit ist, Daten zu empfangen (XON), andernfalls „0“ (XOFF).

Der Unterschied zwischen diesen beiden Mechanismen liegt in der Übertragung dieser Bits: Der In-Band-Flusskontrollmechanismus stützt sich darauf, dass vor und nach jedem Burst ein Steuerwort übertragen wird. Dieses Steuerwort besteht aus 64 Bits, von denen 16 Bits für die Flusskontrolle vorgesehen sind. Damit sind bis zu 16 XON/XOFF-Anforderungen pro Steuerwort möglich. Das reicht jedoch nicht, um bis zu 256 Kanäle zu unterstützen: Jeder Kanal hat sein eigenes XON/XOFF-Bit. Um das zu lösen, werden die Flusskontrollinformationen auf mehrere Steuerwörter aufgeteilt. Diese Methode wird als Kalender bezeichnet. Bit 56 im Steuerwort heißt „Reset Calendar“. Wenn dieses Bit „1“ ist, enthält das Steuerwort die XON/XOFF-Anforderungen für die Kanäle 0 bis 15. Im folgenden Steuerwort sind die Anforderungen für die Kanäle 16 bis 31 enthalten, usw. Wenn alle Kanäle berücksichtigt wurden (möglicherweise schon mit nur einem Steuerwort), wird die Sequenz mithilfe von „Reset Calendar“ neu gestartet.

Wenn über die CRC24 des Bursts ein Bitfehler erkannt wird, gehen alle Kanäle in den XOFF-Zustand über. Der Grund ist, dass die CRC24 auch das Steuerwort abdeckt; der Flusskontrollteil wird daher ignoriert, wenn ein Fehler erkannt wird. Nach einem solchen Ereignis ist es also nicht sicher, auf irgendeinem Kanal zu senden. Der normale Betrieb wird allmählich anhand der Flusskontrollanforderungen in den folgenden Steuerwörtern wieder aufgenommen.

Der Hauptnachteil der In-Band-Flusskontrolle ist, dass die Zustellung von XON/XOFF-Anforderungen von den Datenbursts abhängt, die in dieselbe Richtung gesendet werden. Wenn diese Bursts lang sind oder eine Zeit lang gar keine Bursts gesendet werden, kann die Zustellung von XON/XOFF länger dauern. Das ist teilweise gerechtfertigt, denn es ist unvermeidlich, dass Datentransport und Flusskontrollnachrichten auf demselben physikalischen Kanal um Bandbreite konkurrieren. Andere Protokolle geben Flusskontrollnachrichten jedoch meist eine Priorität, die eine gleichbleibende maximale Verzögerung gewährleistet.

Die Alternative der Out-of-Band-Flusskontrolle (OOBFC) vermeidet die Konkurrenz mit Datenbursts. Bei dieser Methode werden die XON/XOFF-Anforderungen über drei zusätzliche physikalische Leitungen übertragen (FC_CLK, FC_DATA und FC_SYNC). Die XON/XOFF-Bits für alle Kanäle werden in einem langen Frame gesendet.

Das FC_SYNC-Signal ist zusammen mit dem ersten Bit dieses Frames auf high. Die Frequenz von FC_CLK liegt zwischen 0 und 100 MHz, und DDR-Taktung ist erlaubt. Nach jeweils 64 XON/XOFF-Anforderungen oder nach der letzten wird eine 4-Bit-CRC (CRC-4) eingefügt. Wird über eine CRC ein Fehler erkannt, gehen alle Kanäle in den XOFF-Zustand über.

Die Wahl zwischen In-Band- und Out-of-Band-Flusskontrolle hängt natürlich von den Anforderungen des Projekts ab.

Interlaken enthält keinen Mechanismus, um Daten aus verschiedenen Kanälen zu multiplexen. Es ist daher Aufgabe der Anwendungslogik, zwischen den Sendeanforderungen der Kanäle zu entscheiden und auszuwählen, welcher Kanal einen Burst (oder ein ganzes Paket) senden darf. Die Anwendungslogik ist deshalb auch dafür verantwortlich, die Übertragung auf einem Kanal anzuhalten, wenn dies durch ein XOFF verlangt wird. Die Logik, die das Interlaken-Protokoll implementiert, ist nur für das Senden und Empfangen von XON/XOFF-Anforderungen zuständig.

Das Protokoll erwähnt Kredite als Möglichkeit zur Implementierung der Flusskontrolle, allerdings nur als freie Einladung, diese Methode über eigene Kanäle umzusetzen. Einzelheiten zur Implementierung enthält das Protokoll nicht.

Flusskontrolle mit Aurora

Das Aurora-Protokoll wird auf einer anderen Seite kurz vorgestellt. Dieses Protokoll schlägt zwei Mechanismen zur Unterstützung der Flusskontrolle vor: NFC und UFC. Diese beiden werden als Nächstes getrennt beschrieben.

Zunächst zur Native Flow Control (NFC): Bei diesem Mechanismus besitzt die Anwendungslogik auf der Empfängerseite eine Schnittstelle zum Senden von Flusskontrollanforderungen an den Sender. Diese Anforderungen bestehen aus zwei getrennten Teilen: einem XOFF-Bit und einem zeitlich begrenzten XOFF-Teil („Pause“) (beide Konzepte wurden oben erklärt). Die Protokolllogik auf der Senderseite ist dafür verantwortlich, diese Anforderungen zu befolgen: Ist das XOFF-Bit „0“, pausiert der Sender die Datenübertragung für die Anzahl der Taktzyklen, die der in der Flusskontrollanforderung enthaltenen 8-Bit-Zahl entspricht. Ist diese Zahl null, wird die Datenübertragung sofort wieder aufgenommen. Die Zahlen in den Anforderungen addieren sich nicht. Vielmehr setzt jede NFC-Anforderung den Countdown der Pause auf einen neuen Wert.

Ist das XOFF-Bit „1“, pausiert der Sender die Datenübertragung auf unbestimmte Zeit. Der Sender nimmt die Datenübertragung nur dann wieder auf, wenn eine Flusskontrollanforderung mit XOFF = „0“ eintrifft. Eine solche Anforderung wird wie oben erwähnt verarbeitet.

Beachten Sie, dass dieser Flusskontrollmechanismus den gesamten Datenverkehr über den physikalischen Datenkanal steuert. NFC ist daher nicht für die individuelle Steuerung mehrerer Kanäle geeignet, falls solche implementiert sind.

Der zweite Mechanismus ist die User Flow Control (UFC): Dabei handelt es sich praktisch um einen separaten Kanal zum Senden von Nachrichten von bis zu 256 Byte an die Gegenseite. UFC-Nachrichten haben eine höhere Priorität als die Datenübertragung, sodass sie mit geringer Latenz auf der anderen Seite ankommen.

Da das Protokoll das Format dieser Nachrichten nicht festlegt, können sie zur Implementierung einer beliebigen Flusskontrolle verwendet werden. Eine solche Implementierung erfolgt vollständig in der Anwendungslogik. UFC-Nachrichten können auch zum Übertragen anderer Arten von Statusinformationen verwendet werden.

Beachten Sie, dass keine der in diesen beiden Flusskontrollmechanismen verwendeten Nachrichten gegen Bitfehler auf der physikalischen Verbindung geschützt ist. Eine Flusskontrollanforderung kann daher falsch ankommen oder gar nicht ankommen, was möglicherweise zu einem Überlauf am Empfänger führt.

Da beide Flusskontrollmechanismen auf der Datenverbindung in der Gegenrichtung beruhen, sind sie nur im Vollduplex-Modus verfügbar.

Zusammenfassung

Auf dieser Seite wurden hauptsächlich zwei Techniken zur Flusskontrolle vorgestellt: XON/XOFF und Kredite. Bei computerbezogenen Protokollen (z. B. PCIe, SuperSpeed USB und SATA) wird die Flusskontrolle von der Protokolllogik implementiert. Bei Protokollen für die Kommunikation zwischen FPGAs ist dagegen die Anwendungslogik für die gesamte oder den größeren Teil der Implementierung verantwortlich. Die einzige Ausnahme ist Xillyp2p, das alle Aspekte der Datenkommunikation übernimmt, einschließlich Flusskontrolle, Fehlererkennung und Neuübertragung.

Die flusskontrollbezogenen Merkmale zweier Protokolle für FPGAs wurden vorgestellt: Interlaken und Aurora. Wie gezeigt, überlassen diese Protokolle der Anwendungslogik den größeren Teil der Implementierung der Flusskontrolle, obwohl die eigenen Fähigkeiten der Protokolle in bestimmten Anwendungsszenarien einen Teil der Arbeit übernehmen können.

Damit ist die letzte Seite in dieser Serie über MGTs abgeschlossen.