DE102016006399A1 - Hardwarevorrichtungen und verfahren zum durchführen von transaktionaler energieverwaltung - Google Patents

Hardwarevorrichtungen und verfahren zum durchführen von transaktionaler energieverwaltung Download PDF

Info

Publication number
DE102016006399A1
DE102016006399A1 DE102016006399.8A DE102016006399A DE102016006399A1 DE 102016006399 A1 DE102016006399 A1 DE 102016006399A1 DE 102016006399 A DE102016006399 A DE 102016006399A DE 102016006399 A1 DE102016006399 A1 DE 102016006399A1
Authority
DE
Germany
Prior art keywords
energy
transaction
power
energy transaction
power management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102016006399.8A
Other languages
English (en)
Inventor
Rajeev D. Muralidhar
Harinarayanan Seshadri
Nivedha Krishnakumar
Youvedeep Singh
Suketu R. Partiwala
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102016006399A1 publication Critical patent/DE102016006399A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3243—Power saving in microcontroller unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3287—Power saving characterised by the action undertaken by switching off individual functional units in the computer system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3296—Power saving characterised by the action undertaken by lowering the supply or operating voltage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/30083—Power or thermal control instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5094—Allocation of resources, e.g. of the central processing unit [CPU] where the allocation takes into account power or heat criteria
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

Es werden Verfahren und Vorrichtungen beschrieben, die transaktionale Energieverwaltung betreffen. In einer Ausführungsform enthält eine Hardwarevorrichtung einen Hardwareprozessor, der einen Kern, eine Vielzahl von Energiedomänen, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne überzugehen, und eine Energietransaktionseinheit aufweist, um einen ersten Energieverwaltungsbefehl als eine erste Energietransaktion und einen zweiten Energieverwaltungsbefehl als eine zweite Energietransaktion für eine nebenläufige Ausführung zuzuweisen, eine Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion durchzuführen, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt, und einen Abbruch der ersten Energietransaktion und eine Festschreibung der zweiten Energietransaktion durchzuführen, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt.

