JTAG/ BOUNDARY SCAN WAS KANN ES, UND WAS MUSS MAN DAFÜR TUN

Transkript

1 JTAG/ BOUNDARY SCAN WAS KANN ES, UND WAS MUSS MAN DAFÜR TUN 1 Entstehungsgeschichte oder Das Testen einer integrierten Schaltung Seit es integrierte Schaltungen gibt besteht die Notwendigkeit die Funktion zu überprüfen. Handelt es sich dabei um digitale Schaltungen, gestaltet sich deren Test relativ einfach: Man legt an den Eingängen nacheinander sämtliche möglichen Testvektoren an und vergleicht die Reaktion der Schaltung an den Ausgängen (IST-Ausgangsvektor) mit den erwarteten Mustern (SOLL-Ausgangsvektor). Ergibt der Vergleich keine Abweichung, ist die Schaltung in Ordnung. Für ein einfaches UND-Gatter mit zwei Eingängen ist die Anzahl der Testvektoren noch überschaubar. Nach Moore und McCluskey errechnet sich diese nach der Formel: Q = 2 ( x+ y) Q = Mindestanzahl der Testvektoren x = Zahl der Eingänge y = Zahl der Speicherelemente (bei sequentiellen Schaltungsteilen) Da ein UND-Gatter gewöhnlich keinerlei Speicherelemente beinhaltet, kommt man auf eine Anzahl von gerade einmal vier notwendigen Testvektoren, was eine leicht zu handhabende Menge darstellt. Führt man diese Berechnung allerdings für eine Schaltung mit einer angenommenen Anzahl von 25 Eingängen und 50 Speicherelementen durch, wird man sofort erkennen, mit welchem Problem sich die Ingenieure in den Chip Entwicklungen in den 70er Jahren konfrontiert sahen hatte Ed Eichelberger bei IBM mit der Erfindung des ersten Level Sensitive Scan Design (LSSD) Verfahrens eine bahnbrechende Idee. Hierzu werden die in einem Chip vorhandenen Speicherelemente in Ihrer Funktion erweitert. Sie bekommen vier zusätzliche Anschlüsse: einen Eingang (IN), einen Ausgang (OUT) und zwei Clocks (A und B); siehe Abbildung 1. Mit diesen zusätzlichen Ressourcen ist es möglich ebenfalls auf die Ein- und Ausgänge der Speicherelemente zuzugreifen. Das im U.S. Patent 3,761,695 beschriebene Verfahren eröffnete also einen zweiten Weg, neben der eigentlichen Funktion der Speicherelemente auf deren Ein- und Ausgänge zuzugreifen. Das war der Durchbruch! - 1 -

2 Aufgrund dieser neu geschaffenen Möglichkeit zerfallen die zuvor noch komplexen und untestbaren Chip Designs, bestehend aus einer vielfachen Verschaltung von kombinatorischer mit sequentieller Logik, in Gruppen, welche dann nur noch aus kombinatorischen und somit einfach zu testenden Elementen bestehen. Abb. 1 Ausschnitt aus U.S. Patent 3,761,695 Erst Anfang der 80er Jahre begann man auch auf Baugruppen-Ebene, die Problematik der zunehmenden Komplexität der Baugruppen mit immer höheren Packungsdichten anzugehen. Als eine der ersten beschäftigte sich die 1985 gegründete Joint European Test Action Group mit dem Thema. Damals bestand diese Gruppe aus Test-Ingenieuren der großen europäischen Chip Hersteller traten ihr weitere Firmen aus Nordamerika bei, und die Gruppe wandelte ihre Bezeichnung in Joint Test Action Group (JTAG) um. Die JTAG konstruierte dann ein Verfahren, welches sich stark an das von Ed Eichelberger entwickelte LSSD Verfahren anlehnte. So definiert es ebenfalls Speicherelemente innerhalb eines Chips, welche miteinander in einer Schiebekette verbunden sind. Nur mit dem Unterschied, dass diese Speicherelemente nun zusätzlich an der Peripherie, sprich an der Bauteilgrenze ( at boundaries ) eingebracht wurden. Das entwickelte Verfahren wurde deshalb auch Boundary Scan genannt. Standardisiert wurde es im Jahre 1990 vom Institute of Electrical and Electronics Engineers (IEEE) als Standard Test Access Port and Boundary Scan Architecture. Da die Arbeit der JTAG maßgeblich für den Inhalt des Standards war, hat sich als Synonym für den Standard der Name der Gruppe etabliert

