DE102014000372A1

DE102014000372A1 - Verbesserte steuerung des prefetch-traffics

Info

Publication number: DE102014000372A1
Application number: DE201410000372
Authority: DE
Inventors: Jason Meredith
Original assignee: Imagination Technologies Ltd
Current assignee: MIPS Tech LLC
Priority date: 2013-01-14
Filing date: 2014-01-14
Publication date: 2014-07-17
Also published as: US9658962B2; CN109446112B; GB2509765A; GB2513043B; GB2513043A; GB2513042A; GB201412476D0; GB201412477D0; US20140325159A1; GB201300646D0; GB2509765B; US20170220471A1; GB2513042B; US10754778B2; CN103927266A; CN103927266B; CN109446112A

Abstract

Verfahren und Systeme zur verbesserten Steuerung des von einem Prozessor erzeugten Traffics werden beschrieben. Wenn eine Vorrichtung in einer Ausführungsform eine Prefetch-Anforderung nach einer Information oder einer Anweisung aus einer Speicherhierarchie erzeugt, fügt die Vorrichtung der Anforderung eine Prefetch-Kennung bei. Diese Kennung zeichnet die Anforderung als eine Prefetch-Anforderung und nicht als eine Nicht-Prefetch-Anforderung, wie zum Beispiel eine zeitkritische Anforderung, aus. Auf dieser Kennung basierend kann die Speicherhierarchie dann zu Zeiten starken Traffics eine Abbruchantwort ausgeben, die den Prefetch-Traffic unterdrückt, da der Prefetch-Traffic von der Speicherhierarchie nicht erfüllt wird. Bei Erhalt einer Abbruchantwort löscht die Vorrichtung wenigstens einen Teil jedes Datensatzes der Prefetch-Anforderung, und falls die Information/Anweisung später benötigt wird, erfolgt die Ausgabe einer neuen Anforderung mit einer höheren Priorität als die ursprüngliche Prefetch-Anforderung.

Description

