 Herzlich willkommen bei der Übersetzung vom Vortrag When Hardware Must Just Work auf dem 32.Kost Communication Congress. Vielen Dank für meine Kollegen. Ich werde heute Abend über Handware-Design in der echten Welt reden. Normalerweise arbeite ich über die Sicherheit. Ich werde darüber reden, was benutzt wird, um eine echte X86 CPU zu herzustellen. Ich höre über ein paar Werkzeuge und Techniken, die dafür dabei benutzt werden. Und ein paar der einzigartigen Herausforderungen, die damit verbunden sind. Zu Anfang, ich weiß nicht, wer von euch von Hardware-Design gearbeitet hat, aber Hardware-Design ist ziemlich anders als Software. Zu einen braucht es eine sehr lange Zeit, insbesondere bei einer X86 CPU. Eine wirklich neue CPU entwickeln kann einfach vier bis fünf Jahre dauern. Und zwar mit Hunderten und wenn nicht Tausende von Leuten. Es ist sehr komplex, viele Bestandteile. Und es ist auch sehr teuer. Nur nicht nur die Kosten von Hunderttausenden oder Tausende von Leuten, sondern auch die Herstellung von Silikon-Trips ist sehr teuer. Und die Prozesse, die dafür für moderne X86 Chips benutzt werden. Also ein Maskset, die zur Herstellung von Silikon-Trips benutzt wird, Silicon-Trips benutzt werden, kann über drei Millionen Dollar kosten. Und das ist bevor man den ganzen Test-Equipment kauft und den ganzen Rest, der dafür benötigt wird. Und ein anderer Problem ist, dass es sehr kompliziert ist, alles zu testen, bevor man es herstellen lässt. Und dann kann es sehr teuer werden, herauszufinden, was schief gelaufen ist. Und ich werde dann über ein paar unterschiedliche Technologie zurückgehen, die dabei benutzt werden. X86 CPUs sind insbesondere problematisch, weil sie sehr komplex sind. Ein moderner Hochperformance-Chip kann sehr einfach 60 Millionen NAND Gates sein, equivalent. Und der RTL-Code, der normalerweise in der Sprache wie VeryLock ist, kann problemlos Millionen von Zahlen erreichen. X86-Course sind auch verdammt schnell. Es ist fast sehr schwer zu fortzustellen, was eine 3 GHz CPU ist. Eine 3 GHz CPU läuft bei drei Milliarden Sekunden pro Sekunde. Wir werden gleich sehen, welche Probleme das hat. Außerdem müssen diese Chips immer laufen. Die meisten werden nicht darüber nachdenken, ob eventuell in der Nacht die X86 CPU ein Problem hat. Aber wenn es einen Fehler drin hat, dann wäre es katastrophal. Ein CPU muss richtig funktionieren, damit alles überhaupt irgendetwas läuft. Und was das bedeutet von dem Hardware-Entwicklungsansicht? Man muss keine Bugs haben. Selbst wenn man einen sehr seltenen Bug hat und einmal in einer Milliarde passiert, dann passiert es immer noch dreimal in die Sekunde. Also, CPUs müssen perfekt sein. Also, natürlich nicht wirklich perfekt. Vielleicht können sich die CPU-Bugs, die in der Vergangenheit waren, zum Beispiel, Intel Pentium Divide Biobug oder den Pentium TLB Bug 2007. Es gibt noch eine große Anzahl weiterer kleiner Bugs. Wenn Sie den Rata-Guide einer modernen CPU anschauen, sehen Sie das. Wenn Sie das hinten sehen, steht der No Fix Plant auf der rechten Seite. Obwohl das stimmt, sind diese Issus in der Regel sehr klein. Ich glaube, ich hoffe, dass Sie sich mal so ein Rata-Guide herunterladen und schauen, was für Fehler dort eingetragen sind. In den meisten Fällen sind das, sind die mehr oder weniger egal, oder Software-Requerance sind normalerweise eingebaut, aber es sind immer noch viele, die im Silicone vorhanden sind. Zudition. Wir müssen ein wenig über das Hardware-Design-Prozess reden und wie das Testen von diesen Chips funktioniert. CPU-Entwicklungen beginnt beim Design und Verifikation. Das ist, wo die Gruppen den Verilog oder den VST-Code schreiben und den ausprobieren in der Simulation. Und das kann ein bis vier Jahre dauern, je nachdem, wie viel die geändert wurde in dem Design. Wenn das fertig ist, dann wird es zu der Herstellungsfacility geschickt. Es dauert mindestens zwei bis drei Monate, um irgendeinen Silicone zurückzubekommen. Und wenn man ihn zurückbekommt, dann muss man ihn immer noch testen und ihn validieren. Der Validierungsprozess kann immer noch ein Jahr dauern. Das ist, wenn man das sammeltet und wenn man das Ganze macht, dann braucht man vier bis fünf Jahre einen Konzept bis hin zu einer Massenproduktion. Zuerst möchte ich über die Verifikation vor Silicone-Design reden. Was ist Verifikation? Verifikation ist ein Disziplin innerhalb des Silicone-Designs, die berprüft, dass eine Design den Spezifikationen entspricht. Und wenn Hardware und insbesondere CPUs entwickelt wird, dann gibt es nicht nur eine funktionale Spezifikation, die sagt, welche Funktionen die CPU hat. Man hat aber auch eine Spezifikation für die Performance, die den Strom bedarf. Und die müssen genau gleich getest werden. Wenn der Prozess langsamer ist, als man erwartet, dann ist er genauso wertlos, als ob er irgendwo einen Back hätte. Und das Ziel der Verifikation ist es, einen Back zu finden, und je früher man den Back findet, desto einfacher ist es, ihn zu reparieren. Also, wie finden wir diese Bugs? Der Standardweg ist, zu simulieren, dort einen Test drüber laufen zu lassen. Dann hat es einen Hardware-Design, es ist ein Varylock-Code. Das ist der rote Block. Zuallererst hat man eine Möglichkeit, Eingaben zu machen. Und der normale Methode ist entweder dadurch, einen Directed-Test, oder einen Zufallstesting hat. Direktions-Test, da hat man eine Reihe von Anforderungen, die werden dann ausgeführt und Random-Testing. Ein zufälliges Testen, man öffnet einige der Anforderungen, macht einfach Zeug drauf. Das meiste, was gemacht wird, ist zufälliges Testen. Weil es sehr gut ist, um sehr komische Fälle zu finden. Und es ist deutlich einfacher, um Menschen freundlicher, als alle Sachen auszutesten. Außerdem wird irgendeine Art von Überprüfung gemacht. Zum Beispiel, wenn man ein X86-Core hat, dann hat man in der Regel ein C++-Modell der Architektur, das parallel dazu läuft. Und man schickt dieselben Anforderungen zu beiden, Anweisungen zu beiden. Wenn beide fertig sind, dann schaut man sich den Memory an und schaut, ob da irgendwo ein Unterschied ist. Checkers werden auf niedrigeren Strukturen angewendet. Zum Beispiel, dass man diese Überprüfer über bestimmte Blöcke hat und häufig werden diese Blöcke genau angeschaut, auch interne. Zum Beispiel ein Cache-Überprüfer, der überprüft, dass man nicht doppelte Zahlen im Cache hat. Und diese Sachen sind sehr hilfreich, weil die Verifikationszeit sehr gering ist und man alle Unterschiede so früh wie möglich finden möchte, dass man sich möglichst viel in der Testzeitungszyklus hat. Darum hat man die Überprüfung sehr früh. Eine weitere der Testarbeiten in der Regel gibt es eine Möglichkeit, den Bereich der Überprüftür zu schauen. Und das zeigt, wie gut man testet. Also, wenn man 90, wenn man den allen Code, den man versucht, den man hat, und man möchte auf keinen Fall einen Code, eine CPU herstellen, die irgendeinen Code drin hat, den man noch nicht getestet wurde. So, Testspanches sind nicht schnell. Und das ist ein ziemlich großes Problem. Wenn man einen ganzen SCC-Chip haben, so mehrere CPUs, Nordbrücke, Südbrücke, dann hat man ungefähr eine Geschwindigkeit von einem Herz. Das heißt, man hat ein Zyklus für jede Sekunde der Uhr an der Wand. Man kann da nicht viel machen. Und das ist mit einem sehr neuen Tool, ein sehr guter Hardware. Und was man normalerweise macht, ist es, in kleinere Blöcke zurückzugehen. Wenn man nur einen X86-Core hat, dann ist das ungefähr zehnmal so schnell. Und das ist immer noch sehr langsam, aber mehrfach schneller. Wenn man es weiter zusammenbringt, auseinander nimmt, dann kann man einen Multi-Unit-Testing machen. Man macht mehrere ähnliche Blöcke zusammen. Und man kann sogar zum Testen von einzelnen Units, z.B. nur den Decoder oder ein einzelnes Speicherunit, und dann kann man um die 100 Hertz, vielleicht 200 Zeugeln pro Sekunde durchführen. Wenn man das jetzt kurz mit einem wirklichen Zidikon verteilt, vielleicht die 3 Milliarden Zeugeln pro Sekunde hat, dann ist es verdammt langsam. In der ersten Sekunde, die eine CPU läuft, das sind ungefähr 9,5 Testjahre im rosten Level. Und sobald man es anmacht, dann hat es schon mehr verifiziert, als es je gemacht hat. Es gibt ein Methode, wie man das Ganze schneller macht, dadurch, dass man mehr Geld dran wirft, mit Monationen. Und eine CPU macht eine Maschine, eine spezielle Hardware, die FPGA-endig ist. Denen kann man ein Design daraufladen, und man kann schneller testen. Und das ist deutlich größer, als das Bild aussieht. Und eine dieser Boxen kostet ungefähr eine Million Dollar. Aber die können 1 bis 2 laufen. Es ist immer noch eine Million mal schneller als eine Simulation. Aber deutlich langsamer als das Edition. Es sind sehr hilfreich, aber die kosten sehr viel. Eine Frage, die ich oft gestellt bekommen, ist, wie sieht es mit formaler Verifikation aus? Und wenn jemand das noch nicht kennt, was es ist, im Grunde genommen, ist es ein mathematischer Beweis des Verhaltens des Designs. Und formale Verifikation ist großartig für manche Dinge. Es ist wirklich super, wenn man einen kompletten 100% Beweis bekommen kann. Dafür, dass Dinge wirklich funktionieren. Das Problem mit formalen Werkzeugen ist, sie werden wirklich schlecht, weil man ein großes Design hat. Es sind im Wesentlichen etwas, wo du vergleichen musst, gegen ein Vergleichsobjekt. Und wenn man zum Beispiel ein Multiplizierer hat, ist es ziemlich einfach, die Multiplikation zu simulieren und zu sagen, die ganze CPU ist es aber eine ganz andere Sache. Vielleicht muss man das ganze Design noch mal implementieren, damit man überhaupt was hat, gegen das man vergleichen kann. Und meine Erfahrung nach ist, Formal Verifikation für ganz vereinzelte Ausführungseinheiten geeignet, aber sonst auch nicht. Eine Sache, über die ich sprechen möchte ist, wo schlägt Verifikationen Fehl? Wir fangen erst mal damit an, wo es gut funktioniert. Es funktioniert gut, wenn man Fehler in den Grundfunktionen hat. Funktioniert dieser Modus überhaupt, werden diese Ausnahmen überhaupt generiert und derartige Dinge. Alles, was man formal beweisen kann, ist außer dem gut zu testen. Und auch die Abdeckungsanalyse funktioniert gut. Zum Beispiel kann ich eigentlich alle Anweisungen und Modi ausführen, werden alle Ausnahmen ausgelöst. Aber es gibt andere Sachen, die schwer zu finden sind, zum Beispiel Fehler auf dem Systemlevel. Wenn ihr euch erinnert, die Sache, die wir dort simulieren wollen, läuft einfach so unglaublich schnell, dass wir nicht viel Testzeit haben und da stehen dann Dinge, die uns einfach mal durchs Netz rutschen. Und wenn man zum Beispiel ein Protokoll-Mismatch hat, wo Dinge in einem falschen Status landen, kann man das schlecht finden. Was ich am häufigsten bisher gesehen habe, ist, dass mehrere scheinbar zufällige Ereignisse gleichzeitig eintreffen müssen, um einen bestimmten Back hervorzurufen. Also zum Beispiel eine Cash-Up-Frage macht und dann kommt ein Interab rein und in einem gleichen Zyklus sagt der Temperatursensor, dass die CPU zu heiß wird. Und solche Dinge findet man, wenn man mit einigen Milliarden Instruktionen pro Sekunde das prüft, passiert das natürlich öfter als in der langsamen Simulation. Eine andere Sache, die schwer zu finden ist, sind Dinge, die nur nach langer Laufzeit hier auf großen Datenstrukturen zum Beispiel. Die kann man schlecht testen, diese Fälle in Verifikationsmethoden. Man muss sich das bewusst sein. Und eine weitere Sache, die ich gesehen habe, sind statistisch unwahrscheinliche Dinge. Stellen wir uns zum Beispiel vor, man hat ein Design mit einem besonderen Verhalten, wenn ich zum Beispiel zwei verschiedene Speicheroperationen habe und die untersten 20-Bits der beiden Operationen sind beide mal die gleichen und die anderen wird es nicht. Und wenn man zufällige Eingabendaten macht, dann wird genau diese Übereinstimmung eben so gut wie nie passieren. Und man bräuchte unglaublich viel Testzeit, um das Ganze zu auszulösen. Manches davon könnte man natürlich beheben, wenn man schon wüsste, dass genau dieser Corner Case, diese Spezialsache besonders sensitiv ist. Und dann könnte man natürlich den Zufallsgenerator so modifizieren, dass eben nicht zufällig ist, sondern genau solche Sonderfälle generiert. Aber man versucht es so gut, wie es geht, aber man kann nicht alle diese zufälligen Konfigurationen überblicken. Das nächste, was ich erklären möchte, ist, was passiert denn, wenn wir unser Silizium schon gefertigt haben? Und ihr könnt euch sicherlich vorstellen, man bekommt das Ganze aus der Fertigungsanlage zurück und es funktioniert halt nicht beim ersten Mal. Man muss debaggen, aber wie debaggt man das? Die meisten hier werden sicherlich schon mal was debaggt haben. Das sieht dann ungefähr so aus. Wenn wir über Software reden würden, dann würde man das Problem untersuchen, GDP starten, gucken, was dort falsch ist, schnell beheben, neu kompilen und das Ganze von vorne. Mit Hardware geht es so nicht ganz. Die erste Sache, die man betrachten muss, was ist denn passiert? Ein häufiger Weg, um das herauszufinden, ist das JTAG Interface. JTAG steht für Joint Test Action Group. Es ist ein Standard der IEE. Und viele Hardware unterstützt diesen Standard. Und aktuelle X680 Prozessoren haben halt spezifische Pins dafür, die man dort rechts sieht. Und wir können Testdaten rein und raus. Wir haben einen Test-Klock-Signal. Und diese Spezifikationen gibt es vor, wie ich mit diesen Pins arbeiten kann. Es muss erwähnt werden, diese Pins sind physikalisch vorhanden. Die sind normalerweise auf dem Wasserboard nicht physikalisch ausgeführt, mit Anschlüssen, die man finden kann. Aber in dem Clip sind sie tatsächlich physisch vorhanden. Prozessoren müssen manche von diesen Kommandos, wie zum Beispiel Bypass und ID-Code, implementieren. Die sind die Mindestkommandos, die vorgeschrieben sind. Und die IEE hat das Ganze aber recht offen gehalten. So, dass wir auch noch weitere proprietäre Anweisungen hinzufügen können. Und man kann sich vorstellen, wenn ich eine CPU debugge, dann habe ich halt spezifische Debugganweisungen, um bestimmte Speicheradressen zu lesen oder zu schreiben und derartige Dinge. Und das kann natürlich sehr nützlich sein, um rauszufinden, was passiert ist. Aber der Prozessor macht das natürlich nicht einfach so auf magische Weise, sondern auch dieses Debugging-Interface muss natürlich mit ins Design eingearbeitet werden. Und das lohnt sich, weil man hat auf jeden Fall irgendwelche Bugs. Das Ganze kann sehr nützlich sein, ähnlich wie in der Softwarewelt an GDP, aber es funktioniert auch nicht immer. Insbesondere ist es eine Sache, die häufig passiert bei Silicium-Designs, dass der, die CPU einfach sich aufhängt, komplett still steht und man kann eigentlich nichts mehr machen. Wie soll man das noch debaggen? Die Antwort sieht so aus, hat eine Scan-Funktion funktioniert ähnlich wie in Crash-Dump. Alle Register, also alle Register, die als Flip-Flop ausgeführt sind, können wir über einen einzelnen J-Tag-Port nacheinander ausgeben. Und das funktioniert, indem die Flip-Flops im Silicium ungefähr so angeordnet sind, wie uns hier sieht. Das ist also ein Strangat Flip-Flop. Und jetzt haben wir einen Extra-Mux-Anschluss, mit dem ich entweder die normalen Daten reinholen kann oder die Scan-In-Daten. Und dann kann ich mehrere solche Einheiten hintereinander verketten, so wie hier. Und dann können die Daten des einen Flip-Flops in das Scan-In des Nächsten gehen. Und wenn ich diese Daten dann ausgeben möchte, dann schalte ich auf all diesen Flops das Scan-Able ein, das Scan-Able-Fleck. Und es ist dann so designed, dass die nacheinander durchrutschen, so dass ich über eine längere Zeit, die wirklich eine Weile dauern kann, über mehrere Zykler hinweg, die ganzen Register eins nach dem anderen auslesen kann. Das ist eigentlich ganz nett. Und das kann ich dann später offline analysieren. Aber es ist nicht perfekt. Eine Einschränkung, ich bekomme nur die Daten aus den Flops, irgendwelchen anderen Zwischensignalen. Und es ist auch nur ein einziger Zeitpunkt, den ich dort auslesen kann. Es ist wirklich nur ein Quest-Stump. Und die Information, die ich eigentlich brauche, könnte schon längst wieder weg sein. Und bei der Geschwindigkeit mit der CPUs für gewöhnlich laufen, wenn er nicht sofort in dem Moment, wo der Fehlerzustand da ist, abstürzt, habe ich keine Möglichkeit, da noch mal heranzukommen in den Zustand. Manchmal muss man sich alle verschiedenen Fehlerstaatszustände, die davor waren, nach und nach angucken. Und das ist dann komplizierter. Das sind Beispiele von Verfahren, die öfters genutzt werden. Okay. Dann gehen wir mal davon aus, wir haben irgendwelche Methoden davon verwendet und wissen, was passiert ist, was schief gelaufen ist. Und auch die eigentliche Fehlerbehebung ist nicht wirklich einfach. Natürlich kann ich meinen Verilock-Coach fixen und das Design nochmal neu machen. Da war 2 Monate, 3 Millionen Dollar. Aber das muss ich nicht immer so machen. So wie moderne Chips aufgebaut sind, gibt es einen Base-Layer und Metall-Layer. Und wir haben da bis zu 9 verschiedene Metall-Layer über den Base-Layer und um das ganze stark zu vereinfachen, weil ich bin kein richtiger Prozessor-Designer. Man hat dort verschiedene Gatter-End und Noir und so. Und die sind alle auf dem Base-Layer und die Metall-Layer darüber verbinden diese Gatter. Und wenn mich irgendwas verändern muss und den Base-Layer neu machen muss, ist das sehr, sehr teuer und sehr kostspielig, was Zeit angeht. Aber eventuell kann ich auch stattdessen einfach nur einen der Metall-Layer verändern. Und das ist deutlich günstiger, sowohl was Zeit als auch was Geld angeht. Und an den neuen Metall-Layer kann ich einfach dazwischen schieben und das kostet mich nur einige Wochen an Verzögerung. Eine Sache, die auch häufig gemacht wird bei physikalischen Designs ist, man hat einen Block und wenn man irgendwo noch Platz hat, dann packt man da einfach noch ein paar weitere Gatter hin, die nichts Spezifisches tun, die sind einfach nur dort als Reserve. Und wenn ich dann irgendwie einen Back habe, dann kann ich immer noch mit den Metall-Layern versuchen, dort eine Verbindung hinzumachen, um etwas auszutauschen. Und warum sollte man das auch nicht tun, wenn man dann noch nützliche Dinge unterbringen kann? So, das sind die sehr kostspieligen Lösungen. Die einzigen Möglichkeiten, wie man wirklich etwas schwierige Fehler beheben kann. Aber es gibt auch ein paar andere Lösungen, die kosten nicht unbedingt 3 Millionen Dollar. Eine Sache, die man machen kann, wenn da ein Problem ist, kann ich ins Labor gehen. Und ich nehme eine von diesen Katzen und guckt, ob sie das beheben kann. Wir haben natürlich auch bessere Lösungen, zum Beispiel diese Maschine. Man kann einen schon fabrizierten Chip dort hinein tun und mit einem elektronen Mikroskop kann ich Jonen dort hineinschicken an manchen Stellen, um kleinere Stellen des Designs nachträglich zu verändern. Das macht man pro Chip. Und das einzige Problem damit ist, man muss es für jeden einzelnen Chip machen. Und außerdem, die Chips, mit denen ich das mache, halten meist nur noch ein bis zwei Wochen, weil das Ganze so fragil ist. Und wenn ich nur mal kurz den Fix-Proto als Prototyp machen muss, kann ich das in ein paar Stunden machen und ausprobieren und gucken, ob der Fix wirklich funktioniert. Aber für die eigentliche Produktion ist es absolut ungeeignet. Also, was kann man noch machen? Eine weitere häufige Verfahrensweise ist, dass man Disabled Bits in der Hardware hat und die heißen Klickenbits, also Hühnchenbits. Und die sind sehr nützlich, um zum Beispiel Performance oder Energieverbrauch irgendwie zu optimieren. Und wenn das nicht funktioniert, dann kann man es halt deaktivieren. Es ist auch sehr wichtig, ich meine, wenn Prozessoren hergestellt werden, dann sind manche Dinge, die einfach sehr schneller machen, zum Beispiel Branch Prediction, das ist sehr gut. Aber wie der X80 Chip diese neue Performance hat, die man jede Generation bekommt, das ist normalerweise dadurch, dass man einen sehr kleinen Enderungen macht. Die, welche die 0,54 haben und 0,25 % da und vielleicht ein großes Feature, das um 1 % schneller macht. Die werden alle adäert und kriegen seine 10, 15 %, die man besser wird. Und wenn man eine von denen ausschaltet, um einen kritischen Berg auszuschalten, ist es kein Problem. Und da sind viele Fälle, wo das benutzt wurde. Man kann in viele dieser Sachen, in einem Dokument, das AMD veröffentlicht, nämlich das Biosc Developer Pub geeint. Und vielleicht haben Sie das schon voran das gesehen. Bei X86 werden diese Bits in spezifischen Register gesetzt und das ist ein Beispiel dafür, ein Data Cache Configuration Register. Und das sind einige Sachen, die definiert sind. Man hat bestimmte Aspekte zu disabeln, die für die Geschwindigkeit erhöhen und ein paar andere Features. Und die sind nicht nur für Herstellungen hilfreich, wenn man z.B. ein Bug mit dem Hardware Prefecture vorholt hat, aber sind auch sehr hilfreich beim Debugging. Und das führt also, dass Designer über mögliche Fehler nachdenken müssen, welche man eventuell später ausschalten möchte. Und das ist eine der Sachen, wo man alles Mögliche damit macht, wenn man viel lieber ein Bitney setzt, als wenn man ein Bug hat, der die 3 Millionen Euro kostet, um es neu zu machen. Eine weitere Option über den modernen CPUs sind Microcode Patches. Microcode ist quasi der Firma, die auf dem Chip läuft. Es sind Prozessoren, die normalerweise komplexe Anweisungen im X86 durchzuführen. Es sind einige, z.B. Interrupt Delivery und viele Stromversorgungsprobleme. Und Microcode nimmt diese komplexen Sachen, nimmt die auseinander und macht viele kleine Schritte in der CPU. Und wie das funktioniert, ist, man hat einen On-Chip-Rom, der im Silizium vorhanden ist. Und wenn man einen kleinen S-Ram nächt, dann ist das der Patch-Ram. Und im Patch-Ram kann man verschiedene oder alle von den Microcode-Befälen überschreiben, wenn sie repariert werden müssten oder wenn man irgendwelche Bugs umgehen möchte. Und das ist sehr hilfreich, wenn man Instructionen ändern möchte. Wenn man z.B. eine Silization machen kann, dann kann man das eventuell im Microcode machen. Wenn es einen sehr seltsamen Fall hat, nur ein Bug im Mac drin ist, dann kann man das häufig rauspatschen. Da ist nicht viel für Öffentlichkeit dafür, die beste Quelle, die man dafür finden kann, im Linux-Körner. Dort ist ein einige für Internet- und AMD-Prozessoren. Eine Sache, die ich reparieren möchte, ist, dass Microcode-Patches in der Regel von dem Hersteller signiert. Und das ist nichts, was man häufig ändern kann. Die sind sehr hilfreich, um auch für andere Ideen zu ändern, als X86 im Feld ein paar Sachen zu ändern. So, um das noch etwas zusammenzumachen, wir haben JTag Debugging und Scan, so zwei Arten, wie man Fehler identifizieren kann. Und wenn man die wirklich repariert, dann gibt es Workaround. In der Regel muss man es einfach rauskriegen. Man macht, was auch immer funktioniert. Und die Union hier zwischen Fix und Workaround ist sehr unklar. Man hat Silizion, Respin, man hat Microcode-Patch, und man kann auch immer noch zu Noten neu machen müssen. Weil die meisten hier Sicherheitsleute sind, möchte ich kurz über die Sicherheit davon reden. Alle, die Debug-Interfaces über die ich geredet habe, das sind potenziell mehr als Debug-Interfaces für alle. Und das ist etwas, das nicht ignoriert werden kann. Die Barrierinterface-Sicherheit muss als Design relevant sein und muss ausgetestet werden. Einige der Beispiele für Sicherheit, die ich gesehen habe, waren zum Beispiel, manche oder alle JTag-Commands werden ausgeschaltet. Normalerweise wird dies dabei gemacht, dass Fuses, also kleine Stellen, die dann einfach durchgebrannt werden. Wenn die durchgebrannt ist, dann sind diese Funktionen nicht mehr benutzbar. Eine andere Möglichkeit ist zu überprüfen, dass die Debug-Zugang zu geheimen Regionen in Produktion abgebrochen wird oder durchbrochen wird. Man kann ein bisschen Authentikation machen, um ein Debug-Interface wirklich zu benutzen. Aber das muss man testen und den Deburger zu testen, ist sehr kompliziert. Und ja, das ist eine Möglichkeit, die man benutzen könnte und die Sicherheit hochzusetzen könnte. Und signierte CPU-Microcode-Updates sind normal heutzutage. So ein paar Sachen, die ich Ihnen doch sagen möchte. Der X86 CPU ist mittlerweile nicht das, was Sie jetzt anfangen wollen. Aber viele der Techniken sind hoffentlich immer noch interessant und können eventuell in anderen Projekten angewendet werden. Zuerst große Designs und kleine Gruppen auszubrechen. Sieht sehr üblich aus. Aber manchmal ist es sehr hilfreich, insbesondere wenn man etwas hat, was wie eine CPU sehr langsam simulierbar ist. Die Tools zu benutzen, um die Testzeit zu reduzieren, formale Werkzeuge, automatisierte Werkzeuge, ist sehr hilfreich. Einfach um die Benutzbarkeit von jedem CPU-Zyklus, den man laufen lässt, maximieren. Man muss auch immer überprüfen, wer sind die schwachen Punkte in dem Testzyklus und man muss schauen, wie man die umgeht. Zum Beispiel weiß man bei CPU-Architektoren, nach einigen Jahren wissen sie, wo die Bugs sind und sie bauen dementsprechend, dass die Bugs drinnen sind. Eine Bauung eines Tipps, eine Funktion, die so gut ist, dass man die ganzen Sachen anschauen kann. Wenn man ein Debugfeatures hat, dass man auch wieder ausschalten kann, ist auch unter Umständen sehr hilfreich. Mit Hardware muss man, hat man, aber das ist nie wirklich die Option, dass man den Benutzern sagen kann, hey, lade einen Patch runter. Und wirklich in Hardware-Pack kann man nur dadurch reparieren, dass man das Edition zu Millionen und Millionen von Leuten schicken kann. Und das möchte niemand machen. Darum möchte man diese anderen Features dabei haben, dass Fehler, die einfach mal auftauchen, umgehen kann. Bei Software kann man manchmal wirklich einen Patch rausschicken. Aber in vielen Situationen, wo man einfach nur ein Software upgrade hat, die Benutzer sagt, hey, lade das runter, ist manchmal nicht wirklich das Benutzbare möglich. Und häufig versucht man, eine Möglichkeit zu haben, einen Update durchzuführen. Und das ist, was ich hier habe. Ich habe noch ein paar zusätzliche Links, wenn Sie interessiert sind, wenn Sie mehr darüber lesen wollen. Die BIOS Current Developer Guide ist eine große Quelle von Informationen. Das sind ein paar Tausend Seiten, aber sehr interessant, das zu lesen. Es geht zuallererst über jeden Register, der existiert im X86er CPU und was die Bits machen. Die CPU Revision Guides, die Erata Dokumente von Intel oder HMD, ist sehr groß. Man braucht einfach den für die eigene CPU Version. Und es ist sehr interessant, die sich anzuschauen. Nicht nur, was die Fehler sind, sondern auch die Revisionen. Schaut, welche Fehler immer noch wichtig sind, nicht wichtig sind, und nie gefixt werden. Wenn ein Interesse besteht bei der CPU-Verifikation, dann gibt es eine große Anzahl von guten Quellen. Und da kann man viele Informationen finden. Ein sehr interessantes Feld. Es ist viel Arbeit, die dort gemacht wird und Verifikationen zu optimisieren und mehr Beweise durchführen, mehrere Fälle, zum Beispiel Power Aware-Verifikationen. Es wird mehr und mehr wichtiger. Und einige Chips kann man teilweise ausschalten und man kann sie nicht benutzen. Wenn man sie vorher anschaltet, das ist eine sehr interessante Arbeit, die in diesem Bereich getan wird. Wenn Sie den Bereich interessiert sind, schauen Sie die Idee einfach an. Jetzt können wir ein paar Fragen stellen. Ich mache die... Eins, zwei, okay. Vielen Dank, David. Könnte ich bitte hinzufügen? Nein, könnt ihr bitte bei eins und drei euch hinstellen? Irgendwas funktioniert da nicht. Also, zuallererst die erste Frage bei den Nummer drei. Danke. Vielen Dank für den großartigen Vortrag. Ich weiß nicht, ob Sie irgendetwas darüber wissen oder ob das außerhalb von dem ist, was Sie wissen. Ich frage mich, wie wird dieses Layout da drin benutzt werden? Wenn man FPGA benutzt, dann schmeißt sich mein Design drauf und es wird automatisch layoutet. Und alles passiert einfach. Aber werden CPUs manuell ausgelegt werden? Also, ein bisschen von all dem. Es war früher mal so, dass man alles manuell layoutet hat, weil die damaligen Tools nicht gut genug waren, um so große Designs zu machen. Aber in den letzten fünf bis zehn Jahren gab es eine große Entwicklung Richtung automatisierter Layout und Synthese. Und das ist wirklich gut geworden. Und was heutzutage ist, das Beste passiert, wenn man einfach die ganze CPU nimmt und sagt, sucht einfach aus, wo es hin soll. Und in manchen Fällen sagt man gar nicht, hier möchte ich diese Instruction Sachen, sondern das Tool kann aufgrund der Verbindungen gucken, wie das Welten ist, der einzelnen Elemente ist. Und es ist heutzutage im Wesentlichen automatisiert mit relativ wenig menschlichem Input. Und es ist anders als bei FPGAs. Die Tools sind allerdings recht ähnlich an manchen Stellen. Die Person in Nummer eins. Was passiert denn bei AMD-Updates? Wenn man zum Beispiel irgendeine Micro-CPU drin hat, zum Beispiel, wenn man eine Next-86-Code für Generalsprozessungen hat. Da gibt es euch mal Sicherheit. Und macht man das ganze Test oder einfach nur einzelne Teile davon? Ja, also typischerweise funktioniert es so. Der ganze Chip besteht aus einer Sammlung von sogenannten IPs. Und der Power Management Controller ist ein IP. Der PSP, der Security Prozessor ist ein IP. Und man hat noch eine ganze Menge andere IPs, wie Speicherkontroller und so. Die werden meistens einzeln verifiziert, aber es gibt auch noch mal eine Systemlevelverifikation, wo alle zusammengetestet werden. Und aufgrund der Geschwindigkeit und Größe ist das Ganze eingeschränkt, aber es gibt es prinzipiell. Wir müssen auch noch ein paar Leute außerhalb ansprechen. Haben wir eine Frage auf das Internet? Ja. Wer könnte man diese ChickenBits setzen? Haben wir die im Betriebssystem setzen? Also, die ChickenBits sind in modellspezifischen Regestern. Und man muss wissen, wo sie sitzt und kann sie da einfach mit einer Instruktion setzen. Ja, ich bin sehr gut über den Vortrag. Und ich bin überhaupt nicht ein Hard-Track-Typ. Als Sicherheitstyp sehe ich diesen Prozess, der arbeitet mit ungewünschten Bugs draußen. Wie gut arbeitet der gegen eine Person, die wirklich schwerfindbarer, absichtliche Bugs einbauen möchte? Oder wie würden die sonst solche Sachen erkennen? Also, ich denke, das ist ein Problembereich, über den ich eigentlich so viel sagen kann. Der Lechter aus dem Publikum. Ich überlege gerade, ob es überhaupt etwas gibt, was ich darüber sagen kann. Also, es gibt eine ganze Reihe von Phasen im Designprozess. Und um für mich zu sprechen, es wäre äußerst schwierig für jemand anderen, etwas durch die ganzen Prüfungen durchzubekommen. Aber darüber hinaus gesehen, viel kann ich dazu gar nicht sagen. Wozu ich tatsächlich was sagen kann, da ist ein ganzer Bereich in der Fabrikation, sagen wir mal, deine Firma benutzt ein perfektes Design. Dann ist es vielleicht nicht das, was das Fabrikationslab dir zurückschickt. Das kann also auch auf dem Unternehmenslevel schwierig sein. Wenn man also das Silizium zurückkriegt, dann testet man, ob alles das, was man haben wollte, auch da ist. Aber es ist schwer zu testen, ob noch mehr Features da sind, als man eigentlich haben wollte. California. So, wir wissen alle die Pixel Failure-Klasse zu unseren Monitor, die wir kennen. Sind da Failure-Klassen von CPUs? Und kann man einen guten Test kaufen? Nein, es gibt keine Failure-Klassen oder was Vergleichbares für CPUs. Die CPUs sind funktional gesehen alle identisch. Und es kann Unterschiede geben, zum Beispiel je nach BIOS-Version, welche Fixes da drin sind, welcher Mikrokod geladen wird. Unglücklicherweise, selbst wenn es einen Fehler gibt und es wird zum Beispiel ein Mikrokod-Update veröffentlicht, wir können die Hersteller nicht zwingen, das in ihr BIOS einzubauen. Also da gibt es also ein Problem. Und das Einzige, was ich da erwähnen kann, ist, dass man einzelne Teile testet. Und wenn wir das machen, es gibt keine verschiedenen Geschwindigkeits-Klassen. Also, dass man manche Teile kommen einfach schneller oder langsamer aus der Fabrik oder mit mehr oder weniger Stromverbrauch. Aber das Ganze ist einfach eher zufällig. Da musst du einfach Glück haben, dass das Teil des Tukhaus schnell und Stromspann laufen kann. Wir haben noch eine Frage aus dem Internet. Ja. In der Verifikations-Fahl, wie unterscheiden Sie Designs-Federn und von Herstellungs-Federn? Also, in der Verifikationsphase ist das Design noch nicht durch die Fabrikation durch. Das heißt, man testet im Wesentlichen nur den Verilock-Code und es gibt Mechanismen, um das zu testen, was aus der Fabrikation zurückkommt, um zu gucken, ob das Teil korrekt gebaut wurde. Und manchmal ist das recht einfach, zum Beispiel, dass man den gleichen Bug auf verschiedenen Teilen versucht zu reproduzieren. Und es gibt ein paar andere Features, die wir eingebaut haben, die wir als Design-First-Test-Kategorie zusammenfassen würden. Aber das wäre ein komplett anderer Talk. Ich würde Ihnen wissen, wie viele dieser Design-Zyklen hat ein X86, ein 80er-CPU normalerweise, bevor es fertig ist. Also, das hängt sehr stark davon ab, wie viele neue Features man in der neuen Generation hinzufügt. Es kann manchmal nur eine oder zwei solche Interaktionen sein. Manchmal sind es auch so ungefähr fünf bis zehn. Eine Möglichkeit, um das herauszufinden, ist, wenn man von A0, A1, B1 hört oder so, der erste Buchstabe ist die Base-Layer-Version und die Nummer dahinter ist die Revision der Metall-Layer. Gentleman. Nummer one, please. Entschuldigung zu fragen. Aber ich bin auch ein Sicherheits-Senschafts-Crap. Wenn Sie es dramatisch wie ein Prozessor verantworten, dann hat die Legacy anderen Zeichen drin. Wie? What? Are you calling the Design-Crap? Nein, ich sage nicht, dass das Design-Crap ist. Wie würde man das Testen dadurch ändern? Also, es gibt einige Legacy-Funktionen in X86. Eine interessante Sache ist, es würde nicht unbedingt einfacher werden. Denn wenn man etwas herausnimmt, muss man es überall rausnehmen, auch aus den Testgeneratoren und aus den spezifischen Tests und Generatoren. Und glaube es oder nicht, aber es ist manchmal mehr Arbeit, als das Feature einfach drin zu lassen und es einfach nochmal zu testen. Das mag Anti, also schwer zu verstehen sein. Aber wirklich etwas rauszunehmen an Features ist auch schwierig, weil es gibt einfach eine ganze Menge Software, die darauf noch basiert. Wir haben endlich 3D Now und A20 haben wir jetzt rausgebrochen, dass seit dem 2.86er oder so da drin ist, aber naja. Ich habe zwei Fragen. Die erste ist, den man sagt, dass ein bisschen RAM drin ist, den man RAM-Sendlinie programmieren kann, um diese Microproz scramming zu enden, nachdem eine Prozesse hergestellt ist. Warum wird der im Silikon reingeprannt, wenn es dann ein bisschen ROM ist, der ausreichend groß ist, um alles draufzuhalten? Also dieser RAM ist nicht in jedem Fall groß genug, um alle Instruktionen zu enthalten. Ich würde sagen, der Hauptgrund dafür, weshalb man überhaupt das Fest einbaut ist, naja. Erstens, der ROM ist im Silikon deutlich kleiner vom Footprint her. Und man will nicht so einen großen RAM dort aufbringen, man spart einfach Fläche durch den ROM. Und es ist auch aus Sicherheitsaspekten, man muss dem Prozess, der das Ganze herein lädt, nicht so sehr vertrauen. Wenn man gar keinen ROM hätte, müsste man den loadingprozess selbst wiederum komplett, voll funktional in Hardware einbauen. Und es gibt halt Gründe dafür, unter anderem auch legacy Gründer. Die zweite Frage ist, in welchem Designzyklus muss man entscheiden, welche Clockrate der Prozessor veröffentlicht werden soll? Normalerweise laufen soll. Also für gewöhnlich ist das sogar schon Teil der ursprünglichen Designspezifikation. Wenn man ein Design erstellt, dann möchte man einfach eine Zielgeschwindigkeit, eine Zielperformance haben. Und basierend auf der Prozesstechnologie, die eingesetzt wird, wo man weiß, man kann so und so viele Gata pro Zyklus haben oder ähnliches. Wenn man das Ganze natürlich tatsächlich herstellt und testet, dann kann es natürlich sein, dass etwas anderes bei rauskommt. Je nachdem, wie ideal die Annahmen und Daten sind. Aber es ist normalerweise Teil der Spezifikation. Der ist auch noch frei aus dem Internet? Ja. Typischerweise ist es so implementiert, dass man einen Publiki, einen öffentlichen Schlüssel in den Raum eingebrannt hat für die Signatur, aber ich kann nicht zu sehr ins Detail dort gehen. Das ist gut. Von dem Vortrag sieht man, dass das Test in ein großer Bereich von dem Prozess ist. Wenn zu CPUs komplexer werden, Virus wird der Testproblem gehen, dass die neuen Features längst später kommen. Es ist ein ganz wesentlicher Faktor. Der Testing ist das größte bei der CPU, was die Zeit, die Kosten, aber auch die Anzahl der beteiligten Personen betrifft. Ich meine, solche Dinge werden langsamer, wenn man mehr Menschen hinzufügt. Andererseits gibt es manchmal neue Tools oder Verfahren, die das wieder ausgleichen. Wenn man sich das anguckt und sagt, warum dauert das so lange, bis die CPU-Features drin sind, gerade wenn es auch um Security-Features geht, das ist einer der Gründe. Das Testen ist ein langer Prozess und jedes neue Feature, das man hinzufügt, erweitert die Zeit, bis man das verkaufen kann und erst dann verdient man auch Geld damit. Wenn Sie keine Follow-up-Question haben, und Sie testen Methoden, die man sehen kann, besser als simulieren, ich kann es nicht so genau sagen, aber ich bin auch nicht so ein Expert dafür, was dort in der Zukunft kommen wird, aber ich denke, da werden noch nützliche Dinge kommen. Wenn Sie vielleicht sagen, wie viel Platz braucht man bei einem Silicon-Chip und einem J-Tag-Device, die Chicken-Bits und den ganzen Zeug implementieren, ist das ein Prozent oder viel, viel weniger? Also die Chicken-Bits sind sehr geringfügig, das sind nur ein Register und eine Verbindung, die irgendwie ausgeschaltet wird. Diese J-Tag-Dinge kann ich schlecht quantifizieren. Es ist nicht sehr groß, würde ich sagen, verglichen mit all den anderen Dingen in der CDU. Wenn man sich so eine Di-Photografie anguckt, ist alles klein, was nicht der Cash ist. Und viel von der J-Tag-Logik wird nicht als optional angesehen, weil einfach die Spezifikation ist erfordert. Oder wenn du es nicht debacken kannst, wofür ist der Teil dann überhaupt gut? Also es gibt Fälle, wo das nützlich ist, aber das Problem ist, FP3As sind für gewöhnlich einfach nicht groß genug, um die ganze Zeit zu kommen. Das ist ein Problem, aber das Problem ist, die FP3As sind für gewöhnlich einfach nicht groß genug, um die ganze Zeit zu kommen. Das ist ein Problem, aber das Problem ist, die FP3As sind für gewöhnlich einfach nicht groß genug, um ganze Designs zu erfassen. Und manchmal sind die Dinge darin auch für eine andere Flow optimiert. Manche von diesen Emulator-Systemen, die wir hatten, sind aus mehreren FP3As zusammengestellt, aber mit X86-CPUs. Wenn man sich das anguckt, könnte man sowas in so ein Cycling-Ship synthetisieren. Die Antwort ist, es ist so riesig verglichen mit diesem Chip, da ist einfach keine Möglichkeit, wie es gemacht werden könnte. Vielleicht nicht in einem einzelnen Chip, aber wenn man das in keine Teile schneidet, vielleicht dann. Ja, ich habe gesehen, dass das mit kleineren Designs funktioniert, aber nicht mit sowas wie einem ganzen Core. Okay, wenn Sie die Frage stellen, dann ist das in Ordnung, aber können Sie bitte leise sein, immer noch die Frage stellen, können Sie einfach noch respektieren. Die Personennummer 3, bitte. Ja, Sie haben über die in-CPU die Barring-Features geredet. Sind die im finalen Design alle noch drin, oder werden Sie sagen, oh, dieses Scanner am Ding ist sehr teuer, hat ja gesehen, wie teuer es ist, hartwert nachträglich zu modifizieren und das sollte die Frage beantworten. Irgendwelche Barring-Features, z.B. zeitabhängig, das z.B. die verschiedenen Zeit arbeiten, die verschiedenen Zeitdingen ordentlich funktioniert. Das heißt, um zu prüfen, ob es in der richtigen Geschwindigkeit läuft, wenn es nicht in der richtigen Geschwindigkeit läuft, wo rauskriegen, welches Teil der Problem ist. Das muss man herausfinden, ja. Es ist kein Bereich, mit dem ich persönlich schon zu tun hatte. Eine Sache, die manche benutzt, wird den Laser. Wenn man ein Laser auf einen bestimmten Bereich scheint, kann man diesen Bereich aufheizen, sodass es ein bisschen schneller läuft oder so ähnlich, kann man gucken, wo der langsamste Teil im Ablauf ist. Die Sache ist, es soll auf 3 GHz laufen und wenn das nicht funktioniert und man lässt auf 2,9 laufen und dann geht es, dann muss man sich überlegen, welcher Bereich des Schaltkreises könnte das Problem machen. Typischerweise ist es kein großes Ding, denn die verschiedenen Dinge, mit denen man dabei arbeitet, sind eigentlich gut, das vorherzusagen, wo es Probleme geben könnte im Timing. Eine weitere Frage, Nummer 3 bitte. Ja, ich würde gerne fragen, sind Sie in Berechtigkeit, was ist Ihre Aufgabe, wenn ein Design, ein 90-Bio Design wird? Also, mein aktueller Job besteht darin, eine Sicherheitsfeaturen für die AMD Roadmap zu arbeiten, sowohl Sicherheitsfeatures einzubauen als auch der Platform Security Prozessor und dabei arbeiten wir mit den verschiedenen Teams, die dort an den Sicherheitsfeatures beteiligt sind, aber wir helfen ihnen auch, die Spezifikationen zu entwickeln und sicherzustellen, dass es alles getestet wird. Aber ich schreibe selbst leider kein Code mehr. Eine andere Frage, die ist okay. Nein, das kann keine weiteren Fragen sein, die Person bei Nummer 3, bitte. Die Geschwindigkeit ist eine sehr wichtige Spezifikation. Wird sie die Schockrate reduzieren, um ein Back zu reparieren, um nicht einen neuen Geschwindig, um einen neuen Chip zu reparieren, um nicht laufen zu können? Also ich würde sagen, das ist eine Business-Entfeidung. Letzte Frage, Nummer 1, Sie reden über Formelverifikation und ein Problem ist, man braucht ein Modell, wo man gegen angreifen kann. Wie stellen Sie das bei normalen Tests? Wie stellen Sie sicher, dass Sie gegen Spezifikationen testen? Das Spiel war kein Memory-Model und die CPU hat einfach nicht sinnvolles gemacht. Also das funktionale Prüfen ist mit so einer Art Goldmodell getan. Man tut Instruktionen rein und sagt, das und das muss dann an der Spezifischen Stelle vorhanden sein. Wenn man mit Formel verifiziert und man hat zum Beispiel eine Scheduling-Einheit oder so, dann hat man hunderte verschiedene Blocks, die miteinander interagieren und man muss erstmal diese einzelnen Blocks verifizieren und wie sie sich verhalten und es kann darauf hinauslaufen, dass man die einzelnen Blocks quasi dafür neu implementieren muss, was eine Menge Arbeit ist. Vielen Dank für Ihre Aufmerksamkeit. Ich habe die Übersetzung des Vortrags Well and Hardware gehört. Aus der Besetzer-Kabine