-
Gebiet der Erfindung
-
Die Erfindung bezieht sich auf die Verwaltung des Stromverbrauchs eines Prozessors durch Takt-Gating von einzelnen Teilen des Prozessors, die für eine gegebene Befehlsklasse oder einen bestimmten Inhalt in einem Befehl nicht verwendet werden.
-
Hintergrund der Erfindung
-
Es gibt viele verschiedene funktionelle Einheiten in einer zentralen Recheneinheit (CPU), die in bestimmten Stufen einer Befehlspipeline arbeiten. Abhängig von der Klasse des Befehls oder dem Inhalt eines Befehls ist es oft der Fall, dass nicht alle diese Funktionseinheiten gleichzeitig genutzt werden. Somit gibt es keinen Grund, dass alle Funktionseinheiten innerhalb einer CPU gleichzeitig eingeschaltet sind. Vielmehr können einige Einheiten zu einem bestimmten Zeitpunkt über keine Daten verfügen, mit welchen sie arbeiten können. Wenn eine Funktionseinheit keine Daten zu bearbeiten hat, befindet sie sich effektiv im Leerlauf. Allerdings werden derartige Leerlaufeinheiten, die noch mit einem aktiven Takt versorgt werden, aufgrund des empfangenen Taktsignals einen Stromverbrauch durch den ständigen Wechsel (Hin- und Herschalten) der Latches in der gesamten Einheit erfahren.
-
X68-Befehle weisen mehrere Felder auf. Drei der grundlegendsten Felder sind das Befehls-Opcode-Feld (z. B. Bewegung, Verschiebung, etc.), ein unmittelbares Operandenfeld und ein Verschiebungs-Byte-Feld. Obwohl viele Funktionseinheiten innerhalb der Befehlspipeline eine Schaltung aufweisen, um diese Felder zu behandeln, enthalten einige Instruktionen, die sich durch die Pipeline bewegen, keine Verschiebungs-Byte-Informationen oder eine unmittelbare Operandeninformation. In diesen Fällen werden die Daten, die diese Felder füllen, nicht verwendet und bestehen allgemein aus zufälligen Daten-Bits. Da sich der Befehl durch die Pipeline bewegt, erfahren die Funktionseinheiten, obwohl diese Felder nicht verwendet werden, dennoch ein Umschalten an ihren Latches, die diese Information eingeben. Dieses Umschalten erhöht weiter den Stromverbrauch in den Funktionseinheiten einer CPU.
-
Kurzbeschreibung der Zeichnungen
-
Die vorliegende Erfindung wird beispielhaft dargestellt und wird nicht durch die Zeichnungen, in welchen gleiche Bezugszeichen ähnliche Elemente bezeichnen, beschränkt und in welchen:
-
1 eine Ausführungsform eines Computersystems veranschaulicht, das in der Lage ist, den Stromverbrauch eines Prozessors basierend auf der Klasse und dem Inhalt von Instruktionen, die in zumindest einem Prozessor im System ausgeführt werden, zu verwalten;
-
2 spezifische relevante Einheiten und funktionale Logikblöcke innerhalb eines bestimmten Kerns zeigt, die es dem Kern ermöglichen, den Kernstromverbrauch durch eine Befehlsklassenbestimmung und Befehlsinhaltsbestimmung zu verwalten;
-
3 eine Ausführungsform einer Zustandsmaschine beschreibt, die verwendet wird, um Fließkomma-Mikrooperationen durch eine Befehlspipeline zu verfolgen;
-
4 ein Flussdiagramm einer Ausführungsform eines Verfahrens zum Takt-Gaten eines oder mehrerer programmierbarer Logikarrays in einem Dekoder ist, die nicht dazu konfiguriert sind, einen aktuellen Befehl zu dekodieren, der in den Dekoder eintritt;
-
5 ein Flussdiagramm einer Ausführungsform eines Verfahrens zum Takt-Gaten einer Verzweigungseinheit ist, wenn ein Verzweigungsbefehl nicht in der Pipeline dekodiert wird;
-
6 ein Flussdiagramm einer Ausführungsform eines Verfahrens zum Takt-Gaten einer Fließkommaeinheit ist, wenn kein Fließkommabefehl in der Befehlspipeline vorhanden ist;
-
7 ein Flussdiagramm einer Ausführungsform eines Verfahrens zum Eliminieren der unmittelbaren und Verschiebungs-Byte-Felder eines Befehls ist, wenn der Befehl diese Felder nicht verwendet.
-
Detaillierte Beschreibung der Erfindung
-
Ausführungsformen eines Prozessors und eines Verfahrens zur Verwaltung der Prozessorleistung basierend auf der Klasse und dem Inhalt von Befehlen in einer Befehlseinheit werden offenbart.
-
1 veranschaulicht eine Ausführungsform eines Computersystems, das dazu geeignet ist, den Stromverbrauch eines Prozessors basierend auf der Klasse und dem Inhalt von Befehlen zu verwalten, die in zumindest einem Prozessor im System ausgeführt werden.
-
Das Computersystem 100 wird gezeigt. Das Computersystem kann ein Desktop, Server, eine Workstation, ein Laptop, ein Handheld, ein TV-Set-Top, ein Media-Center, eine Spielkonsole, ein integriertes System (wie beispielsweise in einem Auto) oder eine andere Art eines Computersystems sein. In mehreren Ausführungsformen umfasst das Computersystem 100 eine oder mehrere zentrale Verarbeitungseinheiten (CPUs), die auch als „Prozessoren” bezeichnet werden. Obwohl es in vielen Ausführungsformen potentiell mehrere CPUs gibt, ist in der in 1 gezeigten Ausführungsform zur Vereinfachung lediglich die CPU 102 gezeigt. Die CPU 102 kann eine CPU der Intel Corporation oder eine CPU einer anderen Marke sein. Die CPU 102 umfasst in verschiedenen Ausführungsformen einen oder mehrere Kerne. Die CPU 102 ist mit vier Kernen (Kerne 104, 106, 108 und 110) gezeigt.
-
In vielen Ausführungsformen umfasst jeder Kern mehrere interne funktionelle Blöcke/Einheiten/Logik-Komponenten, wie die in der Explosionsansicht des Kerns 104 gezeigten. Beispielsweise umfasst der Kern 104 zumindest einen Befehls-/Daten-(d. h. Ebene 1, L1)Cache 112, einen Prefetch-Puffer 114, einen Vordekodier-Cache 116, einen Befehlsdekoder 118, eine Verzweigungsadresse-Berechnungseinheit 120, eine Befehlswarteschlange 122, eine Gleit-Komma-Ausführungseinheit 124, eine Zuordnungs-/Rückordnungs-Einheit 126 und eine Takt-Verwaltungs-/Erzeugungs-Logik 128. Mehrere dieser Einheiten und Logik-Komponenten werden in wesentlichen Einzelheiten nachfolgend mit Bezug zu 2 erläutert. Im Allgemeinen gibt es mehr Einheiten, Register und andere Schaltungen in jedem Kern als die im Kern 104 gezeigten, einschließlich der Möglichkeit mehrerer Kopien jeder der gezeigten Einheiten (z. B. eine oder mehrere Ganzzahl-/Adressausführungseinheiten, drei Gleit-Komma-Einheiten, etc.), wobei zusätzliche Einheiten nicht gezeigt sind, um die Klarheit der wichtigen Elemente aus 1 beizubehalten.
-
In einem Einzel-Thread-Kern kann jeder Kern als ein Hardware-Thread bezeichnet werden. Wenn ein Kern ein Multi-Thread oder Hyper-Thread ist, kann jeder Thread, der in jedem Kern arbeitet, auch als ein Hardware-Thread bezeichnet werden. Somit kann jeder einzelne Ausführungs-Thread, der im Computersystem 100 läuft als ein Hardware-Thread bezeichnet werden. Beispielsweise gibt es in 1, wenn jeder Kern ein Einzel-Thread ist, vier Hard-Ware-Threads im System (vier Kerne). Wenn andererseits jeder Kern ein Mehrfach-Thread ist und die Fähigkeit hat, die Zustände von zwei Threads gleichzeitig aufrechtzuerhalten, sind acht Hardware-Threads im System vorhanden (vier Kerne mit zwei Threads pro Kern).
-
Die CPU 102 kann ebenfalls einen oder mehrere Nicht-L1-Caches, wie beispielsweise den Nicht-L1-Cache 112 aufweisen. Bei vielen Ausführungsformen ist zumindest ein Nicht-L1-Cache, wie beispielsweise der Cache 130 in der CPU 102 außerhalb irgendeines gegebenen Kerns vorhanden. Zusätzlich wird bei vielen Ausführungsformen der Cache 130 von den vier gezeigten Kernen geteilt. Bei anderen Ausführungsformen, die nicht gezeigt sind, sind zusätzliche Nicht-L1-Caches neben dem Cache 130 realisiert. Bei verschiedenen Ausführungsformen kann der Cache 130 auf verschiedene Weise aufgeteilt sein. Zusätzlich kann der Cache 130 bei verschiedenen Ausführungsformen eine von vielen verschiedenen Größen haben. Beispielsweise kann der Cache 130 ein 8-Megabyte-(MB)-Cache, ein 16-MB-Cache etc. sein. Zusätzlich kann bei verschiedenen Ausführungsformen der Cache 130 ein direkt abgebildeter Cache, ein vollassoziativer Cache, ein Mehr-Wege-Satz-Assoziativ-Cache oder ein Cache mit einer anderen Art von Abbildung sein. Bei vielen Ausführungsformen kann der Cache 130 einen großen Teil aufweisen, der zwischen allen Kernen geteilt wird, oder kann in mehrere getrennte funktionale Scheiben unterteilt sein (z. B. eine Scheibe für jeden Kern). Der Cache 130 kann auch einen Teil, der zwischen allen Kernen geteilt wird und mehrere andere Teile aufweisen, die getrennte funktionale Scheiben pro Kern sind.
-
Bei vielen Ausführungsformen umfasst die CPU 102 einen integrierten Systemspeichercontroller 132, um über eine Schnittstelle zur Kommunikation mit dem Systemspeicher 134 zu verfügen. Bei anderen Ausführungsformen, die nicht gezeigt sind, kann sich der Speichercontroller 132 in einer diskreten anderswo im Computersystem 100 befinden.
-
Der Systemspeicher 134 kann einen dynamischer Direktzugriffsspeicher (DRAM), wie beispielsweise einen Typ eines DRAM mit doppelter Datenrate (DDR), einen nichtflüchtigen Speicher, wie beispielsweise einen Flash-Speicher, einen Phasenänderungsspeicher (PCM) oder jeden anderen Typ von Speichertechnologie aufweisen. Der Systemspeicher 134 kann ein Mehrzweckspeicher sein, um Daten und Befehle zu speichern, mit welchen die CPU 102 arbeitet. Zusätzlich kann es andere mögliche Vorrichtungen im Computersystem 100 geben, die dazu geeignet sind, in den Systemspeichern zu lesen und zu schreiben, wie beispielsweise eine zu einem direkten Speicherzugriff (DMA) eingerichtete E/A-(Eingabe/Ausgabe)Vorrichtung.
-
Die Verbindung (d. h. Bus, Interconnect, etc.), die die CPU 102 mit dem Systemspeicher 134 koppelt, kann einen oder mehrere optische, metallische oder andere Drähte (d. h. Leitungen) aufweisen, die dazu geeignet sind, Daten, Adressen, Steuer- und Taktinformationen zu transportieren.
-
Der Platform-Controller-Hub (PCH) 136 (z. B. ein Komplex von E/A-Controllern und anderer Schaltung) umfasst eine E/A-Schnittstelle, die eine Kommunikation zwischen der CPU 102 und externen E/A-Vorrichtungen ermöglicht. Der Komplex kann einen oder mehrere E/A-Adapter umfassen, wie beispielsweise den E/A-Adapter 138. Die E/A-Adapter übersetzen ein Host-Kommunikationsprotokoll, das in der CPU 102 verwendet wird, in ein Protokoll, das mit einer speziellen E/A-Vorrichtung kompatibel ist, wie beispielsweise der E/A-Vorrichtung 140. Einige der Protokolle, die ein gegebener E/A-Adapter übersetzen kann, umfassen unter anderem einen Peripheral-Component-Interconnect(PCI)-Express, Universal Serial Bus (USB), Serial Advanced Technology Attachment (SATA), Small Computer System Interface (SCSI), Redundant Array of Inexpensive Discs (RAID) und 1394 „Firewire”. Zusätzlich können einer oder mehrere drahtlose Protokoll-E/A-Adapter vorhanden sein. Beispiele drahtloser Protokolle sind unter anderem Bluetooth, IEEE 802.11-basierende drahtlose Protokolle und Mobiltelefonprotokolle.
-
Abgesehen von U/O-Geräten kann der PCH 136 auch mit einem oder mehreren eingebetteten Controller (ECs) im System, wie beispielsweise EC 142 gekoppelt sein. Der EC 142 kann eine Reihe von Funktionen enthalten. Beispielsweise kann eine RAID-Speicher-Controller-Vorrichtung im Computersystem 100 vorhanden sein. Der RAID-Controller kann ein Array von Festplattenlaufwerken oder Solid-State-Platten (SSDs) verwalten. Andere Beispiele der Controllervorrichtung können eine diskrete Out-of-Band-Verwaltungsengine, ein Keyboard-Controller oder eine andere Art eines Controllers sein.
-
In anderen Ausführungsformen ist der PCH 136 eine diskrete Vorrichtung, die sich außerhalb der CPU 102 befindet. Bei diesen Ausführungsformen koppelt eine Schnittstelle, wie beispielsweise eine direkte Speicherschnittstelle (DMI) die CPU an den PCH. Jedoch sind diese Ausführungsformen nicht gezeigt.
-
Eine Inter-CPU-Schnittstelle 144 kann eine Schnittstelle zu einem Link bereitstellen, das mit einem oder mehreren zusätzlichen CPUs gekoppelt ist und kann ermöglichen, dass CPU-Kommunikationen stattfinden. Beispielsweise kann eine Hochgeschwindigkeits-Inter-CPU-Schnittstelle ein Quick-Path-Interconnect (QPI) oder eine ähnliche Schnittstelle sein. Obwohl zusätzliche CPUs in 1 nicht gezeigt sind, ist bei vielen Ausführungsformen die CPU 102 eine von mehreren CPUs, die im Computersystem 100 vorhanden sind. Bei vielen Ausführungsformen liefert die Inter-CPU-Schnittstelle 144 eine Hochgeschwindigkeits-Punkt-zu-Punkt-Kommunikationsschnittstelle zwischen der CPU 102 und jeder der anderen im System vorhanden CPUs.
-
Eine Graphikschnittstelle 146 kann eine Schnittstelle zu einem Link liefern, das mit einem diskreten Graphik-Controller gekoppelt ist (ein diskreter Graphik-Controller ist nicht gezeigt). Die Schnittstelle kann eine Hochgeschwindigkeitsplattform-Component-Interconnect(PCI)-Express-Schnittstelle oder eine andere Hochgeschwindigkeitsschnittstelle sein. Bei anderen Ausführungsformen umfasst die CPU 102 einen integrierten Graphik-Controller und die Graphik-Schnittstelle 146 kann mit einer Anzeigevorrichtung gekoppelt sein, wie beispielsweise einem Monitor. Bei vielen Ausführungsformen handelt es sich bei der Schnittstelle um eine Hochgeschwindigkeitsschnittstelle, um die Übertragung eines signifikanten Graphikdatenverkehrs über den Link zu ermöglichen (z. B. 3D-Graphik, Video, etc.).
-
Das Computersystem 100 umfasst auch eine Systemmanagement-Firmware 148, um Boot-Befehle zur Initialisierung des Computersystems und der Komponenten bereitzustellen. Bei verschiedenen Ausführungsformen kann die Systemmanagement-Firmware ein Basic-Eingabe/Ausgabe-System (BIOS), eine erweiterbare Firmware oder eine andere Form von Firmware-Befehlen sein, die das Computersystem während des Bootens der Plattform verwenden kann.
-
Bei vielen Ausführungsformen umfasst jeder Kern im Computersystem 100 eine interne Logik, um den Stromverbrauch des Kerns basierend auf der Klasse und dem Inhalt von Befehlen zu verwalten, die in jedem Kern ausgeführt werden. Eine Vielzahl von Logik in mehreren Einheiten wird dazu verwendet, um bestimmte Einheiten auf einer Takt-um-Taktbasis durch die Taktmanagement/Erzeugungslogik 128 zu Takt-gaten.
-
2 veranschaulicht spezielle relevante Einheiten und funktionale Logikblöcke in einem gegebenen Kern, die dem Kern die Fähigkeit verleihen, den Stromverbrauch des Kerns durch eine Befehlsklassenbestimmung und Befehlsinhaltbestimmung zu verwalten.
-
In einem gegebenen Kern werden Makrobefehle aus dem Befehls-Cache 112 abgerufen und gelangen in einen Prefetch-Puffer 200. Bei vielen Ausführungsformen gibt es zwei Befehlsdekoder (Dekoder 0 (202) und Dekoder 1 (204)). Der Prefetch-Puffer 200 versorgt ein Befehlsregister für jeden Dekoder (Befehl-1-Register (206) und Befehl-2-Register (208). Bei denen in 1 gezeigten Ausführungsformen gibt es zwei in der Befehlsdekodereinheit gezeigte Dekoder, da der Kern dazu geeignet ist, zwei Befehle gleichzeitig zu dekodieren. Zur Vereinfachung ist die detaillierte Schaltung in einem einzelnen Dekoder lediglich im Dekoder 0 gezeigt. Dieselbe Schaltung ist auch im Dekoder 1 vorhanden. Sie ist jedoch nicht dargestellt, da die Schaltung die im Dekoder 0 gezeigte Schaltung spiegelt und daher eine nochmalige Erläuterung der Schaltung überflüssig ist.
-
Abgesehen von dem Prefetch-Puffer 200 gibt es auch eine vordekodier-basierte Logik 210, die Cache-Zeilen aus dem Prefetch-Puffer liest und den Makrobefehl aus der Befehlscache-Zeile trennt und die Länge des Befehls basierend auf den Vordekodier-Bits bestimmt. Für jeden Makrobefehl liefert die Dekodierlogik eine erste Durchgangsnährung der Byte-Größenklasse des Befehls (d. h. ob der Makrobefehl in eine 1-Byte-Mikrooperation (Opcode), einen 2-Byte-Opcode, einen 3-Byte-Opcode dekodiert wird oder in einen komplexeren Satz aus einem oder mehreren Opcodes variierender Länge dekodiert. Die Byte-Klassengröße des Vordekodier-Prozesses ist eine Näherung, da es einige Befehle gibt, bei welchen die Byte-Größe falsch werden kann. Abgesehen von der in 2 gezeigten Logik gibt es einen weiteren parallelen Dekoder (Gesamtlängen-Dekoder 242), der eine Gesamtlängendekodierung ausführt, die vollkommen fehlerfrei ist. Jedoch ist der Gesamtlängendekoder nicht so effizient wie der Vordekodier-Längennährung und wird daher parallel zum durch die in 2 gezeigte Logik ausgeführten Dekodierprozess ausgeführt.
-
Bei vielen Ausführungsformen werden, falls der Gesamtlängendekoder mit einer Opcode-Byte-Länge antwortet, die sich von der durch die Makrobefehldekodierlogik abgeschätzten Länge unterscheidet, die nachfolgenden Befehle nach dem momentanen Befehl invalidiert, da eine fehlerhafte Opcode-Byte-Länge bewirken kann, dass zufällige Abfalldaten weiter abwärts in der Befehlspipeline verwendet werden. Invalidierte Befehle werden wieder durch die Pipeline mit der richtigen Opcode-Byte-Länge gesandt, die durch den Gesamtlängendekoder bestimmt wurde. Obwohl die Invalidierung eines gelegentlichen Opcodes und ein nachfolgender zweiter Durchgang durch die Befehlspipeline die Effektivität der Pipeline vermindert, gewährt die hohe Erfolgsrate der Makrobefehlsdekodierlogik-Byte-Längen-Näherung sogar einen noch höheren Effizienzgewinn, um die Verwendung dieses parallelen dualen Längendekodierprozesses zu rechtfertigen.
-
Zurückkommend auf das Befehl-1-Register 206 tritt der Makrobefehl, der in diesem Register eingeklinkt ist, in den Dekoder 0 (202) ein und wird zu mehreren Logikkomponenten im Dekoder weitergeleitet. Anstelle der Handhabung des Dekodierprozesses jedes Typs eines empfangenen Makrobefehls durch ein großes Programmierlogik-Array (PLA) sind die im Dekoder 0 vorhandenen PLAs in PLAs unterteilt, die Makrobefehl-Dekodieren pro Byte-Länge durchführen. Alle Makrobefehle, die 1-Byte-Opcodes produzieren, werden im 1-Byte-Opcode-PLA 212 dekodiert, alle Makrobefehle, die 2-Byte-Opcodes produzieren, werden im 2-Byte-Opcode-PLA 214 dekodiert und alle Makrobefehle, die 3-Byte-Opcodes produzieren, werden im 3-Byte-Opcode-PLA 216 dekodiert. Zusätzliche dekodiert ein komplexes Befehls-PLA 218 alle anderen Opcodes, die nicht durch eine Dekodierung in den PLAs 212–216 abgedeckt sind. Im Allgemeinen fallen die meisten Makrobefehle in die 1-3-Byte-Opcode-Übersetzungen. Somit wird die komplexe Befehls-PLA 218 nicht so häufig verwendet werden wie die anderen drei PLAs.
-
Bei Dekodern einer früheren Generation war im Allgemeinen ein PLA vorhanden, das dazu in der Lage war, alle Befehle zu dekodieren. Die Schaltungen aller vier PLAs in 2 waren in diese einzige PLA integriert. Somit war unabhängig davon, welche Byte-Größenklasse eines Makrobefehls von der PLA empfangen wurde, die ganze PLA aktiv, um den Makrobefehl in entsprechende Opcode(s) zu dekodieren. Bei der in 2 gezeigten vorliegenden Ausführungsform ist diese Schaltung in vier getrennte PLAs aufgeteilt. Zusätzlich führen alle PLAs aktiv von Zyklus zu Zyklus basierend auf einem empfangenen oszillierenden Taktsignal aus. Dieses oszillierende Taktsignal wird von der Takt-Management- und Erzeugungslogik (CMGL) 220 empfangen. Die CMGL 220 umfasst eine Taktschaltung, um zumindest ein bei zumindest einer Frequenz oszillierendes Taktsignal zu erzeugen. Es können jedoch mehrere Signale bei mehreren Frequenzen verwendet werden, um dem Prozessordesign eine Flexibilität zu verleihen. Bei einigen Ausführungsformen wird mehr als eine Taktgeschwindigkeit verwendet. Einige Einheiten nehmen das Taktsignal bei einer doppelten Frequenz, einer halben Frequenz oder bei irgendeiner anderen eventuell manipulierten Taktsignalfrequenz. Jedoch laufen bei einigen Ausführungsformen die in 2 gezeigten Funktionseinheiten und Logik alle bei derselben Frequenz. Jedenfalls kann die CMGL 220 ein oszillierendes Taktsignal zu jedem/r beliebigen funktionalen Block/Einheit, der/die in 2 gezeigt ist, der/die ein solches benötigt, um korrekt zu laufen, weiterleiten. Zur Verdeutlichung von 2 sind lediglich bestimmte Blöcke/Einheiten mit einem Taktsignal gezeigt, das durch eine vom CMGL 220 abgehende Leitung zugeführt wird, wobei diese speziellen Takt-Quellen- und Zielpaare nachfolgend beschrieben werden.
-
Zusätzlich umfasst die CMGL 220 auch eine Taktverwaltungsschaltung, um die Eignung zur Verfügung zu stellen, die Zuführung des Taktsignals zu jedem beliebigen oder mehreren der funktionalen Blöcke/Einheiten aktiv zu verwalten. Beispielsweise kann die Taktverwaltungsschaltung eine Takt-Gating-Logik aufweisen, um das Taktsignal zu einem Dauer-Hoch-Zustand zu ziehen oder um das Taktsignal in einen Dauer-Niedrig-Zustand herabzudrücken.
-
Wenn einem funktionalen Block/Einheit, der/die einen Takt zum Laufen benötigt, ein eingehendes Taktsignal verweigert wird, hält der Block/die Einheit das Arbeiten an, da die interne Schaltung in einen Dauerzustand gezwungen wird und über keine Schaltaktivität in der Schaltung verfügt (d. h. umschalten/hin- und herschalten basierend auf der Versorgung mit dem Taktsignal). Somit stellt die Logik den Betrieb ein, falls die CMGL 220 ein Taktsignal zu einem Block/einer Einheit einer funktionalen Logik abschaltet. Dadurch wird der Stromverbrauch durch dynamisches Schalten in der Schaltung des Blocks/der Einheit eingespart.
-
Somit kann die CMGL 220 ein Taktsignal, das zu einem/einer bestimmten funktionalen Block/Einheit in 2 zugeführt wird, abschalten oder nicht abschalten. Bei vielen Ausführungsformen sendet die Makrobefehlsdekodierlogik 210 der CMGL 220 die Näherungsinformation über die Byte-Größenklassenlänge, die sie entsprechend einem bestimmten Befehl, der in das Befehls-1-Register 206 eingetreten ist, bestimmt hat. Bei vielen Ausführungsformen kann die genäherte Byte-Größenklassenlänge allgemein 1, 2 oder 3 Bytes sein. Die CMGL 220 hält für den nächsten Taktzyklus das zur PLA zugeführte Taktsignal entsprechend der genäherten Länge bei und zieht den Takt, den sie den beiden anderen PLAs zuführt, die andere Längen dekodieren, in einen Dauerzustand. Für den obengenannten nächsten Taktzyklus ist nur einer der drei speziellen Byte-Längen PLAs in Betrieb. Darüber hinaus sind die beiden anderen speziellen Byte-Längen PLAs nicht in Betrieb und verbrauchen weniger dynamische Leistung, da es in ihren entsprechenden Schaltungen keinen Stromverbrauch durch dynamisches Schalten gibt.
-
Bei einem nächsten Taktzyklus, bei dem ein nachfolgender Befehl im Befehl-1-Register 206 auf das Dekodieren wartet, findet derselbe Prozess statt. Somit verbraucht während eines bestimmten Taktzyklus höchstens eines der 1-, 2- und 3-Byte-Opcode-PLAs eine signifikante Leistung zum dynamischen Schalten. Bei vielen Ausführungsformen empfängt die PLA 218 für komplexe Befehle immer einen zugeführten Takt, da die CMGL über keine Takt-Gating-Eignung für dieses spezielle PLA verfügt.
-
Im Fall eines 1-, 2- oder 3-Byte-Dekodierens wird der Makrobefehl, sobald er durch den relevanten Byte-Längen-PLA hindurchgegangen ist und in den entsprechenden Code dekodiert wurde, durch den MUX 222 gemultiplext. Im Fall eines komplexen Befehls, der ein PLA 218 erfordert, kann das Ergebnis einen Opcode (Opcodes) vom Mikrocode Lese-Nur-Speicher (RAM) 224 produzieren. Der Ausgang des MUX 222 wird dann wieder mit dem Ausgang des PLA 218 und dem Mikrocode ROM 224 durch den MUX 226 gemultiplext. Der Opcode-Ausgang des MUX 226, der den resultierenden Opcode vom Dekoder aufweist, wird dann an der Logik 228 empfangen, die beliebige Versetzungs-Bytes und/oder einen unmittelbaren Operanden, der an den ursprünglichen Makrobefehl im Prefetch-Puffer 200 Feld-angefügt war, empfangen. Sobald die Verschiebungs-Bytes und/oder unmittelbaren Operanden behandelt sind (falls es derartige Feld-angefügt zum ursprünglichen Makrobefehl gibt), wird der Opcode aus dem Dekoder 0 und zur Befehlswarteschlange 230 ausgesandt, um auf die Ausführung zu warten.
-
Bei vielen Ausführungsformen kann die Makrobefehlsdekodierlogik 210 einen gegebenen empfangen Makrobefehl teilweise dekodieren. Die Makrobefehldekodierlogik 210 liefert auch eine Gruppe von Vordekodierbits, die während des Vordekodierprozesses auf einen bestimmten Makrobefehl erzeugt werden. Bei einigen Ausführungsformen kann die Makrobefehlsdekodierlogik 210 dazu geeignet sein, um zu bestimmen, dass basierend auf den Vordekodierbits ein zweiter Befehl, der gleichzeitig im Dekoder 1 dekodiert wurde, ungültig ist. Es gibt viele Beispiele, warm ein zweiter Befehl ungültig sein kann (z. B. ein Verzweigungsaspekt), ungeachtet des Grundes wird jedoch, sobald die Makrobefehlsdekodierlogik 210 realisiert, dass ein zweiter Befehl der in den Dekoder 1 eintritt, ungültig wird, die Makrobefehlsdekodierlogik 210 die CMGL 220 dazu veranlassen, das zum gesamten Dekoder 2 zugeführte Taktsignal zu gaten. Beispielsweise kann die CMGL 220 den Takt zu einem Dauerzustand zum Befehl-2-Register 208 hochziehen, um nicht zuzulassen, dass die Latches im Register den Befehl in den Dekoder 1 freigeben. Bei anderen Ausführungsformen kann die CMGL 220 alle größeren funktionalen Einheiten/Blöcke im Dekoder 2 basierend auf einem Takt-Baum, der in den Dekoder an einer einzelnen Stelle eintritt (nicht in 2 gezeigt) individuell versorgen. Bei diesen Ausführungsformen kann die CMGL 220 den gesamten in den Dekoder eintretenden Baum Takt-gaten. Somit kann die Vordekodier-Logik 210, falls sie feststellt, dass ein Befehl ungültig ist, im Wesentlichen die gesamte Logik im Dekoder abschalten, der dafür geplant war, den Befehl in einen Opcode durch Gaten der zur Dekoderlogik zugeführten Takte zu dekodieren.
-
Wieder zurückkommend zum Dekoder 0 empfängt eine Verzweigungs-, Fließkomma-, Felddetektorlogik (BFFDL) 232 ebenfalls den in den Dekoder 0 vom Instruktion-1-Register 206 fortgeschrittenen Makrobefehl. Die BFFDL 232 umfasst mehrere Teile einer Detektionslogik, um bei der Leistungsverwaltung im Kern zu unterstützen.
-
Wie der Name der Logik nahelegt, gibt es eine getrennte Verzweigungsdetektionslogik, Fließkommadetektionslogik und Felddetektionslogik in der BFFDL 232. Die Verzweigungsdetektionslogik stellt fest, ob der Befehl eine Verzweigungsadressberechnung erfordern wird.
-
Eine Verzweigungsadressberechnungseinheit 234 wird berechnen, was die Verzweigungsadresse für einen Verzweigungsbefehl sein wird. Falls der Makrobefehl keinerlei Form einer Verzweigung umfasst, wird diese Verzweigungsadressberechnungseinheit 234 nicht verwendet, wobei dennoch der zu dieser Einheit zugeführte Takt normalerweise betriebsfähig ist, was wiederum einen unnötigen dynamischen Schaltstromverbrauch hervorruft. Um den Stromverbrauch der Verzweigungsadressberechnungseinheit 234 zu minimieren, erkennt die BFFDL 232, dass ein nächster Befehl, der die Verzweigungsadressberechnungseinheit 234 erreichen würde, kein Verzweigungsbefehl ist. Die BFFDL 232 kann diese Information zur CMGL 220 senden, um zu bewirken, dass die CMGL 220 einen zur Verzweigungsadressberechnungseinheit 234 zugeführten Takt gatet.
-
Die Felddetektionslogik in der BFFDL 232 hat die Fähigkeit zu bestimmen, ob der spezielle Makrobefehl, der aktuell empfangen wurde, Daten in einem Versetzungs-Byte-Feld und/oder Daten in einem unmittelbaren Operandenfeld aufweist. Viele Makrobefehle verwenden diese Felder nicht. Selbst wenn die Felder nicht verwendet werden, besitzt die Logik in der gesamten Pipeline, die Opcodes behandelt, Slots für diese Felder, wobei diese Slots zufällige Abfalldaten darin aufweisen, die zusammen mit dem Opcode weitergegeben werden. Zufällige Abfalldaten bewirken einen Stromverbrauch durch dynamisches Schalten, obwohl die Daten nicht verwendet werden. Somit instruiert die BFFDL 232 bei vielen Ausführungsformen, sobald sie festgestellt hat, dass der Makrobefehl weder einen noch beide dieser Felder verwendet, die Logik 228, die nicht verwendeten Felder zu eliminieren. Dieses Eliminieren der Felder minimiert weiter den Stromverbrauch der Pipeline zwischen funktionalen Einheiten/Blöcken im Kern.
-
Die Fließkommadetektionslogik in der BFFDL 232 detektiert, ob der hereinkommende Makrobefehl eine Fließkomma-(FP)-Operation ist. Bei vielen Ausführungsformen kann eine Fließkommaeinheit 236, die Fließkommaberechnungen behandelt, ähnlich den anderen obigen Takt-gegateten Einheiten Takt-gegated sein, wobei jedoch das Takt-gaten der Fließkommaeinheit komplexer ist, da für das korrekte Funktionieren der Einheit eine Vorlaufzeit erforderlich ist und es unpraktisch ist, die gesamte FP-Einheit 236 pro Takt zu Takt-gaten. Somit wird bei vielen Ausführungsformen die FP-Einheit 236 nur dann ge-Takt-gated, wenn in der gesamten Pipeline keine FP-Operationen vorhanden sind. Die Pipeline, die die FP-Einheit betrifft, umfasst im Allgemeinen ein Beginnen an der Dekoder-Einheit (um den FP-Makrobefehl zu dekodieren) und ein Beenden an der Retirement-Einheit (welche den FP-Befehl rückordnet, nachdem die Ausführung abgeschlossen ist). Somit kann eine State-Machine implementiert werden, um ein Verfolgen eines vollen Satzes von FP-Operationen, die in der Pipeline (zwischen Dekodieren und Rückordnen) vorhanden sind, zu unterstützen.
-
Eine FP-Mikro-Op-Tracker-Einheit 238 kann beliebige in der Pipeline vorhandene FP-Befehle/Opcodes beobachten und die CMGL 220 instruieren, die FP-Einheit 236 zu Taktgaten, falls keine FP-Befehle/Opcodes vorhanden sind. Die BFFDL 232 sendet Informationen an den FP-Mikro-Op-Tracker-Einheit 238, wenn ein FP-Befehl in die Dekodierstufe eintritt. Der FP-Befehl geht dann durch die gesamte Pipeline hindurch und wird eventuell rückgeordnet. Während der Rückordnung informiert die Zuweisungs-Retirement-Einheit 240 die FP-Mikro-Op-Tracker-Einheit 238, dass der FP-Befehl rückgeordnet wurde. Sobald er rückgeordnet ist, kann die FP-Mikro-Op-Tracker-Einheit 238, falls keine weiteren FP-Befehle in den Dekoder eingetreten sind, die CMGL 220 instruieren, die in die FP-Einheit 236 eintretenden Takte abzuschalten.
-
3 beschreibt eine Ausführungsform einer Statusmaschine, die verwendet wird, um Fließkommamikrooperationen durch eine Befehlspipeline zu verfolgen.
-
Der Anfangsstatus zeigt die Pipeline in einem Leerlaufzustand bezüglich Fließkommamikrooperationen (Status 300). Falls keine FP-Mikroperation (μOP) empfangen wird, bleibt die Statusmaschine im Leerlaufzustand, da die Pipeline keine FP μOP dekodiert (Aufgabe A). Falls eine FP μOP ankommt, dekodiert die Pipeline die FP μOP (Aufgabe B) und die Zustandsmaschine geht in den nächsten Zustand über, in dem die μOP die Dekodierstufe beendet hat und sich nun in der Befehlswarteschlange befindet (Zustand 302). Sobald sich eine FP μOP in der Befehlswarteschlange befindet, besteht der einzige Weg, um wieder in den Leerlaufzustand zurückzukehren für die FP μOP darin, rückzuordnen, ohne dass zusätzliche FP μOPs in der Pipeline verbleiben.
-
Sobald sich sie FP μOP in der Befehlswarteschlange befindet (Zustand 302) können zwei Ereignisse auftreten. Zuerst, falls sich die FP μOP immer noch in der Befehlswarteschlange befindet, während eine neue zweite FP μOP im Dekoder ankommt, hält die Zustandsmaschine die Verfolgung der ersten FP μOP an und geht stattdessen zu einer Verfolgung der zweiten FP μOP über, die gerade angekommen ist. Dies erfolgt, da die zweite FP μOP nach der ersten FP μOP rückordnen wird. Die Pipeline führt die Aufgabe des Dekodierens einer weiteren FP μOP (Aufgabe C) durch.
-
Ein weiteres potenzielles Ereignis ist, dass der μOP in der Befehlswarteschlange Ressourcen zugewiesen werden können, die ausgeführt werden sollen (Aufgabe D). In diesem Fall geht die Zustandsmaschine in den μOP-Zuweisungszustand über (Zustand 304).
-
Sobald sie sich im μOP-Zuweisungszustand befindet, können weitere drei Ereignisse auftreten. Zuerst, falls die erste FP μOP in der Zuweisungsstufe (Zustand 304) rückgeordnet werden muss und eine neue zweite FP μOP im Dekoder ankommt, hält die Zustandsmaschine das Verfolgen der ersten FP μOP an und geht stattdessen dazu über, die zweite FP μOP zu verfolgen, die gerade angekommen ist. Dies erfolgt, da die zweite FP μOP nach der ersten FP μOP rückordnen wird. Die Pipeline führt die Aufgabe der Dekodierung einer weiteren FP μOP durch (Aufgabe E). Dies bewirkt, dass die Zustandsmaschine zu der μOP zurückkehrt, die sich im Befehlswarteschlangenzustand befindet (Zustand 302), und die Zustandsmaschine nun die zweite FP μOP verfolgt.
-
Ein zweites Ereignis, das im Zustand 304 erfolgen kann, ist, dass die FP μOP-Zuweisung stattgefunden hat, jedoch die FP μOP-Rückordnung noch nicht erfolgt ist. In diesem Fall findet ein Nicht-Ereignis statt, da die Pipeline die FP μOP nicht rückordnet (Aufgabe F). Das kann während der Ausführung der FP μOP stattfinden.
-
Das dritte Ereignis, das im Zustand 304 erfolgen kann ist, dass die Pipeline die FP μOP rückordnen kann (Aufgabe G). Wenn dieses Ereignis stattfindet, bewegt sich die Zustandsmaschine zum Leerlauf zurück (Zustand 300). An jeden gegebenen Punkt, an dem sich die Zustandsmaschine im Leerlaufzustand befindet, kann der FP μOP-Tracker (238 in 2) der CMGL 220 befehlen, die FP-Einheit 236 zu Takt-gaten.
-
4 ist ein Ablaufdiagramm einer Ausführungsform eines Prozesses zum Takt-gaten eines oder mehrerer programmierbarer Logik-Arrays in einem Dekoder, die nicht dazu konfiguriert sind, einen momentanen Befehl zu dekodieren, der in den Dekoder eintritt.
-
Der Prozess wird durch die Verarbeitungslogik durchgeführt, die Hardware-Schaltungen und/oder Mikrocode in verschiedenen Ausführungsformen aufweisen kann. Der Prozess beginnt, indem die Verarbeitungslogik einen Makrobefehl von einem Prefetch-Puffer abruft (Verarbeitungsblock 400). Der Prozess wird fortgesetzt, indem die Verarbeitungslogik eine Byte-Längenklasse des Makrobefehls bestimmt (Verarbeitungsblock 402). Basierend auf der Bestimmung Takt-gated die Verarbeitungslogik dann eine oder mehrere PLAs im Dekoder, in welcher (welchen) der Makrobefehl dekodiert werden soll (Verarbeitungsblock 404). Das/die spezielle/speziellen PLA(s), die Takt-gegated sind, sind diejenigen, die nicht zum Dekodieren von Makrobefehlen der bestimmten Byte-Längen-Klasse zugewiesen sind. Schließlich dekodiert die Verarbeitungslogik dann den Makrobefehl im Dekoder mit dem verbleibenden PLA, das nicht Takt-gegated wurde (Verarbeitungsblock 406).
-
5 ist ein Ablaufdiagramm einer Ausführungsform eines Prozesses zum Takt-gaten einer Verzweigungseinheit, wenn ein Verzweigungsbefehl nicht dekodiert worden ist.
-
Der Prozess wird durch die Verarbeitungslogik durchgeführt, die Hardware-Schaltungen und/oder Mikrocode in verschiedenen Ausführungsformen aufweisen kann. Der Prozess beginnt, indem die Verarbeitungslogik einen Makrobefehl vom Prefetch-Puffer abruft (Verarbeitungsblock 500). Die Verarbeitungslogik bestimmt dann, ob ein Befehl ein Verzweigungsbefehl ist (Verarbeitungsblock 502). Falls der Befehl ein Verzweigungsbefehl ist, endet der Prozess. Ansonsten, falls der Befehl kein Verzweigungsbefehl ist, Takt-gated die Verarbeitungslogik die Verzweigungseinheit während des Taktzyklus, bei dem sich der Opcode, der vom Makrobefehl erzeugt wurde, an der Verzweigungsberechnungsposition in der Pipeline befindet (Verarbeitungsblock 504) und der Prozess ist beendet.
-
6 ist ein Ablaufdiagramm einer Ausführungsform eines Prozesses zum Takt-gaten einer Fließkommaeinheit, wenn in der Befehlspipeline kein Fließkommabefehl vorhanden ist.
-
Der Prozess wird durch die Verarbeitungslogik durchgeführt, die Hardware-Schaltungen und/oder Mikrocode in verschiedenen Ausführungsformen aufweisen kann. Der Prozess beginnt, indem die Verarbeitungslogik bestimmt, ob es in der Pipeline zwischen der Dekodiereinheit und der Retirement-Einheit irgendeinen FP-Befehl gibt (Verarbeitungsblock 600). Falls es dort irgendwo einen FP-Befehl in der Pipeline gibt, kehrt der Prozess zum Block 600 zurück und es erfolgt eine erneute Überprüfung. Ansonsten, falls es keinen FP-Befehl in der Pipeline gibt, Takt-gated die Verarbeitungslogik die FP-Einheit (Verarbeitungsblock 602) und der Prozess endet. Bei vielen Ausführungsformen verwendet dieser Prozess eine Zustandsmaschine, die in 3 detailliert ist, um das Vorhandensein von FP-Befehlen in der Pipeline zu verfolgen.
-
7 ist ein Ablaufdiagramm einer Ausführungsform eines Prozesses zum Eliminieren der unmittelbaren und Verschiebungs-Byte-Felder eines Befehls, wenn der Befehl diese Felder nicht verwendet.
-
Der Prozess wird durch eine Verarbeitungslogik durchgeführt, die Hardware-Schaltungen und/oder Microcode in verschiedenen Ausführungsformen aufweisen kann. Der Prozess beginnt, indem die Verarbeitungslogik einen Makrobefehl aus dem Prefetch-Puffer abruft (Verarbeitungsblock 700). Die Verarbeitungslogik bestimmt dann, ob der Befehl das Immediate-Feld verwendet (Verarbeitungsblock 702). Falls der Befehl das Immediate-Feld nicht verwendet, eliminiert die Verarbeitungslogik alle Daten im Immediate-Feld des Befehls (Verarbeitungsblock 704). Unabhängig davon, ob der Befehl das Immediate-Feld verwendet, bestimmt der Verarbeitungsblock als nächstes, ob der Befehl das Displacement-Bytes-Feld verwendet (Verarbeitungsblock 706). Falls er das Displacement-Bytes-Feld verwendet, ist der Prozess beendet. Ansonsten, falls der Befehl das Displacement-Bytes-Feld nicht verwendet, eliminiert die Verarbeitungslogik alle Daten im Displacement-Bytes-Feld des Befehls (Verarbeitungsblock 708) und der Prozess endet.
-
Bei vielen Ausführungsformen wird der Takt, wenn das Takt-Gaten auf einen/eine gegebenen/gegebene funktionalen/funktionale Block/Einheit ausgeführt wird, für zumindest einen Taktzyklus zu der Einheit getaktet, obwohl das Takt-Gaten über mehrere als einen Zyklus stattfinden kann, abhängig von dem speziellen Grund zum Takt-Gaten der Einheit. Beispielsweise wird das Takt-Gaten des 1-Byte-PLAs im Allgemeinen auf der Basis eines einzelnen Taktzyklus durchgeführt, da Befehle zum Dekodieren an jedem Taktzyklus hereingebracht werden. Somit kann das PLA für so wenig wie einen Taktzyklus ge-gated werden. In derselben Betrachtung können Tausende Mikrobefehle ohne eine einzelne Fließkommaoperation durch die Pipeline laufen, wobei in diesem Fall die FP-Einheit für viele Taktzyklen nacheinander Takt-gegated werden kann.
-
Elemente der Ausführungsformen der vorliegenden Erfindung können auch als ein maschinenlesbares Medium zum Speichern der maschinenlesbaren Befehle bereitgestellt werden. Das maschinenlesbare Medium kann beispielsweise einen Flash-Speicher, optische Platten, Kompaktplatten-Lese-Nur-Speicher (CD-ROM), digitale bewegliche/Videoplatten (DVD) ROM, Direktzugriffsspeicher (RAM), löschbare programmierbare Lese-Nur-Speicher (EPROM), elektrisch löschbare programmierbare Lese-Nur-Speicher (EEPROM), magnetische oder optische Karten, Ausbreitungsmedien oder andere Arten von maschinenlesbaren Medien, die zum Speichern elektronischer Befehle geeignet sind, aufweisen, ohne darauf beschränkt zu sein.
-
In der oben angegebenen Beschreibung und in den Ansprüchen können die Ausdrücke „umfassen” und „aufweisen” zusammen mit ihren Abwandlungen verwendet werden, und es ist beabsichtigt, dass sie als Synonyme betrachtet werden. Zusätzlich können in der folgenden Beschreibung und in den Ansprüchen die Ausdrücke „gekoppelt” und „verbunden” zusammen mit ihren Abwandlungen verwendet werden. Es ist zu beachten, dass diese Ausdrücke nicht als Synonyme füreinander gedacht sind. Vielmehr kann in bestimmten Ausführungsformen „gekoppelt” dazu verwendet werden, um anzuzeigen, dass sich zwei oder mehr Elemente in einem direkten physikalischen oder elektrischen Kontakt miteinander befinden. „Gekoppelt” kann bedeuten, dass sich zwei oder mehr Elemente in direktem physikalischen oder elektrischen Kontakt befinden. Jedoch kann „gekoppelt” auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander stehen, wobei sie jedoch immer noch zusammenwirken, wechselwirken oder miteinander kommunizieren können.
-
In der obigen Beschreibung wird eine bestimmte Terminologie dazu verwendet, um Ausführungsformen der Erfindung zu beschreiben. Beispielsweise ist der Ausdruck „Logik” für Hardware, Firmware, Software (oder beliebige Kombinationen daraus) repräsentativ, um eine oder mehrere Funktionen auszuführen. Beispielsweise umfassen Beispiele von „Hardware” eine integrierte Schaltung, eine endliche Zustandsmaschine oder sogar eine kombinatorische Logik, ohne darauf beschränkt zu sein. Die integrierte Schaltung kann die Form eines Prozessors, wie beispielsweise eines Mikroprozessors, einer anwendungsspezifischen integrierten Schaltung, eines digitalen Signalprozessors, eines Mikrocontrollers oder dergleichen annehmen.
-
Es ist zu beachten, dass eine Bezugnahme in dieser Beschreibung auf „eine einzelne Ausführungsform” oder „eine Ausführungsform” bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine Charakteristik, die in Verbindung mit der Ausführungsform beschrieben wurde, in zumindest einer Ausführungsform der vorliegenden Erfindung enthalten ist. Daher wird betont und sollte beachtet werden, dass zwei oder mehr Bezugnahmen auf „eine Ausführungsform” oder „eine einzelne Ausführungsform” oder „eine alternative Ausführungsform” an verschiedenen Stellen in dieser Beschreibung nicht notwendigerweise alle dieselbe Ausführungsform betreffen. Darüber hinaus können die jeweiligen Merkmale, Strukturen oder Charakteristiken in einer oder mehreren Ausführungsformen der Erfindung in geeigneter Weise kombiniert werden.
-
Gleichermaßen ist zu beachten, dass in der vorangehenden Beschreibung von Ausführungsformen der Erfindung verschiedene Merkmale manchmal miteinander in einer einzelnen Ausführungsform, Figur oder Beschreibung davon gruppiert sind, um die Beschreibung, die das Verständnis eines oder mehrerer der verschiedenen erfinderischen Aspekte unterstützt, zu rationalisieren. Jedoch ist diese Art der Offenbarung nicht dahingehend zu interpretieren, dass sie die Absicht widerspiegelt, dass der beanspruchte Gegenstand mehr Merkmale erfordert als ausdrücklich in jedem Anspruch genannt sind. Stattdessen liegen die erfinderischen Aspekte, wie durch die folgenden Ansprüche reflektiert ist, in weniger als allen Merkmalen einer vorangehend offenbarten Ausführungsform. Somit werden die der detaillierten Beschreibung folgenden Ansprüche hiermit ausdrücklich in diese detaillierte Beschreibung einbezogen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- IEEE 802.11-basierende [0021]
