-
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.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
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-Bit-Muster
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 Muster 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-Grenze gemäß 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 Betrachten
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 Muster (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 verschlü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.