Description

  • TECHNISCHES GEBIET
  • Die Offenbarung betrifft allgemein Elektronik, und insbesondere betrifft eine Ausführungsform der Offenbarung einen Hardware-Prozessor mit einer Energietransaktionseinheit, um transaktionale Energieverwaltung durchzuführen.
  • STAND DER TECHNIK
  • Ein Prozessor oder ein Satz von Prozessoren führt Anweisungen aus einem Anweisungssatz aus, z. B. der Anweisungssatzarchitektur (ISA). Der Anweisungssatz ist der Teil der Computerarchitektur, der mit Programmierung verbunden ist, und enthält im Allgemeinen die nativen Datentypen, Anweisungen, Registerarchitektur, Adressierungsarten, Speicherarchitektur, Interrupt- und Ausnahmebehandlung und externe Eingabe und Ausgabe (E/A).
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Offenbarung wird in den Figuren der beiliegenden Zeichnungen beispielhaft, jedoch nicht einschränkend illustriert, in denen gleiche Referenzen ähnliche Elemente anzeigen und in denen:
  • 1 eine Hardwarevorrichtung nach Ausführungsformen der Offenbarung illustriert.
  • 2 einen integrierten Schaltkreis nach Ausführungsformen der Offenbarung illustriert.
  • 3 einen integrierten Schaltkreis nach Ausführungsformen der Offenbarung illustriert.
  • 4 Energieverwaltungs-Code für ein System ohne Energietransaktionen nach Ausführungsformen der Offenbarung illustriert.
  • 5 Energieverwaltungs-Code für ein System mit Energietransaktionen nach Ausführungsformen der Offenbarung illustriert.
  • 6 ein Zeitsteuerungsschema mit atomaren Energietransaktionen und ohne atomare Energietransaktionen nach Ausführungsformen der Offenbarung illustriert.
  • 7 ein Ablaufdiagramm nach Ausführungsformen der Offenbarung illustriert.
  • 8 ein Ablaufdiagramm nach Ausführungsformen der Offenbarung illustriert.
  • 9A ein Blockdiagramm ist, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline nach Ausführungsformen der Offenbarung illustriert.
  • 9B ein Blockdiagramm ist, das sowohl ein Ausführungsbeispiel eines Kerns mit In-Order-Architektur als auch eines Kerns mit Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungsarchitektur illustriert, die in einem Prozessor nach Ausführungsformen der Offenbarung enthalten sein sollen.
  • 10A ein Blockdiagramm eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung an das chipinterne Verbindungsnetz und mit seinem lokalen Teilsatz des Level-2(L2)-Cache ist, nach Ausführungsformen der Offenbarung.
  • 10B eine erweiterte Ansicht eines Teils des Prozessorkerns in 10A nach Ausführungsformen der Offenbarung ist.
  • 11 ein Blockdiagramm eines Prozessors ist, der nach Ausführungsformen der Offenbarung mehr als einen Kern aufweisen kann, einen integrierten Speichercontroller aufweisen kann und integrierte Grafik aufweisen kann.
  • 12 ein Blockdiagramm eines Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung ist.
  • 13 ein Blockdiagramm eines spezifischeren beispielhaften Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung ist.
  • 14 ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung zeigt.
  • 15 ein Blockdiagramm eines Ein-Chip-Systems (SoC) in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung zeigt.
  • 16 ein Blockdiagramm ist, das die Verwendung eines Softwareanweisungswandlers gegenüberstellt, um binäre Anweisungen in einem Quellanweisungssatz in binäre Anweisungen in einem Zielanweisungssatz nach Ausführungsformen der Offenbarung umzuwandeln.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt. Es ist jedoch klar, dass Ausführungsformen der Offenbarung ohne diese spezifischen Details praktiziert werden können. In anderen Fällen wurden wohlbekannte Schaltkreise, Strukturen und Techniken nicht im Detail gezeigt, um das Verständnis dieser Beschreibung nicht zu verschleiern.
  • Bezugnahmen in der Beschreibung auf „eine Ausführungsform”, „ein Ausführungsbeispiel” usw. zeigen an, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft enthalten kann, aber jede Ausführungsform kann nicht notwendigerweise das bestimmte Merkmal, die bestimmte Struktur oder Eigenschaft enthalten. Darüber hinaus beziehen sich solche Formulierungen nicht notwendigerweise auf die gleiche Ausführungsform. Ferner, wenn ein bestimmtes Merkmal, Struktur oder Eigenschaft in Verbindung mit einer Ausführungsform beschrieben wird, wird vorgebracht, dass es im Wissen von Fachleuten liegt, ein solches Merkmal, eine solche Struktur oder Eigenschaft in Verbindung mit anderen Ausführungsformen zu erwirken, egal, ob es bzw. sie explizit beschrieben wird oder nicht.
  • Ein Prozessor (z. B. Hardwareprozessor) oder ein Satz von Prozessoren führt Anweisungen aus einem Anweisungssatz aus, z. B. der Anweisungssatzarchitektur (ISA). Der Anweisungssatz ist der Teil der Computerarchitektur, der mit Programmierung verbunden ist, und enthält im Allgemeinen die nativen Datentypen, Anweisungen, Registerarchitektur, Adressierungsarten, Speicherarchitektur, Interrupt- und Ausnahmebehandlung und externe Eingabe und Ausgabe (E/A). Es sollte angemerkt werden, dass der Begriff Anweisung hierin eine Makroanweisung, z. B. eine Anweisung, die dem Prozessor zur Ausführung bereitgestellt wird, oder eine Mikroanweisung bezeichnen kann, z. B. eine Anweisung, die vom Decodieren von Makroanweisungen durch eine Decodiereinheit des Prozessors (Decoder) resultiert. Ein Prozessor (der z. B. einen oder mehrere Kerne aufweist, um Anweisungen zu decodieren und/oder auszuführen) kann an Daten operieren, zum Beispiel beim Durchführen von arithmetischen, logischen oder anderen Funktionen.
  • Ein Hardware-Prozessor (z. B. als Teil eines Rechensystems) kann Energie von einer oder mehreren seiner Komponenten (z. B. Kernen und/oder Einrichtungen) zwischen Energiezuständen umschalten, zum Beispiel nach der Spezifikation Advanced Configuration and Power Interface (ACPI). In einer Ausführungsform kann eine Komponente in einem von mehreren Betriebszuständen, einem ungenutzten Zustand oder einem ausgeschalteten Zustand mit Energie versorgt werden. Zum Beispiel kann ein erster Energiezustand eine maximale Energie und Frequenz sein, und ein zweiter Energiezustand kann eine niedrigere Energie und Frequenz sein (z. B., aber nicht ungenutzt). Ein Übergang zwischen Energiezuständen kann mehrere Taktzyklen dauern (z. B. aufgrund mehrerer Anweisungen, die ausgeführt werden, um den Übergang zwischen Energiezuständen zu bewirken), um einen Übergang von einem ersten Zustand in einen zweiten Zustand, z. B. auf Anforderung durchzuführen. Energie kann von einer Batterie oder anderen Energiequelle bereitgestellt werden. Eine Energieverwaltungseinheit kann Energie sparen, indem sie den Prozessor und/oder seine Einrichtungen (z. B. Anzeige, Eingabe-/Ausgabe(E/A)-Anschlüsse usw.) in verschiedene Energiezustände setzt, zum Beispiel einen ungenutzten oder ausgeschalteten Zustand, wenn keine Operationen durchzuführen sind (z. B. keine Anweisungen von einem Kern eines Prozessors auszuführen sind). In bestimmten Ausführungsformen kann eine Energieverwaltungseinheit Energieverbrauch verwalten, indem sie eine Ermittlung und/oder einen Übergang eines Energiezustands durchführt. Zusätzlich oder alternativ kann Energieverwaltung durch ein Betriebssystem (OS) implementiert werden, z. B. über einen Treiber, der zwischen dem OS und der Einrichtung kommuniziert, bei der ein Übergang (z. B. eine Änderung) ihres Energiezustands durchzuführen ist.
  • In bestimmten Ausführungsformen dieser Offenbarung kann die Energieverwaltung einen Prozessor (z. B. Niedrigenergie-Mikrocontroller), der mit Software (z. B. dem OS und/oder Anwendungen) koexistiert. In bestimmten Ausführungsformen dieser Offenbarung (z. B. für Energieeffizienz) kann ein OS die Energiesteuerung innerhalb seiner Domäne dezentralisieren, wobei es z. B. jeder Einrichtungsdomäne überlässt, ihren eigenen Zustand zu steuern. Von einer Perspektive des Energieverwaltungsablaufs kann dies jedoch zu Konkurrenzsituationen und Rennsituationen führen, wenn die Energieverwaltungsbefehle (z. B. Übergangsbefehle) ausgegeben und/oder ausgeführt werden, z. B. von einer Energieverwaltungseinheit. Dies kann adressiert werden, indem eine Sperre bzw. Sperren genommen wird bzw. werden (z. B. unter Verwendung von Semaphoren oder anderen Mitteln), um zum Beispiel eine Energieübergangsanforderung zu blockieren oder zu widerrufen, während ein anderer Energieübergang (z. B. Prozess) stattfindet. Dies kann Energieineffizienz verursachen, zum Beispiel, wenn eine Sperre für einen gesamten Energieübergang aufrechterhalten wird (z. B. entweder Steuerung auf Einrichtungsebene, oder Satz von Einrichtungen oder für die Plattform). Bestimmte Ausführungsformen dieser Offenbarung können eine skalierbare Energieverwaltung bereitstellen, z. B. ohne Verwenden einer Sperre. Bestimmte Ausführungsformen dieser Offenbarung können eine Energieverwaltung ohne Verwenden von groben Sperren oder Synchronisation bereitstellen, zum Beispiel im OS oder mit einer Energieverwaltungseinheit (z. B. einem Energieverwaltungscontroller (PMC) oder einer Speichercontrollereinheit (SCU) eines Prozessors) oder einer Kombination von beidem. Bestimmte Ausführungsformen dieser Offenbarung können Energieverwaltung bereitstellen, ohne eine (beispielsweise grobe oder auf hoher Ebene) Sperre durch das OS einzusetzen, wobei nur ein Energieübergang (z. B. eine Anforderung) gleichzeitig an die Hardware gesendet werden darf.
  • Bestimmte Ausführungsformen dieser Offenbarung enthalten Energieverwaltungsvorrichtungen (z. B. Prozessor(en) und/oder Ein-Chip-System(e) (SoC)) und Verfahren, um eine transaktionale Energieverwaltung durchzuführen. Zum Beispiel kann jeder Energiezustandsübergang (z. B. einer Einrichtung, Komponente und/oder einer Energiedomäne) als eine Transaktion repräsentiert werden. In einer Ausführungsform kann ein Energiezustandsübergang (z. B. von einem Zustand in einen anderen Zustand) durch Empfang eines Energieverwaltungsbefehls angefordert werden, der zum Beispiel an einen Steuereingang einer Energieverwaltungseinheit (z. B. einen Eingang für jede Energiedomäne) gesandt wurde. Bestimmte Ausführungsformen dieser Offenbarung enthalten Energieverwaltungsvorrichtungen und -verfahren, um Energieverwaltungsbefehle zu parallelisieren. Bestimmte Ausführungsformen dieser Offenbarung enthalten transaktionale Speichervorrichtungen und -verfahren (z. B. transaktionale Speicherverwaltungsvorrichtungen und -verfahren), um eine transaktionale Energieverwaltung durchzuführen. Die Energieverwaltung nach dieser Offenbarung kann Energieverwaltungs-Hardware, -Software, -Firmware oder eine beliebige Kombination daraus enthalten.
  • In einer Ausführungsform wird eine Transaktion nach einer oder allen oder einer beliebigen Kombination der folgenden Eigenschaften garantiert: Atomarität, Konsistenz, Isolation und Dauerhaftigkeit (AKID). Atomarität (d. h. Atomarsein) kann im Allgemeinen bezeichnen, dass eine Transaktion „alles oder nichts” ist. Wenn zum Beispiel ein Teil der Transaktion fehlschlägt, dann schlägt die gesamte Transaktion fehl und die Daten, auf die sie ausgeübt wurde, bleiben unverändert. Ein atomares System kann Atomarität in allen Situationen garantieren, die z. B. Stromausfälle, Fehler und Abstürze enthalten. Außerhalb der Transaktion scheint eine festgeschriebene Transaktion (z. B. durch ihre Auswirkungen auf die Daten, auf die sie ausgeübt wird) unsichtbar („atomar”) und eine abgebrochene Transaktion (z. B. eine nicht festgeschriebene) scheint nicht stattgefunden zu haben. Konsistenz kann im Allgemeinen eine beliebige Transaktion bezeichnen, die die Daten von einem gültigen Zustand in einen anderen bringen soll. Zum Beispiel sollen beliebige geschriebene Daten nach allen definierten Regeln gültig sein, die zum Beispiel Bedingungen, Kaskaden, Trigger und beliebige Kombinationen davon enthalten. Dies kann die Richtigkeit der Transaktion nicht auf alle Weisen garantieren, z. B. kann dies die Verantwortung von Code auf Anwendungsebene sein, aber es kann garantieren, dass alle Programmierfehler nicht in der Verletzung von irgendwelchen definierten Regeln resultieren. Isolation kann im Allgemeinen eine nebenläufige Ausführung von Transaktionen (z. B. Threads) bezeichnen, die in einem gleichen Systemzustand resultieren, der erhalten worden wäre, wenn diese Transaktionen seriell, z. B. eine nach der anderen, ausgeführt worden wären. Eine Nebenläufigkeitssteuerung kann Isolation bereitstellen. Zum Beispiel, abhängig vom Nebenläufigkeitssteuerungsverfahren, können die Auswirkungen einer unvollständigen Transaktion für (eine) andere Transaktion(en) nicht sichtbar sein. Dauerhaftigkeit kann im Allgemeinen bezeichnen, dass eine Transaktion, sobald sie festgeschrieben wurde, so bleiben soll, z. B. auch im Falle eines Stromausfalls, von Abstürzen oder von Fehlern. Zum Beispiel können Transaktionen (oder ihre Auswirkungen), um vor Stromausfällen zu schützen, in einem nichtflüchtigen (z. B. persistenten) Speicher aufgezeichnet werden.
  • Bestimmte Ausführungsformen dieser Offenbarung enthalten Energieverwaltungsvorrichtungen und -verfahren, um einen Energiezustandsübergang bzw. Energiezustandsübergänge als eine Transaktion bzw. Transaktionen zu repräsentieren. Dies kann eine semantisch genaue Ansicht (z. B. Mehrprozessoransicht) der Energiezustände von Einrichtungen (z. B. eines Prozessors, eines Ein-Chip-Systems (SoC) und/oder einer Plattform) erlauben. Zusätzlich kann eine Repräsentation eines Energiezustandsübergangs als eine Energietransaktion eine geordnetere, semantisch genaue Art und Weise erlauben, einen Energieverwaltungsübergang zu modellieren, spezifizieren und zu prüfen. In bestimmten Ausführungsformen kann ein Implementieren von Energieverwaltungsübergängen als transaktionale Speichersequenzen eine semantisch genaue Mehrprozessor-Ansicht der Energiezustände von Einrichtungen, SoCs und/oder Plattformen. Zusätzlich kann eine Repräsentation von Energiezustandsübergängen als Transaktionen eine geordnetere, semantisch genaue Art und Weise erlauben, Energieübergange (z. B. Verwaltungsübergänge) zu modellieren, spezifizieren und zu prüfen. In bestimmten Ausführungsformen kann eine Repräsentation von Energieübergängen als Transaktionen ein leistungsstarker Weg sein, Energiesequenzen in Hardware, Firmware und Software zu spezifizieren, wobei die semantisch kohärenten Repräsentationen bei der Energieverwaltungsprüfung von Einrichtungen, SoCs und/oder Plattformen helfen.
  • In einer Ausführungsform können Energieverwaltungsvorrichtungen und -verfahren einen Codebereich (z. B. einen Thread oder Threads) als eine (z. B. einzelne) Transaktion deklarieren. Eine Transaktion kann ausgeführt werden und atomar alle Ergebnisse im Speicher festschreiben (z. B. wenn die Transaktion erfolgreich ist) oder abbrechen und alle Ergebnisse widerrufen (z. B. wenn die Transaktion fehlschlägt). Eine Transaktion kann beispielsweise nach den oben besprochenen Eigenschaften Atomarität, Konsistenz, Isolation und Dauerhaftigkeit (AKID) durchgeführt werden. Transaktionen können sicher parallel ausgeführt werden, zum Beispiel, um Techniken wie Sperren und Semaphoren zu ersetzen. Bestimmte Ausführungsformen können auch einen Leistungsvorteil enthalten, zum Beispiel, da Sperren pessimistisch sein können und annehmen können, dass der sperrende Thread in Daten schreiben wird und daher der Fortschritt von anderen Threads blockiert werden kann. In einer Ausführungsform hierin ohne Sperren können zwei Transaktionen, die beide auf eine gemeinsam benutzte Ressource zugreifen (z. B. eine gleiche Speicheradresse oder ein gleiches Register) parallel fortschreiten, und ein Zurückrollen (z. B. ein Abbruch einer oder beider der Transaktionen) kann nur auftreten, wenn eine der Transaktionen auf die gemeinsam benutzte Ressource schreibt (z. B. ein widersprüchliches Schreiben).
  • Energieverwaltungsvorrichtungen und -verfahren können eine Vielzahl von Anforderungen (z. B. von Hardware, einem OS oder einem Treiber) nach Energiezustandsübergängen empfangen (z. B. die anzeigen, in welche Einrichtung oder Domäne und/oder in welchen neuen Energiepegel übergegangen werden soll). In einer Ausführungsform kann ein Energiezustandsübergang von einem Energieverwaltungsbefehl angefordert werden (z. B. einem Thread von Anweisungen, die auf einem Prozessor auszuführen sind, um den Übergang zu erreichen). In einer Ausführungsform kann ein Energieverwaltungsbefehl von einem Anforderer (z. B. einem OS) an eine Einrichtung (z. B. einen Steuereingang) gesandt werden, bei der ein Übergang bewerkstelligt werden soll. Ein Energiezustandsübergang kann als eine Transaktion deklariert werden, zum Beispiel als ein Energieverwaltungsbefehl (z. B. Thread), der als eine Energietransaktion zugewiesen wird. Als solcher kann der Energiezustandsübergang (z. B. die Operationen, die einen Energiezustandsübergang bewirken sollen) so als eine (z. B. einzige) Energietransaktion behandelt werden, dass die Energieverwaltungsvorrichtungen und -verfahren beim Manipulieren (z. B. Ändern von Energiezuständen) der Datenstrukturen (die z. B. in einem Speicher, in Registern, Dateneingaben usw. gehalten werden) keine Sperren ausgeben, die den Energiezustandsübergang steuern und/oder Teil von diesem sind. In einer Ausführungsform enthält eine Energiezustandstransaktion ein Starten einer bzw. von Zustandsübergangsoperation(en) vor einem Versuchen von Modifikationen an den Datenstrukturen, ein Durchführen ihrer Änderungen an einer Kopie (z. B. einer Referenzversion) der Datenstrukturen (z. B. in einem Cache) und, wenn die Operationen abgeschlossen sind, ein Festschreiben der Transaktion, wenn keine Konflikte aufgetreten sind. Während der Transaktion kann die Energietransaktionseinheit (z. B. ein Energietransaktionssystem) alle Datenstrukturen nachverfolgen (z. B. protokollieren), bei denen diese Operationen einen Lese- und/oder Schreibvorgang durchgeführt haben. Bevor die Energietransaktion festgeschrieben wird, kann die Energietransaktionseinheit prüfen, dass keine anderen Transaktionen (z. B. ihre Operationen) Änderungen an den von der Transaktion verwendeten Datenstrukturen durchgeführt hat. Wenn es keine Änderungen gab, kann die Transaktion festgeschrieben werden. Wenn es Änderungen gab, kann die Transaktion abgebrochen werden, z. B. sodass alle ihre Änderungen widerrufen werden. In einer Ausführungsform kann die abgebrochene Transaktion (z. B. ihre Operation(en)) erneut versucht werden, zum Beispiel, unter einer anderen Strategie (z. B. unter Verwendung einer Sperre bzw. von Sperren) oder widerrufen werden. Deshalb können Energiezustandsübergangsversuche für mehrere Einrichtungen parallel als Energiezustandstransaktionen auftreten. In einer Ausführungsform enthält eine Einrichtung und/oder Domäne ein Energieverwaltungsregister, um einen Energiezustandsübergang bei Empfang eines Schreibvorgangs eines Energieverwaltungsbefehls in das Register zu bewirken, zum Beispiel kann ein Energieverwaltungsbefehl ein Bit oder Bits sein, das bzw. die einen neuen Energiezustand für die Einrichtung anzeigt bzw. anzeigen. In einer Ausführungsform fordert Software (z. B. ein OS) einen Energiezustandsübergang an, zum Beispiel kann sie nach Erkennen, dass eine Einrichtung (und/oder Energiedomäne) nicht verwendet wird, anzeigen, diese Einrichtung ungenutzt zu lassen oder sie auszuschalten. Eine Einrichtung kann eine Komponente bzw. Komponenten (z. B. ein Peripheriegerät) enthalten, die zu einem Prozessor extern, z. B. nicht mit dem Prozessor chipintern ist bzw. sind. Mehrere Einrichtungen können gemeinsam genutzte Ressourcen enthalten, wobei diese Einrichtungen zum Beispiel vom gleichen Taktgeber gesteuert werden oder in der gleichen Energiedomäne sind (z. B. von der gleichen Stromschiene einer Energieversorgung mit Energie versorgt). Das OS kann anzeigen oder erkennen, welche Energiedomäne(en) verwendet wird bzw. werden, um einen Energieverwaltungsbefehl (z. B. Thread) auszuführen. Zum Beispiel kann ein Energietransaktionshinweis (z. B. auf 5 unten Bezug nehmend, „atomar”) im Code enthalten sein, um dem OS oder der Hardware anzuzeigen, dass ein Energieverwaltungsbefehl (um z. B. einen Energiezustandsübergang anzufordern) als eine Transaktion zu behandeln ist.
  • Als ein Beispiel können eine erste Einrichtung (z. B. ein USB-Hub) und eine zweite Einrichtung (z. B. ein Netzwerkadapter) jeweils in einem aktiven Energiezustand sein und Energieverwaltungsbefehle können gesendet werden (z. B. von ihren jeweiligen Treibern), um einen Übergang jeder in einen ungenutzten oder ausgeschalteten Energiezustand zu bewerkstelligen. Der erste Energieverwaltungsbefehl (z. B. für den USB-Hub) und der zweite Energieverwaltungsbefehl (z. B. für den Netzwerkadapter) können z. B. von einem OS gesandt und von einer Energietransaktionseinheit eines Prozessors oder SoC empfangen werden. Die Energietransaktionseinheit kann erkennen, dass die angeforderten Energiezustandsübergänge für jeden Energieverwaltungsbefehl Energietransaktionen sein sollen, z. B. nach den Eigenschaften Atomarität, Konsistenz, Isolation und/oder Dauerhaftigkeit (AKID). Die Energietransaktionseinheit (z. B. in Hardware, Software, Firmware oder Kombinationen davon) kann die nebenläufige (z. B. parallele) Ausführung der Energiezustandsübergänge erlauben, zum Beispiel, aber diese noch nicht festschreiben. Dies kann auftreten, auch wenn diese Einrichtungen von einer gemeinsam genutzten Ressource mit Energie versorgt werden. Alle Lese- und/oder Schreibvorgänge (z. B. an den Steuereingang bzw. die Steuereingänge und/oder -ausgang bzw. -ausgänge) die zum Beispiel durch den ersten Energiebefehl (z. B. Thread) und den zweiten Energiebefehl (z. B. Thread) auftreten, können nachverfolgt werden. In einer Ausführungsform, wenn es keine (z. B. widersprüchliche) Änderungen der ersten Energietransaktion und der zweiten Energietransaktion gab, können sie dann festgeschrieben werden (z. B. die Einrichtungen in den ungenutzten oder ausgeschalteten Energiezustand versetzt werden). Wenn es widersprüchliche Änderungen gab, z. B. eine Einrichtung soll ungenutzt und die andere Einrichtung im ausgeschalteten Zustand sein, wobei beide Einrichtungen eine gemeinsame Energieressource (z. B. Domäne) gemeinsam nutzen, die beide beeinflusst, dann können eine oder beide der Transaktionen abgebrochen werden, zum Beispiel nach einer Konfliktlösungsstrategie. Ein Beispiel einer Konfliktlösungsstrategie ist, dass die erste Transaktion, die in eine Ressource schreibt, festgeschrieben wird, und die zweite Transaktion abgebrochen wird. Ein anderes Beispiel einer Konfliktlösungsstrategie ist, dass die Transaktion mit dem höchsten Energiezustand festzuschreiben ist und die Transaktion des geringeren Energiezustands abgebrochen wird. Andere Konfliktlosungsstrategien können enthalten sein, zum Beispiel, aber nicht darauf beschränkt, ein erneutes Versuchen (z. B. Verzögern) einer abgebrochenen Transaktion, z. B. nachdem die andere Transaktion festgeschrieben wurde. In einer Ausführungsform kann jede Energietransaktion (z. B. für einen jeweiligen Thread) fortschreiten, bis ein Konflikt zwischen den nebenläufig ausführenden Threads erkannt wird. Bestimmte Ausführungsformen hierin erlauben keine Sperre gegen ein nebenläufiges Durchführen (z. B. ohne ein Festschreiben) von einer Vielzahl von Energieübergängen.
  • Es ist zu beachten, dass die Figuren hierin die Energieversorgung (z. B. Batterie oder Nicht-Batterie) oder Energieversorgungsverbindungen nicht zeigen. Fachleuten wird klar sein, dass dies erfolgt, um bestimmte Details in den Figuren nicht zu verdecken. Es ist zu beachten, dass ein Pfeil mit zwei Köpfen hierin keine Zweiwege-Kommunikation erfordern kann, zum Beispiel kann er Einweg-Kommunikation anzeigen (z. B. zu oder von dieser Komponente oder Einrichtung). Beliebige oder alle Kombinationen von Kommunikationspfaden können in Ausführungsformen hierin eingesetzt werden.
  • 1 illustriert eine Hardwarevorrichtung 100 nach Ausführungsformen der Offenbarung. In einer Ausführungsform kann die Hardwarevorrichtung 100 ein SoC sein. Die gezeigte Hardwarevorrichtung 100 enthält einen Hardwareprozessor 102. Obwohl bestimmte Komponenten eines Hardwareprozessors gezeigt werden, können zum Beispiel ein Cache mit mehreren Levels und mehrere Kerne, ein anderer Prozessor bzw. andere Prozessoren, z. B. die hierin besprochenen, eingesetzt werden, ohne vom Geist dieser Offenbarung abzuweichen. Der gezeigte Kern A (102A) enthält einen Level-1-Anweisungscache (L1I) 104A, einen Level-1-Datencache 106A und einen Level-2-Cache (L2) 108A. Der gezeigte Kern B (102B) enthält einen Level-1-Anweisungscache (L1I) 104B, einen Level-1-Datencache (L1D) 106B und einen Level-2-Cache (L2) 108B. Der gezeigte Kern C (102C) enthält einen Level-1-Anweisungscache (L1I) 104C, einen Level-1-Datencache (L1D) 106C und einen Level-2-Cache (L2) 108C. Der gezeigte Kern D (102D) enthält einen Level-1-Anweisungscache (L1I) 104D, einen Level-1-Datencache (L1D) 106D und einen Level-2-Cache (L2) 108D. Die gezeigten Hardwarekerne A und B enthalten einen gemeinsam genutzten Level-3-Cache (L3) 110. Die gezeigten Hardwarekerne C und D enthalten einen gemeinsam genutzten Level-3-Cache (L3) 112. Der gezeigte Prozessor 102 enthält einen gemeinsam genutzten Level-4-Cache (L4) 114. Obwohl vier Kerne gezeigt werden, kann ein einziger Kern oder eine beliebige Vielzahl von Prozessorkernen eingesetzt werden. Obwohl ein Cache mit vier Levels gezeigt wird, kann ein Cache mit einem Level oder ein Cache mit einer beliebigen Vielzahl von Levels eingesetzt werden.
  • In einer Ausführungsform weist jeder Kern seine eigene Energiedomäne auf. In einer Ausführungsform weisen mehrere Kerne (z. B. Kern A und Kern B) eine gemeinsam genutzte Energiedomäne auf. In einer Ausführungsform kann ein gesamter Cache seine eigene Energiedomäne aufweisen. Zum Beispiel kann ein Energieübergang für den L3-Cache 110 einen Energieübergang für bestimmte oder alle der anderen Caches bewirken.
  • Eine Cache-Kohärenz-Einheit kann zum Beispiel als Teil eines Cache nach einem Cache-Kohärenzprotokoll eingesetzt werden, z. B. das Modified-Exclusive-Shared-Invalid(MESI)-Protokoll mit vier Zuständen, modifiziert (M), exklusiv (E), gemeinsam genutzt (S) und ungültig (I), oder das MESIF-Protokoll mit fünf Zuständen, modifiziert (M), exklusiv (E), gemeinsam genutzt (S), ungültig (I) und vorwärts (F).
  • Beliebige oder alle Kombinationen von Kommunikationspfaden können in Ausführungsformen hierin eingesetzt werden. Der Prozessor 102, z. B. ein Kern davon, kann beispielsweise mit anderen Einrichtungen zum Beispiel über ein Netzwerk kommunizieren (als ein Ringnetzwerk 116 gezeigt).
  • Eine Transaktionseinheit (z. B. Energietransaktionseinheit) bzw. Transaktionseinheiten (z. B. Energietransaktionseinheiten) kann bzw. können nach bestimmten Ausführungsformen dieser Offenbarung enthalten sein. Jeder Kern kann eine Transaktionseinheit (z. B. Energietransaktionseinheit) enthalten, zum Beispiel die Transaktionseinheiten (Energietransaktionseinheiten) 120A, 120B, 120C und 120D in ihren jeweiligen Kernen. Zusätzlich oder alternativ kann ein Prozessor oder SoC eine separate Transaktionseinheit (z. B. Energietransaktionseinheit) enthalten. Die gezeigte Hardwarevorrichtung enthält eine Energietransaktionseinheit 120, z. B. zum Speichern von Logik, um die Offenbarung hierin durchzuführen. Obwohl bestimmte andere Komponenten gezeigt werden, sind diese Beispiele, und andere Komponenten können eingesetzt werden und/oder bestimmte der gezeigten Komponenten können in einer Hardwarevorrichtung nicht vorhanden sein. Die gezeigten Komponenten enthalten eine Grafikeinheit 124 (die z. B. ein Grafikprozessor sein kann), die Anzeigesignale an Anzeige 126 senden kann, einen Speicher 128 (z. B. eine Datenspeichereinrichtung, die chipintern oder chipextern sein kann), einen Universal Asynchronous Receiver Transmitter (UART) 130, ein Teilsystem mit niedrigerer Energie (LPSS) 132 und einen Universal Serial Bus (USB) 134. Die Grafikeinheit 124 kann ein Teil des Hardwareprozessors 102 sein.
  • Eine Energieverwaltungseinheit 122 kann enthalten sein, z. B., um den Energiefluss zu den Einrichtungen zu verwalten. Eine Energietransaktionseinheit kann in einer Energieverwaltungseinheit enthalten sein. In einer Ausführungsform kann jede Einrichtung (z. B. Komponente davon) ihre eigene Energiedomäne enthalten. In einer Ausführungsform können mehrere Einrichtungen oder Komponenten einer Einrichtung bzw. von Einrichtungen eine einzige Energiedomäne gemeinsam nutzen.
  • Als ein Beispiel können eine erste Einrichtung (z. B. der USB 134) und eine zweite Einrichtung (z. B. der UART 130) jeweils in einem aktiven Energiezustand sein und Energieverwaltungsbefehle können gesendet werden (z. B. von ihren jeweiligen Treibern), um einen Übergang jeder in einen ausgeschalteten (oder ungenutzten) Energiezustand zu bewerkstelligen. Der erste Energieverwaltungsbefehl (z. B. für den USB 134) und der zweite Energieverwaltungsbefehl (z. B. für den UART 130) können z. B. von einem OS gesandt und von einer Energietransaktionseinheit (z. B. der Transaktionseinheit 120) empfangen werden. Die Energietransaktionseinheit kann erkennen (z. B. aus einer Anzeige vom OS), dass die angeforderten Energiezustandsübergänge für jeden Energieverwaltungsbefehl Energietransaktionen sein sollen, z. B. nach den Eigenschaften Atomarität, Konsistenz, Isolation und/oder Dauerhaftigkeit (AKID). Die Energietransaktionseinheit (z. B. in Hardware, Software, Firmware oder Kombinationen davon) kann die nebenläufige (z. B. parallele) Ausführung der Energiezustandsübergänge erlauben, zum Beispiel, aber diese noch nicht festschreiben. Dies kann eintreten, auch wenn diese Einrichtungen durch eine gemeinsam genutzte Ressource (z. B. als Mitglieder der gleichen Energiedomäne) mit Energie versorgt werden. Alle Lese- und/oder Schreibvorgänge (z. B. an den Steuereingang bzw. die Steuereingänge und/oder -ausgang bzw. -ausgänge) die zum Beispiel durch den ersten Energiebefehl (z. B. Thread) und den zweiten Energiebefehl (z. B. Thread) auftreten, können nachverfolgt werden. Eine Kopie der zu modifizierenden Daten kann gemacht werden (z. B. eine Referenzversion) und kann in einem Cache (z. B. einem Cache eines Prozessors oder einem separaten Cache der Transaktionseinheit 120) gespeichert werden. In einer Ausführungsform, wenn es keine Konflikte (z. B. widersprüchliche Änderungen) der ersten Energietransaktion und der zweiten Energietransaktion gab, können sie dann festgeschrieben werden (z. B. die Einrichtungen USB 134 und UART 130 in den ausgeschalteten (oder ungenutzten) Energiezustand versetzt werden). Wenn es Konflikte (z. B. widersprüchliche Änderungen) gab, z. B. eine Einrichtung soll ungenutzt und die andere Einrichtung im ausgeschalteten Zustand sein, wobei beide Einrichtungen eine gemeinsame Energieressource (z. B. Domäne) gemeinsam nutzen, die beide beeinflusst, dann können eine oder beide der Transaktionen abgebrochen werden, zum Beispiel nach einer Konfliktlösungsstrategie.
  • In einer anderen Ausführungsform kann eine einzelne Einrichtung aufweisen, dass ihr Energieübergang als eine Energietransaktion deklariert wird. Zum Beispiel kann eine Einrichtung (z. B. der USB 134) im Prozess eines Energiezustandsübergangs (z. B. in einen ausgeschalteten oder ungenutzten von einem aktiven Zustand) einen Interrupt empfangen (z. B. dass ein Peripheriegerät in den USB 134 eingesteckt wurde). Die Energietransaktionseinheit kann dies erkennen und dann den im Gang befindlichen Energiezustandsübergang abbrechen und z. B. stattdessen in den aktiven Zustand zurückkehren.
  • Nun zu 2 und 3 gewandt, 2 wird verwendet, um eine Ausführungsform zu beschreiben, in der ein integrierter Schaltkreis (z. B. Prozessorkerne davon) keine Unterstützung für Hardware-Speichertransaktionen (z. B. transaktionalen Speicher) enthält, und 3 wird verwendet, um eine Ausführungsform zu beschreiben, in der ein integrierter Schaltkreis (z. B. Prozessorkerne davon) Unterstützung für Hardware-Speichertransaktionen (z. B. transaktionalen Speicher) enthält.
  • 2 illustriert einen integrierten Schaltkreis 200 nach Ausführungsformen der Offenbarung. Prozessorkerne 0–N sind jeweils als einen (z. B. privaten) Anweisungscache (IC) und einen (z. B. privaten) Datencache (DC) enthalten. Ferner kann der integrierte Schaltkreis einen Cache-Kohärenz-Controller 236 enthalten, um (z. B. globale) Cache-Kohärenz in den Caches (z. B. Datencaches) aufrechtzuerhalten. Obwohl bestimmte Einrichtungen und Komponenten in 2 gezeigt werden, sind diese optional. Zum Beispiel, obwohl eine Energiedomäne „Nordblock” und eine Energiedomäne „Südblock” gezeigt werden, können beliebige Energiedomänen verwendet werden. Bus 216 kann für Kommunikationen verwendet werden.
  • Cache-Kohärenz-Controller 236 und andere besprochene Modifikationen können transaktionales Energiemanagement erlauben. Der integrierte Schaltkreis 200 (z. B. ein SoC) enthält Energieverwaltungseinheit (PUNIT) 240 und Energieverwaltungscontroller (PMC) 242, die zum Beispiel jeweils oder beide diskrete Prozessorkerne sein können. Der PMC 242 kann die Energie zu einer Domäne (z. B. dem Südblock) steuern, zum Beispiel als Antwort auf einen Energieverwaltungsbefehl von der PUNIT 240.
  • Eine Hardware-Energietransaktion kann zum Beispiel folgendermaßen implementiert werden, in einem System, das Hardware-Speichertransaktionen (z. B. transaktionalen Speicher) nicht unterstützt. Ein Transaktionsfeld (z. B. ein Bit) kann für jeden Cache-Eintrag (z. B. eine Cache-Zeile) im Cache-System enthalten sein. Eine Datenstruktur (z. B. für jeweils PUNIT und PMC) kann enthalten sein, um den Transaktionsverlauf und/oder etwaige Konflikte nachzuverfolgen. Auf die Datenstruktur kann zugegriffen werden, um zu prüfen (z. B. zu ermitteln), ob ein Element (z. B. eine Einrichtung) ein Mitglied eines Satzes (z. B. einer gemeinsam genutzten Energiedomäne oder anderen gemeinsam genutzten Ressource) ist. In der gezeigten Ausführungsform ist die Datenstruktur ein Bloom-Filter 240A für die PUNIT 240 und ein Bloom-Filter 242A für den PMC 242. Ein Bloom-Filter kann eine (z. B. platzoptimierte) probabilistische Datenstruktur sein, die verwendet wird, um zu prüfen (z. B. zu ermitteln), ob ein Element (z. B. eine Einrichtung) ein Mitglied eines Satzes (z. B. einer gemeinsam genutzten Energiedomäne oder anderen gemeinsam genutzten Ressource) ist. In einer Ausführungsform kann eine falsche positive Übereinstimmung möglich sein, aber keine falsche negative, zum Beispiel, eine Abfrage hiervon für ein Element, die entweder „Element möglicherweise im Satz” oder „Element sicher nicht im Satz” zurückgibt. Die PUNIT und der PMC können die Datenstruktur (z. B. Bloom-Filter) einsetzen, um Unterstützung für eine Konfliktauflösung und für eine Anordnung von Festschreibvorgängen zu bieten. Auf die Datenstruktur (z. B. der Bloom-Filter) kann als (z. B. speicherabgebildete) Register (z. B. die Register 244 und 246) zugegriffen werden. Auf Energieverwaltungsregister (nicht gezeigt) der PUNIT und des PMC kann zugegriffen werden, um einen Energieübergang zu bewirken. Die Datenstruktur (z. B. die Register 244 und 246) kann in Software exponiert werden, z. B. über eine Transaktions-Anwendungsprogrammierschnittstelle (API), die zum Beispiel von Software zu verwenden ist, um Transaktionsgrenzen zu definieren, um zu konfigurieren, wie Konflikte (und etwaige erneute Versuche) zu handhaben sind, usw. Bestimmte Ausführungsformen hierin können deshalb eine skalierbare Hardware- und Softwareimplementierung von transaktionaler Energieverwaltung bieten (z. B. für eine Sequenz von Energieanweisungen, die als Transaktionen zu behandeln sind). Die Repräsentation von Energiezustandsübergängen als Transaktionen kann eine geordnetere, semantisch genaue Art und Weise erlauben, Energieverwaltungsübergange zu modellieren, spezifizieren und zu prüfen.
  • 3 illustriert einen integrierten Schaltkreis 300 (z. B. ein SoC) nach Ausführungsformen der Offenbarung. In diesem Beispiel enthalten die (z. B. alle) Prozessorkerne (die z. B. Energieverwaltungscontroller enthalten) Unterstützung für Hardware-Speichertransaktionen (z. B. transaktionalen Speicher) und können deshalb eine transaktionale Energieverwaltung erlauben. Komponenten des integrierten Schaltkreises können eine (z. B. global) synchronisierte Ansicht von Transaktionen (z. B. Speicher- und Energietransaktionen) über alle Komponenten (z. B. alle Prozessorkerne, einschließlich der Energieverwaltungseinheit (PUNIT) 340 und des Energieverwaltungscontrollers (PMC) 342) hinweg aufweisen. Zum Beispiel kann ein System (z. B. ein SoC) eine Speichertransaktionseinheit (z. B. Engine) und/oder eine Energietransaktionseinheit (z. B. Engine) enthalten. Eine Datenstruktur (z. B. Bloom-Filter) kann nicht eingesetzt werden. Ein Compiler kann Unterstützung für eine Transaktion enthalten, um Energiezustandsübergänge zu erlauben. Die Unterstützung für Speichertransaktionen in einem Compiler kann eingesetzt werden, um eine transaktionale Energieverwaltung zu erlauben. Einrichtungs-Treiber können ihren Code für Energieverwaltungstransaktionen annotieren. Dieser Rahmen kann dem OS und anderen Komponenten helfen, portabler und über mehrere Kern-SoCs skalierbar zu sein, z. B., ohne Punktlösungen von Sperren, Synchronisieren bereitstellen zu müssen. Bus 316 kann für Kommunikationen verwendet werden. Für 2 und 3 sind die für jeweils den Nordblock und den Südblock aufgelisteten Komponenten und Einrichtungen nur Beispiele.
  • In einer Ausführungsform kann ein System (zum Beispiel mit mehreren Kernen) transaktionalen Hardwarespeicher für eine als transaktional markierte Codesequenz unterstützen, indem es Hardware aufweist, die die AKID-Semantik für diese Codesequenz garantiert, z. B. über alle Prozessorkerne (und den gesamten Speicher) hinweg. Dies kann im Allgemeinen als eine global synchronisierte Transaktionsansicht über alle Kerne hinweg bezeichnet werden, sodass zum Beispiel, wenn ein Kern einen als transaktional markierten Codeablauf (z. B. Thread) ausführt, wenn dieser Kern auf Daten zugreift (z. B. im Speicher), dann gibt es eingebaute Hardwareunterstützung, um sicherzustellen, dass die transaktionale Semantik für dieses Stück Code (und Speicher) z. B. über alle Kerne hinweg beibehalten wird. In einem Beispiel eines solchen Systems können (z. B. alle) Hosttreiber auf den Prozessorkernen (z. B. IA) laufen (zum Beispiel, typischerweise für die Operationen auf einen Hauptspeicher zugreifend und diesen verwendend) und ein beliebiger Satz von Hosttreibern, die versuchen, transaktionale Energieverwaltung (z. B. für als transaktional markierte Energieverwaltungsbefehle (Code)) durchzuführen, garantiert transaktionale Semantik beibehalten, zum Beispiel, wenn diese Befehle von einem Kern bzw. von Kernen und/oder einer Energieverwaltungseinheit bzw. Energieverwaltungseinheiten (z. B. einem Controller mit Speicherzugriff) ausgeführt werden.
  • Bestimmte Ausführungsformen eines Systems, das Speichertransaktionen unterstützt, können verwendet werden, um Energietransaktionen zu unterstützen, wo zum Beispiel Energieverwaltungsbefehle Lese- und/oder Schreibvorgänge in einen Speicher (z. B. ein Register) sind. Zum Beispiel kann eine Energieverwaltungsanweisung einer ISA ein Feld davon aufweisen, um anzuzeigen, dass es eine Transaktion ist.
  • Bestimmte Ausführungsformen dieser Offenbarung enthalten Hardware- und/oder Softwareunterstützung (z. B. Laufzeitunterstützung) für eine oder mehrere von Folgendem: Prozessorkerne sowie Controller (z. B. Mikrocontroller) wie eine PUNIT, einen PMC und eine Radioanschlusscontrollereinheit (RPCU), z. B. in einer mobilen Einrichtung, die spezifische Energieverwaltungsbefehle (z. B. Sequenzen) als Transaktionen (z. B. Sequenzen) implementieren. Software-Energietransaktionen können Abstraktionen für ein Einkapseln von Energieverwaltungsbefehlen als Transaktionen bereitstellen, zum Beispiel kann dies durch Energie-Pragmas in Compilern erreicht werden, um Software zu erlauben, Energieverwaltungssequenzen in Softwarecode (z. B. OS- und/oder Treiber-Code) zu annotieren. Compilerübersetzungen können von Software bereitgestellte Energiehinweise (z. B. „atomare” in 5) in transaktionale Speicheranweisungssequenzen umwandeln, die für die zugrunde liegende architektonische Unterstützung für einen transaktionalen Hardware-Speicher spezifisch sind. Das Obenstehende kann erweitert werden, um auch einen transaktionalen Hardware-Speicher für Controllerunterstützung (z. B. Mikrocontrollerunterstützung) aufzuweisen, zum Beispiel einen separaten Kern oder Prozessor, der zur Energieverwaltung verwendet wird. Eine Hardware-Transaktionsunterstützung (Hardware-Energietransaktionsunterstützung) kann eine einheitliche Ansicht der Energiezustände von Einrichtungen und der Plattform und/oder des SoC bieten. Dieser Rahmen kann einem OS und anderen Komponenten erlauben, portabler und über mehrere Kerneinrichtungen (z. B. SoCs) skalierbar zu sein, ohne zum Beispiel Punktlösungen von Sperren, Synchronisieren bereitstellen zu müssen. Zum Beispiel können im in 5 gezeigten Beispiel Threads T1 und T2 Zugriff auf die gemeinsam genutzten Energiezustandsregister in einer gemeinsam genutzten Energieressource 601 durch Einkapseln der Threads um einen atomaren Block ausführen. Wenn eine Transaktion bis zum Abschluss ausgeführt und festgeschrieben wird, können ihre Auswirkungen für andere Transaktionen sichtbar werden. Andernfalls kann die Transaktion abgebrochen werden und keine ihrer Auswirkungen können für andere Transaktionen sichtbar sein.
  • Bestimmte Ausführungsformen hierin enthalten ein Anzeigen (z. B. Markieren) von Codeabschnitten, die auf gemeinsam genutzte Objekte als Transaktionen zugreifen sollen, z. B., die atomar auszuführen sind.
  • 4 illustriert Energieverwaltungs-Code 400 für ein System ohne Energietransaktionen nach Ausführungsformen der Offenbarung. 4 illustriert, dass ohne Energietransaktionen ein System einen zweiten Energieübergang verzögern kann, bis ein erster Energieübergang abgeschlossen ist. In einer Ausführungsform für Energiezustandsübergänge ohne Energietransaktionen kann ein Kernel oder Einrichtungstreiber einen Energieverwaltungsbefehl (z. B. eine Energiezustandsübergangsanforderung) an eine einzige Einrichtung oder an mehrere Einrichtungen ausgeben, zum Beispiel auf Basis von Plattformunterstützung dafür. Es können jedoch mehrere Sperren und/oder Synchronisierungsprimitiven verwendet werden, um diese komplexe Zustandsmaschine über OS, Einrichtungstreiber, Firmware und Hardware hinweg zu orchestrieren, was zu Fehlern (z. B. Bugs), Rennsituationen, Blockaden/Aushungern, nicht-portierbarem Code und plattformspezifischen Lösungen führt. Ferner kann die Zeit zur Durchführung eines Energiezustandsübergangs ohne Energietransaktionen das 10-fache der Zeit oder mehr als bei Verwendung von Energietransaktionen dauern, zum Beispiel aufgrund einer hohen Latenzzeit von Anhalten und Wiederaufnehmen ohne Energietransaktionen.
  • 5 illustriert Energieverwaltungs-Code 500 für ein System mit Energietransaktionen nach Ausführungsformen der Offenbarung. Der gezeigte Code enthält ein Deklarieren (z. B. durch „atomar”), dass Energieverwaltungsbefehle (z. B. beide Threads T1 und T2) als Transaktionen zu behandeln sind, zum Beispiel nach einer oder mehrerer der transaktionalen Eigenschaften Atomarität, Konsistenz, Isolation und Dauerhaftigkeit (AKID). In einer Ausführungsform wird das Rechensystem (z. B. ein Compiler) diejenigen Threads als Transaktionen behandeln, die nebenläufig ausgeführt werden können, wobei z. B. beide festgeschrieben werden, falls es keinen Konflikt gibt.
  • 6 illustriert ein Zeitsteuerungsschema 600 mit atomaren Energietransaktionen für T1 und T2 und ohne atomare Energietransaktionen für T1 und T2 nach Ausführungsformen der Offenbarung. 6 illustriert, dass für die atomaren Energietransaktionen beide Threads nebenläufig ausgeführt werden können, z. B. Zeit t1 und t2 zur jeweiligen Ausführung benötigen (und festgeschrieben werden können, wenn es keinen Konflikt gibt, der durch ihren Zugriff auf (ein) Energiesteuerregister für eine gemeinsam genutzte Energieressource 601 bewirkt wurde), im Gegensatz zu Energieverwaltungsbefehlen (z. B. nicht atomare T1 und T2), die in Serie abgeschlossen werden (z. B. mindestens t1 + t2), da sie keine Transaktionen sind. In einer Ausführungsform wird jeder Energieverwaltungsbefehl (z. B. Thread) auf einem separaten Kern ausgeführt. In einer Ausführungsform kann ein Kern als eine Energieverwaltungseinheit eingesetzt werden.
  • 7 illustriert ein Ablaufdiagramm 700 nach Ausführungsformen der Offenbarung. Das gezeigte Ablaufdiagramm 700 enthält ein Bereitstellen einer Vielzahl von Energiedomänen einer Hardwarevorrichtung, die einen Hardwareprozessor enthält, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne 702 überzugehen, ein Zuweisen eines ersten Energieverwaltungsbefehls als eine erste Energietransaktion und eines zweiten Energieverwaltungsbefehls als eine zweite Energietransaktion für eine nebenläufige Ausführung 704, ein Durchführen einer Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion 706, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt, und ein Durchführen eines Abbruchs der ersten Energietransaktion und einer Festschreibung der zweiten Energietransaktion 708, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt.
  • 8 illustriert ein Ablaufdiagramm 800 nach Ausführungsformen der Offenbarung. Der gezeigte Ablauf enthält eine beispielhafte Energietransaktion, z. B. den gesamten Weg von der Software (z. B. einem OS) bis zur Firmware bis zur Hardware. In einer Ausführungsform kann das Ablaufdiagramm von Fiugur 800 auf die Verschaltung in den 1, 2 und/oder 3 verweisen. PMIC kann einen integrierten Energieverwaltungs-Schaltkreis bezeichnen.
  • In einer Ausführungsform enthält eine Hardwarevorrichtung einen Hardwareprozessor, der einen Kern, eine Vielzahl von Energiedomänen, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne überzugehen, und eine Energietransaktionseinheit aufweist, um: einen ersten Energieverwaltungsbefehl als eine erste Energietransaktion und einen zweiten Energieverwaltungsbefehl als eine zweite Energietransaktion für eine nebenläufige Ausführung zuzuweisen, eine Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion durchzuführen, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt, und einen Abbruch der ersten Energietransaktion und eine Festschreibung der zweiten Energietransaktion durchzuführen, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt. Die erste Energietransaktion und die zweite Energietransaktion können jeweils mehrere Anweisungen enthalten. Die Hardwarevorrichtung kann ferner eine Vielzahl von Energiezustandsregistern enthalten, um den Energieverwaltungsbefehl für jede Domäne zu empfangen. Der Konflikt kann sein, dass die erste Energietransaktion in ein Energiezustandsregister schreibt, in das die zweite Energietransaktion geschrieben hat. Die Energietransaktionseinheit kann keine Sperre ausgeben. Der Konflikt kann sein, dass die erste Energietransaktion und die zweite Energietransaktion widersprüchliche Energieverwaltungsbefehle für eine gemeinsam genutzte Energiedomäne schreiben. Wenn es den Konflikt gibt, kann ein Übergang einer Energiedomäne als Antwort auf Ausführung der zweiten Energietransaktion nur nach der Festschreibung der zweiten Energietransaktion für andere Transaktionen sichtbar sein. Die Hardwarevorrichtung kann ferner eine Speichertransaktionseinheit enthalten, um eine Festschreibung eines ersten Threads und eines zweiten Threads nach nebenläufiger Ausführung des ersten Threads auf dem Kern und des zweiten Threads auf einem zweiten Kern des Hardwareprozessors durchzuführen, falls der erste Thread und der zweite Thread nicht eine gleiche Speicheradresse modifizieren sollen.
  • In einer anderen Ausführungsform enthält ein Verfahren ein Bereitstellen einer Vielzahl von Energiedomänen einer Hardwarevorrichtung, die einen Hardwareprozessor enthält, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne überzugehen, ein Zuweisen eines ersten Energieverwaltungsbefehls als eine erste Energietransaktion und eines zweiten Energieverwaltungsbefehls als eine zweite Energietransaktion für eine nebenläufige Ausführung, ein Durchführen einer Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt, und ein Durchführen eines Abbruchs der ersten Energietransaktion und einer Festschreibung der zweiten Energietransaktion, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt. Die erste Energietransaktion und die zweite Energietransaktion können jeweils mehrere Anweisungen enthalten. Das Verfahren kann ferner ein Empfangen des Energieverwaltungsbefehls für jede Domäne an einem Energiezustandsregister enthalten. Der Konflikt kann sein, dass die erste Energietransaktion in ein Energiezustandsregister schreibt, in das die zweite Energietransaktion geschrieben hat. Das Verfahren kann ferner enthalten, dass keine Sperre ausgegeben wird. Der Konflikt kann sein, dass die erste Energietransaktion und die zweite Energietransaktion widersprüchliche Energieverwaltungsbefehle für eine gemeinsam genutzte Energiedomäne schreiben. Wenn es den Konflikt gibt, kann ein Übergang einer Energiedomäne als Antwort auf Ausführung der zweiten Energietransaktion nur nach einer Durchführung der Festschreibung der zweiten Energietransaktion für andere Transaktionen sichtbar sein. Das Verfahren kann ferner ein Durchführen einer Festschreibung eines ersten Threads und eines zweiten Threads nach nebenläufiger Ausführung des ersten Threads und des zweiten Threads auf dem Hardwareprozessor enthalten, falls der erste Thread und der zweite Thread nicht eine gleiche Speicheradresse modifizieren sollen.
  • In noch einer anderen Ausführungsform weist ein nicht-transitorisches maschinenlesbares Speichermedium gespeicherten Programmcode auf, der bei Verarbeitung durch eine Maschine bewirkt, dass ein Verfahren durchgeführt wird, wobei das Verfahren ein Bereitstellen einer Vielzahl von Energiedomänen einer Hardwarevorrichtung enthält, die einen Hardwareprozessor enthält, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne überzugehen, ein Zuweisen eines ersten Energieverwaltungsbefehls als eine erste Energietransaktion und eines zweiten Energieverwaltungsbefehls als eine zweite Energietransaktion für eine nebenläufige Ausführung, ein Durchführen einer Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt, und ein Durchführen eines Abbruchs der ersten Energietransaktion und einer Festschreibung der zweiten Energietransaktion, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt. Die erste Energietransaktion und die zweite Energietransaktion können jeweils mehrere Anweisungen enthalten. Das Verfahren kann ferner ein Empfangen des Energieverwaltungsbefehls für jede Domäne an einem Energiezustandsregister enthalten. Der Konflikt kann sein, dass die erste Energietransaktion in ein Energiezustandsregister schreibt, in das die zweite Energietransaktion geschrieben hat. Das Verfahren kann ferner enthalten, dass keine Sperre ausgegeben wird. Der Konflikt kann sein, dass die erste Energietransaktion und die zweite Energietransaktion widersprüchliche Energieverwaltungsbefehle für eine gemeinsam genutzte Energiedomäne schreiben. Wenn es den Konflikt gibt, kann ein Übergang einer Energiedomäne als Antwort auf Ausführung der zweiten Energietransaktion nur nach einer Durchführung der Festschreibung der zweiten Energietransaktion für andere Transaktionen sichtbar sein. Das Verfahren kann ferner ein Durchführen einer Festschreibung eines ersten Threads und eines zweiten Threads nach nebenläufiger Ausführung des ersten Threads und des zweiten Threads auf dem Hardwareprozessor enthalten, falls der erste Thread und der zweite Thread nicht eine gleiche Speicheradresse modifizieren sollen.
  • In einer anderen Ausführungsform enthält eine Hardwarevorrichtung einen Hardwareprozessor, der einen Kern, eine Vielzahl von Energiedomänen, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne überzugehen, und ein Mittel aufweist, um: einen ersten Energieverwaltungsbefehl als eine erste Energietransaktion und einen zweiten Energieverwaltungsbefehl als eine zweite Energietransaktion für eine nebenläufige Ausführung zuzuweisen, eine Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion durchzuführen, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt, und einen Abbruch der ersten Energietransaktion und eine Festschreibung der zweiten Energietransaktion durchzuführen, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt.
  • In noch einer anderen Ausführungsform umfasst eine Vorrichtung eine Datenspeichereinrichtung, die Code speichert, der bei Ausführung durch einen Hardwareprozessor bewirkt, dass der Hardwareprozessor irgendein hierin offenbartes Verfahren durchführt. Eine Vorrichtung kann wie in der detaillierten Beschreibung beschrieben sein. Ein Verfahren kann wie in der detaillierten Beschreibung beschrieben sein.
  • Ein Anweisungssatz kann eine oder mehrere Anweisungsformate enthalten. Ein bestimmtes Anweisungsformat kann verschiedene Felder (z. B. Anzahl von Bits, Lage von Bits) definieren, um unter anderem die durchzuführende Operation (z. B. Opcode) und den bzw. die Operand(en), auf den bzw. die diese Operation durchzuführen ist, und/oder ein anderes Datenfeld bzw. andere Datenfelder (z. B. eine Maske) zu spezifizieren. Manche Anweisungsformate sind ferner durch die Definition von Anweisungsvorlagen (oder Teilformaten) aufgegliedert. Zum Beispiel können die Anweisungsvorlagen eines bestimmten Anweisungsformats definiert sein, verschiedene Teilsätze der Felder des Anweisungsformats aufzuweisen (die enthaltenen Felder sind üblicherweise in der gleichen Reihenfolge, aber zumindest einige weisen verschiedene Bitpositionen auf, da weniger Felder enthalten sind), und/oder definiert sein, ein bestimmtes Feld unterschiedlich interpretiert aufzuweisen. Deshalb wird jede Anweisung einer ISA unter Verwendung eines bestimmten Anweisungsformats ausgedrückt (und, falls definiert, in einer bestimmten der Anweisungsvorlagen dieses Anweisungsformats) und enthält Felder zum Spezifizieren der Operation und der Operanden. Zum Beispiel weist eine beispielhafte ADD-Anweisung einen bestimmten Opcode und ein Anweisungsformat auf, das ein Opcode-Feld, um diesen Opcode zu spezifizieren, und Operanden-Felder enthält, um Operanden auszuwählen (Quelle 1/Ziel und Quelle 2); und ein Auftreten dieser ADD-Anweisung in einem Anweisungsstrom wird spezifische Inhalte in den Operanden-Feldern aufweisen, die spezifische Operanden auswählen. Ein Satz von SIMD-Erweiterungen, die als Advanced Vector Extensions (AVX) (AVX1 und AVX2) bezeichnet werden und die das Vector-Extensions(VEX)-Codierschema verwenden, wurde freigegeben und/oder veröffentlicht (siehe z. B. Handbuch für Software-Entwickler zur Intel®-64- und IA-32-Architektur, April 2015; und siehe Programmierreferenz für Befehlssatzerweiterungen für die Intel®-Architektur, Oktober 2014).
  • Beispielhafte Kernarchitekturen, Prozessoren und Computer-Architekturen
  • Prozessorkerne können auf verschiedene Arten, für verschiedene Zwecke und in verschiedenen Prozessoren implementiert werden. Zum Beispiel können Implementierungen solcher Kerne Folgendes enthalten: 1) einen Universal-In-Order-Kern, der für allgemeine Rechenzwecke gedacht ist; 2) einen Hochleistungs-Universal-Out-of-Order-Kern, der für allgemeine Rechenzwecke gedacht ist; 3) einen Kern für Sonderzwecke, der primär für Grafik- und/oder wissenschaftliches Rechnen (Durchsatzrechnen) gedacht ist. Implementierungen von verschiedenen Prozessoren können Folgendes enthalten: 1) eine CPU, die einen oder mehrere Universal-In-Order-Kerne, die für allgemeine Rechenzwecke gedacht sind, und/oder einen oder mehrere Universal-Out-of-Order-Kerne enthält, die für allgemeine Rechenzwecke gedacht sind; und 2) einen Coprozessor, der einen oder mehrere Kerne für Sonderzwecke enthält, die primär für Grafik und/oder Wissenschaft (Durchsatz) gedacht sind. Solche verschiedenen Prozessoren führen zu verschiedenen Computersystemarchitekturen, die Folgendes umfassen können: 1) den Coprozessor auf einem separaten Chip von der CPU; 2) den Coprozessor auf einem separaten Chip im gleichen Paket wie eine CPU; 3) den Coprozessor auf dem gleichen Chip wie eine CPU (in diesem Fall wird ein solcher Coprozessor manchmal als Logik für Sonderzwecke bezeichnet, wie integrierte Grafik- und/oder wissenschaftliche Logik (Durchsatzlogik, oder als Kerne für Sonderzwecke); und 4) ein Ein-Chip-System, das die beschriebene CPU (manchmal als der Anwendungskern bzw. die Anwendungskerne oder der Anwendungsprozessor bzw. die Anwendungsprozessoren bezeichnet), den oben beschriebenen Coprozessor und zusätzliche Funktionalität auf dem gleichen Chip enthalten kann. Als Nächstes werden beispielhafte Kernarchitekturen beschrieben, gefolgt von Beschreibungen von beispielhaften Prozessoren und Computerarchitekturen.
  • Beispielhafte Kernarchitekturen Blockdiagramm für In-Order- und Out-of-Order-Kerne
  • 9A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline nach Ausführungsformen der Offenbarung illustriert. 9B ist ein Blockdiagramm, das sowohl ein Ausführungsbeispiel eines Kerns mit In-Order-Architektur als auch eines Kerns mit Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungsarchitektur illustriert, die in einem Prozessor nach Ausführungsformen der Offenbarung enthalten sein sollen. Die durchgezogen umrandeten Kästchen in den 9A–B illustrieren die In-Order-Pipeline und den In-Order-Kern, während der optionale Zusatz der gestrichelt umrandeten Kästchen die Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline und den Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Kern illustrieren. Da der In-Order-Aspekt ein Teilsatz des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
  • In 9A enthält eine Prozessor-Pipeline 900 eine Abrufphase 902, eine Längendecodierphase 904, eine Decodierphase 906, eine Zuordnungsphase 908, eine Umbenennungsphase 910, eine Zeitplanungsphase (auch als Versand- oder Ausgabephase bekannt) 912, eine Registerlese-/Speicherlesephase 914, eine Ausführungsphase 916, eine Zurückschreib-/Speicherschreibphase 918, eine Ausnahmebehandlungsphase 922 und eine Festschreibphase 924.
  • 9B zeigt einen Prozessorkern 990, der eine Front-End-Einheit 930 enthält, die an eine Ausführengineeinheit 950 gekoppelt ist, und beide sind an eine Speichereinheit 970 gekoppelt. Der Kern 990 kann ein Reduced-Instruction-Set-Computing(RISC)-Kern, ein Complex-Instruction-Set-Computing(CISC)-Kern, ein Very-Long-Instruction-Word(VLIW)-Kern oder ein Hybrid- oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 990 ein Kern für Sonderzwecke sein, wie zum Beispiel ein Netzwerk- oder Kommunikationskern, eine Komprimierungsengine, ein Coprozessorkern, einen Kern einer Grafikverarbeitungseinheit für allgemeine Rechenzwecke (GPGPU), ein Grafikkern oder Ähnliches.
  • Die Front-End-Einheit 930 enthält eine an eine Anweisungscacheeinheit 934 gekoppelte Sprungvorhersageeinheit 932, die an einen Anweisungsübersetzungspuffer (Translation Lookaside Buffer, TLB) 936 gekoppelt ist, der an eine Anweisungsabrufeinheit 938 gekoppelt ist, die an eine Decodiereinheit 940 gekoppelt ist. Die Decodiereinheit 940 (oder Decoder oder Decodereinheit) kann Anweisungen (z. B. Makroanweisungen) decodieren und als Ausgabe eine oder mehrere Mikro-Operationen, Mikrocode-Eingangspunkte, Mikroanweisungen, andere Anweisungen oder andere Steuersignale generieren, die von den ursprünglichen Anweisungen decodiert sind oder diese anderweitig widerspiegeln oder von diesen abgeleitet sind. Die Decodiereinheit 940 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Beispiele geeigneter Mechanismen enthalten Nachschlagetabellen, Hardwareimplementierungen, programmierbare Logikanordnungen (PLAs), Mikrocode-Read-Only-Memories (ROMs) usw., sind jedoch nicht darauf beschränkt. In einer Ausführungsform enthält der Kern 990 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makroanweisungen speichert (z. B. in der Decodiereinheit 940 oder anderweitig innerhalb der Front-End-Einheit 930). Die Dekodiereinheit 940 ist in der Ausführungsengineeinheit 950 an eine Umbenennungs-/Zuordnungeinheit 952 gekoppelt.
  • Die Ausführungsengineeinheit 950 enthält die an eine Stilllegungseinheit 954 gekoppelte Umbenennungs-/Zuordnungeinheit 952 und einen Satz von einer oder mehreren Zeitplangeber-Einheiten 956. Die Zeitplangeber-Einheit(en) 956 repräsentiert bzw. repräsentieren eine beliebige Anzahl von verschiedenen Zeitplangebern, die Reservierstationen, Zentralanweisungsfenster usw. enthalten. Die Zeitplangeber-Einheit(en) 956 ist bzw. sind an die physische(n) Registerdateieinheit(en) 958 gekoppelt. Jede der physischen Registerdateieinheit(en) 958 repräsentiert eine oder mehrere physische Registerdateien, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, wie skalare ganze Zahl, skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma, Status (z. B. einen Anweisungszeiger, der die Adresse der nächsten auszuführenden Anweisung ist) usw. In einer Ausführungsform umfasst die physische Registerdateieinheit 958 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physische(n) Registerdateieinheit(en) 958 wird bzw. werden von der Stilllegungseinheit 954 überlappt, um verschiedene Arten zu illustrieren, auf die eine Registerumbenennung und Out-of-Order-Ausführung implementiert werden können (z. B. unter Verwendung eines Umordnungspuffers bzw. von Umordnungspuffern und (einer) Stilllegungsregisterdatei(en); unter Verwendung einer bzw. von zukünftigen Datei(en), eines Verlaufspuffers bzw. von Verlaufspuffern und einer Stilllegungsregisterdatei bzw. von Stilllegungsregisterdateien; unter Verwendung einer Registerkarte und eines Pools von Registern; usw.). Die Stilllegungseinheit 954 und die physische(n) Registerdateieinheit(en) 958 sind an das bzw. die Ausführungscluster 960 gekoppelt. Das bzw. die Ausführungscluster 960 enthält bzw. enthalten einen Satz einer oder mehrerer Ausführungseinheiten 962 und einen Satz von einem oder mehreren Speicherzugriffseinheiten 964. Die Ausführungseinheiten 962 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Datentypen (z. B. skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma) durchführen. Während manche Ausführungsformen eine Anzahl von Ausführungseinheiten enthalten können, die spezifischen Funktionen oder Funktionssätzen gewidmet sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten enthalten, die alle alle Funktionen durchführen. Die Zeitplangeber-Einheit(en) 956, physische(n) Registerdateieinheit(en) 958 und Ausführungscluster 960 sind als möglicherweise mehrzahlig gezeigt, da bestimmte Ausführungsformen separate Pipelines für bestimmte Arten von Daten/Operationen erstellen (z. B. eine Pipeline für skalare ganze Zahlen, eine Pipeline für skalares Gleitkomma/gepackte ganze Zahlen/gepacktes Gleitkomma/vektorielle ganze Zahlen/vektorielles Gleitkomma und/oder eine Speicherzugriffs-Pipeline, die jeweils ihre eigene Zeitplangeber-Einheit, physische Registerdateieinheit und/oder ihr eigenes Ausführungscluster aufweisen – und im Fall einer separaten Speicherzugriffs-Pipeline sind bestimmte Ausführungsformen implementiert, in denen nur das Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 964 aufweist). Es sollte auch klar sein, dass, wo separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines Out-of-Order-Ausgabe-/Ausführungs- und der Rest In-Order-Pipelines sein können.
  • Der Satz von Speicherzugriffseinheiten 964 ist an die Speichereinheit 970 gekoppelt, die eine Daten-TLB-Einheit 972 enthält, die an eine Datencacheeinheit 974 gekoppelt ist, die an eine Level-2(L2)-Cacheeinheit 976 gekoppelt ist. In einem Ausführungsbeispiel können die Speicherzugriffseinheiten 964 eine Ladeeinheit, eine Adressspeichereinheit und eine Datenspeichereinheit enthalten, von denen jede an die Daten-TLB-Einheit 972 in der Speichereinheit 970 gekoppelt ist. Die Anweisungscacheeinheit 934 ist ferner an eine Level-2(L2)-Cacheeinheit 976 in der Speichereinheit 970 gekoppelt. Die L2-Cacheeinheit 976 ist an eine oder mehrere andere Cache-Levels und letztendlich an einen Hauptspeicher gekoppelt.
  • Beispielsweise kann die beispielhaften Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungskernarchitektur die Pipeline 900 folgendermaßen implementieren: 1) Der Anweisungsabruf 938 führt den Abruf und die Längendecodierphasen 902 und 904 durch; 2) die Decodiereinheit 940 führ die Decodierphase 906 durch; 3) die Umbenennungs-/Zuordnungseinheit 952 führ die Zuordnungsphase 908 und die Umbenennungsphase 910 durch; 4) die Zeitplangebereinheit(en) 956 führt bzw. führen die Zeitplanungsphase 912 durch; 5) die physische(n) Registerdateieinheit(en) 958 und die Speichereinheit 970 führen die Registerlese-/Speicherlesephase 914 durch; das Ausführungscluster 960 führt die Ausführungsphase 916 durch; 6) die Speichereinheit 970 und die physische(n) Registerdateieinheit(en) 958 führen die Zurückschreib-/Speicherschreibphase 918 durch; 7) verschiedene Einheiten können an der Ausnahmebehandlungsphase 922 beteiligt sein; und 8) die Stilllegungseinheit 954 und die physische(n) Registerdateieinheit(en) 958 führen die Festschreibphase 924 durch.
  • Der Kern 990 kann eine oder mehrere Anweisungssätze unterstützen (z. B. den x86-Anweisungssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden); den MIPS-Anweisungssatz von MIPS Technologies in Sunnyvale, CA; den ARM-Anweisungssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings in Sunnyvale, CA), die die hierin beschriebene(n) Anweisung(en) enthalten. In einer Ausführungsform enthält der Kern 990 Logik, um eine gepackte Datenanweisungssatzerweiterung (z. B. AVX1, AVX2) zu unterstützen, wodurch erlaubt wird, dass die von vielen Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten durchgeführt werden.
  • Es sollte klar sein, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies auf vielfältige Weise tun kann, einschließlich Sliced-Multithreading, simultanes Multithreading (wobei ein einziger physischer Kern jedem der Threads, die der physische Kern simultan nebenläufig ausführt, einen logischen Kern bereitstellt) oder eine Kombination davon (z. B. Zeitscheiben-Abruf und -Decodierung und danach simultanes Multithreading wie in der Intel®-Hyperthreading-Technologie).
  • Während Registerumbenennen im Kontext einer Out-of-Order-Ausführung beschrieben wird, sollte klar sein, dass das Registerumbenennen in einer In-Order-Architektur verwendet werden kann. Während die illustrierte Ausführungsform des Prozessors auch separate Anweisungs- und Datencacheeinheiten 934/974 und eine gemeinsam genutzte L2-Cacheeinheit 976 enthält, können alternative Ausführungsformen einen einzigen internen Cache für sowohl Anweisungen als auch Daten aufweisen, wie zum Beispiel einen internen Level-1(L1)-Cache oder mehrere Levels von internem Cache. In manchen Ausführungsformen kann das System eine Kombination eines internen Cache und eines externen Cache enthalten, der extern zum Kern und/oder zum Prozessor ist. Alternativ kann der gesamte Cache extern zum Kern und/oder zum Prozessor sein.
  • Eine spezifische beispielhafte In-Order-Kernarchitektur
  • 10A–B illustrieren ein Blockdiagramm einer spezifischeren beispielhaften In-Order-Kernarchitektur, wobei der Kern einer von mehreren logischen Blöcken (die andere Kerne des gleichen Typs und/oder anderer Typen enthalten) in einem Chip wäre. Die logischen Blöcke kommunizieren über ein Verbindungsnetzwerk hoher Bandbreite (z. B. ein Ringnetzwerk) mit einiger Logik mit festen Funktionen, Speicher-E/A-Schnittstellen und andere notwendige E/A-Logik, abhängig von der Anwendung.
  • 10A ist ein Blockdiagramm eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung an das chipinterne Verbindungsnetz 1002 und mit seinem lokalen Teilsatz des Level-2(L2)-Cache 1004, nach Ausführungsformen der Offenbarung. In einer Ausführungsform unterstützt eine Anweisungsdecodiereinheit 1000 den x86-Anweisungssatz mit einer Erweiterung für gepackte Datenanweisungssätze. Ein L1-Cache 1006 erlaubt Zugriffe mit niedriger Latenzzeit auf Cachespeicher in die Skalar- und Vektoreinheiten. Während in einer Ausführungsform (um das Design zu vereinfachen) eine Skalareinheit 1008 und eine Vektoreinheit 1010 separate Registersätze (Skalarregister 1012 bzw. Vektorregister 1014) verwenden und zwischen ihnen transferierte Daten in einen Speicher geschrieben und danach wieder aus einem Level-1(L1)-Cache 1006 gelesen werden, können alternative Ausführungsformen der Offenbarung einen anderen Ansatz verwenden (z. B. einen einzigen Registersatz verwenden oder einen Kommunikationspfad enthalten, der erlaubt, dass Daten zwischen den zwei Registerdateien ohne Schreiben und Wiedereinlesen transferiert werden).
  • Der lokale Teilsatz des L2-Cache 1004 ist Teil eines globalen L2-Cache, das in separate lokale Teilsätze aufgeteilt ist, einen pro Prozessorkern. Jeder Prozessorkern weist einen direkten Zugriffspfad zu seinem eigenen lokalen Teilsatz des L2-Cache 1004 auf. Von einem Prozessorkern gelesene Daten werden in seinem L2-Cache-Teilsatz 1004 gespeichert und auf sie kann schnell zugegriffen werden, parallel zu anderen Prozessorkernen, die auf ihre eigenen lokalen L2-Cache-Teilsätze zugreifen. Von einem Prozessorkern geschriebene Daten werden in seinem eigenen L2-Cache-Teilsatz 1004 gespeichert und aus anderen Teilsätzen wenn nötig geleert. Das Ringnetzwerk stellt Kohärenz für gemeinsam genutzte Daten sicher. Das Ringnetzwerk ist bidirektional, um Agenten wie Prozessorkernen, L2-Caches und anderen Logikblöcken zu erlauben, miteinander innerhalb des Chips zu kommunizieren. Jeder Ring-Datenpfad ist pro Richtung 1012 Bit breit.
  • 10B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 10A nach Ausführungsformen der Offenbarung. 10B enthält einen L1-Datencache 1006A, einen Teil des L1-Cache 1004 sowie mehr Details in Bezug auf die Vektoreinheit 1010 und die Vektorregister 1014. Insbesondere ist die Vektoreinheit 1010 eine 16-breite Vektorverarbeitungseinheit (VPU) (siehe die 16-breite ALU 1028), die eine oder mehrere von folgenden Anweisungen ausführt: ganzzahlige, Gleitkommaanweisungen mit einfacher Genauigkeit und Gleitkommaanweisungen mit doppelter Genauigkeit. Die VPU unterstützt ein Swizzeln der Registereingänge mit Swizzleeinheit 1020, numerische Umwandlung mit numerischen Umwandlungseinheiten 1022A–B und Replizierung mit Replizierungseinheit 1024 am Speichereingang. Schreibmaskenregister 1026 erlauben ein Vergleichen von resultierenden Vektorschreibvorgängen.
  • 11 ist ein Blockdiagramm eines Prozessors 1100, der nach Ausführungsformen der Offenbarung mehr als einen Kern aufweisen kann, einen integrierten Speichercontroller aufweisen kann und integrierte Grafik aufweisen kann. Die durchgezogen umrandeten Kästchen in 11 illustrieren einen Prozessor 1100 mit einem einzigen Kern 1102A, einem Systemagenten 1110, einen Satz von einem oder mehreren Buscontrollereinheiten 1116, während die optionale Hinzufügung der gestrichelt umrandeten Kästchen einen alternativen Prozessor 1100 mit mehreren Kernen 1102A–N, einem Satz von einem oder mehreren integrierten Speichercontrollereinheiten 1114 in der Systemagenteinheit 1110 und Logik für Sonderzwecke 1108 illustriert.
  • Deshalb können verschiedene Implementierungen des Prozessors 1100 Folgendes umfassen: 1) eine CPU, wobei die Logik für Sonderzwecke 1108 integrierte Grafik- und/oder wissenschaftliche Logik (Durchsatzlogik) ist (die einen oder mehrere Kerne enthalten kann) und die Kerne 1102A–N ein oder mehrere Universalkerne sind (z. B. Universal-In-Order-Kerne, Universal-Out-of-Order-Kerne, eine Kombination der zwei); 2) einen Coprozessor, wobei die Kerne 1102A–N eine große Anzahl von Kernen für Sonderzwecke ist, die primär für Grafik und/oder Wissenschaft (Durchsatz) gedacht sind; und 3) einen Coprozessor, wobei die Kerne 1102A–N eine große Anzahl von Universal-In-Order-Kernen sind. Deshalb kann der Prozessor 1100 ein Universal-Prozessor, Coprozessor oder Prozessor für Sonderzwecke sein, wie zum Beispiel ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine Grafikverarbeitungseinheit für allgemeine Rechenzwecke (GPGPU), ein Many-Integrated-Core(MIC)-Coprozessor mit hohem Durchsatz (der 30 oder mehr Kerne enthält), ein eingebetteter Prozessor oder Ähnliches. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 1100 kann ein Teil eines oder mehrerer Substrate sein und/oder kann auf einem oder mehreren Substraten unter Verwendung einer Anzahl von Prozesstechniken wie zum Beispiel BiCMOS, CMOS oder NMOS implementiert sein.
  • Die Speicherhierarchie enthält einen oder mehrere Level von Cache innerhalb der Kerne, einen Satz von einer oder mehreren gemeinsam genutzten Cacheeinheiten 1106 und externen Speicher (nicht gezeigt), die an den Satz der integrierten Speichercontrollereinheiten 1114 gekoppelt sind. Der Satz der gemeinsam genutzten Cacheeinheiten 1106 kann einen oder mehrere Caches mittlerer Levels enthalten, wie Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cachelevel, einen Last-Level-Cache (LLC) und/oder Kombinationen davon. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 1112 die integrierte Grafiklogik 1108, den Satz der gemeinsam genutzten Cacheeinheiten 1106 und die Systemagenteinheit 1110/den bzw. die integrierten Speichercontrollereinheit(en) 1114 verbindet, können alternative Ausführungsformen eine beliebige Anzahl von gut bekannten Techniken zum Verbinden solcher Einheiten verwenden. In einer Ausführungsform wird Kohärenz zwischen einem oder mehreren Cacheeinheiten 1106 und den Kernen 1102A–N beibehalten.
  • In manchen Ausführungsformen sind einer oder mehrere der Kerne 1102A–N multithreadingfähig. Der Systemagent 1110 enthält diese Komponenten, die die Kerne 1102A–N koordinieren und betreiben. Die Systemagenteinheit 1110 kann zum Beispiel eine Energiesteuereinheit (PCU) und eine Anzeigeeinheit enthalten. Die PCU kann Logik und Komponenten enthalten, die zur Regulierung des Energiezustands der Kerne 1102A–N und der integrierten Grafiklogik 1108 benötigt werden. Die Anzeigeeinheit ist zum Ansteuern einer oder mehrerer extern angeschlossener Anzeigen.
  • Die Kerne 1102A–N können in Bezug auf einen Architekturanweisungssatz homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 1102A–N können fähig sein, den gleichen Anweisungssatz auszuführen, während andere fähig sein können, nur einen Teilsatz dieses Anweisungssatzes oder einen anderen Anweisungssatz auszuführen.
  • Beispielhafte Computerarchitekturen
  • 12–15 sind Blockdiagramme von beispielhaften Computerarchitekturen. Andere Systemdesigns und -konfigurationen, die in der Technik für Laptops, Desktops, tragbare PCs, Organizer, Entwicklungs-Workstations, Server, Netzwerkeinrichtungen, Netzwerkhubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikeinrichtungen, Videospieleinrichtungen, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Mediaplayer, tragbare Geräte und verschiedene andere Elektronikgeräte bekannt sind, sind ebenfalls geeignet. Im Allgemeinen ist eine enorm große Vielfalt von Systemen oder Elektronikeinrichtungen geeignet, die einen Prozessor und/oder eine andere Ausführungslogik, wie hierin offenbart, einbinden können.
  • Nunmehr auf 12 Bezug nehmend, wird ein Blockdiagramm eines Systems 1200 gemäß einer Ausführungsform der vorliegenden Offenbarung gezeigt. Das System 1200 kann einen oder mehrere Prozessoren 1210, 1215 enthalten, die an einen Controllerhub 1220 gekoppelt sind. In einer Ausführungsform enthält der Controllerhub 1220 einen Grafikspeicher-Controllerhub (GMCH) 1290 und einen Eingabe-/Ausgabe-Hub (IOH) 1250 (die auf separaten Chips sein können); der GMCH 1290 enthält Speicher- und Grafikcontroller, an die Speicher 1240 und ein Coprozessor 1245 gekoppelt sind; der IOH 1250 koppelt Eingabe-/Ausgabe(E/A)-Einrichtungen 1260 an den GMCH 1290. Alternativ sind einer der Speicher- und Grafikcontroller oder beide im Prozessor integriert (wie hierin beschrieben), der Speicher 1240 und der Coprozessor 1245 sind direkt an den Prozessor 1210 gekoppelt, und der Controllerhub 1220 in einem einzigen Chip mit dem IOH 1250. Der Speicher 1240 kann ein Transaktionsmodul 1240A (z. B. ein Speicher- und/oder Energietransaktionsmodul) enthalten, zum Beispiel um Code zu speichern, der bewirkt, wenn er ausgeführt wird, dass ein Prozessor ein beliebiges Verfahren dieser Offenbarung durchführt.
  • Der optionale Charakter der zusätzlichen Prozessoren 1215 wird in 12 durch unterbrochene Linien angezeigt. Jeder Prozessor 1210, 1215 kann einen oder mehrere der hierin beschriebenen Verarbeitungskerne enthalten und kann eine Version des Prozessors 1100 sein.
  • Der Speicher 1240 kann zum Beispiel Dynamic Random Access Memory (DRAM), Phase-Change-Memory (PCM) oder eine Kombination der zwei sein. Für mindestens eine Ausführungsform kommuniziert der Controllerhub 1220 mit dem Prozessor bzw. den Prozessoren 1210, 1215 über einen Mehrpunktbus wie einem Frontside-Bus (FSB), einer Punkt-zu-Punkt-Schnittstelle wie QuickPath Interconnect (QPI) oder einer ähnlichen Verbindung 1295.
  • In einer Ausführungsform ist der Coprozessor 1245 ein Prozessor für Sonderzwecke, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder Ähnliches. In einer Ausführungsform kann der Controllerhub 1220 einen integrierten Grafikbeschleuniger enthalten.
  • Es kann eine Vielfalt von Unterschieden zwischen den physischen Ressourcen 1210, 1215 in Bezug auf ein Spektrum von Leistungsmetriken geben, einschließlich architektonisch, mikroarchitektonisch, thermal, Energieverbrauchsmerkmalen und Ähnlichem.
  • In einer Ausführungsform führt der Prozessor 1210 Anweisungen aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In den Anweisungen können Coprozessoranweisungen eingebettet sein. Der Prozessor 1210 erkennt, dass diese Coprozessoranweisungen von einem Typ sind, die vom angebundenen Coprozessor 1245 ausgeführt werden sollen. Dementsprechend gibt der Prozessor 1210 diese Coprozessoranweisungen (oder Steuersignale, die die Coprozessoranweisungen repräsentieren) auf einem Coprozessorbus oder einer anderen Verbindung an den Coprozessor 1245 aus. Der bzw. die Coprozessor(en) 1245 nimmt bzw. nehmen die empfangenen Coprozessoranweisungen an und führt bzw. führen diese aus.
  • Nunmehr auf 13 Bezug nehmend, wird ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 1300 in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung zeigt. Wie in 13 gezeigt, ist das Multiprozessorsystem 1300 ein Punkt-zu-Punkt-Verbindungssystem und enthält einen ersten Prozessor 1370 und einen zweiten Prozessor 1380, die über eine Punkt-zu-Punkt-Verbindung 1350 gekoppelt sind. Jeder der Prozessoren 1370 und 1380 kann eine Version des Prozessors 1100 sein. In einer Ausführungsform der Offenbarung sind die Prozessoren 1370 und 1380 die Prozessoren 1210 bzw. 1215, während der Coprozessor 1338 der Coprozessor 1245 ist. In einer anderen Ausführungsform sind die Prozessoren 1370 und 1380 der Prozessor 1210 bzw. der Coprozessor 1245.
  • Die Prozessoren 1370 und 1380 sind integrierte Speichercontrollereinheiten (IMC) 1372 bzw. 1382 enthaltend gezeigt. Der Prozessor 1370 enthält auch als Teil seiner Buscontrollereinheiten Punkt-zu-Punkt(P-P)-Schnittstellen 1376 und 1378; gleichermaßen enthält der zweite Prozessor 1380 P-P-Schnittstellen 1386 und 1388. Die Prozessoren 1370, 1380 können Informationen über eine Punkt-zu-Punkt(P-P)-Schnittstelle 1350 unter Verwendung der P-P-Schnittstellenschaltkreise 1378, 1388 austauschen. Wie in 13 gezeigt, koppeln die IMCs 1372 und 1382 die Prozessoren an jeweilige Speicher, nämlich einen Speicher 1332 und einen Speicher 1334, die Teile von Hauptspeicher sein können, die lokal an die jeweiligen Prozessoren angebunden sind.
  • Die Prozessoren 1370, 1380 können jeweils Informationen mit einem Chipset 1390 über individuelle P-P-Schnittstellen 1352, 1354 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltkreisen 1376, 1394, 1386, 1398 austauschen. Chipset 1390 kann optional Informationen mit dem Coprozessor 1338 über eine Hochleistungsschnittstelle 1339 austauschen. In einer Ausführungsform ist der Coprozessor 1338 ein Prozessor für Sonderzwecke, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder Ähnliches.
  • Ein gemeinsam genutzter Cache (nicht gezeigt) kann in einem der beiden Prozessoren oder außerhalb beider Prozessoren enthalten sein, jedoch mit den Prozessoren über eine P-P-Verbindung verbunden sein, sodass die lokalen Cache-Informationen von einem der beiden oder beiden Prozessoren im gemeinsam genutzten Cache gespeichert werden kann, wenn ein Prozessor in einen Niedrigenergiemodus versetzt wird.
  • Das Chipset 1390 kann über eine Schnittstelle 1396 an einen ersten Bus 1316 gekoppelt sein. In einer Ausführungsform ist der erste Bus 1316 ein Peripheral-Component-Interconnect(PCI)-Bus oder ein Bus wie ein PCI-Express-Bus oder ein anderer E/A-Verbindungsbus der dritten Generation sein, obwohl der Umfang der vorliegenden Offenbarung dadurch nicht eingeschränkt ist.
  • Wie in 13 gezeigt, können verschiedene E/A-Einrichtungen 1314 zusammen mit einer Busbrücke 1318, die den ersten Bus 1316 an einen zweiten Bus 1320 koppelt, an den ersten Bus 1316 gekoppelt sein. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessoren 1315 wie Coprozessoren, Hochdurchsatz-MIC-Prozessoren, GPGPUs, Beschleuniger (wie z. B. Grafikbeschleuniger oder digitale Signalverarbeitungseinheiten (DSP)), Field Programmable Gate Arrays oder beliebige andere Prozessoren an den ersten Bus 1316 gekoppelt. In einer Ausführungsform kann der zweite Bus 1320 ein Low-Pin-Count(LPC)-Bus sein. Verschiedene Einrichtungen können an einen zweiten Bus 1320 gekoppelt sein, die zum Beispiel eine Tastatur und/oder Maus 1322, Kommunikationseinrichtungen 1327 und eine Datenspeichereinheit 1328, wie ein Plattenlaufwerk oder eine andere Massenspeichereinrichtung enthält, das in einer Ausführungsform Anweisungen/Code und Daten 1330 enthalten kann. Ferner kann ein Audio-E/A 1324 an den zweiten Bus 1320 gekoppelt sein. Es ist zu beachten, dass andere Architekturen möglich sind. Zum Beispiel kann ein System statt der Punkt-zu-Punkt-Architektur von 13 einen Mehrpunktbus oder eine andere solche Architektur implementieren.
  • Nunmehr auf 14 Bezug nehmend, wird ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 1400 in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung zeigt. Gleiche Elemente in den 13 und 14 tragen gleiche Referenzziffern, und bestimmte Aspekte von 13 wurden von 14 weggelassen, um ein Verdecken anderer Aspekte von 14 zu vermeiden.
  • 14 illustriert, dass die Prozessoren 1370, 1380 eine integrierte Speicher- und E/A-Steuerlogik („CL”) 1372 bzw. 1382 enthalten können. Deshalb enthalten die CL 1372, 1382 integrierte Speichercontrollereinheiten und enthalten E/A-Steuerlogik. 14 illustriert, dass nicht nur die Speicher 1332, 1334 an die CL 1372, 1382 gekoppelt sind, sondern auch, dass E/A-Einrichtungen 1414 ebenfalls an die Steuerlogik 1372, 1382 gekoppelt sind. Alt-E/A-Einrichtungen 1415 sind an den Chipsatz 1390 gekoppelt.
  • Nunmehr auf 15 Bezug nehmend, wird ein Blockdiagramm eines SoC 1500 in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung gezeigt. Ähnliche Elemente in 11 tragen gleiche Referenzziffern. Gestrichelt umrandete Kästchen sind außerdem optionale Merkmale an hochentwickelteren SoCs. In 15 ist eine Verbindungseinheit bzw. sind Verbindungseinheiten 1502 an Folgendes gekoppelt: einen Anwendungsprozessor 1510, der einen Satz von einem oder mehreren Kernen 1102A–N und (eine) gemeinsam genutzte Cacheeinheit(en) 1106 enthält; eine Systemagenteinheit 1110; (eine) Buscontrollereinheit(en) 1116; (eine) integrierte Speichercontrollereinheit(en) 1114; einen Satz von einem oder mehreren Coprozessoren 1520, die integrierte Grafiklogik, einen Grafikprozessor, einen Audioprozessor und einen Videoprozessor enthalten können; eine statische Random-Access-Memory(SRAM)-Einheit 1530; eine direkte Speicherzugriffs(DMA)-Einheit 1532; und eine Anzeigeeinheit 1540 zum Koppeln an eine oder mehrere externe Anzeigen. In einer Ausführungsform enthält bzw. enthalten der bzw. die Coprozessor(en) 1520 einen Prozessor für Sonderzwecke, wie zum Beispiel einen Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, eine GPGPU, einen Hochdurchsatz-MIC-Prozessor, einen eingebetteten Prozessor oder Ähnliches.
  • Hierin offenbarte Ausführungsformen (z. B. der Mechanismen) können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungsansätze implementiert werden. Ausführungsformen der Offenbarung können als Computerprogramme oder Programmcode implementiert werden, die auf programmierbaren Systemen ausgeführt werden, die mindestens einen Prozess, ein Speichersystem (das flüchtigen und nichtflüchtigen Speicher und/oder Speicherelemente enthält), mindestens eine Eingabeeinrichtung und mindestens eine Ausgabeeinrichtung umfassen.
  • Programmcode, wie der in 13 illustrierte Code 1330 kann auf Eingabeanweisungen angewandt werden, um die hierin beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu generieren. Die Ausgabeinformationen können auf eine oder mehrere Ausgabeeinrichtungen angewandt werden, auf bekannte Weise. Für Zwecke dieser Anmeldung enthält ein Verarbeitungssystem ein beliebiges System, das einen Prozessor aufweist, wie zum Beispiel: einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor.
  • Der Programmcode kann in einer höheren verfahrens- oder objektorientierten Programmiersprache implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann auch in Assembler- oder Maschinensprache implementiert werden, wenn gewünscht. Tatsächlich sind die hierin beschriebenen Mechanismen im Umfang nicht auf eine beliebige bestimmte Programmiersprache beschränkt. Auf jeden Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
  • Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentative Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors repräsentiert, die, wenn sie von einer Maschine gelesen wird, bewirkt, dass die Maschine Logik erzeugt, um die hierin beschriebenen Techniken durchzuführen. Solche Repräsentationen, als „IP-Kerne” bekannt, können auf einem greifbaren, maschinenlesbaren Medium gespeicherten und an verschiedene Kunden oder Fertigungsanlagen geliefert werden, um in die Fertigungsmaschinen geladen zu werden, die die Logik oder den Prozessor tatsächlich herstellen.
  • Solche maschinenlesbaren Speichermedien können, sind jedoch nicht darauf beschränkt, nicht-transitorische, greifbare Anordnungen von einer Maschine oder Einrichtung gefertigte oder gebildete Artikel enthalten, die Speichermedien wie Festplatten, irgendeinen anderen Typ von Platte einschließlich Disketten, optische Platten, Compact Disc Read-Only Memories (CD-ROMs), wiederbeschreibbare Compact Discs (CD-RWs) und magneto-optische Platten, Halbleiterbauelemente wie Read-Only Memories (ROMs), Random-Access Memories (RAMs) wie dynamische Random-Access Memories (DRAMs), statische Random-Access Memories (SRAMs), Erasable Programmable Read-Only Memories (EPROMs), Flash-Speicher, Electrically Erasable Programmable Read-Only Memories (EEPROMs), Phase-Change-Memory (PCM), magnetische oder optische Karten oder irgendeinen anderen, zur Speicherung von elektronischen Anweisungen geeigneten Medientyp enthalten.
  • Dementsprechend enthalten Ausführungsformen der Offenbarung auch nicht-transitorische, greifbare maschinenlesbare Medien, die Anweisungen enthalten oder die Designdaten enthalten, wie Hardwarebeschreibungssprache (HDL), die hierin beschriebene Strukturen, Schaltkreise, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
  • Emulation (einschließlich binärer Übersetzung, Code-Morphing usw.)
  • In manchen Fällen kann ein Anweisungswandler verwendet werden, um eine Anweisung von einem Quellanweisungssatz in einen Zielanweisungssatz umzuwandeln. Zum Beispiel kann der Anweisungswandler eine Anweisung in eine oder mehrere andere, vom Kern zu verarbeitende Anweisungen übersetzen (z. B. unter Verwendung von statischer binärer Übersetzung, dynamischer binärer Übersetzung einschließlich dynamischem Kompilieren), verwandeln, emulieren oder anderweitig umwandeln. Der Anweisungswandler kann in Software, Hardware, Firmware oder einer Kombination davon implementiert werden. Der Anweisungswandler kann sich auf dem Prozessor, nicht auf dem Prozessor, oder teilweise auf und teilweise nicht auf dem Prozessor befinden.
  • 16 ist ein Blockdiagramm, das die Verwendung eines Softwareanweisungswandlers gegenüberstellt, um binäre Anweisungen in einem Quellanweisungssatz in binäre Anweisungen in einem Zielanweisungssatz nach Ausführungsformen der Offenbarung umzuwandeln. In der illustrierten Ausführungsform ist der Anweisungswandler ein Softwareanweisungswandler, obwohl alternativ der Anweisungswandler in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 16 zeigt, dass ein Programm in einer höheren Sprache 1602 unter Verwendung eines x86-Compilers 1604 kompiliert werden kann, um x86-Binärcode 1606 zu generieren, der nativ von einem Prozessor mit mindestens einem x86-Anweisungssatzkern 1616 ausgeführt werden kann. Der Prozessor mit mindestens einem x86-Anweisungssatzkern 1616 repräsentiert einen beliebigen Prozessor, der im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern durchführen kann, indem er Folgendes kompatibel ausführt oder anderweitig verarbeitet: (1) einen wesentlichen Teil des Anweisungssatzes des Intel-x86-Anweisungssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software, die auf einem Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern laufen sollen, um im Wesentlichen das gleiche Ergebnis wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern zu erreichen. Der x86-Compiler 1604 repräsentiert einen Compiler, der betrieben werden kann, um x86-Binärcode 1606 (z. B. Objektcode) zu generieren, der ohne oder mit zusätzlicher Verlinkungsverarbeitung auf dem Prozessor mit mindestens einem x86-Anweisungssatzkern 1616 ausgeführt werden kann. Gleichermaßen zeigt 16, dass das Programm in der höheren Sprache 1602 unter Verwendung eines Compilers für einen alternativen Anweisungssatz 1608 compiliert werden kann, um Binärcode eines alternativen Anweisungssatzes 1610 zu generieren, der nativ von einem Prozessor ohne mindestens einen x86-Anweisungssatzkern 1614 ausgeführt werden kann (z. B. einem Prozessor mit Kernen, die den MIPS-Anweisungssatz von MIPS Technologies in Sunnyvale, CA und/oder die den ARM-Anweisungssatz von ARM Holdings in Sunnyvale, CA ausführen). Der Anweisungswandler 1612 wird verwendet, um den x86-Binärcode 1606 in Code umzuwandeln, der nativ vom Prozessor ohne einen x86-Anweisungssatzkern 1614 ausgeführt werden kann. Es ist unwahrscheinlich, dass dieser umgewandelte Code der gleiche wie der Binärcode eines alternativen Anweisungssatzes 1610, da ein Anweisungswandler, der dazu fähig ist, schwer herzustellen ist; dennoch wird der umgewandelte Code die allgemeine Operation erzielen und aus Anweisungen aus dem alternativen Anweisungssatz bestehen. Deshalb repräsentiert der Anweisungswandler 1612 Software, Firmware, Hardware oder eine Kombination davon, die durch Emulation, Simulation oder einen beliebigen anderen Prozess einem Prozessor oder einer anderen Elektronikeinrichtung erlaubt, der bzw. die keinen x86-Anweisungssatzprozessor oder -Kern aufweist, den x86-Binärcode 1606 auszuführen.
  • 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
    • Handbuch für Software-Entwickler zur Intel®-64- und IA-32-Architektur, April 2015 [0061]
    • Programmierreferenz für Befehlssatzerweiterungen für die Intel®-Architektur, Oktober 2014 [0061]

