DE60221836T2 - Verfahren und vorrichtung zur optimierten parallelen prüfung und zum zugriff auf elektronische schaltung - Google Patents

Verfahren und vorrichtung zur optimierten parallelen prüfung und zum zugriff auf elektronische schaltung Download PDF

Info

Publication number
DE60221836T2
DE60221836T2 DE60221836T DE60221836T DE60221836T2 DE 60221836 T2 DE60221836 T2 DE 60221836T2 DE 60221836 T DE60221836 T DE 60221836T DE 60221836 T DE60221836 T DE 60221836T DE 60221836 T2 DE60221836 T2 DE 60221836T2
Authority
DE
Germany
Prior art keywords
test
controller
ptb
data
bus
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60221836T
Other languages
English (en)
Other versions
DE60221836D1 (de
Inventor
Michael Nashua RICCHETTI
Christopher J. Durham CLARK
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intellitech Corp
Original Assignee
Intellitech Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intellitech Corp filed Critical Intellitech Corp
Application granted granted Critical
Publication of DE60221836D1 publication Critical patent/DE60221836D1/de
Publication of DE60221836T2 publication Critical patent/DE60221836T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3185—Reconfiguring for testing, e.g. LSSD, partitioning
    • G01R31/318533—Reconfiguring for testing, e.g. LSSD, partitioning using scanning techniques, e.g. LSSD, Boundary Scan, JTAG
    • G01R31/318558—Addressing or selecting of subparts of the device under test
    • G01R31/318563—Multiple simultaneous testing of subparts
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C29/00—Checking stores for correct operation ; Subsequent repair; Testing stores during standby or offline operation
    • G11C29/56—External testing equipment for static stores, e.g. automatic test equipment [ATE]; Interfaces therefor
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3185—Reconfiguring for testing, e.g. LSSD, partitioning
    • G01R31/318516—Test of programmable logic devices [PLDs]
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3185—Reconfiguring for testing, e.g. LSSD, partitioning
    • G01R31/318533—Reconfiguring for testing, e.g. LSSD, partitioning using scanning techniques, e.g. LSSD, Boundary Scan, JTAG
    • G01R31/318555—Control logic
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C29/00—Checking stores for correct operation ; Subsequent repair; Testing stores during standby or offline operation
    • G11C29/04—Detection or location of defective memory elements, e.g. cell constructio details, timing of test signals
    • G11C29/08—Functional testing, e.g. testing during refresh, power-on self testing [POST] or distributed testing
    • G11C29/12—Built-in arrangements for testing, e.g. built-in self testing [BIST] or interconnection details
    • G11C29/18—Address generation devices; Devices for accessing memories, e.g. details of addressing circuits
    • G11C29/26—Accessing multiple arrays
    • G11C2029/2602—Concurrent test

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich im Allgemeinen auf eine Scan-basierte Prüfung bzw. einen Scan-basierten Test von integrierten Schaltungen, gedruckten Leiterplatten und Systemen und besonders auf ein Verfahren und eine Vorrichtung zum Zugriff auf eine Mehrzahl solcher elektronischer Kreise innerhalb eines Systems und auf die optimierte parallele Prüfung einer Mehrzahl solcher elektronischer Kreise.
  • Die Scan-basierte Prüfung wird häufig während der Entwicklung und der Produktion von elektronischen Bauelementen (zum Beispiel, integrierte Schaltungen (ICs)) und Systemen (zum Beispiel, gedruckte Leiterplatten (PCBs) und Systemen auf einem Chip (SoC) zur Ermittlung und Bestimmung von Defekten und für das Fehlerbeseitigen eingesetzt. Dieses Prüfverfahren wird allgemein als "Scan" bezeichnet, weil die Zustandselemente der Kreise konfiguriert werden, um ein Reihenverschieberegister bzw. serielles Shift-(d.h., Scan) Register, häufig einen Scan-Path oder eine Scan-Chain genannt, während eines Testbetriebsmodus zu bilden. Ein Scan-Test bezieht häufig serielles Shifting von Daten zu (Scan-in) und aus (Scan-out) den Scan-Path(s) einer Prüfeinheit [Unit Under Test] (UUT) als Weg zum Anwenden digitaler Logikwerte als Testanregung und Aufnehmen bzw. Capturing der digitalen Logikwerte in Erwiderung auf die Testanregung ein. Die Antworten werden normalerweise gegen erwartete Scan-out-Daten verglichen, und jeder mögliche Ausfall während des Datenvergleiches zeigt im Allgemeinen Feststellung eines Defektes in der UUT an. Für eine Digitalschaltung liefert der Scan-Testmodus daher volle Steuerbarkeit bzw. Kontrollierbarkeit und Beobachtbarkeit von Inputs und Outputs der in einer UUT eingeschlossenen Kombinatorik. Dieses vereinfacht das Testproblem sehr und sorgt für Tests hoher Qualität bei verringerten Gesamtkosten.
  • Bereitstellen von seriellen Scan-Zugriff ermöglicht einen "Blick" in eine UUT zu Test- und Fehlerbeseitigungszwecken, indem er einen Weg zum Beobachten/Steuern des Kreiszustands bereitstellt ohne die Notwendigkeit physisch zu überprüfen. Ohne Scan würden interne Punkte des Kreises nur über die physischen Stifte der UUT zugänglich sein. In diesem Fall würde Prüfen oder Fehlerbeseitigen des Kreises das Anwenden komplizierter Reihenfolgen von Vorgängen erfordern, um Steuern/Beobachten der internen Zustände bereit zu stellen. Eine UUT mit Scan kann auch verwendet werden, um auf andere Kreise, die an die UUT angeschlossen sind, zum Beispiel Kreise, die innerhalb der UUT eingebettet sind, wie eingebettete Speicher und Kerne oder andere Kreise, die von außen an die UUT angeschlossen werden, zuzugreifen. Dieser Ansatz wird häufig eingesetzt, um externe Speicher mit dem Ziel der Programmierung ihres Inhalts zugänglich zu machen, zum Beispiel Programmieren von FLASH-Speicher vom Boundary-Scan-Path eines ICs, der an den FLASH-Speicher angeschlossen ist.
  • Ein Scan-Zugang erfolgt gewöhnlich in Übereinstimmung mit der Spezifikation IEEE 1149.1 Standard Test Access Port und Boundary Scan Architecture, die hierin durch diesen Hinweis aufgenommen wird. Dieser Standard wurde hauptsächlich entwickelt, um die Probleme der PCB-Prüfung zu lösen. Der IEEE 1149.1 Standard verwendet einen Boundary-Scan-Path, um Zugang zu den I/O Stiften der Bauelemente zu erleichtern, die am PCB angebracht sind. Außerdem kann der IEEE 1149.1 Standard verwendet werden, um Scan-Wege bzw. Scan-Paths innerhalb eines ICs zugänglich zu machen, um einen Test zu erleichtern, Fehlerbeseitigen auszuführen und zur In-System-Konfiguration von ICs, von PCBs und von Systemen.
  • 1 veranschaulicht die herkömmliche IEEE 1149.1 Boundary-Scan-Architektur 100. Wie in 1 gezeigt, hat ein IC, der der IEEE 1149.1 Boundary-Scan-Architektur 100 genügt, vier (gegebenenfalls fünf) zusätzliche Bauelementstifte, die Test Clock (TCK), Test-Modus-Select (TMS), Test-Data-Input (TDI) und Test-Data-Output (TDO) genannt werden (und gegebenenfalls Test-Reset (TRSTN)). Diese dedizierten Teststifte werden allgemein als Test-Access-Port (TAP) bezeichnet. Außerdem implementieren IEEE 1149.1 genügende ICs drei Scan-Register, ein Anweisungs-Register bzw. Instruction Register (IR) 102 und zwei Standard-Data-Register (DR), genannt ein Bypass-Register 104 und ein Boundary-Scan-Register (BSR) 106.
  • 1 zeigt auch ein Benutzer-DR 108, womit der IEEE 1149.1-Standard es Entwicklern erlaubt, zu implementieren, um zusätzlichen Test zu unterstützen und Fehler bei Merkmalen in der Architektur 100 zu beseitigen, wie interne Scan-Wege bzw. Scan-Paths und Built-in-Self-Test (BIST).
  • Im IEEE 1149.1-Standard haben die fünf TAP-Stifte die folgenden Funktionen:
    TCK ist ein Input-Signal, das bereitgestellt wird, um die Ausführung der verschiedenen Testtätigkeiten, sowohl innerhalb der einzelnen IC-Bestandteile als auch unter den mehrfachen IC-Bestandteilen, auf die durch den TAP zugegriffen wird, zu synchronisieren. TCK ist ein periodisches Taktgebersignal, das im Allgemeinen in freiem Betrieb bei einer konstanten Frequenz ist. Jedoch kann TCK gestartet werden oder gestoppt werden, oder seine Frequenz kann, abhängig von der Anwendung, geändert werden. Die meisten Testtätigkeiten finden auf der Anstiegsflanke des TCK-Impulses statt, aber bestimmte Tätigkeiten treten nur auf der Abstiegsflanke von TCK auf.
  • TMS ist ein Input-Stift, der benutzt wird, um den internen Zustand eines TAP-Controllers 110 (siehe 1) zu steuern bzw. regeln. Der TAP-Controller 110 ist eine 16-State Finite State Machine (FSM), die ein Standard-IEEE 1149.1-Protokoll für einen Zugriff auf Funktionen innerhalb der Architektur 100 bereitstellt. Bestimmte Tätigkeiten werden, definiert durch den IEEE 1149.1-Standard, die Erlaubnis erhalten und können nur in den speziellen TAP-Controllerzuständen durchgeführt werden. TMS Werte werden an der Anstiegsflanke von TCK gesampelt.
  • TRSTN ist ein Input-Signal, das asynchrones Reset des TAP-Controllers 110 liefert, der ihn in den Test-Logic-Reset-Zustand zurück holt, damit das IC-Bauelement seine zugedachte Funktion durchführen kann. Ungeachtet von dem Zustand von TCK und TMS-Inputs, kommt der Ziel TAP-Controller in den Test-Logic-Reset-Zustand und bleibt so lange darin, wie TRSTN bei einem Logikwert 0 ist. Da es auch möglich ist, den TAP-Controller 110 zurückzustellen, indem man TMS auf den Logikwert 1 für zumindest 5 TCK Perioden einstellt, wird TRSTN als ein wahlweises Input-Signal definiert.
  • TDI ist ein Input-Signal, das serielle Scan-in-Daten zum Bauelement liefert. TDI empfängt Testdaten von TDO anderer Bauelemente oder von einer äußeren Test-Ressource, wie einem Scan-Controller oder Automatic Test Equipment (ATE). Der Logikwert des Signals auf TDI wird auf der Anstiegsflanke von TCK gesampelt.
  • TDO ist der serielle Scan-out auf dem Bauelement. Wenn einem Bauelement ermöglicht wird, Daten zu scannen, überträgt sein TDO Testdaten zu TDO eines anderen Bauelements oder zurück zur Testvorrichtung. Scan-out-Werte an dem TDO-Output ändern sich mit der Abstiegsflanke von TCK.
  • Der IEEE 1149.1-Standard erleichtert, die TAP-Ports von Mehrfach-Bauteilen miteinander zu verbinden, um einen IEEE 1149.1 Bus zu bilden, der erlaubt, dass auf die verbundenen Kreise mit einem gemeinsamen TAP-Protokoll zugegriffen wird. Dieses wird gewöhnlich erzielt, indem man die seriellen Datenanschlüsse, TDI und TDO der einzelnen Bauelemente in einer Verkettungsweise so anschließt, dass der TDO-Output von der vorhergehenden Vorrichtung entlang der Kette an den TDI-Input des folgenden Bauelements in der Kette angeschlossen wird. Dann wird, indem man alle einzelnen TMS, TCK (und gegebenenfalls TRSTN)-Signale zusammen verbindet, ein Gesamt-TAP-Bus gebildet.
  • Eine typische Verkettungs-Konfiguration (daisy chained) 200 des IEEE 1149.1-Busses wird in 2 bildlich dargestellt. Wie in 2 gezeigt, werden der TDI-Input an einem ersten Bauelement 202.1 (UUT1) und der TDO-Output an einem letzten Bauelement 202.n (UUTn) als der serielle Daten-Input beziehungsweise serielle Daten-Output des Busses benutzt. Unter der Voraussetzung der mit Bus versehenen Konfiguration 200, die in 2 gezeigt wird, kann die Testvorrichtung an TDI, TDO, TMS, TCK und TRSTN des Busses angeschlossen werden und mit den Bauelementen 202.1-202.n, die das IEEE 1149.1-TAP-Protokoll verwenden, kommunizieren.
  • Die Verkettungs-Konfiguration 200 von 2 kann an einem einzelnen PCB verwendet werden. Jedoch wird häufig ein anderer Ansatz verwendet, wenn der TAP-Bus sich über Mehrfach-PCBs über einen Systemplatineneinschub erstreckt. In diesem Fall kann das Einführen der Verkettungs-TDI/TDO Konfiguration 200 von 2 entlang dem Platineneinschub unpraktisch sein, weil die Scan-Kette getrennt wür de, wenn irgendein Board getrennt bzw. abgezogen wird. Außerdem kann sich die gesamte Konfiguration (zum Beispiel, die Gesamtlänge der Scan-Kette) ändern, während unterschiedliche Typen von Boards hinzugefügt oder entfernt werden. Dieses erschwert die Kommunikation der Testvorrichtung mit den einzelnen Boards, damit sie richtig gekennzeichnet und geprüft werden können. Infolgedessen hat die Kompliziertheit des Einführens einer einzelnen seriellen Kette über einen Systemplatineneinschub zur Entwicklung und zu dem Gebrauch von einer Konfiguration des IEEE 1149.1 TAP-Busses geführt, der allgemein als die Multi-Drop-Busarchitektur bezeichnet wird.
  • Wie in 3 gezeigt, kann eine herkömmliche Multi-Drop-Konfiguration 300 des IEEE 1149.1 Busses verwendet werden, um einen einzelnen TAP-Bus über einen Platineneinschub bereit zu stellen, um jedem Board 302.1-302.n zu erlauben, Verbindungen zum gleichen Satz der Leitungen auf dem Bus, d.h. parallel, herzustellen. Weil TCK, TMS, TDI und die wahlweisen TRSTN Input-Signale sind, können sie über den Systemplatineneinschub an jeden der TAPs der einzelnen Boards 302.1-302.n direkt angeschlossen werden. Jedoch ist zu beachten, dass Signalzusammenstöße verhindert werden, die aufgrund des Anschließens der Mehrfach-TDO Outputs an die einzelne TDO Leitung des Multi-Drop-Busses resultieren können. Dies ist möglich, da der IEEE 1149.1-Standard erfordert, dass der TDO-Output nur angesteuert werden soll, wenn serielle Daten in/aus den TDI-TDO-Stiften des TAP verschoben wurden. Dieses wird durch die internen Zustände des TAP-Controllers 110 gesteuert (siehe 1), damit das serielle Shifting nur während der Shift-IR oder der Shift-DR-Zustände des TAP-FSMS ermöglicht wird. In allen weiteren Fällen wird der TDO-Output gesperrt bzw. abgestellt, indem man ihn zu einem unaktivierten oder hochohmigen Zustand zwingt.
  • Bei Verwendung der Multi-Drop-Konfiguration 300 empfangen jedoch alle TAP-Controller den gleichen Satz an Input-Signalen und funktionieren folglich im Gleichtakt mit einander. Das heißt, alle FSMs des TAP-Controllers sind im gleichen Zustand, sodass, es sei denn bestimmte Änderungen werden an der Architektur vorgenommen, Ermöglichen des TDO-Outputs von jedem TAP-Controller (zum Beispiel, während des Zustandes Shift-DR) auch den TDO-Output von allen weiteren TAP-Controllern ermöglicht. Weil alle TAP-Controller im Gleichtakt funktionieren und die gleichen Input-Datenwerte (d.h., vom gemeinsam Bus nutzenden TDI) empfangen, ist es außerdem schwierig, andere Testtätigkeiten auf den unterschiedlichen Boards 302.1-302.n ohne spezielle Beachtung in der Architektur durchzuführen.
  • Das Steuern bzw. Regeln der Multi-Drop-Konfiguration 300 des IEEE 1149.1-Busses erfordert normalerweise den Gebrauch von einer kundenangepassten Version des TAP-Controllers und eines speziellen Protokolls, um mit ihm zu kommunizieren. Weiterhin wird der TAP-Controller und das Protokoll im Allgemeinen mit jedem Bauelement oder Board verwendet, die Schnittstellen zum Multi-Drop-Bus haben bzw. sind. Die Multi-Drop-Konfiguration 300 erfordert die Fähigkeit, die TAP-Controller auf dem Bus zu adressieren, damit ein einzelner TAP-Controller sein TDO-Output ansteuert, nur nachdem er einzigartig ausgewählt worden ist. Wenn nicht-ausgewählt, empfangen die TAP-Controller noch den TDI-Input und funktionieren im Gleichtakt, aber ermöglichen ihrem TDO-Output nicht, den Multi-Drop-Bus anzusteuern.
  • Gegenwärtige Lösungen für die parallele Prüfung oder Konfiguration der programmierbaren Kreise schließen das Einsetzen eines "verbundenen bzw. ,ganged' Zugriffs" oder eine "Scan-Multiplier"-Konfiguration der UUT ein. Eine herkömmliche ganged-Zugriff Scan-Multiplier-Konfiguration 400, die den IEEE 1149.1 Bus verwendet, wird in 4 gezeigt. Mit dieser Konfiguration werden Inputs zu UUT 402.1-402.n (d.h., TDI, TMS, TCK und TRSTN) parallel im Bus gehandhabt, während Scan-Outputs von jeder UUT 402.1-402.n (d.h., TDO) einzeln an einen Multiplexer-Controller 408 angeschlossen sind. So wird eine dedizierte TDO-Leitung für jede UUT 402.1-402.n auf dem Bus im Allgemeinen erforderlich. Für Anwendungen, die einen hohen Grad parallele Prüfung erfordern, würde dieses erfordern, dass eine Vielzahl von TDO Signalen von UUTs 402.1-402.n zurück zu dem Multiplexer-Controller 408 angeschlossen werden. Wenn es so zum Beispiel gewünscht wird, einhundert UUTs in dieser Konfiguration 400 anzuschließen, würden einhundert verschiedene TDO-Leitungen (eine pro UUT) zurück zu einem TDO-Selektionskreis 406 geroutet. Der Zweck des Multiplexer-Controllers 408 ist es, eine einfache Schnittstelle mit einem universellen IEEE 1149.1-Controller 404, der gerade 4 oder 5 Standard-TAP-Controllerstifte hat, wie in 4 gezeigt, zuzulassen.
  • Mit dem Ansatz der ,ganged'-Zugriff-Scan-Multiplier-Konfiguration 400 liefert der IEEE 1149.1-Controller 404 das TAP-Protokoll zu allen UUTs 402.1-402.n parallel, und folglich empfangen alle UUTs 402.1-402.n die gleichen TAP-Anweisungen und Testdaten. Weiterhin kann, wie in 4 gezeigt, der Multiplexer-Controller 408 nur einen einzigen TDO-Output von einer der UUT auswählen, um zurück zu dem IEEE 1149.1-Controller 404 zu verbinden. So kann die Gang-Zugriff-Scan-Multiplier-Konfiguration 400 Scan-in Testdaten bezüglich des allgemeinen TDI des Busses zu allen UUTs 402.1-402.n parallel senden, aber der Scan-out empfängt Testdaten bezüglich TDO von nur einer UUT zur Zeit. Dieser Ansatz kann die erforderliche Zeit zum Programmieren von Mehrfach-Bauelementen verringern, gleichwohl beschleunigt er nicht den Betrieb, der zur Überprüfung von Scan-out-Testdaten von den TDO-Outputs der jeweiligen UUT erforderlich ist. So würde zum Beispiel das Überprüfen des programmierten Inhalts der FLASH-Speicher auf der UUT einzeln ein Zurücklesen und Überprüfen des Inhalts jedes FLASH-Speichers, d.h. einzeln, erfordern. Alle möglichen anderen Betriebsformen, die Polling oder Status-Check erfordern, haben einen ähnlichen Nachteil. Für Prüfzwecke wird der TDO-Scan-out an jeder UUT für jedes Bit des Scan-outs überprüft. So gibt es natürlich einen kleinen Vorteil für diesen Ansatz gegenüber der seriellen Prüfung der UUTs. Dementsprechend ist die herkömmliche Gang-Zugriff-Scan-Multiplier-Konfiguration 400 keine optimale Lösung für die parallele Prüfung.
  • Der Gebrauch von Design-for-Testability (DFT)-Techniken durch Ingenieure – einschließlich der Implementierung des IEEE 1149.1 Boundary-Scans, des internen Scans und Built-in-Self-Test (BIST) hat sich stark erhöht, da ICs, PCBs und Systeme komplizierter geworden sind. Dieser erhöhte Gebrauch von DFT hat für Tests auf hoher Qualität, verringerte Testzeiten und Testkosten, verringerten Fehlersuchaufwand und verringerte Zeit zum Vermarkten gesorgt. Während elektronische Kreise weiter an Kompliziertheit zunehmen, bleibt ein Test jedoch forthin eine Herausforderung und kann ein Hauptengpass im Design und in der Herstellung von elektronischen Hochtechnologie-Systemen sein. Beispiele für Technologien, die zu erhöhter Designkompliziertheit beitragen und folglich während des Tests behandelt und von Fehlern befreit werden müssen, schließen eingebettete Kerne, eingebettete Speicher, Analog/Misch-Signal-Anwendungen und In-System-Konfiguration (ISC) von programmierbarer Logik (zum Beispiel, CPLDs und FPGAs) und Permanentspeicher ein (zum Beispiel, FLASH-Speicher). Weiterhin besteht eine wachsende Marktnachfrage nach solchen Produkten, zusätzlich zu erhöhter Konkurrenz auf dem Markt, und übt weiterhin Druck auf Hersteller elektronischer Systeme aus, Kosten zu verringern und Markteinführungszeit zu verbessern. So sind neue Verfahrensweisen, die sowohl Kosten verringern, als auch die Zeit herabsetzen, die für die Prüfung, Fehlersuche und Beseitigung und Konfiguration von kompliziertem ICs, von PCBs und von Systemen erforderlich ist, notwendig.
  • KURZDARSTELLUNG DER ERFINDUNG
  • In Übereinstimmung mit der vorliegenden Erfindung wird eine Parallel-Test-Architektur (PTA) bereitgestellt, die gleichzeitigen Zugriff auf mehrfache elektronische Kreise (d.h., parallel) zum optimierten Prüfen und/oder zu fehlerbeseitigenden Zwecken oder für die Konfiguration von programmierbaren Kreisen erleichtert. In einer Ausführungsform enthält eine PTA einen Parallel-Test-Bus (PTB), einen Test-Controller, der an PTB angeschlossen ist, und eine Mehrzahl von den adressierbaren PTB-Controllern, die an das PTB angeschlossen sind, wobei jeder adressierbare PTB-Controller an einen jeweiligen elektronischen Kreis, auf den zugegriffen werden soll, koppelbar ist. In der momentan offenbarten Ausführungsform ist der Test-Controller konfiguriert, um zumindest ein Steuersignal über den PTB an die jeweiligen adressierbaren PTB-Controller zum Initiieren eines Parallel-Scan-Zugriffs der daran durch die jeweiligen adressierbaren PTB-Controller koppelbaren elektronischen Kreise zu senden. Weiter wird jeder adressierbare PTB-Controller konfiguriert, ein Scan-Protokoll einzusetzen, um auf den jeweiligen daran koppelbaren elektronischen Kreis zuzugreifen, basierend auf dem zumindest einem Steuersignal, das über das PTB durch den Test-Controller gesendet wird und resultierende Scan-Daten über den PTB zum ersten Controller in Erwiderung auf den Zugriff auf den jeweiligen elektronischen Kreis zu senden.
  • Die elektronischen Kreise können jeden möglichen Kreis, einschließlich einer IC-Die enthalten, der auf einem Siliziumwafer, einem verpackten ICs, einem PCBs oder Kreisen innerhalb eines Systems gefertigt wird. PTA ermöglicht parallelen Zugriff auf alle diese elektronischen Kreise, um einer Testvorrichtung zu gestatten, jede beliebige Anzahl an Kreisen vom gleichen Typ parallel zu prüfen oder zu programmieren.
  • Die momentan offenbarte Parallel-Testarchitektur verringert Kosten, die mit der Prüfung von elektronischen Kreisen und Konfigurationen der programmierbaren logischen Bauelemente und der Speicher verbunden sind. Mit der PTA werden die Kosten eines automatischen Testgeräts (ATE) verringert, da die Testvorrichtung, die erforderlich ist, um die PTA zu steuern bzw. regeln, durch ein preiswertes System, wie einen PC, oder eine Unix-gegründete Workstation anstelle von einer Vollfunktion ATE implementiert werden kann. Außerdem werden Kosten verringert, weil die PTA Mehrfach-Kreise parallel prüfen oder programmieren kann, wodurch Prüf- und Programmierzeiten herabgesetzt werden. Die PTA sorgt auch für die Mühelosigkeit der Skalierbarkeit gegenüber traditionellem ATE. ATE ist gewöhnlich auf die Prüfung einer einzelnen UUT oder nur einiger Bauelemente parallel begrenzt. Weiterhin ist die Skalierbarkeit von traditionellem ATE häufig unpraktisch, da es teuer ist, Betriebsmittel hinzuzufügen (zum Beispiel, Prüferkanäle und Vektorspeicher) oder, zusätzliches ATE zu verwenden, um die erhöhte "parallele" Prüfung von mehrfachem UUTs bereit zu stellen.
  • Die PTA wird konfiguriert, um echtes paralleles Prüfen von mehreren UUT bereit zu stellen. Sie ist fähig, eine Anzahl von UUTs gleichzeitig zu prüfen oder zu überprüfen, d.h. parallel, anstatt einzeln. Mit der PTA ist die Beschleunigung in der Testzeit gegenüber jener von der seriellen Prüfung gleich der Zahl von UUT, die parallel angeschlossen und geprüft werden. Die PTA löst zahlreiche Probleme herkömmlicher Testarchitektur, wie das Problem des Erforderns gesonderter TDO-Leitungen für jede UUT. Dieses macht es möglich, dass die PTA praktisch eingesetzt und für eine Vielzahl von Anwendungen verwendet werden kann. Zum Beispiel kann die PTA von den Vorrichtungen oder von UUTs separat implementiert werden, oder es kann zusammen mit den UUTs als Teil einer abschließenden Systemkonfiguration eingeführt werden. Zum Beispiel im Fall von Chip-Tests an einer Wafersonde kann die PTA als Teil einer Prüfvorrichtung- oder Sondenschnittstellenkarte implementiert werden. Weiter kann die PTA auf jedem der PCBs implementiert werden, die auf einen Systemplatineneinschub gesteckt sind. Es ist auch möglich, die PTA in einen IC zu implementieren, zum Beispiel um einen Parallel-Test bereit zu stellen, bei dem die UUTs eingebettete Kerne innerhalb einer Soc sind.
  • Die PTA verwendet einen verbesserten Test-Controller und -Protokoll für das Kommunizieren mit den UUTs. Der Test-Controller selbst kann an die UUTs von außen angeschlossen werden, oder er kann ein Master-Test-Controller sein, der in einem System eingebettet ist, welches die UUTs enthält (zum Beispiel, eine Master-Controller-Vorrichtung auf einem PCB Board) oder eingebettet in einem IC (ist zum Beispiel, ein Master-Controller-Kern) im System. Der externe Test-Controller kann ein universeller Computer oder ein PC mit der passenden Anwendersoftware sein.
  • Die momentan offenbarte parallele Testarchitektur stellt eine preiswerte optimale Lösung zur parallelen Prüfung der elektronischen Kreise und/oder zur Konfiguration der programmierbaren Kreise zur Verfügung. Sie kann in einer Vielzahl von Wegen implementiert werden, die zum Anwendungsgebrauch passend sind. Weiterhin unterstützt die PTA jede beliebige Anzahl an DFT Verfahrensweisen für die Prüfung der UUT zum Beispiel Boundary-Scan, interner Scan und BIST.
  • Weitere Eigenschaften, Funktionen und Aspekte der Erfindung sind aus der nachstehenden ausführlichen Beschreibung der Erfindung ersichtlich.
  • KURZBESCHREIBUNG DER VERSCHIEDENEN ANSICHTEN DER ZEICHNUNG
  • Die Erfindung wird genauer mit Bezug auf die folgende ausführliche Beschreibung der Erfindung in Verbindung mit den Zeichnungen verstanden:
  • 1 ist ein Blockdiagramm, das eine herkömmliche IEEE 1149.1 Test-Zugang Port-(TAP) Boundary-Scan-Architektur bildlich darstellt;
  • 2 ist ein Blockdiagramm, das eine herkömmliche Verkettungs-Konfiguration eines IEEE 1149.1 Busses bildlich darstellt;
  • 3 ist ein Blockdiagramm, das eine herkömmliche Multi-Drop-Konfiguration des IEEE 1149.1 Busses bildlich darstellt;
  • 4 ist ein Blockdiagramm, das eine herkömmliche Ganged-Zugriff-Scan-Multiplier-Konfiguration des IEEE 1149.1-Busses bildlich darstellt;
  • 5 ist ein Blockdiagramm, das eine parallele Testarchitektur entsprechend der vorliegenden Erfindung bildlich darstellt;
  • 6 ist ein Blockdiagramm, das einen Parallel-Testbus-Controller bildlich darstellt, der in der Parallel-Testarchitektur von 5 enthalten ist;
  • 7 ist ein Blockdiagramm, das einen adressierbaren TAP-Linker bildlich darstellt, der im Parallel-Testbus-Controller von 6 enthalten ist;
  • 8 ist ein Blockdiagramm, das eine parallele Testbusbrücke entsprechend der vorliegenden Erfindung bildlich darstellt;
  • 9 ist ein Zeitablauf-Diagramm, das Bus-zu-Bus Übertragungen unter Verwendung der Parallel-Testbusbrücke von 8 bildlich darstellt;
  • 10 ist ein Blockdiagramm, welches die parallele Testarchitektur von 5 einschließlich einer verbrückten Konfiguration des Parallel-Testbusses bildlich darstellt;
  • 11 ist ein Blockdiagramm, welches die parallele Testarchitektur von 5 einschließlich einer alternativen verbrückten Konfiguration des Parallel-Testbusses bildlich darstellt;
  • 12 ist ein Blockdiagramm, welches die parallele Testarchitektur von 5 einschließlich einer Parallel-Testbusanordnung bildlich darstellt, die die analoge Prüfung unterstützt;
  • 13 ist ein Blockdiagramm, welches den adressierbaren TAP-Linker von 6 bildlich darstellt, der konfiguriert ist, um die analoge Prüfung zu unterstützen;
  • 14a ist ein Fließdiagramm, das ein Verfahren zum Durchführen der parallelen Prüfung einer Mehrzahl von Prüflingen mit paralleler Testarchitektur von 5, betriebsmäßig in einer Weise entsprechend der vorliegenden Erfindung veranschaulicht; und
  • 14b ist ein Fließdiagramm, das ein Verfahren zum Durchführen von Board-zu-BoardVerknüpfungstesten an einer Mehrzahl von gedruckten Leiterplatten in einem Platineneinschub unter Verwendung der Parallel-Testarchitektur von 5 betriebsmäßig in einer Weise entsprechend der vorliegenden Erfindung veranschaulicht.
  • AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
  • 5 stellt eine veranschaulichende Ausführungsform einer Parallel-Test-Architektur (PTA) 500 in Übereinstimmung mit der vorliegenden Erfindung bildlich dar. In der erläuterten Ausführungsform wird ein Test-Controller 502 an einen Parallel-Test-Bus (PTB) 504 angeschlossen. Zum Beispiel kann der Test-Controller 502 entweder ein gesonderter externer Test-Controller oder ein eingebetteter Master-Controller sein, zum Beispiel eingebettet mit dem System einschließlich der Units Under Test (UUTs) 506.1-506.n. Der Test-Controller 502 wird konfiguriert, um über den PTB 504 mit dem Protokoll der PTA 500 zu kommunizieren, das unten beschrieben ist. In dieser erläuterten Ausführungsform werden die UUTs 506.1-506.n an den PTB 504 über jeweilige adressierbare PTB-Controllerkreise 508.1-508.n angeschlossen. Weiterhin kann die PTA 500 von 1-n UUTs, angeschlossen an den PTB 504, aufweisen. Auf eine beliebige verwendbare Zahl von UUTs kann dann parallel zu Prüf- und/oder Fehlerbeseitigungs-Zwecken oder für die Konfiguration von programmierbaren Kreisen zugegriffen werden. Andererseits kann auf jeweilige UUTs einzeln zugegriffen werden.
  • Zum Beispiel kann der Test-Controller 502 einen universellen Computer oder einen PC enthalten, einschließlich zumindest eines Speichers, wie schreibgeschützten Speicher (ROM) und RAM (RAM) für die Speicherung von Daten, von Betriebssystemen und von Anwendersoftwaremodulen für die Prüfung, das Fehlerbeseitigen oder das programmierbare Konfigurieren der UUTs 506.1-506.n und zumindest eines Prozessors für das Steuern der jeweiligen PTB-Controllerkreise 508.1-508.n über das PTB 504 und ausführende elektronische Kreis-Test-/Fehlerbeseitigungs-/Konfigurations-Anwendungen.
  • Der PTB 504 erleichtert die Kommunikation zwischen dem Test-Controller 502 und den UUTs 506.1-506.n über die jeweiligen adressierbaren PTB-Controllerkreise 508.1-508.n. Es wird angemerkt, dass der PTB-Controller in einer Vielzahl von Wegen implementiert werden kann. Zum Beispiel kann der PTB-Controller als einzelnes Bauelement, d.h. getrennt von den UUTs 506.1-506.n und dem Test-Controller 502, implementiert werden. Andererseits kann der PTB-Controller als eine Anzahl von gesonderten Bauelementen implementiert werden, zum Beispiel angebracht auf einem PCB oder eingebettet als Teil eines UUTs.
  • In der erläuterten Ausführungsform handhabt jeder PTB-Controller 508.1-508.n lokale Kommunikationen mit einer jeweiligen UUT 506.1-506.n. Das Protokoll, das zur lokalen Kommunikation zwischen dem PTB-Controller und der UUT, angeschlossen daran, verwendet wird, ist das Standard-IEEE 1149.1-Protokoll. Dementsprechend kann ein PTA-System so konfiguriert und implementiert werden, dass bestehendes UUTs direkt zur Standard-IEEE 1149.1-Schnittstelle der PTB-Controller Schnittstellen-mäßig angeschlossen werden können.
  • Weitere Details zu PTB 504, PTB-Controller 508.1-508.n und PTA-Protokoll und Betrieb werden in den folgenden Abschnitten erläutert.
  • Paralleler Test-Bus (PTB)
  • 6 stellt einen beispielhaften Parallel-Test-Bus (PTB) Controller 508 bildlich dar, der an PTB 504 angeschlossen ist (s. 5). In der erläuterten Ausführungsform enthält PTB 504 einen ausgedehnten Multi-Drop-TAP-Bus. Wie in 6 gezeigt, hat PTB 504 Standard-IEEE 1149.1-Signale TCK, TMS, TDI, TDO und TMS. Außerdem schließt PTB 504 Expected-Data-In (EDI) und Mask-Data-In (MDI) Signale ein.
  • Die EDI- und MDI-Signale werden bereitgestellt, damit die PTA 500 Scan-out-Daten parallel für alle UUTs 506.1-506.n überprüft und verifiziert. Dementsprechend sind der Test-Controller 502 und das PTA-Protokoll betriebsfähig zur Bereitstellung der erwarteten Scan-out-Daten bezüglich des EDI-Signals von PTB 504, das dann gegen die tatsächlichen TDO Daten verglichen werden kann, die von UUTs 506.1-506.n kommen.
  • Außerdem wird der Test-Controller 502 konfiguriert, um eine Maske für die erwarteten TDO Daten auf MDI-Signal des PTB 504 bereit zu stellen. Dieses geschieht, damit alle möglichen erwarteten TDO Daten, spezifiziert als "X" (d.h., ein unbestimmter oder unbekannter Logikwert) für UUTs 506.1-506.n während der Überprüfung von Scan-out-Daten maskiert oder ignoriert werden können. Dementsprechend erlauben die EDI- und MDI-Signale in der PTA 500, dass die Überprüfung der Daten TDO der UUTs am Ort, d.h. durch jeden der jeweiligen PTB-Controller 508.1-508.n anstatt durch den Test-Controller 502 erfolgt.
  • Resultierend aus dem Verwenden der Multi-Drop-Busanordnung für den PTB 504, stellt die PTA 500 einen optimalen Weg der parallelen Prüfung von Mehrfach-UUTs zur Verfügung. Unter Verwendung des Multi-Drop PTB 504 erfordert die PTA 500 keine gesonderten TDO-Leitungen für jede UUT, weil die TDOs parallel an die PTB-Controller 508.1-508.n angeschlossen werden. Dieses beseitigt eine bedeutende Anzahl von Leitungen in den Anschlüssen zu den UUTs 506.1-506.n. Weiterhin ermöglicht die Einbeziehung der EDI und MDI-Signale an dem PTB 504 einen verteilten Überprüfungsansatz für Scan-out-Daten, in denen alle von den UUTs 506.1-506.n gleichzeitig geprüft werden können.
  • Obgleich die TDOs parallel im Bus erfolgen, unterstützt der PTB 504 Kommunikation zu einer einzelnen ausgewählten UUT und kann, wenn es gewünscht wird, die tatsächlichen TDO Daten von der ausgewählten UUT zurück empfangen. So zum Beispiel kann der Test-Controller 502 benutzt werden, um Fehlerbeseitigen, oder Reparatur ausgewählter UUT durchzuführen. Weiterhin kann die Implementierung von dem PTB 504 entsprechend der bestimmten Testanwendung angepasst und optimiert werden. Zum Beispiel kann im Fall der Wafersonde, PTB 504 in ein ATE implementiert werden, d.h. getrennt von der parallel zu prüfenden Die. Andererseits kann der PTB 504 zusammen mit den UUTs 506.1-506.n in einer abschließenden Systemkonfiguration, zum Beispiel zusammen mit dem Systemplatineneinschub, implementiert werden. Es sollte angemerkt werden, dass die PTA 500, einschließlich PTB 504, konfiguriert werden kann, um andere Scan-Protokolle und/oder Verfahrensweisen anstelle der IEEE 1149.1 Scan-Verfahrensweise, die oben beschrieben wird, zu verwenden oder zu unterstützen.
  • Adressierbarer PTB-Controller
  • 6 stellt den beispielhaften PTB-Controller 508 bildlich dar. Wie in 6 gezeigt, schließt der PTB-Controller 508 einen adressierbaren TAP-Linker (ATL) 602 ein, der für das Adressieren und das Auswählen der PTB-Controller 508.1-508.n auf dem PTB 504 und Kontroll-Scan-Zugriff zu den UUTs 506.1-506.n sorgt (s. 5). Es wird angemerkt, dass der ATL Kreis 602 in den Multi-Drop Scan-Bus-Anwendungen als Stand Alone-Implementierung, d.h. getrennt von dem PTB-Controller 508 eingesetzt werden kann, wobei parallele Testfähigkeit nicht erforderlich ist. In der erläuterten Ausführungsform gibt es ein ATL 602, angeschlossen an PTB 504 pro UUT. Folglich können die Mehrfach-PTB-Controller 508.1-508.n an PTB 504 angeschlossen werden, und wiederum kann jeder der jeweiligen ATL in den PTB-Controllern 508.1-508.n zu einer einzigen UUT und zum PTB 504 angeschlossen werden. Der PTB-Controllerkreis 508 schließt weiterhin einen Maskier- und Vergleichs-Kreis 604, einen Digital I/O (DIO)-Kreis 606, einen PTB Auto-Start-Kreis 608 und einen Programmierbaren I/O Spannungskreis 610 ein. Jeder der Funktionsblöcke von PTB-Controller 508 wird nachstehend beschrieben.
  • Adressierbarer TAP-Linker
  • Wie in 6 gezeigt, schließt das ATL 602 an den PTB 504 über die Standard-IEEE 1149.1 Signale TCK, TMS, TDI, TDO und TMS an. Dieser Anschluss an Multi-Drop PTB Bus 504 wird von Test-Controller 502 benutzt, um mit dem ATL 602 und den anderen Kreisen 604, 606, 608, und 610, enthalten im PTB-Controller 508, unter Verwendung des PTA-Protokolls zu kommunizieren. Weiterhin schließt ATL 602 an eine jeweilige UUT (nicht gezeigt) und an die anderen Kreise 604, 606, 608 und 610 des PTB-Controllers an.
  • Auf der UUT Seite ist ATL 602 schnittstellenmäßig an einen TAP-Bus der UUT angeschlossen. ATL gibt Signale TDO_UUT, TMS_UUT, TCK_UUT und TRSTN_UUT zur UUT aus. Diese Signale schließen an die entsprechenden TAP-Inputs des UUT an (zum Beispiel, schließt der TDO_UUT-Output an den TDI-Input der UUT an). Weiterhin hat der ATL 602 ein TDI_UUT Input-Signal, das an den TDO-Output der UUT anschließt. In der PTA 500 (s. 5) verwendet der Test-Controller 502 diese ATL Schnittstelle zum TAP der UUTs, um das IEEE 1149.1-Protokoll zwischen den UUTs 506.1-506.n und den PTB-Controllern 508.1-508.n an PTB 504 zu handhaben. ATL 602 steuert die UUT TAPs, basierend auf dem PTA-Protokoll und ob oder nicht auf die UUTs 506.1-506.n parallel zugegriffen wird oder eine spezielle UUT, die an den ATL 602 angeschlossen ist, zugegriffen wird (zum Beispiel, zum Überprüfen von TDO-Daten einer bestimmten UUT bezüglich PTB 504). In der erläuterten Ausführungsform schließt ATL 602 auch schnittstellenmäßig an den Maskier- und Vergleichs-Kreis 604, den digitalen I/O-Kreis 606, den PTB Auto-Start-Kreis 608 und den programmierbaren I/O Spannungs-Kreis 610 an.
  • ATL 602 liefert eine Anzahl von Eigenschaften für das Adressieren und das Auswählen von UUTs, wie unten beschrieben.
  • UUTs Adressieren und Auswählen
  • Wie in 6 gezeigt, empfängt ATL 602 Inputs auf dem ATL_ADDR[n:0]-Bus und auf dem UUT ID[n:0]-Bus. Diese Inputs ermöglichen dem Test-Controller 502 (s. 5) UUTs 506.1-506.n, die an die jeweiligen PTB-Controller 508.1-508.n über PTB 504 angeschlossen sind, zu adressieren und auszuwählen.
  • In der erläuterten Ausführungsform implementieren alle PTB-Controller 508.1-508.n, die an PTB 504 angeschlossen sind, eine n+1-Bit ATL Adresse, die zu ATL 602 auf der ATL_ADDR[n:0] Leitung eingegeben wird. Die ATL Adresse wird so konfiguriert, dass jedem der PTB-Controller 508.1-508.n auf dem PTB 504 eine einzigartige Adresse zugewiesen werden kann. Diese Adresse ermöglicht es dem Test-Controller 502, einen der PTB-Controller 508.1-508.n auf dem Multi-Drop PTB 504 einzigartig zu adressieren und auszuwählen. Wenn zum Beispiel PTB konfiguriert wurden, um bis zu 16 UUTs zu unterstützen, dann würde zumindest eine 4-bit ATL Adresse so eingeführt, dass es ATL_ADDR[3:0]-Inputs gibt, um bis 16 einzigartige ATL Adressen bereitzustellen.
  • Die UUT-ID, die zum ATL 602 auf den UUT_ID[n:0]-Leitungen eingegeben wird, wird verwendet, um UUT Kennzeichnungs-Daten für den Test-Controller 502 für die UUTs 506.1-506.n, die an die jeweiligen PTB-Controller 508.1-508.n im PTA 500 angeschlossen sind, bereit zu stellen. In der erläuterten Ausführungsform liefert die UUT ID den UUT Typ und, gegebenenfalls, die UUT Version, UUT Hersteller und/oder andere Daten, die verwendet werden, um die UUT zu kennzeichnen. Wenn eine PTA Implementierung so ist, dass alle UUTs von dem gleichen Typ und Version sind, dann können die UUT_ID[n:0]-Inputs zum ATL 602 möglicherweise nicht erforderlich sein. In diesem Fall kann ATL 602 ohne diese Inputs konfiguriert werden, oder die UUT_ID[n:0]-Leitungen können an einige vorbestimmte oder Vorgabe-Logikwert gebunden werden. Wenn mehrere Typen (oder Versionen) von UUTs in der gleichen PTA implementiert sind, wird die UUT-ID so konfiguriert, dass alle unterstützten UUT Typen eine einzigartige Zuweisung haben können. Die UUT ID ermöglicht es dem Test-Controller 502, UUTs vom gleichen Typ, Version, usw., gleichzeitig, d.h. als Gruppe, zu adressieren und auszuwählen.
  • Wie vorstehend beschrieben, gestatten die ATL Adresse und die UUT ID das Adressieren und das Auswählen von einem oder mehreren UUTs, abhängig von der Adressierungsart, die von dem Test-Controller 502 verwendet wird. In der erläuterten Ausführungsform unterstützt der ATL 602 die folgenden Adressierungsarten:
    ATL Adressen-Modus. Diese Adressierungsart wählt einzigartig die UUT aus, die auf ihrem ATL Adresswert basiert. In diesem Modus kann nur eine einzige UUT ausgewählt werden, da alle ATL Adressen einzigartig einem PTB-Controller zugewiesen sind. Der PTB-Controller, der in diesem Modus ausgewählt wird, kann veranlasst werden, sein TDO heraus auf den PTB zu steuern.
  • Der UUT Modus. Dieser adressiert UUTs, basierend auf ihrem UUT Typ, usw. wie durch die UUT ID gegeben. Der UUT Typ Modus erlaubt ein Aussenden an alle UUTs vom gleichen Typ, Revision und/oder dem Hersteller. In diesem Modus ist der PTB-Controller nicht in der Lage, sein TDO auf dem PTB anzusteuern (d.h., sein TDO ist tristated [im Dreierzustand]).
  • Gruppen-Adressen-Modus. Dieser ist ein programmierbarer Adressierungsmodus, bei dem der Test-Controller jedem PTB-Controller eine Gruppen-Adresse zuweist. Mehrfache PTB-Controller können mit der gleichen Gruppen-Adresse programmiert werden. Infolgedessen kann der Test-Controller unter Verwendung des Gruppen-Adressen-Modus mit zwei oder mehr UUTs als Gruppe kommunizieren. Dies ermöglicht es, zu allen UUTs oder zu einer auserwählten Gruppe von UUTs auszusenden, basierend auf bestimmten Eigenschaften des UUT zum Beispiel seine Hardwareversion, oder welche Komponenten/Funktionen es mit einschließen kann. Bei diesem Modus wird es dem PTB-Controller nicht ermöglicht, seinen TDO auf PTB zu steuern (d.h., sein TDO ist "tristated").
  • Alias-Adress-Modus. Dieses ist ein programmierbarer Adressierungsmodus, der dem Gruppen-Adress-Modus ähnlich ist. Jedoch erlaubt der Alias-Modus auch das einzigartige Adressieren eines einzelnen PTB-Controllers. In diesem Fall, d.h. wenn ein einzigartiger Alias einer einzelnen UUT zugewiesen wird, kann es dem PTB-Controller ermöglicht werden, seinen TDO auf den PTB zu steuern.
  • Dementsprechend ermöglicht der ATL Adress-Modus Auswählen einer einzelnen UUT und erlaubt, dass TDO der UUTs in die Lage versetzt wird, auf den PTB und die Scan-out-Daten zu steuern, die nachher durch den Test-Controller empfangen werden. Dieser Modus kann für die Prüfung oder Konfiguration einer einzelnen UUT und für die Bereitstellung von TDI Daten ausschließlich zur ausgewählten UUT verwendet werden, während alle anderen UUTs gesteuert werden, um die Daten zu ignorieren. So kann der ATL Adress-Modus für Fehlerbeseitigen, Diagnose und Reparatur, wenn es notwendig ist, Daten zu nur einer UUT zu schicken oder die tatsächlichen TDO-Output Daten vom UUT mit dem Test-Controller zu überprüfen, verwendet werden. Die Typ- und Gruppe-Modi erlauben das Senden zu mehreren Boards und können für parallele Konfiguration oder die Prüfung mit PTA 500 verwendet werden. Außerdem erlaubt der Alias-Modus eine einzigartige Alias-Adresse zuzuweisen, wobei es in diesem Fall dem PTB-Controller ermöglicht werden kann, das TDO von PTB zu steuern. Zuweisen einer einzigartigen Alias-Adresse erlaubt einem Satz Vektoren programmierbares Konfigurieren oder Prüfen einer UUT, um unabhängig von der ATL-Adresse zu sein. Diese Eigenschaft von ATL 602 erleichtert Wiederverwendung der Testvektoren in der Multi-Drop Test-Bus-Implemen-tierung von der PTA 500.
  • PTB Auto-Start
  • Wie in 6 gezeigt, sind die ATL 602 schnittstellenmäßig am PTB Auto-Start-Kreis 608, der konfiguriert ist, um zurück zu dem Test-Controller 502 (5) auf das START-Signal des PTB 504 zu signalisieren, dass alle von den zu prüfenden UUTs 506.1-506.n vorliegen und dass der Test-Controller 502 die Prüfungs-Reihenfolge einleiten kann. Diese automatische Startfähigkeit ermöglicht der PTA 500, die Prüfung in einer Produktionsumgebung ohne Eingriff eines Bedienenden automatisch einzuleiten.
  • In der erläuterten Ausführungsform empfängt der PTB Auto-Start-Kreis 608 ein UUT_PRESENT Signal von der UUT. Das UUT_PRESENT Signal wird zum PTB Auto-Start-Kreis 608 eingegeben und wird bestätigt, wenn ein UUT an den PTB-Controller 508 angeschlossen wird. Die Bestätigung von UUT_PRESENT signalisiert dem PTB Auto-Start-Kreis 608, dass diese UUT an den UUT Bus des ATL 602 angeschlossen ist und für einen Zugriff bereit ist. Wenn einmal alle zu prüfenden UUTs 506.1-506.n an ihre zugehörigen PTB-Controller 508.1-508.n angeschlossen sind, wird das START-Signal am PTB 504 bestätigt und durch den Test-Controller 502 empfangen.
  • Der ATL 602 ist schnittstellenmäßig am PTB Auto-Start-Kreis 608, sodass der Auto-Start ermöglicht oder gesperrt bzw. abgestellt wird, abhängig davon, ob von der UUT für diesen PTB-Controller 508 erwartet wird, anwesend zu sein oder nicht. Wenn alle der UUTs 506.1-506.n (s. 5) nicht im PTA-System bestückt werden, kann ein Benutzer (zum Beispiel, ein Bedienender oder ein Programm, das auf den Test-Controller 502 läuft) anzeigen, welche UUTs über dem Test-Controller 502 nicht anwesend sind. Der ATL 602 weiß dann, um jede mögliche Fehlerprüfung und den PTB Auto-Start-Kreis 608 für diese bestimmte UUT zu sperren. Wenn ein gegebener PTB Auto-Start-Kreis 608 gesperrt bzw. abgestellt worden ist und der Benutzer eine UUT anschließt, dann erkennt der PTB Auto-Start-Kreis 608 diese Bedingung und stellt ein Warn-Status-Bit ein, das über die Schnittstelle von ATL 602 gelesen werden kann.
  • Daten maskieren und vergleichen
  • Wie in 6 gezeigt, wird der Maskier- und Vergleichs-Kreis 604 an PTB 504 und schnittstellenmäßig an ATL 602 angeschlossen. Der Maskier- und Vergleichs-Kreis 604 empfängt die EDI- und MDI-Signale vom PTB 504 und vom Actual-Data-In (ADI)-Signal vom ATL 602 und verwendet sie, um Scan-Daten von der UUT und/oder vom digitalen I/O-Kreis 606 zu überprüfen und zu verifizieren. Die erwarteten Scan-Daten werden auf dem EDI-Signal des PTB 504 empfangen und werden mit den tatsächlichen Scan-Daten von der UUT verglichen, empfangen auf dem ADI-Signal vom ATL 602, wenn er ausgewählt ist. Wenn der PTB-Controller 508 nicht-ausgewählt ist, wird Maskier- und Vergleichs-Kreis 604 automatisch gesperrt bzw. abgestellt. Während des Scan-Betriebs gibt das ATL 602 ein, welche Scan-Wege bzw. Scan-Paths auch immer durch ATL 602 auf ADI konfiguriert werden, zum Beispiel IR Scan-Daten, TDI_UUT Daten und/oder Scan-Out-Daten vom digitalen I/O Kreis 606. EDI und ADI werden Bit für Bit verglichen, da sie seriell in den Maskier- und Vergleichs-Kreis 604 verschoben sind. Der PTB-Controller 508 kann diese TDO Daten auch auf PTB 504 ausgeben, wenn er einzigartig ausgewählt wird. Das Resultat von jedem Vergleichsbit ist entweder ein Bestehen oder Nicht-Bestehen, abhängig davon, ob die erwarteten und aktuellen Datenbits "vergleichen" beziehungsweise "fehlvergleichen [Miscompare]".
  • Wenn ein Bit in den erwarteten Scan-Daten, bereitgestellt am EDI, zu einem X spezifiziert wird, kann es mit Daten bezüglich der MDI Leitung des PTB 504 maskiert werden. Jedes Scan-Bit von EDI hat ein entsprechendes Bit in den Scan-Masken-Daten von MDI, das bestätigt wird, um den Wert des entsprechenden ADI Scan-Bits zu ignorieren. Dementsprechend bestehen Bits, die in den EDI Scan-Daten maskiert werden, den Bit-Vergleich mit den entsprechenden ADI Daten, unabhängig von dem ADI Wert. So kann die Überprüfung aller möglicher ADI Scan-Daten-Bits durch den Maskier- und Vergleichs-Kreis 602, wo MDI bestätigt wird, keinen Testfehler verursachen.
  • Wie oben erwähnt, ist der Maskier- und Vergleichs-Kreis 604 schnittstellenmäßig an ATL 602. Diese Schnittstelle ermöglicht dem Test-Controller 502, die Funktionen in dem Maskier- und Vergleichs-Kreis 604 zu steuern bzw. regeln. In der erläuterten Ausführungsform registriert Maskier- und Vergleichs-Kreis 604 einen Bestehen/Nicht-Bestehen-Status, der vom Test-Controller 502 über eine ATL TAP-Anweisung abgefragt werden kann. Dieses ermöglicht PTA 500, Test oder Überprüfung an einer Anzahl von UUTs parallel durchzuführen und einen Bestehen/Nicht-Bestehen-Status zurück von jedem der zugehörigen PTB-Controller zu empfangen. Dementsprechend kann der Test-Controller 502 einen. Test parallel auf vielen UUTs laufen lassen und dann jeden PTB-Controller überprüfen, um zu sehen, ob es einen Ausfall für die zugehörige UUT gibt. Auf ausgefallene UUTs kann dann unter Verwendung des normalen TDI-TDO Zugriffs von PTB 504 einzeln zugegriffen werden, wenn irgendeine Diagnose und Reparatur der UUT notwendig ist.
  • Der Maskier- und Vergleichs-Kreis 604 kann weitere Funktionsfähigkeiten haben, die über die Schnittstelle zu ATL 602 gesteuert bzw. geregelt werden. In der erläuterten Ausführungsform gibt es eine Aktivierungs-/Sperr-Funktion für den Maskier- und Vergleichs-Kreis 604. Diese gewährt Vergleichsvorgänge und das Festhalten des Bestehen/Nicht-Bestehen-Status im PTB-Controller 508, um manuell gesperrt bzw. abgestellt zu werden. Weiterhin kann der Maskier- und Vergleichs-Kreis 604 bestimmte Maßnahmen nach Detektion eines Miscompare ergreifen. In der erläuterten Ausführungsform veranlasst ein Miscompare die UUT, in ihren Test-Logic-Reset-Zustand gezwungen zu werden, wenn ein Ausfall ermittelt wird. Dies erfolgt automatisch durch den PTB-Controller 508, indem man die TMS UUT in den TLR_Modus zwingt. Weiterhin lässt der PTB-Controller 508 den gegenwärtigen Scan-Betrieb ablaufen, bevor er die UUT in ihren Test-Logic-Reset-Zustand zwingt. Dementsprechend wird der TLR_Modus anschließend an Update-DR oder Update-Update-IR vom gegenwärtigen Scan-Betrieb hergestellt. Dieses verhindert potenzielle Beschädigung der UUT wegen eines Herstellungsdefektes, wie durch das Miscompare der erwarteten Scan-Daten ermittelt.
  • Wie oben beschrieben, erlaubt der Maskier- und Vergleichs-Kreis 604, Datenvergleiche für alle UUTs vom gleichen Typ parallel durchzuführen. Die EDI und MDI-Signale des PTB und sein Anschluss an Maskier- und Vergleichs-Kreis 604 ermöglichen diese parallele Test- und Überprüfungsfähigkeit. Diese Merkmale ermöglichen gleichzeitige Überprüfung von TDO-Daten jeder UUTs, d.h. parallel, durch jeden der PTB-Controller 508.1-508.n anstatt durch den Test-Controller 502, wodurch die Testzeit der UUTs 506.1-506.n optimiert wird. Infolgedessen ist die Zeit, n UUTs des gleichen Typs, die die PTA 500 verwendet, zu prüfen, gleich der Zeit, die sie selbst braucht, um ein einzelnes UUT zu prüfen.
  • Digital I/O
  • Wie in 6 gezeigt, schließt der PTB-Controller 508 den Digital I/O (DIO)-Kreis 606 ein, der zum ATL 602 und der UUT schnittstellenmäßig anschließt. Der DIO Kreis 606 versieht die UUT, die an den PTB-Controller 508 angeschlossen ist, mit einer Anzahl von parallelen (d.h., "Breitseite") Inputs und Outputs DIO_UUT[n:0]. Die DIO_OUT Leitungen können über PTB 504 durch den Test-Controller 502 oder direkt durch ATL 602 kontrolliert werden und können zusätzlich zur Scan-Schnittstelle zum UUT verwendet werden, um die Prüfung, das Fehlerbeseitigen oder die Konfiguration der UUT zu erleichtern. In der erläuterten Ausführungsform werden die DIO_UUT Leitungen als programmierbare Input/Output (d.h., bidirektionale)-Signale implementiert. Andererseits kann jede der DIO_UUT Leitungen als ein festgelegtes Input- oder Output-Signal implementiert werden.
  • In der erläuterten Ausführungsform hat der DIO Kreis 606 eine serielle Schnittstelle zu ATL 602, über die auf die Input/Output Daten- und Richtungssteuerung der DIO_UUT Leitungen zugegriffen werden kann. Weiterhin kann der DIO Kreis 606 über die serielle Schnittstelle zu ATL 602 entweder zum Beispiel durch das normale TDI-TDO von PTB 504 separat erreicht werden, oder seriell mit dem Scan-Weg der UUT verkettet werden. Dies ermöglicht Zugriff auf die parallelen I/O Leitungen des DIO Kreises 606 durch den Test-Controller 502 über den PTB 504 zusammen mit den Scan-Daten für die UUT. Infolgedessen können alle parallelen Daten vom UUT Input zu den DIO_UUT Leitungen auf den TDI UUT Input serialisiert werden. Sie können an ADI-Output von ATL 602 zu dem Maskier- und Vergleichs-Kreis 604 geschickt werden und unter Verwendung der EDI und MDI-Daten vom Test-Controller 502 überprüft werden.
  • Programmierbare I/O-Spannung
  • Wie in 6 gezeigt worden ist, schließt der PTB-Controller 508 weiterhin den programmierbaren I/O Spannungs-Kreis 610 ein, der auch schnittstellenmäßig an ATL 602 anschließt. In der erläuterten Ausführungsform wird der programmierbare I/O Spannungs-Kreis 610 benutzt, um die Spannungshöhe für die UUT Schnittstelle einzustellen, damit elektrische Kompatibilität mit der UUT und dem geeigneten Betrieb mit der ATL Schnittstelle gesichert ist. Durch die Schnittstelle mit ATL 602 kann die Schwelle für die Logik 1 oder die "hohe" Spannungshöhe durch den programmierbaren I/O Spannungs-Kreis 610 eingestellt werden und nachher gesteuert werden. Zum Beispiel kann die Spannung als 5 Volt, 3.3 Volt, usw., abhängig von den speziellen Technologieanforderungen der UUT Schnittstelle ausgewählt werden. Außerdem kann die Spannung vom programmierbaren I/O Spannungs-Kreis 610 abgestellt werden oder so eingestellt werden, dass eine von außen zugeführte (zum Beispiel, durch den Benutzer) Spannungshöhe eingestellt werden kann, um die Schnittstelle zur UUT zu versorgen.
  • ATL Anweisungen
  • TAP-Controller-Anweisungen für ATL 602 (s. 6), wie im PTA 500 angewendet (5), werden nachstehend beschrieben. Die ATL TAP-Controlleranweisungen werden durch den Test-Controller 502 oder einen Master-Controller am PTB 504 ausgegeben. Der Test-Controller 502 verwendet diese ATL TAP-Anweisungen beim Kommunizieren mit den PTB-Controllern 508.1-508.n (s. 5), um die Merkmale der PTA 500 zugänglich zu machen. Da Mehrfach-ATLs parallel an dem PTB 504 angeschlossen werden und im Gleichtakt funktionieren, implementieren alle von den ATLs dieselben TAP-Controlleranweisungen und Befehlscodes. Für alle unten beschriebenen Anweisungen wird ATL 602 nicht befähigt, sein TDO an PTB 504 anzusteuern, es sei denn, dass es vorher mit seiner ATL Adresse oder einer einzigartigen Alias-Adresse ausgewählt wurde.
  • Es wird angemerkt, dass einige der Anweisungen, die unten beschrieben sind, abhängig von der bestimmten Konfiguration der Parallel-Testarchitektur, wahlweise sind. Wenn zum Beispiel ATL 602 in einer Stand Alone-Anwendung oder in anderer Anwendung verwendet wird, die nicht parallele Testfunktionen erfordert, können die COMPARE_STATUS und AUTO_START Anweisungen möglicherweise nicht implementiert werden, da sie Funktionen und Datenregister im PTB-Controller 508, die nicht für Stand-Alone ATL Betrieb erforderlich sind, steuern.
  • Überbrücken bzw. BYPASS – Diese Anweisung ist die Standard IEEE 1149.1 BYPASS Anweisung. Sie wählt ein Einzel-Bit-Bypass-Register im adressierbaren TAP Linker (ATL) 602 zwischen TDI und TDO aus. Wenn die unten beschriebene IDCODE-Anweisung nicht implementiert wird, wird die BYPASS-Anweisung in das Anweisungs-Register von ATL (IR) geladen, wenn es über den Parallel-Test-Bus (PTB) 504 zurückgestellt wird.
  • IDCODE – Die IDCODE-Anweisung kann verwendet werden, um das Device_ID-Register auszuwählen, das einen Standard-32-bit IEEE 1149.1 Identifizierungscode liefert. Das Device_ID Register im ATL 602 wird zwischen TDI und TDO ausgewählt. Wenn implementiert, wird die IDCODE-Anweisung in das IR von ATL geladen, wenn es zurückgestellt wird.
  • SAMPLE/PRELOAD – Diese Anweisung kann verwendet werden, um die I/O Stifte des PTB-Controllers 508 zu prüfen, oder, vorher Werte in die Boundary-Scan-Zellen des PTB-Controllers zu laden. Es wird angemerkt, dass der PTB-Controller 508 dedizierte Teststifte haben kann, die mit der IEEE 1149.1 Boundary-Scan-Architektur nicht völlig übereinstimmen. So kann diese Anweisung nicht auf jeden Stift des PTB-Controllers 508 zugreifen.
  • EXTEST – Diese Anweisung ist der Standard-IEEE 1149.1 EXTEST-Anweisung ähnlich. Wie in der SAMPLE/PRELOAD Anweisung können die dedizierten Teststifte des PTB-Controllers 508 nicht völlig mit der IEEE 1149.1 Boundary-Scan-Architektur übereinstimmen, und folglich kann die EXTEST Anweisung nicht jeden Stift von dem PTB-Controller 508 steuern bzw. regeln.
  • LORD_ATL_ADDR – Die LORD_ATL_ADDR Anweisung wird implementiert, wenn der ATL 602 für das Laden einer ATL Adresse sorgt. In der erläuterten Ausführungsform sind die ATL_ADDR Inputs direkte Parallel-Inputs zum PTB-Controller 508 und die LORD_ATL_ADDR Anweisung ist folglich nicht implementiert.
  • Wenn implementiert, veranlasst die LORD_ATL_ADDR Anweisung ATL-Adresse von den ATL_ADDR-Inputs des ATLs, in das ATL_Address-Register aufgenommen zu werden. Abhängig von der Implementierung wird sie entweder seriell geladen (zum Beispiel, im ATL TAP Run-Test/Idle-Zustand des Controllers) oder direkt von den ATL_ADDR Inputs aufgenommen. In jedem Fall ist das ATL_Address-Register die gleiche Größe, d.h. n+1 Bits, wie durch eine Implementierung mit parallelen ATL_ADDR Inputs erforderlich wäre. Der Test-Controller 502 kann die ATL-Adresse überprüfen, die im ATL_Address-Register aufgenommen wird, wenn das ATL 602 ausgewählt wird.
  • SELECT_ATL – Die SELECT_ATL Anweisung wird verwendet, um einen einzelnen PTB-Controller 508, basierend auf seiner ATL-Adresse, auszuwählen. Die SELECT_ATL Anweisung lädt seriell eine ATL Adresse vom Test-Controller 502 in das Select_ATL Register und vergleicht sie mit den ATL_ADDR-Inputs zu ATL 602 oder mit dem ATL_Address-Register (d.h., wie durch die LORD_ATL_ADDR Anweisung geladen wurde). Das Select_ATL Register wird konfiguriert, um die gleiche Größe, d.h. n+1 Bits, aufzuweisen, wie die ATL_ADDR Inputs (oder das ATL_Address-Register). Wenn die LORD_ATL_ADDR Anweisung nicht implementiert wird, nimmt die SELECT_ATL Anweisung die ATL_ADDR-Inputs in das Select_ATL Register auf (d.h., während Capture-DR vor dem Shifting in die ATL Adresse vom Test-Controller 502).
  • Wenn das Select_ATL Register mit den ATL_ADDR-Inputs (oder dem ATL_Address-Register) vergleicht, wird der PTB-Controller 508 einzigartig ausgewählt und seinem TDO wird ermöglicht, den PTB 504 anzusteuern. Sobald ausgewählt, kann der Test-Controller 502 andere Anweisungen herausgeben und mit der angebrachten UUT kommunizieren. Der PTB-Controller 508 bleibt ausgewählt, bis eine UNSELECT_ALL Anweisung (wie unten beschrieben) herausgegeben wird, eine andere Anweisung herausgegeben, die nicht diesen PTB-Controller 508 auswählt, wird (zum Beispiel, eine SELECT_ALIAS Anweisung, die eine ATL Adresse für einen anderen PTB-Controller lädt) oder der ATL wird zurückgestellt. Nach einer SELECT_ATL Anweisung kann der Test-Controller 502 eine andere Anweisung, wie die BYPASS oder IDCODE Anweisung, herausgeben, um zu überprüfen, dass ein PTB-Controller ausgewählt wurde und steuert folglich Daten auf TDO von PTB.
  • LOAD_UUT_ID – Die LOAD_UUT_ID Anweisung wird implementiert, wenn ATL 602 für das Laden eines UUT Codes sorgt. In der erläuterten Ausführungsform wird das Laden des UUT ID nicht bereitgestellt und die UUT ID wird direkt von den UUT_ID Leitungen des PTB-Controllers 508 eingegeben.
  • Wenn implementiert, veranlasst die LOAD_UUT_ID Anweisung die UUD ID von den UUT_ID[n:0] Inputs von ATL, in das UUT_ID Register aufgenommen zu werden. Abhängig von der Implementierung wird sie entweder seriell geladen (zum Beispiel, im ATL TAP Run-Test/Idle-Zustand des Controllers) oder direkt von den UUT_ID[n:0 Inputs] geladen. Der Test-Controller 502 kann die UUT ID, die im UUT_ID Register aufgenommen wird, überprüfen, wenn ATL 602 ausgewählt wird.
  • SELECT_TYPE – Die SELECT_TYPE Anweisung lädt seriell einen UUT Typ vom Test-Controller 502 in das Select_Type Register und vergleicht ihn mit den UUT Typ-Bits der UUT ID. In Abhängigkeit von der Implementierung ist der UUT Typ ein Bit-Feld im UUT_ID Register, oder direkt Input auf die UUI_ID[n:0]-Leitungen von ATL 602. Der UUT Typ wird konfiguriert, um die gleiche Zahl Bits zu sein, wie das UUT Typ Feld im UUT_ID Register oder von den Inputs UUT_ID[n:0]-Inputs. Wenn die LOAD_UUT_ID Anweisung nicht implementiert wird, nimmt die SELECT_TYPE Anweisung das UUT_ID in das Select_Type Register auf (d.h., während Capture-DR vor dem Shifting in den UUT Typ vom Test-Controller 502).
  • In der momentan offenbarten Ausführungsform des ATL 602 wird das Select_Type Register konfiguriert, um die UUT Typ- und UUT Herstellercodes zu vergleichen. In diesem Fall wird der UUT Typ von direkten Parallel-Inputs zum ATL 602 bereitgestellt und der UUT Hersteller wird als interner Code innerhalb des ATL 602 bereitgestellt. Dieses liefert einen Weg, in dem der UUT Typ vom Benutzer spezifiziert werden kann, und dennoch unabhängig von den UUT Typen anderer Händler ist, da unterschiedlichen Händlern einzigartige UUT Herstellercodes zugewiesen würden. Selbst wenn zwei Benutzer den gleichen UUT Typ einer UUT zuweisen, können sie somit noch unterschieden werden, wenn notwendig durch ihre einzigartigen Herstellercodes.
  • Wenn das Select_Type Register mit dem entsprechenden UUT Typ und UUT Hersteller vergleicht, wird der PTB-Controller 508 ausgewählt. Weil Mehrfach-PTB-Controller durch diese Anweisung (zum Beispiel, den gleichen Typ und den gleichen Verkäufer) ausgewählt werden können, wird seinem TDO nicht ermöglicht, auf PTB 504 zu steuern. Somit kommunizieren der Test-Controller 502 parallel mit allen UUTs des Typs, spezifiziert durch das Select_Type Register, aber ohne, dass dem PTB-Controller 508 ermöglicht wird, TDO auf den PTB 504 zu steuern.
  • PROGRAM_GROUP – Die PROGRAM_GROUP Anweisung lädt seriell das Group_Address-Register mit einer programmierbaren Gruppen-Adresse, wie durch den Test-Controller 502 zugewiesen. Wenn der PTB-Controller 508 vorher durch eine ATL Adresse oder eine einzigartige Alias-Adresse ausgewählt wurde, kann er in die Lage versetzt werden, TDO an PTB 504 zu steuern und der gegenwärtige Group_Address-Registerinhalt, wie im Zustand Capture-DR aufgenommen, kann ausgescannt werden und vom Test-Controller 502 überprüft werden. Das Group_Address-Register des ATL 602 wird aktualisiert, wenn der PTB-Controller 508 vorher ausgewählt wurde, d.h. durch eine ATL Adresse, Alias-Adresse, UUT Typ oder Gruppen-Adresse (siehe die unten beschriebene SELECT_GROUP Anweisung). Wenn der PTB-Controller 508 nicht-ausgewählt worden ist, wird die Aktualisierung des Group_Address-Registers gesperrt bzw. abgestellt. Das Group_Address-Register wird der alle-0-Adresse zugewiesen, wann immer ATL 602 zurückgestellt wird.
  • SELECT_GROUP – Unter Verwendung der SELECT_GROUP Anweisung kann eine Gruppen-Adresse vom Test-Controller 502 in das Select_Group Register seriell geladen werden und mit dem programmierbaren Group_Address-Register verglichen werden. Das Select_Group Register wird so konfiguriert, dass es die gleiche Zahl Bits wie das Group_Address-Register hat. Wenn die Gruppen-Adresse in dem Select_Group Register mit dem Group_Address-Register übereinstimmt, wird der PTB-Controller 508 ausgewählt. Da jedoch Mehrfach-PTB-Controller 508 durch diese Anweisung ausgewählt werden können, wird sein TDO nicht in die Lage versetzt, auf das PTB 504 zu steuern. So kommuniziert der Test-Controller 502 parallel mit allem UUTs, die der gleichen Gruppen-Adresse zugewiesen werden, aber ohne dass dem PTB-Controller in Verbindung 508 ermöglicht wird, TDO auf den PTB 504 zu steuern.
  • PROGRAM_ALIAS – Die PROGRAM_ALIAS Anweisung wird verwendet, um eine Alias-Adresse dem PTB-Controller 508 zuzuweisen. Diese Anweisung wählt das Alias_Address-Register und lädt es seriell mit einer programmierbaren Alias-Adresse, wie durch den Test-Controller 502 zugewiesen. Eine allgemeine Alias-Adresse kann allen PTB-Controllern oder einer speziellen Gruppe PTB-Controllern zugewiesen werden, oder eine einzigartige Alias-Adresse kann einem einzelnen PTB-Controller zugewiesen werden. Indem er ein gemeinsames Alias einer Gruppe PTB-Controllern zuweist, kann der Test-Controller 502 sie als Gruppe adressieren und auswählen und kann in die Lage versetzt werden, zu dieser Gruppe parallel zu übertragen. Dieses ist genauso wie in den PROGRAM_GROUP und SELECT_GROUP-Anweisungen. Indem man eine einzigartige Alias-Adresse einem einzelnen PTB-Controller zuweist, können Vektoren für programmierbares Konfigurieren oder Prüfen einer UUT unabhängig von der physischen ATL Adresse gebildet werden, wie spezifiziert oder geladen von den ATL_ADDR-Inputs zu ATL 602.
  • Das Alias_Address-Register wird nur aktualisiert, wenn der PTB-Controller 508 vorher, d.h. durch eine ATL Adresse, UUT Typ, Gruppen-Adresse oder andere Alias-Adresse, ausgewählt wurde (siehe unten beschriebene SELECT_ALIAS Anweisung). Wenn der PTB-Controller 508 nicht-ausgewählt worden ist, ist die Aktualisierung des Alias_Address-Registers gesperrt bzw. abgestellt. Das Alias_Address-Register wird konfiguriert, um ein Bit länger zu sein als das Select_ATL Register. Dieses Zusatzbit, genannt das Unique_Alias Bit, wird benutzt, um anzuzeigen, dass Alias_Address zu einer einzigartigen Alias-Adresse auf PTB 504 programmiert worden ist. In der erläuterten Ausführungsform wird das Unique_Alias Bit als das wichtigste Bit (MSB) des Alias_Address-Registers implementiert. Wenn das Unique_Alias Bit auf Logik 1 eingestellt wird, kann der ausgewählte PTB-Controller in die Lage versetzt werden, sein TDO auf PTB 504 zu steuern. Wenn er eine einzigartige Alias-Adresse zuweist, sichert der Test-Controller 502, dass solche Alias-Adresse zu einem jeweiligen PTB-Controller einzigartig ist. Das Alias_Address-Register wird mit einer alle-0-Adresse geladen, wenn das ATL zurückgestellt wird. Infolgedessen wird das Unique_Alias Bit in jedem PTB-Controller gelöscht, und somit ist die Anfangs-Alias-Adresse nicht einzigartig und der PTB-Controller wird nicht in die Lage versetzt, TDO anzusteuern.
  • SELECT_ALIAS – Die SELECT_ALIAS Anweisung lädt seriell eine Alias-Adresse vom Test-Controller 502 in das Select_Alias-Register und vergleicht sie mit dem programmierbaren Alias_Address-Register. Das auserwählte Alias-Register wird konfiguriert, um die gleiche Zahl Bits zu haben, wie das auserwählte ATL Register. Wenn die Alias-Adresse in den Select_Alias-Register mit der vom programmierbaren Alias_Address-Register übereinstimmt, wird der PTB-Controller 508 ausgewählt. Wenn man das Select_Alias-Register gegen das Alias_Address-Register vergleicht, wird das Unique_Alias Bit im Alias_Address-Register ignoriert. Wenn folglich das Select_Alias-Register und das Alias_ Address-Register übereinstimmen, bestimmt das Unique_Alias-Bit, wann der PTB-Controller 508 seinem TDO ermöglicht, PTB 504 anzusteuern. Da Mehrfach-PTB-Controller durch diese Anweisung ausgewählt werden können, wird einem bestimmter PTB-Controller nicht ermöglicht, TDO auf PTB 504 anzusteuern, es sei denn, der Test-Controller 502 hat beim Programmieren des Alias_Address-Registers das Unique_Alias-Bit eingestellt. Wenn somit mehrfache UUTs ausgewählt werden, kommuniziert der Test-Controller 502 parallel mit allen UUTs, d.h. jenen zur gleichen Alias-Adresse programmiert, aber ohne dass dem PTB-Controller 508 ermöglicht wird, TDO auf PTB 504 anzusteuern.
  • UNSELECT_ALL – Laden der UNSELECT_ALL Anweisung in IR von ATL 602 veranlasst alle PTB-Controller, in einen Zustand zu gelangen, in dem sie nicht-ausgewählt werden. Dieses ("unselects") wählt keine Auswahl, gebildet durch den gegenwärtigen Adressierungsmodus, d.h. ATL Adresse-Modus, UUT Typ-Modus, Gruppen-Modus oder Alias-Adresse-Modus, aus. Nach der UNSELCT_ALL Anweisung können keine der PTB-Controller in die Lage versetzt werden, TDO von PTB 504 anzusteuern. Die UNSELECT_ALL Anweisung wählt das Bypass-Register oder das Device_ID-Register aus, wenn die IDCODE Anweisung implementiert wird.
  • DIO_ACCESS – Die DIO_ACCESS-Anweisung wird verwendet, um auf das Datenregister zu greifen, das die DIO_UUT[n:0]-Leitungen steuert. Sie wählt das DIO_UUT Register im Digital I/O Kreis 606 zwischen TDI und TDO vom PTB 504 aus. Für diese Anweisung kann das ATL 602 seinem TDO nicht ermöglichen, den PTB 504 anzusteuern, es sei denn, es wurde vorher mit seiner ATL-Adresse oder einer einzigartigen Alias-Adresse ausgewählt. Weiterhin nimmt das DIO_UUT Register das Shifting und die Update-Daten auf, wenn der PTB-Controller 508 vorher aus gewählt wurde, d.h. durch eine ATL-Adressen-, UUT-Typ-, Gruppen-Adressen- oder Alias-Adressen-Übereinstimmung. Wenn folglich der PTB-Controller 508 einzigartig ausgewählt wurde, kann er in die Lage versetzt werden, sein TDO auf PTB 504 anzusteuern und der gegenwärtige DIO_UUT Registerinhalt kann heraus gescannt werden und vom Test-Controller 502 überprüft werden. Wenn der PTB-Controller 508 nicht-ausgewählt worden ist, sind Shifting, Update und Aufnahme-Betrieb des DIO_UUT Registers gesperrt bzw. abgestellt.
  • Die Daten, die vom DIO_UUT Register heraus gescannt werden, können auch selektiv auf den Maskier- und Vergleichs-Kreis 604 geroutet werden, sodass die DIO Daten mit MDI maskiert werden und gegen EDI-Signale von PTB verglichen werden können. Dies ermöglicht es, dass die vom UUT empfangenen Digital I/O parallel in jedem PTB-Controller, während der Prüfung der UUTs überprüft werden. Das DIO_UUT Register wird so zurückgestellt, dass alle UUT_DIO[n:0] Leitungen Inputs sind, wann immer ATL 602 zurückgestellt wird.
  • TMS_CONTROL – Diese Anweisung wird verwendet, um den Betrieb des UUT TAP-Controllers mit dem TAP-Controller von ATL 602 zu koordinieren. Sie ermöglicht dem Test-Controller 502, mit gerade dem ATL 602 zu kommunizieren, während der verbundene UUT TAP-Controller in einem stabilen Zustand gehalten wird, oder mit dem UUT über ATL 602 kommuniziert, während die zwei TAP-Controller im Gleichtakt funktionieren.
  • Die TMS_CONTROL-Anweisung wählt das TMS_Control Register aus, das dann mit einem TMS Steuercode vom Test-Controller 502 geladen wird. Abhängig von dem TMS Steuercode, der in das TMS_Control Register geladen wurde, wird der TMS_UUT-Output des ATL 602 in einem von vier Modi gesteuert, wie unten beschrieben.
  • TLR_Modus – TMS_UUT wird zu Logik 1 auf der abfallenden Flanke von TCK während Update-DR des TMS_Control Registers gezwungen. Dieses veranlasst den TAP-Controller der UUT zum Test-Logic-Reset (nach zumindest 5 TCK Takten) und bleibt dort, bis das UUT TMS zurück zum TMS_Modus geändert ist. Der TLR_Modus kann von irgendwelchen der anderen TMS Modi erreicht werden.
  • RTI_Modus – TMS_UUT wird zu Logik 0 auf der abfallenden Flanke von TCK während Update-DR von TMS_Control-Register gezwungen. Der UUT TAP-Controller bewegt zu Run-Test/Idle (auf der folgenden ansteigenden Flanke von TCK) und bleibt dort, bis das UUT TMS zurück zum TMS_Modus oder TLR_Modus geändert ist. Der RTI_Modus kann vom TLR_Modus oder vom TMS_Modus erreicht werden oder während im RTI-Pause Modus und wenn UUT TAP nicht im Pause-DR oder Pause-IR wartet.
  • RTI-Pause_Modus – Der RTI-Pause_Modus steuert bzw. regelt die TMS_UUT so, dass der UUT TAP-Controller zwischen Verbleiben in Run-Test/Idle, und entweder Pause-DR oder Pause-IR wechselt, wenn ATL 602 wechselnd ausgewählt/nicht-ausgewählt wird. Der RTI-Pause_Modus kann vom TLR_Modus, dem TMS_Modus oder während im RTI-Pause Modus erreicht werden und wenn der UUT TAP nicht im Pause-DR oder Pause-IR wartet.
  • TMS_Modus – Der TMS_Modus veranlasst, dass TMS_UUT mit TMS von PTB resynchronisiert, abhängig von dem vorhergehenden Modus und danach dem Wert vom TMS von PTB folgt.
  • Das TMS_Control Register nimmt Shifting auf und aktualisiert Daten, wenn der PTB-Controller 508 vorher ausgewählt wurde, d.h. durch eine ATL-Adressen-, UUT-Typ-, Gruppen-Adressen- oder Alias-Adressen-Übereinstimmung. Wenn folglich der PTB-Controller 508 nicht-ausgewählt worden ist, bleibt der TMS_UUT-Output an seinem letzten kontrollierten Wert pro dem Code im TMS_Control Register. In ähnlicher Weise ändert TMS_UUT nicht den Zustand im RTI-Pause_Modus, um außerhalb von Run-Test/Idle oder Pause-DR/Pause-IR zu synchronisieren, es sei denn, dass ATL 602 ausgewählt worden ist.
  • Nach einem Reset des PTB-Controllers 508 am PTB 504 wird das TMS_Control Register so zurückgestellt, dass es das TMS_UUT Signal mit dem TLR_Modus steuert. Infolgedessen bleibt der UUT TAP-Controller im Test-Logik-Reset, bis der TMS Steuercode nachher durch eine TMS_CONTROL-Anweisung geändert wird. Es ist auch möglich, den UUT TAP-Controller oder eine Gruppe UUT TAP-Controllern un abhängig den globalen TRSTN auf dem PTB zurückzustellen. Indem man zum Beispiel die GROUP_SELECT-Anweisung verwendet, kann eine spezifizierte Gruppe von UUT durch den Test-Controller 502 unter Verwendung eines TMS-Reset zurückgestellt werden, während die restlichen (d.h., nicht ausgewählt) UUT TAP-Controller im Run-Test/Idle warten. Indem man die TMS_Control Register in der ausgewählten Gruppe auf TLR_Modus einstellt, kann ein TMS-Reset an der Gruppe von UUTs durchgeführt werden, während ATL 602 sich zu Run-Test/Idle bewegt und TCK taktet. Übergänge bzw. Transitionen zwischen den TMS-Steuermodi sind unten beschrieben.
  • Der RTI-Pause_Modus erlaubt leistungsfähige Steuerung von zwei oder mehr UUTs so, dass sie separat heraus gescannt werden, aber ihren Update-DR oder Update-IR-Zustände gleichzeitig ausgeführt werden können. Zum Beispiel kann dieser Modus verwendet werden, um Board-zu-Board Interconnect-Test in einem System durchzuführen. Mit dem TMS Steuermodus, eingestellt auf RTI-Pause_Modus und zu den UUT TAP-Controllern in Run-Test/Idle, wird ein ausgewähltes ATL mit den UUT TAP-Controllern synchronisiert, während der ATL TAP durch Run-Test/Idle geführt wird. Nachher folgt TMS_UUT dem PTB TMS, bis ATL 602 entweder den Pause-DR- oder Pause-IR-Zustand erreicht. Das Erreichen eines der Pause-DR/IR-Zustände veranlasst TMS UUT, zu Logik 0 gesteuert zu werden, die den UUT TAP-Controller zwingt, im jeweiligen Pause-DR/IR-Zustand zu bleiben. Wenn ATL 602 ausgewählt ist und dann den entsprechenden Pause-DR- oder den Pause-IR-Zustand erreicht, werden ATL 602 und UUT TAP-Controller synchronisiert und TMS_UUT folgt wieder dem von PTB 504. Nachher wenn ATL 602 dann Run-Test/Idle erreicht, veranlasst es TMS_UUT, zur Logik 0 gesteuert zu werden und zwingt den UUT TAP, noch einmal in seinem Run-Test/Idle Zustand zu bleiben. Diese Reihenfolge von Synchronisieren/Verbleiben in Run-Test/Idle oder in Pause-DR/IR fährt so lang fort, wie der RTI-Pause_Modus in Kraft ist.
  • Wenn das TMS_Control Register nachher mit dem Steuercode für TMS_Modus aktualisiert wird, ändert der TMS_UUT-Output sich nicht von einem früheren stabilen Zustand d.h. Test-Logik-Reset, Run-Test/Idle, Pause-DR oder Pause-IR, bis der ATL TAP-Controller Run-Test/Idle oder den jeweiligen Pause-DR- oder Pause-IR-Zustand erreicht. Diese Zustände sind die Synchronisier- oder Triggerzustände.
  • Nach Gelangen in den passenden synchronisierenden Zustand wird das TMS_UUT Signal dementsprechend gesteuert zur Transition des UUT TAP von seinem früheren Zustand, wie durch den früheren TMS-Modus bestimmt, um mit dem ATL TAP-Controller-Triggerzustand synchronisiert zu werden. Sobald beide TAP-Controller-Zustände synchronisiert haben, folgt TMS_UUT dem TMS von PTB 504 und die TAP-Controller im ATL 602 und UUTs funktionieren im Gleichtakt, so lange, wie der PTB-Controller 508 ausgewählt bleibt. Bereitstellen eines Triggerzustandes zur Synchronisierung erlaubt dem Test-Controller 502 fortzufahren, zu kommunizieren, mit anderen PTB-Controllern und dann Übergang des UUTs zurück zum TMS_Modus nach Kommunikation mit den PTB-Controllern.
  • Wenn TMS_UUT im TMS_Modus (d.h., dem PTB TMS folgend) gesteuert wird, werden Anweisungen und Daten in sowohl ATL 602 als auch UUT gescannt, da die Scan-Wege bzw. Scan-Paths zwischen ihnen verkettet sind. Dementsprechend wird dem TDO_UUT-Output ermöglicht, Daten zu den UUT anzusteuern, damit, wenn der ATL TAP-Controller in Shift-DR oder Shift-IR ist, Scan-Daten aus TDO_UUT heraus zu TDI von UUTs gesteuert werden. In Abhängigkeit von den Anweisungen, die in ATL IR und das IR UUT geladen werden, können beliebige Datenregister im ATL 602 zusammen mit irgendeinem Datenregister in UUT verkettet werden. So kann zum Beispiel das DIO_UUT Register von ATL 602 an das interne Scan-Register von UUT verkettet werden kann. Wenn der TMS_UUT-Output zu jedem möglichen anderen TMS Modus gesteuert wird, wird dem TDO_UUT-Output nicht ermöglicht, anzusteuern, d.h. er bleibt im hohen Widerstandzustand.
  • Bevor ein PTB-Controller 508 nicht-ausgewählt wird, wird TMS_UUT-Output so gesteuert, dass UUT TAP-Controller in Run-Test/Idle bleibt (zum Beispiel, durch das Laden des TMS_Control Registers mit RTI_Modus). Dieses soll sichern, dass, wenn nicht-ausgewählt, die UUTs nicht so in einem TMS Steuermodus bleiben, dass sie weiter TMS von PTB folgen. In der momentan offenbarten Ausführungsform von PTA 500 handhabt der PTB-Controller 508 dies automatisch. Obwohl der PTB-Controller 508 im TMS_Modus ist, und wenn er nachher nicht-ausgewählt wird, wird TMS_UUT-Output provisorisch gesteuert, um RTI_Modus zu erreichen, wenn ATL TAP-Controller den Run-Test/Idle Triggerzustand erreicht. Wenn der PTB-Controller 508 nachher ausgewählt wird, fängt TMS_UUT an, dem TMS von PTB 504 zu folgen, nachdem ATL TAP-Controller über Run-Test/Idle gelangt. Somit sichert, während im TMS_Modus, der PTB-Controller 508, dass die UUT nicht fortfährt, TMS des ATL TAP-Controllers zu folgen, wenn sie nicht-ausgewählt ist.
  • COMPARE_STATUS – Die COMPARE_STATUS Anweisung wählt das Compare_Status Register in dem Maskier- und Vergleichs-Kreis 604 aus. Der Test-Controller 502 kann diese Anweisung verwenden, um den Bestehen/Nicht-Bestehen-Status jedes PTB-Controllers 508.1-508.n zu lesen oder zu löschen und die verschiedenen Funktionen des Maskier- und Vergleichs-Kreises 604 zu steuern bzw. regeln.
  • In der momentan offenbarten Ausführungsform des PTA 500 ist das Compare_Status Register ein 3-Bit-Daten-Register. Ein Bit dient als Bestehen/Nicht-Bestehen-Status-Bit, das eingestellt wird, wenn ein Miscompare von dem Maskier- und Vergleichs-Kreis 604 ermittelt wird. Der Test-Controller 502 kann das Compare_Status Register dann lesen, um zu überprüfen, ob Miscompare auftrat, d.h. das Bestehen/Nicht-Bestehen-Status-Bit eingestellt ist. Er kann auch das Bestehen/Nicht-Bestehen-Status-Bit löschen, d.h. nach Miscompare, um einen neuen Test mit dem gelöschten Status zu beginnen. Ein zweites Bit im Compare_Status Register, Compare_Enable, wird benutzt, um die Vergleichsfunktion zu aktivieren/desaktivieren, und ein drittes Bit, TLR_Enable, aktiviert/desaktiviert das Zwingen der UUT in den TLR_Modus nach einem Ausfall.
  • Das Compare_Status Register nimmt auf, verschiebt und aktualisiert Daten, wenn der PTB-Controller 508 vorher ausgewählt wurde, d.h. durch eine ATL-Adressen-, UUT-Typ-, Gruppen-Adressen- oder Alias-Adressen-Übereinstimmung. Wenn der PTB-Controller 508 zurückgestellt wird, wird das Compare_Status Register gelöscht, sodass der Bestehen/Nicht-Bestehen-Status-Bit zu einem Bestehen-Status zurückgestellt wird und die Compare_Enable- und TLR_Enable Funktionen ermöglicht bzw. eingeschaltet werden.
  • AUTO_START – Die AUTO_START Anweisung wählt das Auto_Start Register im PTB Auto-Start-Kreis 608 aus. Der Test-Controller 502 verwendet diese Anweisung, den UUT_PRESENT-Input zum PTB Auto-Start-Kreis 608 abzufragen und den START-Output zum PTB 504 zu ermöglichen oder zu sperren. In der momentan offenbarten Ausführungsform des PTA 500, ist das Auto_Start Register ein 2-Bit DR – ein erstes Bit nimmt den Zustand der UUT_PRESENT-Leitung auf und ein zweites Bit kontrolliert, ob die START-Leitung auf dem PTB 504 ermöglicht wird. Das Auto_Start Register nimmt auf, verschiebt und aktualisiert Daten, wenn der PTB-Controller 508 vorher d.h. durch eine ATL Adressen-, UUT Typ-, Gruppen-Adressenoder Alias-Adressen-Übereinstimmung ausgewählt wurde. Wenn der PTB-Controller 508 zurückgestellt wird, ist das UUT-Present-Bit gelöscht und START ist gesperrt bzw. abgeschaltet.
  • PROGRAM_IOV – Die PROGRAM_IOV Anweisung wählt das IO_Spannungs-Register im programmierbaren I/O-Spannungs-Kreis 610 aus und wird verwendet, die UUT Schnittstellen-Spannung zu programmieren. In der momentan offenbarten Ausführungsform ist das IO_Spannungs-Register ein 2-Bit DR, das vier programmierbare Spannungshöhen zum Beispiel 5 Volt, 3,3 Volt, USER_SUPPLIED und "off" kodiert. Das IO_Spannungs-Register nimmt auf, verschiebt und aktualisiert Daten, wenn der PTB-Controller 508 vorher, d.h. durch eine ATL Adressen-, UUT Typ-, Gruppen-Adressen- oder Alias-Adressen-Übereinstimmung, ausgewählt wurde. Wenn der PTB-Controller 508 zurückgestellt wird, wird das IO_Spannungs-Register auf aus eingestellt.
  • PTB-Verbrückung
  • Die Parallel-Test-Architektur (PTA)-Implementierungen, die in hohem Grade parallele Fähigkeiten erfordern, können durch die Zahl von PTB-Controllern begrenzt werden, die von dem Parallel-Testbus versorgt werden können (wegen des elektrischen Ladens, der Übertragungsabstände oder anderer Designbeschränkungen). Dementsprechend sorgt die momentan offenbarte PTA für eine Verbrückung zwischen zwei Parallel-Test-Bussen (PTBs). Dieses ermöglicht der PTA, jede verwendbare Zahl von UUTs parallel effektiv zu prüfen. Diese Art der Fähigkeit ist für Wafer-Sonden-Testanwendungen und für Hochdurchsatz Board-Teststationen erforderlich.
  • 8 stellt veranschaulichend eine Ausführungsform eines PTB-Brückenkreis 800 bildlich dar. Die PTB-Brücke 800 ist dem PTB-Controller 508 (s. 6) dadurch ähnlich, dass sie einen ATL (nicht gezeigt) und eine Adresse auf dem Parallel-Test-Bus (PTB) einschließt, markiert in 8 als PTB_ADDR[n:0]. Diese PTB-Adresse kann unabhängig von den ATL-Adressen sein und ist genug groß, die Gesamtzahl an PTB-Brücken in einem gegebenen PTA-System zu stützen. 8 zeigt die PTB-Brücke 802, die zwischen zwei PTBs, PTB_0 804.0 und PTB_1 804.1, zusammen mit dem Kreis 806 für PTB-Brücken-Funktion angeschlossen wird. Eine PTB-Brücke schließt ein PTB als die Source-PTB an ein anderes PTB als verbrückte oder verbundene PTB an. In 8 wird PTB_1 804.1 zur Sourcen-PTB_0 804.0 verbrückt.
  • 10-11 stellen veranschaulichende Ausführungsformen der verbrückten PTB Konfigurationen 1000 und 1100 beziehungsweise der PTA bildlich dar. Wie in 10 gezeigt, werden N+1 PTBs über N PTB-Brückenkreise 1002.0-1002.N-1, d.h. PTB_0 1004.0 über PTB_N 1004.N, verbunden, und jedes PTB 1004.0-1004.N unterstützt bis zu n UUTs. Diese Konfiguration 1000 kann eine Vielzahl von UUTs mit verhältnismäßig wenigen PTB-Brücken unterstützen. Die verbrückte PTB Konfiguration 1100, die in 11 gezeigt wird, schließt N verbundene PTBs 1104.1-1104.N, jede angeschlossen an einen jeweiligen PTB-Controller 1108.1-1108.N, ein. Auf diese Art kann das PTA leicht erweitert werden, um viele UUTs 1106.1-1106.N unterzubringen. Indem man einen adressierbaren PTB-Controller und eine PTB-Brücke für jede UUT verwendet, wird das PTA-System nicht auf das Unterstützen einer speziellen Zahl von UUTs, angeschlossen durch einen Multi-Drop-Bus, begrenzt. Es wird angemerkt, dass in beiden Konfigurationen 1000 und 1100, der ATL Adressbereich eine einzigartige Adresse für jeden PTB-Controller unterstützt. Somit werden in 10, wenn n = 2 und n = 12, dann 14 einzigartige ATL Adressen angefordert. In diesem Fall gibt es 2 einzigartige PTB Adressen für die PTB-Brückenkreise. In 11, wenn der PTB-Controller und die PTB-Brücke zu einem einzelnen Kreis kombiniert werden, wie bei Bezugsziffer 1120 gezeigt, dann ist es möglich, ATL und PTB-Adressen zu kombinieren (d.h., nur 12 einzigartige Adressen für n = 12 erforderlich), und zumindest einige ihrer zugehörigen Anweisungen können vermischt werden. Es sollte bedacht werden, dass andere Konfigurationen der PTB-Brückenkreis möglich sind.
  • Wie in 8 gezeigt, gibt es zwei Register in der PTB-Brücke 802 speziell ein Source_REG 812 und ein Link_REG 814. Das Source_REG 812 wird durch TCK von der Source-PTB_0 804.0 getaktet, und Link REG 814 wird durch TCK LINK Taktgeber getaktet, der verbundene PTB_1 804.1 taktet. So puffert die PTB-Brücke 802 den TCK Taktgeber der Source_PTB_0 804.0 ab und benutzt ihn, um die PTB-Signale für die PTB_1 804.1, angeschlossen an der verbundenen Seite des PTB-Brückenkreises 800, zu takten. Dementsprechend wenn zwei PTBs verbrückt werden, ist das verbundene PTB ein TCK Zyklus, der von der Source-PTB verzögert wird. Der Test-Controller 502 zieht diesen TCK Verbindungs-Zyklus in Betracht, wenn er über eine verbundene PTB kommuniziert und das PTB Protokoll passend für die verbrückte PTB Konfiguration handhabt. Jede beliebige Anzahl von PTB-Brücken 802 kann für eine gegebene PTA-Konfiguration, mit einem einzelnen Zyklus TCK-Delay-Penalty für jede PTB-Brücke implementiert werden.
  • 9 stellt ein zeitliches Diagramm 900 von PTB-Brücken-Übertragungen zwischen den zwei verbundenen PTBs 804.0-804.1 bildlich dar (s. 8). Wie in 8 gezeigt, werden das TRSTN Signal von PTB_0 804.0 und das TRSTN_LINK-Signal von PTB_1 804.1 durch das Source_REG registriert und Link REG registriert 812 und 814. Dies erfordert, dass während eines asynchronen Resets der PTA (d.h., das TRSTN von PTB bestätigend), TCK die TRSTN-Signale über jede der PTB-Brücken pulst, wie in 9 gezeigt. In den weiteren Ausführungsformen der PTA können die Signale auf der Source und der Link-Seite der PTB-Brücke 802 zum Beispiel TRSTN beziehungsweise TRSTN_LINK gepuffert werden (d.h. nicht-registriert) durch den PTB-Brückenkreis 800.
  • Wenn der PTB-Brückenkreis 800 zurückgesetzt wird, wird die BYPASS Anweisung (oder IDCODE Anweisung, wenn implementiert), geladen. Weiter ist die PTB-Brücke 802 nicht-ausgewählt, d.h. sie wird nicht in die Lage versetzt, sein TDO auf die Source PTB_0 804.0 zu steuern, und die TDO der Source PTB_0 804.0 und TDI_LINK vom verbundenen PTB_1 804.1 werden gelöst. Die Inputs zu PTB-Brücke 802 auf der Source-Seite (d.h., TDI, TMS, usw., die in 8 gezeigt werden), bleiben mit den jeweiligen Outputs der PTB-Brücke 802 auf der verbundenen Seite verbunden (d.h., TDO_LINK, TMS_LINK, usw..) unabhängig davon, ob ATL Anweisung in PTB-Brücke 802 geladen ist. So funktionieren die TAP-Controller der PTB-Brücken im Gleichtakt mit jenen der Test-Controller. Weiterhin ist der Test-Controller zum Kommunizieren mit allen PTB-Controllern parallel über die PTB-Brücken fähig.
  • Da die PTB-Brücke 802 (s. 8) keine UUT angeschlossen hat, sind die UUT-bezogenen Anweisungen des PTB-Controllers 508 (s. 6) nicht erforderlich. So kann der ATL (nicht gezeigt) in der PTB-Brücke 802 nur auf einen Teilsatz der Anweisungen reagieren, die von ATL 602 des PTB-Controllers verwendet werden. Dementsprechend reagiert in der erläuterten Ausführungsform der PTB-Brücke 802, ATL für die PTB-Brücke 802 auf die BYPASS-, IDCODE-, EXTEST-, PRELOAD- und UNSELECT_ALL Anweisungen. Außerdem implementiert die PTB-Brücke 802 die SELECT_PTB, LINK_PTB- und UNLINK_ALL-Anweisungen, die unten beschrieben sind, und gegebenenfalls die LOAD_PTB_ADDR Anweisung. Folglich werden diese PTB-Brücken-Anweisungen von ATL 602 des PTB-Controllers 508 ignoriert. Es wird angemerkt, dass die ATL 602 im PTB-Controller 508 und die ATL in der PTB-Brücke 802 die gleiche IR Länge in ihren TAP-Controllern haben.
  • Die PTB-Brücken-Anweisungen LOAD_PTB_ADDR, SELECT_PTB und LINK_PTB werden unten beschrieben.
  • LOAD_PTB_ADDR – Die LOAD_PTB_ADDR Anweisung wird implementiert, wenn die PTB-Brücke 802 für das Laden einer PTB Adresse sorgt. In der momentan offenbarten Ausführungsform der PTA sind die PTB_ADDR-Inputs direkte Parallel-Inputs zur PTB-Brücke 802 und die LOAD_PTB_ADDR Anweisung wird nicht implementiert.
  • Wenn sie eingeführt wird, veranlasst die LOAD_PTB_ADDR-Anweisung die PTB-Adresse von den PTB_ADDR Inputs der PTB-Brücke in das PTB_Address-Register aufgenommen zu werden. Abhängig von der Implementierung wird die Adresse entweder seriell direkt von den PTB_ADDR Inputs geladen oder aufgenommen. Das ATL_Address-Register ist die gleiche Größe, d.h. n+1 Bits lang, wie durch eine Implementierung mit parallelen PTB_ADDR Inputs erforderlich wäre.
  • SELECT_PTB – Die SELECT_PTB Anweisung wird verwendet, um eine einzelne PTB-Brücke auszuwählen, die auf seiner zugewiesenen PTB Adresse basiert. Diese Anweisung lädt seriell eine PTB Adresse vom Test-Controller in das Select_PTB-Register und vergleicht sie mit den PTB_ADDR Inputs zur PTB-Brücke 802 (oder, wenn implementiert zum PTB Address-Register, wie durch die LOAD_PTB_ADDR Anweisung geladen). Das Select_PTB Register wird konfiguriert, um die gleiche Größe, d.h. n+1 Bits, zu haben, wie die PTB_ADDR Inputs (oder PTB_Address-Register). Wenn die LOAD_PTB_ADDR-Anweisung nicht eingeführt wird, nimmt die SELECT_PTB-Anweisung die PTB_ADDR-Inputs in das Select_PTB Register auf (d.h., während Capture-DR vor der Shifting in die PTB Adresse vom Test-Controller).
  • Wenn die PTB Adresse die PTB_ADDR-Inputs (oder den PTB Address-Registerinhalt) in Übereinstimmung bringt, dann wird die PTB-Brücke 802 ausgewählt. Wenn die PTB-Brücke 802 unter Verwendung der SELECT_PTB-Anweisung ausgewählt wird, wird seinem TDO ermöglicht, PTB anzusteuern und auf die DR der PTB-Brücke 802 (zum Beispiel, das Bypass-Register, das Device_ID Register, usw..) kann zugegriffen werden. Die PTB-Brücke 802 bleibt ausgewählt bis eine UNSELECT_ALL oder UNLINK_ALL Anweisung herausgegeben wird (unten beschrieben), eine andere Anweisung, die nicht diese PTB-Brücke 802 auswählt, herausgegeben wird (zum Beispiel, eine SELECT_ATL Anweisung, die eine ATL Adresse für einen PTB-Controller lädt) oder die PTB-Brücke 802 zurückgestellt wird. Nach einer SELECT_PTB-Anweisung kann der Test-Controller eine andere Anweisung, wie die BYPASS- oder IDCODE-Anweisung, herausgeben, um zu verifizieren, dass eine PTB-Brücke ausgewählt wurde und steuert folglich Daten auf das TDO seines PTB.
  • LINK_PTB – Die LINK_PTB-Anweisung verursacht die Verbindung von zwei PTBs (zum Beispiel, das PTB_0 804.0 und PTB_1 804.1) angeschlossen über einen PTB-Brückenkreis (zum Beispiel, die PTB-Brücke 802). Bevor die zwei PTBs 804.0-804.1 verbunden werden, wird die PTB-Brücke 802 für die Source PTB_0 804.0 zuerst mit der SELECT_PTB-Anweisung ausgewählt. Nach der LINK_PTB-Anweisung wird TDO der PTB-Brücke 802 ermöglicht, auf die Source PTB_0 804.0 zu steuern, und TDO der Source PTB_0 804.0 und das TDI_LINK vom verbrückten PTB_1 804.1 werden verbunden.
  • Verbundene PTBs bleiben ausgewählt und verbunden und die PTB-Brückenkreise steuern ihr TDO, bis sie mit der UNLINK_ALL Anweisung gelöst werden (unten beschrieben). Verbundenes PTB kann nicht durch Anweisungen wie UNSELECT_ALL nicht-selektiert sein, oder SELECT_PTB, sie werden zuerst gelöst. Dieses lässt mehrfache PTBs verbunden bleiben, um die PTB Signale zum folgenden PTB in der Verbindung zu führen, damit der Test-Controller Anweisungen zu den verbundenen PTB-Controlleren schicken kann. Weiterhin erlaubt es, dass die TDO-Daten von einer ausgewählten UUT zurück zu dem Test-Controller, d.h. über die PTB-Brückenkreise, gesteuert werden.
  • UNLINK_ALL – Die UNLINK_ALL Anweisung wird verwendet, um alle PTB-Brückenkreise nicht-ausgewählt und nicht verbunden zu machen. Zum Beispiel löst das Laden der UNLINK_ALL-Anweisung in IR von ATL der PTB-Brücke 802 das TDO der Source-PTB_0 804.0 vom TDI LINK des verbrückten PTB_1 804.1 und sperrt das TDO der PTB-Brücke 802 vom Steuern auf das PTB_0 804.0. Außerdem werden alle PTB-Controller nicht-ausgewählt, wie es mit der UNSELECT_ALL Anweisung auftritt. Die UNLINK_ALL Anweisung wählt das Bypass-Register oder gegebenenfalls das Device_ID Register aus, wenn die IDCODE Anweisung implementiert wird.
  • Ein erstes Verfahren zum Verwenden der Parallel-Test-Architektur (PTA) 500 (s. 5) zum Durchführen der parallelen Prüfung einer Mehrzahl der Prüflinge (UUTs) wird durch Hinweis auf 14a veranschaulicht. Das Verfahren von 14a veranschaulicht, wie der Test-Controller über dem PTB mit den PTB-Controllern kommuniziert, um auf die UUTs und die verschiedenen Funktionen der PTA zuzugreifen.
  • Wie in Schritt 1402 bildlich dargestellt, wird das PTA-System zurückgestellt. Dieses wird durch den Test-Controller erzielt, der das TRSTN des PTBs zu Logik 0 bestätigt oder TMS zu Logik 1 für zumindest 5 TCK Taktgeberzyklen einstellt. Jeder der PTB-Controller erlangt Test-Logic-Reset und ihre IDCODE Anweisung (oder BYPASS Anweisung, wenn IDCODE nicht implementiert wird) wird im IR aktualisiert. Hereinkommen bzw. Erlangen von Test-Logic-Reset veranlasst auch, dass die folgenden Fälle auftreten:
    Der TDO-Output des ATLs zum PTB und sein TDO_UUT-Output ist tristated (Dreierzustand), TMS_UUT wird zu Logik 1 gezwungen (d.h., TLR_Modus wird in das TMS_Control Register geladen) und TRSTN_UUT und TCK_UUT folgen dem TRSTN beziehungsweise dem TCK des PTB.
  • Das Compare_Status Register wird gelöscht, das Auto_Start Register wird zurückgestellt, damit START ausgestellt ist, und das IO_Spannungs-Register wird zurückgestellt, damit die Schnittstellenspannung aus ist.
  • Die Select_ATL, Select_Type, Group_Address, Select_Group, Alias_Address, Select_Alias und DIO_UUT Register werden alle auf null zurückgestellt. Alle von den PTB-Controllern sind nicht-ausgewählt und die DIO_UUT[n:0] Leitungen werden tristated.
  • Dann wird die UUT I/O Spannung eingeschaltet und ein Reset wird, wie in Schritt 1404 bildlich dargestellt, zu den UUTs herausgegeben. Die SELECT_GROUP Anweisung kann verwendet werden, um alle PTB-Controller im PTA-System unter Verwendung des Gruppenadressierungs-Modus auszuwählen. Ein Select_Group Registerwert von alle-0 kann hierfür verwendet werden, da die Group_Address-Register alle auf 0 zurückgestellt werden, wenn das PTB zurückgestellt wird. Dann stellt der Test-Controller die Schnittstellen-Spannung für das UUT unter Verwendung der PROGRAM_IOV Anweisung ein. An diesem Punkt bestätigt der Test-Controller TRSTN und stellt zumindest 5 TCK Taktgeber zur Verfügung, um zu sichern, dass irgendwelche der UUTs, die kein TRSTN implementiert haben, zurückgestellt werden. Alle UUTs werden an diesem Punkt zurückgestellt – entweder asynchron durch das TRSTN_UUT oder durch ein TMS_UUT-Reset, wie durch die vorstehenden 5 TCK Taktgeber durchgeführt – und bleiben im Test-Logik-Reset.
  • Der Test-Controller verifiziert dann, wie in Schritt 1406 bildlich dargestellt, das PTA-System. Insbesondere können die folgenden Fälle auftreten:
    Der Test-Controller kann über den ATL-Adressen-Bereich unter Verwendung der SELECT_ATL Anweisung suchen und überprüft das Vorhandensein oder das Fehlen von PTB-Controllern bei jeder Adresse. Das Vorhandensein eines PTB-Controllers an einer gegebenen ATL Adresse kann festgestellt werden, indem man zuerst die ATL Adresse, die im Select_ATL Register überprüft werden soll, aktualisiert. Dann verschiebt der Test-Controller die TAP-Controller der PTB-Controller über Capture-DR. Dieses veranlasst die ATL Adresse des ausgewählten PTB-Controllers (wenn irgendeine ausgewählt wird), in sein Select_ATL Register aufgenommen zu werden. Der Test-Controller bewegt dann zu Shift-DR und überscannt das Select_ATL Register mit einem speziellen Testmuster, um die Scan-Weg-Vollständigkeit zu überprüfen. Wenn ein PTB-Controller ausgewählt wird, dann sieht der Controller die bestimmte ATL-Adresse, gefolgt vom Scan-Testmuster, an dem TDO des PTB.
  • Der Test-Controller kann eine notwendige Prüfung des PTA-Systems durchführen, sobald das Vorhandensein der PTB-Controller festgestellt ist.
  • Wenn dieser Schritt 1406 abgeschlossen ist, sollte der Test-Controller alle PTB-Controller nicht-ausgewählt lassen unter Verwendung der UNSELECT_ALL Anweisung und sollte das PTA-System in einem Zustand so lassen, dass die Adressen-Register von ATL auf ihre Resetzustände eingestellt sind und die UUTs im Test-Logic-Reset sind. Außerdem sollte der Test-Controller die PTA-Konfiguration und alle möglichen Störungen oder über Probleme mitteilen, die im PTA gefunden werden. Wenn das PTA richtig arbeitet, speichert der Test-Controller die Konfiguration in einem darin enthaltenen Speicher (nicht gezeigt).
  • Wie in Schritt 1408 bildlich dargestellt, wird eine Entscheidung getroffen, ob der Test-Controller die verbundene UUT vor der parallelen Prüfung oder Konfiguration des Kreises anfragt. Wenn der Test-Controller die Frage bildet, adressiert der Test-Controller jedes ATL am PTB, wie in Schritt 1410 bildlich dargestellt. Insbesondere wählt der Test-Controller jede UUT mit der SELECT_ATL Anweisung aus. Wenn der Test-Controller nicht die Frage bildet, fängt der Test-Controller die parallele Prüfung oder Konfiguration der UUTs an, wie in Schritt 1412 bildlich dargestellt. Insbesondere wenn eine LOAD_UUT_ID Anweisung implementiert worden ist, dann können die UUT_ID Register der UUTs an diesem Punkt geladen werden, und der Test-Controller kann sie überprüfen. Dann steuert der Test-Controller den TMS_UUT-Output des ATL, um dem TMS des PTBs unter Verwendung der TMS_CONTROL-Anweisung zu folgen und unter Einstellen des TMS_Control Registers auf TMS_Modus. Dies ermöglicht den UUT Scan-Wegen bzw. Scan-Paths, über das ATL erreicht zu werden. Der Test-Controller kann die ID-Register(s) von jeder der UUTs jetzt überprüfen, wenn implementiert, und zusammen mit dem UUT_ID Register den UUT Typ und Version überprüfen. Der Test-Controller kann dann Gruppen- und Alias-Adressen den UUTs dementsprechend zuweisen. Der Test-Controller lässt jede der UUTs in Run-Test/Idle und gibt eine UNSELECT_ALL-Anweisung heraus, wenn erledigt.
  • Dann führt der Test-Controller eine parallele Prüfung und/oder Konfiguration der UUTs durch, indem er zuerst Mehrfach-PTB-Controller auswählt, wie bildlich in Schritt 1414 dargestellt. Dieses wird unter Verwendung einer der SELECT_TYPE, SELECT_GROUP oder SELECT_ALIAS Anweisungen abgeschlossen. Dann wird die TMS_CONTROL Anweisung benutzt, um den Satz des Steuermodus zu TMS_Modus einzustellen, damit die TMS_UUT-Outputs der jeweiligen ATLs dem TMS von PTB folgen. Infolgedessen werden die alle vorher ausgewählten UUTs parallel erreicht. Wenn die Parallel-Test- und Konfigurationsvorgänge abgeschlossen sind, lässt der Test-Controller die UUTs in Run-Test/Idle, indem er das TMS_CONTROL auf RTI_Modus einstellt, und gibt eine UNSELECT_ALL Anweisung heraus.
  • Nach einer Parallel-Testanwendung überprüft der Test-Controller das Compare_Status Register von jedem der PTB-Controller und protokolliert seinen Bestehen/Nicht-Bestehen-Status, wie in Schritt 1416 bildlich dargestellt. Ein Register Compare_Status von PTB-Controller sollte gelöscht sein, in Vorbereitung für den folgenden Test, nachdem geprüft worden ist. Nachdem alle Compare_Status Register überprüft worden sind, gibt der Test-Controller eine UNSELECT_ALL Anweisung heraus.
  • Nachdem der Bestehen/Nicht-Bestehen-Status von jeder der UUTs bekannt ist, kann weitere Fehlerbeseitigung und Diagnose an den ausfallenden UUTs erfolgen, wie in Schritt 1418 bildlich dargestellt. Die SELECT_ATL Anweisung wird verwendet, um den PTB-Controller einer ausfallenden UUT auszuwählen, und dann wird die TMS_CONTROL-Anweisung verwendet, die TMS Steuerung auf TMS_Modus für das Zugänglich machen des UUT einzustellen. Der Test-Controller kann einen fehlschlagenden Versuch jetzt wieder anwenden und die ausfallenden Daten bezüglich des TDO des PTB für Diagnosezwecke überprüfen. Wenn die UUTs nicht erreicht werden, sollten die UUT TAP-Controller in den Run-Test/Idle gebracht werden, indem man die TMS_CONTROL Anweisung verwendet und den RTI_Modus einstellt.
  • Sie können in diesem Zustand dann bleiben, bis auf sie wieder für Prüfungs- oder Konfigurationszwecke zugegriffen wird.
  • Ein zweites Verfahren der Verwendung der Parallel-Test-Architektur (PTA) 500 (s. 5), um Board-zu-Board-Interconnect-Tests an einer Mehrzahl gedruckten Leiterplatten-Prüflingen (UUTs) in einem Platineneinschub durchzuführen, wird durch Hinweis auf 14b veranschaulicht. Wie in Schritt 1420 bildlich dargestellt, verwendet der Test-Controller die SELECT_GROUP Anweisung, um alle UUTs im System auszuwählen, die TMS_CONTROL Anweisung, um die TMS Outputs zum RTI_Modus zu steuern bzw. regeln und alle UUT TAP-Controller auf den Run-Test/Idle Modus zu verschieben.
  • Dann konfiguriert der Test-Controller die UUTs, wie in Schritt 1422 bildlich dargestellt. Insbesondere wählt der Test-Controller eine von den UUTs aus, die am Interconnect-Test unter Verwendung der SELECT_ATL Anweisung teilnimmt. Der Test-Controller weist dann eine Alias-Adresse mit der PROGRAMALIAS-Anweisung zu und stellt das Unique_Alias Bit ein. Zunächst weist der Test-Controller eine Gruppen-Adresse von 1 unter Verwendung der PROGRAM_GROUP-Anweisung zu. Schritt 1422 wird dann für jede UUT wiederholt, die am Interconnect-Test teilnehmen soll, wenn jedem neuen Board eine einzigartige Alias-Adresse zugewiesen ist.
  • Wie in Schritt 1424 bildlich dargestellt, lädt der Test-Controller zuerst die IRs der UUTs. Insbesondere wählt der Test-Controller eines der programmierten Boards aus unter Verwendung seiner Alias-Adresse und verwendet die TMS_CONTROL-Anweisung, um den TMS Modus auf RTI-Pausieren-Modus einzustellen. Dann überträgt der Test-Controller ATL TAP-Controller über Run-Test/Idle, das die TAP-Controller vom ausgewählten ATL und der UUT veranlasst, synchronisiert zu werden. Der Test-Controller lädt dann die IRs der UUT mit der EXTEST (oder PRELOAD)-Anweisung und lädt ATL mit SELECT_ALIAS IR. Dann überträgt der Test-Controller die UUT TAPs zum Pause-IR. Die UUT TAPs bleiben im Pause-IR, und der ATL geht zu Run-Test/Idle. Schritt 1424 wird dann für jedes Board wiederholt, das am Interconnect-Test teilnimmt. Folglich wurde nach Schritt 1424 jede UUT mit EXTEST geladen und wartet im Pause-IR.
  • Zunächst aktualisiert der Test-Controller die IRs der UUTs, wie in Schritt 1426 bildlich dargestellt. Insbesondere verwendet der Test-Controller die SELECT_GROUP-Anweisung mit der programmierten Gruppen-Adresse (zum Beispiel, Gruppen-Adresse 1) zum Auswählen aller Boards, die am Interconnect-Test teilnehmen. Dann überträgt der Test-Controller ATL TAP-Controller über Capture-IR und dann direkt zum Pause-IR. Dieses verursacht, dass die TAP-Controller des ausgewählten ATLs und die jeweiligen UUTs, die an sie angeschlossen sind, synchronisiert werden. Der Test-Controller überträgt dann ATL und UUT TAP-Controller zum Update-IR. Dieses verursacht ein simultanes IR-Update von allen UUTs. Nach dem Update gehe zu Run-Test/Idle, das veranlasst, dass die UUT TAP-Controller dort bleiben.
  • Wie in Schritt 1428 bildlich dargestellt, kann der Test-Controller jetzt Testvektoren anwenden. Insbesondere wählt der Test-Controller eine der UUTs unter Verwendung der SELECT_ALIAS Anweisung aus und lädt dann sein Select_Alias Adressen-Register. Es wird angemerkt, dass der Test-Controller Übertragen bzw. Transitionieren von TAP Controller von ATLs durch Run-Test/Idle vermeiden sollte, um den UUT TAP-Controller in Run-Test/Idle zu halten. Dann lädt der Test-Controller ATL der ausgewählten UUT mit der BYPASS Anweisung, und die Übergänge bzw. Transitionen der ATL TAP-Controller über Run-Test/Idle, um den UUT TAP-Controller mit ATL zu synchronisieren. Der Test-Controller transitioniert dann ATL und UUT TAP-Controller über Capture-DR und Shift-DR, die den Interconnect-Test Vektor abscannen. Der Testvektor-Scan endet dann durch Pause-DR, das den UUT TAP-Controller veranlasst, dort zu bleiben. Schritt 1428 wird dann für jedes Board wiederholt, das am Interconnect-Test teilnimmt, wobei jede UUT den passenden Interconnect-Test Vektor empfängt. Folglich wurde jede UUT nach Schritt 1428 mit einem Testvektor geladen und wartet im Pause-DR.
  • Zunächst aktualisiert der Test-Controller die DRs der UUTs, wie in Schritt 1430 bildlich dargestellt. Insbesondere verwendet der Test-Controller die SELECT_GROUP Anweisung mit der programmierte Gruppen-Adresse (zum Beispiel, Gruppen-Adresse 1) zum Auswählen aller Boards, die an dem Interconnect-Test teilnehmen. Dann transitionieren die Test-Controller ATL TAP-Controller über Capture-DR und dann direkt zu Pause-DR. Dies veranlasst, dass die TAP-Controller des ausgewählten ATLs und die jeweiligen UUTs, die an sie angeschlossen sind, synchronisiert werden. Die Test-Controller transitionieren dann ATL und UUT TAP-Controller zu Update-DR. Dieses veranlasst ein simultanes DR Update von allen UUTs. Nach dem Update gehe zu Run-Test/Idle, das die UUT TAP-Controller veranlasst, dort zu bleiben.
  • Wie 1432 bildlich dargestellt, wird eine Entscheidung getroffen, ob es einen folgenden Interconnect-Testvektor gibt, der auf den Test-Controller anzuwenden ist. Wenn so, schleift der Fluss zurück zu Schritt 1428. Es wird angemerkt, dass für den ersten Scan-in-Vektor in Schritt 1428 die Anfangs-Capture-DR-Daten ignoriert werden können. Nach dem abschließenden Scan-out-Betrieb sollte die Testreihenfolge mit dem Schritt 1430 enden, wodurch ein sicherer Zustand im BSR aktualisiert wird.
  • Um den Board-zu-Board-lnterconnect-Test zu beenden, bringt der Test-Controller die UUTs in die ausgewählte Gruppen-Adresse im RTI_Modus, wie in Schritt 1434 bildlich dargestellt. Weiterhin gibt der Test-Controller eine UNSELECT_ALL Anweisung heraus, damit die UUT TAP-Controller im Run-Test/Idle bleiben, bis sie wieder ausgewählt sind.
  • Nachdem die oben genannten veranschaulichenden Ausführungsformen der Parallel-Test-Architektur (PTA) beschrieben wurden, sollte angenommen werden, dass andere alternative Ausführungsformen oder Veränderungen ausgebildet werden konnten. Beispiele solcher alternativer Ausführungsformen und Veränderungen werden unten beschrieben.
  • Alternative Ausführungsformen des ATL und PTB-Controllers
  • Der PTB-Controller 508, der in 6 gezeigt wird, kann mit vielen Fähigkeiten implementiert werden. Zum Beispiel ist der ATL Kreis 602 fähig, an die Schnittstelle zu anderen Kreisen angepasst zu werden, um die Prüfung von UUT zu erleichtern. Insbesondere kann der PTB-Controller 508 konfiguriert werden, um Mehrfach-Scan-Wege bzw. Scan-Paths an der UUT zugänglich zu machen. Auf die Mehrfach-Scan- Wege bzw. Scan-Paths kann entweder seriell oder parallel zugegriffen werden. Wenn auf die Scan-Wege bzw. Scan-Paths seriell zugegriffen wird, kann der PTB-Controller 508 Scan-Wegschaltung und Verbindungsfähigkeiten zwischen ATL 602 und UUT bereitstellen. Für Parallel-Zugriffs Scan-Wege bzw. Scan-Paths kann ATL 602 zu den Serial-in/Parallel-out und Parallel-out/Serial-in-Umwandlungs-Kreisen zwischen dem PTB-Controller 508 und der UUT schnittstellenmäßig anschließen, oder ATL 602 kann diese Umwandlungen als Teil seines Schaltkreises einschließen. Weiterhin kann das ATL 602 konfiguriert werden, um Scan-Protokoll anders als IEEE 1149.1 auf der UUT Seite zu steuern bzw. regeln, zum Beispiel Multiplex-D Flip-Flop (DFF) oder Level-Sensitive-Scan-Design (LSSD). Weiterhin kann dem PTB-Controller 508 so implementiert werden, dass ein einzelner PTB-Controller auf Mehrfach-UUTs zugreifen kann. Dieses würde das Teilen von ATL 602 auf PTB 504 erlauben, dennoch aber noch erlauben, dass andere PTB-Controllerfunktionen zu einer einzelnen UUT wie der Maske dediziert werden, wie Maskier- und Vergleichs- und DIO Kreise 604 und 606. Weiterhin können UUTs noch parallel oder einzeln erreicht werden, wie mit der Ausführungsform, die in 6 gezeigt wird, wobei UUT-Auswahl über ein UUT_Select Register und ein Multiplexing der TDI_UUT Signale vom UUTs bewirkt wird.
  • Der Maskier- und Vergleichs-Kreis 604 kann auch viele Funktionen haben. Zum Beispiel kann ein erstes Ausfallermittlungs-Signal eingeführt werden, sodass der Maskier- und Vergleichs-Kreis 604 dem Test-Controller 502 signalisieren würde, sobald ein Scan-Daten-Miscompare auftrat. Dieses Signal kann mit der TDO-Leitung des PTB 504 implementiert werden, da es während der parallelen Prüfung zum Vergleichen der erwarteten Daten nicht benutzt zu werden braucht. In diesem Fall würde die Leitung TDO von PTB zu Logik 0 durch Maskier- und Vergleichs-Kreis 604 nach Abfragung eines Ausfalls zu Logik 0 gesteuert. Weiterhin könnte ein Ausfallzähler in dem Maskier- und Vergleichs-Kreis 604 enthalten sein, sodass er entweder das Scan-Bit zählen würde, oder die Anzahl Scan-Bits, die während des Vergleichsvorgangs ausfielen.
  • Der Maskier- und Vergleichs-Kreis 604 kann zusätzlich ein Signaturregister zum Verdichten von Antwortdaten von der UUT einschließen. Dieses kann entweder als Serial- oder Multiple-Input-Signatur-Register implementiert werden (SISR bezie hungsweise MISR). In diesem Fall würde die Signatur auf Bestehen/Nicht-Bestehen überprüft, nach einem Test der UUT. Es wird angemerkt, dass die EDI-Leitung während des Prüfens der Signatur nicht benutzt wird, gleichwohl die MDI-Leitung benutzt werden kann, um undeterminierte Antworten zu maskieren, die zum SISR oder zum MISR eingegeben würden, wodurch man ermöglicht, eine deterministische Signatur zu erreichen.
  • Weiterhin kann in anderen Ausführungsformen von PTA 500 der PTB-Controller 508 einen (Bit)Mustererzeugungskreis, wie ein Linear Feedback Shift Register (LFSR), einschließen, das benutzt werden kann, um Testmuster an die UUT zu liefern. Indem er ein LFSR und ein SISR/MISR bereitstellt, kann der PTB-Controller 508 einen Built-In-Self-Test (BIST) für die UUT anwenden. Weiterhin effektiv kann das PTB 504 auch ein XDI (eXtended Data In)-Signal einschließen, das benutzt werden kann, um Scan-In-Daten zur UUT entweder vom LFSR oder vom TDI Signal von PTB auszuwählen. Folglich kann die XDI Leitung die TDI Daten von PTB 504 (wo die maskierten Daten mit Zufalls-Daten vom LFSR versehen werden) "maskieren".
  • In einer weiteren alternativen Ausführungsform der PTA 500 können eine oder mehrere der DIO_UUT Leitungen durch ATL 602 automatisch gesteuert werden oder fortwährend gepollt werden, zum Beispiel als programmierbare Taktgeber oder Interrupts, die durch die UUT für Prüfungs- oder programmierbare Konfigurationszwecke verwendet werden können. Wenn programmierbare Interrupts bereitgestellt werden, kann ATL 602 ununterbrochen die Zustände der DIO_UUT Leitungen überwachen und nachher zu dem Test-Controller 502 auf dem TDO von PTB zurück signalisieren, wenn ein Interrupt-Fall aufgetreten ist. Weiterhin können TAP-Controlleranweisungen zusätzlich zu denen, die oben beschrieben werden, im ATL 602 bereitgestellt werden, um andere Verlängerungen zur PTA 500 zu unterstützen.
  • Alternative Ausführungsformen von PTB
  • Es sollte verstanden werden, dass PTB 504 nicht auf einen speziellen Satz von Signalen oder einer bestimmten Busimplementierung begrenzt ist, und viele Ausführungsformen zusätzlich zu denen haben kann, die in 5-6, 8 und 10-13 gezeigt werden. Das PTB 504 kann mit vielen anderen Fähigkeiten implementiert wer den, abhängig von zum Beispiel der bestimmten Parallel-Testanwendung, der Zahl von UUTs und/oder den Kosten und den Leistungsanforderungen für parallele Kommunikation zu Mehrfach-UUT.
  • Zum Beispiel können weitere Ausführungsformen von PTB 504 zusätzliche Signale einschließen, um zusätzliche Prüfung, Fehlerbeseitigen, oder Konfigurationseigenschaften für die UUTs 506.1-506.n zu erleichtern. Signale, wie ein High_Speed-Taktgeber für die UUTs 506.1-506.n., ein Taktgeber für PTB 504, Signale zur Unterstützung von analogem Test und Messungen (wie unten beschrieben) oder das XDI Signal, sind solche Beispiele.
  • Die strukturelle und elektrische Konfiguration von PTB 504 kann sich auch verändern, um der bestimmten Implementierung zu entsprechen. Wenn zum Beispiel neue Schaltkreistechnik zur Verfügung steht, können neue PTB Implementierungen höheren Geschwindigkeiten und/oder längere Übertragungsabstände ermöglichen. Insbesondere indem man das PTB konfiguriert, um Low-Voltage-Differential-Signaling-Bus-Technologie (LVDS) zu verwenden, können die PTB Signale als differentiale Signalpaare implementiert werden, um leistungsstarke PTB zu erzielen. Weiterhin kann PTB 504 auf verschiedenen Niveaus der Integration implementiert werden. Zum Beispiel kann er auf einem PCB als Teil eines Systemplatineneinschubes oder durch Verkabeln, bereitgestellt von einer PTA-Prüfvorrichtung zu den UUTs 506.1-506.n, eingeführt werden.
  • In einer weiteren alternativen Ausführungsform kann der PTB 504 mit einer verringerten Anzahl von physischen PTB Leitungen oder Drähten implementiert werden. Um dieses zu veranschaulichen, zeigt 7 einen alternativen Anschluss 700 eines adressierbaren TAP Linkers (ATL) 702 zu einem Parallel-Test-Bus (PTB) 704. Wie in 7 gezeigt, werden die EDI und MDI-Leitungen auf der TDO-Leitung des PTB 704 multiplex geschaltet. Dies ist möglich, da die TDO-Leitung normalerweise nicht in Verbindung mit den EDI und MDI-Leitungen während Parallel-Tests und Überprüfung benutzt wird, aber wenn tatsächliche Scan-out-Daten zurück zu dem Test-Controller auf dem PTB 704 gesendet werden. Im PTB 704 wird die TDO-Leitung als ein bidirektionales Signal implementiert. TDO arbeitet als Input zum ATL 702 während des Parallel-Testens und als Output vom ATL 702, wenn tatsächliche TDO Da ten zurück zu dem Test-Controller gesendet werden. Während einer Parallel-Testanwendung werden die EDI- und MDI-Signale über die einzelne TDO Leitung von 7, in den unterschiedlichen PTB Taktgeberzyklen gesendet, und sie werden dann durch einen EDI/MDI Extraktkreis 730 extrahiert, der im ATL 702 eingeschlossen ist. Dieses erfordert, dass die TCK Taktgeberrate des PTB 704 zweimal (d.h. 2X) von den UUTs ist. So werden Daten übermittelt und von den UUTs mit der Hälfte der Rate eines PTB mit unterschiedlichen EDI und MDI Leitungen empfangen. Dieses kann verringerte Implementierungskosten ergeben. Wo die Anwendung und die Technologie es ermöglichen, können andere Ausführungsformen des PTB die physische Verdrahtung weiter verringern. Außerdem, wenn es die Technologie ermöglicht, ist auch ein PTB, unter Verwendung drahtloser Kommunikationen implementiert, erreichbar und würde zusätzlichen Nutzen beim parallelen Zugriff auf Mehrfach-UUTs bereitstellen.
  • Eine weitere alternative Ausführungsform der PTA 500 (s. 5) unter Verwendung von Mehrfach-PTB 504 zwischen dem Test-Controller 502 und den PTB-Controllern 508.1-508.n kann implementiert werden. Zum Beispiel könnten zwei unabhängige PTBs verwendet werden, in denen ein erster PTB an einen jeweiligen PTB-Controller anschließt und für den Zugriff der UUT verwendet wird, die daran angeschlossen ist und ein zweiter d.h. separater, PTB, schließt auch an den gleichen PTB-Controller an und ist dediziert für den Gebrauch beim Zugriff aufs DIO von dem PTB-Controller. Dies sorgt für höheren Gesamtdurchsatz der PTA durch paralleles Bereitstellen der Mehrfach-Scan-Datenströme.
  • PTA mit analoger Test-Fähigkeit
  • Die PTA 500 (s. 5) kann über die Prüfung von Digitalschaltungen hinaus ausgedehnt werden und kann Misch-Signal (d.h., analoge und Digitalschaltungen)-Prüffähigkeiten zusätzlich bereitstellen. 12-13 zeigen zwei alternative Ausführungsformen 1200 beziehungsweise 1300 einer PTA, die Analogtesten unterstützen, unter Verwendung des IEEE 1149.4 Mischsignal-Test-Busstandards, der in der IEEE 1149.4 Mischen-Signal Test-Busstandard-Spezifikation beschrieben wird, die hierin durch diesen Hinweis enthalten ist. Zusätzlich zu den IEEE 1149.1 TAP-Signalen, wie in 1-3 gezeigt, schließt der IEEE 1149.4 Standard zwei analoge Bussignale, AT1 und AT2 ein, die die zwei vorgeschriebenen analogen Stifte für den IEEE 1149.4 analoge Test-Zugang-Port (ATAP) sind. AT1 ist ein Analogeingabestift zum UUT, der verwendet wird, um einen konstanten Anregungstrom am UUT anzuwenden, und AT2 ist ein Analog-Output von UUT, das verwendet wird, um die resultierende Spannung zu messen.
  • Der IEEE 1149.4 Standard wurde als Verlängerung zum IEEE 1149.1 Standard entwickelt, um den analogen Test-Bus AT1/AT2 und ATAP mit einzuschließen. Der IEEE 1149.4 Standard wurde entwickelt, um die Standard-IEEE 1149.1 Architektur als zum Beispiel Infrastruktur unter Verwendung der EXTEST Anweisung für den analogen Interconnect Test zu verwenden. Er definiert weiter neue Analog Boundary Modules (ABMs) für das Boundary-Scan-Register, die für analoge Test- und Messfähigkeiten über einen analogen AT1/AT2 Test-Bus sorgen. Der IEEE 1149.4 Standard soll hauptsächlich für die Prüfung der mit der Herstellung in Verbindung stehenden Interconnect-Defekte für Analogsignale und Bauteile (zum Beispiel, schließt kurz, öffnet sich, oder ein falscher Wertbestandteil wurde geladen) sorgen. Jedoch kann der analoge AT1/AT2 Test-Bus auch benutzt werden, um eine analoge Messfähigkeit zum Beispiel Impedanzmessung von widerstandsbehafteten Bestandteilen oder DC-parametrischer Prüfung bereit zu stellen. Die interne Chip-Prüfung ist auch mit dem IEEE 1149.4 Standard, zum Beispiel interner Test eines eingebetteten analogen Kernes, möglich.
  • Wegen der Beschaffenheit des Anwendens einer analogen Anregung und Messung der resultierenden Antwort ist analoger Test und Messung verhältnismäßig langsam und zeitraubend, wenn sie mit der digitalen Prüfung verglichen wird. Zum Beispiel erfordert ein einfacher analoger Test, dass ein Gleich- oder Wechselstrom oder -Spannung auf den zu testenden Kreis als die Testanregung aufgebracht wird, und dann die resultierende analoge Antwort gemessen und analysiert wird. Dieses erfordert normalerweise, dass analoge Instrumentenausrüstung oder ATE zuerst in den zu testenden Kreis geschaltet wird und dann gesteuert, um den passenden analogen Test anzuwenden und zu messen. Das Schalten und der folgende Betrieb der analo gen Instrumentenausrüstung geschehen im Allgemeinen in der Höhe einiger Millisekunden pro Test/Messung. Dieses steht im Gegensatz zu der digitalen Prüfung, die in vielen Größenordnungen geringerer Zeit vollendet werden kann. Als solches ist ein paralleler analoger Test zum Beispiel während des Boardherstellungs-Tests oder während der Wafer-Sonden-Tests erforderlich. Zum Beispiel kann diese analoge Testfähigkeit verwendet werden, um parametrisches DC-Testen von digitalem I/O oder zur Überwachung und Charakterisierung von Halbleiterherstellungsverfahren bereit zu stellen. In diesem Fall können anstatt die typischen getrennten Transistorstrukturen und Wafer-Sonden-Pads zu prüfen, die zwischen Die auf einer Siliziumwafer benutzt werden, die Teststrukturen auf den Chip gesetzt werden und unter Verwendung des IEEE 1149.4 Standards darauf zugegriffen werden.
  • 12 stellt die Analog-Parallel-Test-Bus (APTB)-Konfiguration 1200 bildlich dar, die veranschaulicht, wie das PTB verlängert werden kann, um zusätzliches IEEE 1149.4 analoge Testbussignale, AT1 1240.1 und AT2 1240.2, bereit zu stellen. 12 stellt, zusätzlich zu einem digitalen PTB 1204, die AT1 und AT2-Leitungen 1240.1-1240.2 und ein analoges Common-Ground 1242 dar, das an eine Analog-Apply und Messinstrumentions-Einheit 1260 verbunden wird. Die AT1 und AT2-Leitungen 1240.1 und 1240.2 werden als unterschiedliche Busse in 12 zur Klarheit der Diskussion gezeigt, werden aber im Allgemeinen als ein kombinierter Bus betrachtet, der das APTB 1244 bildet. Die AT1 und AT2 Leitungen 1240.1-1240.2 werden an die AT1 und AT2 Signale jeder UUT 1206.1-1206.n durch jeweilige Analog-Schalter 1250.1-1250.n angeschlossen. Es wird angemerkt, dass die analoge Einheit 1260 getrennt implementiert oder mit einem digitalen Test-Controller 1202 kombiniert werden kann. Zur Klarheit der Diskussion stellt 12 die analoge Maßeinheit 1260 und den Test-Controller 1202 als Analog-beziehungsweise Digitalsignalabschnitte der analogen PTB Konfiguration 1200 bildlich dar. 12 zeigt auch einen Kommunikations-Link 1270 zwischen der analogen Einheit 1260 und dem Test-Controller 1202. Die Analog-Apply und Messinstrumentations-Einheit 1260 kann dem Test-Controller 1202 mit dem AT_Done Signal signalisieren, dass ein analoger Test ausgeführt worden ist, und PTB-Controller 1208.1-1208.n können der analogen Einheit 1260 signalisieren, den folgenden analogen Test über das AT_Next Signal auf Leitung 1272 zu beginnen. Das AT_Next Signal wird kontrolliert bzw. ge steuert, wenn ein PTB-Controller ausgewählt wird und ein analoger Test für die UUT, die daran angeschlossen ist, aufgestellt worden ist.
  • Auf diese Art können die analoge Maßeinheit 1260 und der Test-Controller 1202 auf eine automatisierte Art und Weise arbeiten, um analoge Tests auf jeder der UUTs 1206.1-1206.n anzuwenden und zu messen. Die PTB-Controller 1208.1-1208.n sorgen auch für eine automatische Steuerung der jeweiligen Analog-Schalter 1250.1-1250.n, die die AT1 und AT2 Leitungen 1240.1-1240.2 des APTB an das UUTs 1206.1-1206.n anschließen. Es wird angemerkt, dass das digitale Setup für die analoge Prüfung normalerweise parallel auf einer Anzahl von UUTs 1206.1-1206.n durchgeführt wird, während die Anwendungs- und Messvorgänge normalerweise seriell für jede UUT erfolgen.
  • 13 stellt einen PTB-Controller 1300 bildlich dar, der ATL 602 mit einschließt, das an PTB 504, den Maskier- und Vergleichs-Kreis 604, den digitalen I/O Kreis 606 und den programmierbaren I/O-Spannungs-Kreis 610 angeschlossen wird, wobei jeder davon oben mit Bezug auf 6 beschrieben wird. Der PTB-Controller 1300 schließt weiterhin einen analogen Testkreis 1380 ein, der den PTB-Controller 1300 mit einer analogen Testfähigkeit versieht. Mit der Hinzufügung des analogen Testkreises 1380 liefert der PTB-Controller 1300 weiterhin ein AT1_UUT Signal 1382.1, ein AT2_UUT Signal 1382.2 und einen Common-Ground (gemeinsamer Erdungspunkt) 1384 für die analoge Prüfung der UUT, die daran angeschlossen wird. Als solcher kann ein IEEE 1149.4-analoger Testbus 1386, der die AT1_UUT/AT2_UUT Signale 1382.1-1382.2 und den analogen Common-Ground 1384 enthält, von jedem PTB-Controller auf dem Multi-Drop PTB 504 direkt verfügbar gemacht werden. Weiterhin wird der IEEE 1149.4 Testbus 1386 für jede UUT parallel bereitgestellt, anstatt des Teilens von einzelnen APTB 1244, wie in 12 gezeigt.
  • Der analoge Testkreis 1380 (s. 13) kommuniziert mit ATL 602 über eine digitale Schnittstelle, wodurch der analoge Testkreis 1380 direkt über den PTB 504 durch den Test-Controller, d.h. ohne Zugriff über das APTB 1386 oder einen analogen Abschnitt, wie die Analog-Apply und Messinstrumenten-Einheit 1260 zu erfordern, gesteuert wird. Somit liegen für den PTB-Controller 1300, die AT1 und AT2 Signale 1240.1-1240.2 und die analoge Einheit 1260 nicht vor, und die PTB 504 und der Test-Controller 502, die mit dem PTB-Controller 1300 eingesetzt werden, sind zu den entsprechenden Elementen der PTA 500, die in 5 gezeigt wird, identisch.
  • Der analoge Testkreis 1380 (s. 13), schließt einen Analog-zu-Digital-Umwandlungs-(ADC) und einen Digital-zu-Analog-Umwandlungs-(DAC) Kreis 1388 ein, der "Anwenden" und "Messen" Funktionen des analogen Tests ermöglicht, von/zu digitalen Daten umgewandelt zu werden und folglich kann die ganze analoge Prüfung als andere digitale Tests der UUT mit nur dem digitalen Test-Controller an dem PTB 504 auf die gleiche Weise bewirkt werden. Der analoge Testkreis 1380 wird konfiguriert, um einen Gleich- oder Wechselstrom am UUT auf dem AT1_UUT Signal 1382.1 anzuwenden, wie durch den DAC Kreis 1388 gesteuert. Weiter kann der analoge Testkreis 1380 eine resultierende UUT-Spannung auf der AT2_UUT Leitung 1382.2 messen, die nachher von analoger in digitale Form umgewandelt wird. Der analoge Testkreis 1380 schließt weiterhin einen analogen Multiplexer 1389 ein, der für eine Spannungsmessung an AT2 1382.2 einer bekannten Last an AT1 1382.1 sorgt, wodurch Kalibrierung des AT1/AT2-Busses ermöglicht wird. Die parallele Test-Architektur (PTA), enthaltend eine Mehrzahl von den PTB-Controllern 1300, erlaubt, dass analoge Tests parallel durchgeführt werden (d.h., gleichzeitig auf mehreren UUTs), indem man digitale Umwandlungen der Anwendungs- und Messvorgänge in Verbindung mit der Parallel-Testfähigkeit von PTB 504 und der PTB-Controller 1300 verwendet.
  • Es wird weiterhin vom Durchschnittsfachmann eingeschätzt, dass Modifizierungen und Änderungen der oben beschriebenen Parallel-Testarchitektur hergestellt werden können, ohne von den erfinderischen Konzepten abzurücken, die hierin offenbart werden. Folglich sollte die Erfindung nicht als begrenzt angesehen werden, ausgenommen wie in den angefügten Ansprüchen definiert.

Claims (32)

  1. System (500) zum Zugriff auf einen oder mehrere elektronische Schaltkreise (UUT1-UUTn) zum Testen, zur Fehlerbeseitigung bzw. Debuggen oder zum programmierbaren Konfigurieren der elektronischen Schaltkreise mit: einem Testbus (504); einem primären Testcontroller bzw. -regler bzw. -steuerer (502), angeschlossen an den Testbus; und einer Vielzahl von adressierbaren Lokaltestcontrollern bzw. -reglern bzw. -steuerern (508.1-508.n), angeschlossen an den Testbus, wobei jeder lokale Testcontroller an einen jeweiligen elektronischen Schaltkreis, auf welchen zugegriffen werden soll bzw. welcher zugreifbar ist, koppelbar ist, dadurch gekennzeichnet, dass der Testbus ein Multidroptestaccessbus bzw. Mehrpunktverbindungstestzugriffsbus (Englisch: „multi-drop test access bus) ist, der primäre Testcontroller so konfiguriert ist, dass er IEEE 1149.1-Testdaten, erwartete Daten bzw. Solldaten bzw. Erwartungsdaten und Maskierungsdaten über den Testbus an bzw. zu jeweiligen Lokaltestcontrollern sendet, um parallel auf die elektronischen Schaltkreise über die jeweiligen Lokaltestcontroller zuzugreifen bzw. sich damit zu verbinden, und jeder Lokaltestcontroller konfiguriert ist zur Anwendung der Testdaten auf dem jeweiligen daran koppelbaren elektronischen Schaltkreis, zum Empfang von Ergebnisdaten bzw. Resultatdaten bzw. resultierende Daten, erzeugt bzw. generiert durch den jeweiligen elektronischen Schaltkreis in Antwort auf die Anwendung der Testdaten, im Fall, dass ein Bereich der erwarteten Daten nicht bestimmbar bzw. unbestimmbar bzw. unbestimmt ist, zum Maskieren des unbestimmten Bereichs der Erwartungsdaten unter Verwendung der Maskierungsdaten, und zum Verifizieren der Ergebnisdaten gegen die Erwartungsdaten.
  2. System nach Anspruch 1, wobei jeder elektronische Schaltkreis, auf den zugegriffen werden soll bzw. mit dem verbunden werden soll, einen jeweiligen bzw. entsprechenden Testaccessbus (TDI, TMS, TCK, TRSTN, TDO) enthält.
  3. System nach Anspruch 2, wobei jeder Lokaltestcontroller zudem so konfiguriert ist, dass er den Multidroptestaccessbus an den jeweiligen Testaccessbus, der in dem daran koppelbaren elektronischen Schaltkreis enthalten ist, verbindet.
  4. System nach Anspruch 1, wobei der Testbus einen digitalen Testbus (1204) umfasst, wobei der primäre Testcontroller ein erster primärer Testcontroller (1202) ist und das System außerdem einen analogen Testbus (1244), einen zweiten primären Testcontroller (1260) und eine Nachrichtenverbindung bzw. -link (1270) enthält, konfiguriert bzw. augelegt, den zweiten primären Testcontroller an den ersten primären Testcontroller zu koppeln, wobei der analoge Testbus an den zweiten primären Testcontroller gekoppelt ist und an die jeweiligen elektronischen Schaltkreise, auf die zugegriffen werden soll, koppelbar ist.
  5. System nach Anspruch 4, wobei der erste primäre Testcontroller außerdem zum Senden von Testdaten und Erwartungsdaten über den digitalen Testbus zu dem zweiten primären Testcontroller konfiguriert ist, wobei der zweite primäre Testcontroller konfiguriert bzw. ausgelegt ist zum Anwenden der Testdaten auf die jeweiligen daran koppelbaren elektronischen Schaltkreise, zum Empfang von Ergebnisdaten, die von den jeweiligen elektronischen Schaltkreisen in Antwort auf die Anwendung der Testdaten erzeugt werden, und zur Bereitstellung der Ergebnisdaten über die Nachrichtenverbindung für den bzw. an dem ersten primären Testcontroller.
  6. System nach Anspruch 4, wobei der zweite primäre Testcontroller ein mit dem IEEE 1149.4-Teststandard kompatibles Interface bzw. Schnittstelle enthält, wobei der zweite primäre Testcontroller außerdem zur Verwendung eines Protokolls, das in dem IEEE 1149.4-Teststandard angegeben bzw. gegeben ist, zum Zugriff auf die bzw. in Verbindung mit den jeweiligen elektronischen Schaltkreise konfiguriert ist.
  7. System nach Anspruch 1, wobei jeder lokale Testcontroller außerdem zum Empfang von aktuellen Daten bzw. Istdaten von dem jeweiligen elektronischen Schaltkreis im Ergebnis des Zugriffs bzw. als Folge, dass damit verbunden wird und zum Vergleich der aktuellen Daten mit den Erwartungsdaten konfiguriert ist.
  8. System nach Anspruch 1, wobei die jeweiligen Lokaltestcontroller außerdem so konfiguriert sind, dass sie die Ergebnisdaten als Ergebnis bzw. Resultat eines Vergleichs speichern.
  9. System nach Anspruch 8, wobei der primäre Testcontroller außerdem zum Abrufen der gespeicherten Ergebnisdaten konfiguriert ist.
  10. System nach Anspruch 7, wobei die jeweiligen Lokaltestcontroller außerdem zum Komprimieren der aktuellen Daten konfiguriert sind.
  11. System nach Anspruch 1, wobei die jeweiligen Lokaltestcontroller außerdem zur Erzeugung zumindest eines Bereichs von den IEEE 1149.1-Testdaten konfiguriert sind.
  12. System nach Anspruch 1, wobei jeder Lokaltestcontroller einen digitalen Eingabe/Ausgabe-Kreis (606) enthält, konfiguriert zur Übertragung eines oder mehrerer digitaler Signale zwischen dem lokalen Testcontroller und dem jeweiligen elektronischen Schaltkreis.
  13. System nach Anspruch 1, wobei jeder lokale Testcontroller einen Autostartkreis (608) enthält, konfiguriert zum Senden eines Startsignals über den Testbus von dem lokalen Testcontroller zu dem primären Testcontroller, wobei das Startsignal betriebsfähig ist, dem primären Testcontroller anzuzeigen, dass die jeweiligen elektro nischen Schaltkreise, auf die zugegriffen werden soll, an die lokalen Testcontroller gekoppelt sind.
  14. System nach Anspruch 1, wobei jeder lokale Testcontroller ein Kommunikationsinterface bzw. eine Kommunikationsschnittstelle (TDO_UUT, TMS_UUT, TCK_UUT, TRSTN_UUT, TDI_UUT) mit einem zugehörigen Spannungswert bzw. -niveau, koppelbar an den jeweiligen elektronischen Schaltkreis, auf den zugegriffen werden soll bzw. mit dem verbunden werden soll, und einen programmierbaren Eingabe/Ausgabe-Spannungskreis (610), konfiguriert zum Einstellen des Spannungswerts des Kommunikationsinterface zur Gewährleistung elektrischer Kompatibilität mit dem jeweiligen elektronischen Schaltkreis, enthält.
  15. System nach Anspruch 14, wobei der programmierbare Eingabe/Ausgabe-Spannungskreis den Spannungswert des Kommunikationsinterface, basierend auf zumindest einem Signal, das über den Testbus durch den primären Testcontroller gesendet wird, einstellt bzw. setzt.
  16. System nach Anspruch 1, wobei der Testbus eine Vielzahl von Testbussen (804.0-804.1) umfasst und jeweilige Vielzahlen von lokalen Testcontrollern an die Testbusse angeschlossen sind und außerdem zumindest eine adressierbare Busbrücke (802), konfiguriert zum aufeinanderfolgenden bzw. nacheinander Untereinanderverbinden bzw. Zusammenschalten der Testbusse, enthält.
  17. System nach Anspruch 16, wobei die adressierbare Busbrücke einen ersten Testbus und einen zweiten Testbus untereinander verbindet bzw. zusammenschaltet, wobei der erste Testbus als Sourcebus bzw. Quellbus konfiguriert ist.
  18. System nach Anspruch 16, wobei die adressierbare Busbrücke einen ersten Testbus und einen zweiten Testbus untereinander verbindet, wobei jeder von dem ersten und zweiten Testbussen zur Übermittlung von Testdaten konfiguriert ist, wobei die adressierbare Busbrücke zur Übertragung der Testdaten zwischen dem ersten Testbus und dem zweiten Testbus konfiguriert ist.
  19. System nach Anspruch 1, wobei der primäre Testcontroller zum Speichern von Daten, die eine Vielzahl von Modi zum Adressieren bzw. Ansprechen der Vielzahl von lokalen Testcontrollern benennen bzw. kennzeichnen und zum Ausführen zumindest einer Anwendung zum Adressieren von zumindest einer der Vielzahl von lokalen Testcontrollern gemäß einem der Adressierungsmodi konfiguriert ist.
  20. System nach Anspruch 19, wobei jeder lokale Testcontroller einen zugehörigen Adresswert aufweist und in einem von den Adressierungsmodi der primäre Testcontroller einen einzigen lokalen Testcontroller auf der Basis seines zugehörigen bzw. assoziierten Adresswerts adressiert bzw. anspricht.
  21. System nach Anspruch 19, wobei jeder lokale Testcontroller einen zugehörigen bzw. assoziierten Identifikationswert aufweist und in einem von den Adressierungsmodi der primäre Testcontroller einen oder mehrere der Vielzahl von lokalen Testcontrollern basierend auf ihren zugehörigen bzw. assoziierten Identifikationswerten adressiert.
  22. System nach Anspruch 19, wobei jeder lokale Testcontroller einen zugehörigen bzw. assoziierten Gruppenadresswert aufweist und wobei in einem der Adressierungsmodi der primäre Testcontroller die jeweiligen lokalen Testcontroller mit demselben Gruppenadresswert adressiert.
  23. System nach Anspruch 19, wobei zumindest einer der Vielzahl von lokalen Testcontrollern einen zugehörigen bzw. assoziierten Aliasadresswert aufweist und wobei in einem der Adressierungsmodi der primäre Testcontroller zumindest einen lokalen Testcontroller auf der Basis seines zugehörigen Aliasadresswerts adressiert.
  24. Verfahren zum Zugriff auf einen oder mehrere elektronische Schaltkreise (UUT1-UUTn) zum Testen, zur Fehlerbeseitigung bzw. Debaggung oder zum programmierbaren Konfigurieren der elektronischen Schaltkreise, umfassend die Schritte von: Bereitstellen eines ersten Testbus (504), wobei der erste Testbus ein Multidrop testaccessbus bzw. Mehrpunktverbindungstestzugriffsbus ist; Bereitstellen eines primären Testcontrollers bzw. -reglers bzw. -steuerers (502) und einer Vielzahl von adressierbaren lokalen Testcontrollern bzw. -reglern bzw. -steuerern (508.1-508.n), angeschlossen an den ersten Testbus, wobei jeder lokale Testcontroller an den jeweiligen elektronischen Schaltkreis, auf den zugegriffen werden soll bzw. welcher zugreifbar ist, koppelbar ist; Senden von IEEE 1149.1-Testdaten, erwarteten Daten bzw. Solldaten bzw. Erwartungsdaten und Maskierungsdaten über den ersten Testbus an bzw. zu jeweiligen lokalen Testcontrollern durch den primären Testcontroller zum parallelen Zugriff bzw. Verbinden der elektronischen Schaltkreise über die jeweiligen lokalen Testcontroller; Anwenden der Testdaten auf die elektronischen Schaltkreise durch die jeweiligen lokalen Testcontroller; Empfangen von Ergebnisdaten, erzeugt bzw. generiert durch die elektronischen Schaltkreise in Antwort auf die Anwendung der Testdaten durch die jeweiligen lokalen Testcontroller; im Fall, dass ein Bereich der erwarteten Daten nicht bestimmbar bzw. unbestimmbar bzw. unbestimmt ist, Maskieren des unbestimmten Bereichs der Erwartungsdaten unter Verwendung von Maskierungsdaten durch die jeweiligen lokalen Testcontroller, und Verifizieren der Ergebnisdaten gegenüber den erwarteten Daten durch die jeweiligen lokalen Testcontroller.
  25. Verfahren nach Anspruch 24, das außerdem die Schritte des Empfangs von aktuellen Daten bzw. Istdaten von dem jeweiligen elektronischen Schaltkreis im Ergebnis des Zugriffs bzw. als Folge, dass damit verbunden wird durch den lokalen Testcontroller und Vergleich der aktuellen Daten mit den Erwartungsdaten durch den lokalen Testcontroller enthält.
  26. Verfahren nach Anspruch 24, wobei der erste Bereitstellungsschritt Bereitstellen einer Vielzahl von Testbussen (804.0-804.1) beinhaltet und der zweite Bereitstellungsschritt Bereitstellen jeweiliger Vielzahlen von Lokaltestcontrollern, angeschlossen an die Testbusse beinhaltet und außerdem beinhaltend den Schritt von aufein ander folgendem bzw. nacheinander Untereinanderverbinden der Testbusse durch zumindest eine adressierbare Busbrücke (802).
  27. Verfahren nach Anspruch 26, wobei der Schritt des aufeinanderfolgenden Untereinanderverbindens bzw. Zusammenhaltens der Testbusse Untereinanderverbinden eines ersten Testbusses und eines zweiten Testbusses durch die adressierbare Busbrücke einschließt, wobei der erste Testbus als Sourcebus bzw. Quellbus konfiguriert ist.
  28. Verfahren nach Anspruch 26, wobei der Schritt des aufeinanderfolgenden Untereinanderverbindens der Testbusse Untereinanderverbinden eines ersten Testbusses und eines zweiten Testbusses durch die adressierbare Busbrücke einschließt, wobei jeder von den ersten und zweiten Testbussen zum Transport von Testdaten ausgelegt ist und außerdem zum Einschließen des Schritts des Transports der Testdaten zwischen dem ersten Testbus und dem zweiten Testbus über die adressierbare Busbrücke.
  29. System nach Anspruch 1: wobei jeder der lokalen Testcontroller einen Testverbindungsport- bzw. Testaccessport (TAP)-Controller beinhaltet; wobei der Testbus einen seriellen Datenausgabeweg (TDO), einen seriellen Dateneingabeweg (TDI), einen Test-Clock-Weg bzw. Test-Zeit-Weg (TCK) und einen Testmodusselektionsweg (TMS) beinhaltet, wobei der TDO-Weg bidirektional ist; wobei der primäre Testcontroller zur Bereitstellung von Steuersignalen bzw. Kontrollsignalen, einschließlich eines TDO-Signals, eines TDI-Signals, eines TCK-Signals und eines TMS-Signals, entsprechend über den TDO-Weg, den TDI-Weg, den TCK-Weg und den TMS-Weg, zum Einstellen bzw. Setzen bzw. Versetzen des TAP-Controllers in einen Shift-IR-Zustand oder in einen Shift-DR-Zustand, konfiguriert ist, und wobei der primäre Testcontroller zur Bereitstellung der erwarteten Daten bzw. Erwartungsdaten über den bidirektionalen TDO-Weg, während der TAP-Controller im Shift-IR-Zustand oder dem Shift-DR-Zustand ist, konfiguriert ist.
  30. System nach Anspruch 1: wobei jeder der lokalen Testcontroller einen Testverbindungsport- bzw. Testaccessport (TAP)-Controller beinhaltet; wobei der Testbus einen seriellen Datenausgabeweg (TDO), einen seriellen Dateneingabeweg (TDI), einen Test-Clock-Weg bzw. Test-Zeit-Weg (TCK) und einen Testmodusselektionsweg (TMS) beinhaltet, wobei der TDO-Weg bidirektional ist; wobei der primäre Testcontroller zur Bereitstellung von Steuersignalen bzw. Kontrollsignalen, einschließlich eines TDO-Signals, eines TDI-Signals, eines TCK-Signals und eines TMS-Signals, entsprechend über den TDO-Weg, den TDI-Weg, den TCK-Weg und den TMS-Weg, zum Einstellen bzw. Setzen bzw. Versetzen des TAP-Controllers in einen Shift-IR-Zustand oder in einen Shift-DR-Zustand, konfiguriert ist, und wobei der primäre Testcontroller zur Bereitstellung der Maskierungsdaten über den bidirektionalen TDO-Weg, während der TAP-Controller im Shift-IR-Zu-stand oder dem Shift-DR-Zustand ist, konfiguriert ist.
  31. Verfahren nach Anspruch 24: wobei jeder der lokalen Testcontroller einen Testverbindungsport- bzw. Testaccessport (TAP)-Controller beinhaltet; wobei der Testbus einen seriellen Datenausgabeweg (TDO), einen seriellen Dateneingabeweg (TDI), einen Test-Clock-Weg bzw. Test-Zeit-Weg (TCK) und einen Testmodusselektionsweg (TMS) beinhaltet, wobei der TDO-Weg bidirektional ist; und außerdem die Schritte einschließt von: Bereitstellen von Steuersignalen bzw. Kontrollsignalen, einschließlich eines TDO-Signals, eines TDI-Signals, eines TCK-Signals und eines TMS-Signals, entsprechend über den TDO-Weg, den TDI-Weg, den TCK-Weg und. den TMS-Weg durch den primären Testcontroller zum Einstellen bzw. Setzen bzw. Versetzen des TAP-Controllers in einen Shift-IR-Zustand oder in einen Shift-DR-Zustand, und Bereitstellen der Erwartungsdaten über den bidirektionalen TDO-Weg, während der TAP-Controller im Shift-IR-Zustand oder dem Shift-DR-Zustand ist, durch den pri mären Testcontroller.
  32. Verfahren nach Anspruch 24: wobei jeder der lokalen Testcontroller einen Testverbindungsport- bzw. Testaccessport (TAP)-Controller beinhaltet; wobei der Testbus einen seriellen Ausgabeweg (TDO), einen seriellen Daten-Eingabeweg (TDI), einen Test-Clock-Weg Test-Zeit-Weg (TCK) und einen Testmodusselektionsweg (TMS) beinhaltet, wobei der TDO-Weg bidirektional ist; und außerdem die Schritte einschließt von: Bereitstellen von Steuersignalen bzw. Kontrollsignalen, einschließlich eines TDO-Signals, eines TDI-Signals, eines TCK-Signals und eines TMS-Signals, entsprechend über den TDO-Weg, den TDI-Weg, den TCK-Weg und. den TMS-Weg durch den primären Testcontroller zum Einstellen bzw. Setzen bzw. Versetzen des TAP-Controllers in einen Shift-IR-Zustand oder in einen Shift-DR-Zustand, und Bereitstellen der Maskierungsdaten über den bidirektionalen TDO-Weg, während der TAP-Controller im Shift-IR-Zustand oder dem Shift-DR-Zustand ist, durch den primären Testcontroller.
DE60221836T 2001-07-05 2002-06-27 Verfahren und vorrichtung zur optimierten parallelen prüfung und zum zugriff auf elektronische schaltung Expired - Lifetime DE60221836T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US30305201P 2001-07-05 2001-07-05
US303052P 2001-07-05
US119060 2002-04-09
US10/119,060 US6988232B2 (en) 2001-07-05 2002-04-09 Method and apparatus for optimized parallel testing and access of electronic circuits
PCT/US2002/020505 WO2003005050A1 (en) 2001-07-05 2002-06-27 Method and apparatus for optimized parallel testing and access of electronic circuits

Publications (2)

Publication Number Publication Date
DE60221836D1 DE60221836D1 (de) 2007-09-27
DE60221836T2 true DE60221836T2 (de) 2008-04-30

Family

ID=26817004

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60221836T Expired - Lifetime DE60221836T2 (de) 2001-07-05 2002-06-27 Verfahren und vorrichtung zur optimierten parallelen prüfung und zum zugriff auf elektronische schaltung

Country Status (11)

Country Link
US (2) US6988232B2 (de)
EP (1) EP1402278B1 (de)
JP (1) JP4083117B2 (de)
KR (1) KR100623310B1 (de)
CN (1) CN100416288C (de)
AT (1) ATE370423T1 (de)
CA (1) CA2421047C (de)
DE (1) DE60221836T2 (de)
HK (1) HK1064444A1 (de)
TW (1) TWI250293B (de)
WO (1) WO2003005050A1 (de)

Families Citing this family (126)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7571364B2 (en) 2005-08-09 2009-08-04 Texas Instruments Incorporated Selectable JTAG or trace access with data store and output
US7308629B2 (en) 2004-12-07 2007-12-11 Texas Instruments Incorporated Addressable tap domain selection circuit with TDI/TDO external terminal
US7328387B2 (en) * 2004-12-10 2008-02-05 Texas Instruments Incorporated Addressable tap domain selection circuit with selectable ⅗ pin interface
US7159161B2 (en) * 1999-01-29 2007-01-02 National Science Council Test method and architecture for circuits having inputs
US7417450B2 (en) * 2005-12-02 2008-08-26 Texas Instruments Incorporated Testing combinational logic die with bidirectional TDI-TMS/TDO chanel circuit
US7657810B2 (en) 2006-02-03 2010-02-02 Texas Instruments Incorporated Scan testing using scan frames with embedded commands
US7200783B2 (en) * 2003-11-04 2007-04-03 Texas Instruments Incorporated Removable and replaceable TAP domain selection circuitry
US7356786B2 (en) * 1999-11-30 2008-04-08 Synplicity, Inc. Method and user interface for debugging an electronic system
US7240303B1 (en) 1999-11-30 2007-07-03 Synplicity, Inc. Hardware/software co-debugging in a hardware description language
US6823497B2 (en) * 1999-11-30 2004-11-23 Synplicity, Inc. Method and user interface for debugging an electronic system
US7065481B2 (en) * 1999-11-30 2006-06-20 Synplicity, Inc. Method and system for debugging an electronic system using instrumentation circuitry and a logic analyzer
US8286046B2 (en) 2001-09-28 2012-10-09 Rambus Inc. Integrated circuit testing module including signal shaping interface
JP4217158B2 (ja) * 2002-01-23 2009-01-28 インテリテック コーポレイション 電子回路のライセンスされた引渡しおよび課金をするための管理システム、方法および装置
TW531876B (en) * 2002-04-24 2003-05-11 Winbond Electronics Corp Manufacturing method of identification code for integrated circuit
US7827510B1 (en) 2002-06-07 2010-11-02 Synopsys, Inc. Enhanced hardware debugging with embedded FPGAS in a hardware description language
US7231552B2 (en) * 2002-10-24 2007-06-12 Intel Corporation Method and apparatus for independent control of devices under test connected in parallel
US7424417B2 (en) * 2002-11-19 2008-09-09 Broadcom Corporation System and method for clock domain grouping using data path relationships
JP2004264057A (ja) * 2003-02-12 2004-09-24 Sharp Corp バウンダリスキャンコントローラ、半導体装置、半導体装置の半導体回路チップ識別方法、半導体装置の半導体回路チップ制御方法
US7340364B1 (en) * 2003-02-26 2008-03-04 Advantest Corporation Test apparatus, and control method
JP2005037995A (ja) * 2003-07-15 2005-02-10 Toshiba Corp 半導体集積回路の検証システム
DE10340828A1 (de) * 2003-09-04 2005-04-28 Infineon Technologies Ag Testanordnung und Verfahren zur Auswahl eines Testmodus-Ausgabekanals
DE60323851D1 (de) * 2003-12-17 2008-11-13 St Microelectronics Res & Dev TAP Multiplexer
EP1544631B1 (de) * 2003-12-17 2007-06-20 STMicroelectronics Limited Reset-Modus für Scan-Test-Modi
DE60323246D1 (de) * 2003-12-17 2008-10-09 St Microelectronics Res & Dev TAP-Daten-Transfer mit doppelter Daten-Rate
US7752004B1 (en) * 2004-01-09 2010-07-06 Cisco Technology, Inc. Method and apparatus for configuring plurality of devices on printed circuit board into desired test port configuration
US7149943B2 (en) * 2004-01-12 2006-12-12 Lucent Technologies Inc. System for flexible embedded Boundary Scan testing
US20050204217A1 (en) * 2004-02-06 2005-09-15 Whetsel Lee D. Identical core testing using dedicated compare and mask circuitry
US7356745B2 (en) * 2004-02-06 2008-04-08 Texas Instruments Incorporated IC with parallel scan paths and compare circuitry
US7096139B2 (en) * 2004-02-17 2006-08-22 Advantest Corporation Testing apparatus
US7404128B2 (en) * 2004-02-17 2008-07-22 Texas Instruments Incorporated Serial data I/O on JTAG TCK with TMS clocking
US7584386B2 (en) * 2004-04-21 2009-09-01 Stmicroelectronics Sa Microprocessor comprising error detection means protected against an attack by error injection
US7395471B2 (en) 2004-06-17 2008-07-01 Texas Instruments Incorporated Connection of auxiliary circuitry to tap and instruction register controls
US7412624B1 (en) * 2004-09-14 2008-08-12 Altera Corporation Methods and apparatus for debugging a system with a hung data bus
US7266743B2 (en) * 2004-09-30 2007-09-04 Intel Corporation Combinatorial at-speed scan testing
US7263639B2 (en) * 2004-09-30 2007-08-28 Intel Corporation Combinatorial at-speed scan testing
JP2006107590A (ja) * 2004-10-04 2006-04-20 Nec Electronics Corp 半導体集積回路装置及びそのテスト方法
US7500165B2 (en) 2004-10-06 2009-03-03 Broadcom Corporation Systems and methods for controlling clock signals during scan testing integrated circuits
US7650542B2 (en) * 2004-12-16 2010-01-19 Broadcom Corporation Method and system of using a single EJTAG interface for multiple tap controllers
JP4542910B2 (ja) * 2005-01-07 2010-09-15 Ｏｋｉセミコンダクタ株式会社 テストシステム
US7900099B2 (en) * 2005-01-25 2011-03-01 Micron Technology, Inc. Enabling test modes of individual integrated circuit devices out of a plurality of integrated circuit devices
US7543200B2 (en) * 2005-02-17 2009-06-02 Advantest Corporation Method and system for scheduling tests in a parallel test system
JP4826116B2 (ja) * 2005-03-25 2011-11-30 富士通株式会社 Ｒａｍ試験装置及び試験方法
US7895308B2 (en) * 2005-05-11 2011-02-22 Tindall Steven J Messaging system configurator
TWI266065B (en) * 2005-05-18 2006-11-11 Via Tech Inc Chip capable of testing itself and testing method thereof
US7657807B1 (en) * 2005-06-27 2010-02-02 Sun Microsystems, Inc. Integrated circuit with embedded test functionality
US20070006056A1 (en) * 2005-06-30 2007-01-04 Lucent Technologies Inc. Method and apparatus for enabling multipoint bus access
US7208969B2 (en) * 2005-07-06 2007-04-24 Optimaltest Ltd. Optimize parallel testing
US7528622B2 (en) 2005-07-06 2009-05-05 Optimal Test Ltd. Methods for slow test time detection of an integrated circuit during parallel testing
US20070168809A1 (en) * 2005-08-09 2007-07-19 Naoki Kiryu Systems and methods for LBIST testing using commonly controlled LBIST satellites
US20070035321A1 (en) * 2005-08-10 2007-02-15 Emanuel Gorodetsky Device and method for testing mixed-signal circuits
KR100660640B1 (ko) * 2005-08-18 2006-12-21 삼성전자주식회사 웨이퍼 자동선별 테스트를 위한 데이터 기입 장치 및 방법
EP1791133A1 (de) * 2005-11-29 2007-05-30 STMicroelectronics Pvt. Ltd. Ein Verfahren zur gemeinsamen Nutzung von Testvorrichtungen für mehrere eingebettete Speicher und zugehöriges Speichersystem
US7345502B1 (en) * 2006-01-17 2008-03-18 Xilinx, Inc. Design security for configurable devices
US7404121B2 (en) * 2006-01-31 2008-07-22 Verigy (Singapore) Pte. Ltd. Method and machine-readable media for inferring relationships between test results
US7743304B2 (en) * 2006-02-17 2010-06-22 Verigy (Singapore) Pte. Ltd. Test system and method for testing electronic devices using a pipelined testing architecture
EP2677328B1 (de) 2006-02-17 2015-07-29 Mentor Graphics Corporation Mehrstufige Testreaktionsverdichter
KR100781276B1 (ko) * 2006-03-09 2007-11-30 엘지전자 주식회사 테스트 회로 변환 방법
US7360137B2 (en) * 2006-05-04 2008-04-15 Westell Technologies, Inc. Flash programmer for programming NAND flash and NOR/NAND combined flash
US20070258298A1 (en) * 2006-05-04 2007-11-08 Westell Technologies, Inc. Parallel programming of flash memory during in-circuit test
US20070260812A1 (en) * 2006-05-04 2007-11-08 Westell Technologies, Inc. Programming method for write buffer and double word flash programming
US7580807B2 (en) * 2006-06-15 2009-08-25 Texas Instruments Incorporated Test protocol manager for massive multi-site test
JP4262265B2 (ja) * 2006-06-20 2009-05-13 キヤノン株式会社 半導体集積回路
JP4705886B2 (ja) * 2006-06-20 2011-06-22 株式会社日立製作所 回路基板の診断方法、回路基板およびｃｐｕユニット
US20080016421A1 (en) * 2006-07-13 2008-01-17 International Business Machines Corporation Method and apparatus for providing programmable control of built-in self test
US7681081B2 (en) * 2006-09-15 2010-03-16 Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd. Test device and method for testing stability of computer
KR100881622B1 (ko) * 2006-11-14 2009-02-04 삼성전자주식회사 멀티칩 및 그것의 테스트 방법
US8108744B2 (en) * 2006-11-28 2012-01-31 Stmicroelectronics Pvt. Ltd. Locally synchronous shared BIST architecture for testing embedded memories with asynchronous interfaces
US7882405B2 (en) * 2007-02-16 2011-02-01 Atmel Corporation Embedded architecture with serial interface for testing flash memories
US8261143B2 (en) * 2007-05-07 2012-09-04 Texas Instruments Incorporated Select signal and component override signal controlling multiplexing TDI/TDO
US7877653B2 (en) * 2007-05-09 2011-01-25 Texas Instruments Incorporated Address and TMS gating circuitry for TAP control circuit
KR100878301B1 (ko) * 2007-05-10 2009-01-13 주식회사 하이닉스반도체 다중 테스트 모드를 지원하는 테스트 회로
US8015462B2 (en) * 2007-05-11 2011-09-06 Renesas Electronics Corporation Test circuit
US7958419B2 (en) * 2007-06-07 2011-06-07 Texas Instruments Incorporated Entering a shift-DR state in one of star connected components
CN101102566B (zh) * 2007-06-25 2010-12-08 中兴通讯股份有限公司 一种手机jtag调试接口信号设计方法及其调试方法
US8384410B1 (en) * 2007-08-24 2013-02-26 Advantest (Singapore) Pte Ltd Parallel test circuit with active devices
US7870448B2 (en) * 2007-12-18 2011-01-11 International Business Machines Corporation In system diagnostics through scan matrix
US7890286B2 (en) * 2007-12-18 2011-02-15 Hynix Semiconductor Inc. Test circuit for performing multiple test modes
CN101903784A (zh) * 2007-12-21 2010-12-01 索尼公司 模拟扫描电路、模拟触发器和数据处理设备
US7805644B2 (en) * 2007-12-29 2010-09-28 Texas Instruments Incorporated Multiple pBIST controllers
US8242796B2 (en) * 2008-02-21 2012-08-14 Advantest (Singapore) Pte Ltd Transmit/receive unit, and methods and apparatus for transmitting signals between transmit/receive units
US7793181B2 (en) * 2008-03-27 2010-09-07 Arm Limited Sequential storage circuitry for an integrated circuit
JP5167904B2 (ja) * 2008-03-28 2013-03-21 富士通株式会社 スキャン制御方法、スキャン制御回路及び装置
JP4992791B2 (ja) * 2008-03-28 2012-08-08 富士通株式会社 スキャン制御方法及び装置
JP2009266258A (ja) 2008-04-22 2009-11-12 Hitachi Ltd 半導体装置
US8112668B2 (en) * 2008-07-29 2012-02-07 Texas Instruments Incorporated Dynamic broadcast of configuration loads supporting multiple transfer formats
US8112249B2 (en) 2008-12-22 2012-02-07 Optimaltest Ltd. System and methods for parametric test time reduction
CN101813744B (zh) * 2009-02-23 2012-09-19 京元电子股份有限公司 平行测试系统以及平行测试方法
US8161434B2 (en) * 2009-03-06 2012-04-17 Synopsys, Inc. Statistical formal activity analysis with consideration of temporal and spatial correlations
US8312331B2 (en) * 2009-04-16 2012-11-13 Freescale Semiconductor, Inc. Memory testing with snoop capabilities in a data processing system
US8108742B2 (en) 2009-06-11 2012-01-31 Texas Instruments Incorporated Tap control of TCA scan clock and scan enable
KR20110015217A (ko) * 2009-08-07 2011-02-15 삼성전자주식회사 향상된 신호 무결성을 가지는 메모리 시스템
IT1398937B1 (it) * 2010-02-17 2013-03-28 St Microelectronics Srl Metodo per eseguire un testing elettrico di dispositivi elettronici
TWI482166B (zh) * 2010-03-19 2015-04-21 Hoy Technology Co Ltd Hybrid self - test circuit structure
US9304166B2 (en) * 2010-07-16 2016-04-05 Infineon Technologies Ag Method and system for wafer level testing of semiconductor chips
US9336105B2 (en) * 2010-09-30 2016-05-10 International Business Machines Corporation Evaluation of multiple input signature register results
CN102073565B (zh) * 2010-12-31 2014-02-19 华为技术有限公司 触发操作方法、多核分组调试方法、装置及系统
US8473792B2 (en) * 2011-01-06 2013-06-25 Lsi Corporation Logic BIST for system testing using stored patterns
CN102129887B (zh) * 2011-01-17 2016-03-23 上海华虹宏力半导体制造有限公司 存储器测试模式信号产生电路及方法
WO2012100830A1 (en) * 2011-01-27 2012-08-02 Advantest (Singapore) Pte. Ltd. Test card for testing one or more devices under test and tester
US8826086B2 (en) * 2011-02-07 2014-09-02 Sandisk Technologies Inc. Memory card test interface
US8615694B2 (en) * 2011-02-07 2013-12-24 Texas Instruments Incorporated Interposer TAP boundary register coupling stacked die functional input/output data
US8566657B2 (en) 2011-04-26 2013-10-22 Taiwan Semiconductor Manufacturing Co., Ltd. Circuit and method for diagnosing scan chain failures
WO2012159003A1 (en) * 2011-05-19 2012-11-22 Celerint, Llc. Parallel concurrent test system and method
US9817062B2 (en) * 2011-05-19 2017-11-14 Celerint, Llc. Parallel concurrent test system and method
US8756467B2 (en) * 2011-11-30 2014-06-17 Freescale Semiconductor, Inc. Methods and apparatus for testing multiple-IC devices
US8645774B2 (en) 2011-12-13 2014-02-04 International Business Machines Corporation Expedited memory drive self test
US8977919B2 (en) * 2012-02-21 2015-03-10 Texas Instruments Incorporated Scan, test, and control circuits coupled to IC surfaces contacts
US9091727B1 (en) * 2012-10-16 2015-07-28 Xilinx, Inc. Configuration and testing of multiple-die integrated circuits
US20150046763A1 (en) * 2013-08-12 2015-02-12 Apple Inc. Apparatus and Method for Controlling Internal Test Controllers
US10151794B2 (en) * 2014-06-19 2018-12-11 X-Fab Semiconductor Foundries Ag Sleek serial interface for a wrapper boundary register (device and method)
US9823304B2 (en) 2015-04-30 2017-11-21 Stmicroelectronics S.R.L. Integrated electronic device having a test architecture, and test method thereof
US20170125125A1 (en) * 2015-10-30 2017-05-04 Texas Instruments Incorporated Area-efficient parallel test data path for embedded memories
US11175638B2 (en) 2015-11-09 2021-11-16 Otis Elevator Company Self-diagnostic electrical circuit
DE102016123400B3 (de) 2016-01-19 2017-04-06 Elmos Semiconductor Aktiengesellschaft Eindrahtlichtsteuerbus mit mehreren Pegeln
US11262396B2 (en) 2017-02-10 2022-03-01 Checksum, Llc Functional tester for printed circuit boards, and associated systems and methods
WO2018223384A1 (zh) * 2017-06-09 2018-12-13 海能达通信股份有限公司 通信设备及其通信系统
CN109425796B (zh) * 2017-08-30 2021-09-07 中兴通讯股份有限公司 一种背板工装测试系统
CN109540268B (zh) * 2018-12-18 2020-06-30 成都前锋电子仪器有限责任公司 一种能够自动初始化的智能燃气表主板的检测方法
WO2020152230A1 (en) * 2019-01-22 2020-07-30 Advantest Corporation Automated text equipment using an on-chip-system test controller
CA3139887A1 (en) * 2019-05-10 2020-11-19 Westinghouse Electric Company Llc Calibration system and method
CN112147482B (zh) * 2019-06-26 2023-06-13 杭州广立微电子股份有限公司 一种并行测试系统及其测试方法
CN110808743B (zh) * 2019-10-30 2020-11-06 电子科技大学 一种高速并行信号处理方法与装置
EP4198529A4 (de) * 2020-08-31 2023-10-25 Huawei Technologies Co., Ltd. Chiptestschaltung und schaltungstestverfahren
CN112649717A (zh) * 2020-09-15 2021-04-13 广州市几米物联科技有限公司 一种测试方法、装置、终端设备及存储介质
CN112255527A (zh) * 2020-09-24 2021-01-22 胜达克半导体科技(上海)有限公司 一种测试组件及集成电路测试机
TWI773301B (zh) * 2021-05-07 2022-08-01 華邦電子股份有限公司 半導體晶圓與多晶片的並行測試方法

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0417905B1 (de) 1989-08-09 1997-11-05 Texas Instruments Incorporated Architektur des Abtastpfads eines Systems
US5617420A (en) * 1992-06-17 1997-04-01 Texas Instrument Incorporated Hierarchical connection method, apparatus, and protocol
US5627842A (en) 1993-01-21 1997-05-06 Digital Equipment Corporation Architecture for system-wide standardized intra-module and inter-module fault testing
US6006343A (en) * 1993-07-30 1999-12-21 Texas Instruments Incorporated Method and apparatus for streamlined testing of electrical circuits
DE69734379T2 (de) 1996-08-30 2006-07-06 Texas Instruments Inc., Dallas Vorrichtung zur Prüfung von integrierten Schaltungen
US6018815A (en) * 1996-10-18 2000-01-25 Samsung Electronics Co., Ltd. Adaptable scan chains for debugging and manufacturing test purposes
US5805610A (en) * 1997-04-28 1998-09-08 Credence Systems Corporation Virtual channel data distribution system for integrated circuit tester
US6000051A (en) 1997-10-10 1999-12-07 Logic Vision, Inc. Method and apparatus for high-speed interconnect testing
US6408413B1 (en) 1998-02-18 2002-06-18 Texas Instruments Incorporated Hierarchical access of test access ports in embedded core integrated circuits
JP2000276367A (ja) * 1999-03-23 2000-10-06 Advantest Corp データ書込装置、データ書込方法、及び試験装置
US6385749B1 (en) * 1999-04-01 2002-05-07 Koninklijke Philips Electronics N.V. (Kpenv) Method and arrangement for controlling multiple test access port control modules
US6476628B1 (en) * 1999-06-28 2002-11-05 Teradyne, Inc. Semiconductor parallel tester
US6728814B2 (en) * 2000-02-09 2004-04-27 Raytheon Company Reconfigurable IEEE 1149.1 bus interface
US6947884B2 (en) * 2000-03-02 2005-09-20 Texas Instruments Incorporated Scan interface with TDM feature for permitting signal overlay
US6618827B1 (en) * 2000-04-13 2003-09-09 Hewlett-Packard Development Company, L.P. System and method for parallel testing of IEEE 1149.1 compliant integrated circuits
US6671844B1 (en) * 2000-10-02 2003-12-30 Agilent Technologies, Inc. Memory tester tests multiple DUT's per test site
US6829730B2 (en) * 2001-04-27 2004-12-07 Logicvision, Inc. Method of designing circuit having multiple test access ports, circuit produced thereby and method of using same

Also Published As

Publication number Publication date
CN1610834A (zh) 2005-04-27
KR20030048024A (ko) 2003-06-18
KR100623310B1 (ko) 2006-09-18
JP2004522169A (ja) 2004-07-22
EP1402278A1 (de) 2004-03-31
US20030009715A1 (en) 2003-01-09
TWI250293B (en) 2006-03-01
EP1402278A4 (de) 2005-05-18
EP1402278B1 (de) 2007-08-15
TW200305027A (en) 2003-10-16
CA2421047A1 (en) 2003-01-16
WO2003005050A1 (en) 2003-01-16
CA2421047C (en) 2005-01-25
ATE370423T1 (de) 2007-09-15
US6988232B2 (en) 2006-01-17
HK1064444A1 (en) 2005-01-28
WO2003005050B1 (en) 2003-03-06
CN100416288C (zh) 2008-09-03
JP4083117B2 (ja) 2008-04-30
US7574637B2 (en) 2009-08-11
US20060107160A1 (en) 2006-05-18
DE60221836D1 (de) 2007-09-27

Similar Documents

Publication Publication Date Title
DE60221836T2 (de) Verfahren und vorrichtung zur optimierten parallelen prüfung und zum zugriff auf elektronische schaltung
DE60211659T2 (de) Verfahren und vorrichtung zur diagnose von ausfällen in einer integrierten schaltung unter verwendung von techniken des typs design-for-debug (dfd)
DE60220511T2 (de) Verfahren und system zur optimierung der testkosten und deaktivierungsdefekte für scan- und bist-speicher
DE60025789T2 (de) Logische eingebaute Selbstprüfung (LBIST) Steuerschaltungen, Systeme und Verfahren mit automatischer Bestimmung der maximalen Abtastkettenlänge
DE69634778T2 (de) Vorrichtung zum parallelen prüfen von halbleiterschaltkreisen
DE3903835C2 (de)
US7036062B2 (en) Single board DFT integrated circuit tester
DE602004003475T2 (de) Testen von integrierten schaltungen
DE102004053559A1 (de) Drahtloses, berührungsloses Testen von integrierten Schaltungen
EP0186724B1 (de) Prüf- und Diagnoseeinrichtung für Digitalrechner
DE4434927C2 (de) Verfahren zum Testen einer Schaltungsplatine
DE19943941A1 (de) Programmierbare JTAG-Netzwerkarchitektur zum Unterstützen eines proprietären Debug-Protokolls
DE102004009693A1 (de) Technik zum Kombinieren eines Abtasttests und eines eingebauten Speicherselbsttests
DE102005026403B4 (de) Verfahren zum Liefern von Abtastmustern zu einer elektronischen Vorrichtung
DE10150056A1 (de) Externe Prüfhilfsvorrichtung zur Verwendung zum Testen einer Halbleitereinrichtung und Verfahren zum Testen einer Halbleitereinrichtung unter Verwendung der Vorrichtung
WO2001022106A1 (de) Verfahren und anordnung zum datenschützenden selbsttest für microcontroller
DE102006035045A1 (de) Verfahren und Vorrichtung zum Eliminieren der Indexzeit einer automatischen Testausrüstung
DE60306164T2 (de) Verfahren und kontrolllogik zum ansteuern von mehreren taps (test access ports) über einen einzigen tap
DE10150058A1 (de) Vorrichtung und Verfahren zum Testen einer integrierten Halbleiterschaltung
DE2902375A1 (de) Logikbaustein fuer integrierte digitalschaltungen
DE102009012768B4 (de) JTAG Nachrichtenbox
DE112014006751T5 (de) Schlankes serielles Interface für ein Wrapper-Boundary-Register (vorrichtung und Verfahren)
EP1430320B1 (de) Elektronischer baustein und verfahren zu dessen qualifizierungsmessung
DE69921356T2 (de) Boundary-scanverfahren zur beendigung oder zum ändern von betriebsarten einer integrierten schaltung
DE4221435C2 (de) Elektronischer Baustein mit einer taktgesteuerten Schieberegisterprüfarchitektur (Boundary-Scan)

Legal Events

Date Code Title Description
8364 No opposition during term of opposition