-
QUERE REFERENZ ZU BEZOGENEN
ANMELDUNGEN
-
Die
vorliegende Anmeldung ist bezogen auf die
US Patentanmeldung Serien Nr. 10/317,798 vom 11.
Dezember 2002, die
US Patentanmeldung
Serien Nr. 10/317,776 vom 11. Dezember 2002, die
Patentanmeldung Serien Nr. 10/931,565 vom
31. August 2004, die
US Patentanmeldung
Serien Nr. 10/442,595 vom 21. Mai 2003 und das
US Patent Nr. 6,842,035 ,
das am 11. Januar 2005 ausgegeben worden ist.
-
HINTERGRUND
-
Technisches Gebiet
-
Bestimmte
Ausführungsbeispiele
der vorliegenden Erfindung beziehen sich auf das Leistungsmanagement.
Insbesondere beziehen sich einige Ausführungsbeispiele auf ein Powermanagement
auf der Plattformebene.
-
Diskussion
-
Da
die Komponenten von modernen Rechnersystemen in ihrer Funktionalität und Rechenformfaktoren
kontinuierlich wachsen, wobei sie kontinuierlich in ihrer Größe abnehmen,
stehen sich die Gestalter und Hersteller von Computer häufig erheblichen
Anforderungen bezüglich
des zunehmenden Leistungsverbrauchs entgegen. Infolgedessen wurden
eine Vielzahl von Verfahren entwickelt, um den Leistungsverbrauch
zu verringern. Beispielsweise schließen einige Ansätze das
Herabsetzen der Leistung von Systemkomponenten dann, wenn deren Funktionalität nicht
erforderlich ist, ein. Obwohl diese Lösungen unter bestimmten Umständen geeignet sein
können,
bleibt erheblicher Raum für
Verbesserungen.
-
KURZE ERLÄUTERUNG DER ZEICHNUNGEN
-
Verschiedene
Vorteile der Ausführungsbeispiele
der vorliegenden Erfindung ergeben sich dem Fachmann durch eine
Lektüre
der folgenden Beschreibung und der beiliegenden Zeichnungen unter Bezugnahme
auf die folgenden Zeichnungen, in denen:
-
1 ein
Blockdiagramm eines Beispiels einer Vorrichtung nach einem Ausführungsbeispiel
ist;
-
2A und 2B Zeitdiagramme
von Beispielen von einen Eingangsspeicher inaktivierenden Schemata
entsprechend einem ersten bzw. einem zweiten Ausführungsbeispiel
sind;
-
3 ein
Flussdiagramm eines Beispiels eines Verfahrens eines Leistungsmanagements
nach einem Ausführungsbeispiel
ist; und
-
4 ein
Blockdiagramm eines Beispiels eines Systems nach einem Ausführungsbeispiel
ist.
-
EINGEHENDE BESCHREIBUNG
-
In
der nachfolgenden Beschreibung werden zum Zwecke der Erläuterung
verschiedene spezifische Einzelheiten dargestellt, um das volle
Verständnis
der Ausführungsbeispiele
der vorliegenden Erfindung zu ermöglichen. Es versteht sich jedoch
für den Fachmann,
dass die Ausführungsbeispiele
der vorliegenden Erfindung ohne diese spezifischen Einzelheiten
verwirklicht werden können.
In anderen Beispielen werden spezifische Strukturen der Vorrichtungen und
der Verfahren nicht beschrieben, um die Ausführungsbeispiele der vorliegenden
Erfindung nicht unklar zu machen. Die nachfolgende Beschreibung
und die Zeichnungen sind für
die Ausführungsbeispiele der
Erfindung illustrativ und dienen nicht zur Beschränkung der
Ausführungsbeispiele
der Erfindung.
-
Einige
Abschnitte der eingehenden nachfolgenden Beschreibung können in
Begriffen von Algorithmen und symbolischen Darstellungen von Operationen
an Datenbits oder binären
digitalen Signalen in einem Computerspeicher dargestellt werden.
Diese algorithmischen Beschreibungen und Repräsentationen können die
Verfahren, die von dem Fachmann auf dem Gebiet der Datenverarbeitung
angewendet werden, um den Gegenstand ihrer Arbeit anderen Fachleuten
zu erläutern.
Beispielsweise kann eine bestimmte Logik, wie sie hier beschrieben
worden ist, unter Verwendung von Hardwaretechniken wie einer Complementary
Metal Oxide Semiconductor (CMOS) Technologie oder einer Transistor-Transistor Logic
(TTL), einer Controllerfirmware, einem Mikrocode, Softwaretechniken
und jeder beliebigen Kombination daraus implementiert werden. Die
hier beschriebenen Komponenten können
auch in eine oder mehrere Packages einer integrierten Schaltung
(IC) (d. h. Chips) eingebaut sein, die auf einem Die, das aus einem
Wafer geschnitten ist, hergestellt werden.
-
Verwendungen
der Begriffe „erster", „zweiter", usw. müssen nicht
notwendigerweise eine chronologische Beziehung angeben, sie werden
hier lediglich zur Vereinfachung der Diskussion verwendet. Soweit
dies nicht anders besonders angegeben ist, wie sich aus den nachfolgenden
Diskussionen ergibt, versteht es sich, dass in dieser Beschreibung
Diskussionen unter Verwendung von Ausdrücken wie „Verarbeiten" „Berechnen", Kalkulieren", „Bestimmen" oder dgl. sich auf
die Aktion und/oder Prozesse eines Computers oder eines Rechnersystems
oder eine ähnliche
elektronische Recheneinrichtung beziehen, die Daten manipulieren
und/oder transformieren kann, die als physikalische, etwa elektronische,
Mengen in Registern und/oder Speichern eines Rechnersystems dargestellt
werden in andere Daten, die ähnlich
als physikalische Mengen in den Speichern, Registern oder anderen
Informationsspeichern, Übertragungs-
oder Displayeinrichtungen repräsentiert werden.
Weiter können
Begriffe wie „gekoppelt" oder „koppelnd" sich auf jede Art
von Verbindung, direkt oder indirekt, zwischen den in Frage stehenden
Komponenten beziehen und eine mechanische, elektrische, optische,
elektromagnetische oder eine andere Art von Beziehung einschließen.
-
Der
Begriff „Transaktion", wie er hier verwendet
wird, bezeichnet eine Busaktivität,
die auf eine einzige Buszugriffsanfrage bezogen ist. Eine Transaktion
kann verschiedene Phasen einschließen, wobei jede Phase mit einem
spezifischen Satz von Bussignalen zugehörig ist zum Kommunizieren einer
besonderen Art von Information. Bei einem Ausführungsbeispiel können die
beispielhaften Phasen z. B., eine Abwägungsphase, eine Anforderungsphase, eine
Schnüffelphase,
eine Antwortphase und/oder eine Datenphase beinhalten.
-
In
der Anforderungsphase kann der Anforderungsagent eine Anforderungskontrolle
und eine Adressinformation auf dem Bus treiben. Während einer
nachfolgenden Schnüffelphase
kann bestimmt werden, ob die nachgesuchten Daten lokal gespeichert
sind und/oder ob die Transaktion wahrscheinlich richtig abgeschlossen
ist bezüglich
der vorher ausgegebenen Transaktionen. In einer Antwortphase kann
der Antwortagent an den Anforderungsagent Information berichten
die angibt, ob die angeforderte Transaktion erfolgreich war oder
nicht. Wenn die angeforderte Transaktion einen Datentransfer einschließt, kann
eine Datenphase, auch als Datentransferphase bezeichnet, in Antwort
auf die Annahme eines Data Ready Signals.
-
1 zeigt
eine Vorrichtung 10 mit einem Controller 12 und
einem Prozessor 18. Der Prozessor 18 und der Controller 12 können miteinander über einen
Bus 22 kommunizieren, wobei in dem einen Beispiel der Bus
ein getunnelter Front Side Bus (FSB) ist, der Adress-, Daten- und
Steuerteile aufweist. Die Adress-, Daten- und Steuerabschnitte können auch
als Adress-, Daten- und Steuerbusse bezeichnet werden. Bei anderen
Beispielen kann der Bus 22 Teil eines Punkt-zu-Punkt Verbindungsgeflecht
sein, das eine direkte Kombination zwischen mehreren Komponenten
eines Rechnersystems erlaubt.
-
Der
dargestellte Controller 12, der ein Teil eines Graphic
Model and Memory Controller Hub (GMCH) sein kann, wie er gewöhnlich bei
Chipsets eines Rechnersystems verwendet wird, hat einen Leistungssparbotschaftsleitungseingang 14 und
eine Leistungsmanagementlogik 21.
-
Der
Controller 21 kann weiter einen oder mehrere Eingangspuffer 16 aufweisen,
die mit dem Bus 22 gekoppelt sind und eine Leistungsmanagementlogik 21,
wobei die lokale Logik 23 mit der Leistungsmanagementlogik 21 gekoppelt
ist und eine externe Logik 25, die mit der Leistungsmanagementlogik 21 gekoppelt
ist.
-
Der
dargestellte Eingangspuffer 16 hat eine Mehrzahl von Messverstärkern 24,
die einen erheblichen Betrag der Leistung verbrauchen kann, wenn
er zum Empfang von Daten aktiviert ist. Die dargestellte lokale
Logik 23 kann interne Komponenten aufweisen, die einen
funktionalen Block zum Ausführen
verschiedener Informationen, die von dem Controller 12 vorgesehen
werden. Beispielsweise könnte
die lokale Logik 23 Speicheroperationen oder Eingangs/Ausgangs
(10) Managementoperationen durchführen. Die dargestellte externe
Logik 25 könnte
externe Komponenten aufweisen, die einen oder mehrere Speicher (beispielsweise
Systemspeicher) funktionale Blöcke,
wobei die externe Logik 25 von dem Controller 12 gemanagt
werden kann. Die illustrierte lokale Logik 23 und die externe
Logik 25 können
weiter einen erheblichen Betrag an Leistung verbrauchen, wenn sie
für eine
Operation aktiviert sind.
-
Der
Prozessor 18 kann eine Leistungszustandslogik 27 und
eine Buslogik 20 aufweisen, die auch als Busagent bezeichnet
werden kann, die dazu in der Lage ist, eine Leistungssparbotschaft
an den Controller 12 auszugeben. Die dargestellte Leistungsmanagementlogik 21 des
Controllers 12 ist dazu in der Lage, eine Leistungssparaktivität in Antwort
auf die Leistungssparbotschaft auszuführen. Die Leistungssparbotschaft
kann in einer Anzahl verschiedener Wege übertragen werden. In dem dargestellten
Ausführungsbeispiel
verwendet der Prozessor beispielsweise eine Busabschätzungslinie
zum Kommunizieren der Leistungssparbotschaft an den Controller 12.
-
Insbesondere
gibt die dargestellte Buslogik 20 ein Busabschätzungssignal
auf den Leitungseingang 14 auf, immer wenn der Prozessor
mit dem Controller 12 über
den Bus 22 kommunizieren muss. In dem dargestellten Ausführungsbeispiel
wird das Busabschätzungssignal
als „BREQ#" Signal bezeichnet.
Zum Zwecke dieser Diskussion gibt ein „#" an dem Ende eines Signalnamens an,
dass das zugehörige
Signal ein aktives tiefes Signal ist (d. h., als zugewiesen angesehen,
wenn es einen logischen tiefen Pegel auf dem externen Signal treibt).
Es versteht sich, dass aktive hohe Signale stattdessen mit entsprechenden Änderungen
in der zugehörigen
Schaltung zur Schaffung einer ähnlichen
Funktionalität
verwendet werden kann. Weiter sind bei einem Ausführungsbeispiel
eines oder mehrere der Signale, die dem Bus zugehörig sind,
bei sehr tiefer Spannung schwingende Signale, die eine Voltschwingung
haben, die geringer ist als eine volle Schwingung. Es versteht sich
weiter, dass das Busabschätzungssignal
eine kodierte Botschaft sein kann, anders also als ein physikalisches
Signal BREQ#.
-
Die
Buslogik 20 ist auch dazu in der Lage, das Busentscheidungssignal
freizugeben, um dem Controller 12 zu befehlen, die Leistungssparaktivität auszuführen. Die
Leistungssparaktivität
kann das Inaktivieren einer oder mehrerer interner Komponenten des
Controllers 12 und/oder eine oder mehrerer externer Komponenten,
die von dem Controller 12 verwaltet werden, einschießen. Beispielsweise
könnten die
inaktivierten internen Komponenten die Messverstärker 24 der Eingangspuffer 16,
der lokalen Logik 23 usw. einschließen. Entsprechend könnten die
inaktivierten externen Komponenten die externe Logik 25 einschließen, wobei
das Ausführen
der Leistungssparaktivitäten
das Platzieren eines dynamischen Speichers mit wahlfreiem Zugriff
(DRAM) des Systems in einen Niederleistungszustand (beispielsweise
einer Selbstaktualisierung) wenn der Controller 12 ein
Speichercontroller ist. Die Leistungsmanagementlogik 21 des
Controllers 12 kann daher die Freigabe des Busentscheidungssignals
detektieren und verschiedene Leistungssparaktivitäten ausführen in Antwort
auf das Erkennen der Freigabe.
-
In
dem Fall der Inaktivierung des Eingangsspeichers 12 kann
der Speicher 22 als dynamisch „geparkt" bezeichnet werden aus Sicht des Controllers 12.
Entsprechend schafft die Buslogik 20 durch Inaktivieren
des Prozessors 18 zum ausgewählten Ausführen von Leistungssparaktivitäten wie
der Inaktivierung des Eingangspuffers 16 des Controllers 12 erhebliche
Leistungsersparnisse gegenüber
bekannten Ansätzen.
Diese Leistungsersparnisse können
zu einer längeren
Lebensdauer der Batterie in mobilen Plattformen als auch zu reduzierten
Temperaturen führen.
Das Erstrecken der Leistungsmerkmale des Busses 22 auf
die Seite des Controllers 12 des Busses 22 stellt
einen erheblichen Vorteil gegenüber üblichen
Leistungsmanagementarchitekturen dar.
-
Es
wird jetzt auf 2A Bezug genommen, in der ein
Beispiel des Signalisierens für
ein Leistungsmanagementschema 26 in größerer Einzelheit dargestellt
ist. In dem dargestellten Beispiel ist ein Bustaktsignal 28 gezeigt
in Beziehung zu einem Busentscheidungssignal (BREQ#) 30,
einem Busprioritätssignal
(BPRI#) 32, einem Busstatusindikatorsignal (PSI#) 34,
einem gemeinsamen Adressimpulstaktsignal (ADS#) 36, einem
Adress/Anfrage-Signal (Addr/Req.) 38 und einem adresssynchronem
Abtastsignal (ADSTB#) 40. Ein Datenbereitsignal (DRDY#) 41 und
ein Datenbussignal 43 sind weiter gezeigt. In dem dargestellten
Ausführungsbeispiel
ist das Busentscheidungssignal 30 von der Prozessorbuslogik
dem T0 Taktzyklus aufrechterhalten, um die Buszugehörigkeit
zu gewinnen, um mit dem Controller zu kommunizieren. Die dargestellten
gemeinsamen Takt- und
Adressabtastsignale 36, 40 ermöglichen die Übertragung
der Information über
das Adress/Anforderungs-Signal 38 (d. h., „A" und „B") während der
T2-T4 Taktzyklen. Insbesondere wird das gemeinsame Taktsignal 36 verwendet
um anzugeben, dass eine neue Transaktion an den Bus auszugeben ist
und das asynchrone Abtastsignal 40 verwendet wird zum Abtasten
der Doppelpumpadressleitung.
-
Das
dargestellte Busentscheidungssignal 30 wird während des
Tn Taktsignals freigegeben. Die Controllereingangspuffer, die in
dem T0 Taktzyklus inaktiviert sind, können bei Abschluss des letzten Burstdatentransfers,
der mit der DRDY#-Durchsetzung 45 zugehörig ist, inaktiviert werden.
Insbesondere werden, obwohl die Beendigung des Busentscheidungssignals 30 angibt,
dass der Prozessor eine Ausgabeanforderung beendet hat, alle Datentransfers
bezüglich
auf die Anfrage abgeschlossen sein, bevor die Eingangspuffer inaktiviert
werden. Die internen Puffer des Controllers können in dem dargestellten Tn+2
Taktzyklus inaktiv werden. Das Ergebnis kann eine erhebliche Reduktion
des Spannungsverbrauchs in dem Controller sein.
-
Es
sollte beachtet werden, dass jedes Mal, wenn das Busentscheidungssignal 30 wieder
freigegeben wird, dies eine minimale Auswirkung auf die Eigenschaft
haben kann, da eine Neuentscheidung notwendig sein kann, bevor die
nächste
Transaktion auf dem Bus ausgeführt
werden kann. Beispielsweise könnte
die Neuentscheidung zwei Takte zusätzlicher Latenz (beispielsweise
T0 und T1 Taktzyklen in dem gezeigten Beispiel) auf das System aufbringen. Häufige Übergänge in und
aus dem von dem Prozessor initiierten Leistungssparzustand könnte daher eine
unerwünschte
minimale Reduktion der Leistungsfähigkeit verursachen. Entsprechend
kann ein Leerzähler 42 verwendet
werden um sicherzustellen, dass der Bus für eine ausreichende Zeit (beispielsweise
T6 und T7 Taktzyklen in dem gezeigten Ausführungsbeispiel) leer läuft, bevor
das Busentscheidungssignal 30 wieder freigegeben wird.
Es sollte beachtet werden, dass der Ruhezeitzählwert abhängig von den Umständen auf
einen beliebigen Wert (d. h., Null und mehr) programmiert werden
kann. Diesbezüglich
kann die Prozessorbuslogik den Zählerwert aus
einem programmierbaren Speicherort auslesen, etwa dem Basis Eingangs/Ausgangs-System
(BIOS) eines löschbaren
programmierbaren Nur-Lese-Speichers
(EPROM) und die Anzahl der Ruhezeittaktzyklen mit dem Zählerwert
vergleichen zum Bestimmen, ob das Busentscheidungssignal 30 wieder
freizugeben ist.
-
Die
Entscheidung, ob das Busentscheidungssignal 30 freizugeben
ist, kann auch basierend auf der Betriebsfrequenz des Prozessors
durchgeführt
werden. Diesbezüglich
könnte
der Prozessor dazu in der Lage sein, seine Frequenz/Spannung zu reduzieren
während
Perioden relativer Inaktivität oder
zum sonstigen Leistungssparen. Die Freigabe des Busentscheidungssignals 30 könnte limitiert
sein auf Zeitdauern, wenn die Betriebsfrequenz des Prozessors unterhalb
eines Frequenzschwellenwerts ist.
-
Bei
einem Ausführungsbeispiel
kann der Prozessor einen tieferen Frequenzmodus (LFM) annehmen,
um eine größere Lebensdauer
der Batterie zu bewirken. Wenn der Prozessor dazu in der Lage ist,
einen solchen Niederfrequenzmodus zu erreichen ist es erwünscht, die
Verwendung der Busentscheidungsfreigabe in den LFM Perioden zu verwenden,
um die mögliche
Einschränkung
der Leistungsfähigkeit,
die mit der Freigabe verbunden ist, zu verstecken. Einfach ausgedrückt, kann
die Freigabestrafe vernachlässigbar
sein im Vergleich zu der Leistungseinschränkung die mit dem LFM verbunden
ist. In dem dargestellten Beispiel stellt die Prozessorbuslogik
sicher, dass das LFM Signal 34 beibehalten wird vor dem
Fortschreiten mit der Freigabe des Busentscheidungssignals 30.
Die Frequenz, bei der die Leistungssparaktivität aktiviert wird, kann programmierbar
sein. Beispielsweise ist es möglich,
den Wert 1,3 GHz zu speichern, wobei immer dann, wenn der Prozessor
eine Frequenz gleich oder geringer als 1,3 GHz erreicht, die Leistungssparbotschaft
aufrechterhalten bleibt. Alternativ könnte die Leistungssparbotschaft
jedes Mal, wenn der Eigenschaftszustand (z. B., der P-Zustand) des
Prozessors unter einen vorgegebenen Wert sinkt. Dasselbe gilt für eine Mehrzahl von
Kernen/Prozessoren, wenn der kombinierte Zustand evaluiert wird.
-
Alternativ
könnte
der Zustand des LFM Signals 34 gänzlich ignoriert werden, wenn
entschieden wird, ob eine Freigabe des Busentscheidungssignals 30 erfolgen
soll. Ein Umstand, bei dem ein derartiges Vorgehen akzeptabel sein
kann könnte
in dem Fall einer sehr kleinen Rechnerplattform vorhanden sein (beispielsweise
einem mobilen Personal Digital Assistant), bei der die Lebensdauer
der Batterie, eine Priorität über die
Leistungsfähigkeit
hat.
-
Obwohl
nicht gezeigt, könnte
die Prozessorbuslogik weiter die Entscheidung, ob das Busentscheidungssignal 30 freizugeben
ist, auf dem Busverhältnis
(d. h., dem Verhältnis
der Prozessorbetriebsfrequenz zu der Busbetriebsfequenz) basieren. Beispielsweise
könnte
die Prozessorbuslogik bestätigen,
dass das Busverhältnis
unter einer bestimmten Schwelle liegt um sicherzustellen, dass die
Freigabe bezogen auf die Leistungseinschränkung nicht sichtbar ist. Ein
solches Verfahren könnte
angewendet werden zusätzlich
zu oder anstatt der Hochfrequenzprüfung, die von dem LFM Signal 34 durchgeführt wird.
Wenn das LFM Signal 34 nicht verwendet wird, könnte der
Busverhältnisansatz
einen geeigneten Betrieb auch dann ermöglichen, wenn der Prozessor in
dem Hochfrequenzmodus ist.
-
Es
sollte beachtet werden, dass das Busleistungssignal 32,
das von dem Controller zu dem Prozessor wandert, auch von dem Controller
freigegeben werden kann, um die Eingangspuffer des Prozessors effektiv
zu inaktivieren und noch größere Leistungsersparnisse
zu erreichen.
-
2B zeigt
ein Beispiel eines Leistungsmanagementschemas 44, bei dem
der Controller mehr als einen Prozessor unterstützt. Bei diesem Beispiel ist
ein erster Prozessor einem ersten Busentscheidungssignal (BREQ[0]#) 46 zugehörig und ein
zweiter Prozessor ist einem zweiten Busentscheidungssignal (BREQ[1]#) 48 zugehörig. Die
beiden Busentscheidungssignals 46, 48 können über ein
OR verbunden sein, so dass der Eingangspuffer des Controllers aktiviert
wird wenn einer der Prozessoren das Signal führt. Bei dem dargestellten
Beispiel wird der Controllereingangspuffer inaktiviert bis zum Tn+2 Taktzyklus,
bei dem beide Busentscheidungssignale 46, 48 freigegeben
werden. Ein Multiprozessorbusentscheidungsprotokoll kann verwendet
werden, um die Beibehaltung/Freigabe der Signale 46, 48 zu verwalten.
Es kann in dem dargestellten Ausführungsbeispiel erkannt werden,
dass ein Zählerwert von
drei Taktzyklen verwendet wird, so dass der letzte Prozessor zum
Annehmen einer Freigabe seines jeweiligen Busentscheidungssignals
(d. h., des zweiten Prozessors in dem gezeigten Ausführungsbeispiel)
gezwungen ist, auf den Abschluss der T6 bis Tn Taktsignale zu warten,
bevor der Controllereingangspuffer über das Busentscheidungssignal 48 inaktiviert
wird.
-
Es
wird jetzt auf 3 Bezug genommen, in der ein
Verfahren 50 des Leistungsmanagements gezeigt ist. Das
Verfahren 50 kann implementiert werden als eine Prozessorbuslogik
unter Verwendung von Hardwaretechniken wie einer Complementary Metal
Oxide Semiconductor (CMOS) Technologie oder einer Transistor-Transistor
Logic (TTL), Controllerfirmware, Mikrocode, Softwaretechniken oder
jede Kombination daraus. In dem dargestellten Ausführungsbeispiel
sorgt der Prozessorblock 52 für ein Aufrechterhalten eines
Busentscheidungssignals von dem Prozessor zu einem Controller, der
einen Busentscheidungsleitungseingang und einen Eingangspuffer hat.
Wenn in dem Block 54 bestimmt wird, dass die Betriebsfrequenz
des Prozessors auf oder unterhalb einer Frequenzschwelle ist (beispielsweise
bei oder unter einer bestimmten Advanced Configuration and Power
Interface/ACPI Spezification, Rev. 3.0, vom 2. September 2004, Px
Zustand, in einem Tieffrequenzmodus usw.), sorgt der Block 56 für ein Bestimmen,
ob ein Bus, der zwischen dem Prozessor und dem Controller angeordnet
ist, für
eine bestimmte Zeit in Ruhe war. Die Bestimmung bei dem Block 56 kann,
wie bereits diskutiert, vergleichen der Anzahl der Ruhetaktzyklen
mit einem Zählerwert
anschließen,
der ermittelt sein kann aus einem programmierbaren Speicherort.
Wenn der Bus eine ausreichende Ruhezeit hat, kann das Busentscheidungssignal
bei dem Block 58 freigegeben werden, um den Controller
anzuweisen, seinen Eingangspuffer zu inaktivieren.
-
Wenn
in dem Block 54 bestimmt wird, dass die Betriebsfrequenz
des Prozessors nicht bei oder unterhalb der Frequenzschwelle sind,
sorgt der Block 40 für
ein Bestimmen, ob das Busverhältnis
unterhalb einer bestimmten Schwelle ist. Beispielsweise könnte bestimmt
werden, dass dann, wenn das Busverhältnis kleiner als 2:1 ist,
die relative Buseigenschaft die ist, dass eine zusätzliche
Leistungseinschränkung,
die mit einer Freigabe verbunden ist, vernachlässigbar sein kann. Das heißt, wenn
der Block 60 bestimmt, dass das Busverhältnis unterhalb der relevanten
Schwelle ist, ein Prüfen
des Busleerlaufs bei dem Block 56 noch durchgeführt werden
kann. Ansonsten kehrt der Prozess zu dem Block 52 zum Wiederannehmen
des Busentscheidungssignals zurück.
-
4 zeigt
ein Rechnersystem 64, das ein Teil eines Servers, ein Desktop
Personal Computer (PC), ein Notebook PC, ein Personal Digital Assistant (PDA),
ein drahtloses „Smart" Telefon usw. sein kann.
Das dargestellte System 64 hat einen Mikroprozessor 18,
der einen oder mehrere Prozessorkerne (nicht gezeigt) haben kann,
wobei jeder Kern vollständig
funktional mit Befehlsabrufeinheiten, Befehlsdecodern, Level one
(L1) Cache, Ausführungseinheiten
usw. sein kann. Der Mikroprozessor 18 kann weiter eine
Buslogik 20, wie bereits diskutiert, einschließen. Der
Mikroprozessor 18 kann mit einem Grafikmodell und einem
Speichercontrollerhub (GMCH) 66 auch als Northbridge bekannt, über einen Frontseitenbus 22 kommunizieren.
Der Frontseitenbus 22 könnte,
wie bereits erwähnt,
alternativ ersetzt werden durch ein Punkt-zu-Punkt-Netz, das jedes der
Komponenten in dem System 64 verbindet. Der GMCH 66,
der einen Controller 12 aufweisen kann, kann mit dem Random
Access Memory (RAM) 68 über
einen Speicherbus 70 kommunizieren. Bei einem Ausführungsbeispiel
weist das RAM 68 dynamische RAM (DRAM) Module auf. Die
Module des RAM 68 können
zusammengefügt
sein zu einem Single Inline Memory Module (SIMM), Dual Inline Memory
Module (DIMM), Small Outline DIMM (SODIMM) usw. Der GMCH 66 kann
weiter eine oder mehrere Grafikeinheiten (nicht gezeigt) aufweisen.
-
Der
dargestellte GMCH 66 kommuniziert mit einem I/O Controllerhub
(ICH) 72 auch als Southbridge bezeichnet, über einen
Hubbus 74. Der GMCH 66 und der ICH 72 werden
manchmal als ein Chipset 86 bezeichnet. Der Mikroprozessor 18 kann auch
betriebsmäßig mit
einem Netzwerk 78 über
einen Netzanschluss 78 durch das ICH 72 verbunden sein.
Das ICH 72 kann auch mit einem Speicher 80 gekoppelt
sein, der ein Read Only Memory (ROM) 122, einen Flashspeicher 84 usw.
aufweisen kann. Bei einem Ausführungsbeispiel
ist die Buslogik 20 konfiguriert zum wahlweisen Beibehalten
eines Busentscheidungssignals für
den Controller 12 um den Leistungsverbrauch des Chipsets 86 zu
reduzieren.
-
Verschiedene
Ausführungsbeispiele
des offenbarten Gegenstands können,
wie bereits erwähnt, in
Hardware, Firmware, Software oder einer Kombination daraus implementiert
sein und können
beschrieben werden durch Bezugnahme auf oder Verbindung mit einem
Programmcode etwa Befehlen, Funktionen, Prozeduren, Datenstrukturen,
Logiken, Applikationen, Designausgestaltungen oder Formate für Simulation,
Emulation und Herstellung eines Designs, das bei einem Zugriff von
einer Maschine zu Maschinenergebnissen führt, die abstrakte Datentypen
oder Niedrigpegelhardwarezusammenhänge definieren oder ein Ergebnis
erzeugen.
-
Für Simulationen
kann der Programmcode eine Hardware darstellen unter Verwendung
einer Hardwarebeschreibungssprache oder einer anderen funktionalen
Beschreibungssprache, die im Wesentlichen ein Modell schafft, wie
eine ausgebildete Hardware arbeiten wird. Der Programmcode kann
eine Assembler- oder Maschinensprache sein oder Daten, die kompiliert
und/oder interpretiert werden können.
Weiter ist es in der Fachwelt üblich,
von Software in einer Form oder in einer anderen Form zu sprechen,
als eine Aktion auszuführen
oder ein Ergebnis zu erzeugen. Solche Ausdrücke sind nur eine Kurzform
des Feststellens der Ausführung
eines Programmcodes durch ein Prozessorsystem, das einen Prozessor
veranlasst, eine Aktion oder ein Ergebnis zu erzeugen.
-
Der
Programmcode kann, beispielsweise, in flüchtigen und/oder nicht-flüchtigen
Speichern gespeichert werden, etwa einer Speichereinheit und/oder
einem zugehörigen
maschinenlesbaren oder von einer Maschine zugreifbaren Medium einschließlich einem
Solid-State-Memory, einem Hard-Drive, Floppy-Disk, optischen Speichern,
Bändern,
einem Flashspeicher, Memorysticks, Digital Video Disks, Digital
Versstile Diskcs (DVDs), usw., als auch einem oder mehreren exotischen
Medien wie einem von einer Maschine zugreifbaren einen biologischen
Zustand erhaltenden Speicher. Ein maschinenlesbares Medium kann
jeden Mechanismus zum Speichern, Übertragen und Empfangen von
Information in einer von einer Maschine lesbaren Form beinhalten
und das Medium kann ein konkretes Medium beinhalten, über das
elektrische, optische, akustische oder andere Formen von fortschreitenden
Signalen oder Trägerwellen
die den Programmcode codieren passieren kann, wie Antennen, optische
Fasern, Kommunikationsschnittstellen usw. Der Programmcode kann
in der Form von Paketen, seriellen Daten, parallelen Daten, fortschreitenden
Signalen usw. übertragen
werden und kann in einem komprimierten oder verschlüsselten
Format verwendet werden.
-
Programmcodes
können
implementiert sein in Programmen, die auf programmierbaren Maschinen
arbeiten, etwa mobilen oder stationären Rechnern, Personal Digital
Assistants, Set Top Boxes, Cellular Telephones und Pagern und anderen
elektronischen Geräten,
einschließlich
einem Prozessor, flüchtigen
oder nicht-flüchtigen
Speichern, die von dem Prozessor lesbar sind, wenigstens einer Eingabeeinheit
und/oder einem oder mehreren Ausgabeeinheiten. Der Programmcode
kann auf die Daten, die unter Verwendung der Eingabeeinheit erreicht werden
angewendet werden zum Ausführen
der beschriebenen Ausführungsbeispiele
und zum Erzeugen von Ausgangsinformation. Die Ausgangsinformation
kann auf eine oder mehrere Ausgabeeinheiten angewendet werden. Der
Fachmann erkennt, dass Ausführungsbeispiele
des offenbarten Gegenstandes verwirklicht werden können mit
verschiedenen Computersystemausbildungen einschließlich Multiprozessoren
oder Mehrkernprozessorsystemen, Minicomputer, Mainframecomputern,
als auch überall vorhandenen
oder Miniaturcomputern und Prozessoren, die eingebettet sein können in
praktisch jeder Einheit. Ausführungsbeispiele
des Gegenstandes können
auch verwirklicht werden in verteilten Rechnerumgebungen, wo Aufgaben
ausgeführt
werden können
durch entfernte Prozessoreinheiten, die über ein Kommunikationsnetzwerk
miteinander verbunden sind.
-
Obwohl
Operationen als sequentieller Prozess beschrieben werden können, können einige Operationen
tatsächlich
parallel, gleichzeitig oder in einer verteilten Umgebung ausgeführt werden
und mit einem Programmcode, der lokal oder entfernt gespeichert
ist für
einen Zugriff durch Einzel- oder Mehrprozessormaschinen. Weiter
können
bei einigen Ausführungsbeispielen
die Reihenfolge der Operationen anders angeordnet sein ohne sich
von dem Grundgedanken des offenbarten Gegenstandes zu lösen. Der
Programmcode kann von oder in Verbindung mit eingebetteten Controller
verwendet werden.
-
Dem
Fachmann ist aus der vorangehenden Beschreibung klar, dass vielfältige Techniken
die Ausführungsbeispiele
der vorliegenden Erfindung implementiert werden können in
einer Vielzahl von Formen. Obwohl die Ausführungsbeispiele dieser Erfindung
beschrieben worden sind in Verbindung mit bestimmten Beispielen,
sollte der wirkliche Schutzbereich der Ausführungsbeispiele der Erfindung
nicht derart beschränkt
werden, da andere Modifikationen sich dem Fachmann bei einem Studium
der Zeichnungen, der Beschreibung und der folgenden Ansprüche ergibt.
-
ZUSAMMENFASSUNG
-
Systeme
und Verfahren zur Leistungsverwaltung geben eine Leistungssparbotschaft
von einem Prozessor auf einen Controller aus und verwendenden den
Controller zum Ausführen
einer Leistungssparaktivität
in Antwort auf die Leistungssparbotschaft. Bei einem Ausführungsbeispiel
wird die Leistungssparbotschaft ausgegeben durch Aufheben eines
Busentscheidungssignals und die Leistungssparaktivität kann das
Inaktivieren einer oder mehrerer Eingangspuffer und den Controller
aufweisen.