-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft das Gebiet der Datenkommunikation
in einem digitalen System. Insbesondere betrifft die vorliegende
Erfindung Verfahren oder Protokolle zum Übertragen von Informationen
auf einem Bus.
-
Hintergrund der Erfindung
-
Ein
Computer oder eine ähnliche
Vorrichtung weist in der Regel einen Bus auf, der Geräte mit dem Rechensystem
verbindet. Aufgrund verschiedener Fortschritte bei Rechensystemen
und Geräten
(zum Beispiel in der Rechenleistung) hat sich die Menge an Daten,
die zwischen einem Rechensystem und den an dieses angeschlossenen
Geräten übertragen
werden kann, erhöht,
wodurch auch eine gleichzeitige Erhöhung der Bandbreite des Busses
notwendig wurde. Dieser erhöhte
Bedarf an Bandbreite ist zum Teil durch Multimedia-Anwendungen verursacht,
die das Übertragen
von Daten in regelmäßigen Zeitintervallen
(isochron) über den
Bus entweder vom Gerät
an das Rechensystem (in) oder in der entgegengesetzten Richtung
(out) erfordern. Beispiele für
Geräte,
die in erheblichem Umfange Bandbreite benötigen, sind unter anderem Kameras, Compact-Disc-Spieler,
Lautsprecher, Mikrophone, Videoanzeigegeräte, Scanner, Joysticks und
Mäuse.
Die in einer Busarchitektur zur Verfügung stehende Bandbreite wird
teilweise von drei Faktoren bestimmt: dem Übertragungsmedium, der Topologie
und dem Protokoll, das den Zugang zum Medium steuert. Protokoll
und Topologie bestimmen teilweise die Art der Beziehung zwischen
einem Gerät
und einem Rechensystem. Eine mögliche
Beziehung ist eine Master-Slave-Beziehung.
Bei einer Master-Slave-Beziehung initiiert das Rechensystem in der
Regel alle Datentransaktionen zwischen dem Rechensystem und einem
Gerät,
das heißt,
das Gerät antwortet
nur auf Anforderungen vom Rechensystem, initiiert jedoch nie selbst
eine Transaktion. Ein Vorteil der Master-Slave-Beziehung ist eine einfache Busarchitektur
mit vergleichsweise niedrigen Kosten. Die „Universal Serial Bus (USB)
Specificati on",
Revision 1.1 vom 23. September 1998, ist ein Beispiel für eine verbreitete Busarchitektur,
die eine Master-Slave-Beziehung
zwischen durch den Bus miteinander verbundenen Elementen aufweist.
Leider haben viele heutige Geräte
und Rechensysteme Bandbreitenanforderungen (oder Datenraten), die
von existierenden Master-Slave-Busstandards wie dem USB-Standard
nicht unterstützt
werden können.
-
Obwohl
USB vergleichsweise hohe Datenraten nicht unterstützt, wird
es doch von einer vergleichsweise großen Zahl von Anwendern eingesetzt
und unterstützt
zwei Datenraten:
12 MBit/s („full speed” (volle
Geschwindigkeit)) und
1,5 MBit/s („low speed” (niedrige Geschwindigkeit)).
USB lässt
verschiedene Datenraten auf einem Bus zu, da einige Geräte keine
hohen Datenraten benötigen
und durch Nutzung von vergleichsweise kostengünstigen Treibern mit niedrigen
Datenraten und Kabeln bedeutende Kostenersparnisse erzielt werden
können.
-
Das
USB-Protokoll, welches es dem Rechensystem erlaubt, mit Geräten, die
eine niedrige Datenrate aufweisen, mit niedriger Geschwindigkeit
zu kommunizieren, und alternativ mit Geräten, die hohe Datenraten aufweisen,
mit voller Geschwindigkeit zu kommunizieren (Geschwindigkeitsumschaltung,
engl. „speed
shifting"), führt jedoch
dazu, dass die tatsächlich über den
Bus übertragene
Datenmenge (der effektive Durchsatz) kleiner ist, als dies durch
Beschränkung
des Busses auf Transaktionen mit voller Geschwindigkeit erreichbar wäre. Mit
anderen Worten: Geschwindigkeitsumschaltung führt dazu, dass Geräten mit
höheren
Geschwindigkeiten (zum Beispiel „full speed") weniger Bandbreite
zur Verfügung
steht, besonders wenn eine vergleichsweise große Anzahl an „low speed"-Geräten mit
dem Rechensystem verbunden sind. Die Auswirkungen der Geschwindigkeitsumschaltung
auf den Durchsatz werden noch verschlimmert, wenn das Verhältnis von
hoher Datenrate zu niedriger Datenrate vergleichsweise groß ist.
-
Ein
weiteres mögliches
Busprotokoll würde
erfordern, dass der Host 1. ein Datenpaket mit einer hohen Datenrate
an einen Hub übermittelt,
2. darauf wartet, dass der Hub das Paket mit einer niedrigen Datenrate
an den Agent weiterleitet, 3. darauf wartet, dass der Agent dem
Hub mit der niedrigen Datenrate antwortet, und 4. die Antwort des
Agents auf das Paket mit einer hohen Datenrate vom Hub empfängt. Wenn
das Verhältnis der
hohen Datenrate zur niedrigen Datenrate vergleichsweise groß ist, kann
dieses Busprotokoll ebenfalls zu einem niedrigen effektiven Durchsatz
oder einer niedrigen Bandbreite führen, weil darauf gewartet
werden muss, dass der Hub das Paket mit der niedrigen Datenrate
weiterleitet und dass der Agent mit der niedrigen Datenrate antwortet.
-
Eine
weitere verbreitete Bustechnologie wird mit dem IEEE-1994-Standard
für eine
serielle Hochgeschwindigkeitsanschlusstechnik (Institute of Electrical
and Electronics Engineers (IEEE) Standard 1394 for a High Performance
Serial Bus, 1995) („Firewire") definiert. IEEE
1394 unterstützt
mehrere Datenraten von bis zu 400 MBit/s. Während die gesamte Datenrate
bedeutend höher
als die von USB ist, setzt IEEE 1394 verlustreiche Geschwindigkeitsumschaltung
ein und ist eine vergleichsweise aufwendige Technologie.
-
Die
Leistung eines Busses kann von Geschwindigkeitsumschaltung, vom
Warten auf den Hub, während
dieser Transaktionen mit einer niedrigeren Datenrate als der Host-Datenrate durchführt, und
von dem Verhältnis
der Host-Datenrate
zur Agent-Datenrate bedeutend beeinflusst werden. Es ist daher ein
Protokoll wünschenswert,
das die Kommunikation mit den von heutigen bandbreitenintensiven
Systemen benötigten Datenraten
ermöglicht,
gleichzeitig eine Rückwärtskompatibilität mit bereits
existierenden Lösungen,
wie etwa USB, bietet und die Einbußen, die sich durch Geschwindigkeitsumschaltung
und die sonstigen Nachteile des Stands der Technik ergeben, nicht
aufweist.
-
Ein
Problem bei der Kommunikation von Systemen mit hoher Datenrate mit
Geräten
mit niedriger Datenrate ist oben beschrieben worden. Ein weiteres
Problem, welchem Rechensysteme gegenüberstehen, erwächst aus
der Vielzahl an verfügbaren
Busprotokollen oder -standards. In der Regel arbeitet ein für den Betrieb
gemäß einem
Busprotokoll hergestelltes Gerät
nicht mit einem anderen Busprotokoll. Es kann Verschwendung sein,
wenn Anwender nur aufgrund der unterschiedlichen Protokolle großenteils
Geräte
doppelt besitzen müssen.
Wo eine große
Basis an Geräten
mit erheblicher Restnutzungsdauer verwendet wird, kann es wünschenswert
sein, die Verwendung solcher Geräte
mit einem Rechensystem zu ermöglichen,
welches ein Protokoll aufweist, das eine Rückwärtskompatibilität mit dem
Protokoll der vorhandenen Geräte
bietet.
-
-
Kurzdarstellung der Erfindung
-
Gemäß der vorliegenden
Erfindung wird ein Verfahren zum Kommunizieren von Daten zwischen
einem Host und einer Mehrzahl von Agents gemäß Anspruch 1 geschaffen. Ebenfalls
gemäß der vorliegenden Erfindung
wird ein digitales System, das einen Host-Controller gemäß Anspruch
16 beinhaltet, geschaffen. Weiter wird gemäß der vorliegenden Erfindung
ein Hub-Controller gemäß Anspruch
24 geschaffen.
-
Kurzbeschreibung der Zeichnungen
-
Die
vorliegende Erfindung wird anhand der Figuren der beigefügten Zeichnungen,
in denen gleiche Bezugszeichen gleiche Elemente bezeichnen, beispielhaft
und nicht einschränkend
beschrieben. Es zeigen:
-
1a ein
Blockdiagramm eines digitalen Systems, das ein Protokoll gemäß der vorliegenden
Erfindung verwendet,
-
1b, 1c u. 1d jeweils
einen Prozess, der ein Verfahren gemäß dieser Erfindung für das Kommunizieren
zwischen einem Host-Controller und einem Hub zeigt,
-
1e einen
Hub gemäß der vorliegenden
Erfindung,
-
2a u. 2b Zustandsübergangsdiagramme
für einen
Host-Controller
bzw. einen Hub, die eine Übertragung
gemäß dieser
Erfindung durchführen,
-
3a u. 3b Zustandsübergangsdiagramme
für einen
Host-Controller
bzw. einen Hub, die eine andere Übertragung
gemäß dieser
Erfindung durchführen,
-
4a u. 4b Zustandsübergangsdiagramme
für einen
Host-Controller
bzw. einen Hub, die eine andere Übertragung
gemäß dieser
Erfindung durchführen,
-
5a u. 5b Zustandsübergangsdiagramme
für einen
Host-Controller
bzw. einen Hub, die eine andere Übertragung
gemäß dieser
Erfindung durchführen,
-
6a u. 6b Zustandsübergangsdiagramme
für einen
Host-Controller
bzw. einen Hub, die eine andere Übertragung
gemäß dieser
Erfindung durchführen,
-
7a u. 7b Zustandsübergangsdiagramme
für einen
Host-Controller
bzw. einen Hub, die eine andere Übertragung
gemäß dieser
Erfindung durchführen,
-
8a u. 8b Best-Case-
und Worst-Case-Frames für
Datenübertragungen
gemäß der vorliegenden
Erfindung und
-
9 Zeitverlaufsdiagramme
für Transaktionen
zwischen Host-Controller und Hub sowie zwischen Hub und Agent.
-
Detaillierte Beschreibung
-
Es
wird ein Verfahren und eine Vorrichtung für das Kommunizieren zwischen
einem Host und einem Peripheriegerät (Agent) beschrieben, wobei
der Agent mit einer anderen Geschwindigkeit und/oder einem anderen
Protokoll als der Host kommuniziert. In der folgenden Beschreibung
werden zum Zwecke der Erklärung zahlreiche
spezifische Details dargelegt, um ein tiefgehendes Verständnis der
vorliegenden Erfindung zu ermöglichen.
Für den
Fachmann ist es jedoch offensichtlich, dass die vorliegende Erfindung
in einer Vielfalt von Bussystemen, besonders in seriellen Bussen,
ohne diese spezifischen Details ausgeführt werden kann. In anderen
Fällen
werden allgemein bekannte Operationen, Schritte, Funktionen und
Anordnungen nicht gezeigt, um die Erfindung nicht zu verschleiern.
-
Teile
der Beschreibung verwenden Terminologie, die von Fachleuten verwendet
wird, um den Gegenstand ihrer Arbeit anderen Fachleuten zu vermitteln,
wie etwa Geräte-
oder Control lertreiber, Bus- oder Host-Controller, Hubs, Busagents
oder Agents und so weiter. Außerdem
werden Teile der Beschreibung in Form von Operationen präsentiert,
die durch das Ausführen
von Programmanweisungen oder durch das Ingangsetzen der Funktionalität einer
oder mehrerer elektrischer Komponenten oder Schaltkreise durchgeführt werden;
dabei werden Ausdrücke
wie „ausführen", „senden", „verarbeiten", „Packaging", „Zeitplanen", „übertragen", „konfigurieren" usw. verwendet.
Wie der Fachmann weiß,
nehmen diese Operationen die Form elektrischer, magnetischer oder
optischer Signale ein, die gespeichert, übertragen, kombiniert oder
auf andere Weise von elektrischen Komponenten manipuliert werden
können.
-
Verschiedene
Operationen werden als mehrere diskrete, nacheinander auszuführende Schritte
in einer Weise beschrieben, die für das Verständnis der vorliegenden Erfindung äußerst hilfreich
ist. Die Reihenfolge der Beschreibung darf jedoch nicht so ausgelegt
werden, als impliziere sie die Notwendigkeit, diese Operationen
in der dargestellten Reihenfolge durchzuführen, oder dass die Reihenfolge überhaupt
eine Rolle spiele. Schließlich
beziehen sich wiederholt gebrauchte Formulierungen wie „in einer
Ausführungsform", „eine alternative
Ausführungsform" oder „eine andere
Ausführungsform" nicht notwendigerweise
auf dieselbe Ausführungsform,
können
dies aber.
-
1a zeigt
ein Blockdiagramm eines Busses, der ein Protokoll gemäß der vorliegenden
Erfindung verwendet. Der Bus 100 weist ein System 102 mit
einem Host-Controller 110 auf, der an den Hub 120 gekoppelt
ist, welcher wiederum an den Agent 130 gekoppelt ist. Der
Host-Controller 110 hat einen zugehörigen Gerätetreiber 105, der
auf dem System 102 ausgeführt wird. Beispiele für Agents
sind unter anderem Kameras, Compact-Disc-Spieler, Lautsprecher,
Mikrophone, Videoanzeigegeräte,
Scanner, Joysticks und Mäuse.
Das System 102 kann jedes digitale System umfassen, das
zu digitaler Kommunikation befähigt
ist, insbesondere Laptopcomputer, Desktopcomputer, Server, Set-Top-Boxen,
Unterhaltungssysteme und Spielgeräte. Folglich kann diese Erfindung
mit einer Vielzahl digitaler Ge räte,
die digitale Kommunikation verwenden, praktiziert werden.
-
In 1a sind
zwei Pfeile 101a und 101b eingezeichnet, um einen
Bezugsrahmen für
die Kommunikationsrichtung zwischen Host, Hub und Agent zu schaffen.
Die Richtung vom Agent zum Hub und weiter zum Host wird als Upstream-Richtung
oder upstream (in) bezeichnet. Die Richtung vom Host zum Hub und
weiter zum Agent wird als Downstream-Richtung oder downstream (out)
bezeichnet.
-
Der
Host-Controllertreiber 105 ermöglicht Kommunikationen oder
Transaktionen auf dem Bus 100 (zum Beispiel für eine Anwendung,
die auf dem System 102 ausgeführt wird), indem Informationspakete,
die für
den Agent 130 bestimmt sind, verarbeitet und vom Controller 110 für die Übertragung
eingeplant werden. Der Host-Controller 110 sendet und empfängt über den
Hub 120 Daten zu und von Agent 130. Der Agent 130 kommuniziert
mit einer anderen oder geringeren Datenrate (Agentdatenrate) als
der Host-Controller 110 (Hostdatenrate). Obwohl nur ein
an den Hub 120 gekoppelter Agent gezeigt ist, ist es offensichtlich,
dass zusätzliche Agents
(nicht gezeigt) an den Hub 120 oder an andere Hubs (nicht
gezeigt) angeschlossen sein können.
Diese zusätzlichen
Agents können
mit der Hostdatenrate oder mit der Agentdatenrate kommunizieren.
Außerdem
ist der Agent 130 zwar an den Hub 120 gekoppelt
gezeigt, der Agent kann aber auch über mindestens einen konventionellen
Repeaterhub, der mit der Agentdatenrate arbeitet, an den Hub 120 gekoppelt
sein. Ein konventioneller Repeaterhub sendet Signale, die er an
seiner Upstream-Seite empfängt,
auf seinen Downstream-Ports weiter und umgekehrt. An den konventionellen
Repeaterhub können
wiederum ein oder mehrere Agents 130 angeschlossen sein.
-
Der
Host-Controller 110 und der Agent 130 stehen in
einer Master-Slave-Beziehung, was bedeutet, dass der Host in der
Regel alle Datentransaktionen zwischen dem Host und einem Agent
initiiert, das heißt, der
Agent antwortet nur auf Anforderungen vom Host, initiiert jedoch
nie selbst eine Transaktion. Der Hub 120 weist Teilstreckenpuffer
(nicht gezeigt) auf, die es dem Hub 120 ermöglichen,
vom Host-Controller 110 empfange ne, für den Agent 130 bestimmte
Downstream-Informationen temporär
zu speichern und vom Agent 130 empfangene, für den Host-Controller 110 bestimmte
Upstream-Informationen temporär
zu speichern.
-
Da
der Agent 130 und der Host-Controller 110 mit
verschiedenen Datenraten kommunizieren, ist es wünschenswert, den effektiven
Durchsatz auf dem Bus zu verbessern, indem ein Protokoll geschaffen
wird, das es dem Host-Controller 110 erlaubt, sowohl 1.
mit seiner höheren
Datenrate zu kommunizieren als auch 2. nicht auf die Antworten von
Agent 130 warten zu müssen,
bevor er eine andere Transaktion eingeht. Das Protokoll der vorliegenden
Erfindung erlaubt es dem Host-Controller 110, Nutzen aus
der Teilstreckencharakteristik von Hub 120 zu ziehen, um
mit seiner höheren
Datenrate kommunizieren zu können
und eine neue Transaktion einzugehen, anstatt auf eine Antwort von
Agent 130 zu warten, falls eine Antwort erforderlich ist. Das
Protokoll der vorliegenden Erfindung schafft außerdem Robustheit und Zuverlässigkeit
für Transaktionen, die
zwischen Controller 110 und Hub 120 durchgeführt werden.
Außerdem
schaffen der Host-Controller und/oder der Hub der vorliegenden Erfindung
einen erhöhten
effektiven Durchsatz auf dem Bus und eine erhöhte Reaktionsschnelligkeit
für andere
Agents (nicht gezeigt), die mit der Hostdatenrate kommunizieren
und mit dem Hub 120 oder anderen Hubs verbunden sind.
-
1b veranschaulicht
einen Prozess 150, der ein Verfahren gemäß dieser
Erfindung für
das Kommunizieren mit einem Agent, der eine niedrigere (oder andere)
Datenrate als der Host-Controller aufweist, zeigt. Der Agent kann
auch ein anderes Protokoll aufweisen als der Host-Controller. Der
Prozess 150 kann für die
Umsetzung einer Vielzahl von Informationsübertragungen zwischen Host-Controller 110 und
Agent 130 verwendet werden. Für das einfache Verständnis wird
der Prozess 150 nur im Hinblick auf eine Bulk-Out-Übertragung
beschrieben. Der Prozess 150 kann jedoch mit anderen nachstehend
beschriebenen Informationsübertragungen
benutzt werden. Bei einer Bulk-Out-Übertragung werden Daten vom
Host-Controller 110 über den
Hub 120 an den Agent 130 übertragen. Die Bulk-Out- Übertragung ist gemäß einer
Ausführungsform
dieser Erfindung als asynchroner Übertragungstyp definiert. Aus
dieser Definition kann jedoch nicht geschlossen werden, dass alle
Bulk- und/oder Out-Übertragungen
asynchron sein müssen.
-
Bei
Schritt 152 in Prozess 150 wird eine „Split
starten"-Transaktion durchgeführt. Die „Split
starten"-Transaktion
kommuniziert Downstream-Informationen vom Host-Controller 110 an
den Hub 120. Teile der Downstream-Informationen, die an
den Hub 120 kommuniziert werden, werden temporär im Hub 120 gepuffert. Die
Puffer im Hub 120 verhalten sich weitgehend nach dem FIFO-Prinzip
(„first
in, first out"),
und werden nachstehend detaillierter beschrieben. Einige Zeit, nachdem
die Downstream-Informationen gepuffert worden sind, führt Hub 120 eine
Hub-Agent-Transaktion (nicht gezeigt) mit Agent 130 durch,
die auf einigen der gepufferten Downstream-Informationen beruht. Das relative Timing
der Hub-Agent-Transaktion
braucht hier nicht beschrieben zu werden, da es für den Durchschnittsfachmann
ersichtlich ist, dass dieses ein Anwendungs- oder Implementierungsdetail
ist, für
das es viele Möglichkeiten
gibt. Die Hub-Agent-Transaktion kann dazu führen, dass Upstream-Informationen
im Hub 120 gepuffert werden. Einige Zeit, nachdem die Downstream-Informationen gepuffert
worden sind, wird bei Schritt 156 eine „Split beenden"-Transaktion durchgeführt. Die „Split beenden"-Transaktion kommuniziert
gepufferte Upstream-Informationen vom Hub 120 an den Host-Controller 110. Das
relative Timing der „Split
beenden”-Transaktion braucht
hier nicht beschrieben zu werden, da es für den Durchschnittsfachmann
ersichtlich ist, dass dieses ein Anwendungs- oder Implementierungsdetail
ist, für
das es viele Möglichkeiten
gibt.
-
Ein
Vorteil des Split-Transaktionsprotokolls ist, dass es dem Controller 110 erlaubt,
eine Kommunikation („Split
starten”-Transaktion)
mit Agent 130 zu initiieren, in Schritt 154 andere
Funktionen aufzunehmen oder eine andere Kommunikation mit einem
anderen Agent (mit niedriger oder hoher Datenrate) einzugehen und
dann zurückzukehren,
um die zuvor initiierte Kommunikation mit dem Agent mit niedriger
Datenrate zu vollen den. Durch das Kommunizieren unter Verwendung
von Split-Transaktionen
kommuniziert der Controller 110 mit hohen Datenraten ohne
Geschwindigkeitsumschaltung und muss nicht im Idle-Zustand die Kommunikation
des Hubs 120 mit dem Agent 130 abwarten. Die Zeit,
die sonst im Idle-Zustand verbracht worden wäre, kann für die Kommunikation mit einem
anderen Agent genutzt werden. In einer alternativen Ausführungsform gemäß der vorliegenden
Erfindung kann der Controller 110 mit einigen Agents Geschwindigkeitsumschaltung praktizieren,
während
mit anderen Agents die Kommunikation über Split-Transaktion durchgeführt wird.
-
Die
oben beschriebenen „Split
starten"- und „Split
beenden"-Transaktionen
(Split-Transaktionen) können
benutzt werden, um eine Vielzahl von Übertragungstypen (zum Beispiel
Lesen oder Schreiben) für
die Datenkommunikation zwischen Controller 110 und Agent 130 zu
implementieren. In einer Ausführungsform
dieser Erfindung sind vier Übertragungstypen
(oder Übertragungsanforderungen)
definiert: Bulk out/in, Control out/in, Interrupt, isochron. Es
dürfte
für den
Durchschnittsfachmann ersichtlich sein, dass der Schutzumfang dieser Erfindung
andere Ausführungsformen
mit weniger, mehr oder anderen Übertragungstypen
umfasst. Jeder der Übertragungstypen
bietet verschiedene Grade an Robustheit, Zuverlässigkeit, Synchronisation,
Asynchronizität
des Betriebs, Fehlererkennung und Korrektur des Kommunikationsflusses
sowie andere Charakteristiken, die für den Durchschnittsfachmann
offensichtlich sind. Bulk out/in bietet zum Beispiel umfangreiche
asynchrone Datenübertragungen
vom Controller 110 zum Agent 130 oder in der umgekehrten
Richtung. Control out/in bietet ebenfalls asynchrone Datenübertragung
vom Controller 110 zum Agent 130 oder in der umgekehrten Richtung,
jedoch bestehen die Daten in der Regel aus Steuerinformationen,
die zum Steuern des Betriebs von Elementen (zum Beispiel einem Bandlaufwerk)
im Agent 130 oder im System 100 benutzt werden.
Interrupt bietet eine periodische Datenübertragung vom Controller 110 zum
Agent 130 oder in der umgekehrten Richtung. Falls die Übertragung
erfolglos ist, kann der Controller 110 es in einer Ausführungsform
gemäß der vorliegenden
Erfindung erneut versuchen. Isochrone Übertragung bietet eine Datenübertragung
jeweils einmal nach einem vorherbestimmten Zeitintervall. Gemäß einer
Ausführungsform
der vorliegenden Erfindung kann die Übertragung zu jedem Zeitpunkt
innerhalb des Zeitintervalls stattfinden. Ist die Übertragung
erfolglos, wiederholt der Controller 110 die Übertragung
nicht. In einer alternativen Ausführungsform gemäß der vorliegenden
Erfindung können
bei der isochronen Übertragung
Wiederholungsübertragungen
vorgesehen sein.
-
Die
Split-Transaktionen können
eine Anzahl von Phasen umfassen, abhängig vom implementierten Übertragungstyp.
Jede der Split-Transaktionen kann bis zu drei Phasen umfassen: Token,
Data und Handshake. Abhängig
von der ausgeführten Übertragung
können
jedoch einige Transaktionen weniger Phasen umfassen. In einer Ausführungsform
der vorliegenden Erfindung können
Bulk und Control bei jeder ihrer jeweiligen Split-Transaktionen
die gleichen Phasen benutzen. Die Phasen für jeden der oben beschriebenen Übertragungstypen
werden in Tabelle 1 weiter unten gezeigt. Das Vorhandensein eines „X" in einer Zelle der
Tabelle bedeutet, dass die Split-Transaktion für den Übertragungstyp die Phase umfasst,
die über
der Spalte steht, in der die Zelle liegt. Während in dieser Ausführungsform
die Token- und Dataphasen für
jeden der Übertragungstypen
separat sind, können
die Token- und Dataphasen in alternativen Ausführungsformen kombiniert sein.
Es ist offensichtlich, dass in alternativen Ausführungsformen Übertragungstypen
weniger, mehr oder sogar andere als die in Tabelle 1 gezeigten Phasen
umfassen können,
ohne dass vom Schutzumfang der vorliegenden Erfindung abgewichen
wird. Tabelle 1
Übertragungstyp | „Split
starten"-Transaktion | „Split
beenden"-Transaktion |
Token | Data | Handshake | Token | Data | Handshake |
Bulk-Control
Out | X | X | X | X | | X |
Bulk-Control
In | X | | X | X | X | X |
Interrupt
Out | X | X | | X | | X |
Interrupt
In | X | | | X | X | |
Isochron
Out | X | X | | | | |
Isochron
In | X | | | X | X | |
-
1c erläutert detailliert
einen Prozess 160, der eine „Split starten"-Transaktion für eine Bulk-Out-Übertragung
gemäß einer
Ausführungsform
dieser Erfindung zeigt. In Schritt 162 wird ein Token-Paket,
das Hubidentifikationsinformationen, Agentidentifikationsinformationen
und Endpunktidentifikationsinformationen, den Übertragungstyp, einen Indikator
zum Angeben der Übertragungsrichtung
(in oder out) und eine Datenratenidentifikation aufweist, vom Host-Controller 110 an
den Hub 120 gesendet. Hubidentifikationsinformationen,
Agent- und Endpunktidentifikationsinformationen sowie Richtung werden
hier zusammen als Transaktionsadressierungsinformationen bezeichnet.
Die Agentidentifikationsinformationen identifizieren den einzelnen
Agent, mit dem der Host versucht zu kommunizieren. Die Endpunktidentifikationsinformationen
identifizieren einen bestimmten Abschnitt im Agent, mit dem der
Host versucht zu kommunizieren. Beispiele für Endpunkte sind: linker und
rechter Lautsprecher eines Lautsprecherhubs oder Lautsprecher und
Mikrophon eines Telefonhörers.
Der Übertragungstyp
in den Transaktionsadressierungsinformationen ist nicht auf die
hier beschriebenen Typen (zum Beispiel Bulk Out, Interrupt, isochron,
Control) beschränkt,
sondern kann andere auf dem Fachgebiet bekannte Typen einschließen, ohne
dass vom Schutzumfang dieser Erfindung abgewichen wird. Die Datenratenidentifikation
spezifiziert die Datenrate, mit der die im Zusammenhang mit Prozess 150 oben
beschriebene Hub-Agent-Transaktion durchgeführt wird. Für eine Ausführungsform, in der die Hub-Agent-Transaktion
gemäß dem USB-Standard
durchgeführt
wird, spezifiziert die Datenraten identifikation entweder 12 MBit/s
(volle Geschwindigkeit) oder 1,5 MBit/s (niedrige Geschwindigkeit).
In Schritt 164 wird ein Datenpaket vom Host-Controller 110 an
den Hub 120 gesendet. In Schritt 166 empfängt der
Host-Controller 110 eine erste Bestä tigung (engl. „acknowledgement", ACK) vom Hub 120,
wenn das Datenpaket vom Hub 120 ordnungsgemäß dekodiert
wurde. Die erste Bestätigung
zeigt an, ob die Daten ordnungsgemäß vom Hub 120 dekodiert
wurden oder ob der Hub 120 einen späteren Versuch wünscht (zum
Beispiel weil die Puffer von Hub 120 voll waren und dieser
deshalb die Daten nicht annehmen konnte).
-
1d erläutert detailliert
einen Prozess 170, der eine „Split beenden"-Transaktion für eine Bulk-Out-Übertragung
gemäß einer
Ausführungsform
dieser Erfindung zeigt. In Schritt 172 wird ein zweites
Token-Paket, das Transaktionsadressierungsinformationen aufweist,
vom Host an den Hub gesendet. In Schritt 174 empfängt der
Host-Controller 110 eine zweite Bestätigung vom Hub 120,
wobei die zweite Bestätigung entweder
1. Handshake-Informationen aufweist, die der Hub 120 während der
oben im Zusammenhang mit 1b beschriebenen
Hub-Agent-Transaktion vom Agent 130 empfangen hat, oder
2. meldet, dass der Hub 120 noch keine auf der Hub-Agent-Transaktion basierenden
Informationen zum Weiterleiten an den Host-Controller 110 hat
(zum Beispiel weil die Hub-Agent-Transaktion
noch nicht beendet ist). Die Handshake-Informationen zeigen an, ob entweder
1. der Agent 130 während
der Hub-Agent-Transaktion Daten ordnungsgemäß empfangen hat (ACK), 2. der
Agent 130 gemeldet hat, dass er nicht normal arbeiten kann
(STALL), oder 3. der Agent 130 gemeldet hat, dass er später erneut
kontaktiert werden will (NAK). Zwar wurde beschrieben, dass die
erste und die zweite Bestätigung
sowie die Handshake-Informationen bestimmte Meldungen spezifizieren, doch
ist es dem Durchschnittsfachmann offensichtlich, dass diese und
andere hier beschriebene Bestätigungen
und Handshakes andere Meldungen repräsentieren können. Außerdem können in einer alternativen
Ausführungsform
Bestätigungen
und Handshakes hinzugefügt
werden, die sich von den hier beschriebenen unterscheiden oder diese
ergänzen,
ohne dass vom Schutzumfang der Erfindung abgewichen wird.
-
Obwohl
die obige Beschreibung generell im Kontext des Agents 130 und
des Hubs 120 erfolgte, die mit einer niedrigeren Datenrate
als zwischen dem Hub 120 und dem Host-Controller 110 kommunizieren,
wird der Fachmann einsehen, dass die vorliegende Erfindung praktiziert
werden kann, um eine niedrigere Datenrate an eine höhere Datenrate
zu brücken
oder sogar gleiche Datenraten mit verschiedenen Protokollen.
-
Obwohl
in 1 nur ein Hub zwischen Agent und
Host dargestellt ist, können
zwischen jedem gegebenen Agent und dem Host mehrere Hubs sein. Obwohl
nur sechs Übertragungstypen
beschrieben wurden, ist dem Fachmann ersichtlich, dass andere Typen
benutzt werden können,
ohne vom Schutzumfang oder dem Erfindungsgedanken dieser Erfindung
abzuweichen.
-
Die 2a, 2b, 3a, 3b, 4a, 4b, 5a, 5b, 6a, 6b, 7a und 7b stellen
jeweils ein Zustandsübergangsdiagramm
für das
Durchführen
einer Übertragung
mit einem Host-Controller und einem Hub gemäß dieser Erfindung dar. Figuren
mit einem „a" als Suffix zeigen
das Zustandsübergangsdiagramm
für einen
Host-Controller; die Zustandsmaschine kann auf dem oben in Verbindung
mit 1a beschriebenen Host-Controller 110 ausgeführt werden.
Figuren mit einem „b" als Suffix zeigen
das Zustandsübergangsdiagramm
für einen
Hub; die Zustandsmaschine kann auf dem oben in Verbindung mit 1a beschriebenen
Hub 120 ausgeführt
werden. Die in diesen Figuren gezeigten Zustandsmaschinen zeigen
Prozesse, die mehrere Schritte aufweisen. Es ist offensichtlich,
dass einige der Schritte über eine
größere Anzahl
von Schritten verteilt werden oder zu weniger Schritten zusammengefasst
werden können,
ohne vom Schutzumfang und Gedanken dieser Erfindung abzuweichen.
Die Zustandsmaschinen werden nicht näher beschrieben, da ihre Arbeitsweise
für den
Durchschnittsfachmann offensichtlich ist. Zum leichteren Verständnis werden
die von den Zustandsmaschinen durchgeführten Prozesse nicht separat
beschrieben. Da die von den Zustandsmaschinen ausgeführten Prozesse
im Tandem arbeiten (das heißt,
jeder Prozess umfasst Schritte, deren Ausführung vom Eintreten von Ereignissen
oder Schritten in dem anderen Prozess abhängt), sind die Beschreibungen
der Prozesse zum leichteren Verständnis ineinander verschachtelt.
-
2a und 2b zeigen
Zustandsübergangsdiagramme
für einen
Host-Controller bzw. einen Hub, die eine Übertragung gemäß dieser
Erfindung durchführen,
genauer eine gesplittete Bulk/Control-Out-Übertragung. Prozess 200 und
Prozess 260 zeigen die Zustandsmaschinen für einen
Host-Controller bzw. einen Hub. Prozess 200 umfasst eine „Split
starten"-Transaktion,
die eine Token-Phase (XOUT) und eine Datenphase (DATAx) umfasst,
die vom Host-Controller bis zu drei Mal wiederholt werden können, falls
während
der Phasen des Transaktionsversuchs zwischen Host-Controller und
Hub Zeitüberschreitungen
auftreten. Als Antwort auf die „Split starten"-Transaktion läuft Prozess 260 durch
Zustände
weiter, die entweder die Daten akzeptieren (ACK) oder auf einen
erneuten Versuch des Controllers nach einem Kommunikationsfehler
eines Hub-Handshakes zum Host-Controller
antworten (ACK, DATEN NICHT AKZEPTIEREN) oder auf Grund mangelnden
Platzes zur Aufnahme der „Transaktion
starten"-Informationen
einen erneuten Versuch des Host-Controllers anfordern (NAK) oder
bis zu drei Zeitüberschreitungen
erzeugen. Prozess 200 zeigt die Antwort eines Host-Controllers
auf eine „Split
beenden"-Transaktion
(XIN), wenn die Transaktion: zwischen Hub und Agent erfolgreich verarbeitet
wurde (WEITER); zu einem NAK vom Agent geführt hat (NAK); eine Meldung
empfangen hat, dass der Agent nicht normal funktionieren konnte
(STALL); vom Hub oder Agent noch nicht beendet wurde (NYET) oder
der XIN oder seine Antwort einen Kommunikationsfehler hatten, der
zu bis zu drei Zeitüberschreitungen zwischen
Host-Controller
und Hub geführt
hat. Als Antwort auf die „Split
beenden"-Transaktion
meldet Prozess 260 entweder, dass die Transaktion zwischen
dem Hub und dem Agent noch nicht beendet ist (NYET), oder er gibt
eine Meldung (ACK, NAK, STALL) darüber aus, was während der
Transaktion zwischen dem Hub und dem Agent vorgefallen ist.
-
3a und 3b zeigen
Zustandsübergangsdiagramme
für einen
Host-Controller bzw. einen Hub, die eine weitere Übertragung
gemäß dieser
Erfindung durchführen,
genauer eine gesplittete Interrupt-Out-Übertragung. Prozess 300 und
Prozess 360 zeigen die Zustandsmaschinen für einen
Host-Controller bzw. einen Hub. Prozess 300 umfasst eine „Split
starten"-Transaktion, die
eine Token-Phase (XOUT) und eine Datenphase (DATAx) umfasst, die
nicht vom Host-Controller wiederholt wird, weil gemäß einer
Ausführungsform
die Interrupt-Out-Übertragung
zeitkritisch ist und nicht wiederholt zu werden braucht, wenn sie
beim ersten Mal nicht erfolgreich ist. Als Antwort auf die „Split
starten"-Transaktion
akzeptiert Prozess 360 entweder die Daten (ACK), oder er
tut nichts. Prozess 300 zeigt die Antwort des Hosts auf
eine „Split
beenden"-Transaktion (XIN),
wenn die Transaktion: zwischen Hub und Agent erfolgreich verarbeitet
wurde (WEITER); eine Meldung empfangen hat, dass der Agent nicht
normal funktionieren konnte (STALL); vom Hub oder Agent noch nicht beendet
wurde (NYET) oder der XIN oder seine Antwort einen Kommunikationsfehler
hatten, der zu bis zu drei Zeitüberschreitungen
zwischen Host-Controller
und Hub geführt
hat. Als Antwort auf die „Split
beenden"-Transaktion
meldet Prozess 360 entweder, dass die Transaktion zwischen
dem Hub und dem Agent noch nicht beendet ist (NYET), oder er gibt
eine Meldung (ACK, NAK, STALL) darüber aus, was während der
Transaktion zwischen dem Hub und dem Agent vorgefallen ist.
-
4a und 4b zeigen
Zustandsübergangsdiagramme
für einen
Host-Controller bzw. einen Hub, die eine weitere Übertragung
gemäß dieser
Erfindung durchführen,
genauer eine gesplittete isochrone Out-Übertragung. Prozess 400 und
Prozess 460 zeigen die Zustandsmaschinen für einen
Host-Controller bzw. einen Hub. Prozess 400 umfasst eine „Split
starten"-Transaktion, die
eine Token-Phase (XOUT) und eine Datenphase umfasst, die beide nicht
wiederholt werden. Gemäß einer
Ausführungsform
umfasst Prozess 400 keine „Split beenden"-Transaktion. Prozess 460 ermöglicht das
Aufteilen der Daten der Transaktion vom Hub zum Agent in mehrere
Abschnitte, um das im Hub benötigte
Puffern zu minimieren; der Host-Controller
kann den nächsten
Datenabschnitt kurz vor dem Zeitpunkt senden, zu dem der Hub ihn
an den Agent senden muss. In diesem Fall wird jede „Split
starten"-Transaktion
mit ALLE, ANFANG, MITTE oder ENDE markiert, so dass der Hub erkennen kann,
wenn ein Kommunikationsfehler dazu geführt hat, dass der Hub einen
Datenabschnitt nicht in der richtigen Reihenfolge empfangen hat.
Als Antwort auf die „Split
starten"-Transaktion
akkumuliert Prozess 460 Nutzdaten, die einen Datenabschnitt
(ALLE), zwei Datenabschnitte (ANFANG, ENDE) oder mehrere Datenabschnitte
(ANFANG, MITTE ... MITTE, ENDE) umfassen.
-
5a und 5b zeigen
Zustandsübergangsdiagramme
für einen
Host-Controller bzw. einen Hub, die eine weitere Übertragung
gemäß dieser
Erfindung durchführen,
genauer eine gesplittete Bulk/Control-In-Übertragung. Prozess 500 und
Prozess 560 zeigen die Zustandsmaschinen für einen
Host-Controller bzw.
einen Hub. Prozess 500 umfasst eine „Split starten"-Transaktion, die
eine Token-Phase (XOUT) umfasst, die vom Host-Controller bis zu
drei Mal wiederholt wird, falls während der Transaktionsversuche
zwischen Host-Controller und Hub Zeitüberschreitungen auftreten.
Als Antwort auf die „Split
starten"-Transaktion
bestätigt
und akzeptiert Prozess 560 entweder die Transaktion (ACK,
Transaktion akzeptieren), antwortet auf einen erneuten Versuch des
Controllers nach einem Kommunikationsfehler eines Hub-Handshakes
an den Host-Controller (ACK, Transaktion ignorieren) oder fordert
auf Grund mangelnden Platzes zum Aufnehmen der „Transaktion starten"-Informationen einen erneuten Versuch
des Host-Controllers an. Prozess 500 zeigt die Antwort
des Hosts auf eine „Split
beenden"-Transaktion
(XIN), wenn die Transaktion: zwischen Hub und Agent erfolgreich
verarbeitet wurde (WEITER); eine Meldung empfangen hat, dass der
Endpunkt nicht normal funktionieren kann (STALL); vom Hub oder Agent
noch nicht beendet wurde (NYET) oder der XIN oder seine Antwort
einen Kommunikationsfehler hatten, der zu bis zu drei Zeitüberschreitungen
zwischen Host-Controller und Hub geführt hat. Als Antwort auf die „Split
beenden"-Transaktion
meldet Prozess 560 entweder, dass die Transaktion zwischen
dem Hub und dem Agent noch nicht beendet ist (NYET), oder er gibt
eine Meldung (NAK, STALL) darüber
aus, was während
der Transaktion zwischen dem Hub und dem Endpunkt vorgefallen ist,
oder er sendet die Daten, die der Hub vom Agent empfangen hat, an
den Host-Controller.
-
6a und 6b zeigen
Zustandsübergangsdiagramme
für einen
Host-Controller bzw. einen Hub, die eine weitere Übertragung
gemäß dieser
Erfindung durchführen,
genauer eine gesplittete Interrupt-In-Übertragung. Prozess 600 und
Prozess 660 zeigen die Zustandsmaschinen für einen
Host-Controller bzw. einen Hub. Prozess 600 umfasst eine „Split
starten"-Transaktion mit einer
Token-Phase (XOUT). Als Antwort auf die „Split starten"-Transaktion akzeptiert
der Prozess 660 die Transaktion (Transaktion akzeptieren).
Prozess 600 zeigt die Antwort des Hosts auf eine „Split
beenden"-Transaktion
(XIN), wenn die Transaktion: zwischen Hub und Agent erfolgreich
verarbeitet wurde (WEITER); eine Meldung empfangen hat, dass der
Endpunkt nicht normal funktionieren kann (STALL); vom Hub oder Agent
noch nicht beendet wurde (NYET); ein NAK vom Agent erhalten hat
(NAK); erneut die Token-Phase versucht, wenn es sich bei den empfangenen
Daten um einen vom Agent unternommenen erneuten Versuch der vorangehenden
Transaktionsanforderung ist (Daten ignorieren) handelt oder der
XIN oder seine Antwort einen Kommunikationsfehler hatten, der zu
bis zu drei Zeitüberschreitungen
geführt
hat, bevor der Host-Controller die Kommunikation mit dem Agent aufgegeben
hat. Als Antwort auf die „Split
beenden"-Transaktion
meldet Prozess 660, dass eine Zeitüberschreitung eingetreten ist,
während
der Hub mit dem Agent kommunizierte (NYET), oder dass der Hub das „Transaktion
starten" für diese
Anforderung nicht empfangen hat und über keine entsprechenden Antwortinformationen
verfügte (STALL),
oder er gibt eine Meldung (NAK, STALL) darüber aus, was während der
Transaktion zwischen dem Hub und dem Agent vorgefallen ist, oder
er sendet die Daten an den Host-Controller.
-
7a und 7b zeigen
Zustandsübergangsdiagramme
für einen
Host-Controller bzw. einen Hub, die eine weitere Übertragung
gemäß dieser
Erfindung durchführen,
genauer eine gesplittete isochrone In-Übertragung. Prozess 700 und
Prozess 760 zeigen die Zustandsmaschinen für einen
Host-Controller bzw. einen Hub. Prozess 700 umfasst eine „Split
starten"-Transaktion mit einer
Token-Phase (XOUT). Als Antwort auf die „Split starten"-Transaktion akzeptiert
Prozess 760 die Transaktion (Transaktion akzeptieren).
Prozess 700 zeigt die Antwort des Hosts auf eine „Split
beenden"-Transaktion
(XIN), wenn die Transaktion zwischen dem Hub und dem Agent erfolgreich
durchgeführt
wurde und alle Daten zurückgeschickt
worden sind (Tweiter), oder wenn es noch weitere Daten zum Zurückschicken
gibt (Dweiter), oder wenn auf Grund eines Kommunikationsfehlers
zwischen dem Host und dem Hub (Zeitüberschreitung oder fehlgeschlagene
zyklische Redundanzprüfung
(CRC)) oder dem Agent (NAK) oder auf Grund eines Problems des Hubs
mit dem Agent (NYET) ein Fehler aufgetreten ist (Fehler verzeichnen).
Als Antwort auf die „Split
beenden"-Transaktion
(XIN) meldet Prozess 660, dass die zyklische Redundanzprüfung der
vom Agent empfangenen Daten fehlschlug (NAK), der Agent nicht geantwortet
hat (NYET) oder der Hub keine Informationen über dieses „Split beenden” hatte,
oder er sendet die Daten an den Host-Controller und meldet entweder, dass
alle Daten zurückgeschickt
wurden (DATA0) oder noch weitere Daten zurückgeschickt werden müssen (MDATA).
-
An
diesem Punkt ist es nützlich,
die Beschreibung des obigen Protokolls zusammenzufassen, bevor die
verbleibenden Vorrichtungen und Verfahren der vorliegenden Erfindung
beschrieben werden. Das oben beschriebene Protokoll erlaubt es einem
Host-Controller, über
einen Hub Daten an einen Agent zu senden oder von einem Agent zu
empfangen. Das Protokoll erlaubt es dem Host-Controller, eine erste
Transaktion („Split starten"-Transaktion) einzugehen,
bei der eine Übertragungsanforderung
an den Hub kommuniziert wird. Wenn der Host-Controller die erste Transaktion durchgeführt hat,
kann er mit demselben Hub oder einem anderen Hub eine Zwischentransaktion
eingehen, ohne darauf warten zu müssen, dass der Hub und der
Agent die Übertragungsanforderung
durchführen
(das heißt
die Übertragung
von Daten zum oder vom Agent aufnehmen). Die Zwischentransaktion
kann eine Übertragungsanforderung
für den
Agent, einen anderen Agent am selben Hub wie der Agent oder einen
anderen Agent an einem anderen Hub umfassen. Nachdem der Hub die Übertragung
von Daten zum oder vom Agent aufgenommen hat, führt der Host-Controller eine „Split
beenden"-Transaktion (oder
zweite Transaktion) durch, um das Ergebnis (zum Beispiel vom Agent
an den Hub gesendete Daten oder Handshake) der zwischen dem Hub
und dem Agent durchgeführten Übertragung
zu erhalten. Indem dem Host-Controller die Fähigkeit verliehen wird, eine
Zwischentransaktion einzugehen, statt darauf warten zu müssen, dass
der Hub die Übertragungsanforderung
(oder dritte Transaktion) mit dem Agent durchführt, kann der effektive Durchsatz
eines Busses, der ein Protokoll gemäß der vorliegenden Erfindung benutzt,
bedeutend größer sein
als der von Bussen, die Geschwindigkeitsumschaltung benutzen oder
bei denen der Host-Controller mit dem Initiieren einer weiteren Übertragung
warten muss, bis der Hub die Übertragung
mit dem Agent durchgeführt
hat.
-
Während das
obige Protokoll die Abfolge der zum Übertragen von Daten über einen
Bus nötigen Transaktionen
definiert, beschreibt es nicht explizit das Timing für die Transaktionen
oder Übertragungen,
die zum Senden oder Empfangen von Daten von oder zu einem Agent
führen.
Das Timing der Übertragungen
für Agents
ist jedoch wichtig, da Agents in der Regel erfordern, dass Daten
periodisch (zum Beispiel isochron oder Interrupt) oder asynchron
(zum Beispiel Bulk oder Control) an den Host-Controller gesendet
oder von diesem empfangen werden. Außerdem beschreibt das obige
Protokoll, obwohl es einem Host-Controller
das Durchführen
einer Zwischentransaktion (oder sogar mehrerer Zwischentransaktionen)
zwischen der „Split
starten"- und der „Split
beenden"-Transaktion
erlaubt, nicht explizit, wie Übertragungsanforderungen
im Hub gespeichert werden, und wie Hub und Agent Übertragungsanforderungen
durchführen,
ohne dass der Host-Controller auf das Durchführen der Übertragungsanforderung warten
muss, bevor er eine Zwischentransaktion eingeht. Die von der obigen
Beschreibung des Protokolls nicht behandelten Punkte, nämlich das
Timing der Übertragungsanforderungen
und wie ein Hub Übertragungsanforderungen
verarbeitet (also das Puffern und das Durchführen), werden in den folgenden
Beschreibungen von Verfahren und Vorrichtungen gemäß der vorliegenden
Erfindung behandelt. Die vorliegen de Erfindung umfasst ein Verfahren
und eine Vorrichtung zum Zeitplanen (engl. „Scheduling") von Datenübertragungen
an und von einem Agent und ein Verfahren und eine Vorrichtung zum
Verarbeiten von Übertragungsanforderungen
an einem Hub. Das Verfahren und die Vorrichtung für das Zeitplanen
von Datenübertragungen
wird zuerst beschrieben; danach wird als Zweites das Verfahren und
die Vorrichtung für
das Puffern und Durchführen
von Übertragungsanforderungen
beschrieben.
-
Wiederum
bezugnehmend auf 1 beginnt der Prozess
zum Zeitplanen von Datenübertragungen, wenn
das System 102 die Konfiguration für die an den Bus des Systems
angeschlossenen Agents durchführt. Die
Konfiguration kann bei der Systeminitialisierung oder beim Booten
geschehen, oder wenn ein Agent nach der Initialisierung an den Bus
angeschlossen wird. Das Zeitplanen der Datenübertragungen hängt vom Übertragungstyp,
der dem Agent (oder einem Endpunkt eines Agents) zugeordnet ist,
und von der in der Übertragung
zu bewältigenden
Datenmenge ab. Die Art und Weise, mit der Agents behandelt werden,
denen periodische Übertragungen
wie etwa isochron und Interrupt zugeordnet sind, wird unten als
Erstes beschrieben, danach wird die Art und Weise, mit der Agents
behandelt werden, denen asynchrone Übertragungen wie etwa Bulk
und Control zugeordnet sind, beschrieben.
-
Während des
Konfigurationsprozesses informiert jeder Endpunkt jedes Agents das
System über
die dem Endpunkt zugeordnete maximale Nutzdatengröße und den
Transfertyp (zum Beispiel isochron in/out, Interrupt, Bulk, Control).
Die Art und Weise und die Mittel, mit denen jeder Agent das System
informiert, sind dem Durchschnittsfachmann wohlbekannt und brauchen
hier nicht beschrieben zu werden. Die maximale Nutzdatengröße ist die
größte Menge
an Daten, die ein Transfer vom oder zum Agent umfassen kann. Das
System leitet die Nutzdatengröße und den
Transfertyp an den Host-Controller weiter. Die Art und Weise, wie
das System die Größe und den
Transfertyp an den Host-Controller
weiterleitet, ist dem Durchschnittsfachmann wohlbekannt und braucht
hier nicht beschrieben zu werden. Der Host-Controller benutzt die beiden oben erwähnten, jedem
Endpunkt zugeordneten Informationen, um eine Budgetliste für die periodischen Übertragungen
der Endpunkte zu erstellen. In einer alternativen Ausführungsform
kann ein Softwaretreiber wie etwa der Host-Controller-Treiber oder
sogar ein Hardwaretreiber die Budgetliste erstellen und die unten
beschriebenen Zeitplanungs-Operationen durchführen. Die Budgetliste verzeichnet
den frühesten
Zeitpunkt, zu dem eine Übertragung
(Senden oder Empfangen eines Datenpakets) stattfinden darf, sowie
den spätesten
Zeitpunkt, zu dem ein dieser Übertragung
zugeordnetes Ergebnis verfügbar
sein kann. Der früheste
Zeitpunkt, zu dem eine Übertragung
stattfinden kann, hängt
ab von der Zeit, die unter der Annahme, dass die vorhergehenden Übertragungen
unter den bestmöglichen
Umständen
(wie unten definiert) stattgefunden haben, von jeder der vorhergehenden Übertragungen
aufgebraucht wurde. Der späteste
Zeitpunkt, zu dem ein einer Übertragung
zugeordnetes Ergebnis verfügbar
sein kann, hängt
von der Zeit, die unter der Annahme, dass die vorhergehenden Übertragungen
unter den schlechtesten Umständen
(wie unten definiert) stattgefunden haben, von jeder der vorhergehenden Übertragungen
aufgebraucht wurde, und der für
die Übertragung
unter den schlechtesten Umständen
benötigten
Zeitdauer ab. Der früheste
Zeitpunkt, zu dem eine Übertragung
stattfinden kann, ist wichtig, weil der Host-Controller die Übertragungsanforderung
vor diesem Zeitpunkt im Hub gepuffert haben muss, so dass der Hub
sich, sobald er die vor der gepufferten Übertragungsanforderung liegende Übertragungsanforderung
abgeschlossen hat, der gepufferten Übertragungsanforderung zuwenden
kann. Der späteste
Zeitpunkt, zu dem ein der Übertragung
zugeordnetes Ergebnis verfügbar
sein kann, ist wichtig, weil es nach dem spätesten Zeitpunkt im Wesentlichen
sicher ist, dass das Ergebnis für
den Abruf durch den Host-Controller bereit steht. Wenn der Host-Controller
vor dem spätesten
Zeitpunkt versuchen würde,
das Ergebnis vom Hub abzurufen, was bedeutet, dass das Ergebnis
noch nicht verfügbar
ist, würde
ein weniger effizientes Protokoll, das mehrfaches Abrufen benutzt,
erforderlich sein.
-
Übertragungen
finden dann unter den bestmöglichen
Umständen
statt, wenn jede Übertragung
die maximale Nutzdatenmenge umfasst und es im Wesentlichen kein
Bitstopfen gibt. Übertragungen
finden unter den schlechtesten Umständen statt, wenn jede Übertragung
die maximale Nutzdatenmenge umfasst und es maximales Bitstopfen
gibt. Bitstopfen tritt gemäß einer
Ausführungsform
der vorliegenden Erfindung auf, weil die Signale auf dem Bus die
NRZ-Signalisierung (engl. „non-return-to-zero") verwenden. Gemäß einer
Ausführungsform
der vorliegenden Erfindung kann Bitstopfen die Größe der maximalen
Nutzdatenmenge um bis zu 16% erhöhen.
Während
in einer Ausführungsform
die bestmöglichen
und schlechtesten Umstände über das Bitstopfen
definiert wurden, ist es offensichtlich, dass in alternativen Ausführungsformen
die Umstände über andere
Dinge definiert werden können,
die die Größe (oder
Zeit) von Übertragungen
vergrößern oder
verkleinern oder Verzögerungen
erzeugen können.
Im Folgenden wird die Erzeugung einer Budgetliste gemäß der vorliegenden
Erfindung beschrieben. Während
hier ein Weg zur Erzeugung einer Budgetliste beschrieben ist, ist
es offensichtlich, dass der Schutzumfang der vorliegenden Erfindung
andere mögliche
Wege umfasst. Eine Budgetliste ist eine Liste der zulässigen periodischen
Transaktionen, die in einem konkreten Frame-Template stattfinden
können.
Ein Frame ist eine kontinuierlich auftretende Zeitperiode, die als
Teil der Busspezifikation definiert ist und ausreicht, um eine oder
mehrere Transaktionen zuzulassen. In einer Ausführungsform wird ein Frame definiert
als eine Zeitperiode von 1 Millisekunde Dauer. Für jeden Frame wird eine andere
Budgetliste konstruiert, die einen anderen Satz zulässiger periodischer
Transaktionen aufweist. Ein Frame-Template ist eine Beschreibung
eines konkreten, periodisch wiederkehrenden Frames, der eine maximale
Anzahl an Transaktionen zulässt,
wobei jede Transaktion eine maximale Nutzdatenmenge aufweist. Ein
Frame enthält
eine Anzahl von Transaktionen mit einer tatsächlichen Nutzdatenmenge, während ein
Frame-Template einen potentiell budgetierten Frame beschreibt. Jede
Budgetliste weist zugeordnete Best-Case-Informationen und zugeordnete
Worst-Case- Informationen
auf. Die Best-Case-Informationen beschreiben die Situation, in der
jede Transaktion innerhalb des Frame-Templates unter den bestmöglichen
Umständen
stattfindet. In einer alternative Ausführungsform repräsentieren
die Best-Case-Informationen
und die Worst-Case-Informationen Übertragungen statt Transaktionen.
-
8a zeigt
ein Diagramm für
ein Best-Case-Frame-Template 800 gemäß der vorliegenden
Erfindung. Block 805 repräsentiert die mit einem ersten
Endpunkt verknüpfte Übertragung,
wobei die Übertragung im
bestmöglichen
Fall stattfindet. Block 810 repräsentiert die mit einem zweiten
Endpunkt verknüpfte Übertragung,
wobei die Übertragung
im bestmöglichen
Fall stattfindet. Die verbleibenden Blöcke 815–835 repräsentieren ähnliche
Best-Case-Übertragungen
für andere
vom System konfigurierte Endpunkte. Die Worst-Case-Informationen
beschreiben die Situation, in der jede Transaktion innerhalb des
Frame-Templates unter den schlechtesten Umständen stattfindet. 8b zeigt
ein Diagramm für
ein Worst-Case-Frame-Template 850 gemäß der vorliegenden Erfindung.
Block 855 repräsentiert
die mit dem ersten Endpunkt verknüpfte Übertragung, wobei die Übertragung
im schlimmsten Fall stattfindet. Block 860 repräsentiert
die mit dem zweiten Endpunkt verknüpfte Übertragung, wobei die Übertragung
im schlimmsten Fall stattfindet. Die verbleibenden Blöcke 865 bis 885 repräsentieren ähnliche
Worst-Case-Übertragungen
für andere
vom System konfigurierte Endpunkte. Es ist offensichtlich, dass
die relativen Größen der
Blöcke
nur zum Zwecke der Veranschaulichung dienen.
-
Die
Bedeutung des Best-Case-Frame-Templates 800 und des Worst-Case-Frame-Templates 850 werden
nun durch Betrachtung der Blöcke 805, 810, 855 und 860 erläutert. Die
Blöcke 805 und 855 repräsentieren jeweils
die Übertragung
im bestmöglichen
bzw. schlimmsten Fall für
den ersten Endpunkt. Der früheste
Zeitpunkt, zu dem die Übertragung
für den
ersten Endpunkt beendet sein kann, ist Ta. Der späteste Zeitpunkt,
zu dem die Übertragung
für den
ersten Endpunkt beendet sein kann, ist Tb. Das Vorhergehende legt
nahe, dass die mit dem zweiten Endpunkt verknüpfte Übertragung bereits zum Zeitpunkt
Ta oder erst zum Zeitpunkt Tb beginnen kann. Die Blöcke 810 und 860 repräsentieren
jeweils die Übertragungszeiten
im bestmöglichen
bzw. schlimmsten Fall für
den zweiten Endpunkt. Der früheste
Zeitpunkt, zu dem die Übertragung
für den
zweiten Endpunkt beendet sein kann, ist Tc. Der späteste Zeitpunkt,
zu dem die Übertragung
für den
zweiten Endpunkt beendet sein kann, ist Td. Das Vorhergehende legt
nahe, dass die für
die zweite Transaktion notwendigen Informationen vor dem Zeitpunkt
Ta dem Hub zur Verfügung
stehen müssen,
und dass alle Ergebnisse aus der ersten Übertragung im Wesentlichen
sicher nach Zeitpunkt Tb zur Verfügung stehen. Außerdem ist
es offensichtlich, dass das Zeitplanen einer Übertragung von der zum Durchführen jeder
der vorhergehenden Übertragungsanforderungen
benötigten
Zeit abhängt.
Außerdem
ist es offensichtlich, dass das Zeitplanen der „Split beenden"-Transaktion von
der Zeit zum Durchführen
der ggf. vorhandenen, mit einer „Split starten"-Transaktion verknüpften gegenwärtigen Übertragungsanforderung
abhängt.
-
Das
Frame-Template 800 und das Frame-Template 850 sind
Frame-Templates, die repräsentativ
für einen
Frame zwischen dem Hub und dem Agent sind (Hub-Agent- oder klassischer
Frame). Gemäß einer
Ausführungsform
der vorliegenden Erfindung weisen Host-Controller und Hub einen
weiteren Frame auf, dessen Größe ein Bruchteil
der Größe (Microframe)
des klassischen Frames ist. Insbesondere sind in einer Ausführungsform
acht Microframes äquivalent
zu einem einzelnen klassischen Frame. Da der Host-Controller und
der Hub bei ihrer Kommunikation Microframes benutzen und da eine Übertragungsanforderung
eine „Split
starten"-Transaktion
startet, bevor sie den Hub erreicht, ist es nützlich, die Zeit zum Durchführen einer „Split
starten"-Transaktion
in Form von Microframes zu beschreiben. Ebenso ist es nützlich,
die Zeit zum Durchführen der „Split
beenden"-Transaktion
in Form von Microframes zu beschreiben. Im Hinblick auf die Startzeit
für eine „Split
starten"-Transaktion sollte
gemäß einer
Ausführungsform
eine „Split
starten"-Transaktion
einen Microframe vor demjenigen Microframe stattfinden, in dem die Übertragung
zwischen dem Hub und dem Agent gemäß dem Best-Case-Frame stattfinden
kann. Im Hin blick auf die Startzeit für eine „Split beenden"-Transaktion sollte
gemäß einer
Ausführungsform
eine „Split
beenden"-Transaktion einen
Microframe nach demjenigen Microframe stattfinden, in dem die Übertragung
der zugehörigen „Split
starten"-Transaktion
gemäß dem Worst-Case-Frame
beendet sein kann. Gemäß einer
Ausführungsform
der vorliegenden Erfindung benutzt der Host-Controller den Best-Case-Frame
und den Worst-Case-Frame
für jedes
Frame-Template, um einen „Split starten"-Vektor und einen „Split beenden"-Vektor für jeden
Endpunkt in jedem Frame-Template zu generieren. Der „Split
starten"-Vektor
enthält
einen Wert, der den Microframe angibt, in welchem die „Split
starten"-Transaktion
für einen
Endpunkt in einem klassischen Frame stattfinden soll. Gemäß einer
Ausführungsform
hat der „Split
starten"-Vektor
Werte im Bereich von –1
bis 6. Der „Split
beenden"-Vektor
enthält
einen Wert, der den Microframe angibt, in welchem die „Split
beenden"-Transaktion
für einen
Endpunkt in einem klassischen Frame stattfinden soll. Gemäß einer
Ausführungsform
hat der „Split
beenden"-Vektor
Werte im Bereich von 1 bis 8.
-
Wenn
der Host-Controller-Treiber 105 den Host-Controller 110 beauftragt,
eine Übertragung
in einem bestimmten Frame für
einen bestimmten Endpunkt durchzuführen, betrachtet der Host-Controller 110 den Best-Case-Vektor,
der mit dem Endpunkt und dem Frame-Template verknüpft ist,
die dem konkreten Frame entsprechen. Der Wert im „Split
starten"-Vektor
für einen
bestimmten Endpunkt und ein bestimmtes Frame-Template gibt den Microframe
an, zu dem eine „Split
starten"-Transaktion
durchgeführt
werden soll. Ebenso betrachtet der Host-Controller 110 den „Split
beenden"-Vektor,
um den Microframe festzulegen, zu dem eine „Split beenden"-Transaktion durchgeführt werden
soll.
-
9 enthält eine
Reihe von Hub-Agent-Frames (oder klassischen Frames) 900 und
einen Host-Controller/Hub-Frame 950. Die Frames 900 beinhalten
die Frames 910–930.
Der Frame 930 weist eine Übertragung 901 auf,
die dergestalt zeitlich eineplant ist, dass sie im Microframe B
startet und endet. In dieser Veranschulichung ist die Übertragung 901 eine
isochrone Out-Übertragung,
aber es ist offensichtlich, dass andere Über tragungen auf ähnliche
Weise repräsentiert
werden können.
Frame 950 enthält
Frame 960, der die Subframes 961 und 963 aufweist.
Während
die Übertragung 901 dergestalt
zeitlich eingeplant ist, dass sie im Hub 120 im Microframe
B startet und endet (das heißt,
in dem durch die Frames 900 repräsentierten Hub-Agent-Zeitframe),
findet die zugehörige „Split
starten"-Transaktion in Frame 961 und
die zugehörige „Split beenden"-Transaktion in Frame 963 statt.
In dem durch Frame 950 repräsentierten Host-Controller/Hub-Zeitframe
findet die zugehörige „Split
starten"-Transaktion
zum Zeitpunkt 951a irgendwann in Subframe 961 statt, und
die zugehörige „Split
beenden"-Transaktion findet
zum Zeitpunkt 963a irgendwann in Subframe 963 statt. Die Übertragung 951 repräsentiert
die Übertragung
901 im Host-Controller/Hub-Zeitframe. In den Subframes 961 und 963 können noch
weitere Übertragungen
und Transaktionen stattfinden. Aus 9 ist ersichtlich, dass
die Subframes 962 und 963 für weitere Übertragungen und Transaktionen
mit anderen Agents zur Verfügung
stehen.
-
Obwohl
die obige Beschreibung grundsätzlich
im Kontext periodischer Transaktionen gegeben wurde, ist die Erfindung
nicht auf periodische Transaktionen beschränkt, sondern umfasst ebenso
asynchrone Übertragungen
wie etwa die oben beschriebenen Bulk- und Controlübertragungen.
Gemäß einer
Ausführungsform der
vorliegenden Erfindung sind neunzig Prozent eines klassischen Frames
für periodische Übertragungen
reserviert. Asynchrone Übertragungen
finden zum frühestmöglichen
Zeitpunkt statt, zu dem auf dem Bus zwischen dem Hub und dem Agent
Platz für
sie ist. Der Hub akzeptiert eine Transaktion während eines Microframes, wenn
er verfügbaren
Platz hat, um die „Split
starten"-Transaktion
aufzunehmen, bis diese auf dem klassischen Bus (das heißt zwischen
dem Hub und einem Agent) ausgegeben werden kann. Dann gibt der Bus
die Transaktion während
eines klassischen Frames aus, wenn ihm keine weiteren anstehenden
periodischen Transaktionen vorliegen. Wenn der Hub ein „Split
starten" akzeptiert
hat, gibt der Host-Controller zu einem späteren Zeitpunkt eine „Split
beenden"-Transaktion
aus, um die Ergebnisse für
diese Transaktion auf dem klas sischen Bus vom Hub abzurufen. Der
Treiber des Host-Controllers
gibt immer dann eine asynchrone Split-Transaktion an den Hub aus,
wenn ihm während
eines Microframes keine weiteren periodischen Transaktionen zum
Ausgeben vorliegen. Die vom Hub bereitgestellte Pufferung für Bulk-/Control-Transaktionen
ist anders als die und separat von der vom Hub bereitgestellten
Pufferung für
periodische Transaktionen.
-
Im
Folgenden werden nun ein Verfahren und eine Vorrichtung für das Puffern
periodischer Übertragungsanforderungen
und deren Verarbeiten gemäß der vorliegenden
Erfindung beschrieben. 1e zeigt
detailliert den Hub 120 aus 1a. Gemäß einer
Ausführungsform
umfasst der Hub 120 der vorliegenden Erfindung einen Host-Controller/Hub-Controller
(oder High-Speed-Hub-Controller) 180, einen Hub/Agent-Hub-Controller
(oder Low-Speed-Hub-Controller) 181, einen Speicher 182,
eine Steuereinheit 183, einen Taktgeber 183a,
einen Repeater 184, eine Routerlogik 185 und Ports 185 bis 189.
Der Controller 180 führt
Split-Transaktionen zwischen Hub 120 und Host-Controller 110 durch.
Immer, wenn der Controller 180 eine „Split starten"-Transaktion vom
Host-Controller 110 empfängt, speichert der Controller 180 die
aktuelle Microframenummer als Zeitmarke für die Transaktion im Speicher 182.
Eine alternative Ausführungsform
würde die
Microframenummer als Zeitmarke in den Zustandsaufzeichnungen vermerken,
um eine Gruppe von vom Hub während eines
Microframes empfangenen Transaktionen von den während eines anderen Microframes
empfangenen Transaktionen zu trennen. Der Controller 181 führt Übertragungen
zwischen dem Hub und einem oder mehreren Agents durch. Die vom Controller 181 durchgeführten Transaktionen
werden während
der „Split
starten"-Transaktionen
zwischen Controller 180 und Host-Controller 110 empfangen. Der
Speicher 182 ist sowohl an den High-Speed-Hub-Controller 180 als
auch an den Low-Speed-Hub-Controller 181 gekoppelt.
Der Speicher umfasst eine Pipeline mit mehreren Stufen. Gemäß einer
Ausführungsform
umfasst die Pipeline fünf
Stufen. Jede Stufe der Pipeline entspricht einem Microframe wie
oben definiert. Jede Stufe der Pipeline umfasst mehrere Transaktionszustände (oder
Transaktionsaufzeichnun gen). Eine Stufe der Pipeline umfasst gemäß einer
Ausführungsform
19 oder weniger Transaktionszustände
oder – aufzeichnungen.
Jede Stufe speichert Aufzeichnungen, die die auszuführenden Übertragungen
repräsentieren.
Eine Aufzeichnung kann mehrere Felder umfassen, wie etwa Adresse
von Gerät
und Endpunkt, Übertragungsrichtung, Übertragungstyp,
Status und einen Datenverweis. Der Status gibt an, ob die Übertragung
nicht bereit (hindert den Low-Speed-Hub-Controller, sie durchzuführen), ausstehend
(wartet auf die Ausführung)
oder bereit (wurde vom Low-Speed-Hub-Controller durchgeführt) ist.
Der Datenverweis ist ein Zeiger auf eine Startadresse im Speicher
für Daten,
die vom Agent (bei der Übertragung)
empfangen wurden oder für
Daten, die an den Agent gesendet werden sollen (zum Beispiel Out-Übertragung).
-
Der
Hub 120 weist eine Steuereinheit 183 und einen
Taktgeber 183a, der an die Steuereinheit 183 gekoppelt
ist, auf. Gemäß einer
Ausführungsform
generiert der Taktgeber 183a eine Microframe-Meldung, das heißt, dass
ein Achtel der Zeitdauer eines klassischen Frames verstrichen ist.
Die Steuereinheit 183 ist an den Speicher 182 gekoppelt
und überwacht
die Aufzeichnungen in den Stufen und verhindert das Durchführen einer Übertragung
durch den Low-Speed-Hub-Controller 181, falls der Zeitpunkt,
zu dem die Ausführung
der Übertragung
am Low-Speed-Hub-Controller
beginnen soll, nach dem Zeitpunkt liegt, zu dem die Übertragung hätte durchgeführt werden
oder beendet sein sollen. Insbesondere wird gemäß einer Ausführungsform
eine Aufzeichnung, deren zugeordnete Zeitmarke darauf hinweist,
dass der Controller 180 sie vom Host-Controller 110 einen
Microframe zuvor empfangen hat, ein ausstehender Status zugewiesen,
um es dem Low-Speed-Hub-Controller 181 zu ermöglichen,
die Transaktion auf dem klassischen Bus auszugeben. Eine Aufzeichnung,
deren zugeordnete Zeitmarke darauf hinweist, dass sie mehr als drei
Microframes vor der aktuellen Microframe-Meldung empangen wurde, aber noch nicht
vom Low-Speed-Hub-Controller 181 durchgeführt wurde,
wird als alt markiert, um sie für
eine nachfolgende entsprechende „Split beenden"-Transaktion durch den High-Speed-Hub-Controllers
vorzube reiten. Eine Aufzeichnung, deren zugeordnete Zeitmarke darauf
hinweist, dass sie mehr als vier Microframes vor der aktuellen Microframe-Meldung
empfangen wurde, aber vom Low-Speed-Hub-Controller 181 noch nicht durchgeführt wurde
oder von ihm gegenwärtig
durchgeführt
wird, wird abgebrochen und aus der Pipeline entfernt. Der Taktgeber 183a ist
auch an den Low-Speed-Hub-Controller 181 gekoppelt.
Der Controller 181 durchläuft der Reihe nach diejenigen
periodischen Transaktionen, die als ausstehend markiert sind. Gemäß einer
Ausführungsform
läuft der
Controller 181 durch die im frühesten Microframe empfangenen
ausstehenden Aufzeichnungen, bevor er zu den im nächsten Microframe
empfangenen Aufzeichnungen weitergeht, und so weiter. Gemäß einer
Ausführungsform
geht der Controller 181 zum nächsten empfangenen Microframe über, wenn
die Steuereinheit 181 eine Microframe-Meldung empfängt. Wenn
die Steuereinheit 181 eine Microframe-Meldung empfängt, ändert sie
den Status der Übertragungen
im nächsten
empfangenen Microframe von nicht bereit auf ausstehend, und entfernt
diejenigen Übertragungen,
die wie oben beschrieben alt sind. Zum Durchführen einer Übertragung überträgt der Controller 181 Daten
an die Routerlogik 185, die dem Controller 181 Zugriff
auf einen der Ports 186 bis 189 gewährt. Die
Routerlogik 185 gewährt
einem Agent Zugriff entweder auf den Repeater 184 oder
den Controller 181, um das Übertragen von Daten je nach
der konfigurierten Datenrate des Agenten mit hoher Datenrate oder niedriger
Datenrate zu erlauben. Der Repeater 184 ist an den Controller 180 und
die Routerlogik 185 gekoppelt. Der Repeater 184 wiederholt
vom Controller 180 empfangene (oder an diesen gesendete)
Daten, die an einen High-Speed-Agent, der an einen der Ports 186 bis 189 gekoppelt
ist, gerichtet sind (oder von diesem empfangen wurden).
-
Beim
Durchlaufen der im frühesten
Microframe empfangenen ausstehenden Aufzeichnungen arbeitet der
Controller 181 gemäß folgender
Regeln: Nach dem Durchführen
einer Übertragung
zwischen dem Controller 181 und dem Agent ruft der Controller 181 zunächst die
nächste Übertragungsaufzeichnung
ab und führt die
nächste
ausstehende isochrone Übertragung
oder Interrupt- Übertragung
aus. Zweitens führt
der Controller 181 eine ausstehende Bulk- oder Control-Übertragung
aus, falls keine ausstehenden isochronen Übertragungen oder Interrupt-Übertragungen vorliegen. Drittens
wartet der Controller 181, falls keine ausstehende Bulk-/Control-Übertragung
vorliegt, darauf, dass der High-Speed-Hub-Controller 180 eine
ausstehende Bulk-/Control- oder isochrone oder Interrupt-Übertragung
meldet.
-
Wenn
der Low-Speed-Hub-Controller eine Übertragung durchführt, wird
ein Ergebnis im Speicher 182 gespeichert. Das Ergebnis
kann entweder ein Handshake sein, oder es können vom Agent empfangene Daten sein.
Der Low-Speed-Hub-Controller 181 ändert den Status von durchgeführten Übertragungen
auf bereit, und deren Aufzeichnungen werden dem High-Speed-Hub-Controller 180 zur
Verfügung
gestellt. Wenn der High-Speed-Hub-Controller 180 eine „Split
beenden"-Transaktion
empfängt,
untersucht der High-Speed-Hub-Controller 180 die Aufzeichnung
der zuletzt durchgeführten Übertragung
mit denselben Adressinformationen und sendet eine auf dem Ergebnis
der zuletzt durchgeführten Übertragung
basierende Antwort zurück
an den Host-Controller 110. Falls die „Split beenden"-Transaktion nicht
nach einer Transaktion mit denselben Adressinformationen fragt,
antwortet der High-Speed-Hub-Controller 180 mit einem NYET.
-
Damit
sind ein Verfahren und eine Vorrichtung für das Zeitplanen von Übertragungen
zwischen einem Host-Controller und einem Hub beschrieben worden.
Außerdem
sind ein Verfahren und eine Vorrichtung für das Puffern und Durchführen von Übertragungen
an einem Hub beschrieben worden. Obwohl die vorliegende Erfindung
anhand spezifischer beispielhafter Ausführungsformen beschrieben wurde,
ist es für
den Durchschnittsfachmann offensichtlich, dass verschiedene Modifikationen
und Änderungen
an diesen Ausführungsformen
gemacht werden können,
ohne vom weiteren Schutzumfang der Erfindung abzuweichen, der in
den Ansprüchen
dargelegt wird. Demgemäß sind die
Spezifikationen und Zeichnungen in einem veranschaulichenden und
nicht in einem einschränkenden
Sinn zu betrachten.