JTAG/Boundary-Scan: Entwicklungsphasen und Zukunftsausblick

Vor nahezu 30 Jahren brachte eine grundlegende Veränderung beim Bauteil-Packaging (von der Durchsteck- zur Oberflächen-Montage) eine Gruppe gleichgesinnter Produktionstest-Ingenieure dazu, den Einfluss dieser Bauteile auf den Test der bevorstehenden SMT-Baugruppen zu untersuchen. Die Gruppe nannte sich JETAG oder Joint European Test Action Group und setzte sich zusammen aus Mitarbeitern von Philips, BT, GEC, Siemens, Plessey und weiteren Firmen. In den meisten Fällen kamen damals in der Mitte der 1980er Jahre entweder In-Circuit-Tester (ICT) für die Verifizierung einzelner Bauteile beziehungsweise der gesamten Baugruppe zum Einsatz, oder Funktionstester, die das Umfeld der Baugruppe nachbildeten, um den Prüfling zu stimulieren und seine Antwortsignale zu messen.

Mit dem Aufkommen der SMD-Technologie und höheren Integrationsgraden schränkte sich der Testzugriff der In-Circuit-Tester stark ein und die höheren Integrationsgrade sorgten dafür, dass sich Funktionstests zu immer längeren und mühsameren Prozessen entwickelten. In diesem technologischen Umfeld begann der JETAG-Arbeitskreis über ein Verfahren nachzudenken, wie sich Testfähigkeiten direkt in die Bauteile einbetten lassen. Schon nach kurzer Zeit gewann der Arbeitskreis verstärkt Mitglieder aus der „Neuen Welt“ dazu und aus JETAG wurde der JTAG-Arbeitskreis. Die Früchte ihrer Arbeit, der „Test Access Port“ und die „Boundary-Scan-Architektur“ beschrieben, wie ein serielles Scanregister digitale Signalpins eines Bauteils steuert, um Eingangssignale zu erfassen oder ein Ausgangssignal auf ein Pin des Bauteils auszugeben, während die reguläre Funktion des Bauteils ausgeblendet wurde. Support-Register (Befehlsregister, Bypassregister) und eine Zustandsmaschine (TAP-Controller) vervollständigten das Bild. Das System wurde dem IEEE vorgeschlagen. In einer Abstimmung verabschiedeten die Mitglieder des Arbeitskreises diese neue Richtlinie 1990 als IEEE 1149.1. Wenige Jahre später beschrieb IEEE Std 1149.1b (eine Ergänzung) eine präzise Syntax für die Bauteilbeschreibungssprache BSDL, die im Wesentlichen auf VHDL beruht.

Mit der Möglichkeit, die Boundary-Scan-Fähigkeiten eines individuellen Bauteils in BSDL zu beschreiben und gestützt auf die CAD-Daten, die die Verbindungen zwischen den Bauteilen eines Designs definieren, ließen sich automatische Testprogramm-Generatoren entwickeln, die Tests generieren, die alle möglichen Kurzschlüsse und Unterbrechungen der Verbindungen zwischen JTAG-fähigen Bauteilen zu 100 % erkennen. Einer der ersten Testprogramm-Generatoren von Philips Test and Measurement (später JTAG Technologies), der als BTPG_I (Boundary-Scan Test Program-Generator for Interconnects) bekannt wurde, schaffte die Grundlagen für 25 Jahre kontinuierlicher Entwicklung JTAG-orientierter und auf Standards basierter Test-Produkte.

25 Jahre kontinuierliche Entwicklung

Schon bald erkannten die Entwickler IEEE Std 1149.1-kompatibler Werkzeuge, dass der durch das Boundary-Scan-Register (BSR) realisierte Zugang auch genutzt werden konnte, Standard-Bauteile auf die gleiche Weise zu stimulieren, wie es sonst durch die I/O-Pins der In-Circuit-Tester geschah. Bereits nach kürzester Zeit simulierten die Werkzeuge über JTAG-Bauteile Schreib/Lesezyklen für Speicher wie SRAMs, FIFOs und DRAMs. Durch Anlegen sorgfältig gewählter Testmuster (Vektoren) erstellten die Ingenieure einen Test, der Unterbrechungen und Kurzschlüsse an den Signalleitungen zum/vom Memory-„Cluster“ erkennt. Ein hochentwickeltes Diagnose-Modell lieferte Fehlerbeschreibungen auf Pin-Ebene.

