DE10343227A1

DE10343227A1 - System und Verfahren zum Testen eines Schaltungsaufbaus unter Verwendung einer extern erzeugten Signatur

Info

Publication number: DE10343227A1
Application number: DE10343227A
Authority: DE
Inventors: Erik H. San Jose Volkerink; Ajay Cupertino Khoche; Klaus D. Mountain View Hilliges
Original assignee: Agilent Technologies Inc
Current assignee: Advantest Singapore Pte Ltd
Priority date: 2002-12-03
Filing date: 2003-09-18
Publication date: 2004-07-15
Also published as: JP2004184413A; JP4580163B2; US7131046B2; US20040107395A1

Abstract

Ein System und ein Verfahren ermöglichen ein Testen eines Schaltungsaufbaus unter Verwendung einer extern erzeugten Signatur. Eine externe Testeinrichtung ist außerhalb eines DUT angeordnet. Eine solche externe Testeinrichtung ist betreibbar, um Testdaten in das DUT einzugeben, Ausgabedaten von dem DUT zu empfangen und um eine Signatur für zumindest einen Abschnitt von solchen empfangenen Ausgabedaten zu erzeugen. Die externe Testeinrichtung vergleicht die erzeugte Signatur mit einer erwarteten Signatur, um zu bestimmen, ob das DUT wie erwartet funktioniert. Wenn die erzeugte Signatur nicht mit einer erwarteten Signatur übereinstimmt, dann können die Fehlerdaten in ein Fehlerabbildungsprotokoll geschrieben werden. Vorzugsweise ist eine weitere Interaktion mit dem DUT nicht erforderlich, nachem erfaßt worden ist, daß eine erzeugte Signatur nicht mit einer erwarteten Signatur übereinstimmt, um eine solche Fehlerauswertung auszuführen. Somit kann die Fehlerauswertung gleichzeitig mit dem Testen des DUT ausgeführt werden. Die Maskendaten können in einer komprimierten Form gespeichert sein und dekomprimiert und zum Maskieren bestimmter nichtdeterministischer Ausgabebits beim Erzeugen der Signatur verwendet werden.

Description

Die vorliegende Erfindung bezieht sich allgemein auf ein Testen von integrierten Schaltungen und spezieller auf ein System und ein Verfahren zum Testen eines Schaltungsaufbaus unter Verwendung einer Signatur, die außerhalb des Testschaltungsaufbaus erzeugt wird.

Während eines typischen Halbleiterfertigungsprozesses werden eine Mehrzahl von integrierten Schaltungen als Einzelchips auf einem Halbleiterwafer gebildet. Jeder Halbleiterwafer weist allgemein Hunderte oder Tausende von individuellen Einzelchips auf, die auf demselben gebildet sind. Sobald die Einzelchips auf einem Halbleiterwafer gebildet sind, werden die Einzelchips dann getestet, um zu bestimmen, welche Einzelchips funktionsfähig sind und welche Einzelchips nicht funktionsfähig sind. Bei den meisten Testverfahren wird jeder Einzelchip unter Verwendung einer Sondenausrüstung untersucht, während sich die Einzelchips immer noch auf dem Wafer befinden. Dieser Schritt ist auch als „Wafersortierung" bekannt.

Zweck des Sondentests auf Waferebene ist es, möglichst früh im Herstellungsprozeß zu bestimmen, ob jeder individuelle Einzelchip defekt ist oder nicht. Je früher ein defekter Einzelchip erfaßt wird, desto weniger Zeit und Kosten werden auf die Weiterverarbeitung des defekten Einzelchips aufgewendet. Das heißt, wenn bestimmt wird, daß ein erfaßter Defekt nicht behoben werden kann, werden weder Zeit noch Kosten für die Fertigstellung einer Chipanordnung aufgewendet. Nach dem Testen auf Waferebene werden die funktionsfähigen Einzelchips dann gehäust, und allgemein wird das gehäuste Teil erneut getestet, um sicherzustellen, daß während des Häusens keine Defekte eingeführt wurden. Es sind verschiedene Techniken zum Ausführen eines Testens auf Wa ferebene entwickelt worden, wie z. B. jene, die weiter unten beschrieben sind, und, wie in der Technik bekannt ist, können auch ähnliche Techniken zum Testen eines gehäusten Bauelements verwendet werden.

Bei einem typischen Halbleitertesten empfängt das DUT (DUT = device under test = Testobjekt) (das als ein CUT (CUT = circuitry under test = Testschaltungsaufbau) bezeichnet werden kann und ein DUT auf einem Wafer sowie ein gehäustes Bauelement umfassen kann) einen Satz von eingegebenen Stimuli von einer ATE (ATE = automatic test equipment = automatische Testausrüstung), die außerhalb der DUT angeordnet ist, wonach die ATE die Ausgaben des DUT beobachtet. Allgemein werden die korrekten erwarteten Ausgaben des DUT im ATE-Speicher gespeichert, und die ATE vergleicht alle ausgegebenen Bits, die von dem DUT erhalten wurden, mit den gespeicherten erwarteten Bitwerten, um zu bestimmen, ob das DUT ordnungsgemäß funktioniert (z. B. ob das DUT die erwarteten Ausgabewerte ansprechend auf die Eingabewerte erzeugt). Somit kann ein DUT (z. B. ein Bauelement auf einem Wafer oder ein gehäustes Bauelement) mit einer externen ATE kommunikativ gekoppelt sein, und eine solche ATE kann Teststimuli in dasselbe eingeben und Antworten von demselben empfangen und analysieren. Wie nachstehend weiter beschrieben ist, kann ein Schaltungsaufbau auf dem DUT umfaßt sein, der beispielsweise ansprechend auf die eingegebenen Stimuli eine Signatur entsprechend der Antwort des DUT erzeugen kann, und eine solche Signatur kann an das ATE ausgegeben werden. Obgleich ein Großteil der Testverfahren, die hierin beschrieben sind, als Testen eines DUT, das sich auf einem Wafer befindet (d. h. Testen auf Waferebene), beschrieben ist, wird darauf hingewiesen, daß ähnliche Techniken typischerweise ebenfalls zum Testen eines gehäusten Bauelements verwendet werden können.

Im Falle eines Testens auf Waferebene kann eine Sonde mit einer oder mehreren Verbindungsanschlußflächen eines Chips in Kontakt gebracht werden, um Signale (z. B. ein Testmus ter) an den Einzelchip zu kommunizieren und um die Signale, die durch den Chip ansprechend auf die Eingabesignale ausgegeben werden, zu empfangen. Die Sonde ist typischerweise mit einer externen ATE kommunikativ gekoppelt, die betreibbar ist, um die Signale, die in einen Chip eingegeben werden sollen, zu erzeugen, und um die Signale, die durch den Chip ausgegeben werden, auszuwerten, um zu bestimmen, ob der Chip ordnungsgemäß funktioniert. Einzelchips auf einem Wafer können seriell (z. B. durch Kontaktieren von jedem Chip mit der Sonde in Reihe) oder parallel getestet werden.

Herkömmliche Testverfahren des Stands der Technik erfordern eine unerwünscht hohe Speichermenge auf der ATE, die zum Testen verwendet wird, was in unerwünschter Weise die Kosten der ATE und des resultierenden Produkts erhöht. Eine ausreichende Datenspeicherung, die mit der ATE kommunikativ gekoppelt ist, ist beispielsweise allgemein zur Speicherung von zumindest den nachstehenden Informationen für ein Testverfahren erforderlich: 1) Eingabevektordaten, 2) Ausgabevektordaten und 3) Maskenvektordaten. Allgemein weisen die Eingabevektordaten, die an der ATE gespeichert werden, die Daten auf, die als Stimuli für die Eingaben in das DUT (z.B. Testmusterdaten) verwendet werden, und die Ausgabevektordaten weisen die erwarteten Ausgabedaten des DUT angesichts der Eingabevektordaten auf, die zum Vergleich mit der tatsächlichen Datenausgabe des DUT ansprechend auf die Eingabevektordaten verwendet werden, um zu bestimmen, ob das DUT ordnungsgemäß funktioniert. Allgemein weisen die Maskenvektordaten Daten auf, die bezeichnen, welches der Bits der erwarteten Ausgabedaten tatsächlich mit den empfangenden Ausgaben des DUT verglichen werden müssen, z. B. bilden die Maskenvektordaten die erwarteten Ausgabedaten auf die tatsächlichen Ausgabedaten ab, die vom DUT empfangen werden, da bei bestimmten Konfigurationen alle Ausgabebits des DUT nicht mit den erwarteten Ausgabedaten verglichen werden können (z. B. können bestimmte nicht deterministische Bits oder „bedeutungslose/unbekannte Bits" existieren, deren Wert für das richtige Funktionieren des tieren, deren Wert für das richtige Funktionieren des DUT nicht relevant ist).

Solche Eingabevektordaten, Ausgabevektordaten und Maskenvektordaten für ein Testverfahren können eine unerwünscht große Datenspeicherplatzmenge auf dem ATE verbrauchen. Ferner steigt die Datenspeicherplatzmenge, die auf dem ATE verbraucht wird, für diese Vektordaten wahrscheinlich an, da der Umfang des Testverfahrens erhöht wird und/oder die Komplexität des Bauelements, das getestet werden soll, zunimmt. Herkömmliche Testverfahren des Stands der Technik verwenden z. B. üblicherweise näherungsweise 400 bis 800 Bits pro Gatter des DUT, das getestet wird. Natürlich kann die Größe der Eingabevektordaten, Ausgabevektordaten und/oder Maskenvektordaten, abhängig von der Komplexität des DUT und/oder des Umfangs des Testverfahrens, das implementiert wird (die Anzahl von Flip-Flops auf dem DUT, das getestet wird, und/oder die Anzahl von Eingabetestmustern, die 'verwendet werden) von Testverfahren zu Testverfahren variieren (jedoch ist bei aktuellen ATE-Architekturen für jedes Ausgabebit ein Maskenbit erforderlich, so daß das Maskenvektorspeicher gleich dem Ausgabevektorspeicher ist). Die Ausführungsbeispiele der vorliegenden Erfindung überwinden diese Barriere, wodurch eine Verringerung der Datenspeicherungsmenge, die auf einer ATE für einen Test erforderlich ist, ermöglicht wird.

Allgemein ist es wünschenswert, die Datenspeicherungsmenge, die auf der ATE zum Implementieren eines Testverfahrens erforderlich ist, zu minimieren. Im Stand der Technik sind mehrere Lösungen vorgeschlagen worden, um die Datenspeicherungsanforderungen der ATE zum Implementieren eines Testverfahrens zu reduzieren, und, spezieller, um die Speicheranforderung der ATE zum Speichern der Ausgabevektordaten für ein Testverfahren zu reduzieren. Die überzeugendsten Techniken zum Minimieren der Datenspeicherungsmenge, die auf einer ATE zum Speichern von Ausgabevektordaten erforderlich ist, sind Vektorsatzabschneidetechniken und Auf-Chip-Signaturanalysetechniken, die nachstehend ferner Chip-Signaturanalysetechniken, die nachstehend ferner beschrieben werden.

Ein beliebtes Verfahren zum Minimieren der Datenspeicherungsmenge, die auf einer ATE zum Speichern von Ausgabevektordaten erforderlich ist, ist das Abschneiden. Allgemein umfaßt das Abschneiden ein Fallenlassen eines Abschnitts des Tests, d. h. eines Abschnitts der Ausgabedaten, Maskendaten und/oder Eingabedaten, (d. h. ein Nichtverwenden dieses Testabschnitts beim Bestimmen, ob das DUT ordnungsgemäß funktioniert). Infolgedessen kann die Datenmenge, die auf der ATE gespeichert ist, verringert werden. Das Abschneiden der Vektorsätze (z. B. Eingabe-, Ausgabe- und Maskenvektorsätze) führt jedoch beispielsweise zu einer Verringerung einer Testabdeckung, und infolgedessen kann es zu einer Verringerung der Produktqualität führen (d. h. das Abschneiden verringert den Umfang des Testens eines DUT, was zu einem nicht ordnungsgemäßen Funktionieren der DUT führen kann, das den Test besteht). Diese Verringerung in der Produktqualität ist häufig nicht akzeptabel. Manchmal wird dieses Verfahren in Kombination mit einer Vektorsatzneuordnung basierend auf der Wahrscheinlichkeit verwendet, daß ein Vektor tatsächlich einen Defekt für jeden Vektor erfaßt, woraufhin der Schweif der Vektortaten abgeschnitten wird. Auf diese Weise kann die Auswirkung auf die Testabdeckung minimiert werden. In den meisten Fällen besteht jedoch immer noch eine beträchtliche Auswirkung auf die Testabdeckung.

Eines der attraktivsten Ausgabekomprimierungsschemata basiert auf einer Signaturanalyse. Die Signaturanalyse ist ein hinreichend bekanntes Verfahren zum Komprimieren einer Sequenz von logischen Werten, die von einer Testschaltung ausgegeben werden, in eine relativ kleine Anzahl von Bits von Daten (Signatur), die, wenn sie mit gespeicherten Daten verglichen werden (z. B. einer erwarteten Signatur), das Vorliegen oder die Abwesenheit von Fehlern in der Schaltung anzeigen. Allgemein komprimiert eine Signatur einer Gruppe von Ausgabebits eine solche Gruppe von Ausgabebits und identifiziert in eindeutiger Weise eine solche Gruppe von Ausgabebits, so daß bestimmt werden kann, ob die Gruppe von Ausgabebits so ausfällt wie erwartet. Es wird darauf hingewiesen, daß allgemein eine geringe Möglichkeit zum Erhalten einer korrekten Signatur für inkorrekte Ausgabebits (Aliasing) besteht. Obgleich eine Signatur verwendet, werden kann, um festzustellen, ob die Gruppe von Ausgabebits ausfällt wie erwartet, kann von der Signatur, wenn die Signatur nicht ausfällt wie erwartet, allgemein nicht festgestellt werden, welche (s) von der Gruppe von Ausgabebits unerwartete Werte aufwies(en). Somit ist die Diagnose von Fehlern oder eine Fehlerbereinigung allgemein begrenzt (nicht verfügbar), wenn eine Auf-Chip-Signaturerzeugung verwendet wird. Allgemein bezieht sich die Fehlerdiagnose auf einen Prozeß zum Identifizieren eines Fehlers in einem DUT, wie z. B. Bestimmen der Situation(en), in denen das DUT einen Fehler aufweist, und/oder Bestimmen der(des) Bits, die (das) infolge des Fehlers nicht korrekt sind (ist). Die Fehlerbereinigung bezieht sich allgemein auf einen Prozeß zum Bestimmen der Ursache eines Fehlers.

Im Stand der Technik sind verschiedene Techniken zum Erzeugen einer Signatur für Ausgabedaten hinreichend bekannt. Eine Technik weist beispielsweise das Zuführen der kompletten Ausgabevektordaten durch ein lineares Rückkopplungsschieberegister mit unterschiedlichen exklusiven ODER(XOR-) Rückkopplungsschleifen auf, die eine sehr kurze Signatur in dem Schieberegister zur Folge haben, das von allen Ausgabevektordaten abhängt. Wenn die Rückkopplungsschleifen, d. h. die Polynome, des Schieberegisters sorgfältig ausgewählt sind, wird kein bemerkenswertes Aliasing eintreten. Die Auf-Chip-Techniken zum Erzeugen einer Signatur der Ausgabedaten des Chipelements während des Testens unter Verwendung eines Schaltungsaufbaus, der als SISR (SISR = Single Input Signature Register = Einzeleingabesignaturregister) oder (im Falle von mehreren XOR-Eingängen) als MISR (MISR = Multiple Input Signatur Register = Mehrfachein gangssignaturregister) bezeichnet wird, sind im Stand der Technik vorgeschlagen worden. Ein solcher SISR- und MISR-Schaltungsaufbau zum Erzeugen von Signaturen auf dem Chip sind in der Technik hinreichend bekannt und werden daher hierin nicht ausführlicher beschrieben. Beispiele von Testschemata, die eine Signaturanalyse verwenden (z. B. über ein MISR) sind in folgenden Patenten beschrieben: 1) U.S.-Patent Nummer 6,442,722 mit dem Titel „METHOD AND APPARATUS FOR TESTING CIRCUITS WITH MULTIPLE CLOCKS", das an Nadeau-Dostie u. a. erteilt wurde; 2) U.S.-Patent Nummer 6,393,594 mit dem Titel „METHOD AND SYSTEM FOR PERFORMING PSEUDO-RANDOM TESTING OF AN INTEGRATED CIRCUIT", das an Anderson u. a. erteilt wurde; 3) U.S.-Patent Nummer 6,374,370 mit dem Titel „METHOD AND SYSTEM FOR FLEXIBLE CONTROL OF BIST REGISTERS BASED UPON ON-CHIP EVENTS", das an Bockhaus u. a. erteilt wurde; 4) U.S.-Patent Nummer 6,363,506 mit dem Titel „METHOD FOR SELF-TESTING INTEGRATED CIRCUITS", das an Karri u. a. erteilt wurde; 5) U.S.-Patent Nummer 6,327,685 mit dem Titel „LOGIC BUILT-IN SELF TEST", das an Koprowski u. a. erteilt wurde; 6) U.S.-Patent Nummer 6,240,537 mit dem Titel „SIGNATURE COMPRESSION CIRCUIT AND METHOD", das an Sim erteilt wurde; 7) U.S.-Patent Nummer 6,158,033 mit dem Titel „MULTIPLE INPUT SIGNATURE TESTING & DIAGNOSIS FOR EMBEDDED BLOCKS IN INTEGRATED CIRCUITS", das an Wagner u. a. erteilt wurde; 8) U.S.-Patent Nummer 5,978,946 mit dem Titel „METHODS AND APPARATUS FOR SYSTEM TESTING OF PROCESSORS AND COMPUTERS USING SIGNATURE ANALYSIS", das an Needham erteilt wurde; 9) U.S.-Patent Nummer 5,960,008 mit dem Titel „TEST CIRCUIT", das an Osawa u. a. erteilt wurde; 10) U.S.-Patent Nummer 5,938,784 mit dem Titel „LINEAR FEEDBACK SHIFT REGISTER, MULTIPLE INPUT SIGNATURE REGISTER, AND BUILT-IN SELF TEST CIRCUIT USING SUCH REGISTERS", das an Kim erteilt wurde, deren Offenbarungen hierin durch Bezugnahme aufgenommen worden sind. Ein weiteres Beispiel eines Testschemas, das eine Signaturanalyse verwendet, (z. B. über ein MISR) ist in der veröffentlichten U.S.-Patentanmeldunq Nummer 20020073374 mit dem Titel „METHOD, SYSTEM AND PROGRAM PRODUCT FOR TESTING AND/OR DIAGNOSING CIRCUITS USING EMBEDDED TEST CONTROLLER ACCESS DATA" beschrieben, deren Offenbarung hierin durch Bezugnahme aufgenommen worden ist.

Es wird darauf hingewiesen, daß, weil eine Signatur eine komprimierte Identifizierung der Ausgabebits ist, die Speicherplatzmenge, die auf einer ATE zum Speichern der Ausgabevektordaten (erwarteten Signaturen) erforderlich ist, gut unter die Menge reduziert werden kann, die zum Speichern aller tatsächlichen erwarteten Ausgabebits erforderlich ist. Weil ferner eine Signatur einen ganzen Satz von Ausgabebits (innerhalb der Grenzen des Aliasing), der analysiert werden soll (z. B. der gesamte Ausgabevektor), identifizieren kann, wird die Testabdeckung nicht verringert, wie im Falle eines Abschneidens.

Die Auf-Chip-Signaturanalysetechniken des Stands der Technik weisen jedoch mehrere Nachteile auf. Zunächst umfassen solche Techniken einen Schaltungsaufbau auf dem Chip zum Erzeugen einer Signatur der Ausgabedaten des Chipelements während des Testens. Ein solcher Signaturerzeugungsschaltungsaufbau verbraucht eine Fläche auf dem Chip, wodurch die Gesamtgröße des Chips erhöht wird (oder die Menge des Schaltungsaufbaus, der ansonsten im Chip umfaßt ist, verringert wird) und potentiell das Verhalten des Chipelements behindert wird (z. B. aufgrund der erweiterten Entfernung, die die Signale evtl. angesichts der erhöhten Größe des Chipelements zurücklegen müssen). Auch kann ein Implementieren des Signaturerzeugungsschaltungsaufbaus auf dem Chip Entwurfsmodifizierungen erfordern, die an dem Testschaltungsaufbau vorgenommen werden müssen, um zu ermöglichen, daß ein solcher Signaturerzeugungsschaltungsaufbau mit denselben implementiert werden kann. Ferner wird der Signaturerzeugungsschaltungsaufbau typischerweise nur während des Testens des Schaltungsaufbaus verwendet. Das heißt, daß der Signaturerzeugungsschaltungsaufbau typischerweise nicht während eines Normalbetriebs des Schaltungsaufbaus in der Zielanwendung verwendet wird. Somit ist ein Implementieren des Signaturerzeugungsschaltungsaufbau auf dem Chip dahingehend nachteilig, daß er eine Fläche auf dem Chip verbraucht (wodurch die Gesamtgröße des Chipelements erhöht wird) und nur während des Testens des Chipelements nützlich ist. Ferner ist eine Signaturerzeugung auf dem Chip allgemein von Nachteil, weil sie keine Fehlerdiagnose (d. h. eine Bestimmung, welches) von der Gruppe von Ausgabebits, die eine inkorrekte Ausgabe aufweisen, nicht von der Signatur von solchen Ausgabebits erzeugt werden können (kann)) oder eine Fehlerbereinigung ermöglicht. Ferner kann ein Auf-Chip-Signaturerzeugungsschaltungsaufbau an sich Defekte aufweisen.

Da die Signatur von allen Ausgabevektordaten abhängt, hängt sie zusätzlich auch von Ausgabevektordatenbits ab, die kein nicht deterministisches Verhalten aufweisen. Dieses nicht deterministische Verhalten kann beispielsweise eintreten, wenn ein Teilabtastlösungsansatz verwendet wird, z. B. nur ein Teilsatz von Flip-Flops auf einem DUT abgetastet wird. Bei bestimmten Entwürfen können einige Flip-Flop aufgrund von Entwurfsbeschränkungen nicht abgetastet werden. Andere Quellen von nicht deterministischen (unbekannten) Ausgabezuständen umfassen ein Vorliegen von mehreren Taktbereichen und drei Tristate-Bussen. Infolgedessen können die Werte dieser nicht deterministischen Bits nicht ohne zusätzliche Impulsmodifizierungen gesteuert werden. Diese Entwurfsmodifizierungen führen jedoch zu zusätzlichen Flächenkosten und einer potentiellen Verschlechterung des Verhaltens. Das Vorliegen von unbekannten/nicht deterministischen Ausgabesignalen kann die Signatur verfälschen, wodurch die Signatur und der Test fast nahezu immer unbrauchbar werden. Die Auswirkung der Entwurfsmodifizierungen auf die Fläche, den Fluß und das Entwurfsverhalten kann im wesentlichen nachteilig und für einige Entwürfe nicht akzeptabel sein.

Zusätzlich möchte der Benutzer bei den Auf-Chip-Signaturerzeugungstechniken, die keine Auf-Chip-Maskierungsfähigkeit liefern, manchmal nur einen Teil des Tests ausführen oder bestimmte nicht deterministische Ausgaben vom Testschaltungsaufbau unterdrücken, z. B. während der Fehlerbereinigungsphase oder wenn bestimmte erwartete Ausgaben sich als unkorrekt simuliert herausstellen. In diesem Fall können die Signaturanalysetechniken des Stands der Technik abhängig von der Anzahl von maskierten Ausgaben nicht verwendet werden. Das heißt, weil die Signaturerzeugungstechniken des Stands der Technik einen Auf-Chip-Schaltungsaufbau aufweisen, der für ein Erzeugen einer Signatur einen bestimmten Satz von Ausgabewerten festgelegt ist, kann keiner dieser Ausgabewerte während des Testverfahrens herausmaskiert werden. Man könnte eine Auf-Chip-Maskierungsfähigkeit schaffen, jedoch sind im allgemeinen zusätzliche Kanäle/eine zusätzliche Bandbreite zum Liefern der Maskierungsdaten erforderlich.

Außerdem ist es rechnerisch sehr aufwendig und manchmal unmöglich, den Signaturanalyseprozeß umzukehren. In anderen Worten ist es durch Verwenden der Signaturanalysetechniken des Stands der Technik möglich, eine Diskrepanz zwischen den tatsächlichen Ausgabevektordaten und den erwarteten Ausgabevektordaten zu bestimmen. Es ist jedoch typischerweise nicht möglich, zu bestimmen, welche empfangenen Bits der Ausgabevektordaten falsch sind. Dies schränkt die Fehlerdiagnose/Fehlerbereinigungsfähigkeit von signaturbasierten Testverfahren des Stands der Technik ernsthaft ein und erfordert typischerweise einen Umgehungsmodus zum Ausführen einer Fehlerdiagnose/Fehlerbereinigung, der einen zusätzlichen Schaltungsaufbau und zusätzliche Eingaben/Ausgaben erfordert.

Für eine Testeinrichtung, die eine Signatur außerhalb des Chips erzeugt, sind Vorschläge gemacht worden. Zum Beispiel schlägt „Low-Cost Testing of High-Density Logic Components", IEEE Design & Test of Computers, 0740-7475 (April 1990) eine Testeinrichtung vor, die eine Signaturerzeugungslogik umfaßt, die eine Ausgabe von einem DUT empfängt und eine Signatur für eine solche empfangene Ausgabe er zeugt. Solche vorgeschlagenen Testeinrichtungen weisen jedoch mehrere Nachteile auf. Die vorgeschlagene Testeinrichtung ermöglicht beispielsweise nicht, daß das Testen und die Fehlerdiagnose/Fehlerbereinigung gleichzeitig erfolgen können. Ferner ermöglicht die vorgeschlagene Testeinrichtung kein Herausmaskieren von unbekannten Zuständen (z. B. Maskieren von nicht deterministischen Ausgabebits) beim Erzeugen einer Signatur. Wir sind uns keiner im Handel erhältlichen ATEs bewußt, die die durch den Artikel „Low-Cost Testing of High-Density Logic Components" vorgeschlagene Technik implementieren. Wenn ferner eine ATE gemäß einem solchen Vorschlag implementiert werden würde, würde sie keine Maskierung von unbekannten Zuständen ermöglichen, und wenn eine solche Maskierung implementiert werden wäre, dann würde sie eine beträchtliche Menge von Maskendaten erfordern, die an der ATE gespeichert werden, (da keine Komprimierung der Maskendaten vorgeschlagen wird).

Aufgrund der vorstehend beschriebenen Nachteile ist die Verwendung von Signaturanalysetechniken zum Reduzieren der ATE-Speicheranforderungen nicht weit verbreitet.

Es ist eine Aufgabe der vorliegenden Erfindung, ein System und ein Verfahren zum Testen eines Schaltungsaufbaus unter Verwendung einer extern erzeugten Signatur zu schaffen.

Diese Aufgabe wird durch eine Off-Chip-Testsystem gemäß Anspruch 1, ein System zum Testen eines Schaltungsaufbaus gemäß Anspruch 14 sowie ein Verfahren zum Testen eines Schaltungsaufbaus gemäß Anspruch 21 gelöst.

Angesichts des Vorstehenden besteht ein Bedarf an einem System und einem Verfahren zum Testen eines Schaltungsaufbaus, der vorzugsweise Datenspeicherungsanforderungen (z. B. ATE-Speicheranforderungen) zum Implementieren eines solchen Testsverfahrens bewahrt. Ferner besteht ein Bedarf an einem System und einem Verfahren, das ein Testen eines Schaltungsaufbaus ermöglicht, der vorzugsweise den Umfang des Auf-Chip-Schaltungsaufbaus, der zum Implementieren eines solchen Testverfahrens erforderlich ist, minimiert. Ferner besteht außerdem ein Bedarf an einem System und einem Verfahren, das ein Testen eines Schaltungsaufbaus in einer Weise ermöglicht, die eine Diagnose/Fehlerbereinigung von erfaßten Fehlern ermöglicht, um beispielsweise die spezifischen Ausgabebits von einem DUT zu bestimmen, die inkorrekt sind, ohne einen großen Vektorspeicher zu erfordern. Ferner besteht ist eine gleichzeitige Fehlerdiagnose/Fehlerbereinigung und ein Testen des Schaltungsaufbaus erwünscht. Das heißt, daß ein Bedarf an einer gleichzeitigen Fehlerauswertung (z. B. Diagnose und/oder Fehlerbereinigung) und einem Testen des Schaltungsaufbaus besteht. Der Begriff „Fehlerauswertung" wird hierin breit verwendet und soll eine Fehlerdiagnose und eine Fehlerbereinigung umfassen. Die Fehlerauswertung umfaßt ferner eine Ausbeutemitteilung. Das heißt, daß entweder die Fehlerdiagnose, die Fehlerbereinigung oder die Ausbeutemitteilung als eine Fehlerauswertung betrachtet werden können. Zusätzlich besteht ein Bedarf an einem solchen System und Verfahren, die ferner ein Maskieren von unbekannten Zuständen (z. B. nicht deterministischen Bits) beim Erzeugen einer Signatur ermöglichen. Es besteht ein Bedarf an einem System und einem Verfahren, das zumindest die Ausgabedaten und Maskendaten komprimiert, die zum Implementieren eines Testverfahrens zum Testen eines Schaltungsaufbaus verwendet werden.

Die vorliegende Erfindung bezieht sich auf ein System und ein Verfahren, die ein Testen eines Schaltungsaufbaus unter Verwendung einer extern erzeugten Signatur ermöglichen. Bei einem bevorzugten Ausführungsbeispiel wird eine externe Testeinrichtung geschaffen, die außerhalb eines DUT angeordnet ist. Eine solche externe Testeinrichtung ist betreibbar, um Testdaten in das DUT einzugeben, Ausgabedaten vom DUT zu empfangen und eine Signatur für zumindest einen Abschnitt von solchen empfangenen Ausgabedaten zu erzeugen. Wie hierin ferner beschrieben ist, sind verschiedene Vorteile darin zu erkennen, daß eine Signatur für Ausga bedaten außerhalb des DUT erzeugt wird. Die externe Testeinrichtung kann dann die erzeugte Signatur mit einer erwarteten Signatur vergleichen, um zu bestimmen, ob das DUT wie erwartet funktioniert. Wenn die erzeugte Signatur nicht mit einer erwarteten Signatur übereinstimmt, dann können die Fehlerdaten an ein Fehlerabbildungsprotokoll geschrieben werden. Wenn die erzeugte Signatur beispielsweise mit der erwarteten Signatur nicht übereinstimmt, dann kann zumindest ein Abschnitt der tatsächlich empfangenen Ausgabedaten (für die die erzeugte Signatur erzeugt wurde) an ein Fehlerabbildungsprotokoll geschrieben werden. Bei einem bevorzugten Ausführungsbeispiel ist eine weitere Interaktion mit dem DUT, abhängig von den Fehlerauswertungszielen, nach einem Erfassen eines Fehlers (z. B. nach einem Erfassen, das eine erzeugte Signatur nicht mit einer erwarteten Signatur übereinstimmt), nicht erforderlich, um eine solche Fehlerauswertung (z. B. Speichern der tatsächlichen empfangenen Ausgabedaten, die einem Fehler entsprechen, in ein Fehlerabbildungsprotokoll) auszuführen. Somit kann eine Fehlerauswertung (Diagnose und/oder Fehlerbereinigung) gleichzeitig mit dem Testen des DUT ausgeführt werden. Dementsprechend kann eine Fehlerauswertung bei einem bevorzugten Ausführungsbeispiel gleichzeitig mit dem Testen eines DUT in dem Umfang ausgeführt werden, der durch herkömmliche ATEs unterstützt wird. Somit sind separate Test- und Fehlerbereinigungsmodi nicht erforderlich. Das heißt, sobald ein Testen auf dem DUT ausgeführt wird, das eine weitere Interaktion mit dem DUT nicht erforderlich ist, um eine Fehlerauswertung auszuführen.

Ferner kann ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung in Kombination mit Maskenvektorkomprimierungs- und/oder Eingabevektorkomprimierungstechniken für einen Test für eine weitere Beibehaltung der Datenspeicherung, die zum Implementieren des Tests erforderlich ist, implementiert werden. Nicht nur kann eine Signaturanalyse beispielsweise zum Komprimieren der Ausgabevektordaten implementiert werden, sondern Eingabevektor- und/oder Masken vektorkomprimierungstechniken können ebenfalls in Kombination mit derselben zum Minimieren der Datenspeicherungsmenge, die an der ATE zum Implementieren eines gegebenen Tests erforderlich ist, implementiert werden.

Bei bestimmten Ausführungsbeispielen werden die empfangenen Ausgabedaten in eine Mehrzahl von Fenstern aufgeteilt, wobei jedes Fenster eine vorbestimmte Anzahl von Bits ist. Die externe Testeinrichtung erzeugt eine Signatur für jedes Fenster und vergleicht die erzeugte Signatur für jedes Fenster mit einer erwarteten Signatur für ein solches Fenster. Wenn ein Fehler erfaßt wird (d. h. eine erzeugte Signatur für ein Fenster nicht mit der erwarteten Signatur für ein solches Fenster übereinstimmt), dann können die Informationen, die sich auf zumindest das Defekte der Fenster beziehen, an ein Fehlerabbildungsprotokoll geschrieben werden. Die tatsächlich empfangenen Ausgabedaten für ein defektes Fenster können beispielsweise an ein Fehlerabbildungsprotokoll geschrieben werden.

Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung weist ein Off-Chip-Testsystem (Off-Chip = außerhalb des Chipelements) eine Einrichtung zum Eingeben von Testdaten in ein Testchipelement und eine Einrichtung zum Empfangen von Ausgabedaten von dem Testchipelement ansprechend auf die Eingabetestdaten auf. Das Off-Chip-Testsystem weist ferner eine Einrichtung zum Erzeugen einer Signatur für zumindest einen Abschnitt der empfangenen Ausgabedaten und eine Einrichtung zum Vergleichen der erzeugten Signatur mit einer erwarteten Signatur auf. Das Off-Chip-Testsystem weist ferner eine Einrichtung zum Speichern von Informationen an ein Fehlerabbildungsprotokoll auf, wenn die erzeugte Signatur nicht mit der erwarteten Signatur übereinstimmt.

Gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung weist ein System zum Testen eines Schaltungsaufbaus eine automatisierte Testausrüstung außerhalb des Schaltungsaufbaus auf, die zumindest vorübergehend mit ei nem solchen Schaltungsaufbau gekoppelt ist. Die automatisierte Testausrüstung weist eine kommunikative Schnittstelle zum Eingeben von Testdaten in den Schaltungsaufbau, eine kommunikative Schnittstelle zum Empfangen von Ausgabedaten von dem Schaltungsaufbau ansprechend auf die Eingabetestdaten und eine Logik auf, die zum Erzeugen einer Signatur für zumindest einen Abschnitt der empfangenen Ausgabedaten betreibbar ist. Die automatisierte Testausrüstung weist ferner eine Vergleichslogik zum Vergleichen einer erzeugten Signatur mit einer erwarteten Signatur und eine Logik zum Speichern von Informationen an ein Fehlerabbildungsprotokoll auf, wenn eine erzeugte Signatur mit einer erwarteten Signatur nicht übereinstimmt.

Gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung weist ein Verfahren zum Testen eines Schaltungsaufbaus ein Eingeben von Testdaten in den Testschaltungsaufbau und ein Empfangen, an einem externen Testbauelement, von Ausgabedaten von dem Testschaltungsaufbau ansprechend auf die Eingabetestdaten auf. Das Verfahren weist ferner ein Erzeugen, an dem externen Testbauelement, einer Signatur für zumindest einen Abschnitt der empfangenen Ausgabedaten und ein Vergleichen der erzeugten Signatur mit einer erwarteten Signatur auf, um zu bestimmen, ob der Testschaltungsaufbau wie erwartet funktioniert. Wenn die erzeugte Signatur mit der erwarteten Signatur nicht übereinstimmt, werden die Informationen an ein Fehlerabbildungsprotokoll gespeichert, wobei eine weitere Interaktion mit dem Testschaltungsaufbau nicht erforderlich ist, nachdem bestimmt worden ist, daß die erzeugte Signatur nicht mit der erwarteten Signatur übereinstimmt, um die Informationen zum Speichern solcher Informationen an das Fehlerabbildungsprotokoll zu erfassen.

Im vorstehenden wurden die Merkmale und technischen Vorteile der vorliegenden Erfindung eher breit umrissen, damit die ausführliche Beschreibung der Erfindung, die nun folgt, besser verständlich ist. Zusätzliche Merkmale und Vorteile der Erfindung werden nachstehend beschrieben, die einen Teil des Gegenstands der Ansprüche der Erfindung bilden. Fachleute werden darauf hingewiesen, daß die Konzeption und die spezifischen Ausführungsbeispiele, die offenbart sind, ohne weiteres als eine Grundlage zum Modifizieren oder Entwerfen anderer Aufbauten zum Ausführen der gleichen Zwecke der vorliegenden Erfindung verwendet werden können. Fachleute werden ebenfalls darauf hingewiesen, daß solche äquivalente Konstruktionen nicht vom Schutzbereich der Erfindung, der in den angehängten Ansprüchen angeführt ist, abweichen. Die neuartigen Merkmale, die für die Erfindung sowohl in Bezug auf ihre Organisation als auch ihr Betriebsverfahren angeblich charakteristisch sein sollen, werden zusammen mit weiteren Aufgaben und Vorteilen anhand der folgenden Beschreibung besser verständlich, wenn dieselben in Verbindung mit den beigefügten Zeichnungen berücksichtigt werden. Es wird jedoch ausdrücklich darauf hingewiesen, daß die Zeichnungen jeweils ausschließlich zu Darstellungs- und Beschreibungszwecken vorgesehen sind und nicht als eine Definition von Einschränkungen der vorliegenden Erfindungen auszulegen sind.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachstehend, Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:

1A ein Blockdiagramm eines herkömmlichen Testsystems,

1B einen beispielhaften Betriebsfluß des herkömmlichen Testsystems von 1A,

2 ein beispielhaftes Blockdiagramm eines bekannten Testsystems, das eine Signaturanalyse verwendet,

3A ein beispielhaftes Blockdiagramm eines Testsystems eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung,

3B einen beispielhaften Betriebsfluß eines Testsystems eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung,

4 ein beispielhaftes Flußdiagramm, das darstellt, wie erwartete Fenstersignaturen bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung erzeugt werden,

5 ein beispielhaftes Flußdiagramm, das einen Betriebsfluß eines Testverfahrens gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung darstellt,

6 ein beispielhaftes Betriebsflußdiagramm von einem Ausführungsbeispiel der vorliegenden Erfindung, bei dem ein Erfassen von Fehlerinformationen nach einem Erfassen einer vorbestimmten Zielanzahl von defekten Fenstern für ein Testobjekt beginnt,

7 ein beispielhaftes Computersystem, das zum Erzeugen von erwarteten Signaturen verwendet werden kann, um durch eine Testeinrichtung verwendet zu werden, und

8 ein Blockdiagramm einer exemplarischen Testeinrichtung, die angepaßt sein kann, um Ausführungsbeispiele der vorliegenden Erfindung zu implementieren.

Wie vorstehend beschrieben, empfängt das DUT (oder der CUT) bei einem typischen Halbleitertesten einen Satz von eingegebenen Stimuli von einer ATE, die außerhalb des DUT angeordnet ist, woraufhin die ATE die DUT-Ausgaben beobachtet. Allgemein werden die korrekten erwarteten Ausgaben des DUT in dem ATE-Speicher gespeichert, und das ATE vergleicht alle Ausgabebits, die von dem DUT empfangen wurden, mit den gespeicherten erwarteten Bitwerten, um zu bestimmen, ob das DUT ordnungsgemäß funktioniert (z. B. ob das DUT die erwarteten Ausgabewerte ansprechend auf die Eingabewerte erzeugt);
Im Falle eines Testens auf Waferebene kann eine Sonde mit einer oder mehreren Verbindungsanschlußflächen eines Chips in Kontakt gebracht werden, um Signale (z. B. ein Testmuster) an den Chip zu kommunizieren und um die Signale, die durch den Chip ansprechend auf die Eingabesignale ausgegeben werden, zu empfangen. Die Sonde ist typischerweise mit einer externen ATE kommunikativ gekoppelt, die betreibbar ist, um die Signale zu erzeugen, die in einen Chip eingegeben werden sollen, und um die Signale, die durch den Chip ausgegeben werden, auszuwerten, um zu bestimmen, ob der Chip ordnungsgemäß funktioniert.

Ein Beispiel dieses herkömmlichen Lösungsansatzes ist in 1A bis 1B dargestellt. 1A zeigt ein Blockdiagramm eines herkömmlichen Testsystems 100, das einer ATE 101 aufweist, die mit der Sonde 111 kommunikativ gekoppelt ist. Wie ferner nachstehend beschrieben ist, kann die Sonde 111 verwendet werden, um Eingabedaten an ein oder mehrere DUTs, wie z. B. ein DUT 113 auf dem Wafer 112, zu kommunizieren und um Ausgabedaten von solchen DUTs zu empfangen. Wie gezeigt ist, ist die Datenspeicherung 106 mit der ATE 101 kommunikativ gekoppelt und speichert Informationen, die zum Ausführen des Testens des DUT 113 erforderlich sind, wie z.B. Eingabevektordaten 109, Ausgabevektordaten (oder „erwartete Rohdaten") 107 und Maskenvektordaten 110 für den Test. Ferner können die Fehlerabbildungsdaten 108 innerhalb der Datenspeicherung 106, wie nachstehend weiter beschrieben ist, gespeichert werden. Die Datenspeicherung 106 ist typischerweise als interner Speicher der ATE 101 implementiert, kann jedoch bei bestimmten Implementierungen als ein externes Datenspeicherungsmedium implementiert sein, das mit der ATE 101 kommunikativ gekoppelt ist. Wie ferner gezeigt ist, weist die ATE 101 eine Logik 102 zum Erzeugen von Eingabetestdaten (z. B. Eingabetestmustern), die in das DUT 113 eingegeben werden sollen, eine Logik 103 zum Empfangen von Rohausgabedaten vom DUT 113 ansprechend auf die Eingabetestdaten, eine Logik 114 zum Maskieren von nicht deterministischen Bits der empfangenen Rohausgabedaten, eine Logik 104, die betreibbar ist, um die empfangenen, nicht maskierten Rohausgabedaten mit den erwarteten Rohdaten 107 zu vergleichen, und eine Logik 105 zum Erzeugen einer Fehlerabbildung 108 für die nicht bestandenen Tests, auf. Jede Logik 102, 103, 114, 104 und 105 der ATE 101 kann eine Software und/oder Hardware zum Ausführen ihrer jeweiligen Aufgaben aufweisen.

Während des Betriebs wird die Sonde 111 typischerweise mit entsprechenden Zugriffsanschlußflächen zum Testen von einem oder mehreren DUTs, wie z. B. dem DUT 113, in Kontakt gebracht. Die Sonde 111 wird beispielsweise mit den entsprechenden Anschlußflächen zum Eingeben von Testsignalen in das DUT 113 und zum Empfangen von Ausgabesignalen vom DUT 113 in Kontakt gebracht. Die Logik 102 der ATE 101 wird dann verwendet, um Eingabetestdaten an das DUT 113 zu kommunizieren. Solche Eingabetestdaten können beispielsweise ein Muster von Eingabesignalen aufweisen, die konzipiert sind, um das Ansprechvermögen des DUT 113 mit verschiedenen unterschiedlichen Eingabestimuli zu testen. Anschließend empfängt die Logik 103 der ATE 101 die Ausgabedaten, die durch DUT das 113 ansprechend auf die Testeingabedaten erzeugt wurden. Die Logik 114 wird verwendet, um die nicht deterministischen Bits der empfangenen Rohausgabedaten zu maskieren und eine Logik 104 wird verwendet, um die nichtmaskierten Rohausgabedaten, die vom DUT 113 empfangen werden, mit den erwarteten Rohdaten 107, die in der Datenspeicherung 106 gespeichert sind, zu vergleichen. Somit wird bestimmt, ob die Ausgabedaten, die durch das DUT 113 ansprechend auf die Eingabedaten erzeugt werden, wie erwartet ausfallen. Wenn bestimmt wird, daß die Ausgabedaten, die vom DUT 113 empfangen werden, ansprechend auf die Eingabedaten nicht wie erwartet ausfallen (d. h. die empfangenen nichtmaskierten Ausgabedaten stimmen nicht mit den erwarteten Ausgabedaten 107 überein), dann kann die Logik 105 Informationen in der Fehlerabbildung 108 über diesen nicht bestandenen Test erzeugen. Solche Fehlerabbildungsinformationen können beispielsweise ein Fehlerprotokoll der erwarteten Ausgabesignale und tatsächlichen empfangenen Ausgabesignale aufweisen. Dieser Prozeß kann für eine beliebige Anzahl von Eingabetestmustern wiederholt werden, die zum Testen des DUT 113 erzeugt werden.

1B zeigt einen beispielhaften Betriebsfluß des herkömmlichen Testsystems 100 von 1A. Wie bei Betriebsblock 121 gezeigt ist, wird bestimmt, ob ein nächstes Ausgabebit vom DUT 113 ansprechend auf spezielle Eingabetestdaten verfügbar ist. Das heißt, daß die Eingabeteststimuli (z. B. ein Testmuster) in das DUT 113 eingegeben werden und bestimmt wird, ob alle Ausgabebits vom DUT 113 ansprechend auf solche Eingabeteststimuli bei der ATE 101 empfangen werden. Wenn keine weiteren Ausgabebits vom DUT 113 erwartet werden, dann wird bei Block 122 bestimmt, daß das Testen beendet ist. Wenn jedoch bestimmt wird, daß ein Ausgabebit vom DUT 113 ansprechend auf eingegebenes Eingabetestmuster empfangen worden ist, dann rückt der Betrieb in der ATE 101 zu Betriebsblock 123 vor, wo ein „bedeutungsloses" Bit (oder ein „nichtdeterministisches" Bit) maskiert werden kann. Bestimmte Ausgabebits können beispielweise ein nichtdeterministisches Verhalten aufweisen (z. B. können sie nicht anzeigen, ob das DUT 113 ansprechend auf das Eingabemuster ordnungsgemäß funktioniert), und solche Bits, deren Wert für den Test bedeutungslos ist, können anhand der empfangenen Ausgabedaten maskiert (oder gefiltert) werden. Somit kann das empfangene Bit bei Betriebsblock 123 maskiert werden.

Wenn das empfangene Ausgabebit anschließend bei Block 123 nicht maskiert wird, dann vergleicht die ATE 101 bei Betriebsblock 124 das empfangene Ausgabebit mit dem erwarteten Ausgabebit 107, um zu bestimmen, ob ein solches Ausga bebit mit dem erwarteten Bit 107 übereinstimmt. Wenn das empfangene Ausgabebit mit dem erwarteten Ausgabebit 107 übereinstimmt, dann wird bestimmt, daß das DUT 113 diesen Test bei Block 125 besteht, und die Operation kann zu Block 121 zurückkehren, um ein weiteres Testen (z. B. Empfangen von weiteren Ausgabebits vom DUT 113) auszuführen. Wenn jedoch das empfangene Ausgabebit nicht mit dem erwarteten Ausgabebit 107 übereinstimmt, dann wird bestimmt, daß das DUT 113 diesen Test nicht besteht, und Informationen über ein solches Nichtbestehen (z. B. die Adresse und/oder die empfangenen Ausgabedaten vom DUT 113) können an die Fehlerabbildung 108 gespeichert werden, die später bei der Fehlerbereinigung des DUT 113 verwendet werden kann, um den Grund zu bestimmen, warum es diesen Test nicht bestand.

Angesichts des vorstehenden speichern die herkömmlichen Testverfahren allgemein alle erwarteten Ausgabebits für verschiedene unterschiedliche Eingabetestmuster als die Ausgabevektordaten 107 in der Datenspeicherung 106 für die ATE 101. Das Speichern aller solcher erwarteten Ausgabebits führt zu extrem hohen ATE-Speicheranforderungen. Ferner wird mit Weiterentwicklung der Technik erwartet, daß das erforderliche Ausgabevektordatenvolumen mit dem Skalieren einer Halbleitertechnologie steil ansteigt. Daher erwartet man für die Zukunft, daß sich das Problem verschlimmert.

Infolgedessen sind bestimmte Lösungen im Stand der Technik vorgeschlagen worden, um zu versuchen, die ATE-Speicheranforderung zum Speichern solcher Ausgabevektordaten zu reduzieren. Wie vorstehend erwähnt, wird bei einer vorgeschlagenen Lösung ein Abschnitt der Ausgabevektordaten einfach abgeschnitten, weil die ATE nicht in der Lage ist, die hohen Speicheranforderungen zu erfüllen. Wie vorstehend beschrieben, führt ein solches Abschneiden zu einer Verringerung der Testabdeckung, die zu einer geringeren Produktqualität führen kann.

Eine weitere Lösung umfaßt ein Verwenden einer Signaturanalyse, um die Ausgabevektordaten zu komprimieren. Wie vorstehend beschrieben, ist die Signaturanalyse ein hinreichend bekanntes Verfahren zum Komprimieren einer Sequenz von logischen Werten, die von einer Testschaltung ausgegeben werden, in eine relativ geringe Anzahl von Datenbits (Signatur). Im Stand der Technik sind verschiedene Verfahren zum Erzeugen einer Signatur für Ausgabedaten hinreichend bekannt. Typischerweise ist ein hinreichend bekannter SISR- oder MISR-Schaltungsaufbau auf einem Chip implementiert, um eine Signatur für die Ausgabewerte des Chipelements ansprechend auf ein Eingabetestmuster zu erzeugen. Bei bestimmten Implementierungen kann ein hinreichend bekannter Zellular-Automata-Schaltungsaufbau auf dem Chip implementiert sein, um eine Signatur für die Ausgabewerte des Chipelements ansprechend auf ein Eingabetestmuster zu erzeugen. Weil verschiedene Implementierungen des Zellular-Automata-Schaltungsaufbaus zum Erzeugen einer Signatur in der Technik hinreichend bekannt sind, wird ein solcher Zellular-Automata hierin nicht weiter beschrieben.

