DE112011100579T5

DE112011100579T5 - Verfahren und vorrichtung zum verwenden von cachespeicher in einem system, welches einen niedrigleistungszustand unterstützt

Info

Publication number: DE112011100579T5
Application number: DE112011100579T
Authority: DE
Inventors: Christopher B. Wilkerson; Alaa R. Alameldeen; Shih-Lien Lu; Zeshan A. Chishti; Wei Wu; Dinesh Somasekhar
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2010-05-21
Filing date: 2011-05-20
Publication date: 2013-02-07
Anticipated expiration: 2031-05-21
Also published as: WO2011146823A3; WO2011146823A2; GB2506833A; TWI502599B; CN102253865B; BRPI1105243A8; US20110289380A1; GB201122300D0; GB2506833B; KR101495049B1; JP5604513B2; DE112011100579B4; CN102253865A; TW201209841A; BRPI1105243A2; KR20130020808A; US8640005B2; JP2012531683A

Abstract

Es wird ein Cachespeichersystem bereitgestellt, welches einen Mehrbitfehlerkorrekturcode (Error Correcting Code – ECC) mit geringem Speicher- und Komplexitätsüberhang bereitstellt. Das Cachespeichersystem kann bei sehr geringer Leerlaufleistung betrieben werden, ohne dass eine Übergangslatenz in einen und aus einem Leerlaufleistungszustand aufgrund eines Zustandsverlustes dramatisch erhöht wird.

Description

