DE60219047T2

DE60219047T2 - Eine allgemeine eingabe-/ausgabearchitektur und entsprechende verfahren zum aufbau virtueller kanäle darin

Info

Publication number: DE60219047T2
Application number: DE60219047T
Authority: DE
Inventors: Jasmin Portland Ajanovic; David Portland HARRIMAN
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2001-09-30
Filing date: 2002-09-27
Publication date: 2007-12-13
Anticipated expiration: 2022-09-28
Also published as: KR100611268B1; US6993611B2; DE60219047D1; CN100416528C; ATE357696T1; US6691192B2; EP1433067B1; EP1433067A1; WO2003029995A1; HK1063091A1; KR20040037215A; US20030115391A1; CN1561490A; US20040044820A1

Description

PRIORITÄT
Die vorliegende Anmeldung beansprucht ausdrückliche Priorität gegenüber der vorläufigen US-Anmeldungsnr. 60/314,708 mit dem Titel A High-speed, Point-to-Point-Interconnection and Communication Architecture, Protocol and Related Methods, die am 26. August 2001 von Ajanovic et al. eingereicht wurde und dem Zessionär der vorliegenden Anmeldung zugewiesen wurde.
TECHNISCHES GEBIET
Allgemein betrifft diese Erfindung allgemeine Eingabe-/Ausgabearchitektur und insbesondere die Punkt-zu-Punkt-Verbindungen hoher Geschwindigkeit und eine Kommunikationsarchitektur, ein Protokoll und verwandte Verfahren.
HINTERGRUND
Rechnungseinrichtungen, z.B. Computersysteme, Server, Netzwerkschalter und Router, Funkkommunikationsvorrichtungen und dergleichen bestehen in der Regel aus einer Reihe einzelner Elemente. Zu solchen Elementen zählen oftmals ein Prozessor, eine Mikrosteuerung oder andere Steuerlogik, ein Speichersystem, Eingabe- und Ausgabeschnittstelle(n) und dergleichen. Zur Erleichterung der Kommunikation zwischen derartigen Elementen stützten sich Rechnungseinrichtungen lange Zeit auf einen allgemeine Eingabe-/Ausgabe-(GIO)-Bus, um zu ermöglichen, daß diese getrennten Elemente des Rechnungssystems miteinander kommunizieren, um die vielzähligen Anwendungen, die durch solche Einrichtungen geboten werden, zu unterstützen.
Die womöglich am weitesten verbreitete derartiger herkömmlicher GIO-Bus-Architekturen ist die Peripheriekomponentenverbindungs- oder PCI-Busarchitektur. In dem PCI-Bus-Standard (Peripheral Component Interconnect (PCI) Local Bus Specification, Rev. 2.2, herausgegeben am 18. Dezember 1998) wird eine Mehrfachabgabe-Parallelbusarchitektur zum willkürlichen Verbinden von Chips, Speicherkarten und Prozessor/Speicher-Untersystemen in einer Rechnungseinrichtung definiert. Während herkömmliche PCI-Busimplementationen einen Durchsatz von 133 Mbps (d.h. 32 Bit bei 33 MHz) aufweisen, ermöglicht der Standard PCI 2.2 64 Bit pro Pin der Parallelverbindung, die bei bis zu 133 MHz getaktet ist, wodurch ein theoretischer Durchsatz von etwas über 1 Gbps ermöglicht wird.
In dieser Hinsicht hat der durch derartige herkömmliche Mehrfachablage-PCI-Busarchitekturen bereitgestellte Durchsatz bis vor kurzem ausreichende Bandbreite bereitgestellt, um den internen Kommunikationsanforderungen auch der fortgeschrittensten Rechnungseinrichtungen gerecht zu werden (z.B. Mehrfachprozessorserveranwendungen, Netzwerkanwendungen usw.). Vor dem Hintergrund der neuesten Fortschritte in der Verarbeitungsleistung, die die Verarbeitungsgeschwindigkeiten über den Schwellwert von 1 GHz anheben, verbunden mit dem weitverbreiteten Einsatz von Breitbandinternetzugang wurden herkömmliche GIO-Architekturen wie die PCI-Busarchitektur zu einer Engstelle in solchen Rechnungseinrichtungen.
Eine weitere mit herkömmlichen GIO-Architekturen verbundene Beschränkung besteht darin, daß sie sich in der Regel nicht gut zur Handhabung/Verarbeitung isochroner (oder zeitabhängiger) Datenströme eignen. Ein Beispiel eines solchen isochronen Datenstroms sind Multimediendatenströme, welche einen isochronen Transportmechanismus erfordern, um sicherzustellen, daß die Daten so schnell verbraucht werden, wie sie empfangen werden, und daß der Audioanteil mit dem Videoanteil synchronisiert wird. Herkömmliche GIO-Architekturen verarbeiten Daten asynchron oder in Zufallsintervallen, wie es die Bandbreite ermöglicht. Eine solche asynchrone Verarbeitung isochroner Daten kann zu falschausgerichteten Audio- und Videoteilen führen und deshalb haben bestimmte Provider isochroner Medien Regeln, welche bestimmten Daten gegenüber anderen Priorität verleihen, z.B. Audiodaten gegenüber Videodaten Priorität verleihen, so daß mindestens der Endnutzer einen relativ gleichförmigen (d.h. nicht unterbrochenen) Audiostrom erhält, so daß er das übermittelte Lied genießen, die Geschichte verstehen kann usw.
In der US-Patentschrift 5,953,338 werden dynamische Steuerprozesse und -systeme für asynchrone Transfermodusnetzwerke offenbart. Die US-Patentschrift 6,266,345 betrifft ein Verfahren und eine Vorrichtung für die dynamische Zuweisung von Bandbreite an Daten unter schiedlicher Bitraten. In der Richtlinie Infiniband Architektur wird eine kanalbasierte geschaltete Verbindungsarchitektur nach Industrienorm für Server offenbart.
Die Erfindung ist wie in den beigefügten unabhängigen Ansprüchen 1 und 18 dargelegt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird beispielhaft und nicht notwendigerweise einschränkend in den Figuren der beigefügten Zeichnungen dargestellt, in denen ähnliche Bezugszahlen sich auf ähnliche Elemente beziehen.
1 ist ein Blockdiagramm einer elektronischen Einrichtung, welche einen oder mehrere Aspekte der vorliegenden Erfindung zur Erleichterung von Kommunikation zwischen einem oder mehreren Elementen, umfassend die Vorrichtung, in Übereinstimmung mit den Lehren der vorliegenden Erfindung umfaßt;
2 ist eine graphische Darstellung eines beispielhaften Kommunikationsstapels, der durch ein oder mehrere Elemente der elektronischen Vorrichtung zur Erleichterung der Kommunikation zwischen solchen Elementen in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung eingesetzt wird;
3 ist eine graphische Darstellung eines beispielhaften Transaktionsbeschreibers, der in Übereinstimmung mit den Lehren der vorliegenden Erfindung dargestellt wird;
4 ist eine graphische Darstellung einer beispielhaften Kommunikationsstrecke, welchen einen oder mehrere virtuelle Kanäle zur Erleichterung der Kommunikation zwischen einem oder mehreren Elementen der elektronischen Vorrichtung gemäß einem Aspekt der vorliegenden Erfindung umfaßt;
5 ist ein Blockdiagramm eines beispielhaften Kommunikationsagenten zur Implementation eines oder mehrerer Aspekte der vorliegenden Erfindung gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung;
6 ist ein Blockdiagramm verschiedener Paketheaderformate, die in der Transaktionsschicht der vorliegenden Erfindung verwendet werden;
7 ist ein Blockdiagramm einer beispielhaften Speicherarchitektur, die zur Erleichterung eines oder mehrerer Aspekte der vorliegenden Erfindung gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung eingesetzt wird;
8 ist ein Zustandsdiagramm einer beispielhaften Verbindungszustandsmaschine gemäß einem Aspekt der vorliegenden Erfindung;
9 ist ein Blockdiagramm eines zugänglichen Mediums, welches Inhalt enthält, der, wenn von einer elektronischen Vorrichtung auf ihn zugegriffen wird, einen oder mehrere Aspekte der vorliegenden Erfindung implementiert; und
10 ist ein Flußdiagramm eines beispielhaften Verfahrens zum Errichten virtueller Kanäle in einer allgemeinen Eingabe-/Ausgabebusarchitektur gemäß einem Aspekt der vorliegenden Erfindung.
AUSFÜHRLICHE BESCHREIBUNG
Diese Erfindung bezieht sich allgemein auf eine innovative Punkt-zu-Punkt-Verbindungsarchitektur, ein Kommunikationsprotokoll und verwandte Verfahren zum Bereitstellen einer skalierbaren erweiterbaren allgemeinen Eingabe-/Ausgabe-(E/A)-Kommunikationsplattform zum Einsatz in einer elektronischen Vorrichtung. In dieser Hinsicht wird eine innovative erweiterte allgemeine Eingabe-/Ausgabe-(EGIO)-Verbindungsarchitektur und ein damit verbundenes EGIO-Kommunikationsprotokoll eingeführt. Gemäß einer beispielhaften Ausführungsform enthalten die getrennten Elemente einer EGIO-Architektur eine Hostbrücke, einen Schalter und/oder Endstellen, die jeweils mindestens einen Teilsatz der EGIO-Merkmale zur Unterstützung der EGIO-Kommunikation zwischen solchen Elementen enthalten.
Die Kommunikation zwischen den EGIO-Einrichtungen solcher Elemente wird unter Verwendung serieller Kommunikationskanal/-kanäle durch Einsetzen eines innovativen EGIO-Kommunikationsprotokolls ausgeführt, welches wie im folgenden weiter dargelegt werden wird, eines oder mehrere innovative Merkmale unterstützt, einschließlich, jedoch nicht beschränkt auf virtuelle Kommunikationskanäle, tailerbasierte Fehlerweiterleitung, Unterstützung von Altgeräten auf PCI-Basis, Mehrfachanforderungs-Antwortart(en), Durchflußsteuerungs- und/oder Datenintegritätsmanagementsvorrichtungen. Gemäß einem Aspekt der Erfindung wird das Kommunikationsprotokoll in jedem der Elemente der Rechnungseinrichtung unterstützt, wobei ein EGIO-Kommunikationsprotokollstapel eingeführt wird, wobei der Stapel eine physikalische Schicht, eine Datenverbindungsschicht und eine Transaktionsschicht umfaßt.
Gemäß einer alternativen Implementation wird ein Kommunikationsagent eingeführt, der eine EGIO-Maschine umfassend mindestens einen Teilsatz der vorgenannten Merkmale enthält. Aus der folgenden Erörterung wird ersichtlich sein, daß der Kommunikationsagent auch von Altergeräteelementen einer elektronischen Vorrichtung verwendet werden kann, um die Kommunikationsprotokollanforderungen der vorliegenden Erfindung in eine ansonsten nicht mit EGIO-Verbindungen kompatible Architektur einzuführen. Vor dem Hintergrund der vorherigen Bemerkungen und der folgenden Beschreibung wird es Fachleuten klar sein, daß ein oder mehrere Elemente der vorliegenden Erfindung auch in Hardware, Software, einem verteilten Signal oder einer Kombination daraus implementiert werden kann.
In der gesamten Beschreibung bedeutet die Bezugnahme auf „eine Ausführungsform", daß ein bestimmtes Merkmal, Struktur oder Eigenschaft, die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Das Auftreten der Formulierung „in einer Ausführungsform" an verschiedenen Stellen in der gesamten Beschreibung bezieht sich somit nicht notwendigerweise immer auf dieselbe Ausführungsform. Die besonderen Merkmale, Strukturen oder Eigenschaften können außerdem auf jede geeignete Weise in einer oder mehreren Ausführungsformen kombiniert werden.
TERMINOLOGIE
Bevor auf die Besonderheiten der innovativen EGIO-Verbindungsarchitektur und des Kommunikationsprotokolls näher eingegangen wird, ist es sinnvoll, die Elemente des Vokabulars einzuführen, welches in der gesamten ausführlichen Beschreibung verwendet wird.

• Bekanntgeben: Im Kontext der EGIO-Durchflußsteuerung verwendet, um auf den Vorgang Bezug zu nehmen, in dem ein Empfänger Informationen hinsichtlich seiner Durchflußsteuerungs-Punkteverfügbarkeit sendet, indem er eine Durchflußsteuerungs-Aktualisierungsnachricht des EGIO-Protokolls verwendet;
• Vervollständiger: Eine logische Vorrichtung, die durch eine Anforderung adressiert wird;
• Vervollständiger-Kennung: Eine Kombination aus einer Buskennung (z.B. Nummer) eines Vervollständigers einer Vorrichtungskennung und/oder einer Funktionskennung, welche den Vervollständiger der Anforderung eindeutig identifiziert;
• Vervollständigung: Ein Paket, das zum Beenden oder zum teilweisen Beenden einer Sequenz verwendet wird, wird als Vervollständigung bezeichnet. Gemäß einer beispielhaften Implementation entspricht eine Vervollständigung einer vorhergehenden Anforderung und enthält in einigen Fällen Daten;
• Konfigurationsraum: Einer der vier Adressräume in der EGIO-Architektur. Pakete mit einer Konfigurationsraumadresse werden zum Konfigurieren einer Vorrichtung verwendet;
• Komponente: Eine physikalische Vorrichtung (d.h. in einem einzigen Paket);
• Datenverbindungsschicht: Die Zwischenschicht der EGIO-Architektur, welche zwischen der Transaktionsschicht (oben) und der physikalischen Schicht (unten) liegt;
• DLLP: Das Datenverbindungsschichtpaket ist ein Paket, das in der Datenverbindungsschicht zum Unterstützen der Verbindungsmanagementfunktionen erzeugt wird;
• Stromabwärts: Bezieht sich entweder auf die relative Position eines Elements oder auf den Informationsstrom von der Hostbrücke weg;
• Endpunkt: Eine EGIO-Vorrichtung mit einem Konfigurationsraumheader vom 00h-Typ;
• Durchflußsteuerung: Ein Verfahren zum Kommunizieren von Empfangspufferinformationen von einem Empfänger an einen Sender, um das Überströmen des Empfangspuffers zu verhindern, um das Übereinstimmen des Senders mit Sortierregeln zu ermöglichen;
• Durchflußsteuerungspaket (FCP): Transaktionsschichtpaket (TLP), das zum Senden von Durchflußsteuerungsinformationen von der Transaktionsschicht einer Komponente an eine Transaktionsschicht einer anderen Komponente verwendet wird;
• Funktion: Ein unabhängiger Abschnitt einer Mehrfachfunktionsvorrichtung, der in dem Konfigurationsraum durch eine eindeutige Funktionskennung (z.B. eine Funktionsnummer) identifiziert wird;
• Hierarchie: Definiert die in der EGIO-Architektur implementierte E/A-Verbindungstopologie. Eine Hierarchie wird durch eine einzige Hostbrücke charakterisiert, die der Verbindung entspricht, welche der numerierenden Vorrichtung (z.B. der Host-CPU) am nächsten ist;
• Hierarchiebereich: Eine EGIO-Hierarchie wird durch eine Hostbrücke in mehrere Fragmente unterteilt, welche für mehr als eine EGIO-Schnittstelle die Quelle bildet, wobei solche Fragmente als Hierarchiebereich bezeichnet werden;
• Hostbrücke: Verbindet einen Host-CPU-Komplex mit einer oder mehreren EGIO-Verbindungen;
• E/A-Raum: Einer der vier Adressräume der EGIO-Architektur;
• Spur: Gruppe von Differenzialsignalpaaren der physikalischen Verbindung, wobei ein Paar zum Senden und ein Paar zum Empfangen bestimmt ist, eine N-Schnittstelle besteht aus N Spuren;
• Strecke: eine Dual-Simplex-Kommunikationsstrecke zwischen zwei Komponenten, Sammlung von zwei Ports (einer zum Senden und einer zum Empfangen) und ihre verbindende(n) Spur(en);
• Logischer Bus: Logische Verbindung zwischen einer Sammlung von Vorrichtung, die dieselbe Busnummer im Konfigurationsraum aufweisen;
• Logische Vorrichtung: Element einer EGIO-Architektur, welche auf eine eindeutige Vorrichtungskennung in dem Konfigurationsraum anspricht;
• Speicherraum: Einer der vier Adressräume in der EGIO-Architektur. Spezielle Zyklen, wie in PCI definiert, sind als ein Teilsatz des Nachrichtenraums enthalten und stellen dementsprechend eine Schnittstelle zu Altgeräten bereit;
• Altgerätesoftwaremodell(e): Das/die Softwaremodell(e), das/die notwendig ist/sind, um eine Altgerätevorrichtung zu initialisieren, zu entdecken, zu konfigurieren und zu verwenden (z.B. Einschluß des PCI-Softwaremodells in beispielsweise eine EGIO-zu-Altgeräte-Brücke ermöglicht die Wechselwirkung mit Altgeräten);
• Physikalische Schicht: Schicht der EGIO-Architektur, welche eine direkte Schnittstelle mit dem Kommunikationsmedium zwischen den beiden Komponenten bildet;
• Port: Eine Schnittstelle, die mit einer Komponente verbunden ist und sich zwischen dieser Komponente und einer EGIO-Strecke befindet;
• Empfänger: Die Komponente, welche Paketinformationen über eine Strecke empfängt, ist der Empfänger (manchmal als Ziel bezeichnet);
• Anforderung: Ein Paket, das zum Initiieren einer Sequenz verwendet wird, wird als Anforderung bezeichnet. Eine Anforderung enthält einen Operationscode und in einigen Fällen eine Adresse und eine Länge, Daten oder andere Informationen;
• Anforderer: eine logische Vorrichtung, welche als erstes eine Sequenz in den EGIO-Bereich einführt;
• Anforderer-Kennung: Eine Kombination aus der Buskennung des Anforderers (z.B. Busnummer), der Vorrichtungskennung und/oder einer Funktionskennung, welche den Anforderer eindeutig identifiziert. In den meisten Fällen leitet eine EGIO-Brücke oder ein Schalter die Anforderungen von einer Schnittstelle an eine andere weiter, ohne sie zu modifizieren. Eine Brücke von einem anderen Bus als einem EGIO-Bus sollte in der Regel die Anfordererkennung zur Verwendung beim Erzeugen einer Vervollständigung für diese Anforderung speichern;
• Sequenz: Eine einzige Anforderung und keine oder mehrere Vervollständigungen, die mit dem Ausführen eines einzigen logischen Transfers durch einen Anforderer verbunden sind;
• Sequenz-Kennung: Eine Kombination aus einer Anfordererkennung und/oder einem Tag, wobei die Kombination die Anforderungen und Vervollständigungen, die Teil einer gemeinsamen Sequenz sind, eindeutig kennzeichnet;
• Spalttransaktion: Ein einziger logischer Transfer, der eine Anfangstransaktion (die Spaltungsanforderung) enthält, welche das Ziel (den Vervollständiger oder die Brücke) mit einer Spaltantwort beendet, gefolgt von einer oder mehreren Transaktionen (der Spaltvervollständigungen), die durch den Vervollständiger (oder der Brücke) initiiert werden und die gelesenen Daten (wenn es sich um ein Lesen handelt) oder eine Vervollständigungsnachricht an den Anforderer zurücksenden;
• Symbol: Eine Menge von 10 Bit, die als das Ergebnis der 8b/10b-Codierung erzeugt wird;
• Symbolzeit: Die Zeitdauer, die notwendig ist, um ein Symbol auf einer Spur zu platzieren;
• Tag: Eine Zahl, welche einer gegebenen Sequenz durch den Anforderer zugewiesen wurde, um sie von anderen Sequenzen zu unterscheiden, Teil der Sequenzkennung;
• Transaktionsschichtpaket: TLP ist ein Paket, welches in der Transaktionsschicht erzeugt wird, um eine Anforderung oder Vervollständigung zu übermitteln;
• Transaktionsschicht: Die äußerste (oberste) Schicht der EGIO-Architektur, welche auf dem Transaktionsniveau operiert (z.B. Lesen, Schreiben usw.);
• Transaktionsbeschreiber: Element eines Paketheaders, welches zusätzlich zu der Adresse, Länge und der Art die Eigenschaften einer Transaktion beschreibt.

