DE102009061814B3 - Verfahren, Sender, Empfänger und System für ein Paketisierungsschema auf Link- und Lane-Ebene für die Codierung in seriellen Links - Google Patents
Verfahren, Sender, Empfänger und System für ein Paketisierungsschema auf Link- und Lane-Ebene für die Codierung in seriellen Links Download PDFInfo
- Publication number
- DE102009061814B3 DE102009061814B3 DE102009061814.7A DE102009061814A DE102009061814B3 DE 102009061814 B3 DE102009061814 B3 DE 102009061814B3 DE 102009061814 A DE102009061814 A DE 102009061814A DE 102009061814 B3 DE102009061814 B3 DE 102009061814B3
- Authority
- DE
- Germany
- Prior art keywords
- blocks
- receiver
- bit
- transmitter
- followed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
- G06F13/4286—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus using a handshaking protocol, e.g. RS232C link
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0061—Error detection codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0079—Formats for control data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L25/00—Baseband systems
- H04L25/02—Details ; arrangements for supplying electrical power along data transmission lines
- H04L25/03—Shaping networks in transmitter or receiver, e.g. adaptive shaping networks
- H04L25/03828—Arrangements for spectral shaping; Arrangements for providing signals with specified spectral properties
- H04L25/03866—Arrangements for spectral shaping; Arrangements for providing signals with specified spectral properties using scrambling
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
Es wird ein neues Codierungsschema offenbart, das der physischen Schicht durch Betrachtung weniger ausgewählter Bits die Identifizierung von Paketgrenzen ermöglicht bei gleichzeitiger Verbesserung der Fehlererkennungsfähigkeit und Aufrechterhaltung eines niedrigen Overhead für Zustände mit niedrigem Energieverbrauch. Durch das Eliminieren des Overhead der 8b/10b-Codierung für die physische 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 Zuständen mit niedrigem Energieverbrauch und einen Mechanismus für die Handhabung von problematischen Paketen.
Description
- 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
- 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/iob verbessertes Kodierungsschema bereitzustellen.
Erfindungsgemäß wird diese Aufgabe gelöst durch ein Verfahren nach Anspruch 1, einen Sender nach Anspruch 10, einen Empfänger nach Anspruch 18 und ein System nach Anspruch 25. 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 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 in1 verwendet wird, gemäß einiger Ausführungsformen; -
3 ist ein Blockdiagramm von vier Arten von Nutzdaten, deren Längen von dem Codierungsschema aus1 verarbeitet werden, gemäß einiger Ausführungsformen; -
4 ist ein Blockdiagramm eines Transaktionsschichtpaket-Layouts, das vom Codierungsschema aus1 verwendet wird, gemäß einiger Ausführungsformen; -
5 ist ein Ablaufdiagramm, das Funktionsabläufe des Codierungsschemas aus1 zum Erhalt einer Blocksperre zeigt, gemäß einiger Ausführungsformen; -
6 ist ein Ablaufdiagramm, das Funktionsabläufe des Codierungsschemas aus1 zur Verarbeitung der Pakete zeigt, wie in bestimmten Ausführungsbeispielen gezeigt; -
7 ist ein Blockdiagramm eines Datenlinkschichtpaket-Layouts, das vom Codierungsschema aus1 verwendet wird, gemäß einiger Ausführungsformen; und -
8 ist ein Ablaufdiagramm, das verbesserten Funktionsabläufe durch das Codierungsschema aus1 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 (in2 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.
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).
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.
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.)
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.
Weitere Aspekte der Erfindung sind:
- 1. System, das Folgendes umfasst:
- einen Empfänger, der einen Decoder umfasst;
- 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;
- 2. System nach Anspruch 1, bei dem der Empfänger den Code als eine Trainingsequenz verwendet, die dem Empfänger einer Synchronisierung mit dem Sender ermöglicht.
- 3. System nach Anspruch 1, bei dem das Zwei-Bit-Präfix einen ersten gültigen Zustand umfasst, wobei der erste gültige Zustand anzeigt, dass der Code eine elektrisch inaktive Eingangssequenz oder eine elektrisch inaktive Ausgangssequenz ist und die Sequenz der vorbestimmten Bitlänge ein sich wiederholendes Muster umfasst.
- 4. System nach Anspruch 1, bei dem das Zwei-Bit-Präfix einen zweiten gültigen Zustand umfasst, wobei der zweite gültige Zustand anzeigt, dass ein erstes Byte der Sequenz der vorbestimmten Bitlänge ein Nutzdatentypsymbol ist.
- 5. System nach Anspruch 4, bei dem das Nutzdatentypsymbol anzeigt, dass die Nutzdaten entweder inaktive Nutzdaten, Nutzdaten eines Transaktionsschichtpakets, Nutzdaten eines Datenlinkschichtpakets oder Ordered-Set-Nutzdaten sind.
- 6. System nach Anspruch 5, wobei das Nutzdatentypsymbol Nutzdaten eines Transaktionsschichtpakets anzeigt, wobei das Transaktionsschichtpaket des Weiteren Folgendes umfasst:
- ein oder mehrere Längenfelder; und
- ein CRC-Feld, wobei das CRC-Feld einen festen Platz im Transaktionsschichtpaket einnimmt, und das CRC-Feld eine zyklische Redundanzprüfung des einen oder der mehreren Längenfelder umfasst;
- wobei der Empfänger das eine oder die mehreren Längenfelder mit dem CRC-Feld bestätigt, bevor die Länge des Transaktionsschichtpakets unter Verwendung des einen oder der mehreren Längenfelder berechnet wird.
- 7. Codierungsschema, das Folgendes umfasst:
- Empfangen eines Codes durch einen Empfänger über einen seriellen Link, wobei der Code Folgendes umfasst:
- ein Zwei-Bit-Präfix; und
- eine Sequenz einer vorbestimmten Bitlänge;
- Empfangen eines Codes durch einen Empfänger über einen seriellen Link, wobei der Code Folgendes umfasst:
- 8. Codierungsschema nach Anspruch 7, wobei das Lesen eines Nutzdatentypsymbols des Weiteren Folgendes umfasst:
- Einholen des Nutzdatentypsymbols, wobei das Symbol inaktive Nutzdaten anzeigt; und
- kein weiteres Verarbeiten des Codes.
- 9. Codierungsschema nach Anspruch 7, wobei das Lesen eines Nutzdatentypsymbols des Weiteren Folgendes umfasst:
- Einholen des Nutzdatentypsymbols, wobei das Symbol ein Datenlinkschichtpaket anzeigt;
- Berechnen der Byteparität der Sequenz der vorbestimmten Bitlänge;
- Weiterleiten von sechs aufeinanderfolgenden Byte für ein Verarbeiten; und
- Vergleichen der berechneten Byteparität mit einem letzten Byte der Sequenz der vorbestimmten Bitlänge, wobei ein Fehler protokolliert wird, wenn die Byteparität und das letzte Byte nicht gleich sind.
- 10. Codierungsschema nach Anspruch 7, wobei das Lesen eines Nutzdatentypsymbols des Weiteren Folgendes umfasst:
- Einholen des Nutzdatentypsymbols, wobei das Symbol ein Transaktionsschichtpaket anzeigt;
- Einholen der Längenbytes des Transaktionsschichtpakets, wobei die Längenbytes sich an einer vorbestimmten Stelle in der Sequenz der vorbestimmten Bitlänge befinden; und
- Vergleichen der eingeholten Längenbytes mit einer Vielzahl von zyklischen Redundanzprüfungs-Bits, die sich an einer zweiten vorbestimmten Stelle in der Sequenz der vorbestimmten Bitlänge befinden, um ein Resultat zu produzieren;
- wobei bei einem Resultat von Null eine Länge des Transaktionsschichtpakets von den Längenbytes eingeholt wird.
- 11. Codierungsschema nach Anspruch 10, wobei das Vergleichen der eingeholten Längenbytes mit einer Vielzahl von zyklischen Redundanzprüfungs-Bits nach einer Formel des Weiteren Folgendes umfasst:
- Verwenden einer vorbestimmten Formel für das Berechnen einer Länge des Transaktionsschichtpakets.
- 12. Codierungsschema nach Anspruch 7, das des Weiteren Folgendes umfasst:
- Senden einer vorbestimmten Anzahl von niederfrequenten Symbolen, um den Empfänger zu veranlassen, einen elektrisch inaktiven Zustand zu beenden;
- Senden einer zweiten vorbestimmten Anzahl von hochfrequenten Symbolen, um dem Empfänger den Erhalt einer Bitsperre zu ermöglichen;
- Senden einer dritten vorbestimmten Anzahl von Symbolen, um dem Empfänger ein Lane-zu-Lane-Deskew zu ermöglichen;
- wobei der Empfänger ein Wiederherstellen aus einem Energiesparzustand durchführt.
- 13. Code zum Ersetzen einer 8b/10b-Codierung in einem seriellen Link, wobei der Code Folgendes umfasst:
- ein Zwei-Bit-Präfix, das einen ersten Wert und einen zweiten Wert umfasst, wobei:
- der erste Wert entweder eine elektrisch inaktive Ausgangssequenz oder eine elektrisch inaktive Eingangssequenz anzeigt; und
- der zweite Werte entweder eine inaktive Sequenz, ein Datenlinkschichtpaket
- oder ein Transaktionsschichtpaket anzeigt; und
- eine Sequenz einer vorbestimmten Bitlänge, wobei die Sequenz eindeutige Bits auf Basis des Wertes des Zwei-Bit-Präfix umfasst;
- wobei der Code einem mit einem Ende des seriellen Links verbundenen Empfänger das Synchronisieren mit einem Sender, der mit dem anderen Ende des seriellen Links verbunden ist, ermöglicht.
- ein Zwei-Bit-Präfix, das einen ersten Wert und einen zweiten Wert umfasst, wobei:
- 14. Code nach Anspruch 13, wobei das Zwei-Bit-Präfix den ersten Wert umfasst und die Sequenz der vorbestimmten Bitlänge eine Wiederholungssequenz von Einsern und Nullen umfasst, wobei das Zwei-Bit-Präfix und die Sequenz der vorbestimmten Bitlänge nicht verschlüsselt sind und für das Identifizieren einer Blockgrenze für das nachfolgende Verarbeiten und bei Bedarf für das Validieren und erneutes Identifizieren der Blockgrenze verwendet werden.
- 15. Code nach Anspruch 14, wobei die Sequenz der vorbestimmten Bitlänge mit einer niedrigeren Frequenz gesendet wird, wodurch der Empfänger einen Energiesparzustand beenden kann.
- 16. Code nach Anspruch 14, wobei die Sequenz der vorbestimmten Bitlänge den Empfänger veranlasst, ein lineares Feedback-Shift-Register zurückzusetzen.
- 17. Code nach Anspruch 13, wobei das Zwei-Bit-Präfix den zweiten Wert umfasst, ein erstes Byte der Sequenz der vorbestimmten Bitlänge des Weiteren ein Nutzdatentypsymbol umfasst, wobei der Empfänger die Sequenz der vorbestimmten Bitlänge gemäß dem Nutzdatentypsymbol verarbeitet.
- 18. Code nach Anspruch 18, wobei das Nutzdatentypsymbol des Weiteren inaktive Nutzdaten anzeigt, wobei der Empfänger keine weiteren Maßnahmen durchführt.
- 19. Code nach Anspruch 18, wobei das Nutzdatentypsymbol des Weiteren ein Datenlinkschichtpaket anzeigt, und die restlichen Bytes des Codes sechs Bytes für die Verarbeitung und ein Paritätsbyte umfassen.
- 20. Code nach Anspruch 18, wobei das Nutzdatentypsymbol des Weiteren ein Transaktionsschichtpaket anzeigen, und die restlichen Bytes des Codes Folgendes umfassen:
- zwei Bits mit Formatinformationen;
- zehn Bits mit Längeninformationen;
- ein Bit mit Digestinformationen, wobei Format-, Längen- und Digestinformationen gemeinsam eine Länge des Transaktionsschichtpakets liefern; und
- eine Vielzahl von CRC-Bytes, wobei die CRC-Bytes mit der Länge des Transaktionsschichtpakets verglichen werden, bevor das Transaktionsschichtpaket vom Empfänger verarbeitet wird.
Claims (32)
- Verfahren, das folgendes umfasst: Senden eines oder mehrerer erster Blöcke von einem Sender (40) zu einem Empfänger (50), der mit dem Sender (40) über einen seriellen Link (80) gekoppelt ist, um den Empfänger (50) zu veranlassen, einen elektrisch inaktiven Zustand zu verlassen, wobei jeder erste Block unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix enthält, das einen Sync-Header (22), gefolgt von 16 niederfrequenten Symbolen, die 128 Bit umfassen, umfasst; Senden eines oder mehrerer zweiter Blöcke an den Empfänger (50), um dem Empfänger (50) zu ermöglichen, eine Bitsperre und eine Symbolsperre zu erhalten, wobei jeder zweite Block unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix enthält, das einen Sync-Header (22), gefolgt von 16 hochfrequenten Symbolen, die 128 Bit umfassen, umfasst; Senden eines oder mehrerer dritter Blöcke an den Empfänger (50), um dem Empfänger (50) zu ermöglichen, ein Lane-zu-Lane-Deskew zu erreichen, wobei der eine oder die mehreren dritten Blöcke unter Verwendung eines (130, 128)-Codes (90) codiert sind und ein Zwei-Bit-Präfix enthalten, das einen Sync-Header (22), gefolgt von 16 Symbolen, die 128 Bit umfassen, umfasst; und Beginnen, Datenblöcke vom Sender (40) zum Empfänger (50) zu übertragen, wobei jeder Datenblock mit einem (130, 128)-Code (90) codiert ist und ein Zwei-Bit-Präfix enthält, das einen Sync-Header (22), gefolgt von einer 128-Bit-Nutzlast mit 16 Symbolen, umfasst.
- Verfahren nach
Anspruch 1 , wobei der Sync-Header (22) für den einen oder die mehreren ersten Blöcke einen Wert von ‚10‘ binär (10b) oder ‚01‘ binär (01b) hat. - Verfahren nach
Anspruch 1 oderAnspruch 2 , wobei der eine oder die mehreren ersten Blöcke ein Muster aufweisen, das einen Zwei-Bit-Sync-Header umfasst, der ‚10‘ binär (10b) gefolgt von abwechselnden Sequenzen von acht Nullen und acht Einsen, die achtmal wiederholt werden. - Verfahren nach einem der vorhergehenden Ansprüche, wobei der eine oder die mehreren ersten Blöcke eine elektrisch inaktive Ausgangssequenz ist/sind, die ein Ordered-Set mit einer vorbestimmten Anzahl von niederfrequenten Symbolen umfasst.
- Verfahren nach einem der vorhergehenden Ansprüche, wobei die mehreren zweiten Blöcke ein Muster aufweisen, das einen Zwei-Bit-Sync-Header umfasst, der ‚10‘ binär (10b), gefolgt von einer schnellen Trainingssequenz (FTS), die eine vorbestimmte Sequenz von Hochfrequenzsymbolen aufweist, umfasst.
- Verfahren nach
Anspruch 5 , wobei der Sender (40) die Anzahl der hochfrequenten Fast-Training-Sequenzen (FTS), die der Empfänger (50) während der Linkverhandlung angefordert hatte, sendet. - Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren den Link von einem Energiesparzustand Los in einen normalen Betriebszustand Lo, während dem Datenblöcke über den seriellen Link (80) übertragen werden, überführt.
- Verfahren nach einem der vorhergehenden Ansprüche, wobei der Sender (40) einen Scrambler (30) und der Empfänger (50) einen Descrambler (70) aufweist, wobei das Verfahren ferner die Verwendung des Scramblers (30) zur Verschlüsselung der 128-Bit-Nutzlast eines Datenblocks umfasst.
- Verfahren nach einem der vorhergehenden Ansprüche, wobei der Sender (40) einen Scrambler (30) aufweist, und wobei der eine oder die mehreren ersten Blöcke eine elektrisch inaktive Ausgangssequenz enthalten, wobei das Verfahren ferner Zurücksetzen eines lineares Feedback-Schieberegisters (LFSR) des Scramblers (30) mittels der elektrisch inaktiven Ausgangssequenz eines ersten Blocks umfasst.
- Sender (40), der konfiguriert ist, um über einen seriellen Link (80) mit einem Empfänger (50) gekoppelt zu werden, und einen Encoder (20) enthält, wobei der Sender (40) konfiguriert ist, um: einen oder mehrere erste Blöcke an den Empfänger (50) zu senden, um den Empfänger (50) zu veranlassen, einen elektrisch inaktiven Zustand zu verlassen, wobei jeder erste Block von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix enthält, das einen Sync-Header (22), gefolgt von 16 niederfrequenten Symbolen, die 128 Bit umfassen, umfasst; einen oder mehrere zweite Blöcke an den Empfänger (50) zu senden, um dem Empfänger (50) zu ermöglichen, eine Bitsperre und eine Symbolsperre zu erhalten, wobei jeder zweite Block von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix enthält, das einen Sync-Header (22), gefolgt von 16 hochfrequenten Symbolen, die 128 Bit umfassen, umfasst; einen oder mehrere dritte Blöcke an den Empfänger (50) senden, um dem Empfänger (50) zu ermöglichen, ein Lane-zu-Lane-Deskew zu erreichen, wobei der eine oder die mehreren dritten Blöcke von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert sind und ein Zwei-Bit-Präfix enthalten, das einen Sync-Header (22), gefolgt von 16 Symbolen, die 128 Bit umfassen, umfasst; und zu beginnen, Datenblöcke an den Empfänger (50) zu senden, wobei jeder Datenblock von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix mit einem Sync-Header (22) gefolgt von einer 128-Bit-Nutzlast mit 16 Symbolen enthält.
- Sender (40) nach
Anspruch 10 , wobei der Sync-Header (22) der ein oder mehreren ersten Blöcke einen Wert von ‚10‘ binär (10b) oder ‚01‘ binär (01b) hat. - Sender (40) nach
Anspruch 10 oder11 , wobei der eine oder die mehreren ersten Blöcke ein Muster aufweisen, das einen Zwei-Bit-Sync-Header umfasst, der ‚10‘ binär (10b), gefolgt von abwechselnden Sequenzen von acht Nullen und acht Einsen, die achtmal wiederholt werden, umfasst. - Sender (40) nach einem der
Ansprüche 10 bis12 , wobei der eine oder die mehreren ersten Blöcke eine elektrisch inaktive Ausgangssequenz, die ein Ordered-Set mit einer vorbestimmten Anzahl von niederfrequenten Symbolen umfasst, ist. - Sender (40) nach einem der
Ansprüche 10 bis13 , wobei die mehreren zweiten Blöcke ein Muster aufweisen, das einen Zwei-Bit-Sync-Header, der ‚10‘ binär (10b) umfasst, gefolgt von einer Fast-Training-Sequenz (FTS) mit einer vorbestimmten Sequenz von hochfrequenten Symbolen, umfasst. - Sender (40) nach
Anspruch 14 , wobei der Sender (40) die Anzahl der hochfrequenten Fast-Training-Sequenzen (FTS), die der Empfänger (50) während der Linkverhandlung angefordert hatte, sendet. - Sender (40) nach einem der
Ansprüche 10 bis15 , wobei der Sender (40) einen Scrambler (30) enthält und der Sender (40) ferner konfiguriert ist, die 128-Bit-Nutzlast eines Datenblocks mit dem Scrambler (30) zu verschlüsseln. - Sender (40) nach einem der
Ansprüche 10 bis16 , wobei der Sender (40) einen Scrambler (30) aufweist, wobei der eine oder die mehreren ersten Blöcke eine elektrisch inaktive Ausgangssequenz aufweisen, und wobei der Sender (40) ferner so konfiguriert ist, dass er ein lineares Feedback-Shift-Register (LFSR) des Scramblers (30) mittels der elektrisch inaktiven Ausgangssequenz eines ersten Blocks zurücksetzt. - Empfänger (50), der konfiguriert ist, um über einen seriellen Link (80) mit einem Sender (40) gekoppelt zu werden, und einen Decoder (60) umfasst, wobei der Empfänger (50) konfiguriert ist, um: einen oder mehrere erste Blöcke vom Sender (40) zu empfangen, um den Empfänger (50) zu veranlassen, einen elektrisch inaktiven Zustand zu verlassen, wobei jeder erste Block von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix enthält, das einen Sync-Header (22), gefolgt von 16 niederfrequenten Symbolen, die 128 Bit umfassen, umfasst; den elektrischen Ruhezustand als Reaktion auf den Empfang der ein oder mehr ersten Blöcke zu verlassen; einen oder mehrere zweite Blöcke von dem Sender (40) zu empfangen, um dem Empfänger (50) zu ermöglichen, eine Bitsperre und eine Symbolsperre zu erhalten, wobei jeder zweite Block von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix enthält, das einen Sync-Header (22), gefolgt von 16 Hochfrequenz-Symbolen, die 128 Bit umfassen, umfasst; Bit- und Symbolsperre unter Verwendung von mindestens einem der ein oder mehreren zweiten Blöcke zu erhalten; einen oder mehrere dritte Blöcke vom Sender (40) zu empfangen, um dem Empfänger (50) zu ermöglichen, ein Lane-zu-Lane-Deskew zu erreichen, wobei der eine oder die mehreren dritten Blöcke von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert sind und ein Zwei-Bit-Präfix enthalten, das einen Sync-Header (22), gefolgt von 16 Symbolen, die 128 Bit umfassen, umfasst; Lane-zu-Lane-Deskew unter Verwendung von mindestens einem der beiden dritten Blöcke zu erreichen; zu beginnen, Datenblöcke von dem Sender (40) zu empfangen, wobei jeder Datenblock von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix mit einem Sync-Header (22) gefolgt von einer 128-Bit-Nutzlast mit 16 Symbolen enthält; und die Datenblöcke mit dem Decoder (60) zu dekodieren.
- Empfänger (50) nach
Anspruch 18 , wobei der Sync-Header (22) der ein oder mehreren ersten Blöcke einen Wert von ‚10‘ binär (10b) oder ‚01‘ binär (01b) hat. - Empfänger (50) nach
Anspruch 18 oder19 , wobei der eine oder die mehreren ersten Blöcke ein Muster aufweisen, das einen Zwei-Bit-Sync-Header umfasst, der ‚10‘ binär (10b), gefolgt von abwechselnden Sequenzen von acht Nullen und acht Einsen, die achtmal wiederholt werden, umfasst. - Empfänger (50) nach einem der
Ansprüche 18 bis20 , wobei der eine oder die mehreren ersten Blöcke eine elektrisch inaktive Ausgangssequenz, die ein Ordered-Set mit einer vorbestimmten Anzahl von niederfrequenten Symbolen umfasst, ist. - Empfänger (50) nach einem der
Ansprüche 18 bis21 , wobei die mehreren zweiten Blöcke ein Muster aufweisen, das einen Zwei-Bit-Sync-Header, der ‚10‘ binär (10b), gefolgt von einer Fast-Training-Sequenz (FTS) mit einer vorbestimmten Sequenz von Hochfrequenzsymbolen, umfasst. - Empfänger (50) nach
Anspruch 22 , wobei der Empfänger (50) die Anzahl der hochfrequenten Fast-Training-Sequenzen (FTS), die der Empfänger (50) während der Linkverhandlung angefordert hatte, empfängt. - Empfänger (50) nach einem der
Ansprüche 18 bis23 , wobei der Sender (40) einen Scrambler (30) enthält und der Sender (40) ferner konfiguriert ist, die 128-Bit-Nutzlast eines Datenblocks mit dem Scrambler (30) zu verschlüsseln, und wobei der Empfänger (50) einen Descrambler (70) enthält, der konfiguriert ist, die verschlüsselte 128-Bit-Nutzlast des Datenblocks zu entschlüsseln. - System, umfassend: einen Sender (40) der einen Encoder (20) enthält; einen Empfänger (50), der einen Decoder (60), der über einen seriellen Link (80) mit dem Sender (40) gekoppelt ist, enthält; wobei der Sender (40) konfiguriert ist, um einen oder mehrere erste Blöcke an den Empfänger (50) zu senden, um den Empfänger (50) zu veranlassen, einen elektrisch inaktiven Zustand zu verlassen, wobei jeder erste Block von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix enthält, das einen Sync-Header (22), gefolgt von 16 niederfrequenten Symbolen, die 128 Bit umfassen, umfasst; einen oder mehrere zweite Blöcke an den Empfänger (50) zu senden, um dem Empfänger (50) zu ermöglichen, eine Bitsperre und eine Symbolsperre zu erhalten, wobei jeder zweite Block von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein Zwei-Bit-Präfix enthält, das einen Sync-Header (22) gefolgt von 16 hochfrequenten Symbolen, die 128 Bit umfassen, umfasst; einen oder mehrere dritte Blöcke an den Empfänger (50) zu senden, um dem Empfänger (50) zu ermöglichen, ein Lane-zu-Lane-Deskew zu erreichen, wobei der eine oder die mehreren dritten Blöcke von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert sind und ein Zwei-Bit-Präfix enthalten, das einen Sync-Header (22), gefolgt von 16 Symbolen, die 128 Bit umfassen, umfasst; und zu beginnen, Datenblöcke an den Empfänger (50) zu senden, wobei jeder Datenblock von dem Encoder (20) unter Verwendung eines (130, 128)-Codes (90) codiert ist und ein 2-Bit-Präfix mit einem Sync-Header (22), gefolgt von einer 128-Bit-Nutzlast mit 16 Symbolen, enthält; und wobei der Empfänger (50) konfiguriert ist, um die ein oder mehreren ersten Blöcke vom Sender (40) zu empfangen; den elektrisch inaktiven Zustand als Reaktion auf den Empfang eines oder mehrerer erster Blöcke zu verlassen; einen oder mehrere zweite Blöcke vom Sender (40) zu empfangen; Bit- und Symbolsperre mit mindestens einem der beiden zweiten Blöcke zu erhalten; einen oder mehrere dritte Blöcke vom Sender (40) zu empfangen; Lane-zu-Lane-Deskew unter Verwendung mindestens eines der ein oder mehreren dritten Blöcke zu erreichen; zu beginnen, Datenblöcke vom Sender (40) zu empfangen; und die Datenblöcke mit dem Decoder (60) zu dekodieren.
- System nach
Anspruch 25 , wobei der Sync-Header (22) der ein oder mehreren ersten Blöcke einen Wert von ‚10‘ binär (10b) oder ‚01‘ binär (01b) hat. - System nach
Anspruch 25 oder26 , wobei der eine oder die mehreren ersten Blöcke ein Muster aufweisen, das einen Zwei-Bit-Sync-Header umfasst, der ‚10‘ binär (10b), gefolgt von abwechselnden Sequenzen von acht Nullen und acht Einsen, die achtmal wiederholt werden, umfasst. - System nach einem der
Ansprüche 25 bis27 , wobei der eine oder die mehreren ersten Blöcke eine elektrisch inaktive Ausgangssequenz, die ein Ordered-Set mit einer vorbestimmten Anzahl von niederfrequenten Symbolen umfasst, ist. - System nach einem der
Ansprüche 25 bis28 , wobei die mehreren zweiten Blöcke ein Muster aufweisen, das einen Zwei-Bit-Sync-Header, der ‚10‘ binär (10b) umfasst, gefolgt von einer Fast-Training-Sequenz (FTS) mit einer vorbestimmten Sequenz von hochfrequenten Symbolen, umfasst. - System nach
Anspruch 29 , wobei der Sender (40) die Anzahl der hochfrequenten Fast-Training-Sequenzen (FTS), die der Empfänger (50) während der Linkverhandlung angefordert hatte, sendet. - System nach einem der
Ansprüche 25 bis30 , wobei der Sender (40) einen Scrambler (30) enthält und der Sender (40) ferner konfiguriert ist, die 128-Bit-Nutzlast eines Datenblocks mit dem Scrambler (30) zu verschlüsseln , und wobei der Empfänger (50) einen Descrambler (70) enthält, der konfiguriert ist, die verschlüsselte 128-Bit-Nutzlast des Datenblocks zu entschlüsseln. - System nach einem der
Ansprüche 25 bis30 , wobei der Sender (40) einen Scrambler (30) aufweist, wobei der eine oder die mehreren ersten Blöcke eine elektrisch inaktive Ausgangssequenz aufweisen, und wobei der Sender (40) ferner so konfiguriert ist, dass er ein lineares Feedback-Shift-Register (LFSR) des Scramblers (30) mittels der elektrisch inaktiven Ausgangssequenz eines ersten Blocks zurücksetzt.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/145,696 | 2008-06-25 | ||
US12/145,696 US7769048B2 (en) | 2008-06-25 | 2008-06-25 | Link and lane level packetization scheme of encoding in serial links |
Publications (1)
Publication Number | Publication Date |
---|---|
DE102009061814B3 true DE102009061814B3 (de) | 2022-10-20 |
Family
ID=41396936
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE102009061814.7A Active DE102009061814B3 (de) | 2008-06-25 | 2009-06-25 | Verfahren, Sender, Empfänger und System für ein Paketisierungsschema auf Link- und Lane-Ebene für die Codierung in seriellen Links |
DE102009030545.9A Active DE102009030545B4 (de) | 2008-06-25 | 2009-06-25 | Paketisierungsschema auf Link- und Lane-Ebene für die Codierung in Seriellen Links |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE102009030545.9A Active DE102009030545B4 (de) | 2008-06-25 | 2009-06-25 | Paketisierungsschema auf Link- und Lane-Ebene für die Codierung in Seriellen Links |
Country Status (4)
Country | Link |
---|---|
US (1) | US7769048B2 (de) |
JP (1) | JP4981102B2 (de) |
CN (1) | CN101631000B (de) |
DE (2) | DE102009061814B3 (de) |
Families Citing this family (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009510898A (ja) * | 2005-09-30 | 2009-03-12 | ミツビシ・エレクトリック・リサーチ・ラボラトリーズ・インコーポレイテッド | Mimoワイヤレスlanにおけるアンテナ及びビームを選択するためのトレーニング信号 |
US8010860B2 (en) * | 2007-10-22 | 2011-08-30 | International Business Machines Corporation | Method and architecture to prevent corrupt data propagation from a PCI express retry buffer |
US8184758B2 (en) * | 2008-12-16 | 2012-05-22 | Hewlett-Packard Development Company, L.P. | Method and apparatus for detecting electrical idle |
US7958404B2 (en) * | 2009-03-31 | 2011-06-07 | Intel Corporation | Enabling resynchronization of a logic analyzer |
DE102009047199A1 (de) * | 2009-11-26 | 2011-06-01 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Eine Datenübertragungsvorrichtung und ein Verfahren zum Aktivieren einer Datenübertragung |
JP5657242B2 (ja) | 2009-12-09 | 2015-01-21 | 株式会社東芝 | 半導体装置及びメモリシステム |
US8275922B2 (en) * | 2010-02-22 | 2012-09-25 | International Business Machines Corporation | Implementing serial link training patterns separated by random data for training a serial link in an interconnect system |
US8804960B2 (en) * | 2010-02-22 | 2014-08-12 | International Business Machines Corporation | Implementing known scrambling relationship among multiple serial links |
CN103141066B (zh) * | 2010-10-12 | 2015-06-10 | 松下电器产业株式会社 | 发送电路、接收电路、发送方法、接收方法、通信系统及其通信方法 |
JP2012199724A (ja) | 2011-03-19 | 2012-10-18 | Fujitsu Ltd | データ送信装置、データ受信装置、データ送受信装置及びデータ送受信装置の制御方法 |
US8645585B2 (en) * | 2011-06-10 | 2014-02-04 | Nvidia Corporation | System and method for dynamically configuring a serial data link in a display device |
CN102957492B (zh) * | 2011-08-18 | 2015-05-13 | 盛科网络(苏州)有限公司 | 实现64b/67b编码边界锁定的方法及装置 |
US8572300B2 (en) * | 2011-10-26 | 2013-10-29 | Taiwan Semiconductor Manufacturing Co., Ltd. | Physical coding sublayer (PCS) architecture for synchronizing data between different reference clocks |
EP2775648B1 (de) * | 2011-10-31 | 2017-03-01 | Huawei Technologies Co., Ltd. | Datensender, datenempfänger und rahmensynchronisierungsverfahren |
US9043526B2 (en) | 2012-06-20 | 2015-05-26 | International Business Machines Corporation | Versatile lane configuration using a PCIe PIe-8 interface |
US8856573B2 (en) * | 2012-06-27 | 2014-10-07 | Intel Corporation | Setting a number (N) of fast training sequences (FTS) automatically to an optimal value |
DE112013007751B3 (de) * | 2012-10-22 | 2023-01-12 | Intel Corporation | Hochleistungs-Zusammenschaltungs-Bitübertragungsschicht |
US9311268B1 (en) * | 2012-10-25 | 2016-04-12 | Qlogic, Corporation | Method and system for communication with peripheral devices |
WO2015054898A1 (zh) * | 2013-10-18 | 2015-04-23 | 华为技术有限公司 | 电气空闲状态处理方法及快速外设组件互联pcie设备 |
WO2015066842A1 (zh) * | 2013-11-05 | 2015-05-14 | 华为技术有限公司 | 通信方法、高速外围组件互连pcie芯片及pcie设备 |
KR101874726B1 (ko) | 2013-12-26 | 2018-07-04 | 인텔 코포레이션 | Pci 익스프레스 강화 |
US20150222384A1 (en) * | 2014-02-03 | 2015-08-06 | Valens Semiconductor Ltd. | Changing receiver configuration by replacing certain idle words with bitwise complement words |
US9379739B2 (en) * | 2014-08-11 | 2016-06-28 | Qualcomm Incorporated | Devices and methods for data recovery of control channels in wireless communications |
US9842020B2 (en) | 2014-11-26 | 2017-12-12 | Qualcomm Incorporated | Multi-wire symbol transition clocking symbol error correction |
CN104767590A (zh) * | 2015-04-08 | 2015-07-08 | 江苏飞尚安全监测咨询有限公司 | 一种串行通信的可靠数据传输和控制方法 |
US9497020B1 (en) * | 2015-05-26 | 2016-11-15 | International Business Machines Corporation | Initializing a descrambler |
US9515813B1 (en) * | 2015-05-26 | 2016-12-06 | International Business Machines Corporation | Initializing a descrambler |
CN114726479A (zh) | 2017-07-18 | 2022-07-08 | 华为技术有限公司 | 一种检测块发送和接收的方法、网络设备和系统 |
WO2019015462A1 (zh) * | 2017-07-18 | 2019-01-24 | 华为技术有限公司 | 一种检测块发送和接收的方法、网络设备和系统 |
JP6552581B2 (ja) * | 2017-11-27 | 2019-07-31 | インテル・コーポレーション | 装置、方法、およびシステム |
CN108449162B (zh) * | 2018-03-15 | 2020-07-17 | 浙江工业大学 | 一种基于非前缀码的无线通信节能编码方法 |
US11159153B2 (en) | 2018-03-29 | 2021-10-26 | Nvidia Corp. | Data bus inversion (DBI) on pulse amplitude modulation (PAM) and reducing coupling and power noise on PAM-4 I/O |
US10599606B2 (en) | 2018-03-29 | 2020-03-24 | Nvidia Corp. | 424 encoding schemes to reduce coupling and power noise on PAM-4 data buses |
US11966348B2 (en) | 2019-01-28 | 2024-04-23 | Nvidia Corp. | Reducing coupling and power noise on PAM-4 I/O interface |
US10657094B2 (en) | 2018-03-29 | 2020-05-19 | Nvidia Corp. | Relaxed 433 encoding to reduce coupling and power noise on PAM-4 data buses |
US10606790B2 (en) | 2018-04-16 | 2020-03-31 | Intel Corporation | Precoding mechanism in PCI-express |
US10623200B2 (en) | 2018-07-20 | 2020-04-14 | Nvidia Corp. | Bus-invert coding with restricted hamming distance for multi-byte interfaces |
US11424905B1 (en) * | 2019-09-20 | 2022-08-23 | Astera Labs, Inc. | Retimer with mesochronous intra-lane path controllers |
JP7132964B2 (ja) * | 2020-03-25 | 2022-09-07 | アンリツ株式会社 | パターン同期回路、それを用いた誤り率測定装置、及びパターン同期方法 |
US12132590B2 (en) | 2022-03-18 | 2024-10-29 | Nvidia, Corp. | Hardware-efficient PAM-3 encoder and decoder |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6628725B1 (en) | 2001-03-28 | 2003-09-30 | Ciena Corporation | Method and system for encoding data for transmission over a serial link |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06244896A (ja) * | 1993-02-19 | 1994-09-02 | Canon Inc | シリアルデータ通信方式 |
KR0154010B1 (ko) * | 1995-03-16 | 1998-11-16 | 배순훈 | 가변길이 복호화 장치 |
KR100377441B1 (ko) * | 1999-01-19 | 2003-03-26 | 샤프 가부시키가이샤 | 전송방법 및 장치 |
US6650638B1 (en) * | 2000-03-06 | 2003-11-18 | Agilent Technologies, Inc. | Decoding method and decoder for 64b/66b coded packetized serial data |
US20020009089A1 (en) * | 2000-05-25 | 2002-01-24 | Mcwilliams Patrick | Method and apparatus for establishing frame synchronization in a communication system using an UTOPIA-LVDS bridge |
US7508800B1 (en) * | 2002-05-22 | 2009-03-24 | Cisco Technology, Inc. | Block code mapping system and method |
US7296211B2 (en) * | 2002-06-25 | 2007-11-13 | Lockheed Martin Corporation | System and method for transferring data on a data link |
JP4431113B2 (ja) * | 2003-11-14 | 2010-03-10 | 株式会社日立コミュニケーションテクノロジー | データ伝送方法及びデータ伝送装置 |
JP4256335B2 (ja) * | 2004-12-16 | 2009-04-22 | 株式会社ケンウッド | 無線通信システム、無線通信装置及び無線通信方法 |
US7081838B2 (en) * | 2004-12-29 | 2006-07-25 | Enigma Semiconductor, Inc. | 16b/10s coding apparatus and method |
KR20060081522A (ko) * | 2005-01-10 | 2006-07-13 | 삼성전자주식회사 | 피씨아이 익스프레스의 바이트 스큐 보상방법 및 이를위한 피씨아이 익스프레스 물리 계층 수신기 |
JP4419867B2 (ja) * | 2005-02-22 | 2010-02-24 | ソニー株式会社 | データ処理装置 |
US7813289B2 (en) * | 2006-02-02 | 2010-10-12 | Infineon Technologies Ag | Electrical idle detection circuit including input signal rectifier |
US7899111B2 (en) * | 2007-08-07 | 2011-03-01 | Intel Corporation | Link interface technique including data indicator symbols |
-
2008
- 2008-06-25 US US12/145,696 patent/US7769048B2/en not_active Expired - Fee Related
-
2009
- 2009-06-22 JP JP2009147787A patent/JP4981102B2/ja not_active Expired - Fee Related
- 2009-06-25 CN CN2009101398369A patent/CN101631000B/zh active Active
- 2009-06-25 DE DE102009061814.7A patent/DE102009061814B3/de active Active
- 2009-06-25 DE DE102009030545.9A patent/DE102009030545B4/de active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6628725B1 (en) | 2001-03-28 | 2003-09-30 | Ciena Corporation | Method and system for encoding data for transmission over a serial link |
Also Published As
Publication number | Publication date |
---|---|
JP2010011454A (ja) | 2010-01-14 |
US20090323722A1 (en) | 2009-12-31 |
US7769048B2 (en) | 2010-08-03 |
JP4981102B2 (ja) | 2012-07-18 |
DE102009030545B4 (de) | 2020-09-03 |
CN101631000A (zh) | 2010-01-20 |
CN101631000B (zh) | 2013-09-25 |
DE102009030545A1 (de) | 2010-01-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE102009061814B3 (de) | Verfahren, Sender, Empfänger und System für ein Paketisierungsschema auf Link- und Lane-Ebene für die Codierung in seriellen Links | |
DE3687792T2 (de) | Verfahren und system zum bearbeiten von uebertragungsfehlern. | |
EP3192219B1 (de) | Verfahren zur seriellen übertragung eines rahmens über ein bussystem von einem sender zu mindestens einem empfänger und teilnehmern eines bussystems | |
DE10393682B4 (de) | Verfahren zur Fehlerschutzcodierung und -decodierung von Nachrichten in einem Datenübertragungssystem mit Paketvermittlung | |
DE69626211T2 (de) | Blockkodierung für übertragung von digitalen videosignalen | |
DE60000912T2 (de) | Verfahren und Vorrichtung zur Datenkomprimierung von Netzwerkdatenpaketen unter Verwendung von paketweisen Hash Tabellen | |
DE19736434C2 (de) | Verfahren und Vorrichtungen zur Erkennung der Position von in einem seriellen Datenempfangsstrom liegenden Datenpaketen | |
US7296211B2 (en) | System and method for transferring data on a data link | |
DE102020101358A1 (de) | Selektive Echtzeit-Kryptographie in einem Fahrzeugkommunikationsnetz | |
DE2539109C2 (de) | Schaltungsanordnung zum Übertragen von digitalen Signalfolgen | |
DE112010002704T5 (de) | Mehrere Komprimierungstechniken für Informationen in Paketform | |
DE60307165T2 (de) | Verfahren zur Kodierung eines Benutzeridentifikator in einem Kommunikationssystem | |
EP1258085B1 (de) | Verfahren zum anpassen der einem turbo-codierer zuzuführenden datenblöcke und entsprechende kommunikationsvorrichtung | |
DE2602807C2 (de) | ||
DE112019001021T5 (de) | Verschlüsseln von nutzlast und präambel in 10spe mit synchroner und selbst-synchroner verschlüsselung | |
DE112013006339T5 (de) | Kompression hoher Bandbreite um Datenströme zu Verschlüsseln | |
DE102019003979B4 (de) | System und verfahren zum durchführen einer interpacket-gap-reparatur für verlustbehaftete protokolle | |
AT412933B (de) | Verfahren zur einseitig gerichteten und störungssicheren übertragung von digitalen daten über funkwellen sowie einrichtung zur durchführung des verfahrens | |
DE69934663T2 (de) | Serielles hochgeschwindigkeitsübertragungssystem | |
DE102014007820A1 (de) | Datenrahmen für geschützte Datenübertragungen | |
EP1469625B1 (de) | Verfahren und Vorrichtung zum Paket-orientierten Übertragen sicherheitsrelevanter Daten | |
Cheshire et al. | Consistent overhead byte stuffing | |
DE3502676C2 (de) | Verfahren zur Übertragung von digitalen Informationen | |
AfiqahAzahari et al. | Review of error detection of data link layer in computer network | |
DE69729433T2 (de) | Kodierte Modulation für Konstellationen, welche weniger Bits pro Symbol haben, als vom Kodierungsschema verlangt wird |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
R012 | Request for examination validly filed | ||
R129 | Divisional application from |
Ref document number: 102009030545 Country of ref document: DE |
|
R016 | Response to examination communication | ||
R018 | Grant decision by examination section/examining division | ||
R020 | Patent grant now final |