Der nächste wesentliche Entwicklungsschritt bei der Nutzbarmachung von JTAG für die Produktion war die Einführung programmierbarer Logik, die JTAG nicht nur als Zugriffsverfahren für Boundary-Scan-Eigenschaften nutzte. Über JTAG wurden Daten in Konfigurationsregister eingelesen, sodass die Bauteile im System programmiert werden konnten. Zu den ersten Halbleiter-Herstellern, die diese Funktionalität anboten, zählten Intel (bevor die PLD-Aktivitäten an Altera verkauft wurden), Xilinx und Altera. Lattice Semiconductor folgte kurze Zeit später mit einer Schnittstelle zur In-System-Programmierung nach, die jedoch nicht mit IEEE 1149.1 kompatibel war.

Es könnte argumentiert werden, dass die Möglichkeit, Bauteile im System zu programmieren, den Produktionsverantwortlichen so lukrativ erschien (schließlich bedeutete es weniger Investkosten, weniger Bauteilhandling und so weiter), dass die Erweiterung der Werkzeuge um die Möglichkeit, andere Bauteile wie FLASH-Speicher und serielle PROMs programmieren zu können, eigentlich zwangsläufig sei. Tatsächlich kam 1996 der erste automatische JTAG-gesteuerte Generator für die Flash-Programmierung mit High-Speed-Controller-Hardware auf den Markt. Flash-Imagedaten erreichten bereits ein Volumen von einigen Megabytes. JTAG Technologies verbesserte den Durchsatz dieser Systeme noch weiter und fügte der JTAG-Hardware eine zusätzliche Steuerleitung (Autowrite) hinzu, um das WE_-Signal des zu programmierenden Flash-Bauteils zu pulsen und so gegenüber dem Pulsen über das Boundary-Scan-Register zwei vollständige Schiebezyklen einzusparen. Autowrite ist heute eine Standardeigenschaft der Hochleistungs-Controllerfamilie Datablaster.

Der nächste Schritt entlang der Entwicklungskurve war die Einführung der produktionsorientierten PIP-Werkzeuge (Production Integration Package). Diese Optionsfamilie ermöglichte die Hochsprachensteuerung und Ausführung der Boundary-Scan-Anwendungen über gängige Testsoftwarepakete wie National Instruments Labview, Labwindows und Teststand, zusammen mit Visual-Basic, C(++) und .NET in späteren Jahren.

Entwicklung der analogen Variante

1999 konnte man die Entwicklung der analogen Variante des Standards (IEEE Std 1149.4) abschließen und etliche Produkte trafen auf einen zögerlichen Markt, auf dem sie ihre Plätze suchten. Der Standard an sich war übersichtlich genug. Neben den Zellen nach 1149.1 (Dot-1) (Digitale Boundary-Module DBMs) gibt es damit auch analoge Boundary-Module (ABMs). Die ABMs bestehen aus einem Schaltnetzwerk zwischen dem Pin und der Kernschaltung. Das analoge Pin kann in den Core-Disconnect-Zustand (CD) versetzt und so vom Schaltungskern isoliert und mit einem externen Signal, einer internen Gleichspannung oder dem internen analogen Testbus verbunden werden. Aus den beiden Signalen AT1 und AT2 besteht der interne analoge Testbus. In Verbindung mit den Signalen des herkömmlichen Dot-1-Test-Access-Ports bildet er den sogenannten ATAP (Analoger Test-Access-Port). Um auf die Eigenschaften der ABMs zugreifen zu können, fügt der 1149.4-Standard den in IEEE 1149.1 spezifizierten Befehlen einen weiteren hinzu. Die Anweisung „Probe“ erlaubt einen Echtzeit-Zugriff auf Signalpins, ohne den eigentlichen Betrieb zu beeinträchtigen. Ähnlich der „Sample/Preload“-Anweisung aus IEEE 1149.1 ermöglicht Probe ein „virtuelles Kontaktieren“ ausgewählter Pins eines ICs bei minimalem Einfluss auf deren normale Funktion. Leider haben sich die Mixed-Signal-Halbleiterhersteller nicht dazu entschlossen, 1149.4 im größeren Maßstab (wenn überhaupt) in ihre Bauteile zu integrieren, vermutlich wegen zu geringer ernsthafter Nachfrage seitens der Kunden. Und so kann, wie es immer ist, die Einführung eines Standards und selbst die Verfügbarkeit von Produkten, die diesen Standard unterstützen, die Akzeptanz des Standards nicht garantieren. Wenn eine alternative Technik zur Erreichung der gleichen Ziele vorhanden und ebenfalls kostengünstig ist und eine gewisse Trägheit des Marktes dazu kommt, wird jede neue Alternative von Anfang an zum Scheitern verurteilt sein.

Boundary-Scan Fault Coverage Examiner (BFCE)

Ein neuer Aspekt der Boundary-Scan-Technologie entwickelte sich etwa zeitgleich mit der Dot-4-Erweiterung. Hierbei handelt es sich um ein System, das für eine Baugruppe mit Boundary-Scan-fähigen Bauteilen sowie Clustern, die dem Boundary-Scan-Test zugänglich sind, die Fehlerabdeckung prognostiziert und bewertet. Das als Boundary-Scan Fault Coverage Examiner (BFCE) bekannt gewordene System liest Netzlistendaten, BSDL-Bauteilmodelle und weitere Modelldaten aktiver Bauteile ein und liefert eine auf den Bauteildaten basierende, optimierte Fehlerabdeckung einer Baugruppe, die mittels JTAG-/Boundary-Scan-Technik geprüft werden soll. Es beinhaltet auch einen Vergleichstest, der die tatsächliche Fehlerabdeckung mit dem prognostizierten Wert vergleicht. Dieses Werkzeug erlangte großen Erfolg, da es den Testingenieuren erlaubte, die Wirksamkeit der Boundary-Scan-Tests zu quantifizieren und zu erkennen, wann und wo die Testabdeckung mittels anderer Verfahren erhöht werden sollte.

Optimierte Fehlerabdeckung

Seit 2001 war der JTAG-Port die De-facto-Standardschnittstelle zur Programmierung von CPLDs und Konfigurierung von PROMs. Es gab jedoch keinen formalen Standard für die benutzten Datenformate oder die Befehle, die zur Programmierung eines oder mehrerer Bauteile erforderlich waren. Dies änderte sich im Laufe des Jahres, als eine Gruppe von JTAG-Anbietern und PLD-Lieferanten vom IEEE die Freigabe ihres ISC-Standards (In-System-Configuration) IEEE Std 1532 erhielt. Im Gegensatz zu anderen verbreiteten Programmierungsformaten wie SVF, hielt dieser Standard den Datenbereich (.ISC-Dateien) getrennt vom Programmierungsprotokoll, das jetzt in einem BSDL-Modell mit erweiterter Syntax eingebettet wurde. So können mehrere Bauteile, auch von verschiedenen Herstellern, in einer Scan-Kette verbunden sein und gleichzeitig programmiert werden, indem man ihre ISC-Dateien zusammenfügt. JTAG Technologies hat die ISC-Programmierung nach IEEE Std 1532 von Beginn an unterstützt – einschließlich der Funktion der gleichzeitigen Konfigurierung mehrerer Bauteile.

Der Erfolg oder Misserfolg von Test-Lösungen hängt häufig von dem Maß an Unterstützung ab, das ihnen zuteil wird. Das kann Unterstützung im Sinne von Beratung und Betreuung oder in Form von Support-Produkten bedeuten. Dieser Support macht es Anwendern leicht, JTAG-/Boundary-Scan in vorhandene Testkonzepte zu integrieren. Mit der Einführung der PIP-Tools stellte JTAG Technologies Werkzeuge zur Verfügung, die eine einfache Integration in zahlreiche weit verbreitete Test-Plattformen wie Labview, Labwindows, ATEasy, Teststand, Microsoft .NET und weitere  ermöglichte, um Funktionstester zu entwickeln.

Wandel in der Markterwartung

