Protokollbasierter Halbleitertest

Armin Lechner & Michael Konrad, Konrad GmbH, Radolfzell

Der Halbleitertest wird seit langem auf automatischen Testsystemen (ATE) durchgeführt, die synchron agieren. Hierbei werden die zu testenden Bauteile mit Testmustern versorgt, die einem zentral abgeleiteten Takt folgen. Die Struktur der Pinelektronik erlaubt es dabei nicht, eine asynchrone Kommunikation zwischen Testsystem und Baustein aufzubauen. Moderne Bauteile, die eine hohe Systemintegration besitzen, agieren als Master und benötigen damit einen Tester, der adäquat auf die zeitlichen Anforderungen der Bauteile reagiert. [1]

Neben der zeitlichen Abstimmung in der direkten Kommunikation zwischen Baustein und Tester bedingen flexible Prüfabläufe anspruchsvolle Synchronisationen zwischen den einzelnen Testsystemeinheiten wie Mixed Signal oder RF Einheiten, digitalen Pins, parametrischen Messeinheiten und Prüflingsversorgungsspannungen bzw. relevanten Informationen des Tests wie Testmuster, Protokollrahmen und Ablaufsteuerung.

Werden ATEs in der Produktion eingesetzt, liegt das Hauptaugenmerk auf der Effizienz und damit auf dem Durchsatz. Jegliche intrinsische Zeit des Testsystems, wie sie etwa durch Datentransfers oder Rechenzeiten auf Zentralrechnern anfallen, ist unerwünscht. Dies führt zu der Forderung nach dezentralen Intelligenzen, die entsprechende Aufgaben übernehmen. Mit der Integration einer Echtzeiteinheit werden die Anforderungen an den deterministischen Paralleltest realisiert. Durch die enge Partnerschaft mit der Halbleiterindustrie seitens Konrad Technologies ist eine universelle Testplattform entstanden, die den Test von protokollbasierten Bauteilen adressiert. Neben Chipkarten, Funklautsprechern und Fernbedienungen werden auch alle RFID-Produkte bedient. Im Folgenden soll anhand eines HF-Produkts das „protocol aware semiconductor test system“ FINN erläutert werden.

Die modulare Systemplattform basiert auf dem ABex Konzept (Bild 1), das ein PXI-Chassis, einen Realtime-Controller, mehrere R-Series FPGA-Karten und spezifische Terminal Module beinhaltet. Für die Anbindung an die Testmanagement-Systeme und als Benutzerschnittstelle kommt ein Host PC zum Einsatz. Durch den modularen Aufbau und die Verwendung des PXI Standards können digitale Einheiten für den synchronen Patterntest, für die analogen Test Signalgeneratoren und Module zur Datenerfassung oder Prüflingsversorgungsspannungen leicht hinzugefügt werden. Für den betrachteten RFID-Test verwenden wir Instrumente, deren logische Funktionalitäten auf der FPGA-Karte und die Signalkonditionierungen auf dem Terminal Modul realisiert sind. Alle Terminal Module, die im protokollbasierten Test von DC bis 1,1 GHz zum Einsatz kommen, können asynchron betrieben werden. Die Terminal Module führen die Impedanzanpassung, Verstärkung, Kalibration und Signalkonditionierung durch. Hierbei können für jeden Kanal unabhängige Werte, wie z.B. Frequenz, Amplitude oder Empfangsempfindlichkeit eingestellt werden.

Das abgebildete Terminal Modul (Bild 2) bietet vier Kanäle und eignet sich daher ausgezeichnet für den Paralleltest. In unserem Beispiel werden Modulation und Demodulation auf dem Terminal Modul durchgeführt. Die Digitalisierung der Signale erfolgt über eine Komparatorstufe. Unterschiedliche Signalpfadschaltungen erlauben dem Ingenieur eine ferngesteuerte Diagnose der Signale.

Betrachtet man die Anforderungen der Generierung und Analyse verschiedenster RFID-Bauteile und deren Protokolle, werden verschiedene Anforderungen sichtbar. Sowohl Kodierung und Dekodierung als auch die Fehlerkorrektur-Mechanismen wie etwa CRC benötigen eine flexible und universelle Implementierung. Durch die Einführung von Symbolen ist es möglich, verschiedene Signal- und Bitfolgen, wie sie in einer Präambel oder in einer Manchesterkodierung vorkommen, in einer Auflösung von 25 ns zu definieren. Damit kann der Testingenieur nicht nur ideale, sondern auch reale Signale generieren, die im Testablauf unter anderem ein verschobenes Testverhältnis simulieren. Die Parametrisierung der universellen Sende- und Empfangseinheiten erlaubt nebenbei die freie Definition der Bitzeiten und damit die bewusste Verschiebung der idealen Kommunikation in einen Worst-case-Testablauf.