Unter Bezugnahme auf 2 ist ein beispielhaftes Blockdiagramm eines bekannten Testsystems 200 gezeigt, das eine Signaturanalyse verwendet. Das Testsystem 200 weist eine ATE 201 auf, die mit einer Sonde 211 kommunikativ gekoppelt ist. Wie nachstehend weiter beschrieben ist, kann die Sonde 211 verwendet werden, um Eingabedaten an ein oder mehrere DUTs zu kommunizieren, wie z. B. ein DUT 213 auf einem Wafer 212, und um Ausgabedaten von solchen DUTs zu empfangen. Bei dieser Testlösung ist ein Signaturerzeugungsschaltungsaufbau 214 (z. B. SISR, MISR oder Zellular-Automata) im DUT 213 umfaßt, der betreibbar ist, um eine Signatur von Ausgabewerten zu erzeugen, die durch das DUT 213 ansprechend auf die Eingabetestwerte erzeugt werden. Wie gezeigt, ist die Datenspeicherung 206 mit der ATE 210 kommunikativ gekoppelt und speichert Informationen, die zum Ausführen des Testens des DUT 213 notwendig sind, z. B. Eingabevektordaten 208 und erwartete Signaturen 207. Wie ferner gezeigt ist, weist die ATE 201 eine Logik 202 zum Erzeugen von Eingabetestdaten, die in das DUT 213 eingegeben werden sollen, eine Logik 203 zum Empfangen einer Signatur (die durch den Schaltungsaufbau 214 erzeugt wird) vom DUT 213 ansprechend auf die Eingabetestdaten und eine Logik 214, die betreibbar ist, um die empfangende Signatur mit der erwarteten Signatur 207 zu vergleichen, auf.

Während des Betriebs wird die Sonde 211 typischerweise mit den entsprechenden Zugriffsanschlußflächen zum Testen von einem oder mehreren DUTs, z. B. dem DUT 213, in Kontakt gebracht. Die Sonde 211 wird beispielsweise mit den entsprechenden Anschlußflächen zum Eingeben von Testsignalen in das DUT 213 und zum Empfangen von Ausgabesignalen vom DUT 213 in Kontakt gebracht. Die Logik 202 der ATE 201 wird dann verwendet, um Eingabetestdaten an das DUT 213 zu kommunizieren. Solche Eingabetestdaten können beispielsweise ein Muster von Eingabesignalen aufweisen, die konzipiert sind, um das Ansprechvermögen des DUT 213 auf verschiedene unterschiedliche Eingabeanstimuli zu testen. Anschließend erzeugt die Signaturerzeugungslogik 214 des DUT 213 eine Signatur für die Ausgabewerte des DUT 213 ansprechend auf die Eingabetestsignale. Die Logik 203 der ATE 201 empfängt die erzeugte Signatur vom DUT 213, und die Logik 204 wird verwendet, um die empfangene Signatur mit der erwarteten Signatur 207, die in der Datenspeicherung 206 gespeichert ist, zu vergleichen. Somit wird bestimmt, ob die erzeugte Signatur, die vom DUT 213 ansprechend auf die Eingabetestdaten empfangen wurde, wie erwartet ausfällt. Dieser Prozeß kann für eine beliebige Anzahl von Eingabetestmustern, die zum Testen des DUT 213 erzeugt werden, wiederholt werden.

Es wird darauf hingewiesen, daß, weil eine Signatur eine komprimierte Identifizierung der Ausgabebits ist, die Speicherplatzmenge, die auf einer ATE 201 zum Speichern der Ausgabevektordaten (erwarteten Signaturen 207) erforderlich ist, weit unter die Menge reduziert werden kann, die für ein Speichern aller tatsächlich erwarteten Ausgabebits er forderlich ist (wie bei dem herkömmlichen System 100 von 1A). Somit können die erwarteten Signaturen 207 weniger Speicherplatz innerhalb der Datenspeicherung 206 zum Implementieren eines gegebenen Testverfahrens verbrauchen als durch herkömmliche Testlösungen verbraucht werden würde, bei denen alle erwarteten Bits gespeichert werden (z.B. erwartete Rohdaten 107 in dem Beispiel von 1A), Ferner wird eine Testabdeckung wie im Fall des Abschneidens nicht verringert, weil eine Signatur einen ganzen Satz von Ausgabebits, die analysiert werden sollen (z. B. den gesamten Ausgabevektor) eindeutig identifizieren kann.

Wie vorstehend beschrieben, weisen Signaturanalyseverfahren des Stands der Technik jedoch mehrere Nachteile auf. Solche Verfahren umfassen beispielsweise einen Schaltungsaufbau auf einem Chip (z. B. Schaltungsaufbau 214) zum Erzeugen einer Signatur der Ausgabedaten des Chipelements während des Testens. Ein solcher Signaturerzeugungsschaltungsaufbau verbraucht eine Fläche auf dem Chip, wodurch die Gesamtgröße des Chipelements erhöht wird (oder die Menge des Schaltungsaufbaus, der ansonsten im Chipelement umfaßt sein kann, verringert wird) und das Verhalten des Chipelements potentiell behindert wird. Ferner ermöglicht eine solches Auf-Chip-Signaturerzeugungsverfahren typischerweise keine Diagnose von Fehlern (z. B. Bestimmen der spezifischen Ausgabebits, die nicht korrekt sind) an der ATE. Somit wird darauf hingewiesen, daß eine Fehlerabbildung bei diesem Beispiel nicht konstruiert ist, wie sie im Beispiel von 1A konstruiert war. Verschiedene weitere Nachteile, die dem Signaturanalyseverfahren des Stands der Technik zugeordnet sind, werden nachstehend beschrieben, und aufgrund dieser Nachteile ist die Verwendung von Signaturanalyseverfahren zum Verringern der ATE-Speicheranforderungen nicht weit verbreitet. Da die Komplexität der DUTs und/oder der Umfang der Testabdeckung angestiegen ist, ist der Wunsch an einer Beibehaltung der Datenspeichermenge, die auf einer ATE zum Implementieren eines Tests erforderlich ist, größer geworden. Dementsprechend ist ein Bedarf an einem verbes serten Testverfahren entstanden, das die Datenspeichermenge, die zum Implementieren eines solchen Testsverfahrens erforderlich ist (z. B. durch Verwendung einer Signaturanalyse), beibehält, jedoch nicht die vorstehend erwähnten Nachteile aufweist.

Wie vorstehend beschrieben, sind für eine Testeinrichtung, die eine Signatur außerhalb des Chips erzeugt, ebenfalls Vorschläge eingereicht worden. Zum Beispiel wird in „Low-Cost Testing of High-Density Logic Components", IEEE Design & Test of Computers, 0740-7475 (April 1990) eine Testeinrichtung vorgeschlagen, die eine Signaturerzeugungslogik umfaßt, die eine Ausgabe von einem DUT empfängt und eine Signatur für eine solche empfangene Ausgabe erzeugt. Eine solche vorgeschlagene Testeinrichtung weist jedoch mehrere Nachteile auf. Die vorgeschlagene Testeinrichtung ermöglicht beispielsweise kein gleichzeitiges Testen und eine Fehlerdiagnose. Ferner ermöglicht die vorgeschlagene Testeinrichtung kein Herausmaskieren von unbekannten Zuständen (z. B. Maskieren von nichtdeterministischen Ausgabebits) beim Erzeugen einer Signatur. Außerdem sind wir uns keiner im Handel erhältlichen ATEs bewußt, die das durch den Artikel „Low-Cost Testing of High-Density Logic Components" vorgeschlagene Verfahren implementieren. Wenn ferner eine ATE gemäß einem solchen Vorschlag implementiert wäre, würde sie kein Maskieren von unbekannten Zuständen ermöglichen, und wenn ein solches Maskieren implementiert wäre, würde dies eine erhebliche Maskendatenmenge erfordern, die an der ATE gespeichert ist (da keine Komprimierung der Maskendaten vorgeschlagen wird).

Ausführungsbeispiele der vorliegenden Erfindung schaffen eine Testlösung, die die Datenspeichermenge, die an der Testeinrichtung (z. B. der ATE) erforderlich ist, beibehält und auch vorzugsweise den Umfang des Auf-Chip-Schaltungsaufbaus, der für eine solche Testlösung erforderlich ist, minimiert. Spezieller verwenden die Ausführungsbeispiele der vorliegenden Erfindung eine Signaturanalyse, um eine Komprimierung der erwarteten Ausgabedaten zu erreichen. Ferner verwenden Ausführungsbeispiele der vorliegenden Erfindung eine Logik (z. B. Software und/oder Hardware) die außerhalb des DUT angeordnet sind (z. B. außerhalb eines Bauelements auf einem Wafer oder einem gehäusten Bauelement, das getestet wird), um eine Signatur der Ausgabe von einem solchen Bauelement zu erzeugen. Bei einem bevorzugten Ausführungsbeispiel ist die Logik in einer ATE umfaßt, um Rohausgabedaten von einem DUT zu empfangen und um eine Signatur für zumindest einen Abschnitt der empfangenen Rohausgabedaten zu erzeugen (z. B. kann ein Abschnitt der empfangenen Rohausgabedaten bei bestimmten Implementierungen so maskiert sein, daß er beim Erzeugen der Signatur nicht verwendet wird). Am meisten bevorzugt wird, die empfangenen Rohausgabedaten in eine Mehrzahl von „Fenstern" zu unterteilen, wobei jedes Fenster eine bevorzugte Anzahl von Bits ist, und eine Signatur in der ATE für jedes Fenster zu erzeugen und mit einer erwarteten Signatur für ein solches Fenster zu vergleichen, um zu bestimmen, ob das Bauelement wie erwartet funktioniert.

Bei einem bevorzugten Ausführungsbeispiel kann die Datenspeicherung, die an der ATE erforderlich ist, dahingehend beibehalten werden, daß die erwarteten Signaturen für die Testlösung, im Gegensatz zum Speichern aller erwarteten tatsächlichen Ausgabebits für eine solche Testlösung, in derselben gespeichert werden können. Ferner ist bei einem bevorzugten Ausführungsbeispiel ein Schaltungsaufbau zum Erzeugen einer Signatur der Ausgabe des DUT nicht auf dem DUT umfaßt, wodurch die Fläche, die auf dem DUT zum Implementieren der Testlösung erforderlich ist, minimiert wird. Ein weiterer Vorteil eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung ist, daß es eine gleichzeitige (oder Einzeldurchgangs-) Fehlerauswertung (z. B. Diagnose-Fehlerbereinigung) ermöglicht. Wenn somit ein Fehler während des Testens erfaßt wird, ist ein zweiter Durchgang zum Eingeben von Daten in das DUT und zum Empfangen von Ausgabedaten von demselben zur Fehlerauswertung nicht erforder lich (z. B. Diagnostizieren des Fehlers zum Bestimmen der spezifischen Ausgabebits, die einen inkorrekten Wert aufweisen). Ferner ermöglicht ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung ein Maskieren von empfangenen Ausgabedaten zum Erzeugen einer Signatur. Somit können die nichtdeterministischen Bits der empfangenen Ausgabedaten gemäß den Maskendaten, die auf der ATE gespeichert sind, die die Ausgabebits identifiziert, die für den Test maskiert oder gefiltert werden sollen, maskiert werden. Gemäß bestimmter Ausführungsbeispiele der vorliegenden Erfindung können Komprimierungsverfahren für die Maskendaten verwendet werden, um die Datenspeicherungsanforderungen an der ATE weiter zu verringern. Verschiedene weitere Vorteile der Ausführungsbeispiele der vorliegenden Erfindung werden nachstehend beschrieben.

Verschiedene Ausführungsbeispiele der vorliegenden Erfindung werden nun unter Bezugnahme auf 3A – 3B und 4 – 8 beschrieben, in denen identische Bezugszeichen identische Teile in verschiedenen Ansichten darstellen. Unter Bezugnahme auf 3A – 3B wird eine beispielhafte Implementierung eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung in Verbindung mit derselben beschrieben. 3A zeigt ein beispielhaftes Blockdiagramm eines Testsystems 300, das eine Signaturanalyse verwendet, um die Ausgabevektordaten zu komprimieren, um die Menge der Datenspeicherung, die zum Implementieren des Testverfahrens erforderlich ist, beizubehalten. Obgleich viele Beispiele, die hierin (einschließlich des Beispiels von 3A) vorgesehen sind, das Testen eines Bauelements, das sich auf einem Wafer befindet, beschreiben, wird darauf hingewiesen, daß die vorliegende Erfindung in ihrer Anwendung diesbezüglich nicht eingeschränkt ist. Vielmehr können andere DUTs unter Verwendung von Ausführungsbeispielen der vorliegenden Erfindung einschließlich eines DUT, das beispielsweise gehäust worden ist, getestet werden.

Das Testsystem 300 weist eine ATE 301 auf, die mit einer Sonde 313 kommunikativ gekoppelt ist. Wie nachstehend weiter beschrieben ist, kann die Sonde 313 verwendet werden, um Eingabedaten an ein oder mehrere DUTs, wie z. B. das DUT 315 auf dem Wafer 314, zu kommunizieren und Ausgabedaten von solchen DUTs zu empfangen. Wie gezeigt ist, ist die Datenspeicherung 308 mit der ATE 311 kommunikativ gekoppelt und speichert Informationen, die zum Ausführen des Testens des DUT 315 notwendig sind, wie z. B. Eingabevektordaten 309, Ausgabesignaturdaten 311 und Maskenvektordaten 310 für den Test. Ferner können Fehlerabbildungsdaten 312 in einer Datenspeicherung 308 gespeichert werden, wie nachstehend weiter beschrieben wird.

Wie weiter gezeigt ist, weist die ATE 301 eine Logik 302 zum Erzeugen von Eingabetestdaten, die in das DUT 315 eingegeben werden sollen, eine Logik 303 zum Empfangen von Rohausgabedaten vom DUT 315 ansprechend auf die Eingabetest daten, eine Logik 304 zum De komprimieren von Maskendaten 310 und Maskieren der entsprechenden Bits der empfangenen Ausgabedaten, eine Logik 305 zum Erzeugen einer Signatur von zumindest einem Abschnitt der empfangenen Ausgabedaten (z. B. der nicht maskierten Ausgabedaten), die vom DUT 315 empfangen werden, eine Logik 306, die betreibbar ist, um die erzeugte Signatur mit der erwarteten Signatur 311 zu vergleichen, und eine Logik 307 zum Erzeugen einer Fehlerabbildung 312 für nicht bestandene Tests auf. Wie nachstehend ausführlicher beschrieben ist, erzeugt die Logik 305 vorzugsweise eine Signatur für jedes von einer Mehrzahl von Fenstern der empfangenen Ausgabebits, und jede Fenstersignatur wird mit einer erwarteten Fenstersignatur in der Logik 306 verglichen. Jede Logik 302, 303, 304, 305, 306 und 307 der ATE 306 kann eine Software und/oder Hardware zum Ausführen ihrer jeweiligen Aufgaben aufweisen.

Während des Betriebs eines bevorzugten Ausführungsbeispiels kann die Sonde 313 mit den entsprechenden Zugriffsanschlußflächen zum Testen von ein oder mehreren DUTs, wie z. B. dem DUT 315, in Kontakt gebracht werden. Die Sonde 313 kann beispielsweise mit den entsprechenden Kontaktanschlußflächen zum Eingeben von Testsignalen in das DUT 315 in Kontakt gebracht werden und Ausgabesignale vom DUT 315 empfangen. Die Logik 302 der ATE 301 wird dann verwendet, um Eingabetestdaten an das DUT 315 zu kommunizieren. Solche Eingabetestdaten können beispielsweise ein. Muster von Eingabesignalen aufweisen, die entworfen sind, um das Ansprechvermögen des DUT 315 auf verschiedene unterschiedliche Eingabestimuli zu testen. Anschließend empfängt die Logik 303 der ATE 301 die Rohausgabedaten, die durch das DUT 315 ansprechend auf die Eingabetestdaten erzeugt werden. Somit ist die ATE 301 mit dem DUT 315 (z. B. über die Sonde 313) kommunikativ schnittstellenmäßig verbunden, um die Testdaten in das DUT 315 einzugeben und Rohausgabedaten vom DUT 315 zu empfangen.