3 Der Standard IEEE hat unter anderem in den Jahren 1993 und 1994 eine Überarbeitung erfahren und liegt nun im aktuellen Stand von 2001 vor. 2 Der Boundary Scan Standard IEEE Der Boundary Scan Standard IEEE beschreibt den statischen, digitalen Verbindungstest. Spricht man heute von Boundary Scan oder JTAG, so bezieht sich dies immer auf den Standard IEEE Im Standard selbst ist der Aufbau eines Boundary Scan-fähigen Bausteins dargelegt, wie auch die Beschreibungssprache, die Boundary Scan Description Language (BSDL), welche die für jeden Baustein einzigartige Boundary Scan Ressourcen offen legt. Für ein besseres Verständnis des Boundary Scan Testverfahrens ist es zunächst notwendig, den inneren Aufbau eines solchen Bausteins zu kennen. Der Standard IEEE definiert hierzu vier wesentliche Bestandteile, über die ein Boundary Scan-fähiger Baustein verfügen muss: - Test Access Port (TAP) - TAP Controller - Befehlsregister ( Instrucion register ) - ein oder mehrere Datenregister 2.1 Das Test Access Port (TAP) Das Test Access Port stellt die Schnittstelle zwischen der im Baustein befindlichen Boundary Scan Logik und der Außenwelt dar. Es sind drei Eingänge (zzgl. eines optionalen vierten) und ein Ausgang beschrieben. Die Eingänge sind: - Test Clock (TCK) - Test Mode Select (TMS) - Test Data Input (TDI) - Test Reset (/TRST) optional Der Ausgang ist: - Test Data Output (TDO) Bei den beiden Signalen TCK und TMS sowie beim optionalen /TRST Signal handelt es sich um Broadcast Signale, wohingegen das TDI hin zum TDO eine serielle Kette bildet, die - 3 -

4 sogenannte Scankette oder auch Scanpfad (siehe Abbildung 2). Auf Baugruppen-Ebene spricht man vom Testbus. Das Geniale bei diesem Konstrukt ist, dass nie mehr als vier (optional fünf) Signalleitungen benötigt werden, unabhängig davon, wie viele Bausteine in die Scankette geschaltet werden. Abb. 2 Testbus Verdrahtung von zwei Boundary Scan Bausteinen Im Boundary Scan Baustein sind der Test Clock, das Test Mode Select wie auch der Test Reset direkt mit dem TAP Controller, sprich statisch, verbunden. Die Signale sind einzig und allein verantwortlich für den dessen Zustand. Das bedeutet gleichzeitig auch, dass sich alle Boundary Scan Bausteine einer Scankette immer im gleichen TAP Zustand befinden. Das bedeutet nicht automatisch, dass sich auch alle Bausteine immer im gleichen Betriebsmode/ Befehl befinden müssen. Dieser wird nämlich nicht über den TAP Zustand definiert, sondern über das im Kapitel 2.4 Die Datenregister beschriebene Datenregister, das für jeden Baustein separat gesetzt wird. Im Gegensatz zur statischen Zuordnung der zuvor beschriebenen Signale ist die Auswahl des Registers, das zwischen dem Test Data Input und dem Test Data Output geschaltet wird, flexibel. Dabei wird zunächst im TAP Controller entschieden, ob das Befehlsregister oder eines der Datenregister aktiviert wird. Es wird entsprechend der Graph Scan IR oder Scan DR (siehe Abbildung 3) beschritten. Im Falle eines Datenregisters basiert die weitere Auswahl auf dem aktuell im Befehlsregister befindlichen Betriebsmode (siehe Tabelle 1). In den folgenden Kapiteln wird das beschriebene Verhalten näher erläutert

5 2.2 Der TAP Controller Der TAP Controller ist verantwortlich für die komplette Steuerung der Boundary Scan Logik im Baustein. Das heißt, er ist unter anderem dafür verantwortlich, ob eine Boundary Scan Zelle (siehe Kapitel 2.5 Die Boundary Scan Zelle) aktiviert bzw. deaktiviert wird und ob diese messen oder treiben soll. Herzstück des TAP Controllers ist die TAP state machine. Die darin enthaltenen Zustände haben einen unterschiedlichen Einfluss auf die Steuerung der internen Boundary Scan Logik. Am besten lässt sich dies im Zusammenspiel mit der Boundary Scan Zelle erklären, siehe 2.6 Wie alles zusammenspielt. Abb. 3 TAP controller state diagram Abbildung 3 zeigt das im Standard definierte TAP controller state diagram. Gut zu erkennen sind die beiden nahezu identische Graphen Scan DR und Scan IR. So muss Scan DR beschritten werden, um ein Datenregister anzusprechen, und Scan DR für das Setzen eines neuen Befehls. Die Arbeitsweise beider Graphen ist absolut identisch. Der Wechsel von einem Zustand des TAP Controllers in einen anderen erfolgt über die steigende Flanke am Test Clock. Ein Zustand kann immer auf zwei Wegen verlassen werden. Entscheidend hierfür ist, welchen Pegel das Test Mode Select Signal zu diesem Zeitpunkt hat. Als Beispiel kann der Testlogic Reset (TL Reset) Zustand nur verlassen - 5 -

