DE69720157T2

DE69720157T2 - System und Verfahren zur Prüfung elektronischer Geräte

Info

Publication number: DE69720157T2
Application number: DE69720157T
Authority: DE
Inventors: Royce G. Jordan
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 1996-12-17
Filing date: 1997-12-17
Publication date: 2003-11-06
Anticipated expiration: 2017-12-18
Also published as: EP0849678A2; US6058255A; EP0849678A3; SG53138A1; EP0849678B1; KR19980064249A; TW359750B; DE69720157D1; JPH10209376A

Description

GEBIET DER ERFINDUNG

Diese Erfindung bezieht sich auf ein System und ein Verfahren zum Testen elektronischer Vorrichtungen, und insbesondere bezieht sie sich, wobei sie jedoch nicht hierauf beschränkt ist, auf den Test von anwendungsspezifischen integrierten Schaltungen (ASICs).

HINTERGRUND DER ERFINDUNG

Die IEEE-Norm 1149.1 (HAG: Joint Test Action Group Standard) führte eine "Boundary Scan"-Implementierung für den Test der Zusammenschaltung von ASICs ein. Die JTAG-Norm ist eine auf einem Scan-Vorgang beruhende Architektur, die beispielsweise auf einem zu testenden ASIC als ein Teil seiner Schaltung angeordnet ist. Ein Scan-Eingang empfängt an einem Eingangsanschluß serielle Daten und ein Scan-Ausgang empfängt an einem Ausgangsanschluß serielle Daten von dem ASIC. Der ASIC umfaßt außerdem einen Betriebsart-Anschluß, der jederzeit die gewünschte Betriebsart angibt, einen Taktanschluß und einen Rückstellanschluß.
ASICs werden getestet, sowohl bevor sie in Gehäuse (z. B. in Dual-in-line- Gehäuse oder Dip-Gehäuse, flache Chipträger oder LCCs, "Pin Grid Arrays", viereckige flache Gehäuse usw.) eingesetzt werden als auch danach. Bevor sie in ein Gehäuse eingesetzt werden, können die ASICs mit speziellen Maschinen geprüft werden, die spezielle Prüfkarten und Testvektoren verwenden, die einen Satz von Eingangssignalen, Ausgangssignalen und bidirektionalen Signalen umfassen. Diese Testvektoren werden verwendet, um für die Prüfmaschine Informationen bereitzustellen, damit der ASIC elektrisch stimuliert und geprüft werden kann. Jeder Vektor enthält einen Satz von Eingangssignalen (Stimulus) und einen Satz von Ausgangssignalen, die von der Prüfmaschine nach der Anwendung des Eingangsstimulus für jeden Testvektor verifiziert werden.
Wenn die Funktionsfähigkeit der vormontierten ASICs verifiziert worden ist, werden sie in ein Gehäuseteil eingesetzt und unter Verwendung des gleichen Typs von Vorrichtung erneut getestet, wobei diese jetzt mit einer Fassung statt mit einem Satz von Prüfspitzen ausgerüstet ist. Es wird der gleiche Satz Testvektoren verwendet, um den Zustand nach dem Montagevorgang zu verifizieren.
Die JTAG-Norm kann für die Überprüfung sowohl auf der Ebene des ASICs als auch, nachdem die ASICs auf einer Schaltkarte angebracht worden sind, auf der Ebene der Zusammenschaltung auf der Schaltkarte verwendet werden. Aufgrund der heutzutage gebräuchlichen Leitwegdichte und aufgrund der Verwendung von ASICs, die keine Anschlüsse haben, die zugänglich sind, wenn die ASICs auf diesen Schaltkarten angebracht worden sind, wird es zunehmend schwieriger, die Schaltkarten und die darauf angebrachten ASICs nach der Montage zu testen. Die JTAG-Norm 1149.1 stellt ein Schema dar, das eine spezielle Schaltungsanordnung umfaßt, die in die einzelnen ASICs integriert ist und ein Boundary-Scan-Register benutzt, das sich zwischen der in üblicher Weise funktionierenden ASIC-Schaltungsanordnung und den Anschlüssen des ASICs befindet. Die speziellen Testeigenschaften der JTAG-Norm ermöglichen, daß die JTAG-Schaltungsanordnung auf den ASICs die Schnittstelle der ASICs übernimmt und die Ausgangssignale der ASICs treibt, so daß sie von dem JTAG- Boundary-Scan der ASICs erfaßt werden können, mit denen sie auf der Schaltkarte verbunden sind. Die JTAG-Schaltungsanordnung kann außerdem auf ähnliche Weise verwendet werden, um die interne Funktionsweise der ASICs zu testen, obwohl sie auf der Schaltkarte angebracht sind. Dies erfolgt durch einen externen Standard-JTAG-Controller gesteuert über fünf serielle Signalschnittstellen, die einen Takt (TCK), eine Test-Betriebsartauswahl (TMS), ein Testdateneingangssignal (TDI), ein Testdatenausgangssignal (TDO) und das optionale Test- Rückstellsignal (TRST) umfassen.
Am Anfang wird über den Scan-Eingang ein Befehl in das Befehlsschieberegister des ASICs eingelesen. Sofort nach Abschluß des Einlesens wird der Befehl in dem Befehlsschieberegister decodiert (mittels einer kombinatorischen Logikschaltung derart expandiert, daß alle Steuersignale in den entsprechenden Zustand versetzt werden, um die Funktion zu erfüllen, die durch den Befehl definiert ist), und die decodierten Befehle oder Befehlsdecodierungen werden in einer Reihe von parallelen Auffangregistern gespeichert. Diese Befehlsdecodierungen werden verwendet, um die Aktionen der Testlogik zu steuern.
Von der JTAG-Norm 1149.1 werden nur drei Befehle benötigt; es gibt jedoch eine unbeschränkte Anzahl von optionalen Befehlen, wobei jeder Befehl seine eigene Decodierung hat. Jede Decodierung ist eine Kombination aus Steuerbits, die verwendet werden, um die Aktionen der Testlogik zu spezifizieren. Um die Schaltungsanordnung nach der JTAG-Norm vollständig zu testen, muß jeder Befehl in das Befehlsschieberegister geschoben werden, wobei Messungen durchgeführt werden, um den Zustand jedes Bits der Decodierung zu bestimmen. Da es schwierig ist, den Zustand dieser Decodierungsbits auf der Grundlage der Reaktion an den äußeren Anschlüssen des ASICs zu verifizieren, könnten bis zu mehren tausend Testvektoren für jedes Bit jedes Befehls erforderlich sein und zu einer riesigen Anzahl von Vektoren, langen Testzeiten und zusätzlichen Prüfkosten führen. Da jeder Befehl vollständig getestet werden muß und da jeder Befehlstest viele Testvektoren benötigt, erfordern ASICs, die mehr als nur ein paar JTAG- Befehle verwenden, eine inakzeptabel große Anzahl von Testvektoren. (Der Begriff "Testvektor" ist eine Beschreibung des Zustands der Anschlüsse eines ASICs zu einem beliebigen Zeitpunkt). Es ist offensichtlich, daß eine große Menge an Prüfzeit und -kosten gespart werden kann, indem die Anzahl der Testvektoren, die erforderlich sind, um die JTAG-Schaltungsanordnung auf dem ASIC zu testen, verringert wird.
Ein Problem, dem sich die vorliegende Erfindung widmet, ist der Test der JTAG-Schaltungsanordnung selbst. Da die JTAG-Schaltungsanordnung in jedem ASIC enthalten ist, muß sie verifiziert werden, bevor die Betriebsfähigkeit des ASICs bescheinigt werden kann. Im Stand der Technik wurde dieser Test ausgeführt, indem ein Testbefehl eingeschoben wurde und beobachtet wurde, wie der Chip daraufhin reagierte, wobei die Decodierung durch Beobachten der Funktion der Vorrichtung nach dem Senden des Befehls geprüft wurde. Dieser Test wird auf dem Prüfkopf ausgeführt und, wie weiter oben beschrieben ist, nach dem Montieren des ASICs wiederholt. Da die einzige Möglichkeit, die korrekte Funktionsweise des ASICs zu verifizieren, darin besteht, die Reaktion auf eine vorgegebene stimulierende Eingabe an seinen Ausgangsanschlüssen zu überwachen, kann das Testen der JTAG-Schaltungsanordnung sowohl kompliziert als auch zeitaufwendig sein. Obwohl die IEEE-Norm 1149.1a-1990 nur drei spezifische Befehle erfordert, erlaubt sie die Verwendung einer unendlichen Anzahl von Befehlen, die von den Entwicklern und Systemingenieuren definiert werden, um den Systemtest zu vereinfachen. Diese Tests werden ausgeführt, indem ein JTAG- Befehl eingelesen wird und dann die Eingänge des ASICs manipuliert werden, während die Ausgänge überwacht werden, um zu verifizieren, daß die korrekte Antwort erhalten wird. Da jeder Befehl in viele Bits decodiert wird (die verwendet werden, um die JTAG-Schaltungsanordnung zu steuern und die sofort, nachdem ein neuer Befehl eingelesen worden ist, aktualisiert werden) und da für jedes Bit verifiziert werden muß, daß es für jeden Befehl in korrekter Weise decodiert worden ist, könnten für eine vollständige Prüfung viele tausend Vektoren erforderlich sein. Dies führt zu langen Testzeiten und damit verbunden zu hohen Prüfkosten.
Die vorliegende Erfindung schafft einen Halbleiterbaustein, der eine in einer vorgegebenen Weise arbeitende funktionale Schaltungsanordnung besitzt, wobei der Baustein umfaßt:
eine Testschaltungsanordnung zum Testen der funktionalen Schaltungsanordnung des Bausteins, wobei die Testschaltungsanordnung umfaßt:
eine Decodierungsschaltungsanordnung zum Decodieren von Befehlsdaten und
ein Befehlshalteregister, das die decodierten Befehle speichert,
dadurch gekennzeichnet, daß die Testschaltungsanordnung ferner ein Befehlsdecodierungs-Testregister enthält, das die Ausgabe des Befehlshalteregisters empfängt und die decodierten Befehlsdaten als Ausgabe fit den Vergleich mit einer erwarteten Ausgabe bereitstellt.
Vorzugsweise enthält die Testschaltungsansordnung ferner eine Vergleichsschaltungsanordnung, die die Inhalte des Befehlsdecodierungs-Testregisters mit erwarteten decodierten Befehlsdaten vergleicht.
Vorzugsweise ist die Testschaltungsanordnung in Übereinstimmung mit der IEEE-Norm 1149.1-1990.
In einer Anordnung umfaßt der Baustein eine integrierte Schaltung.
Vorzugsweise umfaßt der Baustein ferner:
eine Schaltungsanordnung, die in Reaktion darauf, daß der Halbleiterbaustein in einer Testbetriebsart ist, die Befehlsdaten in Eingänge der funktionalen Schaltungsanordnung eingibt und
eine Schaltungsanordnung, die in Reaktion auf die Testschaltungsanordnung interne Aktionen des Bausteins erfaßt und beobachtet.
Vorzugsweise enthält die Decodierungsschaltungsanordnung:
einen Testdatenausgang, der mit einem Testdateneingang verbunden ist, um serielle Testdaten und -befehle zu empfangen,
ein Befehlsschieberegister, das mit dem Testdateneingang verbunden ist, um die Testdaten und -befehle zu empfangen,
eine Befehlsdecodierungsschaltung, die mit dem Befehlsschieberegister verbunden ist, um mehrere vorgegebene Testbefehle, die in dem Befehlsschieberegister empfangen werden, zu decodieren.
Vorzugsweise ist das Befehlsdecodierungs-Testregister so beschaffen, daß es mit dem Testdatenausgang verbunden ist, um die Inhalte des Befehlsdecodierungs-Testregisters an einen externen Komparator zu übertragen, der den decodierten Testbefehl mit einem erwarteten decodierten Befehl vergleicht.
Vorzugsweise ist der Baustein eine anwendungsspezifische integrierte Schaltung (ASIC).
Die Erfindung liefert außerdem ein Verfahren zum Testen eines Halbleiterbausteins, der eine in einer vorgegebenen Weise arbeitende funktionale Schaltungsanordnung besitzt, wobei das Verfahren die Schritte umfaßt, bei denen
in dem Baustein eine Testschaltungsanordnung vorgesehen wird, die ein Befehlsdecodierungs-Testregister zum Testen der funktionalen Schaltungsanordnung des Bausteins enthält,
Befehlsdaten für die Testschaltungsanordnung bereitgestellt und in dieser decodiert werden und
die decodierten Befehlsdaten in der Testschaltungsanordnung gespeichert werden,
gekennzeichnet durch den Schritt, bei dem die gespeicherten decodierten Befehlsdaten in das Befehlsdecodierungs-Testregister übertragen werden und
den Schritt, bei dem die Inhalte des Befehlsdecodierungs-Testregisters als eine Ausgabe für den Vergleich mit einer erwarteten Ausgabe bereitgestellt werden.
Vorzugsweise wird bei dem Schritt der Bereitstellung einer Testschaltungsanordnung eine Testschaltungsanordnung bereitgestellt, die mit der IEEE-Norm 1149.1-1990 in Übereinstimmung ist.
Vorzugsweise umfaßt das Verfahren ferner den Schritt, bei dem die Befehlsdaten in Eingänge der funktionalen Schaltungsanordnung des Halbleiterbausteins eingegeben werden und interne Aktionen des Halbleiterbausteins erfaßt und beobachtet werden.

