JTAG ist mehr als nur ein Port zum Test von Chips Peter van den Eijnden, JTAG Technologies, Eindhoven

Das Akronym JTAG steht für die Joint Test Action Group, die ursprünglich nach neuen Möglichkeiten für den Test elektronischer Schaltungen suchte. Die Gruppe traf sich von 1985 bis 1990 und entwickelte Methoden zur Einbettung einer Testschaltung in digitale Bauteile. Das Verfahren unterstützt einen strukturellen Test von Baugruppen, auf denen derartige Bauteile implementiert sind.

Die Struktur von JTAG als Testport ist heute umfassend dokumentiert und weit verbreitet und seit 1990 ist JTAG auch ein IEEE-Standard (1149.1). Bis heute wurden viele Artikel über die Vorzüge dieser Testlösung veröffentlicht, besonders von den inzwischen zahlreich am Markt vertretenen Anbietern von Testsoftware. Mittlerweile wurde auch eine Reihe von alternativen Anwendungen für ‚JTAG‘ entwickelt, wie für das Debugging und die Programmierung. Die Verwendung des JTAG Ports für das Debugging geht auf die frühen 90er Jahre zurück. Damals erkannten TI und die junge ARM Ltd., dass mit dieser Schnittstelle und einer Ablaufsteuereinheit nicht nur ein Zugriff auf die vom JTAG Komitee definierten IEEE 1149.1 Testregister, sondern auch auf die internen (Debug) Register möglich ist.

An diesem Punkt wäre es vielleicht sinnvoll gewesen, sich für dieses System einen eigenen Namen auszudenken, dem war aber nicht so. Dadurch gibt es heute neben ‚JTAG für Test‘ auch ‚JTAG für Debug‘, obwohl letzteres nicht als IEEE Standard definiert ist. Noch verwirrender wurde es, als Intel im Jahr 1993 eine Reihe von PLDs vorstellte (die bald an Altera verkauft wurden, um besser mit dem damaligen Marktführer AMD konkurrieren zu können). Diese Bauteile nutzten erstmals den JTAG Mechanismus für einen direkten Zugriff auf die Konfigurationsregister.

Damit gab es innerhalb von nur drei Jahren nach der formellen Einführung des Testports des JTAG Komitees zwei weitere wichtige Anwendungsbereiche: das Debugging von RISC/DSP-Prozessoren und die Programmierung von Bauteilen auf der Baugruppe (OBP – On-board Programming). Das OBP-Verfahren hat sich über die letzten Jahre stetig weiterentwickelt und bietet der Fertigung eine Reihe von Vorteilen.

Als im Jahr 1994 JTAG Technologies seine erste Anbieter-unabhängige OBP-Software vorstellte, war eine Programmierung über die JTAG-Schnittstelle nur bei einigen wenigen CPLDs von AMD (später Vantis) und Intel möglich. Lattice Semiconductor verwendete immer noch Bauteile auf der Basis des In-System-Programmierung (ISP) Protokolls und musste erst auf die JTAG Ablaufsteuereinheit migrieren. Es gab somit keine einheitlichen Softwarestandards und über viele Jahre wurde argumentiert, wessen System leistungsfähiger ist.

Erst als sich weitere Unternehmen (zum Beispiel Altera, Actel, Cypress und Xilinx) für den Einsatz von JTAG Ports zur Programmierung entschieden, kam Bewegung in die bislang große Zahl der Standards. Einige Anbieter übernahmen das etwas umfangreiche, aber einfache SVF (Serial Vector Format), das ursprünglich von TI, Tektronix und Teradyne zur Beschreibung von Testvektoren entwickelt wurde. Im Laufe der Zeit stellten die einzelnen IC-Hersteller unterschiedlichste Systeme als den jeweils nächsten OBP-‚Standard‘ vor, wie beispielsweise “XSVF” von Xilinx und “VirtualMachine” von Lattice. Jedoch wurde SVF nicht wirklich abgelöst.

Anfangs schlug Altera sein JAM und später dann sein STAPL (‘Standard’ Programming Language) Format als neuen Standard vor, aber wie man sich vorstellen kann, kam dies nicht gut bei den Konkurrenten an. Erst als das IEEE ein Machtwort sprach, setzten sich die führenden IC-Anbieter zusammen und zwar auch mit den Tool-Anbietern und gründeten eine Arbeitsgruppe zur Entwicklung eines harmonisierten Programmiersystems für CPLDs und andere Bauteile.

Im Jahr 1998 begann die IEEE 1532 Arbeitsgruppe mit der Entwicklung einer formellen Erweiterung des Boundary-Scan-Standard IEEE 1149.1. Das neue ISC (In-System Configuration) Format, wie es genannt wurde, basierte auf dem BSDL (Boundary-Scan Description Language) Bauteilmodell und verfügte über zusätzliche Standardbefehle und entsprechende Register.

Die Software-Tools erhalten die für eine Hardware-unabhängige Programmierung notwendigen Informationen aus den in jedem 1532-BSDL Modell enthaltenen Bauteil-spezifischen ‚Verfahren‘ und ‚Flows‘. In Verbindung mit dem neu definierten ISC Datenformat bietet der neue Standard zudem bislang nicht genutzte Möglichkeiten, wie: eine parallele Programmierung von Bauteilen verschiedener Anbieter und (in einigen Fällen) ein Austausch von Bauteilen durch Typen anderer Hersteller.