6 werden, wenn das TMS Signal bei der steigenden TCK Flanke gleich 0, also Low ist. Dann wäre der nächste Zustand Run Test / Idle (RT / Idle). 2.3 Das Befehlsregister Das Befehlsregister ( Instruction register ) entscheidet über den Betriebsmode des Boundary Scan Bausteins, der wiederum Einfluss auf die Steuerung der Boundary Scan Zellen wie auch auf die Auswahl des aktuell in die Scankette (Register zwischen TDI und TDO) geschalteten Datenregisters hat. Der Standard IEEE definiert drei zwingend erforderliche Befehle: - BYPASS - SAMPLE/PRELOAD - EXTEST Zusätzliche Befehle sind erlaubt. Als Beispiel seien an dieser Stelle die häufig anzufindenden Befehle IDCODE und HIGHZ zu nennen. In der folgenden Tabelle soll der Einfluss der Befehle auf das aktuelle Datenregister wie auch auf die Boundary Scan Zellen verdeutlicht werden. Die verschiedenen Datenregister sind im Kapitel 2.4 Die Datenregister näher erklärt. Betriebsmode/Befehl gewähltes Datenregister Verhalten der Boundary Scan Zellen BYPASS bypass Inaktiv SAMPLE/PRELOAD boundary-scan Inaktiv EXTEST boundary-scan Aktiv IDCODE idcode Inaktiv HIGHZ bypass TriState Tabelle 1 Einfluss des Betriebsmode auf Datenregister und Boundary Scan Zelle Jedem Befehl ist ein entsprechender Befehlscode (Bitcode) hinterlegt. Dieser kann von jedem Chip Hersteller frei definiert werden (ausgenommen ist der BYPASS Befehl er muss sich vollständig aus Einsen zusammensetzen). Auch die Länge des Befehlsregisters ist beliebig wählbar. Eine beispielhafte Zuordnung stellt Tabelle 2 dar. Dabei wurde die Länge des Befehlsregisters auf zwei Bit definiert

7 Betriebsmode/Befehl Befehlscode (binär) BYPASS 11 SAMPLE/PRELOAD 01 EXTEST 00 Tabelle 2 Beispiel für eine Befehlsregister Definition 2.4 Die Datenregister In einem Boundary Scan-fähigen Baustein können mehrere Datenregister enthalten sein. Sie dienen dazu, Informationen im Baustein abzulegen oder auch daraus auszulesen. Der Standard IEEE beschreibt im Minimum zwei zwingend notwendige Datenregister: - bypass - boundary-scan Auch hier sind wieder zusätzliche Register möglich, wie das device identification oder umgangssprachlich auch idcode Register. Das bypass Register stellt dabei die Möglichkeit dar, den Baustein aus einem Verbund von Boundary Scan Bausteinen zu lösen, sprich diesen zu umfahren ( bypass ). Das Register hat dazu eine minimale Länge von nur einem Bit. Der Wert des Bits ist unveränderlich und mit 0 definiert. Das für ein späteres Testen wesentlich interessantere Datenregister ist jedoch das boundary-scan Register, soweit es die Aneinanderreihung der einzelnen Boundary Scan Zellen darstellt. Da jeder Chip eine andere Anzahl an Boundary Scan Zellen besitzt, ist die Länge dieses Registers variabel. Im folgenden Kapitel wird die Boundary Scan Zelle detailliert beschrieben. 2.5 Die Boundary Scan Zelle Die Boundary Scan Zelle ist der Hauptbestandteil des Boundary Scan Testverfahrens. Alle bisher beschriebenen Konstrukte dienen ausnahmslos der korrekten Ansteuerung der einzelnen Boundary Scan Zellen. Die Boundary Scan Zelle ist die geniale Möglichkeit, den Bauteilpin eines Bausteins gelöst von dessen normaler Funktion zu kontrollieren, d.h. einen bestimmten Pegel zu treiben oder auch zu messen. Zu diesem Zweck befindet sich die Boundary Scan Zelle zwischen der - 7 -

8 Kernlogik des Bausteins und dessen Peripherie (Ausgangstreiber, Eingangstreiber); siehe Abbildung 2. Aufgrund der funktionellen Ähnlichkeit zu den physischen Antastnadeln ( nails ) des In-Circuit Testverfahren, welche dort den Zugriff auf die einzelnen Testpunkte realisieren, spricht man bei den Boundary Scan Zellen auch von electronic nails. Eine Boundary Scan Zelle kann immer nur EINE der folgenden Funktionen übernehmen: - Aktivieren/ deaktivieren des Treibers Steuerzelle ( control ) - Vorgabe des zu treibenden Pegels Ausgangszelle ( output ) - Messen des Pegels Eingangszelle ( input ) Abb. 4 Verschiedene Anordnungen von Boundary Scan Zellen Damit trotzdem an einem Bauteilpin getrieben und auch gemessen werden kann, befinden sich in aller Regel mehrere (bis zu drei) Boundary Scan Zellen an einem einzigen Bauteilpin. In Abbildung 4 stellen die Boundary Scan Zellen 45, 46 und 47 ein solches in der Praxis sehr häufig anzutreffendes Konstrukt dar. Aus diesem Grund ist es auch nicht verwunderlich, dass es oft mehr Boundary Scan Zellen als Bauteilpins gibt. Der interne Aufbau einer einzelnen Boundary Scan Zelle kann sich sehr unterschiedlich gestalten. Der Standard IEEE beschreibt in der Fassung 2001 allein zehn unterschiedliche Zell Typen (BC_1 bis BC_10). Eigene Strukturen sind zusätzlich möglich. Der Aufbau ist oft sehr ähnlich. Dies soll nun anhand des im Standard beschriebenen Typs BC_1 in der Funktion als Ausgangszelle näher erläutert werden: - 8 -