ZUSAMMENFASSUNG DER ERFINDUNG

Ein System gemäß der vorliegenden Erfindung liefert ein schnelles Prüfmittel für die Testschaltungsanordnung nach JTAG-Norm, die schon auf einem ASIC vorhanden ist, und verringert in starkem Maße die Anzahl von Testvektoren, die erforderlich sind, um die Befehlsdecodierungslogik zu verifizieren. Eine Aufgabe der Erfindung besteht darin, während des Tests der JTAG-Schaltungsanordnung Taktzyklen zu sichern. Die tatsächliche Decodierung des Testbefehls kann betrachtet werden. Da die gleichen Logikgatter verwendet werden, um viele Befehle zu decodieren, kann ein reduzierter Testvektorsatz verwendet werden, um zu verifizieren, daß die Decodierungsschaltung in der JTAG-Schaltungsanordnung in korrekter Weise arbeitet. Die korrekte Funktionsweise der JTAG- Schaltungsanordnung selbst wird schnell verifiziert.
Dies wird dadurch erreicht, daß die Decodierungen von dem Befehl erfaßt werden, der diesem speziellen Test unmittelbar vorausgeht, so daß sie innerhalb von wenigen Taktzyklen übermittelt werden können, statt nach Verfahren des Standes der Technik viele tausend Taktzyklen zu benötigen, um zu verifizieren, daß die Decodierungen das leisten, wofür sie vorgesehen sind. Da der größte Teil der Decodierungslogik, die von den Befehlen verwendet wird, auch bei weiteren Befehlen anzutreffen ist, braucht die Wirkung der Logik nur anhand eines einzigen Befehls, der diesen Teil der Decodierung verwendet, verifiziert zu werden. Dieser einzigen Überprüfung folgend kann, wenn das Befehlsdecodierungs- Testregister einbezogen ist, die Überprüfung der Decodierung für die folgenden Befehle ausgeführt werden, indem einfach der Befehl, dessen Decodierung getestet werden soll, eingeschoben wird, der Testbefehl eingeschoben wird, der in dem Befehlsdecodierungs-Testregister gehaltene Wert ausgeschoben und mit dem erwarteten Ergebnis verglichen wird. Dieser Vergleichswert ist in den Testvektoren enthalten und wird von der Prüfvorrichtung geliefert. Das Befehlsdecodierungs-Testregister wird automatisch mit der Decodierung des vorherigen JTAG- Befehls geladen. Dieses Verfahren verringert in starkem Maße die Redundanz, die für die Überprüfung der Decodierung von ASICs erforderlich wäre, die kein Befehlsdecodierungs-Testregister enthalten.
Daraus folgt, daß eine bevorzugte Ausführungsform der Erfindung ein zusätzliches Testdatenregister schafft, hier als das Befehlsdecodierungs-Testregister bezeichnet, das verwendet wird, um die Decodierung des vorhergehenden JTAG- Befehls zu erfassen, so daß sie ausgeschoben und verifiziert werden kann. Wenn ein JTAG-Befehl in den ASIC geschoben wird, erfaßt dieses Befehlsdecodierungs-Testregister die Decodierung des vorhergehenden Befehls, bevor diese Decodierung durch die Decodierung des neuen Befehls ersetzt wird. Da die meisten der Decodierungsbits von mehreren verschiedenen Befehlen verwendet werden und eine korrekte Antwort auf ein Decodierungsbit von dem ASIC nur einmal gezeigt werden muß, kann dann der Rest der Befehle, die dieses Decodierungsbit verwenden, einfach verifiziert werden, indem die Decodierung über das Befehlsdecodierungs-Testregister ausgelesen wird. Das, was andernfalls mehrere tausend Vektoren benötigen würde, wird mit wenigen Vektoren vollbracht, wodurch Prüfzeit und -kosten gespart werden.
Insbesondere wird ein Mittel geschaffen, um die Anzahl der Testvektoren, die erforderlich sind, um zu verifizieren, daß jeder Befehl auf korrekte Weise decodiert worden ist, zu verringern. Es enthält ein Schieberegister, das mit der Decodierung des vorherigen JTAG-Befehls (aus den Auffangregistern, die weiter oben zum Stand der Technik beschrieben sind) geladen wird, bevor diese Decodierung durch die Decodierung des aktuellen Befehls ersetzt wird. Die in diesem Schieberegister gehaltenen Daten können dann unter Verwendung des Protokolls der JTAG-Norm ausgeschoben und untersucht werden, um sicherzustellen, daß sie korrekt sind. Wenn eine Schaltung gegeben ist, die n Bits der Befehlsdecodierung und m Befehle umfaßt, dann ergibt dies m mal n Bits Befehlsdecodierung, die unter Verwendung der JTAG-Protokolle und des JTAG-Systems des Standes der Technik getestet werden müssen. Durch das Hinzufügen einer weiteren Schieberegister-Stufe (des Befehlsdecodierungs-Testregisters), die hinzugefügt wird, um die Decodierung zu erfassen und für eine genaue Prüfung auszuschieben, ist es jedoch nur notwendig sicherzustellen, daß ein Decodierungsbit einmal funktionsbeteiligt ist. Daraufhin kann jeder nachfolgende Befehl verifiziert werden, indem statt der Reaktion an den Anschlüssen des Halbleiterbausteins einfach der Bitzustand überprüft wird.
Wenn ein ASIC angenommen wird, der nur 10 JTAG-Befehle und nur 10 Bits einer Befehlsdecodierung verwendet, und wenn jeder JTAG-Befehl 2 000 Testvektoren erfordert, um die korrekte Funktionsweise aller 10 Befehlsdecodierungsbits für diesen bestimmten Befehl zu verifizieren, würden unter Verwendung des JTAG-Systems und Protokolls des Standes der Technik 20 000 Testvektoren erforderlich sein. Bei Verwendung der beschriebenen Ausführung würden jedoch nur ein paar Befehle erforderlich sein, um unter Verwendung der Reaktion an den Systemanschlüssen des ASICs die Decodierungen zu verifizieren, wobei die übrigen Befehle unter Verwendung eines einfachen JTAG-Scans verifiziert werden könnten. Werden drei Befehle mit jeweils 2 000 Testvektoren und ungefähr jeweils 50 Testvektoren für die verbleibenden sieben Befehle angenommen, würde der Test nur 6 350 statt 20 000 Testvektoren erfordern. Obwohl die Zahlen in Abhängigkeit vom enthaltenen Befehlstyp, von der Anzahl der benutzten Befehle und von der Anzahl der verwendeten Befehlsdecodierungsbits schwanken, liefert dieses Beispiel einen groben Anhaltspunkt für das Konzept der vorliegenden Erfindung.
In einem anderen Beispiel verwendet ein gegebener ASIC mehrere verschiedene Befehle, die das Boundary-Scan-Register für ein Verschieben auswählen. Um zu zeigen, daß das Boundary-Scan-Register für jeden Befehl ausgewählt worden ist, würde der Stand der Technik erfordern, einen Datenstrom (mit einer Länge von 183 Bits) durch das ausgewählte Register zu schieben. In diesem ASIC werden vier Bits der 20 Befehlsdecodierungsbits verwendet, um den richtigen Pfad auszuwählen, wobei die Befehlslänge 8 Bit beträgt. Deshalb würde, wenn eine JTAG-Schaltungsanordnung des Standes der Technik verwendet wird, um die Decodierung zu verifizieren, jeder Befehl ungefähr 200 Testvektoren benötigen, nur um zu verifizieren, daß diese vier Decodierungsbits korrekt sind. Wenn vorausgesetzt wird, daß es sechs Befehle gibt, die dieses spezifische Schieberegister auswählen, so sind, um unter Verwendung des Systems und Protokolls des Standes der Technik 20% der Decodierungsbits zu testen, 1 200 Testvektoren erforderlich, denen ungefähr 500 Testvektoren bei Verwendung der vorliegenden Erfindung gegenüberstehen. Ferner würden diese 500 Testvektoren auch die übrigen 80% der Bits der letzten fünf Befehle verifizieren.

