-
Querverweis auf verwandte Anwendungen
-
Diese Anmeldung beansprucht die Priorität der Provisional-Patentanmeldung mit der Seriennummer 61/349,584, eingereicht am 28. Mai 2010 mit dem Titel „Storing Data in any of a Plurality of Buffers in a Memory Controller”.
-
Hintergrund
-
Eine Speichersteuerung verwaltet den Datenfluss der auf einen physikalischen Speicher geschrieben und von demselben gelesen wird. Eine „Leseanforderung” ist eine Anforderung, Daten von dem Speicher zu lesen und kann eine Adresse in dem Speicher aufweisen, von der zu lesen ist und einen Identifizierer der Vorrichtung, die von dem Speicher lesen möchte. Eine „Schreibanforderung” ist eine Anforderung, Daten in den Speicher zu schreiben und kann die Daten, die zu schreiben sind, die Adresse in dem Speicher, an die die Daten zu schreiben sind und einen Identifizierer der Vorrichtung, die in den Speicher schreiben möchte, umfassen. Leseanforderungen und Schreibanforderungen von einer bestimmten Vorrichtung dringen durch ein Tor in die Speichersteuerung ein. Eine Mehrtor-Speichersteuerung ist eine Speichersteuerung, die in der Lage ist, Leseanforderungen und Schreibanforderungen von mehr als einer Vorrichtung zu bedienen, wobei jede Vorrichtung einem bestimmten Tor der Speichersteuerung zugewiesen ist.
-
Viele unterschiedliche Vorrichtungen erfordern Zugriff auf physikalischen Speicher aus verschiedenen Gründen (z. B. Speichern von Zeigern, Daten). Um Kosten zu reduzieren, können diese Vorrichtungen einen einzigen physikalischen Speicher gemeinschaftlich verwenden, was zu vielen Speicheranforderungen für die gleiche Ressource führen kann. Nicht alle Speicheranforderungen können gleichzeitig erfüllt werden, daher werden Schreibpuffer verwendet, um anstehende Schreibdaten zu halten, während andere Schreibdaten in den Speicher geschrieben werden. Jedes Tor hat einen zweckgebundenen Schreibpuffer, der es ermöglicht, dass Schreibanforderungen, die in ein Tor kommen, absorbiert werden, ohne die zugeordneten Schreibdaten sofort in den Speicher schreiben zu müssen.
-
Häufig hat ein Tor einer Speichersteuerung eine geringe Nachfrage nach Speicherzugriff während ein anderes Tor eine hohe Nachfrage nach Speicherzugriff hat, somit wird ein Puffer nicht so häufig verwendet wie ein anderer Puffer.
-
Kurze Beschreibung der Zeichnungen
-
Für eine detaillierte Beschreibung der Ausführungsbeispiele der Erfindung wird nachfolgend auf die beiliegenden Zeichnungen Bezug genommen.
-
1 zeigt ein Systemblockdiagramm gemäß verschiedenen Ausführungsbeispielen;
-
2a, 2b, 2c, 2d, 2e und 2f zeigen beispielhafte Tor-Puffer-Diagramme gemäß verschiedenen Ausführungsbeispielen;
-
3a und 3b zeigen beispielhafte Speicherdiagramme gemäß verschiedenen Ausführungsbeispielen;
-
4a zeigt ein Verfahrensflussdiagramm gemäß verschiedenen Ausführungsbeispielen; und
-
4b zeigt ein weiteres Verfahrensflussdiagramm gemäß verschiedenen Ausführungsbeispielen.
-
Notation und Nomenklatur
-
Bestimmte Begriffe werden in der gesamten folgenden Beschreibung und in Ansprüchen verwendet, um bestimmte Systemkomponenten zu bezeichnen. Wie es für einen Fachmann auf diesem Gebiet klar ist, können Computerfirmen eine Komponente unterschiedlich bezeichnen. Dieses Dokument beabsichtigt nicht, zwischen Komponenten zu unterscheiden, die sich nur vom Namen, aber nicht der Funktion her unterscheiden. In der folgenden Erörterung und in den Ansprüchen werden die Begriffe „umfassen” und „aufweisen” auf offene Weise verwendet, und sollten somit bedeuten „aufweisen, aber nicht begrenzt auf...”. Außerdem soll der Begriff „koppeln” oder „koppelt” entweder eine indirekte, direkte, optische oder drahtlose elektrische Verbindung bedeuten. Falls somit eine erste Vorrichtung mit einer zweiten Vorrichtung koppelt, kann diese Verbindung durch eine direkte elektrische Verbindung, durch eine indirekte elektrische Verbindung über andere Vorrichtungen und Verbindungen, durch eine optische elektrische Verbindung oder durch eine drahtlose elektrische Verbindung sein.
-
Detaillierte Beschreibung
-
Die folgende Erörterung bezieht sich auf verschiedene Ausführungsbeispiele der Erfindung. Obwohl eines oder mehrere dieser Ausführungsbeispiele bevorzugt werden können, sollten die offenbarten Ausführungsbeispiele nicht so interpretiert oder anderweitig verwendet werden, dass dieselben den Schutzbereich der Offenbarung einschließlich der Ansprüche begrenzen. Außerdem ist es für einen Fachmann auf diesem Gebiet klar, dass die folgende Beschreibung breite Anwendung findet und die Erörterung jedes Ausführungsbeispiels nur beispielhaft sein soll für dieses Ausführungsbeispiel und nicht den Schutzbereich der Offenbarung einschließlich der Ansprüche auf dieses Ausführungsbeispiel begrenzt.
-
Gemäß verschiedenen Ausführungsbeispielen zeigt 1 eine Speichersteuerung 100, die Tore 102 aufweist, die mit einer Pufferauswahllogik 104 und einer Pufferentscheidungslogik 108 gekoppelt sind. Jedes Tor 102 empfängt Leseanforderungen und Schreibanforderungen von einer Vorrichtung (z. B. einem Prozessor, einem Eingabe/Ausgabegerät, einem Videogerät). Zusätzlich weist die Speichersteuerung 100 Puffer 106 auf, die mit sowohl der Pufferauswahllogik 104 als auch der Pufferentscheidungslogik 108 gekoppelt sind. Die Puffer 106 sind konfiguriert, um Schreibdaten, die einer Schreibanforderung zugeordnet sind, vorübergehend zu speichern, bevor solche Daten in den Speicher geschrieben werden. Bei beispielhaften Ausführungsbeispielen sind die Puffer 106 die Größe einer Cachezeile (z. B. 32 Byte) und jeder speichert Schreibdaten für mehrere Adressen eines Speichers 110. Schreibanforderungen werden von dem Tor 102 zu der Pufferauswahllogik 104 geleitet, während Leseanforderungen von dem Tor 102 zu der Pufferentscheidungslogik 108 geleitet werden. Jedes Tor 102 kann der Pufferauswahllogik 104 während eines bestimmten Zyklus eine Schreibanforderung präsentieren, und somit können der Pufferauswahllogik 104 während eines bestimmten Zyklus mehrere Schreibanforderungen präsentiert werden. Außerdem ist die Pufferentscheidungslogik 108 mit dem Speicher 110 (z. B. Cache) gekoppelt.
-
Die Pufferauswahllogik 104 empfängt Schreibanforderungen von den Toren 102 während eines bestimmten Zyklus und ist sich des Status jedes Puffers 106 bewusst. Beispielsweise ist sich die Pufferauswahllogik 104 des Ursprungstors von Schreibdaten in einem Puffer 106, der Adresse in dem Speicher 110, der die Schreibdaten in dem Puffer 106 entsprechen, und des Adressbereichs (d. h. Cachezeile), der in dem Puffer 106 dargestellt ist, bewusst. Bei einem beispielhaften Ausführungsbeispiel speichern die Puffer 106 32 Byte Schreibdaten und eine Adresse in einem Speicher speichert 2 Byte Daten; somit speichern die Puffer 106 jeweils 16 sequentielle Adressen, die eine Cachezeile bilden. Die Pufferauswahllogik 104 ordnet auch jedes Tor 102 einem eindeutigen Puffer zu, für den das bestimmte Tor höchste Priorität erhält. Beispielsweise erhält Tor_0 die höchste Priorität für Puffer_0, und Tor_7 erhält die höchste Priorität für Puffer_7. Bei einem beispielhaften Ausführungsbeispiel erhält Tor_0 zunehmend niedrigere Prioritäten, wenn sich die Pufferzahl erhöht (z. B. Puffer_9 ist der Puffer niedrigster Priorität für Tor_0); Tor_7 ist ähnlich, die Puffer springen jedoch zurück (z. B. 7, 8, 9, 0, 1, 2, 3, 4, 5, 6), und somit ist der Puffer_6 der Puffer niedrigster Priorität für Tor_7. Als Folge dieses beispielhaften Schemas ist jedes Tor 102 auf jeder Prioritätsebene nur einem Puffer 106 zugeordnet.
-
Bei einem weiteren beispielhaften Schema ändert sich die Zuordnungspriorität jedes Puffers 106 jedes Mal, wenn Schreibdaten in dem Puffer 106 gespeichert werden. Beispielsweise gibt Puffer_0 Tor_0 anfangs höchste Priorität, aber nachdem die Schreibdaten von Tor_0 in den Speicher 110 geschrieben wurden, gibt der Puffer_0 Tor_1 höchste Priorität usw. Folglich gibt jeder Puffer 106 jedem Tor 102 eine gleichmäßiger verteilte Priorität. Gemäß verschiedenen Ausführungsbeispielen kann das Prioritätsschema fest codiert sein in der Schaltungsanordnung der Pufferauswahllogik 104, während bei anderen Ausführungsbeispielen das Prioritätsschema programmierbar sein kann.
-
Gemäß verschiedenen Ausführungsbeispielen empfängt die Pufferentscheidungslogik eine Schreibanforderung von einem oder mehreren Toren 102 während eines bestimmten Zyklus. Ansprechend auf das Empfangen einer Schreibanforderung sendet die Pufferauswahllogik 104 eine Anforderung an alle Puffer 106, um die Verfügbarkeit der Puffer 106 zu bestimmen. 2a–f zeigen darstellende Tor-Puffer-Diagramme 200–250. Beispielsweise empfängt die Pufferauswahllogik 104 in 2a Schreibanforderungen von Tor_0, Tor_1 und Tor_2 (gezeigt als fettgedruckte Kästchen). Es wird angenommen, dass Puffer_0 und Puffer_2 nicht verfügbar sind und alle anderen Puffer (d. h. 1 und 3–9) verfügbar sind (verfügbare Puffer sind als fettgedruckte Kästchen gezeigt). Ein Puffer 106 kann nicht verfügbar sein, falls der Puffer 106 Schreibdaten enthält, die nicht in den Speicher geschrieben wurden, und stellt somit die einzige verfügbare Instanz solcher Schreibdaten dar und kann nicht überschrieben werden. Für jede Schreibanforderung sendet die Pufferauswahllogik 104 eine Anforderung an alle Puffer 106, gezeigt durch die Pfeile in 2a.
-
Falls ein Puffer 106 verfügbar ist, sendet der Puffer 106 eine Bestätigung zurück an die Pufferauswahllogik 104 für die Anforderung, die von dem Tor höchster Priorität des Puffers stammt, was bewirkt, dass die Pufferentscheidungslogik die Schreibanforderung gewährt, die von dem Tor höchster Priorität jedes verfügbaren Puffers stammt. Somit empfängt die Pufferauswahllogik 104 eine Bestätigung von Puffer_1 für Tor_1, gezeigt durch den Pfeil in 2b von Puffer_1 zu Tor_1, da Tor_1 das Tor 102 höchster Priorität für den Puffer_1 ist. Die Pufferauswahllogik 104 empfängt auch eine Bestätigung von jedem Puffer_3–9 für Tor_2, gezeigt durch die anderen Pfeile in 2b, da Tor_2 für jeden dieser Puffer eine höhere Priorität hat als Tor_1 oder Tor_0. Bei diesem beispielhaften Ausführungsbeispiel hat Tor_2 eine höhere Priorität über diese Puffer, da dieselben „näher” sind zu Tor_2 als Tor_0 (z. B. Puffer_3 ist zweiter in der Priorität des Tors_2, während Puffer_3 dritter in der Priorität ist von Tor_1 und vierter in der Priorität von Tor_0 usw.). An diesem Punkt hat die Pufferauswahllogik 104 von keinem Puffer 106 eine Bestätigung empfangen für die Schreibanforderung von Tor_0, da es für jeden verfügbaren Puffer ein Tor höherer Priorität gibt (d. h. Tor_1 oder Tor_2).
-
Um das obige Beispiel fortzuführen, gewährt die Pufferauswahllogik 104 für jedes Tor, das eine Bestätigung von den Puffer 106 empfängt, die Schreibanforderung, und schreibt die Schreibdaten, die der Schreibanforderung zugeordnet sind, in den Puffer 106 mit höchster Priorität dieses Tors. Somit werden die Schreibdaten von Tor_1 in Puffer_1 gespeichert und die Schreibdaten von Tor_2 werden in Puffer_3 gespeichert, gezeigt durch die Pfeile in 2c. Obwohl Puffer_4–9 auch ihre Verfügbarkeit für die Schreibanforderung von Tor_2 bestätigen, sind diese Puffer niedriger in der Priorität von Tor_2 als Puffer_3, der zweiter ist. Wie es oben erläutert wurde, hat die Pufferauswahllogik 104 von keinem Puffer 106 eine Bestätigung empfangen für die Schreibanforderung von Tor_0, und somit wurde die Schreibanforderung von Tor_0 noch nicht gewährt, und die Schreibdaten, die der Schreibanforderung von Tor_0 zugeordnet sind, wurden noch nicht in einem Puffer 106 gespeichert.
-
In dem folgenden Zyklus empfängt die Pufferauswahllogik 104 erneut eine Schreibanforderung von Tor_0. Bei einigen Ausführungsbeispielen bestätigt Tor_0 seine Schreibanforderung erneut während des folgenden Zyklus; alternativ behält Tor_0 seine Schreibanforderung bei und muss die Schreibanforderung während des folgenden Zyklus nicht speziell deaktivieren und neu versuchen. 2d zeigt ein darstellendes Tor-Puffer-Diagramm 230. Tor_1 und Tor_2 sind nicht mehr fettgedruckt, da Schreibdaten, die ihrer Schreibanforderungen zugeordnet waren, durch die Pufferauswahllogik 104 in Puffer_1 bzw. Puffer_3 gespeichert wurden. Puffer_1 und Puffer_3 sind nicht mehr fettgedruckt, da dieselben die Schreibdaten enthalten, die den Schreibanforderungen von Tor_1 und Tor_2 von dem vorhergehenden Zyklus zugeordnet sind und nicht mehr zum Speichern von zusätzlichen Schreibdaten verfügbar sind.
-
Ansprechend auf das Empfangen von Schreibanforderung von Tor_0, sendet die Pufferauswahllogik 104 wie oben eine Anforderung an alle Puffer 106, die Verfügbarkeit der Puffer 106 zu bestimmen, wie es durch die Pfeile in 2d gezeigt ist. Falls ein Puffer 106 verfügbar ist, sendet der Puffer 106 wie oben eine Bestätigung zurück an die Pufferauswahllogik 104 für die Anforderung, die von dem Tor höchster Priorität des Puffers stammt. Somit empfängt die Pufferauswahllogik 104 eine Bestätigung von jedem Puffer_4–9 für Tor_0, gezeigt durch die Pfeile in 2e, da Tor_0 das verbleibende Tor höchster Priorität für jeden dieser Puffer ist. Für jedes Tor, das eine Bestätigung von den Puffer 106 empfängt (an diesem Punkt nur Tor_0), gewährt die Pufferauswahllogik 104 die Schreibanforderung und speichert die Schreibdaten, die der Schreibanforderung zugeordnet sind, von dem Tor_0 in Puffer_4, gezeigt durch den Pfeil in 2f, da Puffer_4 der Puffer höchster Priorität für Tor_0 ist, der die Schreibanforderung von Tor_0 gewährt hat. Obwohl Puffer_5–9 ebenfalls ihre Verfügbarkeit für die Schreibanforderung von Tor_0 bestätigt haben, sind diese Puffer in der Priorität von Tor_0 niedriger als Puffer_4. Ferner wird bei einem alternativen Ausführungsbeispiel die Schreibanforderung von Tor_0 unter Verwendung des oben beschriebenen Schemas gehandhabt, aber während des gleichen Zyklus wie die Schreibanforderungen von Tor_1 und Tor_2.
-
Die Pufferauswahllogik 104 ist als eine zentralisierte Logikeinheit beschrieben, die Schreibanforderungen von den Toren 102 empfängt, eine Anforderung an die Puffer 106 sendet, um die Verfügbarkeit der Puffer 106 zu bestimmen, Bestätigungen der Verfügbarkeit von den Puffer 106 empfängt und Schreibdaten, die den Schreibanforderungen von den Toren 102 zugeordnet sind, in dem geeigneten Puffer 106 speichert. Ein Fachmann auf diesem Gebiet würde jedoch verstehen, dass eine solche Logikimplementierung auf dezentralisierte Weise existieren könnte. Beispielsweise könnten die Tore 102 direkt mit den Puffer 106 kommunizieren. Die Anforderungen von den Toren 102, Pufferverfügbarkeit zu bestimmen, können Informationen aufweisen wie zum Beispiel die Adressen, die den Schreibdaten der Schreibanforderung zugeordnet sind, und andere Informationen, die notwendig sind, um zu bestimmen, ob ein Puffer 106 verfügbar ist. Die Puffer 106 sind konfiguriert, um solche Anforderungen von den Toren 102 zu empfangen und zu bestimmen, ob sie die Anforderung bestätigen. Wie oben bestätigt jeder Puffer 106, falls verfügbar, nur die Anforderung, die von dem Tor höchster Priorität 102 des Puffers 106 stammt. Dann speichert jedes Tor 102, das eine Bestätigung von einem oder mehreren Puffer 106 empfängt, die Schreibdaten, die seiner Schreibanforderung zugeordnet sind, in dem Puffer 106 höchster Priorität, der seine Anforderung bestätigt hat.
-
In der Praxis kann es selten vorkommen, dass während eines bestimmten Zyklus alle Puffer nicht verfügbar sind, dies gilt insbesondere, wenn die Speichersteuerung mit einer größeren Anzahl von Puffern 106 als Toren 102 entworfen ist. Somit können in einem Großteil der Fälle die Schreibdaten, die einer ankommenden Schreibanforderung zugeordnet sind, in einem Puffer 106 gespeichert werden, ohne darauf warten zu müssen, dass die Schreibdaten eines Puffers an den Speicher 110 gesendet werden. Falls alle Puffer für die ankommende Schreibanforderung nicht verfügbar sind, dann muss die Schreibanforderung auf den nächsten Zyklus warten, um zu versuchen, auf einen der Puffer 106 zuzugreifen. Faktoren zum Bestimmen der Verfügbarkeit von Puffer werden nachfolgend näher erläutert.
-
Gemäß verschiedenen Ausführungsbeispielen ist ein Puffer 106 verfügbar, falls derselbe leer ist oder vorher in den Speicher 110 geschrieben wurde, was bestätigt werden kann durch Prüfen eines Besetzt-Bits, das dem Puffer 106 zugeordnet ist. Das Besetzt-Bit für jeden Puffer 106 wird verwendet, um anzuzeigen, dass der Puffer 106 bereits Schreibdaten enthält, so dass das ursprünglich gewährte Tor 102 weiter in diesen Puffer 106 schreiben kann. Falls das Besetzt-Bit deaktiviert ist, ist der Puffer 106 leer. Das Besetzt-Bit ist deaktiviert, wenn die Inhalte eines Puffers 106 zu einem Speicher 110 übertragen werden.
-
Gemäß verschiedenen Ausführungsbeispielen ist die Pufferauswahllogik 104 konfiguriert, um Schreibdaten, die einer aktuellen Schreibanforderung zugeordnet sind, und Schreibdaten, die einer vorhergehenden Schreibanforderung zugeordnet sind, die in einem Puffer 106 gespeichert ist, zu mischen, falls die Daten der aktuellen Schreibanforderungen der gleichen Cachezeile zugeordnet sind wie die Schreibdaten, die in dem Puffer 106 gespeichert sind. Falls die Bedingungen zum Mischen von Schreibdaten, die einer aktuellen Schreibanforderung zugeordnet sind, und Schreibdaten, die einer vorhergehenden Schreibanforderung zugeordnet sind, die in einem Puffer 106 gespeichert ist, erfüllt sind, ist dieser Puffer 106 für diese bestimmte Schreibanforderung verfügbar.
-
3a zeigt ein darstellendes Diagramm des Mischprozesses 300. Falls beispielsweise ein Puffer 106 32 Byte groß ist und eine Adresse 2 Byte im Speicher darstellt, dann weist der Puffer 106 16 Adressenplätze auf (z. B. Adressen 0–15). Falls die vorhergehende Schreibanforderung das Schreiben der Daten „A”–„D” jeweils in die Adressen 4–7 umfasste, dann werden „A”–„D” in Stellen 4–7 des Puffer_0 gespeichert. Die aktuelle Schreibanforderung 302 enthält Schreibdaten „E”–„I” jeweils für Adressen 9–13 (d. h. Adressen in der gleichen Cachezeile wie die vorhergehende Schreibanforderung), die Inhalte des Puffers 106 müssen weder in den Speicher 110 geschrieben werden noch muss die aktuelle Schreibanforderung ihren eigenen Puffer erhalten. Die resultierenden Inhalte 304 des Puffers 106 umfassen Daten für Adressen 4–7 von der vorhergehenden Schreibanforderung und Daten für Adressen 9–13 von der aktuellen Schreibanforderung 302.
-
Da nur die aktuellsten Daten, die in eine Adresse geschrieben werden, für eine nachfolgende Leseanforderung von Bedeutung sind, können alternativ Schreibdaten an überlappende Adressen in einer Cachezeile ebenfalls gemischt werden. 3b zeigt ein weiteres darstellendes Diagramm des Mischprozessors 310. Falls beispielsweise die vorhergehende Schreibanforderung das Schreiben von Daten „A”–„D” jeweils in Adressen 4–7 umfasste, dann werden „A”–„D” in Stellen 4–7 eines Puffers 106 gespeichert. Die aktuelle Schreibanforderung 312 enthält Schreibdaten „J”–„O” jeweils für Adressen 6–11. Die resultierenden Inhalte 314 des Puffers 106 umfassen Daten für Adressen 4–5 von der vorhergehenden Schreibanforderung und Daten für Adressen 6–11 von der aktuellen Schreibanforderung 312. Adressen 6–7 der vorhergehenden Schreibdaten wurden überschrieben.
-
Der Puffer 106 erscheint jedoch für andere Tore nach wie vor als nicht verfügbar, da das Mischen nicht bewirkt hat, dass die Schreibdaten, die in dem Puffer 106 gespeichert sind, in den Speicher 110 geschrieben werden, und somit ist das Besetzt-Bit des Puffers 106 aktiviert. Als Folge ist der Puffer 106 nicht verfügbar, falls die ankommende Schreibanforderung für eine andere Adresse oder Gruppe von Adressen ist als die Adressen der Cachezeile, die durch Schreibdaten dargestellt wird, die in dem Puffer 106 gespeichert sind (d. h. andere Adressen als 0–15) und das Besetzt-Bit des Puffers 106 bleibt aktiviert.
-
Gemäß verschiedenen Ausführungsbeispielen wird das Besetzt-Bit deaktiviert, wenn die Schreibdaten, die in einem Puffer 106 gespeichert werden, in einen Speicher 110 geschrieben werden. Die Pufferentscheidungslogik 108 empfängt Leseanforderungen von den Toren 102 während eines gegebenen Lesezyklus und ist sich des Status jedes Puffers 106 bewusst. Beispielsweise ist sich die Pufferentscheidungslogik 108 des Ursprungstors von Schreibdaten in einem Puffer 106 bewusst, und der Adresse in dem Speicher 110, der die Schreibdaten in einem Puffer 106 entsprechen. Unter Verwendung dieser Informationen bestimmt die Pufferentscheidungslogik 108, wann die Inhalte eines Puffers 106 in den Speicher 110 geschrieben werden. In einigen Fällen kann die Pufferentscheidungslogik 108 bestimmen, dass während eines gegebenen Zyklus die Inhalte von mehr als einem Puffer 106 in den Speicher 110 geschrieben werden sollten. Abhängig von der Größe des Busses in den Speicher 110 können jedoch bei einigen Ausführungsbeispielen die Inhalte von nur einem Puffer 106 pro Zyklus in den Speicher 110 geschrieben werden, somit bestimmt die Pufferentscheidungslogik 108, von welchem Puffer 106 die Inhalte in den Speicher 110 geschrieben werden.
-
Basierend auf dem Auftreten unterschiedlicher Ereignisse bestimmt die Pufferentscheidungslogik 108, die Inhalte eines Puffers 106 in den Speicher 110 zu schreiben. Ein Schreib/Schreibkohärenztreffer tritt auf, wenn eine Schreibanforderung von einem anderen Tor 102 stammt und der gleichen Cachezeile entspricht wie Schreibdaten von einem Tor 102, gespeichert in einem Puffer 106. Falls beispielsweise Schreibdaten, die einer Schreibanforderung von Tor_1 zugeordnet sind, Adressen 0–15 entsprechen, und Tor_0 Schreibdaten in einem Puffer 106 gespeichert hat, der Adressen 0–15 entspricht (d. h. der gleichen Cachezeile, der die Schreibanforderung von Tor_1 entspricht), gab es einen Schreib/Schreibkohärenztreffer. Bei einem beispielhaften Ausführungsbeispiel bewirkt ein Schreib/Schreibkohäherenztreffer, dass die Pufferentscheidungslogik 108 die Inhalte des Puffers 106, der Schreibdaten speichert, die der früheren Schreibanforderung zugeordnet sind, in den Speicher 110 schreibt und das Besetzt-Bit für diesen Puffer 106 deaktiviert. Wenn somit eine Schreibanforderung an die gleiche Cachezeile von einem anderen Tor 102 stammt, können Schreibdaten, die der Schreibanforderung zugeordnet sind, in einem Puffer 106 gespeichert werden, falls einer verfügbar ist, und die Inhalte des Puffers 106, der Schreibdaten speichert, die der früheren Schreibanforderung zugeordnet sind, werden in den Speicher 110 geschrieben. Dies trägt dazu bei, sicherzustellen, dass ankommende Schreibanforderungen nicht darauf warten müssen, dass sich der Puffer 106 höchster Priorität des Tores leert, bevor dieselben in einem Puffer 106 gespeichert werden können, während auch sichergestellt wird, dass ein Tor nicht zu viele Puffer 106 verbraucht als Folge von sequentiellen Schreibanforderungen an unterschiedlichen Cachezeilen in dem Speicher 110. Bei einem alternativen Ausführungsbeispiel wird ein tieferer Schreib/Schreibkohärenztreffer-Schwellenwert gesetzt (d. h. der zweite Schreib/Schreibkohärenztreffer oder eine dritte Schreibanforderung an eine andere Cachezeile statt des ersten Kohärenztreffers bewirkt, dass der Puffer, der Schreibdaten enthält, die der frühesten Schreibanforderung zugeordnet sind, in den Speicher 110 geschrieben wird).
-
Die Pufferentscheidungslogik 108 bestimmt auch, die Inhalte eines Puffers 106 zu schreiben, falls ein Lese/Schreibkohärenztreffer auftritt. Ein Lese/Schreibkohärenztreffer tritt auf, wenn eine Leseanforderung für die gleiche Cachezeile ist wie in einem Puffer 106 gespeichert. Falls die Leseanforderung bedient wurde, bevor die Inhalte des Puffers 106 an den Speicher 110 gesendet wurden, würde die Leseanforderung auf nicht korrekte Daten von dem Speicher 110 zugreifen; somit müssen die Schreibdaten in dem Puffer 106 an den Speicher 110 gesendet werden, bevor die Leseanforderung bedient wird, so dass die Leseanforderung von der „korrekten” Version des Speichers 110 liest (d. h. so dass der Speicher 110 die Daten enthält, die als letztes in die Cachezeile geschrieben wurden). Bei einem alternativen Ausführungsbeispiel sendet die Pufferentscheidungslogik 108 die angeforderten Schreibdaten von dem Puffer 106 direkt an das Tor 102 zurück, ansprechend auf eine Leseanforderung für eine bestimmte Adresse oder Adressen, vorausgesetzt, dass der Puffer 106 alle Schreibdaten enthält, die durch die Leseanforderung angefordert werden. Dies vermeidet, dass die Schreibdaten zuerst an den Speicher 110 gesendet werden müssen und dann nachfolgend die Schreibdaten von dem Speicher 110 gelesen werden müssen. Falls jedoch der Puffer 106 nicht alle Schreibdaten enthält, die durch die Leseanforderung angefordert werden, müssen die Schreibdaten in dem Puffer 106 zuerst in den Speicher 110 geschrieben werden.
-
Falls außerdem kein Lese/Schreibkohärenztreffer auftritt, bedient die Pufferentscheidungslogik 108 die Leseanforderung ohne irgendeinen der Puffer 106 in den Speicher 110 zu schreiben. In solch einer Situation vermeidet die Leseanforderung das Warten darauf, dass Daten in den Speicher geschrieben werden, bevor dieselbe auf den Speicher 110 zugreift und alle Schreibdaten in den Puffer 106 bleiben in den Puffer 106 und bleiben gültig.
-
Gemäß verschiedenen Ausführungsbeispielen ist die Pufferentscheidungslogik 108 konfiguriert, um ein Gültigkeitsbit zu überwachen, das jedem Puffer 106 zugeordnet ist. Das Gültigkeitsbit eines Puffers 106 wird aktiviert, falls bestimmt wird, dass der Schreibpuffer in den Speicher geschrieben werden muss, beispielsweise aus den oben gegebenen Gründen. Die Aktivierung des Gültigkeitsbits des Puffers 106 zeigt der Pufferentscheidungslogik 108 an, dass der Puffer in der Entscheidung für den Speicher 110 teilnehmen muss. Nachdem die Schreibdaten des Puffers 106 in den Speicher 110 geschrieben werden, wird das Gültigkeitsbit deaktiviert.
-
Zusätzlich behält der Puffer 106 ein Statusbit bei für jedes Byte in der Cachezeile (d. h. zwei Statusbits pro Adresse in dem Fall einer 2-Byte-Adressgröße). Das Statusbit zeigt an, ob ein bestimmtes Byte in der Cachezeile gültige Daten enthält, die nicht in den Speicher 110 geschrieben wurden. Auf diese Weise werden nur Bytes, die in der Cachezeile modifiziert wurden, tatsächlich zurückgeschrieben in den Speicher 110, wenn bestimmt wird, dass ein Puffer 106 in den Speicher 110 geschrieben werden muss. Die erste Schreibanforderung an einen leeren Puffer 106 wird bewirken, dass das Statusbit für jedes Byte aktiviert wird, das in den Puffer 106 geschrieben wird.
-
Mit erneuter Bezugnahme auf 3a werden die Statusbits für Adressen 4–7 (d. h. die Adressen, die gültige Daten enthalten, die noch nicht in dem Speicher 110 geschrieben wurden) aktiviert. Die Statusbits für Adressen 0–3 und 8–15 werden deaktiviert, da diese Adressen ungültige Daten enthalten oder vorher in den Speicher 110 geschrieben wurden.
-
Eine nachfolgende Schreibanforderung, die in einen Puffer 106 gemischt wird, aktualisiert die zugehörigen Statusbits, so dass, wenn die Schreibdaten des Puffers 106 schließlich in den Speicher 110 geschrieben werden, die Statusbits, die den gültigen Adressen zugeordnet sind, aktiviert werden. Beispielsweise zeigen die resultierenden Inhalte 304 des Puffers 106, dass die Statusbits für Adressen 4–7 und 9–13 aktiviert werden, da diese Adressen gültige Daten enthalten, die nicht in dem Speicher 110 geschrieben wurden. Die Statusbits für Adressen 0–3, 8 und 14–15 werden deaktiviert, da diese Adressen ungültige Daten enthalten oder vorher in den Speicher 110 geschrieben wurden. Nachdem die Schreibdaten des Puffers 106 in den Speicher 110 geschrieben wurden, werden alles Statusbits deaktiviert.
-
Die Pufferentscheidungslogik 108 deaktiviert auch das Besetzt-Bit für einen Puffer 106 nach dem Schreiben der Inhalte dieses Puffers 106 in den Speicher 110. Falls jedoch die angeforderten Schreibdaten direkt zu dem Tor 102 zurückgesendet werden, deaktiviert die Pufferentscheidungslogik 108 das Besetzt-Bit nicht, da eine weitere Leseanforderung auf dieselbe Cachezeile zugreifen kann und die Inhalte des Puffers 106 nicht in den Speicher 110 geschrieben wurden, somit ist der Puffer 106 nicht leer.
-
Die obige Erörterung adressiert die Szenarien, bei denen nur ein Tor 102 eine Schreib/Schreib-Kohärenztreffer oder einen Lese/Schreib-Kohärenztreffer erzeugt. Ein Fachmann auf diesem Gebiet würde jedoch erkennen, dass aufgrund der Beschaffenheit von Mehrtorspeichersteuerungen mehr als ein Tor 102 in einem gegebenen Zyklus einen Kohärenztreffer erzeugen könnte. Gemäß verschiedenen Ausführungsbeispielen bestimmt die Pufferentscheidungslogik 108 somit welches Tor 102 in dem gegebenen Zyklus auf den Speicher 110 zugreift. Dies könnte auf einer Priorität des Tors 102 basieren, wo Tor_0 die höchste Priorität hat und Tor_7 die niedrigste Priorität hat, oder jedes andere geeignete Verfahren um zwischen konkurrierenden Toren 102 zu entscheiden.
-
4a zeigt ein Verfahren 400 gemäß verschiedenen Ausführungsbeispielen. Das Verfahren beginnt mit dem Empfangen einer oder mehrerer Schreibanforderungen von einem oder mehreren Tore 102 (Block 402). Bei einem beispielhaften Ausführungsbeispiel empfängt die Pufferauswahllogik 104 die eine oder die mehreren Schreibanforderungen. Wie oben erörtert, kann jedoch die Pufferauswahllogik 104 auf dezentralisierte Weise implementiert sein, wo ein Tor 102 eine Schreibanforderung an jeden Puffer 106 sendet und somit jeder Puffer 106 eine oder mehrere Schreibanforderungen empfängt.
-
Das Verfahren 400 fährt fort mit dem Gewähren der Schreibanforderung, die von dem Tor höchster Priorität 102 jedes Puffers 106 stammt (Block 404). Falls ein Puffer 106 verfügbar ist, sendet der Puffer 106 eine Bestätigung zurück an die Pufferauswahllogik 104 für die Anforderung, die von dem Tor höchster Priorität des Puffers stammt, was bewirkt, dass die Pufferauswahllogik die Schreibanforderung gewährt, die von dem Tor höchster Priorität jedes verfügbaren Puffers stammt. Wie es beispielsweise oben mit Bezugnahme auf 2a und 2b erörtert ist, bestätigt jeder Puffer_3–9 die Schreibanforderung von Tor_2 anstatt Tor_0, da bei diesem beispielhaften Schema Tor_2 für jeden dieser Puffer ein Tor höherer Priorität ist. Außerdem ist Tor_1 das Tor höchster Priorität für den Puffer_1, und somit bestätigt der Puffer_1 die Schreibanforderungen von Tor_1. Durch Implementieren der Pufferauswahllogik 104 auf eine dezentralisierte Weise bestätigt jedoch jeder verfügbare Puffers 106 die Schreibanforderung von dem Tor höchster Priorität 102 des Puffers direkt an dieses Tor 102.
-
Für jedes Tor 102, dessen Schreibanforderung gewährt wurde, fährt das Verfahren 400 fort mit dem Speichern der Schreibdaten, die der Schreibanforderung zugeordnet sind, in dem Puffer 106 höchster Priorität des Tors, der die Schreibanforderung des Tors 102 gewährt hat (Block 406). Beispielsweise werden Schreibdaten, die der Schreibanforderung von Tor_1 zugeordnet sind, in Puffer_1 gespeichert, da Puffer_1 der Puffer höchster Priorität ist, der die Schreibanforderung von Tor_1 bestätigt hat. Gleichartig dazu werden Schreibdaten, die der Schreibanforderung von Tor_2 zugeordnet sind, in Puffer_3 gespeichert, da Puffer_3 der Puffer höchster Priorität ist, der die Schreibanforderung von Tor_2 bestätigt hat. Gemäß verschiedenen Ausführungsbeispielen speichert die Pufferauswahllogik 104 die Schreibdaten in dem Puffer 106 höchster Priorität für ein Tor 102. Alternativ ist die Pufferauswahllogik 104 auf dezentralisierte Weise implementiert und ein Tor 102 speichert, auf das Empfangen einer oder mehrerer Gewährungen von den Puffer 106 hin, die Schreibdaten, die der Schreibanforderung von diesem Tor 102 zugeordnet sind, in dem Puffer höchster Priorität 106, der die Schreibanforderungen des Tors 102 gewährt hat.
-
Falls es ein oder mehrere Tore 102 gibt, deren Schreibanforderungen nicht gewährt wurden (Entscheidungsblock 408), kehrt das Verfahren 400 zurück zu Block 402. Falls alle Schreibanforderungen von den Toren 102 gewährt wurden (Entscheidungsblock 408) endet das Verfahren 400. Wie oben kann die Pufferauswahllogik 104 bestimmen, ob es Schreibanforderungen gibt, die nicht gewährt wurden. Alternativ aktiviert ein Tor 102, deren Schreibanforderung nicht gewährt wurde, erneut die Schreibanforderung an jeden Puffer 106 während des nächsten Zyklus, und das Verfahren 400 schreitet auf dezentralisierte Weise fort, wie es oben beschrieben ist.
-
4b zeigt ein Verfahren 410 zum Mischen von Schreibdaten einer aktuellen Schreibanforderung mit Schreibdaten, die bereits in einem Puffer 106 gespeichert sind. Das Verfahren 410 ist eine weitere Erläuterung des Gewährungsschrittes von Block 404 und des Speicherschrittes von Block 406 des Verfahrens 400. Das Verfahren 410 beginnt mit einem Bestimmen, ob die Schreibdaten, die einer aktuellen Schreibanforderung zugeordnet sind, einer Adresse zugeordnet sind, die in einer Cachezeile von Schreibdaten enthalten sind, die in einem Puffer 106 gespeichert sind (Block 412). Wie oben erläutert, enthält ein Puffer 106 beispielsweise 16 Adressenplätze. Falls die Adresse der Schreibdaten, die der aktuellen Schreibanforderung zugeordnet sind, in der Cachezeile enthalten ist (d. h. 16 Adressenplätze eines Puffers 106) (Entscheidungsblock 414), dann führt das Verfahren 410 fort, zu bestimmen, dass der Puffer 106 für die aktuelle Schreibanforderung verfügbar ist (Block 416). Falls jedoch die Adresse der Schreibdaten, die der aktuellen Schreibanforderung zugeordnet sind, nicht in der Cachezeile eines Puffers 106 enthalten ist (Entscheidungsblock 414), dann endet das Verfahren 410. Ein Fachmann auf dem Gebiet würde es verstehen, dass der Puffer 106 nach wie vor verfügbar sein könnte für die aktuelle Schreibanforderung, falls beispielsweise das Besetzt-Bit des Puffers 106 deaktiviert ist oder wird.
-
Falls der Puffer 106 für die aktuelle Schreibanforderung verfügbar ist, fährt das Verfahren 410 damit fort, die Schreibdaten der vorhergehenden Schreibanforderung und die Schreibdaten, die der aktuellen Schreibanforderung zugeordnet sind, zu mischen, wodurch resultierende Schreibdaten erzeugt werden (Block 418). Falls mit erneuter Bezugnahme auf 3a beispielsweise die vorhergehende Schreibanforderung das Schreiben von Daten „A”–„D” jeweils an die Adressen 4–7 umfasste, dann werden „A”–„D” an Stellen 4–7 von Puffer_0 gespeichert. Die aktuelle Schreibanforderung 302 enthält Schreibdaten ”E”–”I” jeweils für Adressen 9–13 (d. h. Adressen in der gleichen Cachezeile wie die vorhergehende Schreibanforderung), die Inhalte von Puffer_0 müssen nicht in den Speicher 110 geschrieben werden und auch die aktuelle Schreibanforderung muss nicht ihren eigenen Puffer erhalten. Die resultierenden Inhalte 304 von Puffer_0 umfassen Daten für Adressen 4–7 von der vorhergehenden Schreibanforderung und Daten für Adressen 9–13 von der aktuellen Schreibanforderung 302.
-
Da nur die aktuellsten Daten, die geschrieben wurden, für eine nachfolgende Leseanforderung von Bedeutung sind, können Schreibdaten alternativ an überlappende Adressen innerhalb einer Cachezeile ebenfalls gemischt werden. Falls beispielsweise mit erneuter Bezugnahme auf 3b die vorhergehende Schreibanforderung das Schreiben von Daten „A”–„D” jeweils an die Adressen 4–7 umfasste, dann werden „A”–„D” an Stellen 4–7 von Puffer_0 gespeichert. Die aktuelle Schreibanforderung 312 enthält Schreibdaten „J”–„O” jeweils für Adressen 6–11. Die resultierenden Inhalte 314 von Puffer_0 umfassen Daten zu Adressen 4–5 von der vorhergehenden Schreibanforderung und Daten für Adressen 6–11 von der aktuellen Schreibanforderung 312. Adressen 6–7 der vorhergehenden Schreibdaten wurden überschrieben.
-
Das Verfahren 410 fährt fort mit dem Speichern der resultierenden Schreibdaten (304 oder 314 von oben) in den Puffer 106 (Puffer_0 in diesem Fall) der vorhergehenden Schreibanforderung (Block 420) und das Verfahren 410 endet.
-
Die obige Erörterung soll darstellend sein für die Prinzipien und verschiedenen Ausführungsbeispiele der vorliegenden Erfindung. Zahlreiche Variationen und Modifikationen werden offensichtlich für Fachleute auf diesem Gebiet, sobald die obige Offenbarung vollständig klar ist. Obwohl Adressen in dem Speicher als zwei Byte groß beschrieben sind, könnten die Adressen kleiner oder größer sein (z. B. Ein-Byte-Adressen, Vier-Byte-Adressen). Die folgenden Ansprüche sollen so interpretiert werden, dass dieselben alle solche Variationen und Modifikationen umfassen.