9 Abb. 5 Boundary Scan Zelle vom Typ BC_1 als Ausgangszelle Die BC_1 Zelle besteht zunächst aus zwei D-FlipFlops, welche beide von der TAP state machine (Signal Clock DR und Update DR ) getriggert werden. Die BC_1 Zelle kann also zwei Werte speichern, den Capture Wert und den Update Wert. Der linke Multiplexer wird ebenfalls von der TAP state machine (dem Signal Shift DR ) gesteuert. Je nach Pegel des Shift DR Signals liegt am Eingang des Clock DR FlipFlops der Pegel aus der inneren Logik des Bausteins oder der Capture Wert der vorherigen Zelle an. Der rechte Multiplexer hingegen wird vom aktuellen Betriebsmode des Boundary Scan Bausteins gesteuert. Handelt es sich beim aktuellen Befehl etwa um EXTEST, wird der Multiplexer auf den unteren Eingang geschaltet. Hierdurch wird die Kernlogik vom Bauteilpin gelöst, und der Update Wert allein ist verantwortlich für den getriebenen Pegel. Man spricht dann davon, dass die Boundary Scan Zelle aktiv ist. 2.6 Wie alles zusammenspielt Zum besseren Verständnis der bisher gewonnenen Erkenntnisse soll nun ein Beispiel dienen. Erklärt wird der Ablauf eines Schiebe -Vorgangs zum Zweck des Messens und Treibens von Pegeln an einem Bauteilpin. Vorausgesetzt wird, dass sich der betreffende Baustein im Betriebsmode EXTESTund die TAP state machine im Zustand Run Test/ Idle befindet

10 Letztlich muss einmal der Graph Scan DR durchlaufen werden, da der Wert einer Boundary Scan Zelle geändert werden soll und es sich bei dem boundary-scan Register um ein Datenregister handelt. Zunächst wird in den Select DR Zustand gewechselt, um dann mit der nächsten steigenden TCK Flanke in den Capture DR Zustand zu gelangen. Mit dieser steigenden TCK Flanke wird ebenfalls ein Impuls am Signal Clock DR erzeugt. Das Signal ist mit dem Capture FlipFlop der Boundary Scan Zelle verbunden. Dieses FlipFlop wird dazu veranlasst, den an seinem Eingang befindlichen Pegel zum Ausgang zu übernehmen, d.h. zu speichern. Es wird gemessen. Das Clock DR Signal liegt an allen Boundary Scan Zellen parallel an. Dies führt dazu, dass sämtliche Boundary Scan Zellen aller Bausteine (TCK und TMS liegen an allen Bausteinen parallel an) zu einem Zeitpunkt, also synchron(!) geschaltet werden. Mit dem Capture DR erhält man somit den Zustand einer ganzen Baugruppe, eines ganzen Systems zu einem bestimmten Zeitpunkt. Nun müssen die eben gemessenen Daten ausgelesen werden. Hierzu dient der nächste TAP Zustand: Shift DR. Dieser veranlasst einen Pegelwechsel des Signals Shift DR und somit ein Umschalten des linken Multiplexers der Boundary Scan Zelle auf den Capture Wert der vorigen Zelle. Da es sich auch bei diesem Signal um ein Broadcast Signal handelt, werden somit alle Boundary Scan Zellen miteinander zum boundary-scan Register verschaltet (in Abbildung 5 ist dieses durch die gestrichelte blaue Linie dargestellt). Der Eingang der letzten Zelle wird auf TDI des Bausteins geschaltet, und der Ausgang der ersten Zelle auf TDO. Der Capture Wert der ersten Zelle (Zelle 0) wird somit am TDO des Bausteins ausgegeben und kann von einem daran angeschlossenen Testsystem ausgelesen werden. Mit der nächsten steigenden TCK Flanke wird ein Impuls auf dem Clock DR Signal erzeugt, wodurch das Capture FlipFlop geschaltet wird. Jede Boundary Scan Zelle übernimmt somit den Capture Wert der vorherigen. Einzige Ausnahme bildet die letzte Zelle, da ihr Eingang mit dem TDI der Baugruppe verschaltet wurde. Ein daran angeschlossenes Testsystem kann also den Pegel vorgeben, der in den Capture Wert der letzten Zelle gespeichert werden soll. Mit der nächsten fallenden TCK Flanke beginnt der Vorgang von vorn. Da dabei die Bits von Zelle zu Zelle geschoben werden, spricht man hier vom Schieben. Das Schieben endet, indem das TMS Signal auf 1 wechselt, wodurch der Shift DR Zustand wieder verlassen wird und der linke Multiplexer aller Boundary Scan Zellen zurück auf den oberen Eingang schaltet. Der TAP Zustand ist nun Exit1 DR. Dies ist wieder nur eine Verzweigungsmöglichkeit

