Chiptest Geplante Prüfung

Beim Test von Bauelementen gelten stets dieselben Maßgaben: möglichst viele Chips in möglichst kurzer Zeit möglichst gut für möglichst wenig Geld zu prüfen. Zum Erreichen dieser Ziele haben grundlegende Verfahren wie »Design for Test« beigetragen, die jedoch durchaus auch Nachteile besitzen, denn je mehr Funktionsblöcke bereits in frühen Entwurfsstadien festgeschrieben sind, umso unflexibler wird das Design. Besonders bei Mixed-Signal-Implementierungen kann das verhängnisvoll sein. Wie kann also eine sinnvolle Teststrategie aussehen?

EDA-Firmen investieren große Mengen an F&E-Ressourcen in ihre Testtools, um den Zeitbedarf des Chiptests zu reduzieren. Und das zu Recht, beeinflusst die Testzeit doch direkt die Wirtschaftlichkeit eines Chips. Aber sich auf die Verringerung der Testzeit zu konzentrieren ist noch nicht alles. Entwicklerteams streben vermehrt Produktivitätsgewinne im Rahmen ihrer Testaktivitäten über den gesamten Designfluss hinweg an, von der Testintegration bis zur Yield-Analyse.

Die Integration des Tests mit dem Entwurf verkürzt den Zeitaufwand für die Testimplementierungsschritte innerhalb des Designflows signifikant. In der Praxis zeigt sich, dass der Unterschied zwischen einem synthesebasierten Testansatz und einer separaten Testlösung die Zeit für die Testimplementierung von vier Wochen oder mehr auf einige Tage senken kann.

Generell sind die fundamentalen Herausforderungen für Testingenieure weitgehend konstant geblieben: möglichst viele Bauteile mit höchster Qualität zu geringsten Kosten. Dennoch gibt es eine Reihe von Entwurfs- und Techniktrends, die das Überwinden dieser fundamentalen Herausforderungen erschwert haben. So nimmt die Designkomplexität weiter zu, und zwar hinsichtlich der Anzahl an Logikgattern, einem wachsenden Mixed-Signal-Anteil, größeren Speicherblöcken und hochentwickelten Architekturen zur Reduktion der Verlustleistung.

Weiterhin müssen Testingenieure mit immer weniger dedizierten Testpins auskommen. Dies liegt an einem verstärkten Fokus auf Package-Kosten, kleineren Formfaktoren für mobile Anwendungen, der Verbreitung core-basierter Entwurfsmethodiken und der Notwendigkeit, standortübergreifenden Testtechniken gerecht zu werden. Als Konsequenz daraus bemühen sich die Testteams um einen höheren Grad der Testkompression. Mit zunehmender Komplexität von Entwurf und Test werden die Abhängigkeiten zwischen beiden Bereichen weitaus schwieriger zu beherrschen, um die Vorgaben hinsichtlich Durchsatz, Qualität und Kosten beim Test zu erfüllen.

Test beeinflusst Entwurf

Das Hinzufügen von Teststrukturen zu einem Design, um die Fehlerabdeckung zu erhöhen, kann es schwieriger machen, die Entwurfsziele hinsichtlich Timing, Chipfläche, Verlustleistung und Routing zu erreichen. Gleichzeitig kann die Komplexität des Designs selbst die Erfüllung der Testziele erschweren.

Zu den Problemen, welche die Testingenieure berücksichtigen müssen, gehören beispielsweise die Anzahl der für den Test verfügbaren Pins, die Größe und die Art der zu testenden Speicherblöcke, sowie Teststrategien für Strukturen, die verschiedene Verlustleistungs- und Betriebsspannungsbereiche überspannen. Die Konvergenz der Entwurfs- und Testziele ist zunehmend schwieriger zu erreichen, wenn sie als separate Aufgaben betrachtet und realisiert werden, was bei einem sogenannten »Bolt-on-Test« der Fall ist.

Bolt-on-Testflows trennen die entscheidenden Schritte der Testimplementierung von der RTL-Synthese und der Designimplementierung. Der Einsatz von Bolt-on-Testflows impliziert eine iterative Vorgehensweise bei der Test- und Designimplementierung.

