DE60303119T2

DE60303119T2 - Echtzeitdatenströmung von antworten auf lesezugriffe in einer verbindung zwischen zwei datenknoten

Info

Publication number: DE60303119T2
Application number: DE60303119T
Authority: DE
Inventors: Randy Beaverton OSBORNE
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2002-02-19
Filing date: 2003-01-30
Publication date: 2006-08-31
Anticipated expiration: 2023-01-31
Also published as: AU2003205389A8; EP1476817B1; CN101819562B; US7006533B2; US20030156581A1; CN1636198B; AU2003205389A1; WO2003071434A3; WO2003071434A2; DE60303119D1; ATE315252T1; CN101819562A; TW200401538A; EP1476817A2; TWI292989B; CN1636198A

Description

Hintergrund der Erfindung
Gebiet der Erfindung
Die Erfindung bezieht sich auf das Gebiet der Computersysteme und insbesondere auf der Gebiet der Kommunikation zwischen Vorrichtungen in einem Computersystem.
Beschreibung des verwandten Standes der Technik
Moderne Computersysteme enthalten eine Vielzahl von Komponenten, wie beispielsweise mit dem Systemspeicher verbundene Zentraleinheiten bzw. CPUs, eine Host-Bridge, Peripheriegeräte (z.B. Tastatur, Diskettenlaufwerk, Maus), externe Busse (z.B. PCI(peripheral component interconnect)-Bus), usw. Eine Schnittstelle, wie beispielsweise eine Hub-Verbindung bzw. Hublink, überträgt Daten zwischen separaten Hubs innerhalb eines Computersystems. Ein Hublink ist eine Schnittstelle zum Verbinden von Baueinheiten einer Kernlogik über eine Schnittstelle mit niedriger und hoher Bandbreite. Zur Übertragung von Daten zwischen Hubs über den Hublink werden Pakete verwendet. Bei einer neueren Technologie, wie beispielsweise PCI-X (PCI Local Bus Specification Rev. 3.0) muss eine Übertragung von Paketen zwischen den Hubs über die Hub-Verbindung verbessert werden. Bei einer Technologie mit höherer Bandbreite müssen Latenz bzw. Wartezeit und Overhead bzw. Überhang verbessert werden.
Das US-Patent 6 145 039 offenbart eine Schnittstelle zur Übertragung von Daten zwischen einem Speicher-Controller-Hub und einem Input/Output- bzw. Eingabe/Ausgabe-Hub eines Chipsatzes innerhalb eines Computersystems. Ein Ausführungsbeispiel der Schnitstelle enthält einen bidirektionalen Datensignalpfad und ein Paar von quellsynchronen Abtastsignalen. Der Datensignalpfad über trägt Daten in Paketen über aufgeteilte Transaktionen. Zusätzlich enthalten die Pakete, wenn erforderlich, ein Anfragepaket und ein Beendigungspaket.
Kurzbeschreibung der Zeichnung
Die Erfindung wird beispielhaft und nicht beschränkend in den Figuren der Zeichnung veranschaulicht, wobei gleiche Bezugszeichen ähnliche Elemente bezeichnen. Es ist zu be achten, daß Bezüge auf „ein" (unbestimmt) oder „ein" (Zahl) Ausführungsbeispiel in dieser Offenbarung nicht notwendigerweise dasselbe Ausführungsbeispiel ist und ein derartiger Bezug zumindest ein bedeutet.
1 veranschaulicht ein System mit einen Hublink.
2 ein Beispiel für eine Aufteilungs-Transaktion über einen Hublink.
3 veranschaulicht ein Blockschaltbild eines Hublinks.
4 veranschaulicht ein Anfrage-Paket-Kopfzeilenformat einschließlich einer 32-Bit-Adressierungsart.
5 veranschaulicht eine Anfrage-Paket-Kopfzeile einschließlich einer 64-Bit-Adressierungsart.
6 veranschaulicht eine Anfrage-Paket-Kopfzeile 600 einschließlich einer implizierten Adressierungsart.
7 veranschaulicht eine Beendigungs-Paket-Kopfzeile.
8 veranschaulicht eine Beendigungszustand- und Kodierungstabelle.
9 veranschaulicht eine Leseanfrage- und Leseergebnis bzw. Leserückgabe-Paket-Kommunikation.
10 veranschaulicht ein Ausführungsbeispiel der Erfindung, das ein Strömen bzw. Streaming von Leserückgabedaten über einen Hublink strukturiert.
11 veranschaulicht ein Zeitdiagramm für ein Ausführungsbeispiel der Erfindung.
12 veranschaulicht ein Zeitdiagramm für einige Ausführungsbeispiele der Erfindung.
13 veranschaulicht ein Ausführungsbeispiel der Erfindung mit einem dynamisch aufgeteilten Datenpaket.
14 veranschaulicht ein Blockschaltbild eines Verfahrens für ein Ausführungsbeispiel der Erfindung.
Genaue Beschreibung der Erfindung
Die Erfindung bezieht sich allgemein auf ein Verfahren und eine Vorrichtung zur Verbesserung der Bandbreite und Verringerung der Latenz für eine Datenübertragung über eine Hub-Verbindung bzw. einen Hublink. Ein Bezug in der Beschreibung auf „ein (unbestimmt) Ausführungsbeispiel", „ein (Zahl) Ausführungsbeispiel", „einige Ausführungsbeispiele" oder „andere Ausführungsbeispiele" bedeutet, dass ein bestimmtes in Verbindung mit den Ausführungsbeispielen beschriebenes Merkmal, Struktur oder Charakteristik in zumindest einigen Ausführungsbeispielen, aber nicht notwendigerweise in allen Ausführungsbeispielen der Erfindung enthalten ist. Das mannigfaltige Auftreten von „ein (unbestimmt) Ausführungsbeispiel", „ein (Zahl) Ausführungsbeispiel" oder „einige Ausführungsbeispiele" bezieht sich nicht notwendigerweise immer auf dieselben Ausführungsbeispiele. Wem diese Beschreibung angibt, dass eine Komponente, ein Merkmal, eine Struktur oder Charakteristik enthalten sein „kann", „dürfte" oder „könnte", ist es nicht erforderlich, dass diese bestimmte Komponente, das Merkmal, die Struktur oder Charakteristik enthalten ist. Wenn die Beschreibung oder der Anspruch sich auf „ein" (unbestimmt) Element bezieht, bedeutet dies nicht, daß es nur ein (Zahl) Element gibt. Wenn sich die Beschreibung oder Ansprüche auf „ein zusätzliches" Element beziehen, schließt das nicht ein, dass mehr als ein zusätzliches Element vorhanden ist.
Der von dieser Offenbarung profitierende Fachmann wird erkennen, daß viele andere Abwandlungen der vorstehenden Beschreibung und Zeichnung innerhalb des Schutzbereichs der vorliegenden Erfindung möglich sind. Demgemäß ist der Schutzumfang der Erfindung durch die folgenden Ansprüche einschließlich irgendwelcher Verbesserungen daran definiert. Nun werden unter Bezugnahme auf die Zeichnung beispielhafte Ausführungsbeispiele der Erfindung beschrieben. Die beispielhaften Ausführungsbeispiele dienen zur Veranschaulichung der Erfindung und sollten nicht als den Schutzumfang der Erfindung einschränkend interpretiert werden.
1 veranschaulicht ein System 100. Das System 100 umfasst eine Hub-Verbindung bzw. einen Hublink 102, einen Speicher-Controller-Hub (MCH) 104, einen Eingabe/Ausgabe(I/O)-Controller-Hub (ICH) 106, eine Zentraleinheit (CPU) 108, einen Speicher 110, einen PCI(Peripheral Component Interconnect)-Bus 112, PCI-Agenten 114, eine Tastatur 118, eine Maus 120, einen Scanner 122 und ein Diskettenlaufwerk 124. Der Hublink 102 stattet einzelne Komponenten mit einer Punkt-Zu-Punkt- bzw. Point-to-Point-Schnittstelle au. Es ist jedoch zu beachten, dass der Hublink 102 eine Schnittstelle mit drei oder mehr Komponenten zur Verfügung stellen kann. Wie in 1 veranschaulicht, wird der Hublink 102 verwendet, zwei separate Komponenten (z.B. Hub-Agenten) innerhalb eines Chipsatzes zu verbinden. Die Hub-Agenten bilden eine zentrale Verbindung zwischen zwei oder mehr separaten Bussen und/oder anderen Arten von Kommunikationsleitungen. ICH 106 bildet eine Zwischenverbindung zwischen zahlreichen Peripheriegeräten innerhalb des Systems 100 (z.B. Tastatur 118, Diskettenlaufwerk 124, Scanner 122 und/oder Maus 120). Weiterhin verbinden die externen Busse und ihre Agenten (z.B. PCI-Bus 112 und PCI-Agenten 114) direkt zwischen dem Speicher 110 und der CPU 108 über den Hublink 102, indem eher mit der ICH 106 verbunden wird. eher als direkt mit dem MCH 104 zwischen zu verbinden.
Durch Verwendung des Hublink zum Verbinden zwischen dem MCH 104 und dem ICH 106 ist Zugriff zwischen I/O-Komponenten und dem CPU/Speicher-Untersystem möglich. Transaktionen werden über den Hublink 102 unter Verwendung eines paketbasierten Aufteil-Transaktions-Protokolls übertragen. Beispielsweise wird ein Anfragepaket verwendet, um eine Transaktion zu starten, und ein separates Beendigungspaket kann nachfolgend verwendet werden, um eine Transaktion zu beenden, wenn erforderlich.
2 veranschaulicht ein Beispiel für eine Aufteil-Transaktion über den Hublink 102. Wie in 2 veranschaulicht, erhält ein Hub-Agent anfänglich per Entscheidung 202 Verfügung über den Hublink 102. Folgend auf diese Entscheidung gibt es eine Anfragephase 204. Wem es notwendig ist (d.h. im Fall einer Rückgabe von Daten für eine Lesetransaktion) wird der Anfragephase eine Beendigungsphase folgen. Vor der Beendigungsphase wird jedoch der antwortende Hub-Agent zuerst über die Verfügung über den Hublink entscheiden 206.
Zwischen der Zeit eines Übertragens eines Anfragepakets und eines entsprechenden Beendigungspakets über den Hublink 102 können separate Pakete ohne Bezug entsprechend vorbestimmten Reihenfolgeregeln über den Hublink übertragen werden, wie nachstehend genauer diskutiert. Beispielsweise kann im Fall einer Leseanfrage von einem Peripheriegerät zum Speicher die Bereitstellung der angefragten Daten eine Mehrzahl von Taktzyklen in Anspruch nehmen, damit die Daten fertig zur Rückgabe sind und ein Beendigungspaket enthalten ist. Während der Zeit, die es in Anspruch nimmt, die angeforderten Daten zu erhalten, können separate, in einer Schlange/Warteschleife des MCH 104 wartende Beendigungs- und/oder Anfrage-Pakete über die ICH 106 übertragen werden.
Weiterhin wird, wie in 2 veranschaulicht, jede Anfrage oder Beendigung als ein Paket über die Schnittstelle übertragen. Bei Transaktionen vom Schreib-Typ stehen die Daten in Zusammenhang mit der Anfrage. Bei Transaktionen vom Lese-Typ werden die Daten mit der Beendigung in Zusammenhang stehen. In einigen Fällen wird es in dem Fall, in dem das Beendigungs-Paket aufgetrennt ist, mehr als eine Beendigung für eine Anfrage geben, was effektiv in eine Vielzahl von Beendigungspaketen aufteilt.
Der Hublink 102 verwendet Transaktions-Descriptoren sowohl zum Schreiben eines Hublink-Verkehrs als auch zum Identifizieren der Attribute bzw. Eigenschaften einer Transaktion. Beispielsweise können die Descriptoren zur Definition einer Transaktion als isochron oder asynchron verwendet werden, die als eine Folge dann entsprechend einem vordefinierten Protokoll behandelt werden kann.
Der Hublink 102 verwendet ein Paket-basiertes Protokoll mit zwei Arten von Paketen: Anfrage und Beendigung. Ein Anfrage-Paket wird für jede Hublink-Transaktion verwendet. Beendigungs-Pakete werden, wo erforderlich, beispielsweise verwendet, um Lesedaten zurückzugeben oder eine Beendigung bestimmter Arten von Schreibtransaktionen (z.B. I/O-Schreiben und Speicher-Schreiben mit angefragter Beendigung) zu bestätigen. Beendigungs-Pakete stehen mit ihren entsprechenden Anfrage-Paketen durch Transaktions-Descriptoren in einer Reihenfolge in Zusammenhang.
Die Hublink-Schnittstelle verwendet ein Entscheidungsprotokoll, das symmetrisch und verteilt ist. Beispielsweise gibt jeder Hub-Agent ein Anfragesignal ab, das durch die anderen mit derselben Schnittstelle verbundenen Agenten überwacht wird. Es wird kein Erteilungssi gnal verwendet und die Agenten bestimmen unabhängig über die Verfügung über die Schnittstelle. Das Ende einer Paketübertragung tritt auf, wenn ein Hublink-Agent, der über die Schnittstelle „verfügt" (z.B. beim Übertragen von Daten ist) seine Kontrolle über die Schnittstelle durch Nicht-Vorbringen eines Anfragesignals freigibt. Zusätzlich erfolgt auch eine Flusssteuerung durch Verwendung eines „Stop"-Signals, um die Pakete zu wiederholen oder zu unterbrechen.
Übertragungen von Informationen über den Hublink 102 werden unter Verwendung eines Paket-basierten Protokolls erreicht. Ein Anfrage-Paket wird im Allgemeinen zum Starten einer Transaktion und ein Beendigungs-Paket zum Beenden der Transaktion verwendet. Das Hublink-Protokoll weist auch einen Transaktions-Beschreibungsmechanismus auf, um eine deterministische Dienstqualität zu erreichen. Dieser Mechanismus bietet für ein Schreiben von Hublink-Verkehr verwendete Informationen ebenso wie die Eigenschaften einer Transaktion, beispielsweise durch Definieren der Transaktion als isochron oder asynchron.
3 veranschaulicht ein Blockschaltbild eines das MCH 104 und die ICH 106 verbindenden Hublinks 102. Der Hublink enthält einen bidirektionalen Datenpfad 151, einen oder mehr Daten-Strobes bzw. Daten-Abtaster 152, ein Flusssteuersignal 153, eine Gruppe von Entscheidungssignalen 154, ein Systemrücksetzsignal 155, ein Taktsignal 156, ein Bezugsspannungssignal 157 und optional ein Betriebsmittelentzug- bzw. Preemption(PMPT)-Signal 158. Ein Hub A enthält eine Datenpfad-I/O-Einheit 135 und ein Hub B enthält eine Datenpfad-I/O-Einheit 165. Beide Datenpfad-I/O-Einheiten 135 und 165 verbinden mit dem Datenpfad 151. Im Allgemeinen ist der Hublink 102 ein Mechanismus zur Verbindung von Hauptbaueinheiten der Kernlogik eines Computersystems, wie beispielsweise des Systems 100, über einen relativ begrenzten Datenpfad 151 mit relativ hoher Bandbreite. Zwischen einzelnen Komponenten in einem Computersystem, wie beispielsweise dem Hub A und dem Hub B ist eine Verbindung auf eine Punkt-zu-Punkt- bzw. Point-to-Point-Weise realisiert.
4 veranschaulicht ein Anfrage-Paket-Kopfzeilen-Format 400 einschließlich einer 32-Bit Adressierungsart. Der Grundteil des Anfrage-Paket-Kopfzeilen-Formats 400 ist ein Doppelwort lang (ein Wort ist gleich 16 Bit). Ein zusätzliches Doppelwort ist für eine 64-Bit Adressierungsart erforderlich (in 5 veranschaulicht). Daten werden über die Schnittstelle in „kleiner Indianer"-Reihenfolge, d.h. das unwichtigste Byte zuerst für einen 8-Bit breiten Datenpfad 151 oder ein Wort für einen 16-Bit breiten Datenpfad 151 übertragen. Die verschiedenen Felder der Paketkopfzeile 400 sind wie folgt beschrieben.
Das Anfrage/Beendigungs-Feld (rp/cp) bei einem Bit 31 des ersten Doppelwortes zeigt an, ob ein Paket ein Anfrage-Paket oder ein Beendigungs-Paket ist. Bevorzugt zeigt „0" ein Anforderungs-Paket und „1" ein Beendigungspaket an. Da die Paket-Kopfzeile 400 eine Anforderungs-Paket-Kopfzeile ist, sollte dieses Feld auf „0" gesetzt sein.
Das Lese/Schreib-Feld (r/w) bei einem Bit 30 des ersten Doppelworts zeigt an, ob ein Paket eine Lese- oder eine Schreib-Transaktion ist. Das Lese/Schreib-Feld zeigt auch zusammen mit dem Anfrage/Beendigungs-Feld an, ob Daten in dem Paket enthalten sein werden. Wenn beispielsweise das Paket eine Anfrage ist und wenn ein Schreiben angezeigt ist, werden Daten in dem Feld enthalten sein. Wenn das Paket weiterhin ein Beendigungspaket ist und ein Lesen anzeigt ist, werden Daten in dem Paket enthalten sein. Eine Anzeige eines Anfrage-Pakets und eine Anzeige eines Lesens besagt, dass in dem Paket keine Daten enthalten sein werden. Ebenso besagt eine Anzeige eines Beendigungs-Pakets und eines Schreibens, dass in dem Paket keine Daten enthalten sein werden. Eine Lese-Transaktion ist typischerweise durch eine „0" angezeigt und eine Schreib-Transaktion ist typischerweise durch eine „1" angezeigt.
Das Beendigung-erforderlich-Feld (cr) bei einem Bit 29 des ersten Doppelworts des Anfrage-Pakets 400 zeigt an, ob der Initiator bzw. Urheber des Pakets eine Antwort auf das Anfrage-Paket benötigt. Ein Beendigung-erforderlich ist typischerweise durch eine „1" und eine keine Beendigung-erforderlich ist typischerweise durch eine „0" angezeigt. Eine Schreib-Anfrage-Paket-Kopfzeile mit dem gesetzten Beendigung-erforderlich-Bit wird ausgegeben, wenn der Urheber des Pakets positive Informationen benötigt, dass die Anfrage beendet wurde. Die Beendigung des Schreibens sollte bevorzugt nicht zurückgegeben werden, bis das Schreiben sein Endziel erreicht hat. Speicher, I/O und Konfigurations-Lese-Anfrage sollten bevorzugt immer das Beendigung-erforderlich-Bit setzen. Das Beendigung-erforderlich-Bit sollte bevorzugt durch das Ziel für alle Anfragen, einschließlich speziellen Zyklen, wie beispielsweise kein Betrieb (no operation = NOP), Herunterfahren, Flush, Anhalten, Synchronisieren (Sync.), Flush-Bestätigung, Stop-Erteilungsbestätigung, usw. respektiert werden.
Das bei einem Bit 28 des ersten Doppelworts angeordnete Adressformat(af)-Feld zeigt an, ob das Adressierungsformat entweder implizit oder explizit (32 oder 64 Bit-Adressierung) ist. Für die Kopfzeile 400 würde das af-Bit auf „1" gesetzt, um eine explizite Adressierung anzuzeigen. Für eine implizite Adressierung sollte das af-Bit auf „0" gesetzt werden.
Das bei einem Bit 27 des ersten Doppelworts angeordnete Sperr(1k)-Feld zeigt an, ob das gegenwärtige Paket ein Teil einer gesperrten Abfolge ist. Alle Anfragen und Beendigungen in einer gesperrten Abfolge sollten dieses Bit auf „1" gesetzt haben. Agenten, die ein Sperren nicht verstehen, sollten dieses Feld ignorieren und sollten dieses Feld immer mit einer „0" füllen.
Das bei Bits 26 bis 21 des ersten Doppelworts angeordnte Transaktions-Descriptor-Routing-Feld ist ein Sechs-Bit-Feld zur Paketleitung. Es sind andere Feldbreiten möglich. Drei Bits werden für die Hub-Identifizierung(ID) verwendet, die den Agenten identifiziert, der den Anfangsmaster für eine Transaktion enthält. Die verbleibenden drei Bit des Routing-Felds werden zur Identifizierung interner „Leitungen" innerhalb eines Hublink-Agenten verwendet. Dieses zweite drei-Bit-Unterfeld ist als die Leitungs-ID bekannt. Das Hub-ID-Unterfeld wird verwendet, ein Routing in einem Mehrfach-Hublink-System (z.B. in dem System, das zwei oder mehr Hublink-Agenten aufweist). Von verschiedenen Hublink-Agenten (genauer, mit verschiedenen Hub-IDs) kommende Transaktionen sollten bevorzugterweise keine Reihenfolgen im Hinblick aufeinander aufweisen. Eine Verwendung einer Hub-ID ist optional für die Hublink-basierten Systeme, die nicht mehr als zwei Hublink-Komponenten unterstützen, und für bestimmte Hublink-Komponenten, die nicht als Hub-Verbindungs-Bilde-Blöcke entworfen sind, die in größeren Konfigurationen verwendet werden können.
Das Leitungs-ID-Unterfeld kann verwendet werden, Transaktionen nur zu unterscheiden, wenn die Transaktionen keine Reihenfolgenanforderungen im Hinblick aufeinander besitzen. Mit anderen Worten, sie kommen von verschiedenen internen Leitungen, die ungeordneten Verkehr tragen können. Die Bits 20 und 19 sind reserviert. Das an den Bits 18 bis 16 des ersten Doppelworts angeordnete Transaktions-Deskriptor-Attribut-Feld (T.D.Attr.) ist bevorzugterweise ein Drei-Bit-Wert, der bestimmt, wie eine Transaktion zu behandeln ist, wenn sie durch einen Ziel-Hublink-Agenten empfangen wird, beispielsweise, ob die Transaktion asynchron oder isochron zu behandeln ist. Das Attribut-Feld unterstützt ein Fordern von Anwendungsarbeitslasten, die sich auf die Bewegung und Verarbeitung von Daten mit bestimmten Dienstqualitätserfodernissen oder anderen differenzierenden Kennzeichen beziehen. Zusätzlich ermöglichen IEEE1394 (IEEE1394 Standard (1394–1995 IEEE Standard for a High Performance Serial Bus-Firewire 1995)) und USB (Universal Serial Bus)) die isochrone Bewegung von Daten zwischen Vorrichtungen.
Das bei den Bits 15 und 14 des ersten Doppelworts angeordnete Raumfeld zeigt an, ob das Paket einen Zielspeicherraum („00"), I/O („01"), Konfigurationsraum („10") oder spezielle Zyklen („11") aufweist.
Das bei den Bits 13 bis 6 angeordnete Datenlängefeld zeigt die Länge der Daten, die dem Paket folgen (wenn es welche gibt), an. Die Datenlänge ist bevorzugterweise in Doppelworten angegeben, die derart kodiert sind, dass die Anzahl von dargestellten Doppelworten 1 plus diese Anzahl ist. Somit stellt „000000" ein Doppelwort dar.
Das bei den Bits 7 bis 4 des ersten Doppelworts angeordnete Letztes-Doppelwert-Byte-Freigabe-Feld (Last bzw. Letztes DW BE) zeigt die Byte-Freigaben für das letzte Doppelwort von Daten irgendeiner Lese- oder Schreibanfrage an. Die Byte-Freigaben sind aktiv-niedrig („0"). Wenn es nur ein Doppelwort von Daten für eine Anfrage gibt, muss dieses Feld inaktiv sein („1111"). Die Byte-Freigaben können diskontinuierlich sein (z.B. „0101 "). Die Byte-Freigaben sind für Spezial-Zyklen nicht bedeutsam und daher überlappt das Last DW BE das Spezial-Zyklus-Einschluss-Feld.
Das bei den Bits 3 bis 0 des ersten Doppelworts angeordnete Erstes-Doppelwort-Byte-Freigabe-Feld (1st bzw. Erstes DW BE) zeigt die Byte-Freigaben für das erste Doppelwort von Daten von irgendeiner Lese- oder Schreib-Anfrage zum Speicher, I/O oder Konfigurationsräumen an. Die Byte-Freigaben sind aktiv-niedrig („0"). Wenn es nur ein Doppelwort von Daten für eine Anfrage gibt, sollte dieses Feld bevorzugt verwendet werden. Die Byte-Freigaben können diskontinuierlich sein (z.B. „0101 "). Byte-Freigaben sind für Spezial-Zyklen nicht bedeutsam und daher überlappen die Erstes- und Letztes DW BE-Felder das Spezial-Zyklus-Kodier-Feld.
Das bei den Bits 7 bis 0 des ersten Doppelworts angeordnete Spezial-Zyklus-Kodier-Feld kodiert einen Spezial-Zyklus-Typ. Dieses Feld überlappt die Erstes- und Letztes-Doppelwert-Byte-Freigabe-Felder.
Das bei den Bits 31 bis 2 des zweiten Doppelworts angeordnete Adress[31:2]-Feld zeigt die gesamte Adresse für eine explizite 32-Bit-Adressierungsart an und erzeugt den unteren Teil einer Adresse für eine explizite 64-Bit-Adressierungsart.
Das bei einem Bit 0 des zweiten Doppelworts angeordnete Erweiterte-Adressfeld (ea) zeigt eine 32-Bit-Adressierung („0") oder eine 64-Bit-Adressierung („1") an. Dieses Feld ist nur für den Speicher oder nur für Spezial-Zyklus-Anforderungen gültig. Dieses Feld überlappt das Konfigurations-Typ(ct)-Feld.
Das bei einem Bit 0 des zweiten Doppelworts angeordnete CT-Feld ist nur für Konfigurationszyklen gültig. Dieses Feld zeigt einen Konfigurationszyklus vom Typ „0" an, wenn es auf „0" gesetzt ist, und zeigt einen Konfigurationszyklus vom Typ „1" an, wenn es auf „1" gesetzt ist. Diese Typen von Konfigurationszyklen entsprechen Arten von PCI-Konfigurationszyklen.
5 veranschaulicht eine Anfrage-Paket-Kopfzeile 500 einschließlich einer 64-Bit Adressierungsart. Die Felder für die Paket-Kopfzeile 500 sind identisch den in 4 gezeigten Feldern mit dem Zusatz eines Adress-[63:32]-Felds. Das Adress-[63:32]-Feld enthält die oberen Adressbits für die 64-Bit-Adressierungsart. Für diese Art ist das ea-Feld auf „1" gesetzt, das Adress[63:32]-Feld ist nur für die 64-Bit-Adressierungsart enthalten.
6 veranschaulicht eine Anfrage-Paket-Kopfzeile 600 einschließlich einer impliziten Adressierungsart. Die Felder für die Paket-Kopfzeile 600 sind identisch dem in 5 gezeigten Feld mit der Ausnahme des Fehlens des zweiten Doppelworts. Die implizite Adressierungsart wird bevorzugte auf Spezial-Zyklen angewendet, die keine Adresse enthalten. Die implizite Adressierungsart kann auch für Situationen verwendet werden, in denen die Adresse durch den Kontext nicht betroffen ist. Wenn die implizite Art verwendet wird, wird für das Anfrage-Paket keine Adresse gesendet. Das af-Feld wird für die implizite Adressierungsart auf „0" gesetzt.
7 veranschaulicht eine Beendigungs-Paktet-Kopfzeile 700. Die zahlreichen Felder sind identisch den in Verbindung mit 6 gezeigten, mit der Ausnahme der Abwesenheit des Beendigung-erforderlich-Felds, des Adress-Format-Felds und des Raum-Felds. Das Byte-Freigabe-Feld und das Spezial-Zyklus-Feld sind durch ein Beendigungs-Zustand-Feld ersetzt. Das Beendigungs-Zustand-Feld wird bevorzugt mit einem Wert vom Beendigungszustand und der in 8 veranschaulichten Kodiertabelle geladen.
9 veranschaulicht, wie die herkömmliche Lese-Anfrage- und die Lese-Rückgabe-Paket-Kommunikation funktioniert. Wie aus 9 zu ersehen, wenn die Anfrage-Kopfzeile 910 einmal an einen Hub-Agenten gesendet ist, gibt es eine Durchlaufzeit von zumindest einem Takt, bevor die Leserückgabe erteilt wird. Das Leserückgabe-Paket umfasst eine Leserückgabe-Kopfzeile 920 und Daten in 64-Byte-Paketen. Jede Anfrage-Kopfzeile 910 enthält die Startadresse und die Menge angefragter Daten zwischen anderen Informationen. Für Anfragen größer als 64 Byte Daten wird die Leserückgabe in Pakete mit nicht mehr als 64 Byte Daten pro Paket gebrochen, die jedes an eine separate Rückgabe-Kopfzeile 920 gebunden sind. Die 64 Byte Daten 930 umfassen vier 16-Byte Abschnitte, wobei ein Abschnitt einen Taktzyklus darstellt. Die herkömmliche Übertragung einer Leseanfrage, der Leserückgabe und des anfänglichen Senden des Pakets ergibt einen Überhang von einem Basistakt für die Leseanfrage und einem Basistakt für eine Durchlaufzeit und einem Basistakt pro jedem Leserückgabe-Paket, da die Leserückgabe-Kopfzeile mit jedem Paket verbunden ist. Es kann aufgrund der Latenz der Verarbeitung der Leseanfrage am Ziel auch eine Verzögerung zwischen der Leseanfrage und dem Beginn der Leserückgabe geben. Wenn beispielsweise ein Paket eine Größe von 64 Byte besitzt, wird eine große Leserückgabe, wie beispielsweise 512 Byte, aufgrund jeder mit den Paketen verbundenen Rückgabe-Kopfzeile zumindest drei zusätzliche Takte Überhang besitzen. Somit wird die insgesamt mögliche Bandbreite durch den pro Leserückgabe-Paket (jedes mit einer Leserückgabe-Kopfzeile) verteilten Überhang verringert.
Da der Durchlauf-Überhang für Lesevorgänge unvermeidbar ist, wenn die maximale Leseanfragegröße erhöht wird, wird ein Überhang verringert, aber eine Latenz erhöht. Wenn kleinere Anfrage-Pakete verwendet werden, wird eine Latenz verringert, jedoch wird ein Überhang aufgrund jeder Leserückgabe-Kopfzeile erhöht. Es ist zu beachten, dass eine Bandbreite eine Funktion von Leseanfragegröße und Datenrückgabe-Paketgröße ist. In einem Ausführungsbeispiel der Erfindung werden Datenpakete von der Quelle auf den Hublink ohne Pufferung gestreamt (außer es ist nicht möglich, die Hublink-Erteilung zu bekommen). Eine Komplikation dieses Ausführungsbeispiels der Erfindung besteht darin, dass nicht alle Daten zu dem Zeitpunkt verfügbar sind, zu dem eine Anfrage initiiert wird. Wenn alle angefragten Daten vor einem Initiieren einer Antwort angehäuft werden, wird Latenz hinzugefügt. Um die Latenz zu vermeiden, werden Pakete gebildet, die übertragen werden können, sobald Daten verfügbar werden. In diesem Szenario kann die Latenz verringert werden, aber ein Überhang wird erhöht, wodurch die maximale Bandbreite verringert wird.
In einem Ausführungsbeispiel der Erfindung enthalten eine Datenpfad-I/O-Einheit 135 und eine Datenpfad-I/O-Einheit 165 einen Mechanismus zum Daten-Streamen, der ein Streamen von Leserückgabe-Daten über einen Hublink strukturiert. Es sollte beachtet werden, dass eine Datenpfad-I/O-Einheit 135 und eine Datenpfad-I/O-Einheit 165 in einem Chipsatz enthalten oder in einer separaten Schaltungseinrichtung gehalten sein können. 10 veranschaulicht ein Ausführungsbeispiel der Erfindung, das ein Streamen von Leserückgabe-Daten über einen Hublink strukturiert. In diesem Ausführungsbeispiel der Erfindung wird ein Rückgabe-Kopfzeilen-Überhang durch Streamen von Datenpaketen 1040 antiparallel bzw. back-to-back bzw. verkettet ohne Anhängen einer Rückgabe-Kopfzeile an jeden Datenblock verringert, im Gegensatz zum herkömmlichen Ansatz, der eine Leserückgabe-Kopfzeile an jedes Paket anhängt.
Anstelle eines Festlegers der Leserückgabe-Paketgröße (z.B. 64-Byte-Pakete) erlaubt ein Ausführungsbeispiel der Erfindung Pakete mit variabler Länge. Wenn die nächsten Daten für denselben Stream ankommen, bevor das Ende des vorhergehenden Datenpakets aus dem Hublink gesendet ist, setzt ein Ausführungsbeispiel der Erfindung das vorhergehende Paket ohne eine Unterbrechung, d.h. ohne eine Kopfzeile fort. Daher ist keine Pufferung erforderlich, um mehr Daten zu bekommen. Da jede Rückgabe-Kopfzeile einen Grundtakt Überhang verwendet, können Daten in einer minimalen Anzahl von großen Paketen zurückgegeben werden, wodurch die Anzahl von Beendigungs-Kopfzeilen minimiert wird.
In vielen Beispielen kann die gesamte Leserückgabe in einem einzelnen Paket mit nur einer Beendigungs-Kopfzeile übertragen werden. Ein Daten-Streamen beseitigt auch die mit der Ziel-Pufferung von Leserückgabe-Daten verbundene Latenzerhöhung, um ein ausreichend großes Hublink-Paket zu bilden, um den Beendigungs-Kopfzeilen-Überhang zufriedenstellend zu amortisieren. Beispielsweise könnte es drei zusätzliche Grundtakte kosten, drei zusätzliche 64-Byte-Cache-Zeilen zu sammeln, um ein 256-Byte-Leserückgabe-Paket mit maximaler Größe zu bilden.
Ein Daten-Streamen kann jedoch ein Problem von Datenerschöpfung darstellen. Dies kann auftreten, da das Ziel ein Leserückgabe-Paket initiieren kann und in der Tat auch soll, bevor alle Daten an der Hublink-Einheit, z.B. vom Speicher, angekommen sind. In diesem Fall ist es möglich, dass die nächsten Rückgabedaten nicht durch die „Just-in-time"-Deadline ankommen, um dem Schwanz der vorhergehenden Daten rechts aus dem Hublink zu folgen.
In einigen Ausführungsbeispielen der Erfindung enthalten eine Datenpfad-I/O-Einheit 135 und eine Datenpfad-I/O-Einheit 165 eine Einrichtung zur Paket-Aufteilung über einen Hublink. In diesen Ausführungsbeispielen der Erfindung löst die Paket-Aufteilung den Fall einer Datenerschöpfung. In diesen Ausführungsbeispielen der Erfindung wird, wenn eine Datenerschöpfung auftritt, das Datenpaket vorzeitig an dem Punkt, an dem die Datenauslieferungs-Deadline verletzt ist, beendet. Bei einer Ankunft weiterer Daten wird ein anderes Paket (ein „Nachfolge"-Paket) gebildet, um die Originalübertragung am Aufteilungspunkt fortzusetzen. Dieselbe Paket-Aufteilungstechnik kann auch verwendet werden, um eine Leserückgabe in der Mitte eines Leserückgabe-Pakets zu entziehen.
Ein Paket wird aufgeteilt, wenn der Sender des Pakets seine Anfrage vor einer Übertragung des letzten Grundtakes dieses Pakets nicht bestätigt, wie durch die Anfragelänge in der Paket-Kopfzeile angezeigt, oder, wenn ein Flußsteuerungs-Ereignis auftritt, das zu diesem Paket gehört. Eine Paket-Aufteilung kann aus den folgenden Gründen auftreten. Der erste Grund ist eine Datenerschöpfung. In diesem Fall hat der Sender keine weiteren Daten sofort für das Paket verfügbar. Der zweite Fall ist eine Bevorrechtigung. In diesem Fall signalisiert der Empfangs-Agent dem Sender einen Wunsch zu bevorrechtigen, woraufhin der Sender seine Anfrage freiwillig zurückzieht. Der Sender kann entweder durch Abtasten des Bevorrechtigungssignals (PMPT) gefordert werden, oder, wenn der PMPT-Mechanismus nicht unterstützt wird, dann durch ein „Gentlemen-Agreement", dass der Sender seine Anfrage freiwillig zurückzieht, wenn er die entgegensetzte Agentenanforderung abtastet, die bestätigt ist. Der letztere Mechanismus ist optional und dem Nutzer überlassen. Drittens, wenn ein „Stop" während einer Datenübertragung bestätigt ist, kann der Sender optional das Paket aufteilen. Normalerweise behält der Sender seine Anfrage bei und gibt die „gestoppten"-Daten ohne Bilden eines neuen Pakets aus, jedoch kann der Sender auswählen, seine Anfrage freizugeben und zu einem anderen Zeitpunkt wieder zu vermitteln, an dem der Sender ein neues Paket mit den verbleibenden der „gestoppten" Daten bilden wird. Daher kann eine Leseanfrage beibehalten werden, wenn ein "Stop"-Befehl erteilt wird. In einem Ausführungsbeispiel der Erfindung tritt, wenn die Leseanfrage bestätigt wird, eine Paket-Aufteilung auf.
In einigen Ausführungsbeispielen der Erfindung wird im Fall einer Paket-Aufteilung die Kopfzeile die Menge von verbleibenden zu übertragenden Daten vom Original-Paket beibehalten. Es ist zu beachten, dass in einem anderen Ausführungsbeispiel der Erfindung eine Daten-Aufteilung dynamisch auftritt. Somit werden in dem Fall, in dem Daten-Pakete nicht aufgeteilt werden können, große Daten-Pakete von einer einzelnen Kopfzeile begleitet. In dem Fall, in dem die Pakete dynamisch aufgeteilt werden, hält bei Wiederaufnahme der Daten-Paket-Übertragung die mit dem wiederaufgenommenen Daten-Paket verbundene Kopfzeile eine Spur der Menge von zu übertragen verbleibenden Daten basierend darauf, was bereits übertragen wurde. Daher ist in dem Original-Paket die Gesamtmenge von zurückzugebenden Daten in der Kopfzeile enthalten.
11 veranschaulicht ein Beispiel für ein Signaldiagramm für einige Ausführungsbeispiele der Erfindung. Eine Kopfzeile 1110 (H1) ist die Kopfzeile für eine erste Anfrage (Anfrage 1). Eine Kopfzeile 1120 (H1c) ist eine Kopfzeile des Fortsetzungs-Pakets 1. REQ ist ein Anfragesignal, das bestätigt/nicht bestätigt ist. CLK 1140 sind zahlreiche Take für ein Signal 1100. Wie in 11 veranschaulicht, ist das Signaldiagramm ein Beispiel für ein Lese-Streamen mit einer Paket-Aufteilung aufgrund von Datenerschöpfung. Es ist ersichtlich, dass der Leserückgabe (pckt 1) für eine erste Anfrage bei einem Takt X-2 die Daten ausgehen. Ein Agent bestätigt sein REQ-Signal bei Datenerschöpfung nicht. Bei einem Takt X-1 (oder irgendeinem Takt > X-1) hat der Agent genug Daten gesammelt, um ein Streamen fortzusetzen und bestätigt sein REQ-Signal. In diesem Beispielfall erlangt der Agent Kontrolle über die Schnittstelle beim Takt X und nimmt ein Senden der Rückgabedaten bei einem Takt X+1 für die erste Leseanfrage wieder auf. Die Kopfzeile H1c enthält die Adresse für Daten Dn+1 und die Länge der verbleibenden Daten in der Leserückgabe an dem Punkt, an dem eine Datenerschöpfung aufgetreten ist (X-2).
12 veranschaulicht Signaldiagramme für einige Ausführungsbeispiele der Erfindung für eine Fortsetzung eines Streamens nach einem einer Datenerschöpfung folgenden „Stop"-Flusssteuerungsbefehl. Optionen 1210, 1220 und 1230 sind für ein weiteres Verständnis Anwendungen einiger Ausführungsbeispiele für ein Leserückgabe-Streamen dargestellt. Im Signaldiagramm 1200 bestätigt ein Ziel sein REQ-Signal aufgrund von Datenerschöpfung nicht. Zwei Takte später sendet das Ziel eine neue Beendigungs-Kopfzeile, um ein Senden seines Leserückgabe-Pakets wieder aufzunehmen, und dann wird in den folgenden Takten ein STOP-Signal bestätigt.
Bei einem Takt X steuert das Ziel eine Kopfzeile H1C für das Fortsetzungs-Leserückgabe-Paket an. Bei einem Takt X+1 bestätigt das Ziel ein STOP-Signal, das anzeigt, dass der Anfrager die Daten Dn zurückgegeben hat. Die folgenden Optionen beziehen sich darauf, wie das Ziel auf das STOP antworten kann. In einem eine Option 1 1210 anwendenden Ausführungsbeispiel, kann ein Neustart bei einem Takt X+2 mit einer Kopfzeile H1* und Nutzlastdaten Dn, Dn+1, Dn+2, ... auftreten. Die Kopfzeile H1* ist die Kopfzeile H1c mit der Adresse, die modifiziert ist, an der Adresse von Dn zu beginnen, und eine um die Länge von Dn vergrößerte Größe aufweist. In diesem Ausführungsbeispiel wird ein Leserückgabe-Streamen beibehalten.
In einem eine Option 2 verwirklichenden Ausführungsbeispiel 1220 kann ein Neustart bei X+2 mit einer Kopfzeile H1* und Nutzlastdaten Dn auftreten. Die Kopfzeile H1* ist eine Kopfzeile H1 mit einer modifizierten Adresse beginnend bei Dn, und mit der auf die Länge von Dn modifizierten Länge. Sofort folgend auf Dn beginnt das Streamen mit der Kopfzeile H1c wieder, gerade wie es das Ziel war, es beim Takt X zu tun. In diesem Ausführungsbeispiel wird ein Streamen bis nach einer Kopfzeile H1c nicht wieder begonnen.
In einem eine Option 3 verwirklichenden Ausführungsbeispiel 1230 kann ein Neustart bei X+2 mit einer Kopfzeile H1* und Nutzlastdaten Dn auftreten. In diesem Ausführungsbeispiel ist eine Kopfzeile H1* eine mit einer Adresse beginnend bei der Adresse von Dn modifzierte Kopfzeile H1 und einer auf die Länge von Dn modifizierten Größe. Nach zwei Leerlauf-Taktzyklen (die zwei Takten zwischen freigebendem Daten-Streamen und Wiedergewinnen einer Daten-Streamens bei X entsprechen) wird mit einer Kopfzeile H1c, gerade, wenn das Ziel am Takt X versucht, wieder begonnen. Somit werden Leserückgabe-Daten nicht von X+4 bis X+6 gestreamt und nicht wieder begonnen, bis nach der Kopfzeile H1c. Dieses Ausführungsbeispiel erlaubt eine einfache Realisierung, da es keine Notwendigkeit gibt, aufzuzeichnen, dass das bestätigte STOP-Signal bei X+4 und X+5 nicht relevant ist.
13 veranschaulicht ein Ausführungsbeispiel der Erfindung mit einem dynamisch aufgeteilten Daten-Paket. Wie in 13 veranschaulicht, wird eine Rückgabe-Kopfzeile 1310 durch ein Daten-Paket einer beispielhaften Menge von 64 Byte gefolgt. Eine Leserückgabe-Kopfzeile 1310 enthält die Größe von zurückzugebenden Daten (in diesem Beispiel 1 kByte). In einigen Ausführungsbeispielen der Erfindung darf die Leserückgabe-Kopfzeile 1310 hinsichtlich der zurückzugebenden Datengröße „lügen". In diesem Ausführungsbeispielen der Erfindung ist die in der Rückgabe-Kopfzeile bestimmte Größe die Anzahl von zurückzugebenden Daten, während in der Realität dass Paket weniger als die bestimmte Größe enthalten kann. In diesen Ausführungsbeispielen der Erfindung bestätigt ein Ziel ein Anforderungssignal (in 11 veranschaulicht) nicht bevor ein Streaming-Paket eine Übertragung beendet hat. Ein Agent sendet dann den verbleibenden Teil der angefragten Daten in nachfolgenden Paketen. Der Agent kann ein Antwort-Paket senden, bevor der Agent alle angefragten Daten empfangen hat. Dies erlaubt eine Verringerung der Latenz, indem nicht auf ein Sammeln aller angefragten Daten durch den Agenten gewartet werden muss, bevor der Agent die Antwort sendet.
Block 1330 veranschaulicht einen Überhang-Takt-Leerlaufzeit-Abschnitt. Eine Rückgabe-Kopfzeile 1340 enthält die Menge von zum Übertragen verbleibenden Daten. In dem in 13 veranschaulichten Beispiel würde dies die in der Rückgabe-Kopfzeile 1310 erhaltene Menge minus die der Rückgabe-Kopfzeile 1310 folgenden Daten sein, die als 1320 bezeichnet sind (in diesem Beispiel 64-Byte). Es ist zu beachten, dass das der Rückgabe-Kopfzeile 1340 folgende Daten-Paket eine große Paketgröße sein kann, die von einem Daten-Streamen profitiert.
14 veranschaulicht ein Blockschaltbild eines Ausführungsbeispiels der Erfindung. Ein Vorgang 1400 beginnt mit dem Block 1405, der eine Leseanfrage an das Leseziel sendet. Das Leseziel empfängt die Leseanfrage im Block 1440. Der Vorgang 1400 setzt sich mit einem Block 1445 fort, der eine minimale Menge von Daten vor einer Initiierung einer Leserückgabe erreicht. Ein Block 1450 vermittelt den Hublink. Ein Block 1455 bildet ein Paket. Ein Block 1460 sendet eine Kopfzeile. Ein Block 1465 überträgt die angefragten Daten.
Ein Block 1470 bestimmt, ob die Leseanfrage erfüllt ist oder nicht. Wenn die Leseanfrage erfüllt ist, dann erfolgt der Leseziel-Vorgang. Wenn die Leseanfrage nicht erfüllt ist, setzt sich der Vorgang 1400 jedoch mit einem Block 1475 fort. Der Block 1475 bestimmt, ob die nächste Menge von angefragten Daten zum Übertragen verfügbar ist. Wenn der Block 1475 bestimmt, dass die nächste Menge von angefragten Daten zum Übertragenwerden verfügbar ist, setzt sich der Vorgang 1400 mit einem Block 1465 fort. Wem der Block 1475 bestimmt, dass die nächste Menge von angefragten Daten nicht zum Übertragenwerden verfüg bar ist, bestätigt der Vorgang 1400 das Anforderungssignal in Block 1485 nicht und setzt sich mit Block 1445 fort.
Der Lese-Initiator empfängt die von Block 1460 übertragene Kopfzeile beim Block 1410. Der Vorgang 1400 setzt sich mit einem Block 1415 fort, in dem der Lese-Initiator vorbereitet, die Menge von in der vorhergehend empfangenen Kopfzeile bestimmten Daten zu empfangen. Ein Block 1420 empfängt das Daten-Paket. Ein Block 1425 bestimmt, ob alle in der Paket-Kopfzeile bestimmten Daten empfangen wurden oder nicht. Wenn der Block 1425 bestimmt, dass alle in der Paket-Kopfzeile bestimmten Daten empfangen wurden, setzt sich der Vorgang 1400 mit einem Block 1426 fort. Wenn der Initiator alle angefragten Daten empfangen hat, endet der Vorgang 1400 mit einem Block 1427. Wenn der Intiator nicht alle angefragten Daten empfing, setzt sich der Vorgang mit einem Block 1490 fort. Wenn der Block 1425 bestimmt, dass nicht alle in der Paket-Kopfzeile bestimmten Daten empfangen wurden, setzt sich der Vorgang 1400 in einem Block 1430 fort.
Der Block 1430 bestimmt, ob ein Anfragesignal vor dem Ende der bestimmten Datengröße bestätigt wurde. Wenn der Block 1430 bestimmt, das das Anforderungssignal vor dem Ende der bestimmten Datengröße nicht bestätigt wurde, setzt sich der Vorgang 1400 mit einem Block 1490 fort. Wenn der Block 1430 bestimmt, dass das Anfragesignal nicht vor dem Ende der bestimmten Datengröße nicht bestätigt wurde, setzt sich der Vorgang 1400 mit einem Block 1420 fort.
In einigen Ausführungsbeispielen der Erfindung enthält der Vorgang 1400 eine dynamische Paket-Aufteilung. In diesen Ausführungsbeispielen der Erfindung wird, wenn das Anforderungssignal des Ziels nicht bestätigt wurde, bevor ein Streaming-Paket vollständig empfangen wurde, ein neues Paket einschließlich einer Kopfzeile und eines Datenteils gebildet. Die Kopfzeile enthält die Größe der vom Original-Streaming-Paket zum Übertragen verbleibenden Daten. In einigen Fällen kann das Aufteilungs-Paket einen Datenteil mit fester Länge (z.B. 64 Byte) enthalten. In anderen Fällen kann das Aufteilungs-Paket ein Streaming-Paket mit dem die verbleibenden zu übertragenden Daten enthaltenden Datenteil sein.
Neben einer Einbringung in einen Chipsatz, wie beispielsweise einem Einschließen in eine Datenpfad-I/O-Einheit 135 und eine Datenpfad-I/O-Einheit 165, können die vorstehenden Ausführungsbeispiele auch in einer Einrichtung oder einem maschinenlesbaren Medium gespeichert werden und durch eine Maschine zur Durchführung von Anweisungen gelesen werden. Das maschinenlesbare Medium enthält irgendeinen Mechanismus, der Informationen in einer durch eine Maschine (z.B. einen Computer) lesbaren Form zur Verfügung stellt (d.h. speichert und/oder überträgt). Beispielsweise enthält ein maschinenlesbares Medium eine Nur-Lese-Speicher (ROM), einen Direkt-Zugriffs-Speicher (RAM), ein magnetisches Plattenspeichermedium, optische Speichermedia, Flashspeichereinrichtungen, elektrische, optische, akustische oder eine andere Form von ausgebreiteten Signalen (z.B. Trägerwellen, Infrarotsignale, digitale Signale, usw.). Die Einrichtung oder das maschinenlesbare Medium kann eine Festspeichereinrichtung und/oder eine drehende magnetische oder optische Platte enthalten. Die Vorrichtung oder das maschinenlesbare Medium kann verteilt werden, wenn Partitionen von Anweisungen in verschiedene Maschinen aufgeteilt wurden, wie beispielsweise über eine Zwischenverbindung von Computern.
Während bestimmte beispielhafte Ausführungsbeispiele beschrieben wurden und in der beigefügten Zeichnung gezeigt sind, ist es verständlich, dass derartige Ausführungsbeispiele nur veranschaulichend und nicht einschränkend auf die breite Erfindung sind, und, dass diese Erfindung nicht auf die gezeigten und beschriebenen bestimmten Aufbauten und Anordnungen beschränkt ist, da zahlreiche anderen Modifikationen für den Fachmann auftreten können.

Claims

Vorrichtung, welche umfaßt: einen ersten Hub (104); einen Bus (102), welcher mit dem ersten Hub (104) verbunden ist; und einen zweiten Hub (106), welcher mit dem Bus (102) verbunden ist, dadurch gekennzeichnet, daß der erste Hub (104) Streaming-Pakete bildet und überträgt, welche eine Paketkopfzeile umfassen, wobei die Streaming-Pakete aufgeteilt sind, wobei ein aufgeteiltes Paket einen Kopfzeilenabschnitt und einen Datenabschnitt umfaßt, wobei ein Aufteilen der Streaming-Pakete dynamisch ist und wobei der Kopfzeilenabschitt die restliche Größe der verbleibenden zu übertragenden Daten umfaßt und wobei eine Größe eines Datenpakets, welches mit dem Kopfzeilenabschnitt verbunden ist, sich in der Größe von der in dem Kopfzeilenabschnitt angezeigten Größe unterscheiden kann.
Vorrichtung nach Anspruch 1, wobei der Bus (102) ein Hublink ist.
Vorrichtung nach Anspruch 1, welche des weiteren umfaßt: einen Prozessor (108), welcher mit dem ersten Hub verbunden ist; einen Speicher (110), welcher mit dem Prozessor (108) verbunden ist; mehrere Peripheriekomponenten (124, 122, 118, 120), welche mit dem zweiten Hub (106) verbunden sind.
Vorrichtung nach Anspruch 3, wobei der Bus (102) ein Hublink ist.
Verfahren, welches umfaßt: Übertragen (1405) einer ersten Anfrage; Empfangen (1440) der ersten Anfrage; Bilden (1455) eines Streaming-Paketes; Übertragen (1460, 1465) des Streaming-Paketes; Empfangen (1410, 1420) des Streaming-Paketes; gekennzeichnet durch ein Aufteilen eines Streaming-Paketes in ein kleineres Paket, wenn eine Anfrage aufgehoben wird, wobei jedes aufgeteilte Streaming Paket einen Kopfzeilenabschnitt und einen Datenabschnitt umfaßt, und wobei der Kopfzeilenabschnitt eine restliche Größe von verbleibenden zu übertragenden Daten des Originalpakets umfaßt.
Verfahren nach Anspruch 5, wobei das Aufteilen der Streaming-Pakete dynamisch ist.
Verfahren nach Anspruch 5, welches des weiteren umfaßt: Entfernen eines Leseanfragesignals bevor die gesamten angefragten Daten empfangen sind; Senden nachfolgender Pakete, nachdem das Anfragesignal entfernt worden ist, wobei die nachfolgenden Pakete die restlichen angefragten Daten umfassen; und Senden eines Antwortpaketes bevor die gesamten angefragten Daten empfangen sind.
Vorrichtung, welche ein maschinenlesbares Medium umfaßt, in dem Anweisungen enthalten sind, welche, wenn sie durch eine Maschine ausgeführt werden, bewirken, daß die Maschine das Verfahren nach Anspruch 5 durchführt.