-
Die
vorliegende Erfindung bezieht sich auf Verfahren, ein computerlesbares
Medium und ein System zum Handhaben eines fehlgeschlagenen Verbindungstrainings
in einer Datenkommunikationsarchitektur, die einen Serialisierer
und einen Deserialisierer verwendet.
-
Rechenarchitekturen,
die effizient arbeiten und die Daten rasch verarbeiten können, wird
im allgemeinen der Vorrang vor ihren Gegenstücken gegeben. Die Geschwindigkeit,
mit der diese Rechenarchitekturen Daten verarbeiten, kann durch
eine Anzahl von Faktoren begrenzt sein, einschließlich des Entwurfs
der Architektur, der Betriebsbedingungen, der Qualität verwendeter
Komponenten sowie der Protokolle, Logik und Methodologien, die durch
die Rechnerarchitektur beim Verarbeiten von Daten verwendet werden.
Verzögerungszeiten
bei der Kommunikation von Daten über
Komponenten hinweg, die sich aus Datenkommunikationsarchitekturen
und Protokollen einer Rechenarchitektur ergeben, können die
Geschwindigkeit, mit der Daten verarbeitet werden können, ebenfalls
beeinflussen.
-
Derzeit
werden eine Anzahl von Datenkommunikationsarchitekturen eingesetzt,
um Daten zwischen kooperierenden bzw. zusammenwirkenden Komponenten
einer Rechnerarchitektur zu kommunizieren (z. B. Computerprozessoren
in der Verarbeitungseinheit einer Rechenumgebung oder zwischen einem
Computerprozessor und einer peripheren Komponente, wie z. B. einem
Datenspeicherlaufwerk). Beispielsweise sind sowohl IDE/ATA (Integrated
Drive Electronics/Advanced Technology Attachment) als auch SCSI
(Small Computer Systems Interface – Kleincomputer-Schnittstelle) übliche Schnittstellen
für Festplattenlaufwerke
(sowie manche andere Vorrichtungen, z. B. CD-ROM und DVD-Laufwerke),
und von jeder bzw. jedem gibt es mehrere Ausführungen. Andere Datenkommunikationsarchitekturen
umfassen PCI (Peripheral Components Interconnect), AGP (Accelerated
Graphics Port – AGP-Steckplatz),
USB (Universal Serial Bus – Universalserienbus),
serielle Datenkommunikationstore und parallele Datenkommunikationstore.
-
Obwohl
jede der oben erwähnten
Datenkommunikationsarchitekturen beim Übertragen von Daten zwischen
kooperierenden Komponenten effektiv ist, weist jede dieser Architekturen
Nachteile und Einschränkungen
der Leistungsfähigkeit
auf. Im Einzelnen sind derartige Datenkommunikationsarchitekturen
nicht entworfen, um große
Mengen an Datenkommunikationen, die bei hohen Taktfrequenzen (z. B.
mehreren Gigahertz) kommuniziert werden, zu handhaben. Ferner erfordern
die PCI-, IDE- und SCSI-Datenkommunikationsarchitekturen allgemein Mehraufwand-Bearbeitungsberechnungen,
wenn sie Daten kommunizieren, die die Gesamtgeschwindigkeit der
Datenkommunikationen beeinflussen. Anders gesagt müssen zusätzlich zu
den gewünschten Daten,
die kommuniziert werden, zusätzliche
Mehraufwand-Verarbeitungsdaten kommuniziert werden. Folglich werden
während
jedes Taktzyklus weniger Gesamtdaten verarbeitet.
-
Als
Antwort auf das Erfordernis von Datenkommunikationsarchitekturen
einer höheren
Bandbreite wurde die SERDES- Datenkommunikationsarchitektur
entwickelt (SERDES = serializer/deserializer, Parallel-Serien-Umsetzer/Serien-Parallel-Umsetzer).
SERDES fungiert dahingehend, Daten gemäß einem vordefinierten Schema
(z. B. Acht-Bit/Zehn-Bit-Codierung – 8b10b-Codierung)
zu codieren und decodieren. Die codierten Daten werden zum Decodieren
von dem Parallel-Serien-Umsetzer über einen
oder mehr Kommunikationskanäle an
einen entsprechenden Serien-Parallel-Umsetzer kommuniziert. Die
SERDES-Datenkommunikationsarchitektur erhöht erwiesenermaßen die
Datenkommunikationsbandbreite zwischen kooperierenden Komponenten.
In diesem Kontext werden SERDES-Datenkommunikationsarchitekturen
als Datenbusse eingesetzt, die arbeiten, um Daten zwischen kooperierenden
Komponenten zu transportieren.
-
Die
US 2003/0158992 A1 lehrt
eine allgemeine Eingabe/Ausgabe-Architektur, ein Eingabe/Ausgabe-Protokoll
und darauf bezogene Verfahren, um eine Flusssteuerung in einer Kommunikationsarchitektur
zu implementieren, die geeignet sind, um isochrone Datenströme zu handhaben,
beispielsweise Multimedia-Datenströme mit synchronisierten Audio- und
Video-Abschnitten. Diese Schrift offenbart eine Prozedur, um Kommunikationsverbindungen
neu zu trainieren, enthält
jedoch keinen Hinweis darauf, die Trainingsprozedur in dem Fall
einzustellen, dass ein erster Trainingsversuch fehlschlägt.
-
Die
US 2003/0145134 A1 lehrt
eine ähnliche allgemeine
Eingabe/Ausgabe-Architektur, ein entsprechendes Protokoll sowie
darauf bezogene Verfahren, um eine Flusssteuerung in einer Kommunikationsarchitektur
zu implementieren. Auch diese Schrift offenbart eine Prozedur zum
Neutrainieren von Kommunikationsverbindungen, enthält jedoch wiederum
keine Lehre hinsichtlich des Einstellens der Trainingsprozedur für den Fall,
dass ein erster Trainingsversuch fehlschlägt.
-
Die
US 2003/0120852 A1 offenbart
einen Port-Konfigurationsmechanismus
für eine
Port-Konfiguration und -Zuordnung und eine Nutzung gemeinsam verwendeter
Betriebsmittel, um Datenübertragungen
in einem Datennetzwerk zu handhaben. Der Mechanismus ermöglicht,
dass ein einzelner Port mehrere Port-Breitenkonfigurationen unterstützt, um eine
größere Verbindungsfreiheit
zu erreichen, und beinhaltet ein Port-Konfigurationstraining. Diese Schrift
erwähnt
ferner ein Training vom InfiniBand-Typ von Kommunikationsverbindungen.
-
Die
US 2002/0133762 A1 lehrt
Verfahren und Vorrichtungen für
eine Erfassung physikalischer Gleitfenster-Verbindungsfehler, zum Verfolgen des Auftretens
geringerer physikalischer Verbindungsfehler und zum Messen der momentanen
Netzwerkqualität.
Wenn zu viele Verbindungsfehler auftreten, werden die Verbindungen
neu trainiert.
-
Die
Aufgabe der vorliegenden Erfindung besteht darin, Verfahren, ein
computerlesbares Medium und ein System zum Handhaben eines fehlgeschlagenen
Verbindungstrainings mit verbesserten Charakteristika zu schaffen.
-
Diese
Aufgabe wird durch Verfahren gemäß Anspruch
1 oder 17, ein computerlesbares Medium gemäß Anspruch 8 und ein System
gemäß Anspruch 9
gelöst.
-
Es
wird eine Datenkommunikationsarchitektur bereitgestellt, die Parallel-Serien-Umsetzer
und Serien-Parallel-Umsetzer zur Verwendung beim Kommunizieren von
Daten zwischen Computerverarbeitungskomponenten einer Rechenumgebung
verwendet, um die Verzögerungszeit
zu verringern. Bei einer veranschaulichenden Implementierung umfasst eine
Datenkommunikationsarchitektur eine Datenschnittstelle, einen Parallel-Serien-Umsetzer und
einen Serien-Parallel-Umsetzer. Im Betrieb werden Daten von Computerverarbeitungskomponenten durch
den Parallel-Serien-Umsetzer empfangen. Der Parallel-Serien-Umsetzer,
der mit der Datenschnittstelle zusammenar beitet, codiert die Daten
für eine Kommunikation
an den Serien-Parallel-Umsetzer gemäß einem ausgewählten Codie rungsprotokoll.
Betriebsmäßig arbeiten
der Parallel-Serien-Umsetzer und
der Serien-Parallel-Umsetzer (SERDES) zusammen, um eine Kommunikationsverbindung
oder einen Kommunikationskanal zu bilden. Die Datenschnittstelle
ermöglicht
unter anderem die Sammlung von Daten, die von jedem Ende der Verbindung über die
Verbindung transferiert werden sollen, liefert eine Verbindungsverwaltung
und Steuerinformationen, codiert einen Fehlerschutz und liefert
eine Logik zum Verarbeiten der Daten über den Kommunikationskanal
hinweg.
-
Bezug
nehmend auf die beispielhafte Implementierung umfasst die veranschaulichende
Datenkommunikationsarchitektur ferner eine Verbindungstrainingsstatusüberwachungseinrichtung,
ein Verbindungstrainingsmodul, ein Überwachungsmodul, einen Datenpuffer,
ein Verbindungstrainingsmodul, ein Paritätsbitmodul, ein Datenübertragungsquittungsmodul
und einen Datenpuffer. Diese Module umfassen einen Abschnitt des
Parallel-Serien-Umsetzers und des Serien-Parallel-Umsetzers. Im Betrieb
arbeiten diese Module mit der Datenschnittstelle und Anweisungssätzen, die
in dem Parallel-Serien-Umsetzer
und Serien-Parallel-Umsetzer enthalten sind, zusammen, um Funktionen
zu verwirklichen, die folgende umfassen, aber nicht auf diese beschränkt sind:
Handhaben ungewisser Datenankunftszeiten, Erfassung von Einbit- und Mehrbitfehlern,
Handhaben von Kommunikationsverbindungsausfällen, Adressieren eines Trainings
ausgefallener Verbindungen, Identifizieren und Markieren von Daten
als verfälscht
sowie Identifizieren und Verarbeiten erfolgreicher Datentransaktionen über die Kommunikationsverbindung.
-
Andere
Merkmale der Erfindung werden nachfolgend beschrieben.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf
die beiliegenden Zeichnungen näher
erläutert.
Es zeigen:
-
1 ein
Blockdiagramm einer exemplarischen Rechenumgebung gemäß einer
Implementierung der hierin beschriebenen Systeme und Verfahren;
-
2 ein
Blockdiagramm, das die Zusammenwirkung exemplarischer Komponenten
einer exemplarischen Datenkommunikationsarchitektur zeigt;
-
3 ein
Blockdiagramm eines Sendekerns gemäß einer exemplarischen Implementierung
einer Datenkommunikationsarchitektur;
-
4 ein
Blockdiagramm eines Empfangskerns gemäß einer exemplarischen Implementierung einer
Datenkommunikationsarchitektur;
-
5 ein
Flussdiagramm, das die Verarbeitung zeigt, die durch eine exemplarische
Datenkommunikationsarchitektur beim Kommunizieren von Daten durchgeführt wird;
-
6 ein
Flussdiagramm, das die Verarbeitung zeigt, die durch eine exemplarische
Datenkommunikationsarchitektur beim Handhaben einer ungewissen Datenankunft
durchgeführt
wird;
-
7 ein
Flussdiagramm, das die Verarbeitung zeigt, die durch eine exemplarische
Datenkommunikationsarchitektur beim Erfassen von Bitfehlern in Datenkommunikationen
durchgeführt
wird;
-
8 ein
Flussdiagramm, das die Verarbeitung zeigt, die durch eine exemplarische
Datenkommunikationsarchitektur beim Adressieren eines Verbindungsausfalls
durchgeführt
wird;
-
9 ein
Flussdiagramm, das die Verarbeitung zeigt, die durch eine exemplarische
Datenkommunikations architektur beim Adressieren eines Verbindungsausfalltrainings
durchgeführt
wird;
-
10 ein
Flussdiagramm, das die Verarbeitung zeigt, die durch eine exemplarische
Datenkommunikationsarchitektur beim Adressieren verfälschter
Daten durchgeführt
wird;
-
11 ein
Flussdiagramm, das die Verarbeitung zeigt, die durch eine exemplarische
Datenkommunikationsarchitektur beim Handhaben einer Fehlererfassung
durchgeführt
wird; und
-
12 ein
Flussdiagramm, das die Verarbeitung zeigt, die durch eine exemplarische
Datenkommunikationsarchitektur durchgeführt wird, um erfolgreiche Datenkommunikationen
zu quittieren.
-
Übersicht:
-
Um
die bei Rechenumgebungen erforderliche Infrastrukturbandbreite bereitzustellen,
wandten sich Implementierungen einer Verwendung von bei hohen Frequenzen
arbeitenden SERDES-Punkt-zu-Punkt-Datenkommunikationsarchitekturen
zu. Beim Anwenden der SERDES-Datenkommunikationsarchitektur auf
die interne Datenkommunikationsinfrastruktur einer Rechenumgebung
kommen eine Anzahl von Einschränkungen
ans Licht. Allgemein ausgedrückt
ergibt sich eine Verzögerungszeit
bei Datenkommunikationen aus einer ineffizienten Verwaltung der
Datenkommunikationsarchitektur. Die Verwaltung der SERDES-Datenkommunikationsarchitektur
kann durch eine Datenschnittstelle erfolgen, die unter anderem Daten
zum Kommunizieren entlang der SERDES-Kommunikationsverbindungen
zusammenträgt
und Fehlererfassungs- und Handhabungsanweisungen für Fehlerdaten
liefert.
-
Die
vorliegende Erfindung liefert eine Datenschnittstelle zur Verwendung
durch SERDES-Verbindungskanäle,
die Operationen unterstützen,
die auf bidirektionale Weise zwischen Datenkommunikationsarchitekturkomponenten
erfolgen. Bei einer veranschaulichenden Implementierung ist ein
Mechanismus vorgesehen, um Daten für einen Transfer über eine
SERDES-Verbindung von jedem Ende der Verbindung zusammenzutragen.
Zusätzlich
kann der Mechanismus arbeiten, um Überlagerungsverbindungsverwaltungsinformationen
zu liefern, einen Fehlerschutz zu codieren und Daten zu dem richtigen Format
zu codieren. Die Datenschnittstelle der hierin beschriebenen veranschaulichenden
Implementierung unterhält
ferner eine Logik, die annimmt/akzeptiert, SERDES-Komponenten anzuleiten,
Daten zusammenzutragen und zwischen SERDES-Verbindungskomponenten
zu kommunizieren sowie zu prüfen,
dass diese Daten korrekt zusammengetragen und kommuniziert werden.
-
Die
veranschaulichende SERDES-Datenkommunikationsarchitektur kann auch
einen Datenpuffer verwenden, um Daten zu speichern. Im Betrieb kann
der Datenpuffer verwendet werden, um Daten zu speichern, bis ein
korrekter Empfang durch eine Antwort von dem Empfangsende einer
SERDES-Kommunikationsverbindung
bestätigt
wird. In einem derartigen Fall kann eine Quittung als Bestandteil
von Daten eingebettet sein, die zwischen zusammenwirkenden Komponenten
der SERDES-Datenkommunikationsarchitektur kommuniziert werden. Wenn
durch die SERDES-Komponenten ein Fehler erfasst wird, kann der Datenpuffer
verwendet werden, um die Daten erneut zu senden, um den Fehler zu
korrigieren.
-
Ferner
kann die veranschaulichende Implementierung die Verwendung mehrerer
paralleler SERDES-Kommunikationskanäle aufeinander abstimmen. Ein
SERDES-Kommunikationskanal kann eine logische Kommunikationsverbindung
umfassen, die auf einer physischen Verbindung (z. B. Drähten) zwischen
SERDES-Komponenten (z. B. Parallel-Serien-Umsetzern und Serien-Parallel-Umsetzern)
arbeitet. Beim Durchführen
einer Fehlererfassung, eines Trainings und anderer Operationen kann
die veranschaulichende SERDES-Datenkommunikationsarchitektur einen
Ersatzkanal verwenden. Zusätzlich kann
ein derartiger Ersatzkanal verwendet werden, um auch im Fall eines
maschinenbedingten Fehlers einer der Kanäle eine Kommunikationsverfügbarkeit aufrechtzuerhalten.
-
Die
veranschaulichende Implementierung liefert die Flexibilität, verschiedene
Medien – Kabel, PC-Bahn
oder durch eine entsprechende Pufferfaser anzutreiben, und unterstützt eine
Vielzahl von Verbindungsfrequenzen, um am besten mit den gewählten Medien
zu arbeiten.
-
Veranschaulichende Rechenumgebung:
-
1 zeigt
ein exemplarisches Rechensystem 100 gemäß hierin beschriebenen Systemen
und Verfahren. Das Rechensystem 100 ist in der Lage, eine
Vielzahl von Rechenanwendungen 180 auszuführen. Das
beispielhafte Rechensystem 100 wird vorwiegend durch computerlesbare
Anweisungen gesteuert, die in Form von Software vorliegen können, wo
und wie eine derartige Software gespeichert oder auf dieselbe zugegriffen
wird. Eine derartige Software kann in einer Zentralverarbeitungseinheit (CPU) 110 ausgeführt werden,
um das Datenverarbeitungssystem 100 zu veranlassen, zu
arbeiten. Bei vielen bekannten Computerservern, Arbeitsstationen und
Personalcomputern ist die Zentralverarbeitungseinheit 110 durch
CPUs in Form mikroelektronischer Chips implementiert, die als Mikroprozessoren
bezeichnet werden. Der Koprozessor 115 ist ein optionaler
Prozessor, der von der CPU 110 getrennt ist und der zusätzliche
Funktionen erfüllt
oder die CPU 110 unterstützt. Ein üblicher Typ von Koprozessor
ist der Gleitkomma-Koprozessor, der auch als numerischer oder mathematischer
Koprozessor bezeichnet wird und der entworfen ist, um numerische
Berechnungen schneller und besser durchzuführen als eine Mehrzweck-CPU 110.
-
Man
wird erkennen, dass, obwohl eine veranschaulichende Rechenumgebung
in der Darstellung eine einzige CPU 110 umfasst, diese
Beschreibung lediglich veranschaulichend ist, da die Rechenumgebung 100 eine
Anzahl von CPUs 110 umfassen kann. Ferner kann die Rechenumgebung 100 die Ressourcen
entfernter CPUs (nicht gezeigt) durch ein Kommunikationsnetzwerk 160 oder
eine andere (nicht gezeigte) Datenkommunikationseinrichtung nutzen.
-
Im
Betrieb ruft die CPU 110 Anweisungen ab, decodiert sie
und führt
sie aus und überträgt Informationen
an und von anderen Ressourcen über
den Hauptdatentransferpfad des Computers, einen Systembus 105.
Ein derartiger Systembus verbindet die Komponenten in dem Rechensystem 100 und
definiert das Medium für
einen Datenaustausch. Der Systembus 105 umfasst üblicherweise
Datenleitungen zum Senden von Daten, Adressleitungen zum Senden
von Adressen und Steuerleitungen zum Senden von Unterbrechungen
und zum Betreiben des Systembusses. Ein Beispiel eines derartigen
Systembusses ist der PCI-Bus (PCI = Peripheral Component Interconnect).
Manche der heutigen höherentwickelten
Busse liefern eine Funktion, die als Busentscheidung bezeichnet
wird und die einen Zugriff auf den Bus durch Erweiterungskarten,
Steuerungen und die CPU 110 regelt. Vorrichtungen, die
an diese Busse angeschlossen werden und entscheiden, den Bus zu übernehmen,
werden als Busmaster bezeichnet. Eine Busmasterunterstützung ermöglicht ferner,
dass Multiprozessorkonfigurationen der Busse durch die Hinzufügung von
Busmasteradaptern, die einen Prozessor und seine Unterstützungschips
enthalten, erzeugt werden.
-
Speichervorrichtungen,
die mit dem Systembus 105 gekoppelt sind, umfassen einen
Direktzugriffsspeicher (RAM) 125 und einen Nur-Lese-Speicher
(ROM) 130. Derartige Speicher umfassen eine Schaltungsanordnung,
die ermöglicht,
dass Informationen gespeichert und wiedergewonnen werden. Die ROMs 130 enthalten
allgemein gespeicherte Daten und können nicht modifiziert werden.
Daten, die in einem RAM 125 gespeichert sind, können durch
die CPU 110 oder andere Hardwarevorrichtungen gelesen oder
geändert
werden. Ein Zugriff auf einen RAM 125 und/oder ROM 130 kann
durch eine Speichersteuerung 120 gesteuert werden. Die
Speichersteuerung 120 kann ferner eine Adressübersetzungsfunktion
bereitstellen, die virtuelle Adressen in physische Adressen übersetzt,
während
Anweisungen ausgeführt
werden. Die Speichersteuerung 120 kann auch eine Speicherschutzfunktion
bereitstellen, die Prozesse innerhalb des Systems isoliert und Systemprozesse
von Benutzerprozessen isoliert. Somit kann ein Programm, das in
einem Benutzermodus läuft, normalerweise
lediglich auf einen Speicher zugreifen, der durch den virtuellen
Adressraum seines eigenen Prozesses abgebildet ist; es kann nicht
auf einen Speicher in einem virtuellen Adressraum eines anderen
Prozesses zugreifen, es sei denn, es wurde eine gemeinsame Verwendung
des Speichers zwischen den Prozessen eingerichtet.
-
Ferner
kann das Rechensystem 100 eine Peripheriegeräte-Steuerung 135 enthalten,
die für ein
Kommunizieren von Anweisungen von der CPU 110 an Peripheriegeräte, z. B.
einen Drucker 140, eine Tastatur 145, eine Maus 150 und
ein Datenspeicherlaufwerk 155, verantwortlich ist.
-
Eine
Anzeige 165, die durch die Anzeigesteuerung 163 gesteuert
wird, wird verwendet, um eine durch das Rechensystem 100 erzeugte
visuelle Ausgabe anzuzeigen. Eine derartige visuelle Ausgabe kann
Text, Graphiken, animierte Graphiken und Video umfassen. Die Anzeige 165 kann
mit einer CRT-basierten
Videoanzeige, einer LCD-basierten Flachbildschirmanzeige, einer
gasplasmabasierten Flachbildschirmanzeige oder einem Berührungsbildschirm
oder anderen Anzeigeformen implementiert sein. Die Anzeigesteuerung 163 umfasst
elektronische Komponenten, die erforderlich sind, um ein Videosignal
zu erzeugen, das an die Anzeige 165 gesendet wird.
-
Ferner
kann das Rechensystem 100 einen Netzwerkadapter 170 enthalten,
der verwendet werden kann, um das Rechensystem 100 mit
einem externen Kommunikationsnetzwerk 160 zu verbinden. Das
Kommunikationsnetzwerk 160 kann Computerbenutzern Einrichtungen
zum elektronischen Kommunizieren und Übertragen von Software und
Informationen bereitstellen. Ferner kann das Kommunikationsnetzwerk 185 eine
verteilte Verarbeitung bereitstellen, die mehrere Computer und das
Teilen von Arbeitslasten oder kooperativen Bemühungen beim Ausführen einer
Aufgabe beinhaltet. Man wird erkennen, dass die gezeigten Netzwerkverbindungen
exemplarisch sind und dass andere Mittel zum Einrichten einer Kommunikationsverbindung
zwischen den Computern verwendet werden können.
-
Man
wird erkennen, dass das exemplarische Computersystem 100 lediglich
veranschaulichend für eine
Rechenumgebung ist, in der die hierin beschriebenen Systeme und
Verfahren arbeiten können,
und dass es die Implementierung der hierin beschriebenen Systeme
und Verfahren in Rechenumgebungen nicht einschränkt, die unterschiedliche Komponenten und
Konfigurationen aufweisen, da die hierin beschriebenen erfindungsgemäßen Konzepte
in verschiedenen Rechenumgebungen, die verschiedene Komponenten
und Konfigurationen aufweisen, implementiert sein können.
-
Datenkommunikationsarchitektur:
-
2–4 zeigen
Blockdiagramme einer veranschaulichenden Datenkommunikationsarchitektur
zur Verwendung bei einer exemplarischen Rechenumgebung. Die veranschaulichende
Datenkommunikationsarchitektur kann als Komponenten der Rechenumgebung
implementiert sein und kann SERDES-Komponenten verwenden. Im einzelnen zeigt 2 ein
Blockdiagramm einer veranschaulichenden Datenkommunikationsarchitektur 200.
Wie in 2 gezeigt ist, umfasst die Datenkommunikationsarchitektur 200 Datenkommunikationsschnittstellenkarten 205 und 210,
die zusammenwirken, um Daten 230 über physische Verbindungen 220 zu
kommunizieren. Die Datenkommunikationsschnittstellenkarten 205 und 210 umfassen
zumindest einen Sendekern und zumindest einen Empfangskern. Physische
Verbindungen 220 werden durch physische Verbinder 225 an
die Datenkommunikationsschnittstellenkarten 205 und 210 angeschlossen.
-
Im
Betrieb arbeitet die (nicht gezeigte) exemplarische Rechenumgebung
mit den Datenkommunikationsschnittstellenkarten 205 und 210 zusammen, um
Daten zwischen den Datenkommunikationsschnittstellenkarten 205 und 210 zu
kommunizieren. Bei der veranschaulichenden Implementierung können Datenkommunikationsschnittstellenkarten
in getrennten geographischen Positionen in der (nicht gezeigten)
exemplarischen Rechenumgebung vorliegen oder können als Bestandteil einer
der gedruckten Schaltungsplatinen (PCB – printed circuit boards) der (nicht
gezeigten) exemplarischen Rechenumgebung vorliegen. Wie gezeigt
ist, können
Daten in einer ausgewählten
Richtung oder bidirektional, wie durch die Pfeile auf den physischen
Verbindungen 220 und Daten 230 angegeben ist,
zwischen Sendekernen und Empfangskernen der Datenkommunikationsschnittstellen 205 und 210 kommuniziert
werden. Ferner wird man erkennen, dass die physischen Verbindungen 220 mit
verschiedenen Leitungsdicken gezeigt sind, um unterschiedliche Medien
der physischen Verbindung 220 anzugeben.
-
Wie
gezeigt ist, zeigt das gestrichelte Kästchen 215 ferner
die Komponenten einer exemplarischen Datenkommunikationsrückwandplatine.
Bei der bereitgestellten Implementierung weist die Rückwandplatine 215 in
der Darstellung ein Paar von Sende-/Empfangskernen auf, die arbeiten,
um Daten zu kommunizieren. Im einzelnen werden Daten durch den Sendekern 235 der
Datenkommunikationsschnittstelle 205 für eine Kommunikation durch
den physischen Verbinder 225 und die physischen Verbindungen 220 an
den Empfangskern 245 der Datenkommunikationsschnittstelle 210 verarbeitet.
Desgleichen können
Daten für
eine Kommunikation durch den Sende kern 250 der Datenkommunikationsschnittstelle 210 an
den Empfangskern 240 der Datenkommunikationsschnittstelle 205 verarbeitet werden. Überdies
können
Sende-/Empfangskernpaare 235, 240 und 245, 250 zusammenwirken,
um einen Kommunikationskanal zu bilden. Als Kommunikationskanal
können
die Sende-/Empfangskernpaare ausgerichtet und trainiert werden,
um Daten gemäß einem
ausgewählten
Codierungsprotokoll, z. B. einer Acht-Bit-Zehn-Bit-Codierung (8b10b-Codierung),
zu verarbeiten.
-
Wie
in 2 gezeigt ist, können die Daten 230 ferner
eine Anzahl von Paketen umfassen. Im einzelnen können die Daten 230 einen
Anfangsblockabschnitt und einen Datenpaketabschnitt enthalten. Der
Datenpaketabschnitt kann ferner kleine Datenpakete enthalten. Man
wird erkennen, dass bei der bereitgestellten veranschaulichenden
Implementierung als ein kleines Paket ein Datenpaket angesehen werden
kann, das eine geringere Größe aufweist als
ein normales Datenpaket einer vollen Größe. Im Betrieb können diverse
Daten-, Steuer-, Trainings- und Kanalverwaltungsinformationen als
Daten 230 über
die exemplarische Datenkommunikationsarchitektur 200 kommuniziert
werden.
-
3 zeigt
ein Blockdiagramm einer exemplarischen Sendekernumgebung 300,
das ihre Komponenten und deren Zusammenwirkung zeigt. Wie in 3 gezeigt
ist, umfasst die exemplarische Sendekernumgebung 300 eine
Mehrzahl von Sendekernen, die von dem Sendekern 300-1 zu
dem Sendekern 300-n reichen. Der Sendekern 300-1 weist
in der Darstellung einen Logikblock einer Mehrzahl von Parallel-Serien-Umsetzern und Treibern
von dem Parallel-Serien-Umsetzer 1 zu dem Parallel-Serien-Umsetzer
n bzw. von dem Treiber 1 zu dem Treiber n auf. Ferner wirkt der
Sendekern 300-1 mit einer (nicht gezeigten) externen Datenkommunikationskomponente
zusammen, um ein Taktsignal CLK zu erhalten. Ferner umfasst der
Sendekern 300-1, wie gezeigt, eine Logik, die Anweisungssätze unterhält, um die Komponenten
des Sendekerns 300-1 (z. B. Parallel-Serien-Umsetzer 1)
anzuweisen, Funktionen gemäß Datenkommunikationsoperationen
auszuführen.
Die Logik des Sendekerns 300-1 kann ferner agieren, um
ein(en) oder mehr Module und Mechanismen zur Verwendung während Datenkommunikationsoperationen
zu unterhalten, einschließlich,
aber nicht ausschließlich,
einer Verbindungstrainingsstatusüberwachungseinrichtung,
eines Verbindungstrainingsmoduls, eines Überwachungsmoduls, eines Datenpuffers,
eines Verbindungstrainingsmoduls, eines Paritätsbitmoduls und eines Datenübertragungsquittungsmoduls.
-
Im
Betrieb werden Daten als Eingabe einem der Parallel-Serien-Umsetzer des
Sendekerns 300-1 bereitgestellt. Die Daten werden gemäß einem
ausgewählten
Codierungsprotokoll codiert und auf eine Kommunikation durch einen
der Treiber des Sendekerns an eine kooperierende Datenkommunikationskomponente
an einem der Ausgangskanäle
des Sendekerns vorbereitet. Das Codierungsprotokoll kann ein CLK-Signal
verwenden, um eine Anzahl von Bits in einem ausgewählten Zyklus
bzw. in ausgewählten Zyklen
des CLK-Signals zu codieren. Beispielsweise können Daten A durch den Parallel-Serien-Umsetzer 1
des Sendekerns 300-1 gemäß einem ausgewählten Codierungsprotokoll
codiert und auf eine Kommunikation durch den Treiber 1 vorbereitet
werden, um gemäß Anweisungen,
die durch die Logik des Sendekerns 300-1 bereitgestellt
werden, an dem Ausgang des Kanals A Codierte Daten zu erzeugen. Desgleichen
können
Daten B durch den Parallel-Serien-Umsetzer 2 des Sendekerns 300-1 gemäß einem
ausgewählten
Codierungsprotokoll codiert und auf eine Kommunikation durch einen
Treiber 2 vorbereitet werden, um an dem Kanal B Codierte Daten zu erzeugen.
Ein derartiger Codierungsprozess und eine derartige Datenkommunikationsvorbereitung wird über die
verbleibenden Parallel-Serien-Umsetzer
und Treiber des Sendekerns 300-1 und der anderen Sendekerne
der Sendekernumgebung 300 durchgeführt.
-
4 zeigt
ein Blockdiagramm einer exemplarischen Empfangskernumgebung 400,
das ihre Komponenten und deren Zusammenwirkung zeigt. Wie in 4 gezeigt
ist, umfasst der exemplarische Empfangskern 400 eine Mehrzahl
von Empfangskernen, die von dem Empfangskern 400-1 zu dem
Empfangskern 400-n reichen. Der Empfangskern 400-1 weist
in der Darstellung einen Logikblock einer Mehrzahl von Serien-Parallel-Umsetzern
und Treibern von dem Serien-Parallel-Umsetzer 1 zu dem Serien-Parallel-Umsetzer
n bzw. von dem Treiber 1 zu dem Treiber n auf. Ferner wirkt der
Empfangskern 400-1 mit einer (nicht gezeigten) externen
Datenkommunikationskomponente zusammen, um ein Taktsignal CLK zu
erhalten. Ferner umfasst der Empfangskern 400-1, wie gezeigt,
eine Logik, die Anweisungssätze unterhält, um die
Komponenten des Empfangskerns 400-1 (z. B. Serien-Parallel-Umsetzer 1) anzuweisen,
Funktionen gemäß Datenkommunikationsoperationen
auszuführen.
Die Logik des Empfangskerns 400-1 kann ferner agieren,
um ein(en) oder mehr Module und Mechanismen zur Verwendung während Datenkommunikationsoperationen
zu unterhalten, einschließlich,
aber nicht ausschließlich,
einer Verbindungstrainingsstatusüberwachungseinrichtung,
eines Verbindungstrainingsmoduls, eines Überwachungsmoduls, eines Datenpuffers,
eines Verbindungstrainingsmoduls, eines Paritätsbitmoduls und eines Datenübertragungsquittungsmoduls.
-
Im
Betrieb werden codierte Daten als Eingabe einem der Serien-Parallel-Umsetzer
des Empfangskerns 400-1 bereitgestellt. Die Daten werden gemäß einem
ausgewählten
Decodierungsprotokoll decodiert und auf eine Kommunikation durch
einen der Treiber des Empfangskerns an eine kooperierende Datenkommunikationskomponente
an einem der Ausgänge
des Serien-Parallel-Umsetzers des Empfangskerns vorbereitet. Das
Decodierungsprotokoll kann ein CLK-Signal verwenden, um eine Anzahl
von Bits in einem ausgewählten
Zyklus bzw. in ausgewählten
Zyklen des CLK-Signals zu decodieren. Beispielsweise können Codierte
Daten A durch den Serien-Parallel-Umsetzer
1 des Empfangskerns 400-1 gemäß einem ausgewählten Decodierungsprotokoll decodiert
und auf eine Kommunikation durch den Treiber 1 vorbereitet werden,
um gemäß Anweisungen,
die durch die Logik des Empfangskerns 400-1 bereitgestellt
werden, Daten A zu erzeugen. Desgleichen können Daten B durch den Serien-Parallel-Umsetzer
2 des Empfangskerns 400-1 gemäß einem ausgewählten Decodierungsprotokoll
decodiert und auf eine Kommunikation durch den Treiber 2 vorbereitet
werden, um Daten B zu erzeugen. Ein derartiger Decodierungsprozess
und eine derartige Datenkommunikationsvorbereitung wird über die
verbleibenden Serien-Parallel-Umsetzer und Treiber des Empfangskerns 400-1 und der anderen
Empfangskerne der Sendekernumgebung 400 durchgeführt.
-
Zusammengenommen
beschreiben 3 und 4 eine exemplarische
Kommunikationskanalumgebung, derart, dass Daten für eine Kommunikation
durch einen oder mehr Sendekerne zum Decodieren und anschließenden Verarbeiten
durch einen oder mehr Empfangskerne codiert werden. Obwohl die Sendekerne
und Empfangskerne als separate Komponenten beschrieben wurden, wird
man erkennen, dass sich dieselben auf einer einzigen Kommunikationskomponente
befinden können
(siehe Datenkommunikationsschnittstelle 205 der 2). Überdies
können
Sendekerne und Empfangskerne als Paare arbeiten, um einen oder mehr
bidirektionale Datenkommunikationskanäle zu bilden.
-
Kommunizieren von Daten über Kommunikationsverbindungen:
-
5 zeigt
die Verarbeitung, die durch die exemplarische Datenkommunikationsarchitektur 200 beim
Einrichten eines Kommunikationskanals durchgeführt wird. Wie gezeigt ist,
beginnt die Verarbeitung bei Block 500 und geht zu Block 505 über, wo
die Kommunikationskomponenten für
den Betrieb eingeschaltet werden. Von dort geht die Verarbeitung
zu Block 510 über,
wo zwischen den Datenkommunikationsarchitekturkomponenten Kommunikationsverbindungen
eingerichtet werden. Bei Block 515 werden die Kommunikationsverbindungen
anschließend trainiert,
einen Kommunikationskanal zu bil den. Bei Block 520 werden
dann Trainingsdaten über
den Kommunikationskanal gesendet, um den Kommunikationskanal zu
testen. Bei Block 525 wird dann eine Prüfung durchgeführt, um
zu bestimmen, ob der Kommunikationskanaltest erfolgreich war. Wenn
er erfolgreich war, geht die Verarbeitung zu Block 540 über, wo
eine Prüfung
durchgeführt
wird, um zu bestimmen, ob Daten über
den erfolgreich getesteten Kommunikationskanal kommuniziert werden
sollen. Falls bei Block 540 bestimmt wird, dass keine Daten kommuniziert
werden sollen, kehrt die Verarbeitung zu Block 525 zurück. Falls
jedoch Daten über
den erfolgreich getesteten und trainierten Kommunikationskanal kommuniziert
werden sollen, geht die Verarbeitung zu Block 545 über, wo
die Daten durch Parallel-Serien-Umsetzer codiert werden. Bei Block 550 werden
die codierten Daten dann über
den Kommunikationskanal an kooperierende Serien-Parallel-Umsetzer
kommuniziert. Bei Block 555 werden die Daten dann durch
die Serien-Parallel-Umsetzer
decodiert. Bei Block 560 wird dann eine Prüfung durchgeführt, um
zu bestimmen, ob die Daten erfolgreich kommuniziert wurden. Falls
die Daten erfolgreich gesendet wurden, kehrt die Verarbeitung zu
Block 540 zurück und
fährt von
dort aus fort. Wenn die Daten jedoch nicht erfolgreich kommuniziert
wurden, geht die Verarbeitung zu Block 565 über, wo
die Serien-Parallel-Umsetzer anfordern, dass die Daten durch die
Parallel-Serien-Umsetzer erneut gesendet werden. Von dort kehrt
die Verarbeitung zu Block 550 zurück und fährt von dort aus fort.
-
Falls
jedoch bei Block 525 bestimmt wird, dass der Kommunikationskanaltest
nicht erfolgreich war, geht die Verarbeitung zu Block 530 über, wo
die Kommunikationsverbindungen erneut trainiert werden. Von dort
geht die Verarbeitung zu Block 535 über, wo Steuerinformationen
zwischen den Kommunikationsverbindungskomponenten kommuniziert werden.
Von dort kehrt die Verarbeitung zu Block 520 zurück und fährt von
dort aus fort.
-
Im
Betrieb sieht die veranschaulichende Implementierung vor, dass die
Trainingssequenz durch die Serien-Parallel-Umsetzer eine Kommunikationsverbindung
gelenkt wird. Im Einzelnen wird ein anfängliches Training auf ein Erkennen
einer Angabe der Aufschrift eines ausgewählten Registers vom Softwaretyp
auf dem Serien-Parallel-Umsetzer hin als abgeschlossen erachtet.
Zu einem solchen Zeitpunkt werden Daten durch die Parallel-Serien-Umsetzer
des Kommunikationskanals auf die Verbindung getrieben. Im Kontext
von Serien-Parallel-Umsetzer-Operationen unterhalten die Serien-Parallel-Umsetzer
einen oder mehr Anweisungssätze,
die die Serien-Parallel-Umsetzer anweisen, eine Aktivität auf der
Verbindung zu erfassen, um kooperierenden Parallel-Serien-Umsetzern
zu signalisieren, die Initialisierung zu beginnen. Die Serien-Parallel-Umsetzer und
Parallel-Serien-Umsetzer
der Kommunikationskanäle
unterhalten zumindest einen Anweisungssatz, um die Kanäle anzuweisen,
eine Einschaltung vorzunehmen. Nach einer erfolgreichen Einschaltung wird
ein Pro-Kanal-Selbsttest durchgeführt, dessen Ergebnisse zusammengetragen
und verglichen werden. Der Anweisungssatz weist die Parallel-Serien-Umsetzer
und Serien-Parallel-Umsetzer anschließend an, ein ausgewähltes Datenmuster
zu kommunizieren, das durch die Serien-Parallel-Umsetzer erwartet wird und
das es den Serien-Parallel-Umsetzern
ermöglicht,
eine Biteinheiten-Gruppierung
zur Verwendung durch die Codierungs- und Decodierungsprotokolle,
die durch die Parallel-Serien-Umsetzer und die Serien-Parallel-Umsetzer
verwendet werden, zu bestimmen.
-
Zusätzlich wird
ein zweites erkennbares Datenmuster an die Serien-Parallel-Umsetzer
kommuniziert, das die Serien-Parallel-Umsetzer
als die Kleinpaketdatenkommunikationen zuweisen. Durch Einstellen
der Kleinpaketdatenkommunikationen können die Serien-Parallel-Umsetzer
arbeiten, um kleine Pakete in Gruppierungen übereinstimmend damit, wie sie
ursprünglich
kommuniziert wurden, passend zusammenzustellen. Nachdem das zweite Datenmuster
erfolgreich kommuni ziert und verarbeitet wurde, wird ein Steuersignal
von den Serien-Parallel-Umsetzern an die Parallel-Serien-Umsetzer
der Kommunikationsverbindungen gesendet, das angibt, dass das Training
abgeschlossen ist. An diesem Punkt können Datenpakete über die
trainierten Kanäle
kommuniziert werden.
-
Ferner
sieht die veranschaulichende Implementierung vor, dass, falls ein
Fehler über
die Kommunikationsverbindung auftreten sollte, die Verbindung einen
Neutrainingsprozess durchführen
kann. Ein Verbindungsneutraining ist ähnlich dem oben beschriebenen
Verbindungstraining, mit Ausnahme eines Verzichts des Einschaltens
der Kommunikationskanalkomponenten. Ein Neutraining kann durch eine Anzahl
von Ereignissen ausgelöst
werden, einschließlich,
aber nicht ausschließlich,
des Erkennens eines Fehlers über
die Kommunikationsverbindung oder durch den Empfang eines Fehlersignals
auf der Verbindung, das durch das Empfangsende der Kommunikationsverbindung
erzeugt wird.
-
Handhaben von Datenkommunikationslücken (Datenankunftszeitgebung):
-
Die
veranschaulichende Datenkommunikationsarchitektur ist in der Lage,
unsichere Datenankunftszeiten zwischen zusammenwirkenden Komponenten
zu handhaben. Im Kontext einer SERDES-Datenkommunikationsarchitektur
sind Daten, die von dem Empfangsende einer SERDES-Verbindung extrahiert
werden, eventuell nicht eng auf einen lokalen Takt synchronisiert.
Anders ausgedrückt kann
die Verbindung bei einem beliebigen gegebenen Zyklus des lokalen
Taktes zu präsentierende neue
gültige
Daten aufweisen oder auch nicht.
-
Bei
der veranschaulichenden Implementierung und gemäß der obigen Beschreibung werden Datentransaktionen über die
Verbindungen in einem „Paket”-Format
weitergeleitet. Jedes Paket ist aus einem oder mehreren kleinen
Paketen gebildet, je nach der Informationsmenge und den Daten, die
die Transaktion umfasst. Als ein kleines Paket kann eine Nutzlasteinheit
betrachtet werden, die die Verbindung während eines gegebenen Zeitraums
transferiert. Ein Paket kann ein Anfangsblockpaket aufweisen, auf
das eine bestimmte Anzahl von kleinen Datenpaketen folgt, um die
Transaktion auszufüllen.
Der Anfangsblock kann Informationen, die den Pakettyp beschreiben,
und andere Informationen bezüglich der
Handhabung des Pakets, z. B. seine Zieladresse, umfassen.
-
Um
die Datenkommunikationsinfrastruktur einer exemplarischen Rechenumgebung
zu durchlaufen, kann es der Fall sein, dass eine über eine SERDES-Verbindung
geleitete Transaktion auf dem Weg zu ihrem endgültigen Ziel an eine andere
SERDES-Verbindung weitergeleitet wird. In einem derartigen Kontext
kann eine Datentransaktion mehrere Zyklen auf der SERDES-Verbindung
benötigen,
um einen Transfer all ihrer kleinen Pakete abzuschließen. Es
kann sich eine unerwünschte
Verzögerungszeit
ergeben, wenn eine vollständige
Transaktion hochgepuffert wird, bevor sie an die nächste Kommunikationsverbindung
weitergeleitet wird. Ferner kann es der Fall sein, dass eine Verbindung
in ihrem anfänglichen
Versuch, einen Teil eines Pakets zu senden, ausfällt bzw. fehlschlägt, was
eine lange Pause zwischen dem Beginn und dem Ende des Pakets erzeugt.
Ferner kann der Frequenzbetrieb verschiedener Verbindungen unterschiedlich
sein, was Lücken im
Fluss kleiner Pakete auf eine schnellere Verbindung bewirken kann,
wenn die Daten von einer langsameren Verbindung kommen.
-
Die
veranschaulichende Datenkommunikationsarchitektur handhabt derartige
Fälle,
indem sie einen Mechanismus vorsieht, um einen korrekten Betrieb
der SERDES-Verbindung für
diese Anwendung in der Gegenwart von Lücken im Fluss der kleinen Pakete
und der Pakete einer normalen Größe zu ermöglichen.
Im Betrieb verwendet die SERDES-Verbindungsschnittstelle
an dem Sendeende der Verbindung (siehe Sendekern 235 der 2)
einen ausgewählten
codier ten oder Steuerwert, der über
die Verbindung gesendet werden soll, falls sie nicht das nächste gültige kleine
Paket zum Senden aufweist. Ferner erzeugt das Empfangsende der Verbindung (siehe
Empfangskern 245 der 2) ein ausgehendes
kleines Steuerpaket, wenn sie zu Beginn ihres Taktzyklus keine neu
empfangenen Daten an ihrer Verbindungsschnittstelle findet oder
wenn sie ein codiertes kleines Paket findet. Während der Datenverarbeitung
werden kleine Steuerpakete ignoriert.
-
6 zeigt
die Verarbeitung, die beim Handhaben von Datenkommunikationslücken für Daten durchgeführt wird,
die über
die exemplarische Datenkommunikationsarchitektur 200 der 2 kommuniziert
werden. Wie gezeigt ist, beginnt die Verarbeitung bei Block 600 und
geht zu Block 605 über,
wo eine Prüfung
durchgeführt
wird, um zu bestimmen, ob Daten über
die Kommunikationskanäle
der exemplarischen Datenkommunikationsarchitektur kommuniziert werden
sollen. Wenn keine Daten kommuniziert werden sollen, kehrt die Verarbeitung
zu Block 600 zurück
und fährt
von dort aus fort. Falls jedoch Daten kommuniziert werden sollen,
geht die Verarbeitung zu Block 610 über, wo die zu kommunizierenden
Daten in Bezug auf Kommunikationslücken überwacht werden. Im Betrieb
können
Daten in einem Datenpuffer gepuffert werden, bevor sie durch einen
Parallel-Serien-Umsetzer der Datenkommunikationsarchitektur codiert
werden. Eine Datenverarbeitung in Bezug auf Lücken findet in dem Datenpuffer
statt. Dann wird bei Block 615 eine Prüfung durchgeführt, um
zu bestimmen, ob eine Datenkommunikationslücke vorlag. Falls keine Datenkommunikationslücke vorliegt,
geht die Verarbeitung zu Block 620 über, wo die Daten durch den
Parallel-Serien-Umsetzer an einen kooperierenden Serien-Parallel-Umsetzer
kommuniziert werden. Von dort aus geht die Verarbeitung zu Block 605 über und
fährt von
dort aus fort.
-
Falls
jedoch bei Block 615 bestimmt wird, dass eine Datenlücke vorliegt,
geht die Verarbeitung zu Block 625 über, wo ein kleines Steuerpaket
erzeugt wird. Das kleine Steuerpaket wird anschließend bei
Block 630 an den kooperierenden Serien-Parallel-Umsetzer
kommuniziert, um den kooperierenden Serien-Parallel-Umsetzer von
der Kommunikationslücke
zu benachrichtigen. Der Serien-Parallel-Umsetzer verarbeitet das
kleine Steuerpaket bei Block 635 und breitet das kleine
Steuerpaket bei Block 640 durch die gesamte Datenkommunikationsarchitektur
aus. Die Verarbeitung endet dann bei Block 645.
-
Fehlererfassung:
-
Die
exemplarische Datenkommunikationsarchitektur 200 der 2 ist
ferner in der Lage, an den Daten, die zwischen ihren Komponenten
kommuniziert werden, eine Fehlererfassung durchzuführen. Im
Kontext einer SERDES-Datenkommunikationsarchitektur
kann das erneute Versuchen von Datentransfers notwendig sein, um
Daten zu kommunizieren, die darin fehlschlagen, exakt über die
Verbindung zu gelangen. Um eine Übertragung
erneut zu versuchen, wird zuerst ein Fehler erfasst. Der Fehler ist
erfassbar, um das erste kleine Paket, das erneut versucht wird,
ordnungsgemäß zu identifizieren,
um mit Datenkommunikationsoperationen fortzufahren.
-
Bei
der vorgesehenen Implementierung kann der Codierungsstandard, der
verwendet werden kann, um Daten für eine SERDES-Verbindung zu formatieren,
entworfen sein, um elektrische Charakteristika zu befolgen, die
erforderlich sind, damit die SERDES-Verbindung in der Lage ist,
Daten bei hohen Frequenzen, die sie verwendet, zu übertragen. Ferner
können
auf dem Kanal genügend Übergänge durchgeführt werden,
so dass ein Takt an dem Empfangsende der Verbindung aus dem Bitstrom
extrahiert werden kann. Ferner kann das Bitmuster eine neutrale
Disparität
aufweisen. Anders ausgedrückt kann
die Anzahl von übertragenen
Nullen und Einsen zu jeglichem Zeitpunkt gleich sein oder höchstens
um eins differieren. Das exemplarische Codierungsprotokoll arbeitet
derart, dass einzelne Bitfehler zu einer illegalen Codierung führen. Es
kann jedoch der Fall sein, dass die illegale Codierung in manchen
Fällen legal
aussehen mag, jedoch die falsche erwartete Disparität erzeugt.
Wenn diese Art von Fehler vorliegt, wird der Fehler erst dann erfasst,
wenn die nachfolgenden Datenmuster die Disparität an dem Empfangsende der Verbindung
auf +/–2
schieben.
-
Bei
einer SERDES-Datenkommunikationsarchitektur kann eine einzelne Verbindung
fungieren, um große
Mengen an Informationen rasch über
ihren Kanal zu leiten. Als solches können Fehler durch Senden von
speziellen „Endpaket”-Steuerschriftzeichen
auf der Verbindung begrenzt werden. Diese würden gewährleisten, dass ein Fehler
erkannt wird, bevor der Datenblock freigegeben wird. Dieser Lösungsansatz
bedeutet den Mehraufwand, dass es erforderlich ist, das spezielle
Steuerschriftzeichen zu senden, und kann Ineffizienzen in dem Datenkommunikationsprozess
liefern, wobei eine zusätzliche
Verzögerungszeit
auftritt. In der Praxis kann es einen Codierungszyklus lang dauern,
ein Steuerschriftzeichen zu senden. Man erkennt, dass für eine Datenkommunikationsarchitektur,
die eine Mehrzahl von SERDES-Verbindungen
aufweist, eine beträchtliche Zeitdauer
erforderlich wäre,
um Steuerschriftzeichen zu verarbeiten, was zu beträchtlichen
Ineffizienzen bei Datenkommunikationen führen würde.
-
Die
veranschaulichende Implementierung liefert einen alternativen Lösungsansatz,
bei dem die Datenkommunikationsarchitektur erkennt, dass das erste
Fehlersymptom des Codierungsstandards durch einen Vergleich der
Disparität
der kommunizierten Daten an dem Empfangsende (siehe Empfangskern 245 der
Datenkommunikationsschnittstelle 210 der 2)
und dem Sendeende (siehe Sendekern 235 der Datenkommunikationsschnittstelle 205 der 2)
bestimmt werden kann. Falls die Disparität, die zum Senden der Daten
verwendet wird, an dem Empfänger
bekannt ist, könnte
ein Fehler sofort erfasst werden. Um dies zu erzielen, wird die
Disparität
der Verbindungen, die zum Senden eines kleinen Pakets verwendet
werden, zusammengestellt und verwendet, um einen Fünf-Bit-Fehlercode
zu erzeugen. Dieser Fünf-Bit-Wert
wird dann an das Empfangsende der Verbindung weitergeleitet. Bei
der veranschaulichenden Implementierung kann ein derartiger Fehlercode
unter Verwendung eines zusätzlichen SERDES-Verbindungskanals
an das Empfangsende der Verbindung kommuniziert werden. Dieser Wert kann
dann an dem Empfangsende der Verbindung verwendet werden, um die
Disparitäten
an dem Empfangsende der Verbindung zu prüfen und sofort ein erneutes
Senden von Daten von dem Sendeende des Kommunikationskanals anzufordern,
falls die Disparitäten
nicht die erwarteten Werte aufweisen.
-
Im
Betrieb verwendet die veranschaulichende Implementierung eine Fünf-Bit-
bis Zehn-Bit-Codierung beim Kommunizieren des Fehlercodes. Die fünf Bits
werden zweimal gesendet, einmal als positiv wahr und einmal als
negativ wahr. Auf diese Weise umfasst das Zehn-Bit-Muster fünf Einsen
und fünf Nullen,
wobei eine neutrale Disparität
erzielt wird. Eine derartige Verarbeitung ist außerdem effizient, so dass beim
Verwenden eines Zehn-Bit-Codierungsschemas eine Systemzeitgebung
aufrechterhalten werden kann.
-
Ferner
sieht die veranschaulichende Implementierung vor, dass auf den Abschluss
eines Verbindungstrainings hin Daten über die Verbindung kommunizierbar
sind. Die Daten können
einen Anfangsblock, kleine Datenpakete, falls sie für eine Kommunikation
zur Verfügung
stehen sollten, oder Steuerinformationen, wie z. B. kleine Verbindungsverwaltungsdatenpakete,
umfassen. Unabhängig vom
Typ erzeugen diese Daten, wenn sie codiert werden, ein Muster von
1en und 0en, die eine zugeordnete Disparität aufweisen.
-
7 zeigt
die Verarbeitung, die durch eine exemplarische Datenkommunikationsarchitektur 200 beim
Durchführen
einer Fehlererfassung durchgeführt
wird. Wie gezeigt ist, beginnt die Verarbeitung bei Block 700 und
geht zu Block 705 über,
wo eine Prüfung
durchgeführt
wird, um zu bestimmen, ob Daten über
die Komponenten der exemplarischen Datenkommunikationsarchitektur 200 der 2 kommuniziert
werden sollen. Falls die Prüfung
bei Block 705 die Bestimmung ergibt, dass keine Daten kommuniziert
werden sollen, kehrt die Verarbeitung zu Block 700 zurück und fährt von
dort aus fort. Falls jedoch bei Block 705 bestimmt wird,
dass Daten kommuniziert werden sollen, geht die Verarbeitung zu Block 710 über, wo
die Disparität
für die
zu kommunizierenden Daten berechnet wird. Von dort wird unter Verwendung
der berechneten Disparitäten
durch den Parallel-Serien-Umsetzer bei Block 715 ein Fehlercode
für die
zu kommunizierenden Daten berechnet. Bei Block 720 werden
dann die Daten zusammen mit dem berechneten Fehlercode durch den
Parallel-Serien-Umsetzer
an einen kooperierenden Serien-Parallel-Umsetzer kommuniziert. Der Serien-Parallel-Umsetzer
empfängt
bei Block 725 die Daten und berechnet den Fehlercode auf
der Basis der kommunizierten Daten. Von dort aus wird bei Block 730 eine Prüfung durchgeführt, um
zu bestimmen, ob die Fehlercodes einander entsprechen. Wenn die
Fehlercodes bei Block 730 einander nicht entsprechen, geht
die Verarbeitung zu Block 735 über, wo eine Anforderung, die
Daten erzeugt zu kommunizieren, durch den Serien-Parallel-Umsetzer an den Parallel-Serien-Umsetzer
gesendet wird. Der Parallel-Serien-Umsetzer erhält die Daten für eine erneute
Kommunikation bei Block 740, und die Verarbeitung kehrt zu
Block 710 zurück
und fährt
von dort aus fort.
-
Falls
jedoch bei Block 730 bestimmt wird, dass die Fehlercodes,
die durch eine Berechnung durch den Parallel-Serien-Umsetzer und den
Serien-Parallel-Umsetzer erzeugt wurden, einander nicht entsprechen,
geht die Verarbeitung zu Block 745 über, wo Datentransaktionen
fortgesetzt werden. Von dort aus kehrt die Verarbeitung zu Block 700 zurück und fährt von
dort aus fort.
-
Verbindungsausfälle:
-
Die
exemplarische Datenkommunikationsarchitektur 200 ist ferner
in der Lage, Verbindungsausfälle
zu handhaben, wenn die Verbindungen während des Betriebs ausfallen.
Die veranschaulichende Implementierung arbeitet, um eine Verbindung
mit der Infrastruktur der exemplarischen Rechenumgebung zu ermöglichen,
um aktiv zu bleiben, wenn eine Verbindung ausfällt, und um die Rechenumgebung
nicht zu zwingen, instabil zu werden (z. B. Absturz).
-
Im
Kontext einer SERDES-Datenkommunikationsarchitektur können die
Punkt-zu-Punkt-Verbindungen in der Infrastruktur des Computers aus mehreren
SERDES-Verbindungen bestehen, die zusammenwirken, um eine vergrößerte Datenkommunikationsbandbreite
bereitzustellen. Die veranschaulichende Implementierung sieht die
Verwendung einer zusätzlichen
SERDES-Verbindung vor, die in dem Fall, dass eine der anderen Kommunikationsverbindungen
ausgefallen ist, über
einem „Ersatz”-Verbindungskanal
eingesetzt werden soll. Überdies
kann die veranschaulichende Implementierung erfassen, dass ein Verbindungskanal
nicht zuverlässig
ist, und ihn nicht benutzen. Die Implementierung sieht ferner ein
Protokoll vor, anhand dessen das Empfangsende (siehe Empfangskern 245 der Datenkommunikationsschnittstelle 210 der 2) der
Verbindung mit dem Sendeende (siehe Sendekern 235 der Datenkommunikationsschnittstelle 205 der 2)
der Verbindung kommunizieren kann, wobei der Verbindungskanal nicht
verwendet werden sollte. Im Betrieb bestimmt die veranschaulichende Implementierung,
dass eine Verbindung während
der Verbindungstrainingssequenz ausgefallen ist. Ein Verbindungstraining
erfolgt ansprechend auf einen erfassten Fehler bei der normalen
Datenübertragung oder
beim anfänglichen
Einrichten einer Verbindung. Das Erkennen, dass eine Verbindung
ausgefallen ist, umfasst neben anderen Ereignissen den Verlust des Vorhandenseinerfassungssignals
für diese
Verbindung; Fehlschlagen dieser Verbindung, einen Verbindungsselbsttest
zu bestehen; Fehl schlagen dieser Verbindung, eine ordnungsgemäße Ausrichtung
zu signalisieren.
-
Ansprechend
auf einen Verbindungsausfall verschiebt die Logik an dem Empfangsende
der Verbindung logische Verbindungskanäle von der ausgefallenen Verbindung
zu der letzten nummerierten Verbindung weg von der ausgefallenen
physischen Verbindung. Zusätzlich
wird eine neue Abbildung in einem 5-Bit-Feld codiert und an das
Sendeende der Verbindung zurückgegeben.
Dort wird die Neuabbildung verwendet, um die Sendelogik zu programmieren,
die Verbindungen bei dem nächsten
Trainingsversuch auf die ordnungsgemäßen physischen Kanäle zu treiben.
-
8 zeigt
die Verarbeitung, die durch die exemplarische Datenkommunikationsarchitektur 200 zum
Handhaben eines Verbindungsausfalls durchgeführt wird. Wie gezeigt ist,
beginnt die Verarbeitung bei Block 800 und geht zu Block 805 über, wo
die Datenkommunikationsarchitektur ein Training der Kommunikationsverbindung
einleitet. Von dort werden ein Parallel-Serien-Umsetzer und ein
Serien-Parallel-Umsetzer
der Datenkommunikationsarchitektur 200 dazu abgeordnet,
eine logische Kommunikationsverbindung bei Block 810 zu
erzeugen. Die erzeugte logische Kommunikationsverbindung wird dann
bei Block 815 über
eine physische Kommunikationsverbindung betrieben. Von dort geht
die Verarbeitung zu Block 820 über, wo die Schulung der Kommunikationsverbindung überwacht
wird, um etwaige Verbindungsausfälle
zu identifizieren. Dann wird bei Block 825 eine Prüfung durchgeführt, um
zu bestimmen, ob auf der Verbindung Ausfälle vorliegen. Falls gemäß der Bestimmung
durch die Prüfung
bei Block 825 keine Ausfälle vorliegen, geht die Verarbeitung zu
Block 845 über,
wo das Training der Verbindung abgeschlossen wird. Bei Block 850 werden
anschließend
Datenkommunikationstransaktionen auf der trainierten bzw. geschulten
Verbindung durchgeführt. Die
Verarbeitung endet dann bei Block 855.
-
Wenn
jedoch bei Block 825 bestimmt wird, dass ein Verbindungsausfall
aufgetreten ist, geht die Verarbeitung zu Block 830 über, wo
die logische Kommunikationsverbindung von der ausgefallenen physischen
Kommunikationsverbindung weg verschoben wird. Bei Block 835 wird
eine neue Abbildung erzeugt, die neue logische und physische Kommunikationsverbindungsanordnungen
bereitstellt, und bei Block 840 werden die logischen und physischen
Kommunikationsverbindungen gemäß der neuen
Abbildung ausgerichtet. Von dort kehrt die Verarbeitung zu Block 815 zurück, um die
neu abgebildeten Kanäle
bezüglich
eines ordnungsgemäßen Betriebs
erneut zu testen. Von dort fährt
die Verarbeitung wie gezeigt fort.
-
Man
wird erkennen, dass nach einer ausgewählten Anzahl von fehlgeschlagenen
Versuchen ein Signal über
die kooperierenden Komponenten der Datenkommunikationsarchitektur 200 gesendet
wird, um anzugeben, dass die Verbindung ausgefallen ist. In einem
derartigen Kontext wird die Verbindung nicht für Datenkommunikationstransaktionen
verwendet.
-
Training und fehlgeschlagenes Training:
-
Die
exemplarische Datenkommunikationsarchitektur 200 ist ferner
in der Lage, ein erneutes Training fehlgeschlagener bzw. ausgefallener
Verbindungen zu handhaben. Im Kontext von SERDES-Datenkommunikationsarchitekturen
verwendet die veranschaulichende Implementierung eine Mehrzahl vieler SERDES-Verbindungen,
die miteinander verwendet werden, um eine hohe Bandbreite und eine
geringe Verzögerungszeit
bereitzustellen. In der Praxis werden die SERDES-Verbindungen, bevor sie zum Übertragen
von Daten verwendet werden können, zuerst „trainiert”, indem
entsprechende bekannte Datensequenzen gesendet werden, die das Empfangsende
der Verbindung verwenden kann, um die Verbindungen ordnungsgemäß auszurichten.
Ferner liefert ein Training auch eine Möglichkeit, zu testen, dass
die Verbindungen andere bekannte Datensequenzen genau übertragen.
Unter manchen Umständen
kann das Verbindungstraining während
eines ersten Versuchs fehlschlagen und während eines zweiten Versuchs
erfolgreich sein. In diesem Zusammenhang arbeitet die veranschaulichende
Implementierung, um von dem Sendeende des Kommunikationskanals (siehe
Sendekern 235 der Datenkommunikationsschnittstelle 205 der 2)
an das Empfangsende (siehe Empfangskern 245 der Datenkommunikationsschnittstelle 210 der 2)
des Kommunikationskanals Informationen zu kommunizieren, die ermöglichen
können,
dass das Training während
eines zweiten Versuchs erfolgreich ist.
-
Die
veranschaulichende Implementierung liefert ferner einen Mechanismus,
um Informationen über
die Verbindung weiterzuleiten, wenn ein Verbindungstraining fehlgeschlagen
ist. Im Betrieb werden Datensequenzen zum Testen der Verbindungen
formatiert, bevor sie auf dem Codierer präsentiert werden, derart, dass
dieselbe Bitcodierung unabhängig von
der vorherigen Disparität
des Codierungsschemas, d. h. neutrale Disparität, erzeugt wird.
-
An
dem Empfangsende der Verbindung sind die Daten von der SERDES-Schnittstelle
ein Statisches-Bit-Empfangen-Muster, da die Daten formatiert sind,
um eine neutrale Disparität
aufrechtzuerhalten. Als solches können die bereitgestellten Daten als
statischer Wert behandelt werden, obwohl die Ausrichtung zwischen
den Verbindungen und zwischen den Empfangslogiktakten untereinander
nicht garantiert ist. Ferner sieht die veranschaulichende Implementierung
im Betrieb vor, dass Kopien der Datensequenzen an dem Empfangsende
der Kommunikationsverbindung miteinander verglichen werden, um jegliche
Verbindung, die eventuell fehlerhaft ist, zu disqualifizieren. Überdies
können
die Informationen anschließend
verwendet werden, um jedes Ende der Verbindung neu zu programmieren,
um zu verändern,
wie erwartet wird, dass die Daten ankommen, um um jeglichen Defekt
herum ein erneutes Training durchzuführen.
-
9 zeigt
die Verarbeitung, die durch die exemplarische Datenkommunikationsarchitektur 200 beim
Handhaben von Verbindungstrainingsfehlschlägen durchgeführt wird.
Wie gezeigt ist, beginnt die Verarbeitung bei Block 900 und
geht zu Block 905 über,
wo die exemplarische Datenkommunikationsarchitektur ein Training
der Kommunikationsverbindung einleitet. Von dort geht die Verarbeitung
zu Block 910 über,
wo Verbindungsverwaltungsdaten erzeugt werden. Die Verbindungsverwaltungsdaten werden
anschließend
bei Block 915 von den Parallel-Serien-Umsetzern und Serien-Parallel-Umsetzern über die
Verbindungsverwaltung hinweg kommuniziert. Das Training wird bei
Block 920 überwacht,
um Verbindungstrainingsfehlschläge
zu identifizieren. Bei Block 925 wird dann eine Prüfung durchgeführt, um
zu bestimmen, ob etwaige Verbindungstrainingsfehlschläge vorlagen.
Falls keine Verbindungstrainingsfehlschläge vorliegen, geht die Verarbeitung
zu Block 950 über,
wo Datenkommunikationstransaktionen durchgeführt werden. Von dort aus endet
die Verarbeitung bei Block 955.
-
Falls
jedoch bei Block 925 bestimmt wird, dass Verbindungstrainingsfehlschläge vorliegen, geht
die Verarbeitung zu Block 930 über, wo die Verbindungsverwaltungsdaten
durch die Serien-Parallel-Umsetzer verarbeitet werden. Die Verbindungsverwaltungsdaten
werden anschließend
bei Block 935 über
die zusammenwirkenden Serien-Parallel-Umsetzer hinweg verglichen,
um Trainingsfehlschläge
zu identifizieren. Die Parallel-Serien-Umsetzer und Serien-Parallel-Umsetzer
werden dann bei Block 940 erneut programmiert, um um den
Verbindungstrainingsfehlschlag herum erneut zu trainieren. Von dort
aus kehrt die Verarbeitung zu Block 905 zurück und fährt wie
gezeigt fort.
-
Man
wird erkennen, dass nach einer ausgewählten Anzahl von Ausfällen, wie
sie bei Block 925 bestimmt werden, eine Bestimmung durchgeführt wird,
dass die Verbindung ausgefallen ist und nicht für Datenkommunikationstransaktionen
verwendet wird. In diesem Zusammenhang kann eine zusätzli che
Verarbeitung, wie sie durch 8 beschrieben ist,
durchgeführt
werden, um die logischen und physischen Kanäle erneut abzubilden.
-
Handhaben verfälschter Daten:
-
Die
exemplarische Datenkommunikationsarchitektur 200 ist ferner
in der Lage, Daten als verfälscht
zu identifizieren und zu markieren, um die Robustheit der Datenkommunikationsarchitektur
zu erhöhen.
Im Kontext von SERDES-Datenkommunikationsarchitekturen
liefert die veranschaulichende Implementierung einen Mechanismus
zum Erkennen, wann Daten nicht erfolgreich über die Verbindung hinweg übertragen
werden, und markiert derartige Daten als verfälscht. Dies kann auftreten,
wenn das kleine Datenpaket verfälscht
wird, bevor es gesendet wird. Die veranschaulichende Implementierung
arbeitet, um zu ermöglichen,
dass die ausgefallenen Daten akzeptiert werden, so dass die Verbindung dazu übergehen
kann, Daten hinter dem ausgefallenen kleinen Datenpaket zu senden.
Ferner wird das ausgefallene kleine Datenpaket als verfälscht markiert
und an seinen Zielort gesandt.
-
Ferner
ermöglicht
die veranschaulichende Implementierung, dass eine Verbindung ein
als verfälscht
markiertes kleines Datenpaket annimmt und jegliche Transaktion,
die im Gange ist, wenn die Verbindung, die es derzeit durchläuft, ausfällt, abschließt. Dies
wird bewerkstelligt, indem hergestellte Daten gesendet werden, um
die Transaktion auszufüllen,
und indem die gesamten Daten, Teildaten und Fülldaten, als verfälscht markiert
werden. Dadurch wird verhindert, dass teilweise übertragene Transaktionen andere
Verbindungsschnittstellen verstopfen, was die Infrastruktur befähigt, den
Ausfall auf Prozesse zu beschränken,
die die ausgefallene Verbindung aktiv nutzten.
-
10 zeigt
die Verarbeitung, die durchgeführt
wird, wenn Daten während
Datenkommunikationstransaktionen identifiziert und als verfälscht markiert
werden. Wie gezeigt ist, beginnt die Verarbeitung bei Block 1000 und
geht zu Block 1005 über,
wo eine Kommunikationsverbindung zwischen zusammenwirkenden Komponenten
der exemplarischen Datenkommunikationsarchitektur 200 eingerichtet wird.
Von dort aus geht die Verarbeitung zu Block 1010 über, wo
eine Datenübertragung über die
eingerichtete Kommunikationsverbindung überwacht wird. Daten, die nicht
erfolgreich über
die Kommunikationsverbindung übertragen
werden, werden bei Block 1015 identifiziert. Die identifizierten,
nicht erfolgreich übertragenen
Daten werden bei Block 1020 als verfälscht markiert. Von dort aus
wird bei Block 1025 eine Prüfung durchgeführt, um
zu bestimmen, ob die verfälschten
Daten Teildaten enthalten. Falls die Prüfung bei Block 1025 ergibt,
dass keine Teildaten vorliegen, geht die Verarbeitung zu Block 1040 über, wo die
als verfälscht
markierten Daten durch die Komponenten der Datenkommunikationsarchitektur
verarbeitet werden. Von dort aus werden die als verfälscht markierten
Daten bei Block 1045 über
die Datenkommunikationsarchitektur hinweg weiterverbreitet. Bei Block 1050 werden
dann Datenkommunikationstransaktionen durchgeführt. Die Verarbeitung endet dann
bei Block 1055.
-
Falls
jedoch bei Block 1025 bestimmt wird, dass Teildaten vorliegen,
geht die Verarbeitung zu Block 1030 über, wo Fülldaten erzeugt werden, die an
die verfälschten
Teildaten anzuhängen
sind. Die Fülldaten
und die verfälschten
Teildaten werden dann bei Block 1035 kollektiv als eine
Einheit verfälschter
Daten markiert. Von dort aus geht die Verarbeitung zu Block 1040 über und
fährt von
dort aus fort.
-
Ferner
sieht die veranschaulichende Implementierung vor, dass die Daten
infolge einer oder mehrerer Iterationen erfolgreicher Versuche eines Kommunikationsverbindungstrainings
als verfälscht identifiziert
werden. Anders ausgedrückt
wird bestimmt, dass das Problem ein mit den Daten zusammenhängendes
Problem ist, wenn die Kommunikationsverbindung letztlich erfolgreich
trainiert werden kann, die Übertragung
spezifischer kleiner Datenpakete jedoch wiederholt fehlschlägt.
-
Fehlercodes zur Verwendung bei der Fehlererfassung:
-
Die
exemplarische Datenkommunikationsarchitektur 200 der 2 ist
ferner in der Lage, Fehler über
eine Mehrzahl ihrer Kommunikationskanäle auf effiziente Weise zu
erfassen, ohne eine umfassende Verarbeitung durchzuführen. Im
Kontext einer SERDES-Datenkommunikationsarchitektur sieht die veranschaulichende
Implementierung eine Fehlercodierung vor, die unter Verwendung des
Codierungsprotokolls der Datenkommunikationsarchitektur arbeitet.
-
Im
Betrieb werden Transaktionen (oder Datenpakete) über eine Sammlung mehrerer
Verbindungskanäle
in Einheiten, die als kleine Datenpakete bezeichnet werden, weitergeleitet,
wobei jede Transaktion gemäß ihrer
Größe eine
Anzahl von kleinen Datenpaketen erfordert. Jedes kleine Datenpaket umfasst
eine Anzahl (z. B. 8) logischer Bits pro Kanal, die in einem nummerierten
(z. B. 10) Bitcodierungsprotokoll übertragen werden. Dieses Fehlererfassungsschema
arbeitet zu jeglichem Zeitpunkt mit jeweils einem kleinen Datenpaket.
In der Praxis ist die standardmäßige 8b10b-Codierung,
die pro Kanal verwendet wird, in der Lage, Einbitfehler in einem
Kanal zu erfassen. Diese Erfassung ist mit einer Logik kombiniert,
um acht Paritätsbits über die
Kanäle,
die das kleine Datenpaket tragen, zu berechnen. Das Paritätsbit beruht
nicht auf dem 1., 2., 3., ... 8. Bit der 8 Bits von auf dem Kanal
gesendeten Daten. Diese 8 Paritätsbits
werden dann als die Daten verwendet, die über einen zusätzlichen
Verbindungskanal hinweg übertragen
werden sollen. Fehler können
erfasst werden, indem die Paritätsbits
für die über einen Kommunikationskanal übertragenen
Daten an dem Empfangsende berechnet werden.
-
11 zeigt
die Verarbeitung, die durch die exemplarische Datenkommunikationsarchitektur 200 beim
Erfassen von Fehlern über
eine Mehrzahl von Datenkommunikationskanälen durchgeführt wird. Wie
gezeigt ist, beginnt die Verarbeitung bei Block 1100 und
geht zu Block 1105 über,
wo eine Kommunikationsverbindung zwischen Komponenten der exemplarischen
Datenkommunikationsarchitektur 200 eingerichtet wird. Von
dort aus geht die Verarbeitung zu Block 1110 über, wo
Paritätsbits
für Daten,
die kommuniziert werden, auf der Basis des Codierungsprotokolls,
das n Bits aufweist, berechnet werden. Die Paritätsbits werden dann bei Block 1115 über die Kommunikationsverbindung
hinweg von den Parallel-Serien-Umsetzern an die Serien-Parallel-Umsetzer
kommuniziert. Die Paritätsbits
werden dann bei Block 1120 durch die Serien-Parallel-Umsetzer
verarbeitet. Bei Block 1125 wird dann eine Prüfung durchgeführt, um
zu bestimmen, ob etwaige Fehler unter Verwendung der Paritätsbits identifiziert
wurden. Falls bei Block 1125 keine Fehler identifiziert wurden,
geht die Verarbeitung zu Block 1135 über, wo Datenkommunikationstransaktionen
durchgeführt werden.
Die Verarbeitung endet dann bei Block 1140.
-
Falls
jedoch bei Block 1125 bestimmt wird, dass Fehler identifiziert
wurden, geht die Verarbeitung zu Block 1130 über, wo
die Daten erneut von dem Parallel-Serien-Umsetzer an den Serien-Parallel-Umsetzer
kommuniziert werden. Von dort aus kehrt die Verarbeitung zu Block 1110 zurück und fährt wie
gezeigt fort.
-
Man
wird erkennen, dass nach einer Anzahl von Versuchen, die Daten erneut
von dem Parallel-Serien-Umsetzer an den Serien-Parallel-Umsetzer
zu kommunizieren, und nachdem die Fehler weiterhin identifiziert
werden, dann derartige Daten gemäß der oben
bei 10 beschriebenen Verarbeitung als verfälscht markiert
werden können.
-
Erneuter Versuch auf Verbindungsebene:
-
Die
exemplarische Datenkommunikationsarchitektur 200 der 2 ist
ferner in der Lage, einen erfolgreichen Datentransfer zwischen ihren
Komponenten zu quittieren. Im Kontext einer SERDES-Datenkommunikationsarchitektur
können
Transaktionen in einem „Paket”-Format über die
Verbindungen weitergeleitet werden. Je nach der Menge an Informationen
und Daten, die die Transaktion umfasst, kann aus einem oder mehreren
kleinen Paketen ein Paket gebildet werden. Als ein kleines Datenpaket kann
die Nutzlasteinheit betrachtet werden, zu deren Transfer, jeweils
einzeln, die Verbindung entworfen ist. Das Paket kann ein kleines
Anfangsblockpaket aufweisen, auf das eine Anzahl kleiner Datenpakete folgt,
um die Transaktion auszufüllen.
Unter anderem kann der Anfangsblock Informationen, die den Pakettyp
beschreiben, und andere Informationen, das Paket zu handhaben, z.
B. seine Zieladresse, umfassen.
-
Um
die Fähigkeit
eines erneuten Sendens oder eines erneuten Versuchs des Transfers
kleiner Datenpakete über
die Verbindung zu erzielen, hält die
veranschaulichende Implementierung im Wesentlichen alle kleinen
Anfangsblock- und Datenpakete, die über die Verbindung transferiert
wurden, solange in einem Datenpuffer, bis von dem entgegengesetzten
Ende der Verbindung ein Quittungssignal empfangen wird. Nachdem
eine Quittung eines erfolgreichen Transfers empfangen wurde, kann
der Datenpuffereintrag, der dieses kleine Anfangsblock- und Datenpaket
enthält,
freigegeben werden, um durch ein anderes kleines Datenpaket verwendet
zu werden. Bei der vorgesehenen Implementierung können allgemein
nicht mehr kleine Anfangsblock- und Datenpakete über die Verbindung gesendet
werden, als es Verbindungsebene-Neuversuchspuffereinträge gibt,
um sie zu halten. Falls es misslingt, ein kleines Datenpaket ordnungsgemäß über die
Verbindung zu transferieren, ist das erste kleine Anfangsblock-
und Datenpaket, das erneut über
die Verbindung gesendet werden soll, das älteste kleine Datenpaket in
dem Datenpuffer, das nicht quittiert wurde.
-
Die
veranschaulichende Implementierung liefert einen Mechanismus und
ein Protokoll, die die Quittung eines erfolgreichen Transfers eines
kleinen Datenpakets erzielen. In der Praxis weist das über die
Verbindung transferierte kleine Datenpaket eine demselben zugeordnete
Markierung auf, die zu der Eintragsadresse des Datenpuffers passt,
wo das kleine Datenpaket gespeichert ist. Das kleine Anfangsblockpaket
enthält
ein Feld, das für
eine Quittung eines erfolgreichen Transfers reserviert ist. Wenn
ein Anfangsblock über
die Verbindung ausgesendet wird, wird dieses Feld mit der Adresse
des letzten kleinen Datenpakets, das zu diesem Zeitpunkt erfolgreich
empfangen wurde, gefüllt.
Beim Senden der Adresse korrigiert, falls eine Quittung verloren
geht, die nächste
Quittung selbst den Mechanismus.
-
In
dem Fall, dass kein gültiger
Anfangsblock bereit ist, die Adressquittung über die Verbindung zu tragen,
erzeugt die veranschaulichende Implementierung einen Leerlauf-Anfangsblock, um
die Quittung über
die Verbindung zurückzutragen.
-
Schließlich wird,
nachdem ein Verbindungstransferausfall korrigiert wurde, jedoch
bevor der Normalbetrieb erneut gestartet wird, die Adresse des zuletzt
erfolgreich empfangenen kleinen Datenpakets als Teil der Verbindungsneustartsequenz
gesendet, um sicherzustellen, dass erfolgreich empfangene kleine
Datenpakete entsprechend quittiert werden.
-
12 zeigt
die Verarbeitung, die durch die exemplarische Datenkommunikationsarchitektur 200 der 2 beim
Erzeugen und Abwickeln von Quittungen für erfolgreiche Datenkommunikationen durchgeführt wird.
Wie gezeigt ist, beginnt die Verarbeitung bei Block 1200 und
geht zu Block 1205 über, wo
zwischen zusammenwirkenden Komponenten der Datenkommunika tionsarchitektur 200 der 2 eine
Kommunikationsverbindung eingerichtet wird. Bei Block 1210 werden
dann kleine Datenpakete in einem kooperierenden Datenpuffer gespeichert.
Von dort aus geht die Verarbeitung zu Block 1215 über, wo
eine Adresse für
das kleine Datenpaket erzeugt wird. Die Daten mit der Adresse des
kleinen Datenpakets werden dann bei Block 1220 von einem
sendenden Parallel-Serien-Umsetzer
kommuniziert. Bei Block 1225 wird dann eine Prüfung durchgeführt, um zu
bestimmen, ob die Daten ordnungsgemäß an einen empfangenden Serien-Parallel-Umsetzer
kommuniziert wurden. Falls die Prüfung bei Block 1225 angibt,
dass die Daten nicht ordnungsgemäß kommuniziert
wurden, geht die Verarbeitung zu Block 1230 über, wo
angefordert wird, dass die Daten durch das Sendeende der Kommunikationsverbindung
unter Verwendung der Adresse des jüngsten empfangenen kleinen
Datenpakets erneut gesendet werden. Von dort aus kehrt die Verarbeitung
zu Block 1220 zurück
und fährt
wie gezeigt fort.
-
Falls
jedoch bei Block 1225 bestimmt wird, dass die Daten ordnungsgemäß kommuniziert
wurden, geht die Verarbeitung zu Block 1235 über, wo eine
Prüfung
durchgeführt
wird, um zu bestimmen, ob ein Anfangsblock verfügbar ist, um die Quittung von
dem Empfangsende der Kommunikationsverbindung zu dem Sendeende der
Kommunikationsverbindung zu tragen. Es kann zu einer Zeitverzögerung kommen,
bis die Quittung erstellt wird, während die kleinen Datenpakete
zuerst gesendet werden, um aktuelle ausgehende Pakete zu vervollständigen. Falls
die Prüfung
bei Block 1235 angibt, dass ein Anfangsblock zur Verfügung steht,
geht die Verarbeitung zu Block 1255 über, wo die Adresse des kleinen Datenpakets
unter Verwendung des verfügbaren
Anfangsblocks als Quittung eines erfolgreichen Transfers von dem
Empfangsende des Kommunikationskanals an das Sendeende des Kommunikationskanals
kommuniziert wird. Die Verarbeitung geht zu Block 1260 über, wo
die Adresse des kleinen Datenpakets aus dem kooperierenden Datenpuffer
freigegeben wird. Die Verarbeitung endet dann bei Block 1250.
-
Falls
jedoch bei Block 1235 bestimmt wird, dass kein Anfangsblock
zur Verfügung
steht, wird bei Block 1240 ein Leerlauf-Anfangsblock erzeugt,
um die Quittung eines erfolgreichen Transfers zu tragen. Der Leerlauf-Anfangsblock
wird bei Block 1245 von dem Empfangsende der Kommunikationsverbindung an
das Sendeende der Kommunikationsverbindung kommuniziert. Die Verarbeitung
geht wiederum zu Block 1260 über, wo die Adresse des kleinen
Datenpakets aus dem kooperierenden Datenpuffer freigegeben wird.
Die Verarbeitung endet dann bei Block 1250.
-
Zusammengenommen
liefern die hierin beschriebenen Vorrichtungen und Verfahren eine
Datenkommunikationsarchitektur, die zur Verwendung als Kommunikationsmittel
einer Rechenumgebung eingesetzt wird, das eine Datenverzögerungszeit
verringert. Es versteht sich jedoch, dass an der Erfindung verschiedene
Modifikationen und alternative Konstruktionen vorgenommen werden
können.
Es besteht keine Absicht, die Erfindung auf die hierin beschriebenen
spezifischen Konstruktionen zu beschränken. Im Gegenteil – die Erfindung
soll alle Modifikationen, alternativen Konstruktionen und Äquivalente,
die in den Schutzumfang und die Wesensart der Erfindung fallen,
abdecken.
-
Man
sollte beachten, dass die vorliegende Erfindung in einer Vielzahl
von Rechnerumgebungen (einschließlich sowohl nicht drahtloser
als auch drahtloser Computerumgebungen), Teilrechenumgebungen und
realen Umgebungen implementiert sein kann. Die verschiedenen hierin
beschriebenen Techniken können
in Hardware oder Software oder einer Kombination aus beiden implementiert
sein. Vorzugsweise sind die Techniken in Rechenumgebungen implementiert,
die programmierbare Computer unterhalten, die einen Prozessor, ein
durch den Prozessor lesbares Speichermedium (einschließlich eines
flüchtigen
und nicht-flüchtigen
Speichers und/oder flüchtiger
und nicht-flüchtiger
Speicherelemente), zumindest eine Eingabevorrichtung und zumindest
eine Ausgabevorrichtung umfassen. Eine Rechenhardwarelogik, die
mit verschiedenen Anweisungssätzen
kooperiert, wird auf Daten angewendet, um die oben beschriebenen
Funktionen zu erfüllen und
um Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen werden
an eine oder mehrere Ausgabevorrichtungen angelegt. Programme, die durch
die exemplarische Rechenhardware verwendet werden, können vorzugsweise
in verschiedenen Programmiersprachen implementiert sein, einschließlich einer
verfahrensorientierten Programmiersprache oder einer objektorientierten
Programmiersprache auf hohem Niveau, um mit einem Computersystem
zu kommunizieren. Veranschaulichenderweise können die hierin beschriebenen
Vorrichtungen und Verfahren auf Wunsch in Assemblersprache oder
Maschinensprache implementiert sein. In jedem Fall kann die Sprache
eine kompilierte oder interpretierte Sprache sein. Jedes derartige
Computerprogramm wird vorzugsweise auf einem Speichermedium oder
einer Speichervorrichtung (z. B. ROM oder Magnetplatte) gespeichert,
das bzw. die durch einen programmierbaren Mehrzweck- oder Spezialcomputer
lesbar ist, um den Computer zu konfigurieren und zu betreiben, wenn
das Speichermedium oder die Speichervorrichtung durch den Computer gelesen
wird, um die oben beschriebenen Prozeduren durchzuführen. Die
Vorrichtung kann auch so angesehen werden, dass sie als computerlesbares Speichermedium
implementiert ist, das mit einem Computerprogramm konfiguriert ist,
wobei das derart konfigurierte Speichermedium bewirkt, dass ein Computer
auf eine spezifische und vordefinierte Weise arbeitet.
-
Obwohl
eine exemplarische Implementierung der Erfindung oben ausführlich beschrieben wurde,
werden Fachleute ohne weiteres erkennen, dass bei den exemplarischen
Ausführungsbeispielen viele
zusätzliche
Modifikationen möglich
sind, ohne wesentlich von den neuartigen Lehren und Vorteilen der
Erfindung abzuweichen. Dementsprechend sollen diese und alle derartigen
Modifikationen in dem Schutzumfang dieser Erfindung enthalten sein.
Die Erfindung wird durch die vorliegenden exemplarischen Patentansprüche besser
definiert.