AMD zum 32C3: Einblicke in die Komplexität eines x86-Prozessordesigns
Zum 32. CCC hat David Kaplan, der fünf Jahre AMDs Bobcat und die Jaguar-Kerne mit designt hat und seit 2011 Hardware Security Architect von AMD ist, Einblicke in die Komplexität eines modernen x86-Prozessordesigns gegeben. Auch nach vielen Jahren Zeit und Millionen Kosten wird eine CPU niemals fehlerfrei sein.
Nach rund fünf Jahren vom Konzept bis hin zur Massenproduktion, dem Großteil davon im Bereich der Entwicklung und dem Testen inklusive Fehlersuche und -behebung, ist ein Prozessor in der Regel marktreif und geht in die Serienproduktion. Dann muss das Gesamtkonstrukt funktionieren, kleine Fehler werden dabei aber immer vorkommen.
Kaplan begann seine Ausführungen zum 32. Chaos Communication Congress (32C3) mit dem Blick auf die Testmethoden für moderne Prozessoren. Denn genau die Testserien sind es, die die meiste Zeit in Anspruch nehmen und am teuersten sind. Deshalb vergehen von rund fünf Jahren gesamter Entwicklungszeit bis zu vier Jahre auf die Entwicklung und das Ausmerzen der Probleme. Dies wiederum ist in die Bereiche des direkten Testens für wichtige Bereiche sowie dem random testing aufgeteilt. Insbesondere das zufällige Testverfahren ist bei der Fehlersuche am wichtigsten, da es den Alltag für den Prozessor darstellt.
Bei der Grundsteinlegung eines Prozessors wird die Ausrichtung des Projekt festgelegt: Ein Hoch-Takt-Design oder ein Low-Power-Modell, dazu passend die Feature-Palette abgesteckt. Danach arbeiten unzählige Teams an den diversen dazu benötigten Baustellen eines Prozessors. Während sich das eine primär um einzelne Bereiche der CPU-Kerne kümmert, passen anderen beispielsweise die Caches, den Speichercontroller, die Northbridge oder unzählige weitere Dinge inklusive dem Power Management an. Dabei werden viele kleine einzelne Baugruppen immer separat getestet, da dies zeitlich deutlich zügiger vonstatten geht, als größere Segmente erst zusammenzufassen und dann zu testen. Erst wenn ein gewisser Punkt erreicht ist, werden die Bauteile nach und nach bis hin zum sogenannten System Level zusammengefügt, der dann dem angepeilten Produkt entspricht, und verifiziert. Da die meisten Test-Stationen viel zu langsam sind, helfen Emulations-Maschinen, die laut Kaplan schnell eine Millionen US-Dollar pro Exemplar kosten können – aber zeitlich extreme Einsparungen bieten können.
Die Simulationsphase und Testbenches werden so lange genutzt, bis die ersten Prozessoren in den Fabriken gefertigt werden und in die Labore zurückkommen. Diese Modelle werden dann ausführlich geprüft, nicht selten kommt es dabei vor, dass erste Rückläufer nur teilweise oder im schlimmsten Fall auch gar nicht lauffähig sind. Ein Rückschlag ist dies aber nicht zwangsweise, die nächste Testphase läuft an. Für die Fehlersuche können gewisse Segmente trotzdem noch zum Leben erweckt werden und der Fehler so gefunden werden. Je nachdem wie groß der vorhandene Fehler ist, muss im schlimmsten Fall ein kompletter Respin erfolgen, welcher zwei, drei Monate dauert und mehrere Millionen US-Dollar kostet. Ein etwas kleineres Problem kann eventuell mit einem Eingriff in die vielschichtigen Metall-Layer behoben werden – dies kostet weniger und benötigt auch weniger Zeit. Für riskante neue Features haben die Entwickler vorgesorgt: Falls diese nicht funktionieren, werden diese notfalls einfach via kleinem Disable-Register komplett deaktiviert.
Viele der genutzten Debug-Features oder Problembehebungen, die irgendwann einmal in der Design-Phase angewandt wurden, sind oft auch noch im fertigen Endprodukt zu finden, betont Kaplan. Denn echte Änderungen an der Hardware wären erneut ein zeitintensives und kostspieliges Verfahren, sodass der Fix oft zur Serie wird. Gewisse Debug-Features wie Microcode-Patches sind zudem extra berücksichtigt, dafür wird eine sehr kleine Menge an SRAM im Prozessor reserviert. Mit dieser Debug-Möglichkeit können auch sehr spät im Design-Prozess noch kleinere Fehler behoben werden.
Das finale Produkt auf dem Markt wird auch in Zukunft keinesfalls fehlerfrei sein. Bestimmte Konstellationen werden zuvor nicht bekannte Probleme hervorrufen, so wie in der Vergangenheit. Größere Fehler wie den Pentium-Bug bei Intel in den späten 90ern oder den TLB-Bug bei AMD Mitte der 2000er sind erst nach der Serienproduktion aufgetreten, auch Intels SATA-Bug bei den Sandy-Bridge-Chipsätzen aus dem Jahre 2011 zählt in diese Kategorie. Damals half ein Metal Spin, jedoch dauerte auch dieser rund zwei Monate. Kaplan ermahnt deshalb, dass die Entwickler Fehlern direkt im Design-Prozess Platz einräumen müssen, um sie dann beseitigen zu können oder diese so unwichtig sind, dass kein echter Fix nötig wird. Exakt das ist dieser Tage bereits die Regel, der Blick in die Fehlerlisten der Prozessorhersteller zeigt viele kleine Probleme, die jedoch nie eine Lösung auf Hardwareseite erfahren werden, dafür aber Workarounds enthalten, um die möglichen Probleme umgehen zu können.