DE69826659T2

DE69826659T2 - Billige, leicht anzuwendende software für ein automatisches testsystem

Info

Publication number: DE69826659T2
Application number: DE69826659T
Authority: DE
Inventors: C. Daniel PROSKAUER; B. Pradeep DESHPANDE
Original assignee: Teradyne Inc
Current assignee: Teradyne Inc
Priority date: 1997-06-13
Filing date: 1998-06-04
Publication date: 2005-10-06
Anticipated expiration: 2018-06-05
Also published as: EP0988558B1; JP4972244B2; WO1998057187A1; EP0988558A1; JP2002505000A; DE69826659D1; US5910895A; KR20010013719A

Description

Diese Erfindung betrifft allgemein automatische Testgeräte, die bei der Herstellung von Halbleitern verwendet werden, und insbesondere die Steuersoftware für derartige Testsysteme.
Automatische Testgeräte werden in einem weit verbreiteten Maße bei der Herstellung von Halbleitern verwendet. Halbleiter werden allgemein wenigstens einmal während ihrer Herstellung getestet und werden manchmal an mehr als einer Stufe in dem Herstellungsprozess getestet. Weil jede Komponente getestet wird, ist die Geschwindigkeit des Testvorgangs kritisch für die wirtschaftliche Herstellung der Halbleiter. Ein langsamer Testvorgang verhindert die volle Verwendung des Geräts mit einem hohen Investitionsaufwand, das benötigt wird, um Halbleiterkomponenten herzustellen.
Moderne Halbleiterkomponenten sind sehr kompliziert und weisen viele Betriebszustände auf. Jeder von diesen Betriebszuständen muss ausgeübt werden, um einen vollständige Test auszuführen. Ein automatisches Testgerät ist deshalb dafür ausgelegt, um an eine Halbleitereinrichtung Testdaten anzulegen und zahlreiche Messungen sehr schnell in einer Produktionsanlage durchzuführen. 1 zeigt ein verallgemeinertes automatisches Testsystem des Standes der Technik. Um einen gründlichen und schnellen Testvorgang bereitzustellen umfasst das automatische Testsystem im Allgemeinen einen Testerkörper 112, eine computerisierte Arbeitsstation 110 und eine Behandlungseinrichtung 114.
Die Computerarbeitsstation 110 steuert sowohl die Behandlungseinrichtung 114 als auch den Testerkörper 112. Sie steuert die Behandlungseinrichtung 114, um die Halbleitereinrichtung (nicht gezeigt) zu positionieren, wo sie einen Kontakt mit zahlreichen Testsonden (Prüfspitzen) 118 auf den Testerkörper 112 bildet. Oft wird ein Tester einen getrennten Testkopf einschließen, der Testsonden 118 enthält. Jedoch ist ein derartiger Unterschied für die Erfindung nicht wichtig.
Die Arbeitsstation steuert dann den Testerkörper 112, um eine Reihe von Tests für die Einrichtung, die gerade getestet wird, ablaufen zu lassen. Jeder Test umfasst im Allgemeinen einen Aufbauabschnitt, in dem Steuersignale von der Arbeitsstation 110 an den Testerkörper 112 gesendet werden. Die Steuersignale sind gewöhnlicherweise digitale Werte, die über den Bus 116 gewendet werden. Diese Steuersignale konfigurieren die Hardware innerhalb des Testerkörpers 112, um die Messungen durchzuführen, die für den Test benötigt werden. Die Hardware innerhalb des Testerkörpers stellt eine Anregung bereit und misst Antworten von der Einrichtung, die gerade getestet wird, in Übereinstimmung mit den Steuersignalen.
1 zeigt, dass die Hardware in dem Testerkörper 112 zahlreiche Schaltungen einschließt, die als Stifte 124 identifiziert sind. Jeder Stift 124 erzeugt Signale oder führt Messungen für eine der Testsonden 118 durch. Jeder Stift kann ein statisches oder ein DC Signal bereitstellen oder messen. Alternativ könnte jeder Stift 124 sich ändernde Daten in einer Einheit, die manchmal als ein „Burst" bezeichnet wird, bereitstellen oder messen.
Während eines Bursts wird der Testerkörper 120 durch eine Timing- und Ablaufsteuerungs-Schaltung 120 gesteuert. Die Timing- und Ablaufsteuerungs-Schaltung 120 veranlasst jeden der Stifte 124 eine Sequenz von Datenwerten aus einem zugehörigen Speicher 128 auszulesen. Jeder Datenwert zeigt den Typ von Signal an, das der Stift anlegen sollte oder von dem erwartet werden sollte, dass es an seiner zugehörigen Testsonde 118 zu einem spezifischen Zeitpunkt gemessen wird. Wenn der Stift eine Messung mit einem erwarteten Wert vergleicht, dann könnten die Ergebnisse auch in dem Speicher 128 gespeichert werden.
Der Satz von Datenwerten, die die Werte definieren, die sämtliche Stifte 124 bereitstellen sollten oder von denen erwartet wird, dass sie von sämtlichen Stiften 124 zu einer Zeit gemessen werden, wird als „Vektor" bezeichnet. Während eines Bursts werden viele Vektoren ausgeführt. Die Vektoren müssen bei einer sehr hohen Rate ausgeführt werden, um tatsächliche Betriebsbedingungen der Einrichtung, die sich unter einem Test befindet, zu simulieren. Es gibt gewöhnlicherweise Millionen von Vektoren, um die Bursts zu definieren, die benötigt werden, um eine Halbleitereinrichtung zu testen. Die Vektoren werden typischerweise in Speichern 128 zu der Zeit hinein geladen, zu der das Testsystem programmiert wird, um einen bestimmten Teiletyp zu testen. Dieser Ladeprozess kann mehrere Minuten andauern und wird zu jedem Burst nicht wiederholt. Anstelle davon sendet die Arbeitsstation 110 für jeden Burst Befehle, die anzeigen, welche Vektoren als Teil des Bursts ausgeführt werden sollen. Sobald der Burst beendet ist liest die Arbeitsstation 110 die Ergebnisse des Bursts aus dem Speicher 128 oder der Timing- und Ablaufsteuerungs-Schaltung 120.
Zusätzlich umfasst ein Testerkörper 112 ein oder mehrere Instrumente 126. Ein Instrument führt eine spezifische Testfunktion aus. Es könnte zum Beispiel ein spezifisches Testsignal, wie beispielsweise eine Sinus-Welle, erzeugen. Alternativ könnte ein Instrument ein Signal bei einer hohen Rate abtasten, sodass es später durch einen digitalen Signalprozessor analysiert werden kann. Diese Funktionen könnten als Teil eines Bursts ausgeführt werden oder könnten getrennt von einem Burst ausgeführt werden.
Ein voller Test eines Teils, was manchmal als ein „Job" bezeichnet wird, wird aus einer Serie von Bursts bestehen, unter die DC Messungen oder Messungen durch Instrumente 126 verteilt sind. Die Bursts könnten verwendet werden, um spezifische funktionale Attribute der zu testenden Einrichtung (der Einrichtung, die gerade getestet wird) zu messen. Alternativ könnte jeder Burst nur verwendet werden, um die zu testende Einrichtung in einen Zustand zu versetzen, in dem eine DC Messung vorgenommen werden kann. Die Reihenfolge, in der diese Elemente eines Tests ausgeführt werden, was manchmal als der „Fluss" bezeichnet wird, wird durch die Software in der Arbeitsstation 110 vorgegeben.
Sobald eine Einrichtung vollständig getestet worden ist, oder bis zu dem Punkt getestet worden ist, wo bestimmt wird, dass sie defekt ist, erzeugt die Arbeitsstation 110 Steuersignale an der Behandlungseinrichtung 114. Die Behandlungseinrichtung 114 bietet dann die nächste Einrichtung, die getestet werden soll, an dem Testerkörper 112 an und der Prozess wird wiederholt. Die Arbeitsstation 110 sammelt auch Daten darüber, ob bestimmte Einrichtungen den Test bestanden haben oder nicht. Sie kann diese Daten so verarbeiten, dass defekte Einrichtungen weggeworfen werden oder sie kann andere Funktionen, wie beispielsweise das Analysieren der Daten hinsichtlich der Ausfalltrends, ausführen.
Eine andere wichtige Funktion der Software innerhalb der Arbeitsstation 110 besteht darin, dass sie eine Unterstützung bei der Entwicklung von Tests für eine bestimmte Einrichtung oder sogar während der Konstruktion der Einrichtung selbst bereitstellt. Während der Entwicklung muss ein Testingenieur in der Lage sein derartige Aspekte wie die Einstellungen für die Hardware innerhalb des Testerkörpers 112 zu spezifizieren. Der Ingenieur muss auch in der Lage sein den Fluss des Tests zu spezifizieren. Es ist höchst wünschenswert, dass die Software, die den Tester steuert, flexibel ist und auch leicht zu erlernen und zu verwenden ist. Es besteht eine starke Konkurrenz im Halbleiterchipmarkt, angetrieben größtenteils durch technische Innovationen. Es ist deshalb wichtig, dass die Chips für die Herstellung so schnell wie möglich entwickelt und vorbereitet werden. Es ist unerwünscht, wenn Verzögerungen eingeführt werden, weil Testingenieure lernen müssen, wie ein Tester zu programmieren ist.
2 zeigt eine traditionelle Softwarearchitektur für die Software in der Arbeitsstation 110. Die Software ist aufgeteilt in Elemente, die zur Zeit der Testentwicklung und der Analyse verwendet werden, und in Software, die zu der Testausführungszeit verwendet wird.
Ein erster Schritt beim Definieren des Tests ist allgemein die Einrichtungsdaten zu spezifizieren. 2 zeigt die Entwicklungswerkzeuge 210 für die Einrichtungsdaten. Traditionell haben diese Werkzeuge Daten über eine bestimmte zu testende Einrichtung genommen und diese in einer Datenbank gespeichert, die speziell für den Tester kundenspezifisch ausgelegt worden ist. Diese Information definiert derartige Aspekte wie die Stiftgruppen und Zeitsätze. Die Halbleitereinrichtungen haben viele Einrichtungszuleitungen. Oft arbeiten diese Zuleitungen zusammen in Gruppen. Zum Beispiel könnte eine Gruppe einen Adressenbus oder einen Datenbus darstellen. Somit ermöglicht ein Werkzeug, dass Gruppen von Zuleitungen spezifiziert werden. Ein anderes Werkzeug erlaubt, dass eine Korrelation zwischen spezifischen Zuleitungen auf der Einrichtung und Stiften auf dem Tester spezifiziert werden. In einigen Fällen könnte ein spezifischer Teil von Daten durch eine Gleichung definiert werden, die diesen Wert mit anderen Datenwerten in Beziehung setzt. Jedoch sind in dem Stand der Technik die Gleichungsbehandlungsfähigkeiten beschränkt gewesen.
Andere Werkzeuge ermöglichen, dass das Timing von Signalen spezifiziert wird. Jeder Stift 124 kann Signale erzeugen oder messen, die relativ zu Timing „Flanken" definiert sind. Es gibt einen Satz von Timing Flanken für jeden Stift. Jede Flanke kann einmal für jeden ausgeführten Vektor auftreten, Die Zeit, zu der jede Flanke auftritt, kann programmiert werden. Eine programmierte Zeit für jede Flanke für jeden Stift stellt einen Satz von Timingdaten dar. Da die gewünschte Programmierung in unterschiedlichen Bursts oder sogar innerhalb des gleichen Bursts unterschiedlich sein kann, werden gewöhnlicher Weise mehrere Zeitsätze spezifiziert. Jeder Zeitsatz muss eingegeben und gespeichert werden. Diese Information ist traditionell durch ein speziell ausgelegtes Datenbankprogramm eingegeben worden, das für einen spezifischen Tester ausgelegt ist. Die Information, die durch die speziell zugeschnittene Datenbank eingegeben wird, wird in Einrichtungsdaten-Dateien 214 gespeichert.
Ein anderer Typ von Information, der eingegeben werden muss, ist die spezifischen Schritte, die für einen Test ausgeführt werden müssen. Diese Information wird in einer Testschablone 220 spezifiziert. Eine Schablone ist ein Satz von Schritten, die unabhängig von den Werten von irgendeiner spezifischen Einrichtungsdaten-Datei beschrieben wird. Die Testschablonen sind als Datendateien in einem Format aufgezeichnet worden, dass für das spezifische Testsystem definiert ist. Diese Dateien werden allgemein durch den Tester-Hersteller bereitgestellt und typischerweise in einer Programmiersprache, wie beispielsweise der C Programmiersprache, die für schnelle Ausführungsgeschwindigkeiten bekannt ist, geschrieben. In einigen Fällen wird ein Testingenieur die Testschablonen speziell auslegen.
Die Testschablonen werden durch einen Compiler 250 kompiliert. Es wird gewöhnlicher Weise angenommen, dass kompilierte Programme schneller ablaufen als interpretierte Programme. Wegen der Ausführungsgeschwindigkeitsanforderungen in Testern sind kompilierte Testprogramme bevorzugt worden.
Werkzeuge 218 für die Spezifizierung des Flusses (des Ablaufs) erlauben ebenfalls, dass die Reihenfolge von Tests spezifiziert werden. Der Fluss wird als der Programmfluss 222 aufgezeichnet. Traditionell wird der Fluss als eine Reihe von Einträgen in einer Tabelle spezifiziert, könnte aber auch in einer speziellen Programmiersprache sein, die ähnlich wie eine traditionelle Programmiersprache ist.
Um einen Schritt des Flusses (des Ablaufs) zu spezifizieren, kann eine bestimmte Testschablone zusammen mit der Einrichtungsdaten-Datei, die für diese Stufe verwendet werden soll, spezifiziert werden. Einige der Schablonen werden einen auszuführenden Burst spezifizieren. Andere Schablonen werden spezifizieren, dass Ergebnisse von Tests von der Hardware innerhalb des Testers 112 gelesen werden oder, dass die Hardware in einer bestimmten Weise aufgebaut ist. Andere Schritte in dem Fluss sind Steueranweisungen, die beispielsweise Verzweigungs- und Schleifenabarbeitungs-Befehle, so wie man diese in traditionellen Programmiersprachen findet.
Der Programmfluss dient als ein Eingang an einer Spezifizierungs-Ausführungseinheit 224 (einer Einheit für die Spezifizierung bzw. Maßschneiderung der Ausführung). Die Spezifizierungs-Ausführungseinheit 224 füllt die Schablonen, die in dem Programmfluss spezifiziert sind, mit den Daten von den Einrichtungsdaten-Dateien 214 auf. Dies erzeugt ein Testobjekt.
Zur Testzeit verarbeitet die Spezifizierungs-Ausführungseinheit 224 das Testobjekt und steuert tatsächlich den Tester 112. Die Spezifizierungs-Ausführungseinheit 224 sendet Daten und Befehle an den Tester 112 durch die Einrichtungs-Treiber 228. Weil die Geschwindigkeit, mit der die Spezifizierungs-Ausführungseinheit 224 arbeitet, eine große Rolle beim Vorgeben der Gesamttestzeit spielen wird, sind Spezifizierungs-Ausführungseinheiten traditionell in einer Programmiersprache, wie beispielsweise der C-Sprache, die einem Programmierer viele Optionen für eine Spezifikation und deshalb eine Optimierung von ihrer Ausführung gibt, geschrieben worden.
Die Einrichtungstreiber 228 sind Programmierprozeduren, die Information über den Bus 116 zum Steuern der Hardware innerhalb des Testers 112 senden und empfangen. Weil die Einrichtungstreiber 228 eine Hardwaresteuerung auf einer niedrigen Ebene ausführen, sind sie in einer Programmiersprache geschrieben, beispielsweise der C-Sprache, die eine derartige Steuerung erlaubt.
Es ist höchst wünschenswert, dass jede Einrichtung so schnell wie möglich getestet wird. Deshalb ist es wünschenswert, dass der Zeitbetrag, der benötigt wird, um jeden Schritt in dem Programmfluss auszuführen, sehr kurz ist. Die tatsächliche Zeit, die ein Tester 112 oder eine Behandlungseinrichtung 114 benötigt, um auf Befehle anzusprechen oder diese „auszuführen" ist unabhängig von der Software in der Arbeitsstation 110. Jedoch bestimmt die Software in der Arbeitsstation 110 den „Zusatz" oder den Zeitbetrag, der benötigt wird, um jeden Befehl aufzubauen. Beträchtliche Anstrengungen werden durchgeführt, um die Ausführungszeit eines Jobs sehr kurz zu machen. Deshalb ist es sehr wichtig, dass die Zusatzzeit ebenfalls sehr kurz ist. In Systemen des Standes der Technik wurde dies mit einer Spezifizierungs-Ausführungseinheit (Custom Executive) 224 erreicht. Die Spezifizierungs-Ausführungseinheit 224 wird typischerweise in der C Sprache geschrieben. Die C-Sprache wird in einem weit verbreiteten Maß dafür anerkannt, dass sie die Entwicklung einer Ausführungseinheit (Executive) erlaubt, die dafür situiert sein kann um schnell zu arbeiten.
Ein Hauptproblem mit dem Erstellen einer Spezifizierungs-Ausführungseinheit 224 in der C Sprache besteht darin, dass sehr viel Zeit benötigt wird, um eine derartige Ausführungseinheit zu schreiben. Die Kosten könnten im Grunde genommen Millionen von Dollars sein und könnten jahrelange Anstrengungen mit sich bringen. Ein anderes Problem der Bereitstellung einer Spezifizierungs-Ausführungseinheit ist, dass die Benutzerschnittstelle ebenfalls eine speziell ausgelegte Schnittstelle ist. Dies bedeutet, dass ein Ingenieur, der einen Tester betreibt, Zeit investieren muss, um zu lernen, wie der Tester zu programmieren ist, was für die meisten Benutzer unerwünscht ist. Trotzdem sind bislang diese Nachteile als notwendig befunden worden, um einen Tester bereitzustellen, der schnell arbeitet.
Ein anderer Nachteil einer Spezifizierungs-Ausführungseinheit in der C Sprache ist, dass sie wahrscheinlich einen sehr beschränkten Satz von Benutzerschnittstellen-Möglichkeiten aufweist. Die Benutzerschnittstelle ist für Tester, die von Leuten mit sehr unterschiedlichen Fertigkeiten zu verschiedenen Zeiten betrieben werden, von größter Wichtigkeit. Während der Einrichtungs- und Testentwicklung wird der Tester durch einen hoch ausgebildeten Ingenieur betrieben. Sobald die Einrichtung und der Test jedoch entwickelt sind, wird der Tester durch einen Produktionsarbeiter mit normalen Fertigkeiten betrieben. Deshalb muss die Benutzerschnittstelle in der Produktionsanlage stark vereinfacht werden.
Tester haben traditionell keine getrennte Produktionsschnittstellensoftware, die auf der Arbeitsstation 110 läuft. Die Benutzerschnittstelle ist traditionell als ein Menü implementiert worden. Der Testingenieur legt auf das Menü nur diejenigen Befehle, die der Betreiber während eines Produktionstest benötigen sollte. Die Software, die mit dem Tester bereitgestellt wird, hat deshalb nur die Möglichkeit bereitgestellt, dass eine Benutzerschnittstelle in der Form eines Menüs erzeugt wird. Unglücklicherweise sind Menüs hierarchisch, aber viele Operationen sind dies nicht. Deshalb würde es wünschenswert sein, einen Tester mit Software bereitzustellen, die erlaubt, dass eine nicht-hierarchische Schnittstelle schnell und leicht entwickelt wird.
2 zeigt andere Softwareelemente, die in der Arbeitsstation 110 enthalten sind. Die in die Speicher 128 (1) geladenen Vektoren stellen eine große Datenmenge dar. Sie werden gewöhnlicher Weise durch Softwaresimulatoren entwickelt oder in einer automatischen Weise abgeleitet. Sie werden gewöhnlicher Weise nicht manuell durch einen Benutzer eingegeben. 2 zeigt, dass Vektorentwicklungswerkzeuge Simulationseingänge empfangen. Vektorentwicklungswerkzeuge erlauben einem Benutzer die Vektordateien zu editieren, die dann in dem Vektor und den Ergebnisdateien 234 gespeichert werden. Die Vektordateien werden in Speicher 128 vor einem Test geladen.
Genauso, wenn große Datenmengen, die zum Beispiel gemessene Werte an der zu testenden Einrichtung für zahlreiche sukzessive Zyklen darstellen, während eines Tests genommen worden sind, werden sie unter Umständen zurück über den Bus 116 (1) gegeben.
Auf die Vektordateien 234 kann auch mit Debugging- und Analysewerkzeugen 230 zugegriffen werden. Debugging- und Analysewerkzeuge werden durch einen Ingenieur, der einen Test entwickelt oder das Teil entwickelt, welches gerade getestet wird, verwendet. Diese Werkzeuge führen Aufgaben aus, wie das Anzeigen der Vektoren und Ergebnisse graphisch, sie erlauben dem Benutzer die Vektordatei zu modifizieren oder erwartete Werte oben auf gemessene Werte zu überlagern. Zusätzlich könnten die Debugging- und Analysewerkzeuge einem Benutzer ermöglichen die Hardware in dem Tester 112 direkt zu programmieren. Somit rufen sie manchmal die Einrichtungstreiber 228 auf.
In einem typischen Szenarium werden Einrichtungsdaten- und Entwicklungswerkzeuge 212, Test- und Flussentwicklungswerkzeuge 218, Debugging- und Analysewerkzeuge und Testvektor-Entwicklungswerkzeuge 232 mit einem Tester versorgt. Während die Einrichtung, die gerade getestet wird, noch gerade entwickelt wird, verwendet ein Benutzer die Einrichtungsdaten- und Entwicklungswerkzeuge 212, um die Charakteristiken der Einrichtung zu spezifizieren. Test-Flussentwicklungswerkzeuge 218 könnten ebenfalls verwendet werden, um einige Tests zu spezifizieren, die auf der Einrichtung ablaufen gelassen werden sollen.
Probeeinrichtungen werden hergestellt. Die Testprogramme werden ablaufen gelassen und die Debugging- und Analysewerkzeuge werden verwendet, um diese Probeeinrichtungen zu untersuchen. In dem Prozess werden Defekte in den Probeneinrichtungen erfasst oder Probleme mit dem Programm werden erfasst. Diese Probleme werden korrigiert und weitere Tests werden erzeugt und ablaufen gelassen.
Am Ende des Entwicklungsprozesses werden die Halbleitereinrichtung, sowie das Testprogramm, an die Produktion übergeben. In der Produktion wird jedes Teil, sowie es hergestellt wird, getestet.
ZUSAMMENFASSUNG DER ERFINDUNG
Im Hinblick auf den voranstehend angegebenen Hintergrund der Erfindung ist es eine Aufgabe der Erfindung eine Software zum Steuern eines Testers bereitzustellen, die schnell und kostengünstig entwickelt werden kann.
Es ist auch eine Aufgabe eine Software für einen Tester bereitzustellen, die ein Benutzer für die Verwendung leicht und schnell lernen kann.
Die voranstehenden und andere Aufgaben werden in einem Tester erreicht, der kommerziell erhältliche Tabellenblatt-Software (Spreadsheet-Software) verwendet, um Einrichtungsdaten-Dateien, Testschablonen und einen Programmfluss zu entwickeln. Wir haben entdeckt, dass eine kommerziell erhältliche Tabellenblatt-Software in der Lage ist sämtliche von diesen Funktionen bei der erforderlichen Geschwindigkeit und bei sehr geringen Kosten bereitzustellen und zusätzlich die Vorteile der Bereitstellung einer standardmäßigen Benutzerschnittstelle, deren Verwendung Benutzer lernen können ohne ein extensives Training, bereitstellt.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung lässt sich besser unter Bezugnahme auf die folgende ausführlichere Beschreibung und die beiliegenden Zeichnungen verstehen. In den Zeichnungen zeigen:
1 ein Hardware-Blockdiagramm eines herkömmlichen Testers;
2 ein Software-Blockdiagramm von Software für einen herkömmlichen Tester;
3 ein Software-Blockdiagramm von Software in Übereinstimmung mit der Erfindung;
4A bis 9 Einrichtungs-Datenblätter zur Verwendung mit der Erfindung;
10A bis 10C Fluss-Datenblätter zur Verwendung mit der Erfindung;
12A und 12B ein Beispiel einer Testschablone;
13 ein Diagramm, das den Betrieb der Flusssteuersoftware in Übereinstimmung mit der Erfindung darstellt;
14 eine optionale Programmierschnittstelle, die leicht in Übereinstimmung mit der Erfindung implementiert werden kann;
15 ein Beispiel eines Einrichtungs-Datenblatts, welches unter Verwendung eines alternativen kommerziell erhältlichen Tabellenblatt-Programms implementiert ist; und
16A und 16B ein Beispiel eines optionalen Einrichtungs-Daten- und Fluss-Entwicklungswerkzeugs.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
3 zeigt eine einzigartige Softwarearchitektur, die sich aus unserer Erkenntnis ergibt, dass die meisten der Funktionen der speziellen Software in herkömmlichen Testern durch ein kommerziell erhältliches Tabellen-Programm (Spreadsheet-Programm) ausgeführt werden können. In der bevorzugten Ausführungsform wird EXCEL von Microsoft aus Redmond, Washington verwendet.
EXCEL ist ein Spreadsheet-Programm (Tabellen-Programm), das einem Benutzer erlaubt ein „Arbeitsbuch" („Workbook") zu erzeugen. Ein Arbeitsbuch ist eine Ansammlung von Daten, die in unterschiedliche Tabellenblätter organisiert sind. Ein Tabellenblatt ist einfach ein Gitter von Zellen, wobei jede Zelle einen Datenteil oder eine Gleichung, die definiert, wie der Datenwert aus den Werten in anderen Zellen berechnet werden soll, hält. Die Zelle erscheint in einem geordneten Gitter. Die Zellen sind im Allgemeinen derart organisiert, dass verwandte Daten in Zellen erscheinen, die in einer bestimmten Zeile oder einer bestimmten Spalte sind. Die Werkzeuge für Operationen für jede der Zellen sind die gleichen, unabhängig davon, was die Daten darstellen. Innerhalb eines Arbeitsbuchs kann auf irgendeines der Tabellenblätter zugegriffen werden und Daten in einem Tabellenblatt können in einem anderen verwendet werden.
EXCEL umfasst auch Funktionen zum Definieren der Tabellenblätter und zum Entwickeln einer „Anwendung" („Application"). EXCEL ist für Anwendungen, wie beispielsweise die Entwicklung von Buchhaltungssystemen, verwendet worden. Das Erscheinungsbild eines Tabellenblatts kann spezifiziert werden, sodass ein Benutzer nur die Zellen sehen wird, die sich auf eine bestimmte Aufgabe (Task) beziehen. Die Anzeige kann auch in anderen Vorgehensweisen speziell zugeschnitten werden, wobei diese anderen Vorgehensweisen in dem EXCEL Application Developers Guide und Using Excel Visual Basic For Applications by Jeff Webb, veröffentlicht von Que Corporation 1996 ISBN 0-7897-0269-X beschrieben sind.
Eine zweite Vorgehensweise, mit der EXCEL verwendet werden kann, um eine Anwendung zu bilden, ist über die Verwendung von Visual Basic. Visual Basic ist eine Programmiersprache, die in EXCEL eingebaut ist. Wie sein Name vorschlägt ist ein Hauptzweck von Visual Basic das Erscheinungsbild der Tabellenblätter, sowie sie einem Benutzer zum Eingeben von Daten dargeboten werden, zu steuern. Visual Basic wird allgemein verwendet, um zu wählen, welches der Tabellenblätter einem Benutzer zu irgendeiner gegebenen Zeit dargeboten wird, während gerade eine Anwendung ausgeführt wird. Auswahlvorgänge werden allgemein auf Daten oder Befehle gestützt, die durch einen Benutzer eingegeben worden sind, sodass der Benutzer, während irgendeine gegebene Aufgabe (Task) gerade ausgeführt wird, die Daten sieht, die für diese Aufgabe relevant sind. Deshalb umfasst Visual Basic viele Befehle, die verwendet werden können, um zu steuern, wie eine ablaufende Anwendung für einen Benutzer erscheint. Visual Basic umfasst auch Programmierbefehle, die den Programmfluss steuern, beispielsweise bedingte Anweisungen für eine Verzweigung und eine Schleifenabarbeitung.
Wir haben entdeckt, dass Visual Basic verwendet werden kann, um Testschablonen zu schreiben und außerdem die Ausführung von Tests zu steuern, wenn es in der Arbeitsstation eines Halbleitertesters verwendet wird. Insbesondere haben wir entdeckt, dass ein kommerzielles Tabellenblatt-Programm, wie Excel, zugeschnitten werden kann, um ein Testprogramm aus Daten und Testschablonen so schnell zusammenzubauen, dass kein bemerkbarer Geschwindigkeitsverlust beim Ausführen eines Tests im Vergleich mit einer Spezialisierungs-Ausführungseinheit (Custom Executive) vorhanden ist. Mit dieser Erkenntnis sind wir in der Lage gewesen zahlreiche nützliche Eigenschaften zu erzielen. Die Entwicklung einer derartigen Softwareanwendung ist sehr schnell. Zusätzlich ist die Verwendung dieser Anwendung sehr einfach für irgendjemanden, weil die meisten Programmierer mit kommerziellen Tabellenblatt-Programmen vertraut sind. Ferner kann die Testersteuersoftware viele Funktionen bzw. Merkmale, die in ein kommerzielles Tabellenblatt-Programm eingebaut sind, wie kontext-empfindliche Hilfefunktionen und Editierbefehle, vorteilhaft nutzen.
3 zeigt die Einrichtungsdaten- und Fluss-Entwicklungswerkzeuge 310. In der bevorzugten Ausführungsform werden diese Werkzeuge dadurch implementiert, dass Tabellenblätter innerhalb des Excel Arbeitsbuch (Workbook) speziell zugeschnitten werden. Um Einrichtungsdaten zu halten gibt es Tabellenblätter für: eine Stiftkarte, die Pegel der Signale, die an jedem Stift angelegt werden sollen, und die Zeitsätze. Optional könnten andere Tabellenblätter für Daten wie: eine Kanalkarte, eine Spezifikation von verschiedenen konstanten Werten und Flankensätze vorhanden sein. Es können mehrere Tabellenblätter für jeden Typ vorhanden sein, weil unterschiedliche Datenwerte für unterschiedliche Arten von Tests benötigt werden. Jedes Tabellenblatt wird als ein „Datensatz" bezeichnet. Tabellenblätter für Einrichtungsdaten, die in einer bevorzugten Ausführungsform verwendet werden, werden in Verbindung mit den 4A bis 9 nachstehend illustriert.
Der Testfluss wird ebenfalls als ein Tabellenblatt innerhalb des Arbeitsbuchs dargestellt. Der Testfluss wird durch eine Serie von Schritten spezifiziert, die ausgeführt werden. Es gibt Daten, die zu jedem Schritt gehören, und jeder Schritt wird als eine Zeile in einem Tabellenblatt dargestellt. Der exakte Betrieb, der in jedem Schritt ausgeführt wird, könnte durch den Zustand von einem oder mehreren Flags beeinflusst werden. Eine Ausführung eines Schritts könnte bewirken, dass der Zustand von einigen von diesen Flags verändert wird. Dadurch könnte eine Verzweigung oder andere ähnliche Steuerkonstrukte erzielt werden.
Eine der Teile von Daten, die für bestimmte Schritte in dem Fluss spezifiziert werden, bezieht sich darauf, welche Testschablone mit welchem Datensatz verwendet werden soll. Eine Testschablone und die Datensätze zur Verwendung mit dieser Testschablone wird als ein „Exemplar" („Instance") bezeichnet. Exemplare bzw. Instanzen können ebenfalls als ein Tabellenblatt beschrieben werden. Tabellenblätter für eine Flussinformation, die in einer bevorzugten Ausführungsform verwendet werden, werden nachstehend in Verbindung mit den 10 bis 11 dargestellt.
Der Aufbau von jedem der Tabellenblätter wird durch die Software in der Arbeitsstation 110 definiert. Der Aufbau von jedem Tabellenblatt wird durch Spezifizieren einer Schablone unter Verwendung von altbekannten Mechanismen des kommerziellen Tabellenblatt-Programms erzeugt. Die Datenwerte für jedes der Tabellenblätter werden durch einen Testingenieur aufgefüllt und deren Werte werden von dem Typ der Einrichtung, die gerade getestete wird, abhängen.
Die Testersteuersoftware gemäß der Erfindung wird Debugging- und Analysewerkzeuge und Testvektor-Entwicklungswerkzeuge wie in dem Stand der Technik verwenden. Diese Einzelheiten sind zur Vereinfachung in der 3 nicht gezeigt. In der bevorzugten Ausführungsform sind die Vektordateien zu groß, um in einem kommerziellen Tabellenblatt-Programm einfach gehandhabt zu werden. Deshalb werden sie nicht in Excel implementiert.
Bezug nehmend auf die 4A und 4B ist die Anzeige auf der Arbeitsstation 110 gezeigt, während auf ein Stiftkarten-Einrichtungsdatenblatt gerade zugegriffen wird. Die 4A und 4B stellen ein Fenster dar. Das Fenster wird durch die Excelsoftware auf der Arbeitsstation 110 angezeigt. Weil die Excelsoftware durch ein Windows^® NT (eine Marke der Microsoft Corporation) Betriebssystem gesteuert wird, können mehrere Fenster gleichzeitig auf dem Bildschirm angezeigt werden.
Jedes Fenster enthält bestimmte Felder. Das Feld 410 ist als ein Werkzeugbalken bekannt. Das Feld 420 ist als ein Menübalken bekannt. Das Feld 430 ist das Datenzellenfeld. Das Feld 440 ist das Tabulatorfeld. Der Inhalt von diesen Feldern wird in den meisten Fällen als Teil einer Vorbereitung der Software zum Steuern der Arbeitsstation 110 spezifiziert. Jedoch ist die Platzierung und der allgemeine Betrieb von jedem von diesen Feldern für sämtliche Anwendungen, die unter Verwendung von Excel entwickelt werden, standardmäßig. Obwohl gemäß der Erfindung Excel verwendet wird, um ein Halbleitertestsystem zu steuern, werden somit Menschen, die mit Excel oder anderen Excelanwendungen vertraut sind, allgemein verstehen wie die Software zu verwenden ist. Somit stellt die Erfindung im Vergleich mit einem kundenspezifisch zugeschnittenen Softwaresystem beträchtliche Zeit- und Kosteneinsparungen bereit, weil sie so einfach zu verwenden ist.
Der Werkzeugbalken 410 enthält zahlreiche Werkzeugicons, wie die Werkzeugicons 412 und 414. Wie nachstehend mit näheren Einzelheiten beschrieben werden wird, wird das Testprogramm für den Tester 112 größtenteils dadurch spezifiziert, dass Daten in die verschiedenen Tabellenblätter aufgefüllt werden. Trotz der Tatsache, dass die Daten eine Steuerinformation für einen Halbleitertester darstellen, im Gegensatz zu Finanz- oder anderen Typen von Daten, für die ein kommerzielles Tabellenblatt-Programm normalerweise verwendet wird, müssen die Daten in der gleichen Weise manipuliert werden. Somit werden Datenmanipulationswerkzeuge benötigt, können aber die standardmäßigen Datenmanipulationswerkzeuge sein, die mit Excel verwendet werden. Diese Werkzeuge (Tools) führen derartige Funktionen wie das Kopieren von Daten, das Löschen von Daten oder das Speichern des Tabellenblatts auf einer Computerdatei aus. Der Benutzer greift auf diese Werkzeuge dadurch zu, dass eine Eingabeeinrichtung manipuliert wird, beispielsweise eine Maus oder ein Trackball, um ein spezifisches Werkzeugicon zu wählen.
Zusätzlich kann das Feld 410 mit kundenspezifischen Werkzeugen kundenspezifisch zugeschnitten werden. Excel erlaubt, dass kundenspezifisch zugeschnittene Werkzeuge spezifiziert und zu einem Werkzeugbalken hinzugefügt werden. Wenn gewünscht, könnten kundenspezifische Werkzeuge, die Funktionen ausführen, die für die Erzeugung von Testprogrammen einzigartig sind, zu dem Werkzeugbalken 410 hinzugefügt werden. Zum Beispiel könnten einige kundenspezifische Werkzeuge Testprogramme ausführen, während andere Einrichtungsdaten nach Fehlern oder in Fehlübereinstimmungen überprüfen.
Der Menübalken 420 umfasst Systemmenüposten, wie 422 und 424. Diese Posten vergrößern sich, wenn auf sie durch einen Benutzer zugegriffen wird, um mehrere Auswahlmöglichkeiten von Aktionen in Bezug auf den Systemmenüposten bereitzustellen. Zum Beispiel gibt es unter dem Systemmenüposten File (Datei) Auswahlmöglichkeiten wie safe, delete oder print (speichern, löschen oder drucken). Es besteht eine gewisse Überlappung zwischen den Werkzeugen, auf die von dem Werkzeugbalken 410 und dem Menübalken 420 zugegriffen werden kann. Im Allgemeinen erscheinen die gebräuchlichsten Werkzeuge auf dem Werkzeugbalken 410 und werden oft als eine der Wahlmöglichkeiten unter einem der Systemmenüposten dupliziert.
Die meisten Menüposten stellen Funktionen dar, die für die Daten, die für automatische Testsysteme verwendet werden, nicht spezifisch sind. Deshalb können Systemmenüposten, die als eine voreingestellte Bedingung (Default-Bedingung) für Excel Anwendungen bereitgestellt werden, für die meisten der Menüposten verwendet werden. Es gibt jedoch viele Funktionen, die für automatische Testsysteme spezifisch sind. In der bevorzugten Ausführungsform werden diese Funktionen dadurch ausgeführt, dass ein Benutzer Wahlmöglichkeiten aus einem kundenspezifisch zugeschnittenen Menüposten 426 wählt. Excel kann für Anwendungen in Übereinstimmung mit Befehlen, die in dem voranstehend erwähnten Excel Anwendungs-Entwicklungshandbuch bereitgestellt werden, kundenspezifisch zugeschnitten werden. Die kundenspezifischen Menüwahlmöglichkeiten könnten auf den gleichen Menübalken wie die Systemmenübalken oder auf einem getrennten kundenspezifischen Menübalken erscheinen.
Für Datenblätter, die Einrichtungsdaten enthalten, ermöglichen die kundenspezifischen Menüposten, dass die Datenblätter „validiert" werden. Wie voranstehend beschrieben können den verschiedenen Zellen in einem Datenblatt Datenvalidierungsfunktionen zugeordnet sein. Diese Datenvalidierungsfunktionen können unrichtige Datenwerte im Kontext des gegenwärtigen Datenblatts erfassen. Wenn zum Beispiel ein bestimmtes Feld dafür vorgesehen ist, um einen numerischen Wert zu halten, kann ein Fehler erfasst werden, wenn der Eingabewert Buchstaben enthält. Andere Zellen könnten unter Umständen auf nur positive Werte begrenzt werden und ein Fehler wird angezeigt, wenn der Eingabewert negativ ist. Jedoch hängen einige Validierungsfunktionen von mehreren Blättern ab. Zum Beispiel könnte die Gesamtanzahl von Stiften auf einem Blatt spezifiziert werden und bestimmte Attribute könnten für jeden Stift auf einem anderen Blatt spezifiziert werden. Wenn Attribute für zu wenige Stifte spezifiziert worden sind, kann dies nur durch Vergleichen der zwei Blätter erfasst werden. Verschiedene Validierungsfunktionen können auf Grundlage der Anforderungen und Beschränkungen der Tester-Hardware definiert werden. Diese Validierungsfunktionen können aus den kundenspezifischen Menüposten gewählt werden. Alternativ könnten die gleichen Funktionen unter Verwendung von Werkzeugbalken-Tasten gewählt werden.
Für Flussdatenblätter wird zusätzlich gefordert, dass eine Vorgehensweise vorhanden ist, um die Tests auszuführen, die durch den Fluss definiert werden. Kundenspezifische Menüposten, die zu Flussblättern gehören, bewirken, dass der Fluss ausgeführt wird, und bewirken auch die Vorgehensweise der Ausführung. Zum Beispiel könnte es wünschenswert sein Unterbrechungspunkte in die Ausführung des Flusses einzustellen oder den Fluss (Ablauf) mit jedes Mal einem Schritt ablaufen zu lassen. Jede von diesen Funktionen könnte als eine Menüauswahl aus dem kundenspezifischen Menü oder den Werkzeugbalken-Tasten spezifiziert werden.
Die kundenspezifischen Menüposten könnten für jedes der Blätter unterschiedlich sein. Excel erlaubt, dass bestimmte Attribute für jedes Datenblatt spezifiziert werden. Eines von diesen Attributen ist der kundenspezifisch zugeschnittene Menüposten. In dieser Weise kann das kundenspezifische Menü zugeschnitten werden, um nur diejenigen Operationen einzuschließen, die für den spezifischen Typ von Daten, die in einem bestimmten Blatt angezeigt werden, geeignet sind.
Nachstehend werden andere Operationen beschrieben, die durch die Software ausgeführt werden, die den Tester 112 steuert. Diese Operationen können als Funktionen definiert werden, die auf Menüposten abgebildet sind, die auf dem kundenspezifischen Menü erscheinen.
Das Datenzellenfeld 430 enthält Datenzellen, die zum Steuern des Testers 112 speziell ausgelegt sind. Das Zellenlayout wird durch Excel bereitgestellt. Jedoch wird die Anzahl von Zeilen und Spalten, die in dem Fenster sichtbar sind, durch eine Programmierung von Excel vorgegeben. Die 4A und 4B stellen ein Stiftkarten-Datenblatt für die Einrichtung dar. Deshalb enthält das Datenzellenfeld 430 Zeilen und Spalten von den Zellen, die ausgelegt sind, um Stiftkarten-Daten der Einrichtung zu empfangen.
In einem Halbleitertester weist die Einrichtungs-Stiftkarte den physikalischen Stiften 118 (1) logische Namen auf Grundlage davon zu, wie diese Stifte 118 eine Einrichtung, die gerade getestet wird, kontaktieren, während gerade ein Testprogramm ausgeführt wird. Das Datenzellenfeld 430 ist mit vier Spalten von Datenzellen 432A...432D gezeigt. Jeder der Spalten geht eine Zelle voraus, beispielsweise die Anfangsblock-Zelle 434 (Header-Zelle). Die Header-Zelle 434 enthält eine Beschreibung des Typs von Daten, die in die verbleibenden Zellen von dieser Spalte eingefüllt werden sollen. Wenn ein Tabellenblatt in Excel definiert wird, kann bestimmten Zellen, wie beispielsweise den Header-Zellen, ein fester Wert gegeben werden.
Regeln zum Eingeben und Überprüfen von Daten sind in den 4A und 4B nicht sichtbar. Jedoch besteht eine Funktion eines kommerziellen Tabellenblatt-Programms darin, dass Daten validiert werden können, wenn sie in verschiedene Zellen eingegeben werden. Alternativ können einige Datenzellen auf Grundlage der Werte, die in anderen Zellen eingegeben werden, berechnet werden. Kommerzielle Tabellenblätter wurden mit dieser Funktion entwickelt, beispielsweise für das Eingeben von großen Mengen von Finanzdaten. Sogar dann, wenn die Daten zum Steuern eines Testers verwendet werden, werden trotzdem einige Dateneingaberegeln möglich sein und können verwendet werden.
Ein weiteres Feld in den 4A und 4B ist das Tabulator-Feld (Tab-Feld) 440. Das Tabulator-Feld 440 enthält eine Reihe von Tabulatoren, wie 442 und 444. Jeder Tabulator stellt ein Tabellenblatt dar, das innerhalb des Arbeitsbuchs ist, das das Testprogramm enthält. Ein Benutzer wählt, welches Tabellenblatt aktiv ist, und zwar durch Aktivieren von einem der Tabulatoren. In der Darstellung der 4A und 4B ist ein Tabulator 443, der den Namen pinmap.pmp trägt, oben auf den anderen Tabulatoren. Dies ist der gewählte Tabulator, entsprechend zu dem Pinkarten-Tabellenblatt, das in den 4A und 4B gezeigt ist.
Das Tabulator-Feld 440 illustriert einen wichtigen Vorteil zum Einrichten von sämtlichen Einrichtungsdaten als ein Arbeitsbuch. Im Gegensatz zu herkömmlichen Testern, bei denen unterschiedliche Typen von Daten in unterschiedliche Werkzeuge eingegeben wurden, werden sämtliche Einrichtungsdaten in ein Excel Arbeitsbuch eingegeben. Die Bereitstellung von sämtlichen Daten in einem Arbeitsbuch ermöglicht, dass Datenwerte in einem Tabellenblatt von Daten abhängen, die in ein anderes Tabellenblatt eingegeben wurden. Zusätzlich ermöglicht dies, dass eine Person, die ein Testprogramm entwickelt, schnell zwischen den Blättern für unterschiedliche Typen von Daten umschalten kann. Während jede von diesen Operationen möglich gewesen wäre, wenn eine speziell vorgesehene Programmierumgebung für einen Tester richtig entwickelt worden wäre, wird diese Einfachheit bei relativ geringen Kosten und ohne die Komplexität einer Übergabe von Daten von einem Programmierwerkzeug an ein anderes erreicht. Ferner wird dies in einer Weise implementiert, die konzeptionell für einen Programmierer einfach und schnell zu verstehen ist.
Bezug nehmend auf 5 ist ein zweites Einrichtungsdaten-Tabellenblatt gezeigt. Die 5 zeigt ein Fenster auf dem Bildschirm einer Arbeitsstation 110, so wie es erscheinen würde, während gerade Kanalkarten-Daten eingegeben werden. Es ist wichtig darauf hinzuweisen, dass die Bildschirmanzeigen in den 4A/4B und 5 sehr ähnlich sind, obwohl Kanalkarten-Daten sich von Stiftkarten-Daten unterscheiden.
Die Bildschirmanzeige in 5 weist die gleichen Felder wie in den 4A und 4B auf. Der Werkzeugbalken (Symbolleiste) 510 ist der gleiche wie der Werkzeugbalken 410. Der Menübalken 520 ist der gleiche wie der Menübalken 420. Es ist möglich, dass einige Menüposten in dem Menübalken 510 sich von Posten in dem Menübalken 410 unterscheiden werden. Dies wird der Fall sein, wenn bestimmte Funktionen zum Beispiel nur auf die Kanalkarten-Daten anwendbar wären. In diesem Fall würden Menüposten oder Untermenüposten für diese Funktionen nur auf der Menüleiste 510 (Menübalken) erscheinen. In der bevorzugten Ausführungsform werden diejenigen Funktionen, die von dem Typ von Testerdaten in dem Tabellenblatt, welches gerade angezeigt wird, abhängen, als Untermenüposten unter dem kundenspezifischen Menüposten 526 erscheinen. Alternativ kann auf die datenabhängigen Funktionen über kundenspezifische Werkzeugbalkenposten zugegriffen werden.
Es wird bevorzugt, dass das kommerziell erhältliche Tabellenblatt, das verwendet wird, um die Software für den Tester zu implementieren, Funktionen bzw. Merkmale umfasst, die ermöglichen, dass unterschiedlichen Type von Datenblättern definiert werden, und auch ermöglichen, dass Untermenüposten so angezeigt werden, dass sie von dem Typ von verwendetem Datenblatt abhängen.
Es sei darauf hingewiesen, dass jeder Tabulator in dem Tabulator-Feld 540 einen zweiteiligen Namen darauf aufweist. Der erste Teil ist ein Identifizierer für das Tabellenblatt. Der zweite Teil des Namens, oder die Erweiterung, ist der Typ des Tabellenblatts. Zum Beispiel zeigt 5 einen Tabulator, der mit ChannelMap.cmp bezeichnet ist. Sämtliche Arbeitsblätter, die Daten halten, die der Typ ist, der eine Kanalkarte definiert, werden die „.cmp" Erweiterung aufweisen. Jedoch wählt ein Testingenieur den spezifischen Identifizierer. In einer bevorzugten Ausführungsform erlaubt das kommerziell verfügbare Tabellenblatt-Programm, das auf der Arbeitsstation 110 läuft, das ein Anwendungsentwickler spezifiziert, welche Menüposten und Untermenüposten auf dem Menübalken 420 für Tabellenblätter dieses Typs erscheinen.
Bezug nehmend nun auf 6 ist ein Tabellenblatt für ein Spezifikations-Blatt (Spec-Blatt) gezeigt. Wie bei sämtlichen anderen Datenwerkzeugen weist dieses Tabellenblatt einen Werkzeugbalken (Symbolleiste) 610 und einen Menübalken 620 (Menüleiste) und ein Tabulator-Feld 640 auf. Das Tabulator-Feld 640 ist mit dem gegenwärtigen Tabellenblatt gezeigt, das mit „SpecSheet.sps" bezeichnet ist, was hervorgehoben ist. Genauso weist das SpecSheetblatt ein Datenfeld 630 mit vielen Datenzellen auf, die in Zeilen und Spalten organisiert sind. Hier enthält jede Zeile ein Symbol für einen Parameter, der zu einer bestimmten Einrichtung gehört, die sich unter einem Test befindet. Verschiedene Information wird für jeden Parameter gegeben. 6 zeigt sieben Spalten in jeder Zeile des Datenfeld 630. Zusätzlich zu den Symbolnamen umfasst jede Zeile einen Wert, Einheiten für diesen Wert, ein Textfeld für eine Beschreibung des Symbols, minimale und maximale Werte für einen richtig arbeitenden Teil und ein Kommentarfeld. Weil die Datenblätter alle in einem einzelnen Excel Arbeitsbuch entwickelt werden, kann auf diese Symbole über den Namen in den anderen Trabellenblätter Bezug genommen werden. Insbesondere können die Parameter, die zu jedem Symbol gehören, auch in anderen Tabellenblättern verwendet werden. Zusätzlich kann der Name Spec Sheetblatt als ein Parameter an eine spezifische Testschablone übergeben werden, wenn ein Testexemplar gerade entwickelt wird. Dies erlaubt der Testschablone Vergleiche mit dem Spec Sheet Daten durchzuführen, um beispielsweise zu bestimmen, ob die Einrichtung, die gerade getestet wird, innerhalb der Spezifikation arbeitet (d.h. dass sie den Test bestanden hat oder durchgefallen ist).
6 zeigt ein einzelnes Spezifikationsblatt. Es ist möglich, dass unterschiedliche Spezifikationen für unterschiedliche Typen von Tests innerhalb eines einzelnen Jobs benötigt werden. Deshalb könnten mehrere Spezifikationsblätter verwendet werden. Wie nachstehend in Verbindung mit dem Datenmanager 316 (Data Manager) beschrieben, werden Vorkehrungen getroffen, um mehrere Sätze von Daten eines bestimmten Typs bereitzustellen.
7 zeigt ein weiteres Einrichtungsdaten-Blatt, das zum Definieren von Flankensätzen verwendet wird. Wie in 1 gezeigt umfasst der Tester 112 mehrere Stifte 124. Jeder Stift umfasst mehrere Schaltungen, die als Flankengeneratoren bezeichnet sind und die jeweils eine Flanke erzeugen. Eine Flanke ist ein Signal, welches verwendet wird, um irgendeine Aktion durch einen Stift 124 zeitlich zu steuern. Zum Beispiel könnten vier Flankensignale vorhanden sein, die derartige Parameter wie die Start- und Stoppzeit eines Impulses, der durch den Stift erzeugt wird, steuern. Die Zeit, zu der jede Flanke erzeugt wird, kann programmiert werden. Die Zeiten, zu denen jede Flanke für einen Stift programmiert sind, werden als ein Flankensatz definiert. Weil sich die Zeit, zu der die Flanken für einen bestimmten Stift programmiert sein sollen, während eines Jobs ändern könnte, können mehrere Flankensätze für jeden Stift vorhanden sein.
7 zeigt einen Flankensatz für einen Stift. Die Spalte 750 zeigt, dass der Stift, für den der Flankensatz spezifiziert ist, mit „QDataPins" bezeichnet ist. Die Flankensätze für andere Stifte könnten durch Hinzufügen von weiteren Zeilen zu dem Datenfeld 730 hinzugefügt werden. Die Spalte 752 zeigt einen Flankensatz für den Stift QDataPins als „LooseFunctions 1" („Losefunktionen 1") bezeichnet wird.
Andere Flankensätze könnten durch Hinzufügen durch weitere Zeilen zu dem Datenfeld 730 definiert werden.
Die Spalten 754 und 756 geben eine andere Information an, die benötigt wird, um die Stifte 124 aufzubauen, um ein gewünschtes Signal zu erzeugen. Die Spalte 758 listet Flanken innerhalb des Stifts auf und die angrenzenden Spalten 760 und 762 geben Werte für die Zeiten an, zu denen diese Flanken auftreten.
Die Spalten 760 und 762 illustrieren einen nützlichen Vorteil zum Steuern des Testers 112 mit einem kommerziell erhältlichen Tabellenblatt. Das Tabellenblatt kann automatisch einen Wert aus einer Gleichung berechnen. Somit erlaubt die Spalte 762, dass der Zeitwert für jede Flanke als eine Gleichung in Bezug auf andere Konstanten oder Parameter, die in anderen Tabellenblättern definiert sind, spezifiziert wird. Die Spalte 760 zeigt den numerischen Wert, der entweder für dieses Feld programmiert ist oder automatisch durch das Tabellenblatt-Programm durch Auswerten der Gleichung in der Spalte 762 berechnet wird.
Die Zellen 766, 768, 770 und 772 zeigen andere Vorteile, die durch Verwenden eines kommerziell erhältlichen Tabellenblatt-Programms erhalten werden können. Herunterzieh-Auflistungsboxen (Dropdown-Auflistungsboxen) in dem Datenfeld 730 können verwendet werden, um die Anzeige oder Werte von Datenzellen in dem Datenfeld 730 zu steuern. Dropdown-Auflistungsboxen 766, 768, 770 und 772 werden in dieser Weise verwendet. Diese Zellen werden als Dropdown-Boxen implementiert, die ein Standardobjekt in Excel sind. Jede Dropdown-Box kann einen einer festen Anzahl von Werten aufweisen. Die Werte können spezifiziert werden als eine feste Liste oder durch Bezugnahme auf Werte, die in ein Blatt der Tabellenblätter innerhalb des Arbeitsbuchs eingegeben werde, und die sich ändern würden, sich die eingegebenen Werte ändern.
Wenn eine große Anzahl von Stiften in dem Tester 112 gegeben sind, könnte ein Flankensatz-Tabellenblatt potenziell viele Zeilen enthalten. Die Zellen 766, 768, 770 und 772 können verwendet werden, um die Datenmenge einzuschränken, die zu einer Zeit angezeigt wird. Die Zelle 766 enthält den Namen eines bestimmten Stifts oder einer bestimmten Stiftgruppe. Nur Flankensätze für diesen Stift oder Stifte innerhalb dieser Gruppe werden in dem Datenfeld 730 angezeigt. In einer ähnlichen Weise zeigen die Zellen 768 und 770 Flankensätze für einen bestimmten Timingmodus und für nur eine gewählte Anzahl von Flanken an. Die Zelle 772 ist in ähnlicher Weise eine Dropdown-Box, wird aber verwendet, um die Einheiten für Werte zu spezifizieren, die in die Wertespalte 760 eingegeben werden.
8A zeigt ein anderes Tabellenblatt innerhalb des Excel Arbeitsbuchs. Das Blatt in 8A gibt Daten für einen Zeitsatz und ist in dem gleichen Format wie andere Datenblätter. Ein Zeitsatz ist eine Sammlung von Flankensätzen, und zwar jeweils eine für jeden der Stifte 124. Mehrere Zeitsätze werden oft definiert, sodass unterschiedliche programmierte Zeit innerhalb eines Jobs verwendet werden könnten.
8A zeigt Spalten, die eine Eingabe von Daten auf den Namen eines Zeitsatzes, der Periode, die zu diesem Zeitsatz gehört, und eines Stifts oder einer Stiftgruppe erlauben. Für jeden Stift oder jede Stiftgruppe gibt es eine Zeile in der Tabelle. Für jeden Stift oder jede Stiftgruppe gibt es Spalten, die erlauben, dass die programmierte Zeit für Flanken dieses Stifts entweder durch Bezugnahme auf einen Flankensatz oder auf eine Gleichung spezifiziert wird. 8A zeigt auch Dropdown-Boxen 832A und 834A. Die Dropdown-Box 832A wählt, welche Zeitsätze angezeigt werden. Die Dropdown-Box 834A spezifiziert die Einheiten, in denen sämtliche Zeitwerte angezeigt werden.
8B zeigt einen andere Vorteil, der sich aus einer Verwendung eines kommerziell erhältlichen Tabellenblatt-Programms ergibt. Mehrere Tabellenblatt-Schablonen können für die gleichen Daten definiert werden. Die Bereitstellung von mehreren Schablonen für das gleiche Tabellenblatt erlaubt, dass die gleichen Daten unterschiedlich angezeigt werden, um einem Benutzer zu ermöglichen die Daten in einem Format zu sehen, das für die jeweilige Aufgabe, mit der der Benutzer gerade arbeitet, am Nützlichsten ist. 8B zeigt eine alternative Schablone zum Anzeigen von Flankensatzdaten. Sie weist eine Dropdown-Box 832B auf, genauso wie die Dropdown-Box 832A. Sie weist auch ein Datenfeld 830B auf ähnlich wie das Datenfeld 830A. Jedoch sind die Spalten in den Datenfeldern 830A und 830B unterschiedlich organisiert.
Die Schablone, die in 8A dargestellt ist, könnte zum Beispiel dazu verwendet werden, um Stiftgruppen spezifischen Zeitsätzen zuzuweisen. Die Schablone in 8B könnte zum Beispiel verwendet werden, um zu bestimmen, welchem Flankensatz jeder Stift zugewiesen worden ist. In einer bevorzugten Ausführungsform könnte die Schablone in 8B eine Nur-Lese-Schablone sein.
9 zeigt noch einen anderen Typ von Daten, die durch einen Benutzer in einem konsistenten Format leicht eingegeben werden können. Es sei darauf hingewiesen, dass 9 den gleichen Werkzeugbalken (Symbolleiste) und Menübalken (Menüleiste) zeigt, wie für andere Tabellenblätter verwendet. 9 zeigt ein Tabellenblatt zum Spezifizieren von Pegeln, die zu verschiedenen benannten Parametern gehören. Die Parameter sind höchstwahrscheinlich Spannungs- und Strompegel, die zu verschiedenen Messungen oder Anregungssignalen gehören. Excel erlaubt, dass auf diese benannten Parameter über den Namen in anderen Tabellenblättern Bezug genommen wird. Es erlaubt auch, dass Werte der Parameter durch eine Gleichung spezifiziert werden, die andere benannte Werte beinhalten.
Bezug nehmend auf 10A kann einer der Vorteile der Erfindung beobachtet werden. 10A zeigt ein „Flusstyp" Tabellenblatt. 10A stellt die Vorgehensweise dar, mit der Test „Exemplare" für einen bestimmten Test definiert werden. Ein Halbleitertestsystem wird allgemein benötigt, um einen Test für eine begrenzte Anzahl von Aspekten vorzunehmen. Zum Beispiel könnte das Testsystem einen Muster „Burst" ablaufen lassen. Während eines Bursts legt der Tester eine spezifizierte Anregung an und prüft nach bestimmten erwarteten Antworten. Die Werte für die Anregung und die Antworten werden in einer „Vektordatei" spezifiziert. Verschiedene Werte in der Vektordatei werden verwendet, um unterschiedliche Arten von Teilen zu testen oder um unterschiedliche Tests für das gleiche Teil ablaufen zu lassen. Jedoch sind die Betriebsvorgänge, durch die der Tester geht, um eine Vektordatei zu verwenden, im Allgemeinen die gleichen, unabhängig von den spezifischen Datenwerten darin.
Die Serie von Schritten, die das Testsystem durchlaufen muss, um einen Musterburst ablaufen zu lassen, werden als eine „Schablone" codiert. Eine Schablone ist eine Reihe von Schritten, die ausgeführt werden müssen mit der Programmierung equivalent zu Leerstellen für eine Beschreibung der spezifischen Vektordatei oder anderen Daten, die benötigt werden. In dieser Weise kann die Schablone für irgendeinen Test verwendet werden, sobald die spezifischen Datenwerte, die sie verwenden soll, spezifiziert sind.
Sobald die Daten zur Verwendung mit einer spezifischen Schablone spezifiziert worden sind, ist ein „Exemplar" der Schablone erzeugt worden. Das Exemplar kann in dem Programm verwendet werden.
Ein Testerhersteller stellt allgemein mehrere Testschablonen als Teil seiner Steuersoftware bereit. Die Testschablonen könnten verwendet werden, um einen Musterburst ablaufen zu lassen oder um eine Leckstrommessung durchzuführen, wobei DC Pegel auf den Zuleitungen einer Einrichtung, die gerade getestet wird, oder andere Testeroperationen überprüft werden. Wie nachstehend mit näheren Einzelheiten beschrieben werden wird sind die Schablonen der bevorzugten Ausführungsform in Visual Basic, was eine Programmiersprache ist, die zu einem Excel Tabellenblatt-Programm gehört. Jede Schablone ist in einer Visual Basic Prozedur geschrieben und Datenwerte werden als Argumente zu der Prozedur spezifiziert.
10A zeigt die Vorgehensweise, mit der Programm-Exemplare erzeugt werden. Das Datenfeld 1030 enthält eine Spalte 1032A zum Auflisten des Namens der Exemplare, die in einem Testjob verwendet werden könnten. Die Spalte 1032B enthält den Namen der Schablone, die zum Erzeugen des Exemplars (der Instanz) verwendet wird.
10B zeigt wie spezifische Daten zu einer Schablone gehören. Excel umfasst eine Programmierfunktion, die erlaubt, dass eine Dialogbox 1036 einer spezifischen Zelle in dem Datenfeld 1030 zugeordnet wird. Eine andere Dialogbox kann in Abhängigkeit von dem Wert in der Zelle oder irgendeiner anderen Zelle gewählt werden. Zum Beispiel ist in 10B die Dialogbox 1036 zu der Zelle 1034 zugeordnet gezeigt. Die Zelle 1034 ist der Name eines Exemplars, das durch Zuordnen von spezifische Datenwerten zu der Schablone, die in der Zelle 1035 aufgelistet ist, erzeugt werden soll. In diesem Beispiel wird das Format der Dialogbox 1036 auf Grundlage der Schablone gewählt, die in der Zelle 1035 aufgelistet ist.
Die Dialogbox 1036 enthält Bereiche 1038 und 1050, jeweils mit Feldern, in denen bestimmte Datenwerte, die der Schablone in der Zelle 1035 zugeordnet werden sollen, aufgelistet sind. Der Bereich 1038 enthält erforderliche Felder. Der Bereich 1050 enthält optionale Felder. Um das Testexemplar mit der Bezeichnung „ 30Mhzfunc" zu erzeugen, werden die Werte in der Dialogbox 1036 als Argumente an die Schablone übergeben, die mit „functional" („funktional") benannt ist.
10B zeigt, dass das Datenfeld 1030 viele Zeilen enthält. Es gibt eine Zeile für jedes Testexemplar, das in dem Testjob benötigt wird. Es sei darauf hingewiesen, dass die Schablone, die mit „functional" bezeichnet ist, verwendet wird, um zwei unterschiedliche Instanzen (Exemplare) zu erzeugen. Unterschiedliche Exemplare werden mit der gleichen Schablone durch Spezifizieren von anderen Argumenten in der Dialogbox 1036 erzeugt.
Die 10A und 10B zeigen Schritte beim Spezifizieren des Testflusses. Es sei jedoch darauf hingewiesen, dass die Benutzerschnittstelle die gleiche wie die Benutzerschnittstelle für die Datentabellenblätter der 4 bis 9 ist. Somit wird kein spezielles Training benötigt, um den Programmfluss zu spezifizieren. Es sei auch darauf hingewiesen, dass die Argumente, die in der Dialogbox 1036 eingegeben sind, vorwiegend die Namen von anderen Tabellenblättern oder Werten, die innerhalb von Tabellenblättern definiert sind, sind. Somit werden die Einrichtungsdaten leicht mit der Programmflussinformation kombiniert, wobei beträchtlich an der Softwareentwicklungszeit gespart wird.
Dieser Nutzen ergibt sich aus der Tatsache, dass sowohl Einrichtungsdaten als auch der Programmfluss in Tabellenblättern (Spreadsheets) dargestellt werden.
Eine andere Programmflussinformation wird in ein Tabellenblatt eingegeben, das in 11A gezeigt ist. Sobald die Exemplare definiert sind, muss die Reihenfolge spezifiziert werden, in der sie ausgeführt werden. Weil die Exemplare Tests innerhalb eines Testjobs beschreiben, muss die Information zusätzlich auch darüber bereitgestellt werden, welche Ereignisse auftreten, wenn ein Testexemplar bestanden wird oder fehlschlägt. All diese Information wird durch einen Benutzer in ein Tabellenblatt unter Verwendung der gleichen Schnittstelle wie bei den anderen Fluss- und Einrichtungsdaten-Tabellenblättern eingegeben.
Innerhalb des Datenfelds 1130 gibt es mehrere Spalten, die Informationen halten, die für jeden Schritt in dem Testjob spezifiziert werden muss. Jede Zeile in den Datenfeld 1130 enthält Informationen über einen Schritt in dem Testjob. Die Spalte 132 ist mit „OPCODE" bezeichnet. Diese Spalte zeigt an, was bei dem spezifizierten Schritt passieren soll. Im Allgemeinen ist jeder Eintrag in der OPCODE Spalte 132 ein Testexemplar.
Die Spalte 1134 enthält eine Schrittnummer in dem Test. Schrittnummern können durch das Testsystem verwendet werden, um über die Ausführung des Tests zu berichten. Wenn zum Beispiel ein Defekt während eines Tests erfasst wird, dann könnte die Schrittnummer, bei der der Defekt erfasst wurde, berichtet werden.
Die Spalte 1136 enthält eine Übergabe-Behälter-Nummer. Wenn jede Einrichtung getestet wird, weist ein Tester im Allgemeinen der Einrichtung, die gerade getestet wird, eine „Behälter" als Nummer (Zahl) entsprechend zu dem Ergebnis des Tests zu. Die Behälter-Nummer zeigt eine Beurteilung des Teils an. Zum Beispiel werden einige Behälter-Nummern Teile darstellen, die gemäß der Einrichtungsspezifikation arbeiten. Andere Behälter-Nummern könnten Teile anzeigen, die so defekt sind, dass sie nutzlos sind. Noch andere Behälter-Nummern könnten Einrichtungen anzeigen, die nicht innerhalb der Spezifikation arbeiten, aber ausreichend funktional sind, um auf eine reduzierte Spezifikation zu arbeiten. Der Testingenieur weist die Behälter-Nummern unter deren Bedeutung zu.
Die Spalte 1138 ist ähnlich. Sie enthält eine Behälter-Nummer, die zugewiesen wird, wenn der Test fehlschlägt.
Das Datenfeld 1130 könnte andere Spalten über das hinaus, was gezeigt ist, enthalten. 11B zeigt ein Flussblatt mit einem Datenfeld 1130B, das mit mehr Spalten von Information für eine kompliziertere Flusssteuerung erweitert ist. Zum Beispiel enthält das Datenfeld 1130B Flag-Felder 1156 und 1158. Das Flag-Feld 1156 enthält optional das gleiche Flag oder die Bool'sche Variable, die auf „wahr" gesetzt wird, wenn der spezifizierte Test in einem Schritt bestanden wird. Das Feld 1158 ist ähnlich, enthält aber den Namen eines Flags, das gesetzt wird, wenn der Test fehlschlägt.
Andere Spalten in dem Datenfeld 1130B könnten für kompliziertere Flüsse für den Fall verwendet werden, dass mehrere Einrichtungen gleichzeitig getestet werden. Zum Beispiel zeigt die Spalte 1152 an, auf welche der Einrichtungen der Schritt angewendet wird, der in irgendeiner Zeile spezifiziert wird. Ein bestimmter Test könnte auf sämtliche Einrichtungen angewendet werden. Andere Tests könnten nur für die Einrichtungen ablaufen gelassen werden, die sämtliche vorangehenden Tests bestanden haben. Andere Tests könnten nur mit Einrichtungen ablaufen gelassen werden, die einen früheren Test nicht bestanden haben.
Die Spalte 1154 spezifiziert, auf welche Einrichtungen die Ergebnisse des Tests angewendet werden sollen.
Andere Spalten als diejenigen, die gezeigt sind, könnten ebenfalls verwendet werden. Es könnte eine Spalte vorhanden sein, die Bedingungsfelder enthält, die auf einen Bool'schen Ausdruck vor der Ausführung des Test-Exemplars in diesem Schritt ausgewertet werden. In dieser Weise können bedingte Programmflüsse implementiert werden. Diese Funktion könnte mit der Spalte 1152 kombiniert werden, indem ihr erlaubt wird Bool'sche Ausdrücke anzunehmen. Ein Bool'scher Ausdruck, der auf wahr ausgewertet wird, würde anzeigen, dass der Test für sämtliche Einrichtungen ausgeführt werden würde. Im Gegensatz dazu, wenn der Ausdrck auf unwahr ausgewertet wird, dann würde der Test nicht für sämtliche Einrichtungen ausgeführt werden. Hybride Situationen würden ebenfalls möglich sein, wenn ein Bool'scher Ausdruck für jede Einrichtung spezifiziert werden könnte. In dem Beispiel der 11B umfasst die Spalte 1152 einige Werte, die einen konstanten Wert von „alle" einschließt. Ein derartiger Wert zeigt an, dass der Test, auf den in dieser Zeile Bezug genommen wird, für sämtliche Einrichtungen bedingungslos ausgeführt werden soll. Andere Zeilen zeigen jedoch Bool'sche Ausdrücke, die sich auf Flags beziehen, die in den Spalten 1154 oder 1158 in früheren Zeilen aufgelistet sind. Zusätzlich könnte er eine Spalte enthalten, in der die Zelle auf einen bestimmten Wert gesetzt werden könnte, um wie ein Debugging-Unterbrechungspunkt zu wirken.
Die in 11B gezeigte Information ist ähnlich zu derjenigen, die spezifiziert werden muss, um einen existierenden Tester zu programmieren. Jedoch wird die Flussinformation der 11B in Zeilen organisiert, wobei jede Zeile Spalten mit Arten von Informationen in jeder Spalte enthält. Im Vergleich dazu, dass die Flussinformation bereitgestellt wird, die in einer Textdatei gespeichert wird, ist die Zeilen- und Spalten-Organisation, die aus der Verwendung eines kommerziell erhältlichen Tabellenblatt-Programms kommt, sehr viel intuitiver für einen Programmierer, wodurch der Programmierer in die Lage versetzt wird das Programmieren eines Flusses schneller zu lernen. Ein zweiter Vorteil ist, dass der Aufbau und die Werkzeuge zum Manipulieren der in 11B gezeigten Flussinformation durch das kommerziell erhältliche Tabellenblatt-Programm bereitgestellt wird. Somit kann eine Entwicklung der Software schnell durchgeführt werden.
11C zeigt eine alternative Vorgehensweise, mit der eine Flusssteuerinformation spezifiziert werden kann. 11C zeigt eine Pop-Up-Optionsbox, die verwendet werden kann, um Optionen zu spezifizieren, die die Option der unteren Steuersoftware 314 (3) modifizieren. Optionen werden durch einen menschlichen Testingenieur durch Anklicken der Wahlmöglichkeiten in der Dialogbox spezifiziert. Zum Beispiel verursacht die „Do All" („Alles Ausführen") Option, dass die Flusssteuersoftware 314 sämtliche Schritte in dem Programmfluss ausführt, sogar wenn ein Schritt fehlschlägt. Wenn diese Option nicht gewählt wird stoppt der Test von einem bestimmten Teil, sobald einer der Tests fehlschlägt. Als ein anderes Beispiel verursacht die „Print Final" Option, dass die Ergebnisse des Tests gedruckt werden, sobald der Testjob abgeschlossen ist. Wenn sie nicht gewählt wird, dann werden die Ergebnisse nicht gedruckt, sondern gespeichert, bis sie von einem Benutzer gelesen werden. Als ein weiteres Beispiel bewirkt die „Do Time" Option, dass die Flusssteuersoftware die Zeit beim Start eines Jobs und auch bei dem Ende eines Jobs aufzeichnet, sodass die Zeitspanne, die der Job benötigt hat, aufgezeichnet werden kann. Wie nachstehend beschrieben wird das Flussdatenblatt in eine Flussdatenstruktur umgewandelt. Die spezifizierten Optionen beeinflussen die exakte Vorgehensweise, mit der diese Umwandlung durchgeführt wird.
Die 12A und 12B zeigen ein Beispiel einer Testschablone. Die Testschablone ist in Visual Basic geschrieben, einer Programmiersprache, die verwendet werden kann, um Makros zu schreiben, die an ein Tabellenblatt angehängt werden. Jeder Makro könnte als eine Prozedur in einer Programmiersprache verwendet werden und kann deshalb als Testschablonen verwendet werden.
Mehrere wichtige Punkte können in den 12A und 12B erkannt werden. Zunächst ist die gesamte Programmierumgebung die gleiche wie diejenige, die verwendet wird, um Informationen in die Einrichtungsdaten- und Fluss-Tabellenblätter einzugeben. Sie hat den gleichen Werkzeugbalken 1210, den gleichen Menübalken 1220 und das gleiche Tabulator-Feld 1240. Anstelle eines Datenfelds umfasst der Testschablonen-Bildschirm jedoch Zeilen eines Programmcodes.
Jede Zeile eines Programmcodes könnte andere Prozeduren aufrufen, die durch den Test der Hersteller entwickelt oder durch den Benutzer geschrieben werden. Die Linien 1250 und 1254 stellen Aufrufe an Funktionen dar, die durch den Test der Hersteller bereitgestellt werden. An der Zeile 1250 ist „PinHi" eine Prozedur, die auf einen der Einrichtungstreiber 328 (3) zugreift und spezifizierte Stifte auf einen hohen Zustand einstellt. An der Zeile 1254 ist „StartPatgen" eine ähnliche Funktion, die einen Ablauf der Timing- und Ablaufsteuerungs-Schaltung 120 (1) startet.
Die 12A und 12B zeigen ebenfalls einen Debugging-Werkzeugbalken 1232. Wenn eine neue Halbleitereinrichtung zunächst gerade entwickelt wird, ist es für den Einrichtungsingenieur erforderlich dass tatsächliche Betriebsverhalten der Einrichtung zu messen, um zu beurteilen, ob sie richtig konstruiert worden ist. Wenn ein Defekt erfasst wird möchte der Einrichtungsingenieur in der Lage sein genau herauszufinden, was schief gegangen ist. Um dies zu tun, verwendet der Einrichtungsingenieur den Tester in einem „Debugging-Modus". Der Einrichtungsingenieur steuert den Tester, um zu einer Zeit einen Betrieb derart auszuführen, dass die Ergebnisse von jedem Betrieb analysiert werden können. Der Debugging-Werkzeugbalken 1232 enthält Werkzeuge, die während Debugging-Operationen verwendet werden. Der Debugging-Werkzeugbalken 1232 ist vorzugsweise als Teil des kommerziell erhältlichen Tabellenblatt-Programms bereitgestellt.
Der Debugging-Werkzeugbalken 1232 enthält Werkzeuge, die verschiedene Debugging-Funktionen ausführen. Zum Beispiel stellt das Werkzeug 1234 einen Unterbrechungspunkt in dem Code ein. Die Linie 1254 ist hervorgehoben, um anzuzeigen, dass auf dieser Zeile ein Unterbrechungspunkt gesetzt ist. Während der Ausführung eines Tests stoppt die Ausführung vor der Ausführung einer Zeile, die mit einem Unterbrechungspunkt markiert ist. Der Einrichtungsingenieur kann dann den Zustand des Testers oder die Einrichtung überprüfen.
Sobald eine Ausführung an einem Unterbrechungspunkt gestoppt ist, steuern andere Werkzeuge auf dem Debugging-Werkzeugbalken 1232, wie die Ausführung fortgesetzt wird. Zum Beispiel erlaubte das Werkzeug 1236 der Ausführung in jeder Prozedur, die folgt, Schritt-für-Schritt voranzugehen. Im Gegensatz dazu erlauben andere Werkzeuge, dass Prozeduren übersprungen werden, während noch andere Werkzeuge erlauben, dass bestimmte Werte untersucht werden. In dieser Weise kann der Einrichtungsingenieur viel über den Betrieb der Einrichtung lernen. Die gleichen Debugging-Werkzeuge können durch einen Testingenieur, der einen Test für die zu testende Einrichtung entwickelt, verwendet werden. In einer signifikanten Weise werden sämtliche von diesen Möglichkeiten bei sehr geringen Kosten durch Verwendung eines kommerziell erhältlichen Tabellenblatt-Progamms, dem eine Programmiersprache mit Debugging-Werkzeugen zugeordnet ist, bereitgestellt.
Sobald die Daten- und Flussinformation für einen Testjob durch einen Testingenieur oder einen anderen Benutzer des Systems eingegeben ist, kann die Software in der Arbeitsstation 110 ablaufen gelassen werden, um einen Testjob zu steuern. Wie in 3 gezeigt, wird die Ausführung des Testjobs durch die Flusssteuersoftware 314 im Ansprechen auf eine Benutzereingabe ausgeführt. In der dargestellten Ausführungsform ist die Flusssteuersoftware 314 als ein C++ Programm implementiert. Insbesondere ist sie eine DLL.
13 ist ein Flussdiagramm, das den Betrieb der Flusssteuersoftware 314 erläutert. Die Flusssteuersoftware 314 beginnt in einem Leerlaufzustand 1310. Die Flusssteuersoftware 314 kann eine von drei unterschiedlichen Aktionen, in Abhängigkeit von Eingängen an die Software, ausführen. Eine Aktion, die die Flusssteuersoftware 314 vornehmen könnte, besteht darin die Daten für einen Testjob in eine Datenstruktur hinein zu organisieren, auf die während eines Testjobs zugegriffen werden kann. Wie in Verbindung mit den 10 und 11 beschrieben wird ein Testjob als eine Liste von Exemplaren spezifiziert und Exemplare werden durch eine Zuordnung von bestimmten Einrichtungsdaten an bestimmte Schablonen spezifiziert. Zusätzlich könnte die Reihenfolge, in der die spezifischen Exemplare ausgeführt werden, durch Bedingungen beeinflusst werden, die in das Programmfluss-Datenblatt eingegeben werden.
Im Ansprechen auf einen Benutzerbefehl bildet die Flusssteuersoftware 314 eine Jobsteuerungs-Datenstruktur, die jede Schablone, die ausgeführt werden soll, und die Daten, die für die Ausführung dieser Schablone verwendet werden sollen, auflistet. Wenn die Reihenfolge der Ausführung der Schablonen aus den Bedingungen bestimmt werden kann, wird sie aufgelöst, bevor die Schablonen in die Jobsteuerungs-Datenstruktur platziert werden. Wenn jedoch die Reihenfolge einer Ausführung der Schablonen nicht aufgelöst wird, bis der Testjob ablaufen gelassen wird, umfasst die Jobsteuerungs-Datenstruktur einfach Information über die Bedingungen, die ausgewertet werden, um die Reihenfolge zu bestimmen, in der die Schablonen ausgeführt werden. Die Jobsteuerungs-Datenstruktur könnte eine indizierte Liste sein, aber auch andere Implementierungen sind möglich.
Beim Aufbauen der Jobsteuerungs-Datenstruktur geht eine Ausführung weiter zum Schritt 1312. In dem Schritt 1312 wird die erste Schablone bestimmt. Die Schablone wird aus dem ersten Exemplar in dem Fluss-Datenblatt bestimmt. Die Schablone, die zu diesem Exemplar gehört, wird aus dem Exemplar-Datenblatt bestimmt. Eine Notation für die Schablone wird in die Jobsteuerungs-Datenstruktur eingegeben. In einer bevorzugten Ausführungsform zeigt die Notation den Namen des Unterprogramms, welches aufgerufen werden soll, um die Schablone auszuführen, an.
Im Schritt 1314 werden die Daten, die auf den Aufruf des gewählten Schablonen-Unterprogramms übergeben werden, identifiziert. Welche Daten zu verwenden sind wird aus dem Exemplar-Datenblatt bestimmt.
Im Schritt 1316 wird eine Identifikation der Daten, die für die spezifizierte Testschablone verwendet werden sollen, zu der Jobsteuerungs-Datenstruktur hinzugefügt. Wie in 3 gezeigt übergibt der Datenmanager Daten von dem Excelarbeitsbuch an die Einrichtungstreiber für eine Anwendung auf den Tester 112 (1). Wie nachstehend noch näher beschrieben werden wird, baut der Datenmanager 316 Parameter-Datenstrukturen zusammen, die die spezifischen Daten halten, die an den Tester 112 während eines Testjobs übergeben werden. Die Daten in der Parameter-Datenstruktur sind in „Behältnisse" („container") organisiert, sodass die richtigen Daten außer der Parameter-Datenstruktur dadurch gewählt werden können, dass die Daten mit dem Namen des richtigen „Behältnisses" versehen werden. Die Argumente, die zu der Flusssteuerungs-Datenstruktur hinzugefügt werden sollen, spezifizieren das richtige „Behältnis", das der Datenmanager 316 aus der Parameter-Datenstruktur wählt. Diese Information wird in einer bevorzugten Ausführungsform als eine Textkette dargestellt, die auf Grundlage des Namens gewählt ist, der dem Datenblatt gegeben ist. Die gleiche Textkette gehört zu dem Behälter. Jedoch könnten alternativ andere Vorgehensweisen gewählt werden, um ein Behältnis zu identifizieren.
Zusätzlich zu Argumenten, die die Namen von „Behältnissen" darstellen, könnten durch eine bestimmte Schablone auch Argumente verwendet werden, die Datenwerte sind, und könnten auch zu der Parameter-Datenstruktur hinzugefügt werden.
Sobald eine Information zum Identifizieren der Schablonen und der Datenwerte zu der Jobsteuerungs-Datenstruktur hinzugefügt sind, geht die Ausführung zum Schritt 1318. Im Schritt 1318 werden die Bedingungen zum Ausführen der nächsten Schablone, die in dem Flussblatt spezifiziert wird, bestimmt. Die Bedingungen werden berechnet, um die des mögliche Exemplar in dem Fluss-Blatt zu bestimmen, welches das nächste Exemplar für eine Ausführung sein könnte. Zusätzlich werden die Bedingungen, unter denen jedes der Exemplare das nächste sein würde, als eine logische Gleichung ausgedrückt. Variablen werden für Werte verwendet, die während eines Testjobs ausgewertet werden müssen. Diese logischen Ausdrücke werden in die Jobsteuerungs-Datenstruktur im Schritt 1320 eingegeben. Die logischen Ausdrücke werden als Bedingungen dafür verwendet, was zu Verzweigungsbefehlen in einer traditionellen Programmiersprache gleichgesetzt werden kann.
Sobald die Information für eine Zeile des Flusssteuerungs-Blatts eingegeben ist, geht die Ausführung zum Schritt 1322. Der Schritt 1322 überprüft, ob zusätzliche Zeilen in dem Flusssteuerungs-Datenblatt vorhanden sind. Wenn dem so ist geht die Ausführung durch eine Schleife zum Schritt 1312. Wenn keine zusätzlichen Zeilen in dem Flusssteuerungs-Datenblatt vorhanden sind, kehrt die Flusssteuerungssoftware 314 auf den Leerlaufzustand 1310 zurück.
Wenn die Flusssteuerungssoftware 314 in ihrem Leerlaufzustand ist, könnte sie einen Befehl von einem Benutzer zum Ablaufen lassen eines Testjobs empfangen oder sie könnte ein Startsignal von einer Behandlungseinrichtung 114 empfangen, was anzeigt, dass eine zu testende Einrichtung geladen worden ist und zum Testen bereit ist. Wenn der Befehl zum Ablaufen lassen eines Testjobs aus empfangen wird geht die Ausführung zum Schritt 1324. Im Schritt 1324 wird die erste Schablone von der Jobsteuerungs-Datenstruktur gelesen. Die Schablone wird als ein Unterprogramm mit den spezifizierten Argumenten von der Jobsteuerungs-Datenstruktur aufgerufen. Das Schablonen-Unterprogramm wird dann ausgeführt und kehrt zu der Flusssteuerungssoftware 314 zurück.
Jedes Schablonen-Unterprogramm, das einen Test darstellt, zeigt an, ob der Test bestanden wurde oder fehl schlägt. Eine Vorgehensweise, dass die Ergebnisse der Tests angezeigt werden könnten, ist wenn das Schablonen-Unterprogramm codiert ist, um einen Wert an das aufrufende Programm zurückzugeben, der die Ergebnisse des Tests anzeigt, der durch diese Unterprogramm-Schablone ausgeführt wird. Alternativ kann die Schablone, oder ein Einrichtungstreiber, wenn geeignet, eine Funktion innerhalb der Fluss-DLL aufrufen, die den Zustand des Testers überprüft, um zu bestimmen, ob der Test bestanden wurde oder fehl geschlagen ist. Im Schritt 1236 wird der Zustand des Testjobs auf Grundlage des Werts, der durch die Testschablone zurückgegeben wird, die gerade aufgerufen wurde, aktualisiert. Zum Beispiel wird der Test anzeigen, ob eine Testschablone ohne Erfassen eines Fehlers ausgeführt wurde (d. h. der Test bestanden wurde) oder ob ein Fehler erfasst wurde. In einigen Fällen werden die Fehler numerische Werte aufweisen, die ein Wegwerfen der Einrichtung, die gerade getestet wird, ermöglichen.
Im Schritt 1328 wird der neue Zustand des Tests verwendet, um den logischen Ausdruck auszuwerten, der in der Jobfluss-Datenstruktur im Schritt 1328 gespeichert wird. Auf Grundlage dieser Auswertung wird die nächste Schablone gewählt, und zwar auf Grundlage der Verzweigungsinformation, die in dem Schritt 1320 gespeichert wird.
Die Ausführung geht dann zum Schritt 1330. Der Schritt 1330 wertet aus, ob eine andere Schablone für die Ausführung vorhanden ist. Wenn dem so ist geht die Jobausführung durch eine Schleife zurück zum Schritt 1324. Wenn keine zusätzlichen Schablonen vorhanden sind kehrt die Flusssteuerungssoftware 314 auf ihren Leerlaufzustand zurück.
In der bevorzugten Ausführungsform werden die Ergebnisse eines Testjobs einem Benutzer oder der Behandlungseinrichtung 114 nicht dargeboten, wenn der Test beendet ist. Das Darbieten von Daten verlangsamt die Ausführung des Testjobs. Deshalb werden in der bevorzugten Ausführungsform Ergebnisse über die Ausführung von jedem Testjob in einem Computerspeicher gespeichert, bis eine Anfrage durchgeführt wird. Die Anfrage nach Ergebnissen bewirkt, dass die Flussteuerungssoftware 314 von dem Leerlaufzustand 1310 zu dem Schritt 1332 übergeht. Im Schritt 1332 können die Ergebnisse für einen menschlichen Benutzer angezeigt oder an eine Behandlungseinrichtung 114 übergeben werden. Die Ergebnisse können für eine Anzeige in einer was für den Benutzer zweckdienlichen Weise oder geeignet für eine Behandlungseinrichtung formatiert werden.
Nun werden die näheren Einzelheiten über den Datenmanager 316 dargeboten. Der Datenmanager 316 besteht aus einer Reihe von C++ "Klassen" („classes"). Klassen weisen nicht ein Zustandsdiagramm auf, das ihnen zugeordnet ist. Sie führen Operationen im Ansprechen von Anforderungen von anderen Programmierelementen aus. Klassen weisen „Verfahren" („methods") auf, die ihnen zugeordnet sind. Jedes Verfahren kann wie eine herkömmliche Programmierfunktion aufgerufen werden, um auf Daten zuzugreifen, die innerhalb der Klassen gespeichert sind.
Die C++ Verfahren können direkt durch andere C++ Programme aufgerufen werden. In der Ausführungsform der 3 können die Einrichtungstreiber 328, weil Sie als C++ Prozeduren implementiert sind, die Verfahren (methods) aufrufen, um Daten in dem Datenmanager 316 direkt zu lesen oder zu ändern. Das Excel Arbeitsbuch, welches nicht in C++ ist, benötigt APIs – Application Program Interfaces – zum Aufrufen der Verfahren, die Daten von dem Datenmanager 316 speichern oder auslesen.
Jedoch sind APIs alt-bekannte Programmierstrukturen. Daten werden zwischen den Excel Programmen, einschließlich der Visual Basic Makros, und im Datenmanager 316 in einem Format übergeben, welches als „SafeArray" bezeichnet wird. Ein SafeArray ist Teil der Microsoft OLE (Objekt Linking and Embedding Language), die mit einem Microsoft Excel kommerziell erhältlichen Tabellenblatt-Programm verwendet werden kann.
Der Dateimanager 316 ist als eine Serie von Speicherstrukturen implementiert, die als „Behältnisse" („Container") bezeichnet werden. Das Format des Behälters hängt von dem Typ von Daten, die gespeichert werden sollen, ab. Und zum Beispiel werden Stiftkarten-Daten in einem Behältnis mit einem anderen Format als das Behältnis, welches Pegel-Blattdaten hält, gespeichert. Das Format des Behältnisses wird unter Verwendung von bekannten Programmiertechniken auf Grundlage der Information, die gespeichert werden soll, definiert.
Die Behältnisse können eingenistet sein. Zum Beispiel könnten innerhalb eines Behälters für eine Stiftkarte mehrere Stiftgruppen vorhanden sein. Innerhalb jeder Stiftgruppen könnten mehrere Stifte vorhanden sein. In diesem Beispiel weist das Behältnis 3 Einnistungsebenen auf. Jedoch könnte irgendein Grad einer Einnistung möglich sein.
Die C++ STL (Standard Template Library) umfasst Verfahren, die zum Manipulieren von Daten innerhalb von Klassen nützlich sind. Zwei von diesen Verfahren sind „MAP" und „Vector". Im Allgemeinen werden in dem Computerspeicher „Behältnisse" zugeordnet in der Reihenfolge, in der sie durch das Programm erzeugt werden, und nicht in einer logischen Reihenfolge. Um jedoch das Auslesen bzw. das Zurückholen von Information einfacher zu machen wird ein Satz von „Schlüsseln" zwischen den Namen der Behältnisse und deren physikalischen Ort in dem Speicher erzeugt. Die „Schlüssel" wirken wie ein Index, zu dass gewünschte Daten durch Finden des richtigen Schlüssels auf gefunden werden können.
Das MAP Verfahren erzeugt einen Satz von Schlüsseln, die verzweigt sind, wie ein Binärbaum. Das Vector Verfahren erzeugt einen Index, der wie eine Liste geordnet ist. Der Vorteil des MAP Verfahrens ist, dass ein zufälliger Posten leicht gefunden werden kann. Der Nachteil des MAP Verfahrens ist, dass eine Ordnung verloren geht. Zum Beispiel ist die Reihenfolge bzw. die Ordnung von Stiften in einem Stiftkarten-Datenblatt eine wichtige Information für ein Testprogramm. Die Verwendung lediglich des MAP Verfahrens würde dazu führen, dass die Reihenfolge verloren geht. Die Verfahren zum Speichern von Daten in dem Datenmanager 316 verwenden eine Kombination der MAP und VECTOR STLs, um die Vorteile von jedem zu erreichen.
Um Funktionen zu speichern und zurückzugewinnen enthält der Datenmanager 316 andere Verfahren zum Ausführen der erforderlichen Datenmanagementfunktionen. Eine der zusätzlichen Funktionen ist eine SELECT DEFAULT Funktion (VOREINSTELLUNG WÄHLEN Funktion). Wie voranstehend beschrieben können mehrere Sätze von Daten für eine spezifische Klasse von Daten vorhanden sein. Zum Beispiel können mehrere Stiftkarten in einem Testjob vorhanden sein. Das SELECT DEFAULT Verfahren zeigt an, welcher Datensatz als eine Voreinstellung (Default) verwendet werden sollen. Wenn ein Testjob zum Beispiel zwei Stiftkarten aufweist, nämlich PIN MAP 1 und PIN MAP 2, dann könnte PIN MAP 1 als der Default eingestellt werden. Irgendeine Verwendung einer Zurückgewinnungs-Funktion zum Zurückholen von Stiftkarten-Daten würde die Daten von PIN MAP 1 erhalten, außer wenn PIN MAP 2 ausdrücklich angezeigt werden würde, wenn der Zurückholungs-Betrieb ausgeführt würde.
Ein SELECT ACTIVE Verfahren (AKTIVE WÄHLEN) könnte ebenfalls in dem Datenmanager 316 eingebaut sein. Dieses Verfahren würde ähnlich wie das SELECT DEFAULT sein, würde aber das Behältnis spezifizieren, welches verwendet werden würde.
Ein anderes Verfahren, welches eingebaut werden könnte, würde ein REPLACE Verfahren (ERSETZEN) sein. Wie voranstehend beschrieben ist der Datenmanager 316 eine Serie von Behältnissen für Daten für einen Testjob, um eine bestimmte Einrichtung zu testen. Während einer Entwicklung eines Testjobs oder Zwischentests in einen bestimmten Job könnte es wünschenswert sein einige der Daten für die Einrichtung zu ändern. Das REPLACE Verfahren erlaubt, dass ein Satz von Daten durch einen anderen ersetzt wird. Wenn zum Beispiel ein Benutzer ein Einrichtungs-Stiftkarten-Tabellenblatt als Teil des Prozesses zum Entwickeln eines Testjobs editiert hat, könnte ein Makro, der zu dem Stiftkarten-Tabellenblatt gehört, automatisch das REPLACE Verfahren aufrufen, um sicherzustellen, dass die neuen Daten verwendet werden, wenn der Testjob ausgeführt wird. Anstelle dass es automatisch ausgeführt wird, wenn Daten geändert werden, könnte das REPLACE Verfahren durch einen Makro aufgerufen werden, der im Ansprechen auf eine Benutzereingabe arbeitet.
Ein ähnliches Verfahren wird benötigt, wenn Daten in dem Datenmanager durch einen der Einrichtungstreiber 328 verändert werden. Wie beschrieben worden ist hält der Datenmanager 316 im Wesentlichen eine Kopie der Daten, die getrennt von den Daten ist, die innerhalb des Excel Arbeitsbuchs gehalten werden. Änderungen innerhalb des Excel Arbeitsbuchs werden in dem Datenmanager durch das REPLACE Verfahren reflektiert. Wenn die Daten innerhalb des Datenmanagers nicht innerhalb des Arbeitsbuchs verändert werden, wird ein REPLICATE Verfahren (REPLIZIEREN) benötigt. Wenn zum Beispiel der Einrichtungstreiber einen Wert innerhalb von einem der Behältnisse in dem Datenmanager ändert, könnte der Datenmanager das REPLICATE Verfahren aufrufen.
Das REPLICATE Verfahren ruft ein Excelwerkzeug auf, das die gegenwärtigen Daten von dem Datenmanager 316 zurückliest. Die Daten werden in das geeignete Exceltabellenblatt geladen, was die Excelfunktionen, die zu dem Arbeitsbuch gehören, veranlasst irgend welche Daten in Abhängigkeit von den geänderten Daten neu zu berechnen. Dann werden die Daten in irgendeinem Tabellenblatt, welches geändert wurde, in dem Datenmanager ersetzt. Testschablonen, die Operationen ausführen, die die Daten ändern, die durch den Dateimanager gespeichert werden, verwenden das REPLICATE Verfahren, wenn sie eine Ausführung abgeschlossen haben.
BETRIEB
Der Aufbau der Software zum Steuern des Testers 112 ist beschrieben worden. Viele Verwendungen der Software könnten möglich sein. Eine wahrscheinliche Verwendung ist, dass die Software zunächst zum Entwickeln eines Testjobs und dann zum Ausführen dieses Testjobs wiederholt während der Herstellung der Halbleitereinrichtungen verwendet werden wird. Eine wahrscheinliche Verwendung würde sein, dass ein Einrichtungsingenieur zunächst Testschablonen 320, wenn erforderlich, editieren würde. Es ist beabsichtigt, dass eine sehr kleine Anzahl von Testschablonen viele Arten von Einrichtungen testen können. Deshalb ist es unwahrscheinlich, dass ein Editieren von Testschablonen benötigt wird.
Der nächste Schritt, den ein Entwickler einer Halbleitertesteinrichtung möglicherweise vornehmen würde, würde darin bestehen die Einrichtungsdaten und die Flussentwicklungswerkzeuge 310 (3) zu verwenden. Auf diese Werkzeuge kann zugegriffen werden, indem ein Excel Arbeitsbuch für die spezifische Einrichtung, die gerade entwickelt wird, geöffnet wird. Insbesondere stellen diese Werkzeuge die Tabellenblätter, die in den 4 bis 11 dargestellt sind, dar. Makros oder Wizards können verwendet werden, um den Benutzer durch diese Formen zu führen. Validierungs-Makros könnten ablaufen gelassen werden, sobald die Dateneingabe für ein bestimmtes Blatt abgeschlossen ist, sodass irgend welche Daten, die mit anderen Daten inkonsistent sind, erfasst und korrigiert werden könnten. Zum Beispiel könnte ein Programmierer Datenwerte für einen bestimmten Stift eingeben, der nicht in der Stiftkarte war. Eine derartige Eingabe würde einen Fehler anzeigen, entweder weil der Stift unbeabsichtigt von der Stiftkarte ausgelassen wurde, oder weil der falsche Name für einen bestimmten Stift verwendet worden ist.
In einer bevorzugten Ausführungsform wird die Software derart codiert, dass ein Testjob nicht ablaufen wird, wenn Daten eingegeben oder geändert worden sind und nicht validiert worden sind. Eine Validierung kann durch den Benutzer von dem kundenspezifischen Menübalken gewählt werden.
Sobald die Daten eingegeben sind würde ein Benutzer eine „compile" Option („Kompilieren") wählen. In einer bevorzugten Ausführungsform wird die compile Option aus dem kundenspezifischen Menüposten, der zu dem Fluss-Datenblatt gehört gewählt. Die compile Option triggert die Flusssteuersoftware 314, um die Jobfluss-Datenstruktur zu konstruieren. Sie verursacht auch, das Verfahren innerhalb des Datenmanagers 316 die Daten von dem Excel Arbeitsbuch an den Datenmanager transferieren.
In der Entwicklungsumgebung würde der Testingenieur den Prozess zum Debugging des Programms beginnen. Möglicherweise könnte der Ingenieur eine Einrichtung mit dem Tester 112 verbinden. Alternativ könnte der Testingenieur das Testprogramm unter Verwendung eines Simulators einem Debugging unterziehen. Ein Simulator ist ein Softwareprogramm, das den Betrieb des Testers 112 mit einer damit verbundenen Einrichtung simuliert.
Der Ingenieur könnte unter Umständen die Debugging-Werkzeuge, wie voranstehend beschrieben, verwenden, um Schrittweise durch das Programm zu gehen. Wenn der Testingenieur Fehler in den Programmen erfasst, könnte der Ingenieur die Testschablonen editieren. Weil die Testschablonen in Visual Basic geschrieben sind, was eine interpretierte Sprache ist, könnten die Änderungen sofort einen Effekt haben, ohne den Testjob erneut zu kompilieren.
Alternativ muss der Testingenieur unter Umständen einige der Daten in einer der Einrichtungsdaten-Strukturen ändern. Der Testingenieur würde auf die Daten durch die Tabellenblatt-Bildschirme, die in den 4–11 gezeigt sind, zugreifen. Der Validierungsprozess würde dann erneut ablaufen gelassen. Als Teil des Validierungsprozesses wird automatisch das REPLACE Werkzeug ablaufen gelassen. Ein automatisches Verwenden des REPLACE Werkzeugs stellt sicher, dass der Datenmanager 316 aktuelle Daten bereitstellt.
Wenn als Teil eines Debugging-Prozesses der Testingenieur den Programmfluss ändert, dann müsste der Fluss erneut kompiliert werden, sodass eine neue Jobfluss-Struktur gebaut werden könnte.
Sobald die erforderlichen Änderungen an den Einrichtungsdaten, den Testschablonen oder den Einrichtungsflüssen durchgeführt sind, könnte dann der Testjob erneut ablaufen gelassen werden. Die Zeit, die benötigt wird, um die Änderungen an dem Testprogramm durchzuführen, kann sehr kurz sein. In einigen herkömmlichen Systemen erforderten irgendwelche Änderungen, sogar sehr kleine Änderungen, an dem Testjob eine vollständige erneute Kompilierung. Infolgedessen könnte irgend eine Änderung bis zu einer Stunde dauern. Mit der Erfindung erfordern Änderungen an Schablonen nicht irgendeine erneute Kompilierung. Änderungen an Einrichtungsdaten erfordern, dass nur die geänderten Daten neu geladen werden. Es ist nur der Programmfluss, der dann, wenn er geändert wurde, kompiliert werden muss. Weil die Kompilierung nur mit dem Fluss betraut ist, und nicht mit den gesamten Daten, kann sie im Grunde genommen in Sekunden ausgeführt werden.
In einer typischen Entwicklungsanlage würde der Testingenieur iterativ den Prozess zum Ändern des Testjobs wiederholen, bis der Testjob so abläuft wie erwartet. Sobald er fertig gestellt ist würde der Testjob an eine Produktionsanlage transferiert werden. In einer Produktionsanlage werden die Einrichtungsdaten- und Flussentwicklungs-Werkzeuge nicht verwendet. Genauso wird eine kundenspezifische Schnittstelle entwickelt. Die kundenspezifische Schnittstelle stellt nur die Steuerungen bereit, die benötigt werden, um den Tester zum Testen eines Teils ablaufen zu lassen, und zeigt nur grundlegende Ausgangsinformation an, um einen Betreiber darüber in Kenntnis zu setzen, dass gerade ein Test vor sich geht. Obwohl ein Tester viele Daten messen und speichern kann, wird dem Betreiber in der Produktionsumgebung sehr wenig davon dargeboten.
Wenn die Software unter Verwendung von Excel implementiert wird, ist eine Visual Basic Programmiersprache verfügbar, um eine kundenspezifische Produktionsschnittstelle zu erstellen. Die wahrscheinlichen Aspekte in der Schnittstelle sind eine Steuerung zum Starten eines Testvorgangs, zum Stoppen eines Testvorgangs und eine Anzeige, die die Anzahl von Einrichtungen anzeigt, die bestimmte Tests nicht bestanden haben.
ANDERE AUSFÜHRUNGSFORMEN
Nachdem eine Ausführungsform beschrieben worden ist können zahlreiche alternative Ausführungsformen oder Veränderungen durchgeführt werden. Zum Beispiel würde die Erfindung in Verbindung mit einem Tester mit einem Körper und einer getrennten computerisierten Arbeitsstation beschrieben. Es ist nicht erforderlich, dass die computerisierte Arbeitsstation physikalisch getrennt von dem Testerkörper ist. Sie könnte zum Beispiel in dem Testerkörper eingebaut sein. Andere Konfigurationen sind möglich. Zum Beispiel weisen einige Tester einen Hauptrahmen und einen Testkopf auf. Für Zwecke dieser Erfidung könnte der Tester in einem oder mehreren unterschiedlichen Paketen sein.
Beispiele von spezifischen Daten- und Flussblättern sind angegeben worden. Jede Zeile wurde mit einer spezifischen Anzahl von Spalten gezeigt, wobei jede Spalte einen spezifischen Typ von Informationen über einen Posten oder einen Schritt in dem Fluss (dem Ablauf) enthält. In Abhängigkeit von den Typen, die ablaufen gelassen werden sollen, könnte die Hardware des Testers oder die Anforderungen an eine zu testende Einrichtung, die Anzahl und die Art von Information, die in jeder Zeile enthalten ist, anders sein.
Mehr oder weniger Spalten könnten verfügbar sein. Eine Möglichkeit besteht darin einen super Satz von möglichen Spalten für jeden Typ von Tabellenblatt zu haben. Ein Benutzer könnte dann heraussuchen, welche Spalten für den bestimmten Job wichtig wären. Ein Wizard könnte bereitgestellt werden, um einen Programmierer durch den Wählprozess zu führen. Ein Wizard ist ein Makro, der seinen Benutzer auffordert Auswahlvorgänge durchzuführen. Diejenigen Spalten in dem super Satz, die für eine Anzeige auf einem bestimmten Bildschirm nicht gewählt wurden, könnten vollständig von dem Tabellenblatt weggelassen werden oder könnten vorhanden, aber nicht angezeigt werden. Spalten, die vorhanden waren, aber nicht angezeigt werden, würden dann entweder ignoriert werden oder es würde ihnen Default-Werte gegeben werden.
Wir haben die Flusssteuerungssoftware 314 so beschrieben, dass sie in C++ beschrieben ist. Es wird in einem weit verbreiteten Maße angenommen, dass C++ so ausgebildet werden kann, dass sie schneller ausgeführt wird als Visual Basic, was die Programmiersprache ist, die ein Teil des Excel kommerziell erhältlichen Tabellenblatt-Programms ist. Jedoch haben wir erkannt, dass die Zeit zur Kopplung mit der Einrichtung und mit der Flussdateneingabe unter Verwendung des Excel Programms langsamer ist, obwohl die Flusssteuersoftware schneller ausgeführt wird, wenn sie in C++ geschrieben ist. Somit wird es in einigen Fällen vorzuziehen sein eine Flusssteuersoftware zu haben, die in Visual Basic oder einer anderen Makro-Programmiersprache implementiert ist, die Teil des kommerziell erhältlichen Tabellenblatt-Programms ist.
In Verbindung mit 13 wurde beschrieben, dass die Flusssteuerungssoftware 314 einen Testjob steuert, der ein einzelnes Teil testet. Der Tester 112 hat wahrscheinlich mehrere hundert bis mehrere tausend Stifte 124. Es ist deshalb möglich, dass genug Stifte vorhanden sind, um mehrere Teile mit dem Tester 112 zur gleichen Zeit zu verbinden. In diesem Fall werden die Stifte in „Stellen" hinein gruppiert. Die Stifte an jeder Stelle erhalten die gleichen Daten und führen die gleichen Messungen durch. Wenn jedoch eine Stelle einen Fehler erfasst wird unter Umständen eine andere Verarbeitung an dieser Stelle benötigt. Deshalb könnte die Flusssteuersoftware 314 strukturiert werden, um Tests an mehreren Stellen gleichzeitig ablaufen zu lassen. Wenn jedoch irgendeine Stelle fehlschlägt, würde diese Stelle getrennt getestet werden. Um diese Funktion auszuführen könnte der Schritt 1326 geändert werden, um den Zustand der Stellen getrennt zu verfolgen. Der Schritt 1328 könnte dann verändert werden, um Schablonen für jede Stelle zu wählen, und zwar in Abhängigkeit davon, ob die Einrichtung an jeder Stelle irgendeinen Test in den Testjob bestanden hat oder nicht.
Ferner ist beschrieben worden, dass das Testsystem Halbleiterkomponenten testet. Eine ähnliche Software könnte zum Steuern von Testsystemen für gedruckte Schaltungsplatinen oder andere Einrichtungen verwendet werden.
Zusätzlich ist beschrieben worden, dass die Verwendung des kommerziell erhältlichen Tabellenblatt-Programms erlaubt, dass die Software ein Testsystem testet, um schnell in einer Weise implementiert zu werden, die durch einen Benutzer einfach verstanden werden kann. 14 zeigt ein Beispiel eines anderen Werkzeugs, welches implementiert werden kann. 14 zeigt ein Werkzeug welches vorwiegend dafür verwendet worden ist, um als ein Debugging- oder Analysewerkzeug verwendet zu werden. Hier ist ein Dateneingabe-Bildschirm gezeigt. Der Bildschirm ist als eine Dialogbox unter Verwendung von Visual Basic anstelle als ein Tabellenblatt implementiert. Das bestimmte Beispiel der 14 bezieht sich auf den Hardware-Aufbau eines einzelnen Stifts 124 (1). Die Dialogbox enthält mehrere Felder, in die Daten eingegeben werden können. Die Daten stellen Werte dar, die an die Hardware in dem Tester übergeben werden. Wenn diese Dialogbox verwendet wird überbrückt sie den normalen Datenpfad durch die Flusssteuerung 314 und ruft die Einrichtungstreiber 328 direkt auf, um auf die Testerhardware zuzugreifen.
Als ein anderes Beispiel einer möglichen Veränderung könnte das kommerziell erhältliche Tabellenblatt-Programm ein anderes als Excel sein oder Versionen von Excel, abgesehen von denjenigen, die dargestellt wurden, könnten verwendet werden. 15 zeigt ein Beispiel eines Dateneingabe-Bildschirms, der mit Excel '97 implementiert ist, nämlich einem kommerziell erhältlichen Tabellenblatt-Programm, das durch Microsoft verkauft wird. Mehrere zusätzliche Funktionen bzw. Merkmale sind durch die Verwendung von Excel '97 möglich. Steuerelemente 1510 sind Gruppenanzeigesteuerungen. Wenn mehrere Zeilen von Daten innerhalb der gleichen Gruppe sind kann die Anzeige zusammengeklappt werden, sodass nur eine einzelne Zeile vorgesehen ist, um speziell diese Gruppe anzuzeigen. In 15 sind zum Beispiel die Zeilen, die bei 1512 und 1514 angezeigt sind, alle in den Zeitsatz mit dem Namen „rdcycle". Alle Zeilen sind gezeigt und von der Gruppe sagt man, dass sie ausgedient (expandiert) ist. Wenn jedoch die Gruppenanzeigesteuerung 1510 verwendet wird, würde nur eine einzelne Zeile für diese Gruppe gezeigt werden. Obwohl die anderen Zeilen nicht sichtbar sind, würde irgendeine Operation, die unter Verwendung des Dateneingabe-Bildschirms der 15 ausgeführt wird, noch auf diese wirken.
Eine andere Funktion bzw. ein anderes Merkmal, welches durch die Verwendung von Excel '97 verwendet werden könnte, ist, dass das Datenerscheinungsbild auf Grundlage von seinem Typ anders gemacht wird. Dies liegt daran, weil die Daten in der Zelle 1516 einem Typ für einen Adressenbus zugewiesen worden sind und die Daten in der Zelle 1518 einem Typ für einen Datenbus zugewiesen worden sind. Das Bilden der unterschiedlichen Typen von Daten visuell unterscheidend erleichtert die Verwendung der Software.
Die 16A und 16B zeigen andere Verbesserungen, die durchgeführt werden könnten. Das Gruppensteuerelement 1610 ist in seinem expandierten Zustand gezeigt. Somit gibt es eine Liste von Elementen, die für die Gruppe gezeigt sind, die mit „Generalinfo" („Allgemeine Informationen") angezeigt wird. Im Gegensatz dazu ist die Gruppensteuerung 1612 in ihrem nicht expandierten Zustand gezeigt. Somit werden keine Einträge für die Gruppe „Digital Setup" („Digitaler Aufbau") gezeigt.
Die 16A und 16B heben auch den Vorteil hervor, dass das Erscheinungsbild von Gruppen visuell unterschiedlich gemacht wird. Zum Beispiel erscheinen die Felder 1614 und 1616 unterschiedlich, weil sie Daten von unterschiedlichen Typen enthalten.
Ein anderes Merkmal bzw. eine andere Funktion, das/die in den 16A und 16B gezeigt ist, ist die Navigationsfunktion. In den vorangehenden Beispielen wurde auf Werkzeuge zugegriffen, indem Tabulatoren unten an dem Bildschirm gewählt werden. Die 16A und 16B demonstrieren, dass die Bildschirme mit „hot links" („Heißverbindungen") zusammengeknüpft werden können. Durch Klicken auf den Namen eines Bildschirms von einem anderen Bildschirm kann ein Benutzer die Bildschirmanzeige ändern. Ferner enthält ein Navigations-Werkzeugbalken Werkzeuge, die zum Auffinden eines gewünschten Datenbildschirms nützlich sind. Der Navigations-Werkzeugbalken enthält Werkzeuge, sowie man diese in einem Internet Navigator finden könnte. Die Werkzeuge führen derartige Operationen wie eine Bewegung an einem früheren Bildschirm oder das Weiterschalten auf einem vorher spezifizierten favorisierten Bildschirm aus.
Ein anderer Vorteil einer Verwendung von Excel '97 besteht darin, dass eine objektorientierte Sprache verwendet wird. Der Datenbildschirm ist ein Objekt. Jedes Objekt, wie ein Datenbildschirm, weist eine ihm zugeordnete Klasse auf. Sämtlichen Datenblättern kann eine Basisklasse gegeben werden, die die Operationen definiert, die für irgendein Datenblatt gemeinsam sind. Zum Beispiel kann in der Basisklasse eine Fehlerbehandlung, Datentypen und eine Formatierung definiert werden. Andere Funktionen, wie das Validieren von Daten und das Senden von Daten an den Datenmanager, die durch sämtliche Datenblätter ausgeführt werden, können als „public methods" („öffentliche Verfahren") für die Basisklasse definiert werden. In dieser Weise werden sämtliche von diesen Möglichkeiten für sämtliche Datenbildschirme bereitgestellt, obwohl sie nur einmal spezifiziert werden. Genauso wichtig ist, dass jedes Einrichtungsdaten- und Flussdaten-Werkzeug in der gleichen Weise arbeitet.
Eine andere Veränderung, die durch die Verwendung der objektorientierten Programmierung ermöglicht worden ist, besteht darin eine sofortige Validierung von Fehlern zwischen Blättern zu haben. Validierungsriegeln können spezifiziert werden und Daten können überprüft werden, wenn sie eingegeben werden. Eine Validierungsroutine, die nach inkonsistenten Daten zwischen mehreren Blättern prüft, könnte noch ablaufen gelassen werden.
Deshalb sollte die Erfindung nur durch den Umfang der beigefügten Ansprüche beschränkt werden.

Claims

Halbleitertestsystem, umfassend: einen Körper (112) zum Halten einer elektronischen Schaltungsanordnung (120, 122, 124, 126, 128) und zum Erzeugen und Messen einer Vielzahl von Testsignalen; eine Comnputer-Workstation (110) zum Bereitstellen von Steuerinformation an der elektronischen Schaltungsanordnung innerhalb des Körpers (112); und eine Steuersoftware innerhalb der Computer-Workstation (110), wobei die Steuersoftware eine Vielzahl von Einrichtungstreiber-Programmelementen (328) einschließt, wobei jedes Programmelement angeordnet ist, um einen Abschnitt der elektronischen Schaltungsanordnung innerhalb des Körpers zu steuern, dadurch gekennzeichnet, dass: die Steuersoftware ferner umfasst: eine Vielzahl von Typen von Tabellenblättern (312), wobei ein erster Abschnitt der Vielzahl von Typen von Tabellenblättern konfiguriert ist, um Daten über eine Einrichtung, die gerade getestet wird, zu halten, und ein zweiter Abschnitt der Vielzahl von Typen von Tabellenblättern konfiguriert ist, um Information zu halten, die die Schritte beeinflusst, die während eines Testjobs an der Einrichtung, die gerade getestet wird, ausgeführt werden, und eine Progrmmeinrichtung (314, 316, 320) zum Empfangen von Daten von dem zweiten Abschnitt der Vielzahl von Typen von Tabellenblättern und zum Steuern einer Ausführung eines Testjobs durch Bereitstellen von Daten von Tabellenblättern des ersten Typs an gewählten der Vielzahl von Progranmelementen in einer Reihenfolge, die von Daten in Tabellenblättern des zweiten Typs diktiert wird.
Testsystem nach Anspruch 1, wobei das kommerziell erhältliche Tabellenblatt-Programm eine integrierte Programmiersprache einschließt, die integriert ist, um Daten von Tabellenblättern zu lesen, und die Programmeinrichtung eine Flusssteuersoftware einschließt, die in der integrierten Programmiersprache geschrieben ist.
Testsystem nach irgendeinem vorangehenden Anspruch, wobei die Vielzahl von Typen von Tabellenblättern in ein Arbeitsbuch organisiert sind, wobei auf Daten in einem Tabellenblatt innerhalb des Arbeitsbuchs von einem anderen Tabellenblatt innerhalb des Arbeitsbuchs zugegriffen werden kann.
Testsystem nach irgendeinem vorangehenden Anspruch, zusätzlich umfassend eine Vielzahl von Testprogrammelementen, wobei jedes davon eine Funktion darstellt, die während eines Schritts des Testjobs ausgeführt wird, und wobei ein Tabellenblatt in dem zweiten Abschnitt der Vielzahl von Tabellenblättern ein Flussblatt ist, welches eine Vielzahl von Zeilen umfasst, wobei wenigstens ein Abschnitt der Vielzahl von Zeilen jeweils einschließt eine Referenz auf ein Testprogrammelement, und eine Anzeige einer Klassifikation, die der Einrichtung, die gerade getestet wird, zugewiesen werden soll, wenn der in Bezug gesetzte Test, wenn er ausgeführt wird, einen Ausfall anzeigt.
Testsystem nach Anspruch 4, wobei wenigsten ein Abschnitt der Vielzahl von Zeilen in einem Flussblatt jeweils zusätzlich einschließt den Namen eines Flags, welches gesetzt werden soll, wenn der in Bezug gesetzte Test fehlschlägt, und eine Zelle, die einen Bool'schen Ausdruck darstellt, der anzeigt, ob der in Bezug gesetzte Test ausgeführt werden sollte, wobei der Bool'sche Ausdruck in einer Zeile die Namen von Flags einschließt, die in anderen Zeilen enthalten sind.
Testsystem nach Anspruch 5, wobei jedem Flussblatt zusätzlich eine Einrichtung zum Eingeben von Argumenten, die die Ausführung des Testjobs modifizieren, zugeordnet ist.
Testsystem nach Anspruch 4, wobei jedes der Testprogrammelemente eine Testschablone umfasst und ein Tabellenblatt in dem zweiten Abschnitt der Vielzahl von Tabellenblättern ein Exemplarblatt ist, welches eine Vielzahl von Zeilen umfasst, wobei wenigstens ein Abschnitt der Vielzahl von Zeilen jeweils ein Exemplar der Testschablone definiert und eine Referenz auf eine Testschablone einschließt, und einen Identifizierer für das Testexemplar, wobei das Exemplarblatt zusätzlich umfasst eine Einrichtung zum Spezifizieren von gewählten der Tabellenblätter, die konfiguriert sind, um Daten über eine Einrichtung, die gerade getestet wird, zu halten, die mit der Testschablone kombiniert werden sollen, um das Testexemplar zu bilden, und wobei die Referenz auf eine Testprogrammelement in dem Flussblatt den Identifizierer für ein Testexemplar umfasst.
Testsystem nach Anspruch 7, wobei jede der Testschablonen in einer interpretierten Programmiersprache geschrieben wird.
Testsystem nach irgendeinem vorangehenden Anspruch, wobei die Programmeinrichtung umfasst; eine Flusssteuerungs-Programmeinrichtung zum Aufrufen von gewählten der Einrichtungstreiber-Programmelemente in einer Reihenfolge, die durch die Information in einem Tabellenblatt in dem zweiten Abschnitt der Vielzahl von Typen von Tabellenblättern bestimmt ist, und eine Datenrückgewinnungs-Programmeinrichtung, die von den Einrichtungstreiber-Programmelementen aufgerufen wird, um Werte zurückzugeben, die durch Information in einem Tabellenblatt in dem ersten Abschnitt der Vielzahl von Typen von Tabellenblättern bestimmt wird.
Computerprogrammcode zum Steuern einer Computer-Workstation in dem Testsystem nach irgendeinem vorangehenden Anspruch, wobei der Computerprogrammcode umfasst: eine Vielzahl von Einrichtungstreiber-Programmelementen (328), wobei jedes Programmelement angeordnet ist, um einen Abschnitt der elektronischen Schaltungsanordnung innerhalb eines Körpers (112) zum Halten einer elektronischen Schaltungsanordnung (120, 122, 124, 126, 128), die getestet werden soll, zu steuern; gekennzeichnet durch: eine Vielzahl von Typen von Tabellenblättern (312), wobei ein erster Abschnitt der Vielzahl von Typen von Tabellenblättern konfiguriert ist, um Daten über eine Einrichtung, die gerade getestet wird, zu halten und ein zweiter Abschnitt der Vielzahl von Typen von Tabellenblättern konfiguriert ist, um Information zu halten, die die Schritte beeinflusst, die während eines Testjobs an der Einrichtung, die gerade getestet wird, ausgeführt werden, und eine Programmeinrichtung (314, 316, 320) zum Empfangen von Daten von dem zweiten Abschnitt der Vielzahl von Typen von Tabellenblättern und zum Steuern einer Ausführung eines Testjobs durch Bereitstellen von Daten von Tabellenblättern des ersten Typs an gewählten der Vielzahl von Programmelementen in einer Reihenfolge, die durch Daten in Tabellenblättern des zweiten Typs diktiert wird.
Computerprogrammcode nach Anspruch 10, wobei das kommerziell erhältliche Tabellenblattprogramm eine integrierte Programmiersprache einschließt, die integriert ist, um Daten aus Tabellenblättern zu lesen, und die Programmeinrichtung eine Flusssteuersoftware einschließt, die in der integrierten Programmiersprache geschrieben ist.
Computerprogrammcode nach irgendeinem der Ansprüche 10 und 11, wobei die Vielzahl von Typen von Tabellenblättern in ein Arbeitsbuch hinein organisiert sind, wobei auf Daten in einem Tabellenblatt innerhalb des Arbeitsbuchs von einem anderen Tabellenblatt innerhalb des Arbeitsbuchs zugegriffen werden kann.
Computerprogrammcode nach irgendeinem der Ansprüche 10 bis 12, zusätzlich umfassend eine Vielzahl von Testprogrammelementen, die jeweils eine Funktion darstellen, die während eines Schritts des Testjobs ausgeführt werden, und wobei ein Tabellenblatt in dem zweiten Abschnitt der Vielzahl von Tabellenblättern ein Flussblatt ist, welches eine Vielzahl von Zeilen umfasst, wobei wenigstens ein Abschnitt der Vielzahl von Zeilen jeweils einschließt eine Referenz auf ein Testprogrammelement, und eine Anzeige einer Klassifikation, die der Einrichtung, die gerade getestet wird, zugewiesen werden soll, wenn der in Bezug gesetzte Test, wenn er ausgeführt wird, einen Ausfall anzeigt.
Computerprogrammcode nach Anspruch 13, wobei wenigstens ein Abschnitt der Vielzahl von Zeilen in einem Flussblatt jeweils zusätzlich einschließt den Namen eines Flags, welches gesetzt werden soll, wenn der in Bezug gesetzte Test fehlschlägt, und eine Zelle, die einen Bool'schen Ausdruck darstellt, der anzeigt, ob der in Bezug gesetzte Test ausgeführt werden sollte, wobei der Bool'sche Ausdruck in einer Zeile die Namen von Flags, die in anderen Zeilen eingeschlossen sind, einschließt.
Computerprogrammcode nach Anspruch 14, wobei jedem Flussblatt zusätzlich eine Einrichtung zum Eingeben von Argumenten, die die Ausführung des Testjobs modifizieren, zugeordnet ist.
Computerprogrammcode nach Anspruch 13, wobei jedes Testprogrammelement eine Testschablone umfasst und ein Tabellenblatt in dem zweiten Abschnitt der Vielzahl von Tabellenblättern ein Exemplarblatt ist, welches eine Vielzahl von Zeilen umfasst, wobei wenigstens ein Abschnitt der Vielzahl von Zeilen jeweils ein Exemplar der Testschablone definiert und einschließt eine Referenz auf eine Testschablone, und einen Identifizierer für das Testexemplar, wobei das Exemplarblatt zusätzlich umfasst eine Einrichtung zum Spezifizieren von gewählten der Tabellenblätter, die konfiguriert sind, um Daten über eine Einrichtung, die gerade getestet wird, zu halten, die mit der Testschablone kombiniert werden sollen, um das Testexemplar zu bilden, und wobei die Referenz auf ein Testprogrammelement in dem Flussblatt den Identifizierer für ein Testexemplar umfasst.
Computerprogrammcode nach Anspruch 16, wobei jede der Testschablonen in einer interpretierten Programmiersprache geschrieben ist.
Computerprogrammcode nach irgendeinem der Ansprüche 10 bis 17, wobei die Programmeinrichtung umfasst eine Flusssteuerungs-Programmeinrichtung zum Aufrufen von gewählten der Einrichtungstreiber-Programmelemente in einer Reihenfolge, die durch die Information in einem Tabellenblatt in dem zweiten Abschnitt der Vielzahl von Typen von Tabellenblättern bestimmt wird, und eine Datenrückgewinnungs-Programmeinrichtung, die von den Einrichtungstreiber-Programmelementen aufgerufen wird, zum Zurückgeben von Werten, die durch Information in einem Tabellenblatt in dem ersten Abschnitt der Vielzahl von Typen von Tabellenblättern bestimmt werden.
Trägermedium, welches den Computerprogrammcode nach irgendeinem der Ansprüche 10 bis 18 trägt.