-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft das Power- bzw. Leistungs- und thermische Management
von Computersystemen und Vorrichtungen bzw. Bausteinen. Im Besonderen
betrifft die vorliegende Erfindung eine Vorrichtung und ein Verfahren
zur dynamischen Regelung der Leistungsverbrauchswerte von Speicherbausteinen in
einem Speichersystem.
-
STAND DER
TECHNIK
-
Im
Zuge der Weiterentwicklung von Computervorrichtungen bzw. Computerbausteinen
und Systemen und der zunehmenden Komplexität, ist ein effektives und effizientes
Power- und thermisches Management der Computervorrichtungen und
Systeme immer wichtiger geworden für die Systementwicklung und
die Implementierung. Da Computervorrichtungen und Systeme nur innerhalb
bestimmter Bereiche der elektrischen Stromversorgung und der Temperatur
ordnungsgemäß und sicher
betrieben werden können,
ist es wichtig sicherzustellen, dass eine ausreichende Stromversorgung
gegeben ist, um verschiedene Vorrichtungen zu betreiben, wenn diese
benötigt
werden. Darüber
hinaus ist es wichtig sicherzustellen, dass die thermischen Bedingungen bestimmte
Schwellen- bzw. Grenzwerte nicht überschreiten, die für den Betrieb
dieser verschiedenen Vorrichtungen bzw. Geräte als sicher gelten. Im Allgemeinen
sind Computervorrichtungen wie zum Beispiel Speicherbausteine so
gestaltet, dass sie verschiedene Betriebsmodi oder Leistungszustände aufweisen,
die unterschiedlichen Leistungswerten und Stromverbrauchswerten
entsprechen. Zu den unterschiedlichen Betriebsmodi oder Leistungszuständen zählen unter
anderem zum Beispiel ein aktiver Modus, ein Standby- bzw. Bereitschaftsmodus,
ein Ruhe- bzw. Schlafmodus, etc. Im Allgemeinen arbeiten Vorrichtungen
im aktiven Modus schneller als in den anderen Modi. In dem aktiven
Modus verbrauchen Vorrichtungen aber auch mehr Leistung und erzeugen
mehr Wärme
als in den anderen Modi. Alle Vorrichtungen in dem System in dem
aktiven Modus zu halten reduziert die Latenzzeit im Betrieb und
verbessert somit die Leistung des Systems insgesamt. Alle Vorrichtungen
in dem aktiven Modus zu halten, verbraucht jedoch auch mehr Leistung
und erzeugt eine größere Wärmeausbreitung.
Selbst wenn die Systemstromversorgung ferner ausreicht, um alle
Vorrichtungen in dem System zu betreiben, können sich einige der Vorrichtungen
trotzdem im Ruhezustand befinden, und somit wäre es eine Verschwendung von
Ressourcen, alle Vorrichtungen stets im aktiven Modus zu halten.
Die Anforderungen hinsichtlich der Systemleistung und die Anforderungen
hinsichtlich des Systemleistungsverbrauchs müssen ausgeglichen werden. Um
ein Gleichgewicht zwischen der Systemleistung und dem Systemleistungsverbrauch
sowie der Wärmeausbreitung
zu erhalten, ist es erforderlich, eine bestimmte Anzahl der Vorrichtungen
in einem inaktiven Modus zu halten, um den Leistungsverbrauch ebenso
zu reduzieren wie die Wärmeabstrahlung.
Abhängig
von den Anwendungen und der Betriebsumgebung kann die Anzahl der
in dem inaktiven Modus zu haltenden Vorrichtungen variieren. Zum
Beispiel offenbart das U.S. Patent US-A-5.901.103 eine integrierte
Schaltung mit einer CPU und Speicherbänken mit einer Mehrzahl von
Leistungsschaltern, die dazu eingesetzt werden, dynamisch auszuwählen, welche
Signale einer Mehrzahl externer Spannungsversorgungssignale bereitgestellt
werden, um jeden der Speicherblöcke
mit Leistung bzw. Strom zu versorgen. Die Leistungsregelungsschalter
können
durch Software gesteuert bzw. geregelt werden, oder eine intelligente
Steuereinheit kann dynamisch die Schalter als Reaktion auf den Ausführungsablauf
von Datenzugriffen und Befehlserfassungen aus den Speicherbänken steuern,
so dass Speicherbänke,
auf die gerade zugegriffen wird oder kürzlich zugegriffen worden ist,
auf einen hohen Leistungswert aktiviert werden, während sich
alle anderen Speicherbände
in einem Niederleitungs-Standby-Modus
befinden.
-
Die
vorstehend beschriebenen Beschränkungen
und Kompromisse des Systems in Bezug auf Computervorrichtungen treffen
im Allgemeinen gleichermaßen
auf Speichervorrichtungen bzw. Speicherbausteine in einem Speichersystem
zu. In ihrem aktiven oder Leistung konsumierenden Modus arbeiten
Speicherbausteine, wie etwa DRAM-Bausteine (dynamische Direktzugriffsspeicher)
schneller als wenn sie sich in einem inaktiven Modus befinden (z.B.
Standby- oder Schlafmodus). Allerdings verbrauchen DRAM-Bausteine in ihrem
aktiven Modus auch deutlich mehr Leistung als in dem inaktiven Modus.
Um folglich ein Gleichgewicht zwischen der Leistung und dem Leistungsverbrauch
(und der Wärmeabstrahlung)
zu erhalten, muss eine bestimmte feste Anzahl von DRAM-Bausteinen
in einem inaktiven Modus gehalten werden, um die Leistung zu konservieren
und die Wärmeabstrahlung
zu reduzieren. Die Anzahl der Vorrichtungen bzw. Bausteine in einem aktiven
Modus und die Anzahl der Vorrichtungen in einem inaktiven Modus
kann beim Systemstart (Booten bzw. Hochfahren) oder beim Zurücksetzen
des Systems durch das BIOS (Basic Input/Output Program) spezifiziert
werden. Die Verwaltung, welche Vorrichtungen sich im aktiven Modus
befinden, und welche Vorrichtungen sich im inaktiven Modus befinden,
kann durch eine Definition von Vorrichtungspools erreicht werden,
die dazu eingesetzt werden, den Betriebsmodus oder Leistungszustand
(z.B. aktive oder inaktive) der jeweiligen Vorrichtungen zu verfolgen.
Ein Vorrichtungspool bezieht sich in diesem Kontext auf eine Abbildung
oder eine Liste von Vorrichtungen, die sich in einem jeweiligen
Betriebsmodus oder Leistungszustand befinden. Zum Beispiel kann
ein Pool verwaltet werden, um die Vorrichtungen zu verwalten, die
sich in dem aktiven Modus befinden, und wobei ein weiterer Pool
zur Verwaltung der Vorrichtungen eingesetzt wird, die sich in dem
inaktiven Modus befinden. Bei einem derartigen Power Management
bzw. Leistungsmanagement wird angenommen, dass die Vorrichtungen,
die in einem der Pools dargestellt sind, in einem bestimmten Betriebsmodus
oder Leistungszustand arbeiten und somit eine bestimmte Leistungsmenge
verbrauchen. Zum Beispiel wird angenommen, dass Vorrichtungen, die
in dem aktiven Pool dargestellt sind, in dem aktiven Modus arbeiten.
Die Anzahl der Vorrichtungen bzw. Bausteine in jedem Pool kann überprüft werden,
um zu bestimmen, welche Leistungsmenge von dem ganzen Speichersystem
verwendet wird. Die verschiedenen Pools zur Verfolgung bzw. Verwaltung
des Betriebsmodus oder des Leistungszustands der verschiedenen Speicherbausteine
werden nachstehend auch als Leistungsregelungspools oder Leistungseinsparungspools
bezeichnet.
-
Für gewöhnlich wird
die Anzahl der Vorrichtungen bzw. Bausteine in jedem Pool (nachstehend
auch als Größe des Pools
oder Poolgröße bezeichnet)
beim Einschalten bzw. Hochfahren oder Zurücksetzen durch das BIOS konfiguriert
oder spezifiziert und bleibt während
dem Systembetrieb unverändert,
aufgrund der Komplexität
der Berücksichtigung
der Leistungsverbrauchszustände
aller Vorrichtungen während
einem vorgesehenen Übergang.
Zum Beispiel kann ein Systembetreiber oder ein Systemanwender über das
BIOS-Setup spezifizieren, dass die Anzahl der aktiven Bausteine
gleich 8 und die Anzahl der inaktiven Bausteine gleich 24 ist. Diese
beiden Zahlen werden zur Bestimmung der maximal zulässigen Anzahl
von Vorrichtungen bestimmt, die entsprechend aktiv bzw. inaktiv
sein können.
Eine derartige statische und unflexible Pool-Konfiguration ist in Bezug auf die Balancierung
der Systemleistungsvoraussetzungen mit den Voraussetzungen für die Systemleistung
und die Wärmeabstrahlung
nicht effektiv und effizient, da während dem Systembetrieb bestimmte
Ereignisse und Betriebsbedingungen auftreten können, welche eine Anpassung
der Pool-Konfiguration erforderlich machen könnten, so dass das System weiter
ordnungsgemäß, sicher
und effizient arbeitet. In verschiedenen Situationen kann es zum
Beispiel nützlich
sein, in der Lage zu sein, die Pool-Konfiguration während den Systemoperationen
als Reaktion auf verschiedene Reize von außen oder Veränderungen
der Betriebsbedingungen zu verändern
(z.B. die Größe des aktiven
Pools und es inaktiven Pools zu verändern, etc.), da die Größen der
Pools dazu verwendet werden, ein zweckmäßiges Gleichgewicht zwischen
der Systemleistung und dem Systemleistungsverbrauch (und der Wärmeerzeugung)
aufrechtzuerhalten. Zum Beispiel kann es sein, dass die Größen der
Pools verändert
werden müssen
als Reaktion auf einen Temperaturzustand, der die für das System
zulässigen
thermischen Toleranzen überschreitet
oder als Reaktion auf eine Indikation, dass das System aufgrund
eines Stromausfalls oder eines ähnlichen
Fehlers über
eine batteriebetriebene Quelle versorgt wird. Darüber hinaus
kann es sein, dass die Größen der
Pools aufgrund von Veränderungen
der Systembetriebseigenschaften verändert werden müssen, wie
etwa Veränderungen
der Anzahl der Systembenutzer, wobei dies allgemein die Nutzungs-
und somit Leistungsverbrauchswerte des Speichersystems beeinflusst.
-
Folglich
ist eine dynamische Umkonfiguration oder Veränderung der Größen der
Leistungsregelungspools von Speicherbausteinen im Verlauf des Systembetriebs
erforderlich.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Vorgesehen
ist gemäß einem
ersten Aspekt der vorliegenden Erfindung ein Verfahren gemäß dem gegenständlichen
Anspruch 1.
-
Vorgesehen
ist gemäß einem
zweiten Aspekt der vorliegenden Erfindung eine Vorrichtung gemäß dem gegenständlichen
Anspruch 18.
-
Bevorzugte
Merkmale der vorliegenden Erfindung sind durch die Unteransprüche definiert.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Merkmale und Vorteile der vorliegenden Erfindung werden in Bezug
auf die beigefügten
Zeichnungen umfassender verständlich.
In den Zeichnungen zeigen:
-
1 ein
Blockdiagramm eines Ausführungsbeispiels
eines Systems, das die Lehren der vorliegenden Erfindung implementiert;
-
2 ein
Blockdiagramm einer Speichersteuereinheit mit einem Speicherleistungsverbrauch-Regelungsmechanismus;
-
3 ein
Blockdiagramm eines Ausführungsbeispiels
einer Speichersteuereinheit, die einen Pool-Manager aufweist;
-
die 4A bis 4C ein
Beispiel für
ein Ausführungsbeispiel
eines Verfahrens zur Verwaltung verschiedener Leistungsregelungspools,
die verwendet werden, um die Betriebszustände von Speicherbausteinen
zu überwachen
und zu regeln;
-
die 5A bis 5C ein
Beispiel für
ein Ausführungsbeispiel
eines Verfahrens zur Verwaltung von Leistungsregelungspools, die
verwendet werden, um die Betriebszustände von Speicherbausteinen
zu überwachen
und zu regeln;
-
6 ein
Zustandsdiagramm eines Ausführungsbeispiels
eines Verfahrens zur Ausführung
normaler Speicherauffrischoperationen;
-
7 ein
Zustandsdiagramm eines Ausführungsbeispiels
eines Verfahrens zur Ausführung
von Auffrischoperationen als Reaktion auf eine Anforderung für eine neue
Größenfestlegung
der Leistungsregelungspools;
-
die 8A bis 8B ein
Beispiele für
eine Umkonfiguration der Leistungsregelungspools als Reaktion auf
eine Anforderung zur neuen Größenfestlegung
der Speicher-Leistungsregelungspools;
-
9 ein
Blockdiagramm eines Ausführungsbeispiels
einer Vorrichtung zum dynamischen Anpassen der Größe von Speicher-Leistungsregelungspools;
-
10 ein
Blockdiagramm eines Ausführungsbeispiels
einer Vorrichtung zum dynamischen Anpassen der Größe von Speicher-Leistungsregelungspools;
-
11 ein
Blockdiagramm eines Ausführungsbeispiels
einer Vorrichtung zum dynamischen Anpassen der Größe von Speicher-Leistungsregelungspools;
-
12 ein
Flussdiagramm eines Ausführungsbeispiels
eines Verfahrens zum dynamischen Anpassen der Größe von Speicher-Leistungsregelungspools
als Reaktion auf eine Anforderung von einem Prozessor;
-
13 ein
Flussdiagramm eines Ausführungsbeispiels
eines Verfahrens zum dynamischen Anpassen der Größe von Speicher-Leistungsregelungspools
als Reaktion auf durch Hardware detektierte Systemereignisse; und
-
14 ein
Flussdiagramm eines Ausführungsbeispiels
eines Verfahrens zum dynamischen Anpassen der Größe von Speicher-Leistungsregelungspools
als Reaktion auf eine Anforderung eines Prozessors oder durch Hardware
detektierte Systemereignisse.
-
GENAUE BESCHREIBUNG
-
In
der folgenden genauen Beschreibung sind zahlreiche spezifische Einzelheiten
ausgeführt,
um ein umfassendes Verständnis
der vorliegenden Erfindung zu vermitteln. Für den Fachmann auf dem Gebiet
ist es jedoch offensichtlich, dass die vorliegende Erfindung ohne
diese spezifischen Einzelheiten verstanden und ausgeführt werden
kann.
-
In
der nachstehenden Beschreibung werden die Lehren der vorliegenden
Erfindung zur Implementierung eines Verfahrens und einer Vorrichtung
eingesetzt, um dynamisch die Größen der
Speicher-Leistungsregelungspools zu verändern bzw. anzupassen, die
verwendet werden, um die Betriebszustände verschiedener Speicherbausteine
zu überwachen
und zu regeln. In einem Ausführungsbeispiel
wird der Auffrischprozess, der normalerweise eingesetzt wird, um
die verschiedenen Speicherbausteine aufzufrischen, so modifiziert,
dass bewirkt wird, dass verschiedene Speicherbausteine in einen
speziellen Betriebszustand eintreten, wie z.B. den Schlafzustand,
und zwar nach einer Auffrischung als Reaktion auf eine Anforderung
zur Anpassung der Größen der
Speicher-Leistungsregelungspools. Nachdem verschiedene Speicherbausteine
in den speziellen Betriebszustand (z.B. den Schlafzustand) eingetreten
sind, können
die Größen der
Speicher-Leistungsregelungspools auf neue Werte gemäß der Anforderung
angepasst werden. In einem Ausführungsbeispiel
kann die Anforderung zum Anpassen der Größen der Speicher-Leistungsregelungspools
durch einen Prozessor oder andere Einheiten eingeleitet werden,
die eine Veränderung
der Größen der
Speicher-Leistungsregelungspools benötigen. In einem Ausführungsbeispiel
kann die Anforderung für
die Anpassung der Größen der
Speicher-Leistungsregelungspools
auch ohne Intervention der Systemsoftware eingeleitet werden als
Reaktion auf das Detektieren eines spezifischen Systemereignisses,
wie zum Beispiel, wenn ein Signal von einer thermischen Regelungseinheit
des Systems oder einer thermischen Regelungseinheit des Computers
anzeigt, dass die Temperatur einen Grenzwert überschritten hat.
-
Die
Abbildung aus 1 zeigt ein Blockdiagramm eines
Ausführungsbeispiels
einer Systemkonfiguration, wobei die Lehren der vorliegenden Erfindung
implementiert werden. Die Systemkonfiguration 100 weist eine
Mehrzahl von Zentraleinheiten (CPUs) 101a–d, einen
Speicher-Steuer-Hub (auch als Speichersteuereinheit bezeichnet) 111,
eine P64-Steuereinheit 121, eine Ein-Ausgabe-Steuereinheit
(E/A-Steuereinheit) 131, eine
Grafiksteuereinheit 141, die mit einem Grafikteilsystem 151 verbunden
ist, und eine Mehrzahl von Speicherbausteinen 161 auf.
Für die
Zwecke der vorliegenden Patentschrift betrifft der Begriff „Prozessor" oder „CPU" jede Maschine bzw.
Vorrichtung, die eine Befehlsfolge ausführen kann, und wobei die Bedeutung
unter anderem und ohne einzuschränken
universelle Mikroprozessoren, spezielle Mikroprozessoren, Multimedia-Steuereinheiten
und Mikrocontroller, etc. einschließt. In einem Ausführungsbeispiel
handelt es sich bei den CPUs 101a–101d um universelle
Mikroprozessoren, die einen Befehlsvorrat der Inte1 Architektur
ausführen können. Die
CPUs 101a–101d,
die P64-Steuereinheit 121, die E/A-Steuereinheit 131 und
die AGP-Grafiksteuereinheit 141 greifen über die
Speichersteuereinheit 111 auf die Systemspeicherbausteine 161 zu.
Die Speichersteuereinheit 111 ist in einem Ausführungsbeispiel
zuständig
für die
Behandlung aller Speichertransaktionen, die die Systemspeicherbausteine 161 zum
Ziel haben. Die Speichersteuereinheit 111 kann eine Standalone-Einheit,
ein integraler Bestandteil eines Chipsatzes oder Teil einer größeren Einheit
sein, welche die Schnittstellen zwischen verschiedenen Systemkomponenten
und Systemspeicherbausteinen 161 steuern. Die P64-Steuereinheit 121 sorgt
für die
Schnittstellensteuerung zwischen einer Mehrzahl von PCI-64-Slots 125 und
der Speichersteuereinheit 111. Die E/A-Steuereinheit 131 sorgt für die Schnittstellensteuerung
zwischen der Speichereinheit 111 und verschiedenen E/A-Vorrichtungen und
Ports mit PCI-Slots und PCI-Agenten 133, einer Mehrzahl
von USB-Ports 135, einer Mehrzahl von IDE-Ports 137 und
anderen E/A-Vorrichtungen 139. Die AGP-Grafiksteuereinheit 141 sorgt
für die
Schnittstellensteuerung zwischen dem Grafikteilsystem 151 und der Speichersteuereinheit 111.
Die Struktur und die Funktionen der Speichersteuereinheit 111 sind
nachstehend im Text näher
beschrieben.
-
Für die Zwecke
der vorliegenden Patentschrift wird angenommen, dass es sich bei
den Speicherbausteinen 161 um DRAM-Bausteine (dynamische
Direktzugriffsspeicher) handelt. Es ist allgemein bekannt, dass DRAM
eine Art von RAM ist, welche flüchtige
Speicherzellen verwendet, die periodisch aufgefrischt werden, um
Daten zu speichern. Die Auffrischrate oder die Auffrischfrequenz
variiert abhängig
von dem verwendeten Typ von DRAM, der installierten Speichergröße, der
Konfiguration des Systemspeichers, etc. In der folgenden Beschreibung
wird davon ausgegangen; dass es sich bei den Speicherbausteinen
um RAMBUS® DRAMs (auch
als RDRAMs bezeichnet) handelt, die von der Rambus Incl, Mountain
View, Kalifornien, USA, entwickelt worden sind. Die vollständige folgende
Beschreibung gilt jedoch gleichermaßen für andersartige DRAMs, dazu zählen herkömmliche
DRAMs, Fast Page Mode (FPM) DRAMs, Extended Data Out (EDO) DRAMs,
Burst Extended Data Out (BEDO) DRAMs, synchrone DRAMs (SDRAMs),
SDRAMs mit doppelter Datenrate (DDR SDRAMs), synchronous-link DRAMs
(SLDRAMs), etc.
-
Die
Abbildung aus 2 zeigt ein Blockdiagramm eines
Ausführungsbeispiels
der in Bezug auf die Abbildung aus 1 beschriebenen
Speichersteuereinheit 111. In dem vorliegenden Ausführungsbeispiel weist
die Speichersteuereinheit 111 drei Hauptblöcke auf:
die Host-Gruppe (HG) 211, die E/A-Gruppe (IOG) 221 und
die Datengruppe (DG) 231. In einem Ausführungsbeispiel fungiert die
Host-Gruppe 211 als eine Host-Schnittstelle für die Speichersteuereinheit 111.
Zu einigen der durch die Host-Gruppe 211 ausgeführten Funktionen
zählen
der Empfang von Transaktionsanforderungen von den CPUs 101a–101d,
das Erzeugen entsprechender Befehle an die E/A-Gruppe 221 und die Datengruppe 231,
das Empfangen von Antworten von der E/A-Gruppe 221 und
der Datengruppe 231 und das Übermitteln der empfangenen
Antworten an den Host (CPUs 101a–101d). Darüber hinaus
ist die Host-Gruppe 211 auch verantwortlich für die Erzeugung
von Snoop-Anforderungen an die Datengruppe 231, den Empfang
von Snoop-Antworten von der Datengruppe 231 und das Übermitteln
von Snoop-Antworten zu dem Host. Die E/A-Gruppe 221 fungiert
in einem Ausführungsbeispiel
als eine E/A-Schnittstelle für
die Speichersteuereinheit 111. Im Besonderen erfüllt die
E/A-Gruppe 221 die Schnittstellenfunktionen zwischen der
Datengruppe 231 und der P64-Steuereinheit 121,
der E/A-Steuereinheit 131 und der Grafiksteuereinheit 141.
In einem Ausführungsbeispiel
ist die Datengruppe (die auch als Daten-Custer bezeichnet wird) 231 für die Verteilung
und vollständige
Ausführung
aller Speichertransaktionen zuständig,
welche die System-RDRAMs zum Ziel haben. In einem Ausführungsbeispiel
weist die Datengruppe 231 zwei logische Teilkomponenten
auf: eine Dateneinheit (Dunit), welche die komplexe Mechanik des Übermittelns
von Transaktionen an die RDRAM-Bausteine über die RAMBUS-Kanalsteuereinheit
(RAC) ausführt, und
die Puffereinheit (Bunit), die für
die Ablaufsteuerung, das Puffern und das Zustellen der Daten zuständig ist,
die über
den Speicherbus (auch als RAM-Bus bezeichnet) aus den RDRAM-Bausteinen
gezogen oder zu diesen geschoben werden. Die Dunit akzeptiert Speicherlese-,
Speicherschreib- und Speicherauffrischanforderungen von der Bunit.
Diese Anforderungen werden decodiert, um den Status bzw. Zustand
der Speicherseiten zu bestimmen, an welche sie gerichtet sind. Die
Dunit erzeugt danach die entsprechenden Befehle oder Anweisungen
(auch als die Pakete bezeichnet), die erforderlich sind, um die
Speicherzugriffsanforderungen auszuführen, und wobei die Pakete
für eine Übertragung über den
Speicherbus in Warteschlangen platziert werden. Darüber hinaus
synchronisiert die Dunit auch Datenübertragungen, welche eine Taktbegrenzung
zwischen der Kernfrequenz und der Grundfrequenz des Speicherbusses überschreiten.
Die Bunit empfängt
in einem Ausführungsbeispiel
Anforderungen für
Speicherdaten von der Host-Gruppe 211 und der E/A-Gruppe 221 und
erzeugt die entsprechenden Speicherzugriffsanforderungen an die
Dunit, wie dies vorstehend im Text beschrieben worden ist.
-
Die
Abbildung aus 3 zeigt ein Blockdiagramm eines
Ausführungsbeispiels
der Speichersteuereinheit 111, mit einer Auffrischeinheit 311,
einem Paketgenerator 321 und einem Pool-Manager 331. Die Funktionen
dieser Einheiten und die Interaktionen zwischen ihnen sind nachstehend
im Text näher
beschrieben. Wie dies bereits vorstehend im Text beschrieben worden
ist, ist die Speichersteuereinheit (MCU) 111 zuständig für die Behandlung
von Speichertransaktionen, die von verschiedenen Quellen zeitgerecht
empfangen werden. Die von verschiedenen Quellen in dem System 100 empfangenen
Speichertransaktionen umfassen Lese- und Schreibanforderungen in
Bezug auf Speicherdaten. In einem Ausführungsbeispiel setzt die MCU 111 die
von verschiedenen Quellen empfangenen Lese- und Schreibanforderungen in Befehle
um, welche die RDRAM-Bausteine
verstehen, die über
den Speicherbus mit der MCU 111 gekoppelt sind. Die von
den RDRAM-Bausteinen verstandenen Befehle (d.h. die nativen RDRAM-Anforderungen)
werden hierin auch als RDRAM-Anforderungspakete oder einfach nur
Pakete bezeichnet. Die in der Abbildung aus 3 dargestellte Paketgeneratoreinheit 321 ist
die Einheit in der MCU 111, die für die Erzeugung und das Übermitteln
von Paketen zu den RDRAM-Bausteinen zuständig ist.
-
In
einem Ausführungsbeispiel
ist die MCU 311 auch für
die RDRAM-Verwaltungsoperationen wie etwa das Auffrischen und die
Kalibrierung zuständig.
Wie dies vorstehend im Text beschrieben worden ist, verwenden RDRAMs,
wie jede andere DRAM-Technologie, flüchtige Speicherzellen, die
periodisch aufgefrischt werden müssen,
um Daten zu speichern. Die MCU 311 führt diese Verwaltungs- bzw.
Wartungsoperationen in regelmäßigen Intervallen
aus, indem Pakete an die RDRAMs übermittelt
werden, um deren Daten aufzufrischen oder um deren elektrische Eigenschaften
zu kalibrieren. In einem Ausführungsbeispiel
verwendet die MCU 111 die Auffrischeinheit 311 aus 3 zur
Ausführung
der RDRAM-Wartungsoperationen. In einem Ausführungsbeispiel verwaltet die
Auffrischeinheit 311 einen Zähler, der dazu eingesetzt wird,
die Zeitintervalle zwischen Auffrisch- und Kalibrierungszyklen zu überwachen.
Wenn die Auffrischeinheit 311 bestimmt hat, dass ein Wartungszyklus
an den RDRAMs ausgeführt
werden muss, so richtet sie eine Anforderung an den Paketgenerator 321,
der wiederum die entsprechenden RDRAM-Anforderungspakete erzeugt,
die bewirken, dass die RDRAM-Bausteine die erforderlichen Verwaltungs-
bzw. Wartungsfunktionen (z.B. Auffrischen oder Kalibrieren) ausführen.
-
Der
Pool-Manager 331 ist für
die Verwaltung der Leistungsverbrauchsebenen (hierin auch als Betriebsmodi
oder Leistungszustände
bezeichnet) der RDRAM-Vorrichtungen zuständig. Um das Gleichgewicht zwischen
der Systemleistung und der Systemleistungsnutzung zu erhalten, sind
die Speicherbausteine so gestaltet, dass sie unterschiedliche Betriebsmodi
aufweisen, die verschiedenen Leistungsebenen bzw. Leistungswerten
(d.h. Geschwindigkeiten) entsprechen, wie dies bereits vorstehend
im Text beschrieben worden ist. In dem vorliegenden Ausführungsbeispiel
sind die RDRAMs so gestaltet, dass sie verschiedene Betriebsmodi
aufweisen: aktiv, Bereitschaft bzw. Standby, Ruhe bzw. Schlafen
und ausgeschaltet. Diese vier unterschiedlichen Betriebsmodi der
RDRAMs unterscheiden sich durch zwei Faktoren: ihre Leistungsverbrauchswerte
und ihre Leistungs- bzw. Performance-Werte. Zum Beispiel ist ein RDRAM im
aktiven Modus bereit, eine Transaktion direkt zu bedienen. Der Leistungsverbrauch
ist in dem aktiven Modus jedoch höher als in den anderen Modi.
Die vier verschiedenen Leistungsverbrauchsebenen und Leistungsebenen
der RDRAMs, welche den vier verschiedenen Betriebsmodi entsprechen,
sind in der nachstehenden Tabelle 1 abgebildet, wobei 4 in der Leistungsverbrauchsspalte
der höchsten
Ebene des Leitungsverbrauchs durch den RDRAM entspricht, und 1 in
der Leistungswertspalte entspricht der höchsten Leistungsebene.
-
-
Wie
dies in Tabelle 1 veranschaulicht ist, arbeiten die RDRAMs im aktiven
Modus schneller als in allen anderen drei Modi. Die RDRAMs verbrauchen
jedoch in dem aktiven Modus deutlich mehr Leistung als in den anderen
drei Modi. Der Leistungsverbrauch und auch die Wärmeerzeugung der Speicherbausteine
(z.B. in der vorliegenden Beschreibung der RDRAMs) können reduziert
werden, indem eines oder mehrere der RDRAMs in einem niedrigeren
Leistungsmodus (z.B. Standby-, Ruhe- oder ausgeschalteter Modus)
platziert werden. Wie dies bereits vorstehend im Text beschrieben
worden ist, sind das Power Management und das thermische Management
in modernen und häufig
komplexen Computersystemen bezüglich
der Entwicklung und Implementierung von Systemen immer bedeutender
geworden. Um ein akzeptables Gleichgewicht zwischen der Systemleistung
und dem Systemleistungsverbrauch (der auch der Wärmeabstrahlung entspricht)
zu erreichen, werden Systeme häufig
so konfiguriert, dass nur eine feste Anzahl von Speicherbausteinen
(z.B. RDRAMs) in dem aktiven Modus arbeiten kann. Abhängig von
den Anwendungen und den Betriebsumgebungen des Systems variiert
die Anzahl der Speicherbausteine, die in dem aktiven Modus gehalten
wird, wie dies bereits vorstehend im Text beschrieben worden ist.
Bei einer Systemkonfiguration unter Verwendung von 12 RDRAM Speicherbausteinen
können
bestimmte Systemeinschränkungen
zum Beispiel vorgeben, dass nur maximal 4 RDRAM Bausteine zu einem
bestimmten Zeitpunkt aktiv sein dürfen. Wie dies bereits vorstehend
im Text beschrieben worden ist, kann die maximale Anzahl der Bausteine
bzw. Vorrichtungen in dem aktiven Modus, in dem Standby-Modus oder
in dem Ruhemodus, etc. durch den Systembenutzer über das System-BIOS beim Hochfahren
oder Zurücksetzen
des Systems spezifiziert werden. Die Verwaltung, welche Bausteine
sich in welchem Betriebsmodus befinden (z.B. aktiv, Standby, Ruhe,
etc.), kann unter Verwendung einer Definition der Pools der Bausteine
(auch bezeichnet als Leistungsregelungspools) erreicht werden, die
verwendet werden, um den Betriebsmodus oder Leistungszustand der
einzelnen Speicherbausteine zu überwachen
und zu regeln. Ein Pool bezieht sich in der vorliegenden Beschreibung
auf eine Abbildung oder eine Liste von Speicherbausteinen, die sich
in einem bestimmten Betriebsmodus oder Leistungszustand befinden.
-
Wie
dies bereits vorstehend im Text beschrieben worden ist, können die
RDRAMs eine erhebliche Leistungsmenge verbrauchen und Wärme in erheblichem
Ausmaß erzeugen,
wenn sie im aktiven Modus betrieben werden. Folglich wäre es vorteilhaft,
so viele RDRAMs wie praktisch möglich,
in einem niedrigen Leistungszustand zu betreiben. In einem Ausführungsbeispiel
erreicht die MCU 111 dies durch Drosselung, indem eine
Reihe von Speicherbausteinen (z.B. die RDRAMs) in den Ruhe- oder
Schlafmodus versetzt werden, in dem die Speicherbausteine deutlich
weniger Leistung verbrauchen und somit deutlich weniger Wärme erzeugen
als wie dies im aktiven Modus oder im Standby-Modus der Fall ist.
Die RDRAMs können
in dem Ruhemodus ihre Daten halten, wobei sie jedoch nicht in der
Lage sind, ihre Daten an die MCU 111 bereitzustellen, bis sie
in den aktiven oder den Standby-Modus gewechselt sind. Wie dies
vorstehend im Text beschrieben worden ist, sollte um ein Gleichgewicht
zwischen der Systemleistung und dem Leistungsverbrauch zu erhalten,
eine bestimmte feste Anzahl von Speicherbausteinen zu einem beliebigen
bestimmten Zeitpunkt in den Ruhemodus versetzt werde, Folglich muss
nur eine bestimmte feste Anzahl von Speicherbausteinen zu einem
bestimmten Zeitpunkt in dem aktiven Modus oder dem Standby-Modus gehalten werden.
Computerprogramme kennen den Betriebsmodus oder den Leistungszustand
eines bestimmten Speicherbausteins nicht. Somit muss der Betriebsmodus
eines bestimmten Speicherbausteins durch die MCU verändert werden,
bevor der jeweilige Speicherbaustein eine Speichertransaktion behandeln
kann.
-
In
erneutem Bezug auf die Abbildung aus 3 ist der
Pool-Manager 331 in
der MCU 111 die zuständige
Einheit für
die Erhaltung des Gleichgewichts zwischen dem Leistungsverbrauch
der RDRAM Bausteine und deren entsprechenden Leistungswerten. Im
Besonderen überwacht
der Pool-Manager 331 den Betriebsmodus jedes einzelnen
Speicherbausteins und unternimmt entsprechende Maßnahmen,
um die Speicherbausteine auf der Basis von verschiedenen Faktoren
aus einem Betriebsmodus in einen anderen zu versetzen, wie zum Beispiel
der maximalen Anzahl von Vorrichtungen bzw. Bausteinen, die in jedem
Betriebsmodus zulässig
sind, welcher Baustein für
die Behandlung einer bestimmten Speichertransaktion erforderlich
ist, etc. Um in einem Ausführungsbeispiel
den Betriebsmodus eines bestimmten Speicherbausteins zu verändern, fordert
der Pool-Manager 331 den Paketgenerator auf, die entsprechenden
Pakete (d.h. Befehle) an den Speicherbaustein zu senden, welche
den Speicherbaustein anweisen, die erforderliche Funktion auszuführen (z.B.
Wechsel aus dem aktiven in den Standby-Modus oder ein Wechsel aus
dem Standby- in den Ruhemodus, etc.).
-
Wie
dies vorstehend im Text beschrieben worden ist, verwaltet der Pool-Manager 331 in
einem Ausführungsbeispiel
Informationen in Bezug auf den Betriebsmodus jeder der einzelnen
Bausteine bzw. Vorrichtungen (d.h. welche Vorrichtungen sich in
dem aktiven, dem Standby- oder dem Ruhemodus befinden), und zwar
unter Verwendung einer Mehrzahl von Pools, wobei jeder Pool eine
Abbildung oder Liste von Vorrichtungen bzw. Bausteinen betrifft,
die sich in einem spezifischen Betriebsmodus oder Leistungszustand
befinden). In einem Ausführungsbeispiel
verwendet der Pool-Manager 331 drei Pools, um die Betriebsmodi
der Speichervorrichtungen zu überwachen.
Eine der Pools, der als der aktive Pool oder Pool A bezeichnet wird,
wird dazu verwendet, zu überwachen,
welche Vorrichtungen in dem aktiven Modus arbeiten. Der andere Pool,
der als Standby-Pool oder Pool B bezeichnet wird, überwacht,
welche der Vorrichtungen in dem Standby-Modus betrieben wird. Der
letzte Pool, der als Ruhe-Pool oder Pool C bezeichnet wird, wird
zur Überwachung
verwendet, welche der Vorrichtungen in dem Ruhemodus betrieben wird.
Jeder der drei Pools enthält
somit Verweise auf die Vorrichtungen bzw. Bausteine, die sich in
einem bestimmten Betriebsmodus oder Leistungszustand befinden. In
einem Ausführungsbeispiel
werden die Informationen in dem aktiven Pool und dem Standby-Pool
in einer Reihe von Registern gespeichert, während der Ruhe-Pool durch eine
Subtraktions-Teilmenge der Speicherbausteine dargestellt wird, die
sich nicht in dem aktiven Pool oder dem Standby-Pool befinden.
-
In
einem Ausführungsbeispiel
kann die MCU 111 zwei Betriebsmodi in Bezug auf die Betriebsmoduskonfiguration
der RDRAM-Bausteine aufweisen. In dem ersten Modus wird angenommen,
dass sich alle Bausteine bzw. Vorrichtungen entweder in dem aktiven
oder dem Standby-Modus befinden. Bei dieser Konfiguration sind alle
aktiven Vorrichtungen durch Token in Pool A (dem aktiven Pool) dargestellt,
wobei der Pool B unbenutzt ist, und wobei Pool C subtraktiv alle
Vorrichtungen aufweist, die nicht in Pool A dargestellt sind. Folglich
wird davon ausgegangen, dass sich alle in Pool C dargestellten Vorrichtungen
in dem Standby-Modus befinden. In dem zweiten Betriebsmodus können sich
die Speichervorrichtungen bzw. Speicherbausteine in dem aktiven
Modus, dem Standby-Modus oder dem Ruhemodus befinden. Alle drei
Pools A, B und C werden in dieser Konfiguration eingesetzt. Pool
A stellt alle aktiven Bausteine dar, Pool B stellt Bausteine dar,
die sich in dem Standby-Modus befinden, und Pool C wird subtraktiv
zur Darstellung aller Bausteine verwendet, die sich weder in Pool
A noch in Pool B befinden und für
die somit angenommen wird, dass sie sich in dem Ruhemodus befinden.
-
In
einem Ausführungsbeispiel
setzt der Pool-Manager 331 einen echten Least-Recently-Used-Algorithmus
(LRU-Algorithmus) ein, um die Liste der in den Pools A und B dargestellten
Bausteine zu verwalten. Die Abbildungen der 4A–4C veranschaulichen
ein Beispiel der Konfiguration und Wartung der drei Pools A, B und
C, wenn die MCU 111 in dem zweiten Betriebsmodus betrieben
wird (d.h. die Speicherbausteine können sich in dem aktiven Modus,
dem Standby-Modus oder dem Ruhemodus befinden). In diesem Beispiel
wird angenommen, dass sowohl Pool A als auch Pool B auf die Größen von
4 festgelegt sind, und wobei sie somit jeweils bis zu vier Speicherbausteine
darstellen können.
Ferner wird in diesem Beispiel angenommen, dass in dem System 12 Speicherbausteine
vorhanden sind, bezeichnet von A bis L.
-
Die
Abbildung aus 4A zeigt eine Konfiguration
der drei Pools A, B und C an einem bestimmten Punkt im Verlauf des
Systembetriebs. Auf dieser Stufe, wie dies in der Abbildung aus 4A abgebildet
ist, sind die Bausteine A–D
in dem Pool dargestellt, und wobei somit angenommen wird, dass sie
sich in dem aktiven Modus befinden. Die Bausteine E–H sind
in dem Pool B dargestellt, und wobei angenommen wird, dass sie in
dem Standby-Modus betrieben werden. Die Bausteine I–L sind
in dem Pool C dargestellt, und wobei dabei angenommen wird, dass
sie sich in dem Ruhemodus befinden. In dem vorliegenden Beispiel
gilt die in der Liste oben aufgeführte Vorrichtung bzw. Baustein
(z.B. der Baustein A aus 4A) als
der zuletzt verwendete Baustein, während der unten auf der Liste
stehende Baustein (z.B. Baustein D aus 4A) als
der am weitesten zurückliegend
verwendete Baustein gilt. Unter Verwendung der Pool-Darstellung
aus 4A würden
die drei Pools A, B und C nach dem Lesen aus oder Schreiben an eine
Stelle in dem Baustein D in die in der Abbildung aus 4B dargestellte
Darstellung transformiert werden. Das Token „D", das den Baustein D darstellt, würde sich
an die zuletzt verwendete Position (das obere Ende der Liste) in
Pool A bewegen, während die
Pools B und C unbeeinflusst bleiben, da die Änderung in Bezug auf den Baustein
D die Anzahl der in jedem Pool zulässigen Bausteine nicht beeinflusst
hat. Wenn angenommen wird, dass als nächstes auf den Baustein I zugegriffen
wird, so würden
die drei Pools A, B und C in die Pools gemäß der Abbildung aus 4C transformiert
werden. In diesem Fall wurde der Baustein I an die zuletzt verwendete
Position in Pool A bewegt. Da der Baustein I aus dem Ruhemodus in
den aktiven Modus bewegt worden ist, wurde der Baustein C, der den am
weitesten zurückliegenden
verwendeten Baustein in dem Pool A darstellt, an die zuletzt verwendete
Position in dem Pool B bewegt worden ist, um die maximal zulässige Anzahl
aktiver Bausteine in dem Pool A zu erhalten. Da der Baustein C in ähnlicher
Weise aus dem aktiven Modus in den Standby-Modus geändert worden
ist, wurde der am weitesten zurückliegend
verwendete Baustein aus Pool B (d.h. Baustein H) aus dem Pool B
gestoßen
und subtraktiv in Pool C bewegt, um die maximal zulässige Anzahl
von Bausteinen in dem Pool B zu erhalten. Die Abbildung aus 4C zeigt
somit die Pool-Darstellung der drei Pools A, B und C nachdem die
entsprechenden Bausteine in ihre entsprechenden Betriebsmodi gewechselt
sind.
-
Die
Abbildungen der 5A–5C veranschaulichen
ein Beispiel der Konfiguration und Wartung der drei Pools A, B und
C, wenn die MCU 11 in dem ersten Modus arbeitet (d.h. es
wird angenommen, dass die Speicherbausteine entweder in dem aktiven oder
dem Standby-Modus arbeiten). In dem vorliegenden Beispiel wird angenommen,
dass Pool A eine maximale Größe von vier
aufweist, was bedeutet, dass bis zu vier Vorrichtungen bzw. Bausteine
zu einem beliebigen Zeitpunkt aktiv sein können. Pool B wird nicht verwendet. Ferner
wird in dem vorliegenden Beispiel angenommen, dass in dem System 12 Speicherbausteine
gegeben sind, die von A bis L bezeichnet sind.
-
Die
Abbildung aus 5A zeigt eine Konfiguration
der drei Pools A, B und C an einem bestimmten gegebenen Punkt im
Verlauf des Systembetriebs. Auf dieser Stufe sind die Bausteine
A–D gemäß der Abbildung
aus 5A in dem Pool A dargestellt, und wobei angenommen
wird, dass sie sich in dem aktiven Modus befinden. Die Bausteine
E–L sind
in dem Pool C subtraktiv dargestellt (d.h. da diese Bausteine nicht
in Pool A dargestellt sind, wird angenommen, dass sie sich in dem
Standby-Modus befinden). In dem vorliegenden Beispiel gilt wieder
der oben in Pool A aufgeführte
Baustein (z.B. der Baustein A aus 5A) als
der zuletzt verwendete Baustein, während der am unteren Ende von
Pool A aufgeführte
Baustein (z.B. Baustein D aus 5A) als
der am weitesten zurückliegend
verwendete Baustein gilt. Unter Verwendung der Pool-Darstellung aus 5A würden die
drei Pools A, B und C in die in 5B dargestellten
Pools transformiert werden, nachdem ein Lese- oder Schreibvorgang
von oder an eine Stelle in dem Baustein D vorgenommen worden ist.
Das Token „D", das den Baustein
D darstellt, würde
sich an die zuletzt verwendete Position (das obere Ende der Liste)
in Pool A bewegen, während
die Pools B und C unbeeinflusst bleiben, da die Änderung in Bezug auf den Baustein
D die Anzahl der in jedem Pool zulässigen Bausteine nicht beeinflusst
hat. Wenn angenommen wird, dass als nächstes auf den Baustein I zugegriffen
wird, so würden
die drei Pools A, B und C in die Pools gemäß der Abbildung aus 5C transformiert
werden. In diesem Fall wurde der Baustein I an die zuletzt verwendete Position
in Pool A bewegt. Da der Baustein I aus dem Standby-Modus in den
aktiven Modus bewegt worden ist, wurde der Baustein C, der den am
weitesten zurückliegenden
verwendeten Baustein in dem Pool A darstellt, aus Pool A gestoßen und
subtraktiv in Pool C bewegt, um die maximal zulässige Anzahl von Bausteinen in
dem Pool A zu erhalten. Die Abbildung aus 5C zeigt
somit die Pool-Darstellung der drei Pools A, B und C nachdem die
entsprechenden Bausteine in ihre entsprechenden Betriebsmodi gewechselt
sind.
-
Wie
dies bereits vorstehend im Text beschrieben worden ist, ist es erforderlich,
um das Gleichgewicht zwischen der Systemleistung, dem Leistungsverbrauch
und der thermischen Sicherheit aufrechtzuerhalten, eine bestimmte
Anzahl von Speicherbausteinen in dem aktiven Modus zu halten und
den Rest der Bausteine in niedrigeren Leistungszuständen (z.B.
Standby- oder Ruhemodus).
Da im Besonderen die Anzahl der in jedem der Leistungszustände betriebenen
Speicherbausteine die Leistungs-, den Leistungsverbrauchs- und die Wärmeerzeugungswerte
des Systems beeinflusst, ist es nützlich, die Größen der
aktiven, Standby- und Ruhe-Pools innerhalb bestimmter anfänglicher
Schwellenwertgrenzen zu halten, um ein gewisses Gleichgewicht zwischen
der Systemleistung, dem Leistungsverbrauch und der Wärmeerzeugung
zu erhalten. Auf herkömmliche
Weise wird die maximal zulässige
Anzahl von Bausteinen bzw. Vorrichtungen in jedem Pool unter Verwendung
des System-BIOS beim Einschalten bzw. Hochfahren oder Zurücksetzen
bzw. Reset konfiguriert oder spezifiziert und unverändert gelassen über den
Verlauf der Systemoperationen. Eine derartige statische und unflexible
Pool-Konfiguration stellt zwei ein anfängliches Systemgleichgewicht
zwischen der Leistung und dem Leistungsverbrauch bereit, ist jedoch
nicht effektiv und effizient in Bezug auf den Ausgleich der Systemleistungsvoraussetzungen
in Verbindung mit den Anforderungen hinsichtlich der Systemleistung
und der Wärmeabstrahlung.
Grund dafür
ist es, dass verschiedene Ereignisse und Betriebsbedingungen im
Verlauf der Systemoperationen auftreten können, die eine Anpassung der
anfänglichen
Pool-Konfiguration erforderlich machen könnten, damit das System weiter
ordnungsgemäß, sicher
und effizient arbeitet. Anders ausgedrückt berücksichtigt das herkömmliche
Verfahren der Pool-Konfiguration und Steuerung nicht die dynamische
Beschaffenheit der Operationen des Computersystems und die Zuverlässigkeit,
da Veränderungen
der thermischen Umgebung des Systems oder der Intensität der Nutzung
des Systems eine Anpassung der Betriebsmodi der Speicherbausteine
voraussetzen können,
die durch den Pool-Manager 331 geregelt werden. In verschiedenen
Situationen wäre
es nützlich,
die Größen der
Pools während
Systemoperationen verändern
zu können
als Reaktion auf verschiedene externe Reize oder Veränderungen
der Betriebsbedingungen, da die Größen der Pools verwendet werden,
um ein zweckmäßiges Gleichgewicht
zwischen der Systemleistung, dem Systemleistungsverbrauch und der
Wärmeerzeugung
zu erhalten. Zum Beispiel kann eine Systemüberhitzung als ein Auslöser verwendet
werden, um die aktiven Speicherbausteine in einen Ruhemodus zu versetzen,
um die Wärmeerzeugungskapazität der Speicherbausteine
zu reduzieren. Darüber
hinaus kann es sein, dass die Größen der
Pools verändert
werden müssen
als Reaktion auf eine Indikation, dass das System über eine
niedrigere Leistungsquelle (z.B. Batterie) betrieben wird, und zwar
aufgrund eines Stromausfalls oder eines anderen Fehlers. Ferner
kann eine Anpassung der Größen der
Pools erforderlich sein aufgrund von Veränderungen der Betriebsmerkmale
des Systems, wie etwa von Veränderungen
hinsichtlich der Anzahl der Systembenutzer, etc.
-
Wie
dies bereits vorstehend im Text beschrieben worden ist, bleibt die
Pool-Konfiguration für
gewöhnlich
während
den Systemoperationen unverändert,
und zwar aufgrund der substanziellen Komplexität, die bei der Anpassung der
Pool-Größe während dem
Betrieb bzw. während
Operationen erzeugt wird. Grund dafür ist es, dass entsprechende
Anweisungen bzw. Befehle an die RDRAM-Bausteine übermittelt werden müssen, um für diese
einen Wechsel von einem Zustand in den anderen zu bewirken, zusätzlich zu
der Bewegung oder der Aktualisierung von Werten in den Registern,
die dazu verwendet werden, die Betriebsmodi oder Leistungszustände der
Speicherbausteine zu erhalten. Erforderlich wird dies dadurch, dass
die Voraussetzung, dass die Zustände
der Speicherbausteinen mit den in der MCU 111 gegebenen
Zuständen übereinstimmen
sollen. Die vorliegende Erfindung löst dieses Problem durch die
Ausnutzung einer Eigenschaft der durch die Auffrischeinheit 311 ausgeführten Auffrischoperationen,
die es erforderlich macht, dass die Speicherbausteine in regelmäßigen Zeitintervallen
in bekannte Leistungszustände
versetzt werden. Um im Besonderen Auffrischoperationen auszuführen, werden
alle Speicherbausteine aktiviert (d.h. Übergang in den aktiven Modus),
bevor Auffrischungsanforderungspakete zu diesen übertragen werden. Die Auffrischeinheit 311 fordert
normalerweise bei der Ausführung
periodischer Auffrischoperationen an, dass nach dem Abschluss der
Auffrischung die Bausteine durch den Paketgenerator 321 wieder
in ihre Zustände
vor der Aktivierung versetzt werden.
-
Die
Abbildung aus 6 zeigt ein Zustandsdiagramm
eines Ausführungsbeispiels
eines Verfahrens zur Ausführung
normaler Auffrischoperationen, welche Zustände der Speicherbausteine reflektieren,
die sowohl in der Auffrischeinheit 311 als auch dem Paketgenerator 321 existieren.
Die Auffrischeinheit 311 tritt in dem Block 601 in
einen Wartezustand ein. Wenn der Auffrischzähler, der für die Überwachung der Zeitintervalle
zwischen Auffrischungen eingesetzt wird, einen vorbestimmten Zielzählwert erreicht,
leitet die Auffrischeinheit 311 die Auffrischoperationen
ein. In dem Block 611 wird eine Auffrischanforderung eingeleitet,
welche die Auffrischoperationen beginnt. Wie dies bereits vorstehend
im Text beschrieben worden ist, beginnt die Auffrischeinheit mit
den Auffrischoperationen, indem eine Anforderung zum Aufwecken oder
Aktivieren aller Speicherbausteine an den Paketgenerator 321 gesendet
wird, der wiederum die entsprechenden Pakete an die Speicherbausteine
ausgibt. In dem Block 621 wird eine Anforderung zum Aufwecken
aller Speicherbausteine eingeleitet. Als Reaktion auf ein Signal,
das anzeigt, dass alle Bausteine aktiviert worden sind, wird in dem
Block 631 eine Anforderung zum Auffrischen aller Speicherbausteine
eingeleitet. Als Reaktion auf ein Signal, das anzeigt, dass alle
Bausteine aufgefrischt worden sind, wird in dem Block 641 eine
Anforderung eingeleitet, um Bausteine aufzuwecken, die sich vor
der Aktivierung in dem Schlaf- bzw. Ruhemodus befunden haben. Nachdem
die Bausteine wieder in ihre Zustände vor der Aktivierung versetzt
worden sind, tritt die Auffrischeinheit 311 in dem Block 601 wieder
in den Wartezustand ein, um auf den nächsten Auffrischzyklus zu warten.
-
Um
eine dynamische Konfiguration der Leistungsregelungspools zu ermöglichen
(d.h. eine Veränderung
der Größen der
Pools während
dem Systembetrieb), modifiziert die vorliegende Erfindung den vorstehend
beschriebenen Auffrischprozess, so dass alle Bausteine am ende des
Auffrischprozesses in einen bestimmten Modus versetzt werden, wie
zum Beispiel den Ruhemodus, anstatt nur die Bausteine aufzuwecken, die
sich vor der Aktivierung in dem Ruhemodus befunden haben. Dieses
Verfahren ermöglicht
es dem Pool-Manager 331 nach Abschluss einer Auffrischoperation
einfach seine Pools zurückzusetzen,
wenn eine derartige Pool-Konfiguration im Verlauf des Systembetriebs
wünschenswert
ist. In einem Ausführungsbeispiel wird
der modifizierte Auffrischprozess durch eine Anforderung von dem
Pool-Manager 331 eingeleitet, dass eine Größenanpassung
des Pools oder eine neue Konfiguration erforderlich ist. Wenn in
einem Ausführungsbeispiel
alle Bausteine am Ende des modifizierten Auffrischprozesses einem
Nap-Down unterzogen werden, signalisieren der Paketgenerator 321 und
die Auffrischeinheit dem Pool-Manager 331 anzuzeigen, dass
die Pools jetzt neu konfiguriert oder neu initialisiert werden können. Nachdem
die Pools neu konfiguriert oder neu initialisiert worden sind, kann
der Pool-Manager 331 seinen normalen Betrieb wieder aufnehmen,
da er in der Lage ist die Pools zu erhalten nachdem die Zustände der
Bausteine bekannt sind.
-
Die
Abbildung aus 7 veranschaulicht ein Zustandsdiagramm
eines Ausführungsbeispiels
eines modifizierten Auffrischprozesses als Reaktion auf eine Anforderung
für die
neue Konfiguration oder Größenanpassung
der Leistungsregelungspools. Die Auffrischeinheit 311 tritt
in dem Block 701 in einen Wartezustand. Wenn der Auffrischzähler, der
zur Überwachung
der Zeitintervalle zwischen Auffrischungen verwendet wird, einen
vorbestimmten Zielwert erreicht, leitet die Auffrischeinheit 311 die
Auffrischoperationen ein. In dem Block 711 wird eine Auffrischanforderung
eingeleitet, welche die Auffrischoperationen beginnt. Wie dies bereits
vorstehend im Text beschrieben worden ist, beginnt die Auffrischeinheit mit
den Auffrischoperationen, indem eine Anforderung zum Aufwecken oder
Aktivieren aller Speicherbausteine an den Paketgenerator 321 gesendet wird,
der wiederum die entsprechenden Pakete an die Speicherbausteine
ausgibt. In dem Block 721 wird eine Anforderung zum Aufwecken
aller Speicherbausteine eingeleitet. Als Reaktion auf ein Signal,
das anzeigt, dass alle Bausteine aktiviert worden sind, wird in
dem Block 731 eine Anforderung zum Auffrischen aller Speicherbausteine
eingeleitet. In dem vorliegenden Beispiel wird angenommen, dass
der Pool-Manager eine Anforderung zur Größenanpassung der Pools eingeleitet
hat. Da eine Anforderung zur Größenanpassung
der Pools eingeleitet worden ist anstatt mit dem Block 741 fortzufahren,
um die Zustände
der Bausteine wiederherzustellen, die sich vor der Aktivierung in
dem Ruhemodus befunden haben, fährt
der Ablauf mit dem Block 751 vor, um alle Speicherbausteine
am Ende der Auffrischung in den Ruhezustand zu versetzen, und wobei es
dem Pool-Manager signalisiert wird, wenn alle Bausteine in den Ruhezustand
versetzt worden sind. Der Ablauf tritt danach in dem Block 701 wieder
in den Wartezustand ein, um auf den nächsten Auffrischzyklus zu warten.
Wie dies bereits vorstehend im Text beschrieben worden ist, kann
durch Modifizieren des Auffrischprozesses eine dynamische Pool-Konfiguration
erreicht werden. Die Abbildungen der 8A–8B zeigen
ein Beispiel für
eine Konfiguration der drei Pools A, B und C als Reaktion auf eine
Anforderung zur Größenanpassung
der Pools. In dem vorliegenden Beispiel wird der aktive Pool in
Bezug auf die Größe auf Eins
neu angepasst, und die Größe des Standby-Pools
wird ebenfalls auf Eins angepasst. Die Abbildung aus 8A zeigt den
Status der drei Pools an einem bestimmten Punkt während dem
Systembetrieb. Die Abbildung aus 8B zeigt
den Status der drei Pools nach Abschluss einer Anforderung zur Größenanpassung
der Pools. Wie dies in der Abbildung aus 8B dargestellt
ist, ist sowohl der Pool A (der aktive Pool) als auch der Pool B
(der Standby-Pool) leer, und alle Speicherbausteine sind in dem
Pool C (dem Ruhezustands-Pool) dargestellt. Der Pool-Manager kann
jetzt den normalen Betrieb wieder aufnehmen, um die Pools gemäß der neuen
Größen der
Pools zu erhalten.
-
Die
Abbildung aus 9 zeigt ein Blockdiagramm eines
Ausführungsbeispiels
einer Vorrichtung zur dynamischen Anpassung der Größen der
Leistungsregelungspools, die zum Erhalten und Regeln der Betriebsmodi
der Speicherbausteine eingesetzt werden. In einem Ausführungsbeispiel
befinden sich die Leistungsregelungseinheit 931 und die
DRAM-Steuereinheit 941 in einer Speichersteuereinheit 921,
welche die hierin beschriebenen Lehren der vorliegenden Erfindung
einsetzt, um die Größen der
Leistungsregelungspools dynamisch anzupassen. In einem Ausführungsbeispiel
weist die Leistungsregelungseinheit 931 eine Pool-Verwaltungseinheit
(d.h. einen Pool-Manager) auf, die dafür zuständig ist, die Größen der
Leistungsregelungspools zu erhalten und zu regeln sowie die Betriebsmodi
der Speicherbausteine. In einem Ausführungsbeispiel arbeitet die
DRAM-Steuereinheit 941 so, dass die verschiedenen Speichertransaktionen,
die an die Speicherbausteine gerichtet sind, gesteuert werden, und
ferner zur Ausführung
verschiedener Wartungsoperationen, wie etwa Auffrisch- und Kalibrierungsoperationen,
wie dies bereits vorstehend im Text beschrieben worden sind. In
einem Ausführungsbeispiel
weist die DRAM-Steuereinheit 941 eine Auffrischeinheit
und einen Paketgenerator auf, wobei es sich um Einheiten handelt,
wie sie in Bezug auf die Abbildung aus 3 beschrieben worden
sind. Eine oder mehrere Prozessoreinheiten (z.B. CPUs) sind mit
der Leistungsregelungseinheit 931 gekoppelt, um Anforderungen
für einen
Größenanpassung
der Pools zu senden. Wie dies bereits vorstehend beschrieben worden
ist, kann es während
dem Systembetrieb erforderlich oder vorteilhaft sein, die Größen der Leistungsregelungspools
als Reaktion auf verschiedene Änderungen
der Systemoperationen und Systembedingungen anzupassen, wie zum
Beispiel bei Veränderungen
der thermischen Umgebung des Systems oder der Systemnutzungswerte,
um ein Gleichgewicht zwischen den Anforderungen in Bezug auf die
Systemleistung, den Leistungsverbrauch und die Wärmeerzeugung zu erhalten. Wenn
eine derartige Änderung
detektiert wird, leitet der Prozessor 911 eine Anforderung
zur Größenanpassung
der Leistungsregelungspools an die Leistungsregelungseinheit 931 ein.
In einem Ausführungsbeispiel
leitet der Pool-Manager in der Leistungsregelungseinheit 931 als
Reaktion auf dem Empfang einer Anforderung zur Größenanpassung
der Pools eine Anforderung an die DRAM-Steuereinheit 941 ein,
die Behandlung von Speichertransaktionen zu unterbrechen, bis alle
DRAMs aufgefrischt worden sind. In diesem Fall weist der Pool-Manager, wie dies
bereits vorstehend im Text beschrieben worden ist, die DRAM-Steuereinheit 941 an,
dass eine Anforderung zur Größenanpassung
der Pools eingeleitet worden ist, und somit müssen alle Speicherbausteine
nach Abschluss der Auffrischung in den Ruhezustand versetzt werden
(Napped-Down). Im
Besonderen führt
die DRAM-Steuereinheit 941 den vorstehend beschriebenen
Auffrischprozess aus, so dass alle Speicherbausteine nach Abschluss
der Auffrischung in einen bekannten Zustand (z.B. den Ruhezustand)
versetzt werden. Der Pool-Manager in der Leistungsregelungseinheit 931 initialisiert
danach die Pools mit neuen Größen neu,
nachdem ein Signal von der DRAM-Steuereinheit 941 empfangen
worden ist, dass alle Speicherbausteine aufgefrischt worden und
in einen bestimmten Zustand (z.B. den Ruhezustand) versetzt worden
sind. Nach der neuen Initialisierung der Pools kann der Pool-Manager
jetzt dessen normalen Betrieb wieder aufnehmen, um die Pools zu
erhalten und zu regeln, und zwar unter Verwendung der neuen Pool-Größen, die
der von dem Prozessor 911 empfangenen Anforderung entsprechen.
In einem Ausführungsbeispiel
kann der Prozessor 911 Informationen liefern, die mit der
Anforderung zur Größenanpassung
die neuen Größen anzeigen.
In einem anderen Ausführungsbeispiel können die
neuen Größeninformationen
vorab gespeichert werden, und der Pool-Manager kann bestimmen, welche
neuen Größen durch
die Art von Anforderung verwendet werden sollen, die von dem Prozessor 911 empfangen
werden.
-
Unter
Anwendung der Lehren der vorliegenden Erfindung, die eine dynamische
Konfiguration der Leistungsregelungspools ermöglichen, kann Systemsoftware
oder können
Programme modifiziert oder so gestaltet werden, dass sie die thermischen
Bedingungen des Systems überwachen
und entsprechende Anforderungen an die Leistungsregelungseinheit
erzeugen, um die Größen der
Pools bei Bedarf anzupassen, wie dies in der Abbildung aus 9 dargestellt
ist, um den Systembetrieb in einem sicheren Temperaturbereich zu
halten. Leider können
es thermisch induzierte Fehler verhindern, dass das System normal
arbeitet, und somit können sie
die Systemsoftware blockieren, so dass diese keine Möglichkeit
besitzt, etwaige potenziell schädliche
Zustände
bzw. Bedingungen zu beheben. Im Besonderen kann es sein, dass die
Systemsoftware nicht ausreichend schnell reagiert oder durch thermische
Fehler selbst funktionsunfähig
wird. Aus diesem Grund ist es erforderlich die Größen der
Leistungsregelungspools dynamisch anzupassen, ohne Eingriffe der
Systemsoftware. Um dieses Problem zu lösen können die Lehren der vorliegenden
Erfindung eingesetzt werden, um einen Mechanismus bereitzustellen,
der der Speichersteuereinheit ermöglicht, auf verschiedene thermische Bedingungen
auf konfigurierbare Art und Weise zu reagieren, welche eine Drosselung
der Leistungsverbrauchswerte der Speicherbausteine schnell ermöglicht,
und dies ohne Intervention durch die Systemsoftware. In einem Ausführungsbeispiel
kann der vorstehend beschriebene Pool-Manager so gekoppelt werden, dass er
ein Signal empfängt,
das anzeigt, dass einen thermischen Zustand, der einen bestimmten
Schwellenwert überschritten
(z.B. eine thermische Überlastung)
hat, detektiert worden ist. Das Signal zeigt an, dass ein thermischer Überlastungszustand
von externer Hardware oder einem thermischen Sensor stammen kann,
der dafür zuständig ist,
die thermischen Zustände
auf Komponenten- oder Systemebene zu überwachen. Darüber hinaus
kann das Signal, das den thermischen Überlastungszustand anzeigt,
von anderer Hardware stammen, die die thermischen Zustände der
Speicherbausteine selbst überwacht.
In einem Ausführungsbeispiel
bewirkt jeder Zustand, dass die Systemhardware so anspricht, dass
die Größen der
Leistungsregelungspools auf bestimmte sichere Werte angepasst werden,
um den Leistungsverbrauchswert des Speichersystems schnell zu reduzieren.
In einem Ausführungsbeispiel
können
sichere Größenwerte
der Pools durch die Systemsoftware bereitgestellt und in einem Register
gespeichert werden. Zum Beispiel können Informationen, die die
Größe der aktiven,
Standby- und Ruhezustands-Pools anzeigen, durch die Systemsoftware
bereitgestellt und in einem Register gespeichert werden, auf dass
der Pool-Manager zugreift. Wenn ein thermischer Überlastungszustand detektiert
wird, passt der Pool-Manager die Größe der Pools gemäß den sicheren
Größenwerten
an, die in dem Register gespeichert sind, um die Größen der
Pools gemäß den in
dem Register gespeicherten sicheren Größenwerten anzupassen, um den
Leistungsverbrauchswert der Speicherbausteine auf einen Wert zu
reduzieren, der als sicher gilt. Die als sicher geltenden Größen der
Pools können
natürlich
variieren, abhängig
von der Systemkonfiguration, den Leistungsverbrauchswerten der Speicherbausteine
in verschiedenen Leistungszuständen,
der Schwere der thermischen Überlastungszustände, etc.
Ferner können
unterschiedliche Größen der
sicheren Größenwerte
für unterschiedliche
Systemereignisse oder Variationen dieser bereitgestellt werden.
-
Die
Abbildung aus 10 zeigt ein Blockdiagramm eines
Ausführungsbeispiels
einer Vorrichtung zum dynamischen Anpassen der Größen der
Leistungsregelungspools als Reaktion auf verschiedene Systemereignisse,
und zwar ohne Intervention durch die Systemsoftware. In einem Ausführungsbeispiel
ist der Pool-Manager 1020 zuständig für die Regelung der Größen der
Leistungsregelungspools ohne Intervention durch die Systemsoftware.
In einem Ausführungsbeispiel
werden ein oder mehrere Register eingesetzt, um die Größen der
Pools zu speichern, die als sichere Größen für die Verwendung durch den
Pool-Manager 1020 gelten, wenn es erforderlich ist, die
Größen der
Pools als Reaktion auf einige spezifizierte Ereignisse anzupassen,
die durch das Ausgangssignal des OR-Gatters 1030 angezeigt
werden. Die sicheren Größen oder
Variationen dieser können
in einem Ausführungsbeispiel
durch Systemsoftware bereitgestellt oder programmiert werden. In einem
Ausführungsbeispiel
können
die Eingaben in das OR-Gatter 1030 von zwei verschiedenen
Quellen stammen. Eine der beiden Eingaben in das OR-Gatter kann
von einer Hardwarevorrichtung stammen, die für die Überwachung der thermischen
Zustände
spezifischer Komponenten auf der Komponentenebene oder des Systems
auf Systemebene zuständig
sind. In einem Ausführungsbeispiel
stammt die andere Eingabe in das OR-Gatter 1030 von einem
Thermosensor oder einer Hardwarevorrichtung, die für die Überwachung
der thermischen Zustände
des Speichersystems zuständig
ist. In einem Ausführungsbeispiel
wird das Ausgangssignal des OR-Gatters 1030 dazu verwendet,
dem Pool-Manager 1020 anzuzeigen, dass ein thermischer Überlastungszustand
detektiert worden ist. Als Reaktion auf das Ausgangssignal des OR-Gatters 1030 leitet
der Pool-Manager 1020 eine Anforderung an die DRAM-Steuereinheit 1040 ein,
die Größen der
Pools gemäß der vorstehenden
Beschreibung anzupassen, unter Verwendung der in dem Register 1010 gespeicherten
sicheren Größenwerte.
-
Die
Abbildung aus 11 zeigt ein Blockdiagramm eines
Ausführungsbeispiels
einer Vorrichtung zum dynamischen Anpassen der Größen der
Leistungsregelungspools als Reaktion auf eine Größenanpassungsanforderung von
einem Prozessor (dargestellt in 9) oder
als Reaktion als ein durch Hardware detektiertes Signal, das einen
thermischen Überlastungszustand
anzeigt (wie dies in 10 dargestellt ist). In dem
vorliegenden Ausführungsbeispiel
löst entweder
eine von dem Prozessor 1110 empfangene Größenanpassungsanforderung
oder ein Signal von dem OR-Gatter 1130 den Pool-Manager 1120 aus,
um eine Anforderung an die DRAM-Steuereinheit 1140 zur
Größenanpassung
der Pools unter Verwendung des vorstehend beschriebenen Auffrischprozesses
zu erzeugen. Wenn der Prozessor, wie dies vorstehend im Text beschrieben
worden ist, die Anforderung für
die Größenanpassung
einleitet, können
die neuen Größenwerte
durch den Prozessor 1110 zum Zeitpunkt der Anforderung
bereitgestellt werden. Die neuen Größenwerte können vorab gespeichert und durch
den Pool-Manager 1120 auf der Basis der Art der von dem
Prozessor 1110 empfangenen Anforderung bestimmt werden.
Wenn der Ausgang des OR-Gatters 1130 einen thermischen Überlastungszustand
anzeigt, können
die zu verwendenden sicheren Größenwerte
aus dem Register 1105 abgerufen werden. In einem Ausführungsbeispiel
kann das Register 1105 durch Systemsoftware programmiert
werden. Bei dieser Konfiguration kann der Pool-Manager 1120 die
Größen der
Pools dynamisch anpassen, und zwar als Reaktion auf die Größenanpassungsanforderung
von dem Prozessor 1110 oder als Reaktion auf ein Signal
von dem OR-Gatter 1130, das einen thermischen Überlastungszustand
anzeigt.
-
Die
Abbildung aus 12 veranschaulicht ein Flussdiagramm
eines Ausführungsbeispiels
eines Verfahrens zum dynamischen Anpassen der Größen der Leistungsregelungspools
als Reaktion auf eine Anforderung zur Größenanpassung von einem Prozessor
oder von anderen Systemeinheiten. Das Verfahren 1200 beginnt
in dem Block 1201 und fährt
mit der Schleife 1205 fort. In der Schleife 1205 wartet
der Pool-Manager auf eine Anforderung für eine Größenanpassung der Pools von
dem Prozessor. Nach dem Empfang einer Anforderung für eine Größenanpassung
von dem Prozessor verlässt
der Pool-Manager die Schleife 1205, um in dem Block 1209 eine
Anforderung an die DRAM-Steuereinheit zur Größenanpassung der Pools einzuleiten.
In der Schleife 1213 verlässt die DRAM-Steuereinheit
die Warteschleife 1213, wenn der Zeitpunkt für die Auffrischung
der Speicherbausteine gekommen ist. In dem Block 1217 wird
als Reaktion auf eine durch den Pool-Manager erzeugte Größenanpassungsanforderung
ein modifizierter Auffrischprozess gemäß der vorstehenden Beschreibung
ausgeführt,
um alle Speicherbausteine in einen spezifischen Betriebsmodus oder
Leistungszustand (z.B. den Ruhezustand) am Ende der Auffrischung
zu versetzen. In einem Ausführungsbeispiel umfasst
der modifizierte Auffrischprozess die Aktivierung aller Speicherbausteine,
die Auffrischung aller Speicherbausteine und das Versetzen aller
Speicherbausteine in den Ruhezustand, nachdem sie aufgefrischt worden
sind. In dem Block 1221 werden die Pools durch den Pool-Manager
neu initialisiert, und zwar nach dem Empfang eines Signals, das
anzeigt, dass alle Speicherbausteine in einen bekannten spezifischen
Betriebszustand oder Leistungszustand (z.B. den Ruhezustand) versetzt
worden sind. Das Verfahren fährt
danach mit dem Ende in dem Block 1291 fort.
-
Die
Abbildung aus 13 veranschaulicht ein Flussdiagramm
eines Ausführungsbeispiels
eines Verfahrens zum dynamischen Anpassen der Größen der Leistungsregelungspools
als Reaktion auf Systemereignisse ohne Softwareintervention. Das
Verfahren 1300 beginnt mit dem Block 1301 und
tritt in der Schleife 1305 in einen Wartezustand ein. Wenn
ein Signal detektiert wird, das einen thermischen Überlastungszustand
anzeigt, so verlässt
das Verfahren die Schleife 1305, so dass eine Anforderung
zur Größenanpassung
der Pools auf sichere Größenwerte
in dem Block 1309 erzeugt wird. In der Schleife 1313 fährt die
DRAM-Steuereinheit mit
dem Verlassen der Warteschleife 1313 fort, wenn der Zeitpunkt
zum Auffrischen der Speicherbausteine gekommen ist. In dem Block 1317 wird
als Reaktion auf eine durch den Pool-Manager erzeugte Anforderung
zur Größenanpassung
ein modifizierter Auffrischprozess gemäß der vorstehenden Beschreibung
ausgeführt,
um alle Speicherbausteine in einen spezifischen Betriebsmodus oder
Leistungszustand (z.B. den Ruhezustand) am Ende der Auffrischung
zu versetzen. In einem Ausführungsbeispiel
umfasst der modifizierte Auffrischprozess die Aktivierung aller
Speicherbausteine, das Auffrischen aller Speicherbausteine und das
Versetzen aller Speicherbausteine in den Ruhezustand, nachdem sie
aufgefrischt worden sind. In dem Block 1331 werden nach
dem Empfang eines Signals, das anzeigt, dass alle Speicherbausteine
in einen bekannten spezifischen Betriebsmodus oder Leistungszustand
(z.B. den Ruhezustand) versetzt worden sind, die. Pools durch den Pool-Manager
neu initialisiert, und zwar unter Verwendung der sicheren Größenwerte,
die dem detektierten thermischen Überlastungszustand entsprechen.
Wie dies vorstehend beschrieben worden ist, können die sicheren Größenwerte
zur Verwendung als Reaktion auf einen thermischen Überlastungszustand
oder Variationen dieses Zustands durch Systemsoftware programmiert
und in einem Register gespeichert werden, auf das der Pool-Manager
zugreifen kann. Das Verfahren fährt
danach mit dem Ende in dem Block 1391 fort.
-
Die
Abbildung aus 14 zeigt ein Flussdiagramm eines
Ausführungsbeispiels
eines Verfahrens zum dynamischen Anpassen der Größen der Leistungsregelungspools
als Reaktion auf eine Anforderung zur Größenanpassung, die von einem
Prozessor empfangen worden ist (wie dies vorstehend im Text in Bezug
auf die Abbildung aus 12 beschrieben worden ist) oder
als Reaktion als ein durch Hardware detektiertes Signal, das einen
thermischen Überlastungszustand
anzeigt (wie dies vorstehend im Text in Bezug auf 13 beschrieben
worden ist). Das Verfahren 1400 beginnt in dem Block 1401 und
fährt mit
dem Entscheidungsblock 1405 fort. In dem Entscheidungsblock 1405 fährt das
Verfahren mit dem Entscheidungsblock 1409 fort, wenn kein
thermischer Überlastungszustand
detektiert worden ist. Ansonsten fährt das Verfahren mit dem Block 1413 fort.
In dem Entscheidungsblock 1409 fährt das Verfahren in einer
Schleife mit dem Entscheidungsblock 1405 fort, wenn keine
Größenanpassungsanforderung
von dem Prozessor gegeben ist. Ansonsten fährt das Verfahren mit dem Block 1413 fort.
In dem Block 1413 leitet der Pool-Manager eine Anforderung
zur Größenanpassung
ein. An der Schleife 1417 verlässt die DRAM-Steuereinheit die
Warteschleife 1417, wenn der Zeitpunkt zum Auffrischen
der Speicherbausteine gekommen ist. In dem Block 1421 wird
als Reaktion als eine durch den Pool-Manager erzeugte Größenanpassungsanforderung
ein modifizierter Auffrischprozess gemäß der vorstehenden Beschreibung
ausgeführt,
so dass alle Speicherbausteine in einem spezifischen Betriebsmodus
oder Leistungszustand (z.B. dem Ruhezustand) am Ende der Auffrischung
platziert werden. In einem Ausführungsbeispiel
umfasst der modifizierte Auffrischprozess das Aktivieren aller Speicherbausteine,
das Auffrischen aller Speicherbausteine und das Versetzen aller
Speicherbausteine in den Ruhezustand, nachdem sie aufgefrischt worden
sind. In dem Block 1431 werden die Pools nachdem ein Signal
empfangen worden ist, das anzeigt, dass alle Speicherbausteine in
einen bekannten spezifizierten Betriebsmodus oder Leistungszustand
(z.B. den Ruhezustand) versetzt worden sind, durch den Pool-Manager
neu initialisiert, und zwar unter Verwendung der neuen Größenwerte,
die dem Zustand entsprechen, der die Größenanpassungsanforderung auslöst. Wenn
die Größenanpassungsanforderung
durch den Prozessor ausgelöst
wird, können
die neuen Größenwerte
zur Verwendung entweder durch den Prozessor bereitgestellt werden,
wenn der Prozessor die Anforderung einleitet oder vorab gespeichert
und durch den Pool-Manager bestimmt worden ist, auf der Basis des
von dem Prozessor empfangenen Anforderungstyps. Wenn die Größenanpassungsanforderung
durch das Signal ausgelöst
wird, das einen thermischen Überlastungszustand
anzeigt, werden die sicheren Größenwerte,
die dem detektierten thermischen Überlastungszustand entsprechen,
durch den Pool-Manager verwendet, um die Pools neu zu initialisieren.
Wie dies bereits vorstehend im Text beschrieben worden ist, können die
sicheren Größenwerte,
die als Reaktion auf einen thermischen Überlastungszustand oder Variationen
dieses Zustands verwendet werden sollen, durch Systemsoftware programmiert
und in einem Register gespeichert werden, auf das der Pool-Manager
zugreifen kann. Das Verfahren fährt
danach mit dem Ende in dem Block 1491 fort.
-
Die
vorliegende Erfindung wurde in Bezug auf die bevorzugten Ausführungsbeispiele
beschrieben. Es ist offensichtlich, dass zahlreiche Alternativen,
Modifikationen, Abänderungen
und Anwendungen für
den Fachmann auf dem Gebiet aus der vorstehenden Beschreibung deutlich
werden.