11 Der nächste wichtige Zustand ist Update DR. Die nächste fallende TCK Flanke nach Erreichen dieses Zustandes erzeugt einen Impuls auf dem Broadcast Signal Update DR und führt zu einem Schalten des Capture FlipFlops der Boundary Scan Zelle. Somit wird der Capture Wert zum Update Wert übernommen. Da der rechte Multiplexer auf diesen Wert geschaltet ist (der aktuelle Betriebsmode ist EXTEST) wird das zuvor im Capture und nun im Update Wert gespeicherte Bit am Bauteilpin getrieben (sofern die Boundary Scan Zelle eine Ausgangszelle ist). Mit der nächsten steigenden Flanke am TCK gelangt man wieder in den Ausgangszustand Run Test / Idle. Kurz zusammengefasst kann der Ablauf wie folgt beschrieben werden: 1. Messen 2. Ausschieben der Messergebnisse bei gleichzeitigem Einschieben neuer zu treibender Testvektoren 3. Treiben der neuen Testvektoren 2.7 Die Boundary Scan Description Language (BSDL) Jeder Boundary Scan-fähige Baustein hat seine ganz spezielle Boundary Scan Struktur, ohne deren Kenntnis ein Testingenieur bzw. eine Testsoftware nicht in der Lage wäre, sinnvoll mit dem Baustein zu arbeiten. Der Standard IEEE schreibt zwar einiges zwingend vor, lässt aber auch genügend Freiräume für Individualität. Die ist auch notwendig, was gerade am Beispiel der Struktur/Anzahl der Boundary Scan Zellen deutlich wird: Ein Baustein mit 20 Anschlusspins verfügt sinnvollerweise über eine geringere Anzahl an Zellen verglichen mit einem Baustein mit Pins. Um diese Individualität zu beschreiben, wurde die Boundary Scan Description Language (BSDL) entwickelt. Sie ist das Verständigungsmedium zwischen Chip-Hersteller (der allein das Innenleben seines Chips kennen kann) und dem Testingenieur (der dieses Innenleben in seinem speziellen Einsatzfall verwenden möchte). Es handelt sich dabei um eine Datei

12 Da eine vollständige Beschreibung der Sprache weit über das Ziel dieses Dokuments hinausgehen würde, soll nur kurz der Inhalt einer typischen BSDL Datei umrissen werden. So findet man in u.a. Angaben über: - verfügbare Testbussignale (insbesondere Angaben über das Vorhandensein des optionalen /TRST Signals und auch zur maximalen TCK Frequenz, bis zu welcher der Baustein betrieben werden kann) - mögliche Compliance Pins (siehe Kapitel 5. 1 Compliance Pattern) - das Befehlsregister (verfügbare Befehle inkl. deren Bitcode; Länge des Befehlsregisters) - die Datenregister (verfügbare Datenregister inkl. möglicher voreingestellter Werte, z.b. IDCODE des Bausteins) - die Struktur der Boundary Scan Zellen (Anzahl, Typ, Funktion, Zuordnung zum Bauteilpin)

13 3 Der statische, digitale Verbindungstest Dieses Kapitel beschreibt, wie man die bisher gewonnenen Erkenntnisse dazu benutzen kann, eine Verbindung zwischen zwei Boundary Scan Bausteinen zu testen, was einen der wichtigsten Anwendungsfälle des Boundary Scan Verfahrens darstellt. 3.1 Schritt 1: Betriebsmode SAMPLE/PRELOAD Abb. 6 Beispielschaltung nach dem Einschalten; die Boundary Scan Zellen sind inaktiv und nicht in die Scankette geschaltet Als Ausgangspunkt soll Abbildung 6 dienen. Daraus ist die zu testende elektrische Verbindung zwischen dem Pin AB2 des Bausteins U1 und dem Pin 15 des Bausteins U2 erkennbar. Weiterhin sind zu erkennen: die Steuerzelle 5, die Ausgangszelle 6 und die Eingangszelle 7 am Bauteilpin AB2 des U1. Die Steuerzelle 5 ist im gewählten Beispiel High aktiv, d.h. der Treiber des Pins AB2 ist nur aktiv, wenn die Steuerzelle mit 1 geladen ist. U2 soll sich in dem Beispiel gleich U1 verhalten. Beim Einschalten der Baugruppe befinden sich die Boundary Scan Bausteine im BYPASS Mode, d.h., die Boundary Scan Zellen sind inaktiv, und der Baustein arbeitet normal, was bedeutet, dass die Pegel an den Bauteilpins durch die Kernlogik vorgegeben werden (siehe Abbildung 6). Würde man jetzt sofort in den Testmode, sprich EXTEST umschalten, könnte das verheerende Folgen für die Baugruppe mit sich bringen. Der Inhalt der Boundary Scan Zellen ist zu diesem Zeitpunkt noch völlig unbestimmt. Somit ist das auch das Verhalten der Bauteilpins nicht vorhersehbar. Aus diesem Grund müssen die Boundary Scan Zellen zunächst mit Werten vorgeladen werden. Im BYPASS Mode hat man jedoch keinen Zugriff

