-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Die Erfindung betrifft allgemein
Hostcontroller wie etwa USB-Hostcontroller (USB: Universal Serial
Bus) und zugehörige
Verfahren und insbesondere Hostcontroller zum Abwickeln des Datenverkehrs zwischen
wenigstens einem Peripheriegerät
und einem Computersystem.
-
2. Beschreibung des Standes
der Technik
-
USB wurde ursprünglich im Jahre 1995 entwickelt,
um einen externen Erweiterungsbus zu definieren, der die Verbindung
zusätzlicher
Peripheriegeräte
an ein Computersystem erleichtert. Die USB-Technik wird durch PC-Hostcontrollerhardware und
-software (PC: Personalcomputer) implementiert, sowie durch peripheriefreundliche
Master-Slave-Protokolle, und sie ermöglicht robuste Verbindungen
und Kabelanordnungen. USB-Systeme sind durch Mehrport-Hubs erweiterbar.
-
In USB-Systemen besteht die Rolle
der Systemsoftware darin, eine vereinheitlichte Sicht auf die Eingabe/Ausgabe-Architektur
für die
gesamte Anwendungssoftware dadurch bereitzustellen, dass Hardwareimplementierungsdetails
verdeckt werden. Die Systemsoftware verwaltet insbesondere das dynamische
Anschließen
und Abtrennen von Peripheriegeräten
und kommuniziert mit dem Peripheriegerät, um dessen Identität zu ermitteln.
Während
der Laufzeit veranlasst der Host Transaktionen zu spezifischen Peripheriegeräten, und
jedes Peripheriegerät akzeptiert
seine Transaktionen und antwortet demgemäß.
-
Hubs werden in das System eingefügt, um eine
zusätzliche
Konnektivität
für periphere
USB-Geräte
bereitzustellen und um angeschlossene Geräte kontrolliert mit Leistung
zu versorgen (Powermanagement). Die Peripheriegeräte sind
Slaves, die auf vom Host gesendete Anforderungstransaktionen reagieren
müssen.
Solche Anforderungstransaktionen enthalten Requests (Anforderungen,
Anfragen) nach detaillierten Informationen über das Gerät und dessen Konfiguration.
-
Während
diese Funktionen und Protokolle bereits in der USB-1.1-Spezifikation
implementiert waren, wurde diese Technik weiter verbessert, um eine
höher performante
Schnittstelle bereitzustellen. 1 verdeutlicht
ein beispielhaftes USB-2.0-System, das einen Hostcontroller 100,
eine Anzahl von USB-Geräten 115, 120, 125, 130 und
zwei Hubs 105, 110 umfasst. In dem System von 1 sind die Hubs 105, 110 zur
Erhöhung
der Konnektivität
eingefügt, jedoch
können
die USB-Geräte
in anderen USB-2.0-Systemen direkt mit dem Hostcontroller 100 verbunden
sein.
-
Wie oben erwähnt, stellt USB 2.0 eine höher performante
Schnittstelle bereit, und die Geschwindigkeitsverbesserung kann
bis zu einem Faktor von 40 betragen. Darüber hinaus ist USB 2.0, wie
aus 1 ersichtlich, rückwärtskompatibel
zu USB 1.1, da es gestattet, USB-1.1-Geräte 120, 125, 130 zu verbinden,
um von demselben Hostcontroller 100 betrieben zu werden.
Es können
sogar USB-1.1-Hubs 110 verbunden werden.
-
Wie aus 1 gesehen werden kann, kann ein USB-1.1-Gerät 120 direkt
mit einem USB-2.0-Hub 105 verbunden werden. Darüber hinaus
kann das USB-1.1-Gerät auch direkt
mit dem Hostcontroller 100 verbunden werden. Dies wird durch
die Fähigkeit
von USB-2.0-Hostcontrollern und -Hubs ermöglicht, sowohl höhere als
auch niedrigere Transmissionsgeschwindigkeiten auf Zwischengerätebasis
zu verhandeln.
-
Wird nun zu 2 übergegangen,
so wird die Systemsoftware und -hardware eines USB-2.0-Systems verdeutlicht.
Die Systemkomponenten können
hierarchisch organisiert sein, indem mehrere Schichten wie in der
Figur gezeigt definiert werden.
-
In der allerobersten Schicht läuft die
Clienttreibersoftware 200 auf dem Host-PC, die einem bestimmten USB-Gerät 230 entspricht.
Die Clientsoftware ist typischerweise Teil des Betriebssystem oder wird
mit dem Gerät
geliefert.
-
Der USB-Treiber 205 ist
ein Systemsoftwarebustreiber, der die Details des bestimmten Hostcontrollertreibers 210, 220 für ein bestimmtes
Betriebssystem abstrahiert. Die Hostcontrollertreiber 210, 220 stellen
eine Softwareschicht zwischen einer speziellen Hardware 215, 225, 230 und
dem USB-Treiber 205 bereit, um eine Treiberhardwareschnittstelle bereitzustellen.
-
Während
die soweit diskutierten Schichten softwareimplementiert sind, enthält die alleroberste Hardwarekomponentenschicht
die Hostcontroller 215, 225. Diese Controller
sind mit dem USB-Gerät 230 verbunden,
das die Endnutzerfunktion bereitstellt. Bei einem gegebenen USB-Gerät ist das
Gerät natürlich nur
mit einem der Hostcontroller 215, 225 verbunden.
-
Wie aus der Figur ersichtlich ist,
gibt einen Hostcontroller 225, der ein erweiteter Hostcontroller (EHC:
Enhanced Host Controller) für
die Hochgeschwindigkeits-USB-2.0-Funktionalität ist. Dieser Hostcontroller
arbeitet gemäß der EHCI-Spezifikation
(EHCI: Enhanced Host Controller Interface) für USB 2.0. Auf der
Softwareseite ist dem Hostcontroller 225 ein spezifischer
Hostcontrollertreiber EHCD 220 zugeordnet.
-
Ferner gibt es Hostcontroller 215 für Voll- und
Niedergeschwindigkeitsvorgänge.
UHCI (Universal Host Controller Interface) oder OHCI (Open Host Controller
Interface) sind die zwei Industriestandards, die in den universellen
oder offenen Hostcontrollern (UHC/OHC) 215 zur Bereitstellung von USB-1.1-Hostcontrollerschnittstellen
angewendet werden. Den Hostcontrollern 215 sind universelle/offene
Hostcontrollertreiber (UHCD/OHCD) 210 in der untersten Softwareschicht
zugeordnet.
-
Somit umfasst das USB-2.0-gemäße Hostcontrollersystem
eine Treibersoftware und Hostcontrollerhardware, die der EHCI-Spezifikation
genügen müssen. Während diese
Spezifikation die Schnittstelle auf Registerebene sowie zugehörige speicherresidente
Datenstrukturen definiert, enthält
sie weder eine Definition noch eine Beschreibung der Hardwarearchitektur,
die erforderlich ist, um einen entsprechenden Hostcontroller aufzubauen.
-
Wird nun auf 3 Bezug genommen, so sind die Hardwarekomponenten
eines gewöhnlichen Motherboardlayouts
dargestellt. Die Basiselemente, die auf einem Motherboard zu finden
sind, schließen die
CPU (Central Processing Unit, zentrale Verarbeitungseinheit) 300,
eine Northbridge 305, eine Southbridge 310 und
einen Systemspeicher 315 ein. Die Northbridge 305 ist
gewöhnlicherweise
ein einzelner Chip in einem Core-Logic-Chipsatz, der den Prozessor 300 mit
dem Systemspeicher 315 und dem AGP-Bus (AGP: Accelerated
Graphic Port) und dem PCI-Bus (PCI: Peripheral Component Interface)
verbindet. Der PCI-Bus
wird in Personalcomputern gewöhnlicherweise
zur Bereitstellung eines Datenpfades zwischen dem Prozessor und
Peripheriegeräten wie
etwa Videokarten, Soundkarten, Netzwerkschnittstellenkarten und
Modems verwendet. Der AGP-Bus ist ein Hochgeschwindigkeitsgrafikerweiterungsbus,
der den Displayadapter und den Systemspeicher 315 direkt
verbindet. AGP arbeitet unabhängig
von dem PCI-Bus. Es ist anzumerken, dass andere Motherboardlayouts
existieren, die keine Northbridge enthalten oder eine Northbridge
ohne AGP- oder PCI-Optionen aufweisen.
-
Die Souhbridge 310 ist üblicherweise
der Chip in einem System-Core-Logic-Chipsatz, der den IDE-Bus (IDE: Integrated
Drive Electronics) oder EIDE-Bus (EIDE: Enhanced IDE) steuert, den USB-Bus
steuert, der eine Plug-and-Play-Unterstützung ermöglicht,
der eine PCI-ISA-Brücke
(ISA: Industry Standard Architecture) steuert, der den Tastatur/Maus-Controller
verwaltet, der Powermanagementfeatures bereitstellt und andere Peripheriegeräte steuert.
-
USB-Hostcontroller und andere Hostcontroller
in Southbridges oder I/O-Hubs sind Hardwarekomponenten, die in ihrer
Struktur extrem komplex sind. Es können somit Fehler im Betrieb
solcher Hostcontroller auftreten und es ist üblicherweise schwierig festzustellen,
ob solche Fehler durch Hardwarekomponenten oder durch den Softwaretreiber oder
irgendeine andere Hardware- oder Softwarekomponente verursacht wurden.
Aus diesem Grund kann es herkömmlichen
Hostcontrollern oft an Zuverlässigkeit
fehlen.
-
ÜBERSICHT ÜBER DIE
ERFINDUNG
-
Verbesserte Hostcontroller, Computersysteme
und zugehörige
Verfahren werden bereitgestellt, die die gesamte Arbeitszuverlässigkeit
erhöhen
können.
-
In einer Ausgestaltung wird ein USB-Hostcontroller
zum Abwickeln des Datenverkehrs zwischen wenigstens einem USB-Gerät und einem Computersystem
bereitgestellt. Der Hostcontroller hat einen Registersatz, der wenigstens
ein Hostcontrollerfähigkeitsregister
umfasst, das Daten speichert, die Betriebsarten angeben, zu denen
der USB-Hostcontroller imstande ist, sowie wenigstens ein Hostcontrollerbetriebsregister,
das Daten speichert zum Steuern des Betriebs des USB-Hostcontrollers.
Das wenigstens eine Hostcontrollerfähigkeitsregister speichert
Daten, die verfügbare
Diagnosemodi angeben, die der Hostcontroller einnehmen kann. Das
wenigstens eine Hostcontrollerbetriebsregister speichert Diagnosedaten
zum Steuern des Betriebs des USB-Hostcontrollers in Diagnosemodi.
-
In einer anderen Ausgestaltung kann
ein Hostcontroller zum Steuern des Datenverkehrs zu und von wenigstens
einem Peripheriegerät
bereitgestellt werden, das mit einem Computersystem über einen
seriellen Bus verbunden ist. Der Hostcontroller weist einen Registersatz
auf, der wenigstens ein Hostcontrollerfähigkeitsregister umfasst, das
Daten speichert, die Betriebsarten angeben, zu denen der Hostcontroller
imstande ist, sowie wenigstens ein Hostcontrollerbetriebsregister,
das Daten speichert zum Steuern des Betriebs des Hostcontrollers.
Das wenigstens eine Hostcontrollerfähigkeitsregister speichert
Daten, die verfügbare
Diagnosemodi angeben, die der Hostcontroller einnehmen kann. Das
wenigstens eine Hostcontrollerbetriebsregister speichert Diagnosedaten
zum Steuern des Betriebs des Hostcontrollers in Diagnosemodi.
-
In einer weiteren Ausgestaltung wird
ein Verfahren zum Betreiben eines USB-Hostcontrollers zum Abwickeln des Datenverkehrs
zwischen wenigstens einem USB-Gerät und einem Computersystem bereitgestellt.
Der USB-Hostcontroller weist einen Registersatz auf. Das Verfahren
umfasst das Speichern von Daten, die Betriebsarten angeben, zu denen
der USB-Hostcontroller imstande ist, in wenigstens einem Hostcontrollerfähigkeitsregister,
und das Speichern von Daten zum Steuern des Betriebs des USB-Hostcontrollers
in wenigstens einem Hostcontrollerbetriebsregister. Die Daten, die
mögliche
Betriebsarten angeben, umfassen Daten, die verfügbare Diagnosemodi angeben,
die der USB-Hostcontroller
einnehmen kann. Die Daten zum Steuern des Betriebs des USB-Hostcontrollers umfassen
Diagnosedaten zum Steuern des Betriebs des UBS-Hostcontrollers in Diagnosemodi.
-
In noch einer weiteren Ausgestaltung
wird ein Verfahren zum Betreiben eines Hostcontrollers bereitgestellt,
um den Datenverkehr zu und von wenigstens einem Peripheriegerät zu steuern,
das mit einem Computersystem über
einen seriellen Bus verbunden ist. Der Hostcontroller weist einen
Registersatz auf. Das Verfahren umfasst das Speichern von Daten,
die Betriebsarten angeben, zu denen der Hostcontroller imstande
ist, in wenigstens einem Hostcontrollerfähigkeitsregister, und das Speichern von
Daten zum Steuern des Betriebs des Hostcontrollers in wenigstens
einem Hostcontrollerbetriebsregister. Die Daten, die mögliche Betriebsarten
angeben, umfassen Daten, die verfügbare Diagnosemodi angeben,
die der Hostcontroller einnehmen kann. Die Daten zum Steuern des
Betriebs des Hostcontrollers umfassen Diagnosedaten zum Steuern
des Betriebs des Hostcontrollers in Diagnosemodi.
-
In einer noch weiteren Ausgestaltung
wird ein Computersystem bereitgestellt, das einen Hostcontroller
zum Steuern des Datenverkehrs zu und von wenigstens einem Peripheriegerät umfasst,
das mit dem Computersystem über
einen seriellen Bus verbunden ist. Der Hostcontroller weist einen
Registersatz auf, der wenigstens ein Hostcontrollerfähigkeitsregister
umfasst, das Daten speichert, die Betriebsarten angeben, zu denen
der Hostcontroller imstande ist, sowie wenigstens ein Hostcontrollerbetriebsregister,
das Daten zum Steuern des Betriebs des Hostcontrollers speichert.
Das wenigstens eine Hostcontrollerfähigkeitsregister speichert
Daten, die verfügbare
Diagnosemodi angeben, die der Hostcontroller einnehmen kann. Das
wenigstens eine Hostcontrollerbetriebsregister speichert Diagnosedaten zum
Steuern des Betriebs des Hostcontrollers in Diagnosemodi.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die beigefügten Zeichnungen sind in die
Beschreibung eingefügt
und bilden einen Teil derselben zum Zwecke der Erläuterung
der Prinzipien der Erfindung. Die Zeichnungen sind nicht als die
Erfindung nur auf die verdeutlichten und beschriebenen Beispiele,
wie die Erfindung gemacht und verwendet werden kann, beschränkend zu
verstehen. Weitere Merkmale und Vorteile werden aus der folgenden
und genaueren Beschreibung der Erfindung ersichtlich werden, wie
in den beigefügten
Zeichnungen verdeutlicht, in denen:
-
1 ein
beispielhaftes USB-2.0-gemäßes System
verdeutlicht;
-
2 die
Hardware- und Softwarekomponentenschichten in dem System von 1 verdeutlicht;
-
3 ein
gewöhnliches
Motherboardlayout verdeutlicht;
-
4 die
Hauptkomponenten des USB-2.0-gemäßen Hostcontrollers
gemäß einer
Ausgestaltung verdeutlicht;
-
5 ein
Blockdiagramm ist, das die Komponenten des erweiterten Hostcontrollers
verdeutlicht, der eine Komponente der Anordnung von 4 ist;
-
6 ein
Blockdiagramm ist, das Register in einem Register-File verdeutlicht,
das eine Hardwarekomponente der Anordnung von 5 ist;
-
7 den
Inhalt der Fähigkeitsregister
in dem Register-File von 6 verdeutlicht;
-
8 den
Inhalt des Betriebsregisters in dem Register-File von 6 verdeutlicht; und
-
9 ein
Flussdiagramm ist, das den Prozess des Verwendens der Register zu
Diagnosezwecken gemäß einer
Ausgestaltung verdeutlicht.
-
DETAILLIERTE
BESCHREIBUNG DER ERFINDUNG
-
Die verdeutlichten Ausgestaltungen
der vorliegenden Erfindung werden unter Bezugnahme auf die Zeichnungen
beschrieben werden, in denen gleiche Elemente und Strukturen durch
gleiche Bezugszeichen angegeben sind.
-
Wird nun auf die Zeichnungen und
insbesondere auf 4 Bezug
genommen, so sind die Hauptkomponenten eines USB-2.0-gemäßen Hostcontrollers 400 gemäß einer
Ausgestaltung gezeigt. Im Allgemeinen umfasst der Hostcontroller
drei Hauptkomponenten: den erweiterten Hostcontroller (EHC) 225, einen
oder mehrere Begleithostcontroller 215 und den Port-Router 415.
-
Der erweiterte Hostcontroller 225 wickelt
den USB-2.0-Hochgeschwindigkeitsverkehr ab. Zusätzlich steuert er den Port-Router 415.
-
In der Begleithostcontrollereinheit 215 der vorliegenden
Ausgestaltung gibt es zwei OHCI-gemäße Hostcontroller, OHC0 405 und
OHC1 410. Diese Controller wickeln den gesamten USB-1.1-gemäßen Verkehr
ab und können
die Legacy-Tastaturemulation
für nicht
USB-gemäße Umgebungen
enthalten.
-
Der Port-Router 415 weist
den physikalischen Portschnittstellen ihre jeweiligen Eigner zu. Die
Eignerschaft wird durch EHC-Register gesteuert und standardmäßig werden
alle Ports auf die Begleithostcontroller geroutet, um die Funktion
eines Systems zu ermöglichen,
das nur USB-1.1-gemäße Treiber
aufweist. Wenn ein USB-2.0-gemäßer Treiber
in dem System vorhanden ist, wird der Port-Router die Ports entweder
einem Begleithostcontroller 405, 410 für Nieder-
und Vollgeschwindigkeitsgeräte
und -hubs (USB-1.1-Verkehr) oder dem EHC 225 für Hochgeschwindigkeitsgeräte und -hubs
zuweisen.
-
Das bedeutet, dass der in 4 gezeigte USB-2.0-Hostcontroller
der EHCI-Spezifikation
genügt
und die Verwendung bestehender OHCI-USB-1.1-Hostcontroller ermöglicht, wobei eine minimale
Anpassung erforderlich ist, um eine Schnittstelle zu dem Port-Routerblock 415 anstelle
zu den physikalischen USB-1.1-Geräte auszubilden.
-
Eine Plug-and-Play-Konfiguration
kann von jedem Hostcontroller 405, 410, 225 separat
behandelt werden. Es kann eine durch EHCI auferlegte Beschränkung geben,
wonach die OHCI-Controller 215 niedrigere Funktionsnummern
haben müssen
als der EHCI-Controller 225.
-
Der USB-2.0-gemäße Hostcontroller von 4 kann als Hardwarearchitektur
definiert sein, um einen EHCI-gemäßen Hostcontroller zur Integration
in eine Southbridge 310 zu implementieren. Der Hostcontroller
sitzt dann zwischen den analogen USB-2-Eingabe/Ausgabe-Pins und
einem Verbindungsschnittstellenmodul, um in Upstreamrichtung eine
Schnittstelle in Richtung auf den Systemspeicher bereitzustellen,
z.B. eine Schnittstelle zu einer Northbridge, wenn eine solche in
dem System vorhanden ist. Diese Schnittstelle kann eine interne
HyperTransportTM-Schnittstelle sein. Die
HyperTransport-Technologie ist eine hochperformante Hochgeschwindigkeits-Punkt-zu-Punkt-Verbindung,
um integrierte Schaltungen auf einem Motherboard miteinander zu
verbinden. Sie kann signifikant schneller sein als ein PCI-Bus bei
einer äquivalenten
Anzahl von Pins. Die HyperTransport-Technologie wurde entworfen,
um eine signifikant höhere
Bandbreite als aktuelle Technologien bereitzustellen, um Antworten mit
geringer Latenz zu verwenden, um eine geringe Pinzahl bereitzustellen,
um zu Legacy-PC-Bussen kompatibel zu sein, um auf neue Systemnetzwerkarchitekturbusse
erweiterbar zu sein, um für
Betriebssysteme transparent zu sein, und um geringe Auswirkungen
auf Peripherietreiber zu haben.
-
Somit wird in der Ausgestaltung von 4 ein HyperTransport-basierter
USB-Hostcontroller
bereitgestellt, bei dem ein erweiterter Hostcontroller 225 für die Abwicklung
des gesamten Hochgeschwindigkeits-USB-Verkehrs sowie für die Steuerung
der Porteignerschaft für
sich selbst und die Begleitcontroller 215 über den
Port-Router 415 verantwortlicht ist. Nach einem Rücksetzen
beim Einschalten oder einem softwaregesteuerten Reset des EHC 225 kann
er standardmäßig einen
Zustand einnehmen, in dem alle Ports von den Begleithostcontrollern 215 besessen
und gesteuert werden, alle Betriebsregister ihre jeweiligen Defaultwerte
aufweisen und der EHC 225 angehalten ist, d.h. er weder
Deskriptoren aus dem Systemspeicher 315 holt noch irgendeine USB-Aktivität herausgibt.
Im Normalbetrieb kann der EHC 225 asynchrone und Interrupttransfers
von einer periodischen Liste verarbeiten sowie Bulk und Steuerungen
von einer asynchronen Liste. Beide Listen können leer sein oder ihre Abarbeitung
kann softwaregesteuert ruhen.
-
Wird nun auf 5 Bezug genommen, so werden die Komponenten
des erweiterten Hostcontrollers EHC 225 in weiteren Einzelheiten
gezeigt. Wie aus der Figur gesehen werden kann, kann der erweiterte
Hostcontroller 225 in eine 100-MHz-Core-Taktdomäne und eine
60-MHz-Taktdomäne
aufgeteilt werden. Während
die 60-MHz-Taktdomäne
die Schaltung für
das Routen von Transaktionen auf physikalische Geräte enthält, führt die
100-MHz-Taktdomäne
die eigentliche Deskriptorverarbeitung durch. Es ist anzumerken,
dass die Domänen
in anderen Ausgestaltungen Taktraten aufweisen können, die von den obigen Werten
100 MHz und 60 MHz abweichen. In diesen Ausgestaltungen weist der
Deskriptorverarbeitungsdomänentakt
noch eine Frequenz auf, die wenigstens so hoch wie die der anderen
Domäne
ist, oder höher.
-
In der 100-MHz-Domäne wird
die Abwicklung des Datenverkehrs zu und von dem Systemspeicher durch
den Stub 500 bewerkstelligt. Der Stub 500 weist
die internen Quellen und Senken den jeweiligen HyperTransport-Strömen zu,
d.h. Posted Requests, Non-Posted Requests, Responses (Antworten).
Der Stub 500 arbitriert die interne HyperTransport-Schnittstelle
zwischen allen internen Busmastern, d.h. der DMA-Empfangseinrichtung
(DMA: Direct Memory Access) 510, dem Deskriptorcache 545, der
Deskriptorverarbeitungseinrichtung 525 und der DMA-Sendeeinrichtung 550.
Somit arbitriert der Stub 500 zwischen dem Holen eines
Deskriptors, dem Zurückschreiben
von Deskriptoren, dem Empfangen und dem Senden von Daten.
-
Der Stub 500 ist mit einem
Register-File 505 verbunden, das die EHCI-Register enthält. In der
vorliegenden Ausgestaltung speichern die EHCI-Register Daten bezüglich der
PCI-Konfiguration, der Hostcontrollerfähigkeiten und der Hostcontrollerbetriebsmodi.
-
Die Deskriptorverarbeitungseinrichtung 525 ist
mit dem Stub 500 verbunden und umfasst drei Untereinheiten:
die Deskriptorholeinrichtung (DescrFetch) 530, die Deskriptorspeichereinrichtung
(DescrStore) 535 und die Transaktionsvervollständigungsmaschine
(TACM) 540. Die Deskriptorholeinrichtung 530 bestimmt
basierend auf Timinginformationen und Registereinstellungen, welcher
Deskriptor zu holen oder als nächster
im voraus zu holen ist, und sendet die Anforderung an den Stub 500 und/oder
an den Deskriptorcache 545. Wenn sie den Deskriptor empfängt, sendet
sie ihn an die Deskriptorspeichereinrichtung 535.
-
Die Deskriptorspeichereinrichtung 535 hält die im
voraus geholten Deskriptoren. Durch die Durchführung eines Speichermanagements
liegt ihre Hauptfunktion in der Bereitstellung einer Speicherkapazität, um Speicherzugriffslegacies
für Deskriptorholvorgänge zu mitteln.
-
Die Transaktionsvervollständigungsmaschine 540 ist
mit der Deskriptorholeinrichtung 530 verbunden, um die
Statusrückschreibung
zu Deskriptoren zu managen. Zu diesem Zweck ist die Transaktionsvervollständigungsmaschine 540 mit
dem Deskriptorcache 545 verbunden.
-
Der Cache enthält Deskriptoren, die mittles der
Deskriptorholeinrichtung 530 für schnellen wiederholten Zugriff
im voraus geholt worden sind. Die in dem Deskriptorcache 545 gehaltenen
Deskriptoren werden von der Transaktionsvervollständigungsmaschine 540 aktualisiert
und über
den Stub 500 in den Systemspeicher eventuell zurückgeschrieben.
Der Deskriptorcache 545 kann vollassoziativ mit Write-Through-Eigenschaften
sein. Er kann ferner das Ersetzen des Inhalts abhängig von
dem Alter der gespeicherten Deskriptoren steuern.
-
Wie aus 5 ersichtlich ist, werden weiterhin die
DMA-Sendeeinrichtung 550 und die DMA-Empfangseinrichtung 510 bereitgestellt.
Die DMA-Sendeeinrichtung 550 umfasst
eine Datenholeinrichtung (DataFetch) 555 und einen Datensendepuffer
(T×Buf) 560.
Die Datenholeinrichtung 555 ist der DMA-Lesebusmaster und untersucht die Einträge in der
Deskriptorspeichereinrichtung 535 der Deskriptorverarbeitungseinrichtung 525.
Die Datenholeinrichtung 555 holt die entsprechenden Daten
im voraus und leitet sie an den Datensendepuffer 560 weiter.
-
Der Datensendepuffer 560 kann
ein FIFO-Puffer (FIFO: First In First Out) sein, und seine Funktion
entspricht der der Desciptorspeichereinrichtung 535 darin,
dass sie es gestattet, genügend
Daten für
herausgehende Transaktionen im voraus zu holen, um die Speichersystemlatenz
abzudecken. Der Datensendepuffer 560 kann ferner der Taktdomänenübersetzung
dienen, um die verschiedenen Takte der Domänen zu behandeln.
-
Die DMA-Empfangsmaschine 510 umfasst die
Datenschreibeinrichtung (DataWrite) 515, die als DMA-Schreibbusmastereinrichtung
dient, um die empfangenen Daten, die in dem Datenempfangspuffer
(R×Buf) 520 gespeichert
sind, an ihren jeweiligen Platz im Systemspeicher zu schieben. Der
Datenempfangspuffer 520 kann ein einfacher FIFO-Puffer sein
und ebenfalls der Taktdomänenübersetzung
dienen.
-
In der 60-MHz-Taktdomäne wird
eine Rahmentimingeinrichtung (FrameTiming) 565 bereitgestellt,
die die USB-Masterzeitreferenz ist. Ein Taktpuls der Rahmentimingeinrichtung
entspricht einem ganzzahligen Vielfachen (z.B. 8 oder 16) der USB-Hochgeschwindigkeitsbitzeiten.
Die Rahmentimingeinrichtung 565 ist mit der Deskriptorspeichereinrichtung 535 und
dem Paketbearbeitungsblock 570 verbunden.
-
Der Paketbearbeitungsblock 570 umfasst eine
Paketaufbaueinrichtung (PktBuild) 585, die die notwendigen
USB-Busoperationen zum Senden von Daten und Handshakes konstruiert,
und einen Paketdekodierer (PktDecode) 575, der empfangene USB-Pakete
zerlegt. Weiterhin wird eine Transaktionssteuereinrichtung (TaCtrl) 580 bereitgestellt,
die die Paketaufbaueinrichtung 585 und den Paketdekodierer 575 überwacht.
Weiterhin umfasst der Paketbearbeitungsblock 570 eine CRC-Einrichtung
(CRC: Cyclic Redundancy Check) 590 zum Erzeugen und Überprüfen von
CRC-Daten für
gesendete und empfangene Daten.
-
Die Paketaufbaueinrichtung 585 und
der Paketdekodierer 575 des Paketbearbeitungsblocks 570 sind
mit dem Root-Hub 595 verbunden, der portspezifische Steuerregister,
eine Verbindungsdetektionslogik und eine Streu/Einsammelfunktionalität für Pakete
zwischen dem Paketbearbeitungsblock 570 und dem Port-Router
enthält.
-
Darüber hinaus wird eine Taktüberwachungseinrichtung 597 in
der Ausgestaltung von 5 bereitgestellt.
Die Taktüberwachungseinrichtung 597 ist
mit dem Root-Hub 595 verbunden und überwacht den Takt, der zur
Abwicklung des Datenverkehrs zu und von den USB-Geräten verwendet wird.
Mittels der Taktüberwachungseinrichtung 597 stellt
der Hostcontroller 225 zusammen mit dem Port-Router 415 und
den physikalischen USB-2.0-Geräten
Testfeatures auf niedrigerer Ebene bereit, um die grundlegende strukturelle
Integrität
zu testen. Im Einzelnen überwacht
die Taktüberwachungseinrichtung 597 einen
USB-Gerätereferenztakt
(den durch 8 geteilten 48-MHz-Referenztakt) und/oder
einen PLL-Ausgabetakt (PLL: Phased Locked Loop, Phasenregelschleife)
(den durch 10 geteilten und den physikalischen Geräten gemeinsamen
60-MHz-Takt). Darüber
hinaus überwacht
die Taktüberwachungseinrichtung 597 der
vorliegenden Ausgestaltung ein PLL-Einrastsignal. Die Taktüberwachungseinrichtung 597 kann
Test/Diagnoseregister zum Steuern des Überwachungsmechanismus umfassen.
-
Wird nun zu der Diskussion des Register-Files 505 zurückgegangen,
so wurde bereits erwähnt,
dass das Register-File 505 der vorliegenden Ausgestaltung
die EHCI-Register enthält,
die Daten bezüglich
der PCI-Konfiguration, der Hostcontrollerfähigkeiten ("host controller
capabilities": Betriebsarten, zu denen der Hostcontroller imstande
ist) und der Hostcontrollerbetriebsmodi speichern. Dies wird nun
unter Bezugnahme auf 6 genauer
beschrieben werden, die die Registerkomponenten des Register-Files 505 zeigt.
-
Wie aus 6 ersichtlich ist, umfasst das Register-File 505 PCI-Konfigurationsregister 600. Diese
Register können
Geräte-
und Verkäufer identifizierungen,
USB-Status- und -Befehlsdaten, USB-Klassen- und -Revisionsidentifizierungen, BIST-bezogene
(BIST: Built-In Self-Test) Daten, die Größe des Headers, der Latenz
und der Cachezeile, Speicheradressen usw. speichern. Ferner können die
PCI-Konfigurationsregister 600 PCI-Powermanagementregister
umfassen sowie Register bezüglich
der USB-Legacyeigenschaften.
-
Zusätzlich zu den PCI-Konfigurationsregistern 600 umfasst
das Register-File 505 ferner Fähigkeitsregister 610,
die Daten wie in 7 angegeben, speichern.
Die Fähigkeitsregister
können
EHC-Fähigkeitsregister
und zusätzliche
Fähigkeitsregister umfassen,
die eine Erweiterung der EHC-Features und
für nicht
EHC-gemäße Software
transparent sind.
-
Beispielsweise können Daten 700 gespeichert
sein, die eine Schnittstellenversionsnummer und eine Länge der
Fähigkeitsregister
angeben. Ferner können
strukturelle Parameter 710 wie etwa die Anzahl von Begleitcontrollern,
sofern verfügbar,
die Anzahl der von Begleithostcontrollern unterstützten Ports
usw. gespeichert sein.
-
Fähigkeitsparameter 720,
die in den Fähigkeitsregistern 610 gespeichert
sind, können
angeben, ob erweiterte Hostcontrollerfähigkeiten implementiert sind.
Darüber
hinaus können
Daten zum Aktualisieren eines isochronen Planungsschemas gespeichert
sein. Zusätzlich
können
Daten bezüglich
eines asynchronen Planungsschemas gespeichert sein.
-
Wie aus 7 ersehen werden kann, speichern die
Fähigkeitsregister 610 der
vorliegenden Ausgestaltung ferner Diagnoseverfügbarkeitsparameter 730,
die verfügbare
Diagnosemodi angeben, die der USB-Hostcontroller einnehmen kann.
Ferner kann ein Einzelschrittmodusflag 740 bereitgestellt sein,
um anzugeben, dass einer der verfügbaren Diagnosemodi ein Einzelschrittmodus
ist, in welchem der USB-Hostcontroller gezwungen wird, zu einer Zeit
jeweils eine einzelne Transaktion durchzuführen. Dies wird unten in weiteren
Einzelheiten diskutiert werden.
-
Wird nun zu 6 zurückgegangen,
so umfasst das Register-File 505 ferner Betriebsregister 620,
die Parameter wie in 8 verdeutlicht
speichern. Wiederum können
die Betriebsregister EHC-Betriebsregister und andere Betriebsregister umfassen.
Die Register können
Befehlssteuerparameter 800 speichern, wie etwa Daten, die
es der Systemsoftware ermöglichen,
die maximale Rate auszuwählen,
bei der der Hostcontroller Interrupts herausgeben wird, Parkmodusdaten,
Enabledaten für
die periodische und asynchrone Planung, Hostcontrollerrücksetzdaten
usw. Weiterhin können
Statusparameter 810 gespeichert sein, die die periodische
und asynchrone Planung, Fehler und Interrupts etc. betreffen. Es
können
andere Parameter in den Betriebsregistern 620 gespeichert
sein, wie etwa Interruptenabledaten, Rahmenindexdaten, Portstatus-
und -steuerdaten usw.
-
Zusätzlich speichern die Betriebsregister 620 des
Register-Files 505 Diagnosesteuerparameter 820,
Diagnosestatusparameter 830 und Diagnoseparameter 840.
Die Diagnosesteuerparameter 820 können verwendet werden, um den
Betrieb des USB-Hostcontrollers in Diagnosemodi zu steuern. Es ist
anzumerken, dass der Hostcontroller in einem der verfügbaren Diagnosemodi
betrieben werden kann, die von den Diagnoseverfügbarkeitsparametern 730 angegeben
werden, oder dass er in Diagnosemodi betrieben werden kann, die
jederzeit verfügbar
sind, ohne dass entsprechende Daten in den Fähigkeitsregistern 610 gespeichert
sind.
-
Die Diagnosestatusparameter 830 können Daten
in Bezug auf Empfangsfehler, Leitungsstatus und Verbindungsstatus
speichern. Die Diagnoseparameter 840 speichern Daten, die
in Diagnosemodi verwendet werden oder sich aus dem Betrieb des Hostcontrollers
in einem der Diagnosemodi ergeben, wenn der Hostcontroller gemäß den Diagnosesteuerparametern 820 gesteuert
wird.
-
Wird nun zu 6 zurückgegangen,
so umfasst das Register-File 505 ferner Debugregister 630, die
Informationen speichern, die relevant sind, wenn der Hostcontroller
in einem Debugmodus arbeitet, wie etwa Statusinformationen in Bezug
auf den Debugprozess usw.
-
Somit wird der Hostcontroller der
vorliegenden Ausgestaltung mit verschiedenen Diagnosemechanismen
zum Verbessern der Zuverlässigkeit
des gesamten Hostcontrollerbetriebs bereitgestellt. Neben der obenerwähnten Taktüberwachung
enthalten die Diagnosemechanismen einen Einzelschrittmechanismus,
einen Fehlererzwingungsmodus, eine Mikrorahmenendetotzeitdiagnose,
verschiedene Zeitzähldiagnosemodi
und einen Debugmodus. Diese Diagnosemechanismen werden nun in weiteren Einzelheiten
diskutiert werden.
-
Wie bereits oben erwähnt, umfassen
die Fähigkeitsregister
ein Einzelschrittmodusflag 740, das angibt, dass einer
der verfügbaren
Diagnosemodi ein Einzelschrittmodus ist. In dem Einzelschrittmodus wird
der USB-Hostcontroller gezwungen, eine einzelne Transaktion (oder
einen Deskriptor) zu einer Zeit zu verarbeiten. Der USB-Hostcontroller
kann angepasst sein, um eine erste Liste von Transaktionen in periodischer
Weise und eine zweite Liste von Transaktionen in asynchroner Weise
abzuarbeiten, wobei der Einzelschrittmodus nur die asynchrone Liste
betrifft. Die Diagnosesteuerparameter 820 können ein Einzelschrittmodusenableflag
umfassen, das angibt, ob der USB-Hostcontroller gerade in dem Einzelschrittmodus
arbeitet. Das Enableflag ist durch Software wiederbeschreibbar,
wenn das Einzelschrittmodusflag 740 gesetzt ist. Andernfalls
kann das Enableflag nur gelesen werden.
-
Die Diagnosesteuerparameter 820 können ferner
ein Aktivitätsflag
speichern, das angibt, ob der USB-Hostcontroller gegenwärtig eine
Transaktion verarbeitet, wenn er in dem Einzelschrittmodus arbeitet.
Keine andere Transaktion kann gestartet werden, wenn sowohl das
Enableflag als auch das Aktivitätsflag
gesetzt sind.
-
In einer anderen Ausgestaltung kann
der USB-Hostcontroller angepasst sein, um einen Handshakemechanismus
anzuwenden, um von einer Transaktion zu der nächsten in dem Einzelschrittmodus
zu überzugehen.
-
In jeder Ausgestaltung kann der Einzelschrittmodus
hilfreich sowohl für
das Debuggen sein als auch als Rückfallmodus,
um Belange bezüglich der
Spezifikationskompatibilität
und der Zusammenarbeit mit Hubs und Geräten zu behandeln. Das bedeutet,
dass der Hostcontroller angepasst sein kann, um den Einzelschrittmodus
in einem Softwaredebugmodus des Hostcontrollers und/oder in einem
vordefinierten Kompatibilitätsmodus
des Hostcontrollers einzunehmen.
-
Ein anderer Diagnosemodus, der in
dem Hostcontroller der vorliegenden Ausgestaltung verfügbar sein
kann, ist ein Fehlererzwingungsmodus. Die Hostcontrollerbetriebsregister 620 können ein Fehlererzwingungsmodusflag
als einen der Diagnosesteuerparameter 820 speichern, das
angibt, dass einer der verfügbaren
Diagnosemodi ein Fehlererzwingungsmodus ist. In dem Fehlererzwingungsmodus
wird der USB-Hostcontroller gezwungen, absichtlich den CRC-Wert
(CRC: Cyclic Redundancy Check) für
jedes herausgehende Datenpaket zu verfälschen. Darüber hinaus kann ein Fehlervoraussetzungsmodus
unter Verwendung eines Fehlervoraussetzungsmodusflags 820 gesetzt
werden, wobei der USB-Hostcontroller gezwungen wird, jedes hereinkommende
Datenpaket als eines mit einem verfälschten CRC-Wert zu behandeln.
In derselben Weise kann ein Fehlerignorierungsmodusflag 820 angeben,
dass der USB-Hostcontroller in einem Fehlerignorierungsmodus arbeitet,
in dem er gezwungen wird, jedes hereinkommende Datenpaket als einen korrekten
CRC-Wert aufweisend zu behandeln.
-
Ein weiterer Diagnosemodus, der in
dem Hostcontroller verfügbar
sein kann, verwendet Mikrorahmenendetotzeitdiagnosedaten, die die
Zeit am Ende des vorherigen Mikrorahmens angeben, die für USB-Transaktionen
nicht verwendet wird. Mittels eines solchen Mikrorahmenendetotzeitberichtregisters 840 kann
die Anzahl asynchron geplanter Deskriptoren gesteuert werden, die
auf Grundlage ihrer geschätzten
Vervollständigungszeit
im voraus geholt werden.
-
Andere Diagnosemodi betreffen die
Queue-, Cache- und Puffermechanismen insbesondere bezüglich asynchroner
Deskriptoren. Beispielsweise können
die Betriebsregister 620 Zeitzähldiagnosedaten 840 speichern,
die eine geschätzte
Vervollständigungszeit
für alle
asynchron geplanten Transfers des vorherigen Mikrorahmens angeben,
die in einem Queue der Deskriptorspeichereinrichtung 530 gespeichert
sind, aber noch nicht ausgeführt
wurden. Andere Diagnoseparameter 840 können Maximalzeitdiagnosedaten 840 enthalten,
die einen Maximalwert für
eine geschätzte
Vervollständigungszeit
asynchron geplanter Transfers des vorherigen Mikrorahmens angeben.
Zusätzlich
können
Minimalzeitdiagnosedaten gespeichert werden, um einen Minimalwert
für die
geschätzte
Vervollständigungszeit
asynchron geplanter Transfers des vorherigen Mikrorahmens anzugeben.
-
Es können auch Zeitzähldiagnosedaten
gespeichert werden, die eine geschätzte Vervollständigungszeit
für alle
in der Queue befindlichen Transfers des aktuellen Mikrorahmens angeben.
Die Hostcontrollerbetriebsregister 620 können fernen
Schwellenwertdiagnosedaten 840 speichern, die einen Schwellenwert
für die
geschätzte
Vervollständigungszeit
angeben, der verwendet werden kann, um die Anzahl asynchron geplanter
Deskriptoren zu steuern, die im voraus auf Grundlage ihrer geschätzten Vervollständigungszeit
geholt werden.
-
Wird auf die Deskriptorspeichereinrichtung 535 Bezug
genommen, die geholte Deskriptoren speichert, so kann das Hostcontrollerbetriebsregister 620 Flush-Diagnosedaten speichern,
die den Hostcontroller zu einem Flush der gespeicherten Deskriptoren
anweisen. Ferner können
die Betriebsregister 620 Diagnosedaten 840 speichern,
die Betriebsparameter der Deskriptorspeichereinrichtung 535 angeben,
wie etwa Ladeniveaus und Randwerte.
-
Bezüglich des Deskriptorcaches 545,
der im voraus geholte Deskriptoren speichert, können die Diagnoseparameter 840 Flush-Diagnosedaten
umfassen, die den Hostcontroller anweisen, einen Flush der gespeicherten
Deskriptoren durchzuführen.
Wiederum können
die Betriebsregister 620 weiterhin Diagnosedaten 840 speichern,
die Betriebsparameter des Deskriptorcaches 545 angeben,
wie etwa die Anzahl der gegenwärtig
in Cache befindlichen Deskriptoren.
-
Wie oben erwähnt, umfassen die Sende- und Empfangseinrichtungen 550, 510 FIFO-Puffer 560, 520.
Die Betriebsregister 620 können Flush-Diagnosedaten 840 speichern,
die den Hostcontroller anweisen, einen Flush eines oder beider FIFO-Puffer 560, 520 durchzuführen. Ferner
können
Diagnosedaten 840 gespeichert sein, die die aktuelle Anzahl
an Bytes in einem oder beiden FIFO-Puffern angeben.
-
Wie aus der obigen Beschreibung der
Ausgestaltungen ersichtlich ist, sind verschiedene Diagnosemodi
verfügbar,
um die gesamte Betriebszuverlässigkeit
des Hostcontrollers zu verbessern. Ein Beispiel dafür, wie die
Diagnosemodi verwendet werden können,
wird nun unter Bezugnahme auf 9 erläutert werden.
-
In dem in dem Flussdiagramm von 9 gezeigten Prozess werden
Fähigkeitsdaten
und EHC-Betriebsdaten in den Schritten 900 und 910 gespeichert.
Es ist anzumerken, dass das Speichern der Daten in einer anderen
Ausgestaltung vollständig unabhängig und
separat von den verbleibenden, in 9 gezeigten
Schritten erfolgen kann. Das Speichern der Daten kann das Aktualisieren
der Daten oder das Kopieren der Daten von anderen Quellen enthalten.
-
Im Schritt 920 bestimmt der Hostcontroller, ob
ein Diagnosemodus eingenommen werden soll. Dies kann in Erwiderung
auf Softwareanweisungen erfolgen. In einer anderen Ausgestaltung
kann die Entscheidung, ob einer der Diagnosemodi eingenommen werden
soll, in bestimmten Fällen
fest verdrahtet erfolgen, z.B. wenn eine vorbestimmte Fehlerbedingung
erfüllt
ist.
-
Wenn einer der Diagnosemodi in Schritt
920 eingenommen wird, kann im Schritt 930 auf Diagnoseverfügbarkeitsparameter 730 zugegriffen
werden, um festzustellen, ob der ausgewählte Diagnosemodus in dem Hostcontroller
verfügbar
ist. Es ist anzumerken, dass der Schritt 930 übergangen werden kann, wenn
der gewählte
Diagnosemodus einer der Modi ist, die jederzeit verfügbar sind,
ohne dass Diagnoseverfügbarkeitsparameter 730 in
den Fähigkeitsregistern 610 gespeichert
sind.
-
Wenn der gewählte Diagnosemodus verfügbar ist,
kann auf Diagnosebetriebsparameter 820, 830, 840 im
Schritt 940 zugegriffen werden. Die Diagnose wird dann im Schritt
950 durchgeführt.
-
Wie aus der vorangegangenen Beschreibung
der Ausgestaltungen ersichtlich ist, wird eine Hostcontrollertechnik
bereitgestellt, die effiziente Diagnosefähigkeiten und -modi aufweist
und somit über
die Definitionen und Konventionen, die in der EHCI-Spezifikation
angegeben sind, hinausgeht.
-
Während
die Erfindung unter Bezugnahme auf die physikalischen Ausgestaltungen,
die in Übereinstimmung
damit konstruiert worden sind, beschrieben worden ist, wird Fachleuten
ersichtlich sein, dass zahlreiche Modifikationen, Variationen und Verbesserungen
der vorliegenden Erfindung im Lichte der obigen Lehren und innerhalb
des Umfangs der beigefügten
Ansprüche
gemacht werden können, ohne
von der Idee und dem beabsichtigten Umfang der Erfindung abzuweichen.
Zusätzlich
sind solche Bereiche, in denen davon ausgegangen wird, dass sich
Fachleute auskennen, hier nicht beschrieben worden, um die hier
beschriebene Erfindung nicht unnötig
zu verschleiern. Es ist demgemäß zu verstehen,
dass die Erfindung nicht durch die spezifisch verdeutlichten Ausgestaltungen,
sondern nur durch den Umfang der beigefügten Ansprüche beschränkt wird