Alte Mythen

Die folgende Situation kommt wohl jedem von uns bekannt vor: Ein neuer Chip betritt die Bildfläche. Wenige Stunden später wimmelt es in Foren nur so vor Gerüchten und Halbinformationen, je nach der Informationspolitik des Herstellers. Mit dem rapiden Anstieg von Wissen über die Funktionsweise von Chips ist dies zwar heute nicht mehr so dramatisch wie noch vor einigen Jahren, dennoch ist die Situation prinzipiell immer noch so, da die Hersteller auch heutzutage zumeist nicht sehr freigiebig mit handfesten technischen Informationen sind.

Um so schneller werden nun aus Gerüchten und Spekulationen harte, jedoch unbestätigte Fakten. Manche davon nisten sich recht schnell und dann gleichzeitig auch beharrlich bei uns ein. So auch die oftmals vertretene Meinung, deaktivierte Caches bei Prozessoren wären zwingend defekt. So heißt es des öfteren, das Abschalten des Caches würde CPUs vor der Müllhalde retten.

Nun stimmt es tatsächlich, dass AMD und Intel CPUs mit teilweise abgeschaltetem Level2-Cache unter neuem Namen ausliefern. Im Detail geht uns Usern dann meist die Hälfte des Caches durch die Lappen. Die bekanntesten Vertreter mit deaktivierten Caches sind einige Athlon 64 und Athlon XP Modelle sowie natürlich der Celeron. Gerade Intel stellt mit dem Celeron den Urahn dieser Vorgehensweise zum Verkauf.

Sind nun aber alle diese CPUs mit Defekten in einer der Cachehälften belastet? Aller Wahrscheinlichkeit nach stehen eher komplexe marktwirtschaftliche Gründe hinter diesen Entscheidungen. Wir wollen allerdings gar nicht so tief in die wirtschaftlichen Entscheidungen hinter der Chipfertigung eintauchen. Wir wollen dagegen jedoch behaupten: Weniger defekte Caches und Recycling von schrottreifen Chips, sondern Flexibilität und Kostenersparnis zeigen sich hier bestimmend.

Wie kommen wir auf diese Idee? Nun, gerade für Caches gibt es gute Methoden, um Defekten entgegenzuwirken. Dazu ist es allerdings vorteilhaft, ein wenig über die Hintergründe Bescheid zu wissen.

Wie Defekte im Chip entstehen

Halbleiterfirmen müssen sich mit einer Vielzahl von Defekten abärgern. Ein Teil entsteht bereits beim Design des Chips. Hier ist der Schuldige schnell gefunden. Andere sind auf unreife oder fehlerhafte Fertigungsschritte zurückzuführen. Wie so oft, lassen sich diese Probleme mit Zeit und Geld lösen. Dummerweise gibt noch eine recht unberechenbare Art von Fertigungsdefekten.

Die Herstellung von Halbleiterschaltkreisen legt höchsten Wert auf Reinheit bei Maschinen, Materialien und Luft. Trotzdem lässt es sich nicht vollständig vermeiden, dass im Laufe der Fertigung doch einmal ein Defekt im Wafer oder den Schaltungen entsteht. Bereits ein unscheinbarer Partikel reicht, um eine Schaltung kurzzuschließen und damit zu zerstören.

Dabei ist die Anzahl und Verteilung der Fehler ein rein statistischer Wert. Niemand kann genau vorhersagen, wie viele Fehler auftreten. Auch die Position der Defekte bleibt bis zum Ende unbekannt. Allgemein spricht man von der Defektdichte auf dem Wafer. Wie viele dieser Fehler sich an den Chips vergreifen, liegt letztendlich am Fertigungsprozess. Verschiedene Hersteller, ja sogar einzelne Fertigungsanlagen eines Herstellers, besitzen unterschiedliche Werte für Defektdichten.

Bisher fehlt uns natürlich jegliche Vergleichsbasis für die Häufigkeit dieser Fehler: Was ist gut, wann ist zuviel? Und wer kann am wenigsten dieser Defekte aufweisen? Als erster Anhaltspunkt hierzu kann folgendes gelten: 1995 musste Intel mit 0.5 bis 0.8 Fehlern pro cm² Wafer-Fläche rechnen. Die Werte entstammten übrigens dem Fertigungsprozess des Pentium Pro Level2-Caches. Entsprechenden Werte von Heute gehören zu den bestgehütetsten Geheimnissen der Hersteller. Mit ihnen könnte man die Anzahl an funktionsfähigen Chips der Konkurrenz recht genau bestimmen.