BEISPIELHAFTE ELEKTRONISCHE VORRICHTUNG
1. ist ein Blockdiagramm einer vereinfachten elektronischen Vorrichtung 100, die eine unterstützte allgemeine Eingabe-/Ausgabe-(EGIO)-Busarchitektur, ein Protokoll und verwandte Verfahren in Übereinstimmung mit den Lehren der vorliegenden Erfindung enthält. Gemäß dem in 1 gezeigten Beispiel wird die elektronische Vorrichtung 100 so dargestellt, daß sie einen oder mehrere Prozessor/Prozessoren, eine Hostbrücke 104, Schalter 108 und Endpunkte 110 enthält, welche jeweils wie gezeigt gekoppelt sind. Gemäß den Lehren der vorliegenden Erfindung ist mindestens die Hostbrücke 104, der/die Schalter 108 und die Endpunkte 110 mit einem oder mehreren Beispielen einer EGIO-Kommunikationsschnittstelle 106 ausgestattet, um einen oder mehrere Aspekte der vorliegenden Erfindung zu ermöglichen.
Wie gezeigt ist jedes der Elemente 102, 104, 108 und 110 kommunikativ an mindestens ein anderes Element über eine Kommunikationsstrecke 112 gekoppelt, welche einen oder mehrere EGIO-Kommunikationskanal/-kanäle über die EGIO-Schnittstelle 106 unterstützen. Wie oben dargestellt, soll die elektronische Vorrichtung 100 eines oder mehrere einer Vielzahl herkömmlicher und nicht herkömmlicher Rechnungssysteme, Server, Netzwerkschalter, Netzwerkrouter, Funkkommunikationsteilnehmereinheiten, Funkkommunikationstelefonie-Infrastrukturelementen, Personal Digital Assistants, Set-top Boxen und andere elektronische Vorrichtungen darstellen, welche von den Kommunikationsressourcen, die durch die Integration mindestens eines Teilsatzes der EGIO-Verbindungsarchitektur, des Kommunikationsprotokolls oder verwandter Verfahren, die hierin beschrieben werden, profitiert.
In Übereinstimmung mit der in 1 dargestellten beispielhaften Implementation ist die elektronische Vorrichtung 100 mit einem oder mehreren Prozessor(en) 102 ausgestattet. Wie hierin verwendet, kontrolliert/kontrollieren der/die Prozessor(en) 102 einen oder mehrere Aspekte der Funktionsfähigkeit der elektronischen Vorrichtung 100. In dieser Hinsicht ist der Prozessor/sind die Prozessoren 102 repräsentativ für jeden einer Vielzahl von Steuerlogik, ein schließlich, aber nicht beschränkt auf einen oder mehrere Mikroprozessoren, programmierbare logische Vorrichtungen (PLD), programmierbarer logischer Array, anwendungsspezifische integrierte Schaltungen (ASIC), Mikrosteuerung und dergleichen.
Die Hostbrücke 104 stellt eine Kommunikationsschnittstelle zwischen dem Prozessor 102 und/oder einem Prozessor/Speicherkomplex und einem oder mehreren anderen Elementen 108, 110 der elektronischen Vorrichtungs-EGIO-Architektur bereit und ist in dieser Hinsicht die Wurzel der EGIO-Architekturhierarchie. Wie hierin verwendet, bezieht sich Hostbrücke 104 auf eine logische Gruppe einer EGIO-Hierarchie, welche einer Hoststeuerung, einem Speichersteuerungshub, einem E/A-Steuerungshub oder jeder Kombination aus den vorgenannten Elementen oder einer Kombination aus Chipset/CPU-Elementen (d.h. in einer Rechnungssystemumgebung) am nächsten ist. Obwohl in 1 als einzige Einheit dargestellt, kann die Hostbrücke 104 in dieser Hinsicht auch als eine einzige logische Gruppe gedacht sein, die mehrere physikalische Komponenten aufweisen kann. Gemäß der dargestellten beispielhaften Implementation aus 1 ist die Hostbrücke 104 mit einer oder mehreren EGIO-Schnittstellen 106 bevölkert, um die Kommunikation mit anderen Peripheriegeräten, z.B. Schalter(n) 108, Endstelle(n) 110, und, obwohl nicht gesondert dargestellt, Altgerätebrücke(n) 114 oder 116, zu erleichtern. Gemäß einer Implementation stellt jede EGIO-Schnittstelle 106 einen unterschiedlichen EGIO-Hierarchiebereich dar. Die in 1 dargestellte Implementation bezeichnet in dieser Hinsicht eine Hostbrücke 104 mit drei (3) Hierarchiebereichen. Es sei darauf hingewiesen, daß obwohl mit mehreren separaten EGIO-Schnittstellen 106 dargestellt, alternative Implementationen vorgesehen sind, in denen eine einfache Schnittstelle 106 mit mehreren Ports ausgestattet ist, um die Kommunikation mit mehreren Vorrichtungen zu ermöglichen.
Gemäß den Lehren der vorliegenden Erfindung weisen die Schalter 108 mindestens einen stromaufwärtigen Port (d.h. in Richtung zu der Hostbrücke 104) und mindestens einen stromabwärtigen Port auf. Gemäß einer Implementation unterscheidet ein Schalter 108 einen Port (d.h. einen Port einer Schnittstelle oder die Schnittstelle 106 selbst), welcher der Hostbrücke als der stromaufwärtige Port am nächsten ist, während alle anderen Port(s) stromabwärtige Ports sind. Gemäß einer Implementation erscheinen die Schalter 108 der Konfigurationssoftware (z.B. Altgerätekonfigurationssoftware) als eine PCI-zu-PCI-Brücke und verwenden PCI-Brückenmechanismen zum Weiterleiten von Transaktionen.
Im Zusammenhang mit den Schaltern 108 werden Peer-to-Peer-Transaktionen als Transaktionen definiert, für die der Empfangs- und der Sendeport jeweils stromabwärtige Ports sind. Gemäß einer Implementation unterstützen die Schalter 108 das Weiterleiten aller Arten von Transaktionsschichtpaketen (TLP) außer jenen, die einer verriegelten Transaktionssequenz von jedem Port zu jedem anderen Port verwenden. Alle Rundsendenachrichten sollten in der Regel von dem empfangenden Port zu allen an deren Ports an dem Schalter 108 weitergeleitet werden. Ein Transaktionsschichtpaket, welches nicht an einen Port weitergeleitet werden kann, sollte in der Regel als ein nicht unterstütztes TLP durch den Schalter 108 beendet werden. Die Schalter 108 verändern das/die Transaktionsschichtpaket(e) (TLP) beim Übertragen von dem empfangenden Port an den sendenden Port in der Regel nicht, es sei denn solche Abänderungen sind notwendig, um mit einer anderen Protokollanforderung für den sendenden Port übereinzustimmen (z.B. wenn der sendende Port mit einer Altgerätebrücke 114, 116 gekoppelt ist).
Es versteht sich, daß die Schalter 108 für andere Einrichtungen agieren und in dieser Hinsicht keine vorherige Kenntnis von Trafficarten und -mustern haben. Gemäß einer Implementation, die im folgenden ausführlicher erörtert wird, werden die Durchflußsteuerungs- und Datenintegritätsaspekte der vorliegenden Erfindung auf einer Basis pro Verbindung implementiert und nicht auf einer Ende-zu-Ende-Basis. In Übereinstimmung mit einer solchen Implementation nehmen die Schalter 108 somit an Protokollen teil, die zur Durchflußsteuerung und für die Datenintegrität verwendet werden. Um an der Durchflußsteuerung teilzunehmen, führt der Schalter 108 eine getrennte Durchflußsteuerung für jeden der Ports, um die Leistungsmerkmale des Schalters 108 zu verbessern. Der Schalter 108 unterstützt dementsprechend die Datenintegritätsvorgänge auf einer Basis pro Verbindung, indem jedes in den Schalter eintretende TLP unter Verwendung der TLP-Fehlererkennungsmechanismen untersucht wird, welche im folgenden ausführlicher beschrieben werden. Gemäß einer Implementation sind stromabwärtige Ports eines Schalters 108 zugelassen, um neue EGIO-Hierarchiebereiche zu bilden.
Weiter unter Bezugnahme auf 1 wird ein Endpunkt 110 als jede Vorrichtung mit einem Konfigurationsraumheader vom Typ 00hex (00h) definiert. Endpunktgeräte 110 können entweder ein Anforderer oder ein Vervollständiger einer semantischen EGIO-Transaktion, sei es in eigener Sache oder für eine entfernte nicht-EGIO-Einrichtung, sein. Zu Beispielen solcher Endpunkte 110 gehören, aber nicht beschränkt auf, EGIO-fähige Graphikvorrichtung(en), EGIO-fähige Speichersteuerung und/oder Vorrichtungen, die eine Verbindung zwischen EGIO und anderen Schnittstellen, wie einem USB (Universal Serial Bus), Ethernet und dergleichen implementieren. Anders als eine Altgerätebrücke 114, 116, die im folgenden ausführlicher erörtert werden wird, kann ein Endpunkt 110, der als eine Schnittstelle für nicht-EGIO-fähige Vorrichtungen agiert, möglicherweise keine volle Softwareunterstützung für solche nicht-EGIO-fähigen Vorrichtungen bereitstellen. Während Vorrichtungen, die einen Hostprozessorkomplex 102 mit einer EGIO-Architektur verbinden, als Hostbrücke 104 betrachtet werden, kann es sich tatsächlich um dieselbe Geräteart wie andere Endpunkte 110 handeln, die in der EGIO-Architektur angesiedelt sind, handeln, wobei sie nur durch ihre Position relativ zu dem Prozessorkomplex 102 unterschieden sind.
In Übereinstimmung mit den Lehren der vorliegenden Erfindung können die Endpunkte 110 in eine oder mehrere von drei Kategorien gruppiert werden: (1) Altgeräte und EGIO-fähige Endpunkte, (2) Algeräte-Endpunkte und (3) EGIO-fähige Endpunkte, wobei alle verschiedene Betriebsregeln in der EGIO-Architektur aufweisen.
Wie oben erwähnt unterscheiden sich EGIO-fähige Endpunkte 110 von Altgeräte-Endpunkten (z.B. 118, 120) insofern, als EGIO-Endpunkte 110 einen Konfigurationsraumheader vom Typ 00h aufweisen werden. Jeder solcher Endpunkte (110, 118 und 120) unterstützen Konfigurationsanforderung als ein Vervollständiger. Solche Endpunkte können Konfigurationsanforderungen erzeugen und entweder als ein Altgeräte-Endpunkt oder als ein EGIO-fähiger Endpunkt klassifiziert werden, aber eine solche Klassifikation kann das Einhalten der folgenden zusätzlichen Regeln erfordern.
Altgeräte-Endpunkte (z.B. 118, 120) können E/A-Anforderungen als ein Vervollständiger unterstützen und dürfen E/A-Anforderungen erzeugen. Altgeräte-Endpunkte (118, 120) können Verriegelungssemantik als Vervollständiger erzeugen, wenn dies durch ihre Altgerätesoftwareunterstützungsanforderungen erforderlich ist. Altgeräte-Endpunkte geben in der Regel keine verriegelte Anforderung aus.
EGIO-fähige Endpunkte 110 unterstützen in der Regel keine E/A-Anforderungen als ein Vervollständiger und erzeugen keine E/A-Anforderungen. EGIO-Endpunkte 110 unterstützen keine verriegelten Anforderungen als ein Vervollständiger und erzeugen keine verriegelten Anforderungen als ein Anforderer.
EGIO-zu-Altgeräte-Brücken 114, 116 sind spezialisierte Endpunkte 110, welche wesentliche Softwareunterstützung, z.B. volle Softwareunterstützung, für die Altgerätevorrichtungen (118, 120) enthalten, zu denen sie die Schnittstelle zur EGIO-Architektur bilden. In dieser Hinsicht weist die Altgerätebrücke 114, 116 in der Regel einen stromaufwärtigen Port auf (kann jedoch mehr haben) und mehrere stromabwärtige Ports (kann jedoch nur einen haben). Verriegelte Anforderungen werden in Übereinstimmung mit dem Altgerätesoftwaremodell unterstützt. Ein stromaufwärtiger Port einer Altgerätebrücke 114, 116 sollte die Durchflußsteuerung auf einer Basis pro Verbindung unterstützen und die Durchflußsteuerungs- und Datenintegritätregeln der EGIO-Architektur einhalten, die im folgenden ausführlicher dargestellt werden.
Wie hierin verwendet, soll die Strecke 112 jede Art einer Vielzahl von Kommunikationsmedien repräsentieren, einschließlich, aber nicht beschränkt auf, Kupferleitungen, optische Leitungen, Funkkommunikationskanal/-kanäle, Infrarotkommunikationsstrecken und dergleichen. Gemäß einer beispielhaften Implementation ist eine EGIO-Strecke 112 ein differenzielles Paar serieller Leitungen, wobei ein Paar jeweils das Senden und den Empfang von Kommunikationen unterstützt, wodurch eine Unterstützung für Vollduplexkommunikationsfähigkeit geboten wird. Gemäß einer Implementation stellt die Verbindung eine skalierbare serielle Taktfrequenz mit einer Anfangs-(Basis)-Betriebsfrequenz von 2,5 GHZ bereit. Die Schnittstellenbreite ist pro Richtung von ×1, ×2, ×4, ×8, ×12, ×16, ×32 physikalische Spuren skalierbar. Wie oben erwähnt und im folgenden ausführlicher beschrieben werden wird, kann die EGIO-Strecke 112 sehr wohl mehrere virtuelle Kanäle zwischen Vorrichtungen unterstützen, wodurch Unterstützung für ununterbrochene Kommunikation isochronen Traffics zwischen solchen Vorrichtungen unter Verwendung eines oder mehrerer virtueller Kanäle, z.B. einem Kanal für Audio und einem Kanal für Video unterstützt wird.
BEISPIELHAFTE EGIO-SCHNITTSTELLEN-ARCHITEKTUR
2 ist eine graphische Darstellung einer beispielhaften EGIO-Schnittstellen-Architektur 106, welche durch ein oder mehrere Elemente der elektronischen Vorrichtung zur Vereinfachung von Kommunikation zwischen solchen Elementen gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung eingesetzt wird. In Übereinstimmung mit der dargestellten beispielhaften Implementation aus 2 kann die EGIO-Schnittstelle 106 sehr wohl als ein Kommunikationsprotokollstapel dargestellt werden, welcher eine Transaktionsschicht 202, eine Datenverbindungsschicht 204 und eine physikalische Schicht 208 enthält. Wie ge zeigt wird die physikalische Verbindungsschichtschnittstelle so dargestellt, daß sie einen logischen Unterblock 210, einen physikalischen Unterblock aufweist, wobei, wie gezeigt, jeder davon im folgenden ausführlicher dargestellt werden wird.
Transaktionsschicht
In Übereinstimmung mit den Lehren der vorliegenden Erfindung stellt die Transaktionsschicht 202 eine Schnittstelle zwischen der EGIO-Architektur und einem Vorrichtungskern bereit. In dieser Hinsicht ist die hauptsächliche Verantwortlichkeit der Transaktionsschicht 202 das Zusammensetzen und Auseinandernehmen von Paketen (d.h. Transaktionsschichtpakete oder TLP) für eine oder mehrere logische Vorrichtungen in einer Hostvorrichtung (oder Agent).
Adressräume Transaktionsarten und Verwendung
Die Transaktionen bilden die Basis für den Informationstransfer zwischen einem initiierenden Agenten und einem Zielagenten. Gemäß einer beispielhaften Ausführungsform sind in der innovativen EGIO-Architektur vier Adressräume definiert, einschließlich beispielsweise einem Konfigurationsadressraum, einem Speicheradressraum, einem Eingabe/Ausgabe-Adressraum, einem Nachrichtenadressraum, wobei jeder seine eigene eindeutige beabsichtigte Verwendung aufweist (siehe z.B. 7, unten ausführlicher dargestellt).
Zu Speicherraumtransaktionen (706) gehören eine Leseanforderung und/oder Schreibanforderung zum Übertragen von Daten zu/von einer im Speicher abgebildeten Stelle. Die Speicherraumtransaktionen können zwei unterschiedliche Adressformate verwenden, z.B. kurzes Adressformat (z.B. 32-Bit-Adresse) oder langes Adressformat (z.B. 64-Bit-Adresse). Gemäß einer beispielhaften Ausführungsform sieht die EGIO-Architektur herkömmliche Lese-, Modifizier- und Schreibsequenzen unter Verwendung von Verriegelungsprotokollsemantik bereit (d.h. wobei ein Agent den Zugriff auf modifizierten Speicherraum verwehren kann). Insbesondere ist die Unterstützung für stromabwärtige Verriegelungen in Übereinstimmung mit besonderen Vorrichtungsregeln (Brücke, Schalter, Endpunkt, Altgerätebrücke) erlaubt. Wie oben erwähnt werden solche Verriegelungssemantiken bei der Unterstützung von Altgeräten verwendet.
E/A-Raum-Transaktionen (704) werden für den Zugriff auf in einem E/A-Adressraum abgebildete Eingabe-/Ausgabe-Speicherregister verwendet (z.B. 16-Bit-E/A-Adressraum). Bestimmte Prozessoren 102, wie Intel-Architektur-Prozessoren und andere, enthalten eine E/A-Raumdefinition durch die Gruppe von Anwendungen des Prozessors. Dementsprechend enthalten die E/A-Raumtransaktionen Leseanforderungen und Schreibanforderungen, um Daten von/zu einer in E/A abgebildeten Stelle zu übertragen.
Konfigurationsraumtransaktionen (702) werden für den Zugriff auf Konfigurationsraum der EGIO-Vorrichtungen verwendet. Zu Transaktionen auf den Konfigurationsraum gehören Leseanforderungen und Schreibanforderungen. Insofern herkömmliche Prozessoren keinen nativen Konfigurationsraum enthalten, wird der Raum durch einen Mechanismus, der mit herkömmlichen PC-Konfigurationsraum-Zugriffsmechanismen kompatibel ist, abgebildet (z.B. unter Verwendung eines Konfigurationsmechanismus Nr. 1 auf CFC/CFC8-Basis). Alternativ kann ein Speicheraliasmechanismus für den Zugriff auf Konfigurationsraum verwendet werden.
Nachrichtenraumtransaktionen (708) (oder einfach Nachrichten) sind so definiert, daß sie In-Band-Kommunikationen zwischen EGIO-Agenten über die Schnittstelle(n) 106 unterstützen. Herkömmliche Prozessoren enthalten keine Unterstützung für nativen Nachrichtenraum, so daß dieser durch EGIO-Agenten in der EGIO-Schnittstelle 106 ermöglicht wird. Gemäß einer beispielhaften Implementation werden herkömmliche Seitenbandsignale wie Unterbrechungen und Leistungsmanagementanforderungen als Nachrichten implementiert, um die erforderliche Pinzählung zum Unterstützen solcher Altgerätesignale zu verringern. Einige Prozessoren und der PCI-Bus enthalten das Konzept der „speziellen Zyklen", welche auch in Nachrichten in der EGIO-Schnittstelle 106 abgebildet sind. Gemäß einer Ausführungsform werden Nachritchten allgemein in zwei Kategorien unterteilt: Standardnachrichten und Vendor-definierte Nachrichten.
In Übereinstimmung mit der dargestellten beispielhaften Ausführungsform enthalten Standardnachrichten eine allgemeine Nachrichtengruppe und eine Systemmanagementnachrichtengruppe. Die allgemeinen Nachrichten können eine Nachricht mit einem einzigen Ziel oder eine Rundsende-/Multicastnachricht darstellen. Die Systemmanagementnachrichtengruppe kann aus einer oder mehreren Unterbrechungssteuernachrichten, Leistungsmanagementnach richten, Reihenfolgesteuerungsprimitiven und Fehlersignalgebung bestehen, von denen unten Beispiele angeführt werden.
Gemäß einer beispielhaften Implementation enthalten die allgemeinen Nachrichten zur Unterstützung verriegelter Transaktionen. In Übereinstimmung mit der beispielhaften Implementation wird eine Entriegeln-Nachricht eingeführt, in der Schalter (z.B. 108) in der Regel die Entriegelungsnachricht durch einen Port weiterleiten sollen, der möglicherweise an verriegelten Transaktionen teilnimmt. Endpunktvorrichtungen (z.B. 110, 118, 120), welche eine Entriegelungsnachricht empfangen, wenn sie nicht verriegelt sind, werden diese Nachricht ignorieren. Andernfalls werden die verriegelten Nachrichten bei Empfang einer Entriegelungsnachricht entriegeln.
Gemäß einer beispielhaften Implementation enthält die Systemmanagementnachrichtengruppe Spezialnachrichten zum Sortieren und Synchronisieren von Nachrichten. Eine solche Nachricht ist eine FENCE-Nachricht, welche strikte Sortierregeln auf Transaktionen, die durch Empfangen von Elementen der EGIO-Architektur erzeugt wurden, anwendet. Gemäß einer Implementation wird auf solche FENCE-Nachrichten nur durch einen ausgewählten Teilsatz von Netzwerkelementen, z.B. Endpunkten, reagiert. Zusätzlich zu dem Vorstehenden sind hierin Nachrichten, die einen korrigierbaren Fehler, einen nicht korrigierbaren Fehler und einen fatalen Fehler bezeichnen, vorgesehen, z.B. durch die Verwendung von Fehlerweiterleitung.
Gemäß einem Aspekt der vorliegenden Erfindung, der oben erwähnt wurde, sieht die Systemmanagementnachrichtengruppe die Signalgebung von Unterbrechungen unter Verwendung von In-Band-Nachrichten vor. Gemäß einer Implementation wird das ASSERT_INTx/DEASSERT_INTx-Nachrichtenpaar eingeführt, wenn die Unterbrechungsbestätigungsnachricht in dem Prozessorkomplex durch die Hostbrücke 104 gesendet wird. In Übereinstimmung mit der dargestellten beispielhaften Implementation spiegeln die Verwendungsregeln für das ASSERT_INTx/DEASSERT_INTx-Nachrichtenpaar jene der in der oben erwähnten PCI-Richtlinie vorgefundenen PCI INTx# Signale wieder. Von jeder anderen Vorrichtung sollte für jede Sendung von Assen_INTx in der Regel eine entsprechende Sendung von Deassert_INTx erfolgen. Für ein bestimmtes ,x' (A, B, C oder D) sollte es in der Regel eine Sendung von Assert_INTx vor einer Sendung von Deassert_INTx geben. Schalter sollten in der Regel Assen_INTx/Deassert_INTx-Nachrichten an die Hostbrücke 104 weiterleiten, wo die Hostbrücke in der Regel die Assert_INTx/Deassert_INTx-Nachrichten nachverfolgen sollte, um virtuelle Unterbrechungssignale zu erzeugen und diese Signale auf die Systemunterbrechungsressourcen abzubilden.
Zusätzlich zu den allgemeinen und Systemmanagementnachrichtengruppen führt die EGIO-Architektur einen Standardrahmen ein, in dem die Kernlogik-(z.B. Chipset)-Vendoren ihre eigenen Vendoren-definierten Nachrichten definieren können, um den spezifischen Betriebsanforderungen ihrer Plattform zu entsprechen. Dieses Rahmenwerk wird durch ein gemeinsames Nachrichtenheaderformat eingerichtet, bei dem Codierungen für Vendoren-definierte Nachrichten als „reserviert" definiert sind.
Transaktionsbeschreiber
Ein Transaktionsbeschreiber ist ein Mechanismus zum Tragen von Transaktionsinformationen von dem Ursprungspunkt zu dem Servicepunkt und zurück. Er stellt erweiterbare Mittel zum Bereistellen einer generischen Verbindungslösung bereit, welche die neuen Arten von Systemen und Anwendungen unterstützen können. In dieser Hinsicht unterstützt der Transaktionsbeschreiber die Identifikation von Transaktionen in dem System, die Modifikation von voreingestellten Transaktionsreihenfolgen und die Assoziation der Transaktionen mit virtuellen Kanälen unter Verwendung des virtuellen Kanalkennungsmechanismus. Eine graphische Darstellung eines Transaktionsbeschreibers wird unter Bezugnahme auf den 3 dargestellt.
Unter Bezugnahme auf 3 wird eine graphische Darstellung eines Datagramms, welches einen beispielhaften Transaktionsbeschreiber enthält, in Übereinstimmung mit den Lehren der vorliegenden Erfindung dargestellt. In Übereinstimmung mit den Lehren der vorliegenden Erfindung wird der Transaktionsbeschreiber 300 so dargestellt, daß er ein globales Kennungsfeld 302, ein Attributfeld 306 und ein virtuelles Kanalkennungsfeld 308 enthält. In der dargestellten beispielhaften Implementation wird das globale Kennungsfeld 302 so dargestellt, daß es ein lokales Transaktionskennungsfeld 308 und ein Quellkennungsfeld 310 enthält.
Globale Transaktionskennung
Wie hierin verwendet ist die globale Transaktionskennung für alle ausstehenden Anforderungen eindeutig. In Übereinstimmung mit der dargestellten beispielhaften Implementation aus 3 besteht die Transaktionskennung 302 aus zwei Unterfeldern: dem lokalen Transaktionskennungsfeld 308 und einem Quellkennungsfeld 310. Gemäß einer Implementation handelt es sich bei dem lokalen Transaktionskennungsfeld 308 um ein 8-Bit-Feld, das durch jeden Anforderer erzeugt wird, und es ist für alle ausstehenden Anforderungen, die eine Vervollständigung für diesen Anforderer erfordern, eindeutig. Die Quellkennung identifiziert den EGIO-Agenten in der EGIO-Hierarchie eindeutig. Dementsprechend stellt die lokale Transaktionskennung mit der Quellkennung eine globale Identifikation einer Transaktion in einem Hierarchiebereich bereit.
Gemäß einer Implementation gestattet die lokale Transaktionskennung 308 die Handhabung von Anforderungen/Vervollständigungen von einer einzigen Quelle von Anforderungen außerhalb der Reihenfolge (abhängig von den unten ausführlicher dargestellten Reihenfolgenregeln). Beispielsweise kann eine Quelle von Leseanforderungen Lesungen A1 und A2 erzeugen. Der Zielagent, der diese Leseanforderungen bedient, kann zuerst eine Vervollständigung für die Transaktionskennung der Anforderung A2 zurückgeben und dann eine Vervollständigung für A1. In dem Vervollständigungspaketheader werden lokale Transaktionskennungsinformationen kennzeichnen, welche Transaktion vervollständigt wird. Ein solcher Mechanismus ist insbesondere für Einrichtungen wichtig, welche verteilte Speichersystem verwenden, da er die Handhabung von Leseanforderungen auf effizientere Weise gestattet. Es sei darauf hingewiesen, daß die Unterstützung einer solchen Vervollständigung außerhalb der Reihenfolge annimmt, daß die Vorrichtungen, welche Leseanforderungen ausgeben, die vorherige Zuweisung von Pufferraum für die Vervollständigung sicherstellen werden. Wie oben erwähnt müssen EGIO-Schalter 108, insoweit sie keine Endpunkte sind (z.B. nur Vervollständigungsanforderungen an geeignete Endpunkte weiterleiten) keinen Pufferraum reservieren.
Eine einzige Leseanforderung kann zu mehreren Vervollständigungen führen. Vervollständigungen, die zu einer einzigen Leseanforderung gehören, können außerhalb der Reihenfolge zueinander zurückgegeben werden. Dies wird dadurch unterstützt, daß in der Originalanforderung ein Adressversatz bereitgestellt wird, der der teilweisen Vervollständigung in dem Header eines Vervollständigungspakets entspricht (d.h. Vervollständigungsheader).
Gemäß einer beispielhaften Ausführungsform enthält das Quellkennungsfeld 310 einen 16-Bit-Wert, der für jede logische EGIO-Vorrichtung eindeutig ist. Es sei darauf hingewiesen, daß eine einzige EGIO-Vorrichtung mehrere logische Vorrichtung enthalten kann. Der Quell kennungswert wird während der Systemkonfiguration auf eine gegenüber dem Standard-PCI-Busnummerierungsmechanismus transparenten Weise zugewiesen. EGIO-Vorrichtungen richten intern und automatisch einen Quellkennungswert unter Verwendung von beispielsweise Busnummerinformationen ein, die während der Anfangskonfigurationszugriffe auf diese Vorrichtungen zusammen mit intern verfügbaren Informationen verfügbar sind, welche beispielsweise eine Vorrichtungsnummer und eine Flußnummer angeben. Gemäß einer Implementation wird die Busnummer durch einen PCI-Initialisierungsmechanismus zugewiesen und von jeder Vorrichtung erfaßt. Im Fall von Hot-Plug- und Hot-Swap-Vorrichtungen werden solche Vorrichtungen diese Busnummerinformationen bei jedem Konfigurationszykluszugriff neu erfassen müssen, um den SHPC-Softwarestapeln Transparenz zu verleihen.
In Übereinstimmung mit einer Implementation der EGIO-Architektur kann eine physikalische Komponente aus einer oder mehreren logischen Vorrichtungen (oder Agenten) bestehen. Jede logische Vorrichtung ist so ausgelegt, daß sie auf Konfigurationszyklen reagiert, auf die an ihrer bestimmten Vorrichtungsnummer abgezielt wird, d.h. die Kennung der Vorrichtungsnummer ist in der logischen Vorrichtung eingebettet. Gemäß einer Implementation sind bis zu sechzehn logische Vorrichtungen in einer einzigen physikalischen Komponente zulässig. Jede dieser logischen Vorrichtungen kann eine oder mehrere Strömmaschinen enthalten, z.B. bis zu einer Höchstzahl von sechzehn. Dementsprechend kann eine einzelne physikalische Komponente bis zu 256 Strömungsmaschinen enthalten.
Transaktionen, welche von verschiedenen Quellkennungen mit Tags versehen wurden, gehören zu verschiedenen EGIO-Eingabe/Ausgabe-(E/A)-Quellen und können daher aus dem Blickwinkel der Reihenfolge vollkommen unabhängig voneinander gehandhabt werden. Im Fall von Peer-to-Peer-Transaktionen mit drei Parteien kann eine sortierende Fence-Steuer-Primitive verwendet werden, um das Sortieren falls notwendig zu erzwingen.
Wie hierin verwendet, folgt das globale Transaktionskennungsfeld 302 des Transaktionsbeschreibers 300 mindestens einen Teilsatz der folgenden Regeln:

(a) Jede Vervollständigen-Erforderlich-Anforderung wird mit einer globalen Transaktionskennung (GTID) versehen;
(b) allen ausstehenden Vervollständigungs-Erforderlich-Anforderungen, welche durch einen Agenten initiiert worden sind, wird in der Regel eine eindeutige GTID zugewiesen;
(c) Vervollständigung-Nicht-Erforderlich-Anforderungen verwenden das lokale Transaktionskennungsfeld 308 der GTID nicht und das lokale Transaktionskennungsfeld wird als reserviert behandelt;
(d) das Ziel verändert die Anforderungs-GTID auf keine Weise, sondern gibt sie lediglich an den Header eines Vervollständigungspakets für alle mit der Anforderung verbundenen Vervollständigungen wieder, wobei der Initiator die GTID verwendet hat, um die Vervollständigung(en) an die ursprüngliche Anforderung anzupassen.

Attributfeld 304
Wie hierin verwendet spezifiziert das Attributfeld 304 die Eigenschaften und Beziehungen der Transaktion. In dieser Hinsicht wird das Attributfeld 304 verwendet, um zusätzliche Informationen bereitzustellen, die die Modifikation der voreingestellten Handhabung von Transaktionen zulässt. Diese Modifikationen können sich auf verschiedene Aspekte der Handhabung der Transaktionen in dem System beziehen, wie beispielsweise der Sortierung, des Hardwarekohärenzmanagements (z.B. Abhörattribute) und Priorität. Ein Beispielformat des Attributfelds 304 wird mit den Unterfeldern 312-318 dargestellt.
Wie gezeigt enthält das Attributfeld 304 ein Prioritätsunterfeld 312. Das Prioritätsunterfeld kann durch einen Initiator modifiziert werden, um der Transaktion Priorität zuzuweisen. In einer beispielhaften Implementation kann beispielsweise eine Klassen- oder Dienstgüteeigenschaft einer Transaktion oder eines Agenten in dem Prioritätsunterfeld 312 eingebettet sein, wodurch die Verarbeitung anderer Systemelemente beeinFlußt wird.
Das reservierte Attributfeld 314 wird für die Zukunft oder den Vendor-spezifischen Gebrauch reserviert belassen. Mögliche Gebrauchsmodelle, die die Prioritäts- oder Sicherheitsattribute verwenden, können unter Verwendung des reservierten Attributfelds implementiert werden.
Das Sortierattributfeld 316 wird zum Zuführen optionaler Informationen verwendet, welche die Sortierart übermitteln, der die voreingestellten Sortierregeln in derselben Sortierebene modifizieren kann (wobei die Sortierebene den durch den Hostprozessor (102) und der E/A-Vorrichtung mit ihrer entsprechenden Quellkennung initiiert wird). Gemäß einer beispielhaften Implementation bezeichnet ein Sortierattribut von „0", daß die voreingestellten Sortierregeln angelegt werden sollen, während ein Sortierattribut von „1" aufgelockerte Sortierung bezeichnet, bei der Schreibvorgänge Schreibvorgänge in derselben Richtung überholen können und Lesevervollständigungen Schreibvorgänge in derselben Richtung überholen können. Vorrichtungen verwenden die aufgelockerte Sortiersemantik vor allem zum Bewegen der Daten und Transaktionen und die voreingestellte Sortierung für Lese-/Schreibstatusinformationen.
Das Abhörattributfeld 318 wird zum Zuführen optionaler Informationen verwendet, welche die Art der Cachekohärenzmanagement übermitteln, welche die voreingestellte Cachekohärenzmanagementregeln in derselben Sortierebene modifizieren können, wobei eine Sortierebene Traffic umfaßt, der durch einen Hostprozessor 102 und der E/A-Vorrichtung mit ihrer entsprechenden Quellkennung initiiert wird. In Übereinstimmung mit einer beispielhaften Implementation entspricht ein Wert von „0" des Abhörattributfelds 318 einem voreingestellten Cachekohärenzmanagementschema, in dem die Transaktionen abgehört werden, um eine Cachekohärenz auf Hardwareebene durchzusetzen. Ein Wert von „1" des Abhörattributfelds 318 hebt die voreingestellten Cachekohärenzschemata dagegen auf und Transaktionen werden nicht abgehört. Stattdessen können die Daten, auf die zugegriffen wird, entweder nicht gecached werden oder ihre Kohärenz wird durch Software gemanagt.
Virtueller-Kanal-Kennungsfeld 306
Wie hierin verwendet identifiziert das Virtueller-Kanal-Kennungsfeld 306 einen unabhängigen virtuellen Kanal, dem die Transaktionen zugeordnet werden. Gemäß einer Ausführungsform handelt es sich bei der Virtueller-Kanalkennung (VCID) um ein Vier-Bit-Feld, welches die Identifikation von bis zu sechzehn virtuellen Kanälen (VC) auf einer Basis pro Transaktion. Ein Beispiel von VCID-Definitionen wird unten in Tabelle 1 gegeben:

Tabelle I: Virtuelle Kanalkennungscodierung
Virtuelle Kanäle
In Übereinstimmung mit einem Aspekt der vorliegenden Erfindung kann die Transaktionsschicht 202 der EGIO-Schnittstelle 106 einen oder mehrere virtuelle Kanäle in der Bandbreite der Kommunikationstrecke 112. Der Aspekt des virtuellen Kanals (VC) der vorliegenden Erfindung, welcher oben erwähnt wurde, wird zur Definition separater logischer Kommunikationsschnittstellen in einer einzigen physikalischen EGIO-Verbindung 112. In dieser Hinsicht werden separate VC verwendet, um Traffic abzubilden, der von unterschiedlichen Handhabungsrichtlinien und Dienstprioritäten profitieren würde. Traffic, welcher hinsichtlich des Garantierens einer Datenmenge von X innerhalb eines Zeitraums T eine deterministische Dienstgüte erfordert, kann auf einen isochronen (zeitabhängigen) virtuellen Kanal abgebildet werde. Auf verschiedene virtuelle Kanäle abgebildete Transaktionen können in Bezug aufeinander gar keine Sortieranforderungen aufweisen. Das heißt, virtuelle Kanäle operieren als separate logische Schnittstellen mit unterschiedlichen Flußsteuerregeln und -attributen.
Hinsichtlich des durch den Hostprozessor 102 initiierten Traffics erfordern virtuelle Kanäle möglicherweise eine Sortierkontrolle auf der Grundlage von voreingestellten Sortiermechanismusregeln oder der Traffic kann vollkommen außerhalb der Reihenfolge gehandhabt werden. Gemäß einer beispielhaften Implementation verstehen die VC die folgenden beiden Trafficarten: Allgemeiner E/A-Traffic und isochroner Traffic. Das heißt, gemäß dieser beispielhaften Implementation werden zwei Arten von virtuellen Kanälen beschrieben: (1) allgemeine virtuelle E/A-Kanäle und (2) isochrone virtuelle Kanäle.
Wie hierin verwendet, führt die Transaktionsschicht 202 eine unabhängige Durchflußsteuerung für jeden des einen oder der mehreren virtuellen Kanal/Kanäle, welche durch die Kom ponente aktiv unterstützt werden. Wie hierin verwendet sollten alle EGIO-fähigen Komponenten in der Regel den allgemeinen virtuellen E/A-Kanal unterstützen, z.B. der virtuelle Kanal 0, bei dem keine Sortierbeziehungen zwischen getrennten virtuellen Kanälen dieser Art erforderlich sind. Gemäß der Voreinstellung wird VC = für allgemeinen E/A-Traffic verwendet, während VC1 zur Handhabung isochronen Traffics zugewiesen ist. In alternativen Implementationen kann ein beliebiger virtueller Kanal zugewiesen sein, um jede Trafficart zu handhaben. Eine konzeptuelle Darstellung einer EGIO-Verbindung, die mehrere, unabhängig gemanagte Kanäle umfaßt, wird unter Bezugnahme auf 4 dargestellt.
Unter Bezugnahme auf 4 wird eine graphische Darstellung einer beispielhaften EGIO-Verbindung 112, die mehrere virtuelle Kanäle (VC) umfaßt, gemäß einem Aspekt der vorliegenden Erfindung dargestellt. Gemäß der dargestellten beispielhaften Implementation aus 4 wird die EGIO-Verbindung 112 so dargestellt, daß sie mehrere virtuelle Kanäle 402, 404, die zwischen der/den EGIO-Schnittstelle(n) erstellt sind, dargestellt. Gemäß einer beispielhaften Implementation wird in Bezug auf den virtuellen Kanal 402 Traffic von mehreren Quellen 406A...N dargestellt, die mindestens durch ihre Quellkennung unterschieden sind. Wie gezeigt wurde der virtuelle Kanal 402 ohne Sortieranforderungen zwischen Transaktionen unterschiedlicher Quellen (z.B. Agenten, Schnittstellen usw.) eingerichtet.
Analog wird der virtuelle Kanal 404 so dargestellt, daß er Traffic von mehreren Quellen, mehreren Transaktionen 408A...N umfaßt, wobei jede Transaktion durch mindestens eine Quellkennung bezeichnet wird. In Übereinstimmung mit dem dargestellten Beispiel sind die Transaktionen von der Quellkennung 0 406A stark geordnet, es sei denn, sie werden durch das Attributfeld 304 des Transaktionsleaders modifiziert, während die Transaktionen von der Quelle 408N keine solchen Sortierregeln darstellen. Ein Beispielverfahren des Errichtens und Managen von einem oder mehreren virtuellen Kanal/Kanälen wird unter Bezugnahme auf 10 unten dargestellt.
Transaktionsreihenfolge
Obwohl es einfacher ist zu erzwingen, daß alle Transaktionen in der Reihenfolge ausgeführt werden, versucht die Transaktionsschicht 202, die Leistung zu verbessern, in dem die Neusortierung von Transaktionen zugelassen wird. Um eine solche Neusortierung zu erleichtern, versieht die Transaktionsschicht 102 die Transaktionen mit „Tags". Das heißt, gemäß einer Ausführungsform fügt die Transaktionsschicht 202 jedem Paket einen Transaktionsbeschreiber zu, so daß seine Sendezeit (z.B. durch Neusortierung) durch Elemente in der EGIO-Architektur optimiert werden kann, ohne die relative Sortierung, in der das Paket ursprünglich verarbeitet wurde, außer Acht zu lassen. Solche Transaktionsbeschreiber werden verwendet, um die Weiterleitung von Anforderungs- und Vervollständigungspaketen durch die EGIO-Schnittstellenhierarchie zu erleichtern.
Einer der innovativen Aspekte der EGIO-Verbindungsarchitektur und des Kommunikationsprotokolls ist somit die Bereitstellung von Kommunikation außerhalb der Reihenfolge, wodurch der Datendurchsatz durch die Verringerung von Leer- oder Wartezuständen verbessert wird. In dieser Hinsicht setzt die Transaktionsschicht 202 eine Gruppe von Regeln ein, die die Sortieranforderungen für EGIO-Transaktionen definieren. Transaktionssortieranforderungen sind so definiert, daß sie den korrekten Betrieb mit Software zur Unterstützung des Hersteller-Kunden-Sortiermodells sicherstellen und gleichzeitig eine verbesserte Flexibilität bei der Handhabung von Transaktionen für Anwendungen, die auf unterschiedlichen Sortiermodellen beruhen (z.B. aufgelockerte Sortierung für Graphikanwendungen). Die Sortieranforderungen für zwei unterschiedliche Modellarten werden unten dargestellt, ein Modell mit einer einzigen Sortierebene und ein Modell mit mehreren Sortierebenen.
Basistransaktionssortierung – Modell mit einfacher „Sortierebene"
Es wird angenommen, daß zwei Komponenten über eine EGIO-Architektur, die ähnlich der aus 1 ist, miteinander verbunden sind: ein Speichersteuerhub stellt eine Schnittstelle an einen Hostprozessor und ein Speicheruntersystem bereit und ein E/A-Steuerhub stellt eine Schnittstelle an ein E/A-Untersystem bereit. Beide Hubs enthalten interne Schlangen, die eingehenden und ausgehenden Traffic handhaben, und in diesem einfachen Modell wird der gesamte E/A-Traffic auf eine einzige „Sortierebene" abgebildet. (Es sei darauf hingewiesen, daß die Quellkennungsinformationen von dem Transaktionsbeschreiber eine eindeutige Kennung für jeden Agenten in einer EGIO-Architektur bereitstellt. Außerdem kann der E/A-Traffic, der auf die Quellkennung abgebildet wird, verschiedene Transaktionssortierattribute tragen). Die Sortierregeln für diese Systemkonfiguration werden zwischen E/A-initiierten Traffic und Host-initiierten Traffic festgelegt. Aus dieser Perspektive stellt E/A-Traffic, der zusammen mit von dem Hostprozessor initiiertem Traffic auf eine Quellkennung abgebildet wird, Traffic dar, der in einer einzigen „Sortierebene" ausgeführt wird.
Ein Beispiel solcher Transaktionssortierregeln wird unten unter Bezugnahme auf Tabelle II dargestellt. Die in dieser Tabelle definierten Regeln gelten gleichförmig für alle Arten von Transaktionen in dem EGIO-System, einschließlich Speicher, E/A, Konfiguration und Nachrichten. In Tabelle II stellen die Spalten die ersten von zwei Transaktionen dar und die Reihen stellen die zweite dar. Die Tabelleneinträge zeigen die Sortierbeziehung zwischen den beiden Transaktionen. Die Tabelleneinträge werden wie folgt definiert:

Ja – Die zweite Transaktion sollte in der Regeln die erste überholen, um ein Verstopfen zu verhindern (wenn eine Blockierung auftritt, ist die zweite Transaktion erforderlich, um die erste Transaktion zu überholen. Die Fairness sollte in der Regel dazu ausgelegt sein, um ein Ausbleiben zu verhindern).
J/N – Es gibt keine Anforderungen. Die erste Transaktion kann optional die zweite Transaktion überholen oder durch sie blockiert werden.
Nein – Die zweite Transaktion sollte in der Regel die erste nicht überholen dürfen. Dies ist erforderlich, um eine starke Sortierung zu sichern.

Tabelle II: Transaktionssortierung und Verhinderung von Blockierung für einfache Sortierebene
Tabelle III: Transaktionssortiererläuterungen
Fortgeschrittene Transaktionssortierung – „Mehrschicht"-Transaktionssortiermodell
Der vorherige Abschnitt hat die Sortierregeln in einer einzigen „Sortierebene" festgelegt. Wie oben erwähnt setzt die EGIO Verbindungsarchitektur und Kommunikationsprotokoll einen eindeutigen Transaktionsbebschreibermechanismus ein, um zusätzliche Informationen mit einer Transaktion zu verbunden, um fortgeschrittenere Sortierbeziehungen zu unterstützen. Felder in dem Transaktionsbeschreiber gestatten die Schaffung mehrerer „Sortierebenen", die unabhängig voneinander aus Sicht der E/A-Trafficsortierung sind. Jede „Sortierebene" besteht aus einer Schlangen-/Pufferlogik, die einer bestimmten E/A-Vorrichtung entspricht (welche durch eine eindeutige Quellkennung bezeichnet ist), und einer Schlangen-/Pufferlogik, die vom Hostprozessor initiierten Traffic trägt. Die Sortierung in der „Ebene" wird in der Regel nur zwischen diesen beiden definiert. Die im vorherigen Abschnitt definierten Regeln zur Unterstützung des Hersteller/Verbraucher-Gebrauchsmodells und zur Verhinderung von Blockierungen werden für jede „Sortierebene" unabhängig von anderen „Sortierebenen" durchgesetzt. Lesevervollständigungen für Anforderungen, die durch „Ebene" N initiiert worden sind, können Leseanforderungen für Anforderungen, die durch die „Ebene" M initiiert worden sind, beispielsweise umgehen. Leseanforderungen für Ebene N und Leseanforderun gen für Ebene M können jedoch beide keine eingetragenen Speicherschreibvorgänge umgehen, die vom Host initiiert worden sind.
Obwohl der Gebrauch des Ebenenabbildungsmechanismus das Vorhandensein mehrerer Sortierebenen ermöglicht, können einige oder alle Sortierebenen „zusammengelegt" werden, um die Implementation zu vereinfachen (d.h. das Kombinieren mehrerer separat gesteuerter Puffer/FIFO in einen einzigen). Wenn alle Ebenen zusammengelegt worden sind, wird der Transaktionsbebschreiber-Quellkennungsmechanismus nur dafür verwendet, die Weiterleitung von Transaktionen zu erleichtern und wird nicht verwendet, um die Sortierung zwischen unabhängigen Strömen von E/A-Traffic aufzulockern.
Zusätzlich zu dem Vorstehenden sieht der Transaktionsbeschreibermechanismus die Modifikation voreingestellter Sortierung in einer einzigen Sortierebene vor, wenn ein Sortierattribut verwendet wird. Die Modifikationen der Sortierung kann daher auf einer Basis pro Transaktion gesteuert werden.
Transaktionsschichtprotokollpaketformat
Wie oben erwähnt verwendet die innovative EGIO-Architektur ein paketbasiertes Protokoll, um Informationen zwischen Transaktionsschichten zweier Vorrichtungen, die miteinander kommunizieren, auszutauschen. Die EGIO-Architektur unterstützt in der Regel den Speicher, E/A, die Konfiguration und die Nachrichtentransaktionsarten. Solche Transaktionen werden in der Regel unter Verwendung von Anforderungs- oder Vervollständigungspaketen ausgeführt, wobei die Vervollständigungspakete nur verwendet werden, wenn erforderlich, d.h. zum Zurückgeben von Daten oder zum Bestätigen des Empfangs einer Transaktion.
Unter Bezugnahme auf 6 wird eine graphische Darstellung eines beispielhaften Transaktionsschichtprotokolls in Übereinstimmungen mit den Lehren der vorliegenden Erfindung dargestellt. In Übereinstimmung mit der dargestellten beispielhaften Implementation aus 6 wird der TLP-Header 600 als ein Formatfeld, ein Typfeld, ein erweitertes Typ/erweitertes Längenfeld (ET/EL) und ein Längenfeld aufweisend dargestellt. Es sei darauf hingewiesen, daß einige TLP Daten nach dem Header enthalten, wie durch das in dem Header spezifizierte Formatfeld bestimmt. Kein TLP sollte mehr Daten enthalten, als durch die Grenze MAX_PAYLOAD_SIZE festgelegt. In Übereinstimmung mit einer beispielhaften Implemen tation sind TLP-Daten natürlich ausgerichtete 4-Bitdaten und in Inkrementation eines 4-Bit-Doppelworts.
Wie hierin verwendet spezifiziert das Format-(FMT)-Feld das Format des TLP in Übereinstimmung mit der folgenden Definition:

– 000-2DW Header, Keine Daten
– 001-3DW Header, Keine Daten
– 010-4DW Header, Keine Daten
– 101-3DW Header, Mit Daten
– 110-4DW Header, Mit Daten
– Alle anderen Codierungen sind reserviert

Das TYP-Feld wird verwendet, um die in dem TLP verwendeten Typcodierungen zu bezeichnen. Gemäß einer Implementation sollten sowohl Fmt[2:0] als auch Typ[3:0] in der Regel decodiert sein, um das TLP-Format zu bestimmen. Gemäß einer Implementation wird der Wert in dem Typ[3:0]-Feld verwendet, um zu bestimmen, ob das erweiterte Typ/erweiterte Längen-Feld verwendet wird, um das Typfeld oder das Längenfeld zu erweitern. Das ET/EL-Feld wird in der Regel nur verwendet, um das Längenfeld in Leseanforderungen von der Speicherart zu erweitern.
Das Längenfeld stellt eine Anzeige der Länge der Nutzlast bereit, wiederum in DW-Inkrementierungen von:
0000 0000 = 1DW
0000 0001 = 2DW
...
1111 1111 = 256DW
Eine Zusammenfassung von mindestens einem Teilsatz von beispielhaften TLP-Transaktionsarten, ihre entsprechenden Headerformate und eine Beschreibung wird in der folgenden Tabelle IV gegeben:
Weitere Einzelheiten bezüglich Anforderungen und Vervollständigungen werden in Anhang A gegeben.
Durchflußsteuerung
Eine der Beschränkungen, die im allgemeinen mit herkömmlichen Durchflußsteuerungsschemen verbunden ist, besteht darin, daß sie auf möglicherweise auftretende Probleme reagieren, statt das Auftreten solcher Probleme von Anfang an proaktiv zu reduzieren. Bei dem herkömmlichen PCI-System sendet beispielsweise ein Sender Informationen an einen Empfänger, bis er eine Nachricht empfängt, die Sendung bis auf Weiteres anzuhalten/auszusetzen. Auf solche Anforderungen können danach Anforderungen zur Neuversendung von Paketen folgen, beginnend bei einem gegebenen Punkt in der Sendung. Fachleuten dürfte klar sein, daß dieser reaktive Ansatz zu der Verschwendung von Zyklen führt und in dieser Hinsicht ineffizient sein kann.
Um diese Einschränkung anzugehen, enthält die Transaktionsschicht 202 der EGIO-Schnittstelle 106 einen Durchflußsteuerungsmechanismus, der die Gelegenheit für das Auftreten von Überstrombedingungen proaktiv verringert, während er auch das Einhalten von Sortierregeln auf einer Basis pro Verbindung des virtuellen Kanals, der zwischen dem Initiator und dem/den Vervollständiger(n) eingerichtet ist, bereitstellt. In Übereinstimmung mit einem Aspekt der vorliegenden Erfindung wird das Konzept von Durchflußsteuerungspunkten eingeführt, wobei ein Empfänger Informationen über (a) die Puffergröße (in Punkten) und (b) den gegenwärtig verfügbaren Pufferraum für jeden der zwischen dem Sender und dem Empfänger eingerichteten virtuellen Kanal/Kanäle (d.h. auf einer Basis pro virtuellem Kanal) gemeinsam benutzt. Dies ermöglicht der Transaktionsschicht 202 des Senders, eine Schätzung des verfügbaren Pufferraums zu führen (z.B. Zählung verfügbarer Punkte), welcher der Sendung über einen identifizierten virtuellen Kanal zugewiesen ist, und ihre Sendung durch jeden der virtuellen Kanäle proaktiv zu drosseln, wenn sie bestimmt, daß die Sendung eine Überstrombedingung in dem Empfangspuffer verursachen würde.
In Übereinstimmung mit einem Aspekt der vorliegenden Erfindung führt die Transaktionsschicht 202 die Flußsteuerung ein, um das Überströmen der Empfangspuffer zu verhindern und das Einhalten der Sortierregeln wie oben erwähnt zu ermöglichen. In Übereinstimmung mit einer Implementation wird der Durchflußsteuerungsmechanismus der Transaktionsschicht 202 von dem Anforderer verwendet, um den in einem Agenten über die EGIO-Verbindung 112 verfügbaren Schlangen-/Pufferraum zu verfolgen. Wie hierin verwendet bedeutet Durchflußsteuerung nicht, daß eine Anforderung ihren letztendlichen Vervollständiger erreicht hat.
In Übereinstimmung mit den Lehren der vorliegenden Erfindung ist die Durchflußsteuerung orthogonal zu den Datenintegritätsmechanismen, die verwendet werden, um einen zuverlässigen Informationsaustausch zwischen einem Sender und einem Empfänger zu implementieren. D.h. die Durchflußsteuerung kann den Fluß von Transaktionsschichtpaket-(TLP)-Informationen von dem Sender zu dem Empfänger als perfekt behandeln, da die Datenintegritätsmechanismen sicherstellen, daß korrupte und verlorene TLP durch Neuversenden korrigiert werden. Wie hierin verwendet umfaßt die Durchflußsteuerung die virtuellen Kanäle der EGIO-Verbindung 112. In dieser Hinsicht wird jeder virtuelle Kanal, der durch einen Empfänger unterstützt wird, in den Durchflußsteuerungspunkten (FCC), die durch den Empfänger bekannt gegeben werden, reflektiert.
In Übereinstimmung mit den Lehren der vorliegenden Erfindung wird die Durchflußsteuerung durch die Transaktionsschicht 202 im Zusammenwirken mit der Datenverbindungsschicht 204 ausgeführt. Zur Vereinfachung der Darstellung bei der Beschreibung des Durchflußsteuerungsmechanismus werden die folgenden Arten von Paketinformationen unterschieden:

(a) Eingetragene Anforderungsheader (PRH)
(b) Eingetragene Anforderungsdaten (PRD)
(c) Nicht eingetragene Anforderungsheader (NPRH)
(d) Nicht eingetragene Anforderungsdaten (NPRD)
(e) Lese-, Schreib- und Nachrichtenvervollständigungsheader (CPLH)
(f) Lese- und Nachrichtenvervoilständigungsdaten (CPLD).

Wie oben erwähnt ist die Maßeinheit in der EGIO-Implementation der proaktiven Durchflußsteuerung ein Durchflußsteuerungspunkt (FCC). In Übereinstimmung mit nur einer Implementation beträgt ein Durchflußsteuerungspunkt 16 Datenbyte. Für Header ist die Durchflußsteuerunginheit ein Header. Wie oben erwähnt, weist jeder virtuelle Kanal unabhängige Durchflußsteuerung auf. Für jeden virtuellen Kanal werden separate Indikatoren der Punkte geführt und für jeden der vorhergehenden Arten von Paketinformationen ((a) bis (f), wie oben angegeben) nachverfolgt. In Übereinstimmung mit der dargestellten beispielhaften Implementation verbraucht die Sendung von Paketen Durchflußsteuerungspunkte in Übereinstimmung mit dem Folgenden:

– Speicher/E/A/Konfigurationsleseanforderung: 1NPRH-Einheit
– Speicherschreibanforderung: 1PRH + nPRD-Einheiten (wobei n mit der Größe der Datennutzlast, z.B. der Länge der Daten, verbunden ist, geteilt durch die Durchflußsteuerunginheitsgröße (z.B. 16 Byte)).
– E/A/Konfigurationsschreibanforderung: 1NPRH + INPRD
– Nachrichtenanforderungen abhängig von der Nachricht, mindestens 1PRH und/oder 1NPRH-Einheit
– Vervollständigungen mit Daten: 1CPLH + 1nCPLD-Einheit (wobei n bezogen ist auf die Größe der Daten geteilt durch die Durchflußsteuerungsdateneinheitsgröße, z.B. 16 Byte)
– Vervollständigungen ohne Daten: 1CPLH.

Für jede Art der verfolgten Informationen gibt es drei konzeptuelle Register, wobei jedes 8 Bits breit ist, um die (in dem Sender) verbrauchten Punkte, eine Punktegrenze (in dem Sender) und die zugewiesenen Punkte (in dem Empfänger) zu überwachen. Das Register der verbrauchten Punkte enthält eine Zählung der Gesamtanzahl von Durchflußsteuerungseinheitsmodule 256, die seit der Initialisierung verbraucht worden sind. Nach der Initialisierung wird das Register der verbrauchten Punkte insgesamt auf 0 gesetzt und inkrementiert, wenn die Transaktionsschicht mit dem Senden von Informationen an die Datenverbindungsschicht. Die größte Inkrementation ist mit der Anzahl der durch die für das Senden bestimmte Information verbrauchten Punkte verbunden. Gemäß einer Implementation wird die Zählung auf 0 gestellt, wenn die Maximalzählung (z.B. alle 1) erreicht oder überschritten wird. Gemäß einer Implementation wird die oben bezeichnete 8Bit-Modularithmetik verwendet, um den Zähler zu führen.
Das Punktegrenzenregister enthält die Grenze für die maximale Anzahl von Durchflußsteuerungseinheiten, die verbraucht werden können. Nach der Initialisierung der Schnittstelle wird das Register auf nur Nullen gesetzt und wird auf dem in einer Durchflußsteuerungsaktualisierungsnachricht (oben erwähnt) nach Empfang der Nachricht angezeigten Wert eingestellt.
Das Register der zugewiesenen Punkte führt eine Zählung der Gesamtzahl der dem Sender seit der Initialisierung zugewiesenen Punkte. Die Zählung wird anfangs gemäß der Puffergröße und der Zuweisungsrichtlinie des Empfängers eingestellt. Dieser Wert kann in den Durchflußsteuerungsaktualisierungsnachrichten enthalten sein. Der Wert wird inkrementiert, wenn die Empfängertransaktionsschicht verarbeitete Informationen aus ihrem Empfangspuffer entfernt. Die Größe des Inkrements ist mit der Größe des verfügbar gemachten Raums verbunden. Gemäß einer Ausführungsform sollten Empfänger in der Regel anfangs die zugewiesenen Punkte auf Werte setzen, die gleich oder größer als die folgenden Werte sind:

– PRH: 1 Durchflußsteuerungseinheit (FCU);
– PRD: FCU gleich die größtmögliche Einstellung der maximalen Nutzlastgröße der Vorrichtung;
– NPRH: 1FCU;
– NPRD: FCU gleich der größtmöglichen Einstellung der maximalen Nutzlastgröße der Vorrichtung;
– Schaltungsvorrichtung – CPLH: 1FCU;
– Schaltungsvorrichtung – CPLD: FCU gleich der größtmöglichen Einstellung der maximalen Nutzlastgröße der Vorrichtung oder der größtmöglichen Leseanforderung, welche die Vorrichtung jemals erzeugen wird, was immer das kleinere ist;
– Wurzel- und Endpunktvorrichtungen – CPLH oder CPLD: 255 FCU (alle 1), ein Wert, der von dem Sender als unendlich betrachtet wird und der damals niemals drosseln wird.

In Übereinstimmung mit dieser Implementation wird ein Empfänger in der Regel das Register zugewiesener Punkte nicht auf Werte, die größer als 127FCU sind, für jede Nachrichtenart setzen.
Gemäß einer alternativen Implementation kann ein Sender statt das Register der zugewiesenen Punkte unter Verwendung spezieller Verfahren zu führen, die zugewiesenen Punkte dynamisch in Übereinstimmung mit der folgenden Gleichung berechnen: C_A = (Punkteinheitszahl der zuletzt empfangenen Sendung) + (verfügbarer Empfangspufferraum)
Wie oben erwähnt implementiert ein Sender die konzeptuellen Register (verbrauchte Punkte, Punktegrenzen) für jeden der virtuellen Kanäle, die der Sender verwenden wird. Analog implementieren die Empfänger die konzeptuellen Register (zugewiesene Punkte) für jeden der virtuellen Kanäle, die durch den Empfänger unterstützt werden. Um die Sendung von Informationen proaktiv zu verhindern, wenn ihre Ausführung dazu führen würde, daß der Empfangspuffer überströmt, darf eine Sender eine Informationsart senden, wenn die Zählung der verbrauchten Punkte zuzüglich der Anzahl der mit den zu sendenden Daten verbundenen Punkteeinheiten geringer oder gleich des Punktegrenzwerts ist. Wenn ein Sender Durchflußsteuerungsinformationen für Vervollständigungen (CPL) empfängt, welche nicht endliche Punkte (d.h. < 255 FCU) anzeigen, wird der Sender die Vervollständigungen gemäß den verfügbaren Punkten drosseln. Beim Berechnen des Verbrauchs und der Rückgabe von Punkte werden Informationen von verschiedenen Transaktionen in einem Punkt nicht vermischt. Beim Berechnen von Punkteverbrauch und Rückgabe werden Header- und Dateninformationen von einer Transaktion in einem Punkt nie vermischt. Wenn einige Pakete somit von der Sendung blockiert werden, da Durchflußsteuerungspunkt(e) fehlen, werden die Sender somit den Sortierregeln (oben) folgen, wenn sie bestimmen, welche Paketarten die aufgehaltenen Pakete überholen dürfen. Die Rückgabe von Durchflußsteuerungspunkten für eine Transaktion wird nicht so ausgelegt, daß die Transaktion abgeschlossen wurde oder Systemsichtbarkeit erreicht hat. Die Nachrichtensignalunterbrechungen (MSI), die einen Speicherschreibanforderungssemantik verwenden, werden wie jede anderen Speicherschreibung behandelt. Wenn eine nachfolgende FC-Aktualisierennachricht (von dem Empfänger) einen geringen Punktegrenzwert anzeigt, als anfangs angezeigt worden ist, sollte der Sender die neue niedrigere Grenze einhalten und eine Fehlernachricht bereitstellen.
Wenn der Empfänger mehr Informationen empfängt, als er zugewiesene Punkte aufweist (welche die zugewiesenen Punkte überschreiten), wird ein Empfänger in Übereinstimmung mit dem hierin beschriebenen Durchflußsteuerungsmechanismus einen Empfangsüberstromfehler an den sendenden Sender anzeigen und eine Datenverbindungsschicht-Neuversuchsanforderung für das den Überstrom verursachende Paket initiieren.
Durchflußsteuerungspakete FCP)
Gemäß einer Implementation werden die Durchflußsteuerungsinformationen, die zum Führen der Register notwendig sind, siehe oben, unter Verwendung von Durchflußsteuerungspaketen (FCP) zwischen Vorrichtungen kommuniziert. Gemäß einer Ausführungsform bestehen die Durchflußsteuerungspakte aus einem 2-DW-Headerformat und übertragen Informationen für einen spezifischen virtuellen Kanal über den Status der sechs durch die Durchflußsteuerungslogik der Empfangstransaktionsschicht für jeden FC geführten Punkteregister. In Übereinstimmung mit den Lehren der vorliegenden Erfindung gibt es zwei Arten von FCP: Anfangs-FCP und Aktualisierungs-FCP, wie in 6 dargestellt.
Wie oben erwähnt, wird ein Anfangs-FCP 602 bei Initialisierung der Transaktionsschicht ausgegeben. Nach Initialisierung der Transaktionsschicht werden Aktualisierungs-FCP verwendet, um Informationen in den Registern zu aktualisieren. Der Empfang von Initialisierungs-FCP während des normalen Betriebs bewirkt ein Reset des lokalen Durchflußsteuerungsmechanismus und die Sendung eines Anfangs-FCP. Der Inhalt eines Anfangs-FCP enthält mindestens einen Teilsatz der angegebenen Punkte für jeden von PRH, PRD, NPRH, NPRD, CPH, CPD und Kanalkennung (z.B. der verbundene virtuelle Kanal, auf den sich die FC-Informationen beziehen). Das Format eines Aktualisieren-FCP ist ähnlich dem des Initialisierungs-FCP. Es sei darauf hingewiesen, daß obwohl der FC-Header das Längenfeld, das anderen Transaktionsschichtpaketheaderformaten gemein ist, nicht enthält, die Größe des Pakets eindeutig ist, da keine zusätzlichen DW-Daten mit diesem Paket verbunden sind.
Fehlerweiterleitung
Anders als herkömmliche Fehlerweiterleitungsmechanismen beruht die EGIO-Architektur nicht auf Tailer-Informationen, welche an Datengramm(en) angehängt werden, die aus einer Reihe von Gründen, wie unten erörtert, als defektiv identifiziert sind. Gemäß einer beispielhaften Implementation setzt die Transaktionsschicht 202 jede einer Vielzahl wohlbekannter Fehlererfassungstechniken ein, wie beispielsweise zyklische Redundanzprüfung (CRC), Fehlerkontrolle und dergleichen.
Gemäß einer Implementation verwendet die EGIO-Architektur zur Ermöglichung der Fehlerweiterleitungsmerkmale einen „Tailer", der an die TLP, die die bekannten schlechten Daten tragen, angehängt wird. Zu Beispielen von Fällen, in denen Tailer-Fehlerweiterleitung verwendet werden kann, gehören:

– Beispiel Nr. 1: Ein Lesen aus dem Hauptspeicher trifft einen unkorrigierbaren ECC-Fehler an;
– Beispiel Nr. 2: Paritätsfehler bei einer PCI-Schreibung in den Hauptspeicher;
– Beispiel Nr. 3: Datenintegritätsfehler in einem internen Datenpuffer oder Cache.

Gemäß einer beispielhaften Implementation wird die Fehlerweiterleitung nur für diese Vervollständigungsdaten oder die Schreibdaten verwendet. D.h. Fehlerweiterleitung wird für Fälle, in denen der Fehler in dem mit dem Datagramm verbundenen administrativen Overhead auftritt, z.B. ein Fehler in dem Header (z.B. Anforderungsphase, Adresse/Befehl usw.) typischerweise nicht angewendet. Wie hierin verwendet können Anforderungen/Vervollständigungen mit Headerfehlern allgemein nicht weitergeleitet werden, da ein wahres Ziel nicht positiv identifiziert werden könnte und daher eine solche Fehlerweiterleitung eine direkte oder eine Nebenwirkung bewirken könnte, wie beispielsweise Datenkorruption, Systemausfall usw. Gemäß einer Ausführungsform wird die Fehlerweiterleitung zur Verbreitung von Fehlern über das System, Systemdiagnostik verwendet. Fehlerweiterleitung verwendet keinen Wiederversuch der Datenverbindungsschicht und somit werden TLP, die mit dem Tailer enden, nur wieder versucht, wenn es Sendefehler in der EGIO-Verbindung 112 gibt, die durch den TLP-Fehlererfassungsmechanismus bestimmt werden (z.B. cyclische Redundanzprüfung, CRC, und dergleichen). Somit kann ein Tailer schließlich dazu führen, daß der Urheber der Anforderung sie wieder ausgibt (an der Transaktionsschicht von oben) oder eine andere Maßnahme trifft.
Wie hierin verwendet sind alle EGIO-Empfänger (z.B. in der EGIO-Schnittstelle 106) in der Lage, TLP, die mit einem Tailer enden, zu verarbeiten. Die Unterstützung zum Zufügen eines Tailers in einem Sender ist optional (und daher kompatibel mit Altgerätevorrichtungen). Die Schalter 108 leiten einen Tailer zusammen mit dem übrigen TLP weiter. Die Hostbrücken 104 mit Peer-Weiterleitungs-Unterstützung werden in der Regel einen Tailer gemeinsam mit dem übrigen TLP weiterleiten, müssen dies aber nicht tun. Die Fehlerweiterleitung gilt in der Regel für Daten in einer Schreibanforderung (eingetragen oder nicht eingetragen) oder eine Lesevervollständigung. TLP, von denen der Sender weiß, daß sie schlechte Daten enthalten, sollten mit dem Tailer enden.
Gemäß einer beispielhaften Implementation besteht ein Tailer aus 2 DW, wobei Bytes [7:5] alle Nullen sind (z.B. 0000) und Bit [4:1] alle Einsen sind (z.B. 1111), während alle anderen Bits reserviert sind. Ein EGIO-Empfänger wird all die Daten in einem TLP, die mit dem Tailer enden, als korrupt ansehen.
Beim Anlegen von Fehlerweiterleitung wird der Empfänger bewirken, daß alle Daten von dem angezeigten TLP als schlecht („vergiftet") mit einem Tag versehen werden. In der Transaktionsschicht wird ein Analysator in der Regel das Ende des gesamten TLP analysieren und sofort die folgenden Daten prüfen, um zu verstehen, ob die Daten vollständig sind oder nicht.
Datenverbindungsschicht 204
Wie oben erwähnt agiert die Datenverbindungsschicht 204 aus 2 als Zwischenstufe zwischen der Transaktionsschicht 202 und der Physikalischen Schicht 206. Die hauptsächliche Verantwortlichkeit der Datenverbindungsschicht 204 ist das Bereitstellen eines zuverlässigen Mechanismus zum Austauschen von Transaktionsschichtpakten (TLP) zwischen zwei Komponenten über eine EGIO-Verbindung 112. Die Sendeseite der Datenverbindungsschicht 204 nimmt TLP, die durch die Transaktionsschicht 202 zusammengesetzt wurden, legt einen Paketsequenzidentifizierer (z.B. eine Identifikationsnummer) an, berechnet und legt einen Fehlererkennungscode (z.B. CRC-Code) an und überträgt die modifizierten TLP an die physikalische Schicht 206 zum Senden über einen oder mehrere ausgewählte virtuelle(n) Kanal/Kanäle, der/die in der Bandbreite der EGIO-Verbindung 112 eingerichtet sind.
Die empfangende Datenverbindungsschicht 204 ist zur Prüfung der Integrität der empfangenen TLP (z.B. unter Verwendung von CRC-Mechanismen usw.) und für das Senden solcher TLP verantwortlich, für die Integritätsprüfung positiv war, an die Transaktionsschicht 204 zum Auseinandernehmen vor Weiterleitung an den Vorrichtungskern.
Zu den von der Datenverbindungsschicht 204 allgemein bereitgestellten Diensten gehört der Datenaustausch, die Fehlererkennung und der Neuversuch, die Initialisierungs- und Leistungsmanagementdienste und Datenverbindungsschicht-Interkommunikationsdienste. Jeder dieser angebotenen Dienste, die unter jeder der vorgenannten Kategorien angeboten werden, werden unten aufgelistet.
Datenaustauschdienste

– TLP zur Sendung von der Sendetransaktionsschicht annehmen;
– TLP, die über die Verbindung von der physikalischen Schicht empfangen wurden, annehmen und an die Empfangstransaktionsschicht übermitteln Fehlererkennung und Neuversuch
– TLP-Sequenznummer und CRC-Erzeugung
– Speicherung der gesendeten TLP für den Neuversuch der Datenverbindungsschicht
– Datenintegritätsprüfung
- Bestätigung und Neuversuch DLLP
- Fehleranzeigen für Fehlerberichte und Protokollmechanismen
– Verbindungsbest.-Timout-Timer Initialisierungs- und Leistungsmanagementdienste
– Verbindungsstatus verfolgen und aktiv/reset/unterbrochener Status an die Transaktionsschicht übermitteln Datenverbindungsschicht-Interkommunikationdienste
– Für die Verbindungsmanagementfunktionen einschließlich Fehlererfassung und Neuversuch verwendet
– Zwischen Datenverbindungsschichten der zwei direkt verbundenen Komponenten übertragen
– nicht für Transaktionsschichten offengelegt

Wie in der EGIO-Schnittstelle 106 verwendet, erscheint die Datenverbindungsschicht 204 als eine Informationsleitung mit veränderlicher Latenz zu der Transaktionsschicht 202. Alle in die Sendedatenverbindungsschicht eingeführten Informationen werden später am Ausgabe der Empfangsdatenverbindungsschicht erscheinen. Die Latenz hängt von einer Reihe von Faktoren ab, einschließlich der Pipelinelatenzen, Breite und Betriebsfrequenz der Verbindung 112, Sendung von Kommunikationssignalen über das Medium und Verzögerungen durch Datenverbindungsschichtneuversuche. Aufgrund dieser Verzögerungen kann die Sendedatenverbindungsschicht Druck auf die Sendetransaktionsschicht 202 ausüben und die Empfangsda tenverbindungsschicht kommuniziert das Vorhandensein oder Fehlen gültiger Informationen an die Empfangstransaktionsschicht 202.
Gemäß einer Implementation verfolgt die Datenverbindungsschicht f204 den Status der EGIO-Verbindung 112. In dieser Hinsicht kommuniziert der DLL 204 den Verbindungsstatus an die Transaktions- 202 und die physikalische Schicht 206 und führt Verbindungsmanagement über die physikalische Schicht 206 aus. Gemäß einer Implementation enthält die Datenverbindungsschicht eine Verbindungskontrolle und eine Managementstatusmaschine, um solche Managementaufgaben auszuführen. Der Status dieser Maschine wird unten beschrieben.

Beispiel DLL-Verbindungsstatus: – LinkDown (LD) – Physikalische Schicht berichtet, daß Verbindung nicht betriebsfähig oder Port nicht angeschlossen;
– LinkInit (LI) – Physikalische Schicht berichtet, daß Verbindung betriebsfähig und initialisiert ist;
– LinkActive (LA) – Normaler Betriebsmodus;
– LinkActDefer (LAD) – Normaler Betrieb unterbrochen, physikalische Schicht versucht die Wiederaufnahme Entsprechende Managementregeln pro Status (siehe z.B. 8) – LinkDown (LD) Anfangsstatus nach Reset der Komponente nach Eintritt in LD
– Alle Datenverbindungsschichtstatusinformationen auf voreingestellte Werte zurückstellen Während in LD: – Keine TLP-Informationen mit der Transaktions- oder physikalischen Schicht austauschen
– Keine DLLP-Informationen mit der physikalischen Schicht austauschen
– Keine DLLP erzeugen oder annehmen Ausgabe zu LI, wenn: – Anzeige von Transaktionsschicht, daß die Verbindung nicht deaktiviert ist durch SW
– LinkInit (LI) Während in LI: – Keine TLP-Informationen mit der Transaktions- oder Physikalischen Schicht austauschen;
– Keine DLLP-Informationen mit der physikalischen Schicht austauschen;
– Keine DLLP erzeugen oder annehmen Ausgabe zu LA, wenn: – Anzeige von der physikalischen Schicht, daß die Verbindungseinrichtung erfolgreich war Ausgabe zu LD, wenn – Anzeige von der physikalischen Schicht, daß die Verbindungseinrichtung fehlschlug
– LinkAktive (LA) Während in LA: – Austausch von TLP-Informationen mit der Transaktions- und physikalischen Schicht;
– Austausch von DLLP-Informationen mit der physikalischen Schicht
– DLLP erzeugen und annehmen Ausgabe zu LinkActDefer, wenn: – Anzeige von dem Datenverbindungsschichtneuversuch- Managementmechanismus, daß Neuverbindungseinrichtung erforderlich ODER wenn die physikalische Schicht berichtet, daß eine Neuverbindungseinrichtung abläuft
– LinkActDefer (LAD) Während in LinkActDefer: – Keine TLP-Informationen mit der Transaktions- oder physikalischen Schicht austauschen
– Keine DLLP-Informationen mit der physikalischen Schicht austauschen
– Keine DLLP erzeugen oder annehmen Ausgabe zu LinkAktiv, wenn: – Anzeige von der physikalischen Schicht, daß die Neuverbindungseinrichtung erfolgreich war Ausgabe zu LinkDown, wenn: – Anzeige von der physikalischen Schicht, daß die Neuverbindungseinrichtung nicht erfolgreich war.

Datenintegritätsmanage
Wie hierin verwendet, werden Datenverbindungsschichtpakete (DLLP) verwendet, um die EGIO-Verbindungsdatenintegritätsmechanismen zu unterstützen. In dieser Hinsicht stellt die EGIO-Architektur gemäß einer Implementation die folgenden DLLP bereit, um die Verbindungsdatenintegritätsmanagement zu unterstützen:

– Ack DLLP: TLP-Sequenznummer-Bestätigung – verwendet, um erfolgreichen Empfang einiger Zahlen von TLP anzuzeigen
– Nack DLLP: TLP-Sequenznummer-Negativbestätigung – verwendet, um einen Datenverbindungsschicht-Neuversuch anzuzeigen
– Ack Timeout DLLP: Zeigt zuletzt gesendete Sequenznummer an – verwendet, um einige Formen von TLP-Verlust zu erfassen.

Wie oben erwähnt, stellt die Transaktionsschicht 202 TLP-Grenzinformationen an die Datenverbindungsschicht 204 bereit, wodurch der DLL 204 ermöglicht wird, eine Sequenznummer und eine zyklische Redundanzprüfungs-(CRC)-Fehlererkennung an dem TLP auszuführen. Gemäß einer beispielhaften Implementation validiert die Empfangsdatenverbindungsschicht empfangene TLP durch Prüfen der Sequenznummer, CRC-Code und aller Fehleranzeigen von der physikalischen Empfangsschicht. Im Falle eines Fehlers in einem TLP wird der Datenverbindungsschicht-Neuversuch zur Wiederherstellung verwendet.
CRC, Sequenznummer und Neuversuchmanagement (Sender)
Die Mechanismen, welche verwendet werden, um zu die TLP-CRC und die Sequenznummer zu bestimmen und den Datenverbindungsschicht-Neuversuch zu unterstützen werden mit Bezug auf konzeptueller „Zähler" und „Flags" wie folgt beschrieben
CRC und Sequenznummerregeln (Sender)
Die folgenden 8bit-Zähler werden verwendet:

– TRANS_SEQ – Speichert die Sequenznummer, die an die zum Senden vorbereiteten TLP angelegt wird
– Alle ,0' in den LinkDown-Status setzen
– Nach jedem Senden eines TLP um 1 inkrementieren
– Wenn alle ,1', bewirkt die Inkrementation ein Zurückstellen auf alle ,0'
– Empfang von Nak DLLP verursacht ein Zurückstellen des Werts auf die Sequenznummer, die in Nak DLLP angezeigt wird
– ACKD_SEQ – Speichert die Sequenznummer, die in dem zuletzt empfangenen Verbindung-zu-Verbindungs-Bestätigungs-DLLP bestätigt wurde
– Auf alle ,1' im LinkDown-Status einstellen
– Jedem TLP wird eine 8-Bit-Sequenznummer zugewiesen
– Der Zähler TRANS_SEQ speichert diese Nummer
– Wenn TRANS_SEQ gleich (ACKD_SEQ – 1) Modul 256, sollte der Sender in der Regel kein anderes TLP senden, bis ein Ack DLLP ACKD_SEQ aktualisiert, so daß die Bedingung (TRANS_SEQ == ACKD_SEQ – 1) Modul 256 nicht länger gilt. TRANS SEQ wird an das TLP angelegt durch:
– Voranstellen des einzigen Bytewerts in dem TLP
– Voranstellen eines einzigen reservierten Bytes an das TLP
– Eine 32b-CRC wird für das TLP unter Verwendung des folgenden Algorithmus berechnet und an das Ende des TLP angehängt
– Das verwendete Polynomial ist 0x04C11DB7
– Dieselbe CRC-32 wird von Ethernet verwendet
– Das Verfahren für die Berechnung ist wie folgt: 1) Der Anfangswert der CRC-32-Berechnung ist das durch Voranstellen gebildete DW 26 ,0' zu der Sequenzzahl 2) Die CRC-Berechnung wird unter Verwendung jedes der DW des TLP aus der Transaktionsschicht in der Reihenfolge von dem DW einschließlich Byte 0 des Headers zu dem letzten DW des TLP weitergeführt. 3) Die Bitsequenz aus der Berechnung wird vervollständigt und das Ergebnis ist die TLP-CRC 4) Das CRC-DW wird an das Ende des TLP angefügt.
– Kopien der gesendeten TLP sollten in der Regel in dem Datenverbindungsschicht-Neuversuchpuffer gespeichert sein
– Wenn ein Ack DLLP von der anderen Vorrichtung empfangen wird:
– ACKD_SEQ wird mit dem in DLLP spezifizierten Wert geladen
– Der Neuversuchspuffer wird von TLP gereinigt, die Sequenznummern im Bereich von:
– von dem vorherigen Wert von ACKD_SEQ + 1
– bis zu dem neuen Wert von ACKD_SEQ aufweisen
– Wenn ein Nak DLLP von der anderen Komponente der Verbindung empfangen wird:
– Wenn ein TLP gegenwärtig an die physikalische Schicht gesendet wird hält der Transfer an, bis der Transfer des TLP vollständig ist
– Zusätzliche TLP werden nicht von der Transaktionsschicht genommen, bis die folgenden Schritte vollständig sind:
– der Neuversuchspuffer wird von TLP gereinigt, die eine Sequenznummer im Bereich von
– dem vorherigen Wert von ACKD_SEQ + 1
– dem in dem Nak-Sequenznummernfeld des Nak DLLP spezifizierten Wert aufweisen
– Alle übrigen TLP in dem Neuversuchspuffer werden der physikalischen Schicht erneut zur erneuten Sendung in der ursprünglichen Reihenfolge vorgelegt
– Hinweis: Dies schließt alle TLP mit Sequenznummer im Bereich von
– Dem in dem Nak-Sequenznummernfeld von Nak DLLP+ spezifizierten Wert
– dem Wert von TRANS_SEQ – 1 mit ein.
– Wenn es keine übrigen TLP in dem Neuversuchspuffer gibt, war Nak DLLP fehlerhaft
– Das fehlerhafte Nak DLLP sollte in der Regel gemäß dem Abschnitt Fehlerverfolgung und Protokollieren gemeldet werden
– Keine weiteren Vorkehrungen durch den Sender notwendig.