KURZBESCHREIBUNG DER ZEICHNUNG

Die vorliegende Erfindung wird nun weiter anhand eines Beispiels beschrieben, wobei auf die beigefügte Zeichnung Bezug genommen wird, in der
- Fig. 1 ein Blockschaltplan einer integrierten Schaltung des Standes der Technik ist;
- Fig. 2 eine Tabelle ist, die Testvektoren gemäß dem Stand der Technik für eine einfache Schaltung zeigt,
- Fig. 3 eine einfache integrierte Schaltung mit JTAG gemäß dem Stand der Technik ist;
- Fig. 4 eine integrierte Schaltung mit JTAG und bevorzugten Merkmalen gemäß der vorliegenden Erfindung ist;
- Fig. 5 eine Blockdarstellung des Befehlsdecodierungs-Testregisterblocks von Fig. 4 ist.

BESCHREIBUNG DER ZEICHNUNGEN

In Fig. 1 ist eine sehr einfache integrierte Schaltung (IC) des Standes der Technik gezeigt, um die nachfolgende Beschreibung der bevorzugten Ausführungsform zu vereinfachen. Diese Schaltung ist ein Register, das einen Wert von seinem Eingang D bei einer ansteigenden Flanke seines Taktsignaleingangs (CLK) entgegennimmt und diesen Wert an seinem Ausgang Q ausbringt.
Das Testen der integrierten Schaltung von Fig. 1 findet in zwei Phasen statt. In der ersten Phase wird die integrierte Schaltung getestet, während sie sich noch auf dem Wafer befindet. Dies erfolgt unter Verwendung einer Prüfvorrichtung, die Prüfspitzen enthält, die auf den Anschlußflächen der integrierten Schaltung plaziert werden, und die Signale an die Anschlußflächen anlegen, die mit den Eingängen D und CLK verbunden sind, und die Reaktion auf der Anschlußfläche messen, die mit dem Ausgang Q verbunden ist. Nachdem der Wafer diese Tests bestanden hat, wird er in einzelne "Plättchen" (einzelne integrierte Schaltungen vor dem Verkapseln) zerschnitten, die dann in einem Gehäuse plaziert werden. Diese Gehäuse könnten Dual-in-line-Gehäuse (Dips), flache Chipträger (LCCs), Singlein-line-Gehäuse, "Pin Grid Arrays" (PGAs) oder eine von vielen weiteren Verkapselungen sein. Jedoch enthält jedes Gehäuse einen Mechanismus, um das "Plättchen" zu halten und es mit der Außenseite des Gehäuses so zu verbinden, daß die Signale durch das Gehäuse in die integrierte Schaltung oder aus dieser heraus gelangen können. In der folgenden Diskussion werden diese Verbindungen an den integrierten Schaltungen als "Anschlüsse" bezeichnet.
Das Anlegen eines einzigen Satzes von Eingangsstimuli gefolgt von der Messung der Ausgangswerte zu einem vorgegebenen Zeitpunkt wird als ein Testvektor bezeichnet. Der Testvektor enthält die einzugebenden Eingangswerte und den erwarteten Ausgangswert, der sich aus diesem Satz von Eingangssignalen zu einem Zeitpunkt ergibt. Die Prüfvorrichtung muß die Eingangssignale anlegen, die Ausgangswerte messen und diese Ausgangswerte mit den Werten vergleichen, die in dem Testvektor enthalten sind. Es erfolgt eine Fehlerkennzeichnung, wenn der erwartete und der gemessene Ausgangswert nicht übereinstimmen. In der folgenden Diskussion werden "H" (high) und "L" (low) für hohe bzw. niedrige Eingangswerte und "1" (high) und "0" (low) für die Ausgangswerte verwendet.
Für die integrierte Schaltung von Fig. 1 besteht der Test nur aus ein paar Vektoren, wovon zwölf (12) in der Tabelle von Fig. 2 gezeigt sind. Der Testvektor #1 setzt die Eingänge D und CLK auf den niedrigen Wert (L), wodurch der Ausgang Q nicht definiert ist da es nicht möglich sein würde, den Wert des Ausgangs Q vorauszusagen, ohne ihn schon mit der Taktflanke in die integrierte Schaltung zu geben. Der Testvektor #2 enthält einen niedrigen Wert (L) am Eingang D und einen hohen Wert (H) am Takteingang CLK, was einen niedrigen Wert (0) am Ausgang Q ergeben soll, da das der Wert ist, der bei korrekter Funktion am Ausgang wäre. Der Testvektor #3 enthält einen hohen Wert (H) am Eingang D und einen niedrigen Wert (L) am Eingang CLK, um einen niedrigen Wert (0) am Ausgang Q zu liefern. Der Testvektor #4 enthält einen hohen Wert (H) am Eingang D, einen hohen Wert (H) am Eingang CLK und einen hohen Wert (1) am Ausgang Q. Für einen vollständigen Test wird der Ausgang überprüft, um zu sehen, daß seine Übergänge auf allen Kombinationen der vorliegenden Eingangs- und Ausgangswerte beruhen, was für eine einfache Funktionsprüfung zu 10 bis 12 Vektoren führt, wobei zwölf (12) derartige Vektoren fit den Test der Schaltung von Fig. I in der Fig. 2 des Standes der Technik gezeigt sind. Es wird angemerkt, daß typische integrierte Schaltungen sehr viel kompliziertere Schaltungsanordnungen als die einfache Schaltung von Fig. 1 enthalten und deshalb viel mehr Testvektoren benötigen, als hier veranschaulicht wird. Eine typische integrierte Schaltung kann aufgrund der Anzahl der in ihr enthaltenen internen Schaltungen (z. B. Register, Auffangregister, NAND-Gatter usw.) leicht eine Anzahl von Testvektoren in der Größenordnung von einer Million erfordern.
Die IEEE-Norm 1149.1a-1990 (JTAG) spezifiziert ein Verfahren, um eine Prüflogik so in eine integrierte Schaltung einzufügen, daß die integrierte Schaltung selbst benutzt werden kann, um die Zusammenschaltung zwischen ihr und weiteren integrierten Schaltungen in dem System zu testen, das außerdem eine JTAG-Schaltungsanordnung enthält, wie in der Fig. 3 des Standes der Technik gezeigt ist. Die Schaltungsanordnung selbst enthält einen JTAG- Testzugangsanschluß (TAP), ein Boundary-Scan-Register, das eine Boundary- Scan-Zelle für jeden Eingang und Ausgang, ausgenommen die JTAG- Schnittstellenanschlüsse TCK, TMS, TDI und TDO, enthält, ein Ausweichregister, das ein JTAG-spezifisches Schieberegister ist, ein Befehlsschieberegister, eine Befehlsdecodierungslogik und ein Befehlshalteregister. Ferner ermöglicht die Schaltungsanordnung die Verwendung einer zusätzlichen Schaltungsanordnung wie beispielsweise des Coderegisters der integrierten Schaltung, wie in Fig. 3 gezeigt ist.
Die JTAG-Schaltung von Fig. 3 wird für die Prüfung der äußeren Schnittstellen der integrierten Schaltung, fit die Prüfung der internen Schaltungen sowie für die Einrichtung von Flächen der integrierten Schaltung, die für spezielle Tests bestimmt sind, verwendet. Das JTAG-Verfahren verwendet zwei Scan-Typen, die sogenannten Befehls-Scans und die Daten-Scans. Ein Befehls-Scan beinhaltet, daß ein JTAG-TAP-Controller das Befehlsschieberegister auswählt und über den TDI-Anschluß Daten in dieses Schieberegister schiebt. Am Ende des Schieberegisters angelangt, werden die Daten, die in das Befehlsschieberegister geschoben worden sind, von der Befehlsdecodierungslogik decodiert (in einen Satz von Steuerbits expandiert, nachfolgend Befehlsdecodierungen genannt) und dann in dem Befehlsdecodierungs-Halteregister gespeichert, wo sie gehalten werden, bis es am Ende der nächsten Befehlsverschiebung aktualisiert wird. Diese Befehlsdecodierungen werden verwendet, um zu bestimmen, welches Datenregister für den Daten-Scan, die Betriebsart des Boundary-Scan-Registers ("Test" oder "Normal") und eine Anzahl von schaltungsspezifischen Aufgaben, die von den Entwicklern der integrierten Schaltung definiert worden sind, ausgewählt wird. Die genaue Verwendung dieser Bits ist wohlbekannt und fit die Diskussion der vorliegenden Erfindung nicht relevant, weshalb sie hier nicht weiter erörtert wird.
Ein Daten-Scan besteht aus einem drei Schritte umfassenden Prozeß, in dem das durch die Befehlsdecodierungsbits bezeichnete Register (1) die Daten erfaßt, (2) diese Daten ausschiebt (während neue Daten eingeschoben werden) und dann (3) eine vorgegebene Position am Ende des Schieberegisters mit den neuen Daten aktualisiert wird. Die Einzelheiten dieses Vorgangs sind wohlbekannt und für die Erfindung nicht von Bedeutung, weshalb sie nicht angeführt werden.
Wenn die JTAG-Schaltungsanordnung verwendet werden soll, um das System auf der Ebene der Zusammenschaltung zu testen, wird sie entweder in der Betriebsart "Test" oder in der Betriebsart "Normal" benutzt. In der Betriebsart "Normal" ist das Boundary-Scan-Register so konfiguriert, daß die Werte von den Eingangsanschlüssen über die Eingangs-Scan-Zellen direkt an die Kernlogik (den Teil der integrierten Schaltung, der von den E/A-Puffern verschieden ist, die ohne JTAG vorhanden wären) weitergegeben werden und die Werte von der Kernlogik durch die Ausgangs-Scan-Zellen direkt an die Ausgangsanschlüsse weitergegeben werden. Diese Betriebsart ermöglicht der Kernlogik der integrierten Schaltungen so zu funktionieren, als sei die JTAG-Schaltungsanordnung in der integrierten Schaltung nicht vorhanden. Wenn die integrierte Schaltung in der "normalen" Betriebsart arbeitet, wird das Boundary-Scan-Register dazu verwendet, immer dann "Momentaufnahmen" von den Werten zu machen, die an den Anschlüssen der integrierten Schaltung vorliegen, wenn dies von dem externen JTAG- Controller (der Schaltungsanordnung, die kein Bestandteil der integrierten Schaltung ist und dazu verwendet wird, die JTAG-Schnittstellenanschlüsse TMS und TDI zu steuern) angewiesen wird.
Wenn die integrierte Schaltung in der Betriebsart JTAG-"Test" ist, werden die Boundary-Scan-Zellen so gesteuert, daß die Daten, die den Eingängen der Kernlogik zugeführt worden sind, von dem Halteregister, das in den Boundary-Scan- Eingangszellen enthalten ist, gespeichert werden, und die Daten, die den Ausgangspuffern der integrierten Schaltung zugeführt worden sind, von den Auffangregistern, die in den Boundary-Scan-Ausgangszellen enthalten sind, gespeichert werden. Diese Funktionsweise ermöglicht dem Boundary-Scan-Register, die Kernlogik von Einwirkungen durch andere externe Ein/Ausgaben als diejenigen des JTAG-Controllers zu isolieren.
Die Betriebsart "Test" wird verwendet, wenn die integrierte Schaltung in das System für die Prüfung der Zusammenschaltung eingesetzt ist (wobei sie außerdem verwendet werden könnte, um die Kernlogik der integrierten Schaltung zu testen). Dies wird unter Verwendung einer Folge von Daten-Scans ausgeführt, um Werte in die Ausgangszellen der Boundary-Scan-Register zu laden, die verwendet werden, um die Ausgangsanschlüsse einer integrierten Schaltung zu treiben und deren Werte an den Eingangszellen des Boundary-Scan-Registers jeder möglichen integrierten Schaltung zu erfassen, die an diese Ausgangszelle angeschlossen ist.
Diese erfaßten Daten werden ausgeschoben und mit den erwarteten Datenwerten verglichen, um zu ermitteln, ob die Zusammenschaltung der integrierten Schaltungen auf der Ebene des Systems betriebsfähig ist.
Da die JTAG-Schaltungsanordnung in der integrierten Schaltung enthalten ist, muß verifiziert werden, daß sie voll betriebsfähig ist, bevor die integrierte Schaltung als voll funktionsfähig erklärt werden kann. Eines der komplizierteren Gebiete dieser Überprüfung ist das Gebiet der JTAG-Befehlsdecodierungen. Die Decodierungen bilden den Mechanismus, über den die JTAG-Schaltungsanordnung die Auswahl der Daten-Scan-Pfade, die Auswahl der "Test"- oder der "normalen" Betriebsart, die Einführung spezieller Testeigenschaften, die Steuerung von schaltkreisspezifischen Prüfvorgängen usw. steuert. Da diese Befehlsdecodierungen an den Anschlüssen der integrierten Schaltung nicht zugänglich sind, können sie nicht auf einfache Weise oder schnell getestet werden. Es muß jedoch jedes Befehlsdecodierungsbit jedes Befehls getestet werden, um den korrekten Betrieb sicherzustellen, bevor die integrierte Schaltung für funktionell fehlerfrei erklärt werden kann.
Eine Teilmenge der Überprüfungen, die ohne die vorliegende Erfindung erforderlich sind, umfaßt folgendes:
a) einen Daten-Scan für jeden Befehl, obwohl viele Befehle dieselben Scan- Pfade wählen und die Daten-Scans, wie etwa der/die Boundary-Scan-Pfad(e) und der/die interne(n) Scan-Pfad(e) lange Ketten von Schieberegistern sind, die viele Testvektoren erfordern, um einen einzigen Scan zu vervollständigen;
b) einen Test für jeden Befehl, um sicherzustellen, daß der Befehl im richtigen Betriebszustand (entweder "Test" oder "Normal") war, wobei eine Folge von Vektoren an die Eingänge angelegt wird und die Ausgangssignale gemessen werden, um zu ermitteln, ob sich die Eingangswerte durch die integrierte Schaltung fortgepflanzt haben;
c) den Test von speziellen Befehlsdecodierungen, wie beispielsweise von Befehlsdecodierungen, die interne Testfunktionen für jeden derartigen Befehl starten, um zu ermitteln, ob jeder Befehl die im zugeordnete interne Testfunktion startet;
d) die Überprüfung spezialisierter Befehlsdecodierungen (wie etwa des Befehlsdecodierungsbits, um das Hochziehen des Pegels an den Anschlüssen der integrierten Schaltung abzuschalten), um sicherzustellen, daß eine derartige spezialisierte Befehlsdecodierung nicht nur für den Befehl, der sie aktiviert, sondern auch für die Befehle, die nicht dafür vorgesehen sind, sie zu aktivieren, im richtigen Zustand ist.
Es sollte noch einmal angemerkt werden, daß die Befehlsdecodierungen für jeden JTAG-Befehl einen definierten Wert haben und deshalb für jeden möglichen JTAG-Befehl Verfahren zum Überprüfen jedes Befehlsdecodierungsbits ausgeführt werden müssen. Dies hat eine summierende Wirkung, da beispielsweise für jeden Befehl ein einfacher Test mit 1 000 Vektoren, um ein einziges Befehlsdecodierungsbit zu verifizieren, laufen muß. Dies führt zu mehreren zehntausend Tesivektoren pro Befehlsdecodierungsbit in der integrierten Schaltung.
Fig. 4 zeigt die Schaltung von Fig. 3 mit einigen bevorzugten erfinderischen Merkmalen (z. B. dem Befehlsdecodierungs-Testregister), die hinzugefügt worden sind. Eine vergrößerte Blockdarstellung des Befehlsdecodierungsregisters ist in Fig. 5 gezeigt.
Mit der integrierten Schaltung, die diese zusätzliche Schaltungsanordnung enthält, wird die Anzahl der Testvektoren durch eine Kombination aus einer Verringerung der Anzahl der Vektoren, die notwendig sind, um ein Befehlsdecodierungsbit für einen einzelnen Befehl zu verifizieren, und der Tatsache, daß für einen gegebenen Befehl alle Befehlsdecodierungsbits für eine genaue Prüfung in einem einzigen Daten-Scan ausgeschoben werden, verringert.
Da die Werte der Befehlsdecodierungen über einen JTAG-Daten-Scan-Pfad zugänglich sind, würde beispielsweise ein Befehl A über den Scan-Eingang TDI in das Befehlsschieberegister der integrierten Schaltung geschoben werden, der Befehl INDEC, um das Befehlsdecodierungsregister als Pfad für den JTAG- Daten-Scan auszuwählen, wird über den Scan-Eingang in das Befehlsschieberegister der integrierten Schaltung geschoben, und dann wird ein Daten-Scan ausgefährt, um den gesamten Satz der Befehlsdecodierungen für den Befehl A über den Scan-Ausgang (TDO) auszuschieben. Bei Verwendung dieses Verfahrens und des Befehlsdecodierungsregisters reduziert sich die frühere Teilmenge der Überprüfungen, die in Systemen des Standes der Technik notwendig sind, wie folgt:
a) Jeder Daten-Scan-Pfad wird durch eine spezifische Befehlsdecodierung ausgewählt. Dies erfordert einen Daten-Scan pro Pfad statt einen Daten-Scan pro Pfad pro Befehl.
b) Es wird verifiziert, daß die "Test"-/"Normal"-Betriebsart Befehlsdecodierung sowohl für die "Test"-Betriebsart als auch für die "normale" Betriebsart wirksam ist. Dies erfordert zwei Befehle und die damit verbundene Eingabe einer Folge von Vektoren in die Eingänge sowie das Messen der Ausgangssignale, um zu sehen, ob sich die Eingangswerte durch die integrierte Schaltung fortgepflanzt haben, statt zu erfordern, daß jeder Befehl einmalig über den Scan-Eingang in das Befehlsschieberegister eingeschoben wird, verbunden mit der Eingabe einer Folge von Vektoren in die Eingänge sowie Messen der Ausgangssignale, um zu sehen, ob sich die Eingangswerte durch die integrierte Schaltung fortgepflanzt haben.
c) Spezielle Befehlsdecodierungen, wie etwa Decodierungen, die interne Testfunktionen starten, werden nur für einen Befehl getestet, um zu ermitteln ob diese speziellen Befehlsdecodierungen diese interne Testfunktion gestartet haben, sowie außerdem für einen Befehl, der die interne Testfunktion nicht auslöst.
d) Spezialisierte Befehlsdecodierungen (wie etwa das Befehlsdecodierungsbit, um das Hochziehen des Pegels an den Anschlüssen der integrierten Schaltung abzuschalten) werden wie oben in c) für einen aktiven und für einen inaktiven Befehl verifiziert.
e) Der Rest des Tests ist eine Folge aus einfacher Eingabe des Befehls, dessen Decodierung zu verifizieren ist, Eingabe des Befehls INDEC und Ausgabe der zugehörigen Decodierung für die Überprüfung.
Im Betrieb, wenn die Vorrichtung in der "Test"-Betriebsart ist, wird ein Testbefehl, der von der JTAG-Schaltungsanordnung des ASICs ausgeführt werden soll, zunächst gemäß der Norm 1149.1 seriell auf den TDI-Eingangsanschluß des ASICs gegeben, wobei der Eingang TCLK verwendet wird, um die Daten mit den Taktflanken in das Befehlsschieberegister zu schieben. Nachdem der Befehl von dem Befehlsschieberegister empfangen worden ist, wird er anschließend von der Befehlsdecodierungs-Schaltungsanordnung, die typisch aus einer herkömmlichen kombinatorischen Logik für eine Decodierung oder einer anderen Decodierungsschaltungsanordnung, die den Fachleuten wohlbekannt ist, gebildet ist, in einen expandierten Testbefehl decodiert. Der decodierte Befehl wird dann in dem Befehlshalteregister erfaßt. Für die Durchführung des gewünschten Tests treiben die Ausgänge des Befehlshalteregisters verschiedene Schaltungen des ASICs. Gleichzeitig werden die Daten aus dem Befehlsdecodierungs-Halteregister von dem Befehlsdecodierungs-Testregister erfaßt.
Das Befehlsdecodierungs-Testregister ist ein parallel ladendes, seriell verschiebendes Register. Nachdem es mit dem decodierten Befehl aus dem Befehlshalteregister geladen worden ist, wird es als Reaktion auf ein Steuersignal, das an den seriellen Testdaten-Eingangsanschluß TDI abgegeben worden ist, über den seriellen Testdaten-Ausgangsanschluß TDO ausgeschoben. Die Inhalte des Befehlsdecodierungs-Testregisters könnten von einer weiteren Vorrichtung erfaßt und mit der erwarteten Decodierung für den bestimmten Testbefehl verglichen werden. Folglich kann die Decodierung des JTAG-Befehls als korrekt verifiziert oder als inkorrekt identifiziert werden. Die hier beschriebene Anwendung ermöglicht folglich eine schnelle Überprüfung der korrekten Funktionsweise des Befehlsschieberegisters, der Befehlsdecodierungs-Schaltungsanordnung und des Befehlshalteregisters. Diese schnelle Überprüfung der korrekten Funktionsweise war in der JTAG-Schaltungsanordnung des Standes der Technik nicht möglich.
Eine alternative Anordnung, die außerdem in Betracht gezogen wird, enthält nicht nur das Befehlsdecodierungs-Testregister, das die Inhalte des Befehlshalteregisters empfängt, sondern auch einen Komparator auf der Schaltkarte und ein zusätzliches Testregister, das ein erwartetes Decodierungsdatenwort empfängt. In dieser Anordnung könnte ein erwartetes Decodierungsdatenwort unter Verwendung des Eingangs TDI in die Komparator-Logik geschoben werden, woraufhin die weiter obenbeschriebenen Schritte ausgeführt werden würden, um einen Befehl zu decodieren. Statt die Inhalte des Befehlsdecodierungsregisters für einen Vergleich außerhalb des Chips mit einer erwarteten Decodierung wie weiter oben beschrieben seriell zu übertragen, könnte nun der Komparator auf der Schaltkarte die Inhalte des Befehlsdecodierungsregisters mit der erwarteten Decodierung vergleichen und eine Anzeige ausgeben, die auf der Grundlage des Vergleichsergebnisses angeben würde, ob eine Übereinstimmung oder keine Übereinstimmung vorliegt.
Obwohl die Erfindung mit Bezug auf eine spezifische bevorzugte Ausführungsform der Erfindung beschrieben worden ist, werden dem Fachmann viele Veränderungen und Modifikationen sofort offensichtlich sein.

Claims

1. Halbleiterbaustein, der eine in einer vorgegebenen Weise arbeitende funktionale Schaltungsanordnung besitzt, wobei der Baustein umfaßt:

eine Testschaltungsanordnung zum Testen der funktionalen Schaltungsanordnung des Bausteins, wobei die Testschaltungsanordnung enthält:

eine Decodierungsschaltungsanordnung zum Decodieren von Befehlsdaten und

ein Befehlshalteregister, das die decodierten Befehle speichert,

dadurch gekennzeichnet, daß die Testschaltungsanordnung ferner ein Befehlsdecodierungs-Testregister enthält, das die Ausgabe des Befehlshalteregisters empfängt und die decodierten Befehlsdaten als Ausgabe für den Vergleich mit einer erwarteten Ausgabe bereitstellt.

2. Baustein nach Anspruch 1, bei dem die Testschaltungsanordnung ferner eine Vergleichsschaltungsanordnung enthält, die die Inhalte des Befehlsdecodierungs-Testregisters mit erwarteten decodierten Befehlsdaten vergleicht.

3. Baustein nach Anspruch 1 oder Anspruch 2, bei dem die Testschaltungsanordnung mit der IEEE-Norm 1149.1-1990 in Übereinstimmung ist.

4. Baustein nach einem der Ansprüche 1 bis 3, der eine integrierte Schaltung umfaßt.

