DE10392667T5

DE10392667T5 - Ereignisbasiertes IC-Testsystem

Info

Publication number: DE10392667T5
Application number: DE10392667T
Authority: DE
Inventors: Rochit Santa Clara Raysuman; Robert F. Santa Clara Sauer; Shigeru Santa Clara Sugamori; Hiroaki Santa Clara Yamoto; James Alan Santa Clara Turnquist; Anthony Santa Clara Le; Bruce R. Santa Clara Parnas
Original assignee: Advantest Corp
Current assignee: Advantest Corp
Priority date: 2002-05-20
Filing date: 2003-05-19
Publication date: 2005-06-30
Also published as: US7089135B2; US20030217341A1; WO2003098240A1; US20030217345A1; JP2005525577A

Abstract

Verfahren zum Testen eines IC-Bauelementprüflings (DUT), der unter einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung entworfen wurde, umfassend die folgenden Schritte:
Speichern von Ereignisdaten, die direkt aus der Simulation von Designdaten für eine intendierte integrierte Schaltung in einer EDA-Umgebung erlangt wurden, in einem Ereignisspeicher, wobei die Ereignisdaten für jedes Ereignis aus Ereigniszeitablaufdaten, die eine Zeitlänge ab einem vorherigen Ereignis angeben, und Ereignistypdaten gebildet werden, die einen Ereignistyp angeben;
Erzeugen von Testvektoren auf der Grundlage der Ereignisdaten aus dem Ereignisspeicher, wobei die Signalform eines jeden Vektors durch die Ereignistypdaten bestimmt wird und ein Zeitablauf der Signalform durch Akkumulieren der Zeitablaufdaten von vorherigen Ereignissen bestimmt wird; und
Zuführen der Testvektoren zum DUT und Evaluieren von Antwortausgaben des DUT mit festgelegten Zeitabläufen.

Description

