Chip-Design-Debugging Formale Verifikation mit OneSpin 360 MV erzwingt die 100%-Prüfung

Autor / Redakteur: Roland Syba* / Gerd Kucera

Was fernab der Welt unvermeidbarer physikalischer Defekte eines Schaltkreises dem Entwickler das Leben wirklich schwerer macht, zeigt dieser Erfahrungsbericht. Er hinterfragt das Phänomen „no Failure found“, das trotz eingehender Analyse des definitiv defekten Chips immer wieder auftritt. Und er zeigt, wie es mit Methoden der formalen Verifikation möglich ist, die bisher nie erreichte 100%-Vollständigkeit der Verifikation zu erzwingen.

Anbieter zum Thema

Jeder Entwickler kennt die Situation: man betrachtet zufrieden den gerade fertig gestellten perfekten Chip und wendet sich voller Motivation einem neuen Design zu. Monate später und wie aus dem Nichts tauchen dann Probleme auf, von denen man dachte, sie gar nicht haben zu dürfen. Der Mensch ist stets geneigt, positiv zu denken und an den „Guten Chip“ zu glauben. Doch niemand ist gefeit vor unliebsamen Überraschungen. Wenn ein „gut verifiziertes“ Design eines erfahrenen Entwicklungsteams den Schreibtisch verlässt (simuliert nach allen Regeln der EDA-Kunst) und mit gutem Gefühl der Maskensatz dann in die Fabrik rollt (die Testpattern sind so vollgestopft mit Coverage, dass die Reklamationsrate schon negativ sein müsste) passiert es trotzdem: fehlerhafte Chips tauchen auf.

Während die Thematik von Partikelfehlern, Wafer- Prozessierungsabweichungen, Zuverlässigkeitsuntersuchungen und die Auswertung der Daten aus statistischen Analysen mittlerweile schon sehr gut vorhersagbare Ergebnisse über die Qualität in der Herstellung eines IC liefern, die selbst im ppm-Bereich noch höchst wirksam potenzielle Ausfallkandidaten herausfiltern können, bewegt sich die Entwicklungswelt unmerklich auf ein neues Dilemma zu.

22874100

Die Verifikationslücke

Der Wunsch nach Schaltkreisen mit immer mehr Prozessorleistung, hergestellt auf immer kostengünstigeren Wafern in immer kleineren Technologien, ausgestattet mit großen Speichern und der Integration möglichst vieler diskreter Komponenten in die Chips hinein, lassen in rasantem Tempo die Schaltkreise anwachsen.

Bild1: Modulares Konzept in IC-Entwicklungen (Archiv: Vogel Business Media)

Nicht genug, dass die IC-Designs immer größer werden und inzwischen mehr einem Motherboard als einem Silizium-Chip gleichen – insbesondere der Zuwachs der Komplexität potenziert die Gefahren unentdeckt gebliebener Schwächen oder gar echter Bugs. Oft werden ganze Gruppen von verschiedenen Applikationsfunktionen zusammen mit Möglichkeiten der Umkonfiguration in einen einzigen IC verpackt, dem Kostendruck nach Vereinfachung der Lieferlogistik Rechnung tragend und um die Entwicklungskosten „über alles“ zu reduzieren.

Diese Verschachtelung mehrerer IC-ähnlicher Inhalte forciert regelrecht das Anwachsen der Komplexität solcher Chips. Im Gegensatz zu überwiegend datenverarbeitenden Schaltkreisen mit hoher Parallelität stehen hier ganze Registerbänke mit Einzelbits, von denen jedes Bit eine der vielfältigen Funktionen verändern kann.

Die Errata-Listen werden länger

Es ist also nicht verwunderlich, dass sich die Errata-Listen der Hersteller-Datenblätter weiter füllen, kaum dass ein Chip auf dem Markt ist. Und selbst 30 oder mehr darin publizierte Abweichungen zur Spezifikation sind durchaus keine Seltenheit. Zu hoch sind Aufwand, Kosten und Zeitbedarf für deren komplette Beseitigung, und zu allem Überfluss schließt sich das gerade geöffnete Marktfenster schon wieder, bevor auch das letzte Re-Design fertig gestellt sein würde. Nun, damit kann man immer noch leben, es ist nicht perfekt und bei Umschiffung von genau beschriebenen Fehlern funktioniert das Design trotzdem.

