Startseite » Allgemein »

Behandlung fehlerhafter BSDL-Files Gerhard Vieweg, Goepel, Jena

„Boundary Scan (IEEE 1149.1, JTAG) – Verifizierung von Registern und Pin-Eigenschaften“
Behandlung fehlerhafter BSDL-Files Gerhard Vieweg, Goepel, Jena

Das Vorhandensein und die Qualität eines BSDL-Files (Boundary Scan Description Language) sind Voraussetzung für sowohl Testpattern-Generierung als auch die Qualität der Diagnoseinformation im Fehlerfall bei der Testausführung. Dieser Artikel zeigt in einer Übersicht, wie fehlerhafte BSDL-Files erkannt und behandelt werden können. Die beschriebenen Verfahren sind jedoch nicht geeignet, einen kompletten BSDL-Check durchzuführen bzw. ein vollständiges BSDL-File zu erstellen.

Indikatoren fehlerhafter BSDL-Files:

Die untenstehende Tabelle zeigt eingehend die Testmöglichkeiten verschiedener Verfahren auf.
Methoden der Prüfung
Der wichtigste Unterschied ist, ob das Device-Under-Test (DUT) auf einem Board montiert ist oder separat getestet werden kann. Im letzteren Fall sind alle Freiheiten von Bitkombinationen vorhanden, während im Falle der Integration die Umgebung dies verbietet, und nur wenige Tests möglich sind. Bei Nichtbeachtung können Schäden für Testobjekt (Device-Under-Test) und Board die Folge sein (Bild 1).
Fall 1: Die Boundary-Scan-Struktur ist komplett unbekannt (BSDL ist nicht verfügbar).
Da die Struktur dem System völlig unbekannt ist, muss das DUT emuliert werden. Als Ergebnis erhält man ein BSDL-File, welches ein Minimum an Informationen für den Fall 2 enthält. Verifizierbar sind:
  • Instruktions-Register-Längen,
  • Daten-Register-Längen,
  • Vorhandensein des Device-Identifikation-Registers (IDCode-Register),
  • Inhalt des IDCode-Registers und
  • Zuordnung Instruktions-Register-Code zu Data-Register-Längen.
Fall 2: BSDL-File ist verfügbar, Pin-Eigenschaften sollen aber geprüft werden.
Das DUT ist direkt mit dem TAP (Test-Access-Port) des Controllers verbunden bzw. kann sich die Scan-Kette mit anderen BScan-ICs teilen; sämtliche Pins sind isoliert (Bild 2). Prüfbar sind:
  • Pin-Eigenschaften (BScan-Input/Output2/Output3/Bidir) eines zu prüfenden Pins, einschließlich Ermitteln der Boundary-Register-Zell-Nummern. Bedingungen:
  • BSDL-File (und somit Bibliotheksmodell) ist verfügbar und
  • alle BScan-Pins des DUT müssen isoliert sein sowie mit einer geeigneten Testeinrichtung verbunden werden können.
Fall 3: Überprüfung einzelner Pins
Das DUT ist direkt mit dem TAP des Controllers verbunden bzw. kann sich die Kette mit anderen BScan-ICs teilen; es könnte auf einem Board montiert sein. Prüfbar sind:
  • Pin-Eigenschaften (BScan-Input/Output2/Output3/Bidir) einschließlich der BScan-Zell-Nummern, innerhalb der Grenzen, die das Board durch seine Struktur definiert. Bedingungen:
  • BSDL-File (Bibliotheks Modell) ist vorhanden und
  • DUT kann Teil des Boards sein, der zu testende Pin wird mit einer Handheld-Probe kontaktiert.
