-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft das Gebiet der Computersysteme. Insbesondere
betrifft die vorliegende Erfindung das Gebiet der Hochgeschwindigkeits-Punkt-zu-Punkt-Verbindungen
und der Datenaustauscharchitekturen.
-
ALLGEMEINER
STAND DER TECHNIK
-
Rechnervorrichtungen,
z.B. Computersysteme, Server, Netzwerkschalter und Leitwegrechner,
drahtlose Datenaustauscheinheiten und ähnliches, bestehen typischerweise
aus einer Anzahl verschiedener Elemente. Solche Elemente sind z.B.
häufig
ein Prozessor, eine Systemsteuerungslogik, ein Speichersystem, Eingabe-
und Ausgabe-Schnittstellen und ähnliches.
Um den Datenaustausch zwischen solchen Elementen zu erleichtern,
waren Rechnervorrichtungen lange auf allgemeine Eingabe/Ausgabe-Busse
angewiesen, um zu ermöglichen,
daß diese
verschiedenen Elemente des Rechnersystems miteinander Daten austauschen,
um die Myriaden von Anwendungen zu unterstützen, die von solchen Vorrichtungen
angeboten werden.
-
Vielleicht
eine der allgegenwärtigsten
solcher allgemeinen Busarchitekturen ist der Peripheral-Component-Interconnect-(PCI)-Bus.
Der PCI-Bus-Standard (Peripheral Component Interconnect (PCI) Local
Bus Specification, Ausgabe 2.2, veröffentlicht am 18. Dezember
1998) wird definiert durch eine parallele Mehrfachabzweig-Busarchitektur
zum Verbinden von Chips, Erweiterungskarten und Prozessor/Speicher-Untersystemen
mit Buszuteilung innerhalb einer Rechnervorrichtung. Während typische
Verwirklichungen von PCI-Bussen einen Durchsatz von 133 Mbps (also
32 Bit mit 33 MHz) aufweisen, ermöglicht der PCI-2.2-Standard
64 Bit je Stift der Parallelverbindung, getaktet mit bis zu 133
MHz, was zu einem theoretischen Durchsatz von eben über 1 Gbps
führt.
-
Der
Durchsatz, den die PCI-Busarchitekturen bieten, hat bis vor kurzem
für eine
geeignete Bandbreite besorgt, um den internen Datenaustauscherfordernissen
sogar der fortgeschrittensten Rechnervorrichtungen (z.B. Mehrprozessor-Server-Anwendungen,
Netzwerkanwendungen usw.) zu genügen.
Die jüngsten
Fortschritte in der Verarbeitungsleistung und steigende Anforderungen
an die Eingabe/Ausgabe-Bandbreite schaffen jedoch eine Situation,
wo die früheren
allgemeinen Architekturen wie die PCI-Bus-Architektur zu Verarbeitungs-Engpässen innerhalb
solcher Rechnervorrichtungen geworden sind.
-
Eine
andere Einschränkung,
welche die früheren
Architekturen mit sich bringen, ist es, daß sie typischerweise nicht
gut dafür
geeignet sind, isochrone (zeitabhängige) Datenströme zu verarbeiten.
Ein Beispiel für
einen isochronen Datenstrom ist ein Multimedia-Datenstrom, welcher
einen Transportmechanismus erfordert, um sicherzustellen, daß die Daten
so schell verbraucht werden, wie sie empfangen werden, und um sicherzustellen,
daß der
Audio-Teil mit dem Video-Teil synchronisiert ist. Herkömmliche
allgemeine Eingabe/Ausgabe-Architekturen verarbeiten Daten asynchron
oder in unregelmäßigen Intervallen,
wie es die Bandbreite erlaubt. Eine solche asynchrone Verarbeitung
von Multimedia-Datenströmen
kann zu Datenverlusten und/oder einem nicht abgestimmten Audio-
und Videoteil führen.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Erfindung ist vollständiger
zu verstehen aus der folgenden detaillierten Beschreibung und aus
den begleitenden Zeichnungen der Ausführungsformen der Erfindung,
welche jedoch die Erfindung nicht auf die speziellen beschriebenen
Ausführungsformen
beschränken
sollen, sondern nur der Beschreibung und dem Verständnis dienen
sollen.
-
1 ist
ein Blockdiagramm einer Ausführungsform
eines Computersystems.
-
2 ist
eine graphische Darstellung eines beispielhaften verbesserten allgemeinen
Eingabe/Ausgabe-Anschlusses.
-
3 ist
ein Diagramm, welches das Format einer Ausführungsform des Beginns eines
Transaktionsebenen-Paketkopfes darstellt.
-
4 ist
ein Diagramm eines Anforderungs-Paketkopfes, welcher ein 32-Bit-Adreßformat
unterstützt.
-
5 ist
ein Diagramm eines Anforderungs-Paketkopfes, welcher ein 64-Bit-Adreßformat
unterstützt.
-
6 ist
ein Diagramm eines Paketkopfes für
eine Mitteilung.
-
7 ist
ein Diagramm, welches ein Anforderungskopf-Format für eine Konfigurationstransaktion
darstellt.
-
8 ist
ein Diagramm, welches eine Ausführungsform
eines Formats für
einen Beendigungskopf darstellt.
-
9a und 9b bilden
in Kombination ein Flußdiagramm
eines Ausführungsbeispiels
eines Verfahrens zur Behandlung empfangener Transaktionsebenenpakete.
-
10 ist
ein Flußdiagramm
einer Ausführungsform
eines Verfahrens zur Behandlung von Fehlerbedingungen in Zusammenhang
mit empfangenen Anforderungspaketen.
-
11 ist
ein Flußdiagramm
einer Ausführungsform
eines Verfahrens zur Behandlung eines Beendigungspaketes, welches
von einem Systemagenten nicht erwartet wird.
-
12 ist
ein Flußdiagramm
einer Ausführungsform
eines Verfahrens für
eine anfordernde Einheit, welche ein Beendigungspaket mit einem
anderen Beendigungsstatus als „Erfolgreiche
Beendigung" behandelt.
-
13 ist
ein Flußdiagramm
einer Ausführungsform
eines Verfahrens für
eine beendigende Einheit, welche ein Beendigungspaket mit einem
anderen Beendigungsstatus als „Erfolgreiche
Beendigung" behandelt.
-
DETAILLIERTE
BESCHREIBUNG
-
Im
folgenden werden Ausführungsformen
einer Punkt-zu-Punkt-Verbindungsarchitektur auf Paketbasis, eines
Datenaustauschprotokolls und ähnlicher
Verfahren, um eine skalierbare und erweiterbare allgemeine Eingabe/Ausgabe-Datenaustauschplattform
für den
Einsatz innerhalb einer elektronischen Vorrichtung bereitzustellen,
beschrieben. Die offenbarten Ausführungsformen umfassen eine
verbesserte allgemeine Eingabe/Ausgabe-Ver bindungsarchitektur und
ein damit zusammenhängendes
Datenaustauschprotokoll. Ein Ausführungsbeispiel enthält einen
oder mehrere eines Grundkomplexes, welcher eine Host Bridge, einen
Schalter oder Endpunkte enthält,
wobei jeder zumindest eine Untergruppe verbesserter allgemeiner
Eingabe/Ausgabe-Merkmale beinhaltet, um einen verbesserten allgemeinen
Eingabe/Ausgabe-Datenaustausch zwischen solchen Elementen zu unterstützen.
-
Der
Datenaustausch zwischen den verbesserten allgemeinen Eingabe/Ausgabe-Merkmalen
solcher Elemente wird in einer Ausführungsform unter Verwendung
serieller Datenaustauschkanäle
durchgeführt,
wobei ein Datenaustauschprotokoll angewendet wird, welches eines
oder mehrere neue Merkmale unterstützt, z.B., aber nicht darauf
beschränkt,
virtuelle Datenaustauschkanäle,
Fehlerweiterleitung auf Tailer-Basis („Tailer" sind an Transaktionsebenenpakete angehängt, um
eine Fehlerbedingung anzuzeigen), Unterstützung für bestehende Einheiten auf
PCI-Basis, Mehrfachanforderungs-Antworttypen, Flußregelung
und/oder Datenintegritätsmanagement-Merkmale.
Das in dieser Ausführungsform
unterstützte
Datenaustauschprotokoll enthält einen
Datenaustauschprotokollstapel, welcher eine physikalische Ebene,
eine Datenübermittlungsebene
und eine Transaktionsebene enthält.
-
In
einer alternativen Ausführungsform
beinhaltet ein Datenaustauschagent eine verbesserte allgemeine Eingabe/Ausgabe-Maschine,
welche eine Untergruppe der vorstehenden Merkmale umfaßt. Ferner
können ein
oder mehrere Elemente der verschiedenen Ausführungsformen in Hardware, Software,
einem sich ausbreitenden Signal oder einer Kombination davon verwirklicht
werden.
-
1 ist
ein Blockdiagramm einer elektronischen Vorrichtung 100,
bei welcher es sich in dieser Ausführungsform um ein Computersystem
handelt. Das System 100 enthält einen Prozessor 102,
eine Host Bridge 103, welche als Teil eines Grundkomplexes 104 enthalten
ist, den Schalter 108 und den Endpunkt 110, jeweils wie
dargestellt verknüpft.
Der Grundkomplex 104, der Schalter 108 und der
Endpunkt 110 enthalten ein oder mehrere Exemplare eines
verbesserten allgemeinen Eingabe/Ausgabe-Datenaustauschanschlusses 106.
Wie dargestellt, ist jedes der Elemente 102, 104, 108 und 110 durch
eine Datenaustauschverbindung 112, welche einen oder mehrere
verbesserte allgemeine Eingabe/Ausgabe-Datenaustauschkanäle unterstützt, über den verbesserten
allgemeinen Eingabe/Ausgabe-Datenaustauschanschluß mit mindestens
einem anderen Element verknüpft.
Das System 100 soll für
jedes System einer breiten Vielfalt an herkömmlichen und nichtherkömmlichen
Rechnersystemen, Servern, Netzwerkschaltern, Netzwerk-Leitwegrechnern,
Teilnehmergeräten für den drahtlosen
Datenaustausch, Infrastrukturelementen für das drahtlose Telefonieren,
PDA-Computer, Set-Top-Boxen oder irgendeine elektrische Vorrichtung
stehen, die von den Datenaustausch-Ressourcen profitieren würde, die
durch die Integration mindestens einer Untergruppe der verbesserten
allgemeinen Eingabe/Ausgabe-Verbindungsarchitektur und/oder des
hier beschriebenen Datenaustauschprotokolls eingeführt werden.
-
In
diesem Ausführungsbeispiel
steuert der Prozessor 102 eine oder mehrere Erscheinungsformen
der funktionellen Möglichkeiten
der elektronischen Vorrichtung 100. In dieser Hinsicht
steht der Prozessor 102 für irgendeine aus einer breiten
Vielfalt von Steuerlogikeinheiten, z.B., aber nicht darauf beschränkt, für eines
oder mehrere aus einem Mikroprozessor, einer programmierbaren Logikeinheit
(PLD), einer programmierbaren Logikanordnung (PLA), einer anwendungsspezifischen
integrierten Schaltung (ASIC), einem Mikrocontroller und ähnlichem.
-
Der
Grundkomplex 104 stellt eine Datenaustausch-Schnittstelle
zwischen dem Prozessor 102 und dem Schalter 108 und
dem Endpunkt 110 bereit. Wie hier verwendet, bezieht sich
der Begriff „Grundkomplex" auf eine logische
Einheit einer verbesserten allgemeinen Eingabe/Ausgabe-Hierarchie,
welche einem Wirtscontroller, einem Speichercontrollerknoten, einem
IO-Controllerknoten oder irgendeiner Kombination der obigen oder
irgendeiner Kombination von Chipsatz/CPU-Elementen (d.h., in einer
Computersystem-Umgebung) am nächsten
ist. Obwohl in 1 als eine einzelne Einheit
dargestellt, kann der Grundkomplex 104 mit mehreren physikalischen
Komponenten verwirklicht werden. Der Grundkomplex 104 enthält einen
oder mehrere verbesserte allgemeine Eingabe/Ausgabe-Anschlüsse 106,
um den Datenaustausch mit anderen Peripherieeinheiten, z.B. dem
Schalter 108, dem Endpunkt 110 und, obwohl nicht
im einzelnen dargestellt, den bestehenden Brücken 114 oder 116,
zu erleichtern. In einer Ausführungsform
steht jeder verbesserte allgemeine Eingabe/Ausgabe-Schnittstellenanschluß für eine andere
Hierarchiedomäne.
In dieser Hinsicht beschreibt die Ausführungsform der 1 einen
Grundkomplex 104 mit drei Hierarchiedomänen.
-
2 ist
eine graphische Darstellung eines beispielhaften verbesserten allgemeinen
Eingabe/Ausgabe-Anschlusses 106. In dieser Ausführungsform
verwirklicht der verbesserte allgemeine Eingabe/Ausgabe-Anschluß 106 einen
Datenaustauschstapel, welcher eine Transaktionsebene 202,
eine Datenübermittlungsebene 204 und
eine physikalische Ebene 206 umfaßt, die, wie dargestellt, einen
logischen Teilblock 208 und einen physikalischen Teilblock 210 enthält. Elemente
der Transaktionsebene werden im folgenden detaillierter beschrieben.
-
Die
Transaktionsebene 202 stellt eine Schnittstelle zwischen
der verbesserten allgemeinen Eingabe/Ausgabe-Architektur und einem
Einheits-Kernspeicher bereit. Eine hauptsächliche Aufgabe der Transaktionsebene 202 ist
die Zusammenstellung und Zerlegung von Paketen für eine oder mehrere logische
Einheiten innerhalb eines Agenten.
-
Eines
der Hauptziele der verbesserten allgemeinen Eingabe/Ausgabe-Architektur
ist es, die Effizienz des Datenaustausches zwischen Einheiten zu
maximieren. In einer Ausführungsform
verwirklicht die Transaktionsebene ein im Fließbandsystem verarbeitetes vollständiges Protokoll
für zerteilte
Transaktionen ebenso wie Mechanismen zum Differenzieren der Ordnungs-
und Verarbeitungserfordernisse von Transaktionsebenenpaketen. Die
Transaktionsebene umfaßt
ferner die Konstruktion und die Verarbeitung von Transaktionsebenenpaketen.
-
Eine
Ausführungsform
der verbesserten allgemeinen Eingabe/Ausgabe-Architektur unterstützt die
folgenden grundlegenden Transaktionstypen und Adreßräume: Speicher,
E/A, Konfiguration und Mitteilung. Es werden zwei Adressierungstypen
unterstützt:
32 Bit und 64 Bit.
-
Die
Transaktionen werden unter Verwendung von Anforderungs- und Beendigungspaketen übertragen,
welche einfach als Anforderungen und Beendigungen bezeichnet werden
können.
Beendigungen werden nur dort verwendet, wo sie benötigt werden,
z.B.: um gelesene Daten zurückzusenden
oder um die Beendigung von E/A- und von Konfigurations-Schreibtransaktionen
zu bestätigen.
Beendigungen sind durch den Wert in dem Anforderungseinheits-Kennungsfeld
des Paketkopfes (unten beschrieben) mit ihren entsprechenden Anforderungen
verbunden.
-
Alle
Transaktionsebenenpakete in dieser Ausführungsform beginnen mit einem
festgelegten Kopf. Einige Transaktionsebenenpakete enthalten Daten,
die dem Kopf folgen, wie durch das Formatfeld festgelegt, welches
in dem Transaktionsebenenpaketkopf spezifiziert ist. Das Transaktionsebenenpaket
ist durch einen vorgegebenen Wert der maximalen Nutzlast in der
Größe begrenzt.
Die Transaktionsebenenpaketdaten betragen in dieser Ausführungsform
vier Byte natürlich
angeordnet und mit Inkrementen von Vier-Byte-Doppelwörtern.
-
3 ist
ein Diagramm, welches das Format einer Ausführungsform des Beginns eines
Transaktionsebenenpaketkopfes darstellt. Jeder Transaktionsebenenpaketkopf
enthält
ein Drei-Bit-Formatfeld
(Fmt[2:0]). Der Transaktionsebenenpaketkopf enthält auch ein Vier-Bit-Typenfeld (Typ[3:0]).
Sowohl das Fmt- als auch das Typenfeld müssen decodiert werden, um das
Format des Transaktionsebenenpaketes zu ermitteln. Tabelle 1 zeigt
beispielhafte Decodierungen für
das Fmt-Feld.
-
Tabelle
1 – Fmt-Feld-Decodierungen
-
In
dieser Ausführungsform
enthält
der Transaktionsebenenkopf auch ein Zwei-Bit-Erweitertes Typen-/Erweitertes
Längenfeld
(Et/El). Dieses Feld wird verwendet, um entweder das Typenfeld oder
das Längenfeld
zu erweitern, abhängig
von dem Wert im Typenfeld. In dieser Ausführungsform ist das Längenfeld
gewöhnlich
ein Acht-Bit-Feld, kann aber erweitert werden, so daß es zu
einem Zehn-Bit-Feld wird, wenn der Wert im Typenfeld anzeigt, daß das Et/El-Feld
verwendet werden soll, um das Längenfeld
zu erweitern. Das Typenfeld kann erweitert werden, so daß es zu
einem Sechs-Bit-Feld wird, indem das Et/El-Feld angehängt wird, abhängig von
dem Wert im Typen[3:0]-Feld. Siehe Tabelle 2 unten für beispielhafte
Fmt-, Typen- und Et/El-Feld-Codierungen
(in alternativen Ausführungsformen
können
andere Codierungsschemen verwendet werden). Das Et/El-Feld wird
als Erweiterung des Typenfeldes benutzt, wenn nicht anders angegeben.
-
-
-
Tabelle
2 – Fmt-,
Typ- und Et/El-Codierungen
-
Anforderungspakete
enthalten einen Anforderungskopf, welcher für einige Typen von Anforderungspaketen
von einer gewissen Anzahl an Daten-Doppelwörtern gefolgt wird. Der Begriff „Doppelwort", wie er hier verwendet
wird, bezeichnet eine 32-Bit-Länge
der Daten. In diesem Ausführungsbeispiel
wird das Längenfeld für Mitteilungsanforderungsköpfe nicht
verwendet, außer
für Mitteilungen,
welche sich ausdrücklich
auf eine Datenlänge
beziehen. Ebenfalls ist in dieser Ausführungsform für Speicherleseanforderungen
das Et/E1-Feld und Speicherschreibanforderungen mit dem Längenfeld
verkettet, um ein Zehn-Bit-Längenfeld
zu bilden. Das Zehn-Bit-Längenfeld
erlaubt Lese- und Schreibanforderungen, welche bis zu 4 kB an Daten
anzeigen. Andere Typen von Transaktionsebenenpaketen sind durch
die Größe des Längen[7:0]-Feldes
darauf begrenzt, bis zu 1 kB an Daten anzuzeigen. Die Datenmenge,
die in jedem Transaktionsebenenpaket enthalten ist, ist in einer Ausführungsform
auf eine vorgegebene maximale Nutzlast begrenzt. Für Transaktionsebenenpakete,
welche Daten enthalten, sollte der Wert in dem Längenfeld und die tatsächliche
Datenmenge gleich sein. Wenn der Empfänger ermittelt, daß der Längenfeldwert
und die tatsächliche
Datenmenge nicht übereinstimmen,
dann wird das Paket als fehlgebildetes Transaktionsebenenpaket behandelt.
Fehlgebildete Transaktionsebenenpakete werden unten beschrieben.
-
4 ist
ein Diagramm eines Anforderungspaketkopfes, welcher ein 32-Bit-Adreßformat
unterstützt, und 5 ist
ein Diagramm eines Anforderungspaketkopfes, welcher ein 64-Bit-Adreßformat
unterstützt.
In einer Ausführungsform
verwenden Speicherleseanforderungen und Speicherschreibanforderungen
entweder das 32-Bit-Adreßformat
oder das 64-Bit-Adreßformat.
Für Adressen
unterhalb 4 GB wird das 32-Bit-Format verwendet.
-
Die
Anforderungspaketköpfe
der 4 und 5 enthalten auch ein Byte-Freigabefeld
für das
erste Doppelwort (Erstes DW BF) und ein Byte-Freigabefeld für das letzte
Doppelwort (Letztes DW BF). Das erste Doppelwort-Byte-Freigabefeld
enthält
Byte-Freigaben für
das erste Doppelwort jeder Speicherlese- oder -schreibanforderung.
Dieses Feld enthält
auch Byte-Freigaben
für das
einzige Doppelwort einer Eingabe/Ausgabe- oder Konfigurationsanforderung.
Das Byte-Freigabefeld für
das letzte Doppelwort enthält
Byte-Freigaben für
das letzte Doppelwort jeder Speicherlese- oder -schreibanforderung.
Die Byte-Freigabe-Felder werden bei Mitteilungen nicht verwendet,
weil diese Felder mit dem Mitteilungscodefeld für einen Mitteilungsanforderungskopf überlappen
(siehe 7, unten erörtert).
-
In
einer Ausführungsform
zeigt für
jedes Bit in den Byte-Freigabefeldern ein Wert von „0" an, daß das entsprechende
Daten-Byte nicht geschrieben ist, oder, falls nicht vorauslesbar,
an einer Beendigungseinheit ausgelesen ist. Der Begriff „Beendigungseinheit", wie er hier verwendet
wird, soll für
eine logische Einheit stehen, die von einem Anforderungspaketkopf
adressiert wird. Ein Wert von „1" zeigt an, daß das entsprechende Daten-Byte
geschrieben ist, oder, falls nicht vorauslesbar, an der Beendigungseinheit
ausgelesen ist. Für
das Byte-Freigabefeld für
das erste Doppelwort entspricht das Bit 0 dem Byte 0 des ersten
Daten-Doppelwortes. Das Bit 1 entspricht dem Byte 1 des ersten Daten-Doppelwortes.
Das Bit 2 entspricht dem Byte 2 des ersten Daten-Doppelwortes. Das
Bit 3 entspricht dem Byte 3 des ersten Daten-Doppelwortes. Für das Byte-Freigabefeld
für das
letzte Doppelwort entspricht das Bit 0 dem Byte 0 des letzten Daten-Doppelwortes.
Das Bit 1 entspricht dem Byte 1 des letzten Daten-Doppelwortes.
Das Bit 2 entspricht dem Byte 2 des letzten Daten-Doppelwortes.
Das Bit 3 entspricht dem Byte 3 des letzten Daten-Doppelwortes. Die
beispielhaften Paketköpfe
der 4, 5, 6 und 8 enthalten
ein Anforderungseinheits-Kennungsfeld,
ein Markierungsfeld, ein Attributfeld und ein Kennungsfeld für virtuelle
Kanäle.
Das Anforderungseinheits-Kennungsfeld und das Markierungsfeld bilden
zusammen ein Transaktionskennungsfeld. Das Anforderungseinheits-Kennungsfeld
ist in ein Busnummernfeld, ein Einheitsnummernfeld und ein Funktionsnummernfeld
unterteilt.
-
Das
Markierungsfeld ist ein 5-Bit-Feld, welches von jeder anfordernden
Einheit erzeugt wird. Der Markierungswert ist für alle unerledigten Anforderungen,
die eine Beendigung für
diese anfordernde Einheit erfordern, einmalig. Das Transaktionskennungsfeld
ist in allen Anforderungen und Beendigungen enthalten. Bei dem Anforderungseinheits-Kennungsfeld
handelt es sich in diesen Ausführungsbeispielen
um einen 16-Bit-Wert, der für
jede Funktion (eine Funktion ist ein unabhängiger Teil einer Multifunktionseinheit,
welcher im Konfigurationsraum durch eine einmalige Funktionsnummer
gekennzeichnet ist) einmalig ist. Funktionen erfassen die Busnummer,
die mit allen Konfigurationsschreiboperationen, die von der Funktion
beendet werden, mitgeliefert wird, und legen diese Nummer im Busnummernabschnitt
des Anforderungseinheits-Kennungsfeldes ab. Jede logische Einheit
in einer Komponente ist so konstruiert, daß sie auf eine einmalige Einheitsnummer
für Konfigurationsanforderungen,
welche diese Komponente adressieren, reagiert. In diesen Ausführungsbeispielen
kann eine Komponente viele (möglicherweise
bis zu mehrere Dutzend) logische Einheiten enthalten. Jede Funktion,
die mit einer logischen Einheit in einer Komponente verbunden ist,
ist so konstruiert, daß sie
auf eine einmalige Funktionsnummer für Konfigurationsanforderungen,
welche diese Komponente und diese logische Einheit adressieren,
reagiert. Jede logische Einheit kann bis zu acht logische Funktionen
enthalten.
-
Das
Attributfeld spezifiziert Eigenschaften der Transaktion. Attribute,
die in dem Attributfeld spezifiziert sein können, sind z.B. ein Prioritätsattribut,
Transaktionsordnungsattribute und Cachespeicher-Kohärenzmanagement-Attribute.
-
Das
Kennungsfeld für
virtuelle Kanäle
identifiziert den virtuellen Kanal. In diesen Ausführungsbeispielen
handelt es sich bei dem Kennungsfeld für virtuelle Kanäle um ein
4-Bit-Feld, welches
die Identifizierung von bis zu 16 virtuellen Kanälen auf einer Je-Transaktions-Basis ermöglicht.
In diesen Ausführungsbeispielen
wird für
allgemeinen Verkehr der virtuelle Kanal 0 verwendet und für isochronen
Verkehr ein anderer Kanal als 0 verwendet.
-
6 ist
ein Diagramm eines Paketkopfes für
eine Mitteilung. Wie in Tabelle 2 zu sehen ist, können Mitteilungen
Daten enthalten oder nicht und können
eine Beendigung erfordern oder nicht. Mitteilungen werden von allen
Einheiten in einem System decodiert, welche die verbesserte allgemeine
Eingabe/Ausgabe-Verbindungsarchitektur unterstützen.
-
Für Mitteilungsanforderungen
wird das Mitteilungsfeld decodiert, um den speziellen Zyklus zu
ermitteln und um zu ermitteln, ob die Mitteilung eine Beendigung
erfordert. In dieser Ausführungsform
handelt es sich bei dem Mitteilungsfeld um ein 8-Bit-Feld, welches
sich dort befindet, wo sich für
andere Transaktionstypen normalerweise die Byte-Freigabefelder befinden.
Nicht unterstützte
Mitteilungen werden von der empfangenden Einheit als solche behandelt,
die keine Beendigung erfordern (keine Beendigung erfordernde Transaktionen
werden unten beschrieben).
-
In
diesem Ausführungsbeispiel
werden die Mitteilungen in Gruppen unterteilt. Es gibt acht Gruppen, bei
welchen in der Anforderung Daten enthalten sind, und acht Gruppen,
welche dies nicht tun. In anderen Ausführungsformen werden möglicherweise
andere Anzahlen an Gruppen verwendet. In dieser Ausführungsform weisen,
wie in Tabelle dargestellt, die acht Gruppen, bei welchen in den
Anforderungen Daten enthalten sind, einen Wert von b010 im Fmt-Feld
auf. Das Unterfeld s[2:0] beinhaltet ein Bit aus dem Typenfeld und
die beiden Bits aus dem Et/El-Feld. Das Unterfeld s[2:0] zeigt eine
von acht Gruppen an.
-
Beispiele
für verschiedene
Mitteilungen, die verwirklicht werden können, sind, aber nicht darauf
beschränkt,
die folgenden: Mitteilungen zum Entsperren von Einheiten; Mitteilungen
zum Zurückstellen
von Einheiten; Mitteilungen, die eine korrigierbare Fehlerbedingung
anzeigen; Mitteilungen, die eine nicht korrigierbare Fehlerbedingung
anzeigen; Mitteilungen, die eine schwere Fehlerbedingung anzeigen;
Mitteilungen, die verwendet werden, um fehlerhafte Anforderungspakete
zu melden; Mitteilungen, die sich auf das Strommanagement beziehen;
Mitteilungen, die sich auf Ordnungssteuerung/-mangement beziehen;
und Mitteilungen zum Emulieren von bestehenden (z.B. PCI)-Unterbrechungssignalen
(oder anderen bestehenden Signalen). Diese verschiedenen Mitteilungstypen
können
in eine der zuvor beschriebenen Gruppen eingeteilt werden. Zum Beispiel
können
alle Strommanagement-Mitteilungen in einer Gruppe enthalten sein,
und die Unterbrechungssignal-Mitteilungen können in einer anderen Gruppe
enthalten sein.
-
7 ist
ein Diagramm, welches ein Anforderungskopfformat für eine Konfigurationstransaktion
darstellt. Der Konfigurationsraum ist einer der vier unterstützten Adreßräume für diese
Ausführungsbeispiele.
-
8 ist
ein Diagramm, welches eine Ausführungsform
eines Formates für
einen Beendigungskopf darstellt. Alle Leseanforderungen und einige
Schreibanforderungen erfordern eine Beendigung. Beendigungen enthalten
einen Beendigungskopf, welcher für
einige Typen von Beendigungen von einer gewissen Anzahl an Daten-Doppelwörtern gefolgt
wird. Das Beendigungsstatus[2:0]-Feld, welches in 8 dargestellt
ist, zeigt den Status für
eine Beendigung an. Tabelle 3 zeigt ein beispielhaftes Codierungsschema.
-
Tabelle
3 – Codierungsschema
für das
Beendigungsstatusfeld
-
Das
Beendigungseinheitskennungs[15:0]-Feld enthält denselben Typ von Informationen
wie das oben beschriebene Anforderungseinheits-Kennungsfeld. Der
in dem Beendigungseinheits-Kennungsfeld
bereitgestellte Wert entspricht Bus/Einheit/Funktion des Agenten,
welcher die Anforderung beendet. Die Beendigungsköpfe enthalten
dieselben Werte für
die Anforderungseinheitskennung, die Markierung und die Kanalkennung, wie
sie im Kopf des Anforderungspaketes mitgeliefert wurden. Die Beendigungsköpfe enthalten
auch im Attributfeld denselben Wert, wie er ursprünglich mit
dem Kopf der Anforderung mitgeliefert wurde. Die Beendigungspakete
werden über
Schalter und Grundkomplexe zu dem Anschluß geleitet, welcher die entsprechende Anforderungstransaktion
begonnen hat.
-
Für Speicherleseanforderungs-Transaktionen
können
einzelne Beendigungspakete weniger als die volle Datenmenge bereitstellen,
die von der entsprechenden Leseanforderung angefordert wurde, solange
alle der Beendigungspakete, welche mit der entsprechenden Leseanforderung
verbunden sind, in Kombination die spezifizierte Datenmenge zurücksenden.
In diesen Ausführungsbeispielen
werden E/A- und Konfigurationsleseanforderungen mit genau einem
Beendigungspaket beendet.
-
Eine
Beendigung, die Daten enthält,
spezifiziert die Datenmenge im Paketkopf. Wenn das Beendigungspaket
in Wirklichkeit eine Datenmenge enthält, die sich von der spezifizierten
Menge unterscheidet, dann führt
dies zu einem fehlgebildeten Transaktionsebenenpaket.
-
9a und 9b bilden
in Kombination ein Flußdiagramm
eines Ausführungsbeispiels
für ein
Verfahren zur Behandlung empfangener Transaktionsebenenpakete. Die
unten beschriebenen Operationen müssen nicht notwendigerweise
der Reihe nach geschehen. In einigen Ausführungsformen können einige
Operationen gleichzeitig durchgeführt werden. In Block 905 wird
eine Überprüfung durchgeführt, um
zu ermitteln, ob die in den Fmt- und Längenfeldern des empfangenen
Paketes enthaltenen Werte mit der tatsächlichen Größe des Paketes übereinstimmen.
Eine Abweichung zeigt ein fehlgebildetes Paket an, und es resultiert
ein Fehlerfall, wie in Block 925 dargestellt. Die Fehlerfallbehandlung
wird unten beschrieben. Wenn die tatsächliche Größe des empfangenen Paketes
keine Abweichung von den Fmt- und Längenfeldern anzeigt, dann wird
die Verarbeitung in Block 910 fortgeführt.
-
Wenn
es sich bei dem empfangenen Paket um eine Speicheranforderung unter
Verwendung der 64-Bit-Adressierung handelt, dann werden die Adreß-Bits [63:32]
in Block 910 überprüft, um zu
sehen, ob irgendeines der Adreß-Bits
[63:32] ungleich Null ist. Wenn keines der Adreß-Bits [63:32] ungleich Null
ist, dann ist das Ergebnis ein fehlgebildetes Paket, und die Verarbeitung
schreitet zu dem Fehlerfallblock 925 fort. Wenn mindestens
eines der Adreß-Bits
[63:32] ungleich Null ist, dann wird die Verarbeitung in Block 915 fortgeführt.
-
In
Block 915 wird eine Überprüfung durchgeführt, um
zu ermitteln, ob irgendwelche Felder in dem Paketkopf reservierte
Werte enthalten. Wenn reservierte Werte gefunden werden, dann ist
das Ergebnis ein fehlgebildetes Paket, und die Verarbeitung schreitet
zu Block 925 fort. Wenn keine reservierten Werte gefunden werden,
dann wird die Verarbeitung in Block 930 fortgeführt.
-
In
Block 930 wird ermittelt, ob das Paket ein Anforderungspaket
oder ein Beendigungspaket ist. Wem das Paket ein Beendigungspaket
ist, dann schreitet die Verarbeitung zum Beendigungsbehandlungsblock 935 fort.
Die Beendigungsbehandlung wird unten ausführlicher beschrieben. Wenn
das empfangene Paket kein Beendigungspaket ist, dann wird die Verarbeitung
in Block 940 fortgeführt.
Man beachte, daß alle
Pakete, die zu Block 940 laufen, Anforderungspakete sind.
-
In
Block 940 wird eine Überprüfung durchgeführt, um
zu ermitteln, ob es sich bei dem Anforderungspaket um einen Anforderungstyp
handelt, welcher von der beendigenden Einheit unterstützt wird.
Wenn der Anforderungstyp nicht unterstützt wird, dann ist das Ergebnis
eine nicht unterstützte
Anforderung, und die Verarbeitung schreitet zum Fehlerfallblock 925 fort.
Wenn der nicht unterstützte
Anforderungstyp eine Rundschreibmitteilung ist oder eine Mitteilung,
welche eine Codierung verwendet, die für Rundschreibmitteilungen reserviert
ist, dann wird in diesem Ausführungsbeispiel
das Paket still verworfen, und kein Fehlerfall resultiert. Wenn
der Anforderungstyp von der beendigenden Einheit unterstützt wird,
dann wird die Verarbeitung in Block 945 fortgeführt.
-
Wenn,
wie in Block 945 dargestellt, die Beendigungseinheit aufgrund
eines internen Fehlers nicht auf das Anforderungspaket reagieren
kann, dann ist das Ergebnis ein „Abbruch der Beendigungseinheit", und die Verarbeitung
schreitet zum Fehlerfallblock 925 fort. Anderenfalls wird
die Anforderung in Block 950 bedient. Bei der Bedienung
der Anforderung kann es notwendig sein, die Verarbeitung, die in
den Blöcken 940 und 945 angezeigt
ist, zu wiederholen.
-
Wenn
die Anforderung einmal erfolgreich bedient ist, dann wird die Verarbeitung
in Block 955 fortgesetzt. Wie in Block 955 angezeigt,
wird dann in Block 960 ein Beendigungspaket zurückgesendet,
wenn die verarbeitete Anforderung eine Beendigung erfordert.
-
10 ist
ein Flußdiagramm
einer Ausführungsform
eines Verfahrens zur Behandlung von Fehlerbedingungen, die mit empfangenen
Anforderungspaketen verbunden sind. Wie in Block 1010 zu
sehen, wird dann, wenn für
die empfangene Anforderung eine Beendigung erwartet wird, in Block 1020 eine
Beendigung mit dem geeigneten Beendigungsstatus gesendet. Die Beendigung
wird zu der anfordernden Einheit zurückgeleitet. Wenn für die empfangene
Anforderung keine Beendigung erwartet wird, dann wird in Block 1030 eine Fehlermitteilung
an die anfordernde Einheit gesendet. In Block 1040 wird
der Fehler dem System gemeldet. Die Operation des Sendens der Fehlermitteilung,
welche in Block 1030 dargestellt ist, kann als programmierbare
Option verwirklicht werden.
-
Einige
Systeme können
zusätzlich
zu der zuvor beschriebenen verbesserten allgemeinen Eingabe/Ausgabe-Verbindungsarchitektur
einen oder mehrere PCI-Busse enthalten. Für Speicher-, E/A- und Konfigurationsanforderungen,
welche durch die verbessere allgemeine Eingabe/Ausgabe-Verbindungsarchitektur wandern
und für
eine Einheit auf einem PCI-Bus bestimmt sind, stellt in diesen Ausführungsformen
der Beendigungsstatus den gegenwärtigen
PCI-Abbruch für
den Zyklus dar. Zum Beispiel muß ein
nicht gesendeter PCI-Zyklus gegenwärtig auf dem PCI-Bus bedient
werden, bevor ein Beendigungsstatus ermittelt werden kann. Für alle anderen
Fälle sind
die Werte des Beendigungsstatus wie unten beschrieben definiert.
-
Wenn
eine Anforderung von der Beendigungseinheit erfolgreich beendet
worden ist, lautet der resultierende Wert des Beendigungsstatus „Erfolgreiche
Beendigung" (in
dieser Ausführungsform
im Beendigungsstatusfeld als „000" codiert, wie in
Tabelle 3 dargestellt). Zum Beispiel wird eine Leseanforderung von
einer Host Bridge über
einen Schalter zu einem Endpunkt einer Beendigungseinheit geleitet.
Die Beendigungseinheit reagiert antwortet mit einem Beendigungspaket,
welches den Status einer erfolgreichen Beendigung anzeigt, und antwortet
auch mit den Daten für
die Leseanforderung. Der Schalter leitet dieses Beendigungspaket zurück zu der
Host Bridge.
-
Wenn
eine Anforderung von der beendigenden Einheit empfangen und decodiert
wird, die beendigende Einheit die angeforderte Transaktion aber
nicht unterstützt
und die Anforderung eine Beendigung erfordert, dann lautet der resultierende
Beendigungsstatus „Nicht
unterstützte
Anforderung" (in
dieser Ausführungsform im
Beendigungsstatusfeld als „001" codiert, wie in
Tabelle 3 dargestellt). Ein Beispiel für eine nicht unterstützte Anforderung
wäre eine
Speicherleseanforderung an eine unerreichbare Adresse. In diesem
Fall kann die Beendigungseinheit die Anforderung nicht unterstützen, und
die Anforderungseinheit erwartet eine Beendigung.
-
Für den Fall,
daß eine
Anforderung von der beendigenden Einheit empfangen und decodiert
wird und die beendigende Einheit die angeforderte Transaktion nicht
unterstützen
kann und die anfordernde Einheit keine Beendigung erwartet, ist
der resultierende Beendigungsstatus eine nicht unterstützte Anforderung.
Da die anfordernde Einheit keine Beendigung erwartet, wird der Beendigungsstatus über eine
Mitteilung an die anfordernde Einheit übermittelt, wie oben in Verbindung
mit 10 beschrieben. Ein Beispiel für eine nicht unterstützte Anforderung,
bei welcher die anfordernde Einheit keine Beendigung erwartet, ist
eine Speicherschreibtransaktion an eine unerreichbare Adresse. Die Übermittlung
des Beendigungsstatus über
eine Mitteilung kann als optionales Merkmal verwirklicht werden.
-
Wenn
eine beendigende Einheit eine Anforderung empfängt und decodiert, die beendigende
Einheit aber aufgrund eines internen Fehlers nicht antworten kann,
lautet der resultierende Beendigungsstatus „Abbruch der Beendigungseinheit" (in dieser Ausführungsform
im Beendigungsstatusfeld als „100" codiert).
-
Wenn
eine beendigende Einheit ein Paket empfängt, das Paketbildungsregeln
verletzt, ist das Ergebnis ein „Fehlgebildetes Paket". Die beendigende
Einheit antwortet auf diese Situation, indem sie eine Fehlermitteilung „Fehlgebildetes
Paket" übermittelt,
welche zu der anfordernden Einheit geleitet wird. Ein Schalter, welcher
ein fehlgebildetes Paket empfängt,
muß in
dieser Ausführungsform
das Paket zu dem stromaufwärts gelegenen
Anschluß leiten,
wenn kein anderer Anschluß positiv
als der vorgesehene Zielanschluß identifiziert werden
kann.
-
Wenn
eine Lesebeendigung einen anderen Beendigungsstatus als „Erfolgreiche
Beendigung" aufweist,
werden mit dem Beendigungspaket keine Daten zurückgesendet. Die Lesebeendigung
mit dem nicht erfolgreichen Beendigungsstatus ist die letzte Beendigung,
die für
die Anforderung übermittelt
wird. Zum Beispiel kann eine Beendigungseinheit eine Leseanforderung
zur Bedienung in vier Teile aufteilen, und das zweite Beendigungspaket
führt zu
dem Beendigungsstatus „Abbruch
der Beendigungseinheit".
Die letzten beiden Beendigungspakete werden nicht übermittelt.
Die anfordernde Einheit betrachtet die Anforderung als beendet, wenn
sie das Beendigungspaket mit dem nicht erfolgreichen Beendigungsstatus
empfängt,
und sollte keine weiteren Beendigungspakete erwarten, die dieser
Leseanforderung entsprechen.
-
11 ist
ein Flußdiagramm
einer Ausführungsform
eines Verfahrens zur Behandlung eines Beendigungspaketes, welches
von einem Systemagenten nicht erwartet wird. Eine „unerwartete
Beendigung" tritt
auf, wenn ein Agent eine Beendigung empfängt, welche nicht irgendwelchen
unerledigten Anforderungen entspricht, die von demselben Agenten
ausgegeben wurden. In dem beispielhaften Verfahren der 11 zeigt Block 1110 an,
daß dann,
wenn keine unerwartete Beendigung vorliegt, die normale Operation
in Block 1120 fortgesetzt wird. Wenn jedoch eine unerwartete
Beendigung empfangen wird, wird das unerwartete Beendigungspaket
in Block 1130 verworfen. Nachdem das Paket verworfen ist,
kann in Block 1140 die obige Fehlerbedingung an das System
gemeldet werden. In diesem Ausführungsbeispiel
kann die Meldung des Fehlers eine Option sein, die durch Software
programmierbar ist.
-
12 ist
ein Flußdiagramm
einer Ausführungsform
eines Verfahrens für
eine anfordernde Einheit, welche ein Beendigungspaket mit einem
anderen Beendigungsstatus als „Erfolgreiche
Beendigung" behandelt.
Block 1210 zeigt an, daß dann, wenn der Beendigungsstatus „Erfolgreiche
Beendigung" ist,
die normale Operation in Block 1220 fortgesetzt wird. Wenn
der Beendigungsstatus ein anderer als „Erfolgreiche Beendigung" ist, dann wird in
Block 1230 der Wert des Beendigungseinheits-Kennungsfeldes
aufgenommen. In dieser Ausführungsform
wird der Wert der Beendigungseinheitskennung in einem Register gespeichert.
Dann wird in dieser Ausführungsform
in Block 1240 ein Bit „Empfangene Nicht Erfolgreiche
Beendigung" in einem Register
in der anfordernden Einheit eingestellt. In Block 1250 kann
die obige Fehlerbedingung gemeldet werden. Die Meldung der Fehlerbedingung
kann als programmierbare Option verwirklicht werden. Ein Softwareagent
kann den Beendigungseinheits-Kennungswert und das Bit „Empfangene
Nicht Erfolgreiche Beendigung" verwenden,
um die Quelle für
die Fehlerbedingung zurückzuverfolgen.
-
13 ist
ein Flußdiagramm
einer Ausführungsform
eines Verfahrens für
eine beendigende Einheit, welche ein Beendigungspaket mit einem
anderen Beendigungsstatus als „Erfolgreiche
Beendigung" behandelt.
Block 1310 zeigt an, daß dann, wenn der Beendigungsstatus
eines übermittelten
Beendigungspaketes „Erfolgreiche
Beendigung" ist,
die normale Operation in Block 1320 fortgesetzt wird. Wenn
der Beendigungsstatus ein anderer als „Erfolgreiche Beendigung" ist, dann wird in
Block 1330 der Wert der Anforderungseinheitskennungs- und
der Markierungsfelder aufgenommen. In dieser Ausführungsform
werden die Werte der Anforderungseinheitskennung und der Markierung
in einem oder mehreren Registern gespeichert. Dann wird in dieser
Ausführungsform
in Block 1340 ein Bit „Übermittelte Nicht Erfolgreiche
Beendigung" in einem
Register in der beendigenden Einheit eingestellt. In Block 1350 kann
die obige Fehlerbedingung gemeldet werden. Die Meldung der Fehlerbedingung
kann als programmierbare Option verwirklicht werden. Ein Softwareagent kann
die Anforderungseinheitskennungs- und Markierungswerte und das Bit „Übermittelte
Nicht Erfolgreiche Beendigung" verwenden,
um die Quelle für
die Fehlerbedingung zurückzuverfolgen.
-
In
der vorstehenden Beschreibung ist die Erfindung mit Bezug auf spezielle
Ausführungsbeispiele
beschrieben worden. Es wird jedoch ersichtlich sein, daß daran
verschiedene Modifikationen und Veränderungen vorgenommen werden
können,
ohne den weiteren Umfang der Erfindung zu verlassen, wie er in den
beigefügten
Patentansprüchen
ausgeführt
ist. Die Beschreibung und die Zeichnungen sind dementsprechend als Veranschaulichung
und nicht als Beschränkung
anzusehen.
-
Bezugnahmen
in der Beschreibung auf „eine
Ausführungsform", „einige
Ausführungsformen" oder „andere
Ausführungsformen" bedeuten, daß ein bestimmtes
Merkmal, eine Struktur oder eine Eigenschaft, die in Verbindung
mit den Ausführungsformen
beschrieben ist, in zumindest einigen Ausführungsformen enthalten ist,
aber nicht notwendigerweise in allen Ausführungsformen der Erfindung.
Das verschiedene Auftreten von „eine Ausführungsform" oder „einige Ausführungsformen" bezieht sich nicht
notwendigerweise jedesmal auf dieselbe Ausführungsform.