Mitte der 2000er Jahre vollzog sich ein Wandel in der Markterwartung bezüglich der Benutzerfreundlichkeit der JTAG-/Boundary-Scan-Testwerkzeuge. Während die enthusiastischen Früheinsteiger beim JTAG-/Boundary-Scan-Test Systemarchitekturen tolerierten, die einen erheblichen manuellen Eingriff durch Ingenieurleistungen benötigten, forderten diejenigen, die erst später dazu kamen, von ihren Werkzeugen höhere Automatisierung und bessere Benutzerfreundlichkeit. Pro-Vision von JTAG Technologies zählte zu diesen neuen Werkzeugen der „Zweiten Generation“, die weit weniger Benutzereingriffe benötigten und den Fokus auf wiederverwendbare Modelle setzten, um sichere Testbedingungen und Clustertestmöglichkeiten zu konfigurieren. Pro-Vision bot zum ersten Mal eine vereinheitlichte Umgebung an, die Boundary-Scan-Strukturtest, Cluster-Test (Speicherlogik und weitere) und die Programmierung von CPLDs, PROMs sowie NOR- und NAND-FLASH unterstützte. Der modulare Ansatz des Systems bedeutete darüber hinaus, dass weitere hinzugefügte Funktionen über „Plug-Ins“ die grundlegende Architektur des Systems nicht beeinträchtigten.

1999 konnte die Entwicklung der analogen Variante des Standards IEEE Std 1149.4 abgeschlossen werden. JTAG Technologies

Das erste Plug-In, das die Funktionalität von Pro-Vision erweitern sollte, bot eine Möglichkeit, AC-gekoppelte LVDS-Signale zu testen, die von einer Logik gesteuert wurden, die kompatibel zum neuesten Standard IEEE Std 1149-6 sind. (Aktivitäten zu 1149.5 lassen sich im Internet finden, die Standardisierungsaktivitäten hatten sich jedoch vollständig festgefahren).

IEEE 1149.6 ergänzt das BSDL-Modell um neue Instruktionen und die konformen Bauteile um neue Logik-Strukturen. In Dot-6-kompatiblen Bauteilen ist es möglich, zwei neue Befehle zu nutzen, um einen High-Speed-Puls (EXTEST_PULSE) oder eine Serie von Pulsen (EXTEST_TRAIN) über das zu testende Netzwerk auszulösen. Bild 3 zeigt eine Standard-1149.1-Boundary-Scan-Registerzelle (Ausgangstreiber), die erweitert wurde, um Dot-6 zu unterstützen. Es ist nötig, eine komplementäre Empfangsschaltung hinzuzufügen, die das Pulssignal wieder herstellt, nachdem es beim Durchgang durch die AC-Kopplung verzerrt wurde. Da die Umstellung von breiten, parallelen Bussen (zum Beispiel PCI) hin zu seriellen High-Speed-Verbindungen (zum Beispiel PCI-Express) in hoher Geschwindigkeit fortschreitet, ist zu erwarten, dass künftig mehr Bauteile das Dot-6-Testverfahren unterstützen.

Der nächste zu verabschiedende Standard war IEEE 1149.7, auch bekannt als CJTAG (Compact-JTAG oder Dot-7). Unter dieser Neuerung verbirgt sich mehr, als der Name vermuten lässt. Ursprünglich vorangetrieben von Halbleiter-Herstellern wie TI, ist Dot-7 ein Konglomerat verschiedener Funktionserweiterungen, zusammengefasst unter einem Standard. TIs eigene Wiki-Seite beschreibt die wesentlichen Vorteile von Dot-7 (insbesondere für Embedded-Designs) wie folgt:

• Die Fähigkeit, die Leistungsaufnahme der Debug-Logik gemäß Industriestandards zu steuern. Während IEEE 1149.1 (JTAG) nur den „EIN-Zustand“ kannte, bietet IEEE 1149.7 vier wählbare Leistungsstufen, um Ultra-Low-Power-Bauteile zu unterstützen.
• Die Fähigkeit, ein spezielles Bauteil in einem System mit mehreren Bauteilen direkt anzusprechen. Durch Implementierung eines Bypasses auf Systemebene ist die Scan-Kette erheblich kürzer, was die Effizienz des Debuggings spürbar verbessert.
• Die Einführung einer Sterntopologie ergänzt die serielle Standard-Struktur. Entwickler, die sich mit Stacked-Die-Aufbauten, Multichip-Modulen und Plug-In-Cards befassen, werden die Sterntopologie zu schätzen wissen, da sie die physikalischen Verbindungen zwischen Bauteilen vereinfacht.
• Zwei-Pin-Betrieb statt des herkömmlichen Vier-Pin-Betriebs, wie er in IEEE 1149.1 definiert wurde. Da die meisten der aktuellen Systeme mehrere ICs integrieren und häufig Platzprobleme haben, kommt ihnen die reduzierte Anzahl von Pins und Leiterbahnen entgegen, um Formfaktor-Ziele zu erreichen, weitere funktionale Pins und/oder verringerte Package-Kosten zu realisieren.
• Die Kompatibilität mit vorhandenen IEEE 1149.1 (JTAG) -Produkten sorgt für den Erhalt bereits getätigter Investitionen.

Es gibt insgesamt sechs Kompatibilitätsklassen mit Dot-7, allerdings zahlen nur die beiden höchsten Klassen dem Kompaktheitsaspekt Tribut, indem sie den Zweidraht-Betrieb unterstützen. Die folgende Zusammenfassung erläutert die wesentlichen Funktionsmerkmale der einzelnen Klassen:

• Class T0 – Stellt die IEEE-Kompatibilität für Chips mit mehreren TAPs sicher
• Class T1 – Ergänzt Steuerungsfunktionen (zum Beispiel funktioneller Reset, Power)
• Class T2 – Ergänzt Leistungsfeatures für serielle Konfigurationen
• Class T3 – Fügt die Sternkonfiguration hinzu

Zwei-Pin-Betrieb

• Class T4 – Ergänzt Zwei-Pin-Betrieb
• Class T5 – Ergänzt Zwei-Pin-Betrieb um Befehl/applikationsspezifische Pin-Benutzung

Bisher stützen relativ wenige, meist von TI entwickelte, Bauteile den Dot-7-Standard. Das kann der Tatsache geschuldet sein, dass bereits andere „kompakte“ Debug-Schnittstellen, zum Beispiel SWD, existieren und dass nachfolgende Standards wie IEEE Std 1149.1 (2013) Themen wie Powermanagement und Segmentierungsaspekte zu einem gewissen Grad ebenfalls aufgenommen hatten. Wie immer wird die Branche mit den Füßen abstimmen. Nur die Zeit wird zeigen, ob Dot-7 aufblühen oder verkümmern wird – was passieren kann, wenn ein Standard nur für ganz spezielle Ziele definiert wurde.

Obwohl JTAG-/Boundary-Scan weit davon entfernt ist, ein exklusives System für den Produktionstest oder das Debugging zu sein, kamen in den letzten Jahren der 2000er-Dekade hierfür etliche neue Systeme auf den Markt, die das Interesse der Hardware-Entwickler am JTAG-/Boundary-Scan-Standard förderten. Da Prototypen mehr Produktionsfehler enthalten als unter etablierten Prozessen gefertigte Bauteile, wurde JTAG/Boundary-Scan verstärkt als Designwerkzeug vorangetrieben, das die Hardware-Entwicklung und -Validierung lanciert. Eines der Werkzeuge, das 2009 den Markt der Hardware-Validierung betrat, war JTAGLive. Es enthielt das kostenlose, frei herunterladbare Punkt-zu-Punkt-Testsystem „Buzz“, das bei seiner Einführung mehr als tausendmal heruntergeladen wurde. Zum ersten Mal konnten Entwickler ein kostenloses Werkzeug für Verbindungstests benutzen, dessen Anschlusskabel sie wahrscheinlich schon besaßen, da JTAGLive außer einem eigenen, einfachen 1-TAP-Controller auch Altera- und Xilinx-Hardware unterstützt. Darüber hinaus haben Anwender die Möglichkeit, Optionen wie das leistungsfähige, Python-basierte Skript-System oder Core-Emulationsmodule zu erwerben, die ‚Prozessor-gesteuerte Tests’ ermöglichen. Werkzeuge wie JTAGLive bedienen einen Nischenbedarf an elementarer Testsoftware, die die Intuition des Entwicklers und sein Fachwissen über die Baugruppe nutzt, um funktionstestähnliche Tests zu entwickeln.

Elementare Verbindungssignatur