Erfindungsgebiet
Diese Erfindung betrifft ein Design und eine Architektur eines neuen Typs von Halbleiter-IC-Testsystemen und insbesondere ein ereignisbasiertes IC-Testsystem, bei dem Testdaten in einer Ereignisform verwendet werden, wodurch eine direkte Verwendung von Designsimulationsdaten ermöglicht wird, die in einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung erzeugt werden.
Hintergrund der Erfindung
Beim Testen von Halbleiter-IC-Bauelementen durch ein Halbleitertestsystem (IC-Tester oder Tester) beinhaltet die grundlegende Prozedur des funktionalen Testens eines Halbleiter-IC-Bauelements die Erzeugung eines Eingabe-(Ansteuer)-Stimulus für das IC-Bauelement, die Anwendung dieses Stimulus und Vergleichen der Ausgabe des IC-Bauelements mit erwarteten Ergebnissen durch Abtasten der Ausgaben mit festgelegten Zeitabläufen. Solch ein Eingabestimulus und solche Abtastimpulse werden gemeinschaftlich ein Testmuster oder ein Testvektor genannt und werden traditionell auf der Grundlage von Testdaten in einer zyklisierten Form erzeugt. Solch ein traditionelles Testsystem wird manchmal ein zyklusbasiertes Testsystem oder ein zyklisierter Tester genannt, wo verschiedene Daten zum Erzeugen des Eingabestimulus und der Abtastimpulse relativ zu entsprechenden Testzyklen (Testerraten oder Zeiteinstellungen) definiert werden.
Heutzutage wird ein IC-Design unter einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung gemacht, wo IC-Designer neue ICs unter Verwendung einer Hochsprache wie etwa Verilog oder VHDL entwickeln und den Entwurf durch Verhalens-, gate-level Verilog/VHDL-Simulatoren simulieren. Solch eine Entwurfssimulation ist darauf gerichtet, die Funktionalität und Leistung zu überprüfen, bevor der Entwurf in einem Silizium-IC hergestellt wird. Um die Designsimulationsdaten zu verwenden, erfordert das herkömmliche IC-Testsystem die Konversion von Entwurfssimulationsdaten in zyklisierte Form, wie etwa ein WGL-(Waveform Generation Language = Signalformerzeugungssprache) oder ein STIL-Format (Standard Test Interface Language = Standardtest-Schnittstellensprache).
Wie es oben erwähnt wurde sind die heutigen Halbleiter-IC-Testsysteme einzelne oder mehrere Zeiteinstellungsmaschinen (zyklisierte oder zyklusbasierte Maschinen), bei denen Daten mit jedem Pin in Verbindung stehen (T. Kazamaki et al. "trial model of 100 MHz test. station for high speed LSI test system", IEEE Int. Test Conf., S. 139 bis 145, 1978, T. Sudo, "A 100 MHz tester – challange to new horizon of testing high speed LSI" IEEE Int. Test Conf., S. 362 bis 368, 1979 und M. Shimizu et al., "100 MHz algorithmic pattern generator for memory testing", IEEE, Int. Test Conf., S. 56 bis 67, 1980). Die Unterschiede sind die, dass in einigen Testsystemen diese Zeiteinstellungen im Flug umgeschaltet werden können; bei anderen Testsystemen sind Signalformformatierer erhältlich, um komplexe Signalformen zu erzeugen; und der dritte Unterschied ist, dass Relais-Funktionalitäten inkorporiert sind, für gemeinsame Quellenmaschinen, um die Zeitablaufgeneratoren zu teilen oder sie auf die gewünschten Pins zu verteilen (S. Bisset, "The development of a tester per pin VLSI test system architecture", IEEE Int. Test Conf., S. 151 bis 155, 1983).
Wegen dieser Zeiteinstellungen und Signalformformatierer ist die heutige Operationsumgebung völlig unterschiedlich zur IC-Entwurfsumgebung. Zeiteinstellungen, Signalformen, Signalformgruppen, Zeitablaufgeneratoren, Signalformformatierer, Sequenzen und Musterbits/Pin sind Manifestationen des Testsystems und nicht des IC-Designs. Wegen dieser Beschränkungen bei heutigen Testsystemen erfordert das Testen von ICs jedoch eine andere Umgebung als die ursprüngliche IC-Design- und -simulationsumgebung.
Vom Gesichtspunkt des Anwenders aus verursachen die obigen Beschränkungen folgende Probleme: (i) die Vektorkonversion verbraucht beträchtlich Zeit, Server- und Festplattenkapazitäten und ist sehr fehleranfällig, (ii) die Zyklisierung von Vektoren macht mehrfache Taktdomänenbauelemente untestbar und (iii) infolge einer endlichen Zahl von Quellen wie etwa Zeiteinstellungen, Signalformgruppen, Zeitablaufgeneratoren etc. erwachsen Testerbeschränkungen.
Während die primäre IC-Design und -simulationsumgebung wegen der obigen Beschränkungen ereignisorientiert ist, ist die Testumgebung zyklisiert. Daher ist es eine von der ursprünglichen IC-Designumgebung fremde Umgebung und verursacht Schwierigkeiten während des Testens und der Fehlerbehebung der ICs. Um die Testumgebung zu erhalten sind Techniker zudem genötigt, Simulationstestbänke zu erformieren und Simulation noch mal laufen zu lassen, um die zyklisierten Vektoren zu erheben, die zum Testen benötigt werden. Im Wesentlichen macht es die Testdaten sehr unterschiedlich als die ursprünglichen Design- und Simulationsdaten. Die Techniker übersetzen Vektoren in andere Zwischenformate wie etwa STIL (Standard Test Interface Language = Standardtest-Schnittstellensprache, IEEE-Standard 1450, 1999) und WGL (Waveform Generation Language = Signalformerzeugungssprache), um ein Testprogramm zu erzeugen, wie es in 1A veranschaulicht ist.
1A zeigt einen Prozess, der beim heutigen zyklisierten Testsystem zum Testen des IC durch Verwendung der Designtestbankdaten (Simulationsvektoren) mit einbezogen ist. Bei diesem Beispiel gibt die linke Seite eine Designdomäne 10 an, bei der die Designtestbank durch einen Logiksimulator ausgeführt wird, wodurch Eingabe-/Ausgabeereignisdaten des Entwurfs erzeugt werden, d. h. VCD (Werteveränderungsauflistung durch Verilog). Die rechte Seite gibt eine Testdomäne 20 an, bei der das entworfene IC-Bauelement durch den IC-Tester unter Verwendung der Testvektoren getestet werden, die auf der Grundlage der VCD-Daten erzeugt werden, die in der Designdomäne erzeugt werden.
Wie es in 1A gezeigt ist, erfordert die Testprogrammentwicklung bei der herkömmlichen Technologie, die das zyklusbasierte Testsystem involviert, (i) das Extrahieren von ereignisbasierter Simulationsvektoren (VCD-Format) in Schritt 11, (ii) das Konvertieren der Simulationsvektoren in zyklusbasierte Vektoren im Schritt 12 und (iii) das Konvertieren der zyklusbasierten Vektoren in ein Format des Testers wie etwa WGL und STIL in Schritt 21 und/oder ein eigenes Format wie etwa TDL ("Test Description Language" von Advantest Corporation, Tokyo, Japan) im Schritt 22. Die sich ergebenden Testvektoren im Zyklusformat werden verwendet, um in Schritt 23 ein Testprogramm zu erzeugen. Dieses Testprogramm wird am Tester ausgeführt, um die Antwortausgaben des IC zu evaluieren.
Das Konvertieren der IC-Simulationsvektoren vom VCD-Format in das zyklisierte Format ist sehr zeitraubend, komplex und fehleranfällig. Dieses Problem wird darüber hinaus durch die Tatsache verschlimmert, dass jeder Tester seine eigene einzigartige und proprietäre Sprache und Vektorformat (beispielsweise TDL und LPAT von Advantest) besitzt. Schließlich werden alle diese Anstrengungen bei der Vektorkonversion außerordentlich zeitraubend und kostspielig. Die Zeit, die erforderlich ist, um diese Vektoren zu verarbeiten, hat proportional mit der Größe der Vektoren zugenommen, wobei bis zu ein Monat benötigt wird, um alle VCD-Dateien in zyklisiertes Format zu verarbeiten.
Dieser langatmige Prozess verhindert zudem die Möglichkeit, neue oder verbesserte Vektoren schnell zu verarbeiten, wodurch der Test und der Fehlersuchprozess verlangsamt werden. Darüber hinaus gefährdet der ganze Vorgang des Konvertierens der ursprünglichen IC-Simulationsvektoren in ein zyklisiertes Format des Testers die Genauigkeit der Daten. Das führt zu Fehlern und Testvektoren, die nicht länger simulationsgetreu sind. Alle diese Probleme führen zu zusätzlicher Zeit und Kosten.
Deshalb besteht eine dringende Notwendigkeit in der Industrie für ein IC-Testsystem, das in der IC-Entwurfsumgebung arbeitet und all die Komplexität beseitigt, die mit der Testdatenkonversion in zyklisierte Form involviert ist, wie es bei heutigen Testsystemen getan wird.
Zusammenfassung der Erfindung
Es ist deshalb eine Aufgabe der vorliegenden Erfindung, einen neuen Typ von Halbleiter-IC-Testsystemen bereitzustellen, der in der Lage ist, die Designsimulationsdaten direkt zu verwenden, die in einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung erzeugt werden.
Es ist eine andere Aufgabe der vorliegenden Erfindung, eine neue Testerarchitektur bereitzustellen, die die IC-Designumgebung erlaubt, um von der Simulation auf das physikalische Testen der entworfenen Schaltungen (ICs) auszuweiten.
Es ist darüber hinaus Aufgabe der vorliegenden Erfindung, eine neue Testerarchitektur bereitzustellen, die das Testen in der Designsimulationsumgebung ermöglicht, was Entwicklungszeit spart und die Kosten des Testens von Halbleiter-ICs vermindert.
Es ist darüber hinaus Aufgabe der vorliegenden Erfindung, eine neue Testerarchitektur bereitzustellen, die Vektorverarbeitungsschritte in der herkömmlichen Technologie beseitigt und größtenteils die Dateianforderungen und den Mustervergleichsprozess vereinfacht, wodurch Zeit; Kosten gespart werden und Fehler bei der Vektorkonversion vermieden werden.
Ein Gesichtspunkt der vorliegenden Erfindung ist ein Verfahren zum Testen eines IC-Bauelementprüflings (DUT), der unter einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung entworfen wurde. Das Verfahren umfasst die Schritte des Speicherns von Ereignisdaten, die direkt aus der Simulation von Designdaten für eine intendierte integrierte Schaltung in einer EDA-Umgebung erlangt wurden, in einem Ereignisspeicher, wobei die Ereignisdaten für jedes Ereignis aus Ereigniszeitablaufdaten, die eine Zeitlänge ab einem vorherigen Ereignis angeben, und Ereignistypdaten gebildet werden, die einen Ereignistyp angeben, des Erzeugens von Testvektoren auf der Grundlage der Ereignisdaten aus dem Ereignisspeicher, wobei die Signalform eines jeden Vektors durch die Ereignistypdaten bestimmt wird und ein Zeitablauf der Signalform durch Akkumulieren der Zeitablaufdaten von vorherigen Ereignissen bestimmt wird, und des Zuführens der Testvektoren zum DUT und Evaluieren von Antwortausgaben des DUT mit festgelegten Zeitabläufen.
Ein anderer Gesichtspunkt der vorliegenden Erfindung ist ein ereignisbasiertes Testsystem zum Testen eines IC-Bauelementprüflings (DUT), der unter einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung entworfen wurde. Das ereignisbasierte Testsystem beinhaltet einen Ereignisspeicher zum Speichern von Ereignisdaten, die direkt aus der Simulation von Designdaten für eine intendierte integrierte Schaltung in einer EDA-Umgebung erlangt wurden, wobei die Ereignisdaten, um jedes Ereignis anzugeben, aus einem Zeitindex, der eine Zeitlänge ab einem festgelegten Punkt angibt, und Ereignistypdaten gebildet werden, die einen Typ der Veränderung bei einem Ereignis angeben, eine Ereigniserzeugungseinheit zum Erzeugen von Testvektoren auf der Grundlage der Ereignisdaten aus dem Ereignisspeicher, wobei die Signalform eines jeden Vektors durch den Ereignistyp bestimmt wird und ein Zeitablauf der Signalform durch Akkumulieren des Zeitindex von vorherigen Ereignissen bestimmt wird, und Mittel zum Zuführen von Testvektoren zum DUT und Evaluieren von Antwortausgaben des DUT mit festgelegten Zeitabläufen.
Ein weiterer Gesichtspunkt der vorliegenden Erfindung ist ein ereignisbasiertes Testsystem zum Testen eines IC-Bauelementprüflings (DUT), der unter einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung entworfen wurde. Das Testsystem beinhaltet einen Hostrechner zum Steuern einer Gesamtoperation des Testsystems, Schnittstellensoftware zum Verbinden des Hostrechners mit dem ereignisbasierten Testsystems, wobei die Schnittstellensoftware eine graphische Benutzerschnittstelle (GUI) beinhaltet, die einen Ereignisbetrachter zum Überwachen und Bearbeiten von Ereignissen für das Testsystem darstellt, Dateninterpretations- und -managementsoftware zum Interpretieren und Managen von Daten aus dem Hostrechner über die Schnittstellensoftware, und Ereignistesterhardware, die eine Vielzahl von Ereignistestereinheiten zum Speichern von Ereignisdaten, die direkt aus der Logiksimulation von Designdaten erlangt werden, und zum Erzeugen von Testvektoren auf der Grundlage der Ereignisdaten und Zuführen der Testvektoren zum DUT und Evaluieren der Antwortausgaben des DUT mit festgelegten Zeitabläufen aufweist.
Erfindungsgemäß ermöglichen das Verfahren und die Architektur des Testsystems das Testen und die Fehlersuche von ICs, ohne von der Umgebung abzuweichen, in der der IC entworfen wurde. Wie es oben erwähnt wurde, erfordert das herkömmliche IC-Testsystem die Konversion der Designsimulationsdaten in eine zyklische Form, wie etwa das WGL- oder STIL-Format. Die neue Architektur vermeidet solche Konversion und verwendet Designdaten wie sie sind. Auf diese Weise ermöglicht das Verfahren und das Gerät der vorliegenden Erfindung das Testen in der Umgebung, die identisch mit der Designsimulationsumgebung ist, was Entwicklungszeit spart und die Kosten des Testens von Halbleiter-ICs verringert.
Detaillierte Beschreibung der Erfindung
Die vorliegende Erfindung wird nun unter Bezugnahme auf die beigefügte Zeichnung detaillierter beschrieben. Die oben erwähnten Probleme erfordern eine vollständige Veränderung der Umgebung und des Prozesses sowie der Architektur des Testsystems, das heutzutage verwendet wird. Die Lösung erfordert eine fundamentale Veränderung, die das Testen und das Testsystem eher vereinfacht anstatt den bereits komplizierten Prozess noch weiter zu verkomplizieren. Beispielsweise kann im Prinzip eine ausgeklügelte Software entwickelt werden, die die korrekte Vektortranslation von VCD zu STIL sicherstellt. Das grundlegende Problem der Zeit, der Mühen und der Kosten aufgrund des Translationsprozesses bleibt weiterhin bestehen. Daher sollte das Problem nicht durch Entwicklung stärker ausgefeilter Software gelöst werden, sondern durch Beseitigung der Notwendigkeit der Vektortranslation selbst.
Mit anderen Worten, die IC-Test-Umgebung sollte die gleiche sein, wie die ursprüngliche IC-Design-Umgebung; Techniker sollten nicht genötigt sein, ihre Simulationstestbänke in das ATE-zyklisierte Format zu ändern, und VCD-Vektoren brauchen nicht in STIL oder andere Formate konvertiert zu werden. Die Techniker sollten lediglich eine Simulationstestbank entwickeln, die ohne jede Veränderung sowohl für die IC-Designsimulation sowie für das IC-Testen verwendet werden sollte. Das bedeutet, es sollte keine Zyklisierung von Testbänken, keine Vektorkonversion aus VCD zu anderen Formaten und schließlich keine Notwendigkeit geben, komplizierte spezialisierte Testprogramme zu entwickeln.
Dieses Konzept wird in 1B veranschaulicht. Die Designtestbankdaten 11, d. h. VCD, erzeugt in der Designdomäne 10, können direkt von einem ereignisbasierten IC-Tester 30 in der Testdomäne 20 verwendet werden. Das stellt einen völligen Unterschied zum traditionellen Prozess von 1A dar, bei dem die Testprogrammentwicklung Konversion von ereignisbasieren Simulationsvektoren in zyklusbasierte Vektoren, ihr Erfassen im VCD-Format und ihr Konvertieren im Format des Testers erfordert.
Der gesamte IC-Testprozess, der das Konzept der vorliegenden Erfindung anwendet, ist in 2 veranschaulicht. Das Ziel ist es, Zeit, Mühe und Geld zu sparen, und zwar eher durch Beseitigung dieser Schritte in der herkömmlichen Technologie als durch Entwicklung noch weiterer Mittel, um diese Tätigkeiten zu erledigen. Bei dem Beispiel von 2 erzeugen die Designer Designdaten, typischerweise Verhaltens- oder RTL-Pegeldaten, die die Funktion der Schaltungen in der geplanten integrierten Schaltung beschreiben. Solche Designdaten werden in eine Bauelement-Verbindungsliste 32 konvertiert, die Sätze von verbundenen Komponenten durch Signale darstellt. Auf der Grundlage von Simulationsbedingungen 31 und der Bauelement-Verbindungsliste 32 lässt der Designer einen Simulator 33 laufen, wie etwa einen Verilog/VHDL-Simulator, unter Verwendung von Testbänken, die beim Entwerfen der integrierten Schaltung erzeugt werden, um die Funktionen der integrierten Schaltung. Die Ergebnisse dieser Simulation werden eingegeben und Wertesätze ausgegeben, d. h. Verilog VCD, welche in einem Ereignisformat vorliegen.
Eine Silizium-IC 35 wird auf der Grundlage der Baulelement-Verbindungsliste 32 erzeugt, die auf einem Loadboard 36 eines Ereignistesters (ereignisbasiertes Testsystem) 30 montiert werden kann. Der Ereignistester 30 erzeugt Testvektoren durch direktes Verwenden der VCD, erzeugt vom Simulator 33, und wendet die Testvektoren auf die Silizium-IC 35 an und evaluiert Antwortausgaben daraus. Demgemäß wird das Testergebnis erhalten und in einer Bestehen/Versagen-Datei 37 für die Fehleranalyse gespeichert. Auf diese Weise ist das ereignisbasierte Testsystem der vorliegenden Erfindung in der Lage, direkt die Designdaten zu verwenden, um die Testvektoren zu erzeugen.
Der Zessionar dieser Erfindung hat in früheren Patentanmeldungen, wie etwa den US-Anmeldungen Nr. 09/406,300 und 09/340371 , ein Konzept eines ereignisbasierten Testsystems offenbart. Es sollte beachtet werden, dass diese früheren Anmeldungen kein Stand der Technik gegen die vorliegende Erfindung sind. Diese Erfindung offenbart darüber hinaus eine Gesamtarchitektur eines ereignisbasierten Testsystems, einschließlich seiner Hardware- und Softwarekomponenten, der Eingabe- und Ausgabeformate, den internen und externen Datenfluss und des spezifischen Designs, das diese Ziele erreicht.
Die neue Testerarchitektur ist auf das IC-Design und die Simulationsumgebung ausgerichtet. Bei dieser Architektur verwendet der Tester Veränderungen in den Signalwerten (Ereignissen), die identisch sind zu Ereignissen, wie sie bei der IC-Simulation beobachtet werden. Zweitens werden Ereignisse an jedem Pin eher unabhängig behandelt, als dass sie gemäß Zeiteinstellungen zyklisiert werden.
Demgemäß beseitigt die vorliegende Erfindung die Vektorkonversionen und die Notwendigkeit, Testprogramme zu entwickeln.
Die grundlegende Architektur des ereignisbasierten Testsystems ist in 3A gezeigt. Für Vergleichszwecke ist in 3B die Architektur eines herkömmlichen Testsystems (zyklusbasiertes Testsystem) gezeigt. Darüber hinaus veranschaulicht 3C zur Verständlichkeit ein spezielles Beispiel von Beschreibungen des Testvektors im Zyklusformat und im Ereignisformat, das den Unterschied zwischen den beiden zeigt.
In 3A ist das ereignisbasierte Testsystem aus einem Ereignisspeicher 40 zum Speichern von Ereignisdaten (zeitgesteuerte Daten), einem Ereignisgenerator 41 zum Erzeugen von Ereignissen auf der Grundlage der Ereignisdaten und einem Treiber 42 zum Zuführen der Testvektoren an den Bauelement-Prüfling (DUT) aufgebaut. In 3B ist das herkömmliche zyklusbasierte Testsystem aus einen Ratengenerator 43 zum Erzeugen von Testerraten (Testzyklen), einem Musterspeicher zum Speichern von Musterdaten, einem Zeitablaufspeicher 45 zum Speichern von Zeitablaufdaten, einem Signalformspeicher zum Speichern von Signalformdaten (Aktionsdaten), einem Zeitablaufgenerator 47 zum Erzeugen von Zeitablaufsignalen auf der Grundlage der Zeitablaufdaten, einen Signalformformatierer 48 zum Erzeugen eines Testmusters auf der Grundlage der Zeitablaufsignale, Musterdaten und Signalformdaten, und einem Treiber 49 zum Zuführen der Testvektoren an den DUT aufgebaut.
Wie aus den 3A und 3B ersichtlich ist, werden der Ratengenerator 43, der Zeitablaufgenerator 47, der Mustergenerator 44, der Signalformspeicher 46 und der Zeitablaufspeicher 45 des herkömmlichen Testsystems beseitigt und anstelle dessen werden der Ereignisspeicher 40 und Ereignisgeneratoreinheiten 41 verwendet, wie es in 3A veranschaulicht ist. Das stellt eine komplette Veränderung in der Testerarchitektur dar. Der Ereignisspeicher 40 enthält die Ereignisse, wie sie in der Verilog/VHDL-Simulation beobachtet werden. Der Ereignisgenerator 41 konvertiert diese Ereignisse durch Verwendung des zugehörigen Zeitablaufs, wie er in der Verilog/VHDL-Simulation gespeichert wurde, in Aktionen (Signalformen von Testvektoren). Über den Treiber 42 werden diese Aktionen auf den DUT angewendet und die Erwiderung des DUT wird gegen die IC-Simulationswerte verglichen, um einen Fehler zu erfassen.
Durch Beseitigen der Raten- und Zeitablaufgeneratoren, des Musterspeichers, des Signalformspeichers und des Zeitablaufspeichers beseitigt die Architektur wirkungsvoll die Notwendigkeit des Zyklisierens der Vektoren und die Translation in andere Formate wie etwa WGL oder STIL. Der Ereignisspeicher 40 in 3A speichert Ereignisse wie sie in der IC-Simulation aufgenommen wurden. Auf diese Weise wird jeder Testvektor (jede Aktion) durch Antreiben eines Ereignisses (Daten "0" oder "1") mit seinem Zeitablauf erzeugt. Im zyklusbasierten Testsystem von 3B wird jeder Testvektor durch Antreiben einer bestimmten Signalform (Aktion) auf der Grundlage von Musterdaten ("0" oder "1") mit einem Zeitablauf erzeugt, der durch eine Zeiteinstellung (Testzyklus) angegeben wird. Auf diese Weise erreicht die neue Architektur das Ziel, dass der Zyklisierungs- und Vektortranslationsprozess beim dem Testen beseitigt werden sollte; und dass die Testumgebung die gleiche sein sollte wie die IC-Designumgebung.
Um die Unterschiede zwischen dem Zyklusformat und dem Ereignisformat klarer zu erläutern, wird ein kurzer Vergleich zwischen den zwei Formaten beim Beschreiben des gleichen Testvektors in 3C mit der Signalform 131 gemacht. Die Designsimulation VCD der Signalform 131 in einer Datei 137 gespeichert. Die Beschreibung in dieser Datei 137 wird in VCD-Beschreibung 139 gezeigt, welche im ereignisbasierten Format vorliegt, das die Veränderungen bei der Eingabe und Ausgabe der entworfenen IC zeigt. Die Signalformen 131 veranschaulichen zwei Pins Sa und Sb. Die Ereignisdaten, die die Signalformen beschreiben, werden aus Einstell- und Rückstellflanken San, Sbn, Ran und Rbn und ihre Zeitabläufe (beispielsweise Zeitlängen ab einem vorherigen Ereignis oder einem bestimmten Referenzpunkt) gebildet.
Zum Erzeugen der Signalform 131 beim herkömmlichen Halbleitertestsystem auf der Grundlage des zyklusbasierten Konzepts müssen die Testdaten in Testzyklen (Testerraten), Signalformen (Typen von Signalformen und ihre Flankenzeitabläufe) und Musterwerte unterteilt werden. Ein Beispiel solcher Beschreibungen ist in der Mitte und links von 3C gezeigt. Bei der zyklusbasierten Beschreibung werden Testmusterdaten 135 und Zeiteinstellungen 133 im linken Teil von 3C gezeigt, ein Testmuster wird in jeden Testzyklus (TS1, TS2 und TS3) unterteilt, um die Signalformen und Zeitabläufe (Verzögerungszeiten) für jeden Testzyklus zu definieren.
Ein Beispiel von Datenbeschreibungen für solche Signalformen, Zeitabläufe und Testzyklen wird in den Zeitablaufdaten 136 gezeigt. Ein Beispiel von logisch "1", "0" oder "Z" der Signalformen ist in den Musterdaten 135 gezeigt. Beispielsweise wird bei den Zeitablaufdaten 136 der Testzyklus durch "Rate" beschrieben, um Zeitintervalle zwischen Testzyklen zu definieren, und die Signalform wird durch RZ (Kehre zurück auf Null), NRZ (Kehre nicht auf Null zurück) und XOR (exklusives ODER) beschrieben. Darüber hinaus wird der Zeitablauf einer jeden Signalform durch eine Verzögerungszeit ab einer bestimmten Flanke (beispielsweise Startflanke) des entsprechenden Testzyklus definiert.
Wie es in 3C gezeigt ist, ist die ereignisbasierte Beschreibung 138 identisch mit den Designsimulationsergebnissen (VCD), während die zyklusbasierte Beschreibung die Zeiteinstellungen verschiedener Typen von Beschreibungen erfordert, welche zu abseits vom ursprünglichen Designsimulationsergebnis liegen. Es sollte beachtet werden, dass 3A ein sehr vereinfachtes Diagramm ist, um das grundlegende Konzept zu veranschaulichen. Die in 3A gezeigte Architektur ist jedoch weder nahe liegend noch einfach zu erhalten. Nun werden verschiedene Designaspekte beschrieben werden, um diese Architektur zu erreichen.
Ein Beispiel des Gesamttestdesigns ist in 4 gezeigt. Bei dem Beispiel von 4 beinhaltet das Gesamttestdesign einen Hostrechner 51, eine Schnittstellensoftware 52, eine Dateninterpretation- und -managementsoftware 56 und eine Ereignistesterhardware 61. Der Hostrechner 51 und die Ereignistesterhardware 61 können abseitig voneinander gelegen sein und direkt oder über ein allgemeines Kommunikationsnetzwerk, wie etwa über einen Webserver 55 oder ein bestimmtes Datenkommunikationsnetzwerk, übertragen werden. Die Schnittstellensoftware 52 beinhaltet eine Ereignisbetrachter-GUI (Graphische Benutzerschnittstelle) 53 und benutzerseitige Kommunikationsklassen 54. Über den Hostrechner 51 ruft ein Benutzer die Ereignisbetrachter-GUI 53 und den Ereignistester auf. Die Software der Ereignisbetrachter-GUI 53 erlaubt es, verschiedene Kommandos und notwendige Dateien anzugeben, und erlaubt auch die Datenbearbeitung und -manipulation während des Testens.
Die Dateninterpretations- und -managementsoftware 56 beinhaltet primär drei Komponenten: (i) eine Middelware 58 zur Datenverarbeitung und -interpretation, (ii) ein Kernprogramm zum Vermitteln zwischen Hardware und Software und (iii) einen Ereignistesteranwendungsserver 57 zum Koordinieren der Kommunikation vom Benutzer (über die GUI 53) zur Middelware 58 oder umgekehrt. Wie es oben angegeben wurde, kann die Kommunikation von der GUI 53 zum Anwendungsserver 57 entweder durch direkte Verbindung oder über das Kommunikationsnetzwerk stattfinden, wie etwa den Webabruf.
Die Middelware 58 beinhaltet verschiedene Softwarekomponenten zur Datenverarbeitung und -interpretation und erzeugt verschiedene Typen von Daten, wie es unter Bezugnahme auf 6A beschrieben werden wird. Das Kernprogramm 59 vermittelt zwischen der Hardware und Software durch beispielsweise Interpretieren der Spannungs-/Stromwerte, die von der Testerhardware in logischen 0-, 1- oder Z-Werten erhalten werden und führt diese Werte der Middelware 58 zu. Gleicherweise konvertiert das Kernprogramm 59 die Werte aus der Middelware 58 in physikalische Spannungs-/Strompegel für die Testerhardware.
Wie es in 4 dargestellt ist, sind verschiedene Softwarekomponenten entwickelt worden, die zusammenarbeiten, um die notwendige Funktionalität über eine kundenspezifische ASIC und eine Leiterplatte zu liefern. Im Folgenden werden der Aufbau und die Funktionsweise einer jeden der verschiedenen Komponenten detaillierter beschrieben werden. Darüber hinaus wird auch die Funktionsweise des Systems unter Bezugnahme auf die Zeichnung beschrieben werden.
Wie es vorhin erwähnt wurde, verwendet der Ereignistester der vorliegenden Erfindung VCD-Daten ohne Zyklisierung. Wie es oben erwähnt wurde, ist VCD im Grunde ein Zeitwertformat, um eine Veränderung im Signalwert und die Zeit der Veränderung zu beschreiben. Es gibt eine Zeit, einen Signalnamen und einen Binärwert eines Signals an, um ein Ereignis (beispielsweise Übergang von 0 zu 1 oder von 1 zu 0) zu identifizieren. Beispielsweise kann es angeben, dass zum Zeitpunkt 120 ns, ein Signal, das durch das ASCII-Symbol "$" identifiziert wird, 0 wird (mit anderen Worten, das Signal mit dem Namen "$" ändert sich von 1 zu 0 bei 120 ns; Ereignis 0 tritt an "$" bei 120 ns auf), wie es links von 5A angegeben ist (VCD-Datei).
Die Middelware 58, die die Softwarekomponente in 4 ist, interpretiert diese Daten und liefert sie in einer Form von Zeitindex und Binärwert (oder Hexadezimalwert) an das Kernprogramm 59 für die Testerhardware 61. Alternativ erhält in umgekehrter Reihenfolge die Mittelware 58 Zeitindex und Binärwert von der Testerhardware 61 über das Kernprogramm 59 und liefert es in für den Benutzer verständlichen Form über die Ereignisbetrachter-GUI 53 und den Hostrechner 51.
Ein einzigartiger Aspekt dieses Designs ist, dass der Ereigniszeitablauf als die Zeit (Zeitindex) ab dem letzten Ereignis (Deltazeit ab dem letzten Ereignis) beschrieben wird, die identisch mit der Designsimulation ist. Auf der Grundlage dieser Indexzeit erzeugt die Testerhardware Antriebsereignisse (Eingabestimulus an den DUT), Abtastereignisse zum Erfassen der DUT-Erwiderungsausgabe und Erwartungsereignisse (Erwartungswerte zum Vergleich mit der DUT-Ausgabe) ohne irgendeine Notwendigkeit für eine Datentranslation aus der VCD-Datei 60 (5A). Dieser einzigartige Aspekt erlaubt irgendeine Einzel- und Mehrfachereignisedierung (Verschieben, Addieren, Löschen) während des Testens durch einfaches Verwenden des Zeitindexwerts. Solche Ereignisedierungen sind beim derzeitigen Testsystem nicht möglich, weil die Testdaten gemäß den Signalformeinstellungen zyklisiert sind. Das Erfordernis der Zyklisierung beim herkömmlichen Testsystem macht es unmöglich, die entwickelte integrierte Schaltung im Ereignisformat zu testen und Fehler zu beseitigen.
Beim ereignisbasierten Testsystem der vorliegenden Erfindung wird wegen dieser Verwendung des Zeitindexwerts für jedes Ereignis die Speicheranforderung für das Ereignistestsystem wesentlich höher als bei derzeitigen Testsystemen. Die vorliegende Erfindung erfordert jedoch keine speziellen Zeitablauf- und Signalformerzeugungsschaltungen, wie es vorhin erwähnt wurde und in den 3A bis 3C gezeigt ist. Es sollte beachtet werden, dass eine alternative Implementierung für jedes Ereignis eine absolute Zeit verwendet würde (eher als die Deltazeit). In solch einer Situation wird die absolute Zeit als eine Zeitlänge definiert, beispielsweise ab einem Startpunkt der Operation.
Die rechte Seite von 5A veranschaulicht ein Beispiel von Datenstrukturen in einer VCD-Datei 60 und einem Ereignisspeicher 62. Wie es oben erwähnt wurde, ist VCD ein Zeitwertformat und in der Middelware 58 werden diese Zeitwertereignisdaten durch Zeitindizes und Signalwerte gekennzeichnet, die im Ereignisspeicher 62 in der Testerhardware 61 gespeichert werden sollen. Bei der vorliegenden Implementierung verwendet der Zessionar ein 18-Bit-Wort (Ereignisdaten) für jedes Ereignis, die bedeutendsten 3 Bits werden für den Signalwert (Ereignistyp) verwendet und 15 Bits werden für den Zeitindex verwendet (beispielsweise Deltazeit ab dem vorherigen Ereignis am gleichen Signal). Typischerweise wird die Deltazeit für jedes Ereignis gesammelt, wenn die Testvektoren erzeugt werden.
Die verschiedenen Kombinationen von 3 Bits können bis zu acht mögliche Werte von Ereignissen (Ereignistypen) repräsentieren. Beispielsweise hat der Zessionar bei dieser Implementierung sieben Werte, "Ansteuern 1", "Ansteuern 0", "Ansteuern Z", "Vergleiche 1", "Vergleiche 0", "Vergleiche Z" und "no-op". Das "Ansteuern 1", "Ansteuern 0" und "Ansteuern Z" sind Ansteuerereignisse als Stimulus für den Bauelementprüfling (DUT) und "Vergleiche 1", "Vergleiche 0" und "Vergleiche Z" sind Vergleichs- oder Abtastereignisse zum Vergleichen der Ausgabe aus dem Bauelementprüfling mit Erwartungswerten, wobei "Z" einen Hochimpedanzwert bezeichnet. Der 15-Bit-Wert kann bis zu 2¹⁵ Deltazeiten (Zeitdifferenzen ab dem vorherigen Ereignis) repräsentieren. Die gleichen Zessionare haben auch ausgefeiltere Verfahren zur Verzögerungszeiterzeugung und Datenverdichtung im Speicher entwickelt, wie es in den Patentanmeldungen Nr. 09/535,031 und 09/545,730 offenbart wurde, daher wird es hier nicht wiederholt.
Es sollte beachtet werden, dass die IC-Simulationsdaten zusätzlich zu 1, 0 und Z auch "X" (Ignorierungswert) beinhalten. Der Zessionar hat darüber hinaus ein einzigartiges Verfahren entwickelt, um Ignorierungswerte durch Konvertieren von "X" in "Z" (Hochimpedanzwert) zu handhaben. Auf diese Weise werden alle Unbeachtungswerte gleich dem vorherigen Wert bei dem Signal. Mit diesem Verfahren ist es möglich, Signalwerte auf lediglich drei Möglichkeiten zu beschränken: nämlich 1, 0 und Z, und schließlich viel Speicherplatz zu sparen. Es sollte, jedoch beachtet werden, dass eine alternative Implementierung mit einem größeren Speicher den Signalwert X mit einem passenden Zeitindex speichern würde, ähnlich den anderen Signalwerten.
Wegen dieses Verfahrens des Repräsentierens eines Ereignisses durch den Signalwert und Zeitindex kann der Anwender einen Abtastimpulsversatz für Abtastimpuls niedrig, Abtastimpuls hoch und Abtastimpuls Z hinzunehmen, der die Bauelementzeit ermöglicht, um auf die erwarteten Ausgabezustände zu antworten. Solche Operationen sind bei herkömmlichen Testsystemen nicht möglich. Der Anwender kann zudem die grundlegenden Testparameter, wie etwa Stromzuführungspegel und -ströme, Eingabe- und Ausgabespannungen und -ströme, Spannungsklemmen und Zuführungsrampe oder Wartezeiten über den Hostrechner 51 über die graphische Benutzerschnittstelle (Ereignisbetrachter-GUI 53) angeben.
Es lohnt sich zu erwähnen, dass die Verwendung des 18-Bit-Worts (Ereignisdaten) nur ein Beispiel der vorliegenden Implementierung des Zessionars ist; es kann irgendeine Länge des Wortes verwendet werden. Beispielsweise kann anstelle von 3 Bits irgendeine Zahl von Bits verwendet werden, um den Signalwert zu kennzeichnen, und anstelle der 15 Bits kann irgendeine Zahl von Bits verwendet werden, um die Deltazeit zu kennzeichnen.
Wie es in 5B gezeigt ist, wird dieses 18-Bit-Wort (Ereignisdaten) aus dem Ereignisspeicher 62 durch das Kernprogramm 59 an eine Pincardelektronik 65 in der Testerhardware 61 übergeben (4). Da dies ein Binärwert ist, ist er direkt von der Testerhardware verständlich und demgemäß kann die Pincardelektronik 65 ein geeignetes Ansteuerungs-Vergleichsereignis zu einem speziellen Zeitpunkt auf ein spezielles Signal angewandt werden.
Ähnlich zu den Ereignisdaten interpretiert die Middelware 58 zudem die Anweisungen des Anwenders, wie etwa Test-Lauf, Ereignis-Bewegung, Hinzufügen/Löschen eines Ereignisses etc., über die Ereignisbetrachter-GUI 53 und den Anwendungsserver 57 und liefert Start/Stopp, Einstelladresse, Stromzuführungssequenzen etc. an die Testerhardware 61 über das Kernprogramm 59 (oder umgekehrt). Die notwendige Dateienstruktur und der Datenfluss, um dieses Design zu erhalten, sind in 6A veranschaulicht. Wie es in 6A gezeigt ist werden durch den Anwender über den Hostrechner 51 und die Ereignisbetrachter-GUI 53 von 4 eine Testplandatei 63, eine Testparameterdatei 64, eine Pindatei 65 und eine Buchsendatei 66 angegeben.
Die Testplandatei 63 beinhaltet den Typ des Tests, der ausgeführt werden soll, wie etwa einen Kontakttest, Gleichstrom-/Wechselstrommessungen, Funktionstests etc. Die Parameterdatei 64 gibt verschiedene Parameter, wie etwa Voh (Spannungsausgang "hoch"), Vol (Spannungsausgang "niedrig"), Vil (Spannungseingang "niedrig"), Vih (Spannungseingang "hoch"), Iih (Stromeingang "hoch"), Iil (Stromeingang "niedrig"), Stromzuführung (PS) etc. an. Die Pindatei 65 gibt die vom Anwender angegebene Testerlogik-Pinzuweisung an. Die Buchsendatei 66 gibt eine vom Anwender angegebene Testbuchsen-Pinzuweisung an. Auf der Grundlage der Anweisungen des Anwenders über die Ereignisbetrachter-GUI 53 übergibt der Anwendungsserver 57 diese Daten an die Middelware 58. Die Middelware 58 interpretiert diese Daten und auf deren Grundlage schaltet das Kernprogramm 59 die Hardwaretreiber an oder aus, um diese Daten auf den Bauelementprüfling zu applizieren.
Bei dem Beispiel von 6A erzeugt die Middelware 58 über die Dateninterpretation und -verarbeitung verschiedene Datentypen, d. h. Testplan 67, Test 68, Messung 69, logischer PIN/PS 70 und Tester-PIN/PS 72. Auf der Grundlage der Daten aus der Testplandatei 63 beschreibt der Testplan 67 beispielsweise eine Reihenfolge, in der der Test angewendet werden sollte, wie etwa ein Kontakttest, dann ein Wechselstromtest und dann ein Gleichstromtest. Der Test 68 beschreibt beispielsweise die natur des Tests und zugehörige zeitgesteuerte Werte (Vektoren), die auf den DUT angewendet werden, d. h. Ereignisdaten, Zeitabläufe von Ereignisdaten, Abtastimpulsversatz etc.
Die Messung 69 definiert den Typ der Messung, wie etwa Wechselstrom oder Gleichstrom, und zugehörige Spannungs-/Stromwerte auf der Grundlage der Daten aus der Parameterdatei 64. Auf der Grundlage der Daten aus der Pindatei 65 beschreibt der logische PIN/PS die logische Pinzuweisung unter Verwendung einer Pinliste, die in der Middelware gespeichert ist, und gibt I/O-Pins (Eingabestimulus, Erwiderungsausgabe) und Stromzuführungspins (Vdd, GND) an. Auf der Grundlage der Daten aus der Buchsendatei 66 und dem logischen PIN/PS 70 identifiziert der Tester-PIN/PS 72 die physikalische Verbindung zwischen dem Bauelementpin und dem Testerkanal, d. h. welcher I/O-Pin mit welchem Testkanal verbunden ist und welcher Vdd/GND-Pin mit welchem Testerkanal verbunden ist.
Bei dem Beispiel von 6A erzeugt das Kernprogramm 59 Daten, Kernprogramm-FuncMeas 74 und Kernprogramm-PIN/PS 76 zum Vermitteln zwischen der Testerhardware 61 und der Middelware 58. Das Kernprogramm-FuncMeas 74 beschreibt die Messung des Spannungs- und Strompegels durch Interpretieren (Mapping) der Datenwerte bei der Messung 69 in tatsächliche Spannungs- und Strompegel. Das Kernprogramm-PIN/PS 76 beschreibt Anweisungen, um die entsprechenden Testerkanäle auf der Grundlage der Werte aus der Tester-PIN/PS 72 zu aktivieren/deaktivieren, so dass die Testerhardware auf der Grundlage dieser Anweisungen agiert.
Unter Verwendung dieser Struktur und dieses Datenflusses ist in 6B ein einfaches Beispiel des Mappings des vom Anwender angegebenen Tests auf physikalische Testerhardwarepins dargestellt. In 6B ist ein Test mit zwei Messungen ("Messung 1" und "Messung 2") gezeigt, während jede Messung mit zwei Pins (a0 und a1) in Zusammenhang steht. Dieses Beispiel veranschaulicht, dass ein Test mehrere Messungen umfassen kann und dass jede Messung mehrere Pins umfassen kann, an denen bestimmte Ereignisse angewendet und Antworten erhalten werden müssen. Das Mapping von Pins für diese zwei Messungen folgt ähnlich der Struktur, wie sie oben erwähnt wurde, d. h. von der GUI 53 zur Middelware 58 über den Anwendungsserver 57 und die Middelware 58 zum Kernprogramm 59 zur Ereignistesterhardware 61.
Es sollte beachtet werden, dass 6A der Einfachheit wegen lediglich eine Datei eines jeden Typs veranschaulicht, wie etwa eine Testplandatei und eine Pin-Map-Datei (für die Pin- und Stromzuführung). Bei einem tatsächlichen Testsystem gibt es jedoch viele Dateien eines jeden Typs, die einen kompletten Test konstituieren.
Dach Erhalt der Anweisung und der Daten, erzeugt die Testerhardware 61 die Testvektoren (beispielsweise Eingabestimulus und Stromzuführung) und wendet die Testvektoren auf den DUT an. Die verschiedenen Hardwarekomponenten sind in 7 veranschaulicht. Der Hostrechner 51 (der verschiedene Softwarekomponenten enthält, wie es oben erwähnt wurde) ist mit der Testersteuerung über eine PCI-Buskarte 110 verbunden. Bei dieser Implementierung wird der PCI-Bus verwendet obwohl ebenso irgendeine andere Schnittstelle verwendet werden kann. Eine Testersteuerung 107 befindet sich innerhalb des Testkopfgehäuses 100, das zudem eine Bauelementstromzuführungskarte (DPS-Karte) 106 und mehrere Pinkarten 105 enthält und von einer Stromzuführung 109 mit Energie versorgt wird. Eine Rückwandplatine 101 innerhalb des Testkopfgehäuses 100 liefert ein einfaches Verfahren, um die verschiedenen Pinkarten 105, die DPS-Karte 106 und die Testersteuerung 107 zu verbinden.
Darüber hinaus haben die verschiedenen Pinkarten 105 über Pogo-Pins 103 und eine Testhalterung (HiFix) 102, die verschiedene Anschlüsse und Pins aufweist, einen bidirektionalen Zugriff auf das Loadboard 104, auf dem der DUT platziert ist. Wenn ein Anwender eine Anweisung oder Daten appliziert, werden sie auf diese Weise durch die eingebettete Software am Hostrechner 51 interpretiert und entsprechende Nachrichten/Daten werden an die Testersteuerung 107 und Pinkarten 105 übergeben. Die Testersteuerung 107 und die Pinkarten 105 wenden diese Anweisungen/Daten über die Testhalterung 102, die Pogo-Pins 103 und das Loadboard 104 auf den DUT an (umgekehrt, wenn der Anwender Daten vom DUT empfängt).
Das Blockdiagramm der Pinkarte 105 ist in 8 veranschaulicht, wobei jede Pinkartenelektronikschaltung eine Ereignistestereinheit 78 konstituiert. Hier wird eine kurze Erläuterung der Testereinheit 78 gegeben. Die weiteren Details betreffend die Ereignistestereinheit sind in den US-Patentanmeldungen Nr. 09/406,300 und 09/259,401 angegeben, die sich im Besitz des gleichen Zessionars dieser Erfindung befinden.
In 8 sind ein Pineinheit-Schreibdekoder 114 und ein Prozessor (CPU) 115 mit der Testersteuerung (Testersteuerung 107 in 7) über einen Systembus 111 verbunden. Der Schreibdekoder wird beispielsweise verwendet, um Daten vom Hostrechner 51 zu einem (nicht gezeigten) Register in der Ereignistestereinheit 78 zu übertragen, um die Ereignistestereinheiten zu Pins des Bauelementprüflings zuzuordnen. Bei diesem Beispiel ist die CPU 115 in jeder Ereignistestereinheit 78 untergebracht und steuert die Operationen der Ereignistestereinheit einschließlich Erzeugung von Ereignissen (Testvektoren), Evaluierung von Ausgabesignalen aus dem Bauelementprüfling und Erfassung von Fehlerdaten.
Eine Adressfolgesteuerung 117 steuert die Adressen, die einem Fehlerspeicher 116 zugeführt werden, und einen Ereignisspeicher 118. Die Ereigniszeitablaufdaten werden an den Ereignisspeicher 118 aus dem Hostrechner 51 als ein Testprogramm überragen und darin gespeichert. Der Ereignisspeicher 118 speichert die Ereignisdaten, wie es oben erwähnt wurde, welche einen Ereignistyp und einen Zeitablauf für jedes Ereignis definieren. Beispielsweise werden die Ereigniszeitablaufdaten als zwei Typen von Daten gespeichert, von denen einer ganzzahlige Vielfache eines Referenztaktzyklus zeigt, während der andere Bruchteile des Referenztaktzyklus zeigt. Vorzugsweise werden die Ereignisdaten zur Verminderung des Speicherinhalts komprimiert, bevor sie im Ereignisspeicher 118 gespeichert werden. Die Ereignisdaten aus dem Ereignisspeicher werden von einer Dekomprimierungseinheit 120 dekomprimiert.
Nach Erhalt der Ereignisdaten aus der Dekomprimierungseinheit 120 erzeugt eine Zeitablaufzähl- und Skalierungslogik 121 Zeitlängendaten eines jeden Ereignisses durch Summieren der Ereigniszeitablaufdaten eines jeden Ereignisses. Durch Summieren der Ereigniszeitablaufdaten, die die Deltazeit (Zeitlänge ab dem vorherigen Ereignis) zeigen, drücken die sich ergebenden Zeitlängendaten den Zeitablauf eines jeden Ereignisses durch eine Zeitlänge (Verzögerungszeit) ab einem bestimmten Referenzpunkt aus. Eine Ereigniserzeugungseinheit 12 erzeugt ein Testmuster auf der Grundlage der Zeitlängendaten und liefert das Testmuster an den Bauelementprüfling (DUT) 19 über die Pinelektronik (Treiber und Komparator) und Testhalterung 102. Auf diese Weise wird ein einzelner Pin des Bauelementprüflings (DUT) 19 durch Evaluieren der Antwortausgabe daraus getestet.
Der Hauptvorteil des neuen Verfahrens erlaubt IC-Testen und -Fehlersuche in der gleichen Umgebung wie der IC-Design- und -simulationsumgebung. Es ist eine Architektur, die die IC-Simulations-VCD-Datei direkt verwendet, ohne die Notwendigkeit der Zyklisierung, von Testprogrammen, der Vektorkonversion und von Wavesets etc. Ein Parallelvergleich zwischen der neuen Testerarchitektur und dem herkömmlichen Testsystem wird in 9 gegeben, wo die Objekte oder Prozesse in Kästen beim Testsystem der vorliegenden Erfindung beseitigt sind. Wie es in 9 aufgelistet ist, beseitigt das neue System praktisch die gesamten Vektorverarbeitungsschritte und vereinfacht größtenteils die Dateianforderungen und den Mustervergleichsprozess. Das spart wiederum Zeit, Kosten und vermeidet Fehler bei der Vektorkonversion.
Obwohl die Erfindung hierin unter Bezugnahme auf das bevorzugte Ausführungsbeispiel beschrieben wurde, wird ein Fachmann leicht erkennen, dass verschiedene Modifikationen und Variationen gemacht werden können, ohne von der Wesensart und vom Umfang der vorliegenden Erfindung abzuweichen. Solche Modifikationen und Variationen werden als innerhalb des Geltungsbereichs und des Umfangs der beigefügten Ansprüche und ihrer Äquivalente befindlich betrachtet.
Zusammenfassung:
Ein ereignisbasiertes Testsystem zum Testen eines IC-Bauelementprüflings (DUT), der unter einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung entworfen wurde. Das ereignisbasierte Testsystem beinhaltet einen Ereignisspeicher zum Speichern von Ereignisdaten, die direkt aus der Simulation von Designdaten für ein intendiertes IC in einer EDA-Umgebung erlangt wurden, wobei die Ereignisdaten, um jedes Ereignis anzugeben, aus einem Zeitindex, der eine Zeitlänge ab einem festgelegten Punkt angibt, und Ereignistypdaten gebildet werden, die einen Typ der Veränderung bei einem Ereignis angeben, ferner eine Ereigniserzeugungseinheit zum Erzeugen von Testvektoren auf der Grundlage der Ereignisdaten aus dem Ereignisspeicher, wobei die Signalform eines jeden Vektors durch den Ereignistyp bestimmt wird und ein Zeitablauf der Signalform durch Akkumulieren des Zeitindex von vorherigen Ereignissen bestimmt wird, und Mittel zum Zuführen von Testvektoren zum DUT und Evaluieren von Antwortausgaben des DUT mit festgelegten Zeitabläufen.