CRC und Sequenznummer (Empfänger)
Analog werden die zum Prüfen der TLP-CRC und der Sequenznummer und zur Unterstützung des Datenverbindungsschichtneuversuchs verwendeten Mechanismen hinsichtlich konzeptueller „Zähler" und „Flags" wie folgt beschrieben:

– Der folgende 8-Bit-Zähler wird verwendet:
– NEXT_RCV_SEQ – Speichert die für das nächste TLP erwartete Sequenznummer
– Alle ,0' in den LinkDown-Status setzen
– Für jedes angenommene TLP oder wenn DLLR_IN_PROGRESS um 1 inkrementiert Flag (unten beschrieben) wird durch Annehmen eines TLP geleert
– Mit dem Wert (Trans. Seq. Num + 1) jedes Mal dann geladen, wenn ein Verbindungsschicht-DLLP empfangen wird und das DLLR_IN_PROGRESS-Flag leer ist.
– Verlust von Sequenznummernsynchronisation zwischen Sender und Empfänger wird angezeigt, wenn der Wert von NEXT_RCV_SEQ von dem durch ein empfangenes TLP oder Ack Timeout DLLP spezifizierten Wert abweicht; in diese Fall:
– Wenn das DLLR_IN_PROGRESS-Flag gesetzt ist
– DLLR_IN_PROGRESS-Flag zurückstellen
– einen „schlechtes DLLR DLLP gesendet"-Fehler an Fehlerprotokollierung/Verfolgung signalisieren
– Hinweis: Dies zeigt an, daß ein DLLR DLLP (Nak) fehlerhaft gesendet wurde
– Wenn das DLLR_IN_PROGRESS-Flag nicht gesetzt ist
– DLLR_IN_PROGRESS-Flag setzen und Nak DLLP initialisieren
– Hinweis: Dies zeigt an, daß ein TLP verloren ging
– Der folgende 3-Bit-Zähler wird verwendet:
– DLLRR_COUNT – Zählt die Anzahl von Malen, die DLLR DLLP in einer spezifischen Zeitdauer ausgegeben wurde
– b'000 in den LinkDown-Status stellen
– Um 1 für jedes ausgegebene Nak DLLP inkrementiert
– Wenn die Zählung b'000 erreicht:
– Die Verbindungssteuerstatusmaschine bewegt sich von LinkActive zu LinkActDefer
– DLLRR_COUnt wird dann auf b'000 zurückgestellt
– Wenn DLLRR_COUNT nicht gleich b'000 ist, alle 256 Symbole um 1 dekrementieren
– d.h.: bei b'000 gesättigt
– Das folgende Flag wurde verwendet:
– DLLR_IN_PROGRESS
– Bedingungen zum Setzen/Leeren unten beschrieben
– Wenn DLLR_IN_PROGRESS gesetzt, werden alle empfangenen TLP zurückgewiesen (bis das durch DLLR DLLP angezeigte TLP empfangen wird)
– Wenn DLLR_IN_PROGRESS leer ist, werden empfangene TLP wie unten beschrieben geprüft
– Für ein anzunehmendes TLP sollten in der Regel die folgenden Bedingungen erfüllt sein:
– Die Sequenznummer des empfangenen TLP ist gleich NEXT_RCV_SEQ
– Die physikalische Schicht hat beim Empfang des TLP keine Fehler angezeigt
– Die TLP-CRC-Prüfung zeigt keinen Fehler an
– Wenn ein TLP angenommen wird:
– Wird der Transaktionsschichtteil des TLP an die Empfangstransaktionsschicht weitergeleitet
– Wenn gesetzt, wird das DLLR_IN_PROGRESS geleert
– NEXT_RCV_SEQ wird inkrementiert
– Wenn ein TLP nicht angenommen wird:
– Ist das DLLR_IN_PROGRESS-Flag gesetzt
– Ein Nak DLLP wird gesendet
– Das Ack/Nak-Sequenznummerfeld sollte in der Regel den Wert (NEXT_RCV_SEQ – 1) enthalten
– Das Nak-Typ-(NT)-Feld sollte in der Regel den Grund für das Nak anzeigen:
– b'00 – Durch physikalische Schicht identifizierten Fehler empfangen
– b'01 – TLP-CRC-Prüfung fehlgeschlagen
– b'10 – Sequenznummer nicht korrekt
– b'11 – Durch physikalische Schicht identifizierten Rahmenfehler
– Der Empfänger sollte in der Regel nicht zulassen, daß die Zeit von dem Empfang der CRC für ein TLP für die Sendung von Nak 1023 Symbolzeiten überschreitet, gemessen von dem Port der Komponente
– Hinweis: NEXT_RCV_SEQ wird nicht inkrementiert
– Wenn die Empfangsdatenverbindungsschicht innerhalb von 512 Symbolzeiten nach einem Nak DLLP nicht das erwartete TLP empfängt, wird das Nak DLLP wiederholt
– Wenn nach vier Versuchen das erwartete TLP immer noch nicht empfangen worden ist, wird der Empfänger:
– In den LinkActDefer-Status eintreten und eine Verbindungswiederherstellung durch die physikalische Schicht initialisieren
– Das Auftreten eines größeren Fehlers an Fehlerverfolgen und Protokollieren anzeigen
– Datenverbindungsschicht-Bestätigungs-DLLP sollten in der Regel gesendet werden, wenn die folgenden Bedingungen gelten:
– Datenverbindungssteuerungs- und Managementstatusmaschinen ist im LinkActive-Status
– TLP wurden angenommen, aber noch nicht durch das Senden eines Bestätigungs-DLLP bestätigt
– Mehr als 512 Symbolzeiten sind seit dem letzten Bestätigungs-DLLP verstrichen
– Datenverbindungsschicht-Bestätigungs-DLLP können öfter als notwendig gesendet werden
– Datenverbindungsschicht-Bestätigungs-DLLP spezifizieren den Wert (NEXT_RCV_SEQ – 1) in dem AckSequenznummernfeld.

Ack-Timeout-Mechanismus
Angenommen sei der Fall, daß ein TLP in der Verbindung 112 so korrumpiert wird, daß der Empfänger das Vorhandensein des TLP nicht erfaßt. Das verlorene TLP wird erfaßt, wenn ein nachfolgendes TLP gesendet wird, da die TLP-Sequenznummer nicht mit der an dem Empfänger erwarteten Sequenznummer übereinstimmen wird. Die Sendedatenverbindungsschicht 204 kann jedoch die Zeit, in der ihr das nächste TLP von der Sendetransportschicht präsentiert wird im allgemeinen nicht begrenzen. Der Ack-Timeout-Mechanismus ermöglicht es dem dem Sender, die Zeit, die notwendig ist, damit der Empfänger das verlorene TLP erfaßt, zu begrenzen.
Regeln für den Ack-Timeout-Mechanismus

– Wenn der Sendeneuversuchpuffer TLP enthält, für die keine Ack DLLP empfangen worden sind und wenn keine TLP oder Verbindungs-DLLP für eine 1024 Symbolzeiten überschreitende Zeitdauer gesendet worden sind, sollte in der Regel ein Ack-Timeout-DLLP gesendet werden.
– Nach der Sendung eines Ack-Timeout-DLLP sollte die Datenverbindungsschicht in der Regel keine TLP an die physikalische Schicht zur Sendung weiterleiten, bis ein Bestätigungs-DLLP von der Komponente auf der anderen Seite der Verbindung empfangen worden ist.
– Wenn kein Bestätigungs-DLLP für eine 1023 Symbolzeiten überschreitende Zeit empfangen worden ist, wird das Ack-Timeout-DLLP erneut gesendet.
– 1024 Symbolzeiten nach vierten aufeinanderfolgenden Sendung des DLLP ohne Empfang eines Bestätigungs-DLLP
– Eintreten in den LinkActDefer-Status und Initiieren der Verbindung unter Aufrechterhalten der physikalischen Schicht
– Anzeigen des Auftretens eines größeren Fehlers an Fehlerverfolgung und Protokollierung

