-
HINTERGRUND
-
Technisches Gebiet
-
Die Ausführungsformen beziehen sich generell auf das Strommanagement in Rechenplattformen. Im Spezielleren beziehen sich die Ausführungsformen auf die Verwendung von Geräteleerlaufzeiten zur Auswahl von Leerlaufzustanden für Rechenplattforme.
-
Erörterung
-
Bei konventionellen mobilen Rechenplattformen können Leerlaufzustande dazu dienen, den Stromverbrauch zu reduzieren und die Batterielebenszeit zu verlängern, wobei tiefere Leerlaufzustände generell mehr Strom sparen. Die Tiefe des Leerlaufzustandes kann jedoch begrenzt sein, um die Servicequalität (QoS) zu garantieren, die Plattformgeräte erfordern. Das unnötige Begrenzen des Leerlaufzustandes kann unter bestimmten Umständen eine negative Wirkung auf die Energieeffizienz und -leistung haben.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Die verschiedenen Vorteile der erfindungsgemäßen Ausführungsformen sind für den Fachmann beim Durchlesen der folgenden Beschreibung und der anhängenden Ansprüche sowie unter Bezugnahme auf die folgenden Zeichnungen offensichtlich, in denen:
-
1 gemäß einer Ausführungsform eine Aufzeichnung eines Beispiels von Entscheidungen über Leerlaufzustände während eines bestimmten Zeitraums ist;
-
2 ein Blockdiagramm eines Beispiels einer Aggregatorarchitektur gemäß einer Ausführungsform ist;
-
3 ein Blockdiagramm eines Beispiels einer Plattform ist, die gemäß einer Ausführungsform ein Berichterstattungsschema für Leerlaufzeit-Informationen ist;
-
4 ein Ablaufdiagramm eines Beispiels einer Methode zur Bestimmung der Leerlaufzeit-Aktionen gemäß einer Ausführungsform ist;
-
5 ein Ablaufdiagramm eines Beispiels einer Methode zur Verwaltung von Plattform-Leerlaufzeiten gemäß einer Ausführungsform ist;
-
6 ein Ablaufdiagramm eines Beispiels einer Methode zur Verwaltung von Plattform-Leerlaufzeiten gegen Ende einer Leerlaufzeit gemäß einer Ausführungsform ist; und
-
7 eine Aufzeichnung eines Beispiels eines Zeitversatz-Kompensierungsschemas gemäß einer Ausführungsform ist.
-
AUSFÜHRLICHE BESCHREIBUNG
-
In 1 wird eine Leerlaufzeit-Auswahlaufzeichnung für eine Plattform wie etwa ein Rechengerät gezeigt. Die Plattform kann eine Plattformlatenz-Toleranzanforderung (LTR) 12 haben, die die maximal akzeptable Verzögerung bei der Erregung eines für die Plattform ausgewählten Leerlaufzustands anzeigen kann, um die Korrektheit zu garantieren. In dieser Hinsicht ist der Übergang aus einem bestimmten Leerlaufzustand typischerweise nicht unmittelbar, wobei die Plattform LTR 12 einen Mechanismus zur Steuerung des mit Leerlaufzustandsübergängen zusammenhängenden Latenz-Overhead bereitstellen kann, indem sie bestimmt, welcher niedrige Leerlaufzustand erreicht werden kann, um die Ausgangslatenz-Anforderungen zu errfüllen. Wie noch detaillierter erörtert wird, kann die Plattform LTR 12 von der erwarteten Aktivität der internen und externen Geräte abhängen, die mit der Plattform zusammenhängen. Im veranschaulichten Beispiel wird die Leerlaufzeit-Information von den zur Plattform gehörenden Geräten aggregiert, wobei die Leerlaufzeit-Information von einem bestimmten Gerät generell die Dauer der Zeit angibt, die das Gerät im Leerlauf bleiben soll.
-
Im Spezielleren kann die Leerlaufzeit-Information dazu dienen, die Plattform schneller in den tiefsten Leerlaufzustand zu versetzen, der die Plattform LTR 12 entlang eines Zustandsauswahlpfads 10 befriedigt. Tatsächlich wäre das veranschaulichte Leerlaufzeit-Schema auch für Plattforme von Vorteil, die keine LTR haben. Es ist speziell zu beachten, dass ein konventioneller Zustandsauswahlpfad 14, der keine Leerlaufzeit-Informationen von Plattformgeräten aggregiert, zu dem in einer Region 16 der Aufzeichnung gezeigten zusätzlichen Stromverbrauch führen könnte. In einem Beispiel sind die Leerlaufzustände ACPI („Advanced Configuration and Power Interface”, z. B. ACPI-Spezifikation, Rev. 4.0a, 5. April 2010)-Niedrigstromzustände, obwohl auch andere Leerlaufzustände benutzt werden können.
-
2 zeigt eine Aggregatorarchitektur, in der ein untergeordneter Aggregator 18 Leerlaufzeit-Informationen von einem ersten Satz von Geräten 20 erfasst, und ein Root-Aggregator 22 Leerlaufzeit-Informationen von dem untergeordneten Aggregator 18 und einem zweiten Satz von Geräten 24 erfasst. Der erste und der zweite Satz von Geräten 20, 24 können eine breite Vielfalt von internen und/oder externen Plattformgeräten umfassen, wie z. B. Timer, Audiogeräte, Displays, Kameras, Mäuse, Tastaturen, Sensoren, Netzwerkgeräte, Kommunikationsgeräte usw. Die Leerlaufzeit-Information kann von den Geräten 20, 24 z. B. unter Verwendung von spezifischen Busprimitiven, wie z. B. PCIe(„Peripheral Components Interconnect Express”, z. B. die PCI Express ×16 Graphics 150W-ATX Spezifikation 1.0, PCI Special Interest Group)-VDM („Vendor Defined Message”), an die Aggregatoren 18, 22 übertragen oder an spezifische Speicheradressen geschrieben werden. Darüber hinaus können die Aggregatoren 18, 22 die Quelle der Leerlaufzeit-Information z. B. über die Identifikation des Downstream-Port zurückverfolgen, von dem Leerlaufzeit-Nachrichten stammen, oder durch die Verwendung von globalen Aufzählungsschemata, wie z. B. die Quellen BDF(„Bus, Device, Function”)-Information, die in PCIe-Nachrichten gemeldet wird.
-
In 3 wird eine Plattform gezeigt, wobei die Plattform Teil einer Plattform sein kann, die Computing-Funktionalität (z. B. Personal Digital Assistant/PDA, Laptop, Smart-Tablet), Kommunikationsfunktionalität (z. B. drahtloses Smartphone), Bildverarbeitungsfunktionalität, Medienabspielfunktionalität (z. B. Smart-TV/TV) oder jede Kombination davon (z. B. mobiles Internetgerät/MID) aufweist. Die gezeigte Plattform umfasst ein detaillierteres Beispiel eines Leerlaufzeit-Meldungsschemas, in dem der erste Satz von Geräten 20 (20a–20k) die Leerlaufzeit-Information an den untergeordneten Aggregatoren 18 meldet und der zweite Satz von Geräten 24 (24a–24e) die Leerlaufzeit-Information an den Root-Aggregator 22 meldet. In einem Beispiel führt der Root-Aggregator 22 dies auf einem Prozessor aus, wie z. B. der zentralen Recheneinheit (CPU), und der untergeordnete Aggregator 18 führt dies auf einem Input/Output(I/O)-Untersystem der Plattform aus, wobei die Leerlaufzeiten (z. B. die Leerlaufzeit-Information) von den Geräten 20, 24 durch die Aggregatoren 18, 22 als deterministisch, geschätzt oder statistisch eingestuft werden können.
-
Generell können deterministische Geräte sein, von denen nicht erwartet wird, dass sie Verkehr für einen spezifizierten Zeitraum generieren, und von denen bekannt ist, dass sie aufwachen und aktiv werden, wenn der spezifizierte Zeitraum endet. Ein solches Gerät kann vor dem Ende des spezifizierten Zeitraums Verkehr generieren, und in diesem Fall kann das betroffene Gerät erwarten, dass ein solcher Service gemäß der maximalen, vom Gerät geforderten Latenz (z. B. LTR) bedient wird. Die LTR kann daher einen QoS-”Boden” für jedes deterministische Gerät etablieren. Eine verspätete Bedienung kann jedoch unter manchen Bedingungen relativ selten sein (z. B. eine Ausnahme vom Normalbetrieb). Wie noch detaillierter erörtert wird, können die deterministischen Geräte auch Leerlaufzeiten melden, wobei die deterministischen Leerlaufzeiten in einem Beispiel als ein Zeitraum von der Zeit gemeldet wird, als zum letzten Mal eine Nachricht von diesem Gerät gesendet wurde.
-
Somit empfängt der untergeordnete Aggregator 18 deterministische Leerlaufzeiten und LTR-Informationen von internen Geräten wie z. B. einem Timer 20e (z. B. Hochleistungs-Timer/HPET) und einem Audiogerät 20i (z. B. Audio Direct Memory Access/DMA-Controller), und der gezeigte Root-Aggregator 22 empfängt deterministische Leerlaufzeiten von internen Geräten wie einem oder mehreren Timern 24e (z. B. Local Advanced Programmable Interrupt Controller/LAPIC-Timer). Deterministische Leerlaufzeit können auch von externen Geräten wie Displays, Kameras, usw. empfangen werden.
-
In einem Beispiel unterhält der untergeordnete Aggregator 18 einen deterministischen Zähler für jeden Timer 20e und das Audiogerät 20i, wobei die deterministischen Zähler von den gemeldeten Leerlaufzeiten dekrementieren (z. B. herunterzählen), und der untergeordnete Aggregator 18 den Mindestwert der deterministischen Zähler als deterministische Leerlaufzeit auswählt, die an den Root-Aggregator 22 zu melden ist, wenn er später vom Root-Aggregator 22 abgefragt wird oder sich entscheidet, die Information an den Root-Aggregator zu schicken. In ähnlicher Weise kann der Root-Aggregator 22 einen deterministischen Zähler für jeden der Timer 24e sowie die vom untergeordneten Aggregator 18 gemeldete deterministische Leerlaufzeit unterhalten und den Mindestwert der deterministischen Zähler als deterministische Leerlaufzeit für die Plattform auswählen.
-
4 zeigt eine Methode 28 zur Bestimmung der Leerlaufzeit-Aktionen. Das Verfahren 28 kann als ein Satz von logischen Befehlen implementiert werden, die in einem maschinen- oder computerlesbaren Speichermedium wie Random Access Memory (RAM), Read Only Memory (ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. in konfigurierbarer Logik gespeichert sind, wie z. B. programmierbare logische Anordnungen (PLAs), feldprogrammierbare Gate-Arrays (FPGAs), komplexe programmierbare Logikbaugruppen (CPLDs), in Logikhardware mit fester Funktionalität, die Schaltungstechnik verwendet, wie z. B. eine anwendungsspezifische integrierte Schaltung (ASIC), Complementary Metal Oxide Semiconductor-(CMOS) oder Transistor-Transistor-Logik-(TTL)-Technologie oder jede Kombination davon.
-
Der veranschaulichte Verarbeitungsblock 30 bestimmt eine Leerlaufzeit für das Gerät. Wie bereits erwähnt kann die Leerlaufzeit als zeitlich relativ zu einer vom Gerät gesendeten Nachricht betrachtet werden, wobei das Gerät planen könnte, in einen Schlaf-/Leerlaufzustand zu wechseln, bis eine Antwort auf die Nachricht verarbeitet werden muss. Bei Block 32 kann festgelegt werden, ob die Plattform konfiguriert wird, eine oder mehrere Pre-Wake-Aktivitäten durchzuführen, wobei Pre-Wake-Aktivitäten z. B. strom- und/oder uhrbezogene Aufgaben umfassen, die es der Plattform ermöglichen, den Leerlaufzustand in graduellen Schritten effizienter und schneller zu verlassen. Die Festlegung bei Block 32 könnte z. B. durch das Zugreifen auf ein passendes Register oder einen programmierbaren Speicherort gemacht werden. Falls die Plattform konfiguriert wird, Pre-Wake-Aktivitäten durchzuführen, erhöht (bzw. verlängert) der veranschaulichte Block 34 die LTR des deterministischen Gerätes. Die Erhöhung der LTR kann während des Verlassens von Leerlaufzuständen mehr Latenz erlauben und es der Plattform effektiv ermöglichen, in tiefere Leerlaufzustände zu wechseln.
-
Falls die Plattform jedoch nicht konfiguriert wird, Pre-Wake-Aktivitäten durchzuführen, bleibt die LTR im veranschaulichten Beispiel unverändert. Block 36 bietet die Möglichkeit, die Leerlaufzeit und die LTR an einen Aggregator auszugeben, z. B. den Root-Aggregator 22 (2 und 3) oder den untergeordneten Aggregator 18 (2 und 3), wie bereits besprochen. Wie noch detaillierter erörtert wird, kann das deterministische Gerät auch eine weitere, kürzere LTR zur Verwendung für „Pop-ups” gegen Ende der Leerlaufzeiträume melden.
-
Geschätzte Geräte können dagegen Geräte sein, bei denen eine relativ hohe Wahrscheinlichkeit besteht, dass das Gerät keinen Verkehr für einen spezifizierten Zeitraum generiert, wobei das Gerät keinen Verkehr haben kann, wenn der spezifizierte Zeitraum abläuft. Beispiele solcher Geräte umfassen z. B. Netzwerkgeräte (z. B. erweiterbare Hostcontroller-Schnittstelle/XHCI, Geräte mit/ohne Drahtverbindung) und andere Kommunikationsgeräte, die Puffer haben, die sich auf Basis von eintreffendem Verkehr oder geplanten Betriebsfenstern füllen, im Laufe derer Aktivität vorkommen kann. Diese Geräte können auch Leerlaufzeiten als einen Zeitraum melden, von dem eine Nachricht gesendet wurde.
-
Somit empfängt der in 3 veranschaulichte untergeordnete Aggregator 18 geschätzte Leerlaufzeiten von externen Geräten wie z. B. den Expansionsgeräten 20a, 20b, die mit einem externen Bus über einen Erweiterungsport („Erweiterungsport 1”) und einen externen Hub („Ex. Hub”) gekoppelt sind, und von einem Kartengerät 20c, das mit dem externen Bus über einen Erweiterungsport („Erweiterungsport 2”) gekoppelt ist. In einem Beispiel benutzen die Erweiterungsports und das externe Hub ein PCIe-Protokoll, um miteinander zu kommunizieren. Der untergeordnete Aggregator 18 kann auch geschätzte Leerlaufzeiten von internen Geräten wie z. B. einem LAN(„Local Area Network”)-Gerät 20d, einer Fernschnittstelle (I/F, z. B. Managementmotor/ME-Schnittstelle) 20f, einem IO-(„Input/Output”)-Port 20h (z. B. Universal Serial Bus/USB-Port), einem Speicher I/F 20j (z. B. Serial Advanced Technology Attachment/SATA-Schnittstelle), usw. empfangen.
-
Im veranschaulichten Beispiel umfasst die Plattform auch bestimmte Geräte 21 (21a–21g), die keine Leerlaufzeit-Information melden (z. B. „No Hint”-Geräte). In einem solchen Fall können ein oder mehrere Schnittstellen benutzt werden, um Leerlaufzeiten auf Basis des Verkehrsmusters der Kommunikation mit den Geräten 21 zu schätzen. Zum Beispiel schätzt der gezeigte IO-Port 20h die Leerlaufzeit auf Basis des Verkehrsmusters von angeschlossenen Geräten, wie z. B. einem HID(„Human Interface Device”)-Gerät 21a (z. B. Maus, Tastatur, Sensor, etc.), einem isochronen Gerät 21b (z. B. Audio, Kamera), einem Bulk-Gerät 21c (z. B. Speicher, Drucker) und einer SSD („Solid State Disk) 21d. Im Spezielleren könnte das Verkehrsmuster des isochronen Gerätes 21b von seiner Art her eher deterministisch sein, z. B. wenn das Vorkommen des nächsten Slots genau bekannt wäre. Leerlaufzeiten für das Bulk-Gerät 21c können dagegen auf Basis der früheren Aktivität geschätzt werden. Der gezeigte Speicher I/F 20j ist auch mit der SSD 21d gekoppelt, die wiederum mit einem Hub 21e und einem oder mehreren Geräten 21f, 21g gekoppelt sein kann, wobei der Speicher I/F 21j Leerlaufzeiten schätzen kann.
-
Der Speicher I/F 20j kann z. B. wissen, ob es einige anhängige IO-Anforderungen gibt, in welchem Fall er die Leerlaufzeit auf „bald < 1 ms” schätzen würde. Wenn jedoch keine IO-Anforderungen anhängig sind, kann der Speicher die Leerlaufzeit auf „lang mindestens 5 ms” schätzen. Je nach den Umständen können auch andere Werte und Implementierungen benutzt werden. Darüber hinaus empfangt der gezeigte Root-Aggregator 22 geschätzte Leerlaufzeiten von einem externen Kommunikationsgerät 24a, einem externen Grafik-Controller 24b, einem integrierten Display 24c und einem internen Grafik-Controller 24d.
-
In einem Beispiel unterhält der untergeordnete Aggregator 18 je einen geschätzten Zähler für die Expansionsgeräte 20a, 20b, das Kartengerät 20c, das LAN-Gerät 20d, das Fern-I/F 20f, den IO-Port 20h und den Speicher I/F 20j, wobei die geschätzten Zähler von den geschätzten Leerlaufzeiten dekrementieren. Der untergeordnete Aggregator 18 kann daher den Mindestwert der geschätzten Zähler als eine geschätzte Leerlaufzeit identifizieren, die an den Root-Aggregator 22 zu melden ist. In ähnlicher Weise unterhält der gezeigte Aggregator 22 je einen geschätzten Zähler für das externe Kommunikationsgerät 24a, den externen Grafik-Controller 24b, das integrierte Display 24c und den internen Grafik-Controller 24d sowie für die vom untergeordneten Aggregator 18 gemeldete geschätzte Leerlaufzeit, und wählt den Mindestwert der geschätzten Zähler als eine geschätzte Leerlaufzeit für die Plattform aus.
-
Statistische Geräte können Geräte sein, die Verkehrsmuster haben, die nur im Sinne einer spezifischen Durchschnittsquote quantifizierbar sind. Beispiele solcher Geräte sind z. B. Mäuse, Tastaturen, Sensoren, usw. Diese Geräte können die Leerlaufzeit als einen erwarteten Zeitraum zwischen Ereignissen melden. Somit empfangt der gezeigte untergeordnete Aggregator 18 auch statistische Leerlaufzeiten von internen Geräten, wie z. B. einem HID-Gerät 20g und einem HID-Gerät 20k, über einen IO-Port („IO-Port 1”, z. B. USB-Port). In einem Beispiel unterhält der untergeordnete Aggregator 18 je einen statistischen Zähler für die HID-Geräte 20g, 20k, wobei die statistischen Zähler von den gemeldeten statistischen Leerlaufzeiten dekrementieren. Der untergeordnete Aggregator 18 kann daher den Mindestwert der statistischen Zähler als eine statistische Leerlaufzeit identifizieren, die an den Root-Aggregator 22 zu melden ist.
-
Falls es nahe des Mindestwertes der statistischen Zähler mehrere Werte gibt, kann ein Kompensationsansatz benutzt werden, bei dem eine kürzere Zeit angenommen wird, weil die Wahrscheinlichkeit, dass eines der Ereignisse vorkommen wird, ansteigt. Somit könnte der gezeigte untergeordnete Aggregator 18 die statistische Leerlaufzeit und/oder die Plattform-Leerlaufzeit reduzieren, falls sich die Leerlaufzeit des HID-Gerätes 20g und die Leerlaufzeit des HID-Gerätes 20k innerhalb eines vorbestimmten Abstands zueinander befinden. Die Plattform kann auch die Plattform-Managementlogik 26 umfassen, die Leerlaufzustände für die Plattform auf Basis der Leerlaufzeit-Information von den Aggregatoren 18, 22 auswählt.
-
Im Speziellen zeigt 5 ein Verfahren 38 zum Management von Plattform-Leerlaufzuständen. Das Verfahren 38 kann als ein Satz logischer Befehle implementiert werden, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. in konfigurierbarer Logik, wie z. B. PLAs, FPGAs, CPLDs, in Logikhardware mit fester Funktionalität, die Schaltungstechnik verwendet, wie z. B. eine ASIC-, CMOS oder TTL-Technologie oder jede Kombination davon. Der gezeigte Verarbeitungsblock 40 aggregiert Leerlaufzeiten von Plattformgeräten, wobei eine oder mehrere deterministische Leerlaufzeiten und Latenztoleranzen bei Block 42 identifiziert werden können. Der Block 44 kann dazu dienen, eine minimale deterministische Leerlaufzeit unter den deterministischen Leerlaufzeiten zu bestimmen. Zusätzlich können eine oder mehrere Leerlaufzeiten und Latenzanforderungen bei Block 46 identifiziert werden, wobei der gezeigte Block 48 eine minimale statistische Leerlaufzeit unter den statistischen Leerlaufzeiten bestimmt. Der Block 50 kann eine oder mehrere geschätzte Leerlaufzeiten und Latenztoleranzen identifizieren, und der Block 52 bestimmt eine minimale geschätzte Leerlaufzeit unter den geschätzten Leerlaufzeiten. Darüber hinaus kann eine Plattform-Leerlaufzeit bei Block 54 auf Basis der minimalen deterministischen Leerlaufzeit, der minimalen statistischen Leerlaufzeit und der minimalen geschätzten Leerlaufzeit bestimmt werden. In einem Beispiel wird der Minimalwert dieser Minimalwerte als Plattform-Leerlaufzeit benutzt. Ein Plattform-Leerlaufzustand kann bei Block 56 auf Basis der Plattform-Leerlaufzeit und der Latenztoleranzen ausgewählt werden.
-
Zum Beispiel könnte das Gerät, das dem für die Plattform-Leerlaufzeit benutzten Minimalwert entspricht, mittels Downstream-Port-Information, globalen Aufzählungsschemata, etc. identifiziert werden, wie bereits erwähnt. Dementsprechend kann auch die LTR dieses Gerätes identifiziert und als Plattform-LTR, wie z. B. Plattform-LTR 12 (1), benutzt werden, um einen Leerlaufzustand für die Plattform auszuwählen.
-
In 6 wird ein Verfahren 58 zum Management von Plattform-Leerlaufzeiten gegen Ende einer Leerlaufzeit gezeigt. Das Verfahren 58 kann als ein Satz logischer Befehle implementiert werden, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. in konfigurierbarer Logik, wie z. B. PLAs, FPGAs, CPLDs, in Logikhardware mit fester Funktionalität, die Schaltungstechnik verwendet, wie z. B. eine ASIC-, CMOS oder TTL-Technologie oder jede Kombination davon. Der gezeigte Verarbeitungsblock 60 bestimmt, ob eine Leerlauf-Plattform sich nahe dem Ende der Plattform-Leerlaufzeit befindet. Falls ja, dann kann bei Block 62 eine „Pop-up-Zeit” auf Basis einer relativ kurzen Latenztoleranz bestimmt werden. Diesbezüglich kann ein Prozess benutzt werden, um die Plattform für kurze Zeit aus dem Leerlaufzustand zu holen und zu bestimmen, ob der gleiche oder ein tieferer Leerlaufzustand erreichbar ist. Der Prozess könnte daher als ein „Pop-up-Prozess” betrachtet werden, der über einen Zeitraum hinweg stattfindet, der als „Pop-up-Zeit” oder Fenster (z. B. vorläufige „Wachzeit”) bezeichnet werden kann.
-
Wenn die Leerlaufzeit mit einem deterministischen Gerät zusammenhängt, bestimmt der veranschaulichte Ansatz die Länge der Pop-up-Zeit auf Basis einer relativ kurzen LTR im gezeigten Beispiel, um eine ordnungsgemäße Bedienung des deterministischen Geräteverkehrs sicherzustellen/zu garantieren (weil deterministische Geräte längere LTRs melden können, wenn die Plattform für Pre-Wake-Operationen konfiguriert ist). Die kürzere LTR kann daher in einem deterministisch garantierten LTR-Register gespeichert werden, das die Reaktionsfähigkeit der Plattform am Ende einer deterministischen Leerlaufzeit definiert, wobei die kürzere LTR für die Pop-up-Zeit garantiert werden kann.
-
Somit führt der Block 64 eine oder mehrere Pre-Wake-Aktivitäten durch, wobei bei Block 66 bestimmt werden kann, ob das deterministische Gerät (z. B. in Verbindung mit der Plattform-Leerlaufzeit) Verkehr generiert hat. Somit kann der Block 66 das mit der Plattform-Leerlaufzeit zusammenhängende Gerät über einen Zeitraum, der gleichlang ist wie die Pop-up-Zeit, auf Aktivität überwachen. Ist keine solche Aktivität vorgekommen, bestimmt der Block 68, ob die Pop-up-Zeit abgelaufen ist. Ist die Pop-up-Zeit nicht abgelaufen, überprüft der veranschaulichte Loop erneut, ob es eine Geräteaktivität gab. Wenn die Pop-up-Zeit abläuft, ohne dass eine Geräteaktivität erkannt wird, versetzt der veranschaulichte Block 70 die Plattform zurück in den gleichen oder einen tieferen Leerlaufzustand, um weiteren Strom zu sparen und die Batterielebenszeit zu verlängern. Falls bei Block 66 eine Geräteaktivität erkannt wird, sorgt der veranschaulichte Block 72 für die Verarbeitung der Daten/des Verkehrs, die mit dem betroffenen Gerät zusammenhängen.
-
In Fällen, wo das Gerät und die Aggregatoren keine gemeinsame Zeitbasis (z. B. Uhr) benutzen, kann eine Zeitversatz-Kompensierung verwendet werden. Diesbezüglich zeigt 7 ein Zeitversatz-Kompensierungsschema, in dem die Geräte-/Aggregatoraktion über Zeit aufgezeichnet wird. Im veranschaulichten Beispiel wird eine Leerlauf-Nachricht von einem ersten Gerät an einen Aggregator übertragen, wobei das erste Gerät eine Uhr benutzt, die etwas schneller ist als die Uhr, die vom Aggregator benutzt wird (z. B. negativer Zeitversatz). Ein Gerätezeilensegment 76 beginnt, wenn ein Leerlauf-Nachrichtenverbreitungsfenster 78 geöffnet wird, und ein Aggregatorzeilensegment 74 beginnt, wenn das Leerlauf-Nachrichtenverbreitungsfenster 78 geschlossen wird. Somit repräsentiert das Gerätezeilensegment 76 den Zeitraum, während dem das erste Gerät sich im Leerlaufzustand befindet, und das Aggregatorzeilensegment 74 repräsentiert den Zeitraum, während dem der Aggregator sich im Leerlaufzustand befindet, wie im Beispiel gezeigt. Bei Zeit T1 läuft die Leerlaufzeit ab. Weil das erste Gerät eine Uhr hat, die der vom Aggregator benutzten Uhr voraus ist, wacht das erste Gerät jedoch vor dem Aggregator auf. Um sicherzustellen, dass die Nachrichten vom ersten Gerät zum Aggregator nicht verlorengehen, erstellt das veranschaulichte Verfahren ein Geräte-Wartefenster 80, während dem das Gerät darauf wartet, dass der Aggregator den Leerlaufzustand verlässt.
-
In ähnlicher Weise könnte der Aggregator eine Uhr benutzen, die etwas schneller ist, als die von einem zweiten Gerät benutzte Uhr (z. B. positiver Zeitversatz). Zum Beispiel könnten ein Aggregatorzeilensegment 84 und ein Gerätezeilensegment 82 für das zweite Gerät einen Leerlaufzustand bei Zeit T2 verlassen, wobei der Zeitversatz (z. B. „Skew”) den Aggregator veranlasst, vor dem zweiten Gerät aufzuwachen. Dementsprechend implementiert das veranschaulichte Verfahren ein Aggregator-Wartefenster 86, um zu verhindern, dass der Aggregator fälschlicherweise annimmt, dass es für das zweite Gerät keine Daten/keinen Verkehr zu verarbeiten gibt. In einem Beispiel können das Geräte-Wartefenster 80 und das Aggregator-Wartefenster 86 durch die Kompensierung der Plattform-Leerlaufzeit und/oder der Pre-Wake-Aktivität für den Zeitversatz implementiert werden. Zum Beispiel kann für die Plattform-Leerlaufzeit eine Grenze festgelegt werden, damit der Zeitversatz während der Leerlaufzeit kürzer ist als die Pop-up-Zeit. Darüber hinaus können Pre-Wake-Aktivitäten so geplant werden, dass sie vorkommen, bevor das Gerät aufwacht, wobei der maximale negative Zeitversatz berücksichtigt wird. Zum Beispiel können die Pre-Wake-Aktivitäten so geplant werden, dass sie vor dem Ende des Gerätezeilensegments 76 vorkommen, wie im Beispiel gezeigt.
-
Ausführungsformen können daher ein deterministisches Gerät umfassen, das eine Logik hat, um eine Leerlaufzeit für das Gerät zu bestimmen und um eine Latenztoleranz auf Basis einer Pre-Wake-Konfiguration einer mit dem Gerät verbundenen Plattform zu bestimmen. Die Logik kann auch die Leerlaufzeit und die Latenztoleranz ausgeben. In einem Beispiel erhöht die Logik die Latenztoleranz, falls die Plattform konfiguriert ist, eine oder mehrere Pre-Wake-Aktivitäten durchzuführen.
-
Ausführungsformen können auch eine Vorrichtung umfassen, die eine erste Aggregatorlogik aufweist, die eine erste Leerlaufzeit von einem ersten Gerät und eine zweite Leerlaufzeit von einem zweiten Gerät aggregiert. Darüber hinaus kann die Vorrichtung eine Strommanagement-Logik aufweisen, um einen Leerlaufzustand für die Plattform basierend zumindest teilweise auf der ersten Leerlaufzeit und der zweiten Leerlaufzeit auszuwählen.
-
Ausführungsformen können auch eine Plattform umfassen, die ein erstes Gerät zur Ausgabe einer ersten Leerlaufzeit, ein zweites Gerät zur Ausgabe einer zweiten Leerlaufzeit und eine Root-Aggregator-Logik zur Aggregierung der ersten Leerlaufzeit und der zweiten Leerlaufzeit aufweist. Die Vorrichtung kann auch eine Strommanagement-Logik aufweisen, um einen Leerlaufzustand für die Plattform basierend zumindest teilweise auf der ersten Leerlaufzeit und der zweiten Leerlaufzeit auszuwählen.
-
Andere Ausführungsformen können mindestens ein maschinenlesbares Speichermedium umfassen, das einen Satz von Befehlen hat, die, falls sie von mindestens einem Prozessor ausgeführt werden, eine Plattform dazu veranlassen, eine erste Leerlaufzeit von einem ersten, mit der Plattform verbundenen Gerät und eine zweite Leerlaufzeit von einem zweiten, mit der Plattform verbundenen Gerät zu aggregieren. Falls die Befehle ausgeführt werden, können sie die Plattform ferner veranlassen, einen Leerlaufzustand für die Plattform basierend zumindest teilweise auf der ersten Leerlaufzeit und der zweiten Leerlaufzeit auszuwählen.
-
Darüber hinaus können Ausführungsformen ein Verfahren umfassen, in dem eine erste, mit einer Plattform verbundene Leerlaufzeit mit einer zweiten Leerlaufzeit von einem zweiten, mit der Plattform verbundenen Gerät aggregiert wird. Das Verfahren kann auch die Auswahl eines Leerlaufzustandes für die Plattform basierend zumindest teilweise auf einer ersten Leerlaufzeit und einer zweiten Leerlaufzeit bieten.
-
In diesem Dokument beschriebene Techniken können daher das Wissen über anstehende deterministische Zeiträume des Leerlaufs in Plattformgeräten wie Displaygeräten, Audiogeräten, Timer, Kamerapipelines, etc. benutzen, um es Verarbeitungskomponenten zu ermöglichen, vorher aufzuwachen, die Latenz zu reduzieren und die Weckenergie zu optimieren. Darüber hinaus kann das Wissen über anstehende deterministische Zeiträume des Leerlaufs in Plattformgeräten wie Kommunikationsgeräten, Netzwerkgeräten, etc. es Verarbeitungskomponenten ermöglichen, den passendsten Leerlaufzustand angesichts der Leerlaufzeit und der Energie-Break-even-Zeit des spezifizierten Zustands auszuwählen. Vereinfacht gesagt können die Leerlaufzeit-Meldung und -Aggregierung der Leerlaufzeit-Entscheidung einen Determinismus hinzufügen, welcher es wiederum ermöglichen kann, dass der optimale Energieeffizienzzustand so bald wie möglich erreicht wird, und dass die Residenz in diesem Zustand optimiert wird.
-
Darüber hinaus können die in diesem Dokument beschriebenen Techniken skalierbar sein, sowohl interne wie auch externe Geräte abdecken und dabei topologieunabhängig bleiben. Dementsprechend können Architekturen wie z. B. Laptops, Notebooks, Smartphones, etc. leicht von diesen Lösungen profitieren. Darüber hinaus können die in diesem Dokument beschriebenen Datenerfassungsschemata die Operation in der Gegenwart von Tiefschlafzuständen mit relativ langen Exit-Zeiten und Energie-Break-even-Zeiten besonders verbessern.
-
Ausführungsformen der vorliegenden Erfindung können bei allen Arten von Halbleiter-IC-(„Integrated Circuit”)-Chips angewendet werden. Beispiele dieser IC-Chips schließen ein, sind aber nicht beschränkt auf, Prozessoren, Controller, Chipsatz-Komponenten, programmierbare logische Anordnungen (PLAs), Speicherbausteine, Netzwerk-Chips, Systeme auf dem Chip (SoCs), SSD-Controller/NAND-Controller ASICs und dergleichen. Außerdem sind in einigen Zeichnungen Signalleiterleitungen mit Strichen dargestellt. Einige davon können unterschiedlich sein, um maßgeblichere Signalwege darzustellen, andere können eine Beschriftung enthalten, um eine Anzahl von dazugehörigen Signalwegen anzuzeigen, und/oder sie können Pfeile an einem oder an mehreren Enden enthalten, um die primäre Flussrichtung der Daten anzuzeigen. Dies soll jedoch in keiner Weise als eingrenzend ausgelegt werden. Solche zusätzlichen Details können in Verbindung mit einer oder mit mehreren beispielhaften Ausführungsformen verwendet werden, um ein besseres Verständnis einer Schaltung zu ermöglichen. Alle dargestellten Signalleitungen, ob mit oder ohne zusätzliche Informationen, können eines oder mehrere in mehrere Richtungen abgehende Signale umfassen und können mit jedem geeigneten Signalschema implementiert werden, z. B. können digitale oder analoge Leitungen mit Differenzialpaaren, Lichtwellenleitern und/oder referenzbezogenen Leitungen implementiert werden.
-
Größen/Modelle/Werte/Bereiche sind als Beispiele angegeben, obgleich Ausführungsformen der vorliegenden Erfindung nicht auf diese beschränkt sind. Mit der Ausreifung von Fertigungstechniken (z. B. Fotolithografie) im Laufe der Zeit ist zu erwarten, dass immer kleinere Geräte hergestellt werden können. Außerdem ist es möglich, dass wohlbekannte Strom-/Masseverbindungen mit den IC-Chips und anderen Komponenten in den Figuren gezeigt bzw. nicht gezeigt werden, was aus Gründen der Vereinfachung der Veranschaulichung und Erörterung geschieht, und um bestimmte Aspekte der erfindungsgemäßen Ausführungsformen nicht in den Hintergrund rücken zu lassen. Des Weiteren können Anordnungen im Blockdiagrammformat gezeigt werden, um Ausführungsformen der Erfindung nicht in den Hintergrund rücken zu lassen, und auch um aufzuzeigen, dass bestimmte Details in Bezug auf die Implementierung solcher Blockdiagrammanordnungen in hohem Maß von der Plattform abhängen, in die die Erfindung implementiert werden soll, d. h., dass der Fachmann mit solchen spezifischen Details vertraut sein sollte. Wo spezifische Details (z. B. Schaltungen) angeführt werden, um exemplarische Ausführungsformen der Erfindung zu beschreiben, sollte der Fachmann erkennen, dass erfindungsgemäße Ausführungsformen mit oder ohne Variationen dieser spezifischen Details realisiert werden können. Die Beschreibung soll somit als veranschaulichend anstatt einschränkend angesehen werden.
-
Der Begriff „gekoppelt” kann hierin verwendet sein, um auf jede Art von Beziehung, direkt oder indirekt, zwischen den betreffenden Komponenten zu verweisen, und kann sich auf elektrische, mechanische, fluidtechnische, optische, elektromagnetische, elektromechanische oder andere Verbindungen beziehen. Außerdem werden die Begriffe „erste/r/s”, „zweite/r/s”, etc. hierin nur verwendet, um die Erörterung zu vereinfachen, und tragen keine besondere temporäre oder chronologische Bedeutung, außer anderweitig angegeben. Außerdem beschränkt die Verwendung der Begriffe „erste/r/s”, „zweite/r/s”, etc. die erörterten Ausführungsformen nicht auf die Anzahl von aufgeführten Komponenten.
-
Für den Fachmann ist es anhand der vorhergegangenen Beschreibung selbstverständlich, dass die breit gefächerten Techniken der erfindungsgemäßen Ausführungsformen in einer Vielfalt von Formen implementiert werden können. Deshalb soll, während die erfindungsgemäßen Ausführungsformen in Verbindung mit besonderen Beispielen davon beschrieben worden sind, der wahre Umfang der erfindungsgemäßen Ausführungsformen nicht darauf beschränkt werden, da andere Modifikationen für den Fachmann auf diesem Gebiet bei Durchsicht der Zeichnungen, der Beschreibung und der folgenden Ansprüche offensichtlich sind.
