-
TECHNISCHES GEBIET
-
Diese Anmeldung betrifft die Codierung in seriellen Links und insbesondere eine Verbesserung gegenüber dem 8b/10b-Codierungsschema.
-
HINTERGRUND
-
Einige serielle Verbindungen, wie Peripheral Component Interconnect (PCI) Express (PCIe), setzen die 8b/10b-Codierung ein, bei der ein Leitungscode mit zehn Bit zur Darstellung von sinnvollen 8-Bit-Daten verwendet wird. Die 8b/10b-Codierung wurde konzipiert, um eine ausreichende Übergangsdichte von 1-zu-0 und 0-zu-1 zu gewährleisten, damit der Empfänger das ankommende Paket takten kann. Infolge der Codierung gehen 20 % Bandbreite verloren und die Übertragungsleistung wird um 25 % reduziert.
-
Neben der Codierung von 28 möglichen Datenmustern für positive und negative Disparitäten, decken die 10-Bit-Codierungen auch einige Steuerzeichen (auch als K-Codes bezeichnet) ab, die für verschiedene Zwecke benötigt werden, z. B. zum Bestimmen der Rahmengrenzen. Diese können allgemein als paketabgrenzende K-Codes und Lane-Strom-K-Codes klassifiziert werden. Die paketabgrenzenden K-Codes kennzeichnen den Anfang oder das Ende eines Pakets (z. B. STP, SDP, END, EDB). Die Lane-Strom-K-Codes dagegen werden unabhängig auf Pro-Lane-Basis verwendet und werden verwendet in Ordered-Sets (geordneten Sets) während des Link-Trainings (Training-Sets TS1/TS2) in elektrisch inaktiven Eingangs-/Ausgangssequenzen (EIOS bzw. EIES) oder in Ordered-Sets der periodisch übersprungenen Zeichen (SKP), die für die Tolerierung der Differenzen bei den Teilen pro Million (ppm) im eindeutigen Taktmodus verwendet werden. Einer der Lane-Strom-K-Codes (COM) wird für die eindeutige Identifizierung der Byte-Ausrichtung und für die Wiederherstellung nach Fehlern, wie Verlust (Bit-Slip) oder Hinzufügung (Add) eines Bit, verwendet. Neben der Garantie für eine schließliche Wiederherstellung nach mehreren Bitfehlern, einschließlich Verlust der Byte-Ausrichtung aufgrund von Fehlern wie Bit-Slip/Adds, ermöglicht 8b/10b eine garantierte Erkennung gegen jeden einzelnen Bit-Flip-Fehler (in Verbindung mit der CRC).
-
Serielle linkbasierte Implementierungen kommen allerorts immer häufiger zum Einsatz, weshalb effiziente Codierungen entsprechend wichtiger werden, um eine maximale Nutzung der rohen Bandbreite zu ermöglichen.
-
Die Substitution der 8b/10b-Codierung ist jedoch mit Risiken verbunden. Die Herausforderungen in Bezug auf die Zuverlässigkeit eines neuen Schemas müssten gelöst werden. Ein neues Schema muss fähig sein, das existierende Fehlermodell zu garantieren, welches die Erkennung einer vorbestimmten Anzahl von Bit-Flip-Fehler und die schließliche Wiederherstellung nach anderen Fehlertypen (einschließlich mehrfache Bitfehler, Bit-Slips etc.) garantiert.
-
Außerdem können mit zunehmender Frequenz (z. B. PCIe 3.0 bei 8 GT/s) andere Fehlertypen auftreten, die von einem neuen Codierungsschema angesprochen werden müssen. So sollten beispielsweise Empfängerdesigns in Betracht gezogen werden, die Entzerrung mit Entscheidungsrückführung (Decision Feedback Equalizers, DFE) verwenden. Die DFE können je nach Bitmuster erkennen, wenn ein einzelner Bit-Flip-Fehler nachfolgende Bits verfälscht. Diese Art von Fehlern werden eventuell sogar von den bestehenden 8b/10b-Schemen nicht erkannt. Deshalb wäre es sehr wünschenswert, wenn neben der Erhaltung des bestehenden Fehlermodells mehrerer Bitfehler innerhalb eines Gleitfenster von Bits in einer beliebigen Lane toleriert werden könnten.
-
Bei seriellen Links, die Merkmale von seriellen und parallelen Links enthalten (z. B. PCIe, wo Datenbyte in Streifen über mehrere Lanes eines Multi-Lane-Links verteilt sind), funktionieren bestehende Lösungen wie 64/66 nicht. Das erfindungsgemäße Schema spricht einige dieser Probleme an.
-
US 6,628,725 B1 offenbart ein System, das folgendes umfasst: einen Empfänger, der einen Decoder, einen seriellen Link, der einen Sender mit dem Empfänger verbindet, wobei ein Code über den seriellen Link vom Empfänger empfangen wird und der Code folgendes umfasst: ein Zwei-Bit-Präfix, der einen von zwei gültigen Zuständen umfasst, und eine Sequenz einer vorbestimmten Bitlänge, wobei der Code dem Empfänger ein Identifizieren der eingehenden Daten ermöglicht.
-
Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein gegenüber dem 8b/10b verbessertes Kodierungsschema bereitzustellen.
-
Erfindungsgemäß wird diese Aufgabe gelöst durch ein System nach Anspruch 1, ein Kodierungsschema nach Anspruch 7 und ein System nach Anspruch 13. Die Unteransprüche betreffen jeweilige vorteilhafte Weiterbildungen derselben.
-
Figurenliste
-
Die oben angesprochenen Aspekte und die damit verbundenen Vorteile in dieser Schrift, werden in der nachfolgenden ausführlichen Beschreibung verdeutlicht und in den dazugehörigen Zeichnungen für ein besseres Verständnis dargestellt, wobei gleiche Bezugszeichen zu den gleichen Teilen in den verschiedenen Ansichten gehören, wenn es nicht anderweitig angegeben ist.
- 1 zeigt ein Blockdiagramm eines Systems, das ein Codierungsschema gemäß einiger Ausführungsformen verwendet;
- 2 zeigt ein Blockdiagramm eines (130, 128)-Codes inklusive Präfix und eine 128-Bit-Sequenz, die vom Codierungsschema in 1 verwendet wird, gemäß einiger Ausführungsformen;
- 3 ist ein Blockdiagramm von vier Arten von Nutzdaten, deren Längen von dem Codierungsschema aus 1 verarbeitet werden, gemäß einiger Ausführungsformen;
- 4 ist ein Blockdiagramm eines Transaktionsschichtpaket-Layouts, das vom Codierungsschema aus 1 verwendet wird, gemäß einiger Ausführungsformen;
- 5 ist ein Ablaufdiagramm, das Funktionsabläufe des Codierungsschemas aus 1 zum Erhalt einer Blocksperre zeigt, gemäß einiger Ausführungsformen;
- 6 ist ein Ablaufdiagramm, das Funktionsabläufe des Codierungsschemas aus 1 zur Verarbeitung der Pakete zeigt, wie in bestimmten Ausführungsbeispielen gezeigt;
- 7 ist ein Blockdiagramm eines Datenlinkschichtpaket-Layouts, das vom Codierungsschema aus 1 verwendet wird, gemäß einiger Ausführungsformen; und
- 8 ist ein Ablaufdiagramm, das verbesserten Funktionsabläufe durch das Codierungsschema aus 1 vor der Paketverarbeitung zeigt, gemäß einiger Ausführungsformen.
-
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
-
Gemäß den in dieser Schrift beschriebenen Ausführungsformen wird ein neues Codierungsschema offenbart, in dem die physische Schicht fähig ist, durch Ansehen weniger ausgewählter Bits die Paketgrenzen zu identifizieren, während zugleich die Fähigkeit zur Fehlererkennung verbessert und ein geringer Overhead für Energiesparzustände aufrechterhalten wird. Durch die Eliminierung des Overhead der 8b/10b-Codierung für die physikalische Schicht erzielt das Codierungsschema eine bessere Fehlererkennungsfähigkeit als die derzeitige 8b/10b-Codierung. Des Weiteren bietet das neue Codierungsschema eine zusätzliche Fehlererkennungsfähigkeit, einen niedrigen Overhead-Mechanismus zum Beenden von Energiesparzuständen und einen Mechanismus zum Handhaben von problematischen Paketen.
-
In der folgenden ausführlichen Beschreibung wird auf die beigefügten Zeichnungen Bezug genommen, in denen einige bestimmte Ausführungsformen, indem die Erfindung ausgeführt werden kann, dargestellt werden. Für die fachkundige Person geht aus dieser Schrift jedoch deutlich hervor, dass auch weitere andere Ausführungsformen möglich sind. Die in dieser Schrift beschriebenen Ausführungsformen beziehen sich beispielsweise auf den PCI-Express. Die der Offenbarung zugrunde liegenden Techniken können jedoch auf jeden seriellen Link angewandt werden. Die folgende ausführliche Beschreibung ist deshalb in keiner Weise einschränkend, da der Umfang der vorliegenden Erfindung durch die Ansprüche definiert ist.
-
1 zeigt ein schematisches Blockdiagramm eines Systems 200, das ein erfindungsgemäßes Codierungsschema 100 verwendet. Das System 200 umfasst einen Sender 40 und einen Empfänger 50, die über einen seriellen Link 80 kommunizieren. Der serielle Link 80 kann eine drahtgebundene oder drahtlose Verbindung zwischen dem Sender 40 und dem Empfänger 50 sein und kann eine oder mehrere Lanes umfassen. Der Encoder 100 verwendet einen (130, 128)-Code 90, welcher unten genauer beschreiben ist. Der Sender 40 umfasst einen Encoder 20, welcher das offenbarte Codierungsschema 100 ausführt, und einen Scrambler 30. Der Empfänger 50 umfasst einen Decoder 60, welcher ebenfalls das Codierungsschema 100 ausführt, und einen Descrambler 70. Das Codierungsschema 100 ersetzt das aus dem Stand der Technik bekannte 8b/10b-Codierungsschema.
-
Das offenbarte Codierungsschema 100 verwendet verschiedene Techniken für die Verbesserung der Fehlererkennungsfähigkeit und zur Umgehung von Killer-Packets, und es nutzt eine Kombination von verschlüsselten und unverschlüsselten Symbolen für verschiedene Teile eines Link-Trainings, um eine höhere Zuverlässigkeit zu erzielen. Durch den Ersatz der 8b/10b-Codierung mit dem Codierungsschema 100 wird die nutzbare Bandbreite des seriellen Links 80 in einigen Ausführungsformen erweitert. Dadurch wird nicht nur die Leistung gegenüber dem derzeitigen 8b/10b-Codierungsschema gesteigert, sondern das Codierungsschema 100 führt auch zu einer Reduzierung des Stromverbrauchs, da der Strom direkt mit der Roh-Bitrate auf dem Link verbunden ist. Neben der Erhaltung des bestehenden Fehlermodells toleriert das vorgeschlagene Codierungsschema 100 auch mehrere Bitfehler innerhalb eines Gleitfensters von Bits in einer beliebigen Lane.
-
In einigen Ausführungsformen verwendet das Codierungsschema 100 einen (130, 128)-Codetyp 90, um jede Lane des seriellen Links 80 für die meisten Fälle abzudecken. Es kann Ausnahmen geben in Fällen, in denen ein anderes Codierungsschema verwendet wird, um eine bessere Effizienz zu erzielen. Beim Beenden eines Energiesparzustands kann das Codierungsschema 100 beispielsweise einfach Roh-Bits senden, um den Empfänger zu wecken, eine Bitsperre bewirken und dann zum Ausgleich zwischen den Leitungen ein Lane-zu-Lane-Deskewing durchführen, bevor der normale Verkehr im (130, 128)-Format gesendet wird. Jede dieser Funktionen (Wecken des Empfängers, Bitsperre, Lane-zu-Lane-Deskewing) kann durch die Sendung eindeutiger Muster ohne Encoding-Overhead erzielt werden.
-
Der (130,128)-Code 90 ist eine Variante eines früheren 64/66-Codes, wird aber auf andere Weise verwendet. Im Encoder 20 (Sender 40) wird der (130, 128)-Code 90 über den Link 80 gesendet, damit der Empfänger 50 den Anfang der eingehenden Daten identifizieren kann. Der Decoder 60 (Empfänger 50) sucht dann nach dem (130, 128)-Code 90 im Link 80. Der (130, 128)-Code 90 wird auch als eine Trainingsequenz verwendet, um zu ermöglichen, dass sich der Sender 40 und der Empfänger 50 selbst synchronisieren.
-
Es gibt vier Hauptarten von Nutzdaten: Transaktionsschichtpakete (TLP), Datenlinkschichtpakete (DLLP), inaktiv (keine Pakete) (IDLE) und geordnete Sets (Ordered-Sets). TLP enthält Nutzdaten mit variabler Länge. DLLP enthält Nutzdaten mit einer festen Länge von acht Bytes. IDLE enthält Nutzdaten mit einer festen Länge von einem Byte. Ordered-Sets enthält Nutzdaten mit variabler Länge, die pro Lane auf dem Link 80 festgelegt wird. Wie unten gezeigt, kann der (130, 128)-Code 90 neben der wahlweisen Funktion einer Trainingsequenz auch ein logisches IDL, ein Transaktionsschichtpaket (TLP) oder ein Datenlinkschichtpaket (DLLP) sein.
-
Der (130, 128)-Code 90 ist in 2 dargestellt, wie in bestimmten Ausführungsbeispielen gezeigt. Die ersten zwei Bit 22 oder der Sync-Header 22 des (130, 128)-Codes 90 sind entweder 01 binär, 01b oder 10b (in 2 als „10b“ gezeigt). Die Bitsequenz „10b“ wird als Präfix für bestimmte spezielle Pakete oder Ordered-Sets verwendet, in denen die Nutzdaten nicht verschlüsselt sind. Ein Beispiel ist die elektrisch inaktive Ausgangssequenz (EIES) in PCIe, die unter Verwendung eines niederfrequenten Inhalts arbeitet. In einigen Ausführungsbeispielen können die 128-Bit-Nutzdaten für EIES eine Sequenz von acht Nullen sein. Nach den ersten zwei Bit 22 (01b oder 10b) wird, wie gezeigt, eine Sequenz 24 von acht Nullen gefolgt von acht Einsern achtmal wiederholt.
-
Somit umfasst die vorgeschlagene Codierung für den (130, 128)-Code 90 das Zwei-Bit-Präfix 22 und die 128-Bit-Sequenz 24, wie in 2 dargestellt, gemäß einiger Ausführungsformen für insgesamt 130 Bit. Die ersten zwei Bit vom Präfix 22 (entweder 01b oder 10b) sind nicht verschlüsselt und die 128 Bit der Sequenz 24 sind nicht verschlüsselt, um das niederfrequente Muster zu erhalten.
-
In einigen Ausführungsbeispielen dient die Sequenz 24 auch einem anderen Zweck, da sie nicht verschlüsselt ist. Die Sequenz 24 wird periodisch in einen Wiederherstellungszustand versendet und auf diese Weise verwendet, um jegliche Bit-Slip- oder Add-Fehler zu erkennen, die einen Verlust der Byte-Ausrichtung zur Folge haben. Dabei ist zu erwarten, dass bei einem Verlust des Empfängers 50 (z. B. aufgrund des Verlusts der Byte-Ausrichtung) der Link 80 schließlich in einen Wiederherstellungszustand wechselt. Es kann entweder das Versagen einer zyklischen Redundanzprüfung (CRC) (oder eines anderen Fehlerschutzschemas) vorliegen oder ein andere Rahmenfehler eintreten (z. B. Empfang eines ungültigen Paketanfangs) oder die Gegenseite erhält nicht die erwartete Bestätigung, um den Link 80 zu veranlassen, in einen Wiederherstellungszustand zu wechseln und eine Neusynchronisation durchzuführen. Im Wiederherstellungszustand erwartet der Link den Empfang bestimmter Arten von Trainingsequenzen. Jede Lane des im Wiederherstellungszustand befindlichen Links 80 sucht nach einem eindeutigen 130-BitMuster in der EIES. Aufgrund der Eindeutigkeit des EIES-Musters und mit der begrenzten Anzahl möglicher Trainingsequenzen kann im Wiederherstellungszustand sichergestellt werden, dass keine Bit-Slip-Aufkommen (ohne Bit-Flips) dazu führen, dass Nicht-EIES-Muster (z. B. Sequenz 24) einem EIES-Muster ähnlich sind.
-
Die EIES kann auch verwendet werden, um ein lineares Feedback-Schieberregister (LFSR) des Scramblers 30 oder des Descramblers 70 rückzusetzen. Obwohl das Codierungsschema 100 das gleiche EIES-Muster für mehrere Zwecke wiederverwendet, ist der fachkundigen Person bewusst, dass die gleiche Wirkung mit verschiedenen unverschlüsselten Mustern für jeden Zweck des niederfrequenten Musters, den Erhalt einer Blocksperre und die Rücksetzung des (De)Scramblers erzielt werden kann.
-
Wenn der (130, 128)-Code 90 mit einem Präfix von 01b versehen ist, werden andere Nutzdaten gesendet, wie in bestimmten Ausführungsbeispielen gezeigt. Beispiele sind u. a. logische IDL-Tansaktionen und bestimmte andere Ordered-Sets als die mit dem 10b-Präfix gesandten. Die 128-Bit-Nutzdaten mit diesem Präfix können verschlüsselt sein. Innerhalb der 128-Bit-Nutzdaten, die verschlüsselt sind, kommunizieren der Empfänger 50 und Sender 40 auf eindeutige Weise die Paketgrenze sowie die Lane-Strom-Grenzegemäß einiger Ausführungsbeispiele.
-
Der Encoder 100 verwendet ein Paketisierungsschema, um die Paketgrenze abzugrenzen, gemäß einiger Ausführungsbeispiele. Die Pakete lassen sich definieren als logische IDL, Transaktionen oder Ordered-Sets, die mit dem Präfix „01b“ im (130, 128)-Code 90 gesendet werden. Das erste (8-Bit)-Symbol der Nutzdaten zeigt den Typ der nachfolgenden Nutzdaten und hilft bei der Erkennung des Anfangs des nächsten Pakets. 3 zeigt eine mögliche Codierung für das 8-Bit-Nutzdaten-Symbol 32 sowie die erwartete Länge 34 der Nutzdaten, falls bekannt. Es können auch andere Symbolsequenzen verwendet werden, so lange für jeden Nutzdatentyp ein eindeutiges Symbol definiert wird. Durch Betrachen des ersten Symbols der Nutzdaten bestimmt der Empfänger 50, welcher Nutzdatentyp übertragen wird.
-
Wenn der Empfänger 50 ein „Send DLLP Payload“ (SDP) oder ein „IDLE Payload“ im Nutzdatentyp-Symbol 32 erfasst, ist die Nutzdatenlänge 34 vorab bekannt (acht Bytes bzw. ein Byte). Wird jedoch im Nutzdatentyp-Symbol 32 ein „Send TLP Payload“ (STP) übertragen, bestimmt der Empfänger 50, wo das Paket endet, damit das erste Symbol des nächsten Pakets erfasst werden kann. Die Nutzdaten der „Ordered Sets Payload“ werden in dieser Schrift nicht besprochen. Wenn der Empfänger irgendetwas anderes als diese vier Nutzdatentypen 32 im ersten Symbol empfängt, meldet der Empfänger 50 einen Fehler und bewirkt gemäß einiger Ausführungsformen, dass der Link 80 in den Wiederherstellungszustand versetzt wird. Dieses Codierungsschema 100 sorgt für eine garantierte Erkennung von dreifachen Bit-Flip-Fehlern.
-
Wenn der Empfänger 50 in einigen Ausführungsformen ein „Send Transaction Layer Packet“ (STP) erkennt, sucht der Empfänger in den nachfolgenden Bit der nächsten Byte, um die Länge des TLP zu bestimmen. Da Nutzdaten in einem TLP verschiedene Längen haben, hilft diese Berechnung bei der Bestimmung der Anfangsbyte-Position (Byte 0) für das nächste Paket. 4 zeigt ein Blockdiagramm eines Transaktionsschichtpaket-Layouts 36 gemäß einiger Ausführungsformen. Im PCIe ist die Länge der Nutzdaten eine Funktion von mehreren Feldern: dem Länge-Feld 46 (length[9:0]), dem Format-Feld 44 (fmt[1,0]) und dem TLP-Digest-Feld (TD) 48.
-
In bestimmten Ausführungsbeispielen ist die Gleichung für die Ermittlung der Länge der TLP-Nutzdaten in Doppelwörtern wie folgt:
- tlp_length[10:0] = (falls Fmt[1], dann Length[9:0]; sonst 0) + 5 (für drei Doppelwort-Header, Link-Ebenen-CRC, STP, und END/EDB) + (falls Fmt[0] ist 1, dann 1; sonst 0) (bezeichnet einen Header mit vier Doppelwörtern falls 1) +
- (falls TD ist 1, dann 1; sonst 0) (bezeichnet End-to-End-CRC)
-
Die für die Bestimmung der Nutzdatenlänge verwendeten TLP-Felder sind in einigen Ausführungsformen abhängig von der gewünschten Fehlerdeckung durch ein CRC-Feld geschützt. Auch wenn die Pakete selbst durch eine CRC geschützt sind, können Bitfehler in den die Länge bildenden Feldern dazu führen, dass die Paketgrenze im falschen Byte beendet wird, so dass bei der Rahmenabrenzung die falschen Bit als CRC angesehen werden könnten. Dies kann ein Aliasing verursachen, auch wenn weniger Fehler, als von der CRC tolerierbar, erfasst werden.
-
Zur Vermeidung dieses Problems verwendet der Encoder 100 gemäß einiger Ausführungsformen eine separate CRC zum Schutz der Felder, die zur Länge beitragen. Diese separate CRC befindet sich in einer festen Bit-Position des TLP und ermöglicht dem Empfänger 50 bei jedem Mal die Einholung der CRC. In diesem Beispiel befinden sich somit alle zur Länge beitragenden Felder sowie die CRC, die diese schützen, an festen Positionen.
-
In einigen Ausführungsformen , wie in 4 dargestellt, definiert der Encoder 100 die letzten vier Bit von Byte Drei, die vorher für die Speicherung von vier Bits 42 der CRC-Informationen reserviert wurden. Diese Bit (CRC[3:0]) 42 werden verwendet, um die CRC des 13-Bit-Feldes, das die Längeninformation des Transaktionsschichtpakets enthält, zu speichern. Die CRC-Bit 42 nehmen ein CRC des Zwei-Bit-Formats 44, die 10-Bit-Länge 46 und den Ein-Bit-TLP-Digest (TD) 48, wie oben gezeigt, als notwendige Informationen für die Berechnung der Länge des TLP 36. Die CRC[3:0] 42 speichert ein einfaches Polynom vom Grad Vier, um sicherzustellen, dass jede Anzahl von Fehlern innerhalb eines 4-Bit-Fensters erkannt wird. In anderen Ausführungsbeispielen werden mehrere Bits für die CRC verwendet, um eine noch bessere Erkennung zu erzielen.
-
PCI Express definiert ein Byte für END (oder EDB für ein fehlerhaftes Paket), um das Ende eines Pakets zu signalisieren. Dadurch wird dafür gesorgt, dass die physikalische Schicht eine deutliche Abgrenzung für die Signalisierung des Paketendes aufweist, und somit kein Suchen im Inhalt des Pakets notwendig ist. Das Codierungsschema 100 definiert auch ein Byte für END/EDB, um das Ende des TLP 36 zu signalisieren. Wie in 4 gezeigt umfasst das erfindungsgemäße Transaktionsschichtpaket-Layout 36 acht Bit am Ende für das END/EDB-Paritätsbyte 52.
-
Zum Erhalt einer besseren Fehlerdeckung verwendet das Codierungsschema 100 die Endbyte-Position, um eine byteweise Exclusive-OR (XOR) aller Byte im Transaktionsschichtpaket zu senden (Byte Eins bis n - 2, wobei n die Länge des Pakets in Byte ist), wenn das letzte Byte ein fehlerfreies Ende (END) ist. Bei der Sendung/beim Empfang der Bytes werden diese in einem Arbeitsspeicher des jeweiligen Senders 40/Empfängers 50 gespeichert, gemäß einiger Ausführungsformen.
-
Ist das letzte Byte jedoch aufgrund eines fehlerhaften Pakets ein fehlerhaftes Ende (EDB) ist, wird im Transaktionsschichtpaket 36 eine byteweise Exclusive-NOR (XNOR) der Bytes Eins bis n - 2 berechnet. Der Empfänger 50 führt eine byteweise XOR der Bytes Eins bis n - 1 im Transaktionsschichtpaket 36 durch (unter Einschluss der Endbyte-Position). Ein Ergebnis von ausschließlich Nullen zeigt ein erfolgreiches Ende aus Sicht einer physikalischen Schicht (die LCRC-Prüfung erfolgt in der Link-Schicht und andere Prüfungen auf Transaktionsebene werden in der Transaktionsschicht durchgeführt). Ein Ergebnis mit ausschließlich Einser zeigt ein erfolgreiches EDB an. Alle anderen Werte weisen auf Bitfehler hin, so dass ein Rahmenfehler signalisiert wird und der Link in einen Wiederherstellungsmodus wechselt. Aufgrund der byteweisen XOR liefert der Encoder 100 eine Fehlererkennung einer beliebigen Anzahl von Bits innerhalb eines 7-Bit-Fensters. Da ein Ergebnis von ausschließlich Einsern eine gültige Codierung darstellt, holt der Encoder 100 nicht die Deckung für mehrere Bit-Fehler innerhalb eines 8-Bit-Fensters ein. Der fachkundigen Person ist bewusst, dass das erfindungsgemäße END/EDB auf jede beliebige Bitzahl erweitert werden kann und jedes Schema, wie z. B. CRC, verwenden kann, anstatt nur eine byteweise Parität.
-
5 ist ein Ablaufdiagramm und zeigt den Ablauf für den Erhalt einer Blocksperre, gemäß einiger Ausführungsformen. Der Encoder 100 beginnt mit einer Abfrage zur Bestimmung, ob eines der folgenden Ereignisse eingetreten ist: Verlust des Rahmens im Link, Fehler gefunden, Wiederherstellungssequenz empfangen und im Wiederherstellungs- oder Trainingmodus (Block 102). Liegt keines dieser Ereignisse vor, wird nichts unternommen, bis eines der Ereignisse eintritt, worauf der Encoder 100 bestimmt, ob sich der serielle Link 80 im Wiederherstellungs- oder Trainingmodus (Block 104) befindet. In diesem Fall wird ein direkter Link zur Wiederherstellung hergestellt (Block 106). Ein direkter Link zur Wiederherstellung erfolgt bei einem Verlust des Link. Der Empfänger 50 wechselt in einen Wiederherstellungszustand, wo er die Blocksperre wiedergewinnt und erneut beginnt. Andernfalls wird kein direkter Link zur Wiederherstellung hergestellt.
-
In einigen Ausführungsformen verwendet der Empfänger 50 einen aus der Blocksperre gewonnen Parameter, um anzuzeigen, ob er die Blocksperre erhalten hat. An diese Stelle setzt der Empfänger 50 den aus der Blocksperre gewonnenen Parameter auf FALSE (falsch) (Block 106). Als nächstes erfolgt eine Verschiebung des Encoders 100 in Bits in ein 130-Bit-Register, wie der (130, 128)-Code 90 in 2 (Block 110). Der Zweck dieser Verschiebung ist der Erhalt einer Blocksperre über das 130-Byte-Feld. Wenn das 130-Bit-Register eine elektrisch inaktive Ausgangssequenz (EIES) sucht (Block 112), wird eine Prüfung durchgeführt, um zu bestätigen, dass der aus der Blocksperre gewonnene Parameter auf TRUE (wahr) gesetzt ist und dass das 130-Bit-Register nicht mit der vorherigen Grenze übereinstimmt (Block 114). Ist das 130-Bit-Register kein EIES, prüft der Encoder 100, ob der aus der Blocksperre gewonnene Parameter nur auf TRUE (wahr) gesetzt ist (Block 120).
-
Wenn die gewonnene Blocksperre TRUE (wahr) ist und das 130-Bit-Register nicht mit der vorherigen Grenze (dem „Ja“-Zweig von Block 114) übereinstimmt, wird der aus der Blocksperre gewonnene Parameter auf TRUE (wahr) gesetzt (Block 124), die Blocksperregrenze wird vom Encoder 100 neu etabliert (Block 126), und die laufenden Ordered-Sets werden mit einem Fehler beendet (Block 128).
-
Wenn eine oder beide Abfragen nicht wahr sind (der „Nein“-Zweig von Block 114), wird der aus der Blocksperre gewonnene Parameter auf TRUE (wahr) gesetzt (Block 116) und die Blocksperregrenze wird festgelegt (Block 118). Als nächstes folgt eine Abfrage zur Ermittlung, ob der aus der Blocksperre gewonnene Parameter TRUE (wahr) ist (Block 120). Wenn er nicht wahr ist, wird eine weitere Verschiebung in Bits in ein 130-Bit-Register durchgeführt (block 110). Ist der aus der Blocksperre gewonnene Parameter TRUE (wahr) (der „Ja“-Zweig von Block 120), wird die entsprechende Zahl von Bits an den Empfänger weitergeleitet (Block 122).
-
Nachdem entweder das laufende Ordered-Set mit einem Fehler beendet (Block 128) oder die entsprechende Zahl von Bits an den Empfängerkern 50 weitergeleitet wurde (Block 122), erfolgt eine Abfrage, ob die Verbindung mit dem normalen Betrieb wieder hergestellt werden soll (Block 130). In diesem Fall werden die Funktionen des Encoders 100 von Anfang an wiederholt (Block 102). Andernfalls erfolgt eine weitere Verschiebung in Bits in ein 130-Bit-Register (Block 110).
-
6 zeigt ein Ablaufdiagramm zur Darstellung der Operationen des Encoders 100 innerhalb des Systems 200 (1) zur Verarbeitung eines Transaktionsschichtpakets, gemäß einiger Ausführungsformen. Während 5 den Prozess für den Erhalt einer Blocksperre zeigte, ob bei der Wiederherstellung nach einem Fehler oder zu Beginn des Prozesses, zeigt 6 die normale Paketabfertigung nach Festlegung der Blocksperre, wobei die Transaktionen durch den Link 80 transportiert werden. Das Ablaufdiagramm zeigt die Operationen am Empfänger 50 (1) für die Verarbeitung der vom Sender 40 im System 200 ankommenden Pakete. Der Prozess beginnt erst, wenn der Link aktiviert ist und keine Ordered-Sets eingehen (Block 202). Wenn dieser Zustand erreicht ist, wird der Sync-Header 22 gelesen, um zu bestimmen, ob es ein 01b ist (Block 204). Wie schon beschrieben, kommt der (130, 128)-Code 90 mit Präfix 01b, Nutzdaten wie logische IDL, Transaktionsschichtpaketen und Ordered-Sets. Ist der Sync-Header 22 kein 01b, sondern ein 10b, ist das Paket ein Ordered-Set und wird wie oben beschrieben verarbeitet (Block 206). Andernfalls werden die restlichen 128 Bit (16 Byte) 24 entschlüsselt (Block 208).
-
Als nächstes erfolgt eine Abfrage zur Bestimmung, ob das erste Symbol der 128 Bit 24 eine logische IDL (LIDL) ist (Block 210). Ist das der Fall, endet die Verarbeitung und der Encoder 100 kehrt an den Anfang zurück (Block 202). Ist das erste Symbol keine LIDL, erfolgt eine neue Abfrage zur Bestimmung, ob das erste Symbol der Anfang eines Datenlinkschichtpakets (DLLP) ist (Block 212). Ist das der Fall, werden die nächsten sechs Byte zur Verarbeitung weitergeleitet und die Byteparität wird berechnet (Block 214). Wie schon beschrieben, haben DLLP-Pakete eine feste Länge von acht Byte. Als solches ist das Endbyte immer Byte Acht. Demgemäß wird Byte Acht geprüft, um zu bestimmen, ob es mit der berechneten Parität des DLLP übereinstimmt (Block 216). In diesem Fall ist die Verarbeitung vollständig durchgeführt und die Steuerung kehrt an den Anfang zurück (Block 202).
-
Stimmt die berechnete Parität nicht mit dem im Byte Acht gespeicherten Wert überein (der „Nein“-Zweig von Block 216), werden Byte und Lane, die die Nichtübereinstimmung enthalten, protokolliert (Block 218) und es wird ein direkter Link zur Wiederherstellung hergestellt (Block 220).
-
Wenn das erste Symbol nicht der Anfang eines DLLP ist (der „Nein“-Zweig von Block 212), bestimmt der Encoder 100, ob das erste Antasten den Anfang eines Transaktionsschichtpakets (TLP) anzeigt (Block 222). Ist das der Fall, holt der Encoder 100 die CRC-Bit 42 aus dem TLP-Layout 36 (4) und vergleicht den 4-Bit-Wert mit dem aus dem Formatfeld 44, dem Längefeld 46 und dem TLP-Digest-Feld 48 erhaltenen Wert (Block 224). Liegt eine Übereinstimmung vor, wird das gesamte Paket, so wie es empfangen wurde, zur Verarbeitung weitergeleitet, während der Encoder 100 die Byteparität berechnet (Block 226). Andernfalls wird ein direkter Link zur Wiederherstellung hergestellt (Block 220). Nachdem die Parität berechnet wurde, wird sie mit dem im Endbyte der 128-Bit-Sequenz gespeicherten Wert verglichen (Block 228). Wenn das Endbyte mit der berechneten Parität übereinstimmt, stellt das letzte Byte ein gültiges END-Byte dar (Block 230). Ist das Endbyte eine Inverse der berechneten Parität, wird ein fehlerhaftes END (EDB) erkannt (Block 230). Ist das Endbyte weder eine Übereinstimmung noch eine Inverse der berechneten Parität, wird die Verarbeitung für diese Sequenz beendet und die Steuerung kehrt zum Anfang zurück (Block 202).
-
Wenn die erste Antastung kein Anfang eines TLP ist (der „Nein“-Zweig von Block 222), bestimmt der Encoder 100, ob das erste Symbol Ordered-Sets bezeichnet (Block 232). Ist das der Fall, werden die Ordered-Sets weitergeleitet, wenn sie das richtige Format haben. Andernfalls wird ein Fehler protokolliert und der Link wird an die Wiederherstellung geleitet (Block 234). Bezeichnet das erste Symbol keine Ordered-Sets (der „Nein“-Zweig von Block 232), ist das erste Symbol keines der vier Typen (Logische IDL, TLP, DLLP, Ordered-Set) und der Link wir an (Block 220) geleitet.
-
7 ist ein Blockdiagramm, das ein Datenlinkschichtpaket-Layout 56 gemäß einiger Ausführungsformen darstellt. Das DLLP 56 enthält Nutzdaten mit einer festen Länge von acht Byte. Demgemäß werden nach dem ersten 8-Bit-Nutzdatentyp-Symbol 32, welches den Nutzdatentyp (sSDP) angibt, die DLLP-Nutzdaten 54 in den nächsten vier Byte, die LCRC 58 in den nächsten sechzehn Bit und die END-Parität 52 im letzten Byte gespeichert. Für die Nutzdaten eines Datenlinkschichtpakets (DLLP) gelten die gleichen XOR-Regeln beim END-Paritätsbyte 52. Demgemäß wird eine byteweise XOR aller Bytes im DLLP 56 genommen. Da die Datenlinkschichtpakete kein EDB haben, werden alle Einser im XOR des Empfängers ebenfalls als Fehler angesehen. Für DLLP-Nutzdaten 56 kann der Encoder 100 somit eine beliebige Anzahl von Bitfehlern in einem 8-Bit-Fenster tolerieren.
-
In einigen Ausführungsformen bietet der Encoder 100 eine Bitfehlererkennung innerhalb eines Vier-Bit-Fensters (wenn die Längenfelder betroffen sind) und für den Rest der Nutzdaten innerhalb eines Sieben-Bit-Fensters. Die Erkennung von Ordered-Set-Fehlern wird in dieser Schrift nicht beschrieben. In einigen Ausführungsformen verwendet der Encoder 100, falls erforderlich, ein separates Byte für die Parität. Da Ordered-Sets jedoch aufgrund der integrierten Fehlererkennung im Protokoll (viele Wiederholungen) mehrere Bitfehler tolerieren können, und da mehrere Bitfehler keine Auswirkung auf die Datenkonsistenz haben, ist es für Ordered-Sets nicht erforderlich, kann aber für Transaktions- oder Datenlinkschicht-Pakete genutzt werden. Dies wäre extrem nützlich für Implementierungen, bei denen diskrete Fourier-Transformationen (Equalizer) zum Einsatz kommen. Die garantierte Erkennung mehrerer Bit-Flip-Fehler innerhalb eines gegebenen Fensters ist eine neue Fähigkeit, die aufgrund dieses Ansatzes hinzugefügt wird.
-
In einigen Ausführungsformen optimiert der Encoder 100 die benötigte Zeit bis zum Beenden eines Energiesparzustands, wie L0s, indem unverschlüsselte Muster gesendet werden, die nicht (130, 128) codiert sind. (L0 ist ein normaler Betriebszustand, wobei Pakete gesendet und empfangen werden; L0s ist ein Energiesparzustand, in dem eine schnelle Rückkehr in den L0-Zustand möglich ist, ohne die Link-Wiederherstellung durchlaufen zu müssen.)
-
8 zeigt ein Ablaufdiagramm der vom Encoder 100 durchgeführten Operationen, gemäß einiger Ausführungsformen. Zuerst sendet der Encoder 100 eine vorbestimmte Anzahl von niederfrequenten Mustern (wie in PCI Express 2.0), wie z. B. acht Nullen gefolgt von acht Einsern, was vier- bis achtmal (oder nach Bedarf) wiederholt wird (Block 302). Dies hilft dem Empfänger 50, den elektrisch inaktiven Zustand zu beenden. Anschließend sendet der Sender 40 die Anzahl von hochfrequenten Fast-Training-Sequenzen (FTS), die vom Gerät während der Linkverhandlung angefordert wurden (Block 304). Die FTS können eine Kombination aus Sondersymbolen sein (jede FTS kann z. B. 10110010 gefolgt von drei 10101010 sein). Die hochfrequente Komponente hilft beim Erhalt einer Bitsperre, während das erste Symbol zum Erreichen der Bytesperre genutzt werden kann. Am Ende sendet der Encoder 100 eine vorbestimmte Anzahl von Symbolen, um ein Lane-zu-Lane-Deskewing zu erreichen (z. B. 11000011) (Block 306).
-
Nach Erhalt der Symbolsperre sucht der Empfänger 50 nach dem Deskewing-Muster für das Deskewing zwischen den Lanes des seriellen Links 80. Nach dem zweiten Deskewing kann der (130, 128)-Code 90 beginnen (Block 308). Eine Entfernung des (130, 128)-Codes 90 ohne Verschlüsselung zur Aktivierung des Betriebs des Links ist effizienter beim Versenden vorbestimmter Muster, als das Senden periodischer Sequenzen eines niederfrequenten Musters zum Beenden des elektrisch inaktiven Zustands, gefolgt von hochfrequenten Mustern zum Erreichen der Bit- und Symbolsperre und einem separaten Set für die Durchführung des Lane-zu-Lane-Deskewing, wobei alle in einem (130, 128)-Code 90 eingebettet sind und verschlüsselt werden. Die Scrambler 30/Descrambler 70 während im L0s-Zustand rückgesetzt und beginnen ihre Arbeit mit dem ersten (130, 128)-Code 90. Das Ablaufdiagramm 300 zeigt, wie diese separaten Transaktionen vom Encoder 100 durchgeführt werden, in einigen Ausführungsformen zum Beenden des elektrisch inaktiven Zustands, zum Erhalt einer Bitsperre und zum Erreichen des Lane-zu-Lane-Deskewing, bevor wieder normal übertragen wird, z. B. im L0-Zustand.
-
Ein anderes Problem, das bei einem Ansatz, der nur veschlüsselt, auftreten kann, sind die sogenannten Killer-Packets. Wenn ein bestimmtes Bitmuster Fehler verursachen kann und ein TLP- oder DLLP-Paket dieses Muster nach der Verschlüsselung im Anschluss an den ersten Durchlauf durch die Wiederherstellungsphase aufweist, sorgt der Encoder 100 in einigen Ausführungsformen dafür, dass das problematische Bitmuster bei den nachfolgenden Übertragungen nicht wiederholt wird. Durch diesen Ansatz wird verhindert, dass ein Link durch ein Virus außer Betrieb gesetzt werden kann. Bei jedem Durchlaufen der Wiederherstellung und bei jeder EIES-Sequenz wird der Scrambler 30 (Descrambler 70) auf einen Seed-Wert rückgesetzt. Eine Rücksetzung des Scramblers 30 (Descramblers 70) während der Wiederherstellungsphase ist notwendig, da der Descrambler 70 aufgrund von Fehlern, wie Bit-Slip, seine Synchronisation mit dem Sender 40 verloren haben kann. Der Nachteil dieser Scramblersynchronisation ist jedoch, dass das gleiche TLP-Paket 36 mit identischem Bitstrom jedes Mal erneut aus der Wiederholungsphase ausgegeben werden könnte. Wenn es sich bei diesem Bitmuster um ein Killer-Bitmuster handelt, kann das Bitmuster wiederholt Probleme verursachen, z. B. Bitfehler.
-
Um solche Probleme zu vermeiden, sendet der Encoder 100 in einigen Ausführungsformen eine zufällige Anzahl von speziellen IDLE-Symbolen im L0, bevor das erste, aus der Wiederholungsphase kommende TLP 36 gesendet wird. Die exakte Formel für die Anzahl spezieller IDLE-Symbole hängt von der Implementierung in einigen Ausführungsformen ab, und kann abhängig von verschiedenen Faktoren von Ausführung zu Ausführung unterschiedlich sein. Die Auswirkung von mehreren Faktoren erschwert eine Charakterisierung der zu erwartenden Anzahl bei jedem Durchlauf der Wiederholungsphase.
-
Während die Anmeldung unter Verwendung einer begrenzten Anzahl von Ausführungsformen beschrieben wurde, sind sich fachkundige Personen bewusst, dass viele weitere Modifizierungen und Varianten möglich sind. Die beigefügten Ansprüche sollen alle solchen Modifizierungen und Varianten im Rahmen des wahren Sinns und Umfangs der Erfindung abdecken.