Das Produktspektrum von Actel, Altera, Atmel, Cypress, Lattice und Xilinx enthält inzwischen auch 1532-konforme PLDs, die nur wenig mehr oder gleich viel kosten als PLDs ohne derartige Funktionalität. Und JTAG ProVision von JTAG Technologies beinhaltet eine Standardfunktion zur gleichzeitigen Programmierung von IEEE 1532 Bauteilen unterschiedlicher Anbieter.

CPLDs und deren Varianten lassen sich durch den direkten Zugriff auf die Steuerregister innerhalb des Bauteils schnell programmieren. Aber was ist mit diskreten Flash-Bauteilen und seriellen PROMs? Vorausgesetzt diese Bauteile sind mit einem Boundary-Scan-konformen Bauteil verbunden, dann sind diese oftmals ‚indirekt‘ durch ein simuliertes Schreiben und Lesen des Speichers über die Boundary-Scan-Register programmierbar.

Durch die Erweiterung des Designs um zusätzliche Signale lässt sich der Overhead für die serielle Übertragung der Daten und die parallele Zwischenspeicherung an den Pins des “programmierenden Bauteils” reduzieren und somit der Durchsatz erhöhen. Diese Technik unterstützt auch serielle Kommunikationsprotokolle wie I2C und den SPI Bus, so dass JTAG/Boundary-Scan sich zu einer äußerst effektiven Methode bei kleineren (weniger als 1 MB) und mittelgroßen (zwischen 1 und 32 MB) Flash-Blöcken entwickelt hat.

Wenn zudem das IC-Design noch beeinflusst werden kann, dann lässt sich durch die Implementierung spezieller kurzer OBP-Ketten in den Halbleiter der Overhead der seriellen Übertragung weiter reduzieren. Diese kurzen Ketten sind nur für die Boundary-Scan-Zellen notwendig, die für die Programmierung des Zielbauteils genutzt werden, und können die Programmierzeiten bis zu einem Faktor zehn verkürzen. Wenn ein FPGA zur Programmierung verwendet wird, dann kann eine Pseudo-BSR (Boundary-Scan-Register) Scan-Kette vorläufig für die Flash-Programmierung konfiguriert, anschließend gelöscht und mit einem ‚Projektcode‘ neu für den Funktionstest programmiert werden.

Um den Nutzen der JTAG Schnittstelle weiter zu verbessern, erarbeitete eine spezielle Projektgruppe Lösungen zur Programmierung von Bauteilen mit unterschiedlichen Technologien, wie Mikroprozessoren mit embedded Flash, mit Hilfe von JTAG/Boundary-Scan. Obwohl diese Bauteile etwas von dem ‚echten‘ IEEE 1149.1 Standard abweichen, hat sich JTAG auch hier als eine effektive Möglichkeit zur On-Board-Programmierung erwiesen.

Ein Beispiel für eine vom Standard abweichende Schnittstelle findet sich bei den Mikrocontrollern der µPSD Serie von STMicro (ehemals WSI). In diesem Fall verfügen die Bauteile zwar über die richtigen TAP Pins, beinhalten aber eine Ablaufsteuerung, die nicht zu IEEE 1149.1 konform ist.

Die beliebte TI MSP 430 Serie ist ein weiteres Beispiel. Die Bauteile enthalten angeblich JTAG-Funktionen, verfügen aber nicht über Boundary-Scan-Register für den Test und weisen zudem eine andere interne Struktur auf, wodurch das Multiplexen eines zusätzlichen Taktsignals auf den TDI Pin erforderlich ist. Zu den anderen unterstützten Anbietern gehört beispielsweise Freescale mit den Automotive-Mikrocontrollern mit embedded Flash der Serie MPC5500.

Der Boundary-Scan-Testzugangsport (TAP) des JTAG Komitees wurde vor fast 20 Jahren entwickelt und sollte den Produktions-/Testingenieuren die Fehlersuche auf den zu dieser Zeit immer häufiger in SMT-Technologie hergestellten Baugruppen erleichtern. Seither sind immer mehr Anwendungsbereiche für diesen vielseitigen Port hinzugekommen und der Nutzen sowohl für die Design-, als auch die Test-Ingenieure konnte weiter verbessert werden. Während sich die Designer über einen kostengünstigen und einfachen Zugang zu den Debug-Registern der Mikroprozessoren freuen, erhalten die Test- und Fertigungsingenieure eine kostengünstige und vielseitige Lösung zur Bauteilprogrammierung. Damit lassen sich die Bauteile direkt auf der Baugruppe programmieren, zudem ist eine Kopplung mit den vorhandenen strukturellen Testern in der Fertigung möglich. Dies erlaubt eine Reduzierung der Kosten nicht nur für das Handling, sondern auch für die Vorabprogrammierung, eine mögliche Umprogrammierung und die Lagerung von vorprogrammierten Teilen.

SMT, Stand 7-540

EPP 503