2011 kam eine völlig neue Technik auf den Markt, um von der Leistungsfähigkeit von JTAG zu profitieren. JTAG konnte jetzt ohne Vorabkenntnis der Verbindungsdaten (Netzliste) angewendet werden. Bei Autobuzz muss der Anwender lediglich einen kompatiblen Controller am TAP des Designs anschließen. Dieser Anschluss ist das Einzige, was er über die Verbindung wissen muss. Das System erkennt dann automatisch die Anzahl der Bauteile in jeder Scan-Kette, einschließlich des jeweiligen Herstellercodes. Nach der Zuordnung der BSDL-Modelle zu den erkannten Bauteilen kann der Benutzer durch Autobuzz an einem Gutmuster der Baugruppe die Verbindungen automatisch ermitteln lassen. Alle Ausgangspins werden reihum umgeschaltet und die Eingangspins auf Aktivitäten überwacht. So entsteht eine elementare „Verbindungssignatur“, die alle verbundenen Boundary-Scan-Ein- und Ausgangszellen aufzeigt. In einem Vergleichsmodus bewertet das System die zu prüfenden Baugruppen und zeigt alle Abweichungen von der Verbindungssignatur bei fehlerhaften Baugruppen an. Asynchron arbeitende Ausgänge, die den Prozess stören könnten, lassen sich ausmaskieren, um konsistente Ergebnisse zu erzielen.

Die nächste, wesentliche Aktualisierung des Standards IEEE 1149.1 erfolgte 2013 mit einer beträchtlichen Ergänzung (1149.1 (2013)). Dieser Standard ist das Ergebnis intensiver Aktivitäten ab 2010. Zwei verschiedene Gruppierungen schlugen ähnliche Updates zum Standard 1149.1 vor, der bereits seit 20 Jahren existierte. Außer der Gruppe um 1149.1 gab es auch eine Gruppe, die an IEEE 1687 arbeitete. Beide hatten Mängel an den vorhandenen Standards identifiziert und gingen die Probleme durch die Einführung „dynamischerer“ IC-Infrastrukturen an. Die Hauptmotivation für die Entwicklung von 1149.1 (2013) bestand darin, einige der Vorgehensweisen zu standardisieren, die Halbleiter-Hersteller einseitig eingeführt hatten. Hierzu zählten Initialisierungsprotokolle, individuelle Bauteil-ID-Codes und Power-Management-Szenarien. Im Falle von 1687 ging es primär darum, die Testbarkeit auf Board-Ebene durch verstärkte Nutzung eingebetteter Testkerne (BIST IP) zu verbessern, auf die über eine erweiterte, standardisierte Infrastruktur zugegriffen wird.

Die jetzt ratifizierte Erweiterung der 1149.1 hat den Umfang des Beschreibungsdokuments, das auf 444 Seiten angewachsen ist, mehr als verdoppelt. Es enthält die Syntax einer neuen, prozeduralen Beschreibungssprache (PDL), mit deren Hilfe die Nutzung der dynamischen Register-Segmentierung und Bauteil-IP-Hierarchie einer gegebenen Anwendung definiert wird. IEEE 1687 enthält inzwischen ebenfalls eine PDL. Die Kompatibilität zwischen beiden PDLs ist jedoch sehr rudimentär – offensichtlich aufgrund der unterschiedlichen Zielsetzungen der beiden neuen Standards. Bei 1149.1-2013 dient die PDL der Dokumentation der Verfahren zur Stimulation und Beobachtung der Testdaten-Registerfelder. Bei P1687 geht es um die Stimulation von Daten und deren Beobachtung über (interne) Instrumente. Der Unterschied ist nicht so umfassend, abgesehen davon, dass bei P1687 eine zweite Sprache (Instrument Control Language ICL) erforderlich ist, um die Zugriffs-Netzwerke (der eingebetteten Instrumente) zu beschreiben. Bei 1149.1-2013 sind die Beschreibungen der Zugriffs-Netzwerke in ein erweitertes BSDL-Modell eingebettet. Bei komplexen Netzwerken, die intensiven Gebrauch von eingebetteten Instrumenten machen, beansprucht die ICL aus P1687, besser geeignet zu sein.