Die Logik 304 der ATE 301 kann umfaßt sein, um bestimmte empfangene Ausgabebits (z. B. nichtdeterministische Bits) zu maskieren, damit diese beim Erzeugen einer Signatur nicht verwendet werden. Wie nachstehend beschrieben, sind die Maskendaten 310 vorzugsweise komprimiert, und die Logik 304 ist daher betreibbar, um die Maskendaten 310 zu dekomprimieren und solche Maskendaten 310 beim Maskieren der entsprechenden empfangenen Ausgabebits zu verwenden. Die Logik 305 der ATE 301 erzeugt eine Signatur für zumindest einen Abschnitt der empfangenen Ausgabewerte (z. B. die nichtmaskierten Ausgabebits) vom DUT 315. Wie vorstehend erwähnt, können die empfangenen Ausgabedaten bei bestimmten Ausführungsbeispielen in Fenstern organisiert sein, und die Logik 305 kann eine Signatur für jedes Fenster von Bits erzeugen. Die Logik 306 wird dann verwendet, um die erzeugte Signatur mit der erwarteten Signatur 311, die in der Datenspeicherung 308 gespeichert ist, zu vergleichen. Vorzugsweise wird wiederum eine Signatur eines Fensters der empfangenen Ausgabebits mit einer erwarteten Signatur für ein solches Fenster von Bits verglichen. Somit wird bestimmt, ob die erzeugte Signatur für die Ausgabedaten, die vom DUT 315 ansprechend auf die Eingabetestdaten empfangen werden, wie erwartet ausfällt. Wenn bestimmt wird, daß die erzeugte Signatur (z. B. Fenstersignatur) ansprechend auf die Eingabedaten nicht wie erwartet ausfällt (d. h. die erzeugte Signatur für ein Fenster von Bits stimmt nicht mit der erwarteten Signatur 311 überein), dann kann die Logik 307 Informationen in der Fehlerabbildung 312 über diesen nicht bestandenen Test erzeugen. Solche Fehlerabbildungsinformationen können solche Informationen als eine Identifizierung der Fensteranzahl, die nicht bestand, und ein Fehlerprotokoll der erwarteten Daten und tatsächlich empfangenen Daten (z. B. tatsächlich empfangene Rohausgabebits) für das defekte Fenster aufweisen. Es wird darauf hingewiesen, daß diese Fehlerauswertung gleichzeitig mit dem Testen des DUT 315 ausgeführt werden kann. Das heißt, sobald ein Fehler erfaßt wird (z. B. durch die Logik 306, die erfaßt, daß eine erzeugte Signatur nicht mit einer erwarteten Signatur übereinstimmt), muß die ATE 201 nicht erneut auf das DUT 315 zum Auswerten (z. B. Diagnostizieren und/oder Fehlerbereinigen) des erfaßten Fehlers zugreifen, sondern vielmehr können die Rohausgabedaten, die durch die ATE 201 während des Testens empfangen werden (was zur Erzeugung einer fehlerbehafteten Signatur führte), zur Auswertung verwendet werden (z. B. in ein Fehlerabbildungsprotokoll gespeichert werden). Dieser Prozeß kann für eine beliebige Anzahl von Eingabetestmustern, die zum Testen des DUT 315 erzeugt werden, wiederholt werden.

3B zeigt einen beispielhaften Betriebsfluß des Testystems 300 von 3A. Es wird darauf hingewiesen, daß, obgleich 3B ein Beispiel des allgemeinen Betriebs des Systems 300 zeigt, ein solcher Betriebsfluß allgemein bitweise implementiert sein kann. Bei Betriebsblock 322 wird beispielsweise ein Bit von Ausgabedaten empfangen, und der Betrieb rückt für ein solches Bit bitweise ähnlich jenem vor, wie zuvor in Verbindung mit 1B beschrieben. Obwohl das Beispiel von 3B nicht speziell als bitweise Operation gezeigt ist, sieht es ein Beispiel des allgemeinen Betriebs von System 300 vor.

Wie gezeigt ist, werden bei Betriebsblock 321 die Testdaten von einem Off-Chip-Testeinrichtung (z. B. von der ATE 301) in das DUT 315 eingegeben. Bei Betriebsblock 322 empfängt die Off-Chip-Testeinrichtung Ausgabedaten vom DUT 315, die ansprechend auf die Eingabetestdaten ausgegeben werden. Bei Betriebsblock 323 kann ein bestimmter Abschnitt der empfangenen Ausgabedaten (z. B. bestimmte Bits) durch die Off-Chip-Testeinrichtung maskiert werden (durch Maskieren der Logik 304), wie nachstehend hierin weiter beschrieben wird. Bestimmte Bits der empfangenen Ausgabedaten können beispielsweise nichtdeterministisch sein (z. B. können sie nicht anzeigen, ob das DUT 315 ansprechend auf das Eingabemuster ordnungsgemäß funktioniert), solche Bits können (z.B. aufgrund des Vorliegens von mehreren Taktbereichen, Teilabtastlösungsansätzen oder Tristate-Bussen) maskiert werden, um eine Verfälschung der Signatur zu verhindern. Für einen bestimmten Abschnitt des Tests ignoriert zusätzlich der Benutzer typischerweise die Ausgaben (z. B. weil der Test Defekte abdeckt, die selten oder während der Diagnose/Fehlerbereinigung vorkommen). Diese Bits können ebenfalls von den empfangenen Ausgabedaten bei Betriebsblock 323 maskiert (oder gefiltert) werden. Wie nachstehend weiter beschrieben, werden die Maskendaten 310 vorzugsweise komprimiert, und somit kann der Betriebsblock 323 ein Dekomprimieren solcher Maskendaten 310 und Verwenden der Maskendaten zum Herausmaskieren der entsprechenden empfangenen Ausgabebits aufweisen.

Bei Betriebsblock 324 werden diese Ausgabebits, die in Block 323 nicht maskiert worden sind, durch die Off-Chip-Testeinrichtung zum Erzeugen einer Signatur verwendet. Vorzugsweise werden die Ausgabebits in Fenster unterteilt, so daß die nicht maskierten Bits eines Fensters bei Betriebsblock 324 in eine Signatur eines solchen Fensters komprimiert werden. Anschließend vergleicht die Off-Chip- Testeinrichtung bei Betriebsblock 325 die erzeugte Signatur mit einer gespeicherten erwarteten Signatur (z. B. der erwarteten Signatur 311, die in der Datenspeicherung 308 gespeichert ist), um zu bestimmen, ob die erzeugte Signatur mit der erwarteten Signatur übereinstimmt. Wenn bestimmt wird, daß die erzeugte Signatur mit der erwarteten Signatur übereinstimmt, dann wird bei Betriebsblock 326 bestimmt, daß die Ausgabe des DUT 315 diesen Test besteht, und der Betrieb kann zu Block 321 zurückkehren, um ein weiteres Testen auszuführen (z. B. Eingeben weiterer Testmuster in das DUT 312). Wenn jedoch die erzeugte Signatur nicht mit der erwarteten Signatur übereinstimmt, dann wird bestimmt, daß das DUT 315 diesen Test nicht besteht, und die Informationen über ein derartiges Nichtbestehen können an die Fehlerabbildung 312 gespeichert werden, die bei der Fehlerauswertung verwendet werden kann (z.B. Fehlerbereinigung des DUT 315, um den Grund, warum es diesen Test nicht bestand, zu bestimmen). Wenn spezieller eine Fenstersignatur nicht mit einer erwarteten Fenstersignatur übereinstimmt, dann können die tatsächlich empfangenen Rohausgabedaten von einem solchen Fenster in die Fehlerabbildung 312 zur Fehlerauswertung gespeichert werden (z. B. Diagnostizieren eines solchen Fehlers zum Bestimmen, welche spezifischen Bits inkorrekte Werte aufwiesen). Somit werden Daten für die defekten Fenster Fenster-1 bis Fenster-M (wobei M kleiner als oder gleich N ist) in die Fehlerabbildungsdaten 312 gespeichert. Dementsprechend werden für N Fenster der erwarteten Signatur 311 die Daten für die defekten M Fenster, die typischerweise kleiner als die Anzahl N sind (und somit Speicheranforderungen der Fehlerabbildungsdaten 312 beibehalten), in die Fehlerabbildungsdaten 312 gespeichert. Es wird darauf hingewiesen, daß, weil die tatsächlichen Rohausgabedaten durch die Off-Chip-Testeinrichtung empfangen werden, eine solche Fehlerauswertung gleichzeitig mit dem Testen des DUT ausgeführt werden kann. Das heißt, daß ein weiterer Durchgang durch das DUT (z. B. Eingeben von Informationen und/oder Empfangen einer Ausgabe) nicht erforderlich ist, nachdem ein Fehler erfaßt wurde, sondern stattdessen, wenn die erzeugte Signatur für ein Fenster von Ausgabebits mit einer erwarteten Signatur für dieses Fenster nicht übereinstimmt, die tatsächlichen Ausgabebits des defekten Fensters in einer Fehlerabbildung zur Auswertung des Fehlers gespeichert werden können, ohne eine weitere Interaktion mit dem DUT (z. B. für den Zweck einer Ausbeutemitteilung) zu erfordern.

Es wird darauf hingewiesen, daß, weil eine Signatur eine komprimierte Identifizierung einer Gruppe (z. B. eines Fensters) von Ausgabebits ist, die Menge des Speicherplatzes, der bei der Datenspeicherung 308 zum Speichern der Ausgabevektordaten (erwarteten Signaturen 311) erforderlich ist, weit unter die Menge reduziert werden kann, die zum Speichern aller tatsächlichen erwarteten Ausgabebits erforderlich ist (wie in dem herkömmlichen System 100 von 1A). Somit können die erwarteten Signaturen 311 weniger Speicherplatz innerhalb der Datenspeicherung 308 zum Implementieren eines gegebenen Testverfahrens erfordern als ansonsten durch herkömmliche Testlösungen, bei denen alle erwarteten Bits gespeichert werden (z. B. die erwarteten Rohdaten 107 in dem Beispiel von 1A), verbraucht werden würde. Weil ferner eine Signatur einen ganzen Satz von Ausgabebits, die analysiert werden sollen, (z. B. den gesamten Ausgabevektor) identifizieren kann, wird die Testabdeckung nicht verringert, wie dies beim Abschneiden der Fall ist. Somit kann die Menge der Datenspeicherung, die zum Speichern der Ausgabevektordaten für einen Test erforderlich ist, minimiert werden, ohne bezüglich der Qualität des Testens Abstriche machen zu müssen. Zusätzlich können durch Implementieren der Signaturerzeugungslogik außerhalb des Testbauelements (z. B. außerhalb eines Chips auf einem Wafer oder eines gehäusten Bauelements, das getestet wird) viele der vorstehend beschriebenen Nachteile der bekannten Signaturanalysetechniken (die auf einem Chip implementiert sind) überwunden werden. Eine zusätzliche Fläche ist beispielsweise innerhalb des Testchips nicht erforderlich, um einen Signaturerzeugungsschaltungsaufbau zu implementieren.

Ferner kann die Diagnose von Fehlern, wie vorstehend beschrieben, gleichzeitig mit dem Testen ausgeführt werden. Auch ermöglicht ein bevorzugtes Ausführungsbeispiel ein Maskieren von bestimmten empfangenen Ausgabebits (z. B. nichtdeterministischen Bits) von der Signaturerzeugung über eine Maskierungslogik 304. Die Maskierungslogik 304 kann Ausgabebits gemäß den Maskendaten 310 für einen gegebenen Test ausgeben. Wie nachstehend ausführlicher beschrieben, können bei bestimmten Ausführungsbeispielen die Maskierungsdaten 310 ebenfalls komprimiert werden, wodurch die Datenspeicherungsanforderungen der ATE 301 weiter reduziert werden.

Wie vorstehend beschrieben, ist die Signaturerzeugungslogik vorzugsweise in der ATE 301 umfaßt, wie in dem Beispiel von 3A gezeigt ist, oder in einem anderen Typ von Testeinrichtung, die nun bekannt oder später entwickelt wird, die außerhalb des Wafers 314 angeordnet ist, auf dem das DUT 315 positioniert ist. Bei alternativen Ausführungsbeispielen kann eine solche Signaturerzeugungslogik beispielsweise in einer beliebigen anderen Off-Chip-Testeinrichtung (d. h. einer Testeinrichtung, die außerhalb des DUT 315 angeordnet ist) implementiert sein, die zum Testen des DUT 315 verwendet werden kann. Bei bestimmten Ausführungsbeispielen kann beispielsweise eine Testeinrichtung, die außerhalb des DUT 315 ist, auf dem Wafer 314 zum Ausführen eines Teils oder der gesamten vorstehend beschriebenen Funktionalität der ATE 301 umfaßt sein (z. B. Eingeben von Testdaten in das DUT 315, Empfangen von Ausgabedaten vom DUT 315, Erzeugen einer Signatur für die Ausgabedaten, Vergleichen der Signatur mit einer erwarteten Signatur und/oder Erzeugen einer Fehlerabbildung, wenn die Signatur nicht mit der erwarteten Signatur übereinstimmt).

Ein erster Chip, wie z. B. der Chip 316, der in 3A in gestrichelten Linien als betriebsfähig gezeigt ist, des Wafers 314 kann beispielsweise zum Testen des Chips 315 auf einem solchen Wafer 314 implementiert sein. Eine beispiel hafte Konfiguration, die einem Chip eines Wafers ermöglicht, einen weiteren Chip des Wafers zu testen, wird in der mitanhängigen und an die Anmelderin gemeinsam überwiesenen U.S.-Patentanmeldung Seriennummer 10,155,651 mit dem Titel „SYSTEM AND METHOD FOR TESTEING CICUITRY ON A WAFER" weiter beschrieben, deren Offenbarung hiermit durch Bezugnahme aufgenommen worden ist. Bei solchen Konfigurationen kann eine Signaturerzeugungslogik in dem ersten Chip 316 zum Erzeugen einer Signatur für die Ausgabe des Chips 315 umfaßt sein, wobei die Signaturerzeugungslogik in dem Chip 315, der getestet wird, nicht erforderlich ist. Spezieller kann der Testeinrichtungsschaltungsaufbau 316 bei bestimmten Implementierungen Testdaten (z. B. ein Testmuster) in den Chip 315 eingeben. Alternativ können die Sonde 313 und die ATE 301 verwendet werden, um solche Testdaten einzugeben. Der Testeinrichtungsschaltungsaufbau 316 kann die Ausgabe von einem DUT 315 ansprechend auf die Eingabetestdaten empfangen, und der Testeinrichtungsschaltungsaufbau 316 kann eine Signatur für zumindest einen Abschnitt der empfangenen Ausgabedaten erzeugen. Anschließend kann der Testeinrichtungsschaltungsaufbau 316 die Signatur mit einer erwarteten Signatur vergleichen, um zu bestimmen, ob das DUT 315 ordnungsgemäß funktioniert. Alternativ kann die Signatur, die durch den Schaltungsaufbau 316 erzeugt wird, an die ATE 301 (z. B. über die Sonde 313) kommuniziert werden, und die ATE 301 kann einen solchen Vergleich der erzeugten Signatur mit einer erwarteten Signatur vornehmen, um zu bestimmen, ob das DUT 315 ordnungsgemäß funktioniert.

Ausführungsbeispiele der vorliegenden Erfindung können in einer Kombination mit Maskenvektorkomprimierungs- und/oder Eingabevektorkomprimierungs-Verfahren für einen Test implementiert sein. Das heißt, daß die Ausgabevektordaten 311 nicht nur durch die Verwendung von Signaturen komprimiert werden können, sondern daß auch Eingabevektordaten 309 und/oder Maskenvektordaten 310 komprimiert werden können. Durch Komprimieren der Ausgabedaten 311, Eingabedaten 309 und Maskendaten 310 sowie Minimieren der Menge von Fehler abbildungsdaten 312 (durch Verwendung von Fenstern) verringerte ein bevorzugtes Ausführungsbeispiel weitgehend die Datenspeicheranforderungen 308 der ATE 301 zum Implementieren eines Testens eines DUT.

Verschiedene Verfahren können zum Komprimieren der Eingabedaten 309 und Maskendaten 310 verwendet werden. Bei bestimmten Ausführungsbeispielen der vorliegenden Erfindung können beispielsweise die Maskendaten (z. B. Maskendaten 310 von 3A) in Pakete einer feststehenden Anzahl von Bits kategorisiert werden. Es können zwei unterschiedliche Pakettypen definiert sein: (1) Null-Paket, d. h. Paket aus allen Nullen, und (2) ein deterministisches Paket mit sowohl Einsen als auch Nullen. Die Pakete des ersten Typs (Null-Pakete) können durch ein Steuerungsbit, das die Tatsache bezeichnet, daß es ein Null-Paket ist, ausgetauscht werden. Pakete des deterministischen Typs weisen Steuerungsbits auf, die den Typ zusammen mit dem Originalpaket bezeichnen. Da die Anzahl von Einsen allgemein sehr knapp ist (z. B. können Einsen die Bits bezeichnen, die für einen gegebenen Test maskiert werden sollen), können einige wenige Steuerungsbits viele der Originalbits ersetzen.

Die optimale Paketgröße hängt von der statistischen Verteilung der Einsen ab, d. h. sie variiert bei allen Bauelementen. Anstatt nur zwei unterschiedliche Pakettypen zu verwenden, können bei bestimmten Implementierungen mehr Pakettypen eingeführt werden. Zum Beispiel kann eine Paketgröße für alle Einsen eingeführt werden.

Der vorstehende Typ einer Maskenkomprimierung kann sehr gut zusammen mit Eingabekomprimierungslösungsansätzen funktionieren, wie jenen, die in der mitanhängigen und an die Anmeldung der vorliegenden Erfindung gemeinsam übertragenen U.S.-Patentanmeldung Seriennummer 09/802,440 mit dem Titel „TEST VECTOR COMPRESSION METHOD", die am 9. März 2001 eingereicht wurde, beschrieben sind, deren Offenbarung hiermit hierin durch Bezugnahme aufgenommen worden ist.

Da die Anzahl von Einsen im Maskendatensatz allgemein knapp ist, können die Maskendaten unter Verwendung von Lauflängen-Kodierungsverfahren komprimiert werden. Um die Längen zu kodieren, können normale Codewörter einer feststehenden Länge verwendet werden. Die hinreichend bekannten Huffman-Codes können beispielsweise verwendet werden, um kürzer Codewörter an Längen anzubringen, die mit einer höheren Wahrscheinlichkeit eintreten. Die Codes können unter Verwendung eines Huffman-Baums abgeleitet werden. Es kann nur eine begrenzte Anzahl von Längen codiert werden. Andere geeignete Komprimierungscodierverfahren können verwendet werden, die ohne Einschränkung die hinreichend bekannten Alias-γ-, die hinreichend bekannten Alias-λ-, die hinreichend bekannten Fibonacci-Codes, beliebige schwach besetzte Matrixcodes oder andere geeignete Komprimierungsschemata, die nun bekannt oder später entwickelt werden, umfassen, jedoch nicht auf dieselben beschränkt sind.