Halbleitergrößen wie AMD und Intel haben ihre Prozesse und Fertigungsanlagen speziell auf ihre Bedürfnisse angepasst. Wir können hier nach einigen Aussagen pauschal von ca. 0.2 bis 0.3 Fehlern pro cm² Wafer-Fläche ausgehen. Damit erreichen AMD und Intel mit die niedrigsten Fehlerraten in der ganzen Industrie – weit vor Herstellern wie TSMC oder IBM. Diese müssen allerdings einen umfassenderen Prozess für eine größere Produktpalette anbieten. Eine Vielzahl von Halbleiterprodukten machen einen universelleren Fertigungsprozess nötig, womit automatisch die Fehlerrate steigt.

Redundanz als teilweise Lösung des Problems

Eigentlich erscheint es doch nur allzu logisch: Ein Chip mit einem Defekt ist funktionsunfähig und landet auf dem Müll – einfach mal so reparieren, ist in der Mikroelektronik nicht drin. Lange Zeit war dies auch der Fall. Einen bestimmten Teil der produzierten Chips konnte man aufgrund dieser Defekte auf keinen Fall mehr benutzen bzw. musste beschädigte Cache-Teile komplett deaktivieren.

Erst das Konzept der Redundanz brachte eine Änderung. Redundanz steht im Allgemeinen für einen Überschuss an Information, der nicht genutzt wird. Im Normalfall ist Redundanz schlecht. Man nutzt mehr Ressourcen, als man wirklich braucht – was teuerer ist als nötig. Allerdings wird Redundanz auch zur Fehlerkorrektur eingesetzt. Im Fall der Computerchips spricht man hier von überschüssigen Schaltungen, die jedoch absichtlich verbaut werden. Wenn man zusätzliche Schaltungen hat, kann man damit Defekte ersetzen.

Reparieren geht also doch? Ja, aber nur begrenzt. Man kann nicht für jede Schaltung im Chip einen Ersatz hinzufügen. Wenn aber große Teile des Chips identisch aufgebaut sind, steigt die Chance, einen Fehler mit einer insgesamt nur geringen Anzahl an redundanten Schaltung ausbessern zu können. An diesem Punkt fällt die Wahl natürlich auf den Cache. Dieser besteht aus ewig lange Reihen und Spalten aus den immer gleichen Schaltelementen.

Man könnte jetzt annehmen, die Probleme der Hersteller wären damit gelöst. Schön wäre es, aber Redundanz lässt sich effektiv eben nur bei Caches anwenden. Trifft ein Defekt auf eine Logikschaltung, muss man den Müllstapel um einen Chip bereichern. Befindet sich der Defekt jedoch im Cache, kommt das Prinzip der Redundanz voll zum tragen.

Cache besteht aus endlos scheinenden Zeilen und Spalten aus Speicherzellen. Innerhalb des Caches sitzen wiederum einzelne Gruppen von redundanten Cachezellen ohne anfängliche Funktion. Beim CPU-Selbsttest wird der komplette Cachespeicher einer Prüfung unterzogen. Ist ein Fehler gefunden, wird er vorgemerkt. Es wird festgestellt, ob eine Ausbesserung möglich ist, und welche redundante Gruppe die Aufgabe übernehmen kann. So können beim anschließend zwingend nötigen Initialisieren (Programmieren) des Caches die defekten Cachezellen ersetzt werden. In den meisten Fällen ist der Chip jetzt gerettet und voll funktionsfähig.

Im Detail werden natürlich keine einzelnen Zellen ersetzt, sondern ganze Reihen davon. Eine gezielte Zelle zu isolieren und deren Arbeit von einer Zelle an einem beliebigen anderen Ort des Chips ausführen zu lassen, gleicht einem Akt der Unmöglichkeit. Der Ausfall einer einzelnen Cachezelle hat vielmehr den Austausch einer ganzen Zellgruppe zur Folge. In der Initialisierungsphase wird jene Gruppe mit dem Defekt übergangen, und eine Redundante stattdessen programmiert.

Allerdings sprechen wir hier nur von relativ wenigen redundanten Gruppen im Chip. Um die Chipfläche und Kosten niedrig zu halten, wird auch die Redundanz, sprich die Anzahl dieser Transistoren, welche für redundante Schaltungen aufgewendet werden, natürlich niedrig gehalten. Es geht hier also um wenige hundert KiloByte zusätzlichem Cache für mehrere MegaByte nominellen Caches. Allerdings ist das bereits ausreichend. Um eine Vorstellung vom Cacheaufbau zu bekommen, hilft eventuell folgendes Bild:

Cache-Organisation

Cache-Organisation: Redundante Zellen sind mit “R” gekennzeichnet

 

Der Cache selbst ist demnach in sogenannte Subarrays gegliedert, jedes davon mit einer bestimmten Anzahl von Zellgruppen. In den häufigsten Fällen gibt es pro Subarray nur eine redundante Gruppe. Um den Chip nicht zu sehr zu vergrößern, muss hier gespart werden. Es kann in der Regel oft nur ein Fehler pro Subarray korrigiert werden. Durch eine hohe Defektdichte kann die Redundanz also ausgehebelt werden. Bei einer so hohen Defektdichte kann man jedoch sowieso davon ausgehen, dass dann wahrscheinlich auch der Logikteil der CPU beschädigt ist.

Das Auswechseln defekter Cachezellen wird von einem Algorithmus erledigt, der sowohl das Prüfen als auch das Ersetzen gezielt steuert. Durch Redundanz verringert sich zudem die benötigte Zeit, die für das Prüfen der Chips veranschlagt werden muss – und Zeit ist bekanntlich Geld. Insgesamt war man bei Intel 1995 also sehr angetan von dieser neuen Idee. Das dürfte sich auch bei anderen Herstellern bis heute nicht anders verhalten.

Auswirkungen der Redundanz

Durch das Konzept der Redundanz werden moderne CPUs mit großen Level2-Caches erst ermöglicht. Es sind nur Gerüchte, aber AMD hatte angeblich keine Freunde mit ihrem ersten OnDie Level2-Cache bei K6-III, welcher in der Folge unter Produktionsproblemen litt und lange Zeit überhaupt nicht zu bekommen war. Erst als man Redundanz auch beim Cache des K6-III einführt, besserte sich die Lage.

Defektverteilung auf Wafern

Die schwarzen Punkte sind die anfallenden Fehler. Ist ein Chip betroffen, wird sein völliger Ausfall angenommen. Wie man anhand der Illustrationen erkennen kann, sind größere DIEs anfälliger für einen Fehler.

Uns allen ist klar, mehr Cache verbessert die Performance. Allerdings nimmt dabei auch die Chipfläche ordentlich zu. Durch Redundanz lässt sich nun selbst mit viel Cache noch eine akzeptable Ausbeute erreichen. Will man stattdessen die Performance des Chips nur durch zusätzliche Features verbessern, stößt man auf größere Probleme. Der Logikanteil steigt schnell an, und damit auch die Chipfläche. Hier nützt auch keine Redundanz. Man ahnt es schon, mehr defekte Chips sind die Folge. Im direkten Vergleich ist ein “dicker” Cache also günstiger. Nur darum sind Giganten wie AMDs 193mm² Opteron, oder Intels Pentium 4 Extreme Edition trotz ihrer Größe noch rentabel herstellbar.

Deaktivierte Level2-Caches

Kommen wir zurück zu CPUs mit teilweise deaktiviertem Level2-Cache. Man findet diese “kastrierten” CPUs z.B im Athlon XP Thorton, einigen Athlon 64 3000+ und selbstverständlich auch beim Celeron-Prozessor in dessen vielfältigen Ausführungen. Aber sind diese wirklich aufgrund von Defekten abgeschaltet? Sehen wir uns die Verteilung der Defekte auf dem Wafer noch einmal an.

Sieht jemand mehr als ein oder zwei Fehler gleichzeitig auf einem Chip? Manche kommen ganz ungeschoren davon, andere trifft es schlimmer. Aber nur in den wenigsten Fällen wird ein Chip gleich mehrmals Opfer eines Defekts.


Cache (grün) und Logik (blau) eingefärbt

Als kontrastreiches Gegenbeispiel lassen sich hier GPUs, also die Chips der Grafikchip-Entwickler, oder der UltraSPARC-IV von Sun anführen. Der momentane UltraSPARC-IV ist eine riesige DualCore CPU ohne Level2-Cache. Nahezu der gesamte Chip besteht aus Logik. Ein Defekt führt fast sicher zum Ausfall eines der Kerne – und es gibt nichts, was Sun dagegen tun könnte.

Aber auch Intel kann mit einem Logikmonster aufwarten. Der Prescott besitzt zwar 1 MB Level2 Cache, dieser ist jedoch ausgesprochen klein verglichen mit dem Kern selbst. Besser sieht das Verhältnis bei der Pentium 4 Extreme Extreme Edition, dem Pentium-M oder dem nachfolgend zu sehenden Foto des Opteron-Prozessors aus.


Vergleich zwischen Prescott (links) und Opteron (rechts)