14 auf die Boundary Scan Zellen, da sich diese im boundary-scan Register befinden und das aktuelle Datenregister das bypass Register ist. Es muss also zunächst der Betriebsmode eingestellt werden, der auf der einen Seite das boundary-scan Register aktiviert aber auf der anderen Seite die einzelnen Boundary Scan Zellen deaktiviert lässt; der SAMPLE/PRELOAD (siehe Tabelle 1). 3.2 Schritt 2: Boundary Scan Zellen vorladen Abb. 7 Beispielschaltung nach dem SAMPLE/PRELAOD; die Boundary Scan Zellen sind weiter inaktiv, aber nun in die Scankette geschaltet Nach Schritt 1 können die Boundary Scan Zellen mit den gewünschten Werten vorgeladen werden. Im ersten Testvektor soll Bauteilpin AB2 von U1 mit High getrieben werden. Es muss also die Steuerzelle 5 mit 1 und die Ausgangszelle 6 mit 1 geladen werden und, ganz wichtig(!), die Steuerzelle 46 von U2 muss auf 0 gesetzt werden. Andernfalls würden die zwei Ausgangstreiber der beiden Bausteine aufeinander treiben.das kann unter Umständen zu einem unerwünschten Ereignis führen. Schritt 3: Betriebsmode EXTEST Der gewünschte, sichere(!) Testvektor befindet sich nun in den einzelnen Boundary Scan Zellen (siehe nebenstehende Abbildung). Sie sind jedoch noch nicht wirksam, da sich die beiden Boundary Scan Bausteine noch im Betriebsmode SAMPLE/PRELOAD befinden und dieser die Boundary Scan Zellen nicht aktiv schaltet

15 Abb. 8 Beispielschaltung mit vorgeladenen Boundary Scan Zellen Dies wird nun durch Einschieben des EXTEST Befehls geändert. Mit dem Einschieben des Befehls wird die Kernlogik der beiden Boundary Scan Bausteine von den Bauteilpins abgekoppelt, und die Boundary Scan Zellen werden zugeschaltet. Im Beispiel wird nun Pin AB2 von U1 ein High auf die Verbindung treiben und Pin 15 von U2 in TriState geschaltet. Messen können beide Eingangszellen (Zelle 7 von U1 und Zelle 48 von U2). 3.3 Schritt 4: Testvektoren abarbeiten Abb. 9 Beispielschaltung im EXTEST mit dem ersten Testvektor Um eine Aussage über die Qualität der elektrischen Verbindung zwischen den beiden Bauteilpins fällen zu können, muss nun der im vorigen Schritt angelegte High Pegel überprüft werden. Hierzu muss nichts anderes als ein Scan DR durchgeführt werden. Da das aktuell eingestellte Datenregister das boundary-scan Register ist, erfolgt gemäß der im Standard beschriebenen Abfolge ein Messen Schieben Treiben an den Boundary Scan Zellen. Dies betrifft natürlich auch die Eingangszelle 48 des Bausteins U2. Somit wird der vom Pin AB2 des Bausteins U1 getriebene Pegel am Pin 15 des Bausteins U2 überprüft und

16 ermöglicht es damit, eine Aussage über den Zustand der elektrischen Verbindung zwischen diesen beiden Pins zu fällen. Mit dem Ausschieben der Messwerte werden gleichzeitig auch neue Werte eingeschoben, welche nach dem Durchlauf des Scan DR Graphen in den einzelnen Boundary Scan Zellen gültig werden. Hier empfiehlt es sich aus Optimierungsgründen, auch immer gleich den nächsten Testvektor zu verwenden. Man schiebt also immer die Messwerte des aktuellen Testvektors aus und die Treibwerte des nächsten Testvektors ein. Das Datenregister Schieben wird nun solange durchgeführt bis alle Testvektoren abgearbeitet sind. Ein spezielles Ausschaltregime gibt es dann nicht. 3.4 Was ist machbar, und wo liegen die Grenzen? Der statische, digitale Verbindungstest nach Standard IEEE ermöglicht alles, was im digitalen Bereich liegt und zeitunkritisch ist. So können Widerstände auf ihre Anwesenheit, Quarze, Treiber-Bausteine, Logik-Gatter, Reset-Bausteine und sogar RAM-Bausteine, Flash- Bausteine (parallele wie auch serielle) getestet werden eben alles, was digital möglich ist. Bei Letzteren werden zum Beispiel einfach die notwendigen Schreib- und Leseprotokolle über die Pins des Boundary Scan Bausteins nachgeahmt. Und dies ist auch die Limitation des Testverfahrens: die maximal mögliche Schalt-/ Messfrequenz an den Bauteilpins. Diese ergibt sich aus der Anzahl der Boundary Scan Zellen (also der Länge des boundary-scan Registers) sowie der Test Clock Frequenz. Dabei ist es egal, ob der Signalpegel nur eines oder mehrerer Bauteilpins geändert werden soll; in jedem Fall muss immer durch ALLE Zellen geschoben werden. Bei einem mittelgroßen, Boundary Scan-fähigen Baustein mit 500 Boundary Scan-Zellen und einer typischen TCK Frequenz von 10 MHz ergibt sich so eine Dauer von 50 µs für einen Schiebevorgang. Mit einem Schiebevorgang kann allerdings nur ein einziger Signalwechsel am Bausteinpin ausgelöst werden. Für die entgegengesetzte Flanke wird ein weiterer Schiebevorgang benötigt, wodurch sich eine maximal erreichbare Frequenz am Bausteinpin von 100 µs -1, also 10kHz ergibt. Somit ist klar, dass mit Boundary Scan ein Quarz zwar dahingehend überprüft werden kann, ob er schwingt, aber nicht mit welcher Frequenz. Auch können keine Ethernet Protokolle nachgeahmt werden oder ähnliches. Dieser Anspruch wurde mit dem Standard IEEE allerdings auch nie gesetzt. Es handelt sich ausschließlich um einen statischen, digitalen Verbindungstest

17 4 Was können moderne Tools? Nach den Erkenntnissen der beiden vorigen Kapitel und insbesondere des Kapitels 3 Der statische, digitale Verbindungstest ergeben sich einige Grundansprüche an ein Boundary Scan Testsystem. So möchte sich ein Anwender keine Gedanken über das richtige Schalten des Test Mode Select Signals machen, um in den richtigen Graphen in der TAP state machine zu kommen. Und er möchte sich bestimmt ganz und gar nicht mit einer TAP state machine herumplagen. Allenfalls möchte er den Betriebsmode für die Boundary Scan Bausteine vorgeben, mehr aber nicht. Glücklicherweise werden einem diese lästigen Arbeiten von modernen Tools tatsächlich abgenommen. Aber was ist überhaupt gemeint, wenn man über ein Boundary Scan Tool spricht? Ein Boundary Scan Testsystem besteht immer aus Hardware und Software. Die Hardware muss dabei einfach nur in der Lage sein, die TAP Signale anzusteuern. Diese Grundfunktionalität hat jede Boundary Scan Hardware weltweit (es gibt allerdings zum Teil gravierende Unterschiede in der Performance, also echten Durchsatz, und der Flexibilität). Die tatsächlichen Unterschiede gibt es in der Software, und deshalb ist in aller Regel die Software gemeint, wenn man über ein Boundary Scan Tool spricht. Was darf man also von einer modernen Boundary Scan Software erwarten? Natürlich, dass sie die notwendigen Testvektoren automatisch erzeugt und den Operator im Prüffeld im Fehlerfall möglichst einfach zur fehlerhaften Stelle des Prüflings führt, also eine bestmögliche Diagnose. Denkt man jedoch an die Integration des Boundary Scan Tests in die Fertigungslinie oder in ein anderes Testsystem, so ergibt sich der Anspruch, dass ein modernes Boundary Scan Tool über entsprechende Schnittstellen verfügt. 4.1 Automatische Testvektor Generierung Moderne Boundary Scan Tools verfügen über leistungsfähige Automated test pattern generators (ATPG). Diese benötigen lediglich den Schaltplan des Prüflings sowie intelligente Bauteilmodelle, um daraus sichere Testvektoren mit einer optimalen Testabdeckung zu erzeugen. Der Schlüssel liegt dabei in den Bauteil Modellen. Diese umfassen in vielen Fällen nicht mehr nur die Boundary Scan-fähigen Bausteine (die BSDL Dateien), sondern auch die nicht scanfähigen. Gerade diese machen jedoch den alles entscheidenden Unterschied aus

18 Sie enthalten Informationen darüber, mit welchem Pegel an welchem Bauteilpin man einen Treiber Baustein aktivieren/ deaktivieren oder dessen Richtung schalten kann. Sie enthalten die Protokolle für den Zugriff auf Speicher- oder Kommunikationsbausteine und vieles mehr. Erst auf dieser Basis können die ATPGs ihre vollen Fähigkeiten entfalten. Sie generieren per Knopfdruck Testvektoren unter anderem: - um Verbindungen durch Treiber-Bausteine hindurch testen zu können - um Verbindungen zu RAM-Bausteinen zu testen - um Flashes /EEPROMS (mit parallelem oder seriellem Interface) zu programmieren und/ oder auslesen zu können 4.2 Pin genaue Fehlerdiagnose So wichtig wie für den Testentwickler ausgereifte ATPGs sind, so wichtig sind für die Testperson in der Fertigung die Diagnose-Werkzeuge. Erwartet man ein dem In-Circuit Test ähnliches, auf Bauteilen basierendes Fehlerprotokoll, wird man wohl eher enttäuscht werden, denn bei Boundary Scan werden Netze getestet. Es handelt sich also im Gegensatz zum In- Circuit Test um ein auf Netzen basierendes Testverfahren. Damit wird sich eine Fehleraussage in erster Linie immer auf ein Netz beziehen. Allerdings darf man auch weit mehr erwarten als die weitläufig bekannten und äußerst abschreckenden Auflistungen von Testvektoren mit gekennzeichneten fehlerhaften Bits. Moderne Diagnose Werkzeuge bemühen sich um eine möglichst detaillierte Auflistung des Fehlers. Soweit das möglich ist (bei Stuck-At, Short und teilweise auch bei Open Fehlern) werden die beteiligten Netze inkl. aller daran angeschlossenen Bauteilpins protokolliert. Abb. 10 Abb. 11 Beispiel für ein Fehlerprotokoll Beispiel für Fehlervisualisierung im Layout