Die Verwendung separater Testwerkzeuge vor der Synthese, die keine Kenntnis über das endgültige Design besitzen, sowie nach der Synthese auf Basis der Gatternetzliste, wo weitere Syntheseschritte erforderlich sind, um den Einfluss der DFT-Logik auf das Zeitverhalten zu bereinigen, ist die Hauptursache der Iterationen. Zwischen Entwurf und Test zu iterieren erfordert oft einen signifikanten Zeitaufwand, Mühen und Kosten (Bild 1).

Zu den spezifischen Problemen eines Bolt-on-Testflows gehören:

  • Scan-Compression-Schätzwerte:

Für Designs, die Scan-Compression-Logik nutzen, müssen Testingenieure bisweilen die Kompressionsarchitektur bereits festlegen, bevor der Block selbst fertiggestellt ist. In diesem Fall besteht die Gefahr einer inkorrekten Architektur, sodass das Design zu aktualisieren ist und alle Implementierungsschritte zu wiederholen sind. Werden die Schritte nicht wiederholt, so resultiert dies in einer nicht optimalen Kompressionsarchitektur und sehr wahrscheinlich in einer Verminderung der Qualität des von einem ATPG-Tool (Automatic Test Pattern Generation) generierten Testprogramms.

  • Manuelle Verdrahtung:

Das Designteam muss Kompressionslogik, die als separate RTL-Blöcke vor der Synthese entwickelt wurde, manuell mit dem endgültigen RTL-Code verbinden. Ein manueller Prozess ist aber stets fehleranfällig, und dies wird mit zunehmender Verbesserung der Kompressionstechniken immer herausfordernder. Die meisten der in diesem Schritt auftretenden Fehler werden bis zur Validierung im Anschluss an die Synthese nicht entdeckt.

Unglücklicherweise kann die Scan-Chain-Validierung nicht das endgültige ATPG-Ergebnis vorhersagen und daher nicht alle Scan-Compression-Fehler aufdecken. Kurzum, ein während der Verdrahtung der Compression-IP gemachter Fehler kann zu Iterationen zu einem späten Zeitpunkt im Entwurfsprozess führen oder die Testqualität aufgrund fehlender Scan-Compression-Logik verringern.

  • Gate-Level-DFT:

Die herkömmliche Praxis, normale Flip-Flops auf Gatterebene durch Scan-Flip-Flops zu ersetzen, kann nicht länger aufrechterhalten werden. Dieser Prozess schenkt den Design-Constraints nur wenig oder gar keine Beachtung. Gatterorientierte DFT-Tools schaden dem Entwurf, weil sie weder die Verbindungen über Spannungs-/Leistungsbereiche hinweg noch den Einfluss der dominanten Verdrahtungslaufzeiten auf das Zeitverhalten insgesamt, noch Flächenbegrenzungen bei mobilen und hochvolumigen Konsumerchips berücksichtigen.

  • Scan-Chain-Verdichtung:

Die Implementierung von Testkompression in hohem Umfang resultiert aufgrund der vielen Verbindungen zwischen der Kompressionslogik und den internen Scan-Chains in einer erhöhten Routing-Dichte. Physikalische Designwerkzeuge können damit zwar umgehen, allerdings wird die Routing-Konvergenz erschwert und langwieriger, wenn dies erst nach abgeschlossener Optimierung des Routings für das Design selbst erfolgt. Der beste Weg, um die Auswirkungen der Testlogik auf die Entwurfsziele und Designcharakteristiken zu berücksichtigen, ist die Kombination der Design- und Testimplementierung in der RTL-Synthese.

Synthesebasierter Test

Die Alternative zu einer separaten, isolierten Testlösung besteht darin, die Testimplementierung in die Designimplementierung zu integrieren. Synopsys’ synthesebasierter Testansatz bettet DFT in die RTL-Synthese mit »Design Compiler« ein. Die Tools synthetisieren die Testlogik simultan zur funktionalen Logik und beobachten dabei ständig die Timing-, Power-, Chipflächen- und Floorplan-Constraints für die Test- und funktionale Logik (Bild 2).

Im Rahmen des synthesebasierten Tests wird eine vollständige Optimierung der Teststrukturen hinsichtlich Testabdeckung und Testdaten/Testzeit auf der Basis der Designcharakteristik und Design-Constraints ausgeführt. Die Entwicklungszeit wird kürzer, weil die Anzahl der Entwurfsiterationen abnimmt und die Konvergenz von Entwurfs- und Testzielen schneller geht. Zu den spezifischen Vorteilen gehören:

  • Vereinheitlichter Test-DRC:

Ein hierarchisches Design impliziert den Entwurf einzelner Blöcke und deren Integration auf Chip-ebene. Blockentwickler können synthesebasierte Testtools bereits vor der Synthese auf Modulebene einsetzen, um die Einhaltung der DFT-Regeln zu verifizieren. Die Test-DRC-Funktionen von Synop-sys‘ »DFTMAX« und »TetraMAX-ATPG« sind in der Lage, schon vor der Logiksynthese Feedback zur Testbarkeit des Designs zu geben. So können Entwickler die RTL-Testbarkeit frühzeitig im Entwurfsprozess berücksichtigen.

  • Automatische Test-DRC-Korrekturen während der Synthese:

Test-DRC-Feedback ermöglicht Entwicklern, Testbarkeitsprobleme im RTL-Code zu identifizieren und zu beheben. Durch die Möglichkeit, Verletzungen von Testbarkeits-regeln innerhalb der Syntheseumgebung durch Automatismen zu lösen und gleichzeitig die Timing-Constraints einzuhalten, erzielen Entwickler eine kurze Turnaround-Zeit. Die manuelle Implementierung von Testbarkeitskorrekturen auf Gatterebene kann hingegen die Verletzung von Design-Constraints zur Folge haben und führt unweigerlich zu zusätzlichen Synthese-Iterationen, um die Timing-Con-straints einzuhalten.

  • Minimierung des DFT-Chipflächenbedarfs und der Routing-Dichte:

Die Integration von DFTMAX-Kompression mit der Synthese minimiert automatisch die Flächen für DFT. Man betrachte als Beispiel den Fall eines Schieberegisters. Solche Strukturen besitzen bereits eine Schiebefunktion, sodass lediglich das erste Flip-Flop durch ein Scan-Äquivalent ersetzt und der Ausgang des letzten Flip-Flops mit dem nächsten Scan-Flip-Flop verbunden werden muss.

Die Alternative auf Gatterebene wäre die Ersetzung jedes Flip-Flops durch ein Scan-Äquivalent. Im Falle eines umfangreichen Grafikprozessors spart der eingeschränkte Einsatz von Scan-Flip-Flops bis zu 5% der Chipfläche ein, weil darin Schieberegister in großer Zahl zum Einsatz kommen. DFTMAX-Compression arbeitet mit »DC Graphical« zusammen, um die durch die Test-Kompressionslogik und Scan-Pfad-Verbindungen verursachte Routing-Dichte zu verringern, wodurch letztlich der Aufwand und die Laufzeit physikalischer Designsysteme wie IC Compiler sinken.

DC Graphical hat spezifische Kenntnis von der von DFTMAX-Compression generierten Kompressionsarchitektur und kann Techniken zur Congestion-Optimierung gezielt auf diese Architektur anwenden.

  • Automatische Übergabe an ATPG:

DFTMAX-Compression minimiert den für die Testmustergenerierung erforderlichen RTL-Entwurfs-aufwand durch automatische Erstellung der Beschreibung der Scanpfad-Funktionsweise oder einer Protokolldatei. Die Protokolldatei steuert die ATPG und muss in einem gültigen, computer-lesbaren Format vorliegen. DFTMAX-Compression erzeugt die Datei unter Verwendung des IEEE-1450-Standards (bekannt als STIL), die wiederum von TetraMAX-ATPG gelesen wird.

Der Entwickler muss lediglich die Netzlisten- und Bibliotheksinformationen für TetraMAX-ATPG bereitstellen. Der Test komplexer Chips erfordert dedizierte, über das gesamte Design hinweg eingebettete Testlogik. Diese außerhalb des Syntheseflows zu implementieren, beeinflusst Designcharakteristiken wie Performance und Leistungsaufnahme negativ und zieht daher Iterationen zwischen Synthese und Test nach sich, die den Projektzeitplan verlängern.

Dagegen implementiert ein synthesebasierter Testansatz die Testfunktionen im Rahmen der RTL-Synthese, um den Einfluss auf die Leistungsaufnahme, das Zeitverhalten und die Chipfläche zu minimieren, um die Konvergenz von Entwurfs- und Testzielen zu beschleunigen.

Über den Autor:

Robert Ruiz ist Senior Test Product Marketing Manager bei Synopsys.