Diese unterschiedlichsten Anforderungen an die Flexibilität der Software verlangen nach einem in Schichten strukturierten Ansatz. Verantwortlich für die Abarbeitung der rein logischen Protokolle ist der Portsequenzer. Er wird von einer Main Engine kontrolliert, deren Aufgaben die Synchronisation der einzelnen Bauteile ist. Die Schnittstelle zur Peripherie und den Werkzeugen für Ingenieur und Produktionsverantwortlichen werden auf einem Host Rechner ausgeführt. Beispielsweise wird die Konfiguration eines Prüfablaufes durchgesprochen.

Alle Maßnahmen zur Anbindung an eine Datenbank, aus der Testprogramme, Parametersätze, Kalibrationsdaten, Testmuster oder andere Informationen geladen bzw. in die Testergebnisse eingebracht werden, sind in TestStand realisiert. Diese Testorganisation beinhaltet auch die Ansteuerung der Handhabungssysteme.

Wird nun ein Testablauf definiert wie er in Bild 3 dargestellt ist, so werden die Hardware-Parametrisierungen in einem eigenen Testschritt durchgeführt. Alle notwendigen Informationen wie etwa Trägerfrequenz, Modulationsindex, Leistung, Threshold der Komparatoren oder auch Bitzeiten, können frei gesetzt werden.

Nach der Parametrisierung der Hardware, die zu einem beliebigen Zeitpunkt durchgeführt werden kann, wird das zuvor definierte Protokoll aufgerufen. Dem Testingenieur stehen mächtige Werkzeuge zur Seite. Aus einer Bibliothek werden vordefinierte Kommandos ausgewählt und parametrisiert. Beispielsweise werden in einem Query nur noch die reinen Nutzdaten wie die SessionID festgelegt. Andere Informationen wie Command Code oder Aussehen der Präambel oder die Festlegung des CRC sind bereits vorgeschlagen. Damit kann mit wenigen Klicks das Protokoll, respektive der Testinhalt, konfiguriert werden. Für die gebräuchlichen Produkte, die die Standards ISO 14443, 15693 und 7816 bedienen [2], sind die Protokolle und deren Bestandteile in einer Bibliothek vorhanden. Fehlen Templates, so sind entsprechende Tools vorhanden, die es ermöglichen, die benötigten Bestandteile der Kommandos zusammenzusetzen. So kann der CRC beispielsweise frei definiert, oder die Zufallszahlen können an einer beliebigen Stelle platziert werden.

Neben der Protokolldefinition bildet die Parametrisierung der Kodierung und Dekodierung einen wichtigen Bestandteil der Testprogrammentwicklung. Beispielsweise wird die Manchesterkodierung durch die Definition von Symbolen realisiert. In einem GUI-Tool werden die entsprechenden Low/High-Übergänge definiert. Dieses Tool dient auch der Präambel oder End-of-frame-Generierung.

Neben dem umfangreichen TestStand stehen dem Ingenieur vielfältige Analyse und Debug-Möglichkeiten, wie unter anderem Shmootool zur Verfügung. Diverse Triggermöglichkeiten erleichtern dem Testingenieur das Auffinden kritischer Stellen. So können innerhalb von Protokollen an quasi beliebigen Stellen Triggerevents generiert werden. Zur Analyse ist es möglich, systemintern Signale mit optional eingebauten Digitizern ohne zusätzlichen Verdrahtungsaufwand aufzunehmen. Das auf die Bedürfnisse der Produktion angepasste Operator Interface rundet die komplette Software-Unterstützung ab. Werkzeuge zur statistischen Analyse und zur Erfassung großer Datenmengen unterstützen die Produktionsüberwachung.

Konrad bietet umfassende und flexible Lösung für den protokollbasierten Test.

www.ni.com &

EPP 448

[1] Andrew C. Evans. The New ATE: Protocol Aware. Broadcom Corporation Irvine, California

[2] Wolfgang Rankl, Wolfgang Effing. Handbuch der Chipkarten. Carl Hanser Verlag