Bild 2: Vielfalt kontra Standard-IC im Automobil (Archiv: Vogel Business Media)

Sporadisch fallen plötzlich wie aus heiterem Himmel einzelne IC im Feld aus. Manchmal erst Wochen und Monate später, nachdem die Nullserie bereits etliche Betriebsstunden ohne Probleme absolviert hat. Unerklärliche und nicht näher definierbare Fehlersituationen, und immer nur in „Apotheker-Mengen“ – einzeln oder mal drei am Stück – landen solche Reklamationen beim Baugruppenhersteller. Nach zwei Wochen intensivster Untersuchungen ohne Ergebnis gibt es für den Modulhersteller noch eine letzte Idee: Daran kann nur noch der IC schuld sein – auch wenn dieses gar nicht feststellbar war durch üblichen Kreuzvergleich mit einem jungfräulichen Ersatz.

Und so machen die bezweifelten IC sich auf die Reise zu ihren Ursprüngen. Was dem Modulhersteller nicht gelang, soll nun der Chip-Lieferant herausfinden. Bei diesem laufen zunächst alle Chip-Tests beanstandungslos selbst unter verschärften Bedingungen und weit außerhalb der Spezifikationsgrenzen, die Laboruntersuchungen zeigen „leider“ auch nur, dass der Chip wundervoll und wie gewünscht funktioniert. Und selbst die schließlich vorgenommenen Fehleranalysen am geöffneten IC lassen keine neuen Erkenntnisse zu.

Warum der Chiptest versagt

Das Phänomen „no Failure found“ hat wieder zugeschlagen. Und es ist inzwischen ein nicht zu vernachlässigendes Problem. Es trifft mittlerweile in einem Umfang zu, der die Anzahl der aufgeklärten Reklamationen desselben Chips übersteigen kann – sehr zum Leidwesen aller Beteiligten.

Bild 3: Dieser Ausschnitt eines „kleinen Steuerteiles“ lässt erahnen, welche Vielfalt an Abhängigkeiten zu verifizieren ist (Archiv: Vogel Business Media)

Trotz aller intensiven Simulationen, etlicher Design-Reviews und sorgfältigen FMEA, allen Evaluierungen, Qualifizierungen und Laboruntersuchungen zum Trotz und auch wenn scheinbar alles Menschenmögliche getan und jeder erdenkbare Test bestanden wurde, ist einfach nicht herauszufinden, warum „etwas“ nicht funktionieren soll. Oft sind die beigelegten Informationen zur Reklamation beim ersten Lesen eher wenig hilfreich; „Modul defekt“ oder „Funktion XY geht nicht“ sind übliche und nur grobe Beschreibungen. Also fängt man an, die finalen Bauteiletests am Probanden akribisch auszuwerten, mit verblüffendem Aha-Ergebnis: alles scheint in bester Ordnung.

Das Problem jedoch liegt tiefer. Kein Chiptest wird je einen Bug aufdecken können, denn wie der Vergleich eines Apfels mit einem Apfel, stellt der IC-Test lediglich fest, alles ist wie im Vergleichsnormal und lässt den Chip als „gut“ passieren. Der Test allein kann niemals darüber entscheiden, ob das, was in den Chip implementiert wurde, auch richtig ist. Der Chiptest kann nur darüber befinden, ob das was darin sein sollte, auch fehlerfrei produziert wurde. Hier wird geradezu überdeutlich, wie enorm wichtig es ist, für die inhaltliche Richtigkeit des Vergleichsnormals garantieren zu können, mit dem später alle Chips gemessen werden. Und diese Gewähr ist nur bei 100% Verifikation möglich.

(ID:356648)