Claims

Verfahren zum Testen eines IC-Bauelementprüflings (DUT), der unter einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung entworfen wurde, umfassend die folgenden Schritte: Speichern von Ereignisdaten, die direkt aus der Simulation von Designdaten für eine intendierte integrierte Schaltung in einer EDA-Umgebung erlangt wurden, in einem Ereignisspeicher, wobei die Ereignisdaten für jedes Ereignis aus Ereigniszeitablaufdaten, die eine Zeitlänge ab einem vorherigen Ereignis angeben, und Ereignistypdaten gebildet werden, die einen Ereignistyp angeben; Erzeugen von Testvektoren auf der Grundlage der Ereignisdaten aus dem Ereignisspeicher, wobei die Signalform eines jeden Vektors durch die Ereignistypdaten bestimmt wird und ein Zeitablauf der Signalform durch Akkumulieren der Zeitablaufdaten von vorherigen Ereignissen bestimmt wird; und Zuführen der Testvektoren zum DUT und Evaluieren von Antwortausgaben des DUT mit festgelegten Zeitabläufen.
Verfahren zum Testen eines IC-Bauelementprüflings (DUT) nach Anspruch 1, wobei die Ereignisdaten aus VCD (Werteveränderungsspeicherauszug von Verilog) erhalten werden, erzeugt durch Ausführen der Logiksimulation ohne Konversion oder Translation.
Verfahren zum Testen eines IC-Bauelementprüflings (DUT) nach Anspruch 1, wobei die Ereignisdaten aus zeitgesteuerten Ereigniswerten aus der Simulation erhalten werden, ohne Konversion oder Translation.
Ereignisbasiertes Testsystem zum Testen eines IC-Bauelementprüflings (DUT), der unter einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung entworfen wurde, umfassend: einen Ereignisspeicher zum Speichern von Ereignisdaten, die direkt aus der Simulation von Designdaten für eine intendierte integrierte Schaltung in der EDA-Umgebung erlangt wurden, wobei die Ereignisdaten, um jedes Ereignis anzugeben, aus einem Zeitindex, der eine Zeitlänge ab einem festgelegten Punkt angibt, und Ereignistypdaten gebildet werden, die einen Typ der Veränderung bei einem Ereignis angeben; eine Ereigniserzeugungseinheit zum Erzeugen von Testvektoren auf der Grundlage der Ereignisdaten aus dem Ereignisspeicher, wobei die Signalform eines jeden Vektors durch den Ereignistyp bestimmt wird und ein Zeitablauf der Signalform durch Akkumulieren des Zeitindex von vorherigen Ereignissen bestimmt wird; und Mittel zum Zuführen von Testvektoren zum DUT und Evaluieren von Antwortausgaben des DUT mit festgelegten Zeitabläufen.
Ereignisbasiertes Testsystem nach Anspruch 3, wobei die Ereignisdaten eines jeden Ereignisses komprimiert werden, bevor sie im Ereignisspeicher gespeichert werden, und wobei der Zeitindex aus einem ganzzahligen Vielfachen einer Referenztaktperiode (Ganzteildaten) und einem Bruchteil der Referenztaktperiode (Bruchteildaten) gebildet wird.
Ereignisbasiertes Testsystem nach Anspruch 3, wobei die Ereignisdaten eines jeden Ereignisses unkomprimiert sind, bevor sie im Ereignisspeicher gespeichert werden, und wobei der Zeitindex aus einem ganzzahligen Vielfachen einer Referenztaktperiode (Ganzteildaten) und einem Bruchteil der Referenztaktperiode (Bruchteildaten) gebildet wird.
Ereignisbasiertes Testsystem nach Anspruch 5, das darüber hinaus eine Dekomprimierungseinheit zum Reproduzieren der Ereignisdaten aus den komprimierten Ereignisdaten umfasst, die im Ereignisspeicher gespeichert wurden.
Ereignisbasiertes Testsystem nach Anspruch 4, wobei die Ereignisdaten für jedes Ereignis durch ein festgelegtes Längenwort ausgedrückt wird, wobei ein Teil des Worts dazu da ist, um den Ereignistyp anzugeben, und ein anderer Teil des Wortes dazu da ist, um den Zeitindex anzugeben.
Ereignisbasiertes Testsystem nach Anspruch 4, wobei der festgelegte Punkt zum Definieren der Zeitlänge in dem Zeitindex ein Ereignis unmittelbar vor einem momentanen Ereignis ist, so dass die Indexzeit eine Deltazeit zwischen zwei aufeinander folgenden Ereignissen ausdrückt.
Ereignisbasiertes Testsystem nach Anspruch 4, wobei der festgelegte Punkt zum Definieren der Zeitlänge in dem Zeitindex ein Operationsstartpunkt ist, so dass der Zeitindex eine absolute Zeitlänge ab dem festgelegten Punkt ausdrückt.
Ereignisbasiertes Testsystem nach Anspruch 9, wobei ein Wert der Deltazeit verändert wird, um das Ereignis während des Testens durch Verschieben seines Zeitablaufs, Hinzufügen eines neuen Ereignisses oder Löschen eines bestehenden Ereignisses zu bearbeiten.
Ereignisbasiertes Testsystem nach Anspruch 10, wobei ein Wert der absoluten Zeit verändert wird, um das Ereignis während des Testens durch Verschieben seines Zeitablaufs, Hinzufügen eines neuen Ereignisses oder Löschen eines bestehenden Ereignisses zu bearbeiten.
Ereignisbasiertes Testsystem nach Anspruch 11, wobei ein Zeitablauf eines Abtastimpulses durch Verändern der Deltazeit versetzt wird, für einen Typ von Abtastimpulsen, der durch den Ereignistyp gekennzeichnet wird, der in den Ereignisdaten angegeben wird.
Ereignisbasiertes Testsystem nach Anspruch 12, wobei ein Zeitablauf eines Abtastimpulses durch Verändern der absoluten Zeit versetzt wird, für einen Typ von Abtastimpulsen, der durch den Ereignistyp gekennzeichnet wird, der in den Ereignisdaten angegeben wird.
Ereignisbasiertes Testsystem nach Anspruch 8, wobei die Ereignisdaten, die aus der Simulation von Designdaten erlangt werden, zusätzlich zu 1, 0 und Z (hohe Impedanz) einen Ereignistyp "Ignorieren" beinhaltet und wobei das "Ignorieren" zu "Z" konvertiert wird, wodurch die Daten verringert werden, die den Ereignistyp beschreiben, bevor sie im Ereignisspeicher gespeichert werden.
Ereignisbasiertes Testsystem zum Testen eines IC-Bauelementprüflings (DUT), der unter einer elektronischen Entwurfsautomatisierungs-(EDA)-Umgebung entworfen wurde, umfassend: einen Hostrechner zum Steuern einer Gesamtoperation des Testsystems; Schnittstellensoftware zum Verbinden des Hostrechners mit dem ereignisbasierten Testsystems, wobei die Schnittstellensoftware eine graphische Benutzerschnittstelle (GUI) beinhaltet, die einen Ereignisbetrachter zum Überwachen und Bearbeiten von Ereignissen für das Testsystem darstellt; Dateninterpretations- und -managementsoftware zum Interpretieren und Managen von Daten aus dem Hostrechner über die Schnittstellensoftware; und Ereignistesterhardware, die eine Vielzahl von Ereignistestereinheiten zum Speichern von Ereignisdaten, die direkt aus der Logiksimulation von Designdaten erlangt werden, und zum Erzeugen von Testvektoren auf der Grundlage der Ereignisdaten und Zuführen der Testvektoren zum DUT und Evaluieren der Antwortausgaben des DUT mit festgelegten Zeitabläufen aufweist.
Ereignisbasiertes Testsystem nach Anspruch 16, wobei die Schnittstellensoftware und die Dateninterpretations- und -managementsoftware direkt oder über ein allgemeines Kommunikationsnetzwerk oder ein dediziertes Kommunikationsnetzwerk kommunizieren.
Ereignisbasiertes Testsystem nach Anspruch 16, wobei die Dateninterpretations- und -managementsoftware eine Middelware zur Datenverarbeitung und -interpretation und ein Kernprogramm zum Vermitteln von Datenwerten zwischen der Ereignistesterhardware und der Middelware beinhaltet.
Ereignisbasiertes Testsystem nach Anspruch 16, wobei die Middelware Information interpretiert, die durch einen Anwender angegeben wird, und Daten erzeugt, einschließlich Testtypen, eine Reihenfolge von Tests und Testparameter zum Zuführen der Daten zur Ereignistesterhardware über das Kernprogramm.
Ereignisbasiertes Testsystem nach Anspruch 16, wobei die Middelware Information interpretiert, die durch einen Anwender angegeben wird, und Daten erzeugt, einschließlich I/O-Pin- und -Stromzuführung des DUT zusätzlich zu den Testtypen, der Reihenfolge von Tests und Testparametern zum Zuführen der Daten zur Ereignistesterhardware über das Kernprogramm.
Ereignisbasiertes Testsystem nach Anspruch 16, wobei jede Ereignistestereinheit umfasst: einen Prozessor, der in Erwiderung auf Anweisungen vom Hostrechner steuert, um die Testvektoren zu erzeugen und ein Ausgabesignal des Bauelementprüflings zu evaluieren; einen Ereignisspeicher zum Speichern der Ereignisdaten für jedes Ereignis; eine Adressfolgesteuerung zum Liefern von Adressdaten an den Ereignisspeicher zum Lesen der Ereignisdaten daraus; eine Zeitablaufzähllogik zum Erzeugen von Ereigniszeitabläufen auf der Grundlage der Ereignisdaten aus dem Ereignisspeicher; und einen Ereignisgenerator zum Erzeugen der Testvektoren auf der Grundlage der Ereigniszeitabläufe aus der Zeitablaufzähllogik und Zuführen des Testmusters an einen entsprechenden Pin des DUT.