Claims (25)

  1. Hardwarevorrichtung, die Folgendes umfasst: einen Hardware-Prozessor, der einen Kern aufweist; eine Vielzahl von Energiedomänen, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne überzugehen; und eine Energietransaktionseinheit, um: einen ersten Energieverwaltungsbefehl als eine erste Energietransaktion und einen zweiten Energieverwaltungsbefehl als eine zweite Energietransaktion für eine nebenläufige Ausführung zuzuweisen, eine Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion durchzuführen, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt, und einen Abbruch der ersten Energietransaktion und eine Festschreibung der zweiten Energietransaktion durchzuführen, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt.
  2. Hardwarevorrichtung nach Anspruch 1, wobei die erste Energietransaktion und die zweite Energietransaktion jeweils mehrere Anweisungen enthalten.
  3. Hardwarevorrichtung nach Anspruch 1, die ferner eine Vielzahl von Energiezustandsregistern umfasst, um den Energieverwaltungsbefehl für jede Domäne zu empfangen.
  4. Hardwarevorrichtung nach Anspruch 3, wobei der Konflikt ist, dass die erste Energietransaktion in ein Energiezustandsregister schreiben soll, in das die zweite Energietransaktion geschrieben hat.
  5. Hardwarevorrichtung nach Anspruch 1, wobei die Energietransaktionseinheit keine Sperre ausgeben soll.
  6. Hardwarevorrichtung nach Anspruch 1, wobei der Konflikt ist, dass die erste Energietransaktion und die zweite Energietransaktion widersprüchliche Energieverwaltungsbefehle für eine gemeinsam genutzte Energiedomäne schreiben sollen.
  7. Hardwarevorrichtung nach Anspruch 1, wobei, wenn es den Konflikt gibt, ein Übergang einer Energiedomäne als Antwort auf Ausführung der zweiten Energietransaktion nur nach der Festschreibung der zweiten Energietransaktion für andere Transaktionen sichtbar ist.
  8. Hardwarevorrichtung nach irgendeinem der Ansprüche 1–7, die ferner eine Speichertransaktionseinheit umfasst, um eine Festschreibung eines ersten Threads und eines zweiten Threads nach nebenläufiger Ausführung des ersten Threads auf dem Kern und des zweiten Threads auf einem zweiten Kern des Hardwareprozessors durchzuführen, falls der erste Thread und der zweite Thread nicht eine gleiche Speicheradresse modifizieren sollen.
  9. Verfahren, das Folgendes umfasst: Bereitstellen einer Vielzahl von Energiedomänen einer Hardwarevorrichtung, die einen Hardwareprozessor enthält, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne überzugehen; Zuweisen eines ersten Energieverwaltungsbefehls als eine erste Energietransaktion und eines zweiten Energieverwaltungsbefehls als eine zweite Energietransaktion für eine nebenläufige Ausführung; Durchführen einer Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt; und Durchführen eines Abbruchs der ersten Energietransaktion und einer Festschreibung der zweiten Energietransaktion, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt.
  10. Verfahren nach Anspruch 9, wobei die erste Energietransaktion und die zweite Energietransaktion jeweils mehrere Anweisungen enthalten.
  11. Verfahren nach Anspruch 9, das ferner ein Empfangen des Energieverwaltungsbefehls für jede Domäne an einem Energiezustandsregister umfasst.
  12. Verfahren nach Anspruch 11, wobei der Konflikt ist, dass die erste Energietransaktion in ein Energiezustandsregister schreibt, in das die zweite Energietransaktion geschrieben hat.
  13. Verfahren nach Anspruch 9, wobei keine Sperre erteilt wird.
  14. Verfahren nach Anspruch 9, wobei der Konflikt ist, dass die erste Energietransaktion und die zweite Energietransaktion widersprüchliche Energieverwaltungsbefehle für eine gemeinsam genutzte Energiedomäne schreiben.
  15. Verfahren nach Anspruch 9, wobei, wenn es den Konflikt gibt, ein Übergang einer Energiedomäne als Antwort auf Ausführung der zweiten Energietransaktion nur nach Durchführung der Festschreibung der zweiten Energietransaktion für andere Transaktionen sichtbar ist.
  16. Verfahren nach irgendeinem der Ansprüche 9–15, das ferner ein Durchführen einer Festschreibung eines ersten Threads und eines zweiten Threads nach nebenläufiger Ausführung des ersten Threads und des zweiten Threads auf dem Hardwareprozessor umfasst, falls der erste Thread und der zweite Thread nicht eine gleiche Speicheradresse modifizieren sollen.
  17. Nicht-transitorisches maschinenlesbares Speichermedium, das gespeicherten Programmcode aufweist, der bei Verarbeitung durch eine Maschine bewirkt, dass ein Verfahren durchgeführt wird, wobei das Verfahren Folgendes umfasst: Bereitstellen einer Vielzahl von Energiedomänen einer Hardwarevorrichtung, die einen Hardwareprozessor enthält, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne überzugehen; Zuweisen eines ersten Energieverwaltungsbefehls als eine erste Energietransaktion und eines zweiten Energieverwaltungsbefehls als eine zweite Energietransaktion für eine nebenläufige Ausführung; Durchführen einer Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt; und Durchführen eines Abbruchs der ersten Energietransaktion und einer Festschreibung der zweiten Energietransaktion, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt.
  18. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 17, wobei die erste Energietransaktion und die zweite Energietransaktion jeweils mehrere Anweisungen enthalten.
  19. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 17, wobei das Verfahren ferner ein Empfangen des Energieverwaltungsbefehls für jede Domäne an einem Energiezustandsregister umfasst.
  20. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 19, wobei der Konflikt ist, dass die erste Energietransaktion in ein Energiezustandsregister schreibt, in das die zweite Energietransaktion geschrieben hat.
  21. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 17, wobei das Verfahren enthält, dass keine Sperre ausgegeben wird.
  22. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 17, wobei der Konflikt ist, dass die erste Energietransaktion und die zweite Energietransaktion widersprüchliche Energieverwaltungsbefehle für eine gemeinsam genutzte Energiedomäne schreiben.
  23. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 17, wobei, wenn es den Konflikt gibt, ein Übergang einer Energiedomäne als Antwort auf Ausführung der zweiten Energietransaktion nur nach Durchführung der Festschreibung der zweiten Energietransaktion für andere Transaktionen sichtbar ist.
  24. Nicht-transitorisches maschinenlesbares Speichermedium nach irgendeinem der Ansprüche 17–23, wobei das Verfahren ferner ein Durchführen einer Festschreibung eines ersten Threads und eines zweiten Threads nach nebenläufiger Ausführung des ersten Threads und des zweiten Threads auf dem Hardwareprozessor umfasst, falls der erste Thread und der zweite Thread nicht eine gleiche Speicheradresse modifizieren sollen.
  25. Hardwarevorrichtung, die Folgendes umfasst: einen Hardware-Prozessor, der einen Kern aufweist; eine Vielzahl von Energiedomänen, um in einen von einer Vielzahl von Energiezuständen als Antwort auf einen Energieverwaltungsbefehl für jede Energiedomäne überzugehen; und Mittel, um: einen ersten Energieverwaltungsbefehl als eine erste Energietransaktion und einen zweiten Energieverwaltungsbefehl als eine zweite Energietransaktion für eine nebenläufige Ausführung zuzuweisen, eine Festschreibung der ersten Energietransaktion und der zweiten Energietransaktion durchzuführen, wenn es keinen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt, und einen Abbruch der ersten Energietransaktion und eine Festschreibung der zweiten Energietransaktion durchzuführen, wenn es einen Konflikt zwischen der ersten Energietransaktion und der zweiten Energietransaktion gibt.