5. Baustein nach einem der Ansprüche 1 bis 4, der umfaßt:

eine Schaltungsanordnung, die in Reaktion darauf, daß der Baustein in einer Testbetriebsart ist, die Befehlsdaten in Eingänge der funktionalen Schaltungsanordnung eingibt, und

eine Schaltungsanordnung, die in Reaktion auf die Testschaltungsanordnung interne Aktionen des Bausteins erfaßt und beobachtet.

6. Baustein nach einem der Ansprüche 1 bis 5, bei dem die Decodierungsschaltungsanordnung enthält:

einen Testdatenausgang, der mit einem Testdateneingang verbunden ist, um serielle Testdaten und -befehle zu empfangen,

ein Befehlsschieberegister, das mit dem Testdateneingang verbunden ist, um die Testdaten und -befehle zu empfangen, und

eine Befehlsdecodierungsschaltung, die mit dem Befehlsschieberegister verbunden ist, um mehrere vorgegebene Testbefehle, die in dem Befehlsschieberegister empfangen werden, zu decodieren.

7. Baustein nach Anspruch 6, bei dem das Befehlsdecodierungs-Testregister so beschaffen ist, daß es mit den Testdatenausgang verbunden werden kann, um die Inhalte des Befehlsdecodierungs-Testregisters an einen externen Komparator zu übertragen, der den decodierten Testbefehl mit einem erwarteten decodierten Befehl vergleicht.

8. Baustein nach einem der Ansprüche 1 bis 7, der aus einer anwendungsspezifischen integrierten Schaltung (ASIC) besteht.

9. Verfahren zum Testen eines Halbleiterbausteins, der eine in einer vorgegebenen Weise arbeitende funktionale Schaltungsanordnung besitzt, wobei das Verfahren die Schritte umfaßt, bei denen:

in dem Baustein eine Testschaltungsanordnung vorgesehen wird, die ein Befehlsdecodierungs-Testregister zum Testen der funktionalen Schaltungsanordnung des Bausteins enthält,

Befehlsdaten für die Testschaltungsanordnung bereitgestellt und in der Testschaltungsanordnung decodiert werden; und

die decodierten Befehlsdaten in der Testschaltungsanordnung gespeichert werden,

gekennzeichnet durch den Schritt, bei dem die gespeicherten decodierten Befehlsdaten an das Befehlsdecodierungs-Testregister übertragen werden, und

den Schritt, bei dem die Inhalte des Befehlsdecodierungs-Testregisters als eine Ausgabe für den Vergleich mit einer erwarteten Ausgabe bereitgestellt werden.

10. Verfahren nach Anspruch 9, bei dem bei dem Schritt, bei dem die Testschaltungsanordnung bereitgestellt wird, eine Testschaltungsanordnung bereitgestellt wird, die mit der IEEE-Norm 1149.1-1990 in Übereinstimmung ist.

11. Verfahren nach Anspruch 9 oder Anspruch 10, das ferner den Schritt umfaßt, bei dem: die Befehlsdaten in Eingänge der funktionalen Schaltungsanordnung des Bausteins eingegeben werden und interne Aktionen des Bausteins erfaßt und beobachtet werden.