DE60216299T2

DE60216299T2 - Allgemeine eingabe-/ausgabearchitektur und entsprechende verfahren zur bereitstellung virtueller kanäle

Info

Publication number: DE60216299T2
Application number: DE60216299T
Authority: DE
Inventors: Jasmin Ajanovic; Hong San Jose CA 95134 JIANG; L. David Sacramento CA 95816 HARRIMAN
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2001-08-24
Filing date: 2002-08-23
Publication date: 2007-03-29
Anticipated expiration: 2022-08-24
Also published as: US20030131179A1; CN1547706A; ATE346340T1; KR20040035738A; WO2003019392A1; EP1428130A1; KR100726304B1; US7177971B2; CN100442257C; KR20070058593A; EP1428130B1; DE60216299D1

Description

TECHNISCHES FELD
Die Ausführungsformen der Erfindung beziehen sich generell auf das Gebiet der allgemeinen Ein-/Ausgangs- (GIO-) Busarchitekturen und speziell auf eine Architektur, ein Protokoll und spezifische Verfahren für die Bereitstellung isochroner Kommunikationskanäle innerhalb einer GIO-Busarchitektur.
HINTERGRUND
IT-Geräte, wie zum Beispiel Rechnersysteme, Server, Netzwerkschalter und Router, drahtlose Kommunikationsgeräte und andere elektronische Geräte beinhalten gewöhnlich verschiedene elektronische Bausteine bzw. Elemente. Zu diesen zählen vielfach ein Prozessor, Mikrocontroller oder eine andere Steuerlogik, ein Speichersystem, Eingangs- und Ausgangsschnittstelle(n), Peripherieelemente und ähnliche Komponenten. Zur Unterstützung der Kommunikation zwischen diesen Elementen stützen sich IT-Geräte schon lange auf eine universelle Eingangs-/Ausgangs- (GIO-) Busarchitektur, sodass diese diversen Elemente des IT-Geräts miteinander kommunizieren können und auf diese Weise die unzähligen Anwendungen, die von diesen Geräten ermöglicht werden, unterstützen.
Die wohl am weitesten verbreitete dieser konventionellen GIO-Busarchitekturen ist wahrscheinlich die PCI-Busarchitektur (Peripheral-Component-Interconnect-Bus) zur Verbindung von peripheren Komponenten. Der PCI-Busstandard (Peripheral-Component-Interconnect- (PCI-) Local-Bus-Spezifikation, Rev. 2.2, vom 18 Dezember 1998) definiert eine parallele Multidrop-Busarchitektur für die arbitrierte Verbindung von Mikroprozessoren, Erweiterungskarten und Prozessor-/Speicher-Subsystemen innerhalb eines IT-Geräts.
Während die Transferrate bei einem konventionellen PCI-Bus maximal 133 MBps beträgt (d. h. 32 Bytes mit 33 MHz), unterstützt der PCI-Standard 2.2 64 Bytes pro Pin der parallelen Verbindung mit einer Taktfrequenz von bis zu 133 MHz, was eine theoretische Durchsatzrate von knapp über 1 GBps ergibt. Die Durchsatzrate von konventionellen PCI-Busarchitekturen lieferte bis vor kurzem noch genug Bandbreite, um die internen Kommunikationsanforderungen der fortschrittlichsten IT-Geräte zu erfüllen (wie Multiprozessor-/Serveranwendungen, Netzwerkgeräte usw.). Jüngste Fortschritte in der Prozessorleistung, mit Prozessorgeschwindigkeiten von mehr als 1 GHz, und die Zunahme des Breitband-Internet-Zugangs haben allerdings dazu geführt, dass sich konventionelle GIO-Architekturen, wie die PCI-Busarchitektur, in solchen IT-Geräten nun als Engpass erweisen.
Ein weiterer Schwachpunkt von konventionellen GIO-Architekturen besteht darin, dass sie normalerweise nicht gut dafür geeignet sind, isochrone (oder zeitabhängige) Datenströme zu transportieren bzw. zu verarbeiten. Ein Beispiel eines isochronen Datenstroms wären multimediale Datenströme, die einen isochronen Transportmechanismus benötigen, um sicherzustellen, dass die Daten genau so schnell konsumiert werden wie sie empfangen werden und dass der Audioteil und Videoteil synchronisiert werden.
Bei konventionellen GIO-Architekuren werden Daten asynchron verarbeitet oder in regellosen von der Bandbreite abhängigen Intervallen. Durch diese asynchrone Verarbeitung von isochronen Daten kann kann eine Abweichung zwischen Audio- und Videosignalen (Ton und Bild) entstehen und einige Anbieter von isochronen, multimedialen Inhalten haben deshalb Regeln eingeführt, nach denen bestimmte Daten gegenüber anderen Daten priorisiert werden, z. B. Priorisierung von Audiodaten gegenüber Videodaten, damit der Endbenutzer zumindest ein relativ gleichmäßiges Audiosignal empfängt (d. h. ohne Unterbrechungen) und so ein Musikstück oder eine Erzählung genießen kann oder ein HQ-Video-Streaming betrachten kann.
EP-A-1 001 574 offenbart ein System und eine Methode zur dynamischen Anpassung der Bandbreite einer CBR- (continuous bit rate, konstante Bandbreite) VP- (virtual path, virtueller Pfad) Verbindung zwischen einem Quellknoten und einem Zielknoten innerhalb eines Paket- oder Zellenvermittlungsnetzwerks.
US-A-S 463 620 offenbart eine zyklische Abfertigungsdisziplin, die eine effiziente Zuteilung der Bandbreite, Stauvermeidung und gerechte Behandlung der unterschiedlichen Verkehrsströme in einem Hochgeschwindigkeitskommunikationsnetz ermöglicht. Der Rufverkehr wird nach Signalmerkmalen klassifiziert und zu separaten Warteschaltungen geleitet. Rufe werden dann gemäß einer vordefinierten Abfertigungszyklusperiode von diesen Warteschlangen freigeschaltet.
US 5,953,338 offenbart ein System bestehend aus einem SCM-Modul und mehreren, verschalteten ATM-Schaltern, die mindestens über eine physische Schnittstelle miteinander zu einem Netzwerk zusammengeschlossen sind.
Die Hypertransport-I/O-Link-Spezifikation 1.03 offenbart ein I/O-Link-Protokoll und eine elektrische Schnittstelle für eine leistungsstarke Hochgeschwindigkeits-Punkt-zu-Punkt-Verbindung zwischen mehreren integrierten Schaltungen. Sie offenbart nicht isochrone Kommunikationskanäle.
Die Infiniband-Architektur, Release 1.0, Volume 1, allgemeine Spezifikation, offenbart einen Subsetmanager für die Verwaltung verschiedener Servicequalitätsgarantien.
ÜBERSICHTLICHE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird, ohne Einschränkungen, anhand von Beispielen, illustriert. In den beiliegenden Abbildungen beziehen sich gleich lautende Referenznummern auf gleichartige Elemente, wobei:
1 ein Blockdiagramm eines elektronischen Gerätes ist, das einen oder mehrere Aspekte einer Ausführungsform der Erfindung beinhaltet, um die Kommunikation zwischen einem oder mehreren Elementen des Gerätes zu ermöglichen;
2 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung eine grafische Darstellung eines Beispiels eines Kommunikationsstapels ist, der von einem oder mehreren Elementen des elektronischen Gerätes eingesetzt wird, um die Kommunikation zwischen solchen Elementen zu ermöglichen;
3 gemäß der Lehre der vorliegenden Erfindung eine grafische Darstellung eines Beispiels eines Transaktionsschicht-Datagramms ist;
4 gemäß einem Aspekt der Erfindung eine grafische Darstellung eines Beispiels einer Kommunikationsverbindung ist, die aus einem oder mehreren virtuellen Kanälen besteht, um die Kommunikation zwischen einem oder mehreren Elementen des elektronischen Gerätes zu ermöglichen;
5 gemäß einem Aspekt der vorliegenden Erfindung ein Flussdiagramm eines Verfahrensbeispiels für den Aufbau und die Regelung von isochronen Kommunikationsresourcen innerhalb der EGIO-Architektur ist;
6 gemäß einem Ausführungsbeispiel der Erfindung ein Blockdiagramm eines Beispiels eines Kommunikationsassistenten ist, durch den selektiv ein oder mehrere Aspekte der Erfindung implementiert werden;
7 ein Blockdiagramm von verschiedenen Paketheaderformaten ist, die in der Transaktionsschicht der vorliegenden Erfindung eingesetzt werden;
8 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ein Blockdiagranm eines Beispiels einer Speicherarchitektur ist, durch die ein oder mehrere Aspekte der vorliegenden Erfindung implementiert werden;
9 gemäß einem Aspekt der vorliegenden Erfindung ein Beispiel eines Verbindungen-Zustandsdiagramms ist; und
10 ein Blockdiagramm eines zugänglichen Mediums ist, bestehend aus einem Inhalt, durch den ein oder mehrere Aspekte der vorliegenden Erfindung implementiert werden, wenn ein elektronisches Gerät darauf zugreift.
AUSFÜHRLICHE BESCHREIBUNG
Ausführungsformen der Erfindung beziehen sich auf eine allgemeine Ein-/Ausgangs-(GIO-) Architektur, ein Protokoll und spezifische Verfahren für die Bereitstellung isochroner Kommunikationskänäle innerhalb dieser Architektur. In dieser Hinsicht werden eine innovative, verbesserte, Ein-/Ausgangs- (EGIO-) Verbindungsarchitektur, ein dazugehöriges Kommunikationsprotokoll und damit verbundene Verfahren präsentiert. Gemäß einem Ausführungsbeispiel bestehen die Elemente einer EGIO-Architektur aus einer oder mehreren Root-Complex-Einheiten (z. B. innerhalb einer Brücke implementiert), einem Switch und End-Points, die jeweils mindestens ein Subset von EGIO-Funktionen beinhalten, um EGIO-Kommunikation zwischen diesen Elementen zu unterstützen.
Die Kommunikation zwischen den EGIO-Einrichtungen dieser Elemente erfolgt mittels seriellen Kommunikationskanälen unter Einsatz eines EGIO-Kommunikationsprotokolls, welches, wie anschließend dargestellt, eine oder mehrere, innovative Funktionen unterstützt, unter anderem virtuelle Kommunikationskanäle, Tailer-gestützte Fehlerweiterleitung, Unterstützung für PCI-gestützte Legacy-Bausteine und ihre Interrupts, multiple RRTs (request response types), Flow-Control (Flussregelung) und/oder Datenintegritätskontrolleinrichtungen. Gemäß einem Aspekt der Erfindung, wird das Kommunikationsprotokoll innerhalb eines jeden dieser Elemente des IT-Gerätes durch die Einführung eines EGIO-Kommunikationsprotokollstapels unterstützt; der Stapel besteht aus einer physischen Schicht, einer Datenverbindungsschicht und einer Transaktionsschicht.
Durch Bezugnahme in dieser Spezifikation auf „eine Ausführungsform" soll ausgedrückt werden, dass eine bestimmte Funktion, Struktur oder Charakteristik, die in Verbindung mit der Ausführungsform dargelegt wird, zumindest in einer Ausführungsform der vorliegenden Erfindung enthalten ist. Der in dieser Spezifikation an mehreren Stellen verwendete Wortlaut „in einer Ausführungsform" bezieht sich daher nicht zwangsläufig auf ein und dieselbe Ausführungsform. Des Weiteren können die spezifischen Funktionen, Strukturen bzw. Charakteristiken in jeder denkbaren Weise in einer oder mehreren Ausführungsformen kombiniert werden.
Angesichts des oben Erwähnten und der anschließenden Beschreibung werden Fachleute verstehen, dass ein oder mehrere Elemente der vorliegenden Erfindung in Hardware, Software, einem propagierten Signal bzw. einer Kombination davon enthalten sein können.
TERMINOLOGIE
Bevor die einzelnen Details der innovativen EGIO-Verbindungsarchitektur, des Kommunikationsprotokolls und der damit verbundenen Verfahren präsentiert werden, ist es dienlich, zunächst die Fachausdrücke vorzustellen, die in dieser ausführlichen Beschreibung verwendet werden:

• Advertise (ankündigen): bezieht sich im Zusammenhang mit der EGIO-Flow-Control auf die Aussendung von Informationen seitens eines Empfängers in Bezug auf seine Flow-Control-Kredit-Verfügbarkeit, unter Einsatz einer Flow-Control-Aktualisierungsnachricht des EGIO-Protokolls;
• Completer (Target): ein logischer Baustein, das von einem Request adressiert wird;
• Completer-ID: eine Kombination eines oder mehrerer Bus-Identifikatoren (z. B. Nummer), Bausteinidentifikatoren und Funktionsidentifikatoren eines Completers, wodurch der Completer des Requests eindeutig ausgewiesen wird;
• Completion (Abschluss): ein Paket, das für die Termination bzw. teilweise Termination einer Sequenz verwendet wird, bezeichnet man als eine Completion. Gemäß einem Ausführungsbeispiel entspricht eine Completion einem vorangegangenen Request und beinhaltet in manchen Fällen Daten;
• Configuration space (Konfigurationsbereich): einer der vier Adressenbereiche in der EGIO-Architektur. Pakete mit einer Konfigurationsbereichadresse werden für die Konfiguration eines Bausteins eingesetzt;
• Component (Komponente): ein physischer Baustein (d. h. innerhalb einer Bauform);
• Data Link Layer (Datenverbindungsschicht): die Schicht der EGIO-Architektur, die zwischen der Transaktionsschicht (oben) und der physischen Schicht (unten) liegt;
• DLLP: das Data-Link-Layer-Paket ist ein in der Datenverbindungsschicht generiertes und konsumiertes Paket und dient der Unterstützung von Verbindungsverwaltungsfunktionen, die in der Datenverbindungsschicht ausgeführt werden;
• Downstream: bezeichnet entweder die relative Position eines Elementes oder den von der Hostbrücke ausgehenden Informationsfluss.
• End-Point: ein EGIO-Baustein mit einem Konfigurationsbereichheader vom Typ 00h.
• Flow Control (Flusskontrolle): ein Verfahren für die Kommunikation von Empfangspufferdaten von einem Empfänger zu einem Sender, um einen Überlauf am Empfangspuffer zu verhindern und Konformität von Sender mit Reihenordnungsregeln zu gestatten;
• Flow-Control-Paket (FCP): ein Transaktionsschichtpaket (TLP) für die Übertragung von Flusskontrolldaten von einer Transaktionsschicht in einer Komponente zu einer Transaktionsschicht in einer anderen Komponente;
• Funktion: ein unabhängiger Bereich eines Multifunktionsbausteins, ausgewiesen im Konfigurationsbereich durch einen eindeutigen Funktionsidentifikator (z. B. einer Funktionsnummer);
• Hierarchie: definiert die E-/A-Verbindungstopologie, die in der EGIO-Architektur implementiert ist. Eine Hierarchie ist charakterisiert durch einen Root-Complex, korrespondierend mit der Verbindung, die dem Enumerator (z. B. Host-CPU) am nächsten ist;
• Hierarchy domain (Hierarchiedomäne): eine EGIO-Hierarchie wird durch einen Root-Complex in mehrere Fragmente segmentiert, die an mehr als eine EGIO-Schnittstelle gerichtet sind. Diese Fragmente werden als Hierarchiedomäne bezeichnet;
• Host Bridge (Host-Brücke): verbindet einen Host-CPU-Complex mit einem Root-Complex; Host-Brücke kann evtl. Root-Complex bieten;
• I/O Space (E/A-Bereich): einer der vier Adressenbereiche der EGIO-Architektur;
• Lane (Strecke): ein Satz differentieller Signalpaare der physischen Verbindung, ein Paar zum Senden und ein Paar zum Empfangen. Ein xn-Link besteht aus n Lanes;
• Link (Verbindung): ein Dual-Simplex-Kommunikationspfad zwischen zwei Komponenten; Zusammenfassung von zwei Ports (einer zum Senden und einer zum Empfangen) und deren Verbindungsstrecke(n);
• Logical Bus (logische Busstruktur): die logische Verbindung zwischen mehreren Bausteinen mit der gleichen Busnummer im Konfigurationsbereich;
• Logical Device (logischer Baustein): ein Element einer EGIO-Architektur, das auf einen eindeutigen Bausteinidentifikator im Konfigurationsbereich anspricht;
• Memory Space (Speicherbereich): einer der vier Adressenbereiche der EGIO-Architektur;
• Message (Nachricht): ein Paket vom Nachrichtenbereichtyp;
• Message Space (Nachrichtenbereich): einer der vier Adressenbereiche der EGIO-Architektur. Spezielle Zyklen sind, wie laut PCI definiert, als Subset des Message-Space (Nachrichtenbereichs) enthalten und liefern demzufolge eine Schnittstelle für Legacy-Bausteine;
• Legacy-Software-Modell(e): die Software-Modelle, die für die Initialisierung, Entdeckung, Konfiguration und Nutzung eines Legacy-Bausteins notwendig sind (z. B. durch Integrierung des PCI-Software-Modells in einer EGIO-to-Legacy-Bridge wird der Austausch mit Legacy-Bausteinen ermöglicht);
• Physical Layer (physische Schicht): die Schicht der EGIO-Architektur, die eine direkte Schnitstelle zum Kommunikationsmedium zwischen den beiden Komponenten bildet;
• Port: eine Schnittstelle einer Komponente, zwischen dieser Komponente und einem EGIO-Link,
• Receiver (Empfänger): die Komponente, welche Paketdaten über einen Link empfängt, ist der Receiver (manchmal auch als Target bezeichnet);
• Request: Ein Paket, das der Einleitung einer Sequenz dient, bezeichnet man als Request. Ein Request beinhaltet Operationscode und in manchen Fällen Adressendaten, Längendaten und sonstige Daten;
• Requester (Initiator): ein logischer Baustein, der eine Sequenz in der EGIO-Domäne initiiert;
• Requester-ID: eine Kombination eines oder mehrerer Bus-Identifikatoren (z. B. Bus-Nummer), Bausteinidentifikatoren und Funktionsidentifikatoren eines Requesters, wodurch der Requester eindeutig ausgewiesen wird; In den meisten Fällen wird eine EGIO-Brücke oder ein Switch Requests von einer Schnittstelle zu einer anderen Schnittstelle weiterleiten, ohne das Requester-ID zu ändern. Liegt die Brücke statt an einem EGIO-Bus an einem anderen Bus, muss sie typischerweise das Requester-ID speichern, um dieses zu benutzen, wenn für das betreffende Request eine Completion erstellt wird;
• Root-Complex: Eine Einheit, die eine Host-Brücke und einen oder mehrere Root-Ports beinhaltet;
• Root-Port: Ein EGIO-Port an einem Root-Complex, durch den ein Teil der EGIO-Verbindungshierarchie über eine zugehörige, virtuelle PCI-PCI-Brücke abgebildet wird;
• Sequenz: ein einzelnes Request und null oder mehr Completions in Verbindung mit der Durchführung eines einzelnen logischen Transfers durch einen Requester;
• Sequenz-ID: eine Kombination von einem oder mehreren Requester-IDs und Tags, wobei Requests und Completions, die Teil einer gemeinsamen Sequenz sind, durch die Kombination eindeutig identifiziert werden;
• Split-Transaction: ein einzelner logischer Transfer, der eine initialisierende Transaktion (das Split-Request) enthält, dass vom Target (Completer oder Brücke) mit einem Split-Response (Split-Antwort) terminiert wird, gefolgt von einer oder mehreren Transaktionen (den Split-Completions), initiiert durch Completer (oder Brücke), um die Lesedaten (falls gelesen) oder eine Completion-Nachricht zurück an den Requester zu schicken;
• Symbol: eine 10-Bit-Quantität, die durch 8b/10b-Codierung erzeugt wird;
• Symbolzeit: die Zeit, die benötigt wird, um ein Symbol auf einer Lane zu platzieren.
• Tag: eine Nummer, die durch den Requester einer bestimmten Sequenz zugeordnet wird, um sie von anderen Sequenzen zu unterscheiden (ist Teil der Sequenz-ID);
• Transaction Layer Packet (Transaktionsschichtpaket): TLP ist ein in der Transaktionsebene generiertes Paket zur Vermittlung eines Requests oder einer Completion;
• Transaction Layer (Transaktionsschicht): Die äußerste (oberste) Schicht der EGIO-Architektur, auf der die Transaktionen ablaufen (z. B. Lesen, Schreiben usw.);
• Transaction Descriptor (Transaktionsbezeichner): ein Element eines Paket-Headers, das neben Adresse, Länge und Typ auch die Eigenschaften einer Transaktion angibt.

