Die meisten modernen Prozessoren und FPGAs, aber auch viele andere digitale Bauteile, sind mit einer seriellen Schnittstelle nach dem IEEE-Standard 1149.1, auch JTAG genannt, ausgestattet. Über diese Schnittstelle können die meisten Pins der Bauteile von der normalen Logik abgekoppelt werden und im Testmodus auf gewünschte Ausgangspegel gesetzt beziehungsweise ihre Eingangspegel eingelesen werden. Ein über eine JTAG-Controllerkarte an die zu testende Baugruppe angeschlossener PC kann nun mit entsprechender Software direkt die Pins der Boundary-Scan-fähigen Bauteile stimulieren und andere einlesen. So kann die Testsoftware prüfen, ob ein eingelesener Pin wie erwartet den Ausgangspegel eines mit ihm verbundenen anderen stimulierten Pins anzeigt (Bild 1).
Werden nicht die erwarteten Pegel eingelesen, liefert die Testsoftware genaue Hinweise auf die vermutliche Fehlerart und die betroffenen Bauteile und Pins (Bild 2), so dass ein Reparaturtechniker – auch ohne genaue Kenntnis der Baugruppe – zielgerichtet den Fehler finden und reparieren kann. Auch nicht Boundary-Scan-fähige Bauteile, wie etwa Speicher, lassen sich über Boundary-Scan (zumindest bezüglich ihrer Lötverbindungen) testen und auch programmieren. Hierzu werden die Pins eines Boundary-Scan-fähigen Bauteils, an das die Speicher angeschlossen sind – meist der Prozessor oder das FPGA – über Boundary-Scan mit den entsprechenden Signalen für die Speicheransteuerung bedient. Die Bibliotheken der Tool-Anbieter enthalten üblicherweise Modelle für praktisch alle gängigen RAMs, Flashs und EEPROMs. Allerdings ist diese Art des Zugriffs auf die Speicher wesentlich langsamer, als wenn der Prozessor oder das FPGA unter eigener Programmkontrolle auf den Speicher zugreift.
Grenzen des Boundary-Scan
Die Geschwindigkeit bei der Programmierung von nichtflüchtigen Speichern ist eine der Grenzen des Boundary-Scan-Verfahrens, welche durch das Nadelöhr der einen seriellen JTAG-Schnittstelle für den Boundary-Scan-Betrieb gesetzt wird. Eine Rolle spielt dies bei sehr großen Speichern und bei der Produktion großer Stückzahlen einer Baugruppe, bei der es auf hohen Durchsatz ankommt. Eine andere Grenze ist die Testabdeckung beim Einsatz vieler analoger oder anderer nicht Boundary-Scan-fähiger Bauteile. Für solche Bereiche der Baugruppe bietet sich ein Funktionstest an – der natürlich einen erheblichen Aufwand für die Softwareentwicklung des Testprogramms bedeutet.
Für viele Prozessoren bieten einige Hersteller von Boundary-Scan-Testsystemen, wie Corelis Europe (Vertrieb: Bayer DSP Systeme), fertige Testprogramme an, welche sich über die JTAG-Debugging-Schnittstelle auf den Zielprozessor laden und ausführen lassen. Hierbei werden zwar dieselbe physikalische Schnittstelle – JTAG – und dieselbe JTAG-Controller-Karte zum Zugriff auf die Zielhardware genutzt, aber nicht im Boundary-Scan-Betrieb, sondern im Debugging-Modus. Denn die eigentlich für Boundary-Scan entwickelte JTAG-Schnittstelle erfüllt bei vielen Prozessoren einen Doppelnutzen als Debugging-Schnittstelle zum Zugriff auf spezielle Debugging-Funktionen des Prozessors. Hierüber lassen sich auch Programme laden, ausführen, anhalten und Register auslesen und beschreiben. Die Testprogramme werden so geladen und geben ihre Ergebnisse über JTAG an die PC-Applikation zurück (Bild 3).
JTAG macht‘s
Eine aktuelle Liste der von Corelis für den Funktionstest, hier „JET“ für „JTAG Embedded Test“ genannt, unterstützten Prozessoren ist auf deren Website [1] zu finden. Die für die jeweiligen Prozessoren entwickelte JET-Testsoftware kennt bereits viele in diesen Prozessoren integrierte Schnittstellen und kann diese somit in den Test einbinden. Ein zum Test angeschlossenes Loopback-Kabel oder ein Kurzschluss-Stecker ermöglicht den Funktionstest externer Komponenten wie UART, Ethernet oder D/A- und A/D-Wandler. Der an den Prozessor angeschlossene Speicher kann mit der vollen Geschwindigkeit der Speicherschnittstelle getestet werden. Dadurch lassen sich auch umfassende Speichertests in kurzer Zeit ausführen. Ebenso können (E)PROMs und Flashs mit voller Geschwindigkeit programmiert werden, um während des Produktionstests ohne große Verzögerung die Firmware der Baugruppe zu programmieren.
Die gemeinsame Bedienoberfläche für beide Testarten (Tabelle 1) erleichtert zudem den Einsatz beim Fertigungsbetrieb. Übrigens lassen sich die Testwerkzeuge von Corelis auch leicht in ICT-Testsysteme und mit Flying Probes integrieren (Bild 4): Für Testsysteme von beispielsweise Agilent, Checksum, Teradyne, Scorpion, Spea, Digital Test, Seica sowie für National Instrument Controller und LabView stehen bereits fertige Integrationen zur Verfügung, für andere ermöglichen DLLs eine einfache Integration.
Nicht nur für den Produktionstest
Da die Test-Software über die JTAG-Schnittstelle geladen wird, ist sie völlig getrennt von der Applikationssoftware der getesteten Baugruppe. Die Testsoftware wird lediglich in den Arbeitsspeicher des Prozessors geladen und verbleibt dort nur für die Testausführung. Auch wird für den Test keinerlei Applikationssoftware benötigt. Somit kann der Softwareentwickler bereits die ersten Prototypen der Hardwareentwicklung umfassend testen, gegebenenfalls Fehler diagnostizieren und beseitigen lassen und für seine Applikationssoftware-Entwicklung auf eine stabile, getestete Hardware vertrauen.
Auch kann ein Servicetechniker im Feld beispielsweise mit einem Laptop und einem USB-JTAG-Controller schnell und einfach umfassende Tests einer vom Kunden als fehlerhaft gemeldeten Baugruppe durchführen.
Unterschiedliche Tests vereinen
Die Kombination aus JTAG-Embedded-Tests und Boundary-Scan-Tests kombiniert zwei unterschiedliche Testtechniken, nämlich das über eine serielle Schnittstelle betriebene Boundary-Scan-Verfahren und mit voller Prozessorgeschwindigkeit ablaufende Funktionstests, in sehr nützlicher Weise und mit einer konsistenten Bedienschnittstelle. Mit geringem Entwicklungsaufwand kann die Testabdeckung erhöht und die Testdurchführung beschleunigt werden.
Weiterführende Informationen:
[1] http://www.corelis.eu/products-JTAG/ScanExpress_JET_Supported_Processors.htm
(mrc)