Einige CPUs als auch GPUs von nVidia und ATi erreichen also enorme Flächenausmaße. Das Problem wird dadurch natürlich intensiviert. Bei DualCore CPUs kann es sich lohnen, den beschädigten Kern abzuschalten. Bei GPUs besteht bekanntlich die Möglichkeit, zusammenhängende Pixel-Pipelines zu deaktivieren.

Intels Itanium 2 werden zuweilen mit 6 MB oder 9 MB an Level3-Cache auf dem DIE gefertigt. Auch hier zeigt sich Redundanz als einer der wichtigsten Maßnahmen gegen Defekte. Natürlich kann man somit fehlerhafte Chips als 3-MB-Modelle verkaufen. Aber selbst diese 3 MB überschatten die 512 kB oder 1 MB Level2-Cache heutiger Desktop-CPUs. Zukünftige Itanium Prozessoren werden sogar mit 24 MB Cache antreten. Wären die Defekte in diesen Transistoren-Monstern groß genug, um die Produktion dieser Prozessoren ernsthaft zu gefähren, würde man diese Vorhaben sicherlich gar nicht antreten können – was im Umkehrschluß auch heißt, daß heutige Desktop-Prozessoren mit Cache-Größen von 512 kB und 1 MB kaum mit einer hohen Defektdichte kämpfen können.

Auf der technischen Seite verringert sich im übrigen beim Abschalten des Caches nicht einmal spürbar die Leistungsaufnahme des Prozessors. Der Cache wird in der Regel weiterhin mit einem Taktsignal versorgt, und das schluckt ebenfalls Leistung. Ansonst gibt er sich natürlich arbeitslos.

Mit diesem Wissen bleiben eigentlich hauptsächlich die bereits erwähnten marktwirtschaftliche Gründe für das Deaktivieren der Level2-Caches bei einigen der heutigen Desktop-Prozessoren. Es muss schlicht günstiger sein, den Cache einfach teilweisse abzuschalten, als einen eigenen Kern für die geringere Menge an Cache zu fertigen.

Denn es bedeutet für die Hersteller einen gehörigen Zusatzaufwand, eine bestehende CPU noch einmal, ohne einen Teil des Level2-Cache, zu fertigen. Für die Fertigung werden eigene Fotolithographiemasken benötigt, nach ihrem Vorbild entsteht dann die neue CPU. Die Prozessschritte selbst laufen dann getrennt von den anderen Kernen ab. Das heißt, sie müssen teilweise separat davon betreut werden. Zudem besitzt auch die größte Fertigungsanlage eine begrenzte Kapazität. Viele verschiedene Kerne zu fertigen, führt zu alles anderem als optimalen Ergebnissen.

Besonders für AMD ist dies von großer Bedeutung. Natürlich fertigt man gegenüber Intel nur auf kleineren 200mm Wafern und ist damit auf kleinere Kerne angewiesen, um mehr fertigen zu können. Zugleich besitzt man aber auch nur eine Halbleiteranlage (Fab30 Dresden) und genau einmal Personal dafür. Was AMD demnach dringend braucht, ist maximale Flexibilität. Wie wir uns alle vorstellen können, dürfte eine gewichtige Fehlkalkulation gehörige Verluste für AMD bedeuten. Fällt man zu weit hinter Intel zurück, wäre zudem recht schnell vieles von dem verloren, was man sich seit Jahren erkämpft hat.

Es macht zudem generell immer Sinn, sich schnell an eine neue Marktsituation anpassen zu können, anstatt starr für jedes Marktsegment extra Kerne zu fertigen. Ähnliches geschieht schon seit Jahren bei der Festlegung der Taktraten. Oftmals sind CPUs in der Lage, höhere Taktraten zu erreichen, als ihre Bezeichnung vermuten lässt. Die hohe Nachfrage nach niedrig getakteten Modellen bei gleichzeitig gut laufender Produktion von hoch getakteten Modellen macht in vielen Fällen eine tiefere Einstufung eines produzierten Prozessors nötig. Effizienter kann man kaum auf eine Veränderung der Nachfrage reagieren.

Beim Level2-Cache dürfte es sich ähnlich verhalten. Besonders AMD musste zu Beginn seiner K8-Erfolgsgeschichte mit Kontern von Intel rechnen. Zusätzlich zu Clawhammer (Athlon 64) und Sledgehammer (Opteron) noch weitere Kerne zu fertigen, hätte fatale Folgen, sollten sich diese als zu langsam erweisen.