Überblick: siehe obenstehende Tabelle
Bemerkungen:
Mode „emuliert“ bedeutet, dass das DUT nicht mit dem TAP des Controllers angeschlossen ist. Hingegen wird er durch Boundary-Scan-Output / -Input emuliert. Im Real-Mode ist das Testobjekt mit dem TAP des Controllers verbunden bzw. kann sich die Scan-Kette mit anderen BScan-ICs teilen.
„(ja)“ bedeutet, dass diese Methode möglich, jedoch aufgrund des zu hohen Programmieraufwandes nicht sinnvoll ist.
Grenzen
Differenzielle Eingänge sowie Ausgänge können nicht mit den beschriebenen Methoden getestet werden. Der Grund ist ein passendendes Paar als „Gegenstück” für den Treiber bzw. den Empfänger (Bild 3). Zum Testen dieser Strukturen sind somit zwei Verbindungen nötig. Eine Prüfung mit einer Handheld-Probe wird damit unmöglich.
Praktische Realisierung: Boundary-Scan-Probe
Die folgenden Print-Outs wurden beim Untersuchen eines XC95288XLPQ208 der Firma Xilinx gemacht.
Das Bild 5 zeigt die Ergebnisse der Betriebsart „Check DR length after Reset“.
Die Bit-Zurdnung wird automatisch zerlegt, der Herstellername wird eingetragen.
Beim Prüfen der Pin-Eigenschaften in der Betriebsart „check single pin, prompted”, erhält man Ergebnisse, wie im Bild 6 gezeigt. Die Test-Situationen sind:
  • offen (nicht kontaktiert oder kein BScan-Pin),
  • zwei verschiedene BScan-Pins,
  • VCC,
  • GND.
Eine vielseitige Programmiersprache: CASLAN
Mehr als 10 Jahre Erfahrung beweisen: Neben den BScan-Aktionen ist ein ständig steigender Bedarf an Elementen, um Cluster-Tests mit vielseitigen Möglichkeiten zu realisieren. Typisch sind dabei:
  • arithmetische Ausdrücke,
  • Ausgabe von Variablen/Register-Inhalten/Text in das Protokoll,
  • Bediener-Interaktion (Auswahl, Eingabe, Selektion),
  • direkter Zugriff auf BScan-Register (Daten und Instruktionen),
  • File-Zugriff,
  • Schleifen, Verzweigungen, Vergleiche …,
  • Steuerung des Testbus (Irshift, Drshift),
  • Steuerung von Controller Ressourcen (PIP-Kanäle, TCK-Frequenz, ..) sowie
  • String-Verarbeitung.
Die Software-Steuerung der beschriebenen Boundary-Scan-Probe wurde komplett in der Programmiersprache CASLAN realisiert; nachfolgend einige wenige typischen Ausschnitte (siehe Bild 4).
Boundary-Scan-Probe
Die Probe befindet sich in einem handlichen Gehäuse mit diversen Bedien- und Anzeigeelementen. Zwei Steckverbinder ermöglichen die Verbindungen zum Controller und zum Prüfobjekt. Für das direkte Kontaktieren von Schaltkreispins ist die Nadel verwendbar. Die verschiedenen Betriebsarten ermöglichen Treiben und Bewerten von Logikpegeln, sowohl unter CASCON-Kontrolle oder autonom in der Logikstift-Funktion. Als „Herz“ fungiert eine BScan-Struktur, die eine Host-Funktionalität erfüllt (Fall 1 und 2). Die Probe stellt somit das benötigte Hardware-Bindeglied für das die geschilderten Testfunktionen dar (Bild 7).
EPP 463

Literaturangaben
IEEE Std 1149.1 – 1990
IEEE Std 1149.1 – 1993
IEEE Std 1149.1 – 2001

Synonyme
CAD – Computer Aided Design
CASCON – Boundary-Scan-Test-Software der Firma Göpel electronic
CASLAN – CASCON-Language
DUT – Device-Under-Test
BSDL – Boundary-Scan-Description-Language
BScan – Boundary Scan (JTAG)
BS IC – Boundary-Scan-Schaltkreis
TAP – Test-Access-Port
TCK – Test-Clock
TDI – Test-Data-In
TDO – Test-Data-Out
TMS – Test-Mode-Select
Unsere Webinar-Empfehlung
INLINE – Der Podcast für Elektronikfertigung

Doris Jetter, Redaktion EPP und Sophie Siegmund Redaktion EPP Europe sprechen einmal monatlich mit namhaften Persönlichkeiten der Elektronikfertigung über aktuelle und spannende Themen, die die Branche umtreiben.

Hören Sie hier die aktuelle Episode:

Aktuelle Ausgabe
Titelbild EPP Elektronik Produktion und Prüftechnik 2
Ausgabe
2.2024
LESEN
ABO
Newsletter

Jetzt unseren Newsletter abonnieren

Webinare & Webcasts

Technisches Wissen aus erster Hand

Whitepaper

Hier finden Sie aktuelle Whitepaper

Videos

Hier finden Sie alle aktuellen Videos


Industrie.de Infoservice
Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de