Embedded-Instrumentierung in FPGAs verändert die Testrichtung von innen nach außen FPGA-Controlled-Test gewinnt an Bedeutung

Mit zunehmender Komplexität wir es immer schwieriger, den physischen Kontakt zu einer Leiterplatte mit traditionellen Messgeräten herzustellen. Nach Überzeugung der Embedded-Instrumentation-Experten von Asset Intertech schrumpft damit auch die Testabdeckung kontaktgebundener Technologien, weil bei diesen Methoden eine Prüfspitze an der Leiterplatte bzw. am Chip angelegt werden muss. Eine Lösung verspricht der FPGA-Controlled-Test, kurz FCT.

Aufgrund der reduzierten Abdeckung, die sich mit externen kontaktgebundenen Methoden erzielen lässt, haben einige Hersteller bereits auf berührungslose Instrumentierung umgestellt. Diese ist in den Chips und auf den Leiterplatten temporär oder dauerhaft eingebettet und wird über Software angesteuert. »Embedded-Instrumentierung kann Boards und Systeme von innen nach außen validieren, charakterisieren, testen und debuggen, selbst wenn die funktionale Betriebs-Software und -Firmware noch gar nicht entwickelt sind«, erklärt Al Crouch, Chief Technologist, Core Instrument Technology von Asset Intertech. »Diese Messtechnik lässt sich auch in einem FPGA einbetten und betreiben. Wird die Testfunktion nur für eine bestimmte Entwicklungs- oder Montagephase gebraucht, können die entsprechenden Firmware-basierten Systeme in ein FPGA eingebunden und nach Erfüllung ihres Zwecks später wieder entfernt werden. FPGA-basierte Tester arbeiten intern und sind gezielt auf die Anforderungen eines bestimmten Board-Designs oder Systems ausgelegt.«

FPGA-Controlled-Test (FCT)

Die Methode, Embedded-Instrumentierung in FPGAs für Test- und Messzwecke zu verwenden, heißt FPGA-Controlled-Test, kurz FCT. Für die möglichst effiziente Nutzung von FCTs brauchen die Anwender ein festes Set vordefinierter Operationen, um auf die Embedded-Instrumentierung zuzugreifen, ihren Betrieb zu automatisieren und ihre Ausgaben auszuwerten. »Die Einbindung von Instrumentierung in ein oder mehrere FPGAs auf einer Leiterplatte steht lediglich am Anfang des ganzen Prozesses«, so Crouch. »Vielfach sind mehrere Instrumente eingebunden, die jeweils einen ganz bestimmten Zweck bei der Entwicklung, der Montage und sogar beim Feldservice erfüllen. Während der Entwicklung werden beispielsweise die ersten Board-Prototypen in der Regel schon lange vor der Fertigstellung der Betriebsfirmware für das FPGA des Boards geliefert.« Vorteile sieht der Experte unter anderem darin, dass sich mit FCT die Terminpläne für die Entwicklung einhalten oder sogar verkürzen ließen, weil die Ingenieure die Prototypen der Leiterplatten schon validieren und testen könnten, bevor die Firmware des FPGA verfügbar sei. Und sobald die funktionale Betriebsfirmware fertig sei, könne sie auf einem nachweislich fehlerfreien Board getestet und debugged werden.

»Die Infrastruktur der vordefinierten Operationen, die für FCTs erforderlich ist, muss zwischen verschiedenen Board-Designs und FPGA-Typen übertragbar sein«, so Crouch. »Darüber hinaus muss die Architektur den optimierten und effizienten Zugriff auf die Embedded-Instrumentierung ermöglichen und deren effizienten Betrieb gewährleisten. Besonders wichtig ist aber, dass das FCT-Toolkit mit Industriestandards konform ist. Verschiedene vorhandene Standards wie IEEE 1149.1 Boundary-Scan (JTAG) und IEEE1500-Core-Test werden zur Unterstützung von FCT implementiert, aber ein zukünftiger Standard, der interne JTAG (IJTAG) IEEE P1687, wird mit Sicherheit von entscheidender Bedeutung für diese Testmethode sein.«

Warum IJTAG?

Die IJTAG-Arbeitsgruppe des IEEE entwickelt seit zwei Jahren an diesem Standard. Eines der wichtigsten Ziele der Arbeitsgruppe ist die Optimierung der Funktionsweise eingebetteter On-Chip-Instrumente durch Definition einer standardisierten Hardware-Architekturschnittstelle und einer portablen Prozedur/Vektorsprache für diese Instrumente. Der Ausschuss ist überzeugt, dass dies die Nutzung der Instrumentierung erleichtert, die in FPGAs und anderen Arten von Chips eingebettet wird. Darüber hinaus werden damit die Voraussetzungen zur Entwicklung von Drittanbieter-Tools für eingebettete Instrumentierung geschaffen. Das erste IJTAG-Entwicklungs-Toolkit wurde gegen Ende des vergangenen Jahres auf der 2010 International Test Conference angekündigt.

Um den Abschluss der ersten Fassung des IJTAG-Standards zu beschleunigen, nahm die Arbeitsgruppe Anleihen beim Boundary-Scan-Standard (JTAG) IEEE1149.1. So ermöglicht die Boundary-Scan-Infrastruktur, die bereits in vielen Designs und Chips vorhanden ist, den physischen Zugriff auf Embedded-Instrumentierung. Über die physische Ebene hinaus definiert der IJTAG-Standard eine On-Chip-Architektur für eingebettete Instrumentierung und zwei Sprachen zur Beschreibung der Architektur und Steuerung des Betriebs bzw. der Prozeduren der Instrumentierung. Darüber hinaus ist in diesem Standard auch eine Schnittstelle für die Instrumentierung festgelegt, die die Übertragbarkeit und Wiederverwendbarkeit von einbettungsfähigen Instrumenten gewährleistet.

Bild 1 zeigt ein Beispiel für eine IJTAG-Basisinfrastruktur auf einem FPGA. Der Einfachheit halber sind nur zwei Memory-BIST-Instrumente (Built-In Self Test) eingezeichnet, aber es ließen sich auch gleichzeitig viele andere Arten von Instrumentierung in ein und demselben FPGA implementieren. »Eines der Schlüsselelemente einer IJTAG-Architektur ist das Segment Insertion Bit, kurz SIB«, verdeutlicht Crouch. »SIBs ermöglichen den bedarfsgesteuerten Zugriff auf die Register der Instrumentenschnittstelle. Ein Instrument wird durch Selektion seines SIB für einen Testprozess aktiviert. Das gilt auch für die Instrumente in einem aktiven Scan-Test, die sich dann für die Kommunikation mit der eingebetteten Instrumentierung im Rahmen des Tests nutzen lassen. Anschließend kann die FPGA-Instrumentierung die Testvektoren zum Board schicken, um Peripherie-Chips und Routen zu testen und Daten zu erfassen.«

Die ICL-Sprache (Instrument Connectivity Language) des IJTAG-Standards wird zur Beschreibung von Scan-Pfaden und zur Steuerung der Variationen bei den Scan-Pfaden genutzt, die unter Umständen zur Durchführung eines bestimmten Sets von Testvektoren erforderlich sind. Eine andere IJTAG-Sprache, die Procedural Description Language (PDL), beschreibt die Testvektoren oder Abläufe, die von der eingebetteten Instrumentierung angewendet werden.