DE102016006399.8A 2015-06-27 2016-05-25 Hardwarevorrichtungen und verfahren zum durchführen von transaktionaler energieverwaltung Withdrawn DE102016006399A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/752,896 2015-06-27
US14/752,896 US9733689B2 (en) 2015-06-27 2015-06-27 Hardware apparatuses and methods to perform transactional power management

Publications (1)

Publication Number Publication Date
DE102016006399A1 true DE102016006399A1 (de) 2016-12-29

Family

ID=56080322

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016006399.8A Withdrawn DE102016006399A1 (de) 2015-06-27 2016-05-25 Hardwarevorrichtungen und verfahren zum durchführen von transaktionaler energieverwaltung

Country Status (8)

Country Link
US (2) US9733689B2 (de)
EP (1) EP3109728A1 (de)
JP (1) JP6272942B2 (de)
KR (1) KR101804677B1 (de)
CN (1) CN106293894B (de)
BR (1) BR102016012083A2 (de)
DE (1) DE102016006399A1 (de)
TW (1) TWI733672B (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10216245B2 (en) * 2015-12-22 2019-02-26 Cray Inc. Application ramp rate control in large installations
US10133341B2 (en) * 2016-06-06 2018-11-20 Arm Limited Delegating component power control
EP3422192B1 (de) * 2017-06-28 2020-08-12 Arm Ltd Adressübersetzungsdatenungültigkeitserklärung
US10642341B2 (en) * 2018-03-23 2020-05-05 Juniper Networks, Inc. Selective modification of power states based on conditions
KR20200135780A (ko) 2018-03-30 2020-12-03 프로비노 테크놀로지스, 아이엔씨. 인터커넥트와 연관된 가상 채널을 통한 트랜잭션의 부분들 중재하기
JP7383631B2 (ja) 2018-03-30 2023-11-20 グーグル エルエルシー システムオンチップ（ＳｏＣ）エージェントのリセットおよび電力管理のためのプロトコルレベル制御
WO2023287436A1 (en) * 2021-07-16 2023-01-19 Google Llc Power sequencer for power state management

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3906015B2 (ja) * 2000-07-12 2007-04-18 株式会社東芝 クロック周波数切り替え機能を有するｌｓｉ、計算機システム及びクロック周波数切り替え方法
US7685365B2 (en) * 2004-09-30 2010-03-23 Intel Corporation Transactional memory execution utilizing virtual memory
US9785462B2 (en) 2008-12-30 2017-10-10 Intel Corporation Registering a user-handler in hardware for transactional memory event handling
US8423802B2 (en) * 2010-04-07 2013-04-16 Andes Technology Corporation Power scaling module and power scaling unit of an electronic system having a function unit in a standby state which is insensitive to change in frequency or voltage during synchronization
US8601288B2 (en) 2010-08-31 2013-12-03 Sonics, Inc. Intelligent power controller
JP5636276B2 (ja) * 2010-12-27 2014-12-03 ルネサスエレクトロニクス株式会社 半導体装置
US8868941B2 (en) 2011-09-19 2014-10-21 Sonics, Inc. Apparatus and methods for an interconnect power manager
JP5833434B2 (ja) * 2011-12-28 2015-12-16 ルネサスエレクトロニクス株式会社 半導体装置
CN102681937B (zh) * 2012-05-15 2016-05-18 浪潮电子信息产业股份有限公司 一种缓存一致性协议正确性验证方法
US8984313B2 (en) 2012-08-31 2015-03-17 Intel Corporation Configuring power management functionality in a processor including a plurality of cores by utilizing a register to store a power domain indicator
US9304954B2 (en) * 2012-10-24 2016-04-05 Texas Instruments Incorporated Multi processor bridge with mixed Endian mode support
US8959576B2 (en) * 2013-03-14 2015-02-17 Intel Corporation Method, apparatus, system for qualifying CPU transactions with security attributes
US9928264B2 (en) * 2014-10-19 2018-03-27 Microsoft Technology Licensing, Llc High performance transactions in database management systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Programmierreferenz für Befehlssatzerweiterungen für die Intel®-Architektur, Oktober 2014

Also Published As

Publication number Publication date
US20160378160A1 (en) 2016-12-29
US10768680B2 (en) 2020-09-08
JP6272942B2 (ja) 2018-01-31
TW201716923A (zh) 2017-05-16
JP2017016639A (ja) 2017-01-19
US20180059766A1 (en) 2018-03-01
CN106293894B (zh) 2020-05-19
KR20170001577A (ko) 2017-01-04
CN106293894A (zh) 2017-01-04
US9733689B2 (en) 2017-08-15
EP3109728A1 (de) 2016-12-28
KR101804677B1 (ko) 2017-12-04
BR102016012083A2 (pt) 2017-12-12
TWI733672B (zh) 2021-07-21

Similar Documents

Publication Publication Date Title
DE102016006399A1 (de) Hardwarevorrichtungen und verfahren zum durchführen von transaktionaler energieverwaltung
DE112017000721T5 (de) Verfahren, einrichtung und befehle für thread-aussetzung auf benutzerebene
DE102014003798B4 (de) Verfahren zum Booten eines heterogenen Systems und Präsentieren einer symmetrischen Kernansicht
DE112017001825T5 (de) Prozessoren, verfahren, systeme und instruktionen zum atomischen speichern von daten, die breiter als eine nativ unterstützte datenbreite sind, in einem speicher
DE112013004751T5 (de) Prozessor mit mehreren Kernen, gemeinsam genutzter Kernerweiterungslogik und gemeinsam genutzten Kernerweiterungsnutzungsbefehlen
DE112016007566T5 (de) Systeme, Verfahren und Vorrichtungen zur heterogenen Berechnung
DE112012007115T5 (de) Wahlweise Logikprozessor-Zählung und Typauswahl für eine gegebene Arbeitsbelastung basierend auf Wärme- und Leistungsbudget-Einschränkungen der Plattform
DE102014003689A1 (de) Verfolgung des kontrollflusses von befehlen
DE102014003671A1 (de) Prozessoren, verfahren und systeme zum entspannen der synchronisation von zugriffen auf einen gemeinsam genutzten speicher
DE112013003731T5 (de) Neue befehls- und hocheffiziente Mikroarchitektur zum ermöglichen einer sofortigen Kontextumschaltung für Benutzerebenen-Threading
DE102014003399A1 (de) Systeme und Verfahren zur Implementierung transaktionalen Speichers
DE112016004960T5 (de) Befehl und logik, um informationen im voraus aus einem beständigen speicher zu holen
DE112010004963T5 (de) Synchronisieren von SIMD Vektoren
DE202016009016U1 (de) Befehle und Logik für wiederkehrende benachbarte Sammlungen
DE112013004800T5 (de) Anweisung zur Bitverschiebung nach links mit Ziehen von Einsen in niedrigwertigere Bit
DE102016006402A1 (de) Persistente commit-prozessoren, verfahren, systeme und befehle
DE112013005368T5 (de) Prozessoren, verfahren und systeme für echtzeit-befehlsverfolgung
DE102018002294A1 (de) Effizientes bereichsbasiertes speicher-rückschreiben zum verbessern der host-zu-geräte-kommunikation für optimale energie und leistung
DE112017001700T5 (de) Prozessoren, Verfahren, Systeme und Anweisungen zum Abruf von Daten auf der angegebenen Cache-Ebene mit garantiertem Abschluss
DE112016007516T5 (de) Vorrichtungen und verfahren für eine prozessorarchitektur
DE102018002525A1 (de) Hybridatomaritätsunterstützung für einen binärübersetzungsbasierten mikroprozessor
DE102018132521A1 (de) Vorrichtung und verfahren zur verflachung und reduktion von schleifen in einer single instruction, multiple data- (simd-) pipeline
DE112016005863T5 (de) Minimierung von Snoop-Verkehr lokal und über Kerne auf einem Chip-Mehrkern-Fabric
DE112017001716T5 (de) Speicherkopierbefehle, prozessoren, verfahren und systeme
DE102018004727A1 (de) Verfahren und System zum Durchführen von Datenbewegungsoperationen mit Lese-Snapshot und In-Place-Schreibaktualisierung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: SAMSON & PARTNER PATENTANWAELTE MBB, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee