-
HINTERGRUND
-
Querverweis
-
Die vorliegende Anmeldung ist verwandt mit der, und beansprucht den Nutzen der, vorläufigen Anmeldung mit der Seriennummer 61/801615, eingereicht am 15.03.2013, die durch Bezugnahme in den vorliegenden Text aufgenommen wird.
-
Gebiet der Erfindung
-
Diese Erfindung betrifft allgemein das Gebiet der Computerprozessoren. Insbesondere betrifft die Erfindung einen Prozessor.
-
Beschreibung des Standes der Technik
-
Moderne handgehaltene Geräte sind aufgrund ihrer geringen Größe sowohl hinsichtlich ihres Stromverbrauchs als auch ihrer Wärmedissipation Beschränkungen unterworfen. Dennoch erwarten die Verbraucher eine immer höher entwickelte Funktionalität, die zunehmend höhere Rechenleistung erfordert. Um sowohl einen geringeren Stromverbrauch als auch höhere Rechenressourcen bereitzustellen, können heterogene Prozessoren verwendete werden. Heterogene Computerarchitekturen bieten unverkennbare Vorteile gegenüber homogenen Architekturen, weil mehrere Arten von Rechenelementen verfügbar sind, um Rechenaufgaben auszuführen, was es erlaubt, dass weniger rechenintensive Aufgaben durch ein energieeffizientes Rechenelement ausgeführt werden, während stärker rechenintensive Aufgaben in leistungsstärkeren Rechenelementen ausgeführt werden.
-
Trotz der allgemein bekannten Vorteile heterogener Computerarchitekturen gibt es nur wenige Beispiele eines heterogenen Rechnens für CPU-Kerne in der realen Welt. Diese Architekturen erfordern es, dass Software weiß, wie Aufgaben zweckmäßig für die einzelnen CPU-Kern-Arten zu disponieren sind (in diesem Fall sind die Rechenelemente CPU-Kerne). Im Zuge der steten Weiterentwicklung von Hardware und der fortwährenden Veränderung der Kern-Typen ist es sehr schwierig für Software (zum Beispiel Betriebssysteme), immer über die verschiedenen Arten von CPU-Kernen Bescheid zu wissen, die verfügbar sind, und zu wissen, wie die Vorteile einer solchen Heterogenität effektiv zu nutzen sind.
-
US 2012/0 079 235 A1 und
US 2012/0079235 A1 betreffen Anwendungsplanung in Rechenplattformen mit heterogenen Mehrkernprozessoren.
US 2010/0153956 A1 betrifft Mehrkernprozessoren und Verfahren zur Verwendung derselben, die die Kernfunktionen basierend auf der Ausführung von Befehlen konfigurieren.
-
Figurenliste
-
Ein besseres Verständnis der vorliegenden Erfindung ergibt sich aus der folgenden detaillierten Beschreibung in Verbindung mit den folgenden Zeichnungen, in denen Folgendes zu sehen ist:
- 1A ist ein Blockschaubild, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-Out-of-Order-Ausgabe-/Ausführungs-Pipeline veranschaulicht,
- 1B ist ein Blockschaubild, das sowohl eine beispielhafte Ausführungsform eines In-Order-Architekturkerns als auch einen beispielhaften Registerumbenennungs-Out-of-Order-Ausgabe-/Ausführungs- Architekturkern veranschaulicht, der in einen Prozessor gemäß Ausführungsformen der Erfindung zu integrieren ist;
- 2 ist ein Blockschaubild eines Einkern-Prozessors und eines Mehrkern-Prozessors mit integriertem Speicher-Controller und Grafik gemäß Ausführungsformen der Erfindung;
- 3 veranschaulicht ein Blockschaubild eines Systems;
- 4 veranschaulicht ein Blockschaubild eines zweiten Systems;
- 5 veranschaulicht ein Blockschaubild eines dritten Systems;
- 6 veranschaulicht ein Blockschaubild eines Systems auf einem Chip (SoC);
- 7 veranschaulicht ein Blockschaubild, das als Gegensatz die Verwendung eines Software-Instruktionskonverters zum Konvertieren binärer Instruktionen in einem Quelleninstruktionssatz zu binären Instruktionen in einem Zielinstruktionssatz;
- 8 veranschaulicht eine Ausführungsform einer Computerarchitektur mit heterogenem Kern.
- 9A und 9B sind Flussdiagramme einer Übersicht eines Systembootablaufs.
- 10 ist ein Sequenzschaubild, das das Passieren von Daten und Meldungen zwischen Firmware und Mikrocode-Elementen veranschaulicht.
- 11A-11B veranschaulichen eine Ausführungsform eines Systems mit einem verborgenen großen Kern und mehreren sichtbaren kleinen Kernen.
-
DETAILLIERTE BESCHREIBUNG
-
In der folgenden Beschreibung werden zum Zweck der Erläuterung zahlreiche konkrete Details dargelegt, um ein gründliches Verständnis der unten beschriebenen Ausführungsformen der Erfindung zu ermöglichen. Dem Fachmann ist j edoch klar, dass die Ausführungsformen der Erfindung auch ohne einige dieser konkreten Details praktiziert werden können. In anderen Fällen sind allgemein bekannte Strukturen und Vorrichtungen in Blockschaubildform gezeigt, um zu vermeiden, dass die zugrunde liegenden Prinzipien der Ausführungsformen der Erfindung in den Hintergrund treten.
-
Beispielhafte Prozessorarchitekturen und Datentypen
-
1A ist ein Blockschaubild, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-Out-of-Order-Ausgabe-/Ausführungs-Pipeline veranschaulicht. 1B ist ein Blockschaubild, das sowohl eine beispielhafte Ausführungsform eines In-Order-Architekturkerns als auch einen beispielhaften Registerumbenennungs-Out-of-Order-Ausgabe /Ausführungs- Architekturkern veranschaulicht, der in einen Prozessor gemäß Ausführungsformen der Erfindung zu integrieren ist. Die Kästchen mit den durchgezogenen Linien in den 1A-B veranschaulichen die In-Order-Pipeline und den In-Order-Kern, während die optionale Hinzufügung der mit Strichlinien gezeichneten Kästchen die Registerumbenennungs-Out-of-Order-Ausgabe-/Ausführungs-Pipeline und den entsprechenden Kern veranschaulicht. Angesichts der Tatsache, dass der In-Order-Aspekt eine Teilmenge des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
-
In 1A enthält eine Prozessorpipeline 100 eine Holstufe 102, eine Längendecodierstufe 104, eine Decodierstufe 106, eine Zuordnungsstufe 108, eine Umbenennungsstufe 110, eine Disponierungsstufe (auch als eine Versand- oder Ausgabestufe bekannt) 112, eine Registerlese/Speicherlesestufe 114, eine Ausführungsstufe 116, eine Rückschreibe/Speicherschreibstufe 118, eine Ausnahmehandhabungsstufe 122 und eine Bindungsstufe 124.
-
1B zeigt den Prozessorkern 190, der eine Frontend-Einheit 130 enthält, die mit einer Ausführungsengine-Einheit 150 gekoppelt ist, und beide sind mit einer Speichereinheit 170 gekoppelt. Der Kern 190 kann ein Reduced Instruction Set Computing (RISC)-Kern, ein Complex Instruction Set Computing (CISC)-Kern, einen Very Long Instruction Word (VLIW)-Kern oder ein hybrider oder alternativer Kern-Typ sein. Als eine weitere Option kann der Kern 190 ein Spezialkern sein, wie zum Beispiel ein Netzwerk- oder Kommunikationskern, eine Kompressions-Engine, ein Koprozessorkern, ein Allzweck-Computergrafik-Verarbeitungseinheit (GPGPU)-Kern, ein Grafikkern oder dergleichen.
-
Die Frontend-Einheit 130 enthält eine Abzweigprädiktionseinheit 132, die mit einer Instruktions-Cache-Einheit 134 gekoppelt ist, die mit einem Instruktionsübersetzungspuffer (TLB) 136 gekoppelt ist, der mit einer Instruktionsholeinheit 138 gekoppelt ist, die mit einer Decodiereinheit 140 gekoppelt ist. Die Decodiereinheit 140 (oder der Decodierer) kann Instruktionen decodieren und als ein Ausgangssignal eine oder mehrere Mikrooperationen, Mikrocode-Eintrittspunkte, Mikroinstruktionen, andere Instruktionen oder andere Steuersignale generieren, die aus den ursprünglichen Instruktionen decodiert wurden oder diese auf sonstige Weise widerspiegeln oder davon abgeleitet sind. Die Decodiereinheit 140 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Zu Beispielen geeigneter Mechanismen gehören Nachschlagetabellen, Hardware-Implementierungen, programmierbare Logik-Arrays (PLAs), Mikrocode-Nurlesespeicher (ROMs) usw. In einer Ausführungsform enthält der Kern 190 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makroinstruktionen speichert (beispielsweise in der Decodiereinheit 140 oder auf sonstige Weise innerhalb der Frontend-Einheit 130). Die Decodiereinheit 140 ist mit einer Umbenennungs/Zuordnungs-Einheit 152 in der Ausführungsengine-Einheit 150 gekoppelt.
-
Die Ausführungsengine-Einheit 150 enthält die Umbenennungs/Zuordnungs-Einheit 152, die mit einer Retirement-Einheit 154 und einem Satz aus einer oder mehreren Disponierer-Einheiten 156 gekoppelt ist. Die eine oder die mehreren Disponierer-Einheiten 156 stellen eine beliebige Anzahl verschiedener Disponierer dar, einschließlich Reservierungsstationen, zentraler Instruktionsfenster usw. Die eine oder die mehreren Disponierer-Einheiten 156 sind mit den einen oder mehreren physikalischen Registerdateien-Einheiten 158 gekoppelt. Jede der einen oder mehreren physikalischen Registerdateien-Einheiten 158 stellt eine oder mehrere physikalische Registerdateien dar, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, wie zum Beispiel skalare ganze Zahlen, skalares Gleitkomma, gepackte ganze Zahlen, gepacktes Gleitkomma, Vektor/ganzzahlig, Vektor/Gleitkomma, Status (zum Beispiel ein Instruktionszeiger, der die Adresse der nächsten auszuführenden Instruktion ist), usw. In einer Ausführungsform umfasst die physikalische Registerdateien-Einheit 158 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine skalare Registereinheit. Diese Registereinheiten können Architektur-Vektorregister, Vektormaskenregister und Allzweck-Register bereitstellen. Die eine oder mehreren physikalischen Registerdateien-Einheiten 158 werden durch die Retirement-Einheit 154 überlappt, um verschiedene Möglichkeiten zu veranschaulichen, wie Registerumbenennung und Out-of-Order-Ausführung implementiert werden können (zum Beispiel unter Verwendung eines oder mehrerer Umordnungspuffer und einer oder mehrerer Retirement-Registerdateien; unter Verwendung einer oder mehrerer Zukunftsdateien, eines oder mehrerer Vergangenheitspuffer und einer oder mehrerer Retirement-Registerdateien; unter Verwendung von Registerabbildungen und eines Pools von Registern; usw.). Die Retirement-Einheit 154 und die eine oder mehreren physikalischen Registerdateien-Einheiten 158 sind mit den einen oder mehreren Ausführungsclustern 160 gekoppelt. Das eine oder die mehreren Ausführungscluster 160 enthalten einen Satz aus einer oder mehreren Ausführungseinheiten 162 und einen Satz aus einer oder mehreren Speicherzugriffseinheiten 164. Die Ausführungseinheiten 162 können verschiedene Operationen (zum Beispiel Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Arten von Daten (zum Beispiel skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, Vektor/ganzzahlig, Vektor/Gleitkomma) ausführen. Während einige Ausführungsformen eine Anzahl von Ausführungseinheiten enthalten können, die für spezielle Funktionen oder Sätze von Funktionen dediziert sind, brauchen andere Ausführungsformen nur eine einzige Ausführungseinheit zu enthalten, oder können mehrere Ausführungseinheiten enthalten, die allesamt alle Funktionen durchführen. Die eine oder mehreren Disponierer-Einheiten 156, die eine oder mehreren physikalischen Registerdateien-Einheiten 158 und das oder die Ausführungscluster 160 sind so gezeigt, dass sie auch zu mehreren vorhanden sein können, weil bestimmte Ausführungsformen separate Pipelines für bestimmte Arten von Daten/Operationen erzeugen (zum Beispiel eine skalare Ganzzahl-Pipeline, eine skalare Gleitkomma-/gepackte Ganzzahl-/gepackte Gleitkomma-/Vektor-Ganzzahl/-Vektor-Gleitkomma-Pipeline und/oder eine Speicherzugriffs-Pipeline, die jeweils ihre eigene Disponierer-Einheit, ihre eigene(n) physische(n) Registerdateien-Einheit(en) und/oder ihr eigenes Ausführungscluster haben - und im Fall einer separaten Speicherzugriffs-Pipeline werden bestimmte Ausführungsformen implementiert, in denen nur das Ausführungscluster dieser Pipeline die eine oder die mehreren Speicherzugriffseinheiten 164 hat). Es versteht sich des Weiteren, dass, wenn separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines Out-of-Order-Ausgabe/Ausführung und der Rest in-Order sein können.
-
Der Satz Speicherzugriffseinheiten 164 ist mit der Speichereinheit 170 gekoppelt, die eine Daten-TLB-Einheit 172 enthält, die mit einer Daten-Cache-Einheit 174 gekoppelt ist, die mit einer Level 2 (L2)-Cache-Einheit 176 gekoppelt ist. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 164 eine Ladeeinheit, eine Speicheradresseneinheit und eine Speicherdateneinheit enthalten, die jeweils mit der Daten-TLB-Einheit 172 in der Speichereinheit 170 gekoppelt sind. Die Instruktions-Cache-Einheit 134 ist des Weiteren mit einer Level 2 (L2)-Cache-Einheit 176 in der Speichereinheit 170 gekoppelt. Die L2-Cache-Einheit 176 ist mit einer oder mehreren anderen Cache-Ebenen und letztendlich mit einem Hauptspeicher gekoppelt.
-
Beispielsweise kann die beispielhafte Registerumbenennungs-Out-of-Order-Ausgabe-/Ausführungs-s-Kernarchitektur die Pipeline 100 wie folgt implementieren: 1) die Instruktionsholeinheit 138 führt die Hol- und Längendecodierstufen 102 und 104 aus; 2) die Decodiereinheit 140 führt die Decodierstufe 106 aus; 3) die Umbenennungs/Zuordnungs-Einheit 152 führt die Zuordnungsstufe 108 und die Umbenennungsstufe 110 aus; 4) die eine oder die mehreren Disponierer-Einheiten 156 führen die Disponierstufe 112 aus; 5) die eine oder die mehreren physischen Registerdateien-Einheiten 158 und die Speichereinheit 170 führen die Registerlese/Speicherlesestufe 114 aus; das Ausführungscluster 160 führt die Ausführungsstufe 116 aus; 6) die Speichereinheit 170 und die eine oder die mehreren physischen Registerdateien-Einheiten 158 führen die Rückschreibe/Speicherschreibstufe 118 aus; 7) verschiedene Einheiten können an der Ausnahmehandhabungsstufe 122 beteiligt sein; und 8) die Retirement-Einheit 154 und die eine oder die mehreren physischen Registerdateien-Einheiten 158 führen die Bindungsstufe 124 aus.
-
Der Kern 190 kann einen oder mehrere Instruktionssätze unterstützen (zum Beispiel den x86-Instruktionssatz (mit einigen Erweiterungen, die den neueren Versionen hinzugefügt wurden); den MIPS-Instruktionssatz von MIPS Technologies aus Sunnyvale, Kalifornien; den ARM-Instruktionssatz (mit optionalen weiteren Erweiterungen, wie zum Beispiel NEON) von ARM Holdings aus Sunnyvale, Kalifornien), einschließlich der im vorliegenden Text beschriebenen Instruktion(en). In einer Ausführungsform enthält der Kern 190 eine Logik zum Unterstützen einer Packdateninstruktionssatzerweiterung (zum Beispiel AVX1, AVX2 und/oder eine Form eines generischen Vektor-freundlichen Instruktionsformat (U=0 und/oder U=1), wie unten beschrieben), wodurch es ermöglicht wird, dass die Operationen, die durch viele Multimedia-Anwendungen verwendet werden, unter Verwendung von Packdaten ausgeführt werden können.
-
Es versteht sich, dass der Kern Multithreading unterstützen kann (das Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads), und dass er dies auf eine Vielzahl verschiedener Arten tun kann, einschließlich Time-Sliced-Multithreading, Simultaneous Multithreading (wenn ein einzelner physischer Kern einen logischen Kern für jeden der Threads bildet, so führt der physische Kern gleichzeitig Multithreading aus) oder einer Kombination davon (zum Beispiel Time-Sliced-Fetching und Decodieren und gleichzeitiges Multithreading danach, wie zum Beispiel bei der Intel® Hyperthreading-Technologie).
-
Obgleich eine Registerumbenennung im Kontext einer Out-of-Order-Ausführung beschrieben ist, versteht es sich, dass eine Registerumbenennung auch in einer In-order-Architektur verwendet werden kann. Obgleich die veranschaulichte Ausführungsform des Prozessors auch separate Instruktions- und Daten-Cache-Einheiten 134/174 und eine gemeinsam genutzte L2-Cache-Einheit 176 enthält, können alternative Ausführungsformen einen einzelnen internen Cache sowohl für Instruktionen als auch Daten haben, wie zum Beispiel einen internen Level 1 (L1)-Cache oder mehrere Ebenen von internem Cache. In einigen Ausführungsformen kann das System eine Kombination eines internen Cache und eines externen Cache, der außerhalb des Kerns und/oder des Prozessors liegt, enthalten. Alternativ kann der gesamte Cache außerhalb des Kerns und/oder des Prozessors liegen.
-
2 ist ein Blockschaubild eines Prozessors 200 gemäß Ausführungsformen der Erfindung, der mehrere Kerne haben kann, einen integrierten Speicher-Controller haben kann und eine integrierte Grafik haben kann. Die Kästchen mit den durchgezogenen Linien in 2 veranschaulichen einen Prozessor 200 mit einem einzelnen Kern 202A, einem Systemagenten 210, einem Satz aus einer oder mehreren Bus-Controller-Einheiten 216, während die optionale Hinzufügung der mit Strichlinien gezeichneten Kästchen einen alternativen Prozessor 200 mit mehreren Kernen 202A-N, einem Satz aus einer oder mehreren integrierten Speicher-Controller-Einheiten 214 in der Systemagenteinheit 210 und Speziallogik 208 veranschaulicht.
-
Somit können verschiedene Implementierungen des Prozessors 200 enthalten: 1) eine CPU mit der Speziallogik 208, die eine integrierte Grafik- und/oder Wissenschafts (Durchsatz)-Logik sein kann (die einen oder mehrere Kerne enthalten kann), und wobei die Kerne 202A-N ein oder mehrere Allzweck-Kerne (zum Beispiel Allzweck-In-Order-Kerne, Allzweck-Out-of-Order-Keme oder eine Kombination aus beidem); 2) einen Koprozessor mit den Kernen 202A-N, die eine großen Anzahl von Spezialkernen sind, die vor allem für Grafik und/oder Wissenschaft (Durchsatz) gedacht sind; und 3) einen Koprozessor mit den Kernen 202A-N, die eine große Anzahl von Allzweck-In-Order-Kernen sind. Somit kann der Prozessor 200 ein Allzweck-Prozessor, ein Koprozessor oder ein Spezial-Prozessor sein, wie zum Beispiel ein Netzwerk- oder Kommunikationsprozessor, eine Kompressions-Engine, ein Grafikprozessor, eine GPGPU (Allzweck-Grafikverarbeitungseinheit), ein durchsatzstarker Many Integrated Core (MIC)-Koprozessor (der 30 oder mehr Kerne enthält), ein eingebetteter Prozessor oder dergleichen. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 200 kann ein Teil eines oder mehrerer Substrate sein und/oder kann auf einem oder mehreren Substraten implementiert sein, wofür eine Reihe von Prozesstechnologien zum Einsatz kommen können, wie zum Beispiel BiCMOS, CMOS oder NMOS.
-
Die Speicherhierarchie enthält eine oder mehrere Cache-Ebenen innerhalb der Kerne, einen Satz aus einer oder mehreren gemeinsam genutzten Cache-Einheiten 206 und externen Speicher (nicht gezeigt), der mit dem Satz integrierter Speicher-Controller-Einheiten 214 gekoppelt ist. Der Satz gemeinsam genutzter Cache-Einheiten 206 kann einen oder mehrere Mid-Level-Caches enthalten, wie zum Beispiel Level 2 (L2)-, Level 3 (L3)-, Level 4 (L4)- oder andere Cache-Ebenen, einen Last-Level-Cache (LLC) und/oder Kombinationen davon. Obgleich in einer Ausführungsform eine Ring-gestützte Interconnect-Einheit 212 die integrierte Grafiklogik 208, den Satz gemeinsam genutzter Cache-Einheiten 206 und die Systemagenteinheit 210 und die eine oder die mehreren integrierten Speicher-Controller-Einheiten 214 verbindet, können alternative Ausführungsformen jede beliebige Anzahl allgemein bekannter Techniken zum Verbinden solcher Einheiten verwenden. In einer Ausführungsform wird die Kohärenz zwischen einer oder mehreren Cache-Einheiten 206 und den Kernen 202-A-N beibehalten.
-
In einigen Ausführungsformen sind einer oder mehrere der Kerne 202A-N zum Multithreading befähigt. Der Systemagent 210 enthält jenen Komponenten, die die Kerne 202A-N koordinieren und betreiben. Die Systemagenteinheit 210 kann beispielsweise eine Energiesteuereinheit (PCU) und eine Anzeigeeinheit enthalten. Die PCU kann Logik und Komponenten sein oder enthalten, die zum Regeln des Energiezustands der Kerne 202A-N und der integrierten Grafiklogik 208 benötigt werden. Die Anzeigeeinheit dient zum Ansteuern eines oder mehrerer extern angeschlossener Displays.
-
Die Kerne 202A-N können in Bezug auf den Architektur-Instruktionssatz homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 202A-N können in der Lage sein, denselben Instruktionssatz auszuführen, während andere nur in der Lage zu sein brauchen, eine Teilmenge jenes Instruktionssatzes oder einen anderen Instruktionssatz auszuführen. In einer Ausführungsform sind die Kerne 202A-N heterogen und enthalten sowohl die „kleinen“ Kerne als auch die „großen“ Kerne, wie unten beschrieben.
-
Die 3-6 sind Blockschaubilder beispielhafter Computer-Architekturen. Andere dem Fachmann bekannte Systemdesigns und -konfigurationen für Laptops, Desktops, handgehaltene PCs, Personal Digital Assistants, Engineering-Workstations, Server, Netzwerkgeräte, Netzwerk-Hubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikgeräte, Videospielegeräte, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Mediaplayer, handgehaltene Geräte und verschiedene andere elektronische Geräte sind ebenfalls geeignet. Generell ist eine enorme Vielfalt an Systemen oder elektronischen Geräten, die in der Lage sind, einen Prozessor und/oder andere im vorliegenden Text offenbarte Ausführungslogik zu enthalten, allgemein geeignet.
-
Wenden wir uns nun 3 zu, wo ein Blockschaubild eines Systems 300 gezeigt ist. Das System 300 kann einen oder mehrere Prozessoren 310, 315 enthalten, die mit einem Controller-Hub 320 gekoppelt sind. In einer Ausführungsform enthält der Controller-Hub 320 einen Grafikspeicher-Controller-Hub (GMCH) 390 und einen Eingabe/Ausgabe-Hub (IOH) 350 (die sich auf separaten Chips befinden können); der GMCH 390 enthält Speicher- und Grafik-Controller, an die ein Speicher 340 und ein Koprozessor 345 gekoppelt sind; der IOH 350 koppelt Eingabe/Ausgabe (E/A)-Geräte 360 mit dem GMCH 390. Alternativ sind einer oder beide der Speicher- und Grafik-Controller innerhalb des Prozessors integriert (wie im vorliegenden Text beschrieben); der Speicher 340 und der Koprozessor 345 sind direkt mit dem Prozessor 310 gekoppelt, und der Controller-Hub 320 in einem einzelnen Chip mit dem IOH 350.
-
Die optionale Art weiterer Prozessoren 315 ist in 3 mit durchbrochenen Linien angedeutet. Jeder Prozessor 310, 315 kann einen oder mehrere der im vorliegenden Text beschriebenen Verarbeitungskerne enthalten und kann eine Version des Prozessors 200 sein.
-
Der Speicher 340 kann beispielsweise dynamischer Direktzugriffsspeicher (DRAM), Phasenänderungsspeicher (PCM) oder eine Kombination von beiden sein. Für mindestens eine Ausführungsform kommuniziert der Controller-Hub 320 mit dem einen oder den mehreren Prozessoren 310, 315 über einen Multi-Drop-Bus, wie zum Beispiel einen Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle, wie zum Beispiel QuickPath Interconnect (QPI), oder eine ähnliche Verbindung 395.
-
In einer Ausführungsform ist der Koprozessor 345 ein Spezialprozessor, wie zum Beispiel ein durchsatzstarker MIC-Prozessor, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungs-Engine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Controller-Hub 320 einen integrierten Grafikbeschleuniger enthalten.
-
Es kann eine ganze Reihe von Unterschieden zwischen den physischen Ressourcen 310, 315 im Hinblick auf ein Spektrum relevanter Messgrößen geben, darunter Architektur, Mikroarchitektur, Thermik, Stromverbrauchscharakteristika und dergleichen.
-
In einer Ausführungsform führt der Prozessor 310 Instruktionen aus, die Datenverarbeitungsoperationen einer allgemeinen Art steuern. In die Instruktionen können Koprozessor-Instruktionen eingebettet sein. Der Prozessor 310 erkennt diese Koprozessor-Instruktionen als von einer Art, die durch den angeschlossenen Koprozessor 345 ausgeführt werden sollte. Dementsprechend gibt der Prozessor 310 diese Koprozessor-Instruktionen (oder Steuersignale, die Koprozessor-Instruktionen darstellen) auf einem Koprozessorbus oder einem anderen Interconnect an den Koprozessor 345 aus. Ein oder mehrere Koprozessoren 345 nehmen die empfangenen Koprozessor-Instruktionen entgegen und führen sie aus.
-
Wenden wir uns nun 4 zu, wo ein Blockschaubild eines ersten konkreteren beispielhaften Systems 400 gezeigt ist. Wie in 4 gezeigt, ist das Mehrprozessorsystem 400 ein Punkt-zu-Punkt-Interconnect-System und enthält einen ersten Prozessor 470 und einen zweiten Prozessor 480, die über ein Punkt-zu-Punkt-Interconnect 450 gekoppelt sind. Jeder der Prozessoren 470 und 480 kann eine Version des Prozessors 200 sein. In einer Ausführungsform sind die Prozessoren 470 und 480 die Prozessoren 310 bzw. 315, während der Koprozessor 438 der Koprozessor 345 ist. In einer anderen Ausführungsform sind die Prozessoren 470 und 480 der Prozessor 310 bzw. der Koprozessor 345.
-
Die Prozessoren 470 und 480 sind so gezeigt, dass sie integrierte Speicher-Controller (IMC)-Einheiten 472 bzw. 482 enthalten. Der Prozessor 470 enthält außerdem als Teil seiner Bus-Controller-Einheiten Punkt-zu-Punkt (P-P)-Schnittstellen 476 und 478; gleichermaßen enthält der zweite Prozessor 480 P-P-Schnittstellen 486 und 488. Die Prozessoren 470, 480 können Informationen über eine Punkt-zu-Punkt (P-P)-Schnittstelle 450 unter Verwendung von P-P-Schnittstellenschaltkreisen 478, 488 austauschen. Wie in 4 gezeigt, koppeln IMCs 472 und 482 die Prozessoren mit jeweiligen Speichern, und zwar einem Speicher 432 und einem Speicher 434, die Abschnitte von Hauptspeicher sein können, die lokal an die jeweiligen Prozessoren angeschlossen sind.
-
Die Prozessoren 470, 480 können jeweils Informationen mit einem Chipsatz 490 über individuelle P-P-Schnittstellen 452, 454 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltkreisen 476, 494, 486, 498 austauschen. Der Chipsatz 490 kann optional Informationen mit dem Koprozessor 438 über eine Hochleistungsschnittstelle 439 austauschen. In einer Ausführungsform ist der Koprozessor 438 ein Spezialprozessor, wie zum Beispiel ein durchsatzstarker MIC-Prozessor, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungs-Engine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.
-
Ein (nicht gezeigter) gemeinsam genutzter Cache kann in einem der Prozessoren oder außerhalb beider Prozessoren enthalten sein und kann dennoch mit den Prozessoren über ein P-P-Interconnect verbunden sein, dergestalt, dass die Informationen des lokalen Caches eines oder beider Prozessoren in dem gemeinsam genutzten Cache gespeichert werden können, falls ein Prozessor in einen niedrigeren Energiemodus versetzt wird.
-
Der Chipsatz 490 kann mit einem ersten Bus 416 über eine Schnittstelle 496 gekoppelt sein. In einer Ausführungsform kann der erste Bus 416 ein Peripheral Component Interconnect (PCI)-Bus oder ein Bus wie zum Beispiel ein PCI Express-Bus oder ein anderer E/A Interconnect-Bus der dritten Generation sein, obgleich der Schutzumfang der vorliegenden Erfindung nicht darauf beschränkt ist.
-
Wie in 4 gezeigt, können verschiedene E/A-Geräte 414 mit dem erstes Bus 416 gekoppelt sein, zusammen mit einer Busbrücke 418, die den ersten Bus 416 mit einem zweiten Bus 420 koppelt. In einer Ausführungsform sind ein oder mehrere weitere Prozessoren 415, wie zum Beispiel Koprozessoren, durchsatzstarke MIC-Prozessoren, GPGPUs, Beschleuniger (wie zum Beispiel Grafikbeschleuniger oder digitale Signalverarbeitungs (DSP)-Einheiten), feldprogrammierbare Gate-Arrays oder sonstige Prozessoren mit dem ersten Bus 416 gekoppelt. In einer Ausführungsform kann der zweite Bus 420 ein Low Pin Count (LPC)-Bus sein. Verschiedene Geräte können in einer Ausführungsform mit einem zweiten Bus 420 gekoppelt sein, einschließlich beispielsweise einer Tastatur und/oder einer Maus 422, Kommunikationsgeräten 427 und einer Speichereinheit 428, wie zum Beispiel einem Disk-Laufwerk oder einer anderen Massenspeichervorrichtung, die Instruktionen/Code und Daten 430 enthalten kann. Des Weiteren kann ein Audio-E/A 424 mit dem zweiten Bus 420 gekoppelt sein. Es ist zu beachten, dass auch andere Architekturen möglich sind. Beispielsweise kann ein System anstelle der Punkt-zu-Punkt-Architektur von 4 einen Multi-Drop-Bus oder eine andere derartige Architektur implementieren.
-
Wenden wir uns nun 5 zu, wo ein Blockschaubild eines zweiten konkreteren beispielhaften Systems 500 gezeigt ist. Gleiche Elemente in den 4 und 5 tragen gleiche Bezugszahlen, und bestimmte Aspekte von 4 wurden aus 5 weggelassen, um zu vermeiden, dass andere Aspekte von 5 in den Hintergrund treten.
-
5 veranschaulicht, dass die Prozessoren 470, 480 integrierten Speicher und E/A-Steuerungslogik („CL“) 472 bzw. 482 enthalten können. Somit enthält die
CL 472, 482 integrierte Speicher-Controller-Einheiten und E/A-Steuerungslogik.
5 veranschaulicht, dass nicht nur die Speicher 432, 434 mit der
CL 472, 482 gekoppelt sind, sondern ebenso, dass auch E/A-Geräte 514 mit der Steuerungslogik 472, 482 gekoppelt sind. Ältere E/A-Geräte 515 sind mit dem Chipsatz 490 gekoppelt.
-
6 zeigt ein Blockschaubild eines SoC 600. Ähnliche Elemente in 2 tragen gleiche Bezugszahlen. Außerdem sind mit Strichlinien gezeichneten Kästchen optionale Merkmale auf höherentwickelten SoCs. In 6 sind eine oder mehrere Interconnect-Einheiten 602 gekoppelt mit: einem Anwendungsprozessor 610, der einen Satz aus einem oder mehreren Kernen 202A-N und gemeinsam genutzten Cache-Einheiten 206 enthält; einer Systemagenteinheit 210; einer oder mehreren Bus-Controller-Einheiten 216; einer oder mehreren integrierten Speicher-Controller-Einheiten 214; einem Satz aus einem oder mehreren Koprozessoren 620, der eine integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor enthalten kann; einer statischen Direktzugriffsspeicher (SRAM)-Einheit 1430; einer Direktspeicherzugriffs (DMA)-Einheit 632; und einer Anzeigeeinheit 640 zum Koppeln mit einem oder mehreren externen Displays. In einer Ausführungsform enthalten der eine oder die mehreren Koprozessoren 620 einen Spezialprozessor, wie zum Beispiel einen Netzwerk- oder Kommunikationsprozessor, eine Komprimierungs-Engine, eine GPGPU, einen durchsatzstarken MIC-Prozessor, einen eingebetteten Prozessor oder dergleichen
-
Ausführungsformen der im vorliegenden Text offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungsansätze implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert werden, die auf programmierbaren Systemen ausgeführt werden, die mindestens einen Prozessor, ein Speichersystem (einschließlich flüchtigem und nicht-flüchtigem Speicher und/oder Speicherelementen), mindestens ein Eingabegerät und mindestens ein Ausgabegerät enthalten.
-
Programmcode, wie zum Beispiel Code 430, der in 4 veranschaulicht ist, kann auf Eingabe-Instruktionen angewendet werden, um die im vorliegenden Text beschriebenen Funktionen auszuführen und Ausgabe-Informationen zu generieren. Die Ausgabe-Informationen können auf ein oder mehrere Ausgabegeräte in bekannter Weise angewendet werden. Für die Zwecke dieser Anmeldung meint ein „Verarbeitungssystem“ jedes System, das einen Prozessor hat, wie zum Beispiel einen digitalen Signalprozessor (DSP), einen Mikrocontroller, einen anwendungsspezifischen integrierten Schaltkreis (ASIC) oder einen Mikroprozessor.
-
Der Programmcode kann in einer höheren prozeduralen oder objektorientierten Programmiersprache implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann außerdem gewünschtenfalls in Assembler- oder Maschinensprache implementiert werden. Der Geltungsbereich der im vorliegenden Text beschriebenen Mechanismen ist nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
-
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentative Instruktionen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors darstellt, die, wenn sie durch eine Maschine gelesen wird, die Maschine veranlasst, Logik zu bilden, mit der die im vorliegenden Text beschriebenen Techniken ausgeführt werden. Solche Darstellungen, die als „IP-Kerne“ bekannt sind, können auf einem greifbaren, maschinenlesbaren Medium gespeichert sein und an verschiedene Kunden oder Herstellungseinrichtungen verschickt werden, um in die Produktionsmaschinen geladen zu werden, die die Logik oder den Prozessor letztendlich herstellen.
-
Zu solchen maschinenlesbaren Speichermedien können beispielsweise nichttransitorische, greifbare Anordnungen von Artikeln gehören, die durch eine Maschine oder eine Vorrichtung hergestellt oder gebildet werden, einschließlich Speichermedien, wie zum Beispiel Festplatten, alle sonstigen Arten von Disks, einschließlich Floppy-Disks, optischer Disks, Compact Disk-Nurlesespeicher (CD-ROMs), Compact Disk-Rewritables (CD-RWs) und magnet-optischer Disks, Halbleiterbauelemente, wie zum Beispiel Nurlesespeicher (ROMs), Direktzugriffsspeicher (RAMs), wie zum Beispiel dynamischer Direktzugriffsspeicher (DRAMs), statischer Direktzugriffsspeicher (SRAMs), löschbarer programmierbarer Nurlesespeicher (EPROMs), Flash-Speicher, elektrisch löschbarer programmierbarer Nurlesespeicher (EEPROMs), Phasenänderungsspeicher (PCM), magnetischer oder optischer Karten, oder jede sonstige Art von Medium, das zum Speichern von elektronischen Instruktionen geeignet ist.
-
Dementsprechend enthalten Ausführungsformen der Erfindung auch nichttransitorische, greifbare maschinenlesbare Medien, die Instruktionen enthalten oder Designdaten enthalten, wie zum Beispiel Hardware Description Language (HDL), die Strukturen, Schaltkreise, Vorrichtungen, Prozessoren und/oder Systemmerkmale, die im vorliegenden Text beschrieben sind, definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
-
In einigen Fällen kann ein Instruktionskonverter verwendet werden, um eine Instruktion aus einem Quelleninstruktionssatz zu einem Zielinstruktionssatz zu konvertieren. Zum Beispiel kann der Instruktionskonverter eine Instruktion zu einer oder mehreren anderen Instruktionen übersetzen (zum Beispiel unter Verwendung statischer binärer Übersetzung, dynamischer binärer Übersetzung, einschließlich dynamischer Kompilation), morphen, emulieren oder auf sonstige Weise konvertieren, damit sie durch den Kern verarbeitet werden. Der Instruktionskonverter kann in Software, Hardware, Firmware oder einer Kombination davon implementiert werden. Der Instruktionskonverter kann sich auf dem Prozessor, außerhalb des Prozessors oder zum Teil auf dem Prozessor und zum Teil außerhalb des Prozessors befinden.
-
7 ist ein Blockschaubild, das als Gegensatz die Verwendung eines Software-Instruktionskonverters zum Konvertieren binärer Instruktionen in einem Quelleninstruktionssatz zu binären Instruktionen in einem Zielinstruktionssatz gemäß Ausführungsformen der Erfindung darstellt. In der veranschaulichten Ausführungsform ist der Instruktionskonverter ein Software-Instruktionskonverter, obgleich der Instruktionskonverter alternativ auch in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 7 zeigt ein Programm in einer höheren Sprache 702, das unter Verwendung eines x86-Kompilierers 704 kompiliert werden kann, um binären x86-Code 706 zu generieren, der nativ durch einen Prozessor mit mindestens einem x86-Instruktionssatz-Kern 716 ausgeführt werden kann. Der Prozessor mit mindestens einem x86-Instruktionssatz-Kern 716 stellt jeden Prozessor dar, der im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit mindestens einem x86-Instruktionssatz-Kern ausführen kann, indem er kompatibel ausführt oder auf sonstige Weise verarbeitet: (1) einen wesentlichen Abschnitt des Instruktionssatzes des Intel x86-Instruktionssatz-Kerns, oder (2) Objektcode-Versionen von Anwendungen oder anderer Software, die dafür gedacht ist, auf einem Intel-Prozessor mit mindestens einem x86-Instruktionssatz-Kern zu laufen, um im Wesentlichen das gleiche Ergebnis zu erreichen wie ein Intel-Prozessor mit mindestens einem x86-Instruktionssatz-Kern. Der x86-Kompilierer 704 stellt einen Kompilierer dar, der dafür geeignet ist, binären x86-Code 706 (zum Beispiel Objektcode) zu generieren, der, mit oder ohne zusätzliche Linkage-Verarbeitung, auf dem Prozessor mit mindestens einem x86-Instruktionssatz-Kern 716 ausgeführt werden kann. Gleichermaßen zeigt 7 das Programm in der höheren Sprache 702, das unter Verwendung eines alternativen Instruktionssatz-Kompilierers 708 kompiliert werden kann, um alternativen Instruktionssatz-Binärcode 710 zu generieren, der nativ durch einen Prozessor ohne mindestens einen x86-Instruktionssatz-Kern 714 ausgeführt werden kann (zum Beispiel einen Prozessor mit Kernen, die den MIPS-Instruktionssatz von MIPS Technologies aus Sunnyvale, Kalifornien, ausführen und/oder die den ARM-Instruktionssatz von ARM Holdings aus Cambridge, Großbritannien, ausführen). Der Instruktionskonverter 712 dient zum Konvertieren des binären x86-Codes 706 in Code, der nativ durch den Prozessor ohne einen x86-Instruktionssatz-Kern 714 ausgeführt werden kann. Es ist unwahrscheinlich, dass dieser konvertierte Code der gleiche wie der alternative Instruktionssatz-Binärcode 710 ist, weil ein dazu befähigter Instruktionskonverter nur schwierig herzustellen ist; jedoch wird der konvertierte Code die allgemeine Operation bewerkstelligen und aus Instruktionen aus dem alternativen Instruktionssatz bestehen. Somit stellt der Instruktionskonverter 712 Software, Firmware, Hardware oder eine Kombination davon dar, die es einem Prozessor oder einer anderen elektronischen Vorrichtung, der bzw. die keinen x86-Instruktionssatz-Prozessor oder -Kern besitzt, durch Emulation, Simulation oder sonstige Prozesse erlaubt, den binären x86-Code 706 auszuführen.
-
System-transparente heterogene Berechnungen
-
Die unten beschriebenen Ausführungsformen der Erfindung beseitigen das Problem der fehlenden Unterstützung für Heterogenität in einer System-Firmware-Schnittstelle und einem Betriebssystem (Operating System, OS), indem sie vollständig vor dem Systems verborgen wird und alle von der Heterogenität wissende Logik und Heuristik innerhalb des Prozessors integriert wird. Während in einer herkömmlichen CPU die Zuweisung von Aufgaben zu Kernen ausschließlich über Software (in der Regel durch das OS) erfolgt, wird in einer Ausführungsform der Erfindung diese Zuweisung in zwei Teile untergliedert. Die Software disponiert weiterhin Software-Prozesse zu den exponierten homogenen Kernen, während Hardware dynamisch Threads zwischen den exponierten Kernen und den verborgenen heterogenen Kernen umschaltet.
-
Durch Exponieren lediglich homogener Rechenelemente gegenüber dem System wird die heterogene Art der Hardware vollständig vor der Software verborgen, einschließlich der System-Firmware-Schnittstelle (zum Beispiel BIOS, EFI oder UEFI) und des OS und nahezu für alle mögliche Software auf Anwendungsebene. Das System bootet und arbeitet darum so, als wenn es auf einem Prozessor mit ausschließlich homogenen Kernen liefe. Die Prozessor-Hardware dieser Ausführungsform enthält Logik zum dynamischen Abbilden jedes der Rechenelemente, die gegenüber der Software exponiert sind, auf eines oder mehrere der verfügbaren verborgenen physikalischen Rechenelemente. Zusätzlich wahrt die Logik die Konsistenz des Betriebes in jeder Art von Prozessor und die Fähigkeit zum Migrieren der Arbeit zwischen den verschiedenen Kern-Typen. Der spezielle Mechanismus, durch den Hardware dynamisch die physikalischen Rechenelemente auswählt, ist für das System transparent.
-
Durch Einbinden einer heterogenen Auswahl von Rechenelementen kann die Prozessor-Hardware unter sehr verschiedenen Betriebsbedingungen mit sehr verschiedenen Arten von Berechnungsaufgaben immer sehr effizient arbeiten. Zum Beispiel kann eine CPU, die sowohl einen kleinen, Energie-effizienten Kern als auch einen großen, leistungsstarken Kern enthält, verwendet werden, um Software effizient zu Zeiten zu betreiben, wenn die Energie begrenzt ist (und Leistung nicht kritisch ist), und auch zu anderen Zeiten, wenn hohe Leistung benötigt wird (aber die Energie nicht beschränkt ist). Die Auswahl verschiedener Kombinationen von Rechenelementen innerhalb der Hardware basiert auf den Designanforderungen, den Arten von Aufgaben, die auf dem System ausgeführt werden müssen, und unter welchen Bedingungen.
-
Heterogene Systeme können verschiedene Arten von Rechenelementen enthalten, wie zum Beispiel Prozessorkerne, Grafikprozessoreinheiten (GPUs) und Festfunktionsbeschleuniger (zum Beispiel zum Beschleunigen häufiger Funktionen, wie zum Beispiel Sortierungen und Schleifen). In den unten dargelegten Ausführungsformen der Erfindung haben die heterogenen Systeme verschiedene Arten von Prozessorkernen - d. h. ein paar leistungsstarke Kerne und eine größere Anzahl von kleinen Energie-effizienten Kernen. Jedoch können die zugrunde liegenden Prinzipien der Erfindung auch mit anderen Arten von Rechenelementen verwendet werden.
-
8 veranschaulicht eine Ausführungsform einer Computerarchitektur mit heterogenem Kern, die im vorliegenden Text als „Hetero-UP“ 800 bezeichnet wird. In der Konfiguration des Hetero-UP 800 sind kleine Energie-effiziente Kerne 802 gegenüber der Software exponiert. Wenn eine Anwendung 806 zusätzliche Leistung benötigt, und wenn ein genügend großes Energiebudget verfügbar ist, so kann ein Abbilden von einem virtuellen auf einen physischen Kern Threads auf transparente Weise vom dem kleinen Energie-effizienten Kern 802 zu einem leistungsstarken großen physischen Kern 804 übertragen, der anstelle des kleinen Kerns arbeiten soll. In einer Ausführungsform managt eine Paketeinheit 805 die Gruppe heterogener Prozessorkerne, um anhand eines Energieprofils und des Rechendurchsatzbedarfs zu bestimmen, welche Prozessorkerne aktiviert und welche deaktiviert sind. Zum Zweck der folgenden Beschreibung des Boot-Prozesses bei einer Implementierung von Berechnungen mit heterogenen Kernen wird die Ausführungsform des Hetero-UP 800 als ein veranschaulichendes, aber nicht-einschränkendes Beispiel veranschaulicht.
-
Für die Ausführungsform des Hetero-UP 800 ist die Firmware-Schnittstelle nur in der Lage, die Plattformprozessoren als kleine Kerne aufzuzählen. Der große Kern wird vor der Software verborgen und kann nicht mittels herkömmlicher Aufzählungsverfahren, wie zum Beispiel CPUID, aufgezählt werden. Es ist jedoch anzumerken, dass auch andere Ausführungsformen einer Implementierung von Berechnungen mit heterogenen Kernen möglich sind, wie zum Beispiel eine Hetero-DOWN-Konfiguration, wobei ein leistungsstarker großer physischer Kern 804 sichtbar ist, während kleine Energie-effiziente Kerne 802 verborgen sind. In diesem Fall zählt die Firmware-Schnittstelle den Prozessor mit großem Kern.
-
In einer Ausführungsform sind spezialisierte Software-Tools, wie zum Beispiel Prozessor-Debug-Tools, in der Lage, die Art der verfügbaren physischen Kerne zu identifizieren, selbst wenn die Firmware-Schnittstelle und das OS nichts von dem heterogenen Verarbeitungssystem wissen. Die spezialisierten Software-Tools sind in der Lage, die Fähigkeit zum Umschalten zwischen Kernen zu deaktivieren oder zu aktivieren, und können Aktionen ausführen, wie zum Beispiel das Umschalten eines Threads von einem Kern-Typ zu einem anderen Kern-Typ zu erzwingen.
-
Obgleich transparente heterogene Berechnungen eine höhere Komplexität des Designs und der Entwicklung von Prozessor-Hardware mit sich bringen, bieten sie doch zahlreiche Vorteile für die Entwickler von Firmware-Schnittstellen und Betriebssystemen. Zunächst einmal braucht die Firmware-Schnittstelle, das OS oder die Anwendungssoftware nicht zu wissen, dass die CPU heterogene Kerne (oder andere Rechenelemente) hat, was bedeutet, dass ältere Software, einschließlich Betriebssystemen, weiterhin mit der beschriebenen Hardware funktionieren. Gleichermaßen brauchen künftige Betriebssysteme und Software-Anwendungen nicht ständig aktualisiert zu werden, um die Art von Heterogenität in jeder Hardware-Version widerzuspiegeln.
-
Zweitens ist die gesamte Heuristik, die durch Logik zum Abbilden von virtuellen auf physische Kerne implementiert wird, innerhalb der Hardware enthalten, oder ist innerhalb der Software oder Firmware, die im Bündel mit der Hardware geliefert wird, oder auf sonstige Weise durch den Prozessoranbieter bereitgestellt wird, enthalten. Folglich können künftige Hardwaredesigns mutigere und innovativere Auswahlmöglichkeiten im Hinblick auf Rechenelemente erlauben, da das ganze Ausmaß der Änderungen vor der Software verborgen bleibt und keine Software-Updates erforderlich sind.
-
Boot-Ablauf für transparente heterogene Berechnungen
-
Derzeitige heterogene Berechnungslösungen können erfordern, dass sowohl die Firmware-Schnittstelle als auch das Betriebssystem (OS) von den heterogenen Kernen wissen, was mit einer entsprechenden Software-Komplexität verbunden ist. Es ist jedoch möglich, eine Prozessorschnittstelle so zu gestalten, dass die Firmware-Schnittstelle und das OS so arbeiten, als würden sie auf einem einzigen Kern-Typ ausgeführt werden, obwohl sie in Wirklichkeit auf einem oder mehreren heterogenen Kernen arbeiten. Ein Verfahren besteht darin, eine Mikrocode-Schicht zu verwenden, um das Verhalten der anderen Arten von Kernen zu „emulieren“. Ein weiteres Verfahren besteht in der Verwendung von speziellem Mikrocode und Hardware auf Paketebene, um das Migrieren des ausführenden Threads zu dem richtigen Ausführungskern zu unterstützen (zum Beispiel niedrige Energie oder hohe Leistung).
-
Beim Hochfahren des Systems bestimmt die Art des Kerns, der gegenüber dem System exponiert ist, den durch die Firmware-Schnittstelle ausgeführten Boot-Ablauf. Während der Initialisierung der Firmware-Schnittstelle ruhen die verborgenen Kerne und können nicht durch das System verwendet werden, außer zur Verwendung spezialisierter Mikrocode-Routinen. Nachdem das OS initialisiert ist, können die anderen Kern-Typen verwendet werden, um den nötigen Initialisierungsablauf auszuführen. Falls das OS von dem heterogenen Verarbeitungssystem weiß, so werden die heterogenen Prozessorkerne für das OS sichtbar gemacht, das Aufgaben auf jedem der verschiedenen Prozessorkern-Typen direkt disponieren kann. In einer Ausführungsform abstrahiert ein OS, dem die Heterogenität bekannt ist, die Heterogenität der Prozessoren an Software, die auf dem OS abläuft, über Emulation oder virtuelle Prozessoren, wodurch eine homogene Abstraktionsschicht für die ausführende Software gebildet wird.
-
Falls das OS nichts von dem heterogenen Verarbeitungssystem weiß, so können verborgene Kerne unter Einsatz einer dynamischen Kernumschaltfunktionalität verwendet werden, die es dem heterogenen Prozessor erlaubt, ausführende Threads zwischen den verschiedenen Kernen dynamisch umzuschalten. Bei Verwendung dieses Verfahrens glaubt die Software, sie arbeite auf der Art von Kern, die für die Software sichtbar ist, und zwar ungeachtet des Kerns, auf dem die Software in Wirklichkeit arbeitet. Um die Systemtransparenz weiter zu verbessern, wird ein neuer „Maskierter C6“-Prozessorzustand bereitgestellt, wobei ein Prozessorkern in einen niedrigeren Energiezustand versetzt wird, in dem der Prozessorkern nahezu null Energie verbraucht, und in dem der Prozessorkern für die Systemsoftware unsichtbar gemacht wird. Auf einen Prozessorkern im Maskierten C6-Zustand kann nicht durch übliche Systemauslöser zugegriffen werden, sondern nur durch spezialisierte Mikrocode-Routinen.
-
Um die folgende Erläuterung zu vereinfachen, wird ein Hetero-UP 800-System verwendet, um einen beispielhaften Boot-Ablauf zu beschreiben, und die für das System sichtbaren Kerne sind die Energie-effizienten kleinen Kerne 802, die eine Teilmenge der leistungsstarken großen physischen Kerne 804 implementieren und weniger Energie verbrauchen. Es versteht sich jedoch, dass Ausführungsformen nicht darauf beschränkt sind, da die folgende Beschreibung unabhängig von den Kern-Typen, ihrer Anzahl auf dem Prozessor und des Typs, der für die Firmware-Schnittstelle und das OS sichtbar ist, erfolgt.
-
9A und 9B sind Flussdiagramme einer Übersicht eines Systembootablaufs in einer Hetero-UP-Konfiguration gemäß einer Ausführungsform. Beginnend in 9a, bei 901, bereitet sich ein Plattform-Controller-Hub (PCH) auf das Booten des System vor, indem er Firmware-Schnittstellencode in einen für Mikrocode zugänglichen Speicherraum kopiert, wie zum Beispiel Universal Flash Storage (UFS) oder ein anderer durch einen Prozessor ausführbarer Speicherraum. Bei 902 nimmt eine Paket-Hardware-Einheit (zum Beispiel die Paketeinheit 805 von 8) alle kleinen Kerne aus dem Rücksetzungszustand, macht jeden kleinen Kern für die Firmware-Schnittstelle des Systems sichtbar und wählt einen der Energie-effizienten kleinen Kerne aus, zu einem Bootstrap-Prozessor (BSP) zu werden. Bei 904 aktualisiert der Prozessor mit kleinem Kern, der als der BSP ausgewählt wurde, seinen Mikrocode und führt ihn aus. Der B SP-Mikrocode enthält Instruktionen zum Aktivieren der zusätzlichen Prozessoren mit kleinem Kern, die als Anwendungsprozessoren verwendet werden.
-
Der BSP-Mikrocode kann ein Firmware-Schnittstellen-Hochfahrmodul enthalten, das durch den BSP während des ersten Boot-Schrittes geladen wird. Der BSP kommuniziert mit den anderen Prozessoren mittels Verwendung von Inter-Prozessor-Interrupts (IPI). Optional verwendet der BSP bei 910a, 910b und 910c Inter-Prozessor-Interrupts (IPI), um jeden AP mit kleinem Kern auszulösen, allen verfügbaren Vor-Boot-Mikrocode zu laden. Wie bei 912a, 912b und 912c gezeigt, führt jeder AP mit kleinem Kern seinen jeweiligen Anwendungsprozessor-Vor-Boot-Mikrocode aus, wozu auch das Initialisieren der Unterstützung für eine Maschinenüberprüfung gehört. In einer Ausführungsform werden frühere Maschinenüberprüfungsereignisse, die nicht durch die APs mit kleinem Kern gehandhabt werden, geloggt, und neue Maschinenüberprüfungsereignisse werden gehandhabt, sobald die Unterstützung für eine Maschinenüberprüfung aktiviert ist. Bei 914a, 914b und 914c tritt jeder AP mit kleinem Kern einen Leerlaufzustand ein, um auf einen Hochfahr-IPI (SIPI) vom BSP zu warten.
-
Gleichzeitig mit der Initialisierung des Anwendungsprozessors mit kleinem Kern wird ein Anwendungsprozessor mit großem Kern mit einer Supermenge der Anwendungsprozessoren mit kleinem Kern durch die Paketeinheit aktiviert und initialisiert, wie bei 908 gezeigt. In einer Ausführungsform sind ein oder mehrere große Kerne in Hardware verfügbar, aber werden über eine interne Sicherung deaktiviert, wobei in diesem Fall der große Kern nicht initialisiert wird.
-
Bei 916 bereitet sich der BSP darauf vor, den leistungsstarken AP mit großem Kern zu starten, was ein optionales Laden eines aktualisieren Patch für den Vor-Boot-Mikrocode für den großen Kern enthält. Bei 918 führt der große Kern Vor-Boot-Mikrocode aus, um den Kern für die Instruktionsausführung bereit zu machen. Bei 920 vollendet der Prozessor mit großem Kern die Vor-Boot-Sequenz und speichert den bereit gemachten Prozessorkontext. Bei 928 benachrichtigt der große Kern den BSP darüber, dass die Initialisierungssequenz für den großen Kern vollendet ist, und tritt in den Maskierten C6-Zustand ein. An diesem Punkt beendet der BSC den Firmware-Schnittstelle-Boot und bereitet den Start des OS vor, wie bei Block 930 gezeigt und in 9b weiter veranschaulicht ist.
-
Wir wenden uns 9b zu. Sobald das System-Firmware-Schnittstellenmodul, das auf dem BSP abläuft, fertig ist, wartet der BSP auf eventuelle APs mit kleinem Kern, die noch nicht das Laden ihres Mikrocode-Updates vollendet haben, wie bei 934 gezeigt. Bei 936 sendet der BSP ein SIPI-Ereignis an jeden der APs mit kleinem Kern. Bei 938 vollendet jeder AP mit kleinem Kern seinen Rücksetzungszyklus und tritt in einen Standard-C6-Zustand ein. An diesem Punkt sind ein Bootstrap-Prozessor mit kleinem Kern und Anwendungsprozessoren mit kleinem Kern verfügbar, die jeweils für das System sichtbar sind, während der große Kern im Maskierten C6-Zustand bleibt. Bei 940 versetzt der BSP die Paketeinheit in den Hetero-Aktivierungs-Modus, wodurch der Prozessor dynamisch Threads zu dem verborgenen heterogenen Kern umschalten kann.
-
Sobald die Initialisierung der Firmware-Schnittstelle vollendet ist, können die OS-Initialisierungsroutinen beginnen. Falls das OS keine heterogenen Prozessorsysteme unterstützt, kann das OS Aufgaben auf einem AP mit kleinem Kern disponieren, und die Prozessor-Hardware kann automatisch Aufgaben von dem einen der APs mit kleinem Kern zu einem AP mit großem Kern umschalten. Auf Software-Sicht arbeitet das System in einem vollständig homogenen Zustand. Der verborgene große Kern ist maskiert und vermeidet einen für die Software sichtbaren Zustand in dem System. Zum Beispiel hat der verborgene große Kern bei einem OS, das keine heterogenen Prozessorsysteme unterstützt, keine sichtbare höhere programmierbare Interrupt-Controller-ID, nimmt keine direkten Software-initiierten Inter-Prozessor-Interrupts entgegen und handhabt keine Maschinenüberprüfungsereignisse als gro-ßer Kern. In einer Ausführungsform werden ein oder mehrere verborgene Kerne des heterogenen Verarbeitungssystems gegenüber einem OS, das keine Kenntnis von der Heterogenität des Systems hat, exponiert, indem der Instruktionssatz der sichtbaren homogenen Kerne emuliert wird. Falls das OS heterogene Prozessorsysteme unterstützt, so kann das OS jeden der verschiedenen Kern-Typen gegenüber der Software exponieren und kann Software-Aufgaben auf den verschiedenen Kern-Typen disponieren. Außerdem kann ein OS, das Kenntnis von der Heterogenität des Systems hat, den Hardware-Mechanismus steuern, der zum Umschalten von Threads zwischen Kernen verwendet wird.
-
10 ist ein Sequenzschaubild, das veranschaulicht, wie Daten und Meldungen zwischen Firmware und Mikrocode-Elementen einer Ausführungsform einer heterogenen Verarbeitungssystem-Bootsequenz passieren. In einer Ausführungsform, wie bei 1002 gezeigt, sendet ein Satz Firmware-Schnittstelleninstruktionen, die durch eine Paketeinheit-Firmware 1000 ausgeführt werden, eine „Bootstrap-Prozessor (BSP) initialisieren“-Meldung an den Prozessor mit kleinem Kern, der als der BSP 1020 ausgewählt wurde. Die Paketeinheit 1000 löst eine Mikrocode-Aktualisierung aus und lädt 1004 einen Auslöser für den BSP 1020, und geht dann dazu über, die übrigen Anwendungsprozessoren mit kleinem Kern 1040 zu aktivieren, die für das System sichtbar sind. Eine Rendezvous-Initialisierungs-Sequenz 1024, die eine Mikrocode-Aktualisierung enthält, wird an jeden Anwendungsprozessor mit kleinem Kern 1040 gesendet, der für das Systems sichtbar ist, was bewirkt, dass jeder AP mit kleinem Kern in einen Rendezvous-Zustand eintritt.
-
Im Rendezvous-Zustand gibt jeder Prozessorenkern eines Mehrkern- oder Mehrprozessorsystems die Steuerung an einen einzelnen Kern oder Prozessor ab, der die Initialisierung managen oder eine Fehlerhandhabung für alle Prozessoren im System ausführen kann. In Reaktion auf das Empfangen der Rendezvous-Initialisierungs-Sequenz 2024 vom BSP 1020 treten die sichtbaren Anwendungsprozessoren mit kleinem Kern 1040 in eine Mikrocode-Aktualisierungs-Rendezvoussequenz 1046 ein, um den Mikrocode für jeden Prozessor zu laden und auszuführen. Nach der Initialisierung sendet jeder AP mit kleinem Kern 1040 eine Bestätigungsmeldung 1035 an den BSP 1020 und tritt dann in einen für das System sichtbaren Leerlaufzustand 1048 ein (zum Beispiel Standard-C6-Modus).
-
Der B SP 1020 sendet, gleichzeitig mit der Initialisierung der Anwendungsprozessoren mit kleinem Kern, eine Rendezvous-Initialisierungs-Sequenz 1026 an einen oder mehrere verborgene Anwendungsprozessoren mit großem Kern 1060. Der eine oder die mehreren Anwendungsprozessoren mit großem Kern 1060 treten in einen Mikrocode-Aktualisierungs-Rendezvous-Zustand 1068 ein, um den Mikrocode für jeden großen Kern 1060 zu laden. Der eine oder die mehreren Anwendungsprozessoren mit großem Kern 1060 senden eine Bestätigungsmeldung 1055 an den BSP 1020, wenn sie fertig sind, und treten in einen maskierten C6-Leerlaufzustand 1070 ein, in dem der Anwendungsprozessor mit großem Kern 1060 für die Firmware-Schnittstelle und das OS unsichtbar ist. Nachdem alle Kerne initialisiert sind, benachrichtigt der BSP 1020 die Paketeinheit 1000, dass alle Kerne initialisiert sind 1010, und das System bereitet sich auf das Laden des OS vor. In einer Ausführungsform weiß das OS von dem heterogenen Verarbeitungssystem, und nach der OS-Initialisierung wird der Anwendungsprozessor mit großem Kern 1060 für das OS sichtbar und ist zusammen mit den Anwendungsprozessoren mit kleinem Kern 1040 für Kernumschaltoperationen verfügbar. In einer Ausführungsform weiß das OS nichts von dem heterogenen Verarbeitungssystem, und das heterogene Verarbeitungssystem ermöglicht eine transparente Nutzung des Anwendungsprozessors mit großem Kern, ohne Anleitung durch das OS.
-
Die 11A-B veranschaulichen, wie eine Ausführungsform der Erfindung bei Bedarf einen kleinen Kern transparent gegen einen großen Kern tauscht. In einer Ausführungsform ermöglicht das Verbergen der Heterogenität vor der Firmware-Schnittstelle des Systems und das Integrieren aller von der Heterogenität wissenden Logik und Heuristik innerhalb des Prozessors eine transparente Unterstützung für Heterogenität. In einer herkömmlichen CPU erfolgt die Zuweisung von Aufgaben zu Kernen ausschließlich durch Software (in der Regel durch das OS). Jedoch wird in einer Ausführungsform diese Zuweisung in zwei Teile aufgegliedert. Die Software disponiert Software-Prozesse weiterhin zu den homogenen „virtuellen Kernen“, die durch den Prozessor exponiert werden, während Hardware dynamisch auswählt, welcher physische Kern-Typ einen bestimmten virtuellen Kern implementiert. Software-Disponierungsalgorithmen, die dazu dienen, Durchsatz, Leistung oder andere Eckdaten zu maximieren, funktionieren weiter, während Hardware eine andere (transparente) Schicht der Optimierung ausführt, wobei die Prozesse oder Threads, die auf jedem virtuellen Kern ablaufen, stets zu jenem physischen Kern gelenkt werden, der für die Art von Arbeitslast, die auf dem virtuellen Kern bewältigt wird, gerade am besten geeignet ist.
-
Wie in 11A veranschaulicht, enthält die Prozessor-Hardware eine Anzahl heterogener physischer Kerne, PC0-PC4 1150, die einen Satz kleiner Kerne PC0-PC3 und einen großen Kern PC4 enthalten. In dieser Ausführungsform sind homogene virtuelle Kerne VC0-VC3 1106 gegenüber Software exponiert. Ungeachtet der verschiedenen physischen Kern-Typen innerhalb des Systems werden die virtuellen Kerne jeweils als eine einzelne Art von Kern dargestellt; in diesem Fall der Typ mit kleinem Kern. Folglich disponiert ein Softwarebasierter Disponierer 1110 (der Teil eines OS sein kann) Threads 1101 zur Ausführung auf jedem der exponierten homogenen virtuellen Kerne 1106, so wie es in einem echten homogenen Mehrkernprozessor- oder Mehrprozessorsystem der Fall wäre. Eine Virtuell-zu-physisch (V-P)-Abbildungslogik 1130 bildet jeden virtuellen Kern 1120 auf einen oder mehrere geeignete physische Kerne 1150 gemäß einem Satz von Abbildungsregeln 1140 und anhand der momentan detektierten Zustände 1141 ab. Wie oben beschrieben, können die Abbildungsentscheidungen durch eine Abbildungsentscheidungslogik 1109 getroffen werden, die in Software, Hardware, Firmware oder beliebigen Kombinationen davon implementiert werden kann.
-
In einer Ausführungsform liegt eine standardmäßige 1:1-Abbildung zwischen den virtuellen Kernen 1106 und den kleinen Kernen PC0-PC3 vor. Folglich werden die kleinen Kerne PC0-PC3 praktisch für den Software-basierten Disponierer sichtbar gemacht. In einer Ausführungsform wird diese standardmäßige Abbildung beibehalten, wenn das System einen geringen Auslastungsgrad hat (unter einer spezifizierten Schwelle), und/oder wenn die meisten kleinen Kerne beschäftigt sind (zum Beispiel mit einer hohen Verarbeitungslast oberhalb einer spezifizierten Schwelle). Zum Beispiel wird in einer Ausführungsform diese standardmäßige Abbildung beibehalten, wenn das System einen geringen Auslastungsgrad hat (zum Beispiel kein Kern übersteigt 60 % Aktivität), oder wenn die meisten kleinen Kerne beschäftigt sind (zum Beispiel mehr als 75 % der insgesamt verfügbaren Kerne sind mehr als 60 % aktiv).
-
Jedoch verändert in einer Ausführungsform, wenn das System eine große Anzahl leerlaufender Kerne (zum Beispiel mehr als 50 % aller verfügbaren Kerne) und ein paar (ein oder mehrere) stark beanspruchte, sehr aktive Kerne hat, die durch die Abbildungsentscheidungslogik 1109 implementierte Heuristik automatisch die Abbildung, wie in 11B veranschaulicht. Hier werden nur zwei Threads 1101 durch den Disponierer 1110 zu virtuellen Kernen VC1 und VC2 disponiert, und mindestens einer der virtuellen Kerne (VC2 in dem Beispiel) hat eine Aktivität oberhalb einer spezifizierten Schwelle. Folglich hat in diesem Beispiel die V-P-Kernabbildungslogik 1130 den virtuellen Kern VC2 von dem kleinen physischen Kern PC2 auf den großen physischen Kern PC4 abgebildet, nachdem eine entsprechende Abbildungsentscheidung durch die Abbildungsentscheidungslogik 1109 getroffen wurde.
-
Wie im vorliegenden Text beschrieben, können sich Instruktionen auf konkrete Konfigurationen von Hardware beziehen, wie zum Beispiel anwendungsspezifische integrierte Schaltkreise (ASICs), die dafür konfiguriert sind, bestimmte Operationen auszuführen, oder die eine zuvor festgelegte Funktionalität oder Software-Instruktionen haben, die in einem Speicher gespeichert sind, der auf einem nicht-transitorischen computerlesbaren Medium verkörpert ist. Somit können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten implementiert werden, die in einer oder mehreren elektronischen Vorrichtungen gespeichert und ausgeführt werden (zum Beispiel einer Endstation, einem Netzwerkelement usw.). Solche elektronischen Vorrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netzwerk) Code und Daten unter Verwendung von computermaschinenlesbaren Medien, wie zum Beispiel nicht-transitorischen computermaschinenlesbaren Speichermedien (zum Beispiel magnetischen Disks; optischen Disks; Direktzugriffsspeicher; Nurlesespeicher; Flash-Speicherbauelementen; Phasenänderungsspeicher) und transitorischen computermaschinenlesbaren Kommunikationsmedien (zum Beispiel elektrische, optische, akustische oder andere Formen von ausgebreiteten Signalen, wie zum Beispiel Trägerwellen, Infrarotsignale, digitale Signale usw.).
-
Darüber hinaus enthalten solche elektronischen Vorrichtungen in der Regel einen Satz aus einem oder mehreren Prozessoren, die mit einer oder mehreren anderen Komponenten gekoppelt sind, wie zum Beispiel einer oder mehreren Speichervorrichtungen (nicht-transitorischen maschinenlesbaren Speichermedien), Nutzereingabe/Ausgabe-Vorrichtungen (zum Beispiel eine Tastatur, ein Touchscreen und/oder ein Display) und Netzwerkverbindungen. Das Koppeln des Satzes Prozessoren und anderer Komponenten erfolgt in der Regel durch einen oder mehrere Busse und Brücken (auch als Bus-Controller bezeichnet). Die Speichervorrichtung und die Signale, die den Netzwerkverkehr transportieren, stellen jeweils ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien dar.
-
Somit speichert die Speichervorrichtung eines bestimmten elektronischen Gerätes in der Regel Code und/oder Daten zur Ausführung auf dem Satz aus einem oder mehreren Prozessoren jenes elektronischen Gerätes. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung verschiedener Kombinationen von Software, Firmware und/oder Hardware implementiert werden. In dieser detaillierten Beschreibung wurden zum Zweck der Erläuterung zahlreiche konkrete Details dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu ermöglichen. Dem Fachmann ist jedoch klar, dass die Erfindung auch ohne einige dieser konkreten Details praktiziert werden kann. In bestimmten Fällen wurden allgemein bekannte Strukturen und Funktionen nicht besonders ausführlich beschrieben, um zu vermeiden, dass der Gegenstand der vorliegenden Erfindung in den Hintergrund tritt. Dementsprechend sind der Geltungsbereich und der Geist der Erfindung anhand der folgenden Ansprüche zu beurteilen.
