Die Einteilung in Kategorien ist erforderlich, da Boundary Scan nur bei Existenz einer gerichteten Verbindung mit mindestens einem scanfähigen Treiber und einem scanfähigen Sensor Pin-Level Fehler überhaupt erkennen und diagnostizieren kann. Unter der Prämisse, für jede Fehlerart nur die jeweils schnellste und diagnostisch schärfste Teststrategie einzusetzen, ergibt sich eine interessante Optimierung (Tabelle 7). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Durch Minimierung von Überlagerungen und insbesondere Vermeidung von Doppeltests auf Pin-Level ist es möglich, die Anzahl der Testschritte beim Flying Prober in Abhängigkeit von der Boundary Scan Implementierungstiefe zu verringern und so den Durchsatz zu steigern. Dadurch beschränkt sich der FPT auf die parametrischen Tests und die Abdeckung scanunfähiger Pins. Zum Test isolierter Boundary Scan Pins werden die Proben des FPT als virtuelle Boundary Scan Pins genutzt. Dadurch verwandeln sich Isolated Pins temporär in Fully Testable Boundary Scan Pins. Diese Methode wird prinzipiell bereits bei Standard ICT mit paralleler Pinelektronik und Nadelbettkontaktierung genutzt – die serialisierte Anwendung im Rahmen eines Flying Probers besitzt dagegen innovativen Charakter. Der Vorteil gegenüber dem Einsatz der normalen FPT-Fähigkeiten liegt zum einen in der höheren Testgeschwindigkeit von BST als digitales Verfahren begründet und zum anderen in der besseren Fehlerabdeckung bei Opens. Insbesondere bei Gehäusen wie PGA/ BGA bieten FPT mit ihren typischerweise kapazitiv arbeitenden Open-Pin-Erkennungsoptionen nicht immer die gewünschte Testqualität. Selbstverständlich steht es jedoch jedem Anwender frei, die seiner Meinung nach richtige Optimierung einzusetzen. Besitzt der
Prüfling einen eigenen Mikroprozessor nebst FLASH-basierendem
Programmspeicher kann ein Built In Self Test beispielsweise durch
Laden des FLASHs via Boundary Scan mit einem Selbsttestprogramm
implementiert werden. Im Speicher abgelegte Testresultate sind nach
Beendigung des Testvorganges wiederum per Boundary Scan auslesbar.
Auch hierin zeigt sich die Sinnfälligkeit der kombinierten Anwendung. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Abb. 3: Blockschaltbild des adapterlosen In-Circuit-Tests Als Boundary Scan Tester fungiert ein PC-basierendes System mit integrierter Software CASCON-GALAXY®, einer PCI-Einsteckkarte und speziell für Flying Prober entwickelten Erweiterungmodulen aus der SCANPLUS™-Familie. Bis zu 20 Proben können simultan angesteuert werden. Zur universellen Kopplung mit allen marktführenden Flying Probern kann der Datenlink entweder per DDE oder DLL auf einem Host erfolgen oder es kommen zwei über Standardinterface verbundene PCs zum Einsatz. Softwareseitig wurde die ATPG-Toolsuite von CASCON-GALAXY® um ein FPT-Tool ergänzt und ein dementsprechender Diagnoseprozessor integriert (Abb. 4). ![]() Abb. 4: Funktionsstruktur der Boundary Scan Software SYSTEM CASCON™ Über den Datenlink kann der Flying Prober das gewünschte BST Testprogramm auswählen und starten. Am Testende steht ein entsprechendes Testprotokoll als ASCII-File zur Verfügung, welches vom FPT als Master abrufbar ist. Beim Test isolierter Boundary Scan Pins übernimmt der Boundary Scan Tester die Vorgabe der Nadelpositionen. Der Flying Prober fungiert in diesem Fall als intelligenter Nailcontroller zur konfliktfreien Probenpositionierung. Jeder der 20 per Boundary Scan steuerbaren I/O-Testkanäle kann universell im Bereich ± 10V / 50 – 400 mA programmiert werden. Damit sind auch Backdriving/ Nodeforcing Features vorhanden. Zur Abdeckung analoger Funktionen ist jeder Kanal in der Lage, Analogspannungen mit 12bit Auflösung zu messen bzw. zu stimulieren. Weitere Details sind von der jeweiligen Architektur des Flying Probe Testers abhängig. |
|
| Praktische
Systemapplikation Aufgrund der innerhalb CASCON-GALAXY® frei definierbaren Batch-Abläufe kann jeder Anwender völlig individuelle Testsequenzen festlegen. Die Software bietet auch Testbarkeitsanalysen mit entsprechender Filterfunktion zur Ausgabe der ausschließlich durch den Flying Prober zu testenden Netze. Manuelle Modifikationen sind jedoch jederzeit möglich. Die exemplarische Darstellung eines optimierten Testablaufes enthält Tabelle 8. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Für Boundary
Scan als ein den gesamtem Produktlebenszyklus unterstützendes
Verfahren erschließt sich durch Kombination mit Flying Prober eine
neue Anwendungsqualität in der Fertigung. Dabei macht sich auch die
durchgehende Wiederverwendbarkeit der Testprogramme aufwandssenkend
bemerkbar (Abb. 5). |
|
![]() Abb. 5: Boundary Scan als integrierendes Testnetzwerk |