Die Argumente für die fortgesetzte Entwicklung der Standards liegen auf der Hand. Sie sollen dafür sorgen, dass sie für die jeweils aktuellen Designs relevant sind und die Aufgabe der Hersteller von Werkzeugen auf Basis der Standards vereinfachen, maximale Automatisierungsgrade bei der Generierung von Anwendungen erzielen und nicht zuletzt, dass das Marktpotenzial eines gegebenen Verfahrens optimiert wird.

Nicht-standardkonforme, JTAG-basierte Lösungen

In der Zwischenzeit haben wirtschaftliche Zwänge dazu geführt, dass auch nicht-standardkonforme, JTAG-basierte Lösungen auf den Markt kamen. Solche Lösungen basieren auf einem JTAG-Zugang zu eingebetteten Strukturen von VLSI-Bauteilen wie Mikroprozessoren, DSPs und FPGAs. Im Fall von Mikroprozessoren und DSPs ermöglicht JTAG häufig den Zugang zu den On-Chip-Debug-Mechanismen (OCD) des Bauteils. Normalerweise ist dieser Zugang die Domäne von Firmware-Entwicklern. Mithilfe einiger elementarer, auf die Anforderungen von Produktionstests abgestimmter Werkzeuge können Produktionstest-Entwickler den Zugriff auf Prozessorkerne verwenden, um eingebettete Peripherie-Funktionen (DDR-Controller, ADCs, DACs, PHYs, Bus-Controller und weitere) über ein standardisiertes internes Bussystem (zum Beispiel Amba) zu steuern, um Boardtest-Aufgaben wahrzunehmen. Statt Prozessor-zentrierten Funktionstest-Code zu entwickeln, ist es möglich, Peripherie-zentrierte Tests zu generieren, die von einem Script-Programm wie Python oder TCL aufgerufen werden können. Zu den unterstützten Mikroprozessor- und DSP-Kernen zählen etwa ARM 7/9/11, die Cortex-Serie, TI C2000, Freescale PPC, Microchip PIC32, Infineon Tricore, Marvell X-Scale und weitere. Der Core-Commander aus JTAGLive, der 2011 auf den Markt kam, ist ein typisches Beispiel für diese Art von Prozessor-Emulationstest-Systemen.

Über JTAG-Schnittstelle auf die FPGA-Strukturen zugreifen

Im Bereich von FPGAs haben führende Anbieter wie Xilinx und Altera Bridge-Logiken implementiert, mit deren Hilfe es möglich ist, über die JTAG-Schnittstelle auf die FPGA-Strukturen zuzugreifen. Um den Zugriff auf die FPGA-Strukturen zu vereinfachen und eine simple Methode bereitzustellen, um auf eingebettete Peripherie-Funktionen zugreifen zu können, entwickelte JTAG Technologies einen Block-Translator-Code in RTL, der einen allgemeinen Zugangspfad für die Verbindungsbusse eingebetteter IPs bietet. Die Vorteile kommen wenigstens zwei Bereichen zugute: Hardware-Entwickler können IP-Kerne für Funktionen wie DDR-Speicherzugriff, Bussteuerung und so weiter testen, debuggen oder fein abstimmen. Test-Entwickler haben einen einfachen Zugang, um Kerne als Instrumente zu nutzen. Während es früher nicht möglich war, über das Boundary-Scan-Register High-Speed-Verbindungen bei voller Taktrate zu testen, kann der Anwender heute die Leistungsfähigkeit seiner eingebetteten Logik in voller Geschwindigkeit über den Standard-JTAG-Testbus nutzen. Der RTL-Translator-Codeblock ist wahrscheinlich sogar so kompakt, dass er ein permanenter Teil der FPGA-Konfiguration bleiben könnte, statt nur ein „Test Only“-Download. Ob dieser Systemtyp aktuell oder künftig einen Trend repräsentieren wird, muss sich erst noch erweisen. Im Gegensatz zu manchen standardisierten Zugriffsverfahren wie IEEE 1687 hängt die Nutzung dieses Typs des Kern-Zugriffs nicht vom Goodwill oder der Weitsicht der Halbleiter-Hersteller oder -Designer ab, die nicht immer allzuviel Verständnis für die Nöte der Boardtest-Entwickler aufbringen.

AutoBuzz, Autowrite und Buzz sind patentierte Produkte von JTAG Technologies.

(ah)