Durch Verwendung der hinreichend Golomb-Rice-Codierung können alle Längen direkt codiert werden, während eine einfache Hardwaredecodierungsimplementierung beibehalten wird. Ein Golomb-Rice-Codewort besteht aus einer Verkettung von einem Präfix einer variablen Länge von n Bits und einem Ende einer feststehenden Länge von m Bits (die einen Dezimalswert von q darstellen), wodurch die Gesamtlänge des Codeworts zu n+m-Bits gemacht wird. Der Präfix von n Bits beginnt mit n–1 Nullen, und das letzte Bit ist stets 1 (Notation: 0ⁿ ^–1 1). Auf diese Weise wird das Dekodieren des Präfix (n) nur auf das Zählen der Anzahl von Nullen reduziert. Das Ende ist ein normaler binärer Code feststehender Länge. Der Wert eines Golomb-Rice-Codeworts ist als n·2^m + q definiert.

Tabelle 1 gibt ein Beispiel von acht unterschiedlichen Längen an, die unter Verwendung von Codes einer feststehenden Länge, Huffman-Codes und Golomb-Rice-Codes codiert wurden.

Tabelle 1: Binäre Codierungsverfahren für die Gruppengröße

Fachleute werden auf verschiedene weitere Vorteile der Ausführungsbeispiele der vorliegenden Erfindung hingewiesen.

Bei herkömmlichen Testverfahren werden alle Bits der erwarteten Ausgabedaten im ATE-Speicher als die Ausgabevektordaten für einen Test, wie z. B. die erwarteten Ausgabedaten 107, die im Datenspeicher 106 von 1A gespeichert sind, gespeichert. Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung werden jedoch nur „Fenstersignaturen" (die, wie hierin verwendet, sich auf eine Signatur für ein Fenster von Bits beziehen) in einer Datenspeicherung 308 für die Ausgabevektordaten für einen Test gespeichert. In dem Beispiel von 3A weisen z. B. die erwarteten Signaturdaten 311 eine Mehrzahl von Fenstersignaturen auf, die als Fenster-1, Fenster-2, ..., Fenster-N gezeigt sind. Eine Fenstersignatur ist als eine Signatur basierend auf nur einem Fenster von einer vorbestimmten Anzahl von Bits definiert, d. h. der Fenstergröße. Die Fenstergröße kann während des Tests von unterschiedlichen Bauelementen oder selbst beim Test von einem Bauelement variierbar gestaltet werden.

Man nehme beispielsweise an, daß, ansprechend auf eine Eingabe, ein DUT 10 Bits ausgibt. In diesem Fall können die ersten fünf der Ausgabebits einem ersten Fenster zugewiesen werden, das für ein Erzeugen einer ersten Signatur verwendet wird, und die zweiten fünf der Ausgabebits können einem zweiten Fenster zugewiesen werden, das zum Erzeugen einer zweiten Signatur verwendet wird. Als weiteres Beispiel nehme man an, daß ein Test zehn unterschiedliche Testmuster aufweist, die in einDUT eingegeben werden sollen, und die Ausgabebits von dem DUT (die eine beliebige Anzahl von Ausgabebits aufweisen können) ansprechend auf jedes der zehn unterschiedlichen Testmuster ausgewertet werden können, um zu bestimmen, ob das DUT ordnungsgemäß funktioniert. Bei bestimmten Implementierungen können die Ausgabebits ansprechend auf jedes der zehn unterschiedlichen Eingabetestmuster einem anderen Fenster zugewiesen werden, das zum Erzeugen einer Signatur verwendet wird. Die Ausgabebits von dem DUT können ansprechend auf ein erstes Eingabetestmuster beispielsweise einem ersten Fenster zugewiesen werden, die Ausgabebits von dem DUT ansprechend auf ein zweites Eingabetestmuster können einem zweiten Fenster zugewiesen werden, usw.

Das Unterteilen der empfangenen Ausgabebits in Fenster in dieser Weise bietet bestimmte Vorteile. Zum Beispiel kann es verwendet werden, um eine Beibehaltung der Datenspeicherung zu ermöglichen, die zum Speichern von Fehlerabbildungsdaten 312 erforderlich ist. Nach einem Erfassen eines Fehlers für ein spezielles Fenster (z. B. stimmt die Signatur des Fensters nicht mit der erwarteten Signatur für ein solches Fenster überein), können die Ausgabedatenbits von einem solchen speziellen Fenster beispielweise bei bestimmten Implementierungen, im Gegensatz zum Speichern aller empfangenen Ausgabebits, an die Fehlerabbildung gespeichert werden. Natürlich können bei anderen Implementierungen alle (oder eine beliebige andere gewünschte Menge) der empfangenen Ausgabedaten für DUT an die Fehlerabbildung nach einer Erfassung eines Fehlers gespeichert werden. Ferner können bei bestimmten Implementierungen ein oder mehrere der Fehlerabbildungsdatenfenster in ein externes Speicherbauelement abgeladen werden, das mit der Testeinrichtung 301 kommunikativ gekoppelt ist, wodurch ein Teil der Datenspeicherung 308 der Testeinrichtung 301 von einem Speichern von mehr Fehlerdaten entlastet wird. Durchschnittsfachleute werden auf verschiedene weitere Vorteile der Verwendung der Fenster in der hierin offenbarten Weise hingewiesen.

Unter Bezugnahme auf 4 ist ein beispielhaftes Flußdiagramm gezeigt, das darstellt, wie erwartete Fenstersignaturen, wie z. B. die Fenstersignaturen 311 von 3A, bei einem bevorzugten Ausführungsbeispiel erzeugt werden. Solche erwarteten Signaturen würden typischerweise auf einem Computer erzeugt, wie z. B. dem beispielhaften Computer von 7, der nachstehend beschrieben wird, und dann auf die ATE 301 geladen. Wie gezeigt, bestimmt das Signaturerzeugungsprogramm bei Betriebsblock 401, ob ein nächstes Fenster von erwarteten Ausgabebits für einen gegebenen Test zur Verfügung steht. Solche Ausgabebits können beispielsweise durch Simulation des DUT mit den Eingabetestmustern erzeugt werden. Für einen gegebenen Test für ein spezielles Bauelement, das getestet werden soll, können ein oder mehrere Muster von Eingabetestwerten bereitgestellt werden, und das spezielle Bauelement soll spezielle Ausgabedatenwerte ansprechend auf jedes der Eingabetestmuster erzeugen. Dementsprechend kann der Test in einem gewissen Sinne modelliert werden, um die verschiedenen Ausgabedatenwerte zu bestimmen, die von dem Bauelement ansprechend auf die Eingabetestmuster erwartet werden, wenn das Bauelement ordnungsgemäß funktioniert.

Die erwarteten Ausgabedatenwerte können über eine Mehrzahl von „Fenstern" verteilt werden. Wie vorstehend beschrieben kann ein „Fenster" eine bestimmte vorbestimmte Anzahl von Ausgabebits aufweisen, die bei bestimmten Implementierungen während des Tests von unterschiedlichen Bauelementen oder selbst beim Test von einem Bauelement variabel sein können.

Verschiedene Fenster von unterschiedlichen Größen können beispielsweise beim Testen eines gegebenen Bauelements verwendet werden. Ferner können Größe und Anzahl von verwendeten Fenstern von einem Bauelementtest zum nächsten variieren. Vorzugsweise kann ein Benutzer die Fenstergröße, die für einen gegebenen Test zu verwenden ist, spezifizieren.

Somit wird bei Betriebsblock 401 bestimmt, ob alle erwarteten Ausgabebits (ansprechend auf eine Eingabe von Teststimuli), die ein nächstes „Fenster" aufweisen, verfügbar sind. Wenn keine weiteren Fenster von Ausgabedatenbits für den Test zu erwarten sind, dann wird bei Block 402 bestimmt, daß die Signaturerzeugung beendet ist (alle notwendigen Fenstersignaturen für den Test erzeugt worden sind). Somit ist der Test bei Block 402 bereit, um auf den tatsächlichen Bauelementen ausgeführt zu werden. Wenn jedoch bei Block 401 bestimmt wird, daß ein nächstes Fenster von Ausgabebits für die Signaturerzeugung zur Verfügung steht (z. B. erwartete Ausgabebits ansprechend auf ein gegebenes Eingabetestmuster), dann rückt der Betrieb zu Betriebsblock 403 vor, bei dem die Signaturerzeugungslogik (z. B. Software und/oder Hardware, wie z. B. SISR, MISR oder Cellular Automata-Logic) so zurückgesetzt wird, daß sie zum Empfangen eines Fensters von Ausgabebits und zum Erzeugen einer Signatur für ein solches Fenster bereit ist.

Bei Betriebsblock 404 können ein oder mehrere „bedeutungslose" Bits des Fensters der Ausgabebits maskiert werden. Zum Beispiel können bestimmte Ausgabebits ein nichtdeterministisches Verhalten aufweisen (z. B. können sie nicht anzeigen, ob ein DUT ansprechend auf das Eingabemuster ordnungsgemäß funktioniert, und führen daher zu einer Signaturverfälschung, wenn sie nicht herausmaskiert werden), und solche Bits, deren Wert für den Test bedeutungslos ist, können vom Fenster der Ausgabedaten maskiert (oder gefiltert) werden. Solche Maskendaten werden vorzugsweise in der Datenspeicherung 308 als Maskendaten 310 für den erzeugten Test gespeichert, wenn der Test auf die ATE 301 geladen wird. Wie vorstehend beschrieben, werden die Maskendaten 310 vorzugsweise komprimiert, und somit werden solche Daten dekomprimiert und bei Betriebsblock 404 zum Maskieren der entsprechenden Bits verwendet. Dann wird bei Betriebsblock 405 ein Modell der Signaturerzeugungslogik 305 der ATE 301 verwendet, um eine Signatur für die verbleibenden (nicht maskierten) Ausgabebits des Fensters zu erzeugen. Bei bestimmten Ausführungsbeispielen kann beispielsweise ein Modell von einer Signaturerzeugungslogik 305 ein SISR, MISR oder Cellular Automata (als Hardware und/oder Software) implementieren, und ein solches SISR, MISR oder Cellular Automata kann eine Signatur für die nichtmaskierten erwarteten Ausgabebits eines Fensters akkumulieren (erzeugen). Somit erzeugt die Signaturerzeugungslogik 304 ein erwartetes Signaturfenster, das für den entsprechenden Abschnitt des Tests erwartet wird, wenn derselbe auf einem tatsächlichen Bauelement ausgeführt wird (wenn das Bauelement ordnungsgemäß funktioniert). Sobald ein solches erwartetes Signaturfenster erzeugt wird, wird es bei Betriebsblock 406 (d. h. in der Datenspeicherung 308 von der ATE 301) gespeichert. Wie nachstehend ausführlicher beschrieben, werden solche gespeicherten erwarteten Signaturfenster während des tatsächlichen Testens des Schaltungsaufbaus verwendet, um zu bestimmen, ob die Ausgabe eines solchen Schaltungsaufbaus ansprechend auf Testeingabewerte wie erwartet ausfällt.

Unter Bezugnahme auf 5 ist ein Flußdiagramm gezeigt, das einen beispielhaften Betriebsfluß eines Testverfahrens eines bevorzugten Ausführungsbeispiels der Erfindung darstellt. Wie gezeigt, bestimmt die Off-Chip-Testeinrichtung (z. B. die ATE 301) bei Betriebsblock 501, ob ein nächstes Fenster von Ausgabebits von einem DUT (z. B. DUT 315) verfügbar ist. Spezieller werden die Eingabetestdaten von der Testeinrichtung in das DUT eingegeben, woraufhin das DUT Ausgabedaten erzeugt. Bei Betriebsblock 501 bestimmt die Testeinrichtung, ob alle Ausgabebits (ansprechend auf die Eingabedaten), die ein nächstes „Fenster" aufweisen, vom DUT empfangen werden. Wenn keine weiteren Fenster vom DUT für diesen Test erwartet werden, dann wird bei Block 502 bestimmt, daß das Testen beendet ist . Wenn jedoch bestimmt wird, daß ein Fenster von Ausgabebits vom DUT ansprechend auf ein gegebenes Eingabetestmuster empfangen worden ist, dann rückt der Betrieb in der Off-Chip-Testeinrichtung zu Betriebsblock 503 vor, bei dem die Signaturerzeugungslogik (z. B. Logik 305 der ATE 301 in 3A) so zurückgesetzt wird, daß sie zum Empfangen eines Fensters von Ausgabebits und zum Erzeugen einer Signatur für ein solches Fenster bereit ist. Wie vorstehend beschrieben, kann die Signaturerzeugungslogik der Testeinrichtung bei bestimmten Implementierungen ein SISR, ein MISR oder Cellular Automata implementieren, wobei in diesem Fall das SISR, MISR oder Cellular Automata bei Block 503 zurückgesetzt wird.

Bei Betriebsblock 504 können ein oder mehrere „bedeutungslose" Bits des empfangenen Fensters von Ausgabebits (unter Verwendung der Maskierungslogik 304) maskiert werden. Bestimmte Ausgabebits können beispielsweise ein nichtdeterministisches Verhalten aufweisen (z. B. können nicht anzeigen, ob das DUT 315 ansprechend auf das Eingabemuster ordnungsgemäß funktioniert), und solche Bits, deren Wert für den Test bedeutungslos ist, können von dem empfangenen Fenster von Ausgabedaten maskiert (oder gefiltert) werden. Die gleichen Bits, die bei Betriebsblock 404 von 4 beim Erzeugen eines erwarteten Signaturfensters maskiert wurden, werden bei Betriebsblock 504 ebenfalls maskiert, so daß die gleichen Ausgabebits, die zum Erzeugen des erwarteten Signaturfensters in 4 verwendet wurden, verwendet werden, um ein Signaturfenster für die Ausgabe des DUT zu erzeugen (wenn natürlich das DUT nicht wie erwartet funktioniert, können sich die Werte von solchen Ausgabebits von den erwarteten Werten, die beim Erzeugen des erwarteten Signaturfensters in 4 verwendet wurden, unterscheiden). Vorzugsweise ist eine Identifizierung der Ausgabebits, die für den Test maskiert werden sollen, in den Mas kendaten 310 umfaßt, die bei bestimmten Ausführungsbeispielen, wie vorstehend beschrieben, komprimiert sein können.

Anschließend wird die Signaturerzeugungslogik der Off-Chip-Testeinrichtung bei Betriebsblock 505 verwendet, um eine Signatur für die verbleibenden (nicht maskierten) Ausgabebits des Fensters zu erzeugen. Bei bestimmten Ausführungsbeispielen kann die Testeinrichtung beispielsweise ein SISR, MISR oder Cellular Automata (als Hardware und/oder Software) implementieren, und ein solches SISR, MISR oder Cellular Automata kann eine Signatur für die empfangenen (und nicht maskierten) Ausgabebits eines Fensters akkumulieren (erzeugen). Somit wird ein Signaturfenster für die empfangenen (und nicht maskierten) Ausgabebits vom DUT (unter Verwendung von beispielsweise der Logik 305) erzeugt.

Anschließend vergleicht die Testeinrichtung bei Betriebsblock 506 das erzeugte Signaturfenster mit einem gespeicherten erwarteten Signaturfenster für diesen Abschnitt des Tests, um zu bestimmen, ob das erzeugte Signaturfenster mit dem erwarteten Signaturfenster übereinstimmt. Wenn bestimmt wird, daß das erzeugte Signaturfenster mit dem erwarteten Signaturfenster übereinstimmt, dann wird bei Betriebsblock 507 bestimmt, daß das Fenster der empfangenen Ausgabebits diesen Test besteht, und der Betrieb kann zu Block 501 zurückkehren, um ein weiteres Testen auszuführen (z. B. um weitere Fenster von Ausgabedaten, die vom DUT empfangen wurden, auszuwerten). Wenn das erzeugte Signaturfenster jedoch nicht mit dem erwarteten Signaturfenster übereinstimmt, dann wird bestimmt, daß das DUT diesen Test nicht besteht, und Informationen über dieses Nichtbestehen können bei Betriebsblock 508 an eine Fehlerabbildung (z. B. Fehlerabbildung 312 von 3A) gespeichert werden. Bei bestimmten Implementierungen können beispielsweise die Charakteristika und/oder der Inhalt des defekten Fensters von Ausgabebits (z. B. der tatsächlichen Rohausgabebits) in eine Fehlerabbildung gespeichert werden, und solche gespeicherten Fehlerabbildungsinformationen können bei einer Feh lerauswertung (z. B. Diagnostizieren des Fehlers, um zu bestimmen, welche Bits nicht korrekt waren, und/oder Fehlerbereinigung des DUT, um den Grund zu bestimmen, warum es diesen Test nicht bestand) verwendet werden.