Hintergrund
Um die mit dem Zugreifen auf im Hauptspeicher abgelegte Daten verbundene Latenz zu reduzieren, arbeiten Prozessoren typischerweise mit einer Speicherhierarchie, die einen oder mehr Caches umfasst. Normalerweise sind zwei oder drei L1, L2 und L3 genannte Cache-Level vorhanden, und in einigen Beispielen kann es sich bei den ersten beiden Caches (L1 und L2) um On-Chip-Caches handeln, die normalerweise im SRAM (statisches RAM) implementiert werden, während der dritte Cache-Level (L3) ein Off-Chip-Cache sein kann. In anderen Beispielen, wie zum Beispiel bei einem System-on-Chip (SoC), kann der gesamte Speicher auf einem einzigen Stück Silizium implementiert sein. Die Caches sind kleiner als der Hauptspeicher, der in DRAM implementiert sein kann, aber die mit einem Zugreifen auf einen Cache verbundene Latenz ist viel kürzer als für den Hauptspeicher und verkürzt sich bei niedrigeren Levels innerhalb der Hierarchie (wobei der L1-Cache als Cache des niedrigsten Levels betrachtet wird). Da die Latenz zumindest annähernd mit der Größe des Cache zusammenhängt, ist der Cache eines niedrigeren Levels (z. B. L1) typischerweise kleiner als der Cache eines höheren Levels (z. B. L2).
Wenn ein Prozessor auf eine Information oder eine Anweisung zugreift, insbesondere in der MEM-Phase seines Betriebs, wird die Information oder Anweisung vom niedrigsten Level in der Hierarchie, wo sie verfügbar ist, abgerufen (wobei der niedrigste Level der dem Prozessor am nächsten gelegene Level ist). Ein Suchvorgang wird zum Beispiel im L1-Cache durchgeführt, und falls sich das Objekt (d. h. die Information/Anweisung) im L1-Cache befindet, so wird dies als Cache-Treffer bezeichnet. Falls das Objekt aber nicht im L1-Cache vorhanden ist, so spricht man von einem Cache-Fehler, und die nächsten Levels in der Hierarchie werden der Reihe nach geprüft, bis das Objekt gefunden wird (z. B. L2-Cache und dann L3-Cache, falls sich das Objekt auch nicht im L2-Cache befindet). Im Falle eines Cache-Fehlers wird das Objekt in den Cache geholt.
Das von einem Cache-Fehler auf dem niedrigsten Level (z. B. L1-Cache) herrührende Durchlaufen der Speicherhierarchie führt eine Latenz ein; um dies zu überwinden, können Prozessoren Daten und/oder Anweisungen schon früher als benötigt ergreifen, ein Prozess, der Prefetching genannt wird. Prefetching kann für Objekte (d. h. Daten/Anweisungen) erfolgen, die vom Prozessor mit Bestimmtheit zu einem späteren Zeitpunkt benötigt werden, für Objekte, die vielleicht vom Prozessor benötigt werden, falls eine bestimmte Abzweigung in einem Programm genommen wird, und/oder für Objekte, die basierend auf einem alternativen Vorhersageverfahren früher ergriffen werden. Mit Sprungvorhersage kann prognostiziert werden, welche Abzweigung wahrscheinlich genommen wird, um das Ausmaß von überflüssigem Prefetching (d. h. Vorgriff auf ein Objekt, das vom Prozessor tatsächlich aber nicht verwendet wird) zu reduzieren.
Out-of-order-Prozessoren nutzen zum Beispiel Sprungvorhersage und spekulatives Prefetching, damit die Anweisungen im prognostizierten Zweig spekulativ in anderer Reihenfolge ausgeführt werden können.
Die unten beschriebenen Ausführungsformen sind nicht auf Implementierungen beschränkt, die einzelne oder alle der Nachteile bekannter Verfahren zur Steuerung des Prefetch-Traffics lösen.
Kurzfassung
Diese Kurzfassung wird zur Vorstellung ausgewählter Konzepte in vereinfachter Form bereitgestellt, die unten unter Detaillierte Beschreibung genauer dargelegt werden. Diese Kurzfassung ist weder zur Identifizierung von Schlüsselmerkmalen oder wesentlichen Merkmalen des beanspruchten Gegenstands noch für Gebrauch als eine Hilfe zur Feststellung des Umfangs des beanspruchten Gegenstands bestimmt.
Verfahren und Systeme zur verbesserten Steuerung des von einem Prozessor erzeugten Traffics werden beschrieben. Wenn eine Vorrichtung in einer Ausführungsform eine Prefetch-Anforderung nach einer Information oder einer Anweisung aus einer Speicherhierarchie erzeugt, fügt die Vorrichtung der Anforderung eine Prefetch-Kennung bei. Diese Kennung zeichnet die Anforderung als Prefetch-Anforderung und nicht als eine Nicht-Prefetch-Anforderung, wie zum Beispiel eine zeitkritische Anforderung, aus. Auf dieser Kennung basierend kann die Speicherhierarchie dann zu Zeiten starken Traffics eine Abbruchantwort ausgeben, die den Prefetch-Traffic unterdrückt, da der Prefetch-Traffic von der Speicherhierarchie nicht erfüllt wird. Bei Erhalt einer Abbruchantwort löscht die Vorrichtung wenigstens einen Teil jedes Datensatzes der Prefetch-Anforderung, und falls die Information/Anweisung später benötigt wird, erfolgt die Ausgabe einer neuen Anforderung mit einer höheren Priorität als die ursprüngliche Prefetch-Anforderung.
Ein erster Aspekt bietet ein Verfahren zur Steuerung des von einem Prozessor erzeugten Traffics, wobei das Verfahren umfasst: Anhängen einer Prefetch-Kennung an eine Prefetch-Anforderung, wobei die Prefetch-Anforderung ein Objekt aus einer Speicherhierarchie anfordert, wobei das Objekt eine Information oder eine Anweisung umfasst; Senden der Prefetch-Anforderung vom Prozessor an die Speicherhierarchie; und in Reaktion auf den Erhalt einer Abbruchantwort, die der Prefetch-Anforderung entspricht, Entfernen wenigstens eines Teils der bezüglich der Prefetch-Anforderung lokal gespeicherten Daten.
Ein zweiter Aspekt stellt ein Verfahren zur Steuerung des von einem Prozessor erzeugten Traffics bereit, wobei das Verfahren umfasst: an einem Knoten in einer Speicherhierarchie Erhalten einer Prefetch-Anforderung vom Prozessor, wobei die Prefetch-Anforderung eine Prefetch-Kennung enthält und ein in der Speicherhierarchie abgelegtes Objekt anfordert, das eine Information oder eine Anweisung umfasst; basierend auf der Prefetch-Kennung und einer Beurteilung der Traffic-Levels innerhalb eines Teils der Speicherhierarchie, Bestimmen, ob eine Abbruchantwort, die der Prefetch-Anforderung entspricht, erzeugt werden soll; falls die Beurteilung bestimmt, dass eine Abbruchantwort zu erzeugen ist, Erzeugen der Abbruchantwort, die der Prefetch-Anforderung entspricht; und Senden der Abbruchantwort an den Prozessor.
Ein dritter Aspekt stellt ein System bereit, das umfasst: eine Vielzahl von Vorrichtungen, die zur Erzeugung von Anforderungen nach Objekten aus einer Speicherhierarchie ausgelegt sind, wobei ein Objekt eine Information oder eine Anweisung umfasst; wenigstens einen Teil der Speicherhierarchie; und wenigstens einen Bus zur Verbindung der mehreren Vorrichtungen und der Speicherhierarchie, wobei wenigstens eine der mehreren Vorrichtungen umfasst: eine erste Hardware-Logik, ausgelegt zum Anhängen einer Prefetch-Kennung an eine Prefetch-Anforderung, wobei die Prefetch-Anforderung ein Objekt aus einer Speicherhierarchie anfordert, und Senden der Prefetch-Anforderung vom Prozessor an die Speicherhierarchie; und eine zweite Hardware-Logik, ausgelegt zum Entfernen wenigstens eines Teils der bezüglich der Prefetch-Anforderung lokal gespeicherten Daten in Reaktion auf einen Erhalt einer Abbruchantwort, die der Prefetch-Anforderung entspricht.
Ein vierter Aspekt stellt ein Verfahren zum Zurücksetzen eines Teils eines Systems bereit, wobei das Verfahren umfasst: Erzeugen einer Gesamtabbruchantwort in einer Speicherhierarchie; und in Reaktion auf den Erhalt der Gesamtabbruchantwort beim Prozessor, Entfernen wenigstens eines Teils der lokal gespeicherten Daten bezüglich jeglicher unerfüllter, zuvor an die Speicherhierarchie gesendeten Anforderungen nach in der Speicherhierarchie abgelegten Datenobjekten.
Ein fünfter Aspekt stellt ein Verfahren bereit, das im Wesentlichen den 2–5 der Zeichnungen entspricht.
Ein sechster Aspekt stellt ein System bereit, das im Wesentlichen 1 der Zeichnungen entspricht.
Die hier beschriebenen Verfahren können von einem Computer ausgeführt werden, der mit Software in maschinenlesbarer Form konfiguriert ist, die auf einem materiellen Datenträger gespeichert ist, z. B. in Form eines Computerprogramms, das den Computerprogrammcode zur Konfigurierung eines Computers für die Durchführung der Bestandteile der beschriebenen Verfahren umfasst, oder in Form eines Computerprogramms, das Computerprogrammcodemittel umfasst, die für die Durchführung aller Schritte jeder der hier beschriebenen Verfahren angepasst sind, wenn das Programm auf einem Computer ausgeführt wird, und wobei das Computerprogramm auf einem computerlesbaren Medium verkörpert sein kann. Beispiele für materielle (oder nichtflüchtige) Datenträger umfassen Festplatten, USB-Sticks, Speicherkarten usw. und umfassen nicht verbreitete Signale. Die Software kann zur Ausführung auf einem parallelen Prozessor oder auf einem seriellen Prozessor geeignet sein, so dass die Verfahrensschritte in jeder geeigneten Reihenfolge oder gleichzeitig ausgeführt werden können.
Damit wird der Möglichkeit einer getrennten Nutzung und Wertschätzung von Firmware und Software Rechnung getragen. Es wird beabsichtigt, Software einzubeziehen, die auf ”unintelligenter” oder standardmäßiger Hardware läuft oder eine solche steuert, um die gewünschten Funktionen auszuführen. Es wird auch beabsichtigt, Software einzubeziehen, die die Konfiguration der Hardware ”beschreibt” oder definiert, wie zum Beispiel Hardwarebeschreibungssprachen-Software (HDL-Software), um gewünschte Funktionen auszuführen, wie dies bei der Entwicklung von Siliziumchips oder der Konfigurierung universell programmierbarer Chips der Fall ist.
Die bevorzugten Merkmale können entsprechend kombiniert werden, wie es für einen Fachmann offensichtlich wäre, und können mit jedem der Aspekte der Erfindung kombiniert werden.
Kurze Beschreibung der Zeichnungen
Ausführungsformen der Erfindung werden beispielhaft unter Bezugnahme auf die folgenden Zeichnungen beschrieben, wobei:
1 ein Prinzipschaltbild eines Systems darstellt;
2 ein Flussdiagramm eines Beispielverfahrens zur Steuerung von Prefetch-Traffic darstellt;
3 ein Flussdiagramm eines weiteren Beispielverfahrens zur Steuerung von Prefetch-Traffic darstellt;
4 ein Prinzipschaltbild darstellt, das Beispielmeldungsflüsse im System nach Anspruch 1 zeigt; und
5 ein Prinzipschaltbild darstellt, das ein Beispielverfahren zur Steuerung von Traffic zeigt.
Gemeinsame Bezugszeichen werden für alle Figuren verwendet, um ähnliche Merkmale anzuzeigen.
Detaillierte Beschreibung
Ausführungsformen der vorliegenden Erfindung werden im Folgenden nur beispielhaft beschrieben. Diese Beispiele sind die besten Wege zur Umsetzung der Erfindung in die Praxis, die dem Anmelder derzeit bekannt sind, obwohl sie nicht die einzigen Wege darstellen, auf denen dies erreicht werden könnte. Die Beschreibung legt die Funktionen des Beispiels und die Reihenfolge der Schritte für den Aufbau und den Betrieb des Beispiels dar. Identische oder gleichwertige Funktionen und Abläufe können jedoch durch verschiedene Beispiele bewirkt werden.
Die folgende Beschreibung bezieht sich auf verbesserte Verfahren zur Steuerung des Traffics zwischen Prozessoren und Speicher und/oder innerhalb der Speicherhierarchie. Insbesondere werden Verfahren zur Steuerung des Prefetch-Traffics beschrieben. Hardware und/oder Software, die einige oder alle der Verfahrensschritte implementieren könnte, wird ebenfalls beschrieben.
Wie oben beschrieben können Prozessoren Daten und/oder Anweisungen aus einer zugeordneten Speicherhierarchie frühzeitig abgreifen, um die mit einem Durchlaufen der Speicherhierarchie verbundene Latenz zu reduzieren (z. B. im Falle eines Cache-Fehlers für den Cache des höchsten Levels), um den Wirkungsgrad zu erhöhen (z. B. im Falle von Out-of-order-Prozessoren) oder aus anderen Gründen. Das Objekt (d. h. Daten/Anweisung), auf das vorgegriffen wird, kann auf jeden Fall zu einem späteren Zeitpunkt vom Prozessor zur Nutzung verlangt werden, und Anforderungen nach solchen Objekten (d. h. Daten und/oder Anweisungen) können als ”eindeutige Prefetch-Anforderungen” bezeichnet werden. Das Vorgriffsobjekt kann aber auch spekulativ sein, sodass die Möglichkeit besteht, dass es vom Prozessor nicht benötigt wird. Solche spekulativen Prefetch-Anforderungen treten häufig bei Abzweigungen in einem Programm auf, und selbst bei Verwendung von Sprungvorhersage zur Ermittlung des wahrscheinlichsten Wegs, den das Programm einschlagen wird, ist nicht garantiert, dass eine bestimmte Abzweigung genommen wird. Daher besteht die Möglichkeit, dass jegliche Daten, auf die für eine Anweisung nach dem Abzweigpunkt vorgegriffen wird, und jede Anweisung, die nach dem Abzweigpunkt eingeholt wird, nicht verwendet werden. In diesem Fall können die Anforderungen als ”falsch vorhergesagte Prefetch-Anforderungen” bezeichnet werden.
Durch das Vorgreifen auf Objekte (d. h. Daten und/oder Anweisungen) erzeugt der Prozessor Prefetch-Traffic, der Prefetch-Anforderungen nach einzelnen Daten und/oder Anweisungen umfasst. Dieser Traffic und die entsprechenden Antworten mit den angeforderten Objekten aus der Speicherhierarchie konkurrieren dann mit anderem Traffic (z. B. Nicht-Prefetch-Anforderungen und deren zugehörige Antworten) um einen Anteil der Kapazität (z. B. Bandbreite) der Busse im Prozessor, in der Speicherhierarchie und zwischen Prozessor und Speicherhierarchie. Vorgriffe, die vom Prozessor verwendet werden, erzeugen eine temporale Verschiebung in der zeitlichen Steuerung des Traffics (d. h. der Traffic ereignet sich früher als sonst); falsch vorhergesagte Prefetch-Anforderungen führen jedoch zu zusätzlichem Traffic ohne einen Vorteil (jenseits der Möglichkeit einer erfolgreichen Vorhersage und Erweisung der Prefetch-Anforderung als nicht falsch vorhergesagte Prefetch-Anforderung).
In einem System (wie zum Beispiel einem System-on-Chip, SoC), können sich viele Vorrichtungen befinden, die Prefetch-Anforderungen erzeugen. Unter diesen Vorrichtungen kann jede Komponente sein, die auf eine Speicherhierarchie zugreift, zum Beispiel Prozessoren (z. B. physikalische Prozessoren wie CPUs oder GPUs oder virtuelle Prozessoren in einem Multi-Threaded-Prozessor) und Teilelemente eines Prozessors (z. B. virtuelle Threads, Ausführungs-Pipelines oder ALUs). Im System können sich auch Vorrichtungen befinden, die keine Verzögerung dulden und zeitkritische Anforderungen nach Daten und/oder Anweisungen erzeugen; derartige Vorrichtungen können als ”Echtzeitvorrichtungen” oder ”kritische Vorrichtungen” bezeichnet werden. Falls diese zeitkritischen Anforderungen einer Verzögerung unterliegen, wirken sie sich auf den Systembetrieb aus; sie können zum Beispiel mit Audio-, Grafik- und Steuerungsprozessen in Verbindung stehen, wobei eine Verzögerung einen Tonausfall oder eine leere bzw. stillstehende Bildschirmanzeige verursachen kann (und daher vom Benutzer bemerkt wird). Gewisse Vorrichtungen können sowohl Prefetch-Anforderungen als auch zeitkritische Anforderungen erzeugen, während andere Vorrichtungen (z. B. in einem SoC) nur zeitkritische Anforderungen erzeugen können.
Bei einem System, das eine oder mehrere Prefetch-Anforderungen erzeugende Vorrichtungen und wenigstens eine zeitkritische Anforderungen erzeugende Vorrichtung umfasst, können Zeitabschnitte auftreten, in denen der gesamte Traffic innerhalb des ganzen oder in einem Teil des Systems zu stark ist, um alle zeitkritischen Anforderungen zu unterstützen, sodass ein gewisser Traffic hingehalten oder anderweitig gestoppt werden muss, um die für den Systembetrieb unmittelbar kritischen Anforderungen bedienen zu können. Es versteht sich, dass es Unterschiede in der zeitlichen Kritikalität von Nicht-Prefetch-Anforderungen geben kann, obwohl die folgende Beschreibung Anforderungen in ”Prefetch” und ”zeitkritisch” unterteilt; alle Nicht-Prefetch-Anforderungen müssen jedoch abgeschlossen werden.
Bestehende Lösungen halten den gesamten Traffic aus einer Vorrichtung, deren Priorität als niedrig erachtet wird, hin, wodurch deren Traffic zugunsten des Traffics aus einer anderen Vorrichtung vorübergehend gedrosselt wird. Dies beeinträchtigt jedoch nachfolgende, aus der hingehaltenen Vorrichtung kommende Anforderungen, die hohe Priorität haben können, und es gibt keine Möglichkeit, weitere kritische Anforderungen aus der hingehaltenen Vorrichtung zu unterstützen. Außerdem könnte kein Feedback-Mechanismus für die Vorrichtung eingerichtet sein, sodass diese nicht weiß, dass der Traffic hingehalten wird, oder der Feedback-Mechanismus könnte zu langsam reagieren (z. B. können Busse erkennen, dass der Service schlecht ist, aber vielleicht den Grund hierfür nicht wissen).
Bei manchen bestehenden Lösungen wird die Prefetch-Erzeugung durch ein Beschränken der Anzahl der Slots, die in den Prefetch-Traffic eingespeist werden können, gedrosselt. Bei derartigen Lösungen ist dies jedoch nur für die Zeit nach Rückwanderung des verminderten Verkehrsflusses zur Vorrichtung implementiert, sodass die Drosselung der Prefetch-Erzeugung nach dem Zeitpunkt auftritt, zu dem das Gesamtverkehrsaufkommen zu hoch war.
Gemäß den hier beschriebenen Verfahren wird an jede Prefetch-Anforderung eine Prefetch-Kennung angehängt, welche die jeweilige Anforderung als Prefetch-Anforderung auszeichnet. Wie unten genauer beschrieben wird, kann es mehr als eine Prefetch-Anforderungskategorie (oder -klasse) geben, um zum Beispiel zwischen spekulativen und eindeutigen Prefetches zu unterscheiden, und dementsprechend können auch mehrere Prefetch-Kennungstypen verwendet werden.
Wenn die Kapazität der Busse (oder anderer Teile des Systems) wegen starken Traffics so weit eingeschränkt ist, dass kritische Vorgänge beeinträchtigt werden könnten, gibt die Speicherhierarchie bei Erhalt einer Prefetch-Anforderung (erkennbar an einer Prefetch-Kennung) eine Abbruchmeldung aus. Wenn eine Abbruchmeldung erzeugt wird, wird die Prefetch-Anforderung von der Speicherhierarchie nicht erfüllt, und die Abbruchmeldung benachrichtigt die ausgebende Vorrichtung (d. h. die Vorrichtung, die die Prefetch-Anforderung erzeugt hat) über diesen Vorfall. Sollte die Vorrichtung das Objekt (d. h. Daten/Anweisung), auf das sie vorzugreifen versuchte, benötigen, kann sie eine neue Anforderung für dasselbe Objekt mit höherer Prioritätsstufe (z. B. eine Nicht-Prefetch-Anforderung) ausgeben. Dies erhöht die Wahrscheinlichkeit, dass die Vorrichtung das angeforderte Objekt erhält (und dass die Anforderung nicht abermals zu einer Abbruchantwort führt). Die neu ausgegebene Anforderung enthält entweder keine Prefetch-Kennung (und ist damit eine Nicht-Prefetch-Anforderung) oder sie enthält eine andere Kennung als die ursprüngliche Prefetch-Anforderung (z. B. eine Kennung, die eine höhere Prioritätsstufe anzeigt und somit die Anforderung fördert).
Durch Gebrauch dieser Technik wird der Prefetch-Traffic zu Zeiten starker Bandbreitenauslastung (z. B. durch kritische Operationen) unterdrückt. Bei den Vorrichtungen muss der Prefetch-Erzeugungsalgorithmus nicht geändert werden, und es sind auch keine großen Speichermengen innerhalb des Systems, in dem unkritische Anforderungen hingehalten werden könnten, erforderlich. Außerdem wird verhindert, dass sich zeitkritische Anforderungen einer Vorrichtung hinter einer hingehaltenen Prefetch-Anforderung stauen, da nur die Prefetch-Anforderungen zu Zeiten starken Traffics ausgefiltert werden, und eine Vorrichtung weiterhin Anforderungen (Prefetch oder Nicht-Prefetch) in das System ausgeben kann. Die Verfahren können an beliebiger Stelle in der Speicherhierarchie implementiert werden und sie können unabhängig an mehreren Stellen in der Hierarchie implementiert werden, um eine Lokalisierung der Traffic-Verminderung zu ermöglichen (um zum Beispiel eine bestimmte Engstelle innerhalb der Hierarchie anzugehen, da es Stellen in der Hierarchie geben kann, die unabhängige Zeiten mit starkem Traffic haben). Die Technik arbeitet auf sehr dynamische Weise und kann ohne signifikante Zeitverzögerung auf kurze Zeitabschnitte mit starkem Traffic ansprechen. Die Verfahren können auch in Kombination mit anderen Techniken zur Traffic-Arbitrierung verwendet werden.
1 zeigt ein Prinzipschaltbild eines Systems 100 (wie zum Beispiel ein SoC), das eine Vielzahl von Vorrichtungen 102, 104, 106 umfasst, die mit einer Speicherhierarchie 108 über einen oder mehrere Busse 110 verbunden sind. Jede der Vorrichtungen 102, 104, 106 kann Anforderungen nach Daten/Anweisungen aus der Speicherhierarchie 108 über einen Bus 110 ausgeben, und diese Anforderungen können Prefetch-Anforderungen und/oder zeitkritische Anforderungen umfassen. Die Vorrichtungen 102, 104, 106 können zum Beispiel Prozessoren (z. B. physikalische oder virtuelle Prozessoren) und Teilelemente eines Prozessors (z. B. einen virtuellen Thread oder eine ALU) umfassen, und die Vorrichtungen 102, 104, 106 können allesamt vom gleichen Typ oder sie können unterschiedlichen Typs sein (einige könnten zum Beispiel nur zeitkritische Anforderungen ausgeben). Die Speicherhierarchie 108 umfasst eine Vielzahl von Speicher-Levels, und in diesem Beispiel umfasst sie drei Cache-Levels L1 112, L2 114 und L3 116. Gewisse Caches können gemeinsam von zwei oder mehreren Vorrichtungen genutzt werden, während andere Caches getrennt für jede Vorrichtung vorgesehen sind. Es wird darauf hingewiesen, dass bei Ausführung von System 100 als SoC gewisse Level innerhalb der Speicherhierarchie 108 off-chip oder alle Level der Speicherhierarchie 108 on-chip implementiert werden können.
Der Betrieb des Systems 100 in 1 kann unter Bezugnahme auf 2 beschrieben werden, in der ein Flussdiagramm eines Beispielverfahrens zur Steuerung von Prefetch-Traffic gezeigt wird. Wenn eine Vorrichtung 102, 104, 106 eine Prefetch-Anforderung erzeugt (mit Standardtechniken zum Beispiel), wird der Anforderung eine Prefetch-Kennung beigefügt (Block 202), wobei die Prefetch-Kennung zum Beispiel in der Anforderung codiert sein könnte. Diese Anforderung, die die Prefetch-Kennung umfasst, wird dann zur Speicherhierarchie 108 übertragen (Block 204), z. B. über Bus 110.
In Reaktion auf einen Erhalt der Anforderung (Block 206) trifft die Speicherhierarchie 108 je nach aktuellem Traffic-Level eine von zwei Maßnahmen (Block 210 oder 212). Die Beurteilung des Traffic-Levels (in Block 208) kann an jeder Stelle innerhalb der Speicherhierarchie 108 oder innerhalb des Systems 100 erfolgen, und bei Implementierung des Verfahrens von 2 an mehr als einer Stelle im System oder in der Speicherhierarchie 108 (z. B. zwei oder mehr der in 1 gezeigten Knoten A, B und C) kann der Traffic-Level lokal am Entscheidungspunkt (z. B. am Knoten A/B/C) beurteilt werden.
Wenn der aktuelle Traffic-Level nicht zu hoch ist (z. B. nicht so hoch, dass zeitkritische Vorgänge beeinträchtig werden), wird die Anforderung von der Speicherhierarchie erfüllt (”Nein” in Block 208 gefolgt von Block 210). Wenn jedoch festgestellt wird, dass der aktuelle Traffic-Level zu hoch ist (”Ja” in Block 208), erzeugt die Speicherhierarchie 108 eine Abbruchantwort (Block 212). Diese Abbruchantwort ist direkt auf die erhaltene Anforderung (in Block 206) bezogen, und wird der Vorrichtung zugeleitet, die diese Anforderung erzeugt hat (Block 214). Die Abbruchantwort könnte in einem Beispiel eine ID umfassen, die mit der ID der Anforderung (die in Block 206 erhalten wurde) übereinstimmt (oder ihr auf andere Weise entspricht). Wenn die Abbruchantwort erzeugt wird (in Block 212), wird die (in Block 206) erhaltene Anforderung nicht erfüllt und für spätere Verarbeitung auch nicht gespeichert (wie dies der Fall ist, wenn Anforderungen hingehalten werden). Die Prefetch-Anforderung kann daher als ”vom System ausgefiltert” beschrieben werden.
Die von der Speicherhierarchie 108 (in Block 212) erzeugte Abbruchantwort benachrichtigt die anfordernde Vorrichtung darüber, dass die Prefetch-Anforderung, die sie ausgegeben hat, nicht erfüllt wird. Wenn die Vorrichtung eine Abbruchantwort erhält (Block 216), entfernt die Vorrichtung wenigstens einen Teil der lokal gespeicherten Daten bezüglich der Prefetch-Anforderung (Block 218) und kann in manchen Beispielen alle Daten bezüglich der Prefetch-Anforderung entfernen. Bei den Daten hinsichtlich der Prefetch-Anforderung kann es sich zum Beispiel um eine Angabe zur Adresse der angeforderten Information oder Anweisung, zum Ort, wo die angeforderte Information/Anweisung gespeichert wird, usw. handeln.
In dem Fall, dass das Objekt (d. h. die Information oder Anweisung), das in der ursprünglichen Prefetch-Meldung angefordert wurde, von der Vorrichtung als erforderlich betrachtet wird (”Ja” in Block 220, d. h. die ursprüngliche Anforderung hat sich nicht als eine falsch vorhergesagte Prefetch-Anforderung erwiesen), gibt die Vorrichtung eine neue Anforderung für das Objekt aus (Block 222), und diese neue Anforderung wird zur Speicherhierarchie 108 übertragen (zum Beispiel wie oben beschrieben). Bei dieser neuen Anforderung kann es sich zum Beispiel um eine zeitkritische oder um eine andere Form einer Nicht-Prefetch-Anforderung handeln, und die neue Anforderung (ausgegeben in Bock 222) hat dann einen anderen Kennungstyp als die ursprüngliche (in Block 202 erzeugte) Anforderung oder sie umfasst vielleicht keine Kennung.
In manchen Beispielen kann die (in Block 222 ausgegebene) neue Anforderung eine Prefetch-Anforderung mit höherer Priorität als die ursprüngliche (in Block 202 erzeugte) Anforderung sein, wobei in diesem Fall das Verfahren dann (wie durch den gestrichelten Pfeil von Block 222 zu Block 204 angezeigt) wiederholt wird.
Zur Implementierung der Blöcke 218–220 ist für die Vorrichtung nicht unbedingt zusätzliche Logik erforderlich, um die Erzeugung einer neuen Anforderung (in Block 220) auszulösen, da die Daten hinsichtlich des Vorgriffs entfernt worden sind, und der Zustand so ist, als ob der ursprüngliche Vorgriff nie stattgefunden hätte. Bestehende Mechanismen zur Erzeugung einer Anforderung nach einem von der Vorrichtung benötigten Objekt (d. h.
Daten/Anweisung) können daher zur Erzeugung der neuen Anforderung herangezogen werden.
Obwohl die Bestimmung, ob das angeforderte Objekt benötigt war oder nicht (in Block 220), gegen Ende des Flussdiagramms von 2 gezeigt wird, versteht es sich, dass diese Bestimmung tatsächlich an beliebiger Stelle nach der Erzeugung der Prefetch-Anforderung (in Block 202) erfolgen kann; die Ausgabe einer neuen Anforderung für das Objekt (in Block 222) wird jedoch erst nach Erhalt der Abbruchantwort (in Block 216) ausgelöst. Bei früherer Ermittlung, ob das angeforderte Objekt benötigt war oder nicht (in Block 220), kann bestehende Logik verwendet werden, um eine Anzeige zu speichern, dass diese Daten aktiv erforderlich sind, zusätzliche Logik kann jedoch vorgesehen werden, um die neue Anforderung (in Block 222) zu erzeugen.
Die Kennung, die der Prefetch-Anforderung beigefügt ist (in Block 202), kann zum Beispiel in ”Seitenbandmarkierungen” implementiert werden, die einen codierten Datenbitsatz umfassen, der die Anforderung begleitet. Alternativ kann die Prefetch-Kennung auf beliebige Weise innerhalb der Anforderung codiert werden.
Das Beispiel von 2 geht von einem einzelnen Kennungstyp aus, der eine Anforderung als Prefetch-Anforderung auszeichnet. In manchen Beispielen können mehr als ein Prefetch-Kennungstyp zur Angabe des Typs oder der Klasse der Prefetch-Anforderung vorkommen. In einem Beispiel können zwei Prefetch-Anforderungsklassen auftreten: eindeutige Prefetch-Anforderungen und spekulative Prefetch-Anforderungen, und damit auch zwei Prefetch-Kennungen (je eine pro Prefetch-Anforderungsklasse). In einem anderen Beispiel können mehr als zwei Prefetch-Anforderungsklassen vorkommen, wobei die spekulativen Prefetch-Anforderungen nach der Wahrscheinlichkeit, dass das angeforderte Objekt (d. h. Daten/Anweisung) vom Prozessor verwendet wird (z. B. gemäß Vertrauen in die Sprungvorhersage oder andere angewendete Vorhersageverfahren), in verschiedene Klassen unterteilt sind. In einem derartigen Beispiel können zwei spekulative Prefetch-Anforderungsklassen auftreten: Prefetch-Anforderungen mit größerer Sicherheit und Prefetch-Anforderungen mit weniger Sicherheit. Und in weiteren Beispielen kann die Prefetch-Kennung ein Sicherheitsmaß für die Sprungvorhersage umfassen, wobei in diesem Fall eine oder mehr Schwellen verwendet werden können, um zu bestimmen, welche Prefetch-Anforderungen ausgefiltert werden.
3 stellt ein Flussdiagramm eines anderen Beispielverfahrens zur Steuerung des Prefetch-Traffics dar, die auch im in 1 gezeigten System 100 implementiert werden könnte. Dieses Verfahren ist eine Variation der in 2 vorgestellten, und gemeinsame Elemente sind mit denselben Bezugsnummern gekennzeichnet.
Wie oben beschrieben erzeugt eine Vorrichtung eine Prefetch-Anforderung einschließlich einer Prefetch-Kennung (Block 202); bei diesem Beispielverfahren steht jedoch mehr als ein Prefetch-Kennungstyp zur Verfügung, sodass die Prefetch-Anforderung erzeugt (Block 302) und mit einer Prefetch-Kennung des geeigneten Typs in der Anforderung versehen (Block 304) wird. Wie oben beschrieben kann die Prefetch-Kennung innerhalb der Seitenbandmarkierungen codiert werden oder es kann eine Prefetch-Kennung nach einem anderen Verfahren innerhalb der Prefetch-Anforderung codiert werden.
Bei dem in 3 vorgestellten Verfahren filtert die Speicherhierarchie erneut den Prefetch-Traffic basierend auf der in jeder Prefetch-Anforderung eingebetteten Prefetch-Kennung; bei diesem Verfahren kann jedoch der gesamte Prefetch-Traffic ausgefiltert werden (durch Ausgabe einer Abbruchantwort in Block 212) oder es kann nur ein Teil des Prefetch-Traffics (d. h. nicht der gesamte Prefetch-Traffic) ausgefiltert werden.
Bei Erhalt einer Prefetch-Anforderung (in Block 206) wird die Anforderung erfüllt (Block 210), falls der gesamte Traffic nicht zu stark ist (”Nein” in Block 208). Falls der gesamte Traffic aber zu stark ist (”Ja” in Block 208), wird ein weiterer Filterschritt ausgeführt (Block 306), sodass Abbruchantworten nur dann für Prefetch-Anforderungen ausgegeben werden (in Block 212), bei denen die Prefetch-Kennung definierte Kriterien erfüllt (”Ja” in Block 306). Sind diese Filterkriterien nicht erfüllt (”Nein” in Block 306), so wird die Prefetch-Anforderung erfüllt (Block 210). Die (im Block 306 verwendeten) Filterkriterien können festgelegt oder dynamisch sein und können zum Beispiel nur spekulative Prefetch-Anforderungen ausfiltern, sodass alle eindeutigen Prefetch-Anforderungen erfüllt werden (in Block 210).
Dynamische Filterkriterien (die im Block 306 verwendet werden) können (in Block 308) basierend auf einer Beurteilung des gesamten Traffics (in Block 310) eingerichtet werden, wobei wie oben beschrieben dieser gesamte Traffic lokal am Entscheidungspunkt beurteilt werden kann, was das Verfahren implementiert. In einem Beispiel kann die Speicherhierarchie wegen starken gesamten Traffics anfänglich nur die spekulativen Prefetch-Anforderungen ausfiltern (und nicht erfüllen). Wenn das Ausfiltern der spekulativen Prefetch-Anforderungen den gesamten Traffic nicht so weit entlastet, dass zeitkritische Anforderungen nicht beeinträchtigt werden, können die Filterkriterien aktualisiert werden (in Block 308), sodass zusätzliche Prefetch-Anforderungen (z. B. alle Prefetch-Anforderungen) ausgefiltert werden. Wenn der gesamte Traffic wieder abnimmt (z. B. nach einem Zeitabschnitt starken Traffics), können die Filterkriterien erneut angepasst werden (in Block 308), sodass ein gewisser Teil des Prefetch-Traffics erfüllt wird, und wenn der Traffic ausreichend abgenommen hat, wird keine der Prefetch-Anforderungen blockiert (als Ergebnis eines ”Nein” in Block 208).
In Beispielen, bei denen die Prefetch-Kennung einen mit der Anforderung verbundenen Sicherheitswert umfasst (z. B. basierend auf der Sicherheit einer Sprungvorhersage und unter Zuweisung eines Grenzwerts wie 100 zu eindeutigen Prefetch-Anforderungen), können die (im Block 306 verwendeten) Filterkriterien eine Sicherheitsschwelle sein, wobei die Anforderungen mit einer Kennung, die eine Sicherheit über der Schwelle angibt, erfüllt werden, und diejenigen unter der Schwelle ausgefiltert werden. Bei dynamisch eingerichteten Filterkriterien kann der Wert der Sicherheitsschwelle auf Grundlage der Beurteilung des gesamten Traffics (in Block 310) angepasst werden (in Block 308).
In den oben beschriebenen Beispielen in Bezug auf die 1–3 werden nur Prefetch-Anforderungen mit Kennungen versehen. Es wird darauf hingewiesen, dass stattdessen alle Anforderungen nach Objekten (d. h. Daten/Anweisungen) mit Kennungen versehen werden können, und dass diese Kennungen die Art der Anforderung als Prefetch-Anforderung oder als Nicht-Prefetch-Anforderung (und in gewissen Fällen die Klasse der Prefetch-Anforderung und/oder der Nicht-Prefetch-Anforderung) angeben können. Bei Einbezug von Kennungen sowohl für Prefetch- als auch für Nicht-Prefetch-Anforderungen können die hier beschriebenen Verfahren angewendet werden, um gewisse Nicht-Prefetch-Anforderungen zusätzlich zu Prefetch-Anforderungen auszufiltern.
Wie in 2 und 3 gezeigt werden einige Teile der oben beschriebenen Verfahren (z. B. Blöcke 202, 204 und 216–222) durch eine Vorrichtung implementiert, die Prefetch-Anforderungen erzeugt. Alternativ kann eine separate Vorrichtung Prefetch-Anforderungen abfangen und mit Prefetch-Kennungen versehen (d. h. Block 202 ausführen) und die zur Unterstützung des Prefetch-Abbruchs auf dieser Stufe im System erforderliche Logik implementieren (z. B. so, dass die Blöcke 202, 204 und 216–222 durch die Kombination dieser separaten Vorrichtung und der Vorrichtung, die die Prefetch-Anforderung erzeugt, ausgeführt werden), wenn die die Prefetch-Anforderung erzeugende Vorrichtung keine Unterstützung für Prefetch-Abbruch bietet. Andere Teile der oben beschriebenen Verfahren können an beliebiger Stelle im System implementiert werden, und 1 zeigt drei mit A, B und C bezeichnete Beispielpositionen, wo diese anderen Teile des Verfahrens (z. B. Blöcke 206–214 und 306–310) implementiert werden können (z. B. mit zusätzlicher Logik 128). Wie oben beschrieben kann das Verfahren an einer einzelnen Stelle im System oder an mehr als einer Stelle im System implementiert werden. Sollten die Nicht-Vorrichtungs-Teile der Verfahren (z. B. Blöcke 206–214 und 306–310) an mehr als einer Stelle im System betrieben werden, so kann das Verfahren unabhängig an jeder Stelle eingesetzt und auf lokalen Gesamt-Traffic-Levels basieren, sodass verschiedene Stellen unterschiedliche Filterkriterien (in Block 306) verwenden können und/oder eine beliebige Filterung der Prefetch-Anforderungen implementieren können oder nicht. Die genauen Positionen, an denen die Verfahren implementiert wird, können vom Systemdesign und der Führung des Busses (oder der Busse) im System abhängen.
In einem Beispiel können die Nicht-Vorrichtungs-Teile des Verfahrens an einer oder mehreren Arbitrierstellen im System (z. B. innerhalb der Speicherhierarchie) implementiert werden. Diese Arbitrierstellen steuern die Nutzung eines Busses innerhalb des Systems und umfassen eine Logik 130 zur Erfassung von Konflikten und/oder hohen Traffic-Leveln. In manchen Beispielen kann das Verfahren an Knoten im System implementiert werden, die Dienstgüteüberwachung durchführen können.
3 zeigt einen expliziten Schritt des Verfahrens zur Beurteilung des Traffics (Block 310), der in 2 nicht vorhanden ist. Es wird darauf hingewiesen, dass dieser Verfahrensblock in 2 hinzugefügt werden kann, oder alternativ die Überwachung der Traffic-Level mit der Ermittlung, ob der gesamte Traffic zu stark ist (in Block 208), kombiniert werden kann. Jedes geeignete Verfahren zur Beurteilung des Traffics einschließlich Traffic-Level, Dienstgütemessungen, ein Maß der in einem Fenster akzeptierten Anforderungen oder ein spezielleres Maß der vom Ausgabebus in Anspruch genommenen Bandbreite kann verwendet werden. Das Bestimmen, ob der Traffic zu stark ist (in Block 208), kann durch Vergleich der Traffic-Messungen mit einer oder mehreren Schwellen implementiert werden. Überschreitet das Maß des Traffics zum Beispiel die Schwelle T, so kann der Traffic als zu stark (”Ja” in Block 208) betrachtet werden. In einem anderen Beispiel können mehrere Schwellen gesetzt sein, wobei, falls das Maß des Traffics die erste Schwelle T1 überschreitet, nur spekulative Prefetch-Anforderungen ausgefiltert werden (und daher zu einer Abbruchantwort führen), und, falls das Maß des Traffics sowohl die erste als auch die zweite Schwelle T2 überschreitet, alle Prefetch-Anforderungen ausgefiltert werden. In einigen Beispielen können die Schwellen verschieden/unabhängig sein und nur eine Untergruppe der Anforderungstypen (d. h. nicht alle Anforderungstypen) betreffen.
4 zeigt verschiedene Beispielmeldungsflüsse in einem System, das die oben beschriebenen Verfahren implementiert. In diesen Beispielen wird die Prefetch-Anforderung von einer Vorrichtung 102 (in Block 202) erzeugt, und die Nicht-Vorrichtungs-Teile des Verfahrens sind am Knoten C implementiert. Die Prefetch-Anforderung wird von der Vorrichtung 102 über eine Reihe von Zwischenpunkten (wie durch die Pfeile 402–406 angezeigt) zum Knoten C gesendet, wobei in 4 zwei Zwischenpunkte dargestellt sind, die Knoten A und B.
Beim ersten Beispielmeldungsfluss 41 läuft eine am Knoten C (in Block 212) erzeugte Abbruchantwort auf demselben Weg zurück (angezeigt durch die Pfeile 408–412), den die Prefetch-Anforderung genommen hatte, nur in entgegengesetzter Richtung (z. B. über die Zwischenpunkte, Knoten A und B). Beim Zurücklaufen der Abbruchantwort auf dem Weg, den die Prefetch-Anforderung genommen hatte, sehen alle Elemente entlang der Route (wie die Zwischenpunkte, Knoten A und B), die auf eine Rückmeldung warten (d. h. eine Erfüllungsmeldung für die Prefetch-Anforderung erwarten), die Abbruchmeldung und stellen ihren Zustand richtig zurück (soweit erforderlich). Dies kann zum Beispiel bei einem System, das kaskadierte Arbitrierstellen innerhalb der Speicherhierarchie umfasst, verwendet werden.
Beim zweiten Beispielmeldungsfluss 42 läuft eine am Knoten C erzeugte Abbruchantwort auf einem Weg (wie durch Pfeil 414 angezeigt) zurück, der sich vom ausgehenden Weg der Prefetch-Anforderung (wie durch die Pfeile 402–406 angezeigt) unterscheidet. In diesem Beispiel läuft die Abbruchantwort direkt vom Knoten C zur Vorrichtung 102. Ein derartiger Meldungsfluss kann in Fällen eingesetzt werden, bei denen auf dem ausgehenden Weg keine Zwischenpunkte liegen, die irgendeinen mit der Prefetch-Anforderung verbundenen Zustand festhalten und daher keine Rückmeldung vom Knoten C zur Vorrichtung 102 erwarten.
Beim dritten Beispielmeldungsfluss 43 läuft die am Knoten C erzeugte Abbruchantwort auf einem Weg (wie durch die Pfeile 416–418 angezeigt) zurück, der nicht dem der Prefetch-Anforderung entspricht (wie Meldungsfluss 42) und der auch nicht direkt verläuft, sondern über einen Zwischenpunkt (Knoten A) geht.
Es versteht sich, dass die in 4 gezeigten Meldungsflüsse nur einige Beispiele darstellen, und dass die Abbruchmeldung in anderen Beispielen über einen Zwischenpunkt zurücklaufen kann, der nicht auf dem ausgehenden Weg der Prefetch-Anforderung liegt, z. B. so, dass der Rücklaufweg sich vom Ausgangsweg mit Ausnahme des Start- und Endpunkts gänzlich unterscheidet.
Bei den oben beschriebenen Verfahren ist es nicht notwendig, dass eine Prefetch-Anforderungen ausgebende Vorrichtung etwas in Hinblick auf die Erzeugung der Prefetch-Anforderungen ändert. Die Vorrichtungen umfassen zusätzliche Hardware-Logik 120 zum Empfangen von und Reagieren auf Abbruchantworten (z. B. zum Implementieren der Blöcke 216–218, da die Blöcke 220–222 bestehende Hardware-Logik verwenden) und Hardware-Logik 122 zum Einfügen von Prefetch-Kennungen in Prefetch-Anforderungen. Wie in 1 gezeigt kann die zusätzliche Hardware-Logik 120 für ein Empfangen von und Reagieren auf Abbruchantworten alternativ im L1-Cache implementiert werden. Die Hardware-Logik 122 zum Einfügen von Prefetch-Kennungen in Prefetch-Anforderungen kann bei einigen Implementierungen auch in die Cache-Level eingebunden werden, oder wo immer Prefetch-Traffic erzeugt wird.
In manchen Beispielen kann eine Vorrichtung jedoch ihr Prefetch-Verhalten in Erwiderung auf Erhalt einer oder mehrerer Abbruchantworten ändern, und zusätzliche Hardware-Logik kann bereitgestellt werden, um diese Funktionalität zu implementieren. Eine Vorrichtung kann zum Beispiel für gewisse Zeit die Anzahl der erzeugten Prefetch-Anforderungen beschränken oder nur eindeutige Prefetch-Anforderungen (und keine spekulativen Prefetch-Anforderungen) erzeugen. Hierdurch wird die Anzahl der im System erzeugten Abbruchantworten unter Umständen reduziert, falls die Zeit des übermäßigen Traffics jedoch nur kurz ist, kann jede Verminderung der Prefetch-Erzeugung ein Prefetching durch die Vorrichtung unnötigerweise beschränken, wenn kein Stau mehr vorhanden ist.
Die oben beschriebenen Verfahren werden von einem System zum Ausfiltern von Prefetch-Anforderungen verwendet, damit wichtigere Anforderungen (z. B. zeitkritische Anforderungen) wegen eines Staus innerhalb des Systems (z. B. innerhalb eines Busses im System) nicht verzögert oder angehalten werden. Die Verfahren können jedoch modifiziert werden, wie in 5 gezeigt, um alle Anforderungen nach Daten und/oder Anweisungen (d. h. alle Prefetch-Anforderungen und alle Nicht-Prefetch-Anforderungen) von einer bestimmten Vorrichtung zurückzuweisen. Das in 5 gezeigte Verfahren kann zum Beispiel zur Unterstützung beim Zurücksetzen eines Teils des Systems verwendet werden, z. B. bei einer Aufteilung des Systems in verschiedene Strombereiche, und/oder zur Reduzierung des Stroms bei erwartetem Nichtgebrauch einer Zone.
5 stellt ein Flussdiagramm eines Beispielverfahrens zur Steuerung des Traffics dar, die im in 1 gezeigten System 100 implementiert werden kann. Eine Vorrichtung erzeugt eine Anforderung nach einem Objekt (Block 502), wobei das Objekt eine Information oder eine Anweisung sein kann, und die Vorrichtung kann eine Kennung, wie z. B. eine Prefetch-Kennung, in die Anforderung einfügen (Block 504, dies ist aber optional). Das in 5 dargestellte Verfahren erfordert keine Kennungen zur Klassifizierung eines Typs einer Anforderung (z. B. zur Identifizierung von Prefetch-Anforderungen) wie oben hinsichtlich der in 2 und 3 gezeigten Verfahren beschrieben, das in 5 gezeigte Verfahren kann jedoch in Kombination mit den zuvor beschriebenen Verfahren verwendet werden. Die erzeugte Anforderung wird dann zur Speicherhierarchie gesendet (Block 204).
Die Anforderung wird an einem Knoten in der Speicherhierarchie (Block 506) erhalten, und wie oben beschrieben, kann es sich bei dieser Anforderung um eine Prefetch-Anforderung oder um eine zeitkritische Anforderung handeln. Daraufhin oder häufiger in Reaktion auf ein anderes Ereignis, wie eine Zurücksetzung des Speichers oder der Vorrichtung, worauf der Zugriff gesteuert wird, erzeugt der Knoten eine Abbruchantwort (Block 508), jedoch im Gegensatz zu oben beschriebenen Abbruchantworten ist diese Abbruchantwort nicht mit einer einzelnen Anforderung verbunden, sondern ist eine Gesamtabbruchantwort, die alle Anforderungen betrifft, die von einer bestimmten Vorrichtung erhalten, aber noch nicht erfüllt worden sind. Es kann auch sein, dass die Abbruchantwort nicht bei Erhalt einer Anforderung eines bestimmten Typs oder als Folge hoher Traffic-Level ausgelöst wird, sondern daher, weil die Anforderung von einer bestimmten Vorrichtung stammt, und andere Auslösefaktoren involviert sind (z. B. bei einem Statusereignis der angesteuerten Hierarchie wie ”Zurücksetzung” oder ”Strom Aus”). Die Gesamtabbruchantwort wird zur Vorrichtung, von der die Anforderung ausging, gesendet (Block 214), und die Antwort kann einen direkten mit dem ausgehenden Weg der Anforderung übereinstimmenden Weg oder irgendeinen anderen Weg (z. B. gemäß einem der in 4 gezeigten Beispiele) nehmen.
Bei Erhalt der Abbruchantwort (Block 216) entfernt die Vorrichtung wenigstens einen Teil der Daten (und in manchen Beispielen alle Daten) bezüglich aller unerfüllter Anforderungen, die an die Komponente gerichtet sind, die die Gesamtabbruchmeldung ausgegeben hat (Block 510), und nicht nur der in Block 502 erzeugten Anforderung. Indem auf diese Weise alles gelöscht wird, gibt die Vorrichtung dann erneut Anforderungen aus, wenn sie das angeforderte Objekt benötigt (Blöcke 220–222). Nachdem eine Prefetch-Anforderung gelöscht (und nicht erfüllt) worden ist, kann als neue Anforderung eine Nicht-Prefetch-Anforderung ausgegeben werden, wie oben beschrieben. Der Empfang einer Gesamtabbruchmeldung kann auch eine Software- oder Hardware-Operation bei der Vorrichtung auslösen, um eine notwendige, alternative Maßnahme durchzuführen.
Die oben beschriebene Gesamtabbruchantwort kann von Logik auf jeder Ebene der Hierarchie gehandhabt und gesendet werden. Der in 1 gezeigte L3-Cache 116 kann zum Beispiel eine Gesamtabbruchantwort ausgeben, weil erkannt worden ist, dass der Speicherzugriff auf den Hauptspeicher 132 zurückgesetzt worden ist (und daher ausstehende Anforderungen nicht verarbeitet werden).
Die oben beschriebenen Verfahren können sowohl in einem SoC als auch in Systemen, bei denen ein Teil oder die Gesamtheit der Speicherhierarchie off-chip realisiert ist (d. h. nicht auf demselben Siliziumstück wie die Vorrichtungen, die Anforderungen nach Daten erzeugen), implementiert werden.
Die hier verwendeten Begriffe ”Prozessor” und ”Computer” beziehen sich auf jede Vorrichtung, oder einen Teil einer solchen, mit Verarbeitungsfähigkeit, die das Ausführen von Anweisungen ermöglicht. Fachleute werden erkennen, dass derartige Verarbeitungsfähigkeiten in vielen verschiedenen Vorrichtungen integriert sind, und der Begriff ”Computer” daher Set-Top-Boxen, Media Player, Digitalradios, PCs, Server, Mobiltelefone, elektronische Organizer und viele andere Geräte umfasst.
Fachleute werden erkennen, dass zur Speicherung von Programmanweisungen verwendete Speichervorrichtungen über ein Netz verteilt sein können. Ein Remote-Computer kann beispielweise ein Muster des als Software bezeichneten Prozesses speichern. Ein lokaler oder Terminalcomputer kann auf den Remote-Computer zugreifen und einen Teil oder die Gesamtheit der Software herunterladen, um das Programm auszuführen. Alternativ kann der lokale Computer Stücke der Software bedarfsgemäß herunterladen oder gewisse Software-Instruktionen am lokalen Terminal und andere am Remote-Computer (oder Computer-Netz) ausführen. Fachleute werden auch erkennen, dass durch Anwendung Fachleuten bekannter, herkömmlicher Techniken alle oder ein Teil der Software-Instruktionen von einem eigenen Schaltkreis ausgeführt werden können, wie zum Beispiel von einem DSP, einer programmierbaren logischen Anordnung usw.
Jeder hier gegebene Bereichs- oder Vorrichtungswert kann ausgedehnt oder geändert werden, ohne den angestrebten Effekt zu verlieren, wie es der fachkundigen Person offensichtlich sein wird.
Es wird darauf hingewiesen, dass sich die oben beschriebenen Nutzungsgewinne und Vorteile auf eine oder auf mehrere Ausführungsformen beziehen können. Die Ausführungsformen sind nicht auf solche beschränkt, die beliebige oder alle der angegebenen Probleme lösen, und auch nicht auf solche, die beliebige oder alle der angegebenen Nutzungsgewinne und Vorteile aufweisen.
Jeder Bezug auf ”ein” Objekt bezieht sich auf ein oder mehrere dieser Objekte. Der Begriff ”umfassen” bedeutet in diesem Dokument, dass angegebene Verfahrensblöcke oder -elemente eingeschlossen sind, jedoch nicht eine exklusive Liste darstellen, sodass ein Verfahren oder eine Vorrichtung zusätzliche Blöcke oder Elemente beinhalten kann.
Die Schritte der hier beschriebenen Verfahren können in jeder geeigneten Reihenfolge ausgeführt werden und, wenn angemessen, auch gleichzeitig. Die Pfeile zwischen den Kästen in den Figuren zeigen eine Beispielsequenz der Verfahrensschritte, sind aber nicht dafür gedacht, andere Sequenzen oder die parallele Ausführung multipler Schritte auszuschließen. Außerdem können einzelne Blöcke von jedem der Verfahren entfernt werden, ohne vom Wesen und dem Umfang des hier beschriebenen Gegenstands abzuweichen. Aspekte jedes der oben beschriebenen Beispiele können mit Aspekten jedes der anderen beschriebenen Beispiele kombiniert werden, um weitere Beispiele zu bilden, ohne den angestrebten Effekt zu verlieren. Für Fälle, bei denen Elemente der Figuren durch Pfeile verbunden dargestellt sind, wird darauf hingewiesen, dass diese Pfeile nur einen Beispielfluss der Kommunikation (einschließlich Daten und Steuermeldungen) zwischen den Elementen zeigen. Der Fluss zwischen den Elementen kann in jeder Richtung oder in beiden Richtungen erfolgen.
Es ist zu anzumerken, dass die obige Beschreibung einer bevorzugten Ausführungsform nur beispielhaft erfolgt, und dass Fachleute verschiedene Modifikationen vornehmen können. Obwohl oben verschiedene Ausführungsformen mit einem gewissen Grad an Eigentümlichkeit oder unter Bezug auf eine oder mehrere einzelne Ausführungsformen beschrieben worden sind, könnten Fachleute zahlreiche Änderungen an den offengelegten Ausführungsformen vornehmen, ohne vom Wesen oder dem Umfang dieser Erfindung abzuweichen.