GEBIET
Die vorliegende Erfindung betrifft im Allgemeinen einen Speicher, und im Besonderen ein Verringern des Leistungsverbrauchs eines Cachespeichers, während sich ein System in einem Niedrigleistungszustand befindet.
HINTERGRUND
Technologische Fortschritte haben die Integration von großen, auf einem Chip befindlichen, eingebetteten Dynamic-Random-Access-Memory-(eDRAM)-Cachespeichern mit einer zentralen Verarbeitungseinheit (Central Processing Unit – CPU) ermöglicht. Eingebettetes DRAM ist wesentlich dichter als traditionelle Static-Random-Access-Memories (SRAMs), muss aber periodisch wiederaufgefrischt werden, um Daten zu halten. Wie SRAM ist auch eingebettetes DRAM empfindlich gegenüber Bauelementevariationen, welche eine Rolle beim Bestimmen einer Wiederauffrischperiode für eingebettete DRAM-Zellen spielen. Leistung, welche zum Wiederauffrischen eines eDRAM gebraucht wird, stellt einen großen Anteil der gesamten Systemleistung dar, insbesondere während Niedrigleistungszuständen, wenn sich die CPU im Leerlauf befindet.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Merkmale von Ausführungsformen des beanspruchten Gegenstandes werden deutlich, während die folgende detaillierte Beschreibung voranschreitet, sowie durch Bezugnahme auf die Zeichnungen, in welchen gleiche Zahlen gleiche Elemente bezeichnen, und in welchen:
1 eine Ausführungsform eines Prozessors ist, welcher einen Cachespeicher und eine Fehlerkorrekturlogik (Error Code Correction Logic – ECC) aufweist, gemäß den Prinzipien der vorliegenden Erfindung;
2 ein Blockdiagramm eines Systems ist, welches eine Ausführungsform einer Tabelle kürzlich aufgerufener Zeilen (Recently Accessed Lines Table – RALT) und den Cachespeicher und die ECC-Logik wie in 1 gezeigt aufweist, wodurch ein schneller Zugriff auf eine Cachezeile in dem Cachespeicher illustriert wird;
3 ein Blockdiagramm des in 2 gezeigten Systems ist, wobei ein nachfolgendes Lesen einer Cachezeile innerhalb der Wiederauffrischperiode dargestellt ist;
4A ein Blockdiagramm ist, wobei die Ausführungsform eines ECC-Encoders, welcher in die in 1 gezeigte schnelle ECC-Logik einbezogen ist, dargestellt ist;
4B ein Blockdiagramm ist, wobei eine Ausführungsform eines ECC-Decoders (Dekodierlogik), welche in die in 1 gezeigte schnelle ECC-Logik einbezogen ist, dargestellt ist;
5 ein Flussdiagramm ist, wobei eine Ausführungsform eines Verfahrens zum Verwenden des in 1 dargestellten Systems gemäß den Prinzipien der vorliegenden Erfindung dargestellt ist; und
6 ein Blockdiagramm eines Systems ist, welches eine Ausführungsform des in 1 gezeigten Prozessors aufweist.
Obwohl die folgende detaillierte Beschreibung mit Bezügen auf veranschaulichende Ausführungsformen des beanspruchten Gegenstandes fortfährt, werden viele Alternativen, Modifikationen und Variationen davon für den Fachmann ersichtlich sein. Demgemäß ist es beabsichtigt, dass der beanspruchte Gegenstand breit betrachtet wird und nur wie in den beigefügten Ansprüchen dargelegt definiert ist.
DETAILLIERTE BESCHREIBUNG
Fehlerkorrekturcodes (ECC) werden üblicherweise verwendet, um es nicht-flüchtigen Speichern und nicht-flüchtigen Speichergeräten zu ermöglichen, sowohl weiche als auch harte Fehler zu tolerieren. Auf einem Chip angeordnete Cachespeicher in einem Bauelement und Speicherbauelemente (Chips, integrierte Schaltkreise) verwenden üblicherweise einfache und schnelle ECC, wie zum Beispiel Einzelfehlerkorrektur- und Doppelfehlerkorrektur-(SECDED)-Hammingcodes. Langsamere Bauelemente, wie zum Beispiel Flashspeicher, verwenden Mehrbit-ECCs mit mächtigen Fehlerkorrekturfähigkeiten, zum Beispiel Reed-Solomon-Codes. Die größeren Dekodierlatenzen der mächtigen ECC-Mechanismen stellen für Massenspeichergeräte, wie zum Beispiel Plattenspeicher, kein Problem dar, da die Enkodier/Dekodierlatenz im Vergleich zur intrinsischen Gerätezugriffszeit unwesentlich ist. Trotzdem sind On-Chip-Speicheranordnungen (Cachespeicher) als Ergebnis von Technologieskalierung empfindlicher gegenüber Mehrbitfehlern. Daher sind mächtige ECC-Codes auch für On-Chip-Speicher wünschenswert. Zusätzlich zu dem Latenzüberhang ist der Speicherüberhang der zusätzlichen ECC-Bits ein Hindernis für das Verwenden von Mehrbit-ECC für On-Chip-Cachespeicher.
In dem Bestreben nach verbesserter Leistungs- und Energieeffizienz implementieren Mikroprozessoren eine Anzahl von Leerlaufzuständen, um Niedrigleistungsmodi(-zustände) zu unterstützen. Ein Reduzieren der Leistung, welche während Leerlaufzuständen verbraucht wird, ist insbesondere wichtig, weil die typische Zentralverarbeitungseinheit (Central Processing Unit – CPU) viel Zeit in einem Leerlaufzustand zubringt. Die Technologie eingebetteten DRAMs ermöglicht kleinere Speicherzellen im Vergleich zu SRAM-Zellen, wodurch eine große Zunahme in der Speicherdichte erreicht wird. Daher kann DRAM verwendet werden, um SRAM als last-level On-Chip-Cachespeicher in Hochleistungsprozessoren zu ersetzen.
Dennoch stellt es bei eingebetteten DRAM(eDRAM)-Zellen ein Problem dar, dass die Zellen im Verlauf der Zeit aufgrund von Leckströmen Ladung verlieren. Die Haltezeit einer eDRAM-Zelle ist als die Zeitdauer definiert, über welche die Zelle ihren Zustand (Ladung) halten kann. Die Zellhaltezeit hängt von dem Leckstrom ab, welcher wiederum von dem Bauelementeleckverhalten abhängt. Um den Zustand gespeicherter Daten zu bewahren, müssen eDRAM-Zellen periodisch wiederaufgefrischt werden. Um einen Zustandsverlust in dem Cache zu verhindern, muss die Wiederauffrischperiode kleiner als die Zellhaltezeit sein. Da eDRAM ein DRAM ist, welcher in einen üblichen Logikprozess integriert ist, verwendet er schnelle Logiktransistoren mit höherem Leckstrom als Transistoren, welche im konventionellen DRAM verwendet werden. Daher ist die Wiederauffrischzeit für eDRAM etwa eintausend Mal kürzer als für konventionellen DRAM. Die kürzere Wiederauffrischperiode erhöht die Leistung, welche während des Leerlaufzustands verbraucht wird, und führt ferner zu einer verringerten Verfügbarkeit.
In SRAM-Cachespeichern erzwingen intrinsische Variationen einen Betrieb bei höheren Spannungen aufgrund weniger schwacher Zellen, welche bei geringeren Spannungen ausfallen (Ladung (Zustand) verlieren), und Anstrengungen zum Reduzieren des Leistungsverbrauchs während Leerlaufzuständen behindern. Auf ähnliche Weise beeinflussen Bauelementevariationen in eingebetteten DRAM-Cachespeichern die Haltezeit zwischen einem Wiederauffrischen einzelner DRAM-Zellen, wobei wenige besonders schwache Zellen (Bits) die Wiederauffrischperiode des gesamten Cachespeichers bestimmen. Variationen der Schwellenspannung bewirken, dass Haltezeiten verschiedener DRAM-Zellen signifikant variieren. Diese Variationen werden vornehmlich durch zufällige Dotierungsschwankungen verursacht und manifestieren sich als zufällige Verteilung von Haltezeiten zwischen eDRAM-Zellen. Trotzdem erhöht ein Erhöhen der Wiederauffrischrate die Cacheleistung wesentlich.
Ein Verfahren zum Verringern von Cacheleistung ist das Verwenden von Powergates. Powergates sind Schalter in der Leistungsversorgung, welche es erlauben, dass Leistung an einem Block von Transistoren vollständig abgeschaltet wird. Da Speichertechnologien wie eDRAM und SRAM nicht dazu in der Lage sind, einen Zustand zu halten, wenn sie ohne Leistung sind, bestehen die Kosten des Verwendens von Powergates darin, dass Speicherzustand verloren geht.
Da die Cachespeicherdichte zunimmt, nimmt auch die Leistungsfähigkeit und der Leistungsverbrauch von auf Powergates basierenden Verfahren zu. Da die Größe des eingebetteten DRAM-Cachespeichers zunimmt, existiert ein Kompromiss zwischen Leerlaufaustrittslatenz (Zeit zum Wiederherstellen des Cachezustandes durch ein Zurückgewinnen von Cachezeilen aus einem Hauptspeicher) und Leistungsverbrauch während des Leerlaufzustandes.
Die DRAM-Wiederauffrischperiode kann durch das Verwenden von Fehlerkorrekturcodes (ECC) zum dynamischen Identifizieren und Reparieren von ihren Zustand verlierenden Zellen erhöht werden. Die Wiederauffrischrate wird unabhängig von den schwächsten eDRAM-Zellen gesetzt, wobei ECC verwendet wird, um einen verlorenen Zustand zu kompeusieren. Ein mächtigerer Fehlerkorrekturcode mit der Möglichkeit zum Korrigieren von Mehrbitfehlern impliziert eine erhöhte Wiederauffrischrate und einen verringerten Leistungsverbrauch. Dennoch haben Mehrbit-ECC-Codes einen hohen Speicher- und Komplexitätsüberhang, welche ihre Anwendbarkeit beschränken.
Eine Ausführungsform der vorliegenden Erfindung stellt eine flexible Speicherstruktur bereit, welche Mehrbit-ECC-Codes mit einem geringen Speicher- und Komplexitätsüberhang verwenden und bei sehr geringer Leerlaufleistung betrieben werden können, ohne dass eine Übergangslatenz in den und aus dem Leerlaufleistungszustand aufgrund eines Zustandsverlustes von Zellen (Bits) dramatisch zunimmt.
1 ist eine Ausführungsform eines Prozessors 100, welcher einen Cachespeicher und eine Fehlercodekorrektur-(ECC)-Logik 122 gemäß den Prinzipien der vorliegenden Erfindung aufweist. Die ECC-Logik 122 ist eine niedriglatente, kostengünstige Mehrbitfehlerkorrekturlogik, welche hohe Fehlerraten in flüchtigen Speichern, wie dem in 1 gezeigten Speichercache 110, ausgleicht. In der gezeigten Ausführungsform ist der Speichercache 110 ein eingebetteter DRAM (eDRAM). In anderen Ausführungsformen kann der Speichercache 110 Static Random Access Memory (SRAM) oder jede andere Art von flüchtigem Speicher sein.
Ein Korrigieren von mehr Fehlern erfordert eine höhere Redundanz, welche zu einem großen Überhang an Checkbits führt. Zum Beispiel erfordert ein BCH-Code zum Korrigieren von t-Bit-Fehlern in k-Bit Eingangsdaten üblicherweise r = t·ceil(log₂k) + 1 Checkbits. Aufgrund des logarithmischen Verhältnisses zwischen r und k nimmt die Anzahl von Checkbits langsamer zu als die Größe der Eingangsdaten. Daher wird der Überhang an ECC-Checkbits durch ein Erhöhen von k verringert.
Zum Beispiel erfordert ein Einzelfehlerkorrektur-, Doppelfehlerdetektier-(SECDED-)-Code für eine Cachezeile von 64 Byte (512 Bit) 11 Bit, was ein Überhang von etwa 2% ist. Die Anzahl von Bits in einem ECC-Code relativ zu der Anzahl von Bits in dem Datenwort verringert sich, wenn die Anzahl von Bits in dem Datenwort zunimmt. Zum Beispiel hat ein SECDED-Code für eine Cachezeile mit 64 Byte einen Überhang von 11 Bit (2%) und ein SECDED-Code für eine Cachezeile mit 1042 Byte (1 KB) hat einen Überhang von 15 Bit (0,18%).
Wenn eine große Cachezeile verwendet wird, kann ein Schreiben in Unterblöcken in der Cachezeile es jedoch erfordern, dass die gesamte Cachezeile jedes Mal gelesen wird, um die ECC-Bits wiederherzustellen. Als linearer Code erbt BCH die Additions-Eigenschaft linearer Systeme, welche gewährleistet, das ECC-Checkbits aktualisiert werden können, wobei Azur die Information des modifizierten Unterblocks (Datensegments) verwendet wird. Das Datenwort d (welches eine Cachezeile darstellt) ist in mehrere Segmente (Unterblöcke) [d_i-1, d_i-2, ... d₀] unterteilt. Die G-Matrix, welche beim ECC-Enkodieren verwendet wird, kann in zwei Teile wie G = [I_k, P] unterteilt werden, wobei P der Generator für ein ECC-Checkwort C ist, d. h. C = d × P. Falls das j-te Datensegment d_j mit einem neuen Wert d_{j_new} geschrieben wird, ist der neue ECC: C_new = d_new × P = (d + [0, ..., (d_{j_old} + d_{j_new}), ..., 0]) × P = C + [0, ..., (d_{j_old} + d_{j_new}), ..., 0] × P (1)
Gleichung (1) zeigt, dass die Erzeugung von neuen Checkbits nur die alten Werte der Checkbits und die alten und neuen Werte des zu modifizierenden Unterblocks erfordert.
Zurückkehrend zu 1 ist die ECC-Logik 122 eine niedriglatente, kostengünstige Mehrbit-Fehlerkorrekturlogik, welche hohe Fehlerraten in dem eDRAM-Cachespeicher 110 kompensieren kann. Die ECC-Logik 122 implementiert einen mächtigen BCH-Code mit der Fähigkeit, fünf Fehler zu korrigieren (5EC) und sechs Fehler zu detektieren (6ED) (im Folgenden als 5EC6ED-Code bezeichnet). Ein traditioneller Ansatz, welcher Mehrbit-ECC verwendet, leidet an zwei schwer tragbaren Überhängen, welche seine Anwendbarkeit einschränken. Erstens ist das Aufbauen eines Niedriglatenzdecoders für Mehrbit-ECC-Codes extrem kostspielig. Zweitens ist der Speicherüberhang von ECC-Bits hoch (etwa 10% für ein 5EC6ED-ECC-Code für eine Cachezeile mit 64 Byte).
Die ECC-Logik 122 implementiert einen Mehrbitfehlerkorrekturcode mit sehr geringer Fläche, sehr geringer Latenz und sehr geringem Leistungsüberhang. Die ECC-Logik 122 minimiert einen Leistungsverbrauch des eingebetteten DRAM in Niedrigleistungsbetriebsmodi (Leerlaufzuständen) ohne die Leistungsfähigkeit in dem normalen Betriebsmodus zu beeinträchtigen. Die ECC-Logik 122 weist eine schnelle ECC-Logik 104 auf, welche für diejenigen Cachezeilen, welche eine geringe oder keine Korrektur erfordern, optimiert ist. Die ECC-Logik 122 weist eine Hochlatenz-ECC-Logik 106 für Cachezeilen, welche eine komplexe Mehrbitkorrektur erfordern, auf. Um den Einfluss auf die Leistungsfähigkeit durch das Verarbeiten von hochlatenten Mehrbitkorrekturen zu minimieren, deaktiviert die ECC-Logik 122 in einer Ausführungsform Zeilen mit Mehrbitfehlern. In einer anderen Ausführungsform verwendet die ECC-Logik 122 die natürliche räumliche Lage der Daten, um die Kosten des Speicherns der ECC-Bits zu verringern.
In einer Ausführungsform ist der eingebettete DRAM 110 ein 128-Mega-Byte (MB) last-level (Level 3 (L3))-Cachespeicher, welcher in den Prozessor 100 einbezogen ist. In einer Basiskonfiguration ohne Fehlerkorrekturfähigkeit ist die Zeit zwischen den Wiederauffrischungen für den eingebetteten DRAM-Cachespeicher 110 30 Mikrosekunden (μs). Dies bewirkt eine signifikante Leistungsmenge, welche verbraucht wird, selbst wenn sich die zentrale Verarbeitungseinheit (CPU) 102 im Leerlauf befindet. Leistung, die während des Wiederauffrischens verbraucht wird (Wiederauffrischleistung), kann durch ein Flushen und ein Powergating des eingebetteten DRAM Cachespeichers 110 während Niedrigleistungsbetriebsmodi, z. B. Leerlaufzuständen, verringert werden. Dies bewirkt jedoch eine signifikante Leistungseinbuße, wenn die CPU 102 aus dem Leerlaufmodus(-zustand) erwacht, da die CPU 102 Daten von einem externen Speicher (Hauptspeicher (nicht gezeigt)) in den eingebetteten DRAM Cachespeicher laden muss, wodurch eine große Anzahl von Kaltstartcachefehlern auftritt. Alternativ kann ein Wiederauffrischleistungsverbrauch durch ein Verringern der Wiederauffrischfrequenz reduziert werden, d. h. ein Erhöhen der Wiederauffrischperiode (Zeit zwischen Wiederauffrischungen) der in Cachezeilen in dem eingebetteten DRAM-Cachespeicher 110 gespeicherten Daten. Es gibt jedoch eine höhere Anzahl von Fehlern (Zustandsverluste einzelner Bits (Zellen)) für jede Cachezeile, falls die Wiederauffrischfrequenz verringert wird.
Die ECC-Logik 122 implementiert einen Code auf jeder Cachezeile von 1 KB (5EC6ED), wodurch zusätzliche 71 Bit (0,87% Überhang) für jede Cachezeile, die den 5EC6ED-Code speichert, erforderlich sind. In einer Ausführungsform, in welcher die Wiederauffrischperiode gewählt ist, so dass nicht mehr als 1E-03 (d. h. 1/1000) der Cachezeilen ausfallen wird, wird die Basiskonfiguration ohne Fehlerminderung bei der Basiswiederauffrischzeit von 30 Mikrosekunden (μs) betrieben. Die Fehlerkorrekturcodelogik 122 erlaubt eine Zunahme der Wiederauffrischperiode auf 440 μs, was annähernd eine fünfzehnfache Verringerung der Wiederauffrischperiode im Vergleich zur Basiskonfiguration darstellt.
Logik, welche einen 5EC6ED-Code unterstützt, ist sehr komplex und erzwingt als Nachteil eine lange Dekodierlatenz, welche proportional zu sowohl der Anzahl von korrigierten Fehlerbits als auch der Anzahl von Datenbits ist. Falls ein vollständiges Enkodieren/Dekodieren für jeden Zugriff auf den Cachespeicher erforderlich ist, kann dies die Cachezugriffslatenz wesentlich erhöhen. In einer Ausführungsform der vorliegenden Erfindung können fehleranfällige Bereiche des Caches deaktiviert werden, wodurch die hohe Latenz des Dekodierens während des Betriebes verhindert wird.
Die Fehlerkorrekturlogik 122 weist eine schnelle Fehlerkorrekturcode-(ECC)-Logik (erste Fehlerkorrekturlogik) 104 und eine Hochlatenzfehlerkorrekturcode-(ECC)-Logik (zweite Fehlerkorrekturlogik) 106 auf.
Die Schnell-ECC-Logik (Einheit) 104 weist eine Syndromerzeugungslogik und eine Fehlerkorrekturlogik für Cachezeilen in dem eDRAM 110 mit null oder einem Fehler auf. Die Schnell-ECC-Logik 104 klassifiziert auch Cachezeilen in zwei Gruppen auf der Grundlage des Syndroms: Cachezeilen, welche eine komplexe Mehrbitfehlerkorrektur erfordern und Cachezeilen, welche weniger als zwei, d. h. null oder einen Fehler aufweisen. Cachezeilen, welche eine Mehrbitfehlerkorrektur erfordern, werden an die Hochlatenz-ECC-Verarbeitungslogik(-einheit) 106 weitergeleitet, welche eine Mehrbitfehlerkorrektur durchführt. Cachezeilen, welche durch die Schnell-ECC-Logik 104 korrigiert werden, werden an die CPU 102 über einen L1/L2-Cache 124 weitergeleitet.
In einer Ausführungsform führt die Hochlatenz-ECC-Verarbeitungslogik 106 eine Fehlerkorrektur mittels Software durch. In einer anderen Ausführungsform führt die Hochlatenz-Mehrbit-ECC-Verarbeitungslogik 106 eine Mehrbitfehlerkorrektur mittels einer Zustandsmaschine durch. Die Kombination der Schnell-ECC-Logik 104 und der Hochlatenz-ECC-Verarbeitungslogik 106 erlaubt es, dass Cachezeilen in dem eDRAM 110, welche eine oder weniger Fehlerkorrekturen erfordern, unmittelbar korrigiert und mit geringer Latenz an die CPU 102 über den L1/L2-Cache 124 weitergeleitet werden. Die Latenz nimmt für ein Weiterleiten von Cachezeilen in dem eDRAM 110 mit zwei oder mehr Fehlern an die CPU 102 zu.
Die Schnell-ECC-Logik 104 in der ECC-Logik 122 führt einen Ein-Zyklus-ECC durch, um einen einzelnen Bitfehler in einer Cachezeile in dem eingebetteten DRAM 110 zu korrigieren. Die Hochlatenz-Korrekturlogik 106 in der ECC-Logik 122 führt eine Hochlatenz-ECC-Verarbeitung ohne Pipeline durch, um mehrere Bitfehler in einer Cachezeile zu korrigieren.
Wenn eine Cachezeile aus dem eingebetteten DRAM 110 gelesen wird, wird sie durch den Datenzwischenspeicher 114 zusammen mit der Markierung und den ECC, welche mit der von der Markierungs-/ECC-Anordnung 108 gelesenen Cachezeile verbunden sind, zu der Schnell-Fehlerkorrekturlogik 104 geleitet. Die Markierung und die ECC werden durch den Datenzwischenspeicher 116 an die Schnell-ECC-Logik 104 geleitet. Ein Decoder (nicht gezeigt) in der Schnell-ECC-Logik erzeugt das Syndrom für die empfangene Cachezeile. Das erzeugte Syndrom weist eine Information darüber auf, ob die Cachezeile null, einen oder eine höhere Anzahl von Fehlern aufweist. Falls die Cachezeile null oder einen Bitfehler hat, führt der Decoder in der Schnell-ECC-Logik 104 die Korrektur des einen Bitfehlers in einer kurzen Zeitdauer durch. In einer Ausführungsform kann die kurze Zeitdauer ein einzelner Zyklus (500 Picosekunden (ps)) sein. In anderen Ausführungsformen kann die kurze Zeitperiode mehr als ein Zyklus sein. Die Zeitperiode ist kürzer als die Zeit, um eine Mehrbitfehlerkorrektur durch die Hochlatenz-ECC-Verarbeitungslogik 106 durchzuführen.
Die hohe Latenz, welche mit dem Handhaben von Mehrbitfehlern verbunden ist, kann die Leistungsfähigkeit signifikant reduzieren. Um ein Hervorrufen dieser hohen Latenz zu vermeiden, kann in einer Ausführungsform ein Deaktivieren problematische Zeilen oder ein Mechanismus wie eine Bitausbesserung in eine Reparaturlogik 120 integriert sein.
Die Häufigkeit von Fehlern spielt in der Deaktivierstrategie eine Rolle. Falls eine geringe Mehrbitfehlerrate vorhanden ist, reduziert ein Ansatz wie ein Deaktivieren von Cachezeilen, welche Mehrbitfehler enthalten, die Leistungseinbuße. Ein Deaktivieren von Cachezeilen ergibt jedoch einen unakzeptablen Cachekapazitätsverlust, falls Mehrbitfehlerraten hoch sind. Falls eine hohe Mehrbitfehlerrate vorliegt, kann ein komplexerer Mechanismus wie eine Bitausbesserung verwendet werden, um die durch das Deaktivieren von Cachezeilen verlorene Kapazität zu minimieren.
In einer Ausführungsform ist die Reparaturlogik 120 zwischen die Datenzwischenspeicher 114, 116 und die Schnell-ECC-Logik 122 gekoppelt. Mit der zusätzlichen Reparaturlogik 120 wird die Leistungseinbuße für ein Mehrbitdekodieren nur einmal hervorgerufen, d. h. das erste Mal, wenn ein Fehler aufgrund einer schwachen Zelle in dem eDRAM 110 identifiziert wird. Die Reparaturlogik 120 erlaubt es, dass die Anzahl von Fehlern vor einem Weiterleiten der Cachezeile an die ECC-Logik 122 reduziert wird. Daher wird die Gesamtlatenz reduziert, indem zunächst ein Reparaturmechanismus zum Beheben bekannter Fehler in einer Cachezeile vor einem Anwenden von ECC auf die Cachezeile verwendet wird.
In einer Ausführungsform weist die Reparaturlogik 120 eine Bitausbesserungslogik auf. Die Bitausbesserungslogik identifiziert „zerbrochene” Bit-Paare und hält Flicken bereit, um die „zerbrochenen” Bit-Paare in der Cachezeile zu reparieren. In einer Ausführungsform verwendet die Bitausbesserungslogik ein Viertel der Wege in einem Cachesatz, um Positionen und Ausbesserungsbits für fehlerhafte Bits (d. h. den korrekten Zustand (Wert) für die fehlerhaften Bits in anderen Wegen der Menge) zu speichern. In einem Niedrigspannungsmodus sind in einer Ausführungsform für einen Cachespeicher 110, welcher als ein Acht-Wege-Cache implementiert ist, zwei der acht Wege für das Speichern von Defektkorrekturinformationen zum Korrigieren der „zerbrochenen” Bit-Paare reserviert.
Die Bit-Ausbesserungslogik erlaubt es, dass fehlerhafte Paare, d. h. Gruppen von zwei Bits in der Cachezeile, wovon zumindest ein Bit fehlerhaft ist (aufgrund eines Fehlers beim Halten eines logischen Zustandes) deaktiviert werden. Die Bit-Ausbesserungslogik hält einen Zwei-Bit-„Flicken” (korrekter Bitzustand) bereit, welcher verwendet werden kann, um das fehlerhafte 2-Bit-Paar zu korrigieren. Reparaturmuster werden in ausgewählten Cachezeilen in dem Cachespeicher (eDRAM) 110 gespeichert. Während eines Niedrigspannungsbetriebes sind die Reparaturmuster (Reparaturzeiger und Flicken) in dem Cachespeicher 110 gespeichert. Eine Lese- oder Schreiboperation auf einer Cachezeile holt zunächst die Reparaturmuster für die Cachezeile. Während des Lesens erlauben Reparaturmuster Leseoperationen, um ein Lesen von Daten aus „zerbrochenen” Bits (fehlerhaften Bits) zu vermeiden. Durch ein Verwenden von Flicken aus den Reparaturmustern wird die Cachezeile rekonstruiert, bevor sie an die CPU 102 oder einen anderen Cache weitergeleitet oder zurück in den Speicher geschrieben wird. Während des Schreibens erlauben Reparaturmuster Schreiboperationen, um ein Schreiben auf ausgefallen Bits zu vermeiden. Neue Flicken werden in die Reparaturmuster geschrieben, um neue Daten, die in den Cache geschrieben werden, wiederzugeben. Eine Ausführungsform eines Reparaturmechanismus (Reparaturlogik) 120, welche eine Bit-Ausbesserungslogik verwendet, wurde beschrieben. In anderen Ausführungsformen können andere Reparaturmechanismen als eine Bitausbesserungslogik verwendet werden, um bekannte Fehler auszubessern, bevor ECC angewendet werden.
In einer Ausführungsform ist der Cachespeicher 110 ein 32KB-8-Wege-Cache mit 64B-Cachezeilen. Jeder Zugriff auf in dem Cachespeicher 110 gespeicherte Daten erfordert einen zusätzlichen Zugriff, um die dazugehörigen Reparaturmuster aufzufinden. Um auf die Reparaturmuster zurückzugreifen, ohne die Anzahl von Ports zu erhöhen, organisiert das Bit-Ausbesserungsschema den Cachespeicher 110 in zwei Bänke. Zwei Ausbesserungszeilen werden aufrechterhalten, eine in jeder Bank, und jede wird zum Reparieren von Cachezeilen in der gegenüberliegenden Bank verwendet. Die Reparaturmuster für drei Cachezeilen passen in eine einzelne Cachezeile. Daher wird eine einzelne Ausbesserungszeile (eine Cachezeile, welche Reparaturmuster speichert) für jeweils drei Cachezeilen aufrechterhalten. Eine Ausbesserungszeile wird der Bank gegenüber den drei Cachezeilen, welche ihre Reparaturmuster verwenden, zugeordnet. Dies erlaubt es, dass eine Cachezeile parallel zu ihren Reparaturmustern geholt wird, ohne dass die Anzahl der Cache-Ports erhöht wird.
Bei einem Cachefund wird die Datenzeile aus einer Bank in den Cachespeicher 110 gelesen und eine Ausbesserungszeile wird aus einer anderen Bank in den Cachespeicher 110 gelesen. Die Datenzeilen werden durch „n”-Bit-Schiebe-Stufen geleitet, wobei „n” die Anzahl von fehlerhaften Bit-Paaren darstellt. Jede Stufe entfernt ein fehlerhaftes Paar und ersetzt es durch das ausgebesserte Paar. Da die Ausbesserungszeile auch zerbrochene Bits enthalten kann, wird SECDED-ECC angewandt, um die Reparaturmuster in der Ausbesserungszeile zu korrigieren, bevor sie verwendet werden. Nachdem die Reparaturmuster ausgebessert wurden, werden sie verwendet, um die Datenzeile zu korrigieren. Das Reparieren eines einzelnen fehlerhaften Paares besteht aus drei Teilen. Erstens repariert SECDED-ECC alle fehlerhaften Bits in dem Reparaturmuster. Zweitens identifiziert ein Defektzeiger das fehlerhafte Paar. Nachdem das fehlerhafte Paar entfernt wurde, führt ein Flicken drittens die fehlenden korrekten Bits in die Cachezeile wieder ein.
2 ist ein Blockdiagramm eines Systems 200 mit einer Ausführungsform einer Tabelle kürzlich aufgerufener Zeilen (Recently Accessed Line Table – RALT) 112 und des eingebetteten DRAM-Cache 110 und der ECC-Logik 122, welche in 1 gezeigt sind, wodurch ein schneller Zugriff auf eine Cachezeile in dem eDRAM-Cache 110 illustriert wird.
Eine Cachezeile größer als 64 Bytes wird verwendet, um den Speicherbedarf, welcher zum Speichern von Mehrbit-ECC-Codes erforderlich ist, zu reduzieren. In einer Ausführungsform ist der eDRAM-Cache 110 ein Level 3 (L3)-Cache, welcher ein eingebetteter DRAM mit 128 MB ist, und die Größe der Cachezeile 202 ist 1024 Bytes (1 Kilobyte (KB)). Ein Level 2 (L2)-Cache/Level 1 (L1)-Cache 124 hat eine 64 Byte-(B)-Cachezeile (als ein Unterblock der L3-Cachezeile bezeichnet). Die meisten Schreiboperationen auf dem L3-eDRAM-Cache 110 sind in der Form von kleineren Unterblöcken von 64 Byte, welche von Cachespeichern 124 eines niedrigeren Levels (L1 oder L2) erzeugt werden oder aus einem Nicht-Cachespeicher (Hauptspeicher/externen Speicher (nicht gezeigt)) geholt werden.
Um einen Unterblock 204 von 64 B in einer Cachezeile 202 von 1 KB zu modifizieren, wird eine Lese-Modifizier-Schreib-Operation durch die CPU 102 ausgeführt, um den ECC-Code zu berechnen. Zunächst wird der Unterblock 204 von 64 B, welcher überschrieben wird, aus dem eDRAM-Speicher 110 zusammen mit dem ECC-Code 208 für die gesamte Cachezeile 202 von 1 KB gelesen. Die alten Daten, der alte ECC-Code, und neue Daten werden verwendet, um den neuen ECC 208 für die gesamte Cachezeile 202 von 1 KB zu berechnen. Der neue Unterblock 204 von 64 B und ein neuer ECC-Code 208 werden zurück in den L3-eDRAM-Cache 110 geschrieben. Es wird jedoch nicht die gesamte Cachezeile 202 von 1 KB gelesen, um den neuen ECC 208 zu berechnen, wie später noch diskutiert werden wird.
Die meisten Leseoperationen auf dem L3-Cache 110 werden durchgeführt, um Cachezeilen zur Allokation im Cache 124 mit niedrigerem Level (L1 und L2) bereitzustellen. Ein Verarbeiten eines Unterblocks 204 einer Cachezeile 202 erfordert, dass der ECC 208 mit dem gesamten Datenwort (eine Cachezeile von 1 KB) 202, welches es schützt, verarbeitet wird. Da jeder Unterblock 204 von 64 Byte in der Cachezeile 202 von 1 KB überprüft werden muss, wird jede Referenz auf einen Unterblock 204 von 64 B von einer Referenz auf die umgebenden Unterblöcke 204 von 64 B begleitet. Daher greift jede Leseoperation des L3-eingebetteten DRAM-Cache 110 auf alle 16 Unterblöcke 204 von 64 Byte in der Cachezeile 202 von 1 KB, zusätzlich zu denn ECC 208 (pro Cachezeile) zu, welche sich alle Unterblöcke 204 in der Cachezeilt 202 teilen. Zum Beispiel werden um nur acht der 16 Unterblöcke 204 in einer Cachezeile 202 von 1 KB zu lesen, alle 16 Unterblöcke 204 acht Mal gelesen, es ergeben sich also insgesamt 128 separate Unterblock-Leseoperationen. Diese hohe Anzahl von zusätzlichen Unterblockleseoperationen ergibt eine wesentliche Zunahme an dynamischem Leistungsverbrauch und eine Reduktion der nutzbaren Cache-Bandbreite, die durch den eDRAM-Cache 110 bereitgestellt wird.
Die Mehrheit von eDRAM-Fehler beruhen auf Haltefehlern, da der eDRAM-Cache 110, wie bereits dargestellt, periodisch aufgefrischt werden muss, um den aktuellen Zustand jeder Speicherzelle aufrechtzuerhalten. In einer Ausführungsform ist die Haltezeit 30 Mikrosekunden (μs) und jedes Lesen einer einzelnen Cachezeile impliziert automatisch ein Wiederauffrischen dieser Cachezeile. Daher sollten Haltefehler in einer einzelnen Cachezeile nicht innerhalb von 30 μs geschehen, nachdem diese Cachezeile gelesen wurde. Diese Beobachtung erlaubt es, dass die Anzahl von überflüssigen Leseoperationen minimiert wird. Die RALT 112 wird verwendet, um Cachezeilen ausfindig zu machen, welche innerhalb der letzten 30 μs referenziert (gelesen) wurden.
Das erste Lesen einer Cachezeile 202 in den eDRAM-Cache 110 bewirkt, dass alle Unterblöcke 204 in der Cachezeile 202 gelesen und auf Fehler überprüft werden. Die Adresse der Cachezeile 202, welche gelesen wird, wird in einem RALT-Eintrag 206 in der RALT 112 gespeichert. Die gespeicherte Adresse zeigt an, dass die Cachezeile 202 kürzlich gelesen und überprüft wurde, und daher für die nächsten 30 μs frei von Haltefehlern bleiben sollte. Während die Adresse der gelesenen Cachezeile in der RALT 112 gespeichert ist, kann jedes nachfolgende Lesen von Unterblöcken der Cachezeile 202 auf ein ECC-Verarbeiten verzichten und daher ein Lesen des mit der Cachezeile 202 und anderen Unterblöcken 204 in der Cachezeile 202 verbundenen ECC 208 vermieden werden. Die RALT 112 gewährleistet, dass keine ihrer Einträge 206 seit mehr als 30 μs gespeichert sind, indem jede 30 μs lange Zeitperiode in mehrere gleiche „Cachezeilen-Lese-Perioden” aufgeteilt wird. Einträge 206, welche in der RALT 112 während jeder Periode alloziert werden, werden mit einem Periodenidentifizierer 214, welcher die Unterwiederauffrischperiode identifiziert, markiert. Übergänge zwischen Unterwiederauffrischperioden bewirken, dass alle zuvor in den mehreren „Cachezeilen-Lese-Perioden” allozierten RALT-Einträge ungültig gemacht werden (angezeigt durch den Zustand des „Gültig-Feldes”, welches mit dem Eintrag 206 in der RALT in Verbindung steht).
Jeder Eintrag 206 in der RALT 112 weist die folgenden Felder auf: Ein Zeilenadressfeld 209 zum Identifizieren der Cachezeile, mit welcher der Eintrag verbunden ist, ein Gültigfeld 212, ein Periodenidentifiziererfeld 214 zum Anzeigen, in welcher Periode die Zeile alloziert wurde, und ein Paritätsfeld 211, welches ein Paritätsbit für jeden Unterblock in der Cachezeile aufweist. In einer Ausführungsform weist das Periodenidentifiziererfeld 214 zwei Bits auf, um anzuzeigen, in welcher von vier Perioden (P0, P1, P2, P3) die Cachezeile alloziert wurde, und hat das Paritätsfeld 211 16 Bit, eines pro Unterblock von 64 B in der Cachezeile. Die RALT 112 wird unmittelbar abgebildet, aber unterstützt ein Ungültigmachen durch ein CAM (Content Adressable Memory) auf dem Periodenfeld 214, um ein massenhaftes Ungültigerklären von Einträgen 206 in der RALT 112 während Periodenübergängen zu ermöglichen.
Wenn ein Unterblock 204 zum ersten Mal gelesen wird, wird auch das gesamte ECC 208 zusammen mit jedem Unterblock in der Cachezeile 202 von 1 KB gelesen, um ein ECC-Verarbeiten für einen einzelnen Unterblock 204 von 64 B zu ermöglichen. Der mit Cachezeile 202 in der RALT 112 verbundene Eintrag 206 wird mit der Zeilenadresse der referenzierten Cachezeile 202, einem Periodenidentifizierer und einem einzelnen Paritätsbit für jeden Unterblock 204 in der Cachezeile 202 aktualisiert. Nach dem ersten Treffer auf einer Cachezeile 202 erfordern zukünftige Zugriffe auf die gleiche Cachezeile 202 innerhalb der Wiederauffrischperiode kein ECC-Verarbeiten.
Die erste Leseoperation auf einer Cachezeile bewirkt, dass alle Unterblöcke in der Zeile gelesen werden und auf Fehler überprüft werden. Die Adresse der Zeile wird dann in der RALT gespeichert, um anzuzeigen, dass sie kürzlich überprüft wurde und für die nächsten 30 μs frei von Zurückhaltefehlern bleiben wird. Solange die Adresse der Zeile in der RALT gespeichert ist, kann jedes Lesen eines Unterblocks der Zeile auf ein ECC-Verarbeiten verzichten und vermeidet daher ein Lesen des ECC-Codes und anderer Unterblöcke in der Zeile.
Zum korrekten Arbeiten gewährleistet die RALT 112, dass keiner ihrer Einträge mehr als 30 μs alt ist. Um dies sicherzustellen, wird ein Zähler 216 verwendet, um den Ablauf jeder 30 μs langen Periode zu messen. Jede 30 μs lange Periode wird in vier gleiche Unterperioden (P0, P1, P2, P3) unterteilt. Einträge, die in der RALT 112 während jeder Periode alloziert werden, werden mit einem 2-Bit-Identifizierer markiert, um die Allokationsunterperiode zu spezifizieren, welche durch ein Überprüfen des aktuellen Wertes des Zählers bestimmt werden kann. Zum Beispiel kann der Ablauf von 30 μs bei einem 2 GHz-Prozessor 100 durch Verwenden eines Zählers 216 gemessen werden, welcher bis 60000 zählend in jedem Zyklus erhöht wird. Zählerwerte zwischen 0–15000 entsprechen beispielsweise der Unterperiode P0, 15001–30000 entsprechen Unterperiode P1, 30001–45000 entsprechen Unterperiode P2 und 45001–60000 entspricht Unterperiode P3. Wenn der Zähler 216 60000 erreicht, setzt er sich auf 0 zurück, was einen Übergang von P3 zu P0 ergibt. Jeder Unterperiodenübergang kann das Ungültigmachen einiger oder aller RALT-Einträge, welche während des vorherigen Auftretens der Unterperiode alloziert wurden, bewirken. Zum Beispiel ergibt ein Übergang von der Unterperiode P0 zu der Unterperiode P1, dass alle RALT-Einträge, welche in einer Unterperiode P1 alloziert wurden, ungültig gemacht werden.
3 ist ein Blockdiagramm des in 2 gezeigten Systems, welches eine nachfolgende Leseoperation auf einer Cachezeile innerhalb der Wiederauffrischperiode darstellt. In den meisten Fällen wird nur der angeforderte Unterblock 204 von 64 B gelesen. Die Parität für den Unterblock 204 von 64 B wird berechnet und mit der Parität 211 für diesen Unterblock 204 von 64 B der Cachezeile 202, welcher in der RALT 112 gespeichert ist, verglichen. Falls es eine Übereinstimmung gibt, ist die Folge, dass der Unterblock 204 von 64 B gültig ist und der Unterblock 204 von 64 B an den anfordernden Cache 124 oder Prozessor 102 weitergeleitet wird. Eine fehlende Übereinstimmung der Parität wird als RALT-Fehler behandelt und die gesamte Cachezeile 202 von 1 KB wird gelesen. Die RALT 112 wird verwendet, um Cachezeilen 202, auf welche kürzlich zugegriffen wurde, ausfindig zu machen, um ein Lesen der gesamten Cachezeile 202 von 1 KB bei jeder Cache-Lese-Operation zu vermeiden, wodurch die dynamische Leistung minimiert würde.
4A ist ein Blockdiagramm, wobei eine Ausführungsform eines ECC-Decoders 400, welcher in die in 1 gezeigte Schnell-ECC-Logik 104 einbezogen ist, illustriert wird. BCH-Codes sind eine große Klasse von Mehrbitfehlerkorrekturcodes, welche sowohl hochkonzentrierte als auch weit verstreute Fehler korrigieren können. Im Allgemeinen ist jeder BCH-Code ein linearer Blockcode, welcher über ein finites Galois-Feld GF(2^m) mit einem Erzeugerpolynom definiert ist, wobei 2^m die maximale Anzahl von Codewortbits darstellt.
Der ECC-Encoder (Encoderlogik) 400 nimmt das k-Biteingangsdatenwort d und verwendet eine vordefinierte Encoder-Matrix G, um das entsprechende Codewort u (u = d × G) zu erzeugen. Da BCH ein systematischer Code ist, werden die ursprünglichen k-Bitdaten in dem Codewort u(x) zurückgehalten, wobei ihnen r Checkbits folgen.
4B ist ein Blockdiagramm, wobei eine Ausführungsform eines ECC-Decoders (Dekodierlogik) 402 dargestellt ist, welcher in die in 1 gezeigte Schnell-ECC-Logik einbezogen ist. Die Dekodierlogik 402 detektiert und korrigiert alle Fehler in dem empfangenen Codewort u(x), um den ursprünglichen Datenwert wiederherzustellen. Die Dekodierlogik 402 weist eine Syndromerzeugungslogik 404, eine Fehlerklassifizierungslogik 406 und eine Fehlerkorrekturlogik 408 auf.
Die Syndromerzeugungslogik 404 berechnet zunächst ein Syndrom S durch ein Multiplizieren von v (ein Codewort mit Fehler e, so dass v = u + e ist) mit der Transponierten einer vordefinierten H-Matrix (S = v × H^T). Die G- und H-Matrizen sind derart konstruiert, dass G × H^T = 0. Die allgemeine Form einer H-Matrix ist wie folgt:
In dem finiten Feld GF(2^m) kann jedes Element αⁱ als ein Polynom von α mit einer Ordnung kleiner als m oder einfach durch einen Vektor mit m binären Koeffizienten des Polynoms dargestellt werden. Daher kann die H-Matrix in eine Binärmatrix mit (t·m + 1) Zeilen entwickelt werden, wobei t die maximale Anzahl von Fehlern ist, welche der Code korrigieren kann. Da S = v × H^T ist, hat auch S t·m + 1 Bits, welche in mehrere Komponenten [Parität, S1, S3 ..., S_2t-1] unterteilt werden können.
Die Fehlerklassifizierungslogik verwendet das Syndrom S, um zu detektieren, ob das Codewort Fehler aufweist. Da: S = v × H^T = (u + e) × H^T = (d × G + e)× H^T = d × (G × H^T) + e × H^T = e × H^T (3)
Im Falle von null Fehlern gilt daher S = 0 und die folgende Gleichung wäre wahr: Parität = S₁ = S₃ = ... = S_2t-1 = 0 (4)
Keine Fehler in dem Codewort rühren zu einem Syndromwert von null, wie in Gleichung (3) gezeigt. Dieser Fall kann detektiert werden, indem ein logisches OR aller Syndrombits durchgeführt wird. Dies erfordert ceil(log₂tm) 2-Eingangsgateverzögerungen.
Die Fehlerkorrekturlogik verwendet den Syndromwert, um die Orte von beschädigten Bits zu lokalisieren, falls die obige Gleichung nicht erfüllt ist.
Wenn angenommen wird, dass die Fehlerorte in e als [j₁, j₂, ..., j_t] notiert werden können, dann kann jede Syndromkomponente S_i folgendermaßen spezifiziert werden: S_i = α^j1·i + α^j2·i + ... + 1^jt·i (5)
Die Korrekturlogik implementiert die folgenden drei Schritte:
Schritt 1: Bestimme die Koeffizienten des Fehlerortpolynoms σ(x), wobei σ(x) derart definiert ist, dass die Wurzeln von σ(x) jeweils durch die Inverse von Fehlerelementen α^j1, α^j2, ..., α^jt gegeben sind, σ(x) = 1 + σ₁x + ... + σ_tx^t = (1 – α^j ¹x)(1 – α^j2x) ... (1 – α^jtx) (6)
Schritt 1 der Fehlerkorrektur basiert auf einem iterativen Algorithmus mit t Schritten, wobei jede Iteration eine Galois-Feldinversion impliziert, welche allein 2 m Operationen erfordert.
Schritt 2: Löse die Wurzeln von σ(x) auf, welche die Fehlerorte sind. Wenn das Polynom σ(x) bestimmt wird, wird jedes Feldelement α^j in das Polynom ersetzt. Diese Elemente, welche das Polynom gleich null machen, sind die Wurzeln. Die Implementation von Schritt 2 kann entweder n Zyklen mit einem Schaltkreis, oder einen einzelnen Zyklus mit n parallelen Schaltkreisen erfordern. In jedem Fall ist der Basisschaltkreis O(t·m²).
Schritt 3: Berechne den korrekten Wert für Datenbits. Dies wird durch ein einfaches Umdrehen der Bits an den Fehlerorten getan.
In dem Fall eines Einzelbitfehlers entspricht das Syndrom exakt der H-Matrixzeile, welche dem Fehlerbit entspricht. Daher kann ein Einzelbitfehler durch ein Vergleichen jeder Zeile der H-Matrix mit dem Syndrom ermittelt werden. Diese Korrektur ist wesentlich schneller als der allgemeine Fall einer t-Bitkorrektur (mit t > 1), da sie Schritt 1 und den größten Teil von Schritt 2 der Fehlerkorrekturlogik nicht erfordert. Nicht alle Syndromkomponenten müssen mit den gesamten H-Matrixspalten abgeglichen werden. Es ist lediglich erforderlich, dass S₁ mit jeder Spalte in H₁ (definiert in Gleichung (1)) verglichen wird und sichergestellt wird, dass die folgende Gleichung erfüllt ist: [(Parität = 1) & (S₁ ³ == S₃) & (S₁ ⁵ == S₅) & ... & (S₁ ^2t-1 == S_2t-1)] == 1 (7)
Um eine Latenz zu minimieren, können ein Vergleich von S₁ mit H₁ und all die Vergleiche in der Gleichung (7) parallel voranschreiten.
5 ist ein Flussdiagramm, welches eine Ausführungsform eines Verfahrens zum Verwenden des in 1 dargestellten Systems 100, gemäß den Prinzipien der vorliegenden Erfindung darstellt.
Falls bei Block 500 die Cachezeilenadresse (addr) mit einem RALT-Eintrag 206 in der Tabelle der kürzlich aufgerufenen Zeilen (Recently Accessed Line Table) 112 verbunden ist, wurde auf die Cachezeile kürzlich zugegriffen und ein Überprüfen auf Fehler ist nicht erforderlich, und die Cachezeile wird an die CPU 102 über den L1/L2-Cache 124 weitergeleitet. Falls nicht, fährt die Bearbeitung mit Block 502 fort.
Bei Block 502 wird die Cachezeilenadresse (addr) in einem Zeilenadressfeld 209 in einem RALT-Eintrag 206 der RALT-Tabelle 112 gespeichert, wie zuvor im Zusammenhang mit 2 diskutiert. Daten, welche in der Cachezeile in Cachespeicher 110 gespeichert sind, und die Markierung/ECC, welche in der Markierungs/ECC-Anordnung 118 entsprechend der Adresse gespeichert sind, werden gelesen und durch die Datenzwischenspeicher 114, 116 weitergeleitet. Das Verarbeiten fährt mit Block 504 fort.
Bei Block 504 fährt das Verarbeiten in einer Ausführungsform, welche eine Reparaturlogik 120 aufweist, mit einem Block 512 zum Reparieren der Cachezeile fort. In einer Ausführungsform, welche keine Reparaturlogik aufweist, fährt das Verarbeiten mit Block 506 fort.
Bei Block 506 wird ein schneller ECC durch eine Schnell-ECC-Logik 104 durchgeführt, um zu bestimmen, ob Fehler in der Cachezeile vorliegen. Das Verarbeiten fährt mit Block 508 fort.
Falls bei Block 508 mehr als zwei zu korrigierende Fehler in der Cachezeile vorliegen, fährt das Verarbeiten mit Block 514 fort. Wenn weniger als zwei Fehler vorliegen, wird der Fehler durch die Schnell-ECC-Logik 104 korrigiert und das Verarbeiten fährt mit Block 510 fort.
Bei Block 510 werden die korrigierten Cachezeilendaten an die CPU 102 über den L1/L2-Cache 124 weitergeleitet.
Bei Block 512 werden die aus dem Cachespeicher gelesenen und durch die Datenzwischenspeicher 114, 116 weitergeleiteten Cachezeilendaten repariert, wie zuvor diskutiert. Das Verarbeiten fährt mit Block 506 fort.
Bei Block 514 korrigiert die Hi-ECC-Logik 110 den Multibitfehler in der Cachezeile und das Verarbeiten fährt mit Block 510 fort.
6 ist ein Blockdiagramm eines Systems 600, welches eine Ausführungsform des in 1 gezeigten Prozessors 100 aufweist. Das System 600 weist einen Prozessor 100 mit einem eingebetteten Cachespeicher, einen Memory-Controller-Hub (MCH) 602 und einen Input/Output(I/O)-Controller Hub (ICH) 604 auf. Der MCH 602 weist einen Speichercontroller 606 auf, welcher eine Kommunikation zwischen dem Prozessor 601 und einem externen Speicher (Hauptspeicher) 610 steuert. Der Prozessor 100 und der MCH 602 kommunizieren über einen Systembus 616.
Die CPU 102 kann ein beliebiger einer Mehrzahl von Prozessoren sein, wie ein Einzelkern-Intel^®-Pentium-IV^®-Prozessor, ein Einzelkern-Intel-Celeron-Prozessor, ein Intel^®-XScale-Prozessor oder ein Mehrkern-Prozessor, wie ein Intel^®-Pentium-D, Intel^®-Xeon^®-Prozessor oder Intel^®-Core^®-Duo-Prozessor oder jeder andere Typ von Prozessor.
Der Speicher 610 kann ein Dynamic-Random-Access-Memory (DRAM), ein Static-Random-Access-Memory (SRAM), ein Synchronized-Dynamic-Random-Access-Memory (SDRAM), ein Double-Data-Rate-2-(DDR2)-RAM oder ein Rambus-Dynamic-Random-Access-Memory (RDRAM) oder jeder andere Typ von Speicher sein.
Der ICH 604 kann an den MCH 602 gekoppelt sein, wobei eine Chip-zu-Chip-Verbindung 614 hoher Geschwindigkeit wie ein Direct-Media-Interface (DMI) verwendet wird. DMI unterstützt Raten von 2 GB/Sekunde gleichzeitigen Transfers über zwei unidirektionale Spuren.
Der ICH 604 kann einen Speicher-Input/Output(I/O)-Controller zum Steuern einer Kommunikation mit zumindest einem Speichergerät 612, welches mit dem ICH 604 gekoppelt ist, aufweisen. Das Speichergerät kann beispielsweise ein Plattenlaufwerk, ein Digital-Video-Disk-(DVD)-Laufwerk, ein Compact-Disk-(CD)-Laufwerk, ein Redundant-Array-of-Independent-Disks-(RAID)-Laufwerk, ein Bandlaufwerk oder ein anderes Speichergerät sein. Der ICH 604 kann mit dem Speichergerät 612 über eine Speicherprotokollverbindung 618 kommunizieren, wobei ein serielles Speicherprotokoll wie ein Serial-Attached-Small-Computer-System-Interface (SAS) oder ein Serial-Advanced-Technology-Attachment (SA-TA) verwendet wird.
Für. den Durchschnittsfachmann wird erkennbar sein, dass bei Ausführungsformen der vorliegenden Erfindung verwendete Verfahren in einem Computerprogrammprodukt implementiert sein können, welches ein durch ein Computer verwendbares Medium aufweist. Zum Beispiel kann solch ein durch einen Computer verwendbares Medium aus einem Nur-Lesespeichergerät, wie z. B. einer Compact-Disk-Read-Only-Memory-(CD-ROM)-Scheibe oder konventionellen ROM-Geräten oder einer Computerdiskette mit einem darauf gespeicherten computerlesbaren Programmcode bestehen.
Während Ausführungsformen der Erfindung im Besonderen gezeigt und unter Bezugnahmen auf Ausführungsformen davon beschrieben wurden, wird es von Fachleuten verstanden werden, dass verschiedene Änderungen in Form und Einzelheiten daran durchgeführt werden können, ohne von dem Rahmen der Ausführungsformen der Erfindung abzuweichen, welcher von den beigefügten Ansprüchen umfasst ist.

