-
TECHNISCHES
GEBIET
-
Die
vorliegende Erfindung betrifft eine Programmentwicklungsunterstützungsvorrichtung zum
Entwickeln eines Programms in einer spezifischen Sprache, das eine
Beschreibung eines Steuerbefehls für eine gerade getestete Vorrichtung
bzw. einen Prüfling,
wie beispielsweise eine Halbleitervorrichtung, enthält, und
eines Programms in einer allgemeinen Sprache (GPL = General-Purpose
Language), das eine Beschreibung von Schritten enthält, wie beispielsweise
einem Ausführungsschritt
des Programms in spezifischer Sprache und einem Verarbeitungsschritt
von Daten, die von dem Programm in spezifischer Sprache erhalten
sind, eine Programmausführungsvorrichtung
zum Ausführen
der Programme, ein Kompilierverfahren der Programme und ein Diagnoseverfahren
der Programme. Insbesondere betrifft die vorliegende Erfindung eine Programmentwicklungsunterstützungsvorrichtung, eine
Programmausführungsvorrichtung,
ein Kompilierverfahren und ein Diagnoseverfahren zum Entwickeln
eines Programms in gemischter Sprache, wobei ein Programm in spezifischer
Sprache und ein Programm in allgemeiner Sprache gemischt sind und in
einer Datei geschrieben sind.
-
STAND DER
TECHNIK
-
Viele
elektronische Vorrichtungen, wie beispielsweise Messvorrichtungen
und Kommunikationsvorrichtungen, die erforderlich sind, um ein großes Ausmaß von verschiedenen
Typen von Signalen zu verarbeiten, sind mit einem Hochleistungsprozessor
versehen. Ein Programm (Firmware), das auf dem Prozessor auszuführen bzw.
durchzuführen
ist, neigt dazu, kompliziert und bezüglich der Größe groß zu werden.
Das in den elektrischen Vorrichtungen aufgezeichnete Programm enthält oft unbekannte Fehler.
Weiterhin fragen Kunden oft nach einem Zusatz oder einer Verbesserung
von Funktionen der Vorrichtungen.
-
Um
diesen Anforderungen gerecht zu werden, sind viele elektronische
Vorrichtungen über
ein Kommunikationskabel mit externen Computern verbindbar ausgeführt, was
ein Aktualisieren bzw. Updaten des Programms und ein Einstellen/Überwachen des
Betriebs zulässt.
Anders ausgedrückt
kann ein Steuerbefehl oder ein Steuerprogramm selbst von einem externen
Computer zu dem Prozessor einer solchen elektronischen Vorrichtung
verteilt werden. Weiterhin kann ein Programmalgorithmus und eine
Einstellung auf dem externen Computer entwickelt werden, um auf
einer solchen elektronischen Vorrichtung betrieben zu werden.
-
Unter
solchen elektronischen Vorrichtungen ist insbesondere ein Halbleitertestgerät einzigartig, da
das Halbleitertestgerät
in Bezug auf eine breite Vielfalt von Halbleitervorrichtungen für spezielle
Zwecke arbeiten muss, von welchen jede mit einem spezifischen Vorrichtungstestprogramm
getestet werden muss. In den letzten Jahren ist es gewöhnlich geworden,
dass der Anwender der Halbleitertestgeräte, d.h. der Halbleitervorrichtungshersteller,
ein Programm entwickelt, das auf dem Prozessor des Halbleitertestgeräts durch
sich selbst ausgeführt
wird.
-
Jedoch
haben die meisten der Prozessoren, die bei den elektronischen Vorrichtungen
für spezielle
Zwecke verwendet werden, und zwar insbesondere bei den Halbleitertestgeräten, die
Neigung, spezifische Prozessoren anzubringen, die nur die binären Dateien
verarbeiten können,
die gemäß der spezifischen
Spezifikation sind. Dann muss auch eine Quelldatei, die als Basis
für solche
binären
Dateien verwendet wird, gemäß einer
spezifischen Spezifikation der Programmiersprache und der Entwicklungsunterstützungsumgebung
erzeugt werden, was wiederum erfordert, dass die Programmentwickler
nicht nur in Bezug auf die Programmsprache erfahren sind, sondern
auch in Bezug auf den Betrieb von spezifischen Entwicklungsunterstützungsumgebungen.
-
Angesichts
des Obigen sind einige elektronische Vorrichtungen vorgeschlagen,
die ein Programm ausführen
können,
das in der allgemeinen Sprache bzw. der Sprache für allgemeine
Zwecke entwickelt ist, wie beispielsweise der C-Sprache oder JAVA
(eingetragene Marke). In solchen Vorrichtungen können jedoch Programmressourcen,
die gemäß der spezifischen
Spezifikation entwickelt sind, nicht genutzt werden.
-
Eine
herkömmliche
Technik zum Eliminieren einer solchen Unannehmlichkeit besteht im
Beschreiben eines gesamten Datenprozesses und eines Algorithmus
in allgemeiner Sprache, wie beispielsweise der C-Sprache, und ein
in einer Sprache, die für eine
jeweilige elektronische Vorrichtung spezifisch ist, geschriebenes
Programm als Unterprogramm aufzurufen. Ein Beispiel einer Programmentwicklung und
-ausführung
gemäß dieser
Technik ist nachfolgend detailliert beschrieben, wo angenommen ist, dass
die elektronische Vorrichtung, die das Programm ausführt, ein
Halbleitertestgerät
ist.
-
Zum
Erleichtern des Verstehens eines Programmausführungsbetriebs bei dem Halbleitertestgerät werden
das Halbleitertestgerät
und seine Programmentwicklungsumgebung beschrieben. Das Halbleitertestgerät ist eine
spezielle Messvorrichtung, die einen vorbestimmten Betriebstest
an Halbleitervorrichtungen, wie beispielsweise einer Halbleiterspeichervorrichtung,
einem Logik-IC, einem linearen IC, durchführt, und die Vorrichtungsstruktur
variiert gemäß den Typen
von zu testenden Halbleitervorrichtungen. Allgemein ist eine Workstation
mit dem Halbleitertestgerät
verbunden, um dem Halbleitertestgerät eine Testausführungsanweisung
zuzuteilen, um Testergebnisse zu erlangen, und um ein Programm zu
entwickeln. Der Halbleitertest wird mit einem Halbleitertestsystem
realisiert, das aus einem Halbleitertestgerät und einer Workstation besteht, wie
es in der offengelegten japanischen Patentveröffentlichung Nr. 2001-195275
offenbart ist.
-
10 ist
ein Blockdiagramm einer Gesamtstruktur eines herkömmlichen
Halbleitertestsystems, wobei eine Struktur gezeigt ist, die für unterschiedliche
Halbleitertestgeräte
für unterschiedliche
Vorrichtungstests allgemein ist. In 10 enthält ein Halbleitertestgerät 100 einen
Testerprozessor 110, eine Haupttestereinheit 120,
einen Testerkopf 130 und eine Kommunikationsschnittstelle 140.
-
Der
Testerprozessor 110 dient zum Senden bzw. Übertragen
eines Steuerbefehls und zum Empfangen/Senden von Testdaten zu/von
der Haupttestereinheit 120 und funktioniert als Steuerung,
die die Haupttestereinheit 120 und eine Kommunikation mit einer
Workstation, was später
beschrieben werden wird, steuert. Spezifisch enthält der Testerprozessor 110 eine
Betriebssystem-(OS = Operating System)-Kernroutine 111 in
einem eingebetteten Speicher (nicht gezeigt), um eine Einstellung
und eine Überwachung
eines Vorrichtungstestprogramms, ein Speichermanagement sowie eine Überwachung/Steuerung
der Kommunikationsschnittstelle 140, eine Steuerung der
Haupttestereinheit 120 und das Senden bzw. die Übertragung
der Testdaten über einen
Kommunikationsbustreiber 112 und einen Testerbustreiber 113,
die gleichermaßen
im Speicher gespeichert sind, durchzuführen.
-
Das
Vorrichtungstestprogramm ist mit einem Programm 114 in
allgemeiner Sprache und einem Programm 117 in spezifischer
Sprache konfiguriert, wie es oben beschrieben ist, welche als gesamtes
die Prozedur zum Ausführen
von verschiedenen Tests definieren, wie beispielsweise einem Funktionstest und
einem parametrischen DC-Test für
eine getestete Vorrichtung 131. Das Programm 114 in
allgemeiner Sprache ist mit einer Angabe bzw. Anweisung konfiguriert,
die einen Verarbeitungsbefehl für
verschiedene Daten enthält,
die als Ergebnis eines Tests erhalten sind, und einer Angabe bzw.
Anweisung, die einen Befehl enthält,
der anzeigt, wie das gesamte Vorrichtungstestprogramm auszuführen ist,
und ist eine binäre
Datei, die in der OS-Kernroutine 111 direkt ausführbar ist.
-
Andererseits
ist das Programm 117 in spezifischer Sprache eine Objektdatei,
die mit einem Befehl zum Steuern der Haupttestereinheit 120 konfiguriert
ist. Die Objektdatei ist gleich dem Programm in spezifischer Sprache,
welches ein geerbtes Betriebsmittel ist, eine binäre Datei,
die nur in einer Kernroutine direkt ausführbar ist, die für das Programm 117 in
spezifischer Sprache optimiert ist. Somit muss dann, wenn das Programm 117 in
spezifischer Sprache in der OS-Kernroutine 111 auszuführen ist,
ein Ausführungsemulator 115 einen
Interpretationsprozess durchführen.
Zusätzlich
enthält
das Programm 117 in spezifischer Sprache weiterhin einen
Eingabe/Ausgabe-Befehl, der zu Operationen, wie beispielsweise einem
Diskettenzugriff, einer Tastatureingabe, einer Monitoranzeige, für eine Workstation 200 gehört, wie
es später
beschrieben ist. Für
die Ausführung
eines solchen Eingabe/Ausgabe-Befehls ist zusätzlich zu der Interpretation
durch den Ausführungsemulator 115 eine
Interpretation durch einen IO-Steueremulator 116 erforderlich.
-
Die
Haupttestereinheit 120 dient zum Durchführen von verschiedenen Tests,
wie beispielsweise einem Funktionstest, einem parametrischen DC-Test und
einem RF-Test (Test auf hohe Harmonische), an der getesteten Vorrichtung 131,
die an dem Testkopf 130 angebracht ist, gemäß dem von
dem Testerprozessor 110 gesendeten Steuerbefehl, und ist
mit einem Register 121, einem Speicher 122 und
einer Testsignal-Empfangs/Sende-Einheit 123 versehen. Das
Register 121 speichert verschiedene Daten, die von dem
Testerbustreiber 113 im Testerprozessor 110 gesendet
sind. Die gespeicherten Daten werden wiederum direkt oder über den
Speicher 122 zu der Testsignal-Empfangs/Sende-Einheit 123 gesendet.
-
Dann
gibt die Testsignal-Empfangs/Sende-Einheit 123 die im Register 121 oder
Speicher 122 temporär
zu speichernden und dann zu dem Testerbustreiber 113 im
Testerprozessor 110 zu sendenden Daten über das Register 121 aus.
Die Testsignal-Empfangs/Sende-Einheit 123,
die mit verschiedenen Testeinheiten konfiguriert ist, wie beispielsweise
einem Mustergenerator, einem Zeitgabegenerator und einer DC-Einheit, gibt Testsignale,
die durch die Testeinheiten erzeugt sind, aus und erhält Daten,
die an einem Ausgangspin der getesteten Vorrichtung 131 erscheinen.
-
11 ist
ein Blockdiagramm einer Gesamtstruktur der Workstation 200.
Die Workstation 200 dient als Konsolenendgerät, das ein
Programm transferiert und eine Ausführungsanweisung zu dem Testerprozessor 110 in
dem Halbleitertestgerät 100 abgibt,
sowie als Programmentwicklungsunterstützungsvorrichtung, die die
Entwicklung des Programms 114 in allgemeiner Sprache und
des Programms 117 in spezifischer Sprache unterstützt. In 11 enthält die Workstation 200 einen
Prozessor 220, eine Kommunikationsschnittstelle 241,
eine Festplatte 242, eine Maus 243, eine Tastatur 244 und eine
Anzeige 245.
-
Der
Prozessor 220 enthält
eine Betriebssystem-(OS = Operating System)-Kernroutine 221 in
einem eingebetteten Speicher (nicht gezeigt) und führt eine
Verarbeitung, wie beispielsweise ein Einstellen und ein Überwachen
von verschiedenen Programmen, ein Speichermanagement, ein Überwachen und
eine Steuerung der Kommunikationsschnittstelle 241, ein
Auslesen/Einschreiben eines Programms und von Daten von/zu dem Festplattenlaufwerk 242, eine
Erlangung von Information, die von der Maus 243 und der
Tastatur 242 eingegeben ist, und ein Ausgeben von Anzeigeinformation
zu der Anzeige 245 über
Einheiten durch, die gleichermaßen
im Speicher gespeichert sind, wie beispielsweise einen Kommunikationsbustreiber 223,
einen Festplattentreiber 224, einen Maustreiber 225,
einen Tastaturtreiber 226 und einen Anzeigetreiber 227.
Hier ist die Kommunikationsschnittstelle 241 mit der in 10 gezeigten
Kommunikationsschnittstelle 240 über ein Kommunikationskabel
(nicht gezeigt) verbunden, um die Kommunikation zwischen der Workstation 200 und
dem Halbleitertestgerät 100 zuzulassen.
-
Weiterhin
enthält
die OS-Kernroutine 221 eine Verarbeitungseinheit 222 für eine graphische Anwenderschnittstelle
(GUI = Graphical User Interface). Verschiedene Programme, wie beispielsweise ein
Editor 228, ein Compiler 229 für allgemeine Sprache, ein Binder 233,
eine Diagnoseeinheit bzw. ein Debugger 231 für allgemeine
Sprache, ein Compiler 230 für spezifische Sprache und eine
Diagnoseeinheit bzw. ein Debugger 232 für spezifische Sprache, können auf
getrennten Fensterbildschirmen ausgeführt werden, die auf der Anzeige 245 angezeigt
werden. Die Workstation 200 ist bezüglich der Konfiguration äquivalent
zu einem allgemeinen Computer. Die verschiedenen Treiber und Programme,
die oben angegeben sind, sind allgemein im Festplattenlaufwerk 242 gespeichert,
um gemäß der OS-Kernroutine 221 ausgelesen
und ausgeführt
zu werden, wie es nötig ist.
-
Als
nächstes
wird die Prozedur der Entwicklung und der Ausführung des Vorrichtungstestprogramms
im Halbleitertestsystem beschrieben, das aus dem Halbleitertestgerät 100 und
der Workstation 200 besteht. 12 ist
ein Ablaufdiagramm einer Prozedur einer Entwicklung und einer Ausführung eines
herkömmlichen
Vorrichtungstestprogramms. Hier ist das Vorrichtungstestprogramm
mit dem Programm in allgemeiner Sprache und dem Programm in spezifischer
Sprache konfiguriert, wie es oben beschrieben ist. Als Beispiel
ist die C-Sprache als das Programm in allgemeiner Sprache angenommen
und ist ATL (Standard, der für
Advantest Co. spezifisch ist) als das Programm in spezifischer Sprache
angenommen.
-
Zuerst
startet der Programmentwickler den Editor 228 auf der Workstation 200,
um ein Quellprogramm in der C-Sprache zu erzeugen (bei einem Schritt
S301). Das Quellprogramm beschreibt einen Algorithmus des gesamten
Vorrichtungstestprogramms, wie es oben beschrieben ist, und definiert eine
Prozedur zum Aufrufen und Ausführen
des in ATL geschriebenen Objektprogramms und zum Verarbeiten von
Testergebnisdaten, die als Ergebnis der Ausführung erhalten sind.
-
Nach
der Erzeugung des Quellprogramms in der C-Sprache bestimmt der Programmentwickler eine
Datei des erzeugten Quellprogramms (hierin nachfolgend C-Quelldatei
einschließlich
einer nötigen
Anfangsblockdatei oder von ähnlichem
bezeichnet) zu einem C-Compiler (entsprechend dem Compiler 229 für allgemeine
Sprache), um ein Kompilieren auszuführen (bei einem Schritt S302).
Bei dem Kompilierprozess wird zuerst eine Syntaxprüfung durchgeführt. Wenn
ein Syntaxfehler gefunden wird, korrigiert der Programmentwickler
den Fehler mit dem Editor 228 und bestimmt wieder die Ausführung eines
Kompilierens. Wenn kein Fehler gefunden wird, wird eine Objektdatei
erzeugt, die eine Übersetzung der
C-Quelldatei in eine Maschinensprache (die hierin nachfolgend C-Objektdatei
genannt wird) ist.
-
Nach
der Beendigung des Schritts S302 bestimmt der Programmentwickler
nötige
Bibliotheksdateien für
die erzeugten C-Objektdateien und lässt den Binder 233 das
Binden für
die beim Schritt S301 erzeugten C-Quelldateien ausführen (bei
einem Schritt S303). Bei dem Bindeprozess wird eine einzelne C-Objektdatei
erzeugt, die auf dem Testerprozessor 110 des Halbleitertestgeräts 100 direkt
ausführbar
ist.
-
Weiterhin
startet der Programmentwickler den Editor 228 auf der Workstation 200,
um ein Quellprogramm in ATL zu erzeugen (bei einem Schritt S401),
und zwar parallel zu der Erzeugung der Objektdateien in der C-Sprache.
Das Quellprogramm beschreibt, wie es oben beschrieben ist, einen
Steuerbefehl zum Steuern des Halbleitertestgeräts 100.
-
Nach
der Beendigung einer Quellprogrammerzeugung in ATL bestimmt der
Programmentwickler eine erzeugte Quellprogrammdatei (die hierin nachfolgend
ATL-Quelldatei genannt wird) und lässt einen ATL-Compiler (entsprechend
dem Compiler 230 für
spezifische Sprache) das Kompilieren ausführen (bei einem Schritt S402).
Gleich dem oben beschriebenen Schritt S302 wird im Kompilierprozess zuerst
eine Syntaxprüfung
durchgeführt.
Wenn der Syntaxfehler gefunden wird, korrigiert der Programmentwickler
den Fehler mit dem Editor 228 und bestimmt wieder die Ausführung eines
Kompilierens. Wenn kein Fehler gefunden wird, wird das oben beschriebene
ATL-Quellprogramm in eine Maschinensprache eines alten Testerprozessors übersetzt,
die unterschiedlich von der Maschinensprache ist, die in der C-Objektdatei
verwendet wird, was anders ausgedrückt bedeutet, in eine Maschinensprache,
die für einen
spezifischen Testerprozessor verständlich ist, und eine Objektdatei
(die hierin nachfolgend ATL-Objektdatei genannt wird) wird erzeugt.
-
Wenn
die einzige C-Objektdatei und die ATL-Objektdateiengruppe gemäß einer
solchen Prozedur vorbereitet sind, startet der Programmentwickler
ein Steuerprogramm zum Ermöglichen
der Kommunikation mit dem Halbleitertestgerät 100 auf der Workstation 200 und
transferiert mit der Verwendung des gestarteten Steuerprogramms
die einzelne C-Objektdatei und die ATL-Objektdateiengruppe zu dem
Testerprozessor 110 des Halbleitertestgeräts 100 (bei
Schritten S304 und S403).
-
Dann
bestimmt der Programmentwickler die Ausführung der einzelnen C-Objektdatei
zu dem Steuerprogramm (bei einem Schritt S305). Dann wiederholt
der Testerprozessor 110 des Halbleitertestgeräts 100 gemäß dem in
der einzelnen C-Objektdatei beschriebenen
Algorithmus den Verarbeitungszyklus beginnend ab der Ausführung der
ATL-Objektdatei, über
die Operation bzw. den Betrieb einer erwünschten Testeinheit in der
Haupttestereinheit 120, eine Erlangung eines von der getesteten
Vorrichtung 131 erhaltenen Testergebnisses bis zu einer
Datenverarbeitung. Hier kann das Testergebnis, in Bezug auf welches
eine geeignete Datenverarbeitung durchgeführt wird, gemäß dem oben
angegebenen Steuerprogramm über
die Kommunikationsschnittstelle 140 des Halbleitertestgeräts 100,
das Kommunikationskabel, und die Kommunikationsschnittstelle 241 des Halbleitertestgeräts 100 empfangen
werden und auf dem Fensterbildschirm angezeigt werden, der für das Steuerprogramm
bestimmt ist.
-
Beim
Finden einer Unannehmlichkeit, wie beispielsweise eines offensichtlichen
Fehlers, in Testergebnissen bestimmt der Programmentwickler, dass
das Vorrichtungstestprogramm einen logischen Fehler enthält. Dann
startet der Programmentwickler den Debugger 231 für allgemeine
Sprache auf der Workstation 200, um eine Abbruchstelle
in einer vorbestimmten Angabe bzw. Anweisung in der C-Quelldatei
einzustellen. Wenn der Programmentwickler ein Starten eines Diagnostizierens
beauftragt, führt
der Debugger 231 für
allgemeine Sprache die einzelne C-Objektdatei gemäß der Prozedur
der Schritte S302 bis S305 wieder aus. Wenn erfasst wird, dass der Prozess
die eingestellte Abbruchstelle in der Angabe bzw. Anweisung erreicht,
wird eine gültige
Variable bis zu der Abbruchstelle angezeigt. Der Programmentwickler
startet auf ein Finden eines logischen Fehlers durch das Prüfen der
gültigen
Variablen hin den Editor 228, um die C-Quelldatei zu korrigieren, wie
es nötig
ist, und wiederholt die Prozedur der Schritte S302 bis S305, wie
es oben beschrieben ist.
-
Andererseits
fährt der
Programmentwickler dann, wenn der Debugger 231 für allgemeine
Sprache keinen logischen Fehler in der C-Quelldatei findet, mit
einem Starten des Debuggers 232 für spezifische Sprache fort,
um eine Abbruchstelle in einer vorbestimmten Angabe in der ATL-Quelldatei
einzustellen und um einen Diagnoseprozess durchzuführen, wie
oben.
-
Wie
es früher
beschrieben ist, sind jedoch dann, wenn das an der getesteten Vorrichtung
(hier bei dem Beispiel dem Halbleitertestgerät) auszuführende Programm in unterschiedlichen
Sprachen, wie beispielsweise der allgemeinen Sprache und der spezifischen
Sprache geschrieben ist, auch wenn die Nutzung des vergangenen Programmbetriebsmittels, das
in der spezifischen Sprache geschrieben ist, zugelassen ist, unterschiedliche
Quelldateien in der Entwicklungsstufe der Programme nötig. Bei
dem obigen Beispiel müssen
zwei unterschiedliche Dateien als die C-Quelldatei und die ATL-Quelldatei
vorbereitet werden. Kurz gesagt sind dann, wenn die in der allgemeinen
Sprache geschriebene Quelldatei einen Aufruf der in der spezifischen
Sprache geschriebenen Objektdatei enthält, wenigstens zwei Quelldateien
nötig.
Insbesondere muss eine Quelldatei in allgemeiner Sprache in Kombination
mit einer entsprechenden Quelldatei in spezifischer Sprach gemanagt werden,
da eine Quelldatei in allgemeiner Sprache einer Quelldatei in spezifischer
Sprache entspricht.
-
Weiterhin
ist eine Identifikation von zugehörigen Quelldateien, die in
unterschiedlichen Sprachen geschrieben sind, basierend auf den Inhalten
der Quelldateien schwierig. Somit kann ein Fehlmanagement der Quelldateien
Verschwendungen an Zeit und Energie für das erneute Lokalisieren
einer Quelldateienzuordnung veranlassen. Somit müssen die Korrektur und eine
Teilzitierung von Quelldateien auf dem Editor mit höchster Vorsicht
durchgeführt
werden. Eine solche Unannehmlichkeit trägt auch dazu bei, die Anzahl
von Fehlern zu erhöhen,
die durch den Programmentwickler gemacht werden.
-
Weiterhin
wird deshalb, weil es erforderlich ist, dass sowohl eine Quelldatei
in allgemeiner Sprache als auch die Quelldatei in spezifischer Sprache für ein Ausführungsprogramm
vorbereitet werden, dieselbe Anzahl von Objektdateien als Ergebnis
eines Kompilierens davon erzeugt. Dies bedeutet eine weitere Komplikation
bezüglich
des Managements. Somit existieren herkömmlich Quelldateien und Objektdateien
in unterschiedlichen Sprachen pro einem Ausführungsprogramm, was das Dateimanagement kompliziert
macht und die Entwicklungseffizienz des Programms verschlechtert.
-
Angesichts
des vorangehenden ist es eine Aufgabe der vorliegenden Erfindung,
eine Programmentwicklungsunterstützungsvorrichtung, eine
Programmausführungsvorrichtung,
ein Kompilierverfahren und ein Diagnoseverfahren zur Verfügung zu
stellen, welche durch ein Einbetten einer in einer spezifischen
Sprache geschriebenen Quelldatei in eine Vorprozessorbeschreibung
einer Quelldatei in allgemeiner Sprache eine signifikante Reduzierung
bezüglich
der Anzahl von nötigen
Quelldateien und Objektdateien pro einer Ausführungsdatei zulassen, und eine
Nutzung von vergangenen Ressourcen bzw. Betriebsmitteln, die in
der spezifischen Sprache geschrieben sind.
-
OFFENBARUNG
DER ERFINDUNG
-
Zum
Erreichen einer Aufgabe, wie sie oben beschrieben ist, dient eine
Programmausführungsvorrichtung
gemäß der vorliegenden
Erfindung zum Erzeugen einer Programmdatei, die auf einer vorbestimmten
Programmausführungsvorrichtung
ausführbar
ist, aus einem Quellprogramm mit gemischter Sprache, wobei ein Quellprogramm
in spezifischer Sprache in einem vorbestimmten Bereich eines Quellprogramms
für allgemeine
Zwecke geschrieben ist, und enthält
eine Kompiliereinheit für
spezifische Sprache (entsprechend einem später beschriebenen Compiler 30 für spezifische
Sprache), die das Quellprogramm in spezifischer Sprache kompiliert,
um einen Objektcode in spezifischer Sprache zu erzeugen; eine Kompiliereinheit
für allgemeine
Sprache (einen Compiler 29 für allgemeine Sprache, wie er später beschrieben
ist), die das Quellprogramm in allgemeiner Sprache kompiliert, um
einen Objektcode in allgemeiner Sprache zu erzeugen; eine integrative Kompiliereinheit
(entsprechend einem integrativen Compiler 34, wie er später beschrieben
ist), die das Quellprogramm in spezifischer Sprache aus dem Quellprogramm
in gemischter Sprache extrahiert, das extrahierte Quellprogramm
in spezifischer Sprache zu der Kompiliereinheit für spezifische
Sprache zum Ausführen
bestimmt, das Quellprogramm in gemischter Sprache zu der Kompiliereinheit für allgemeine
Sprache zum Ausführen
bestimmt, den erhaltenen Objektcode in spezifischer Sprache und
den Objektcode in allgemeiner Sprache integriert, um eine Objektdatei
zu erzeugen; und eine Bindereinheit (entsprechend einem Binder 33,
wie er später
beschrieben ist), die die Programmdatei aus wenigstens einer Objektdatei
erzeugt, die durch die integrative Kompiliereinheit erzeugt ist.
-
Weiterhin
führt eine
Programmausführungsvorrichtung
(entsprechend einem Halbleitertestgerät 11, das später beschrieben
ist) gemäß der vorliegenden
Erfindung eine Programmdatei aus, wo ein Objektcode eines Quellprogramms
in allgemeiner Sprache und ein Objektcode eines Quellprogramms in spezifischer
Sprache auf gemischte Weise vorhanden sind, und werden der Objektcode
des Quellprogramms in allgemeiner Sprache und der Objektcode des
Quellprogramms in spezifischer Sprache in einen Speicher geladen,
wenn eine Ausführung
der Programmdatei beginnt.
-
Weiterhin
dient ein Kompilierverfahren gemäß der vorliegenden
Erfindung zum Erzeugen einer Programmdatei, die auf einer vorbestimmten
Programmausführungsvorrichtung
ausführbar
ist, aus einem Quellprogramm in gemischter Sprache, wo ein Quellprogramm
in spezifischer Sprache in einem vorbestimmten Bereich eines Quellprogramms
in allgemeiner Sprache geschrieben ist, und enthält einen Extraktionsschritt
für ein
Quellprogramm in spezifischer Sprache (entsprechend einem Schritt
S121, der später
beschrieben ist) zum Extrahieren des Quellprogramms in spezifischer
Sprache aus dem Quellprogramm in gemischter Sprache; einen Kompilierschritt
für spezifische
Sprache (entsprechend einem Schritt S123, der später beschrieben ist) zum Kompilieren
des extrahierten Quellprogramms in spezifischer Sprache, um einen
Objektcode in spezifischer Sprache zu erzeugen; einen Kompilierschritt für allgemeine
Sprache (entsprechend einem Schritt S122, der später beschrieben ist), der eine
Beschreibung des Quellprogramms in allgemeiner Sprache aus dem Quellprogramm
in gemischter Sprache kompiliert, um einen Objektcode in allgemeiner
Sprache zu erzeugen; einen Objektdatei-Erzeugungsschritt (entsprechend einem
Schritt S124, der später beschrieben
ist) zum Kombinieren des Objektcodes in spezifischer Sprache und
des Objektcodes in allgemeiner Sprache, um eine Objektdatei zu erzeugen;
und einen Bindeschritt (entsprechend einem Schritt S130, der später beschrieben
ist) zum Erzeugen der Programmdatei aus wenigstens einer Objektdatei,
die durch die Objektdatei-Erzeugung
erzeugt ist.
-
Weiterhin
ist ein Diagnoseverfahren gemäß der vorliegenden
Erfindung ein Diagnoseverfahren zum Diagnostizieren einer Programmdatei,
die auf einer vorbestimmten Programmausführungsvorrichtung ausführbar ist,
die aus einem Quellprogramm im gemischter Sprache erzeugt ist, wo
ein Quellprogramm in spezifischer Sprache in einem vorbestimmten
Bereich eines Quellprogramms in allgemeiner Sprache geschrieben
ist, und enthält
einen Abbruchstellen-Einstellschritt
zum Einstellen einer Abbruchstelle in einer Angabe bzw. Anweisung
im Quellprogramm in gemischter Sprache; einen Diagnose-Startschritt
zum Stoppen der Programmdatei bei der Abbruchstelle während einer
Ausführung
der Programmdatei, zum Starten eines Debuggers für allgemeine Sprache, wenn
die Angabe der gestoppten Programmdatei zu dem Quellprogramm in
allgemeiner Sprache gehört
(entsprechend einem Schritt S203, der später beschrieben wird), und
zum Starten eines Debuggers für
spezifische Sprache, wenn die Angabe der gestoppten Programmdatei
zu dem Quellprogramm in spezifischer Sprache gehört (entsprechend einem Schritt
S206, der später
beschrieben wird); und einen Diagnoseinformations-Anzeigeschritt zum
Anzeigen von Diagnoseinformation auf einem gemeinsamen Fensterbildschirm
(entsprechend einem Schritt S205, der später beschrieben wird), die
aus dem Debugger für
allgemeine Sprache und dem Debugger für spezifische Sprache erhalten ist
(entsprechend Schritten S204 und S207, die später beschrieben werden).
-
Weiterhin
ist ein computerlesbares Aufzeichnungsmedium gemäß der vorliegenden Erfindung dadurch
gekennzeichnet, dass das Kompilierverfahren durch einen Computer
ausgeführt
wird.
-
Weiterhin
ist ein computerlesbares Aufzeichnungsmedium gemäß der vorliegenden Erfindung dadurch
gekennzeichnet, dass das Diagnoseverfahren durch einen Computer
ausgeführt
wird.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
1 ist
ein Blockdiagramm einer Gesamtstruktur eines Halbleitertestsystems
gemäß einem Ausführungsbeispiel;
-
2 ist
ein Ablaufdiagramm einer Prozedur einer Entwicklung und einer Ausführung eines
Vorrichtungstestprogramms;
-
3 ist
ein Beispiel einer Beschreibung durch ein C+ATL-Quellprogramm;
-
4 ist
ein Ablaufdiagramm eines Kompilierprozesses durch einen integrativen
Compiler;
-
5 ist
ein erklärendes
Diagramm eines Prozesses einer ATL-Quelldatei-Erzeugung;
-
6 ist
ein Diagramm einer Konfiguration einer C+ATL-Objektdatei;
-
7 ist
ein Ablaufdiagramm einer Debugger-Auswahlroutine;
-
8 ist
ein Beispiel eines Ausführungsbildschirms
eines integrativen Debuggers, wenn ein Abbruch in einer ATL-Beschreibung
auftritt;
-
9 ist
ein Beispiel eines Ausführungsbildschirms
eines integrativen Debuggers, wenn ein Abbruch in einer C-Sprachenbeschreibung
auftritt,
-
10 ist
ein Blockdiagramm einer Gesamtstruktur eines herkömmlichen
Halbleitertestsystems;
-
11 ist
ein Blockdiagramm einer Gesamtstruktur einer Workstation in einem
herkömmlichen Halbleitertestsystem;
und
-
12 ist
ein Ablaufdiagramm einer Prozedur einer Entwicklung und einer Ausführung eines herkömmlichen
Vorrichtungstestprogramms.
-
BESTE ART(EN) ZUM AUSFÜHREN DER
ERFINDUNG
-
Im
Folgenden wird ein beispielhaftes Ausführungsbeispiel einer Programmentwicklungsunterstützungsvorrichtung,
einer Programmausführungsvorrichtung,
eines Kompilierverfahrens und einer Diagnoseverfahrens gemäß der vorliegenden
Erfindung detailliert unter Bezugnahme auf die beigefügten Zeichnungen
beschrieben werden. Das Ausführungsbeispiel
soll nicht auf die vorliegende Erfindung beschränkt sein.
-
Um
das Verstehen von Merkmalen der vorliegenden Erfindung zu erleichtern,
ist die vorliegende Erfindung bei einem Ausführungsbeispiel auf ein Halbleitertestsystem
angewendet, welches mit einem Halbleitertestgerät und einer Workstation konfiguriert ist,
was gleich der herkömmlichen
Technik ist, wie sie oben beschrieben ist. Spezifisch entspricht
die Programmentwicklungsunterstützungsvorrichtung gemäß der vorliegenden
Erfindung der Workstation im Halbleitertestsystem, entspricht die
Programmausführungsvorrichtung
gemäß der vorliegenden Erfindung
dem Halbleitertestgerät
im Halbleitertestsystem und entsprechen das Kompilierverfahren und das
Diagnoseverfahren gemäß der vorliegenden
Erfindung dem Kompilierverfahren und dem Diagnoseverfahren, die
auf dem Halbleitertestsystem durchgeführt werden.
-
1 ist
ein Blockdiagramm eines Halbleitertestsystems gemäß dem Ausführungsbeispiel. Das
in 1 gezeigte Halbleitertestsystem enthält eine
Workstation 10 und ein Halbleitertestgerät 11, die über ein
Kommunikationskabel miteinander verbunden sind.
-
Die
Grundstruktur der Workstation 10 ist gleich der Struktur
der Workstation 200 des herkömmlichen Halbleitertestsystems,
und ein Prozessor 20, eine Kommunikationsschnittstelle 41,
ein Festplattenlaufwerk 42, eine Maus 43, eine
Tastatur 44 und eine Anzeige 45, die in 1 gezeigt
sind, entsprechen jeweils dem Prozessor 20, der Kommunikationsschnittstelle 41,
dem Festplattenlaufwerk 42, der Maus 43, der Tastatur 44 und
der Anzeige 45, die in 11 gezeigt
sind.
-
Gleichermaßen entsprechen
Einheiten, die in einem Speicher (nicht gezeigt) im Prozessor 20 gespeichert
sind, wie beispielsweise eine OS-Kernroutine 21, eine GUI-Verarbeitungseinheit 22,
ein Kommunikationsbustreiber 23, ein Festplattentreiber 24, ein
Maustreiber 25, ein Tastaturtreiber 26, ein Anzeigentreiber 27,
ein Editor 28, ein Compiler 29 für allgemeine
Sprache, ein Compiler 30 für spezifische Sprache, ein
Debugger 31 für
allgemeine Sprache, ein Debugger 32 für spezifische Sprache und ein
Binder 33 jeweils der OS-Kernroutine 221, der GUI-Verarbeitungseinheit 222,
dem Kommunikationsbustreiber 223, dem Festplattentreiber 224,
dem Maustreiber 225, dem Tastaturtreiber 226,
dem Anzeigentreiber 227, dem Editor 228, dem Compiler 229 für allgemeine
Sprache, dem Compiler 230 für spezifische Sprache, dem
Debugger 231 für
allgemeine Sprache, dem Debugger 232 für spezifische Sprache und dem Binder 233,
die in 11 gezeigt sind.
-
Die
Workstation 10 gemäß dem Ausführungsbeispiel
unterscheidet sich von der herkömmlichen
Workstation 200 darin, dass die Workstation 10 einen
integrativen Compiler 34 als Anwendung auf höherer Ebene
des Compilers 29 für
allgemeine Sprache und des Compilers 30 für spezifische
Sprache enthält.
Anders ausgedrückt
kann die Workstation 10 den Compiler 29 für allgemeine
Sprache und den Compiler 30 für spezifische Sprache über den
integrativen Compiler 34 nutzen.
-
Weiterhin
unterscheidet sich die Workstation 10 gemäß dem Ausführungsbeispiel
von der herkömmlichen
Workstation 200 darin, dass die Workstation 10 einen
integrativen Debugger 35 als Anwendung auf höherer Ebene
des Debuggers 31 für allgemeine
Sprache und des Debuggers 32 für spezifische Sprache enthält. Die
Workstation 10 kann den Debugger 31 für allgemeine
Sprache und den Debugger 32 für spezifische Sprache über den
integrativen Debugger 35 auf gleiche Weise wie den integrativen
Compiler 34 nutzen.
-
Das
Halbleitertestgerät 11 ist
derart gezeigt, dass es mit der Workstation 10 im Halbleitertestsystem
der 1 verbunden ist, und die interne Struktur des
Halbleitertestgeräts 11 ist
gleich dem herkömmlichen
Halbleitertestgerät 100,
das in 10 gezeigt ist. Bei dem Halbleitertestgerät 11,
arbeitet jedoch der Testerprozessor teilweise unterschiedlich von dem
herkömmlichen
Prozessor, und zwar in Abhängigkeit
von einem Typ eines Programms, das in der Workstation 10 zu
entwickeln ist.
-
Eine
Prozedur einer Entwicklung und einer Ausführung eines Vorrichtungstestprogramms
im Halbleitertestsystem wird beschrieben. 2 ist ein Ablaufdiagramm
einer Prozedur der Entwicklung und der Ausführung des Vorrichtungstestprogramms
gemäß dem Ausführungsbeispiel.
Gleich der Beschreibung der 12 ist
bei einem in 2 gezeigten Beispiel das Vorrichtungstestprogramm
mit dem Programm in allgemeiner Sprache und dem Programm in spezifischer
Sprache konfiguriert, und die C-Sprache ist als das Programm in
allgemeiner Sprache angenommen und ATL (Standard, der spezifisch
für Advantest
Co. ist) ist als Programm in spezifischer Sprache angenommen.
-
Zuerst
startet der Programmentwickler den Editor 28 auf der Workstation 10,
um ein Quellprogramm zu erzeugen (bei einem Schritt S110). Das in der
C-Sprache, die die allgemeine Sprache ist, geschriebene Quellprogramm
enthält
eine Vorprozessorbeschreibung des Inhalts einer ATL-Quelldatei, die
in der spezifischen Sprache geschrieben ist, ungleich dem Inhalt
der C-Quelldatei der 12 ist. Ein solches Quellprogramm
wird C+ATL-Quellprogramm genannt.
-
3 zeigt
ein Beispiel der C+ATL-Quellprogrammbeschreibung.
Eine Beschreibung von "Nr:" am linken Rand der 3 ist
eine Zeilennummer, die für
einen beschreibenden Zweck verwendet ist und die bei der tatsächlichen
Programmoperation ignoriert wird. In der folgenden Beschreibung
des Inhalts des C+ATL-Quellprogramms wird auf jede Angabe mit der
Zeilennummer Bezug genommen werden.
-
Der
C-Sprachen-Compiler erkennt eine Angabe beginnend ab # als einen
Vorprozessorbefehl. In dem in 3 gezeigten
C+ATL-Quellprogramm sind "#include" mit der Zeilennummer
1, "#pragma" mit den Zeilennummern
3, 4 und 5 die Vorprozessorbefehle. Der Befehl "#include" ist ein Befehl zum einfachen Ausdehnen
des Inhalts einer Beschreibung einer Anfangsblockdatei "AT/hybrid.h" bei der Position
und der Inhalt des Befehls ist für
eine Hauptfunktion beginnend ab der Zeilennummer 10 nötig.
-
Andererseits
ist "pragma" ein spezieller Vorprozessorbefehl
zum Realisieren einer eindeutigen Funktion der Maschine oder des
OS, während
die gesamte Kompatibilität
zu der C-Sprache aufrecherhalten wird. Somit ist "#pragma" per Definition eindeutig für die Maschine
oder das OS und allgemein unterschiedlich für jeden Compiler. Der Befehl "#pragma" wird grundsätzlich zum
Gewähren
einer neuen Funktion zu dem Vorprozessor oder zum Liefern von Information
in Abhängigkeit
von einer Implementierung zum Compiler verwendet. In dem gemäß dem Ausführungsbeispiel
erzeugten C+ATL-Quellprogramm ist eine Beschreibung in ATL, welches
eine spezifische Sprache ist, als Token eingebettet, der durch "#pragma" gegeben ist. Ein
Verarbeiten der ATL-Beschreibung, die durch "#pragma" gegeben ist, wird später beschrieben
werden.
-
Die
Inhalte der Beschreibung, welche Prozesse definieren, wie beispielsweise
den Aufruf der ATL-Objektdatei, und einen Datenprozess, in den Zeilennummern
10 bis 28 in dem in 3 gezeigten C+ATL-Quellprogramm
sind dieselben wie die Inhalte, die auf der Workstation des herkömmlichen
Halbleitertestsystems erzeugt sind.
-
Nach
der Beendigung der Erzeugung des C+ATL-Quellprogramms bestimmt der
Programmentwickler eine Datei des erzeugten C+ATL-Quellprogramms
(das hierin nachfolgend C+ATL-Quelldatei einschließlich nötiger Dateien,
wie beispielsweise einer Anfangsblockdatei, genannt wird) zu dem
integrativen Compiler 34 zum Ausführen des Kompilierens (bei
einem Schritt S120). Bei der Ausführung des Kompilierens wird
zuerst die Syntaxprüfung durchgeführt, und
dann, wenn der Syntaxfehler gefunden wird, korrigiert der Programmentwickler
den Fehler mit dem Editor 28 und bestimmt wieder die Ausführung eines
Kompilierens. Wenn kein Fehler gefunden wird, beginnt der Kompilierprozess
zum Erzeugen der Objektdatei.
-
4 ist
ein Ablaufdiagramm des Kompilierprozesses, der durch den integrativen
Compiler 34 durchgeführt
wird. Wenn kein Syntaxfehler in der beim Schritt S110 erzeugten
C+ATL-Quelldatei
gefunden wird, fährt
der integrative Compiler 34 damit fort, die ATL-Beschreibung
aus der C+ATL-Quelldatei zu extrahieren, um die ATL-Quelldatei zu
erzeugen (bei einem Schritt S121). 5 ist gezeigt,
um den Prozess einer ATL-Quelldatei-Erzeugung
zu beschreiben. Der Erzeugungsprozess der ATL-Quelldatei, wie er
oben beschrieben ist, beginnt mit der Identifikation von "#pragma" aus der Vorprozessorbeschreibung
in der C+ATL-Quelldatei und der Analyse eines Tokens, der "#pragma" folgt. Bei einem
in 5 gezeigten Beispiel ist "atl" direkt
hinter "#pragma" ein Schlüsselwort,
das anzeigt, dass die folgende Information die ATL-Beschreibung
ist.
-
Unter
Bezugnahme auf das Beispiel der 5 extrahiert
der integrative Compiler 34 spezifischer auf ein Erkennen
von "#pragma atl" in der Zeilennummer
3 hin das folgende Schlüsselwort "name", um dadurch zu interpretieren,
dass die nach dem Schlüsselwort "name" mit Anführungszeichen
markierte Beschreibung, d.h. "SAMPLE", ein Programmname
ist. Gemäß der Interpretation
wird "PRO SAMPLE" an den Anfang der
ATL-Quelldatei eingefügt. Dann
extrahiert der integrative Compiler 34, der "#pragma atl" in der Zeilennummer
4 erkennt, das folgende Schlüsselwort "socket" und interpretiert,
dass die nach dem Schlüsselwort "socket" mit Anführungszeichen
markierte Beschreibung, d.h. "SSOC", ein Sockelprogrammname
der ATL ist. Gemäß der Interpretation
wird "SSOC" hinter "PRO SAMPLE" in der ATL-Quelldatei
eingefügt.
Dann extrahiert der integrative Compiler 34, der "#pragma atl" in der Zeilennummer
5 erkennt, das folgende Schlüsselwort "proc" und interpretiert,
dass die Zeichenfolge direkt hinter dem Schlüsselwort "proc" und
die folgende Beschreibung, die mit Anführungszeichen markiert ist, d.h.
P1(ARGI,ARG2(2)) "{WRITE "ARG1=",ARG1,/WRITE "ARG2=",ARG2,/}", eine Funktionsdefinition
ist. Gemäß der Interpretation
wird die Beschreibung
P1: ARGUMENT (ARG1, ARG2(2))
WRITE "ARG1=", ARG1,/
WRITE "ARG2=", ARG2,/
GOTO
CONTINUE
zu der ATL-Quelldatei hinzugefügt.
-
Dann
fügt der
integrative Compiler 34 auf ein Erreichen der letzten Zeilennummer
(der Zeilennummer 28) der C+ATL-Quelldatei hin, ohne irgendein weiteres "#pragma atl" in der C+ATL-Quelldatei
zu finden, "END" an das Ende der
ATL-Quelldatei ein, um
die Erzeugung der ATL-Quelldatei zu beenden.
-
Nach
der Beendigung der ATL-Quelldatei-Erzeugung führt der integrative Compiler 34 ein Kompilieren
der C-Sprachenbeschreibung
in der C+ATL-Quelldatei durch, d.h. eine Erzeugung des C-Objektcodes
(bei einem Schritt S122). Der normale C-Compiler (entsprechend dem
Compiler 29 für
allgemeine Sprache) führt
das Kompilieren unter einem Ignorieren der Beschreibung von oben
beschriebenem "#pragma" durch. Bei dem Ausführungsbeispiel ruft
der integrative Compiler 34 den C-Compiler für den Prozess
auf, jedoch kann die Funktion des C-Compilers in den integrativen
Compiler 34 selbst eingebettet sein, um die C-Objektcodeerzeugung
parallel zu der oben beschriebenen ATL-Quelldatei-Erzeugung durchzuführen. Dann
kann der Compiler 29 für
allgemeine Sprache, der in 1 gezeigt
ist, unnötig
sein.
-
Nach
der Beendigung der C-Objektcodeerzeugung führt der integrative Compiler 34 ein
Kompilieren der beim Schritt S121 erzeugten ATL-Quelldatei durch,
d.h. die Erzeugung des ATL-Objektcodes (bei
einem Schritt S123). Mit dem Aufruf des ATL-Compilers (entsprechend dem Compiler 30 für spezifische
Sprache) wird das Kompilieren beendet. Gleich dem Schritt S402 der 12 wird
die Datei in eine Maschinensprache übersetzt, die spezifisch für den alten
Testerprozessor ist (eine Maschinensprache, die in einem spezifischen
Testerprozessor verständlich
ist), welche unterschiedlich von einer Maschinensprache ist, die
im C-Objektcode geschrieben ist.
-
Nach
der Beendigung der Erzeugung des ATL-Objektcodes kombiniert der
integrative Compiler 34 den beim Schritt S122 erzeugten
C-Objektcode mit den beim Schritt S121 erzeugten ATL-Objektcode und
fügt Positionsinformation
für eine
Stelle hinzu, wo der ATL-Objektcode gespeichert ist (eine ATL-Objektcode-Startstelle),
um eine Objektdatei zu erzeugen (die hierin nachfolgend "C+ATL-Objektdatei" genannt wird) (bei
einem Schritt S124). 6 zeigt eine Struktur einer
solchen C+ATL-Objektdatei. Wie es in 6 gezeigt
ist, ist in der C+ATL-Objektdatei der ATL-Objektcode hinter dem
C-Objektcode angeordnet. In 6 ist nun
zusätzliche
Information, wie beispielsweise die Positionsinformation des ATL-Objektcodes,
gezeigt.
-
Der
integrative Compiler 34 führt den Kompilierprozess an
den auf dieselbe Weise erzeugten C+ATL-Quelldateien durch, um dadurch
eine Vielzahl von C+ATL-Objektdateien vorzubereiten. Nach dem Kompilierprozess
durch den integrativen Compiler 34 bestimmt der Programmentwickler
zu dem Binder 33 nötige
Bibliotheksdateien für
die Vielzahl von C+ATL-Objektdateien, die erzeugt sind, wie es oben beschrieben
ist, und ähnliches,
um ein Binden auszuführen
(Schritt S130 der 2).
-
Zusätzlich zu
den nötigen
Bibliotheksdateien für
die Vielzahl von C+ATL-Objektdateien, die erzeugt sind, wie es oben
beschrieben ist, und ähnliches,
vorbereitet und bindet der Binder 33 ein Ladeprogramm zum
Laden des ATL-Objektcodeabschnitts
von jeder der C+ATL-Objektdateien, um eine einzige Objektdatei zu
erzeugen, die auf den Testerprozessor des Halbleitertestgeräts 11 direkt
ausführbar
ist.
-
Wenn
die einzige Objektdatei bereits die Prozedur durchlaufen hat, wie
sie oben beschrieben ist, startet der Programmentwickler ein Steuerprogramm,
das die Kommunikation mit dem Halbleitertestgerät 11 ermöglicht,
auf der Workstation 10, um die einzige Objektdatei zu dem
Testerprozessor des Halbleitertestgeräts 11 unter Verwendung
des Steuerprogramms zu transferieren (bei einem Schritt S140).
-
Dann
gibt der Programmentwickler eine Ausführungsanweisung der einzigen
Objektdatei zum Steuerprogramm (bei einem Schritt S150). In Reaktion
auf die Anweisung lädt
der Testprozessor des Halbleitertestgeräts 11 zuerst den C-Objektcode und den
ATL-Objektcode, die in der einzigen Objektdatei angeordnet sind,
auf den Speicher gemäß dem Ladeprogramm,
das in der einzigen Objektdatei enthalten ist. Dann wiederholt der
Testerprozessor den Prozess von: einer Ausführung des geladenen ATL-Objektcodes;
einer Operation einer erwünschten
Testeinheit in der Haupttestereinheit; einem Erlangen von Testergebnissen
von der getesteten Vorrichtung; und einer Datenverarbeitung gemäß dem Algorithmus,
der im geladenen C-Objektcode beschrieben ist. Hier kann das Testergebnis
nach einer geeigneten Datenverarbeitung durch das oben angegebene Steuerprogramm über die
Kommunikationsschnittstelle des Halbleitertestgeräts 11,
das Kommunikationskabel, und die Kommunikationsschnittstelle 41 der
Workstation 10 empfangen werden und auf einem Fensterbildschirm
angezeigt werden, der dem Steuerprogramm zugeteilt ist, was gleich
der herkömmlichen
Technik ist.
-
Obwohl
hier angenommen ist, dass das Ladeprogramm in der einzigen Objektdatei
enthalten ist, kann das Ladeprogramm im Voraus ausgelesen und im
Testerprozessor des Halbleitertestgeräts 11 gespeichert
werden und zu Beginn des Prozesses gemäß der Ausführungsanweisung von der Workstation 10 gestartet
werden.
-
Als
nächstes
wird der Diagnoseprozess des Halbleitertestsystems gemäß dem Ausführungsbeispiel
beschrieben werden. Der Programmentwickler führt dann, wenn Unannehmlichkeiten,
wie beispielsweise die Anormalität,
aus dem durch die Ausführung des
Schritts S150 erhaltenen Testergebnis gefunden werden, den Diagnoseprozess
des Vorrichtungstestprogramms wie bei der herkömmlichen Technik durch. Zuerst
startet der Programmentwickler den integrativen Debugger 35 auf
der Workstation 10 um eine Abbruchstelle in einer vorbestimmten
Angabe bzw. Anweisung in der C+ATL-Quelldatei einzustellen.
-
Dann
führt der
integrative Debugger 35 in Reaktion auf die Anweisung zum
Starten eines Diagnostizierens, die vom Programmentwickler gesendet ist,
die einzige Objektdatei gemäß der Prozedur
der oben beschriebenen Schritte S120 bis S150 aus. Auf eine Erfassung
hin, dass die Verarbeitung die Abbruchstelle in der ausgeführten Angabe
erreicht, führt der
integrative Debugger 35 eine Debugger-Auswahlroutine aus,
um auszuwählen,
welcher von einem C-Debugger (entsprechend dem Debugger 31 für allgemeine
Sprache) oder einem ATL-Debugger (entsprechend dem Debugger 32 für spezifische Sprache)
zu starten ist.
-
7 ist
ein Ablaufdiagramm der Debugger-Auswahlroutine. Der integrative
Debugger 35 zeigt dann, wenn der Prozess die Abbruchstelle
der Angabe erreicht, die in der einzigen Objektdatei sequenziell
ausgeführt
ist, die Angabe an, in welcher die Abbruchstelle eingestellt ist
(bei einem Schritt S201). Dann startet der integrative Debugger 35, wenn
die Angabe in dem RTL-Objektcodeabschnitt ist (Ja im Schritt S202),
den ATL-Debugger (bei einem Schritt S206), um eine Diagnoseinformation,
wie beispielsweise eine in der Angabe mit einer Abbruchstelle enthaltene
Variable, von dem ATL-Debugger
zu erlangen (bei einem Schritt S207). Hier erlangt der ATL-Debugger
dann, wenn die Abbruchstelle eingestellt ist, wie es oben angegeben
ist, Abbruchstelleneinstellinformation des ATL-Objektcodeabschnitts über den
integrativen Debugger.
-
Der
integrative Debugger 35 zeigt auf ein Erlangen der Diagnoseinformation
vom ATL-Debugger hin eine bestimmte Variable (ein bestimmtes Symbol) an,
das zu der Zeit eines Abbruchs effektiv gemacht ist (bei einem Schritt
S205). 8 zeigt ein Beispiel eines Ausführungsbildschirms
des integrativen Debuggers 35, und zwar insbesondere in
einem Zustand, in welchem der Abbruch in der ATL-Beschreibung aufgetreten
ist. In 8 zeigt der integrative Debugger 35 zusätzlich zu
einer standardmäßigen Fensteranzeigeneinstellung
als Titel- und als Menü- in
einem Ausführungsfenster 50 einen
Abbruchstelleneinstellbereich 51, einen Quellenanzeigebereich 52 und
einen Symbolanzeigebereich 53 an. In 8 ist,
um den Abbruchzustand der ATL-Beschreibung im
C+ATL-Quellprogramm anzuzeigen, die Angabe mit der Zeilennummer
5, wo die Abbruchstelle eingestellt ist, im Quellenanzeigebereich 52 gezeigt
und sind Variable und Werte, welche die Variablen in der Angabe
annehmen können,
im Symbolanzeigebereich 53 gezeigt.
-
Andererseits
startet der integrative Debugger 35 dann, wenn die Angabe
mit einem Abbruch im C-Objektcodeabschnitt ist (Nein beim Schritt
S202), den C-Debugger (bei einem Schritt S203), um eine Diagnoseinformation,
wie beispielsweise eine in der Angabe enthaltene Variable, mit einem
Abbruch von dem C-Debugger zu erlangen (bei einem Schritt S204).
Hier erlangt der C-Debugger zur Zeit einer Abbruchstelleneinstellung
die Abbruchstelleneinstellinformation des C-Objektcodeabschnitts über den
integrativen Debugger 35.
-
Der
integrative Debugger 35 zeigt auf ein Erlangen der Diagnoseinformation
vom C-Debugger hin eine bestimmte Variable (ein bestimmtes Symbol),
welche bei dem Abbruch effektiv gemacht ist (bei einem Schritt S205). 9 zeigt
ein Beispiel eines Ausführungsbildschirms
des integrativen Debuggers 35, und zwar insbesondere in
einem Zustand, in welchem der Abbruch in der C-Sprachenbeschreibung
aufgetreten ist. Das in 9 gezeigte Ausführungsfenster 50 des
integrativen Debuggers 35 ist von gleicher Konfiguration
wie das in 8 gezeigte Fenster. In 9 ist,
um den Zustand anzuzeigen, wo der Abbruch in der C-Sprachenbeschreibung
des C+ATL-Quellprogramms aufgetreten ist, die Angabe mit der Zeilennummer 15 mit
der Abbruchstelle in dem Quellenanzeigebereich 52 gezeigt
und sind eine Variable und ein Wert, welchen die Variable in der
Angabe annehmen kann, im Symbolanzeigenbereich 53 angezeigt.
-
Der
Programmentwickler startet auf ein Finden eines logischen Fehlers
durch ein Prüfen
der auf dem Fensterbildschirm des integrativen Debuggers 35 angezeigten
Variablen hin den Editor 28, um die C+ATL-Quelldatei zu
korrigieren, wie es nötig
ist, und um die Prozedur der Schritte S120 bis S150 zu wiederholen.
-
Wie
es oben beschrieben ist, lässt
das Halbleitertestsystem gemäß dem Ausführungsbeispiel, d.h.
die Programmentwicklungsunterstützungsvorrichtung,
die Programmausführungsvorrichtung,
das Kompilierverfahren und das Diagnoseverfahren gemäß der vorliegenden
Erfindung, durch das Einbetten der ATL-Quelle, die das Programm
in spezifischer Sprache ist, in die C-Sprachenquelle, welche das Programm
in allgemeiner Sprache ist, das Handhaben von zwei unterschiedlichen
Quellen, welche herkömmlicherweise
separat gemanagt werden, als eine C+ATL-Quelldatei zu, wodurch das
Dateimanagement vereinfacht wird und die Effizienz einer Programmentwicklung
verbessert wird.
-
Bei
dem Ausführungsbeispiel
werden die Workstation und das Halbleitertestgerät als Beispiele für die Programmentwicklungsunterstützungsvorrichtung
und die Programmausführungsvorrichtung
gemäß der vorliegenden
Erfindung verwendet. Es ist jedoch klar, dass ein allgemeines Computersystem und
Vorrichtungen, wie beispielsweise eine Messvorrichtung oder eine
Steuervorrichtung, die mit dem Computersystem kommunizieren, als
die Programmentwicklungsunterstützungsvorrichtung und
die Programmausführungsvorrichtung
verwendet werden können.
-
Wie
es oben beschrieben ist, lassen die Programmentwicklungsunterstützungsvorrichtung, die
Programmausführungsvorrichtung,
das Kompilierverfahren und das Diagnoseverfahren gemäß der vorliegenden
Erfindung durch das Einbetten des Programms in spezifischer Sprache
selbst in das Programm mit allgemeiner Sprache das Handhaben von unterschiedlichen
Quellprogrammen, die herkömmlicherweise
separat gemanagt werden, als eine Datei zu, und zwar nicht nur auf
der Stufe der Quelldatei, sondern auch auf der Stufe der Objektdatei,
die durch ein Kompilieren erzeugt ist, wodurch das Dateimanagement
vereinfacht wird und die Effizienz einer Programmentwicklung verbessert
wird.
-
INDUSTRIELLE
ANWENDBARKEIT
-
Wie
es aus dem Vorangehenden gesehen werden kann, sind die Programmentwicklungsunterstützungsvorrichtung,
die Programmausführungsvorrichtung,
das Kompilierverfahren und das Diagnoseverfahren gemäß der vorliegenden
Erfindung nützlich für eine effiziente
Entwicklung des Hochleistungsprogramms (von Firmware) für elektronische
Vorrichtungen und eine Vereinfachung eines Programmmanagements,
und sind insbesondere für
die Entwicklung und das Management von Programmen für Halbleitertestgeräte geeignet.
-
Zusammenfassung
-
Auf
einer Programmentwicklungsvorrichtung (wie beispielsweise einer
Workstation) ist eine Beschreibung eines Quellprogramms in spezifischer Sprache
(wie beispielsweise ATL) in eine Vorprozessorbeschreibung eines
Quellprogramms in allgemeiner Sprache (wie beispielsweise C-Sprache)
eingebettet, um ein Quellprogramm in gemischter Sprache zu erzeugen.
Die Beschreibung des Quellprogramms in allgemeiner Sprache und die
Beschreibung des Quellprogramms in spezifischer Sprache werden aus dem
Quellprogramm in gemischter Sprache extrahiert, durch jeweilige
Compiler kompiliert, und jeweilige so erhaltene Objektcodes werden
kombiniert, um eine Objektdatei zu bilden.