Bei einem bevorzugten Ausführungsbeispiel kann die Fehlerauswertung eines DUT-Fehlers gleichzeitig mit dem Signaturanalysetesten eines solchen DUT ausgeführt werden. Bei bekannten Signaturanalysetechniken ist ein derartiges gleichzeitig stattfindendes Testen und eine Fehlerauswertung des DUT nicht möglich. Tatsächlich gestaltet sich ein Ermöglichen einer Fehlerauswertung (z. B. Fehlerdiagnose) überhaupt unter Verwendung von Signaturanalyseverfahren des Stands der Technik allgemein sehr schwierig. Bei bekannten Signaturanalyseverfahren ist es rechnerisch sehr aufwendig und manchmal unmöglich, den Signaturanalyseprozeß umzukehren. In anderen Worten ist es durch Verwendung von Signaturanalyseverfahren des Stands der Technik möglich, eine Diskrepanz zwischen den tatsächlichen Ausgabevektordaten und den erwarteten Ausgabevektordaten zu bestimmen. Es ist jedoch typischerweise nicht möglich, zu bestimmen, welche empfangenen Bits der Ausgabevektordaten falsch sind. Dies schränkt die Diagnosefähigkeit der signaturbasierten Testverfahren des Stands der Technik ernsthaft ein. Ein bevorzugtes Ausführungsverfahren der vorliegenden Erfindung vereinfacht die Fehlerdiagnose von der Signaturanalyse, weil die Signatur für die Diagnose nicht umgekehrt werden muß, sondern stattdessen können die entsprechenden Rohausgabedaten, die durch die Testeinrichtung empfangen werden, für ein defektes Fenster an ein Fehlerprotokoll geschrieben werden.

Wenn außerdem die Fehlerauswertung (z. B. Diagnose) überhaupt bei bekannten Signaturanalyseverfahren verwendet wird, wird sie nicht gleichzeitig mit dem Testen des DUT ausgeführt. Vielmehr wird das Testen (z. B. Eingeben von Testdaten in das DUT, Erzeugen einer Signatur für Ausgabedaten des DUT und Vergleichen der erzeugten Signatur mit einer erwarteten Signatur) zuerst ausgeführt, und wenn die Fehlerauswertung erwünscht ist (z. B. ansprechend auf eine erzeugte Signatur, die mit einer erwarteten Signatur nicht übereinstimmt), dann wird ein zweiter Durchgang durch das DUT vorgenommen, wobei die Signaturlogik umgangen wird, um die Antwort direkt an die ATE zu senden. Das heißt, daß ein zweiter Satz von Interaktionen zwischen der Testeinrichtung um dem DUT erforderlich ist, um das DUT zu diagnostizieren/ einer Fehlerbereinigung zu unterziehen.

Bei anderen Lösungsansätzen werden mehrere Signaturen erzeugt, so daß die Position (innerhalb des Bereichs der Fläche, von der die Signatur erzeugt wird) des Fehlers bekannt ist. Danach wird immer noch ein zweiter Durchgang durch das DUT vorgenommen, wobei die Signaturlogik umgangen wird, um die Antwort direkt an die ATE zu senden.

Wie vorstehend beschrieben, können die Fenstercharakteristika in der Fehlerabbildung gespeichert werden (z. B. die Fenster-ID, die tatsächlichen und erwarteten Rohausgabedaten, die Zykluszahl etc.), wenn eine Diskrepanz zwischen der erwarteten Fenstersignatur und der erzeugten Fenstersignatur für empfangene Ausgabedaten bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung festgestellt wird. Der Start der Fenster in den Eingabe/Ausgabevektordaten kann beispielsweise durch ein Startzyklusregister oder durch Steuerungsbits bei den Eingabevektordaten erfolgen. Die Länge eines Fensters kann durch ein Längenregister bezeichnet werden, das für einen Test durch Benutzereingabe vorzugsweise dynamisch geändert werden kann. Es ist auch möglich, die Fensterlänge durch Steuerungsbits an den Eingabevektordaten zu bezeichnen, entweder indem dieselben mit den „Start-des-Fensters"-Steuerungsbits kombiniert werden oder das „Ende eines Fensters" bezeichnet wird.

Anstatt nur ein defektes Fenster zu erfassen, ist es möglich, daß ein Zähler vorliegt, der bezeichnet, wie viele defekte Fenster erfaßt werden müssen (z. B. vor dem Speichern von Fehlerabbildungsdaten für das DUT). Während einer intensiven Analyse eines DUT könnte ein Benutzer beispielsweise den Wunsch haben, Informationen für mehr als ein defektes Fenster zu erfassen, wohingegen ein Benutzer während eines schnellen Produktionstestens möchte, daß nur das erste defekte Fenster für ein DUT erfaßt wird.

Es ist möglich, die Speicheranforderungen weiter zu verringern, indem ein Zähler eingeführt wird, der zum Starten des Erfassens von Fehlerabbildungsinformationen verwendet wird, nachdem das nte Fenster oder das nte defekte Fenster erfaßt worden ist. Auf diese Weise müssen nicht alle bisher defekten Fenster im Speicher zum gleichen Zeitpunkt gespeichert werden. 6 zeigt ein Betriebsflußdiagramm von einem Ausführungsbeispiel der vorliegenden Erfindung, bei dem ein Erfassen von Fehlerinformationen nach dem nten defekten Fenster gestartet wird. Bei Betriebsblock 601 wird ein Zähler, der zum Zählen defekter Fenster verwendet wird, zurückgesetzt (z. B. auf Null). Anschließend wird ein Testen eines DUT in einer ähnlichen Weise ausgeführt, wie vorstehend in Verbindung mit 5 beschrieben wurde. Die Betriebsblöcke 602 – 608 entsprechen den Betriebsblöcken 501 – 507 von 5.

Wenn bei dem Ausführungsbeispiel von 6 jedoch bei Betriebsblock 607 bestimmt wird, daß eine Fenstersignatur, die für eine empfangene Ausgabe eines DUT erzeugt wurde (die Signatur, die bei Betriebsblock 606 erzeugt wurde), nicht mit der erwarteten Fenstersignatur für diesen Abschnitt des Tests übereinstimmt, dann rückt der Betrieb zu Block 609 vor, bei dem der Zähler des defekten Fensters inkrementiert wird. Anschließend wird bei Betriebsblock 610 bestimmt, ob der Zähler gleich einer vorbestimmten Zielzahl von defekten Fenstern ist. Bei diesem Ausführungsbeispiel werden Fehlerinformationen nur erfaßt, wenn eine vorbestimmte Zielzahl von defekten Fenstern für ein DUT erfaßt wird. Natürlich kann ein DUT den Test nicht bestehen und laut Bestimmung eine nicht ordnungsgemäße Qualität aufweisen, um als Produkt versandt zu werden, selbst wenn nur ein Fenster nicht besteht, jedoch werden Fehlerinformationen nur erfaßt (z. B. zur Fehlerauswertung), wenn eine vorbestimmte Zielzahl von defekten Fenstern während des Testens des DUT eintritt. Wenn somit bei Betriebsblock 610 bestimmt wird, daß die vorbestimmte Zielzahl von defekten Fenstern nicht erreicht worden ist, dann kehrt der Betrieb zu Block 602 zurück, um das nächste Fenster auszuwerten. Wenn andererseits bei Block 610 bestimmt wird, daß die vorbestimmte Zielzahl von defekten Fenstern erreicht worden ist, rückt der Betrieb zu Block 611 vor, um Informationen (z. B. Fenstercharakteristika und/oder Fensterinhalt) über das Nichtbestehen zu speichern. Anschließend kann der Betrieb zu Betriebsblock 602 zurückkehren, um das Testverfahren fortzusetzen.

Durch Verwenden dieses Lösungsansatzes werden die Ausgabespeicheranforderungen der ATE nun von der Gesamtausgabevektordatengröße auf das Maximum der Fenstergröße und die Größe aller Fenstersignaturen reduziert. Die Speicheranforderungen der ATE können weiter durch Aussenden der erfaßten Fenster während des Tests an ein anderes Datenspeicherbauelement verringert werden, wie z. B. an eine Arbeitsstation, die mit der ATE kommunikativ gekoppelt ist. In diesem Fall kann die Fehlerabbildung, die auf der ATE gespeichert ist, im wesentlichen lediglich als ein Puffer verwendet werden. Die Anzahl von Fenstern in dem Fehlerabbildungspuffer wird durch die Häufigkeit von defekten Fenstern und die verfügbare Bandbreite zum Übertragen von erfaßten Fenstern während des Tests an beispielweise eine Arbeitsstation bestimmt.

Wenn die Korrelation mit dem herkömmlichen Fluß nicht von Bedeutung ist, können folgende Verallgemeinerungen vorgenommen werden. Es ist möglich, nur die empfangenen Ausgabedaten, die an die Fehlerabbildung nach mehreren hierarchischen Iterationen gespeichert werden, entweder mit oder oh ne einen Zähler für die Anzahl von erfaßten defekten Fenstern oder dem zuerst erfaßten defekten Fenster zu erfassen. In diesem Fall können unterschiedliche vorbestimmte Fenstergrößen verwendet werden, um in ein kleineres Teilfenster zu iterieren (oder zu zoomen). Dementsprechend ist nur die erforderliche Speichergröße das Maximum der Größe der letzten Fensteriteration und der Größe der Signatur an sich, und nicht des Maximums der Größe von einem der bisherigen Fenster und der Größe der Signaturen an sich. Die optimale Fenstergröße wird zu einem Kompromiß zwischen der Anzahl von akzeptablen gewünschten Iterationen und dem erforderlichen gewünschten Ausgabekomprimierungsverhältnis.

Angesichts des vorstehenden wird bei einem bevorzugten Ausführungsbeispiel eine Signatur auf einer Testeinrichtung, wie z. B. einer ATE, die sich außerhalb des DUT (z. B. einer Off-Chip-Testeinrichtung) befindet, für zumindest einen Abschnitt der Ausgabedaten, die vom DUT empfangen werden, erzeugt, und eine solche Signatur wird mit einer erwarteten Signatur verglichen, um zu bestimmen, ob das DUT ordnungsgemäß funktioniert. Bei einem bevorzugten Ausführungsbeispiel befindet sich das DUT auf einem Wafer, und die Testeinrichtung weist ein System auf, das sich außerhalb des Wafers befindet, auf dem das DUT angeordnet ist. Bei einer Implementierung eines bevorzugten Ausführungsbeispiels weist die Testeinrichtung beispielsweise eine ATE, wie z.B. die ATE 301 von 3A, auf. Verschiedene Elemente der Testeinrichtung, wie z. B. die Logik 302 zum Eingeben von Testdaten in das DUT, die Logik 303 zum Empfangen von Ausgabedaten von dem DUT, die Logik 304 zum Maskieren von Bits, die Logik 305 zum Erzeugen einer Signatur von zumindest einem Abschnitt der empfangenen Ausgabedaten (z. B. der nicht maskierten Daten), die Logik 306 zum Vergleichen der erzeugten Signatur mit einer erwarteten Signatur und die Logik 307 zum Erzeugen einer Fehlerabbildung für einen nicht bestandenen Test können eine Hardware und/oder Software aufweisen. Wenn ein solcher Code als ausführbare Anweisung oder als Softwarecode implementiert ist, kann er durch die Testeinrichtung von einem computerlesbaren Medium (z. B. einem Festplattenmedium, einem optischen Medium, einem ROM (ROM = read-only memory = Nur-Lesespeicher), einem RAM (RAM = random access memory = Direktzugriffsspeicher), einem Bandmedium, einem Kassettenmedium, einem Flash-Speicher, einem Speicherstift und/oder dergleichen) erhalten werden oder über ein Datensignal von einem Kommunikationsmedium (z. B. dem Internet) kommuniziert werden. Tatsächlich können die lesbaren Medien ein beliebiges Medium umfassen, das Informationen speichern und übertragen kann.

7 stellt ein beispielhaftes Computersystem 700 dar, das zum Erzeugen von erwarteten Signaturen verwendet werden kann, die durch eine Testeinrichtung verwendet werden sollen. Eine CPU (CPU = central processing unit = Zentrale Verarbeitungseinheit) 700 ist mit dem Systembus 702 gekoppelt. Die CPU 700 kann eine beliebige Allzweck-CPU sein. Geeignete Prozessoren umfassen einschränkungslos einen Pentium^®-4-Prozecessor von Intel. Die vorliegende Erfindung ist jedoch nicht durch die Architektur der CPU 700 eingeschränkt, solange die CPU aus 701 die erfindungsgemäßen Operationen, die hierin beschrieben sind, unterstützt. Die CPU 701 kann die verschiedenen logischen Anweisungen zum Erzeugen der gewünschten erwarteten Signaturen (z. B. Fenstersignaturen) für einen Test ausführen. Die CPU 701 kann beispielsweise Anweisungen auf Maschinenebene gemäß den exemplarischen Betriebsflüssen, die vorstehend in Verbindung mit 4 beschrieben wurden, ausführen.

Der Computer 700 umfaßt vorzugsweise auch einen RAM 701, der ein SRAM, DRAM, SDRAM oder dergleichen sein kann. Der Computer 700 kann beispielsweise den RAM 703 verwenden, um (zumindest vorübergehend) die verschiedenen erwarteten Signaturen zu speichern, die für einen speziellen Test, der modelliert wird, erzeugt wurden. Der Computer 700 umfaßt vorzugsweise einen ROM 704, der ein PROM, EPROM, EEPROM oder dergleichen sein kann. Der RAM 703 und der ROM 704 hal ten die Benutzer- und Systemdaten und Programme, wie in der Technik hinreichend bekannt ist.

Der Computer 700 umfaßt auch vorzugsweise einen I/O-Adapter (I/O = input/output = Eingabe/Ausgabe) 705, einen Kommunikationsadapter 711, einen Benutzerschnittstellenadapter 708 und einen Anzeigeadapter 709. Der I/O-Adapter 705 und/oder der Benutzerschnittstellenadapter 708 können bei bestimmten Ausführungsbeispielen einem Benutzer ermöglichen, mit dem Computer 700 zu interagieren, um Informationen einzugeben (z. B. zum Spezifizieren eines Tests für ein DUT, Spezifizieren einer Fenstergröße, Spezifizieren einer Zielzahl von defekten Fenstern, woraufhin Fehlerinformationen erfaßt werden sollen (wie in dem Beispielfluß von 6) und/oder zum Spezifizieren von Informationen, wie z. B. maskierten Bits, die beim Erzeugen erwarteter Signaturen zu verwenden sind). Ferner kann der I/O-Adapter 705 mit einem Drucker 714 gekoppelt sein, um zu ermöglichen, daß Informationen auf demselben gedruckt werden können.

Zusätzlich verbindet der I/O-Adapter 705 vorzugsweise die Speicherbauelemente 706, wie z. B. ein oder mehrere Festplatten, ein CD-Laufwerk, ein Floppy Disk-Laufwerk, ein Bandlaufwerk etc.. Die Speicherbauelemente können verwendet werden, wenn der RAM 703 den Speicheranforderungen, die einem Modellieren eines Tests und einem Erzeugen erwarteter Signaturen zugeordnet sind, nicht genügen kann.

Der Kommunikationsadapter 711 kann umfaßt sein, der angepaßt ist, um den Computer 700 mit dem Netz 712 zu koppeln, das ein beliebiges geeignetes Kommunikationsnetz, wie z. B. eine Telephonienetz (z. B. öffentliches oder privates geschaltetes Telephonienetz), ein LAN (LAN = local area network = lokales Netz), das Internet oder ein anderes WAN (WAN = wide area network = weites Netz) und/oder drahtloses Netz sein kann. Der Benutzerschnittstellenadapter 708 koppelt die Benutzereingabebauelemente, wie z. B. eine Tastatur 713, das Zeigerbauelement 707 und/oder die Ausgabebau elemente, wie z. B. Lautsprecher (nicht gezeigt) mit dem Computer 700. Der Anzeigeadapter 709 wird durch die CPU 701 angetrieben, um die Anzeige auf dem Anzeigebauelement 710 zu steuern, um beispielsweise einem Benutzer Informationen über einen Bauelementtest, der durchgeführt wird, anzuzeigen. Es wird darauf hingewiesen, daß die vorliegende Erfindung nicht auf die Architektur des Systems 701 beschränkt ist. Ein beliebiges geeignetes prozessorbasiertes Bauelement kann beispielsweise zum Erzeugen erwarteter Signaturen für einen Test (einschließlich der Off-Chip-Testeinrichtung, z. B. der ATE 301, bei bestimmten Implementierungen) verwendet werden.