Claims

Vorrichtung, welche Folgendes umfasst: einen Cachespeicher; und eine Fehlerkorrekturlogik zum Empfangen von Daten, welche in einer Cachezeile in dem Cachespeicher gespeichert sind, wobei die Fehlerkorrekturlogik Folgendes umfasst: eine erste Fehlerkorrekturlogik zum Erzeugen eines Syndroms für die empfangene Cachezeile, welche aus dem Cachespeicher gelesen wurde, um eine Anzahl von Fehlern in der Cachezeile zu bestimmen; eine zweite Fehlerkorrekturlogik, um die Cachezeile von der ersten Fehlerkorrekturlogik nur zu empfangen, wenn die Cachezeile mehr als einen Fehler aufweist, wobei die zweite Fehlerkorrekturlogik dazu dient, eine Mehrbitfehlerkorrektur für die empfangene Cachezeile durchzuführen.
Vorrichtung nach Anspruch 1, welche weiter Folgendes umfasst: eine Reparaturlogik, wobei die Reparaturlogik dazu dient, bekannte Fehler in der Cachezeile auszubessern, bevor die Cachezeile an die Fehlerkorrekturlogik weitergeleitet wird.
Vorrichtung nach Anspruch 1, wobei der Cachespeicher ein flüchtiger Speicher ist.
Vorrichtung nach Anspruch 1, wobei die erste Fehlerkorrekturlogik einen Decoder zum Ausführen einer Korrektur in einer kürzeren Zeitperiode als die Mehrbitfehlerkorrektur aufweist.
Vorrichtung nach Anspruch 1, wobei die erste Fehlerkorrekturlogik eine Syndromerzeugungslogik und eine Fehlerkorrekturlogik für Cachezeilen mit null oder einem Fehler aufweist.
Vorrichtung nach Anspruch 1, welche weiter Folgendes umfasst: eine Tabelle kürzlich aufgerufener Zeilen (Recently Accessed Line Table – RALT), welche an den Adressbus des Cachespeichers gekoppelt ist, wobei die RALT dazu dient zu bestimmen, ob auf die adressierte Cachezeile innerhalb einer aktuellen Wiederauffrischzeitperiode des flüchtigen Cachespeichers zugegriffen wurde.
Vorrichtung nach Anspruch 6, wobei die RALT verwendet wird, um Zeilen, auf welche kürzlich zugegriffen wurde, aufzufinden.
Vorrichtung nach Anspruch 1, wobei die erste Fehlerkorrekturlogik dazu dient, eine Fehlerkorrektur für den einzelnen Fehler in der empfangenen Cachezeile durchzuführen.
Verfahren, welches Folgendes umfasst: Speichern von Daten in einem Cachespeicher; Empfangen von in einer Cachezeile in dem Cachespeicher gespeicherten Daten durch eine Fehlerkorrekturlogik, wobei die Fehlerkorrekturlogik eine erste Fehlerkorrekturlogik und eine zweite Fehlerkorrekturlogik umfasst; Erzeugen eines Syndroms für die empfangene Cachezeile, welche aus dem Cachespeicher gelesen wurde, durch die erste Fehlerkorrekturlogik, um eine Anzahl von Fehlern in der Cachezeile zu bestimmen; Weiterleiten der Cachezeile durch die erste Fehlerkorrekturlogik an eine zweite Fehlerkorrekturlogik, nur wenn die Cachezeile mehr als einen Fehler aufweist; Ausführen einer Mehrbitfehlerkorrektur für die empfangene Cachezeile durch die zweite Fehlerkorrekturlogik.
Verfahren nach Anspruch 9, welches weiter Folgendes umfasst: Reparieren bekannter Fehler in der Cachezeile durch eine Reparaturlogik vor einem Weiterleiten der Cachezeile an die Fehlerkorrekturlogik.
Verfahren nach Anspruch 9, welches weiter Folgendes umfasst: Ausführen einer Korrektur durch die erste Fehlerkorrektureinheit in einer kürzeren Zeitperiode als die Mehrbitfehlerkorrektur.
Verfahren nach Anspruch 11, welches weiter Folgendes umfasst: Bestimmen, ob auf die adressierte Cachezeile innerhalb einer aktuellen Wiederauffrischzeitperiode des Cachespeichers zugegriffen wurde, durch eine Tabelle kürzlich aufgerufener Zeilen (Recently Accessed Line Table – RALT), welche an den Adressbus des Cachespeichers gekoppelt ist.
Verfahren nach Anspruch 12, welches weiter Folgendes umfasst: Auffinden von Cachezeilen, auf welche kürzlich zugegriffen wurde, durch die RALT.
Verfahren nach Anspruch 9, welches weiter Folgendes umfasst: Ausführen einer Fehlerkorrektur für den einzelnen Fehler in der empfangenen Cachezeile durch die erste Fehlerkorrekturlogik.
Erzeugnis, welches ein maschinenlesbares Medium mit zugehörigen Informationen aufweist, wobei die Informationen, wenn darauf zugegriffen wird, bewirken, dass eine Maschine Folgendes ausführt: Speichern von Daten in einem Cachespeicher; Empfangen von Daten, welche in einer Cachezeile in dem Cachespeicher gespeichert sind, durch eine Fehlerkorrekturlogik, wobei die Fehlerkorrekturlogik eine erste Fehlerkorrekturlogik und eine zweite Fehlerkorrekturlogik umfasst; Erzeugen eines Syndroms für die empfangene Cachezeile, welche aus dem Cachespeicher gelesen wurde, durch die erste Fehlerkorrekturlogik, um eine Anzahl von Fehlern in der Cachezeile zu bestimmen; Weiterleiten der Cachezeile von der ersten Fehlerkorrekturlogik an die zweite Fehlerkorrekturlogik, nur wenn die Cachezeile mehr als einen Fehler aufweist; und Ausführen einer Mehrbitfehlerkorrektur für die empfangene Cachezeile durch die zweite Fehlerkorrekturlogik.
Erzeugnis nach Anspruch 15, welches weiter Folgendes umfasst: Reparieren bekannter Fehler in der Cachezeile durch eine Reparaturlogik vor einem Weiterleiten der Cachezeile an die Fehlerkorrekturlogik.
Erzeugnis nach Anspruch 15, welches weiter Folgendes umfasst: Ausführen einer Korrektur durch die erste Fehlerkorrekturlogik in einer kürzeren Zeitperiode als die Mehrbitfehlerkorrektur.
Erzeugnis nach Anspruch 15, welches weiter Folgendes umfasst: Bestimmen, ob auf die adressierte Cachezeile innerhalb einer aktuellen Auffrischzeitperiode des Cachespeichers zugegriffen wurde, durch eine Tabelle kürzlich aufgerufener Zeilen (Recently Accessed Line Table – RALT), welche an den Adressbus des Cachespeichers gekoppelt ist.
Erzeugnis nach Anspruch 15, welches weiter Folgendes umfasst: Ausführen einer Fehlerkorrektur für den einzelnen Fehler in der empfangenen Cachezeile durch die erste Fehlerkorrekturlogik.
System, welches Folgendes umfasst: einen externen Speicher; und einen Prozessor, wobei der Prozessor Folgendes umfasst: einen Cachespeicher, um Daten, welche aus dem externen Speicher gelesen wurden, zu speichern; und eine Fehlerkorrekturlogik zum Empfangen von Daten, welche in einer Cachezeile in dem Cachespeicher gespeichert sind, wobei die Fehlerkorrekturlogik Folgendes umfasst: eine erste Fehlerkorrekturlogik zum Erzeugen eines Syndroms für die empfangene Cachezeile, welche aus dem Cachespeicher gelesen wurde, um einen Anzahl von Fehlern in der Cachezeile zu bestimmen; und eine zweite Fehlerkorrekturlogik, um die Cachezeile von der ersten Fehlerkorrekturlogik nur zu empfangen, wenn die Cachezeile mehr als einen Fehler aufweist, wobei die zweite Fehlerkorrekturlogik dazu dient, eine Mehrbitfehlerkorrektur für die empfangene Cachezeile durchzuführen.
System nach Anspruch 20, welches weiter Folgendes umfasst: eine Reparaturlogik, wobei die Reparaturlogik dazu dient, bekannte Fehler in der Cachezeile vor einem Weiterleiten der Cachezeile an die Fehlerkorrekturlogik auszubessern.
System nach Anspruch 20, wobei die erste Fehlerkorrekturlogik einen Decoder zum Ausführen einer Korrektur in einer kürzeren Zeitperiode als die Mehrbitfehlerkorrektur sowie Syndromerzeugungslogik und Fehlerkorrekturlogik für Cachezeilen mit null oder einem Fehler aufweist.