Physikalische Schicht 206
Weiter unter Bezugnahme auf 2 wird die physikalische Schicht 206 dargestellt. Wie hierin verwendet, isoliert die physikalische Schicht 206 die Transaktion 202 und die Datenverbindungsschichten 204 von der Signalgebungstechnologie, die für den Verbindungsdatenaustausch verwendet wird. In Übereinstimmung mit der dargestellten beispielhaften Implementa tion aus 2 ist die physikalische Schicht in logische 208 und physikalische Funktionsunterblöcke unterteilt.
Wie hierin verwendet, ist der logische Unterblock 208 verantwortlich für die digitalen Funktionen der physikalischen Schicht 206. In dieser Hinsicht weist der logische Unterblock 204 zwei Hauptunterteilungen auf: einen Senderabschnitt, der herausgehende Informationen zur Sendung durch den physikalischen Unterblock 210 vorbereitet, und deinen Empfangsabschnitt, der empfangene Informationen vor der Weiterleitung an die Verbindungsschicht 204 identifiziert und vorbereitet. Der logische Unterblock 208 und der physikalische Unterblock 210 koordinieren den Portstatus durch eine Status- und Kontrollregisterschnittstelle. Kontroll- und Managementfunktionen der physikalischen Funktionen 206 werden durch den logischen Unterblock 208 geleitet.
Gemäß einer beispielhaften Implementation setzt die EGIO-Architektur einen 8b/10b-Sendecode ein. Unter Verwendung dieses Schemas werden die 8-Bit-Zeichen als auf eine Vier-Bit-Gruppe bzw. eine Sechs-Bit-Gruppe abgebildete 3-Bit- bzw. 5-Bit-Zeichen behandelt. Diese Codegruppen werden aneinandergehängt, um ein 10-Bit-Symbol zu bilden. Das 8b/10b-Codierungsschema, das durch die EGIO-Architektur verwendet wird, stellt spezielle Symbole bereit, welche sich von den Datensymbolen unterscheiden, die verwendet werden, um die Zeichen darzustellen. Diese speziellen Symbole werden für verschiedene Verbindungsmanagementmechanismen unten verwendet. Spezielle Symbole werden auch zur Rahmengebung von DLLP und TLP unter Verwendung unterschiedlicher spezieller Symbole verwendet, um diese zwei Arten von Paketen schnell und einfach unterscheidbar zu machen.
Der physikalische Unterblock 210 enthält einen Sender und einen Empfänger. Der Sender wird von dem logischen Unterblock 208 mit Symbolen versorgt, welche er in Serie ordnet und auf der Verbindung 112 sendet. Der Empfänger wird mit den in Serie geordneten Symbolen von der Verbindung 112 versorgt. Er wandelt die empfangenen Signale in Bitströme um, welche in Serie geordnet und dem logischen Unterblock 208 mit einem aus dem eingehenden Serienstrom wiedergewonnenen Symboltakt zugeführt werden. Es versteht sich, daß sie EGIO-Verbindung 112, wie hierin verwendet, jedes einer großen Bandbreite von Kommunikationsmedien darstellen kann, einschließlich einer elektrischen Kommunikationsverbindung, einer optischen Kommunikationsverbindung, einer Hochfrequenzkommunikationsverbindung, einer Infrarotkommunikationsverbindung, einer Funkkommunikationsverbindung und der gleichen. In dieser Hinsicht eignet sich jeder des/der den physikalischen Unterblock 210 der physikalischen Schicht 206 umfassenden Sender und/oder Empfänger für eine oder mehrere der vorhergehenden Kommunikationsverbindungen.
BEISPIELHAFTER KOMMUNIKATIONSAGENT
5 veranschaulicht ein Blockdiagramm eines beispielhaften Kommunikationsagenten, der mindestens einen Teilsatz der mit der vorliegenden Erfindung verbundenen Merkmale verkörpert in Übereinstimmung mit einer beispielhaften Implementation der vorliegenden Erfindung. In Übereinstimmung mit der dargestellten beispielhaften Implementation aus 5 wird der Kommunikationsagent 500 so dargestellt, daß er eine Steuerlogik 502, eine EGIO-Kommunikationsmaschine 504, einen Speicherraum für Datenstrukturen 506 und optional ein oder mehrere Anwendungen 508 umfaßt. Wie hierein verwendet stellt die Steuerlogik 502 Verarbeitungsressourcen für jedes des einen oder der mehreren Element der EGIO-Kommunikationsmaschine 504 bereit, um gezielt einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren. In dieser Hinsicht soll die Steuerlogik 502 einen Mikroprozessor, eine Mikrosteuerung, eine Endstatusmaschine, eine programmierbare logische Vorrichtung, ein feldprogrammierbarer Gatearray und/oder Inhalt darstellen, welcher, wenn er ausgeführt wird, die Steuerlogik implementiert, um als der oben Genannten zu fungieren.
Die EGIO-Kommunikationsmaschine 504 wird dargestellt als eine Transaktionsschichtschnittstelle 202, eine Datenverbindungsschichtschnittstelle 204 und/oder eine physikalische Schichtschnittstelle 206 umfassend, welche einen logischen Unterblock 208 und einen physikalischen Unterblock 210 enthält, um eine Schnittstelle zwischen dem Kommunikationsagenten 500 und der EGIO-Verbindung 112 zu bilden.
Wie hierin verwendet führen die Elemente der EGIO-Kommunikationsmaschine 504 ähnliche oder sogar äquivalente Funktionen zu den oben beschriebenen aus.
In Übereinstimmung mit der dargestellten beispielhaften Implementation aus 5 wird der Kommunikationsagent 500 als Datenstrukturen 506 umfassend dargestellt. Wie im folgenden unter Bezugnahme auf 7 näher dargelegt, können die Datenstrukturen 506 Speicherraum, E/A-Raum, Konfigurationsraum und Nachrichtenraum enthalten, der von der Kommunikati onsmaschine 504 verwendet wird, um die Kommunikation zwischen elektronischen Vorrichtungen zu ermöglichen.
Wie hierin verwendet sollen die Anwendungen 508 beliebige einer großen Bandbreite von Anwendungen darstellen, welche gezielt von der Kommunikationsmaschine 500 aufgerufen werden, um das EGIO-Kommunikationsprotokoll und damit verbundene Managementfunktionen zu implementieren.
BEISPIELHAFTE DATENSTRUKTUR(EN)
Unter Bezugnahme auf 7 wird eine graphische Darstellung einer oder mehrerer Datenstruktur(en) dargestellt, welche durch die EGIO-Schnittstelle(n) in Übereinstimmung mit einer Implementation der vorliegenden Erfindung eingesetzt werden. Insbesondere sind unter Bezugnahme auf die in 7 dargestellte beispielhafte Implementation vier (4) Adressräume zur Verwendung in der EGIO-Architektur definiert: der Konfigurationsraum 710, der E/A-Raum 720, der Speicherraum 730 und der Nachrichtenraum 740. Wie gezeigt enthält der Konfigurationsraum 710 ein Headerfeld 712, welches die EGIO-Kategorie definiert, zu der eine Hostvorrichtung (z.B. Endpunkt usw.) gehört. Jeder eines solchen Adressraums führt seine jeweiligen oben angeführten Funktionen aus.
Nach der obigen Vorstellung der architektonischen und Protokollelemente, die mit der vorliegenden Erfindung verbunden sind, wird die Aufmerksamkeit nun mit Bezug auf 1-8 auf 10 gerichtet, in der ein Flußdiagramm eines beispielhaften Verfahrens zum Managen der physikalischen Kommunikationsressourcen der verbesserten allgemeinen Eingabe-/Ausgabe-Architektur vorgestellt wird.
Unter Bezugnahme auf 10 wird ein Flußdiagramm eines beispielhaften Verfahrens zum Errichten und Managen eines oder mehrerer virtueller Kanal/Kanäle in den physikalischen Ressourcen der unterstützten Eingabe-/Ausgabe-Verbindung in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung dargestellt. In Übereinstimmung mit der dargestellten beispielhaften Implementation aus 10 beginnt das Verfahren bei Block 1002, in dem eine EGIO-Schnittstelle 106 Informationen zur Sendung an eine andere Komponente empfängt. In Übereinstimmung mit einer beispielhaften Ausführungsform emp fängt die Empfangsschicht 202 einer EGIO-Schnittstelle 106 die Informationen von einem Verarbeitungsagenten in einer Hostkomponente.
In Block 1004 bestimmt die EGIO-Schnittstelle 106, ob die empfangenen Informationen mit einem eingerichteten virtuellen Kanal verbunden sind, oder ob ein neuer virtueller Kanal notwendig ist. Gemäß einer Implementation trifft die Transaktionsschicht 202 eine solche Bestimmung, indem sie die Quelle und das Ziel der Information identifiziert. Wenn in Block 1004 die Transaktionsschicht 202 die Information als mit einem bestehenden virtuellen Kanal verbunden identifiziert, erzeugt die Transaktionsschicht 202 Transaktionsschichtpakete (TLP), die mit dem entsprechenden virtuellen Kanal verbunden sind, um die empfangenen Informationen über die physikalische Verbindungsschicht 206 an den entsprechenden virtuellen Kanal zur Sendung über die allgemeinen Eingabe/Ausgaberessourcen zu senden, Block 1006.
Wenn in Block 1004 die Informationen die Schaffung eines neuen virtuellen Kanals erfordert, trifft die Transaktionsschicht 202 eine weitere Bestimmung über den erforderlichen Art des virtuellen Kanals, Block 1008. Gemäß einer beispielhaften Implementation, die oben erwähnt wurde, trifft die Transaktionsschicht 202 diese Bestimmung mindestes teilweise basierend auf dem Inhalt der empfangenen Informationen. Gemäß einer beispielhaften Implementation, die oben erwähnt wurde, stellt die EGIO-Architektur Unterstützung für mehrere Arten virtueller Kanäle bereit, die auf der Basis der mit der zu kommunizierenden Information verbundenen Dienstgüteanforderung ausgewählt werden. In dieser Hinsicht bestimmt die Transaktionsschicht 202, ob die empfangene Information zeitabhängig (isochron) ist, und wenn ja, richtet einen oder mehrere isochrone Kanäle ein, um die Sendung einer solchen Information zu unterstützen. Gemäß einer Ausführungsform wird der Art des Inhalts durch eine Analyse des Inhalts selbst bestimmt oder aus dem Art des den Inhalt an die Transaktionsschicht liefernden Agenten abgeleitet (z.B. Anwendungsart).
In Block 1012 richtet die EGIO-Schnittstelle 106 einen virtuellen Kanal mit separater Durchflußsteuerung und Sortierregeln ein, mit denen die Informationen über die physikalischen Ressourcen der EGIO-Verbindung 112 an eine andere Komponente gesendet werden müssen. Insbesondere erzeugt die Transaktionsschicht 202, wie oben erwähnt, Transaktionsschichtpaket(e), die den Art des virtuellen Kanals zur Lieferung durch die Datenverbindungsschicht 204 an die physikalische Schicht zum Weiterleiten auf das physikalische Medium der EGIO- Verbindung 112 bezeichnen. In Übereinstimmung mit den Lehren der vorliegenden Erfindung, die oben erwähnt wurden, führt die Transaktionsschicht 202 separate Durchflußsteuerung und Sortierregeln für jeden der virtuellen Kanäle, die durch die Transaktionsschicht 202 eingerichtet wurden. In dieser Hinsicht wurde eine Architektur, ein Protokoll und verwandte Verfahren zum Errichten und Managen mehrerer virtueller Kanäle in den physikalischen Ressourcen einer EGIO-Verbindung 112 beschrieben.
ALTERNATIVE AUSFÜHRUNGSFORMEN
9 ist ein Blockdiagramm eines Speichermediums mit einer darauf gespeicherten Vielzahl von Anweisungen, einschließlich Anweisungen zur Implementation eines oder mehrerer Aspekte der EGIO-Verbindungsarchitektur und des Kommunikationsprotokolls, gemäß noch einer weiteren Ausführungsform der vorliegenden Erfindung. Im allgemeinen veranschaulicht 9 ein(e) maschinenzugreifbare(s) Medium/Vorrichtung 900 mit darauf/darin gespeichertem Inhalt, einschließlich mindestens eines Teilsatzes, der beim Ausführen durch eine Zugriffsmaschine die innovative EGIO-Schnittstelle 106 der vorliegenden Erfindung implementiert.
Wie hierin verwendet soll das maschinenzugreifbare Medium 900 ein beliebiges einer Vielzahl von dem Fachmann bekannten Medien darstellen, wie beispielsweise flüchtige Speichervorrichtungen, nicht-flüchtige Speichervorrichtungen, magnetische Speichervorrichtungen, optische Speichervorrichtungen, verbreitete Signale und dergleichen. Die ausführbaren Anweisungen sollen analog eine beliebige einer Vielzahl von im Fachgebiet bekannten Softwaresprachen wiedergeben, wie z.B. C++, Visual Basic, Hypertext Markup Language (HTML), Java, eXtensible Markup Language (XML) und dergleichen. Außerdem sei darauf hingewiesen, daß das Medium 900 nicht gemeinsam mit einem Hostsystem angeordnet sein muß. Das heißt, das Medium 900 kann in entfernten Server angesiedelt sein, der kommunikativ an das ausführende System gekoppelt und von diesem aus zugreifbar ist. Dementsprechend muß die Softwareimplementation aus 9 als veranschaulichend aufgefaßt werden, da alternativ Speichermedien und Softwareausführungsformen in dem Schutzumfang der vorliegenden Erfindung vorgesehen sind.
Obwohl die Erfindung in der ausführlichen Beschreibung sowie in der Zusammenfassung mittels für die strukturellen Merkmale und/oder methodologischen Schritte charakteristischen Sprache beschrieben worden ist, versteht sich, daß die in den beigefügten Ansprüchen definierte Erfindung nicht notwendigerweise auf die beschriebenen spezifischen Merkmale oder Schritte beschränkt ist. Vielmehr werden die spezifischen Merkmale und Schritte lediglich als beispielhafte Formen der Implementation der beanspruchten Erfindung verwendet. Es wird jedoch ersichtlich sein, daß verschiedene Abwandlungen und Änderungen daran vorgenommen werden können, ohne den weiteren Umfang der vorliegenden Erfindung zu verlassen. Die vorliegende Beschreibung und die Figuren sind dementsprechend als veranschaulichend und nicht als einschränkend anzusehen. Die Beschreibung und die Zusammenfassung sollten nicht erschöpfend sein oder die vorliegende Erfindung auf die genauen offenbarten Formen einschränken.
Die in den folgenden Ansprüchen verwendeten Begriffe sollten nicht so ausgelegt werden, daß sie die spezifischen in der Beschreibung offengelegten Ausführungsformen einschränken. Vielmehr soll der Umfang der vorliegenden Erfindung vollkommen durch die folgenden Ansprüche bestimmt werden

Claims

Verfahren, umfassend: Empfangen von Informationen zum Senden zu einem externen Agenten durch einen allgemeinen Eingabe-/Ausgabebus (1002); dynamisches Zuordnen eines Teilsatzes einer Gesamtbandbreite, die über den allgemeinen Eingabe-/Ausgabebus verfügbar ist, als virtuellen Kanal, um ein Senden der Informationen zu einer kommunikativ angekoppelten Komponente zu ermöglichen; gekennzeichnet durch Identifizieren einer Art von virtuellem Kanal, durch den das Senden der Informationen ermöglicht werden soll, zumindest teilweise auf der Basis des Inhaltes der empfangenen Informationen (1008).
Verfahren nach Anspruch 1, wobei das Identifizieren einer Art von virtuellem Kanal umfaßt: Bestimmen, ob die empfangenen Informationen isochronen Inhalt enthalten; und Errichten eines isochronen virtuellen Kanals zur Erleichterung des Sendens des isochronen Inhalts, falls verfügbar (1010).
Verfahren nach Anspruch 2, des Weiteren umfassend: Errichten eines allgemeinen virtuellen Eingabe-/Ausgabekanals zur Erleichterung des Sendens eines nicht isochronen Inhalts (1010).
Verfahren nach Anspruch 2 oder 3, wobei isochrone virtuelle Kanäle nicht gesnoopt sind, um eine deterministische Dienstzeitsteuerung zu ermöglichen.
Verfahren nach einem der Ansprüche 2 bis 4, wobei isochrone virtuelle Kanäle mit Dienstgüteerwartungen errichtet sind, die zwischen einem Sender und einem Empfänger der Informationen errichtet sind.
Verfahren nach Anspruch 5, wobei die Dienstgüteerwartungen im Sinne von Informationen, die über eine Zeitperiode übertragen werden, quantifiziert sind.
Verfahren nach einem der Ansprüche 2 bis 6, wobei der isochrone Inhalt zeitabhängig ist.
Verfahren nach einem der vorangehenden Ansprüche, des Weiteren umfassend: Errichten zusätzlicher virtueller Kanäle innerhalb der gesamten allgemeinen Eingabe-/Ausgabebusbandbreite, um eine Kommunikation von Informationen (1004) zu ermöglichen.
Verfahren nach einem der vorangehenden Ansprüche, wobei der virtuelle Kanal einer von bis zu einer Mehrzahl von virtuellen Kanälen ist, die auf dem allgemeinen Eingabe-/Ausgabebus errichtet sind, wobei ein Zustand jedes der virtuellen Kanäle unabhängig gemanagt wird.
Verfahren nach Anspruch 9, wobei ein unabhängiges Management des virtuellen Kanalzustandes umfaßt: unabhängiges Managen einer Durchflußregelung für jeden von einem oder mehreren errichteten virtuellen Kanälen.
Verfahren nach Anspruch 9 oder 10, wobei ein unabhängiges Management des virtuellen Kanalzustandes umfaßt: unabhängiges Managen von Sortierregeln für jeden von einem oder mehreren errichteten virtuellen Kanälen.
Verfahren nach Anspruch 11, wobei die Sortierregeln definieren, ob Pakete von Informationen in Bezug auf andere Pakete innerhalb des virtuellen Kanals außerhalb der Reihenfolge verarbeitet werden können.
Verfahren nach einem der Ansprüche 9 bis 12, wobei ein unabhängiges Management des virtuellen Kanalzustandes umfaßt: unabhängiges Managen von Sortierregeln für jeden von einem oder mehreren errichteten virtuellen Kanälen.
Verfahren nach einem der Ansprüche 9 bis 13, wobei ein unabhängiges Management für jeden von einem oder mehreren virtuellen Kanälen innerhalb einer Transaktionsschicht einer Vorrichtung ausgeführt wird, die an den allgemeinen Eingabe-/Ausgabebus gekoppelt ist.
Verfahren nach einem der vorangehenden Ansprüche, wobei jeder von einem oder mehreren virtuellen Kanälen physikalische Kommunikationsressourcen des allgemeinen Eingabe-/Ausgabebusses benutzt.
Verfahren nach einem der vorangehenden Ansprüche, des Weiteren umfassend: dynamisches Zuordnen einer physikalischen Bandbreite nach Bedarf zu einer beliebigen Anzahl virtueller Kanäle, um eine Kommunikation durch den oder die virtuellen Kanäle (1004, 1008) zu ermöglichen.
Verfahren nach Anspruch 16, wobei das dynamische Zuordnen einer physikalischen Bandbreite zu jedem von einem oder mehreren virtuellen Kanälen durch eine physikalische Schicht einer Vorrichtung erfolgt, die an den allgemeinen Eingabe-/Ausgabebus gekoppelt ist.
Rechnervorrichtung, umfassend: einen allgemeinen Eingabe-/Ausgabebus; zwei oder mehr Komponenten, die jeweils kommunikativ mit dem allgemeinen Eingabe-/Ausgabebus gekoppelt sind, wobei eine oder mehrere der Komponenten eine erweiterte allgemeine Eingabe-/Ausgabeschnittstelle (106) enthalten, um einen oder mehrere virtuelle Kanäle zu errichten, die sich dynamisch physikalische Ressourcen des allgemeinen Eingabe-/Ausgabebusses teilen, um eine Kommunikation von Informationen zwischen den zwei oder mehr Komponenten zu ermöglichen, dadurch gekennzeichnet, daß die erweiterte allgemeine Eingabe-/Ausgabeschnittstelle (106) eine Transaktionsschicht (202) umfaßt, um eine Art von virtuellem Kanal aus einer Mehrzahl von Arten virtueller Kanäle zu wählen, zumindest teilweise auf der Basis des Inhalts der Informationen, die von einem externen Agenten empfangen werden.
Rechnervorrichtung nach Anspruch 18, wobei die Transaktionsschicht (202) Informationen von einem oder mehreren Verarbeitungsagenten innerhalb einer Komponente empfängt und einen oder mehrere virtuelle Kanäle errichtet, mit welchen In formationen von dem einen oder mehreren Verarbeitungsagenten zu einem oder mehreren externen Agenten kommuniziert werden.
Rechnervorrichtung nach Anspruch 19, wobei die Transaktionsschicht (202) einen Zustand jedes der errichteten virtuellen Kanäle in Bezug zueinander unabhängig managt.
Rechnervorrichtung nach einem der Ansprüche 18 bis 20, wobei die Arten virtueller Kanäle eine Art eines allgemeinen virtuellen Eingabe-/Ausgabekanals und eine Art eines isochronen virtuellen Kanals enthalten.
Rechnervorrichtung nach Anspruch 21, wobei die Art eines allgemeinen virtuellen Eingabe-/Ausgabekanals eine Art eines virtuellen Standardkanals ist.
Rechnervorrichtung nach Anspruch 21 oder 22, wobei die Art eines isochronen virtuellen Kanals dafür vorbehalten ist, eine Kommunikation isochroner Informationen zwischen dem oder den Agenten über den allgemeinen Eingabe-/Ausgabebus zu erleichtern.
Rechnervorrichtung nach Anspruch 23, wobei isochrone Informationen einen zeitabhängigen Inhalt enthalten.
Rechnervorrichtung nach einem der Ansprüche 18 bis 24, wobei die erweiterte allgemeine Eingabe-/Ausgabeschnittstelle umfaßt: eine physikalische Verbindungsschicht (206), die auf die Transaktionsschicht (202) anspricht, um einen Zugang zu den physikalischen allgemeinen Eingabe-/Ausgabebusressourcen für jeden von einem oder mehreren errichteten virtuellen Kanälen zu managen, zumindest teilweise auf der Basis des Empfangs von Informationen zur Übertragung über den oder die virtuellen Kanäle.
Rechnervorrichtung nach Anspruch 25, wobei die physikalische Verbindungsschicht (206) der Zuordnung von physikalischen allgemeinen Eingabe-/Ausgaberessourcen zu Informationen, die mit einem oder mehreren isochronen virtuellen Kanälen verknüpft sind, gegenüber Informationen, die mit einem oder mehreren allgemeinen virtuellen Eingabe-/Ausgabekanälen verknüpft sind, Priorität verleiht.
Rechnervorrichtung nach Anspruch 25 oder 26, wobei die physikalische Verbindungsschicht physikalische allgemeine Eingabe-/Ausgaberessourcen jedem der errichteten virtuellen Kanäle zumindest teilweise auf der Basis der Art des virtuellen Kanals dynamisch zuordnet.
Rechnervorrichtung nach Anspruch 27, wobei die physikalische Verbindungsschicht der Zuordnung von physikalischen allgemeinen Eingabe-/Ausgaberessourcen zu einem oder mehreren isochronen virtuellen Kanälen gegenüber dem einem oder mehreren allgemeinen virtuellen Eingabe-/Ausgabekanälen Priorität verleiht.
Rechnervorrichtung nach Anspruch 28, wobei die physikalische Verbindungsschicht eine Art eines virtuellen Kanals durch Informationen in einem Transaktionsschichtpaket identifiziert, das mit Informationen verknüpft ist, die zur Übertragung über den virtuellen Kanal empfangen werden.