Beispiel eines elektronischen Gerätes und die EGIO-Architektur
1 zeigt ein Blockdiagramm des elektronischen Gerätes 100, mit verbesserter, Ein-/Ausgangs- (EGIO-) Verbindungsarchitektur, Protokoll und damit verbundenen Verfahren, gemäß einem Ausführungsbeispiel der Erfindung. Die Abbildung zeigt das elektronische Gerät 100 mit einer Reihe von elektronischen Elementen, u. a. einen odere mehrere Prozessor(en) 102, eine Root-Complex-Einheit (z. B. samt einer Host-Brücke) 104, Switches 108 und End-Points 110, die alle wie in der Abbildung zu sehen verbunden sind. Gemäß der Lehre der vorliegenden Erfindung verfügen zumindest Root-Complex 104, Switch(es) 108 und End-Points 110 über eine oder mehrere Instanzen einer EGIO-Kommunikationsschnittstelle 106, um einen oder mehrere Aspekte der Ausführungsformen der vorliegendeen Erfindung zu realisieren.
Wie aus der Abbildung ersichtlich, ist jedes der Elemente 102, 104, 108 und 110 kommunikativ mit mindestens einem anderen Element durch eine Kommunikationsverbindung 112 gekoppelt, die einen oder mehrere EGIO-Kommunikationskanäle über die EGIO-Schnittstelle 106 unterstützt. Gemäß einem Ausführungsbeispiel werden die Betriebsparameter der EGIO-Verbindungsarchitektur während einer Initialisierung vom elektronischen Hostgerät oder nach dynamischen Anschluss einer Peripherieeinheit am elektronischen Gerät (z. B. Hot-Plug-Device) etabliert. Wie oben präsentiert, repräsentiert das elektronische Gerät 100 ein oder mehrere einer Vielfalt von traditionellen und nicht traditionellen Computersystemen, Servern, Netzwerkschaltern, Netzwerkroutern, drahtlosen Kommunikationsteilnehmergeräten, drahtlosen Kommunikationstelephonie-Infrastrukturelementen, digitalen PA-Geräten, Set-Top-Boxen oder sonstigen elektrischen Geräten, welche die Kommunikationsressourcen nutzen würden, die durch die Integration von mindestens einem Subset der hierin beschriebenen EGIO-Verbindungsarchitektur, des Kommunikationsprotokolls oder der damit verbundenen Verfahren präsentiert werden.
Gemäß dem in 1 illustrierten Ausführungsbeispiel verfügt das elektronische Gerät 100 über einen oder mehrere Prozessoren 102. Wie hier verwendet, werden durch Prozessor(en) 102 ein oder mehrere Aspekte der funktionellen Fähigkeit des elektronischen Gerätes 100 gesteuert. In dieser Hinsicht repräsentieren Prozessor(en) 102 von einer Vielfalt von Steuerlogiken eine beliebige Steuerlogik, wie u. a. einen oder mehrere Mikroprozessoren, einen programmierbaren Logikbaustein (PLD), ein programmierbares logisches Array (PLA), eine anwendungsspezifische integrierte Schaltung (ASIC, Application Specific Integrated Circuit), einen Mikrocontroller und dergleichen.
Wie oben präsentiert, bietet die Root-Complex-Einheit 104 eine EGIO-Kommunikationsschnittstelle zwischen Prozessor 102 und/oder einem Prozessor-/Speicherkomplex und einem oder mehreren anderen Elementen 108, 110 der EGIO-Architektur des elektronischen Gerätes. Wie hier verwendet, bezieht sich die Root-Complex-Einheit 104 auf eine logische Einheit einer EGIO-Hierarchie, die einem Hostcontroller, einem Speicher-Controller-Hub (MCH) und I/O-Controller-Hub, einer beliebigen Kombination von diesen oder einer Kombination von Chipsatz-/CPU-Elementen (d. h. in einer Rechnersystemumgebung) am nächsten kommt. In dieser Hinsicht, obgleich in 1 als Einzelmodul dargestellt, ist die Root-Complex-Einheit 104 sehr wohl als eine einzelne, logische Einheit vorstellbar, die möglicherweise multiple, physische Komponenten beinhaltet.
Gemäß dem in 1 illustrierten Ausführungsbeispiel verfügt die Root-Complex-Einheit 104 über eine oder mehrere EGIO-Schnittstellen 106, um die Kommunikation mit anderen Peripheriegeräten zu ermöglichen, wie z. B. Switch(es) 108, End-Point(s) 110 und, obgleich nicht speziell dargestellt, Legacy-Brücke(n) 114 oder 116. Gemäß einem Ausführungsbeispiel repräsentiert jede EGIO-Schnittstelle 106 eine separate EGIO-Hierarchiedomäne. In dieser Hinsicht präsentiert das in 1 illustrierte Ausführungsbeispiel eine Root-Complex-Einheit 104 mit drei (3) Hierarchiedomänen. Es wird darauf hingewiesen, dass, obwohl dieses mit multiplen, separaten EGIO- Schnittstellen 106 dargestellt ist, alternative Ausführungsformen vorweggenommen werden, worin eine einzelne Schnittstelle 106 über multiple Ports verfügt, um Kommunikation mit multiplen Bausteinen zu führen.
Gemäß einem Ausführungsbeispiel ist die Root-Complex-Einheit 104 verantwortlich für die Identifizierung der Kommunikationsanforderungen (z. B. virtuelle Kanalanforderungen, isochrone Kanalanforderungen etc.) für die einzelnen Elemente der EGIO-Architektur. Gemäß einem Ausführungsbeispiel werden diese Kommunikationsanforderungen während eines Initialisierungsereignisses vom Hostgerät 100 oder einem anderen Element hiervon (z. B. bei einem Hot-Plug-Ereignis) an die Root-Complex-Einheit 104 übermittelt. In einer alternativen Ausführungsform werden diese Elemente von der Root-Complex-Einheit 104 abgefragt, um die Kommunikationsanforderungen zu identifizieren. Sobald diese Kommunikationsparameter identifiziert sind, wird die Root-Complex-Einheit 104 die Bedingungen für die EGIO-Einrichtungen für die einzelnen Elemente der Architektur etablieren, z. B. über einen Verhandlungsprozess.
In der hierin offenbarten EGIO-Architektur werden Switches End-Points innerhalb und zwischen EGIO-Hierarchien und/oder Domänen selektiv koppeln. Gemäß einem Ausführungsbeispiel hat ein EGIO-Switch 108 mindestens einen Upstream-Port (d. h. zur Root-Compex-Einheit 104 gerichtet) und mindestens einen Downstream-Port. Gemäß einem Ausführungsbeispiel betrachtet ein Switch 108 einen Port (d. h. einen Port der Schnittstelle oder die Schnittstelle 106 selbst), welcher der Host-Brücke am nächsten liegt, als den Upstream-Port, während alle anderen Ports Downstream-Ports sind. Gemäß einem Ausführungsbeispiel werden Switches 108 von Konfigurationssoftware (z. B. Legacy-Konfigurationssoftware) als eine Anordnung von multiplen PCI-to-PCI-Brücken betrachtet und sie verwenden PCI-Brücken-Funktionen zum Routen von Transaktionen.
Im Zusammenhang mit Switches 108, sind Peer-to-Peer- (P2P-) Transaktionen als Transaktionen definiert, für die sowohl der Empfangsport als auch der Sendeport Downstream-Ports sind. Gemäß einer Ausführungsform unterstützen Switches 108 das Routing für alle Arten von Transaktionsschichtpaketen (TLP, Transaction Layer Packets), mit Ausnahme von jenen mit einer gesperrten Transaktionssequenz von einem Port zu einem anderen Port. In dieser Hinsicht sollten alle Rundruf- (bzw. Broadcast-) Nachrichten typischerweise vom Empfangsport zu allen anderen Ports am Switch 108 geroutet werden. Ein Transaktionsschichtpaket, das nicht an einen Port weitergeleitet werden kann, sollte typischerweise durch den Switch 108 als ein nicht unterstütztes TLP terminiert werden. Switches 108 werden typischerweise Transaktionsschichtpakete (TLP, Transaction Layer Packets) nicht modifizieren, wenn sie diese vom Empfangsport an den Sendeport weiterleiten, es sei denn, Modifizierung ist notwendig, um eine andere Protokollbedingung für den Sendeport zu erfüllen (z. B. falls Sendeport mit einer Legacy-Brücke 114, 116 gekoppelt ist).
Es ist zu beachten, dass Switches 108 für andere Bausteine tätig sind und aus diesem Grund keine Kenntnisse über Verkehrsarten und Verkehrsmuster besitzen. Gemäß einer Ausführungsform, die nachgehend ausführlicher erörtert wird, werden bei der vorliegenden Erfindung die Aspekte für Flow-Control (Flusskontrolle) und/oder Datenintegritätskontrolle auf Link-Basis und nicht auf End-to-End-Basis implementiert. Gemäß einer solchen Ausführungsform werden Switches 108 folglich in Protokollen mitwirken, die für Flow-Control und Datenintegrität verwendet werden. Um an der Flusskontrolle zu partizipieren, unterhält Switch 108 für jeden der Ports eine separate Flusskontrolle, damit die Leistungsmerkmale von Switch 108 verbessert werden. Gleichermaßen unterstützt Switch 108 Datenintegritätsprozesse auf Link-Basis, indem jedes TLP, das in den Switch eintritt mittels eines TLP-Fehlererkennungsmechanismus geprüft wird, der im Anschluss genauer beschrieben wird. Gemäß einer Ausführungsform ist es Downstream-Ports eines Switch 108 gestattet, neue EGIO-Hierarchiedomänen zu bilden.
Unter weiterer Bezugnahme auf 1 ist ein End-Point 110 definiert als ein Baustein mit einem Konfigurationsbereichheader vom Typ 00hex (00h). End-Point-Bausteine können entweder ein Requester oder ein Completer einer semantischen EGIO-Transaktion sein, entweder für sich selbst oder für einen entfernten Nicht-EGIO-Baustein. Beispiele solcher End-Points 110 umfassen u. a. EGIO-konforme Grafikbausteine, EGIO-konforme Speichercontroller und/oder Bausteine, die eine Verbindung zwischen EGIO und einer anderen Schnittstelle implementieren, wie z. B. einem Universal Serial Bus (USB), Ethernet und dergleichen. Im Gegensatz zu einer Legacy-Brücke, 114, 116, die im Anschluss ausführlicher erörtert wird, wird ein End-Point 110, der als Schnittstelle für nicht EGIO-konforme Bausteine tätig ist, möglicherweise nicht volle Softwareunterstützung für solche nicht EGIO-konforme Bausteine liefern. Obgleich Bausteine, die einen Hostprozessor-Complex 102 mit der EGIO-Architektur verbinden, als ein Root-Complex 104 gelten, kann es sich dabei möglicherweise um den gleichen Bausteintyp handeln als wie bei anderen End-Points 110 innerhalb der EGIO-Architektur, wobei sich lediglich die Positionen der betreffenden Bausteine unterscheiden.
Gemäß der Lehre der vorliegenden Erfindung können End-Points 110 in eine oder mehrere von drei Kategorien eingeordnet werden, nämlich (1) Legacy- und EGIO-konforme End-Points, (2) Legacy-End-Points und (3) EGIO-konforme End-Points, die jeweils unterschiedliche Operationsregeln innerhalb der EGIO-Architektur haben.
Wie oben präsentiert unterscheiden sich EGIO-konforme End-Points 110 von Legacy-End-Points (z. B. 118, 120) dadurch, dass ein EGIO-End-Point 110 einen Konfigurationsbereichheader vom Typ 00h haben wird. Beide dieser End-Points (110, 118 und 120) unterstützen Konfigurationsrequests als ein Completer. Solche End-Points dürfen Konfigurationsrequests generieren und können entweder als ein Legacy-End-Point oder ein EGIO-konformer End-Point klassifiziert werden. Für diese Klassifizierung ist jedoch eventuell die Einhaltung zusätzlicher Regeln erforderlich.
Legacy-End-Points (z. B. 118, 120) dürfen I/O-Requests als ein Completer unterstützen und dürfen I/O-Requests generieren. Legacy-End-Points (118, 120) dürfen Lock-Semantiken, z. B. in Übereinstimmung mit konventioneller PCI-Operation, als Completer unterstützen, falls dies durch die Legacy-Software-Support-Anforderungen verlangt wird. Legacy-End-Points (118, 120) werden typischerweise keinen gesperrten Request generieren.
EGIO-konforme End-Points 110 werden typischerweise keine I/O-Requests als Completer unterstützen und keine I/O-Requests generieren. EGIO-End-Points 110 werden keine gesperrten Requests als Completer unterstützen und keine gesperrten Requests als Requester generieren.
EGIO-to-Legacy-Brücken 114, 116 sind spezielle End-Points 110, welche erheblichen Software-Support beinhalten, z. B. vollen Software-Support, für die Legacy-Bausteine (118, 120), die sie an die EGIO-Architektur anbinden. In dieser Hinsicht hat eine EGIO-Legacy-Brücke 114, 116 typischerweise einen Upstream-Port aber eventuell auch mehr), mit multiplen Downstream-Ports (oder eventuell auch nur mit einem). Gesperrte Requests werden in Übereinstimmung mit dem Legacy-Software-Modell (z. B. dem PCI-Software-Modell) unterstützt. Ein Upstream-Port einer EGIO-Legacy-Brücke 114, 116 sollte Flusskontrolle auf Link-Basis unterstützen und die Regeln der EGIO-Architektur für Flusskontrolle und Datenintegrität befolgen, welche im Anschluss genauer behandelt werden.
Wie hier verwendet, repräsentiert Kommunikationsverbindung 112 eines von einer Vielfalt von Kommunikationsmedien, wie u. a. Kupferleitungen, optische Leitungen, drahtlose Kommunikationskanäle, eine Infrarot-Verbindung und dergleichen.
Gemäß einem Ausführungsbeispiel ist EGIO-Link 112 ein differentielles, serielles Leitungspaar, wobei je ein Leitungspaar für das Senden und ein zweites Paar für das Empfangen verwendet wird und dadurch Vollduplexkommunikation unterstützt wird. Gemäß einer Ausführungsform liefert der Link eine skalierbare, serielle Taktrate mit einer initialen (Grund-) Frequenz von 2,5 GHz. Die Schnittstellenbreite, je Richtung, ist von x1, x2, x4, x8, x12, x16, bis x32 physischen Lanes skalierbar. Wie oben präsentiert und im Anschluss ausführlich beschrieben, könnte es sein, dass EGIO-Link 112 multiple, virtuelle Kanäle zwischen Bausteinen unterstützt und dadurch unter Einsatz von einem oder mehreren, virtuellen Kanälen, z. B. einem Kanal für Audiosignale und einem Kanal für Videosignale, unterbrechungsfreie Kommunikation von isochronem Verkehr zwischen solchen Bausteinen.
Beispiel einer EGIO-Schnittstellenarchitektur
Gemäß dem in 2 illustrierten Ausführungsbeispiel, kann es sein, dass die EGIO-Schnittstelle 106 als ein Kommunikationsprotokollstapel repräsentiert wird, bestehend aus einer Transaktionsschicht 202, einer Datenverbindungsschicht 204 und einer physischen Schicht 206. Die Abbildung zeigt, dass die physische Verbindungsschichtschnittstelle aus einem logischen Unterblock 210 und einem physischen Unterblock besteht, welche beide im Anschluss näher erläutert werden.
Transaktionsschicht 202
Gemäß der Lehre der vorliegenden Erfindung liefert die Transaktionsschicht 202 eine Schnittstelle zwischen dem EGIO-Verbindungssystem und einem Bausteinkern. In dieser Hinsicht ist die Transaktionsschicht hauptsächlich für die Zusammensetzung und Zerlegung von Paketen (d. h. Transaktionsschichtpakete bzw. TLPs) für einen oder mehrere logische Bausteine innerhalb eines Host-Gerätes (oder Agenten) verantwortlich.
Adressbereiche, Transaktionstypen, und Einsatz
Transaktionen bilden die Basis des Datentransfers zwischen einem Initiator-Agenten und einem Target-Agenten. Gemäß einem Ausführungsbeispiel sind innerhalb der innovativen EGIO-Architektur vier Adressbereiche definiert, u. a. z. B. ein Konfigurationsadressbereich, ein Speicheradressbereich, ein E/A-Adressbereich und ein Nachrichtenadressbereich, jeder mit einem eigenen Einsatzzweck (siehe z. B. 7, im Anschluss näher erörtert).
Speicherbereich- (706) Transaktionen beinhalten einen oder mehrere Lese-Requests und Schreibe-Requests für den Transfer von Daten zu/von speicherabgebildeten Punkten. Für Speicherbereichtransaktionen können zwei verschiedene Adressformate verwendet werden, z. B. ein kurzes Adressformat (z. B. 32-Bit-Adresse) oder ein langes Adressformat (z. B. 64-Bit-Adresse). Gemäß einem Ausführungsbeispiel liefert die EGIO-Architektur Unterstützung für konventionelle Lese-, Modifizier- und Schreibsequenzen, unter Einsatz von Lock-Protokoll-Semantiken (d. h. wo ein Agent eventuell den Zugriff auf modifizierten Speicherbereich sperrt). Insbesondere ist Unterstützung für Downstream-Sperren gemäß Geräteregeln gestattet (Brücken, Switch, End-Point, Legacy-Brücke). Wie oben präsentiert, werden solche Lock-Semantiken im Zuge der Unterstützung von Legacy-Bausteinen unterstützt.
E/A-Bereich (704) Transaktionen dienen dem Zugriff von abgebildeten Ein-/Ausgangsspeicherregistern innerhallb eines E/A-Bereichs (z. B. 16-Bit-E/A-Adressbereich). Bestimmte Prozessoren 102, wie Intel Architektur-Prozessoren und andere, beinhalten eine durch die Maschinenbefehle gebotene E/A-Bereichsdefinition. Demzufolge beinhalten E/A-Bereich-Transaktionen Lese- und Schreib-Requests für den Transfer von Daten von/zu E/A-abgebildeten Punkten.
Konfigurationsbereich- (702) Transaktionen dienen dem Zugriff des Konfigurationsbereichs von EGIO-Bausteinen. Transakionen zum Konfigurationsbereich beinhalten Lese- und Schreib-Requests. Insofern als konventionelle Prozessoren typischerweise keinen nativen Konfigurationsbereich beinhalten, wird dieser Bereich durch einen Mechanismus abgebildet, der softwarekompatibel ist mit konventionellen PCI-Konfigurationsbereich-Zugriffsmechanismen (z. B. mit CFC/CF8-I/O-adressbasierten PCI-Konfigurationsmechanismus #1). Als Alternative kann eventuell auch ein Speicher-Alias verwendet werden, um auf Konfigurationsbereich zuzugreifen Nachrichtenbereich- (708) Transaktionen (oder einfach Nachrichten) sind definiert, um Inband-Kommunikation zwischen EGIO-Agenten über Schnittstellen 106 zu unterstützen. Konventionelle Prozessoren bieten keine Unterstützung für nativen Nachrichtenbereich, dies wird also durch EGIO-Agenten innerhalb der EGIO-Schnittstelle 106 ermöglicht. Gemäß einem Ausführungsbeispiel werden traditionelle Seitenband-(Side Band) Signale, wie Interrupt Requests (IRQs) und Power-Management-Requests (PMRs), als Nachrichten implementiert, um den Pin-Count für die Unterstützung solcher Legacy-Signale zu reduzieren. Manche Prozessoren und der PCI-Bus beinhalten das Konzept der "speziellen Zyklen", die ebenfalls in Nachrichten innerhalb der EGIO-Schnittstelle 106 abgebildet sind. Gemäß einer Ausführungsform sind Nachrichten generell in zwei Kategorien unterteilt: Standardnachrichten und herstellerdefinierte Nachrichten.
Gemäß dem illustrierten Ausführungsbeispiel umfassen Standardnachrichten eine Universalnachrichtengruppe und eine Systemmanagementnachrichtengruppe. Universalnachrichten können Unicast-Nachrichten (mit einer Zieladresse) oder Broadcast-/Multicast-Nachrichten sein. Die Systemmanagementnachrichtengruppe kann aus einer oder mehreren Unterbrechungssteuerungs- (Interrupt Control) Nachrichten, PM-(Power Management) Nachrichten, Reihenordnungssteuerungsprimitiven und Fehlersignalisierungen bestehen; diesbezügliche Beispiele werden im Anschluss präsentiert.
Gemäß einem Ausführungsbeispiel umfassen Universalnachrichten auch Nachrichten für die Unterstützung gesperrter Transaktion. Gemäß diesem Ausführungsbeispiel wird eine UNLOCK-Nachricht präsentiert, worin Switches (z. B. 108) typischerweise die UNLOCK-Nachricht über einen beliebigen Port, der eventuell an einer gesperrten Transaktion partizipiert, weiterleiten sollten. End-Point-Bausteine (z. B. 110, 118, 120), die eine UNLOCK-Nachricht empfangen, wenn sie nicht gesperrt sind, werden die Nachricht ignorieren. Ansonsten werden gesperrte Bausteine bei Empfang einer UNLOCK-Nachricht freigeschaltet.
Gemäß einem Ausführungsbeispiel beinhaltet die Systemmanagementnachrichtengruppe spezielle Nachrichten für Reihenordnung und/oder Synchronisierung. Eine derartige Nachricht ist eine FENCE-Nachricht, die eingesetzt wird, um Transaktionen, generiert durch Empfang von Elementen von der EGIO-Archtitektur, strenge Reihenordnungsregeln aufzuerlegen. Gemäß einem Ausführungsbeispiel werden deratige FENCE-Nachrichten nur durch ein ausgewähltes Subset von Netzwerkelementen, z. B. End-Points, beantwortet. Zusätzlich zu dem oben Erwähnten werden hierin ein korrigierbarer Fehler, nicht korrigierbarer Fehler und fatale Fehler antizipiert, z. B. durch die im Anschluss erörterte Tailer-gestützte Fehlerweiterleitung.
Gemäß einem Aspekt der vorliegenden Erfindung, wie oben präsentiert, sorgt die Systemmanagenentnachrichtengruppe auch für Signalisierung von Interrupts mittels Inband-Nachrichten. Gemäß einem Ausführungsbeispiel wird das ASSERT_INTx/DEASSERT_INTx-Nachrichtenpaar präsentiert, worin die Nachricht für die Assert-Interrupt-Ausgabe über Host-Brücke 104 an den Prozessor-Complex gesendet wird. Gemäß dem illustrierten Ausführungsbeispiel spiegeln die Einsatzre geln für das ASSERT_INTx/DEASSERT_INTx-Nachrichtenpaar jene für die PCI INTx#-Signale wider, die in der oben präsentierten PCI-Spezifikation anzutreffen sind. Von jedem Baustein sollte für jede Sendung von Assert_INTx typischerweise auch eine korrespondierende Deassert_INTx-Nachricht gesendet werden. Für eine spezifische 'x' (A, B, C oder D) sollte typischerweise nur eine Sendung von Assert_INTx einer Sendung von Deassert_INTx vorausgehen. Switches sollten typischerweise Assert_INTx/Deassert_INTx-Nachrichten zum Root-Complex 104 weiterleiten, wobei die Root-Complex-Einheit typischerweise Assert_INTx/Deassert_INTx-Nachrichten verfolgen sollte, um virtuelle Interruptsignale zu generieren und diese Signale in Systeminterruptressourcen abzubilden.
Zusätzlich zu den Universal- und Systemmanagementnachrichtengruppen etabliert die EGIO-Architektur einen Standardrahmen, der es Core-Logic- (z. B. Chipsatz-) Herstellern erlaubt, ihre eigenen herstellerdefinierten Nachrichten, entsprechend den jeweiligen Betriebsanforderungen ihrer Plattformen, zu definieren. Dieser Rahmen wird anhand eines gemeinen Nachrichtenheaderformats gebildet, wo Codierungen für herstellerdefinierte Nachrichten als „reserviert" (reserved) definiert sind.
Transaction Descriptor (Transaktionsbezeichner)
Ein Transaktionsbezeichner ist ein Mechanismus für den Transport von Transaktionsdaten vom Entstehungspunkt zum Einsatzpunkt und zurück. Dieser bietet ein erweiterbares Mittel für die Bereitstellung einer generischen Verbindungslösung, welche neue Arten von Anwendungen unterstützen kann. In dieser Hinsicht unterstützt der Transaktionsbezeichner die Kennzeichnung von Transaktionen im System, Modifizierungen von Standardtransaktionsreihenfolgen und Zuordnung von Transaktionen auf virtuelle Kanäle unter Einsatz des virtuellen Kanal- (VCI-) Kennzeichnungsmechanismus. Eine grafische Darstellung eines Transaktionsbezeichners ist aus 3 ersichtlich.
3 zeigt eine grafische Darstellung eines Datagramms mit einem Beispiel eines Transaktionsbezeichners, gemäß der Lehre der vorliegenden Erfindung. Gemäß der Lehre der vorliegenden Erfindung beinhaltet der illustrierte Transaktionsbezeichner 300 ein globales Kennzeichnungsfeld 302, ein Attributfeld 306 und ein VCI-Feld (virtuelle Kanalkennzeichnung) 308. Im illustrierten Ausführungsbeispiel enthält das glo bale Kennzeichnungsfeld 302 ein lokales Transaktionskennzeichnungsfeld (Local Transaction Identifier)308 und ein Quellenkennzeichnungsfeld (Source Identifier) 310.
Global Transaction Identifier (Globale Transaktionskennzeichnung) 302
Wie hier verwendet, ist die globale Transaktionskennzeichnung für alle ausstehenden Requests eine eindeutige Kennzeichnung. Gemäß dem in 3 illustrierten Ausführungsbeispiel besteht die globale Transaktionskennzeichnung 302 aus zwei Unterfeldern: dem lokalen Transaktionskennzeichnungsfeld 308 und einem Quellenkennzeichnungsfeld 310. Gemäß einer Ausführungsform ist das lokale Transaktionskenzeichnungsfeld 308 ein 8-Bit-Feld, das von den einzelnen Requesters generiert wird und für alle ausstehenden Requests, für die eine Completion erforderlich ist, eine eindeutige Kennzeichnung darstellt. Die Quellenkennzeichnung bietet eine eindeutige Kennzeichnung des EGIO-Agenten innerhalb der EGIO-Hierarchie. Demzufolge bietet das lokale Transaktionskennzeichnungsfeld zusammen mit der Quellenkennzeichnung eine globale Kennzeichnung einer Transaktion innerhalb einer Hierarchiedomäne.
Gemäß einer Ausführungsform bietet die lokale Transaktionskennzeichnung 308 die Möglichkeit, dass Requests/Completions von einer Quelle von Requests nicht in Reihenordnung verarbeitet werden (vorbehaltlich der Reihenordnungsregeln, die im Anschluss näher erläutert werden). Zum Beispiel eine Quelle von Lese-Requests kann Lesezugriffe A1 und A2 generieren. Der Zielagent, der diese Lese-Requests bearbeitet, kann eventuell zuerst eine Transaktionskennzeichnung für die Completion von Request A2 und danach für die Completion von Request A1 zurücksenden. Im Completion-Paket-Header wird durch die lokale Transaktionskennzeichnung die Transaktion ausgewiesen, die abgeschlossen ist. Solch ein Mechanismus ist besonders bei Geräten von Bedeutung, bei denen verteilte Speichersysteme zum Einsatz kommen, da damit Lese-Requests in effizienterer Weise bearbeitet werden können. Es ist darauf zu achten, dass für die Unterstützung einer von der Reihenordnung abweichenden Completion von Lese-Requests vorausgesetzt wird, dass Bausteine, welche Lese-Requests ausgeben, dafür sorgen, dass zuvor Pufferplatz für die Completion reserviert wird. Wie oben präsentiert, müssen EGIO-Switches 108, sofern es keine End-Points sind (d. h. wenn sie lediglich Completion-Requests an entsprechende End-Points weiterleiten), keinen Pufferplatz reservieren.
Ein einzelner Lese-Request kann mehrere Completions zur Folge haben. Completions, die zu einem gemeinsamen Lese-Request gehören, können von der Reihenordnung abweichend (out-of-order) zurückgesendet werden. Dies wird unterstützt durch Hinzufügung des Adressoffsets des ursprünglichen Requests, welcher mit der teilweisen Completion korrespondiert, im Header eines Completion-Pakets (d. h. Compleiton-Header).
Gemäß einem Ausführungsbeispiel enthält das Quellenkennzeichnungsfeld 310 einen 16-Bit-Wert, der für jeden logischen EGIO-Baustein anders ist. Es wird darauf hingewiesen, dass ein einzelner EGIO-Baustein sehr wohl multiple, logische Bausteine beinhalten kann. Der Quellenkennzeichnungswert wird im Zuge der Systemkonfiguration in einer für den Standard-PCI-Bus-Enumerationsmechanismus transparenten Weise zugeteilt. EGIO-Bausteine etablieren intern und autonom einen Quellenkennzeichnungswert, zum Beispiel unter Einsatz von Busnummerdaten, die diesen Bausteinen während der anfänglichen Konfigurationszugriffe zur Verfügung stehen, in Verbindung mit intern verfügbaren Daten, wie beispielsweise Baustein-Nummern und Stream-Nummern. Gemäß einer Ausführungsform werden diese Busnummerdaten während der EGIO-Konfigurationszyklen generiert, unter Einsatz eines Mechanismus, der ähnlich ist, wie jener, der für PCI-Konfiguration verwendet wird. Gemäß einer Ausführungsform wird die Busnummer mittels eines PCI-Initialisierungsmechanismus zugeteilt und von jedem einzelnen Baustein erfasst. Im Fall von Hot-Plug- und Hot-Swap-Bausteinen müssen diese Bausteine diese Busnummer bei jedem Konfigurationszykluszugriff neu erfassen, um Transparenz für Hot-Plug-Controller- (z. B. Standard-Hot-Plug-Controller (SHPC)) Software-Stacks zu ermöglichen.
Gemäß einer Ausführungsform der EGIO-Architektur kann eine physische Komponente möglicherweise einen oder mehrere logische Bausteine (oder Agenten) beinhalten. Jeder logischer Baustein ist entsprechend konzipiert, um auf Konfigurationszyklen zu reagieren, die sich auf dessen spezifische Bausteinnummer richten, d. h. das Prinzip der Bausteinnummer ist im logischen Baustein integriert. Gemäß einer Ausführungsform sind in einer einzigen physischen Komponente bis zu sechzehn logische Bausteine gestattet. Jeder dieser logischen Bausteine kann eventuell einen oder mehrere Streaming-Engines beinhalten, d. h. bis maximal sechzehn. Demzufolge kann eine einzige physische Komponente möglicherweise bis zu 256 Streaming-Engines beinhalten.
Transaktionen, die durch andere Quellenkennzeichnungen ausgewiesen sind, gehören zu anderen logischen EGIO-Ein-/Ausgangs- (I/O) Quellen und können daher, aus der Reihenordnungsperspektive, vollkommen unabhängig voneinander bearbeitet werden. Im Fall einer Peer-to-Peer- (P2P-) Transaktion zwischen drei Parteien kann die Reihenordnung, falls erforderlich, durch eine FENCE-Reihenordnungssteuerungsprimitive erzwungen werden.
Wie hier verwendet, erfüllt das globale Transaktionskennzeichnungsfeld 302 des Transaktionsbezeichners 300 mindestens ein Subset der nachstehenden Regeln:

(a) jeder Completion-Required-Request wird mit einer globalen Transaktionskennzeichnung (GTID, Global Transaction ID) ausgewiesen;
(b) jedem ausstehenden Completion-Required-Request, der von einem Agenten initiiert wird, sollte typischerweise ein eindeutiges GTID zugewiesen werden;
(c) Nicht-Completion-Required-Requests benutzen nicht das lokale Transaktionskennzeichnungsfeld 308 des GTID und das lokale Transaktionskennzeichnungsfeld wird als reserviert betrachtet;
(d) das Target modifiziert das Request-GTID in keiner Weise, es wird dieses lediglich im Header eines Completion-Pakets für alle mit dem Request verbundenen Completions wiedergeben, wo der Initiator das GTID dafür benutzt, die Completion(s) mit dem ursprünglichen Request abzustimmen.

Attributfeld 304
Wie hier verwendet, bestimmt das Attributfeld 304 Merkmale und Beziehungen der Transaktion. In dieser Hinsicht dient das Attributfeld 304 dazu, zusätzliche Informationen zur Verfügung zu stellen, mit deren Hilfe die Standardbearbeitung von Trans aktionen modifiziert werden kann. Diese Modifizierungen können verschiedene Aspekte der Bearbeitung von Transaktionen innerhalb des Systems betreffen, zum Beispiel, Reihenordnung, Kohärenzverwaltung von Hardware (z. B. Snooping-Attribute) und Priorität. Ein Beispielformat des Attributfeldes 304 wird durch die Unterfelder 312–318 präsentiert.
Wie zu sehen, umfasst das Attributfeld 304 ein Prioritätsunterfeld 312. Das Prioritätsunterfeld kann durch einen Initiator modifiziert werden, um der Transaktion Priorität zuzuweisen. In einer Ausführungsform können zum Beispiel im Prioritätsunterfeld 312 Klasse oder Servicequalitätsmerkmale einer Transaktion oder eines Agenten enthalten sein, wodurch die Verarbeitung durch andere Systemelemente beeinflusst wird.
Das Attributfeld 314 reserved ist für späteren Gebrauch oder herstellerdefinierten Einsatz reserviert. Durch das Attributfeld reserved könnten mögliche Einsatzmodelle mit Prioritäts- oder Sicherheitsattributen implementiert werden.
Das Reihenordnungattributfeld 316 dient zur Bereitstellung optionaler Informationen zur Angabe des Reihenordnungstyps, durch den Standardreihenordnungsregeln innerhalb der gleichen Reihenordnungsebene modifiziert werden könnten (wo die Reihenordnungsebene den Verkehr einschließt, der initiiert wurde durch den Hostprozessor (102) und den I/O-Baustein mit seiner korrespondierenden Quellenkennzeichnung). Gemäß einem Ausführunungsbeispiel weist ein Reihenordnungsattribut „0" darauf hin, dass Standardreihenordnungsregeln angewandt werden, und ein Reihenordnungsattribut „1", dass die Reihenordnungsregeln entspannt sind. Schreibesequenzen können andere Schreibesequenzen in der gleichen Richtung passieren und Lese-Completions können Schreibesequenzen in der gleichen Richtung passieren. Bausteine verwenden entspannte Reihenordnungssemantiken vorwiegend für Transport von Daten und Transaktionen mit Standardreihenordnung zum Lesen/Schreiben von Statusdaten.
Das Snoop-Attributfeld 318 dient zur Bereitstellung optionaler Informationen zur Angabe des Typs der Cache-Kohärenzverwaltung, wodurch Standard-Cache-Kohärenzverwaltungsregeln innerhalb der gleichen Reihenordnungsebene modifiziert werden könnten (wo die Reihenordnungsebene den Verkehr einschließt, der initiiert wurde durch den Hostprozessor (102) und den I/O-Baustein mit seiner korrespondierenden Quellenkennzeichnung). Gemäß einem Ausführungsbeispiel entspricht ein Snoop-Attributfeld 318 mit dem Wert „0" einer Standard-Cache-Kohärenzverwaltung, wo Transaktionen überwacht (snooped) werden, um Cache-Kohärenz auf Hardwareebene zu stützen. Andererseits wird ein Wert von „1" im Snoop-Attributfeld 318 die Standard-Cache-Kohärenzverwaltung suspendieren. Transaktionen werden dann nicht überwacht. Dies bedeutet, dass entweder die zugegriffenen Daten non-cacheable sind oder die Kohärenz durch Software verwaltet wird.
VCI-Feld (virtuelle Kanalkennzeichnung) 306
Wie hier verwendet, kennzeichnet das virtuelle Kanalkennzeichnungsfeld 306 einen unabhängigen, virtuellen Kanal, mit dem die Transaktionen verbunden sind. Gemäß einer Ausführungsform ist die virtuellle Kanalkennzeichnung (VCID) ein 4-Bit-Feld, das die Kennzeichnung von bis zu sechzehn virtuellen Känälen (VCs) auf Transaktionsbasis ermöglicht. Ein Beispiel möglicher VCID-Definitionen wird in der nachfolgenden Tabelle 1 präsentiert:

Tabelle I: VCID-Codierung
Virtuelle Kanäle
Gemäß eines Aspektes der vorliegenden Erfindung unterstützt die Transaktionsschicht 202 der EGIO-Schnittstelle 106 die Einrichtung und den Einsatz von virtuellen Kanälen innerhalb der Bandbreite der EGIO-Kommunikationsverbindung 112. Der Aspekt des virtuellen Kanals (VC) der vorliegenden Erfindung, wie oben präsentiert, dient der Definition von separaten, logischen Kommunikationspfaden innerhalb einer einzelnen, physischen EGIO-Verbindung 112, basierend auf der erforderlichen Unabhängigkeit des über den Kanal vermittelten Inhalts. In dieser Hinsicht können virtuelle Kanäle durchaus basierend auf einer oder mehreren Charakteristiken eingerichtet werden, z. B. Bandbreitenanforderungen, Serviceklasse, Servicetyp (z. B. Systemservicekanal) etc.
Die Kombination von Kennzeichnungen für virtuelle Kanäle und Verkehrs- (oder Transaktions-) Klasse wird geboten, um differenzierte Dienste und Servicequalität (QoS, Quality of Service) für bestimmte Anwendungsklassen zu unterstützen. Wie hier verwendet ist eine Verkehrs- (oder Transaktions-) Klasse eine Transaktionsschichtpaket- (TLP-) Kennzeichnung, die unverändert von einem Ende zum anderen Ende über die EGIO-Struktur vermittelt wird. An jedem Servicepunkt (z. B. Switches, Root-Complex usw.) werden die Verkehrsklassekennzeichnungen vom Servicepunkt dazu benutzt, die entsprechenden Serviceregeln umzusetzen. In dieser Hinsicht werden separate VCs verwendet, um Verkehr zu differenzieren, für den unterschiedliche Regeln und Serviceprioritäten vorteilhaft sein würden. Zum Beispiel Verkehr, für den eine festgelegte Servicequalität notwendig ist, d. h. es wird garantiert, dass ein bestimmtes Datenvolumen X innerhalb einer bestimmten Zeit T übertragen wird, kann einem isochronen (bzw. zeitkoordinierten) virtuellen Kanal zugeordnet werden. Transaktionen, die anderen, virtuellen Kanälen zugeordnet werden, haben möglicherweise keine gegenseitigen Reihenordnungserfordernisse. Das heißt, virtuelle Kanäle funktionieren als separate, logische Schnittstellen mit unterschiedlichen Kontrollregeln und Attributen.
Gemäß einer Ausführungsform beinhaltet jeder EGIO-Kommunikationsport (Eingang oder Ausgang) eines EGIO-konformen Elementes eine Port-Capability-Datenstruktur (nicht speziell dargestellt). Informationen bezüglich der Leistungsmerkmale des Ports, u. a. (a) die Zahl der vom Port unterstützten virtuellen Kanäle, (b) die Verkehrsklassen der einzelnen virtuellen Kanäle, (c) ein Port-VC-Statusregister, (d) ein Port-VC-Kontrollregister und (e) das Arbitrationssystem im Hinblick auf diese virtuellen Kanäle, werden in der Port-Capability-Datenstruktur festgehalten. Gemäß einem Ausführungsbeispiel werden die Kommunikationsbetriebsparameter und, aufgrund ihrer Zugehörigkeit, die Port-Leistungsparameter zwischen gekoppelten Elementen auf Link-Basis/VC-Basis vereinbart.
Im Hinblick auf Verkehr, der durch den Hostprozessor 102 initiiert wird, wird für virtuelle Kanäle eventuell Reihenordnungskontrolle basierend auf Standardreihenordnungsregeln erforderlich sein oder der Verkehr wird ansonsten möglicherweise vollkommen regellos bearbeitet. Gemäß einem Ausführungsbeispiel sind für VCs die folgenden zwei Verkehrstypen anschaulich: Universal-I/O-Verkehr und isochronen Verkehr. Das heißt, gemäß diesem Ausführungsbeispiel, werden zwei Arten von virtuellen Kanälen beschrieben: (1) virtuelle Universal-I/O-Kanäle und (2) isochrone, virtuelle Kanäle.
Wie hier verwendet, bietet Transaktionsschicht 202 unabhängige Flusskontrolle für einen oder mehrere virtuelle Kanäle, die von der Komponente aktiv unterstützt werden. Wie hier verwendet, sollten alle EGIO-konformen Komponenten typischerweise einen allgemeinen Standard-I/O-Kanal unterstützen, z. B. virtueller Kanal 0, eine „Best-Effort"-Serviceklasse, bei der keine Reihenordnungsbeziehungen zwischen verschiedenen, virtuellen Kanälen dieses Typs bestehen. Standardmäßig wird VC 0 für Universal-I/O-Verkehr benutzt, während VC 1 oder höher (z. B. VC1–VC7) isochronen Verkehr dient. In alternativen Ausführungsformen kann jeder beliebige virtuelle Kanal für die Bearbeitung von jeder Art von Verkehr eingesetzt werden. 4 zeigt eine konzeptionelle Darstellung einer EGIO-Verbindung mit multiplen, unabhängig verwalteten Kanälen.
4 präsentiert, gemäß einem Aspekt der vorliegenden Erfindung, eine grafische Darstellung eines EGIO-Verbindungsbeispiels 112, bestehend aus multiplen, virtuellen Kanälen (VCs). Gemäß dem in 4 illustrierten Ausführungsbeispiel wird EGIO-Verbindung 112 präsentiert bestehend aus multiplen, virtuellen Kanälen (402, 404), die zwischen EGIO-Schnittstellen 106 gebildet werden. Gemäß einem Ausführungsbeispiel (bezüglich virtuellem Kanal 402) wird Verkehr von multiplen Quellen 406A...N dargestellt, der mindestens durch die Quellenkennzeichnung differenziert wird. Wie zu sehen, wurde virtueller Kanal 402 ohne Reihenordnungsanforderungen zwischen Transaktionen von unterschiedlichen Quellen (z. B. Agenten, Schnittstellen usw.) eingerichtet.
Gleichermaßen wird virtueller Kanal 404 präsentiert bestehend aus Verkehr von multiplen Quellen und multiplen Transaktionen 408A...N, wo jede der Transaktionen mindestens mit einer Quellenkennzeichnung ausgewiesen ist. Gemäß dem illustrierten Beispiel werden Transaktionen von Quelle 0 406A in streng geregelter Folge bearbeitet, sofern dies nicht über das Attributfeld im Transaktionsheader modifiziert wird, während für Transaktionen von Quelle 408N keine derartigen Reihenordnungsregeln vorliegen.
Isochrone Kanäle
Wie oben präsentiert werden isochrone Kanäle eingerichtet, um zeitabhängige Inhalte (z. B. Streaming von multimedialem Inhalt) zwischen einem Requester-Agent und Completer-Agent(en) in der EGIO-Architektur des elektronischen Gerätes 100 zu vermitteln. Gemäß einem Ausführungsbeispiel existieren innerhalb der EGIO-Architektur zwei verschiedene, isochrone Kommunikationsparadigmen, z. B. ein Endpoint-to-Root-Complex-Modell und ein Peer-to-Peer- (oder Endpoint-to-Endpoint-) Modell.
Beim Endpoint-to-Root-Complex-Modell besteht der primäre, isochrone Verkehr aus Speicher-Lese-/Schreib-Requests zum Root-Complex 104 und Lese-Completions vom Root-Complex 104. Beim Peer-to-Peer-Modell ist der isochrone Verkehr beschränkt auf Unicast-„Push-only"-Transaktionen (z. B. versandte Transaktionen wie Speicher lesebefehle oder Nachrichten). Die „Push-only"-Transaktionen können innerhalb einer einzelnen Hostdomäne oder in multiplen Hostdomänen stattfinden.
Um isochronen Datentransfer mit garantierter Bandbreite und festgelegter Servicelatenz zu unterstützen, wird zwischen dem Requester/Completer-Paar und der EGIO-Kommunikationsstruktur eine isochrone „Vereinbarung" geschaffen. Gemäß einer Ausführungsform wird die „Vereinbarung" Ressourcenreservierung und Verkehrsregelung stützen, um Überlastung und Stau im virtuellen Kanal zu vermeiden.
Aus 5 ist ein Beispiel eines Verfahrens für die Einrichtung und Verwaltung eines isochronen Kommunikationskanals innerhalb der EGIO-Architektur ersichtlich. Gemäß dem in 5 illustrierten Ausführungsbeispiel fängt das Verfahren mit Block 502 an, worin die Kommunikationsleistungsmerkmale von einem oder mehreren Elementen der EGIO-Struktur (d. h. Root-Complex 104, Switches 108, Endpoints 110, Links 112, Brücken 114, etc.) ausgewiesen sind.
Gemäß einem Ausführungsbeispiel werden die Kommunikationsleistungsmerkmale von mindestens einem Subset der EGIO-Struktur einem Bandbreitenmanager der Root-Complex-Einheit 104 präsentiert, der die Zuordnung von isochronen Kommunikationsressourcen innerhalb der EGIO-Architektur verwaltet. Die Präsentation der Kommunikationsleistungsmerkmale eines Elementes erfolgt während der Initialisierung des Elementes, z. B. beim Hochfahren des elektronisches Hostgerätes 100 oder bei Hot-Plug-Anschluss eines EGIO-konformen Bausteins am elektronischen Hostgerät. Gemäß einer Ausführungsform beinhaltet die präsentierte Information (z. B. von der Datenstruktur innerhalb des EGIO-Agenten 106) eine oder mehrere Port-Kennzeichnungen, Port-Zuordnung, virtuelle Kanalzuweisung(en), Bandbreitenleistung usw. Diese Daten werden in einer Datenstruktur festgehalten, die durch den Bandbreitenmanager zugreifbar ist, um isochrone Vereinbarungen, wie im Anschluss näher erläutert, herzustellen.
Während des normalen Betriebs des elektronischen Gerätes 100 könnte es notwendig oder wünschenswert sein, einen isochronen Kommunikationskanal zwischen zwei (oder mehreren) Agenten innerhalb des Gerätes 100 herzustellen. In einem solchen Fall empfängt der Bandbreitenmanager von Root-Complex 104 einen Request für isochrone Kommunikationsressourcen innerhalb der EGIO-Struktur von einem (oder im Auftrag eines) Requester/Completer-Paar-Block(s) 504. Wie hier verwendet, beinhaltet der Request einen Hinweis bezüglich der gewünschten Kommunikationsressourcen, z. B. Bandbreiten- und Servicelatenzbedarf.
Im Block 506, nach Empfang des Requests für isochrone Kommunikationsressourcen, analysiert der Bandbreitenmanager von Root-Complex 104 die verfügbaren Kommunikationsressourcen von mindestens einem entsprechenden Subset der EGIO-Architektur, um, im Block 508, anzugeben, ob der Request für isochrone Kommunikationsressourcen befriedigt werden kann. Gemäß einer Ausführungsform analysiert der Bandbreitenmanager von Root-Complex 104 die Daten in Verbindung mit den Ports 106, Switch(es) 108, Link(s) 112, etc, dem Kommunikationspfad zwischen dem Requester und dem Completer, um zu bestimmen, ob die Bandbreiten- und Latenzanforderungen für den isochronen Kommunikationsrequest erfüllt werden können. In anderen Ausführungsformen stellt das Requester/Completer-Paar lediglich die isochrone Verbindungsvereinbarung (oder die Vereinbarung bezüglich der Betriebsparameter) für sich selbst oder unter den intervenierenden Elementen auf Link-Basis her.
Falls der Bandbreitenmanager von Root-Complex 104 im Block 508 feststellt, dass die gewünschten Kommunikationsressourcen nicht verfügbar sind, wird die Root-Complex-Einheit 104 den Request für den isochronen Kanal abweisen und eventuell einen Hinweis liefern, dass die gewünschten Ressourcen nicht verfügbar sind (Block 510). Gemäß bestimmten Ausführungsformen wird eventuell ein Hinweis bezüglich der verfügbaren Ressourcen an das Requester/Completer-Paar geliefert, das danach beschließen kann, den Request für isochrone Kommunikationsressourcen, trotz der verneinten Kommunikationsressourcen, erneut auszusenden. In einer anderen Ausführungsform wird ein Bandbreitenmanager die Einheit, welche die Ressourcen angefordert hat, informieren, dass eine bestimmte Bandbreite (eventuell weniger als angefordert wurde) zugewiesen worden ist. In diesem Fall würde die Einheit, welche die Anforderung ausgegeben hat, den Request nicht erneut ausgeben müssen.
Gemäß einer Ausführungsform wird der Bandbreitenmanager von Root-Complex 104, für die Ermittlung, ob der Request für isochrone Kommunikationsressourcen erfüllt werden kann, und für die Herstellung der isochronen Vereinbarung im Block 512, den Bandbreitenbedarf für das Requester/Completer-Paar wie folgt berechnen: BW = (N·Y)/T [1]
Laut dieser Formel wird zugeteilte Bandbreite (BW) als eine Funktion einer gegebenen Zahl (N) von Transaktionen einer gegebenen Nutzlast (Y) innerhalb einer gegebenen Zeit (T) definiert.
Ein weiterer, wichtiger Parameter bei der isochronen Verbindungsvereinbarung ist die Latenz. Basierend auf der Vereinbarung sind isochrone Transaktionen innerhalb der spezifizierten Latenz (L) abzuwickeln. Nachdem ein Requester/Completer-Paar von Bandbreitenmanager für isochrone Kommunikation akzeptiert worden ist, werden, unter normalen Betriebsbedingungen. Bandbreite und Latenz vom Completer und jedem intervenierenden EGIO-Architektur-Element (z. B. Switches, Link(s), Root-Complex etc) dem Requester gegenüber garantiert.
Demzufolge definiert die im Block 512 ausgeführte, isochrone Vereinbarung spezifische Servicedisziplinen, die von den EGIO-Schnittstellen 106 implementiert werden, die an der isochronen Kommunikation innerhalb der EGIO-Architektur partizipieren. Die Servicedisziplinen werden EGIO-Switches 108 und Completers (z. B. Endpoints 110, Root-Complex 104 etc.) in entsprechender Weise auferlegt, dass der Service für isochrone Requests von einem bestimmten Serviceintervall (t) abhängig ist. Dieser Mechanismus wird eingesetzt, um die Kontrolle zu bieten, wenn ein isochrones Paket bearbeitet wird, das von einem Requester eingefügt (injiziert) worden ist.
Demzufolge wird isochroner Verkehr in entsprechender Weise überwacht (Block 514), sodass nur Pakete, die in Übereinstimmung mit der isochronen Vereinbarung in die EGIO-Architektur injiziert werden können, die Möglichkeit erhalten, sofort weitergeleitet und von den EGIO-Architektur-Elementen bearbeitet zu werden. Ein nicht konformer Requester, der versucht, mehr isochronen Verkehr einzuspeisen als laut Vereinbarung gestattet ist, wird von einen Flusskontrollmechanismus, der im An schluss näher erörtert wird, davon abgehalten (siehe z. B. Funktionssatz von Datenverbindungsschicht).
Gemäß einem Ausführungsbeispiel ist die isochrone Zeitperiode (T) in gleichmäßige Einheiten von virtuellen Zeitschlitzen (Zeitabschnitten) (t) unterteilt. Innerhalb eines virtuellen Zeitschlitzes ist bis zu ein isochroner Request gestattet. Gemäß einer Ausführungsform wird die Größe (oder Länge) des virtuellen Zeitschlitzes, der von einem EGIO-Element unterstützt wird, als Headerinformation, in der Datenstruktur der EGIO-Schnittstelle angegeben. In anderen Ausführungsformen wird die Größe des virtuellen Zeitschlitzes über eine Broadcast-Nachricht von der EGIO-Komponente nach Eingang eines Initialisierungsereignisses (z. B. Hochfahren, Reset etc.) gemeldet. In einer weiteren, alternativen Ausführungsform wird die Größe des virtuellen Zeitschlitzes durch eine spezielle Informationsnachricht von der EGIO-Komponente nach Eingang einer speziellen Request-Nachricht gemeldet. In einer weiteren, alternativen Ausführungsform kann die Größe des virtuellen Zeitschlitzes fixiert werden und isochrone Bandbreitenmanagersoftware kann aktive und inaktive Schlitze (während der Bandbreitenzuteilung) entsprechend zusammenfügen, sodass „breitere" Zeitschlitze geschaffen werden.
Gemäß einer Ausführungsform ist die Dauer der virtuellen Zeitschlitze (t) 100ns. Die Dauer der isochronen Zeitperiode (T) ist von der Zahl der Phasen des unterstützten, zeitabhängigen Arbitrationssystems abhängig (z. B. zeitabhängig gewichtetes Round-Robin-Verfahren (WRR) oder sequentiell gewichtet). Gemäß einer Ausführungsform ist die Zahl der Phasen durch die Zahl der isochronen, virtuellen Zeitschlitze definiert, ausgewiesen durch die Zahl der Einträge in einer innerhalb eines jeden Elements verwalteten Port-Arbitration-Tabelle. Wenn die Port-Arbitration-Tabelle 128 Einträge beinhaltet, stehen in einer isochronen Zeitperiode 128 virtuelle Zeitschlitze (t) zur Verfügung, d. h. T = 12,8 μs.
Gemäß einem Ausführungsbeispiel wird während der EGIO-Konfigurationsperiode eine maximale Nutzlast (Y) für isochrone Transaktionen festgelegt. Nach der Konfiguration wird die maximale Nutzlast innerhalb einer gegebenen EGIO-Hierarchie fixiert. Die fixierte, maximale Nutzlast wird für isochrone Bandbreitenbudgetierung verwendet, unabhängig von der eigentlichen Größe der Datennutzlast bezogen auf isochrone Transaktionen zwischen einem Requester/Completer.
Laut Erörterung bezüglich isochroner Periode (T), virtuellen Zeitschlitzen (t) und maximaler Nutzlast (Y) beträgt die maximale Zahl von virtuellen Zeitschlitzen innerhalb einer Zeitperiode: Nmax = T/t [2]
Und die maximale, spezifizierbare, isochrone Bandbreite ist: BWmax = Y/t [3]
Die Granularität, mit der isochrone Bandbreite zugeteilt werden kann, ist demzufolge definiert als: BWgranularity = Y/T [4]
Die Zuteilung isochroner Bandbreite BW_link auf eine Kommunikationsverbindung 112 ist vergleichbar mit der Zuteilung von N_link virtuellen Zeitschlitzen pro isochroner Periode (T), wo N_link: Nlink = BWlink/BWgranularity [5]
Um geregelten Zugriff auf die Verbindung aufrecht zu erhalten, wird ein Port des Switches, der als Egress-Port für isochronen Verkehr fungiert, eine Datenstruktur erstellen (z. B. die oben präsentierte Port-Arbitration-Tabelle), gefüllt mit bis zu N_max Einträgen, wo N_max die maximal zulässige Zahl von isochronen Sitzungen bezogen auf den Bandbreiten-, Granularitäts- und Latenzbedarf der Verbindung ist. Ein Eintrag in der Tabelle entspricht einem virtuellen Zeitschlitz in der isochronen Zeitperiode (T). Wenn ein Tabelleneintrag den Wert einer Port-Nummer (PN) besitzt, bedeutet dies, dass der Zeitschlitz einem Ingress-Port zugeteilt ist, der durch diese Port-Nummer ausgewiesen ist. Demzufolge werden N_link virtuelle Zeitschlitze dem Ingress-Port zugeteilt, wenn in der Port-Arbitration-Tabelle N_link Einträge den Wert PN besitzen. Der Egress-Port wird eventuell nur eine isochrone Request-Transaktion vom Ingress-Port für weitere Bearbeitung akzeptieren, wenn der Tabelleneintrag, den der isochrone Zeitzähler (der mit jeder t Zeit um eins (1) erhöht wird und umläuft, sobald T erreicht wird) des Egress-Ports erreicht, auf PN eingestellt ist. Selbst wenn im In gress-Port ausstehende, isochrone Requests bereit sind, werden diese erst in der nächsten Arbitrationsrunde bearbeitet (z. B. zeitabhängiges, gewichtetes Round-Robin-Verfahren (WRR)). In dieser Weise dient die zeitabhängige Port-Arbitration-Datenstruktur sowohl isochroner Bandbreitenzuteilung als auch Verkehrsregelung. Wie hier verwendet, setzt sich die oben erörterte Transaktionslatenz aus der durch die EGIO-Struktur und der durch den Completer gebotenen Latenz zusammen. Die isochrone Transaktionslatenz wird für jede Transaktion definiert und in Einheiten von virtuellen Zeitschlitzen t gemessen.
Für einen Requester im Endpoint-to-Root-Complex-Kommunikationsmodell ist die Leselatenz als Round-Trip-Latenz definiert, d. h. die Verzögerung ab dem Zeitpunkt, an dem der Baustein ein Speicher-Lese-Request-Paket an seine Transaktionsschicht (an der Sendeseite) abgibt, zu dem Zeitpunkt, an dem die korrespondierende Lese-Completion an der Transaktionsschicht des Bausteins (an der Empfangsseite) eintrifft. Für einen Requester in einem der Kommunikationsmodelle ist die Schreib-Latenz definiert als die Verzögerung ab dem Zeitpunkt, an dem der Requester einen Speicher-Schreib-Request an die Sendeseite seiner Transaktionsschicht abgibt, bis zu dem Zeitpunkt, an dem der Daten-Schreib-Zugriff innerhalb des Speicheruntersystems des Completers global sichtbar wird. Ein Speicher-Schreib-Zugriff erreicht globale Sichtbarkeit, wenn alle Agenten, die auf diese Speicheradresse zugreifen, die aktualisierten Daten erhalten.
Als Teil der isochronen Vereinbarung wird eine obere Grenze und eine untere Grenze der isochronen Transaktionslatenz geboten. Die Größe der isochronen Datenpuffer in einem Requester kann mittels der minimalen und maximalen isochronen Transaktionslatenzen bestimmt werden. Wie im Anschluß genauer ausgeführt ist die minimale isochrone Transaktionslatenz viel geringer als die maximale isochrone Transaktionslatenz.
Für einen Requester kann die maximale isochrone (Lese- oder Schreib-) Transaktionslatenz (L) anhand der nachstehenden Gleichung (6) berechnet werden: L = Lfabric + Lcompleter [6]
Wo L_fabric die maximale Latenz der EGIO-Struktur und L_completer die maximale Latenz des Completers ist.
Die Transaktionslatenz für eine EGIO-Verbindung 112 oder die EGIO-Struktur ist definiert als die Verzögerung zwischen dem Zeitpunkt, an dem eine Transaktion auf der Sendeseite abgegeben wird, und dem Zeitpunkt, an dem diese an der Empfangsseite zur Verfügung steht. Dies gilt sowohl für Lese- als auch Schreib-Transaktionen. In dieser Hinsicht ist L_fabric abhängig von der Topologie, von der für jede Verbindung 112 gegebenen Latenz und vom Arbitrationspunkt im Pfad vom Requester zum Completer.
Transaktionsreihenordnung
Obgleich es eventuell einfacher wäre, zu forcieren, dass alle Antworten in Reihenordnung bearbeitet werden, wird Transaktionsschicht 202 versuchen, die Leistung zu verbessern, indem die Transaktionsreihenordnung neu geregelt wird. Um eine solche Neuordnung zu ermöglichen, wird Transaktionsschicht 202 Transaktionen markieren (mit Tags versehen). Das bedeutet, gemäß einer Ausführungsform, die Transaktionsschicht 202 fügt jedem Paket einen Transaktionsbezeichner hinzu, sodass seine Sendezeit optimiert werden kann (z. B. durch Neuordnung) via Elemente in der EGIO-Architektur, ohne die relative Reihenordnung, in der das Paket ursprünglich bearbeitet wurde, aus den Augen zu verlieren. Diese Transaktionsbezeichner werden eingesetzt, um Routing von Request- und Completion-Paketen durch die EGIO-Schnittstellenhierarchie zu ermöglichen.
Das heißt, eines der innovativen Aspekte der isochronen Verbindungsarchitektur und des zugehörigen Kommunikationsprotokolls besteht darin, dass die Kommunikation von der Reihenordnung abweichen kann, sodass der Datendurchsatz verbessert wird, weil Leerlauf- und Wartezustände reduziert werden. In dieser Hinsicht setzt die Transaktionsschicht 202 einen Regelsatz ein, um die Reihenordnungsanforderungen für EGIO-Transaktionen zu definieren. Transaktionsreihenordnungsanforderungen werden definiert, um korrekten Betrieb mit Software zu gewährleisten, die konzipiert wurde, um das Produzent-Konsument-Reihenordnungsmodell zu unterstützen und gleichzeitig verbesserte Transaktionsbearbeitungsflexibilität für Anwendungen basierend auf anderen Reihenordnungsmodellen zu ermöglichen (z. B. entspannte Reihenordnung für Grafikschnittstellenanwendungen). Die Reihenordnungsanforderungen für zwei verschiedene Modelle werden unten präsentiert: ein Einzelreihenordnungsebene-Modell und ein Multireihenordnungsebene-Modell.
Einfache Transaktionsreihenordnung – Einzelreihenordnungsebene-Modell
Es wird angenommen, dass zwei Komponenten über eine EGIO-Architektur, vergleichbar mit der in 1, miteinander verbunden sind: ein Speicherkontrollhub, der eine Schnittstelle zu einem Hostprozessor und einem Speicheruntersystem bietet, und ein I/O-Kontrollhub, der eine Schnittstelle zu einem I/O-Untersystem bietet. Beide Hubs beinhalten interne Warteschlangen, über die eingehender und ausgehender Verkehr abgewickelt wird, und in diesem einfachen Modell wird der gesamte I/O-Verkehr einer einzelnen Reihenordnungsebene zugeordnet. Es ist zu beachten, das Transaktionsbezeichner/Quellenkennzeichnung eine eindeutige Kennzeichnung für jeden Agent innerhalb der EGIO-Hierarchie bieten. Es ist ferner zu beachten, dass I/O-Verkehr, welcher der Quellenkennzeichnung zugeordnet ist, verschiedene Transaktionsreihenordnungsattrribute führen kann. Reihenordnungsregeln für diese Systemkonfiguration werden im Hinblick auf I/O-initiierten Verkehr und Host-initiierten Verkehr definiert. Aus dieser Perspektive betrachtet ist festzustellen, dass I/O-Verkehr, der einer Quellenkennzeichnung zugeordnet ist, zusammen mit Hostprozessor-initiiertem Verkehr einen Verkehr bildet, der innerhalb einer einzelnen „Reihenordnungsebene" geführt wird.
Ein Beispiel solcher Transaktionsreihenordnungsregeln wird im Anschluss in Tabelle II präsentiert. Die in dieser Tabelle definierten Regeln gelten für alle Transaktionstypen im EGIO-System, einschließlich Speicher, I/O, Konfiguration und Nachrichten. In Tabelle II unten repräsentieren die Spalten die erste von zwei Transaktionen und die Reihen die zweite. Die Tabelleneinträge geben die Reihenordnungsbeziehung zwischen den beiden Transaktionen an. Die Tabelleneinträge sind wie folgt definiert:

– Ja – die zweite Transaktion sollte typischerweise die erste passieren dürfen, um Blockierung zu vermeiden. (Falls es zur Blockierung kommt, muss die zweite Transaktion die erste Transaktion passieren. Fairness sollte typischerweise verstanden werden, um Aushungerung zu vermeiden).
– J/N – keine Anforderungen. Die erste Transaktion kann wahlweise die zweite Transaktion passieren oder durch diese blockiert werden.
– Nein – die zweite Transaktion sollte typischerweise die erste Transaktion nicht passieren dürfen. Dies wird vorausgesetzt, um strenge Reihenordnung zu bewahren.

Tabelle II: Transaktionsreihenordnung und Vermeidung von Blockierung für Einzelreihenordnungsebene
Tabelle III: Erläuterung der Transaktionsreihenordnung
Erweiterte Transaktionsreihenordnung – „Multiebene"-Transaktionsreihenordnungsmodell
Im vorangegangenen Abschnitt ging es um Reihenordnungsregeln innerhalb einer einzelnen „Reihenordnungsebene". Wie oben präsentiert, bedienen sich die EGIO-Schnittstellenarchitektur und das zugehörige Kommunikationsprotokoll eines speziellen Transaktionskennzeichnungssystems, um Transaktionen zusätzliche Informationen zuzuordnen und auf diese Weise kompliziertere Reihenordnungsbeziehungen zu unterstützen. Felder im Transaktionsbezeichner (Transaction Descriptor) ermöglichen die Erstellung von multiplen „Reihenordnungsebenen", die voneinander und aus der Sicht der I/O-Verkehrsreihenordnung unabhängig sind.
Jede „Reihenordnungsebene" besteht aus Warteschlangen-/Puffer-Logik, die mit einem bestimmten I/O-Baustein korrespondiert (ausgewiesen durch eine eindeutige Quellenkennzeichnung), und Warteschlangen-/Puffer-Logik, die vom Hostprozessor initiierten Verkehr führt. Die Reihenordnung innerhalb der „Ebene" umfasst typischerweise nur diese beiden Elemente. Die im vorangegangenen Abschnitt definierten Regeln zur Unterstützung des Produzent-/Konsument-Einsatzmodells und zur Vermeidung von Blockierungen werden für jede „Reihenordnungsebene" unabhängig von anderen „Reihenordnungsebenen" gestützt. Zum Beispiel Lese-Completions für Requests, die via Ebene „Ebene" N initiiert wurden, können Lese-Completions für Requests, die via Ebene „Ebene" M initiiert wurden, umgehen. Jedoch können weder Lese-Completions für Ebene N, noch für Ebene M, aufgegebene Speicher-Schreib-Requests (WR_REQ) umgehen, die vom Host initiiert worden sind.
Obgleich durch das Ebenenzuordnungs- bzw. abbildungssystem multiple Reihenordnungsebenen existieren können, können einige oder alle Reihenordnungsebenen „vereinigt" werden, um die Implementierung zu vereinfachen (d. h. multiple, separat kontrollierte Puffer/FIFOs werden zu einer gemeinsamen Einheit zusammengeschlossen). Wenn alle Ebenen vereinigt sind, dient das Transaktionsbezeichner- /Quellenkennzeichnungssystem nur dem Routing von Transaktionen, es wird also nicht eingesetzt, um die Reihenordnung zwischen verschiedenen I/O-Verkehrsströmen zu entspannen.
Zusätzlich zu dem oben Erwähnten bietet das Transaktionsbezeichnersystem die Möglichkeit, die Standardreihenordnung innerhalb einer einzelnen Reihenordnungsebene mittels eines Reihenordnungsattributs zu modifizieren. Die Modifizierung der Reihenordnung lässt sich daher auf Transaktionsbasis kontrollieren.
Transaktionsschichtprotokoll-Paketformat (TLP, Transaction Layer Protocol Packet Format
Wie oben präsentiert bedient sich die innovative EGIO-Architektur eines paketbasierenden Protokolls, um Daten zwischen Transaktionsschichten zweier Bausteine auszutauschen, die miteinander kommunizieren. Die EGIO-Architektur unterstützt generell Speicher-, I/O-, Konfigurations- und Nachrichten-Transaktionstypen. Diese Transaktionen werden typischerweise unter Einsatz von Request- bzw. Completion-Paketen geführt, d. h. um Daten abzurufen oder den Eingang von Transaktionen zu bestätigen.
6 zeigt eine grafische Darstellung eines Beispiels eines Transaktionsschichtprotokolls (TLP, Transaction Layer Protocol) gemäß der Lehre der vorliegenden Erfindung. Gemäß dem in 6 illustrierten Ausführungsbeispiel beinhaltet der TLP-Header 600 ein Formatfeld, ein Typfeld (TYPE), ein Feld erweiterter Typ/erweiterte Länge (ET/EL, extended type/extended length) und ein Längenfeld (LENGTH). Es ist zu beachten, dass bestimmte TLPs Daten nach dem Header beinhalten, in Übereinstimmung mit dem im Header spezifizierten Formatfeld. Kein TLP sollte mehr Daten beinhalten als die durch MAX_PAYLOAD_SIZE festgelegte maximale Nutzlast. Gemäß einem Ausführungsbeispiel sind TLP-Daten 4-Byte lang, natürlich ausgerichtet, mit Inkrementen eines 4-Byte-Doppelwortes (DW)
Wie hier verwendet wird durch das Format- (FMT-) Feld das TLP-Format laut folgender Definitionen spezifiziert:

• 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 (reserved)

Das TYPE-Feld dient dazu, den Typ der im TLP verwendeten Codierungen auszuweisen. Gemäß einer Ausführungsform sind typischerweise sowohl Fmt[2:0] als auch Type[3:0] zu decodieren, um das TLP-Format zu bestimmen Gemäß einer Ausführungsform dient der Wert im Feld Type[3:0] dazu, zu bestimmen, ob das Feld erweiterter Typ/erweiterte Länge verwendet wird, um das Typfeld bzw. das Längenfeld zu erweitern. Das ET/EL-Feld wird typischerweise nur verwendet, um das Längenfeld mit Speicher-Lese-Requests (RD_REQ) zu erweitern.
Das Längenfeld liefert einen Hinweis auf die Länge der Nutzlast, in DW-Inkrementen von:

– 0000 0000 = 1DW
– 0000 0001 = 2DW
– 1111 1111 = 256DW

Die nachstehende Tabelle IV zeigt eine Übersicht von mindestens einem Subset von TLP-Transaktionstypbeispielen, ihre korrespondierenden Header-Formate sowie eine Beschreibung:
Tabelle IV: TLP-Typen Übersicht
Zusätzliche Informationen bezüglich Requests und Completions sind aus Anhang A ersichtlich.
Flow Control (Flusskontrolle
Eine mit konventionellen Flusskontrollsystemen häufig in Verbindung gebrachte Einschränkung besteht darin, dass diese lediglich auf Probleme reagieren, die möglicherweise auftreten könnten, statt in proaktiver Weise die Möglichkeit, das solche Probleme auftreten, verringern. Im konventionellen PCI-System wird zum Beispiel ein Sender solange Daten an einen Empfänger senden, bis er eine Nachricht erhält, die Sendung bis auf weiteres zu unterbrechen/suspendieren. Solchen Requests können eventuell weitere Requests folgen, um die Sendung von Paketen ab einem besitimmten Punkt wieder aufzunehmen. Fachleute werden verstehen, dass diese reaktive Methode zu unnützen Zyklen führen kann und in dieser Hinsicht ineffizient ist.
Um diese Einschränkung zu adressieren, beinhaltet die Transaktionsschicht 202 der EGIO-Schnittstelle 106 ein Flusskontrollsystem, das in proaktiver Weise die Möglichkeit reduziert, dass es zu Überlaufkonditionen kommt, und gleichzeitig dafür sorgt, dass Reihenordnungsregeln für den zwischen Initiator und Completer(s) hergestellten, virtuellen Kanal auf Link-Basis eingehalten werden. Gemäß einem Aspekt der vorliegenden Erfindung wird das Konzept des Flusskontrolle-„Kredits" präsentiert, wo sich ein Empfänger mit einem Sender für jeden der virtuellen Kanäle zwischen dem Sender und dem Empfänger (d. h. für jeden einzelnen, virtuellen Kanal) Daten über (a) die Größe des Puffers (der sich im Kredit befindet) und (b) den aktuell verfügbaren Pufferplatz teilt. Auf diese Weise erhält die Transaktionsschicht 202 des Senders einen Schätzwert bezüglich des verfügbaren Pufferspeichers (z. B. Summe der verfügbaren Kredite), der für die Sendung über einen ausgewiesenen, virtuellen Kanal zugeteilt ist, und kann proaktiv die Sendung über einen der virtuellen Kanäle drosseln, falls festgestellt wird, dass dadurch ein Überlauf am Empfangspuffer eintreten könnte.
Gemäß eines Aspektes der vorliegenden Erfindung setzt die Transaktionsschicht 202 Flusskontrolle ein, um einen Überlauf an den Empfängerpuffern zu vermeiden und die oben präsentierten Reihenordnungsregeln einzuhalten. Gemäß einer Ausführungsform wird das Flusskontrollsystem der Transaktionsschicht 202 von einem Requester dahingehend benutzt, den bei einem Agenten am gegenüberliegenden Punkt der EGIO-Verbindung 112 verfügbaren Warteschlangen-/Pufferplatz zu kontrollieren. Wie hier verwendet, bedeutet die Flusskontrolle nicht, dass ein Request seinen endgültigen Completer erreicht hat.
Gemäß der Lehre der vorliegenden Erfindung erfolgt die Flusskontrolle orthogonal zum Datenintegritätsmechanismus, der dazu dient, zuverlässigen Datenaustausch zwischen einem Sender und einem Empfänger zu realisieren. Das heißt, die Flusskontrolle kann den TLP- (Tansaction-Layer Paket-) Datenstrom von einem Sender zu einem Empfänger als perfekt einstufen, da der Datenintegritätsmechanismus dafür sorgt, dass korrumpierte bzw. defekte und verlorene TLPs während der Neusendung korrigiert werden. Wie hier verwendet sind die virtuellen Kanäle der EGIO-Verbindung 112 für die Flusskontrolle anschaulich. In dieser Hinsicht wird jeder virtuelle Kanal, der von einem Empfänger unterstützt wird, in den durch den Empfänger angekündigten Flusskontrollekrediten (FCC, flow control credits) wiedergegeben.
Gemäß der Lehre der vorliegenden Erfindung wird die Flusskontrolle von der Transaktionsschicht 202 in Kooperation mit der Datenverbindungsschicht 204 ausgeführt. Zwecks vereinfachter Illustration wird bei der Beschreibung des Flusskontrollmechanismus zwischen den folgenden Paketdatentypen unterschieden

(a) Posted Request Headers (PRH) [aufgegebene Request-Headers]
(b) Posted Request Data (PRD) [aufgegebene Request-Daten]
(c) Non-Posted Request Headers (NPRH) [nicht aufgegebene Request-Headers]
(d) Non-Posted Request Data (NPRD) [nicht aufgegebene Request-Daten]
(e) Read, Write and Message Completion Headers (CPLH) [Lese-, Schreib- und Nachricht-Completion-Headers]
(f) Read and Message Completion Data (CPLD) [Lese- und Nachricht-Completion-Daten]

Wie oben präsentiert wird für die bei der EGIO-Ausführung praktizierte, proaktive Flusskontrolle als Maßeinheit ein Flusskontrollekredit (FCC, Flow Control Credit) verwendet. Gemäß einer Ausführungsform ist ein FCC (Flow Control Credit) 16 Bytes bei Daten. Für Headers ist die Einheit für FCC ein Header. Wie oben präsentiert hat jeder virtuelle Kanal eine eigene Flusskontrolle. Für jeden virtuellen Kanal werden im Hinblick auf alle oben genannten Paketdatentypen ((a)–(f), wie oben ausgewiesen) separate Kreditangaben verwaltet und kontrolliert. Gemäß dem illustrierten Ausführungsbeispiel konsumiert die Sendung von Paketen Flusskontrollekredite nach folgender Aufstellung:

– Speicher-/I/O-/Konfiguration-Lese-Request: 1 NPRH Einheit
– Speicher-Schreib-Request: 1 PRH + nPRD Einheiten (wo n für die Größe der Datennutzlast steht, d. h. die Länge der Daten dividiert durch die Größe der Flusskontrolleinheit (z. B. 16 Bytes)
– I/O-/Konfiguration-Schreib-Request: 1NPRH + 1NPRD
– Nachricht-Requests: Je nach Nachricht mindestens 1PRH und/oder 1NPRH Einheit(en)
– Completions mit Daten: 1 CPLH + nCPLD Einheiten (wo n für die Datengröße steht, dividiert durch die Größe der Flusskontrolleinheit, z. B. 16 Bytes)
– Completions ohne Daten: 1 CPLH

Für jeden kontrollierten Datentyp gibt es drei konzeptionelle Register, jedes 8 Bits groß, um die konsumierten Kredite (im Sender), Kreditgrenze (im Sender) und zugeteilten Kredite (im Empfänger) zu kontrollieren. Das Register für konsumierte Kredite enthält die Gesamtsumme der seit Initialisierung konsumierten Flusskontrolleinheiten Modula 256. Nach Initialisierung wird das Register der konsumierten Kredite auf null (0) gestellt. Es beginnt zu zählen, wenn die Transaktionsschicht mit der Sendung von Daten zur Datenverbindungsschicht beginnt. Der Inkrementsprung ist von der Zahl der durch die Datensendung konsumierten Kredite abhängig. Gemäß einer Ausführungsform wird der Zähler, sobald der Höchstwert (z. B. alles 1) erreicht bzw. überschritten wird, auf Null gehen. Gemäß einer Ausführungsform wird für den Zähler vorzeichenlose 8-Bit-Modul-Arithmetik benutzt.
Das Register für die Kreditgrenze beinhaltet die Grenze für die maximale Zahl von Flusskontrolleinheiten, die konsumiert werden können. Nach Initialisierung der Schnittstelle wird das Register auf null gestellt und nach Eingang einer Nachricht auf den in einer Flusskontrolle-Aktualisierungsnachricht (wie oben präsentiert) ausgewiesenen Wert gestellt.
Das Register für die zugeteilten Kredite verwaltet die Gesamtsumme der seit Initialisierung dem Sender gewährten Kredite. Der Zählerwert wird anfangs gemäß Puffergröße und Zuteilungsregeln des Empfängers eingestellt. Dieser Wert kann eventuell in Flusskontrolle-Aktualisierungsnachrichten eingeschlossen sein. Der Wert wird erhöht, wenn durch die Transaktionsschicht des Empfängers verarbeitete Daten aus dessen Empfangspuffer beseitigt werden. Die Größe des Inkrementsprunges hängt mit der Größe des frei gemachten Speicherplatzes ab. Gemäß einer Ausführungsform sollten Empfänger typischerweise die zugeteilten Kredite anfangs auf Werte gleich der oder größer als die folgenden Werte einstellen:

– PRH: 1 Flusskontrolleeinheit (FCU, flow control unit);
– PRD: FCU gleich der größtmöglichen Einstellung für die maximale Nutzlast des Bausteins;
– NPRH: 1FCU
– NPRD: FCU gleich der größtmöglichen Einstellung für die maximale Nutzlast des Bausteins;
– Switch-Bausteine – CPLH: 1FCU;
– Switch-Bausteine – CPLD; FCU gleich der größtmöglichen Einstellung für die maximale Nutzlast des Bausteins, oder größten Lese-Request, den der Baustein je generieren wird, je nachdem, welcher Wert am kleinsten ist;
– Root- und Endpoint-Bausteine – CPLH or CPLD: 255 FCUs (alle 1), ein vom Sender als unendlich angesehener Wert, der deshalb niemals drosseln wird.

Gemäß dieser Ausführungsform wird ein Empfänger typischerweise das Register für zugeteilte Kredite für keinen Nachrichtentyp auf mehr als 127FCUs einstellen.
Gemäß einer anderen Ausführungsform kann ein Sender, anstatt das Register für zugeteilte Kredite mittels dem oben genannten Zählersystem zu verwalten, die zugeteilten Kredite mittels der folgenden Gleichung errechnen: C_A = (Kredit-Einheit-Zahl der zuletzt empfangenen Sendung) + verfügbarer Empfangspufferplatz) [7]
Wie oben präsentiert implementiert ein Sender die konzeptionellen Register (konsumierter Kredit, Kreditgrenze) für jeden der virtuellen Kanäle, die der Sender nutzen wird. In gleicher Weise implementieren Empfänger die konzeptionellen Register (zugeteilter Kredit) für jeden der virtuellen Kanäle, die vom Empfänger unterstützt werden.
Um in proaktiver Weise die Sendung von Daten zu unterbinden, falls andernfalls ein Überlauf am Empfangspuffer eintreten würde, darf ein Sender einen Datentyp senden, falls die Summe der konsumierten Kredite plus die Zahl der Krediteinheiten bezogen auf die zu sendenden Daten geringer ist bzw. kleiner ist als der Wert der Kreditgrenze. Wenn ein Sender Flusskontrolldaten für Completions (CPLs) empfängt, die auf nicht endlose Kredite (d. h. <255 FCUs) verweisen, wird der Sender die Completions in Übereinstimmung mit dem verfügbaren Kredit drosseln. Bei der Abrechnung von Kreditverbrauch und Rückgabe werden Daten von unterschiedlichen Transaktionen nicht in einem Kredit vermischt. In gleicher Weise werden bei der Abrechnung von Kreditverbrauch und Rückgabe Header und Daten von einer Transaktion nie in einem Kredit vermischt. Das heißt, wenn die Sendung eines Paketes aufgrund mangelnder Flusskontrollkredite blockiert wird, werden Sender anhand der Reihenordnungsregeln (siehe oben) bestimmen, welche Pakettypen das „suspendierte" Paket umgehen sollten.
Die Rückgabe von Flusskontrollkrediten für eine Transaktion wird nicht dahingehend interpretiert, dass die Transaktion abgeschlossen ist oder im System sichtbar geworden ist. MSIs (Message-Signaled-Interrupts), welche die Speicher-Schreib-Request-Semantik benutzen, werden wie andere Speicher-Schreib-Zugriffe behandelt. Falls eine anschließende FC-Update-Nachricht (Flusskontrolle-Aktualisierungsnachricht) (von Empfänger) auf einen niedrigeren Kreditgrenzenwert (credit_limit) hinweist als anfangs angedeutet wurde, muss der Sender die neue, niedrigere Grenze respektieren und wird eventuell einen Nachrichtenfehler melden.
Gemäß des hier beschriebenen Flusskontrollmechanismus wird ein Empfänger, falls er mehr Daten erhält als ihm Kredite zugeteilt sind (d. h. die zugeteilten Kredite überschritten werden), dem verstossenden Sender einen Empfängerüberlauffehler melden und für das Paket, das den Überlauf bewirkt, einen Datenverbindungsschicht-Wiederholungsrequest initiieren.
Flusskontrollpakete FCP, Flow-Control-Pakete)
Gemäß einer Ausführungsform werden die Flusskontrolldaten, die für die Verwaltung der Register, siehe oben, notwendig sind, unter Einsatz von Flusskontrollpaketen (FCPs) zwischen den Bausteinen vermittelt. 7 zeigt eine grafische Darstellung eines Beispiels eines Flusskontrollpaketes. Gemäß einer Ausführungsform besitzen Flusskontrollpakete 700 ein Zwei-DW-Header-Format und vermitteln Daten für einen spezifischen virtuellen Kanal (VC) über den Status der sechs Kredit-Register, die von der Flusskontroll-Logik der Empfangstransaktionsschicht für jeden VC verwaltet werden.
Gemäß einer Ausführungsform und der Lehre der vorliegenden Erfindung gibt es zwei Arten von FCPs: Initial-FCP und Update-FCP, wie in 7 illustriert. Wie oben präsentiert kommt ein Initial-FCP 702 bei der Initialisierung der Transaktionsschicht zum Einsatz. Nach Initialisierung der Transaktionsschicht kommen Update-FCPs 704 zum Einsatz, um die Daten in den Registern zu aktualisieren.
Der Empfang eines Initial-FCP 702 während normalen Betriebs wird eine Rückstellung des lokalen Flusskontrollmechanismus und die Sendung eines Initial-FCP 702 bewirken. Der Inhalt eines Initial-FCP 702 umfasst mindestens ein Subset von angekündigten Krediten für alle PRH, PRD, NPRH, NPRD, CHP, CPD, und Kanal-ID (z. B. der virtuelle Kanal, auf den sich die Flusskontroll- (FC-) Daten beziehen).
Das Format eines Update-FCP 704 ist ähnlich wie das eines Initial-FCP 702. Es ist zu beachten, dass der FC-Header zwar nicht das bei anderen Transaktionsschichtpaket-Headerformaten übliche Längenfeld beinhaltet, die Größe des Paketes aber aufgrund der mit diesem Paket verbundenen, zusätzlichen DW-Daten dennoch eindeutig ist.
Fehlerweiterleitung
Im Gegensatz zu konventionellen Fehlerweiterleitungsmechanismen stützt sich die EGIO-Architektur auf Tailer-Daten, die Datagrammen hinzugefügt werden, welche sich aus einem der unten erörterten Gründe als defekt herausstellen. Gemäß einem Ausführungsbeispiel bedient sich die Transaktionsschicht 202 einer von mehreren, bekannten Fehlererkennungsverfahren, wie z. B. Fehlerkontrolle durch zyklische Redundanzprüfung (CRC, cyclical redundancy check) und dergleichen.
Gemäß einer Ausführungsform, verwendet die EGIO-Architektur einen „Tailer", um Fehlerweiterleitungsfunktionen zu ermöglichen. Dieser wird dem TLP hinzugefügt, von dem bekannt ist, dass es defekte Daten führt. Beispiele, bei denen eventuell tailergestützte Fehlerweiterleitung zum Einsatz kommen könnte:

– Beispiel 1: Ein Lese-Request vom Hauptspeicher stösst auf nicht korrigierbaren ECC-Fehler
– Beispiel 2: Paritätsfehler an einem PCI-Schreibzugriff auf Hauptspeicher
– Beispiel 3: Datenintegritätsfehler an internen Datenpuffer oder Cache

Gemäß einem Ausführungsbeispiel kommt Fehlerweiterleitung nur für Lese-Completion-Daten oder Schreib-Daten zum Einsatz. Dies bedeutet, Fehlerweiterleitung kommt typischerweise nicht zum Einsatz, wenn der Fehler im Verwaltungsteil des Datagramms auftritt, d. h. ein Fehler im Header (z. B. Request-Phase, Adressse/Befehl etc.). Wie hier verwendet, können Requests/Completions mit Header-Fehlern generell nicht weitergeleitet werden, da keine echte Destination ausgemacht werden kann und aus diesem Grund bei einer Fehlerweiterleitung direkte oder Nebeneffekte auftreten könnten, wie zum Beispiel Datendefekte (Korrumpierung), Systemausfälle usw. Gemäß einer Ausführungsform wird Fehlerweiterleitung für die Übertragung von Fehlern im System, Systemdiagnose, eingesetzt. Bei Fehlerweiterleitung wird keine Datenverbindungsschicht-Wiederholung eingesetzt, TLPs mit dem Tailer werden daher nur wiederholt, wenn an der EGIO-Verbindung 112 Übertragungsfehler vorliegen, welche durch den TLP-Fehlererkennungsmechanismus erkannt werden (z. B. zyklische Redundanzprüfung (CRC) etc.). Dies bedeutet, dass am Ende eventuell der Tailer den Initiator des Requests dazu veranlassen wird, den Request zu wiederho len (auf der Transaktionsschichtebene oder darüber) oder eine andere Maßnahme zu ergreifen.
Wie hier verwendet sind alle EGIO-Empfänger (d. h. innerhalb der EGIO-Schnittstelle 106 befindliche Empfänger) in der Lage, TLPs, die mit einem Tailer enden, zu bearbeiten. Unterstützung für die Hinzufügung eines Tailers in einem Sender ist optional (und somit kompatibel mit Legacy-Bausteinen). Switches 108 routen einen Tailer mit dem Rest eines TLPs durch das System. Host-Brücken 104 mit Peer-Routing-Unterstützung werden einen Tailer typischerweise mit dem Rest eines TLPs durch das System routen, werden aber nicht dazu veranlasst. Fehlerweiterleitung betrifft typischerweise Daten innerhalb eines Schreib-Requests (aufgegebene oder nicht aufgegebene) oder einer Lese-Completion. TLPs, von denen der Sender weiß, dass sie schlechte (defekte) Daten beinhalten, sollten mit einem Tailer enden.
Gemäß einem Ausführungsbeispiel besteht ein Tailer aus zwei DW, worin Bytes [7:5] alle null sind (d. h. 000), und Bits [4:1] alle eins (d. h. 1111), mit allen übrigen Bits reserviert. Ein EGIO-Empfänger wird alle Daten in einem TLP, das mit dem Tailer endet, als defekt einstufen. Kommt es zur Fehlerweiterleitung, wird der Empfänger veranlassen, dass alle Daten vom ausgewiesenen TLP als schlecht („vergiftet") markiert werden. Innerhälb der Transaktionsschicht wird ein Parser typischerweise das gesamte TLP bis zum Ende parsen und sofort die folgenden Daten prüfen, um zu sehen, ob die Daten vollständig sind oder nicht.
Data Link Layer (Datenverbindungsschicht) 204
Wie oben präsentiert fungiert die Datenverbindungsschicht 204 – 2 – als Zwischenstufe zwischen der Transaktionsschicht (Transaction Layer) 202 und der physischen Schicht (Physical Layer) 206. Die primäre Aufgabe der Datenverbindungsschicht 204 besteht darin, einen zuverlässigen Mechanismus für den Austausch von Transaktionsschichtpaketen (TLPs, Transaction-Layer-Pakete) zwischen zwei Komponenten über eine EGIO-Verbindung 112 zu bieten. Die Sendeseite der Datenverbindungsschicht 204 akzeptiert von der Transaktionsschicht 202 zusammengestellte TLPs, appliziert einen Paket-Sequenz-Bezeichner/Packet-Sequence-Identifier (z. B. eine Kennnummer), errechnet und appliziert einen Fehlererkennungscode (z. B. CRC-Code) und übergibt die modifizierten TLPs an die physische Schicht 206, um sie über einen oder mehrere virtuelle Kanäle zu senden, die innerhalb der Bandbreite der EGIO-Verbindung 112 hergestellt wurden.
Die Datenverbindungsschicht 204 an der Empfangsseite hat die Aufgabe, die Integrität der empfangenen TLPs zu prüfen (z. B. mittels CRC-Verfahren etc.) und jene TLPs, für die die Integritätsprüfung positiv ausgefallen ist, an die Transaktionsschicht 204 zu übergeben, wo sie zerlegt werden, bevor sie zum Bausteinkern weitergeleitet werden. Die von der Datenverbindungsschicht 204 gebotenen Dienste umfassen generell Datenaustausch, Fehlererkennung und Wiederholung, Initialisierung und Power-Management-Dienste sowie Datenverbindungsschicht-Kommunikationsdienste. Die verschiedenen unter den einzelnen o. g. Kategorien gebotenen Dienste werden im Anschluss detailliert.
Datenaustauschdienste (Data Exchange Services)

– Akezptierung von TLPs für Sendung von Sendetransaktionsschicht (Transmit Transaction Layer) i. Akzeptierung von TLPs, die über den Link von der physischen Schicht empfangen werden, und deren Weitervermittlung zur Empfangstransaktionsschicht

– TLP-Sequenznummer- und CRC-Generation
– Speicherung des gesendeten TLP für Datenverbindungsschichtwiederholung (Data Link Layer Retry)
– Datenintegritätsprüfung
– Bestätigung- und Wiederholung-DLLPs
– Fehleranzeige im Zusammenhang mit Fehlermeldung und Protokollierung i. Link-Ack-Timeout-Timer

– Kontrolle Verbindungsstatus und Weitervermittlung von Status aktiv/rückgestellt/unterbrochen an Transaktions-Schicht

– Für Link-Managementfunktionen, einschließlich Fehlererkennung und Wiederholung
– Vermittlung zwischen Datenverbindungsschichten von zwei direkt verbundenen Komponenten
– Nicht den Transaktionsschichten gegenüber exponiert

Wie bei der EGIO-Schnittstelle 106 verwendet, erscheint die Datenverbindungsschicht 204 gegenüber der Transaktionsschicht 202 als ein Datenleiter mit variierender Latenz. Alle zur Sendedatenverbindungsschicht geleiteten Datenwerden zu einem späteren Zeitpunkt am Ausgang der Empfangsdatenverbindungsschicht erscheinen. Die Latenz wird von einer Reihe von Faktoren abhängen, wie Leitungs-Latenzen, Breite und Betriebsfrequenz von Link 112, Übertragung von Kommunikationssignalen über das Medium und Verzögerungen verursacht durch Datenverbindungsschichtwiederholung (Data Link Layer Retry). Aufgrund dieser Verzögerungen kann die Sendedatenverbindungsschicht Druck auf die Sendetransaktionsschicht 202 ausüben und die Empfangsdatenverbindungsschicht meldet der Empfangstransaktionsschicht 202 die Präsenz bzw. Abwesenheit von gültigen Daten.
Gemäß einer Ausführungsform kontrolliert die Datenverbindungsschicht (DLL) 204 den Status der EGIO-Verbindung 112. In dieser Hinsicht meldet die DLL 204 Link-Status mit der Transaktionsschicht 202 und der physischen Schicht 206 und und führt über die physische Schicht 206 Link-Management aus. Gemäß einer Ausführungsform beinhaltet die Datenverbindungsschicht (DLL) eine Link-Kontrolle- und Management-Zustandsmaschine, um derartige Managementfunktionen auszuführen. Ein Beispiel dafür wird in 8 grafisch dargestellt. Gemäß dem in 8 dargestellten Ausführungsbeispiel sind die Zustände der Link-Kontrolle- und Management-Zustandsmaschine wie folgt definiert:
Beispiele für DLL-Lirilc-Zustände

– LinkDown (LD) – physische Schicht meldet, dass Link nicht funktioniert bzw. Port nicht angeschlossen ist
– LinkInit (LI) – physische Schicht meldet, dass Link funktioniert und initialisiert wird
– LinkActive (LA) – Normaler Betriebsmodus
– LinkActDefer (LAD) – Normaler Betriebsmodus unterbrochen, physische Schicht versucht, Betrieb wieder aufzunehmen

– LinkDown (LD) Initialer Zustand nach Komponentenrückstellung Nach Beginn von LD:
– Alle Datenverbindungsschicht- (DLL-) Daten auf Standardwerte rückstellen

– Keine TLP-Daten mit Transaktions- oder physischen Schichten austauschen
– Keine DLLP-Daten mit physischer Schicht austauschen
– Keine DLLPs generieren oder akzeptieren

– Bei Hinweis von Transaktionsschicht, dass der Link von SW nicht deaktiviert wurde

– Keine TLP-Daten mit Transaktions- oder physischen Schichten austauschen
– Keine DLLP-Daten mit physischer Schicht austauschen
– Keine DLLPs generieren oder akzeptieren Verlassen zu LA, falls:
– Bei Hinweis von physischer Schicht, dass Link-Training gelungen ist

Bei Hinweis von physischer Schicht, dass Link-Training nicht gelungen ist LinkActive (LA)

– TLP-Daten mit Transaktions- und physischer Schicht austauschen
– DLLP-Daten mit physischer Schicht austauschen
– DLLPs generieren und akzeptieren

– Bei Hinweis vom Datenverbindungsschichtwiederholung-Managementmechanismus (Data Link Layer Retry Management Mechanism), dass Link-Retraining notwendig ist, ODER, falls physische Schicht meldet, dass Retraining im Gang ist.

– Bei Hinweis von physischer Schicht, dass Retraining gelungen ist

– Bei Hinweis von physischer Schicht, dass Retraining nicht gelungen ist

Datenintegritätskontrolle (Data Integrity Management)
We hier verwendet werden Datenverbindungsschichtpakete (DLLPs, Data-Link-Layer-Pakete) eingesetzt, um den EGIO-Verbindung-Datenintegritätsmechanismus zu unterstützen. In dieser Hinsicht bietet die EGIO-Architektur gemäß einer Ausführungsform die folgenden DLLPs zwecks Unterstützung der Datenintegritätskontrolle für die Verbindung:

– Ack DLLP: TLP-Sequenznummer-Bestätigung – dient der Anzeige des erfolgreichen Empfangs von einigen TLPs
– Nak DLLP: Negative TLP-Sequenznummer-Bestätigung – dient der Anzeige einer Datenverbindungsschichtwiederholung (DLL-Retry)
– Ack Timeout DLLP: Anzeige von kürzlich gesendeter Sequenznummerdient der Erkennung von TLP-Verlusten

Wie oben präsentiert bietet die Transaktionsschicht 202 TLP-Grenzdaten für die Datenverbindungsschicht 204, sodass die DLL 204 am TLP eine Sequenznummer appli zieren und eine zylindrische Redundanzprüfung (CRC) zwecks Fehlererkennung ausführen kann. Gemäß einer Ausführungsform validiert die Empfangsdatenverbindungsschicht (Receive Data Link Layer) die empfangenen TLPs durch Prüfung von Sequenznummer, CRC-Code und etwaigen Fehleranzeigen seitens der physischen Empfangsschicht (Receive Physical Layer). Im Fall eines Fehlers in einem TLP wird zwecks Wiederherstellung Datenverbindungsschichtwiederholung (DLL Retry) eingesetzt.
CRC, Sequenznummer und Wiederholungsmanagement (Sender)
Der Mechanismus für die Bestimmung der TLP-CRC und Sequenznummer und für die Unterstützung der Datenverbindungsschichtwiederholung (DLL Retry) wird im Anschluss im Zusammenhang mit konzeptionellen „Counters" und „Flags" beschrieben:
CRC- und Sequenznummer-Regeln (Sender)

– Es werden die folgenden 8-Bit-Counters eingesetzt: • TRANS_SEQ – Speichert die Sequenznummer, die an TLPs appliziert wird, welche für die Sendung vorbereitet werden – Im LinkDown-Zustand alle auf „0" gestellt – Um 1 erhöht nach jedem gesendeten TLP – Wenn alle „1" wird der nächste Inkrementsprung alle auf „0" stellen • ACKD_SEQ – Speichert die Sequenznummer, die im allerjüngsten empfangenen Lirilc-to-Link-Acknowledgement-DLLP bestätigt wurde: – Im LinkDown-Zustand alle auf„1" gestellt
– Jedes TLP wird einer 8-Bit-Sequenznummer zugeordnet • Der Counter TRANS_SEQ speichert diese Nummer • Wenn TRANS_SEQ gleich (ACKD_SEQ-1) Modulo 256, sollte der Sender typischerweise kein weiteres TLP senden, bis ein Ack DLLP ACKD_SEQ aktualisiert hat, sodass der Zustand (TRANS_SEQ – ACKD_SEQ – 1) Modulo 256 nicht mehr wahr ist.
– TRANS_SEQ wird am TLP appliziert durch: • durch Hinzufügen des einzelnen Byte-Wertes am Anfang des TLPs • durch Hinzufügen eines einzelnen Reserved-Bytes am Anfang des TLPs
– Ein 32b CRC wird für das TLP errechnet und mittels des folgenden Algorithmus am Ende des TLPs hinzugefügt • Es wird das Polynom 0x04C11DB7 verwendet – identische vom Ethernet benutzte CRC-32 • Das Kalkulationsverfahren ist wie folgt: 1) Der initiale Wert für die CRC-32 Kalkulation ist das DW gebildet durch Hinzufügen von 24 „0s" am Anfang der Sequenznummer 2) Die CRC-Kalkulation wird fortgesetzt unter Verwendung der einzelnen DWs des TLPs von der Transaktionsschicht in Reihe ab dem DW mit Byte 0 im Header bis zum letzten DW im TLP 3) Die Bit-Sequenz der Kalkulation wird ergänzt und das Resultat ist das TLP CRC 4) Das CRC DW wird am Ende des TLPs hinzugefügt
– Kopien der gesendeten TLPs sind typischerweise im Data-Link-Layer-Retry-Puffer zu speichern
– Wenn ein ACK DLLP vom anderen Baustein empfangen wird: • wird ACKD_SEQ geladen mit dem im DLLP spezifizierten Wert • Im Retry-Puffer werden TLPs mit Sequenznummern im folgenden Bereich gelöscht: – vom vorangegangenen Wert für ACKD_SEQ + 1 – bis zum neuen Wert für ACKD_SEQ
– Wenn von der anderen Komponente am Link ein Nak DLLP empfangen wird: • Falls gerade ein TLP an die physische Schicht übermittelt wird, wird die Übermittlung fortgesetzt, bis die Übermittlung dieses TLPs abgeschlossen ist • Weitere TLPs werden von der Transaktionsschicht nicht akzeptiert, solange die folgenden Schritte nicht beendet sind • Im Retry-Puffer werden TLPs mit Sequenznummern im folgenden Bereich gelöscht: – Der vorangegangene Wert für ACKD_SEQ + 1 – Der im Nak Sequenznummerfeld für das Nak DLLP spezifizierte Wert • Alle übrigen TLPs im Retry-Puffer werden wieder der physischen Schicht für erneute Sendung in ursprünglicher Reihenfolge präsentiert – Hinweis: Hierzu gehören alle TLPs mit Sequenznummern im Bereich: • Der im Nak Sequenznummerfeld für das Nak DLLP + 1 spezifizierte Wert • Der Wert für TRANS_SEQ – 1 – Falls im Retry-Puffer keine TLPs übrig waren, erfolgte das NAK DLLP irrtümlich. • Das fehlerhafte Nak DLLP sollte typischerweise in Übereinstimmung mit Fehlerverfolgung und Protokollierung (Error Tracking and Logging) gemeldet werden • Seitens des Senders sind keine weiteren Maßnahmen notwendig

CRC und Sequenznummer (Empfänger)
Gleichermaßen wird der Mechanismus für die Prüfung der TLP-CRC und Sequenznummer und für die Unterstützung der Datenverbindungsschichtwiederholung (DLL Retry) im Anschluss im Zusammenhang mit konzeptionellen „Counters" und „Flags" beschrieben:

– Es werden die folgenden 8-Bit-Counters eingesetzt: • NEXT_RCV_SEQ – Speichert die erwartete Sequenznummer für den nächsten TLP – Im LinkDown-Zustand alle auf „0" gestellt – Erhöht um 1 für jedes akzeptierte TLP oder wenn das DLLR_IN_PROGRESS Flag (wie unten beschrieben) gelöscht wird durch Akzeptierung eines TLP – Geladen mit Wert (Trans. Seq. Num + 1), sobald ein Link-Layer-DLLP empfangen wird und das DLLR_IN +_PROGRESS-Flag gelöscht wird. • Ein Verlust der Sequenznummer-Synchronisation zwischen Sender und Empfänger wird angezeigt, wenn der Wert für NEXT_RCV_SEQ sich vom Wert unterscheidet, der von einem TLP oder einem Ack Timeout DLLP spezifiziert wird; in diesem Fall:
– Falls das DLLR_IN_PROGRESS-Flag gesetzt ist, • DLLR_IN_PROGRESS-Flag rücksetzen • Signalisierung eines „Sent Bad DLLP DLLP" Fehlers an Error Logging/Tracking • Hinweis: Dadurch wird angezeigt, dass ein DLLR DLLP (Nak) irrtümlicherweise gesendet wurde.
– Falls das DLLR_IN_PROGRESS-Flag nicht gesetzt ist, • DLLR_IN_PROGRESS-Flag setzen und Nak DLLP initiieren • Hinweis: Dadurch wird angezeigt, dass ein TLP verloren gegangen ist.
– Es werden die folgenden 3-Bit-Counters eingesetzt: • DLLRR_COUNT – Zählt, wie oft DLLR_DLLP in einer gegebenen Zeitperiode ausgegeben wird
– Im LinkDown-Zustand auf b'000 gesetzt
– Für jedes ausgegebene Nak DLLP um 1 erhöht
– Wenn der Counter b' 100 erreicht: • Die Link-Kontrolle-Zustandsmaschine geht von LinkActive auf LinkActDefer • DLLR_COUNT wird dann auf b'000 rückgesetzt
– Falls DLLRR_COUNT nicht gleich b'000, alle 256 Symbolzeiten um 1 verringert • d. h.: gesättigt bei b'000
– Es wird das folgende Flag eingesetzt: • DLLR_IN_PROGRESS
– Die Bedingungen für Setzen/Beseitigen des Flags werden im Anschluss beschrieben
– Wenn DLLR_IN_PROGRESS gesetzt ist, werden alle empfangenen TLPs zurückgewiesen (bis das TLP empfangen wird, das durch das DLLR DLP ausgewiesen wird)
– Wenn DLLR_IN_PROGRESS beseitigt ist, werden empfangene TLPs wie nachstehend beschrieben geprüft
– Damit ein TLP akzeptiert wird, sollten typischerweise folgende Bedingungen wahr sein: • Die empfangene TLP-Sequenznummer ist gleich NEXT_RCV_SEQ • Die physische Schicht hat keine Fehler beim Empfang des TLPs angezeigt • Die TLP-CRC-Prüfung zeigt keinen Fehler an
– Wenn ein TLP akzeptiert wird: Der Transaktionsschichtteil des TLPs wird an die Empfangstransaktionsschicht weitergeleitet • Falls gesetzt, wird das DLLR_IN_PROGRESS-Flag beseitigt • NEXT_RCV_SEQ wird erhöht
– Wenn ein TLP nicht akzeptiert wird: • Das DLLR_IN_PROGRESS-Flag wird gesetzt • Ein Nak DLLP wird gesendet
– Das Ack/Nak-Sequenznummerfeld sollte typischerweise den Wert (NEXT_RCV_SEQ – 1) enthalten
– Das Feld Nak-Typ (NT) sollte typischerweise die Ursache für die Nak-Situation anzeigen: • b'00 – Receive Error identifiziert durch physische Schicht • b'01 – TLP-CRC-Prüfung fehlgeschlagen • b'10 – Sequenznummer falsch • b'11 – Framing Error identifiziert durch physische Schicht
– Der Empfänger sollte typischerweise nicht gestatten, dass die Zeit vom Empfang des CRC für einen TLP zur Sendung des Nak 1023 Symbolzeiten überschreitet (gemessen vom Port der Komponente) • Hinweis: NEXT_RCV_SEQ wird nicht erhöht
– Falls die Empfangsdatenverbindungsschicht (Receive Data Link Layer) das erwartete TLP nach einem Nak DLLP nicht innerhalb von 512 Symbolzeiten empfängt, wird das Nak DLLP wiederholt. • Falls das TLP nach vier Versuchen immer noch nicht empfangen wird, wird der Empfänger: – in den LinkActDefer-Zustand übergehen und ein Link-Retraining durch die physische Schicht initiieren – Meldung eines größeren Fehlers an Fehlerverfolgung und Protokollierung (Error Tracking and Logging)
– Data-Link-Layer-Acknowledgement-DLLPs sollten typischerweise gesendet werden, wenn folgende Zustände wahr sind: • Die Link-Kontrolle und Management-Zustandsmaschine befindet sich im LinkActive-Zustand • TLPs wurden akzeptiert, aber noch nicht bestätigt durch Senden eines Acknowledgement-DLLP • Mehr als 512 Symbolzeiten sind seit dem letzten Acknowledgement-DLLP verstrichen
– DLL-Acknowledgement-DLLPs können häufiger gesendet werden als erforderlich
– DLL-Acknowledgement-DLLPs spezifizieren den Wert (NEXT_RCV_SEQ – 1) im Feld Ack Sequence Num

Ack-Zeitsperre-Mechanismus
Gesetzt den Fall, dass ein TLP am Link 112 fehlerhaft ist und dieser Umstand zur Folge hat, dass der Receiver die Präsenz des TLPs nicht erfasst. Das verlorene TLP wird erfasst, wenn ein nachfolgendes TLP gesendet wird, da sich die TLP-Sequenznummer nicht mit der am Empfänger erwarteten Sequenznummer deckt. Die Sende-DLL 204 kann jedoch generell nicht die Zeit für das nächste TLP begrenzen, das ihr von der Sendetransaktionsschicht präsentiert wird. Der Ack-Zeitsperre-Mechanismus gestattet dem Sender, die Zeit zu begrenzen, die der Empfänger zur Erfassung des verlorenen TLPs benötigt.
Ack-Zeitsperre-Mechanismusregeln

• Falls der Sende-Retry-Puffer TLPs enthält, für die keine Ack-DLLPs empfangen wurden, und keine TLPs oder Link-DLLPs für eine Periode von mehr als 1024 Symbolzeiten gesendet worden sind, sollte typischerweise ein Ack-Zeitsperren-DLLP gesendet werden.
• Nach Sendung eines Ack-Zeitsperren-DLLP, sollte die Datenverbindungsschicht (DLL) typischerweise keine weiteren TLPs an die physische Schicht zwecks Sendung weiterleiten, bis ein Acknowledgement-DLLP von der Komponente an der gegenüberliegenden Seite des Link empfangen worden ist.
• Falls für eine Periode von mehr als 1023 Symbolzeiten kein Acknowledgement-DLLP empfangen wird, wird das Ack-Zeitsperren-DLLP erneut gesendet, 1024 Symbolzeiten nach der vierten aufeinander folgenden Sendung eines Ack-Zeitsperren-DLLPs ohne Empfang eines Acknowledgement-DLLP; Übergang in LinkActDefer-Zustand und Initiierung von Link-Retraining durch die physische Schicht

Meldung eines größeren Fehlers an Fehlerverfolgung und Protokollierung (Error Tracking and Logging)
Physische Schicht 206
Unter weiterer Bezugnahme auf 2 wird die physische Schicht 206 präsentiert. Wie hier verwendet isoliert die physische Schicht 206 die Transaktionsschicht 202 und die Datenverbindungsschicht (DLL) 204 von der Signaltechnik, die für den Datenaustausch über den Link eingesetzt wird. Gemäß dem in 2 illustrierten Ausführungsbeispiel ist die physische Schicht unterteilt in die logischen 208 und physischen 210 funktionellen Unterblöcke.
Wie hier verwendet ist der logische Unterblock 208 für die „digitalen" Funktionen der physischen Schicht 206 verantwortlich. In dieser Hinsicht hat der logische Unterblock 208 zwei Hauptabschnitte: einen Sendeabschnitt, der ausgehende Daten für die Sendung durch den physischen Unterblock 210 vorbereitet, und einen Empfangsabschnitt, der empfangene Daten identifiziert und vorbereitet, bevor sie an die Datenverbindungsschicht (DLL) 204 weitergeleitet werden. Der logische Unterblock 208 und der physische Unterblock 210 koordinieren den Port-Status durch eine Status- und Kontrollregister-Schnittstelle. Kontroll- und Managementfunktionen der physischen Schicht 206 werden durch den logischen Unterblock 208 gesteuert.
Gemäß einem Ausführungsbeispiel arbeitet die EGIO-Architektur mit einem 8b/10b-Sendecode. Gemäß diesem Aspekt werden 8-Bit-Zeichen als 3-Bits und 6-Bits behandelt, die einer 4-Bit-Codegruppe bzw. 6-Bit-Codegruppe zugeordnet sind.
Diese Codegruppen sind verknüpft und bilden ein 10-Bit-Symbol. Das 8b/10b-Codierungssystem, das von der EGIO-Architektur eingesetzt wird, liefert spezielle Symbole, die sich von den Datensymbolen unterscheiden, die für die Repräsentation von Zeichen eingesetzt werden. Diese Sondersymbole werden für verschiedene Link-Managementmechanismen – wie unten beschrieben – eingesetzt. Sondersymbole werden ferner für die Rahmung von DLLPs und TLPs verwendet, wofür besondere Sondersymbole verwendet werden, sodass diese beiden Pakettypen schnell und leicht unterschieden werden können.
Der physische Unterblock 210 beinhaltet einen Sender und einen Empfänger. Der Sender erhält vom logischen Unterblock 208 Symbole, die dieser serialisiert und auf den Link 112 überträgt. Der Empfänger erhält vom Link 112 serialisierte Symbole, dieser wandelt die empfangenen Signale in einen Bitstream um, der entserialisiert und zusammen mit einer Symbolrate (Symbol Clock), empfangen vom eingehenden Seriellstream, an den logischen Unterblock 208 weitergeleitet wird. Es ist zu beachten, dass die EGIO-Verbindung 112, wie hier verwendet, durchaus eine breite Auswahl von Kommunikationsmedien, wie u. a. elektrische Kommunikationsleitung, optische Leitung, eine Funkverbindung, drahtlose Kommunikationskanäle, eine Infrarot-Verbindung und dergleichen repräsentieren kann. In dieser Hinsicht ist jeder der Sen der und/oder Empfänger, die den physischen Unterblock 210 der physischen Schicht 206 beinhalten, für einen oder mehrere der o. g. Kommunikationsverbindungen geeignet.
BEISPIEL EINES KOMMUNIKATIONSAGENTEN
6 zeigt ein Blockdiagramm eines Beispiels eines Kommunikationsagenten, der gemäß einem Ausführungsbeispiel der vorliegenden Erfindung mindestens ein Subset der Funktionen in Verbindung mit der vorliegenden Erfindung beinhaltet. Gemäß dem in 6 illustrierten Ausführungsbeispiel beinhaltet der Kommunikationsagent 600 Steuerlogik 602, eine EGIO-Kommunikationsmaschine 604, Speicherbereich für Datenstrukturen 606 und wahlweise eine oder mehrere Anwendungen 608.
Wie hier verwendet bietet Steuerlogik 602 Prozessressourcen für jedes von einem oder mehreren Elementen der EGIO-Kommunikationsmaschine 604, um selektiv ein oder mehrere Aspekte der Erfindung zu implementieren. In dieser Hinsicht soll Steuerlogik 602 einen oder mehrere eines Mikroprozessors, eines Microcontrollers, einer Zustandsmaschine (FSM), eines programmierbaren Logikbausteins (PLD), eines programmierbaren logischen Array (PLA) repräsentieren, oder Inhalt, der, wenn ausgeführt, Steuerlogiken für wie oben beschriebene Funktionen implementiert.
Die EGIO-Kommunikationsmaschine 604 wird gezeigt mit einem oder mehreren einer Transaktionsschichtschnittstelle 202, einer Datenverbindungsschichtschnittstelle (DLL) 204 und einer physischen Schicht 206, bestehend aus einem logischen Unterblock 208 und einem physischen Unterblock 210, um den Kommunikationsagent 600 mit einem EGIO-Link 112 zu verbinden. Wie hier verwendet, führen die Elemente der EGIO-Kommunikationsmaschine 604 eine ähnliche Funktion aus, wenn nicht sogar die gleiche Funktion, wie die oben beschriebenen.
Gemäß dem in 6 illustrierten Ausführungsbeispiel wird der Kommunikationsagent 600 gezeigt mit Datenstrukturen 606. Wie im Anschluss unter Bezugnahme auf 8 genauer ausgeführt können Datenstrukturen 606 sehr wohl Speicherbereich, I/O-Bereich, Konfigurationsbereich und Nachrichtenbereich beinhalten, die von der Kommunikationsmaschine 606 genutzt werden, um Kommunikation zwischen elektronischen Geräten zu ermöglichen.
Wie hier verwendet sollen Anwendungen 608 eine breite Auswahl von Anwendungen repräsentieren, die selektiv von der Kommunikationsmaschine 600 aufgerufen werden, um das EGIO-Kommunikationsprotokol und zugehörige Managementfunktionen zu implementieren.
BEISPIELE FÜR DATENSTRUKTUR(EN)
8 zeigt eine grafische Darstellung einer oder mehrerer Datenstrukturen, die von den EGIO-Schnittstellen 106 gemäß einer Ausführungsform der vorliegenden Erfindung eingesetzt werden. Insbesondere unter Bezugnahme auf das in 8 illustrierte Ausführungsbeispiel sind vier (4) Adressbereiche für den Einsatz innerhalb der EGIO-Architektur definiert: Konfigurationsbereich 810, I/O-Bereich 820, Speicherbereich 830 und Nachrichtenbereich 840. Wie gezeigt beinhaltet Konfigurationsbereich 810 ein Header-Feld 812, das Daten enthält, welche die EGIO-Kategorie definieren, zu der ein Hostgerät gehört (z. B. Endpoint, Switch, Root-Complex etc.). Jeder dieser Adressbereiche hat, wie im Anschluss erläutert, bestimmte Funktionen.
ALTERNATIVE AÜSFÜHRUNGSFORMEN
10 ist ein Blockdiagramm eines Speichermediums, in dem eine Vielfalt von Befehlen gespeichert sind, einschließlich Befehle für die Implementierung eines oder mehrerer Aspekte der EGIO-Verbindungsarchitektur und des zugehörigen Kommunikationsprotokolls, gemäß einer weiteren Ausführungsform der vorliegenden Erfindung.
Im Allgemeinen illustriert 10 ein maschinenzugreifbares Medium/Baustein 1000, worauf Inhalt gespeichert ist, u. a. mindestens ein Subset, dass, wenn ausgeführt von einer zugreifenden Maschine, die innovative EGIO-Schnittstelle 106 der vorliegenden Erfindung implementiert. Wie hier verwendet repräsentiert das maschinenzugreifbare Medium 1000 eine beliebige Zahl von derartigen Medien, wie sie unter Fachleuten bekannt sind, wie zum Beispiel flüchtige Speicher, nicht flüchtige Speicher, magnetische Speicher, optische Speicher, propagierte Signale und dergleichen. Gleicherma ßen sollen die ausführbaren Befehle eine beliebige Zahl von Programmiersprachen repräsentieren, die in der Branche bekannt sind, wie zum Beispiel C++, Visual Basic, Hypertext Markup Language (HTML), Java, eXtensible Markup Language(XML) und dergleichen. Ferner ist zu beachten, dass das Medium 1000 gemeinsam mit einem Hostsystem angeordnet werden muss. Das heißt, Medium 1000 kann durchaus innerhalb eines abgesetzten Server residieren, der mit einem ausführenden System kommunikativ gekoppelt und durch dieses zugreifbar ist. Demzufolge ist die Softwareausführung gem. 10 als erläuterndes Beispiel zu betrachten, da alternative Speichermedien und Softwareausführungen im Rahmen der vorliegenden Erfindung zu erwarten sind.
Obgleich die Erfindung in der ausführlichen Beschreibung sowie in der Zusammenfassung in einer Sprache beschrieben wird, die charakteristisch ist für die baulichen Merkmale und/oder methodologischen Schritte, ist es verständlich, dass die in den beiliegenden Ansprüchen definierte Erfindung sich nicht unbedingt auf die beschriebenen, spezifischen Merkmale oder Schritte beschränkt. Spezifische Merkmale und Schritte werden vielmehr als Ausführungsbeispiele der vorliegenden Erfindung offenbart. Es wird jedoch ersichtlich sein, dass verschiedene Modifizierungen und Änderungen daran vorgenommen werden können, ohne vom breiteren Geltungsbereich der vorliegenden Erfindung abzuweichen. Die vorhandene Spezifikation und präsentierten Zahlen sind daher eher als erläuternde Beispiele zu betrachten und nicht als bindende Vorgaben. Die Beschreibung und Zusammenfassung sind daher nicht als vollständig zu betrachten und beschränken die vorliegende Erfindung nicht auf die spezifischen, offenbarten Ausführungsformen.
Der Wortlaut der anschließenden Ansprüche ist nicht dahingehend auszulegen, dass die Erfindung auf die in der Spezifikation offenbarten, spezifischen Ausführungsformen beschränkt ist. Vielmehr wird der Rahmen der Erfindung gänzlich durch die folgenden Ansprüche festgelegt.

Claims

Ein Verfahren, das die Schritte beinhaltet, um einen Request für isochrone Kommunikationsressourcen innerhalb einer allgemeinen Ein-/Ausgangsstruktur eines elektronischen Gerätes zu empfangen (504), wobei die isochronen Kommunikationsressourcen einen oder mehrere virtuelle Kanäle der allgemeinen Ein-/Ausgangsstruktur beinhalten, die dazu bestimmt sind, isochrone Kommunikationen mit garantierter Bandbreite und Latenz abzuwickeln; und zu prüfen (506), ob ein oder mehrere Betriebsanforderungen in Verbindung mit dem empfangenen Request durch ein entsprechendes Subset der allgemeinen Ein-/Ausgangsstruktur befriedigt werden können, um eine mit dem empfangenen Request zusammenhängende isochrone Kommunikation zu unterstützen.
Ein Verfahren nach Anspruch 1, bei dem ferner: eine isochrone Verbindung zwischen einem Requester (Initiator) der isochronen Kommunikation und der allgemeinen Ein-/Ausgangsstruktur aufgebaut wird (512) und die isochrone Verbindung ein oder mehrere Betriebsparameter ausweist, unter denen die isochrone Kommunikation durch die allgemeine Ein-/Ausgangsstruktur unterstützt wird.
Ein Verfahren nach Anspruch 2, bei dem ferner: mindestens ein Subset allgemeiner Ein-/Ausgangselemente bereitgestellt wird, welche am isochronen Datenaustausch der isochronen Verbindung beteiligt sind, und die Einfüge-Requests von Requester (Initiator) bzw. Completer (Target) in Übereinstimmung mit der aufgebauten Verbindung geregelt und überwacht werden.
Ein Verfahren nach Anspruch 3, bei dem ferner: isochrone Transaktionen mittels eines zeitabhängigen, gewichteten Port-Arbitrations-Mechanismus im Round-Robin-Verfahren geregelt und überwacht (514) werden.
Ein Verfahren nach Anspruch 4, bei dem ferner: die Transaction-Service-Zuteilung in einer oder mehreren Datenstrukturen in Übereinstimmung mit der aufgebauten isochronen Verbindung aufrechterhalten wird.
Ein Verfahren nach Ansprüchen 3 bis 5, bei dem ferner: in selektiver Weise durch ein oder mehrere Elemente eines aufgebauten, isochronen Kommunikationskanals Flow-Control (Flussregelung) initiiert wird, um Einfüge-Requests zu verzögern, die über ein oder mehrere Privilegien der isochronen Verbindung hinausgehen.
Ein Verfahren nach einem der vorangegangenen Ansprüche, bei dem ferner: ein Hinweis auf Kommunikationsanforderungen und/oder -fähigkeit von zumindest einem Subset von Elementen innerhalb der allgemeinen Ein-/Ausgangsstruktur empfangen wird, nachdem an einem Hostgerät ein Reset-Event stattgefunden hat.
Ein Verfahren nach Anspruch 7, bei dem ferner: eine Fähigkeitstabelle erstellt wird, die zumindest teilweise auf den Hinweisen basiert, die zumindest von dem Subset von Elementen innerhalb der allgemeinen Ein-/Ausgangsstruktur empfangen werden.
Ein allgemeines Ein-/Ausgangselement, bestehend aus: einem oder mehreren Ein-/Ausgangsports, die mit einem oder mehreren anderen allgemeinen Ein-/Ausgangselementen einer allgemeinen Ein-/Ausgangsstruktur gekoppelt sind; und ferner bestehend aus einem Bandbreitenmanager, um Requests für isochrone Kommunikationsressourcen von einem Requester-/Completer-Paar zu empfangen (504) und in selektiver Weise die angeforderten, isochronen Kommunikationsressourcen bereitzustellen, nachdem geprüft worden ist (506), dass zumindest ein Subset der allgemeinen Ein-/Ausgangsstruktur eine oder mehrere Betriebsanforderungen in Verbindung mit dem empfangenen Request unterstützen kann; wobei die isochronen Kommunikationsressourcen einen oder mehrere virtuelle Kanäle der allgemeinen Ein-/Ausgangsstruktur beinhalten, die dazu bestimmt sind, die isochronen Kommunikationen mit garantierter Bandbreite und Latenz abzuwickeln.
Ein allgemeines Ein-/Ausgangselement nach Anspruch 9, bei dem der Bandbreitenmanager einen Hinweis auf Kommunikationsfähigkeit von zumindest einem Subset der gekoppelten, allgemeinen Ein-/Ausgangselemente empfängt, um danach zu bestimmen, ob der Request für isochrone Kommunikationsressourcen erfüllt werden soll.
Ein allgemeines Ein-/Ausgangselement nach Anspruch 10, bei dem der Bandbreitenmanager die Betriebsanforderungen in Verbindung mit dem isochronen Request mit der Kommunikationsfähigkeit von zumindest einem Subset eines allgemeinen Ein-/Ausgangselementes zwischen Requester und Completer vergleicht (506), um zu bestimmen, ob der Request für isochrone Ressourcen erfüllt werden soll.
Ein allgemeines Ein-/Ausgangselement nach Anspruch 10 oder 11, bei dem der Bandbreitenmanager eine isochrone Verbindung zwischen dem Requester-/Completer-Paar aufbaut (512) und die allgemeine Ein-/Ausgangsstruktur einen oder mehrere Betriebsparameter ausweist, unter denen die isochronen Kommunikationsressourcen auf das Requester-/Completer-Paar zugeteilt worden sind.
Ein allgemeines Ein-/Ausgangselement nach Anspruch 12, bei dem der Bandbreitenmanager für jedes intervenierende, allgemeine Ein-/Ausgangselement zwischen dem Requester-/Completer-Paar die isochrone Verbindung bereitstellt, um die in der Verbindung ausgewiesenen Betriebsparameter zu realisieren (514).
Ein allgemeines Ein-/Ausgangselement nach Anspruch 13, bei dem das (die) intervenierende(n), allgemeine(n) Ein-/Ausgangselement(e) isochrone Transaktionen mittels eines zeitabhängigen, gewichteten Port-Arbitrations-Mechanismus im Round-Robin-Verfahren regeln und überwachen.