Bei Intel gestaltet sich das natürlich anders: Mit Unmengen an Kapazität und hohen Gewinnmargen, kann man sich eher den umgedrehten Weg leisten. Und so wurden und werden aus Top-Produkten wie dem Pentium 4 letztlich Celeron-Prozessoren. Doch sinkt die Nachfrage nach Celerons, hat man zu keinem Zeitpunkt in stillstehenden Produktionsanlagen noch Berge von dann unnützen LowCost-Produkten herumliegen, die einem niemand mehr abnimmt.

CPUs mit deaktivierten Level2-Caches

Bisher ging es um Redundanz, Fertigung und marktwirtschaftliche Gründe. Der ein oder andere fragt sich jedoch vielleicht, welche CPUs nun letztlich davon betroffen sind und wie man diese Level2-Caches eventuell wieder reaktiviert.

Als Vorreiter des Deaktivierens von Level2-Cache dürfe sich Intels Celeron II ab 533 MHz rühmen. Intel nutze die Coppermine-Kerne der Pentium III Prozessoren und deaktivierte die Hälfte des Level2-Caches. Der Käufer musste mit einem Performanceverlust rechnen, bekam dafür aber einen aktuellen Core inklusive SSE auch bei LowCost-Modellen.

Die heutigen Celerons auf Pentium-4-Basis stammen ebenfalls direkt von ihren großen Brüdern ab. Von den 256 kB Level2-Cache des Williamette-Cores blieben 128 kB für den ersten Celeron auf Pentium-4-Basis übrig. Gleiches gilt für die bis vor kurzem noch aktuellen Celerons auf Northwood-Basis, nur das es dort 128 kB von ursprünglich 512 kB sind. Die neuen Celeron-D Modelle auf Prescott-Basis können immerhin 256 kB Level2-Cache vorweisen (wieder eine Viertelung des original 1 MB großen Level2-Caches beim Pentium 4 Prescott) und hängen ihre schwachen Vorgänger in nahezu allen Belangen ab.

Anders musste AMD die Sache für ihre LowCost-CPU handhaben. Den Athlon XP Thunderbird um die Hälfte seiner 256 KB großen Level2-Caches zu berauben, hätte den Duron als seinerzeitige LowCost-CPU von AMD nicht genügend verlangsamt. Aufgrund der großen Level1-Caches bei AMD wirkt sich ein kleinerer Level2-Cache doch deutlich geringer auf die Performance aus als bei den Intel-Prozessoren. AMD hatte also die Möglichkeit den Duron mit nur 64 kB Level2-Cache auszustatten und trotzdem noch hohe Performance zu erzielen. Dafür lohnt es sich dann sogar einen eigenen Kern zu fertigen – eine Ausnahme beim “Sport” des Cache-Deaktivierens für LowCost-CPUs.

Daneben findet man bei AMD beim Athlon XP Thorton, Sempron und Athlon 64 3000+ überall teilweise deaktivierte Level2-Caches vor. Allen “AMDlern” gemein ist die Abschaltung genau der Hälfte des Caches. Intel hingegen deaktiviert bei seinen Celerons generell sogar 3/4 des ursprünglichen Caches. Wie die nachstehenden Die-Fotos zeigen, sind die Caches von AMD dazu in zwei Bereiche aufgeteilt, die Pentium 4 Prozessoren besitzen dafür vier Bereiche, von denen wohl jeder einzeln deaktiviert werden kann.


Vergleich zwischen Northwood (links) und Opteron (rechts)

Bleibt die Frage, ob solche Caches wieder aktivierbar sind? Nicht wenige träumen davon, aus ihrem Celeron einen vollwertigen Pentium zu machen. Das wird allerdings auch ein Traum bleiben. Egal ob Caches nun per Laser physikalisch vom Rest getrennt werden, oder einfach bei der ersten Initialisierung übersprungen werden, für die spätere Reaktivierung ist es wohl meist zu spät. Allenfalls bei AMD mag das in einzelnen Fällen möglich sein. Dort scheinen Caches nicht physikalisch abgetrennt zu werden und können durch Änderungen an den sogenannten Brücken wieder vervollständigt werden. Es besteht natürlich keine Garantie, dass diese dann auch funktionieren.

Am Ende wollen wir natürlich nicht ausschließen, dass defekte Caches mitunter deaktiviert werden, um wirklich die CPU zu retten. Es kann durchaus passieren, dass weder die Redundanz greift, noch der Logikanteil beschädigt ist. Dies dürfte jedoch bei der Mehrheit der CPUs kaum der Grund für die Existenz von Prozessoren mit teilweise deaktivierten Level2-Caches sein.