8 stellt ein Blockdiagramm einer exemplarischen Testeinrichtung, ATE 301, dar, die zum Implementieren von Ausführungsbeispielen einer vorliegenden Erfindung angepaßt werden kann. Bei dem Ausführungsbeispiel von 8 ist das Computersystem 700 gezeigt, das mit der ATE 301 gekoppelt ist, wie z. B. über den Kommunikationsadapter 711 von 7, und kann ein Herunterladen von Testplänen, Testdaten (z.B. Eingabetestdaten, erwarteten Signaturen für einen Test etc.) oder eine Schnittstellenverbindungsfunktionsfähigkeit im Hinblick auf das ATE 301 ermöglichen. Solche Testpläne und Testdaten können in den ATE-Speicher (z. B. kann der Speicher 308 von 3A in den Testressourcen 820 umfaßt sein) über eine Zugriffssteuerungslogik 810 geladen werden. Die Testressourcen 820 können die vorstehend erwähnten Ressourcen 302 bis 307, die vorstehend in 3A beschrieben wurden, aufweisen. Bei dem dargestellten Ausführungsbeispiel werden die Testressourcen 820 mit der Steuerung/den Sequenzern 840 über ein Verbindungsnetz 830 gekoppelt. Die Steuerung/der Sequenzer 840 arbeiten vorzugsweise, um eine der Testressourcen 820 mit einigen der Stifte 860 zu koppeln (die z. B. auf einer Sonde oder Sonden angeordnet sein können, wie z. B. der Sonde 313 von 3A), um entsprechende Testdaten auf das DUT zu Zeitpunkten und Sequenzen anzuwenden, die in dem verwendeten Testplan angeführt sind. Stiftelektronikkarten 850 sind zwischen der Steuerung/den Sequenzern 840 und den Stiften 860 des dargestellten Ausführungsbeispiels angeordnet, um die speziellen Spannungspegel, die durch die DUTs erforderlich sind, zu liefern.

Obwohl das dargestellte Ausführungsbeispiel drei Testressourcen, eine Steuerung/Sequenzer und Stiftelektronikkarten zeigt, kann die ATE 301 eine beliebige Anzahl von Elementen aufweisen. Außerdem liegt dahingehend keine Begrenzung vor, daß eine gleiche Anzahl von jedem dieser Elemente gemäß der vorliegenden Erfindung vorgesehen sein kann. Ferner soll das Ausführungsbeispiel von 8 lediglich ein Beispiel einer Konfiguration einer ATE sein, die Ausführungsbeispiele der vorliegenden Erfindung implementieren kann, und die vorliegende Erfindung soll eine solche beispielhafte Konfiguration nicht eingrenzen. Vielmehr soll eine beliebige andere geeignete Off-Chip-Testeinrichtungskonfiguration, die nun bekannt ist oder später entwickelt wird, die konfiguriert sein kann, um Rohausgabedaten von einem DUT zu empfangen und um eine Signatur (wie vorstehend bei 3A ausführlicher beschrieben ist) zu erzeugen, im Schutzbereich der vorliegenden Erfindung umfaßt sein. Die Testeinrichtung kann ferner bei bestimmten Ausführungsbeispielen auf einem Wafer implementiert sein und zum Testen anderer Schaltungsaufbauten auf einem solchen Wafer verwendet werden. Bei bestimmten Ausführungsbeispielen kann eine Testeinrichtung beispielsweise auf einem ersten Chip eines Wafers implementiert sein und kann zum Testen von zumindest einem anderen Chip auf dem Wafer verwendet werden.

Angesichts des vorstehenden wird darauf hingewiesen, daß die Ausführungsbeispiele der vorliegenden Erfindung implementiert sein können, um viele Vorteile gegenüber den Testverfahren des Stands der Technik zu liefern. Gemäß den Ausführungsbeispielen der vorliegenden Erfindung kann beispielsweise ein ähnliches Komprimierungsverhältnis wie das von herkömmlichen Signaturanalyseverfahren erreicht werden, jedoch ohne die Notwendigkeit an Entwurfsmodifizierungen im DUT. Aufgrund dessen liegen keine möglichen Siliziumflächengesamtkosten auf dem DUT zum implementieren des Tests und keine potentielle Verhaltensverschlechterung des DUT vor. Gemäß den Ausführungsbeispielen der vorliegenden Erfindung kann als weiteres Beispiel ein ähnliches Komprimierungsverhältnis wie bei herkömmlichen Signaturanalyseverfahren erreicht werden, jedoch ohne beliebige Einschränkungen bezüglich der Fehlerdiagnosefähigkeit.

Bei einem bevorzugten Ausführungsbeispiel kann eine Diagnose von Fehlern (und einer Ausbeutemitteilung) gleichzeitig mit dem Testen eines DUT ausgeführt werden. Das heißt ein „erster Durchgang" kann vorgenommen werden, bei dem die Off-Chip-Testeinrichtung mit dem DUT interagiert, indem Eingabetestdaten eingegeben und Rohausgabedaten von demselben empfangen werden, und aus einem solchen „ersten Durchgang" kann die Off-Chip-Testeinrichtung eine Signatur erzeugen und eine solche Signatur verwenden, um einen Fehler bei dem DUT zu erfassen, wobei, wenn ein Fehler erfaßt wird, die tatsächlichen Ausgabedaten, die von dem DUT empfangen werden, an ein Fehlerabbildungsprotokoll gespeichert werden können, ohne eine weitere Interaktion mit dem DUT zum Erfassen solcher Ausgabedaten zu erfordern. Weil eine Fehlerdiagnose gleichzeitig mit dem Testen eines DUT ausgeführt werden kann, sind bestimmte Ausführungsbeispiele der vorliegenden Erfindung speziell für eine Implementierung in einer Massenproduktions-Testeinstellung geeignet.

Ferner unterteilt ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung die empfangenen Ausgabebits in eine Mehrzahl von Fenstern und erzeugt Signaturen für jedes individuelle Fenster. Die Nutzung von Fenstern in dieser Weise ermöglicht bestimmte Vorteile, wie z. B. ein Ermöglichen einer Beibehaltung der Datenspeicherung, die zum Speichern von Fehlerabbildungsdaten erforderlich ist (z. B. durch Speichern von Fehlerdaten, die einem defekten Fenster zugeordnet sind, d. h. einem Fenster, dessen Signatur nicht mit der erwarteten Signatur für ein solches Fenster überein stimmt). Fachleute werden auf verschiedene weitere Vorteile des Verwendens von Fenstern in der hierin offenbarten Weise hingewiesen.

Bei einem bevorzugten Ausführungsbeispiel ist das Testverfahren auf einer ATE implementiert, was dahingehend vorteilhaft ist, weil das ATE bereits die gewünschte Maskierungsfähigkeit aufweist (z. B. um ein flexibles Maskieren von Ausgabebits zu ermöglichen, die in der Signaturanalyse verwendet werden sollen). Als weiteres Beispiel können die Ausführungsbeispiele der vorliegenden Erfindung mit DUTs verwendet werden, die MISRs aufweisen, die auf dem Chip implementiert sind, wodurch eine generische Testplattform ermöglicht wird. Das heißt, obgleich ein Auf-Chip-Testschaltungsaufbau (z. B. ein Signaturerzeugungsschaltungsaufbau) bei Ausführungsbeispielen der vorliegenden Erfindung nicht erforderlich ist, können bestimmte Ausführungsbeispiele der vorliegenden Erfindung auf einer Plattform (z. B. einer ATE) implementiert sein, die verwendet werden kann, um auch DUTs zu testen, die einen Auf-Chip-Testschaltungsaufbau aufweisen, wodurch ein Testen bei den herkömmlichen Verfahren des Stands der Technik oder ein Testen gemäß den Ausführungsbeispielen der vorliegenden Erfindung ermöglicht wird. Das heißt, daß die Plattform der Ausführungsbeispiele der vorliegenden Erfindung kein Testen eines DUT ausschließt, das einen Auf-Chip-Testschaltungsaufbau umfaßt (z. B. einen Auf-Chip-Signaturerzeugungsschaltungsaufbau), jedoch in vorteilhafter Weise ein effizientes Testen von DUTs ermöglicht, die keinen solchen AufChip-Testschaltungsaufbau umfassen.

Als weiteres Beispiel können die Ausführungsbeispiele der vorliegenden Erfindung in Kombination mit Maskenvektorkomprimierungs- und/oder Eingabevektorkomprimierungsverfahren für einen Test für eine anhaltende Beibehaltung der Datenspeicherung implementiert sein, die für ein Implementieren des Tests erforderlich ist.

Claims

Off-Chip-Testsystem, das folgende Merkmale aufweist: eine Einrichtung (302) zum Eingeben von Testdaten in ein Testchipelement (315); eine Einrichtung (303) zum Empfangen von Ausgabedaten von dem Testchipelement ansprechend auf die Eingabetestdaten; eine Einrichtung (305) zum Erzeugen einer Signatur für zumindest einen Abschnitt der empfangenen Ausgabedaten; eine Einrichtung (306) zum Vergleichen der erzeugten Signatur mit einer erwarteten Signatur; und eine Einrichtung (307) zum Speichern von Informationen in einem Fehlerabbildungsprotokoll (312), wenn die erzeugte Signatur nicht mit der erwarteten Signatur übereinstimmt.
Off-Chip-Testsystem gemäß Anspruch 1, bei dem die Einrichtung (307) zum Speichern von Informationen keine weitere Interaktion mit dem Testchipelement (315) erfordert, nachdem bestimmt worden ist, daß die erzeugte Signatur nicht mit der erwarteten Signatur übereinstimmt, um die Informationen, die in dem Fehlerabbildungsprotokoll gespeichert werden sollen, zu erfassen.
Off-Chip-Testsystem gemäß Anspruch 1 oder 2, bei dem die Einrichtung (305) zum Erzeugen einer Signatur folgendes Merkmal aufweist: eine Einrichtung (305) zum Erzeugen einer Signatur für ein Fenster der empfangenen Ausgabedaten, wobei das Fenster eine vorbestimmte Anzahl von Bits aufweist.
Off-Chip-Testsystem gemäß Anspruch 3, bei dem die empfangenen Ausgabedaten in eine Mehrzahl von Fenstern aufgeteilt werden, und die Einrichtung (305) zum Erzeugen einer Signatur eine Signatur für jedes von der Mehrzahl von Fenstern erzeugt.
Off-Chip-Testsystem gemäß Anspruch 4, bei dem die Einrichtung zum Vergleichen folgendes Merkmal aufweist: eine Einrichtung (306) zum Vergleichen der erzeugten Signatur für ein erstes Fenster mit einer erwarteten Signatur für das erste Fenster.
Off-Chip-Testsystem gemäß Anspruch 5, bei dem die Einrichtung (307) zum Speichern von Informationen folgendes Merkmal aufweist: eine Einrichtung zum Speichern von Informationen in ein Fehlerabbildungsprotokoll über zumindest das erste Fenster, wenn die erzeugte Signatur für das erste Fenster nicht mit der erwarteten Signatur für das erste Fenster übereinstimmt.
Off-Chip-Testsystem gemäß einem der Ansprüche 1 bis 6, bei dem der Testchipelement (315) einen Schaltungsaufbau auf einem Halbleiterwafer aufweist und das Off-Chip-Testsystem außerhalb des Wafers angeordnet ist.
Off-Chip-Testsystem gemäß einem der Ansprüche 1 bis 7, bei dem das Testchipelement ein gehäustes Chipelement ist und das Off-Chip-Testsystem außerhalb des gehäusten Wafers angeordnet ist.
Off-Chip-Testsystem gemäß einem der Ansprüche 1 bis 8, das ferner folgendes Merkmal aufweist: eine Einrichtung zum Maskieren von zumindest einem Abschnitt der empfangenen Ausgabedaten, um beim Erzeugen der Signatur nicht verwendet zu werden.
Off-Chip-Testsystem gemäß einem der Ansprüche 1 bis 9, das ferner folgendes Merkmal aufweist: eine Einrichtung (307) zum Speichern von Maskendaten, die Bits der empfangenen Ausgabedaten, die maskiert werden sollen, identifizieren, wobei die Maskendaten komprimiert sind.
Off-Chip-Testsystem gemäß Anspruch 10, das ferner folgende Einrichtung aufweist: eine Einrichtung zum Dekomprimieren der Maskendaten.
Off-Chip-Testsystem gemäß Anspruch 10, das ferner folgendes Merkmal aufweist: eine Einrichtung zum Komprimieren der Maskendaten.
Off-Chip-Testsystem gemäß einem der Ansprüche 1 bis 12, bei dem die Einrichtung zum Speichern von Informationen in das Fehlerabbildungsprotokoll den zumindest einen Abschnitt der empfangenen Ausgabedaten speichert, die zum Erzeugen der Signatur verwendet werden, die nicht mit der erwarteten Signatur übereinstimmt.
System zum Testen eines Schaltungsaufbaus (315), wobei das System folgende Merkmale aufweist: eine automatisiertes Testausrüstung (301) außerhalb des Schaltungsaufbaus, das zumindest vorübergehend mit dem Schaltungsaufbau kommunikativ gekoppelt ist, wobei die automatisierte Testausrüstung eine kommunikative Schnittstelle (313) zum Eingeben von Testdaten in den Schaltungsaufbau, eine kommunikative Schnittstelle (313) zum Empfangen von Ausgabedaten von dem Schaltungsaufbau ansprechend auf die Eingabetestdaten, eine Logik (305), die zum Erzeugen einer Signatur für zumindest einen Abschnitt der empfangenen Ausgabedaten betreibbar ist, eine Vergleichslogik (306) zum Vergleichen einer erzeugten Signatur mit einer erwarteten Signatur und eine Logik (307) zum Speichern von Informationen in ein Fehlerabbildungsprotokoll (312) aufweist, wenn eine erzeugte Signatur nicht mit einer erwarteten Signatur übereinstimmt.
System gemäß Anspruch 14, bei dem der Schaltungsaufbau einen Schaltungsaufbau auf einem Halbleiterwafer aufweist.
System gemäß Anspruch 14 oder 15, bei dem die Logik zum Speichern der Informationen in ein Fehlerabbildungsprotokoll keine weitere Interaktion mit dem Schaltungsaufbau nach Erfassung einer erzeugten Signatur, die mit einer erwarteten Signatur nicht übereinstimmt, erfordert.
System gemäß einem der Ansprüche 14 bis 16, bei dem die Informationen, die in ein Fehlerabbildungsprotokoll gespeichert wurden, zumindest einen Abschnitt der empfangenen Ausgabedaten aufweisen, die zum Erzeugen der Signatur verwendet werden, die mit der erwarteten Signatur nicht übereinstimmte.
System gemäß einem der Ansprüche 14 bis 17, bei dem die automatisierte Testausrüstung ferner folgendes Merkmal aufweist: eine Logik zum Maskieren von zumindest einem Abschnitt der empfangenen Ausgabedaten, um nicht beim Erzeugen der Signatur verwendet zu werden.
System gemäß Anspruch 18, bei dem die automatisierte Testausrüstung ferner folgendes Merkmal aufweist: eine Datenspeicherung, die mit derselben kommunikativ gekoppelt ist, die Maskendaten aufweist, die Bits der empfangenen Ausgabedaten identifizieren, die maskiert werden sollen, wobei die Maskendaten komprimiert sind.
System gemäß Anspruch 19, bei dem die automatisierte Testausrüstung ferner folgendes Merkmal aufweist: eine Logik zum Dekomprimieren der Maskendaten.
Verfahren zum Testen eines Schaltungsaufbaus, wobei das Verfahren folgende Schritte aufweist: Eingeben (321) von Testdaten in einen Testschaltungsaufbau; Empfangen (322), an einer externen Testeinrichtung (301, 316), von Ausgabedaten von dem Testschaltungsaufbau ansprechend auf die Eingabetestdaten; Erzeugen (324), an der externen Testeinrichtung (301, 315), einer Signatur für zumindest einen Abschnitt der empfangenen Ausgabedaten; Vergleichen der erzeugten Signatur mit einer erwarteten Signatur, um zu bestimmen, ob der Testschaltungsaufbau wie erwartet funktioniert; und wenn die erzeugte Signatur nicht mit der erwarteten Signatur übereinstimmt, Speichern von Informationen in ein Fehlerabbildungsprotokoll, wobei eine weitere In teraktion mit dem Testschaltungsaufbau nicht erforderlich ist, nachdem bestimmt worden ist, daß die erzeugte Signatur nicht mit der erwarteten Signatur übereinstimmt, um die Informationen zum Speichern der Informationen in das Fehlerabbildungsprotokoll zu erfassen.
Verfahren gemäß Anspruch 21, das ferner folgenden Schritt aufweist: Aufteilen der empfangenen Ausgabedaten in eine Mehrzahl von Fenstern, wobei jedes Fenster eine vorbestimmte Anzahl von Bits aufweist, wobei der Schritt des Erzeugens ein Erzeugen einer Signatur für jedes von der Mehrzahl von Fenstern aufweist.
Verfahren gemäß Anspruch 22, bei dem der Schritt des Erzeugens folgenden Schritt aufweist: Vergleichen der erzeugten Signatur für ein erstes Fenster mit einer erwarteten Signatur für das erste Fenster.
Verfahren gemäß Anspruch 23, bei dem das Speichern von Informationen in ein Fehlerabbildungsprotokoll ferner folgenden Schritt aufweist: wenn die erzeugte Signatur für das erste Fenster nicht mit der erwarteten Signatur für das erste Fenster übereinstimmt, Speichern von Informationen über zumindest das erste Fenster in das Fehlerabbildungsprotokoll.
Verfahren gemäß Anspruch 24, bei dem die Informationen über das erste Fenster folgendes Merkmal aufweisen die empfangenen Ausgabedaten des ersten Fensters.