Claims

Verfahren zur Steuerung des von einem Prozessor erzeugten Traffics, wobei das Verfahren umfasst: Anhängen einer Prefetch-Kennung an eine Prefetch-Anforderung beim Prozessor (202), um die Prefetch-Anforderung als solche und nicht als Nicht-Prefetch-Anforderung auszuweisen, wobei die Prefetch-Anforderung ein Objekt aus einer Speicherhierarchie anfordert, und das Objekt eine Information oder eine Anweisung umfasst; Senden der Prefetch-Anforderung vom Prozessor an die Speicherhierarchie (204); und in Reaktion auf einen Erhalt einer von einem Knoten der Speicherhierarchie basierend auf der Prefetch-Kennung erzeugten Abbruchantwort, die der Prefetch-Anforderung entspricht, beim Prozessor (216), Entfernen wenigstens eines Teils der lokal beim Prozessor gespeicherten Daten bezüglich der Prefetch-Anforderung (218).
Verfahren gemäß Anspruch 1, ferner umfassend: Senden einer neuen Anforderung nach dem Objekt an die Speicherhierarchie (222), wobei die neue Anforderung eine höhere Priorität als die Prefetch-Anforderung hat.
Verfahren gemäß Anspruch 1 oder 2, wobei das Entfernen wenigstens eines Teils der lokal gespeicherten Daten bezüglich der Prefetch-Anforderung umfasst: Entfernen jedes Datensatzes der lokal gespeicherten Prefetch-Anforderung.
Verfahren gemäß einem der vorhergehenden Ansprüche, ferner umfassend: in Reaktion auf den Erhalt einer Gesamtabbruchantwort (216), Entfernen jedes Datensatzes jeglicher unerfüllter, zuvor an die Speicherhierarchie gesendeter Anforderungen (510) einschließlich jeglicher unerfüllter Prefetch-Anforderungen und jeglicher zeitkritischer Anforderungen, die zuvor zur Speicherhierarchie gesendet worden sind.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei das Anhängen einer Prefetch-Kennung an eine Prefetch-Anforderung umfasst: Erzeugen der Prefetch-Anforderung (302); und Einfügen einer Prefetch-Kennung in die Prefetch-Anforderung (304), wobei die Prefetch-Kennung gemäß einem Typ der Prefetch-Anforderung gewählt wird.
Verfahren gemäß Anspruch 5, wobei der Typ der Prefetch-Anforderung eine der folgenden umfasst: eine spekulative Prefetch-Anforderung und eine eindeutige Prefetch-Anforderung.
Verfahren gemäß einem der vorhergehenden Ansprüche, ferner umfassend bei einem Knoten in der Speicherhierarchie: Erhalten der Prefetch-Anforderung vom Prozessor (206), wobei die Prefetch-Anforderung die Prefetch-Kennung umfasst; Bestimmen, basierend auf der Prefetch-Kennung und einer Beurteilung der Traffic-Levels innerhalb eines Teils der Speicherhierarchie, ob eine Abbruchantwort, die der Prefetch-Anforderung entspricht, erzeugt werden soll (208); und falls die Beurteilung bestimmt, dass eine Abbruchantwort zu erzeugen ist, Erzeugen der Abbruchantwort, die der Prefetch-Anforderung entspricht (212).
Verfahren gemäß Anspruch 7, wobei die Beurteilung der Traffic-Levels innerhalb eines Teils der Speicherhierarchie einen Vergleich eines Maßes der Traffic-Levels und einen oder mehrere Schwellenwerte umfasst.
Verfahren gemäß Anspruch 7 oder 8, wobei das Bestimmen, ob eine Abbruchantwort auf die Prefetch-Anforderung erzeugt werden soll, umfasst: Bestimmen, dass eine Abbruchantwort zu erzeugen ist, falls die Anforderung eine Prefetch-Kennung umfasst, und falls Traffic-Levels einen vorbestimmten Level überschreiten; und Bestimmen, dass keine Abbruchantwort zu erzeugen ist, falls die Anforderung keine Prefetch-Kennung umfasst, und/oder falls Traffic-Levels den vorbestimmten Level nicht überschreiten.
Verfahren gemäß Anspruch 7 oder 8, wobei das Bestimmen, ob eine Abbruchantwort auf die Prefetch-Anforderung erzeugt werden soll, umfasst: Bestimmen, dass eine Abbruchantwort zu erzeugen ist, falls die Prefetch-Kennung Filterkriterien erfüllt, und falls Traffic-Levels einen vorbestimmten Level überschreiten; und Bestimmen, dass keine Abbruchantwort zu erzeugen ist, falls die Anforderung keine Prefetch-Kennung umfasst, falls die Prefetch-Kennung die Filterkriterien nicht erfüllt, und/oder falls Traffic-Levels den vorbestimmten Level nicht überschreiten.
Verfahren gemäß Anspruch 10, ferner umfassend: dynamisches Aktualisieren der Filterkriterien basierend auf einer Beurteilung der Traffic-Levels innerhalb eines Teils der Speicherhierarchie (308).
System (100), das umfasst: eine Vielzahl von Vorrichtungen (102, 104, 106), ausgelegt zum Erzeugen von Anforderungen nach Objekten von einer Speicherhierarchie, wobei ein Objekt eine Information oder eine Anweisung umfasst; wenigstens einen Teil der Speicherhierarchie (108); und wenigstens einen Bus (110) zur Verbindung der mehreren Vorrichtungen und der Speicherhierarchie, wobei wenigstens eine der mehreren Vorrichtungen umfasst: eine erste Hardware-Logik (120), ausgelegt zum Anhängen einer Prefetch-Kennung an eine Prefetch-Anforderung, um die Prefetch-Anforderung als solche anstatt einer Nicht-Prefetch-Anforderung auszuweisen, wobei die Prefetch-Anforderung ein Objekt aus einer Speicherhierarchie anfordert, und Senden der Prefetch-Anforderung von der Vorrichtung an die Speicherhierarchie; und eine zweite Hardware-Logik (122), ausgelegt zum Entfernen wenigstens eines Teils der lokal auf der Vorrichtung gespeicherten Daten bezüglich einer Prefetch-Anforderung in Reaktion auf einen Erhalt einer Abbruchantwort, die der von einem Knoten der Speicherhierarchie basierend auf der Prefetch-Kennung erzeugten Prefetch-Anforderung entspricht.
System gemäß Anspruch 12, wobei es sich bei diesem um ein System-on-Chip handelt.
Verfahren zum Zurücksetzen eines Teils eines Systems, wobei das Verfahren umfasst: Erzeugen einer Gesamtabbruchantwort in einer Speicherhierarchie (508); und in Reaktion auf einen Erhalt der Gesamtabbruchantwort bei einem Prozessor, Entfernen wenigstens eines Teils der lokal auf dem Prozessor gespeicherten Daten bezüglich jeglicher unerfüllter, zuvor an die Speicherhierarchie (510) gesendeten Anforderungen nach in der Speicherhierarchie abgelegten Datenobjekten.