DE10392497T5

DE10392497T5 - Herstellungsverfahren und Herstellungsvorrichtung zum Vermeiden eines Prototypen-Aufschubs bei der ASIC/SOC-Herstellung

Info

Publication number: DE10392497T5
Application number: DE10392497T
Authority: DE
Inventors: Rochit Santa Clara Rajsuman; Hiroaki Santa Clara Yamoto
Original assignee: Advantest Corp
Current assignee: Advantest Corp
Priority date: 2002-04-11
Filing date: 2003-04-11
Publication date: 2005-02-17
Also published as: US20030217343A1; JP2005522859A; CN100341110C; KR20040101421A; WO2003085706A1; KR100936855B1; JP4508657B2; CN1647248A; US7178115B2

Abstract

LSI-Herstellungsverfahren zum Vermeiden eines Prototypen-Aufschubs mit den folgenden Schritten:
Entwerfen eines LSIs unter einer EDA-Umgebung (Elektronikentwurfs-Automatisierungsumgebung) zum Erzeugen von Entwurfsdaten für einen entworfenen LSI,
Ausführen einer Logiksimulation an einem Vorrichtungsmodell des LSI-Entwurfs in der EDA-Umgebung unter Verwendung eines Testfelds und Erzeugen einer Testvektordatei von ereignisbasierten Testvektoren als Ergebnis der Logiksimulation,
Erzeugen von testbezogenen Datendateien unter Verwendung der Entwurfsdaten und ereignisbasierten Testvektoren,
Erzeugen eines Ereignistestersimulators, der eine Operation eines Ereignistesters simuliert,
Überprüfen der testbezogenen Datendateien und der ereignisbasierten Testvektoren durch den Ereignistestersimulator,
Erzeugen eines LSI-Prototypen durch einen Hersteller unter Verwendung der Entwurfsdaten und
Testen des LSI-Prototypen durch den Ereignistester unter Verwendung der ereignisbasierten Testvektoren und Suchen von Fehlern durch Ereigniseditierungen und Rückführen der Testergebnisse zu Entwicklungsingenieuren und zum Hersteller.

Description

Gebiet der Erfindung
Diese Erfindung betrifft ein Verfahren und eine Vorrichtung zur Herstellung hochintegrierter Schaltkreise (LSIs) und insbesondere ein Verfahren zur Herstellung von LSIs unter Verwendung eines ereignisbasierten IC-Testsystems, bei dem Testdaten in einer Ereignisform verwendet werden, die eine direkte Verwendung der in einer Elektronikentwurfs-Automatisierungsumgebung (EDA-Umgebung) erzeugten Entwurfssimulationsdaten ermöglicht, um dadurch einen Prototypen-Aufschub bei der LSI-Herstellung zu vermeiden.
Hintergrund der Erfindung
Diese Anmeldung beschreibt einen modifizierten industriellen Prozeß für die LSI-Herstellung. Eines der Hauptprobleme, die heute bei der Herstellung von LSIs, wie ASICs (anwendungsspezifischen integrierten Schaltkreisen) oder SOCs (System auf einem Chip) auftreten, ist ein Stillstand des Herstellungsprozesses beim Prototypentest. Mehr als 50 % der von der Prototypen-Herstellungsstufe ausgegebenen ICs bestehen den Test nicht, woraus sich ein Aussetzen des Herstellungsprozesses bis zur nächsten Stufe (beispielsweise Anwendungsentwicklung und Massenproduktion) ergibt. In Zusammenhang mit dieser Anmeldung wird diese Situation als Prototypen-Aufschub bezeichnet.
Wenn das erste Silicium (LSI-Prototyp) von der Herstellung ausgegeben wird, weist es in den meisten Fällen bei der Prototypenbeurteilung einige Fehler auf. Die Ursachen dieser Fehler variieren, und es kann sich um Fehler bei der Vektorübersetzung (Testdatenkonvertierung) oder Fehler in einem Testprogramm oder sogar Herstellungsdefekte handeln. In einer großen Anzahl der Fälle ist die Fehlerursache nicht leicht identifizierbar, und das Silicium (der LSI-Prototyp) wird daher einem Prototypen-Aufschub unterzogen. Vor der Identifikation und Behebung der Ursache kann das Silicium nicht für die Anwendungsentwicklung verwendet werden und nicht anschließend in die Massenproduktion übergehen.
Der Hauptfaktor hinter diesem Problem besteht darin, daß sich die Entwurfsumgebung bzw. Entwicklungsumgebung von der Testengineeringumgebung unterscheidet und sich die Fehlerursache daher nicht leicht identifizieren läßt. Wenn ein Chip ausgegeben wird (die Entwurfsdaten des Chips werden vom Entwicklungsingenieur freigegeben), muß ein Testingenieur die Entwurfssimulationsvektoren zur Verwendung in der Testengineeringumgebung konvertieren. Die Testengineeringumgebung liegt entsprechend den Zeitsätzen und Wellengruppen des Testers gewöhnlich in einem zyklischen Format vor. Der Testingenieur übersetzt weiterhin die Vektoren in ein anderes Format, wie STIL (Standard-Testschnittstellensprache) oder WGL (Wellenform-Erzeugungssprache), das für ein bestimmtes Testsystem einzigartig ist, und erzeugt ein Testprogramm, das fast keine Ähnlichkeit mit der ursprünglichen Simulation hat. Wenn daher das erste Silicium (der LSI-Chipprototyp) einen Fehler (einen fehlerhaften Vektor in den Testvektoren) aufweist, ist es recht beschwerlich, die Fehlerursache zu bestimmen.
Die Halbleiterindustrie weist sehr kostspielige und umfangreiche Produktionsanlagen auf, und das Produktionsvolumen jeder LSI-Vorrichtung ist groß. Dementsprechend ist eine solche durch den Prototypen-Aufschub hervorgerufene Verzögerung für Anwendungsentwickler, das Entwicklungshaus (ASIC-Haus oder Entwicklungszentrum) sowie für die Siliciumzüchtungseinrichtung (Halbleiterherstellung) sehr kostspielig. Daher besteht in der Industrie ein dringender Bedarf an einem neuen Halbleiter-Herstellungsprozeß und einem neuen Testsystem, welche in der IC-Entwicklungsumgebung arbeiten und die gesamte Komplexität bei der Testdatenkonvertierung in eine zyklische Form, wie es bei heutigen Testsystemen erfolgt, beseitigen.
Zusammenfassung der Erfindung
Eine Aufgabe der vorliegenden Erfindung besteht dementsprechend darin, ein neues Halbleiter-Herstellungsverfahren bereitzustellen, das einen neuen Typ eines Halbleiter-IC-Testsystems aufweist, der in der Lage ist, die Prototypen-Aufschubprobleme zu vermeiden und in einer nahtlosen Wechselbeziehung mit der Entwicklungsumgebung und der Testengineeringumgebung steht.
Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, ein neues Halbleiter-Herstellungsverfahren bereitzustellen, das ein neues Halbleiter-IC-Testsystem (einen Ereignistester) aufweist, das in der Lage ist, die in einer Elektronikentwurfs-Automatisierungsumgebung (EDA-Umgebung) erzeugten Entwurfssimulationsdaten direkt zu verwenden.
Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, ein neues Halbleiter-Herstellungsverfahren bereitzustellen, das ein neues Halbleiter-IC-Testsystem (einen Ereignistester) in einer Testengineeringumgebung und einen Ereignistestersimulator in einer EDA-Umgebung aufweist, wodurch es unnötig wird, Testvektoren und Testprogramme in der Testengineeringumgebung zu erzeugen.
Die vorliegende Erfindung schlägt einen neuen Herstellungsprozeß vor, der ein ereignisbasiertes Testsystem (einen Ereignistester) für die LSI-Herstellung aufweist, wobei kein Prototypen-Aufschub auftritt. Dieses Verfahren weist die folgenden Schritte auf: Entwerfen eines LSIs unter einer EDA-Umgebung (Elektronikentwurfs-Automatisierungsumgebung) zum Erzeugen von Entwurfsdaten für einen entworfenen LSI, Ausführen einer Logiksimulation an einem Vorrichtungsmodell des LSI-Entwurfs in der EDA-Umgebung unter Verwendung eines Testfelds und Erzeugen einer Testvektordatei von ereignisbasierten Testvektoren als Ergebnis der Logiksimulation, Erzeugen von Testdatendateien unter Verwendung der Entwurfsdaten und des Testfeldes durch Betreiben eines Ereignistestsimulators, Erzeugen eines LSI-Prototypen durch einen Hersteller unter Verwendung der Entwurfsdaten und Testen des LSI-Prototypen durch den Ereignistester unter Verwendung der Testvektordatei und der Simulationsdatei und Rückführen der Testergebnisse zu der EDA-Umgebung oder zum Hersteller.
Gemäß der vorliegenden Erfindung ermöglichen das Verfahren und die Architektur des Testsystems das Testen von ICs und das Suchen von Fehlern in diesen, ohne daß von der Umgebung abgewichen wird, in der der IC entwickelt wurde. Die traditionellen IC-Testsysteme erfordern eine Konvertierung der Entwurfssimulationsdaten in eine zyklische Form in der Art des WGL- oder STIL-Formats. Das neue Verfahren und die neue Architektur vermeiden eine solche Konvertierung und verwenden die Entwurfssimulationsdaten "unverändert". Demgemäß ermöglichen das Verfahren und die Vorrichtung gemäß der vorliegenden Erfindung das Testen in einer zur Entwurfssimulationsumgebung identischen Umgebung, wodurch der Prototypen-Aufschub vermieden wird. Der neue Halbleiter-Produktionsprozeß weist den Ereignistester in der Testengineeringumgebung und den Ereignistestersimulator in der EDA-Umgebung auf, wodurch es unnötig wird, die Testvektoren und Testprogramme in der Testengineeringumgebung zu erzeugen, wodurch Entwicklungszeit gespart wird und die Gesamtkosten bei der LSI-Herstellung reduziert werden.
Kurzbeschreibung der Zeichnung
Es zeigen:
1A ein schematisches Diagramm einer herkömmlichen Testsystemarchitektur und 1B ein schematisches Diagramm, in dem eine neue Testsystemarchitektur zur Verwendung beim Herstellungsprozeß gemäß der vorliegenden Erfindung dargestellt ist,
2 ein Diagramm, in dem ein Konzept eines gesamten LSI-Herstellungsprozesses gemäß der vorliegenden Erfindung unter Verwendung eines Ereignistesters in der Testengineeringumgebung und eines Ereignistestersimulators in der Entwicklungsumgebung dargestellt ist,
3 ein Diagramm, in dem ein LSI-Herstellungsprozeß unter Verwendung eines herkömmlichen Testsystems, in dem die Datenformate zwischen der Entwicklungsumgebung und einem Test getrennt sind, dargestellt ist,
4 ein Diagramm, in dem ein Datenkonvertierungsprozeß zwischen der Datenstruktur der Entwicklungsumgebung und den beim herkömmlichen Testsystem verwendeten Testdaten dargestellt ist,
5 ein Blockdiagramm, in dem ein Beispiel der Struktur im ereignisbasierten Testsystem (Ereignistester) zur Verwendung mit dem Produktionsprozeß der vorliegenden Erfindung dargestellt ist,
6 ein Diagramm zum Vergleichen eines Beispiels von Datenstrukturen, die in dem zyklusbasierten Testsystem (zyklischen Tester) und dem ereignisbasierten Testsystem (Ereignistester) verwendet werden,
7 ein Diagramm, in dem ein Beispiel eines Bilds auf einem Bildschirm auf der Grundlage einer graphischen Benutzerschnittstelle des ereignisbasierten Testsystems gemäß der vorliegenden Erfindung dargestellt ist,
8 ein Diagramm, in dem ein Beispiel des LSI-Produktionsprozesses gemäß der vorliegenden Erfindung unter Verwendung des ereignisbasierten Testsystems dargestellt ist, wobei Datenformate zwischen der Entwicklungsumgebung und der Testumgebung vollständig übereinstimmen,
9 ein Diagramm, in dem ein weiteres Beispiel des LSI-Herstellungsprozesses gemäß der vorliegenden Erfindung unter Verwendung des ereignisbasierten Testsystems dargestellt ist, wobei in dem Prozeß keine Datenkonvertierung erforderlich ist,
10 ein Zustandsdiagramm, in dem ein Beispiel eines Halbleiter-Herstellungsprozesses in der herkömmlichen Technologie dargestellt ist, wobei der Prototypen-Aufschub auftritt,
11 ein Zustandsdiagramm, in dem ein Beispiel eines Halbleiter-Herstellungsprozesses gemäß der vorliegenden Erfindung dargestellt ist, wobei der Prototypen-Aufschub vermieden ist, und
12 ein Flußdiagramm, in dem ein Beispiel des Halbleiter-Herstellungsprozesses gemäß der vorliegenden Erfindung dargestellt ist, wobei ein Ereignistester in die Testengineeringumgebung aufgenommen ist und ein Ereignistestersimulator in die Entwicklungsumgebung aufgenommen ist.
Detaillierte Beschreibung der Erfindung
Die vorliegende Erfindung wird nun in weiteren Einzelheiten mit Bezug auf die anliegende Zeichnung beschrieben. Die vorliegende Erfindung schlägt einen neuen LSI-Herstellungsprozeß vor, der ein ereignisbasiertes Testsystem (einen Ereignistester) für die LSI-Herstellung aufweist, wobei kein Prototypen-Aufschub auftritt. Dieses Verfahren beruht auf einer neuen Technologie, einer neuen Einrichtung und grundsätzlichen Änderungen an dem bestehenden Prozeß. Das Konzept und die Architektur der neuen Einrichtung, des darauf beruhenden Halbleiter-Herstellungsprozesses und des verwendeten spezifischen Datenformats werden in dieser Anmeldung beschrieben.
Bei dem Herstellungsprozeß gemäß der vorliegenden Erfindung wird an Stelle des herkömmlichen zyklusbasierten Test systems (zyklischen Testers) ein ereignisbasiertes Testsystem (Ereignistester) zum Testen des Prototyp-LSI-Chips in der Art eines ASIC oder SOC verwendet. In der Entwicklungsumgebung (Entwicklungshaus) erzeugt ein Entwicklungsingenieur verschiedene Dateien für das Implementieren des Tests auf dem Chip durch den Ereignistester. Diese Dateien schließen Testmusterdaten, Testparameterdaten, Testerkanaldaten usw. ein, deren Korrektheit vor der Herstellung des Prototyps auf der Grundlage der Entwurfs- und der Simulationsdaten des Chips durch einen Ereignistestersimulator geprüft wird.
In der Entwurfsstufe in einer EDA-Umgebung (Elektronikentwurfs-Automatisierungsumgebung) wird der LSI-Entwurf wiederholt simuliert, bis er den Entwurfsspezifikationen entspricht. Während dieses Prozesses läßt der Entwicklungsingenieur zahlreiche Simulationszyklen unter Verwendung einer Hardwarebeschreibungssprache, wie Verilog oder VHDL, ablaufen, um einen Satz von Testvektoren zu erzeugen. Der Entwicklungsingenieur inspiziert die Ergebnisse dieser Simulationen unter Verwendung von EDA-Werkzeugen, wie SignalScan von Cadence, Kalifornien, die es ihm ermöglichen, die Wellenformen und Zeitabläufe zu betrachten. Demgemäß sollte das wünschenswerte Verfahren zum Prüfen des ersten Siliciums die ursprünglichen Verilog/VHDL-Vektoren "unverändert" ohne Übersetzung verwenden, und das Testen des LSIs sollte in der Entwicklungsumgebung stattfinden.
Die Schwierigkeit beim Erhalten einer Lösung, die das Testen in der Entwicklungsumgebung ermöglicht, besteht in der heutigen Testerarchitektur (zyklischer Tester), und insbesondere in den Zeitsätzen und Wellengruppen, die es erfordern, daß Vektoren entsprechend dem Tester zyklisch angeordnet und reformatiert werden. Zur Verwendung der Entwurfssimulationsdaten benötigen die traditionellen IC-Testsysteme eine Konvertierung von Entwurfssimulationsdaten in eine zyklische Form in der Art des WGL-(Wellenform-Erzeugungssprache)- oder des STIL-(Standard-Testschnittstellensprache)-Formats.
Demgemäß ist zum Erhalten einer gewünschten Lösung eine vollständige Änderung der Umgebung und des Prozesses sowie der Architektur des Testers erforderlich. Die Lösung benötigt eine grundsätzliche Änderung, die das Testen vereinfacht, statt den bereits komplizierten Prozeß noch komplexer zu machen. Das Problem sollte durch Beseitigen des Vektorübersetzungsprozesses gelöst werden, so daß keine Möglichkeit eines Prototypen-Aufschubs infolge der Testvektoren besteht.
Die Grundanforderungen zum Betreiben eines Testers in der Entwurfssimulationsumgebung sind: (1) Die Architektur des Testers sollte Änderungen in den Signalwerten unterstützen, die bei den Ereignissen identisch sind, wie bei der Entwurfssimulation, wie beispielsweise bei Verilog/VHDL beobachtet wird, und (2) Ereignisse an jedem Stift des Testers sollten ähnlich der Logiksimulation in der Entwicklungsumgebung unabhängig behandelt werden, statt sie entsprechend Wellengruppen und Zeitsätzen zyklisch zu machen.
Die Erfinder dieser Erfindung haben diese Möglichkeit und den Mechanismus zum Unterstützen der Entwicklungsumgebung für den Test untersucht und grundsätzliche Änderungen an der Architektur des Testers vorgenommen. 1A zeigt die herkömmliche zyklische Architektur des Testers, und 1B zeigt die Architektur des Ereignistesters zur Verwendung beim Herstellungsprozeß gemäß der vorliegenden Erfindung. Bei den herkömmlichen Halbleiter-Testsystemen werden die Testmuster oder Vektoren (Eingangsstimulationen, Strobe-Signale usw.) auf der Grundlage der in einer zyklischen Form beschriebenen Testdaten erzeugt. Wie vorstehend erwähnt wurde, wird ein solches traditionelles Testsystem manchmal als ein zyklusbasiertes Testsystem oder ein zyklischer Tester beschrieben, wobei verschiedene Daten zum Erzeugen der Eingangsstimulationen und Strobe-Signale in bezug auf entsprechende Testzyklen (Testerraten oder Zeitsätze) und Wellenformsegmente definiert sind.
Wie in 1A dargestellt ist, ist der zyklische Tester durch einen Ratengenerator 13 zum Erzeugen von Testerraten (Testzyklen), einen Musterspeicher 14 zum Speichern von Musterdaten, einen Taktspeicher 15 zum Speichern von Taktdaten, einen Wellenformspeicher 16 zum Speichern von Wellenformdaten (Aktionsdaten), einen Taktgenerator 17 zum Erzeugen von Taktsignalen auf der Grundlage der Taktdaten, einen Wellenformformatierer 18 zum Erzeugen eines Testmusters auf der Grundlage der Taktsignale, Musterdaten und Wellenformdaten und einen Treiber 19 zum Anwenden der Testvektoren auf eine getestete Vorrichtung (DUT) konfiguriert.
Wie in 1B dargestellt ist, ist das ereignisbasierte Testsystem (der Ereignistester) durch einen Ereignisspeicher 20 zum Speichern von Ereignisdaten (zeitlich festgelegten Daten), einen Ereignisgenerator 21 zum Erzeugen von Ereignissen auf der Grundlage der Ereignisdaten und einen Treiber 22 zum Anwenden der Testvektoren auf die DUT konfiguriert. Weitere Einzelheiten der Architektur und des Konzepts des ereignisbasierten Testsystems wurden in US-A-6 360 343 und US-A-6 532 561 und in der am 20. Mai 2002 eingereichten US-Patentanmeldung 10/150 777, die der Erwerber der vorliegenden Erfindung besitzt, dargelegt, wobei auf diese alle hiermit verwiesen sei.
Der Ratengenerator 13, der Taktgenerator 17, der Musterspeicher 14, der Wellenformspeicher 16 und der Taktspeicher 15 des zyklischen Testers sind fortgelassen, und es werden stattdessen der Ereignisspeicher 20 und die Ereignisgeneratoreinheiten 21 in dem Ereignistester verwendet. Der Ereignisspeicher 20 enthält die bei der Verilog/VHDL-Simulation beobachteten Ereignisse. Der Ereignisgenerator 21 wandelt diese Ereignisse unter Verwendung der in der Verilog/VHDL-Simulation aufgezeichneten zugeordneten Zeitinformationen in Aktionen (zum Anwenden von Testvektoren) um. Durch den Treiber 22 werden diese Aktionen auf die DUT angewendet, und das Ansprechen der DUT wird mit den IC-Simulationsdaten verglichen, um einen Fehler festzustellen.
In dem Ereignistester macht es die Architektur durch Beseitigen der Raten- und Taktgeneratoren, des Muster- speichers, des Wellenformspeichers und des Taktspeichers im wesentlichen unnötig, die Vektoren zyklisch zu machen und sie in andere Formate, wie WGL oder STIL, zu übersetzen. Der Ereignisspeicher 20 in 1B speichert Ereignisse, wenn sie bei der IC-Simulation aufgezeichnet werden. Demgemäß wird jeder Testvektor (jede Aktion) durch Treiben eines Ereignisses (die Daten "0" oder "1") mit seinem Takt. Bei dem zyklischen Tester aus 1A wird jeder Testvektor durch Treiben einer spezifizierten Wellenform (Aktion) auf der Grundlage von Musterdaten ("0" oder "1") bei einer durch einen Taktsatz (Testzyklus) spezifizierten Takt erzeugt. Demgemäß erreicht der Ereignistester das Ziel, daß der Zyklisierungs- und Vektorübersetzungsprozeß aus dem Testen entfernt werden sollte und daß die Testumgebung der IC-Entwicklungsumgebung gleichen sollte.
2 ist ein Diagramm, in dem ein Konzept eines gesamten LSI-Produktionsprozesses gemäß der vorliegenden Erfindung dargestellt ist, wobei ein Ereignistester 30 in der Testengineeringumgebung und ein Ereignistestersimulator 27 in der Entwicklungsumgebung (EDA-Umgebung) verwendet werden. Bei der Bandausgabe werden die durch die EDA-Umgebung erzeugten Entwurfsdaten für die Prototypenherstellung an den Siliciumprozeß übergeben. Die Testvektoren für den Ereignistester können direkt von einer VCD-Datei (Werteänderungsauszugs-Datei) erzeugt werden, die durch die Logiksimulation in der EDA-Umgebung erzeugt wurde. Die Testvektoren und verschiedenen testbezogenen Daten werden durch den Ereignistestersimulator 27 geprüft, bevor der Siliciumprototyp hergestellt wird.
Weil das Herstellungsverfahren gemäß der vorliegenden Erfindung den Ereignistestersimulator ähnlich der heutigen EDA-Umgebung aufweist, werden alle testbezogenen Daten einschließlich der Testvektoren zur Verwendung mit dem Ereignistester geprüft. Diese Daten sind für den jeweiligen zu testenden LSI und den in den Produktionsprozeß aufgenommenen Ereignistester einzigartig. Mit anderen Worten besteht die Hauptidee der vorliegenden Erfindung darin, vor der Herstellung in Silicium alles durch den Ereignistestersimulator zu prüfen. Wenn ein wirklicher LSI auf dem Ereignistester getestet wird, treten demgemäß keine datenbezogenen Fehler auf.
Falls dementsprechend der wirkliche Test einen Fehler zeigt, kann er nur entweder ein Taktfehler oder ein physikalischer Defekt bei der Herstellung sein. Wenn es sich um einen Herstellungsdefekt handelt, kann der LSI der Fehleranalyse unterzogen werden, um festzustellen, welcher Typ eines physikalischen Defekts aufgetreten ist. Falls es sich um einen Taktfehler handelt, kann er durch den Ereignistester unter Verwendung verschiedener Funktionen des Ereignistesters, die nachstehend beschrieben werden, gesucht werden. Weitere Einzelheiten dieses Herstellungsprozesses aus 2 werden später beschrieben, nachdem anhand der 3–6 die Probleme, die beim herkömmlichen zyklusbasierten Testsystem (zyklischen Tester) auftreten, und die Vorteile des ereignisbasierten Testsystems (Ereignistesters) beschrieben wurden.
3 zeigt einen LSI-Herstellungsprozeß unter Verwendung des herkömmlichen zyklusbasierten Testsystems (zyklischen Testers), wobei die Datenformate zwischen der Entwicklungsumgebung und der Testumgebung getrennt sind. 3 zeigt, daß die Logiksimulationsdaten nicht ohne eine Datenkonvertierung (Vektorübersetzung) verwendet werden können, weil das beim zyklischen Tester verwendete Datenformat (ATE-Format) und das sich aus der Entwurfsstufe ergebende Datenformat (EDA-Format) voneinander verschieden sind. Überdies treten bei dem zyklischen Tester verschiedene Beschränkungen auf, die es sehr schwierig machen, die Logiksimulationsdaten richtig und ausreichend in die Testdaten für den zyklischen Tester umzuwandeln oder umgekehrt.
Genauer gesagt, entwirft der Entwickler den LSI in dem Beispiel aus 3 auf der Grundlage der Spezifikation 41 des vorgesehenen LSIs in der Art eines ASICs oder eines SOCs in einer Entwurfsphase 42. Wie vorstehend erwähnt wurde, wird der LSI-Entwurf wiederholt simuliert, bevor er die Entwurfsspezifikationen erfüllt. Infolge dieses Logiksimulationsprozesses wird die Teststimulationsdatei (das Testfeld) 45 erzeugt, die beispielsweise eine VCD-Datei (Werteänderungsauszugs-Datei) von Verilog ist. Das Testfeld 45 liegt im EDA-Format vor, das das vorstehend erwähnte Ereignisformat ist.
Nach der Entwurfsphase 42 wird eine Entwurfsdatendatei 46 erzeugt, die typischerweise RTL-Daten (Registerübertragungsniveau-Daten), Netzlistendaten und Maskendaten enthält. Auf der Grundlage der Daten in der Entwurfsdatendatei 46 wird ein LSI-Prototyp 47 in einer Herstellungsstufe 43 erzeugt. In einer Testphase 44 wird der LSI-Prototyp 47 durch eine ATE (automatische Testeinrichtung) getestet, die typischerweise ein vorstehend erwähntes herkömmliches zyklusbasiertes Testsystem (zyklischer Tester) ist. Für das Testen des LSI-Prototyps 47 durch den zyklischen Tester wird eine Testdatendatei 48 zum Erzeugen von Testvektoren erzeugt.
Wie vorstehend erwähnt wurde, liegen die beim herkömmlichen Testsystem verwendeten Testdaten im zyklischen Format (ATE-Format) vor, das keine Ähnlichkeit mit dem EDA-Format hat. Daher ist es erforderlich, das Testfeld (EDA-formatierte Daten) in das ATE-Format zu konvertieren, das für den zyklischen Tester akzeptierbar ist. Diese Anforderung ruft folgende Probleme hervor: (1) Die Vektorkonvertierung nimmt umfangreiche Zeit-, Server- und Plattenkapazitäten in Anspruch und ist sehr fehleranfällig, (2) die Zyklisierung von Vektoren macht Vorrichtungen mit mehreren Taktbereichen untestbar und (3) infolge einer begrenzten Anzahl von Betriebsmitteln, wie Zeitsätzen, Wellenformgruppen, Taktgeneratoren usw. in dem zyklischen Tester ergeben sich Beschränkungen für den Tester, wobei Beispiele dieser Beschränkungen in einem Beschränkungskästchen 49 angegeben sind. Es ist auf diese Weise unmöglich, das Testfeld vollständig in das ATE-Format zu konvertieren. Wegen dieser Inkompatibilität kann der Prototyp nicht vollständig getestet werden, wodurch ein durch ein Stoppkästchen 50 angegebenes Prototypen-Aufschubproblem hervorgerufen wird.
4 zeigt einen Datenkonvertierungsprozeß (Vektorübersetzungsprozeß) zwischen der Datenstruktur der Entwicklungsumgebung und der in der Testengineeringumgebung verwendeten Datenstruktur. Wie vorstehend erwähnt wurde, müssen in der EDA-Umgebung erzeugte Stimulationsdaten in das zyklische Format umgewandelt werden, um das zyklusbasierte Testmuster durch das herkömmliche Testsystem zu erzeugen. Demgemäß konvertiert der Prozeß aus 4 die Teststimulationsdatei 45 in die Testvektordatei 48 aus 3.
In dem Beispiel aus 4 werden die Entwurfsprüfungsdaten (das Testfeld) des in der EDA-Umgebung entworfenen LSIs in einer Stimulationsdatendatei (VCD-Datei) 56 und einer Stiftdatendatei 57 gespeichert. Die Daten von der Stimulationsdatendatei 56, die Ein-/Ausgabewerte betreffen, und die Daten von der Stiftdatendatei 57, die die Stiftanordnung des LSIs betreffen, werden an eine Konvertierungssoftware 55 übergeben, wodurch sie in die zyklusbasierten Daten konvertiert werden. Weiterhin werden Daten von den Datendateien 58, 59 und 60, die verschiedene Spezifikationen des Testsystems beschreiben und Testparameter, die die Tester-Stiftanordnung usw. betreffen, an die Konvertierungssoftware 55 übergeben und dadurch in die zyklusbasierten Daten konvertiert.
Durch diese Prozedur werden eine Hauptdatei (Testplandatei) 61 und eine Testmusterdatei 62 erzeugt. Hierbei weist die Hauptdatei 61 die Taktdaten auf, welche Testmusterwellenformen, Testzyklen und Takte der Wellenformen beschreiben. Die Musterdatei 62 weist Testvektoren auf. Die vorstehend erwähnten konvertierten Daten werden weiter durch jeweilige Compiler in Objektcodes konvertiert, wodurch Objektcodedateien 64 und 66 gebildet werden. Die Daten in den Objektcodedateien 64 und 66 werden über Ladeeinheiten in entsprechende Speicher (Wellenform-, Takt- und Muster speicher) im Muster- und Taktgenerator 68 in der Hardware des Testers übertragen.
Die in den Wellenform-, Takt- und Musterspeichern in dem zyklischen Tester gespeicherten Daten haben, wie vorstehend erwähnt wurde, eine zyklusbasierte Datenstruktur. Wenn der LSI-Prototyp getestet wird, werden die Daten aus diesen Speichern ausgelesen, wodurch ein Testmuster erzeugt wird. Das Testmuster wird über Stiftelektronik (nicht dargestellt) auf den LSI angewendet. Die Testergebnisdaten werden in einer Datendatei 67 in der Art eines Fehlerdatenspeichers reorganisiert, um Eingangs- und Ausgangswellenformen zu zeigen. Die Daten von der Datei 67 werden durch ein Analysewerkzeug 54 bei der Fehleranalyse verwendet. Das Ergebnis der Fehleranalyse kann als das Ergebnis der EDA-Werkzeuge 53 in der EDA-Umgebung berechnet werden, das Fehleranalyseergebnis kann jedoch wegen der unterschiedlichen Datenstruktur dort nicht direkt verwendet werden.
Wie vorstehend beschrieben wurde, müssen für die Datenkonvertierung verschiedene Konvertierungsprozesse verwendet werden, weil die von der EDA-Entwicklungsumgebung erhaltenen Daten und die in dem Halbleiter-Testsystem verwendeten Daten unterschiedliche Strukturen aufweisen. Insbesondere sind unterschiedliche Konvertierungssoftware in einer gepunkteten Linie (Tester-Software) für die Datenkonvertierung in dem zyklusbasierten Testsystem erforderlich. All diese Software ist in dem Ereignistester gemäß der vorliegenden Erfindung unnötig.
Wie vorstehend erwähnt wurde, wird das Herstellungsverfahren gemäß der vorliegenden Erfindung durch Aufnehmen des Ereignistesters in die Testumgebung und eines Ereignistestersimulators in die EDA-Umgebung implementiert. Wie vorstehend erwähnt wurde, wurde das Konzept des ereignisbasierten Testsystems in US-A-6 360 343 und US-A-6 532 561 und in der US-Patentanmeldung 10/150 777, die der Erwerber der vorliegenden Erfindung besitzt, eingeführt, wobei auf beide hiermit verwiesen sei. Bevor das LSI-Herstellungs verfahren gemäß der vorliegenden Erfindung erklärt wird, wird kurz ein ereignisbasiertes Testsystem mit Bezug auf die 5 und 6 beschrieben.
5 ist ein schematisches Blockdiagramm, in dem ein Beispiel der Grundstruktur eines ereignisbasierten Testsystems (Ereignistesters) zum Implementieren des Herstellungs- und Testverfahrens gemäß der vorliegenden Erfindung dargestellt ist. Der Ereignistester weist einen Hauptcomputer 72 und eine Busschnittstelle 73 auf, die beide mit einem Systembus 74, einem internen Bus 75, einer Adreßsteuerlogik 78, einem Fehlerspeicher 77, einem Ereignisspeicher 79, einer Ereignissummier- und -skalierlogik 82, einem Ereignisgenerator 84 und einer Stiftelektronik 86 verbunden sind. Der Ereignistester beurteilt eine getestete IC-Vorrichtung (DUT) 88, die mit der Stiftelektronik 86 verbunden ist.
Ein Beispiel des Hauptcomputers 72 ist eine Arbeitsstation mit einem UNIX-, Windows- oder Linux-Betriebssystem. Der Hauptcomputer 72 funktioniert als eine Benutzerschnittstelle in der Art der in 7 dargestellten graphischen Benutzerschnittstelle (GUI), um es einem Benutzer zu ermöglichen, Start- und Stoppoperationen des Tests vorzuschreiben, ein Testprogramm und andere Testbedingungen zu laden, Ereignisse zu überwachen und zu editieren oder eine Testergebnisanalyse auszuführen. Der Hauptcomputer 72 ist über den Systembus 74 und die Busschnittstelle 73 mit einer Testsystemhardware verbunden. Wenngleich dies nicht dargestellt ist, ist der Hauptcomputer 72 vorzugsweise mit einem Kommunikationsnetzwerk verbunden, um Testinformationen zu anderen Testsystemen oder Computernetzwerken zu senden oder von diesen zu empfangen.
Der interne Bus 75 ist ein Bus in einer Testsystemhardware und gewöhnlich mit den meisten Funktionsblöcken verbunden. Die Adreßsteuerlogik 78 führt anderen Funktionsblöcken in dem Testsystem auf der Grundlage des Testprogramms und der Bedingungen von dem Hauptcomputer 72 Befehle zu. Der Fehlerspeicher 77 speichert Testergebnisse, wie Fehlerinformationen der DUT 88, in den von der Adreßsteuerlogik 78 festgelegten Adressen. Die im Fehlerspeicher 77 gespeicherten Informationen werden in der Fehleranalysestufe der getesteten Vorrichtung verwendet.
Die Adreßsteuerlogik 78 führt einem Ereignisspeicher 79, der typischerweise aus einem Ereigniszählspeicher 80 und einem Ereignisfeineinstellungsspeicher 81 besteht, wie in 5 dargestellt ist, Adreßdaten zu. Bei einem wirklichen Testsystem werden mehrere Sätze von Ereignisspeichern bereitgestellt, die jeweils einem Testanschluß des Testsystems entsprechen. In dem Ereignisspeicher 79 speichern der Ereigniszählspeicher 80 und der Ereignisfeineinstellungsspeicher 81 die Taktdaten für jedes Ereignis und die Ereignistypdaten. Der Ereigniszählspeicher 80 speichert die Taktdaten, die ein ganzzahliges Vielfaches des Referenztakts (Ganzteildaten) sind, und der Ereignisfeineinstellungsspeicher 81 speichert Taktdaten, die ein Bruchteil des Referenztakts (Bruchteildaten) sind. Beispielsweise werden die Taktdaten für jedes Ereignis durch eine Zeitdifferenz (Deltazeit) zwischen zwei benachbarten Ereignissen ausgedrückt.
Die Ereignissummier- und -skalierlogik 82 erzeugt Daten, die die Gesamtzeit jedes Ereignisses auf der Grundlage der Deltataktdaten von dem Ereigniszählspeicher 80 und dem Ereignisfeineinstellungsspeicher 81 darstellen. Diese Gesamtzeitdaten werden im wesentlichen durch Summieren der Ganzteildaten und der Bruchteildaten erzeugt. Während des Summierens der Taktdaten wird in der Taktmeß- und Versatzlogik 82 auch ein Übertragsvorgang der Bruchteildaten (Versatz der Ganzteildaten) ausgeführt. Die Taktverschiebungsfunktion und die Taktskalierfunktion zum Editieren der Ereignisse werden auch durch die Taktmeß- und Versatzlogik 82 ausgeführt.
Der Ereignisgenerator 84 dient dem eigentlichen Erzeugen der Ereignisse auf der Grundlage der Gesamttaktdaten von der Ereignissummier- und -skalierlogik 82. Die so erzeugten Ereignisse (beispielsweise Testsignale und Erwartungswerte) werden der DUT 88 durch die Stiftelektronik 86 zugeführt. Im wesentlichen besteht die Stiftelektronik 86 aus einer großen Anzahl von Komponenten, die jeweils einen Treiber und einen Vergleicher sowie Schalter zum Festlegen von Ein- und Ausgabebeziehungen in bezug auf die DUT 88 enthalten.
6 zeigt einen kurzen Vergleich zwischen der Datenstruktur in dem herkömmlichen zyklischen Tester und der Datenstruktur in dem Ereignistester zum Erzeugen der gleichen Testsignale (Testmuster). Dieses Beispiel vergleicht den Fall, in dem die Testmuster-Wellenformen 91 durch die Testdaten in dem zyklusbasierten Format und die Testdaten in dem ereignisbasierten Format erzeugt werden müssen. Die Wellenformen 91 sind an zwei Stifte Sa und Sb der IC-Vorrichtung angelegte Signale, die typischerweise beim Logiksimulationsprozeß bei der Entwicklung der IC-Vorrichtung erzeugt werden, wobei die VCD-Beschreibung (Beschreibung des Werteänderungsauszugs von Verilog) 99 auch dargestellt ist.
Zum Erzeugen der Wellenformen 91 beschreiben die im Ereignistester verwendeten Ereignisdaten die Wellenformen mit Kombinationen von Setz- und Rücksetzflanken San, Sbn, Ran und Rbn und ihre Zeitabläufe, wie in der Ereignisbasisbeschreibung 98 dargestellt ist. In dieser Beschreibung kann der Zeitablauf für jedes Ereignis durch eine relative Zeitdauer vom vorhergehenden Ereignis oder eine absolute Zeitdauer vom spezifizierten Bezugspunkt ausgedrückt werden. Wie 6 entnommen werden kann, gleicht die Ereignisbasisbeschreibung 98 im wesentlichen der VCD-Beschreibung 99.
Zum Erzeugen der Wellenform 91 in dem herkömmlichen Testsystem auf der Grundlage des zyklusbasierten Konzepts müssen die Testdaten in Testzyklen (Zeitsätze), Wellenformgruppen (Typen von Wellenformen und ihre Flankenzeiten) und Vektoren (Musterwerte) unterteilt werden. Insbesondere sind für die zyklusbasierte Datenstruktur die Vektordaten (Musterdaten) 95 und die Testzyklusdaten (Zeitsatzdaten) 93 im linken Teil von 6 dargestellt. Auch ist in der Zeichnung ein Testmuster in jeden Testzyklus, d.h. eine Kombination von einem oder mehreren Zeitsätzen (TS1, TS2 und TS3) und Wellenformen sowie die Takte für jeden Testzyklus unterteilt.
Ein Beispiel von Datenbeschreibungen für solche Wellenformen, Zeitabläufe und Testzyklen ist in den Wellenformdaten 96 dargestellt. Ein Beispiel der logischen "1", "0" oder "Z" der Wellenformen ist in den Musterdaten 95 dargestellt. Beispielsweise wird in den Wellenformdaten 96 der Testzyklus durch "Rate" beschrieben, um Zeitintervalle zwischen Testzyklen zu definieren, und die Wellenform wird durch RZ (Rückkehr zu null), NRZ (keine Rückkehr zu null) und XOR (Exklusiv-ODER) beschrieben. Weiterhin ist der Takt jeder Wellenform durch eine Verzögerungszeit von einer vorgegebenen Flanke (beispielsweise der Startflanke) des entsprechenden Testzyklus aus definiert.
Wie vorstehend erwähnt wurde, ist die Ereignisbasisbeschreibung 98 mit den Entwurfssimulationsergebnissen (VCD) 99 identisch, während die Zyklusbasisbeschreibung die Zeitsätze und verschiedene Typen von Wellenformen und Zeitbeschreibungen benötigt, die zu fern von dem ursprünglichen Entwurfssimulationsergebnis sind. Wegen dieser Komplexität der Datenstruktur beim herkömmlichen Testsystem ist es nicht möglich, die in der Entwurfsumgebung erzeugten Testdaten in ausreichendem Maße in das zyklusbasierte Format zu konvertieren. Überdies ist die Datenkonvertierung von dem Ereignisformat in das Zyklusformat sehr zeitaufwendig, komplex und fehlerträchtig und gefährdet die Genauigkeit der Daten.
Demgemäß wird gemäß der vorliegenden Erfindung der Ereignistester in der Testumgebung verwendet, in der Zeit- und Signalwertdaten verwendet werden, die in der in der Entwicklungsumgebung (EDA-Umgebung) erzeugten VCD-Datei aufgezeichnet sind. Demgemäß können die Daten von der VCD-Datei in dem Ereignistester direkt als die Testvektoren für eine getestete LSI-Vorrichtung verwendet werden. Zum Bestimmen des Bestehens/Nichtbestehens spezifiziert der Benutzer einen Strobe-Versatz für Strobe-Niedrig, Strobe-Hoch und Strobe-Z, um zu ermöglichen, daß die Vorrichtungszeit den erwarteten Ausgangszuständen entspricht.
Nun wird unter Rückbezug auf 2 der gesamte LSI-Herstellungsprozeß gemäß der vorliegenden Erfindung in weiteren Einzelheiten beschrieben. Bei einem wirklichen Test sind zusätzlich zu den Testvektoren, die anhand der VCD-Datei erzeugt werden können, auch andere Daten (Testparameter, die Stiftstruktur, die Testerstiftzuordnung usw.) erforderlich. Diese Daten können auch unter Verwendung der Entwurfsdaten und Simulationsdaten, die vorhanden waren, als der erste Entwurf abgeschlossen wurde, erzeugt werden. Gemäß der vorliegenden Erfindung wird der Ereignistestersimulator 27 verwendet, um die Korrektheit dieser Datendateien zu prüfen.
Der Herstellungsprozeß aus 2 umfaßt einen Entwurfsprozeß unter der EDA-Umgebung (Entwicklungsumgebung), die typischerweise ein Entwicklungszentrum (Entwicklungshaus) ist, einen Testprozeß eines Ereignistesters 30 und einen Siliciumherstellungsprozeß 24 in einer Siliciumzüchtungseinrichtung. Die Entwicklungsumgebung weist den Ereignistestersimulator 27 auf, der eine Operation eines Ereignistesters 30 simuliert. Der Ereignistestersimulator 27 ist eine Software, die die Korrektheit der Daten in bezug auf die Stiftausgabe (Stiftanordnung) der Vorrichtung in einer Stiftdatei 32₁ , ihre Zuordnung zu Testerkanälen in einer Sockeldatei (soc) 32₃ , Betriebs- und E/A-Parameterwerte, unter denen eine LSI-Vorrichtung arbeiten sollte, in einer Parameterdatei (par) 32₂ und Reihenfolgen, in denen Tests auf die LSI-Vorrichtung angewendet werden, in einer Testplandatei (tpl) 32₄ prüft. Die Testvektoren sind Ereignisse in einer VCD-Datei 36, und sie werden durch den Ereignistestersimulator 27 geprüft. Demgemäß ist es nicht erforderlich, ein neues Testprogramm zu entwickeln.
Während des Entwurfs eines LSIs, in diesem Fall eines SOCs 26 (System auf einem Chip) mit Kernen A–C, in der EDA-Umgebung, wird das Erzeugen von Entwurfsdaten 28₁ –28₂ , des Testfelds 31 und der Logiksimulation 29 (beispielsweise unter Verwendung eines Verilog/VHDL-Simulators) wiederholt. Am Ende des Entwurfs werden Entwurfsdatendateien 33₁ –33₄ , die RTL-Daten, Stiftdaten, Netzlistendaten und Maskendaten enthalten, erzeugt, welche an den Silicium-Herstellungsprozeß 24 übergeben werden. Die VCD-Datei 36 wird als Ergebnis der Logiksimulation erzeugt. Der Ereignistestersimulator 27 prüft die Korrektheit der Daten in den Testdatendateien 32₁ –32₄ (pin, par, soc, tpl) und korrigiert einen Fehler, sofern einer auftritt. Der Ereignistestersimulator 27 prüft auch die Testvektoren von der VCD-Datei 36 durch einen Compiler 35. Demgemäß prüft der Ereignistestersimulator 27 die Korrektheit aller vorstehend erwähnten Daten und stellt auch sicher, daß das Laden dieser Datendateien und Testvektoren in den Tester kein Problem hervorruft, und der Ereignistester arbeitet dann mit diesen Dateien und Testvektoren.
Nach dem Überprüfen aller testbezogener Datendateien und Testvektoren durch den Ereignistestersimulator 27 wird der DUT-Prototyp 26 in Silicium in dem Siliciumprozeß 24 erzeugt. Die Daten von den Dateien 32₁ –32₄ (die überprüft worden sind), werden als Ereignistestersoftware 37 in dem Ereignistester 30 installiert. Die Testvektoren, die überprüft worden sind, werden in einem Ereignisspeicher 38 in dem Ereignistester 30 installiert. Der Ereignistester 30 beurteilt die DUT 26 durch Anwenden des Testmusters von dem Ereignisspeicher 38 durch die Hardware 39 des Testers. Es ist auf diese Weise möglich, schnell zu bestimmen, ob der Siliciumprototyp Herstellungsfehler aufweist oder ob er so gut wie die Simulationsvektoren ist. In jedem Fall tritt bei dem festgelegten SOC kein Prototypen-Aufschub auf, und es geschieht ein deterministischer Übergang entweder zur Fehleranalyse oder zur Siliciumfreigabe (für die Anwendungsentwicklung und die Massenproduktion).
Der Erwerber dieser Erfindung hat eine neue graphische Benutzerschnittstelle (GUI) entwickelt, die es dem Benutzer ermöglicht, Signalwerte und Zeitabläufe der Testvektoren und Testreaktionen zu betrachten. Falls der eigentliche Test demgemäß einen Fehler zeigt, kann der Ereignistester bestimmen, ob dies ein zeitbezogener Fehler ist, und der Ereignistester kann, falls dies der Fall ist, Einzelheiten des Taktfehlers durch Ereigniseditierungen (Taktversatz, Skalierung usw.) über die GUI 40 analysieren. Auf der Grundlage des Ergebnisses dieser Ereigniseditierung kann ein neues Testfeld 34 erzeugt werden, das zur weiteren Simulation zur EDA-Umgebung zurückgeführt wird.
7 zeigt ein Beispiel der Anzeige der GUI des Ereignistesters, die vorteilhaft auf das Produktionsverfahren gemäß der vorliegenden Erfindung anwendbar ist. Zum Ausführen eines Tests kann ein Benutzer verschiedene Testparameter, wie Leistungsversorgungsniveaus und -ströme, Ein- und Ausgangsspannungen und -ströme, Spannungsklemmen und Leistungsversorgungsbedingungen (Rampen oder Wartezeiten), ähnlich wie es ein Entwicklungsingenieur an der Planungseinrichtung ausführen würde, durch diese GUI spezifizieren. Das Anzeigebeispiel aus 7 beinhaltet eine Zeitskala 101, Signalereignisse 102 in Kombination mit der Zeitskala 101, ein Schachbrett 103 auch mit der Zeitskala 101, Signalnamen 106 für entsprechende Stifte, die eine Eins-zu-Eins-Beziehung zu den Signalereignissen 102 aufweisen, und Fenster für den Testplan 105, die Stiftauswahl 107 und andere Parameter. Die Testreaktion kann an einem einzelnen Stift oder einer Sammlung von Stiften, die in einer gewünschten Ordnung angeordnet sind, betrachtet werden. Weil alle Operationen ereignisbasiert sind, kann der Benutzer jedes Ereignis und/oder seinen Zeitablauf durch einen einfachen Ziehvorgang mit der Maus laufend modifizieren.
Der Erwerber hat auch eine Skalierungsfunktion entwickelt, die es ermöglicht, die Zeit während eines ausgewählten Bereichs oder für einen ausgewählten Stift oder für den gesamten Test zu skalieren. Falls beispielsweise ein Test fehlschlägt, kann der Benutzer einfach einen Skalierungsfaktor eingeben, um den ganzen Test zu skalieren, damit er zu einer anderen Ereigniszeit abläuft. Dieser Vorgang ist sehr wirksam beim Identifizieren aller zeitbezogenen Fehler in dem ersten Silicium sowie als eine Geschwindigkeits-/Frequenzcharakterisierung eines Teils. Einzelheiten der Skalierung sind in der US-Patentanmeldung 09/286 226 beschrieben, die der Erwerber der vorliegenden Erfindung besitzt. Weiterhin ist ein Beispiel für eine Ereigniseditierung und eine Zeitverschiebung oder einen Zeitversatz in den US-Patentanmeldungen 09/340 371 und 10/039 720 beschrieben, die der Erwerber der vorliegenden Erfindung besitzt. Es sei hiermit auf die vorstehend erwähnten US-Patentanmeldungen verwiesen.
Zusätzlich zu Signalereignisbetrachtungs-, Ereigniseditierungs- und Skalierungsfunktionen hat der Erwerber der vorliegenden Erfindung auch eine Schachbrett-Karte 103 entwickelt, wie sie in 7 dargestellt ist. Die Schachbrett-Karte 103 liefert eine schnelle und kondensierte Ansicht von Bestehens-/Nichtbestehensinformationen für den ganzen Test, und sie ist auch ein einfaches Navigationswerkzeug. Der Mausklick auf jeden Abschnitt auf dem Schachbrett synchronisiert diesen Zeitraum mit dem Signalereignisfenster 102. Demgemäß wird durch ein Anklicken bei einem Fehler in dem Schachbrett 103 eine Zoomdarstellung des Signalereignisfensters 102 bereitgestellt.
Der Erwerber hat auch eine Funktion entwickelt, mit der ein neues Testfeld für die Simulation in der Testumgebung erzeugt wird. Dieses Testfeld kann als eine Eingabe in den EDA-Simulator verwendet werden, um den Entwurf neu zu simulieren (das Testfeld 40 in 2). Nachdem ein Fehler in der Testreaktion des Siliciumprototyps auf dem Ereignistester beobachtet wurde, kann der Benutzer ihn durch Ereigniseditierungen und Ereignismanipulationen suchen. Sobald die Ursache des Fehlers verstanden wurde, ist es wünschenswert, das Simulationstestfeld neu zu erzeugen, so daß die Fehlerursache in dem Entwurf entfernt werden kann. Weil alle Operationen dieses Testers ereignisbasiert sind, wird es dem Benutzer ermöglicht, diese Ereignisse und ihre Zeitabläufe zu erfassen und sie in das Verilog/VHDL-Testfeld zurückzuübersetzen, wie in 2 dargestellt ist.
Wie vorstehend beschrieben wurde, kann das Silicium geprüft werden, sobald der Siliciumprototyp ankommt, weil der Ereignistester die Simulationsdaten direkt verwendet. Der Testlauf und der Durchlauf an dem Ereignistester bestimmen schnell, daß (1) der Siliciumprototyp funktionsfähig ist, und (2), daß der Siliciumprototyp so gut wie die Simulationsvektoren ist. Demgemäß kann das Silicium für die Anwendungsentwicklung und Massenproduktion freigegeben werden.
Falls der Testlauf einen Fehler zeigt, bedeutet dies entweder, daß es Taktverletzungen gibt (diese können unter Verwendung der Ereignisskalierung oder der Ereigniseditierungen gesucht werden, wie vorstehend erwähnt wurde) oder daß es Herstellungsfehler gibt. Es ist erwähnenswert, daß die Zeitverletzungen auch entweder auf Herstellungsfehler oder Prozeßschwankungen zurückzuführen sind. Wenn daher der Testlauf einen Fehler zeigt, kann der Siliciumprototyp zur Fehleranalyse gesendet werden, um den Fehlertyp (Brücke, offen, kurzgeschlossen, Gate-Oxid-Fehler usw.) zu bestimmen. In jedem Fall wird dabei ein Prototypen-Aufschub vermieden. Wenn der Test bestanden wird, wird das Silicium freigegeben, und wenn der Test nicht bestanden wird, wird eine Rückmeldung von Herstellungsfehlern bereitgestellt, so daß die Fehler in dem Herstellungsprozeß behoben werden können. Es sei bemerkt, daß diese deterministische Schlußfolgerung nur dann gezogen werden kann, wenn es keine Vektorübersetzung gibt. Mit anderen Worten kann diese Schlußfolgerung wegen des Ereignistesters und des Ereignistestersimulators gezogen werden. Wegen der Vektorübersetzung kann diese Schlußfolgerung beim heutigen Herstellungsprozeß nicht gezogen werden.
Falls das auf dem Ereignistester basierte Testen untersucht und mit heutigem zyklusbasierten Testen verglichen wird, kann ein erhebliches Ausmaß an Modifikationen beobachtet werden. Die Hauptänderung ist darauf zurückzuführen, daß die Vektorübersetzungsschritte ganz weggelassen wurden. Zum Identifizieren dieses Unterschieds ist 8 ein Diagramm des ereignisbasierten Testablaufs zum Vergleich mit dem zyklusbasierten Testablauf aus 3. Wie anhand der 3 und 4 erläutert wurde, sind heutige EDA- und ATE-Formate infolge verschiedener Beschränkungen (Zeitsätze, Wellenformen usw.) vollkommen getrennt. Daher können heute keine EDA-Vektoren "unverändert" an dem Tester verwendet werden, und es kann daher keine Schlußfolgerung für die Ursache des Fehlers gezogen werden, wenn der Test einen Fehler zeigt.
In 8 sind diese Beschränkungen mit dem Ereignistester beseitigt, und EDA-Vektoren werden "unverändert" verwendet. Auf der Grundlage der Spezifikation 111 eines vorgesehenen LSIs in der Art eines ASICs oder SOCs entwickelt der Entwickler den LSI in einer Entwicklungsphase 112. Nach der Entwicklungsphase 112 wird eine Entwurfsdatendatei 116 erzeugt, die zu einer Herstellungsstufe 113 gesendet wird, in der ein LSI-Prototyp 117 hergestellt wird. Diese Prozesse gleichen im wesentlichen jenen, die in 3 dargestellt sind, der Hauptunterschied besteht jedoch in der Testphase 114, die vom Ereignistester ausgeführt wird.
Als Ergebnis der Logiksimulation in der Entwicklungsphase 112 wird eine Teststimulationsdatei (VCD-Datei) 115 erzeugt, die im Ereignisformat vorliegt. Wie vorstehend mit Bezug auf 2 erwähnt wurde, werden auch andere Testdatendateien verwendet, die vom Ereignistestersimulator in der Entwicklungsphase 112 geprüft werden. Der Ereignistester verwendet das Ereignisformat und ist dadurch in der Lage, die Teststimulationsdatei 115 direkt zu verwenden, die im vorstehend erwähnten Ereignisformat vorliegt. Demgemäß ist die Vektorübersetzung für die Formatkonvertierung in der Art der in 4 dargestellten unnötig.
9 ist ein zu 4 analoges Diagramm zum Erläutern der Unterschiede und zum Bereitstellen eines Vergleichs. Wie in 9 dargestellt ist, wird keine Vektorübersetzung vorgenommen, und die EDA-Simulatorvektoren in dem VCD-Format werden in dem Ereignistester verwendet. Genauer gesagt, wird die Spezifikation 122 auf der Grundlage der Anforderungen 121 des LSIs erzeugt. In der EDA-Umgebung beschreibt der Entwickler den vorgesehenen LSI unter Verwendung von Verilog/VHDL, typischerweise durch einen Struktureintrag 123 und einen Verhaltenseintrag 124. Auf der Grundlage dieser Einträge wird ein Vorrichtungsmodell 125 des vorgesehenen LSIs erzeugt, das sich typischerweise auf einer RTL- oder Gate-Ebene befindet.
Bei der Logiksimulation 126 wird das Vorrichtungsmodell 125 wiederholt unter Verwendung eines Testfelds beurteilt. Infolge der Logiksimulation 126 wird eine Ereignisvektordatei erzeugt, die typischerweise eine VCD-Datei (Werteänderungsauszugs-Datei) 129 von Verilog ist. Die VCD-Datei 129 enthält Daten, die Werteänderungen und Zeiten für Ein- und Ausgaben des LSIs darstellen. Ein LSI-Prototyp 130 wird durch den Ereignistester 131 getestet, der die Vektoren in der VCD-Datei 129 verwendet. Unter Verwendung der GUI, der Skalierung, des Ereignisversatzes und der Editierungsfunktionen, wie vorstehend erwähnt wurde, modifiziert der Ereignistester 131 in Schritt 128 die Testvektoren, falls ein Fehler auftritt, und erzeugt ein neues Testfeld 127, das zur weiteren Simulation zur EDA-Umgebung zurückgeführt wird.
Es sei darauf hingewiesen, daß in dem Prozeß aus 9 das auf dem Ereignistester basierte Testen auch eine vollständige Schleife (Entwurf-Test-Entwurf) bereitstellt, was bei der heutigen Technologie nicht möglich ist. In 9 ist diese vollständige Schleife infolge der neuen Testfelderzeugung, wie vorstehend erwähnt wurde, und weil jede Aufgabe (sowohl Entwurf als auch Testen) in einer Umgebung ausgeführt wird, möglich.
Das Zustandsdiagramm beim heutigen Herstellungsprozeß ist in 10 dargestellt. Der Prozeß beginnt mit dem Spezifikationszustand 141 und geht zum IC-Entwurfszustand 142, zum Simulationszustand 143 und zum Entwurfsabschlußzustand 144 über. In dem Bandausgabezustand 145 werden die Entwurfsdaten an den Herstellungszustand 146 übergeben. Der LSI-Prototyp wird in dem ATE-Testzustand 147 getestet. Wenn bei dem industriellen Prozeß für die heutige Halbleiterherstellung ein Fehler in dem Testzustand 147 auftritt, wird der LSI dem Prototypen-Aufschub 148 unterzogen, weil es mehrere Fehlerursachen, wie ein Fehler bei der Vektorübersetzung, ein Fehler in einem Testprogramm, ein Herstellungsdefekt usw., gibt.
Wie in 10 dargestellt ist, ist dies ein Prozeß mit offenem Ende, wobei der Prototypen-Aufschub ein offener Zustand ist. Wegen dieses offenen Zustands ist der gesamte Prozeß nicht deterministisch. Während des Prototypen-Aufschubs 148 bemühen sich Ingenieure, die Ursache des Fehlers zu identifizieren und hängen von verschiedenen Versuch-und-Irrtum-Operationen ab. Das Silicium kann, bevor die Fehlerursache identifiziert wurde, weder freigegeben werden, noch kann es zur Fehleranalyse gesendet werden, um den Fehlertyp zu identifizieren, weil die Fehlerursache möglicherweise kein Defekt ist, sondern ein Vektorübersetzungsfehler oder ein Fehler in dem Testprogramm sein kann.
Beim Herstellungsprozeß gemäß der vorliegenden Erfindung wird die vorstehend erwähnte Ungewißheit beseitigt, indem der Ereignistester verwendet wird und keinerlei Vektorübersetzung oder Entwicklung eines Testprogramms ausgeführt wird. Das Zustandsdiagramm für den neuen Prozeß ist in 11 dargestellt. Im Zustand 151 erzeugt und prüft der Prozeß die erforderlichen Dateien. Wie vorstehend. beschrieben wurde, überprüft der Ereignistestersimulator diese Dateien (pin, par, soc, tpl, vcd) im Zustand 151 unter Verwendung der im Entwurfszustand 142 und im Simulationszustand 143 erzeugten Daten.
Demgemäß werden die Entwurfsdaten (RTL, netlist, Maske) bei der Bandausgabe 152 zum Herstellungszustand 153 gesendet, und die Dateien (pin, par, soc, tpl, vcd) mit verschiedenen Simulationsdaten zum Testzustand 154 gesendet, um den LSI-Prototyp durch den Ereignistester zu testen. Falls ein Fehler erkannt wird, wird die Fehlerursache zur Herstellungsstufe 155 zurückgeführt. Falls das Testergebnis keine Probleme zeigt, wird der Siliciumprototyp im Zustand 156 für die Anwendungsentwicklung und Massenproduktion freigegeben.
Wie in 11 dargestellt ist, handelt es sich um einen Prozeß mit geschlossenem Ende ohne einen Prototypen-Aufschub und ohne Versuch-und-Irrtum. Bei diesem Prozeß wird das Silicium in deterministischer Weise freigegeben. Zum Erreichen dieses deterministischen Endzustands sind überall fundamentale Änderungen erforderlich. Beispielsweise weist, wie in 11 dargestellt ist, die Bandausgabe 152 die Dateien pin, par, soc, tpl und vcd, statt nur einer GDSII-(Graphikentwurfsstandard II)-Layoutdatenbank auf. Eine weitere grundlegende Anforderung besteht darin, daß der Ereignistester in den Herstellungsprozeß integriert ist und daß keine Vektorübersetzung und keine Testprogrammerzeugung stattfinden.
12 ist ein Flußdiagramm, in dem der Gesamtablauf für den industriellen Prozeß gemäß der vorliegenden Erfindung dargestellt ist. In 12 wird der LSI-Entwurf in Schritt 161 ausgeführt, was typischerweise in einem Entwicklungshaus (Entwicklungszentrum) geschieht. Wie vorstehend beschrieben wurde, ist in diesen Prozeß, zusätzlich zu den gewöhnlichen EDA-Werkzeugen, der Ereignistestersimulator aufgenommen. In Schritt 162 wird bestimmt, ob die Bandausgabe bereit ist. In diesem Prozeß werden nicht nur die Daten für die Herstellung, sondern auch die verschiedenen Dateien (pin, par, soc, tpl, vcd) für den Ereignistester geprüft.
In Schritt 163 wird der Siliciumprototyp durch einen Hersteller (Siliciumzüchtungseinrichtung) auf der Grundlage der Entwurfsdaten hergestellt. Wenngleich das Entwicklungshaus und die Siliciumzüchtungseinrichtung getrennt angegeben sind, können sie auch zwei getrennte Gruppen oder Abteilungen innerhalb einer Firma oder zwei verschiedene Firmen sein. Der Siliciumprototyp wird in Schritt 164 durch den Ereignistester getestet, der die in Schritt 165 bereitgestellten Dateien (vcd, pin, par usw.) verwendet. Wie vorstehend erwähnt wurde, werden diese Dateien in der EDA-Umgebung unter Verwendung des Ereignistestersimulators und des Verilog/VHDL-Simulators erzeugt.
Bei der vorliegenden Implementation hat der Erwerber ASCII-Textdateien für diese Dateien (pin, par, tpl usw.) verwendet, wenngleich auch andere Formate möglich sind. Überdies können an Stelle der Verwendung getrennter Dateien diese Dateien anders kombiniert oder restrukturiert werden, beispielsweise entweder in einer oder in zwei Dateien. Ähnlich sind einige Änderungen in dem Prozeß und dem Ablauf möglich, wobei beispielsweise an Stelle des Entwicklungshauses oder des Entwicklungszentrums in Schritt 161 eine dritte Partei die Dateien pin, par, soc und tpl erzeugen kann.
Falls in Schritt 166 der Test einen Fehler zeigt, wird die Ursache des Fehlers festgestellt. Weil die Testvektoren in der Entwurfsstufe untersucht werden und dieselben Testvektoren in dem Ereignistester verwendet werden, wird, falls in Schritt 166 ein Fehler festgestellt wird, dieser als ein Herstellungsfehler angesehen. Demgemäß wird in Schritt 168 die Fehleranalyse ausgeführt, um die Probleme in dem Herstellungsprozeß herauszufinden. Falls das Testergebnis ein Bestehensergebnis zeigt, wird der Siliciumprototyp in Schritt 167 zur Anwendungsentwicklung und zur Massenproduktion freigegeben.
Bei diesem Ablauf aus 12 sendet der Entwicklungsingenieur die Dateien (pin, par, tpl, soc) und Simulations vektoren (VCD vom Simulator) zusammen mit der Layoutdatenbank (GDSII) zur Herstellung. Es sei bemerkt, daß bei der existierenden Technologie und in der existierenden Praxis Entwicklungsingenieure nur die Layoutdatenbank zur Siliciumzüchtungseinrichtung senden (die Dateien pin, par, soc und tpl existieren in der existierenden Technologie nicht). Wenn die Herstellung abgeschlossen wird und mit anderen Worten der Siliciumprototyp ankommt, kann ein Fertigungsingenieur dieses Silicium auf den Ereignistester bringen und die Simulationsvektoren ablaufen lassen und schnell bestimmen, ob das Silicium Herstellungsdefekte aufweist oder so gut wie die Simulationsvektoren ist. In jedem Fall wird das Silicium keinem Prototypen-Aufschub unterzogen, und es tritt ein deterministischer Übergang entweder zur Fehleranalyse oder zur Siliciumfreigabe auf.
Vorstehend wurde ein neuer industrieller Prozeß für die IC-Herstellung beschrieben, der deterministisch ist und einen Prototypen-Aufschub vermeidet. Diese Lösung schließt die neuen Einrichtungen (den neuen Tester und den neuen Testersimulator) und den auf diesem Tester und Testersimulator beruhenden Ablauf ein. Dieser Tester arbeitet in der Ereignisumgebung, nämlich der Umgebung, in der die Vorrichtung entwickelt und simuliert wurde. Im wesentlichen erweitert dieser Ereignistester die Entwicklungsumgebung um das Testen. Abgesehen davon, daß er das Problem des Prototypen-Aufschubs löst, besteht ein weiterer Vorteil dieses Testers und dieses Verfahrens darin, daß der ganze Testprozeß drastisch vereinfacht wird und er eine direkte Verbindung von der Entwurfssimulation zum Testen bereitstellt. Für eine Fehlersuche und Charakterisierung des ersten Siliciums ist dies ein erheblicher Vorteil, weil Entwickler die Reaktion einer Vorrichtung bei mehreren Versionen von Simulationstestvektoren prüfen können.
Wenngleich die Erfindung hier mit Bezug auf die bevorzugte Ausführungsform beschrieben wurde, wird ein Fachmann leicht verstehen, daß verschiedene Modifikationen und Ab änderungen vorgenommen werden können, ohne vom Gedanken und vom Schutzumfang der vorliegenden Erfindung abzuweichen. Diese Modifikationen und Abänderungen werden als innerhalb des Anwendungsbereichs und des Schutzumfangs der anliegenden Ansprüche liegend angesehen.
Zusammenfassung
Bei einem Herstellungsprozeß für LSIs wird ein Ereignistester verwendet, um einen Prototypen-Aufschub zu vermeiden. Das LSI-Herstellungsverfahren weist folgende Schritte auf: Entwerfen eines LSIs unter einer EDA-Umgebung (Elektronikentwurfs-Automatisierungsumgebung) zum Erzeugen von Entwurfsdaten für einen entworfenen LSI, Ausführen einer Logiksimulation an einem Vorrichtungsmodell des LSI-Entwurfs in der EDA-Umgebung unter Verwendung eines Testfelds und Erzeugen einer Testvektordatei von ereignisbasierten Testvektoren als Ergebnis der Logiksimulation, Erzeugen von testbezogenen Datendateien unter Verwendung der Entwurfsdaten und ereignisbasierten Testvektoren, Erzeugen eines Ereignistestersimulators, der eine Operation eines Ereignistesters simuliert, Überprüfen der testbezogenen Datendateien und der ereignisbasierten Testvektoren durch den Ereignistestersimulator, Erzeugen eines LSI-Prototypen durch einen Hersteller unter Verwendung der Entwurfsdaten und Testen des LSI-Prototypen durch den Ereignistester unter Verwendung der ereignisbasierten Testvektoren und Suchen von Fehlern durch Ereigniseditierungen und Rückführen der Testergebnisse zu Entwicklungsingenieuren und zum Hersteller.

Claims

LSI-Herstellungsverfahren zum Vermeiden eines Prototypen-Aufschubs mit den folgenden Schritten: Entwerfen eines LSIs unter einer EDA-Umgebung (Elektronikentwurfs-Automatisierungsumgebung) zum Erzeugen von Entwurfsdaten für einen entworfenen LSI, Ausführen einer Logiksimulation an einem Vorrichtungsmodell des LSI-Entwurfs in der EDA-Umgebung unter Verwendung eines Testfelds und Erzeugen einer Testvektordatei von ereignisbasierten Testvektoren als Ergebnis der Logiksimulation, Erzeugen von testbezogenen Datendateien unter Verwendung der Entwurfsdaten und ereignisbasierten Testvektoren, Erzeugen eines Ereignistestersimulators, der eine Operation eines Ereignistesters simuliert, Überprüfen der testbezogenen Datendateien und der ereignisbasierten Testvektoren durch den Ereignistestersimulator, Erzeugen eines LSI-Prototypen durch einen Hersteller unter Verwendung der Entwurfsdaten und Testen des LSI-Prototypen durch den Ereignistester unter Verwendung der ereignisbasierten Testvektoren und Suchen von Fehlern durch Ereigniseditierungen und Rückführen der Testergebnisse zu Entwicklungsingenieuren und zum Hersteller.
LSI-Herstellungsverfahren nach Anspruch 1, wobei Simulationstestvektoren in der Testvektordatei direkt in dem Ereignistester verwendet werden, ohne daß eine Datenkonvertierung oder -übersetzung auf den LSI-Prototypen angewendet wird.
LSI-Herstellungsverfahren nach Anspruch 1, wobei Simulationstestvektoren in der Testvektordatei direkt in dem Ereignistester verwendet werden, ohne daß eine Vektorkonvertierung oder -übersetzung auf den LSI-Prototypen angewendet wird, und die Daten in den testbezogenen Datendateien direkt in dem Ereignistester verwendet werden, um Testbedingungen einschließlich Parametern des Testmusters zum Testen des LSI-Prototypen zu spezifizieren.
LSI-Herstellungsverfahren nach Anspruch 1, wobei beim Ausführen der Logiksimulation eine VCD-Datei (Werteänderungsauszugs-Datei von Verilog) als die Testvektordatei erzeugt wird.
LSI-Herstellungsverfahren nach Anspruch 1, wobei beim Überprüfen der testbezogenen Datendateien durch den Ereignistestersimulator die Korrektheit der LSI-Stiftanordnung in einer Stiftdatei, ihrer Zuordnung zu Testerkanälen in einer Sockeldatei, von E/A-Parameterwerten für den LSI-Prototypen in einer Parameterdatei und von Testreihenfolgen in einer Testplandatei geprüft wird.
LSI-Herstellungsverfahren nach Anspruch 1, wobei der Ereignistestersimulator überprüft, daß die von der Logiksimulation erzeugten ereignisbasierten Testvektoren erfolgreich auf den Ereignistester geladen werden.
LSI-Herstellungsverfahren nach Anspruch 1, wobei der Ereignistestersimulator die testbezogenen Datendateien und die von der Logiksimulation erzeugten ereignisbasierten Testvektoren überprüft, so daß darin vorhandene Fehler korrigiert werden, bevor sie an dem Ereignistester verwendet werden.
LSI-Herstellungsverfahren nach Anspruch 1, wobei der Ereignistester mit den ereignisbasierten Testvektoren und Daten in den testbezogenen Datendateien arbeitet, wobei alle durch den Ereignistestersimulator überprüft werden, wodurch der Test an dem LSI ohne getrennte Erzeugung eines Testprogramms ausgeführt wird.
LSI-Herstellungsverfahren nach Anspruch 1, wobei beim Testen des LSI-Prototypen durch den Ereignistester die ereignisbasierten Testvektoren in der Testvektordatei, die direkt von der Logiksimulation beim LSI-Entwurf in der EDA-Umgebung abgeleitet wurden, in einem Ereignisspeicher des Ereignistesters gespeichert werden und die ereignisbasierten Testvektoren aus dem Ereignisspeicher erzeugt und auf den LSI-Prototypen angewendet werden und Reaktionsausgaben des LSI-Prototypen zu vorgegebenen Zeiten beurteilt werden.
LSI-Herstellungsverfahren nach Anspruch 1, wobei beim Testen des LSI-Prototypen durch den Ereignistester ein neues Testfeld auf der Grundlage des Testergebnisses erzeugt wird und das neue Testfeld zur weiteren Logiksimulation zur Entwurfsumgebung bzw. Entwicklungsumgebung gesendet wird.
LSI-Herstellungsvorrichtung zum Vermeiden eines Prototypen-Aufschubs mit: einer Einrichtung zum Entwerfen eines LSIs in einer EDA-Umgebung (Elektronikentwurfs-Automatisierungsumgebung) zum Erzeugen von Entwurfsdaten für einen entworfenen LSI, einer Einrichtung zum Ausführen einer Logiksimulation an einem Vorrichtungsmodell des LSI-Entwurfs in der EDA-Umgebung unter Verwendung eines Testfelds und zum Erzeugen einer Testvektordatei von ereignisbasierten Testvektoren als Ergebnis der Logiksimulation, einer Einrichtung zum Erzeugen von testbezogenen Datendateien unter Verwendung der Entwurfsdaten und ereignisbasierten Testvektoren, einem Ereignistestersimulator zum Überprüfen der testbezogenen Datendateien und der ereignisbasierten Testvektoren durch den Ereignistestersimulator, einer Einrichtung zum Erzeugen eines LSI-Prototypen durch einen Hersteller unter Verwendung der Entwurfsdaten und einem Ereignistester zum Testen des LSI-Prototypen unter Verwendung der ereignisbasierten Testvektoren und zum Suchen von Fehlern durch Ereigniseditierungen und Rückführen der Testergebnisse zu Entwicklungsingenieuren und zum Hersteller.
LSI-Herstellungsvorrichtung nach Anspruch 11, wobei Simulationstestvektoren in der Testvektordatei direkt in dem Ereignistester verwendet werden, ohne daß eine Datenkonvertierung oder -übersetzung auf den LSI-Prototypen angewendet wird.
LSI-Herstellungsvorrichtung nach Anspruch 11, wobei Simulationstestvektoren in der Testvektordatei direkt in dem Ereignistester verwendet werden, ohne daß eine Vektorkonvertierung oder -übersetzung auf den LSI-Prototypen angewendet wird, und die Daten in den testbezogenen Datendateien direkt in dem Ereignistester verwendet werden, um Testbedingungen einschließlich Parametern des Testmusters zum Testen des LSI-Prototypen zu spezifizieren.
LSI-Herstellungsvorrichtung nach Anspruch 11, wobei die Einrichtung zum Ausführen der Logiksimulation eine Einrichtung zum Erzeugen einer VCD-Datei (Werteänderungsauszugs-Datei von Verilog) als Testvektordatei aufweist.
LSI-Herstellungsvorrichtung nach Anspruch 11, wobei der Ereignistestersimulator zum Überprüfen der testbezogenen Datendateien Mittel zum Überprüfen der Korrektheit der LSI-Stiftanordnung in einer Stiftdatei, ihrer Zuordnung zu Testerkanälen in einer Sockeldatei, von E/A-Parameterwerten für den LSI-Prototypen in einer Parameterdatei und von Testreihenfolgen in einer Testplandatei aufweist.
LSI-Herstellungsvorrichtung nach Anspruch 11, wobei der Ereignistestersimulator überprüft, daß durch die Logiksimulation erzeugte ereignisbasierte Testvektoren erfolgreich in den Ereignistester geladen werden.
LSI-Herstellungsvorrichtung nach Anspruch 11, wobei der Ereignistestersimulator die testbezogenen Datendateien und die von der Logiksimulation erzeugten ereignisbasierten Testvektoren überprüft, so daß Fehler darin korrigiert werden, bevor sie am Ereignistester verwendet werden.
LSI-Herstellungsvorrichtung nach Anspruch 11, wobei der Ereignistester mit den ereignisbasierten Testvektoren und Daten in den testbezogenen Datendateien arbeitet, die alle von dem Ereignistestersimulator überprüft werden, wodurch der Test an dem LSI ohne getrenntes Erzeugen eines Testprogramms ausgeführt wird.
LSI-Herstellungsvorrichtung nach Anspruch 11, wobei der Ereignistester zum Testen des LSI-Prototypen durch den Ereignistester eine Einrichtung zum Speichern der ereignisbasierten Testvektoren in der Testvektordatei, die direkt von der Logiksimulation beim LSI-Entwurf abgeleitet wurden, in einem Ereignisspeicher des Ereignistesters und zum Erzeugen der ereignisbasierten Testvektoren und zum Anwenden der Testvektoren auf den LSI-Prototypen und zum Beurteilen von Reaktionsausgaben des LSI-Prototypen zu vorgegebenen Zeiten aufweist.
LSI-Herstellungsvorrichtung nach Anspruch 11, wobei der Ereignistester zum Testen des LSI-Prototypen durch den Ereignistester eine Einrichtung zum Erzeugen eines neuen Testfelds auf der Grundlage des Testergebnisses und zum Senden des neuen Testfelds für die weitere Logiksimulation zur Entwurfsumgebung bzw. Entwicklungsumgebung aufweist.