19 Das man solch ein Protokoll auch im Layout der Baugruppe visualisieren kann ist heutzutage selbstverständlich (siehe Abbildung 11). 4.3 Schnittstellen zur Systemintegration Das Thema der Kombination verschiedener Testsysteme gewinnt mehr und mehr an Bedeutung. JTAG/Boundary Scan eignet sich aufgrund seiner kompakten Abmessungen und seiner geringen Anforderungen an den Prüfling (nur vier TAP Signale müssen verdrahtet werden) wie kaum ein anderes Testverfahren zur Integration. Diesem Trend folgend, verfügen moderne Boundary Scan Tools über zahlreiche Schnittstellen zur Einbettung in die verschiedensten Testsysteme. Die Schnittstellen ermöglichen zumindest den Aufruf fertig generierter Boundary Scan Tests (also einer Ansammlung von Testvektoren). Höherwertigere Tools bieten die Möglichkeit, Testvektoren synchron zu einem anderen Testsystem auszuführen. Diese Eigenschaft wird insbesondere bei der Integration von Boundary Scan in einen In-Circuit bzw. Flying Probe Tester benötigt. So legt das eine Testsystem Testvektoren an, teilt dies dem anderen Testsystem über die Schnittstelle mit, welches daraufhin den anliegenden Testvektor überprüfen kann. Das derzeitige High-End ist die dynamische Testvektorgenerierung. Über solch eine Schnittstelle können die Testvektoren eines fertig generierten Tests nachträglich, ergo zur Laufzeit, den aktuellen Gegebenheiten angepasst werden. 4.4 Was noch? Moderne Boundary Scan Tools basieren auf einer Skript Sprache. Diese ermöglicht es, mit einfachen Befehlen komplexe Boundary Scan Operationen auszuführen (Beispiele sind Scan DR oder Scan IR ). Aber auch der Zugriff auf eine einzelne Boundary Scan Zelle ist mit solch einem Skript machbar, bis herunter auf die Bit Ebene. Dies ist gerade dann von Vorteil, wenn sich der eingesetzte Boundary Scan Baustein nicht 100%ig standardkonform verhält oder die gelieferte BSDL Datei fehlerhaft ist. Ein weiterer Vorteil solch einer Skript Sprache liegt in der Fähigkeit, diese debuggen zu können. Somit kann zu jedem Zeitpunkt eines Tests genau überprüft werden, welche Testvektoren vom ATPG erzeugt wurden. Damit ist es auf eine sehr elegant Art und Weise möglich, eventuell nicht berücksichtigte Konflikte auf dem Prüfling zu erkennen und zu beheben. Ein vollständig integrierter Debugger ist hierfür die Voraussetzung

20 5 Design For Testability (DFT) Die besten Boundary Scan Testsysteme mit den mächtigsten ATPGs können nichts ausrichten, wenn gewisse Design Regeln nicht schon beim Schaltplanentwurf oder noch einen Schritt eher bei der Bauteilauswahl eingehalten wurden. Das folgende Kapitel versteht sich dabei als Anhaltspunkt für ein erstes Boundary Scan Design. Jedoch werden im Folgenden offensichtliche Design For Testability Regeln nicht aufgeführt. Beispielhaft sei der bevorzugte Einsatz von Bausteinen mit Boundary Scan Logik und die Notwendigkeit einer Testbusverdrahtung aufgeführt. Solche Regeln ergeben sich zudem aus dem oben beschriebenen Standard IEEE Anschließend wird eine begrenzte Auswahl der wohl wichtigsten Design For Testabilty Regeln dargelegt. 5.1 Compliance Pattern Bei Boundary Scan-fähigen Bausteinen ist es üblich, sich die TAP Pins mit anderen Funktionen z.b. zum Debuggen zu teilen. Aus diesem Grund verfügt ein solcher Baustein in aller Regel über einen Pin, der über den Zweck entscheidet. Solch ein Pin könnte z.b. JTAG#/DEBUG heißen und würde bei einem High den Debug Mode aktivieren. In diesem Beispiel muss also zwingend ein Low am Pin angelegt werden, damit dieser mit Boundary Scan getestet werden kann. Solche Dinge sind als Compliance Pattern in der BSDL Datei beschrieben (siehe Kapitel 2.7 Die Boundary Scan Description Language (BSDL)) und müssen, sofern man mit Boundary Scan testen möchte, zwingend eingehalten werden. 5.2 Testbusabschluss Für eine schnelle Testabarbeitung ist ein guter Testbusabschluss unerlässlich. Als groben Anhaltspunkt kann man davon ausgehen, dass die Testzeit sich direkt proportional zur Frequenz des Test Clock verhält. Moderne Testsysteme sind in der Lage das TCK Signal mit 80 oder gar 100 MHz zu betreiben. Dies zeigt, dass große Sorgfalt bei der Verdrahtung der TAP Signale angebracht ist