DE60035882T2 - Protokoll einer zerteilten transaktion für ein bussystem - Google Patents

Protokoll einer zerteilten transaktion für ein bussystem Download PDF

Info

Publication number
DE60035882T2
DE60035882T2 DE60035882T DE60035882T DE60035882T2 DE 60035882 T2 DE60035882 T2 DE 60035882T2 DE 60035882 T DE60035882 T DE 60035882T DE 60035882 T DE60035882 T DE 60035882T DE 60035882 T2 DE60035882 T2 DE 60035882T2
Authority
DE
Germany
Prior art keywords
transaction
hub
host controller
agent
controller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60035882T
Other languages
English (en)
Other versions
DE60035882D1 (de
Inventor
John I. Portland Garney
John S. Portland HOWARD
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Application granted granted Critical
Publication of DE60035882D1 publication Critical patent/DE60035882D1/de
Publication of DE60035882T2 publication Critical patent/DE60035882T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/42Bus transfer protocol, e.g. handshake; Synchronisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/16Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1605Handling requests for interconnection or transfer for access to memory bus based on arbitration
    • G06F13/1642Handling requests for interconnection or transfer for access to memory bus based on arbitration with request queuing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/16Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1668Details of memory controller
    • G06F13/1673Details of memory controller using buffers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/40Bus structure
    • G06F13/4004Coupling between buses
    • G06F13/4027Coupling between buses using bus bridges
    • G06F13/405Coupling between buses using bus bridges where the bridge performs a synchronising function
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/42Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4247Bus transfer protocol, e.g. handshake; Synchronisation on a daisy chain bus
    • G06F13/426Bus transfer protocol, e.g. handshake; Synchronisation on a daisy chain bus using an embedded synchronisation, e.g. Firewire bus, Fibre Channel bus, SSA bus
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40058Isochronous transmission
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40123Interconnection of computers and peripherals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N23/00Cameras or camera modules comprising electronic image sensors; Control thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0054Split transaction bus
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/40Bus coupling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/40Bus coupling
    • G06F2213/4002Universal serial bus hub with a single upstream port

Description

  • 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.
  • Weitere Beispiele für Anordnungen nach Stand der Technik sind in den Patentschriften US 5,708,794 , US 5,875,313 und US 5,594,882 beschrieben.
  • 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 815835 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 910930. 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.

Claims (30)

  1. Ein Verfahren zum Kommunizieren von Daten zwischen einem Host (102) und einer Mehrzahl von Agents (130), das Verfahren ist charakterisiert durch: Durchführen einer Split-Transaktion zum Übermitteln von Daten zwischen einem Host-Controller (110) und einem Agent (130), wobei das Durchführen einer Split-Transaktion umfasst: Durchführen einer ersten Transaktion der Split-Transaktion zwischen dem Host-Controller (110) und einem Hub (120), Durchführen einer Agent-Transaktion zwischen dem Hub (120) und dem Agent (130) basierend auf der ersten Transaktion, Durchführen einer zweiten Transaktion der Split-Transaktion zwischen dem Host-Controller (110) und dem Hub (120), wobei sich die zweite Transaktion von der ersten Transaktion unterscheidet, wobei die zweite Transaktion auf der Agent-Transaktion basiert, und Durchführen einer dritten Transaktion mit einem anderen Agent an dem gleichen Hub wie der Agent zwischen der ersten und zweiten Transaktion der Split-Transaktion.
  2. Das Verfahren nach Anspruch 1, wobei die erste Transaktion und die zweite Transaktion mit einer ersten Kommunikationsgeschwindigkeit oder gemäß einem ersten Protokoll durchgeführt werden.
  3. Das Verfahren nach Anspruch 1, wobei die Agent-Transaktion bei einer zweiten Kommunikationsgeschwindigkeit oder gemäß einem zweiten Protokoll durchgeführt wird.
  4. Das Verfahren nach Anspruch 1, ferner aufweisend ein Durchführen der dritten Transaktion während die Agent-Transaktion durchgeführt wird.
  5. Das Verfahren nach Anspruch 1, ferner aufweisend ein Durchführen der dritten Transaktion zwischen der ersten Transaktion und der Agent-Transaktion.
  6. Das Verfahren nach Anspruch 1, wobei die erste Transaktion umfasst: Senden eines ersten Agent-Identifikationsinformationen umfassenden Paketes von dem Host-Controller (110) an den Hub (120), Senden eines zweiten Daten umfassenden Paketes von dem Host-Controller (110) an den Hub (120), und Empfangen einer Bestätigung von dem Hub (120) bei dem Host-Controller (110).
  7. Das Verfahren nach Anspruch 1, wobei die erste Transaktion umfasst: Senden eines ersten Agent-Identifikationsinformationen umfassenden Paketes von dem Host-Controller (110) an den Hub (120), und Empfangen einer Bestätigung von dem Hub (120).
  8. Das Verfahren nach Anspruch 6, wobei die zweite Transaktion umfasst: Senden eines dritten Paketes von dem Host-Controller (110) an den Hub (120), Empfangen einer Bestätigung von dem Hub (120) bei dem Host-Controller (110), wobei die Bestätigung Handshake-Informationen darstellt, die während der dritten Transaktion bei dem Hub (120) von dem Agent (130) empfangen werden.
  9. Das Verfahren nach Anspruch 7, wobei die zweite Transaktion umfasst: Senden eines dritten Paketes von dem Host-Controller (110) an den Hub (120), Empfangen eines Datenpaketes von dem Hub (120) bei dem Host-Controller (110), wobei das Datenpaket von dem Agent (130) an den Hub (120) gesendete Informationen umfasst, und Senden einer Bestätigung von dem Host-Controller (110) an den Hub (120).
  10. Das Verfahren nach Anspruch 1, wobei die erste Transaktion umfasst: Senden eines ersten Agent-Identifikationsinformationen umfassenden Paketes von dem Host-Controller (110) an den Hub (120), und Senden eines Datenpaketes von dem Host-Controller (110) an den Hub (120).
  11. Das Verfahren nach Anspruch 1, wobei die erste Transaktion umfasst: Senden eines ersten Agent-Identifikationsinformationen umfassenden Paketes von dem Host-Controller (110) an den Hub (120).
  12. Das Verfahren nach Anspruch 10, wobei die zweite Transaktion umfasst: Senden eines zweiten Agent-Identifikationsinformationen umfassenden Paketes von dem Host-Controller (110) an den Hub (120), Empfangen einer Bestätigung von dem Hub (120) bei dem Host-Controller (110), wobei die Bestätigung Handshake-Informationen darstellt, die während der dritten Transaktion bei dem Hub (120) von dem Agent (130) empfangen werden.
  13. Das Verfahren nach Anspruch 11, wobei die zweite Transaktion umfasst: Senden eines zweiten Paketes von dem Host-Controller (110) an den Hub (120), und Senden eines Datenpaketes von dem Hub (120) an den Host (102).
  14. Das Verfahren nach Anspruch 1, wobei die erste Transaktion umfasst: Senden eines ersten Agent-Identifikationsinformationen umfassenden Paketes von dem Host-Controller (110) an den Hub (120).
  15. Das Verfahren nach Anspruch 14, wobei die zweite Transaktion umfasst: Senden eines zweiten Paketes von dem Host-Controllers (110) an den Hub (120), und Senden eines Datenpaketes von dem Hub (120) an den Host-Controller (110).
  16. Ein digitales System mit einem Host-Controller (110), wobei das digitale System charakterisiert ist durch: den Host-Controller (110) zum Durchführen einer Split-Transaktion zum Übermitteln von Daten zwischen dem Host-Controller (110) und einer Mehrzahl von Agents (130), wobei das digitale System umfasst: einen Gerätetreiber (105), der den Host-Controller (110) zum Durchführen einer ersten Transaktion der Split-Transaktion und einer zweiten Transaktion der Split-Transaktion zwischen dem Host-Controller (110) und einem Hub (120) betreibt, wobei sich die zweite Transaktion von der ersten Transaktion unterscheidet, wobei der Hub (120) basierend auf der ersten Transaktion eine Agent-Transaktion mit einem Agent (130) durchführt, wobei die zweite Transaktion auf der Agent-Transaktion basiert, und wobei der Host-Controller (110), während die Agent-Transaktion durchgeführt wird, eine dritte Transaktion mit einem anderen Agent an dem gleichen Hub wie dem besagten Agent durchführt.
  17. Das System nach Anspruch 16, wobei die erste Transaktion und die zweite Transaktion bei einer ersten Kommunikationsgeschwindigkeit durchgeführt werden.
  18. Das System nach Anspruch 16, wobei die dritte Transaktion bei einer zweiten Kommunikationsgeschwindigkeit durchgeführt wird.
  19. Das System nach Anspruch 16, wobei die erste Transaktion und die zweite Transaktion gemäß einem ersten Protokoll durchgeführt werden.
  20. Das System nach Anspruch 16, wobei die dritte Transaktion gemäß einem zweiten Protokoll durchgeführt wird.
  21. Das System nach Anspruch 16, wobei die erste Transaktion umfasst: Senden eines ersten Agent-Identifikationsinformationen umfassenden Paketes von dem Host-Controller (110) an den Hub (120).
  22. Das System nach Anspruch 16, wobei die zweite Transaktion umfasst: Senden eines zweiten Paketes von dem Host-Controller (110) an den Hub (120).
  23. Das System nach Anspruch 16, wobei die zweite Transaktion umfasst: Empfangen einer Bestätigung von dem Hub (120) bei dem Host-Controller (110).
  24. Ein Hub-Controller (181), der mit einem Host-Controller (110) gekoppelt ist, wobei der Host-Controller eine Split-Transaktion zum Übermitteln von Daten zwischen dem Host-Controller (110) und einer Mehrzahl von Agents (130) durchführt, dadurch charakterisiert: dass der Hub-Controller (181) zum Durchführen einer ersten Transaktion der Split-Transaktion und einer zweiten Transaktion der Split-Transaktion mit dem Host-Controller (110) betreibbar ist, wobei sich die zweite Transaktion von der ersten Transaktion unterscheidet, dass der Host-Controller (110) zum Durchführen einer dritten Transaktion basierend auf der ersten Transaktion mit dem Agent (130) betreibbar ist, dass die zweite Transaktion auf der dritten Transaktion basiert, und dass der Host-Controller (110) zum Eingreifen in eine andere Kommunikation mit einem anderen Agent an dem gleichen Hub wie der Agent zwischen der ersten und zweiten Transaktion der Split-Transaktion betreibbar ist.
  25. Der Hub-Controller (181) nach Anspruch 24, wobei die erste Transaktion und die zweite Transaktion bei einer ersten Kommunikationsgeschwindigkeit durchgeführt werden.
  26. Der Hub-Controller (181) nach Anspruch 24, wobei die dritte Transaktion bei einer zweiten Kommunikationsgeschwindigkeit durchgeführt wird.
  27. Der Hub-Controller (181) nach Anspruch 24, wobei die erste Transaktion und die zweite Transaktion gemäß einem ersten Protokoll durchgeführt werden.
  28. Der Hub-Controller (181) nach Anspruch 24, wobei die dritte Transaktion gemäß einem zweiten Protokoll durchgeführt wird.
  29. Der Hub-Controller (181) nach Anspruch 24, wobei die erste Transaktion umfasst, dass ein erstes Paket von dem Host-Controller (110) an den Hub-Controller (181) gesendet wird, wobei das erste Paket Agent-Identifikationsinformationen umfasst, und die zweite Transaktion umfasst eine bei dem Host-Controller (110) empfangene Bestätigung.
  30. Der Hub-Controller (181) nach Anspruch 24, wobei die zweite Transaktion umfasst, dass ein erstes Paket von dem Host-Controller (110) an den Hub-Controller (181) gesendet wird und dass ein zweites Paket von dem Hub-Controller (181) an den Host-Controller (110) gesendet wird, und das zweite Paket basiert auf von dem Host-Controller (110) empfangenen Daten.
DE60035882T 1999-07-27 2000-04-25 Protokoll einer zerteilten transaktion für ein bussystem Expired - Lifetime DE60035882T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US362991 1999-07-27
US09/362,991 US6813251B1 (en) 1999-07-27 1999-07-27 Split Transaction protocol for a bus system
PCT/US2000/010923 WO2001008018A1 (en) 1999-07-27 2000-04-25 Split transaction protocol for a bus system

Publications (2)

Publication Number Publication Date
DE60035882D1 DE60035882D1 (de) 2007-09-20
DE60035882T2 true DE60035882T2 (de) 2008-04-17

Family

ID=23428340

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60035882T Expired - Lifetime DE60035882T2 (de) 1999-07-27 2000-04-25 Protokoll einer zerteilten transaktion für ein bussystem
DE60045530T Expired - Lifetime DE60045530D1 (de) 1999-07-27 2000-04-25 Protokoll für geteilte Transaktionen für ein Bussystem

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE60045530T Expired - Lifetime DE60045530D1 (de) 1999-07-27 2000-04-25 Protokoll für geteilte Transaktionen für ein Bussystem

Country Status (7)

Country Link
US (8) US6813251B1 (de)
EP (2) EP1203301B1 (de)
CN (1) CN1205562C (de)
DE (2) DE60035882T2 (de)
HK (1) HK1048179A1 (de)
TW (1) TW466409B (de)
WO (1) WO2001008018A1 (de)

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6792495B1 (en) * 1999-07-27 2004-09-14 Intel Corporation Transaction scheduling for a bus system
US6813251B1 (en) * 1999-07-27 2004-11-02 Intel Corporation Split Transaction protocol for a bus system
US7512082B1 (en) * 1999-12-14 2009-03-31 Intel Corporation Tracking transaction status for a bus system providing legacy bus compatibility
US6771664B1 (en) * 1999-12-28 2004-08-03 Intel Corporation Transaction scheduling for a bus system in a multiple speed environment
US6678761B2 (en) 2001-03-30 2004-01-13 Intel Corporation Method and apparatus for budget development under universal serial bus protocol in a multiple speed transmission environment
US6886062B2 (en) 2001-03-30 2005-04-26 Intel Corporation Method and apparatus for improving time constraints and extending limited length cables in a multiple-speed bus
US6728801B2 (en) * 2001-06-29 2004-04-27 Intel Corporation Method and apparatus for period promotion avoidance for hubs
US7028124B2 (en) * 2001-09-26 2006-04-11 Intel Corporation Method and apparatus for dual queue head processing of interrupt endpoints
US6889265B2 (en) 2001-11-05 2005-05-03 Intel Corporation Apparatus and method to allow and synchronize schedule changes in a USB enhanced host controller
US7254115B1 (en) * 2002-08-28 2007-08-07 Advanced Micro Devices, Inc. Split-transaction bus intelligent logic analysis tool
US7359994B1 (en) 2002-08-28 2008-04-15 Advanced Micro Devices, Inc. Split-transaction bus decoder
EP1759299B1 (de) * 2004-06-15 2011-02-02 Nxp B.V. Bus-controller zur handhabung von geteilten transaktionen
US7702825B2 (en) * 2005-06-29 2010-04-20 Intel Corporation Enhancements to universal serial bus (USB) suspend and resume operations
US20070220153A1 (en) * 2006-03-17 2007-09-20 Veerapuneni Satish K Wireless traffic prioritization
US7490255B2 (en) * 2006-06-30 2009-02-10 Intel Corporation Power efficient flow control model for USB asynchronous transfers
US7610101B2 (en) * 2006-11-30 2009-10-27 Cardiac Pacemakers, Inc. RF rejecting lead
EP2131393A4 (de) * 2007-03-23 2011-08-31 Fujitsu Ltd Elektronische anordnung, eine elektronische anordnung anbringende elektronische vorrichtung, einen artikel anbringende elektronische anordnung und verfahren zur herstellung einer elektronischen anordnung
JP5149399B2 (ja) 2008-02-06 2013-02-20 カーディアック ペースメイカーズ, インコーポレイテッド Mriに対応した設計上の特徴を有するリード
US8103360B2 (en) * 2008-05-09 2012-01-24 Foster Arthur J Medical lead coil conductor with spacer element
EP2445577B1 (de) 2009-06-26 2015-08-05 Cardiac Pacemakers, Inc. Medizinische vorrichtung mit eindrähtiger spule mit verbesserter drehmomentübertraungskapazität und verringerter mri-erwärmung
US8335572B2 (en) * 2009-10-08 2012-12-18 Cardiac Pacemakers, Inc. Medical device lead including a flared conductive coil
US9254380B2 (en) 2009-10-19 2016-02-09 Cardiac Pacemakers, Inc. MRI compatible tachycardia lead
US8819183B2 (en) * 2009-12-15 2014-08-26 International Business Machines Corporation Concurrent execution of request processing and analytics of requests
US8874638B2 (en) * 2009-12-15 2014-10-28 International Business Machines Corporation Interactive analytics processing
US8892762B2 (en) * 2009-12-15 2014-11-18 International Business Machines Corporation Multi-granular stream processing
US9750944B2 (en) * 2009-12-30 2017-09-05 Cardiac Pacemakers, Inc. MRI-conditionally safe medical device lead
EP2519305B1 (de) 2009-12-31 2017-07-05 Cardiac Pacemakers, Inc. Bedingt mri-sichere elektrode mit mehrschichtigem leiter
US8391994B2 (en) * 2009-12-31 2013-03-05 Cardiac Pacemakers, Inc. MRI conditionally safe lead with low-profile multi-layer conductor for longitudinal expansion
JP2011198046A (ja) * 2010-03-19 2011-10-06 Kddi Corp 中継装置及び方法
US8825181B2 (en) 2010-08-30 2014-09-02 Cardiac Pacemakers, Inc. Lead conductor with pitch and torque control for MRI conditionally safe use
US8818963B2 (en) 2010-10-29 2014-08-26 Microsoft Corporation Halloween protection in a multi-version database system
KR101866270B1 (ko) * 2011-02-21 2018-07-05 삼성전자주식회사 데이터 공유 시스템 및 방법
JP5844467B2 (ja) 2011-11-04 2016-01-20 カーディアック ペースメイカーズ, インコーポレイテッド ショック用コイルに対して逆巻の内側コイルを含む移植可能な医療機器リード線
JP5930767B2 (ja) * 2012-02-23 2016-06-08 キヤノン株式会社 電子デバイス、通信制御方法
JP5881859B2 (ja) * 2012-04-13 2016-03-09 株式会社日立製作所 ストレージ装置
US8825179B2 (en) 2012-04-20 2014-09-02 Cardiac Pacemakers, Inc. Implantable medical device lead including a unifilar coiled cable
US8954168B2 (en) 2012-06-01 2015-02-10 Cardiac Pacemakers, Inc. Implantable device lead including a distal electrode assembly with a coiled component
US8958889B2 (en) 2012-08-31 2015-02-17 Cardiac Pacemakers, Inc. MRI compatible lead coil
JP6034499B2 (ja) 2012-10-18 2016-11-30 カーディアック ペースメイカーズ, インコーポレイテッド 植込み型医療装置リード線におけるmri適合性を提供するための誘導素子
TWI497306B (zh) 2012-11-29 2015-08-21 Faraday Tech Corp 超高速通用序列匯流排集線器及其相關流量管理方法
FR3001816B1 (fr) * 2013-02-05 2015-03-06 Thales Sa Systeme de processeur multi-utilisateurs de traitement d'informations
US9195712B2 (en) 2013-03-12 2015-11-24 Microsoft Technology Licensing, Llc Method of converting query plans to native code
US10474645B2 (en) 2014-02-24 2019-11-12 Microsoft Technology Licensing, Llc Automatically retrying transactions with split procedure execution
CN106029162A (zh) 2014-02-26 2016-10-12 心脏起搏器股份公司 Mri安全性心动过速引线的构造
US9569375B2 (en) * 2014-05-19 2017-02-14 Microchip Technology Incorporated Unifying class device interface with one host interface by using embedded controller
US20210173784A1 (en) * 2019-12-06 2021-06-10 Alibaba Group Holding Limited Memory control method and system
US11422968B2 (en) * 2020-03-09 2022-08-23 Infineon Technologies LLC Methods, devices and systems for high speed serial bus transactions

Family Cites Families (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3676846A (en) 1968-10-08 1972-07-11 Call A Computer Inc Message buffering communication system
GB8606217D0 (en) 1986-03-13 1986-04-16 Univ Strathclyde Local area network priority control system
US5243703A (en) * 1990-04-18 1993-09-07 Rambus, Inc. Apparatus for synchronously generating clock signals in a data processing system
IL96808A (en) * 1990-04-18 1996-03-31 Rambus Inc Introductory / Origin Circuit Agreed Using High-Performance Brokerage
US5291614A (en) 1991-09-03 1994-03-01 International Business Machines Corporation Real-time, concurrent, multifunction digital signal processor subsystem for personal computers
JP2888004B2 (ja) * 1992-01-24 1999-05-10 日本電気株式会社 伝送回線インタフェース回路
US5553310A (en) * 1992-10-02 1996-09-03 Compaq Computer Corporation Split transactions and pipelined arbitration of microprocessors in multiprocessing computer systems
US5687388A (en) * 1992-12-08 1997-11-11 Compaq Computer Corporation Scalable tree structured high speed input/output subsystem architecture
US6330629B1 (en) * 1993-02-11 2001-12-11 Hitachi, Ltd. Information processing system
US5708794A (en) 1993-08-10 1998-01-13 Dell Usa, L.P. Multi-purpose usage of transaction backoff and bus architecture supporting same
US5469435A (en) * 1994-01-25 1995-11-21 Apple Computer, Inc. Bus deadlock avoidance during master split-transactions
DE19581234B4 (de) * 1994-10-31 2008-03-20 Intel Corp., Santa Clara Bussteuereinrichtung und Verfahren für eine hierarchische serielle Busanordnung unter Verwendung von Kommunikationspaketen
US5699516A (en) * 1994-12-22 1997-12-16 Motorola, Inc. Method and apparatus for implementing a in-order termination bus protocol within a data processing system
US5838991A (en) 1994-12-29 1998-11-17 International Business Machines Corporation Preemptable idle time activities for constant data delivery by determining whether initiating a host command will conflict with an idle time activity being executed
US5594882A (en) 1995-01-04 1997-01-14 Intel Corporation PCI split transactions utilizing dual address cycle
US5564114A (en) * 1995-01-09 1996-10-08 Cirrus Logic Inc. Method and an arrangement for handshaking on a bus to transfer information between devices in a computer system
US5630174A (en) * 1995-02-03 1997-05-13 Cirrus Logic, Inc. Adapter for detecting whether a peripheral is standard or multimedia type format and selectively switching the peripheral to couple or bypass the system bus
US5689660A (en) * 1995-02-28 1997-11-18 Hewlett-Packard Co. Enhanced peripheral component interconnect bus protocol
US5799207A (en) * 1995-03-28 1998-08-25 Industrial Technology Research Institute Non-blocking peripheral access architecture having a register configure to indicate a path selection for data transfer between a master, memory, and an I/O device
US5704053A (en) * 1995-05-18 1997-12-30 Hewlett-Packard Company Efficient explicit data prefetching analysis and code generation in a low-level optimizer for inserting prefetch instructions into loops of applications
US5832492A (en) 1995-09-05 1998-11-03 Compaq Computer Corporation Method of scheduling interrupts to the linked lists of transfer descriptors scheduled at intervals on a serial bus
US5793994A (en) * 1996-01-31 1998-08-11 3Com Corporation Synchronous event posting by a high throughput bus
US5819111A (en) 1996-03-15 1998-10-06 Adobe Systems, Inc. System for managing transfer of data by delaying flow controlling of data through the interface controller until the run length encoded data transfer is complete
US5911051A (en) * 1996-03-29 1999-06-08 Intel Corporation High-throughput interconnect allowing bus transactions based on partial access requests
US5784581A (en) * 1996-05-03 1998-07-21 Intel Corporation Apparatus and method for operating a peripheral device as either a master device or a slave device
US6032271A (en) * 1996-06-05 2000-02-29 Compaq Computer Corporation Method and apparatus for identifying faulty devices in a computer system
US5918070A (en) * 1996-10-18 1999-06-29 Samsung Electronics Co., Ltd. DMA controller with channel tagging
US5974480A (en) * 1996-10-18 1999-10-26 Samsung Electronics Co., Ltd. DMA controller which receives size data for each DMA channel
US5915087A (en) * 1996-12-12 1999-06-22 Secure Computing Corporation Transparent security proxy for unreliable message exchange protocols
US5890015A (en) 1996-12-20 1999-03-30 Intel Corporation Method and apparatus for implementing a wireless universal serial bus host controller by interfacing a universal serial bus hub as a universal serial bus device
US6040871A (en) * 1996-12-27 2000-03-21 Lucent Technologies Inc. Method and apparatus for synchronizing video signals
US5870567A (en) * 1996-12-31 1999-02-09 Compaq Computer Corporation Delayed transaction protocol for computer system bus
US6098134A (en) * 1996-12-31 2000-08-01 Compaq Computer Corp. Lock protocol for PCI bus using an additional "superlock" signal on the system bus
EP0859326A3 (de) * 1997-02-14 1999-05-12 Canon Kabushiki Kaisha Vorrichtung, System und Verfahren zur Datenübertragung und Vorrichtung zur Bildverarbeitung
EP0859323B1 (de) * 1997-02-14 2007-03-21 Canon Kabushiki Kaisha Vorrichtung, System und Verfahren zur Datenübertragung und Vorrichtung zur Bildverarbeitung
US5909594A (en) * 1997-02-24 1999-06-01 Silicon Graphics, Inc. System for communications where first priority data transfer is not disturbed by second priority data transfer and where allocated bandwidth is removed when process terminates abnormally
US6046762A (en) * 1997-04-01 2000-04-04 Cosmocom, Inc. Multimedia telecommunication automatic call distribution system
US5875313A (en) * 1997-04-08 1999-02-23 National Instruments Corporation PCI bus to IEEE 1394 bus translator employing write pipe-lining and sequential write combining
US5944805A (en) * 1997-08-21 1999-08-31 Advanced Micro Devices, Inc. System and method for transmitting data upon an address portion of a computer system bus during periods of maximum utilization of a data portion of the bus
US6108736A (en) * 1997-09-22 2000-08-22 Intel Corporation System and method of flow control for a high speed bus
US6353866B1 (en) * 1998-01-07 2002-03-05 National Semiconductor Corporation Apparatus and method for initializing a universal serial bus device
KR19990070665A (ko) * 1998-02-23 1999-09-15 윤종용 유에스비를 이용한 디스플레이 장치의 무선 키입력 처리장치
US6483839B1 (en) 1998-03-18 2002-11-19 Conexant Systems, Inc. Apparatus and method for scheduling multiple and simultaneous traffic in guaranteed frame rate in ATM communication system
US6145030A (en) * 1998-03-27 2000-11-07 Intel Corporation System for managing input/output address accesses at a bridge/memory controller
JP3994360B2 (ja) * 1998-05-20 2007-10-17 ソニー株式会社 情報処理装置、情報処理方法、および記録媒体
US6185520B1 (en) * 1998-05-22 2001-02-06 3Com Corporation Method and system for bus switching data transfers
JP3841132B2 (ja) 1998-06-01 2006-11-01 株式会社ソニー・コンピュータエンタテインメント 入力位置検出装置及びエンタテインメントシステム
JP2000013423A (ja) * 1998-06-26 2000-01-14 Sony Corp 情報処理装置および方法、並びに提供媒体
JP3922817B2 (ja) * 1998-06-30 2007-05-30 株式会社東芝 通信ノード及び通信端末
US6418538B1 (en) * 1998-07-06 2002-07-09 Intel Corporation Method and system for scheduling transactions over a half duplex link
US6185642B1 (en) * 1998-07-15 2001-02-06 International Business Machines Corporation Bus for high frequency operation with backward compatibility and hot-plug ability
US6266731B1 (en) * 1998-09-03 2001-07-24 Compaq Computer Corporation High speed peripheral interconnect apparatus, method and system
US6067591A (en) 1998-10-08 2000-05-23 Intel Corporation Method and apparatus for avoidance of invalid transactions in a bus host controller
US6145039A (en) * 1998-11-03 2000-11-07 Intel Corporation Method and apparatus for an improved interface between computer components
US6301627B1 (en) * 1998-12-18 2001-10-09 International Business Machines Corporation Method/system for identifying delayed predetermined information transfer request as bypassable by subsequently-generated information transfer request using bypass enable bit in bridge translation control entry
US7505455B1 (en) * 1999-03-19 2009-03-17 F5 Networks, Inc. Optimizations for tunneling between a bus and a network
US7349391B2 (en) * 1999-03-19 2008-03-25 F5 Networks, Inc. Tunneling between a bus and a network
US6353459B1 (en) * 1999-03-31 2002-03-05 Teralogic, Inc. Method and apparatus for down conversion of video data
US6389501B1 (en) 1999-05-10 2002-05-14 Intel Corporation I/O peripheral device for use in a store-and-forward segment of a peripheral bus
US6629186B1 (en) 1999-05-10 2003-09-30 Intel Corporation Bus controller and associated device drivers for use to control a peripheral bus having at least one store-and-forward segment
US6546018B1 (en) 1999-05-10 2003-04-08 Intel Corporation Digital system having a peripheral bus structure with at least one store-and-forward segment
US6813251B1 (en) * 1999-07-27 2004-11-02 Intel Corporation Split Transaction protocol for a bus system
US6701399B1 (en) 2000-02-29 2004-03-02 Compaq Information Technologies Group Priority mechanism for scheduling isochronous and asynchronous transactions on a shared bus
US6728801B2 (en) 2001-06-29 2004-04-27 Intel Corporation Method and apparatus for period promotion avoidance for hubs
US7875871B2 (en) * 2006-03-31 2011-01-25 Sandisk 3D Llc Heterojunction device comprising a semiconductor and a resistivity-switching oxide or nitride

Also Published As

Publication number Publication date
US9558142B2 (en) 2017-01-31
US20110099308A1 (en) 2011-04-28
US7675871B2 (en) 2010-03-09
US7886087B2 (en) 2011-02-08
US6813251B1 (en) 2004-11-02
US20170255587A1 (en) 2017-09-07
US9600436B2 (en) 2017-03-21
US8677032B2 (en) 2014-03-18
US20140281073A1 (en) 2014-09-18
DE60045530D1 (de) 2011-02-24
CN1376281A (zh) 2002-10-23
WO2001008018A1 (en) 2001-02-01
EP1850239A1 (de) 2007-10-31
EP1850239B1 (de) 2011-01-12
US20050033892A1 (en) 2005-02-10
EP1203301A1 (de) 2002-05-08
CN1205562C (zh) 2005-06-08
DE60035882D1 (de) 2007-09-20
US9892081B2 (en) 2018-02-13
US20150015725A1 (en) 2015-01-15
HK1048179A1 (en) 2003-03-21
US20100169516A1 (en) 2010-07-01
US20170249277A1 (en) 2017-08-31
TW466409B (en) 2001-12-01
EP1203301B1 (de) 2007-08-08

Similar Documents

Publication Publication Date Title
DE60035882T2 (de) Protokoll einer zerteilten transaktion für ein bussystem
DE19581234B4 (de) Bussteuereinrichtung und Verfahren für eine hierarchische serielle Busanordnung unter Verwendung von Kommunikationspaketen
DE60002446T2 (de) Verfahren und vorrichtung zur erweiterung des usb-protokollbereichs
DE69932400T2 (de) Steuerungsvorrichtung für einen Portverwalter zur Verbindung von verschiedenen Funktionsmodulen
DE60111551T2 (de) Mechanismus zur vervollständigung von nachrichten im speicher
DE69836426T2 (de) Steuergerät für einen universellen seriellen Bus
DE69533790T2 (de) Telekommunikationsschnittstelle für einheitliche Handhabung von variierten analog-abgeleiteten und digitalen Datenströmen
DE19581859B4 (de) Steckverbinderanordnung zur Kopplung einer Einheit mit einem SCSI-Bus
DE69912017T2 (de) Peripheriegerät und Steuerverfahren dafür
DE60212626T2 (de) Endknotenunterteilung mittels lokaler identifikatoren
DE69930490T2 (de) Kommunikationsverfahren, Sendungsverfahren und Empfangsverfahren und Geräte zu ihrer Durchführung
DE69532383T2 (de) Verfahren und vorrichtung zur dynamischen erzeugung und erhaltung von rahmenbasierten abfrageprogrammen für das abfragen von isochronen und asynchronen funktionen, die wartezeiten und bandbreiten für die isochronen funktionen garantieren
DE69535108T2 (de) Verfahren und apparat zum herstellen einer seriellen schnittstelle für isochrone und asynchrone peripheriegeräte
DE69634914T2 (de) Hybrides begrenztes konkurrenz- und abfrageprotokoll
DE69821050T2 (de) Datenstromdifferenzierungssystem für Endgerätemulator
DE19900345B4 (de) Schnittstellenmodul für einen Universellen Seriellen Bus (USB) zur Verbindung mit einem USB über eine Programmierschnittstelle für eine USB-Funktion und Vorrichtung zum Anschluß an einen universellen seriellen Bus
DE60132872T2 (de) Anordnung und Verfahren für eine Schnittstelleneinheit um Daten zwischen einem Hauptprozessor und einem digitalen Signalprozessor im asynchronen Übertragungsmodus zu übertragen
DE69929142T2 (de) Verfahren zur Bilddatenübertragung unter Verwendung von einem IEEE 1394 Bus
DE19900369A9 (de) Vorrichtung und Verfahren zur Ausführung einer Steuerübertragung auf einem Universal Serial Bus
DE69928603T2 (de) Medienzugriffssteuerung
DE69829840T2 (de) Medienzugriffskontroller und Medienunabhängige Schnittstelle(MII) zum Verbinden an eine physikalische Schicht Vorrichtung
DE3608173A1 (de) Datenverarbeitungssystem und verfahren zur uebertragung von daten ueber ein datenuebertragungsmedium zwischen mehreren datenverarbeitungsgeraeten
DE60038264T2 (de) Verfahren zur Vorverarbeitung von Datenpaketen in einer Busschnittstelle
DE19900290A9 (de) Verfahren zum Betreiben einer universellen seriellen Buseinrichtung und universelle serielle Buseinrichtung
WO2012084696A1 (de) Verfahren und vorrichtung zur seriellen datenübertragung mit zusätzlich eingefügten daten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition