-
TECHNISCHES GEBIET
-
Diese
Erfindung betrifft das Gebiet der Energieverwaltung einer Plattform
und insbesondere das Synchronisieren von Host-Controllern mit nicht gleichförmigen Frame-Raten.
-
HINTERGRUND
-
Wegen
der immer weiter zunehmenden Gate-Zahlen und Taktgeschwindigkeiten
bei gegenwärtigen
Gestaltungen für
Rechenplattformen gewinnt die Energieerhaltung bei einer Plattform
einen zunehmenden Wert. Niederenergie-Rechenplattformen nehmen an
Beliebtheit zu, da Energieverbrauch stark mit der Lebensdauer einer
Batterie und der Wärmeabstrahlung
verbunden ist, welche die Mobilität beeinträchtigen. Im Allgemeinen sind
Rechenplattformen, die weniger Energie verbrauchen, mobiler. Ein
Weg, Energie zu sparen, besteht darin, funktionale Verhaltensweisen
zu ändern,
die es ermöglichen
würden,
dass bestimmte Komponenten über verlängerte Zeitdauern
in einem Zustand niedrigerer Leistung bleiben.
-
Gegenwärtig können Chipsatz-Implementierungen
mehrere Controller verwenden, so wie Host-Controller für den universellen
seriellen Bus (USB – Universal
Serial Bus), um das Leistungsverhalten zu verbessern. Mehrere USB-Host-Controller innerhalb
einer Rechenplattform können
das Leistungsverhalten verbessern, indem die gesamte Bandbreite
vergrößert wird,
die allen USB-Geräte
in der Plattform zur Verfügung
steht. Im Allgemeinen kann ein alter USB-Host-Controller, so wie
ein Controller, der unter die USB Specification, Neubearbeitung
1.1 fällt,
zwei USB-Ports bedienen. Die Universal Serial Bus Specification,
Neubearbeitung 1.1, veröffentlicht
am 23. September 1998. In jüngerer Zeit
können
USB-Host-Controller,
die die USB Specification, Neubearbeitung 2.0, erfüllen, mehr
als zwei USB-Ports (z. B. sechs Ports) bedienen. Universal Serial
Bus Specification, Neubearbeitung 2.0, veröffentlicht am 27. April 2002.
Obwohl viele Ports von einem einzigen USB-Host-Controller bedient
werden können,
haben viele mobile Rechenplattformen mehrere USB-Host-Controller. Zusätzlich kann
eine einzige Rechenplattform unterschiedliche Typen von USB-Host-Controllern
umfassen.
-
Herkömmlich ist
der Betrieb jedes USB-Host-Controllers von den anderen USB-Host-Controllern unabhängig (d.
h. der Zustand eines Controllers hat nichts mit dem Zustand eines anderen
Controllers zu tun). Weiterhin ist der Betrieb der USB-Host-Controller
periodisch. Zum Beispiel holen alte USB-Host-Controller in jeder
Millisekunde (ms) eine neue Arbeitsliste oder einen Frame. USB-Host-Controller,
die entsprechend dem Standard USB 2.0 arbeiten, holen alle 125 Mikrosekunden (μs) neue Frames.
-
Während des
Betriebs der USB-Host-Controller ist die Rechenplattform typischerweise
in einem normal arbeitenden Energiezustand. Übliche Definitionen für Energiezustände sind
in dem offenen Standard der Advanced Configuration and Power Interface
(ACPI) verfügbar.
Advanced Configuration and Power Interface Specification, Neubearbeitung
3.0a, veröffentlicht
am 30. Dezember 2005. Zum Beispiel können Prozessoren in verschiedenen "C"-Energiezuständen arbeiten,
die im Bereich von CO (volle Leistung) bis C4 (niedrige Leistung)
liegen. Die oben beschriebenen Abhol- oder Frame-Arbeitsgänge werden
typischerweise ausgeführt,
wenn der Prozessor und der Chipsatz in dem Energiezustand C2 sind. Jedoch
können
der Prozessor und der Chipsatz zwischen Speicherzugriffen in einen
Zustand niedriger Leistung, so wie dem Energiezustand C3, eintreten.
-
Wenn
mehrere USB-Host-Controller implementiert sind, kann es mehrere
Speicherzugriffe geben, die über
die Zeit verteilt sind, die verhindern, dass der Prozessor über einen
nennenswerten Zeitraum in einen Zustand niedriger Leistung eintritt.
Zum Beispiel kann unmittelbar vor einem Speicherzugriff durch einen
USB-Host-Controller der USB-Host-Controller einen „Beginn
eines Frame"(SOF – Start
Of Frame)-Marker ausgeben. Die periodischen „Beginn eines Frame"-Marker für einen gegebenen
USB-Host-Controller werden herkömmlich
durch Host-Software unabhängig
von den „Beginn
eines Frame"-Markern
für andere USB-Host-Controller angestoßen. Die
zufällige
Beziehung dieser Marker kann verhindern, dass der Prozessor in einen
Zustand niedriger Leistung eintritt, was zu einem im Wesentlichen
kontinuierlichen Energieverbrauch führt.
-
Die
Einbußen,
die von diesen ungesteuerten Speicherzugriffen durch mehrere USB-Host-Controller herrühren, werden
durch die Änderung
in der Frame-Rate zwischen alten USB-Host-Controllern, die eine Frame-Rate
von ungefähr
einer Millisekunde haben, und USB-Host-Controllern, die kürzere Frame-Raten,
so wie 125 Mikrosekunden, haben, verschärft. Dieser Unterschied in
den Frame-Raten kann weiter die Möglichkeit eines Prozessors,
in einen Zustand niedriger Leistung einzutreten, beschränken oder
sogar ausschalten.
-
Die
herkömmliche
Technologie spricht dieses Problem nicht in angemessener Weise an.
Obwohl manche mögliche
Lösungen
das Vorabholen der nächsten
Paar Arbeitslisten oder Frames vorschlagen, kann das Vorabholen
veraltete Daten einführen,
weil die Software für
den USB-Host-Controller sehr nahe an der Hardware laufen darf. Zusätzlich sprechen
das Vorabholen und weitere herkömmliche Techniken,
um Energie zu sparen, bei denen das Verhalten des USB-Host-Controllers
verwendet wird, nicht die Wechselwirkung zwischen mehreren Host-Controllern
mit nicht gleichförmigen
Frame-Raten an.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Die
vorliegende Erfindung wird beispielhaft und nicht beschränkend in
den Figuren der beigefügten
Zeichnungen veranschaulicht.
-
1 veranschaulicht
eine Ausführungsform
eines Zeitdiagramms für
den herkömmlichen Betrieb
nicht synchronisierter Host-Controller.
-
2 veranschaulicht
eine Ausführungsform
einer Rechenplattform.
-
3 veranschaulicht
eine Ausführungsform
eines Eingabe/Ausgabe (I/O)-Controller-Hubs mit mehreren Host-Controllern
mit nicht gleichförmigen
Frame-Raten.
-
4 veranschaulicht
eine Ausführungsform
eines Synchronisationsverfahrens, um mehrere Host-Controller mit
nicht-gleichförmigen
Frame-Raten zu synchronisieren.
-
5 veranschaulicht
eine Ausführungsform
eines Zeitdiagramms für
den Betrieb synchronisierter Host-Controller.
-
6 veranschaulicht
eine Ausführungsform
eines Zustandsdiagramms für
eine Zustandsmaschine, um mehrere Host-Controller zu synchronisieren.
-
7 veranschaulicht
eine alternative Ausführungsform
einer Rechenplattform, um mehrere Host-Controller zu synchronisieren.
-
GENAUE BESCHREIBUNG
-
Die
folgende Beschreibung führt
zahlreiche bestimmte Einzelheiten auf, so wie Beispiele bestimmter
Systeme, Komponenten, Verfahren und so weiter, um für ein gutes
Verständnis
der verschiedenen Ausführungsformen
der vorliegenden Erfindung zu sorgen. Es wird einem Fachmann jedoch
deutlich werden, dass wenigstens einige Ausführungsformen der vorliegenden
Erfindung ohne diese bestimmten Einzelheiten in die Praxis umgesetzt
werden können. In
andere Fällen
werden gut bekannte Komponenten oder Verfahren nicht in Einzelheiten
beschrieben oder werden im einfachen Blockschaubildformat dargestellt,
um das unnötige
Verschleiern der vorliegenden Erfindung zu vermeiden. Somit sind
die aufgeführten
bestimmten Einzelheiten lediglich beispielhaft. Bestimmte Implementierungen
können
von diesen beispielhaften Einzelheiten abweichen und werden doch
so betrachtet, dass sie im Gedanken und Umfang der vorliegenden
Erfindung liegen.
-
Eine
Ausführungsform
erleichtert den niedrigeren Energieverbrauch einer Plattform, indem
die Taktung von Speicherzugriffen, so wie bei Frames mit direktem
Speicherzugriff (DMA – Direct
Memory Access) von Host-Controllern für den universellen seriellen
Bus (USB) geändert
wird. Zum Beispiel kann eine Logik Speicherzugriffe von mehreren USB-Host-Controllern in einer
solchen Weise gruppieren, dass die Rechenplattform über längere Zeiträume in einem
Zustand niedriger Leistung, so wie dem Energiezustand C3 bleiben
kann, als wenn die Speicherzugriffe nicht synchronisiert wären. Einige Ausführungsformen
können
Hardware verwenden, während
andere Ausführungsformen
eine Kombination aus Hardware und Firmware verwenden können, um
die mehreren USB-Host-Controller zu synchronisieren. Obwohl sich
die folgende Beschreibung häufig
auf USB-Host-Controller bezieht, können andere Arten von Controller
und Implementierungen ihren Nutzen aus denselben oder ähnlichen
Ausführungsformen
ziehen.
-
1 veranschaulicht
eine Ausführungsform
eines Zeitschaubildes für
den herkömmlichen Betrieb
nicht synchronisierter Host-Controller. Bei herkömmlichen Rechenplattformen
sind die Frame-Zähler
für mehrere
USB-Host-Controller nicht aktiv synchronisiert. Somit holt bei inaktiven
USB-Planungen ein Controller beim Systemspeicher die Frame-Liste
ab und anschließende
Abholungen geschehen unabhängig
für jeden
Controller, was möglicherweise
verhindert, dass andere Komponenten der Plattform in Zustände niedrigerer
Leistung eintreten.
-
Das
veranschaulichte Zeitschaubild der 1 beschreibt
die Speicherzugriffssignale von drei nicht synchronisierten USB-Host-Controllern.
Ohne die Synchronisation der USB-Host-Controller arbeiten sie unabhängig voneinander.
Jeder USB-Host-Controller wird individuell durch Host-Software angestoßen. Wenn
er einmal angestoßen
ist, führt
jeder USB-Host-Controller
ein neues Abholen einer Arbeitsliste oder den Beginn eines Frame
aus, in jede Millisekunde (ms) bei alten USB-Host-Controllern oder
alle 125 Mikrosekunden (μs)
bei USB-Host-Controllern,
die den Standard USB 2.0 erfüllen.
Im schlimmsten Fall können
die USB-Host-Controller
ihr Abholen in gleichmäßig verteilten
Intervallen über
ein bestimmte Zeitdauer durchführen.
Aus Zweckmäßigkeitsgründen wird
der Frame des USB-Host-Controllers #1 als das Referenzzeitintervall
verwendet. Als ein Beispiel führt
die Verteilung der Frames für
die drei USB-Host-Controller zu einem neuen Frame und Speicherzugriff,
der von einem USB-Host-Controller in jeder Millisekunde dreimal
durchgeführt
wird. Somit können
innerhalb eines Zeitintervalls von zwei Millisekunden die drei USB-Host-Controller
neue Frames zu den Zeitpunkten t1, t3, t5, t8, t10 und t12 anstoßen. In ähnlicher Weise
können
die USB-Host-Controller
einzelne Speicherzugriffe zu den Zeitpunkten t2, t4, t6, t9, t11 und
t13 durchführen.
-
Obwohl
es für
einen einzelnen USB-Host-Controller nicht erforderlich zu sein braucht,
dass der Prozessor über
einen wesentlichen Teil jedes Frames in einem Zustand hoher Leistung ist,
können
die Speicherzugriffe aller USB-Controller im Verbundsystem die Zeitdauer
beschränken, über die
der Prozessor in einen Zustand niedriger Leistung eintreten kann.
Zum Beispiel kann der Prozessor den größten Teil irgendeines gegebenen
Frames in dem Energiezustand C2 verbringen, wie es im unteren Bereich
des Zeitschaubilds veranschaulicht ist.
-
Dieses
gleichmäßige Streuen
von Abholprozessen oder Speicherzugriffen über das Zeitintervall von 1
ms verhindert, dass der Prozessor in einen Zustand niedriger Leistung
eintritt, was somit das Energiesparen verhindert. Zusätzlich können USB-Host-Controller,
die Speicherzugriffe öfter
als einmal pro Millisekunde durchführen, das Energiesparen weiter
einschränken.
Zum Beispiel beschränkt
ein USB-Host-Controller, der alle 125 Mikrosekunden einen neuen
Frame anstößt und einen Speicherzugriff
durchführt,
die verfügbare
Zeit zum Energiesparen im Vergleich mit einem USB-Host-Controller,
der in jeder Millisekunde einen neuen Frame anstößt, da der Prozessor den Energiezustand
C2 in jeder Millisekunde ungefähr
acht Mal betritt. Darüber
hinaus verschlechtert die Kombination von USB-Host-Controllern,
die bei unterschiedlichen Frame-Raten arbeiten, den Energieerhalt
noch mehr.
-
2 veranschaulicht
eine Ausführungsform
einer Rechenplattform 10. Die dargestellte Rechenplattform 10 umfasst
eine zentrale Verarbeitungseinheit (CPU – Central Processing Unit) 20,
die über
einen Prozessorbus 35 mit einem Grafik- und Speichercontroller-Hub
(GMCH – Graphics
and Memory Controller Hub) 30 gekoppelt ist. Aus Gründen der
Zweckmäßigkeit
wird die zentrale Verarbeitungseinheit 20 auch als der
Prozessor 20 bezeichnet. Bei einer Ausführungsform ist der Prozessor 20 ein
Prozessor aus der Pentium®-Familie von Prozessoren, einschließlich des
Pentium®IV-Prozessors,
der von der Intel Corporation, Santa Clara, Kalifornien, erhältlich ist.
Als Alternative kann der Prozessor 20 ein anderer Typ eines
Prozessors sein. Bei einer anderen Ausführungsform kann der Prozessor 20 mehrere Prozessorkerne
umfassen. Zusätzlich
kann sich der Grafik- und Speichercontroller-Hub 30 bei
manchen Ausführungsformen
in demselben Chip wie der Prozessor 20 befinden. Weiterhin
kann der Grafik- und Speichercontroller-Hub 30 für alle Kerne
oder Prozessoren in einem Chip arbeiten. Als Alternative kann der
Grafik- und Speichercontroller-Hub 30 unterschiedliche
Bereiche umfassen, die getrennt für verschiedene Kerne oder Prozessoren
in einem Chip arbeiten können.
-
Die
veranschaulichte Rechenplattform 10 umfasst außerdem einen
Eingabe/Ausgabe (I/O – Input/Output)-Controller-Hub
(ICH – Input/Output
Controller Hub), 40, der über einen Backbone-Bus 45 mit dem
Grafik- und Speichercontroller-Hub 30 gekoppelt ist. Der
I/O Controller-Hub 40 bildet eine Schnittstelle zu I/O-Baugruppen
innerhalb oder verbunden mit der Rechenplattform 10. Bei
einer Ausführungsform
sind der Grafik- und Speichercontroller-Hub 30 und der
I/O Controller-Hub 40 in einem einzigen Chipsatz kombiniert.
Als Alternative können
der Grafik- und Speichercontroller-Hub 30 und der I/O Controller-Hub 40 auf
einem einzigen Chip integriert sein oder können unabhängig von einem Chipsatz implementiert
werden. Bei einer weiteren Ausführungsform
kann der Prozessor 20 in einer anderen Weise direkt mit
dem I/O Controller-Hub 40 verbunden sein. Ein Beispiel
des I/O Controller-Hubs 40 ist in weiteren Einzelheiten
mit Bezug auf 3 gezeigt und beschrieben.
-
Die
veranschaulichte Rechenplattform 10 umfasst auch einen
Speicher 50, der über
einen Speicherbus 55 mit dem Grafik- und Speichercontroller-Hub 30 gekoppelt
ist, und einen PCI Express-Grafikchip 60, der über einen
Grafikbus 65 mit dem Grafik- und Speichercontroller-Hub 30 verbunden
ist. Bei einer Ausführungsform
kann der Speicher 50 ein mit doppelter Datenrate (DDR – Double
Data Rate) arbeitender, synchroner dynamischer Speicher mit wahlfreiem
Zugriff (SDRAM – Synchronous
Dynamic Random Access Memory) sein. Als Alternative kann der Speicher 50 irgendein
anderer Typ eines elektronischen Datenspeichers sein. Zusätzlich kann
der Speicher 50 in einem Chipsatz mit dem Grafik- und Speichercontroller-Hub 30 und
dem I/O Controller-Hub 40 enthalten sein oder kann davon
getrennt sein. Bei einer Ausführungsform
kann der Speicher 50 als ein Hauptspeicher der Rechenplattform 10 bezeichnet
werden. Der Hauptspeicher 50 speichert Daten und Befehlsabfolgen
und Code, die durch Datensignale dargestellt werden, welche von
dem Prozessor 20 oder irgendeinem anderen Bauelement, das
in der Rechenplattform 10 enthalten ist, ausgeführt werden
können.
-
Wieder
mit Bezug auf den Prozessor 20 kann ein Treiber 70 auf
dem Prozessor gespeichert sein, um die Arbeitsgänge eines oder mehrerer USB-Host-Controller
zu vereinfachen. Zusätzlich kann
der Treiber 70 die Arbeitsgänge eines I/O-Bauelementes
vereinfachen, das mit einem USB-Host-Controller gekoppelt ist. Bei
einer weiteren Ausführungsform
kann der Treiber 70 wenigstens teilweise in dem Speicher 50 gespeichert
sein.
-
Ein
oder mehrere Register 80 können in dem I/O Controller-Hub 40 enthalten
sein, um den Status jedes der USB-Host-Controller zu verfolgen,
die mit dem I/O Controller-Hub 40 gekoppelt sind, wie es hiernach
diskutiert wird. Bei einer Ausführungsform ist
ein Bit innerhalb des Registers für jeden USB-Host-Controller
reserviert, um den Zustand des USB-Host-Controller anzugeben und um beim USB-Host-Controller
auszulösen,
dass er auf den Speicher 50 zugreift. Zum Beispiel kann
ein Bit auf '0' gesetzt werden,
um einen inaktiven Zustand eines USB-Host-Controllers anzuzeigen.
Als Alternative kann ein Bit auf '1' gesetzt
werden, um einen aktiven Zustand eines USB-Host-Controllers anzuzeigen.
-
Bei
einer Ausführungsform
können
diese Bits als Laufbits (run bits) bezeichnet werden. Bei einer
Ausführungsform
kann die Anzahl aktiver USB-Host-Controller (angegeben durch aktive
Laufbits) den Betrieb der USB-Host-Controller beeinflussen. Wenn
nur ein USB-Host-Controller
aktiv ist, können
die Arbeitsgänge
normalerweise ablaufen, indem der eine USB-Host-Controller Speicherzugriffe einleitet
und durchführt.
Wenn jedoch zwei oder mehr USB-Host-Controller
aktiv sind (d. h. zwei Laufbits sind auf '1' gesetzt),
können
die aktiven USB-Host-Controller
synchronisiert werden, um Abholungen zu ungefähr derselben Zeit durchzuführen, so
dass die Zeitdauer maximiert wird, über die der Prozessor 20 oder
andere Komponenten der Rechenplattform 10 in einem Zustand
niedriger Leistung sein können.
-
3 veranschaulicht
eine Ausführungsform
eines I/O Controller-Hubs 40, der mehrere USB-Host-Controller 110 und 120 mit
nicht gleichförmigen
Frame-Raten aufweist. Mit anderen Worten führen die USB-Host-Controller 110 und 120 nicht von
sich aus Speicherzugriffe, die einem einzigen Zeitintervall entsprechen,
durch. Bei der veranschaulichten Ausführungsform umfasst der I/O
Controller-Hub 40 zwei Typen von USB-Host-Controllern. Die
Controller 110 einer universellen Host-Controller-Schnittstelle
(UHCI – Universal
Host Controller Interface) sind alte USB-Host-Controller, die eine
Frame-Rate von ungefähr
einer Millisekunde (ms) haben. Im Gegensatz dazu haben die Controller 120 einer
verbesserten Host-Controller-Schnittstelle
(EHCI – Enhanced
Host Controller Interface) eine Frame-Rate von ungefähr 125 Mikrosekunden
(μs). Obwohl
nur zwei UHCI-Controller 110 und zwei EHCI-Controller 120 gezeigt
sind, kann der I/O Controller-Hub 40 eine größere oder
kleinere Anzahl von jedem Typ USB-Host-Controller 110 und 120 haben. Bei
einer weiteren Ausführungsform
kann der I/O Controller-Hub 40 Controller einer offenen
Host-Controller-Schnittstelle
(OHCI – Open
Host Controller Interface) oder andere Arten von Controller umfassen.
-
Jeder
der USB-Host-Controller 110 und 120 ist mit einem
oder mehreren USB-Ports 160 gekoppelt. USB-Geräte (nicht
gezeigt) können über die USB-Ports 160 mit
dem I/O Controller- Hub 40 verbunden
sein. Jeder UHCI-Controller 110 ist so gestaltet, dass
er zwei USB-Ports 160 unterstützt. Jeder der EHCI-Controller 120 ist
so gestaltet, dass er flexibel bis zu sechs USB-Ports 160 unterstützt. Zum Beispiel
bedient einer der veranschaulichten EHCI-Controller 120 drei USB-Ports 160,
und der andere EHCI-Controller 120 bedient fünf USB-Ports 160. Bei
anderen Ausführungsformen
können
andere Typen Controller mehr oder weniger Ports unterstützen.
-
Der
veranschaulichte I/O Controller-Hub 40 umfasst auch eine
USB-Frame-Synchronisationssteuerlogik 130.
Andere mögliche
Komponenten des I/O Controller-Hubs 40 sind aus Gründen der
Klarheit aus der 3 ausgeschlossen, können bei
bestimmten Implementierungen des I/O Controller-Hubs 40 jedoch
enthalten sein. Aus Zweckmäßigkeitsgründen wird
die USB-Frame-Synchronisationssteuerlogik 130 als Logik 130 bezeichnet.
Bei einer Ausführungsform
ist die Logik 130 in Hardware als eine Vielzahl von Transistoren
implementiert. Als Alternative kann die Logik 130 als eine
Kombination aus Hardware, die Transistoren oder andere Hardwarelogik
umfasst, und Firmware implementiert werden. Die Logik 130 wechselwirkt
mit den USB-Host-Controllern 110 und 120, um Abholungen
oder Speicherzugriffe durch die USB-Host-Controllern 110 und 120 zu
synchronisieren (die USB-Ports 160, die von einem einzigen USB-Host-Controller 110 oder 120 bedient
werden, sind auch miteinander durch denselben USB-Host-Controller 110 oder 120 synchronisiert). Zusätzlich kann
die Logik 130 beeinflussen, wann ein Laufbit für einen
bestimmten USB-Host-Controller 110 oder 120 gesetzt
wird, ebenso, wann das Laufbit erkannt wird.
-
4 veranschaulicht
eine Ausführungsform
eines Synchronisationsverfahrens 200 zum Synchronisieren
mehrerer Host-Controller 110 und 120 mit nicht
gleichförmigen
Frame-Raten. Bestimmte
Ausführungsformen
des Synchronisationsverfahrens 200 können im Zusammenhang mit dem
I/O Controller-Hub 40 der 3 implementiert
werden. Alternative Ausführungsformen
können
in anderen Systemen mit mehreren Host-Controllern 110 und 120 mit
nicht gleichförmigen
Frame-Raten implementiert werden.
-
Das
dargestellte Synchronisationsverfahren 200 beginnt, und
die Logik 130 erkennt 210 einen ersten USB-Host-Controller 110 oder 120 auf
dem I/O Controller-Hub 40. Aus Zweckmäßigkeitsgründen benutzt die Beschreibung
der 4 einen ersten Controller, um auf einen USB-Host-Controller 110 oder 120 zu
verweisen, für
den anfangs Speicherzugriffe durchgeführt werden, und einen zweiten
Controller, um auf einen weiteren USB-Host-Controller 110 oder 120 zu
verweisen, für
den Speicherzugriffe anschließend,
nach dem ersten Controller eingeleitet werden. Die Reihenfolge jedoch,
in der bestimmte USB-Host-Controller 110 und 120 betrieben
werden, kann sich abhängig
davon ändern,
wann Geräte
in die verschiedenen USB-Ports 160 eingesteckt werden und
wann die entsprechenden USB-Treiber 70 und weitere Hostsoftware
die USB-Geräte
erkennen. Weiterhin kann der erste Controller 110 ein UHCI-Controller 110 oder
ein EHCI-Controller 120 oder irgendein anderer Typ eines
Host-Controllers
sein. In ähnlicher
Weise kann der zweite Controller 120 ein UHCI-Controller 110 oder
ein EHCI-Controller 120 oder ein anderer Typ eines Host-Controllers
sein.
-
Bei
einer Ausführungsform
erkennt 210 die Logik 130 den ersten Controller
und setzt 220 ein Laufbit, das dem ersten Controller entspricht.
Die Logik 130 führt
dann 230 einen Speicherzugriff für den ersten Controller aus.
Der erste Speicherzugriff für den
ersten Controller braucht nicht mit dem anderen Host-Controller 110 oder 120,
einem globalen Frame-Zähler
oder einem anderen Synchronisationssignal synchronisiert zu sein,
kann es aber sein. Wenn keine anderen Host-Controller 110 oder 120 angestoßen werden,
kann die Logik 130 damit fortfahren, Speicherzugriffe mit
der Frame-Rate des ersten Controllers 110 (z. B. 1 ms oder
125 μs)
auszuführen.
Als Alternative kann die Logik 130 Speicherzugriffe bei einer
gemeinsamen Frame-Rate ausführen 230,
die standardisiert ist, so dass sie unterschiedliche Frame-Raten bedient, jedoch
von der innewohnenden Frame-Rate des ersten Controllers unterschiedlich ist.
-
Die
Logik 130 bestimmt 240 anschließend, ob
ein zweiter Controller von den USB-Treibern 70 angestoßen ist,
und wenn dies der Fall ist, setzt sie 250 ein Laufbit,
das dem zweiten Cont roller entspricht. Die Logik 130 wartet 260 dann
bis zu einem gemeinsamen Frame-Übergang.
Wenn nur der erste Host-Controller arbeitet, kann der gemeinsame
Frame-Übergang
irgendein folgender Frame-Übergang des
ersten Controllers sein. Als Alternative kann der gemeinsame Frame-Übergang
ein modifizierter Frame-Übergang
sein, der sowohl an den ersten als auch an den zweiten Controller
angepasst ist. Als Alternative kann die Logik 130 mit dem
Setzen des Laufbits, das dem zweiten Controller entspricht, ungefähr bis zur
Zeit des gemeinsamen Frame-Übergangs
warten.
-
Nachdem
das Laufbit, das den zweiten Controller entspricht, gesetzt worden
ist 250 und der gemeinsame Frame-Übergang eingerichtet worden
ist 260, führt
dann die Logik 130 synchronisierte Speicherzugriffe sowohl
für den
ersten als auch für
den zweiten Controller aus 130. Zusätzliche Controller 110 oder 120 können mit
dem ersten und mit dem zweiten Controller 110 und 120 in
einer ähnlichen Weise
synchronisiert werden. Zusätzlich
können
aktive Controller deaktiviert werden, zum Beispiel wenn ein USB-Gerät aus einem
USB-Port 160 herausgenommen wird, und der entsprechende
Host-Controller 110 oder 120 kann vom Betrieb
ausgeschlossen werden. Die verbleibenden Host-Controller 110 und 120 können weiter
in einer synchronisierten Weise arbeiten. Als Alternative, wenn
es nur einen verbleibenden Host-Controller 110 oder 120 gibt,
dann kann die Logik 130 weiter Speicherzugriffe mit der
gemeinsamen Frame-Rate ausführen 230 oder
kann Speicherzugriffe mit der innewohnenden Frame-Rate des verbleibenden
Host-Controllers 110 oder 120 ausführen 230.
-
Bei
einer Ausführungsform
kann ein EHCI-Host-Controller 120 mit einem UHCI-Host-Controller 110 synchronisiert
werden, indem jedes Frame-Abholen für den UHCI-Host-Controller 110 ungefähr zu derselben
Zeit wie das jeweils achte Frame-Abholen für den SCHI-Host-Controller 120 durchgeführt wird.
Dies synchronisiert die Host-Controller 110 und 120 in
dem Sinne, dass jeder Speicherzugriff für den UHCI-Host-Controller 110 zu
derselben Zeit geschieht, wie ein Speicherzugriff für den EHCI-Host-Controller 120,
anstatt zwischen Abholungen durch den EHCI-Host-Controller 120.
Zum Beispiel kann die Logik 130 jeweils acht Abholungen
für den
EHCI-Host-Controller 120 verfolgen, da die Abholungen alle
125 μs geschehen,
so dass acht Abholungen ungefähr
1 Millisekunde überspannen.
Bei einer weiteren Ausführungsform
kann der EHCI-Host-Controller 120 die Abholungen verzögern, so dass
die Speicherzugriffe nur alle Millisekunden anstatt acht Mal pro
Millisekunde geschehen.
-
Obwohl
hierin auf einen ersten und einen zweiten Host-Controller 110 und 120 Bezug
genommen ist, ist der Bezug auf den ersten und den zweiten Host-Controller 110 und 120 lediglich
symbolisch für mehrere
Host-Controller. Der Bezug auf den ersten und den zweiten Host-Controller 110 und 120 innerhalb
der Beschreibung und in den Ansprüchen sollte nicht auf nur zwei
Host-Controller beschränkt
sein und kann einen oder mehrere zusätzliche Host-Controller innerhalb
der beschriebenen und/oder beanspruchten Ausführungsformen umfassen. Weitere Ausführungsformen
können
mehr als zwei Host-Controller 110 und 120, unterschiedliche
Kombinationen von UHCI-Host-Controllern 110, EHCI-Host-Controllern 120 und
anderen Typen von Host-Controller umfassen.
-
5 veranschaulicht
eine Ausführungsform
eines Zeitdiagramms 300 für den Betrieb synchronisierter
Host-Controller 110 und 120. Das Zeitdiagramm 300 zeigt
einen ersten Speicherzugriff für einen
ersten Host-Controller, der an einem gemeinsamen Frame beginnt.
Obwohl ein zweiter und ein dritter Host-Controller erkannt werden
und ihre Laufbits während
des ersten Frame gesetzt werden, werden Speicherzugriffe für den zweiten
und den dritten Host-Controller bis zum gemeinsamen Frame-Übergang
zwischen dem ersten und dem zweiten Frame nicht durchgeführt. Bei
einer weiteren Ausführungsform
kann die Logik 130 warten und die Laufbits für den zweiten
und den dritten Controller ungefähr
am gemeinsamen Frame-Übergang
setzen anstatt zu dem Zeitpunkt, wenn der zweite und der dritte
Controller erkannt werden.
-
Zusätzlich ist
der dritte Host-Controller repräsentativ
für einen
EHCI-Controller 120 oder für einen anderen Typ eines Controllers,
der mehr Speicherzugriffe pro Frame durchführt als ein alter Host-Controller 110.
Insbesondere ist der dritte Controller so gezeigt, dass er drei
Abholungen während
des zweiten Frames anstatt einem einzigen Speicherzugriff durchführt. Obwohl
der dritte Controller mehr Speicherzugriffe durchführt als
der erste und der zweite Controller, kann der dritte Controller
weiter als mit dem ersten und dem zweiten Controller synchronisiert
betrachtet werden, da einer der Speicherzugriffe des dritten Controllers
mit den Speicherzugriffen des ersten und des zweiten Controllers
synchronisiert ist.
-
Das
Speicherzugriffssignal für
das Verbundsystem, das an der Unterseite des Zeitdiagramms 300 gezeigt
ist, veranschaulicht, dass Speicherzugriffe für alle Host-Controller 110 und 120 ungefähr am Beginn
jedes gemeinsamen Frame synchronisiert sind. Dies minimiert die
Zeitdauer, über
die der I/O Controller-Hub 40 den Prozessor 10 oder
andere Systemkomponenten daran hindert, in einen Zustand niedriger
Leistung einzutreten, so wie den Zustand C3. Obwohl die Zeitdiagramme
der 5 und 1 nur schematisch sind, kann
der Unterschied in der verlängerten
Zeit des Energiezustandes C3 in dem Zeitdiagramm 300 der 5 als
die angesammelte und ununterbrochene Zeitdauer gesehen werden, über die
der Prozessor 10 in dem Zustand C3 sein kann. Es sollte
auch angemerkt werden, dass obwohl die Speicherzugriffe des Verbundsystems
des zweiten Frame des Zeitdiagramms 300 der 5 ähnlich den
Speicherzugriffen des Verbundsystems des zweiten Frame des Zeitdiagramms
der 1 zu sein scheinen, diese scheinbare Ähnlichkeit
nicht für
das Leistungsverhalten bezeichnend ist. Das Zeitdiagramm der 1 zeigt
Speicherzugriffe des Verbundsystems bei mehreren Host-Controllern 110,
die jeder auf den Systemspeicher 50 mit einer Frame-Rate
von 1 Millisekunden zugreifen. Im Gegensatz dazu zeigt das Zeitdiagramm 300 der 5 Speicherzugriffe
des Verbundsystems mit einem Host-Controller 110, der auf
den Systemspeicher 50 mit einer Frame-Rate von 125 Mikrosekunden
zugreift, zusätzlich
zu den Host-Controllern 110, die auf den Systemspeicher 50 mit
einer Frame-Rate von einer Millisekunde zugreifen. Zusätzlich sind
die Systemspeicherzugriffe der Host-Controller 110 der 1 nicht
synchronisiert, während
die Host-Controller 110 der 5 synchronisiert
sind, obwohl Host-Controller mit unterschiedlichen Frame-Raten gleichzeitig
implementiert sind.
-
6 veranschaulicht
eine Ausführungsform
eines Zustandsdiagramms 350 für eine Zustandsmaschine, um
mehrere Host-Controller 110 und 120 zu synchronisieren.
Bei einer Ausführungsform
kann die Zustandsmaschine in der Logik 130 implementiert
sein. Aus Zweckmäßigkeitsgründen beim Erläutern des
Betriebes des Zustandsmaschine ist die Zustandsmaschine so veranschaulicht,
dass sie auf drei unabhängigen
USB-Host-Controllern 110 und 120 arbeitet, die
als ein erster Controller, ein zweiter Controller und ein dritter
Controller bezeichnet sind. Jedoch können weitere Ausführungsformen mehr
oder weniger USB-Host-Controller 110 und 120 enthalten.
Zusätzlich
können
die Host-Controller 110 und 120 in irgendeiner
Reihenfolge aufgerufen werden.
-
Anfangs
sind alle drei USB-Host-Controller 110 und 120 in
einem schlafenden Zustand 355. Der erste Controller darf
starten, sobald sein Laufbit gesetzt ist. Wie oben beschrieben kann
das Laufbit ein Datenwert sein, welcher in einem Register 80 gespeichert
ist, der anzeigt, dass der erste Controller gestartet worden ist
und folglich mit einer Frame-Rate das Abholen beginnen wird. Der
Zustand, in dem der erste Controller läuft, wird als der „Ein Controller"-Zustand 360 bezeichnet. Wenn
der zweite und der dritte Controller erkannt werden, werden die
entsprechenden Laufbits gesetzt, jedoch werden der zweite und der
dritte Controller bis zu einem gemeinsamen Frame-Übergang
oder dem Start des Frame-Markierers, von dem der erste Controller
beobachtet wird, gesperrt. Der gemeinsame Frame-Übergang kann auf dem Frame-Zähler des
ersten Controllers oder einem globalen Frame-Zähler, der von dem Frame-Zähler des ersten Controllers
unterschiedlich ist, basieren. Wenn die Laufbits für den zweiten
und den dritte Controller gesetzt sind und der gemeinsame Frame-Übergang
eingerichtet ist, kann die Zustandsmaschine in den „Zwei Controller"-Zustand 370 und
in den „Drei
Controller"-Zustand 380 eintreten.
-
Bei
einer Ausführungsform
kann die Logik 130 einen Zeitgeber verwenden, der mit jedem USB-Host-Controller 110 und 120 verbunden
ist, der angibt, wann die gemeinsame Frame-Zeitdauer abgelaufen ist, wodurch er
den Start eines Frame-Markierers angibt. Die Logik 130 kann
eine Angabe für „Zeitgeber
abgelaufen" oder „Zeitgeber
umgedreht (rolled over)" von
dem einen der USB-Host-Controller 110 oder 120 erkennen
und diese Angabe benutzen, um anzugeben, wann die Logik 130 Abholungen
für die
anderen USB-Host-Controller 110 und 120 durchführt. Auf
diese Weise braucht keine neue Software benutzt zu werden, da die
Logik 130 das Laufbit und die Zeitgeberangaben von jedem
USB-Host-Controller 110 oder 120 beobachten kann,
um mehrere USB-Host-Controller 110 und 120 zu
synchronisieren. Als Alternative kann Software eingesetzt werden.
Bei einer weiteren Ausführungsform
kann ein globaler Frame-Zähler
innerhalb der Logik 130 implementiert werden.
-
Als
ein weiteres Beispiel kann die Steuerlogik 130 für die Frame-Synchronisation
beim USB in ein I/O-Bauelement integriert werden, so wie in den I/O
Controller-Hub 40, welcher mehrere USB-Host-Controller 110 und 120 umfasst
(z. B. EHCI, UHCI und/oder OHCI). Bei einer Ausführungsform umfasst die Logik 130 eine
Ausgangsschnittstelle zu mehreren USB-Host-Controllern 110 und 120,
um zu verhindern, dass die Frame-Zähler der mehreren USB-Host-Controller 110 und 120 asynchron
inkrementieren. Die Logik 130 kann auch eine Eingangsschnittstelle
umfassen, um ein Signal von jedem der USB-Host-Controller 110 und 120 zu
empfangen, die angeben, wann jeder USB-Host-Controller 110 oder 120 einen
neuen Frame beginnt. Die Eingangsschnittstelle kann auch verwendet
werden, um ein Signal einzugeben, das den gegenwärtigen Wert des Laufbits von
jedem der USB-Host-Controller 110 und 120 angibt.
-
Bei
einer weiteren Ausführungsform
kann die USB-Frame-Synchronisation derart implementiert werden,
dass vom Rücksetzen
her alle USB-Host-Controller 110 und 120 leer
laufen, wobei ihre jeweiligen Laufbits gelöscht sind, was eine von den
USB-Host-Controllern 110 und 120 ausgehende Aktivität verhindert.
Wenn die Software anschließend das
Laufbit eines der USB-Host-Controller 110 oder 120 setzt,
beginnt sein Frame-Zähler
wie üblich,
und der USB-Host-Controller 110 oder 120 wird
auf den Systemspeicher 50 zugreifen. Wenn ein anschließendes Laufbit
bei einem anderen USB-Host-Controller 110 oder 120 gesetzt
wird, startet der Frame-Zähler
des nachfolgenden USB-Host-Controllers 110 oder 120 nicht
unmittelbar. Stattdessen hält
die Steuerlogik 130 für
die USB-Frame-Synchronisation den Frame-Zähler
fest, bis der erste USB-Host-Controller 110 oder 120 eine
Frame-Grenze erreicht. Ähnliche
Arbeitsgänge
können
implementiert werden, um folgende USB-Host-Controller 110 und 120 zu
synchronisieren, wenn zugeordnete Laufbits gesetzt werden. Diese
Frame-Synchronisation
zwischen den USB-Host-Controllern 110 und 120 synchronisiert
die Speicherlesezugriffe für
die Frame-Liste auf den Systemspeicher 50, die ansonsten asynchron
geschehen würden.
Bei einer Ausführungsform,
falls die Frames keine aktiven Übertragungs-Deskriptoren haben,
dann wird es wenige, wenn überhaupt
irgendwelche, Abholungen nach dem Zeiger in der Frame-Liste geben.
Zusätzlich
verteilt der I/O Controller-Hub 40 keine Anfragen von mehreren
Controller 110 und 120, sondern hat statt dessen
eine straffer gesteuerte Zeitdauer, während der alle Controller 110 und 120 gleichzeitig
ihre jeweiligen Listen analysieren. Während der Zeitdauern, in denen
wenig bis kein USB-Verkehr geplant ist, kann die Rechenplattform 110 in
Zustände
niedrigerer Energie übergehen.
Ansonsten könnten
diese Zeiten durch zufällige
Speicheraktivität
nicht synchronisierter Controller 110 und 120 gekennzeichnet
werden, was die Rechenplattform 10 daran hindern würde, in Zustände niedrigerer
Leistung überzugehen.
-
Bei
einer Ausführungsform
kann die Frame-Synchronisation, die oben beschrieben ist, den Fußabdruck
des Speicherzugriffs der USB-Host-Controller 110 und 120 verringern,
um zu ermöglichen,
dass weitere Komponenten der Rechenplattform 10 öfter in
Zustände
niedrigerer Leistung eintreten und über verlängerte Zeitdauern in Zuständen niedriger
Leistung verbleiben. Geringere Leistung der Plattform ist bei verschiedenen
Rechenplattformen sehr wertvoll, einschließlich bei mobilen Plattformen.
Weiterhin, wenn einer Rechenplattform 10 zusätzliche
USB-Host-Controller 110 und 120 hinzugefügt werden,
um neue Initiativen anzuspre chen, kann die Effektivität der Frame-Synchronisation
weiter das Leistungsverhalten der Plattform verbessern. Darüber hinaus
kann die Möglichkeit,
die Wechselwirkung zwischen unabhängigen USB-Host-Controllern 110 und 120 zu
regieren, um ihre Frame-Zähler in
einer für
Software transparenten Weise zu synchronisieren, dafür sorgen,
dass für
die Rechenplattform 10 weniger Energie erforderlich ist.
-
7 veranschaulicht
eine alternative Ausführungsform
einer Rechenplattform 400, um mehrere Host-Controller 110 und 120 zu
synchronisieren. Bei einer Ausführungsform
kann die Rechenplattform 400 ein mobiles Gerät sein.
Beispiele mobiler Geräte umfassen
einen Laptop-Computer, ein Mobiltelefon, einen persönlichen
digitalen Assistenten oder ein anderes ähnliches Gerät mit Rechenleistung
und Möglichkeit
zur drahtlosen Kommunikation an Bord, die von einer Gleichstrom(DC – Direct
Current)-Energiequelle versorgt wird, so wie einer Brennstoffzelle
oder einer Batterie, die eine DC-Spannung an das mobile Gerät liefert
und die sich ausschließlich
innerhalb des mobilen Gerätes
befindet. Zusätzlich
kann die DC-Energiequelle
auf einer periodischen Basis wiederaufgeladen werden.
-
Bei
einer Ausführungsform
weist das Computersystem 400 einen Kommunikationsmechanismus
oder Bus 411 zum Kommunizieren von Information und eine
integrierte Schaltungskomponente, so wie eine Hauptverarbeitungseinheit 412,
die mit dem Bus 401 zum Verarbeiten von Information gekoppelt ist,
auf. Eine oder mehrere der Komponenten oder Bauelemente in dem Computersystem 400,
so wie die Hauptverarbeitungseinheit 412 oder ein Chipsatz 436,
können
die Frame-Synchronisation vereinfachen. Die Hauptverarbeitungseinheit 412 kann
einen oder mehrere Prozessorkerne umfassen, die als eine Einheit
zusammenarbeiten.
-
Das
Computersystem 400 weist weiterhin einen Speicher mit wahlfreiem
Zugriff (RAM – Random Access
Memory) oder eine andere dynamische Speichervorrichtung 404 (als
Hauptspeicher bezeichnet), die an den Bus 411 gekoppelt
ist, zum Speichern von Information und Befehlen, die von der Hauptverarbeitungseinheit 412 ausgeführt werden
sollen, auf. Der Hauptspeicher 404 kann zum Speichern zeitweiliger Variablen
oder anderer zwischenzeitlich vorhandener Information während des
Ausführens
von Befehlen durch die Hauptverarbeitungseinheit 412 verwendet werden.
Das Computersystem 400 umfasst auch einen Nur-Lese-Speicher (ROM – Read-Only
Memory) und/oder eine weitere statische Speichervorrichtung 406,
die an den Bus 411 gekoppelt ist, zum Speichern von statischer
Information und von Befehlen für die
Hauptverarbeitungseinheit 412. Die statische Speichervorrichtung 406 kann
Software auf Betriebssystem(OS – Operating
System)-Ebene und auf Anwendungsebene speichern.
-
Die
Firmware 403 kann eine Kombination aus Software und Hardware
sein, so wie ein elektronisch programmierbarer Nur-Lese-Speicher (EPROM – Electronically
Programmable Read-Only Memory), wobei die Arbeitsschritte für die Routine auf
dem EPROM aufgezeichnet sind. Die Firmware 403 kann eingebetteten
Grundlagencode, einen grundlegenden Eingabe/Ausgabe-Systemcode (BIOS – Basic
Input/Output System Code) oder einen anderen ähnlichen Code umfassen. Die
Firmware 403 kann es dem Computersystem 400 möglich machen,
sich selbst hochzufahren.
-
Zusätzlich kann
das Computersystem 400 an eine integrierte Anzeigevorrichtung 421 gekoppelt sein
oder sie enthalten, so wie eine Kathodenstrahlröhre (CRT – Cathode Ray Tube) oder eine
Flüssigkristallanzeige
(LCD – Liquid
Crystal Display), die an den Bus 411 gekoppelt ist, um
dem Nutzer eines Computers Information anzuzeigen. Bei einer Ausführungsform
kann der Chipsatz 436 eine Schnittstelle zu der Anzeigevorrichtung 421 bilden.
-
Eine
alphanumerische Eingabevorrichtung (Tastatur) 422, welche
alphanumerische und weitere Tasten umfasst, kann auch an den Bus 411 zum Kommunizieren
von Information und Befehlsauswahlen an die Hauptverarbeitungseinheit 412 gekoppelt sein.
Weiterhin kann eine Cursorsteuervorrichtung 423, so wie
eine Maus, eine Rollkugel, ein Touchpad, ein Stift oder können Cursorrichtungstasten
an den Bus 411 zum Kommunizieren von Weisungsinformati an
und Befehlsauswahlen an die Hauptverarbeitungseinheit 412 und
zum Steuern der Bewegungen des Cursors auf der Anzeigevorrichtung 421 gekoppelt
sein. Bei einer Ausführungsform
kann der Chipsatz 436 eine Schnittstelle zu den Eingabe/Ausgabevorrichtungen
bilden. In ähnlicher
Weise können
Geräte,
die in der Lage sind, einen Papierausdruck 424 einer Datei
zu erstellen, so wie ein Drucker, ein Scanner, eine Kopiermaschine
usw., auch mit dem Eingabe/Ausgabe-Chipsatz 436 und dem
Bus 411 Wechselwirken.
-
Eine
Energieversorgung, so wie eine Batterie und eine Adapterschaltung
für Wechselstrom
(AC – Alternating
Current) kann an den Bus 411 gekoppelt sein. Weiterhin
kann ein Schallaufzeichnungs- und Wiedergabegerät, so wie ein Lautsprecher
und/oder Mikrofon (nicht gezeigt) als Option an den Bus 411 als
Audioschnittstelle zum Computer 400 gekoppelt sein. Ein
Modul 425 für
die drahtlose Kommunikation kann ebenfalls an den Bus 411 gekoppelt
sein. Das Modul 425 für
die drahtlose Kommunikation kann ein Drahtlos-Anwendungsprotokoll (WAP – Wireless
Application Protocol) verwenden, um einen Kanal für die drahtlose
Kommunikation einzurichten. Das Modul 425 für die drahtlose
Kommunikation kann einen Standard für drahtloses Netzwerk implementieren,
so wie den Standard des Institute of Electrical and Electronics
Engineers (IEEE) 802.11, IEEE Std. 802.11-1999, veröffentlicht
von dem IEEE 1999. Bei anderen Ausführungsformen können andere
Arten drahtloser Technologien in dem Computersystem 400 implementiert
werden.
-
Bei
einer Ausführungsform
kann Software, die verwendet wird, um den Betrieb des Computersystems 400 zu
vereinfachen, in ein maschinenlesbares Medium eingebettet werden.
Ein maschinenlesbares Medium umfasst irgendeinen Mechanismus, der
Information in einer Form, auf die durch eine Maschine (z. B. einen
Computer, ein Netzwerkgerät, ein
persönlicher
digitaler Assistent, ein Herstellungswerkzeug, irgendein Gerät mit einem
oder mehreren Prozessoren usw.) zugegriffen werden kann, zur Verfügung stellt
(d. h. speichert und/oder sendet). Zum Beispiel kann ein maschinenlesbares
Medium beschreibbare/nicht beschreibbare Medien (z. B. Nur-Lese-Speicher
(ROM) einschließlich
Firmware, Speicher mit wahlfreiem Zugriff (RAM), Magnetplatten-Speichermedien,
optische Speichermedien, Flash-Speichervorrichtungen
usw.) ebenso wie elektrische, optische, akustische oder andere Formen sich
fortpflanzender Signale (z. B. Trägerwellen, Infrarotsignale,
digitale Signale usw.) und so weiter umfassen.
-
Ausführungsformen
der vorliegenden Erfindung umfassen verschiedene Arbeitsgänge, wie oben
beschrieben. Diese Arbeitsgänge
können
durch Hardwarekomponenten, Software, Firmware oder ein Kombination
aus diesen durchgeführt
werden. Wie hierin verwendet kann der Ausdruck „gekoppelt mit" direkt oder indirekt
durch eine oder mehrere zwischengeschaltete Komponenten gekoppelt
bedeuten. Irgendeines der Signale, die über verschiedene Busse, wie
sie hierin beschrieben sind, zur Verfügung gestellt wird, kann mit
anderen Signalen zeitlich multiplexiert sein und über einen
oder mehrere gemeinsame Busse geliefert werden. Zusätzlich kann
die Verbindung zwischen Schaltungskomponenten oder Blöcken als
Busse oder als einzelne Signalleitungen gezeigt sein. Jeder der
Busse kann alternativ eine oder mehrere einzelne Signalleitungen
sein, und jede der einzelnen Signalleitungen kann alternativ Busse sein.
-
Obwohl
die Arbeitsgänge
der Verfahren hierin in einer bestimmten Reihenfolge gezeigt und
beschrieben sind, kann die Reihenfolge der Arbeitsgänge bei
jedem Verfahren geändert
werden, so dass bestimmte Arbeitsgänge in einer umgekehrten Abfolge
durchgeführt
werden, oder so dass bestimmte Arbeitsgänge wenigstens teilweise gleichzeitig
mit anderen Arbeitsgängen
durchgeführt
werden. Bei einer weiteren Ausführungsform
können
Befehle oder Teilarbeitsgänge
verschiedener Arbeitsgänge
unterbrochen und/oder abwechselnd ausgeführt werden.
-
In
der voranstehenden Beschreibung ist die Erfindung mit Bezug auf
bestimmte beispielhafte Ausführungsformen
beschrieben worden. Es wird jedoch offensichtlich sein, dass verschiedene
Modifikationen und Änderungen
daran vorgenommen werden können,
ohne dass man sich vom breiteten Gedanken und Umfang der Erfindung
entfernt, wie er in den angefügten
Ansprüchen
aufgeführt
ist. Die Beschreibung und die Zeichnungen sollen daher in einem
veranschaulichenden Sinne anstatt in einem beschränkenden
Sinne betrachtet werden.
-
Zusammenfassung
-
Ein
Verfahren, eine Vorrichtung und ein System zum Synchronisieren mehrerer
Host-Controller mit
nicht gleichförmigen
Frame-Raten. Die Vorrichtung umfasst einen ersten Host-Controller, einen zweiten
Host-Controller und Logik. Der erste Host-Controller ist so konfiguriert,
dass er auf einen Speicher mit einer ersten Frame-Rate zugreift.
Der zweite Host-Controller
ist so konfiguriert, dass er auf den Speicher mit einer zweiten
Frame-Rate zugreift, die von der ersten Frame-Rate unterschiedlich
ist. Die Logik ist mit dem ersten und dem zweiten Host-Controller
gekoppelt, um die Speicherzugriffe des ersten und des zweiten Host-Controllers auf eine gemeinsame
Frame-Rate zu synchronisieren. Weitere Ausführungsformen sind beschrieben.