DE602004007498T2 - Testemulationseinrichtung - Google Patents

Testemulationseinrichtung Download PDF

Info

Publication number
DE602004007498T2
DE602004007498T2 DE602004007498T DE602004007498T DE602004007498T2 DE 602004007498 T2 DE602004007498 T2 DE 602004007498T2 DE 602004007498 T DE602004007498 T DE 602004007498T DE 602004007498 T DE602004007498 T DE 602004007498T DE 602004007498 T2 DE602004007498 T2 DE 602004007498T2
Authority
DE
Germany
Prior art keywords
test
module
section
emulation
test signal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE602004007498T
Other languages
English (en)
Other versions
DE602004007498D1 (de
Inventor
Shinsaku Higashi
Seiji Ichiyoshi
Ankan Pramanick
Mark Elston
Leon Chen
Robert Sauer
Ramachandran Krishnaswamy
Harsanjeet Singh
Toshiaki Adachi
Yoshihumi Tahara
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advantest Corp
Original Assignee
Advantest Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/403,817 external-priority patent/US7290192B2/en
Priority claimed from US10/404,002 external-priority patent/US7460988B2/en
Priority claimed from PCT/JP2004/001649 external-priority patent/WO2004072670A1/en
Application filed by Advantest Corp filed Critical Advantest Corp
Publication of DE602004007498D1 publication Critical patent/DE602004007498D1/de
Application granted granted Critical
Publication of DE602004007498T2 publication Critical patent/DE602004007498T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31908—Tester set-up, e.g. configuring the tester to the device under test [DUT], down loading test patterns
    • G01R31/3191—Calibration
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318342—Generation of test inputs, e.g. test vectors, patterns or sequences by preliminary fault modelling, e.g. analysis, simulation
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31907—Modular tester, e.g. controlling and coordinating instruments in a bus based architecture
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31917—Stimuli generation or application of test patterns to the device under test [DUT]
    • G01R31/31922—Timing generation or clock distribution

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Tests Of Electronic Circuits (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Debugging And Monitoring (AREA)

Description

  • Hintergrund der Erfindung
  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf einen Prüfemulator, einen Prüfmodulemulator und ein Aufzeichnungsmedium-Speicherprogramm darin. Genauer gesagt bezieht sich die vorliegende Erfindung auf einen Prüfemulator, einen Prüfmodulemulator und ein Aufzeichnungsmedium-Speicherprogramm darin zum Emulieren von Prüfvorrichtungen, welche eine Mehrzahl von austauschbaren Prüfmodulen zum jeweiligen Zuführen eines Prüfsignals an DUTs enthalten, und zum Verifizieren einer Prüfumgebung, ohne reale Dinge, wie beispielsweise eine DUT oder ein Prüfmodul zu verwenden.
  • Beschreibung des zugehörigen Standes der Technik
  • Herkömmlich werden Technologien in den veröffentlichten japanischen Patentanmeldungen Nr. 10-320229 , Nr. 2000-267881 , Nr. 2001-51025 , Nr. 2001-134457 und Nr. 2002-333469 als Mittel zum Verifizieren einer Testumgebung ohne reale Dinge, wie beispielsweise eine DUT oder eine Testvorrichtung zu verwenden, offenbart.
  • Die veröffentlichte japanische Patentanmeldung Nr. 10-320229 offenbart: Jede Emulationseinheit zum Emulieren einer Funktion von jeder Hardwareeinheit einer Halbleitertestvorrichtung; einen Vorrichtungsemulator zum Emulieren einer Funktion einer DUT; Mittel zum Sammeln von Daten, welche zur Ausführung eines Prüfprogramms von jeder der Emulatoreinheiten benötigt werden, basierend auf einem Prüfprogramm und einen Emulator, welcher einen Vorrichtungsprüfemulator zum Erzeugen eines Testsignals in einem Vorrichtungsemulator basierend auf den gesammelten Daten enthält, zum Vergleichen von Ergebnissignalen von dem Vorrichtungsemulator und zum Speichern des Ergebnisses darin.
  • Die veröffentlichte japanische Patentanmeldung Nr. 2000-267881 offenbart eine Halbleitersimulationsvorrichtung zum genauen Simulieren von Spannung und Strom, welche sich abhängig von dem internen Widerstand der DUT ändern.
  • Die veröffentlichte japanische Patentanmeldung Nr. 2001-51025 offenbart eine Programmaustestvorrichtung für eine Halbleiterprüfung, welche beinhaltet: Prüfemulationsmittel zum Emulieren der Arbeitsweise der Halbleiterprüfvorrichtung; Hardwarebeschreibungssprachen-Simulationsmittel zum Simulieren der DUT basierend auf der Hardwarebeschreibungssprache und Austestmittel zum Austesten des Programms für die Halbleiterprüfung basierend auf den Simulationsergebnissen der DUT.
  • Die veröffentlichte japanische Patentanmeldung Nr. 2001-134457 offenbart eine Programmaustestvorrichtung für einen Halbleitertest zum Zusammensetzen von Datenpunkten, welche jedem Anschlussstift entsprechen, mit hoher Geschwindigkeit, wenn die Arbeitsweise der Halbleiterprüfvorrichtung emuliert wird.
  • Die veröffentlichte japanische Patentanmeldung Nr. 2002-333469 offenbart eine Programmaustestvorrichtung für einen Halbleitertest zum Verifizieren eines Programms für den Halbleitertest, welches für eine Halbleitervorrichtung, welche einen analogen Ausgangsanschluss enthält, verfasst wurde.
  • Xia J.Q. et al.: „Dynamic Test Emulation for EDA-based Mixed-Signal Test Development Automation", Proceedings of the International Test Conference (ITC), Washington, Okt. 21-25, 1995, New York, IEEE, US, 21. Oktober 1995, S. 761-770, ISBN: 0-7803-2992-9 offenbart die Analyse und die Entwicklung eines elektronischen Designautomations-(EDA von engl. electronic design automation) basierten Prüfentwicklungsautomationssystems (TDA von engl. test development automation). Zum Austesten eines Prüfdesigns und zum gleichzeitigen Emulieren eines zugeordneten Testprogramms in dem TDA-System wird eine gemischte Signalsimulation mit Testschemata durchgeführt. Ein Kommunikationskanal wird zwischen dem Prüfsystemprogrammemulator und der CAE-Simulationsumgebung für gemischte Signale etabliert. Indem die Prüfumgebung und die DUT modelliert werden, handelt der Simulationsmotor für gemischte Signale als ein virtueller Prüfer. Wenn ein Prüfprogramm abläuft und emuliert wird, richtet es die virtuellen Instrumente (Modelle) basierend auf den Ereignisaufzeichnungen, welche von dem Prüfsys temprogrammemulator erzeugt werden, ein. Es belegt die Prüfmuster und Wellenformen, misst die Vorrichtungsantworten, indem es Simulationen auf Prüfdesignschemata laufen lässt und sendet die Simulationsergebnisse zurück an den Prüfsystemprogrammemulator zur Nachverarbeitung.
  • Zusammenfassung der Erfindung
  • Es wird vorausgesetzt, dass die Emulatoren der oben beschriebenen Prüfvorrichtung für die Prüfvorrichtung verwendet werden, welche eine proprietäre Architektur aufweist, welche grundsätzlich von einem Prüfvorrichtungsanbieter entwickelt wurde. Andererseits wird für Prüfvorrichtungen in der Zukunft ein Verfahren zur Konstruktion der Prüfvorrichtung durch Kombination von Modulen, welche von verschiedenen Anbietern entwickelt wurden, welche in einer offenen Architektur realisiert wird, erwartet. Demgemäß ist es wünschenswert, einen Emulator zum geeigneten Emulieren der mittels der verschiedenen Module konstruierten Prüfvorrichtung anzubieten.
  • Es ist demgemäß eine Aufgabe der vorliegenden Erfindung, einen Prüfemulator und ein Aufzeichnungsmedium-Speicherprogramm darin zur Verfügung zu stellen, welche die vorstehenden Probleme lösen können. Die obigen und andere Aufgaben können mittels Kombinationen, welche in den unabhängigen Ansprüchen beschrieben werden, gelöst werden. Die abhängigen Ansprüche definieren weitere vorteilhafte und beispielhafte Kombinationen der vorliegenden Erfindung.
  • Demgemäß wird gemäß dem ersten Aspekt der vorliegenden Erfindung ein Prüfemulator zum Emulieren einer Prüfvorrichtung zur Verfügung gestellt, welcher eine Mehrzahl von Prüfmodulen zum jeweiligen Zuführen eines Prüfsignals zu geprüften Vorrichtungen beinhaltet. Der Prüfemulator beinhaltet: mehrere Prüfmodul-Emulationsabschnitte zum Emulieren der mehreren Prüfmodule, welche das Prüfsignal basierend auf verschiedenen Zyklen erzeugen; einen Steueremulationsabschnitt zum Emulieren einer Steuervorrichtung zum Steuern der Prüfung der zu prüfenden Vorrichtungen; einen synchronen Emulationsabschnitt zum Erzeugen von Prüfsignal-Erzeugungszeitpunkten, zu denen jeder der mehreren Prüfmodul-Emulationsabschnitte das Prüfsignal in einer Simulation entsprechend der Zykluszeit des Prüfmodul-Emulationsabschnitts erzeugen soll auf der Grundlage von Befehlen von dem Steueremulationsabschnitt; einen Zeitausrichtungsabschnitt zum Ausrichten der mehreren Prüfsignal-Erzeugungszeitpunkte, die von dem synchronen Emulationsabschnitt erzeugt wurden in zeitlicher Reihenfolge und zum Ausgeben von diesen nacheinander und einen Ablaufabschnitt zum Bewirken, dass der Prüfmodul-Emulationsabschnitt entsprechend eines der von dem Zeitausrichtungsabschnitt ausgegebenen Prüfsignal-Erzeugungszeitpunkte das Prüfsignal in Simulation in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt erzeugt.
  • Der Prüfemulator kann weiterhin aufweisen einen Simulationsabschnitt für eine zu prüfende Vorrichtung zum Simulieren der Arbeitsweise einer zu prüfenden Vorrichtung auf der Grundlage des simuliert erzeugten Prüfsignals.
  • Der synchrone Emulationsabschnitt kann weiterhin Unterbrechungssammlungs-Zeitpunkte zum Sammeln von Unterbrechungen zu der simuliert durch jeden der mehreren Prüfmodul-Emulationsabschnitte erzeugten Steuervorrichtung erzeugen während der Erzeugung des Prüf signals in der Zykluszeit entsprechend den Prüfsignal-Erzeugungszeitpunkten, die Zeitausrichtungsschaltung kann die mehreren Prüfsignal-Erzeugungszeitpunkte und die mehreren Unterbrechungssammlungs-Zeitpunkte in zeitlicher Reihenfolge ausrichten und sie nacheinander ausgeben, und der Ablaufabschnitt kann den Prüfmodul-Emulationsabschnitt entsprechend des Unterbrechungssammlungs-Zeitpunkts veranlassen, den Steueremulationsabschnitt von der in der Zykluszeit, in der die Prüfmodul-Emulationsschaltung das Prüfsignal direkt vor dem Unterbrechungssammlungs-Zeitpunkt erzeugt, simuliert erzeugten Unterbrechung zu unterrichten für den Fall, dass der Zeitausrichtungsabschnitt einen der Unterbrechungssammlungs-Zeitpunkte ausgibt.
  • Jeder der mehreren Prüfmodul-Emulationsabschnitte kann Änderungszeitpunkte des Prüfsignals in der Zykluszeit bei der Erzeugung des Prüfsignals in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt erzeugen und der Prüfemulator kann weiterhin eine DUT-Verbindungsschaltung zum Erwerben der mehreren Änderungszeitpunkte, die von den mehreren Prüfmodul-Emulationsabschnitten erzeugt wurden, und zum simulierten Ändern des Prüfsignals nacheinander in zeitlicher Reihenfolge auf der Grundlage der mehreren Änderungszeitpunkte aufweisen.
  • Der DUT-Verbindungsabschnitt liefert die mehreren Änderungszeitpunkte, die von den mehreren Prüfmodul-Emulationsabschnitten erworben wurden zu dem Zeitausrichtungsabschnitt, der Zeitausrichtungsabschnitt kann die mehreren Änderungszeitpunkte, die mehreren Prüfsignal-Erzeugungszeiten und die mehreren Unterbrechungssammlungs-Zeitpunkte in zeitlicher Reihenfolge ausrichten und sie nacheinander ausgeben, und der Ablaufabschnitt kann bewirken, dass der DUT-Verbindungsabschnitt das Prüfsignal zu dem Änderungszeitpunkt simuliert ändert für den Fall, dass der Zeitausrichtungsabschnitt einen der Änderungszeitpunkte ausgibt.
  • Jeder der mehreren Prüfmodul-Emulationsabschnitte kann die synchrone Emulationsschaltung von der Zyklusendzeit unterrichten, zu der die Zykluszeit während der Erzeugung des Prüfsignals in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt endet, und der synchrone Emulationsabschnitt kann die Prüfsignal-Erzeugungszeitpunkte erzeugen, zu denen der Prüfmodul-Emulationsabschnitt das Prüfsignal entsprechend der nächsten Zykluszeit simuliert erzeugt auf der Grundlage der von jedem der mehreren Prüfmodul-Emulationsabschnitte mitgeteilten Zyklusendzeit.
  • Der Ablaufabschnitt kann bewirken, dass die von dem Prüfmodul-Erzeugungsabschnitt entsprechend dem Prüfsignal-Erzeugungszeitpunkt simuliert erzeugte Unterbrechung des Steueremulationsabschnittes während der Erzeugung des Prüfsignals in der Zykluszeit direkt vor dem Prüfsignal-Erzeugungszeitpunkt mitgeteilt wird für den Fall, dass der Zeitausrichtungsabschnitt den Prüfsignal-Erzeugungszeitpunkt entsprechend der nächsten Zykluszeit ausgibt.
  • Jeder der mehreren Prüfmodul-Emulationsabschnitte kann durch Betätigen eines Prüfmodul-Emulationsprogramms entsprechend des Prüfmodul-Emulationsabschnitts mittels eines Computers realisiert werden, und das Prüfmodul-Emulationsprogramm kann aufweisen: Mehrere Hardware-Emulationsfunktionen, die entsprechend mehrerer Befehle vorgesehen sind, die jeweils durch das Prüfmo dul von der Steuervorrichtung empfangen werden, zum Emulieren der Operation des Prüfmoduls entsprechend dem Befehl; und eine Steuerfunktion, die verwendet wird, damit der Ablaufabschnitt bewirkt, dass der Prüfemulator das Prüfsignal in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt erzeugt.
  • Gemäß dem zweiten Aspekt der vorliegenden Erfindung wird ein Aufzeichnungsmedium zur Verfügung gestellt, welches darin ein Programm speichert, um einen Computer zu veranlassen, als ein Prüfemulator gemäß dem ersten Aspekt der vorliegenden Erfindung zu arbeiten.
  • Die Zusammenfassung der Erfindung beschreibt nicht notwendigerweise alle notwendigen Merkmale der vorliegenden Erfindung. Die vorliegende Erfindung kann auch eine Unterkombination der oben beschriebenen Merkmale darstellen.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein Blockdiagramm, welches eine Konfiguration einer Prüfvorrichtung 10 gemäß einer Ausgestaltungsform der vorliegenden Erfindung zeigt.
  • 2 ist ein Blockdiagramm, welches eine funktionelle Konfiguration eines Prüfemulators 190 gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
  • 3 ist ein Blockdiagramm, welches exemplarisch eine Hardwarekonfiguration eines Computers 20 gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
  • 4 ist ein Blockdiagramm, welches eine funktionelle Konfiguration eines Prüfmodul-Emulationsabschnitts 270 gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
  • 5 zeigt ein Beispiel einer Klassen-Hierarchiestruktur 500 gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 6 ist ein Flussdiagramm, welches einen Prüfsignal-Erzeugungsverarbeitungsfluss des Prüfemulators 190 gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
  • 7 ist eine Zeichnung, welche exemplarisch das durch den Prüfemulator 190 simulierte Prüfsignal gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
  • 8 illustriert eine Softwarearchitektur gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 9 illustriert die Verwendung von Prüfklassen gemäß einer Ausführungsform der Erfindung.
  • 10 ist ein Diagramm in vereinheitlichter Modellierungssprache (UML von engl. Unified Modelling Language), welches die Interaktion eines Prüfersystems und von Modulressourcen, welche von verschiedenen Anbietern zur Verfügung gestellt werden, gemäß einer Ausführungsform der Erfindung zeigt.
  • 11 illustriert eine Ausführungsform von Standort-Controller-Objekten zum Verwalten einer Prüfung eines Verwenders wie von einem Standard-Controller aufrechterhalten.
  • 12 illustriert eine Ausführungsform eines Objekt-Surrogates auf der Systemcontrollerseite, welches das in 11 gezeigte Standort-Controller-Objekt repräsentiert.
  • 13 illustriert eine Prüfumgebung gemäß einer Ausführungsform der Erfindung.
  • 14 illustriert ein Beispiel einer Simulations-Konfigurationsdatei gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 15 illustriert ein anderes Beispiel der Simulations-Konfigurationsdatei gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 16 illustriert ein Beispiel einer Offline-Konfigurationsdatei gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 17 illustriert ein anderes Beispiel der Offline-Konfigurationsdatei gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 18 illustriert ein Beispiel einer Klassenhierarchiestruktur 5200 gemäß einer Aus führungsform der vorliegenden Erfindung.
  • 19 illustriert ein Spezifikationsdiagramm gemäß eines Kanalobjekts gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 20 illustriert ein Spezifikationsdiagramm eines Ereignisobjekts gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 21 illustriert ein Beispiel einer Basisklasse des Digitalmodus gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 22 illustriert ein Beispiel einer Klassenbestimmung des digitalen Treibermoduls gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 23 illustriert ein Beispiel einer handleEvent-Methode des digitalen Treibermoduls gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 24 illustriert eine Klassendeklaration des digitalen Abtastmoduls gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 25 illustriert ein Beispiel eines handleEvent-Verfahrens des digitalen Abtastmoduls gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 26 illustriert ein Beispiel einer Klassendefinition eines DUT-Modells gemäß einer Ausführungsform der vorliegenden Erfin dung.
  • 27 illustriert ein Beispiel eines Laufverfahrens des DUT-Modells gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 28A und 28B illustrieren eine Positionierung einer Systembus-Zugriffsbibliothek 6014 in einer realen Umgebung 6000 und einer Emulations-Umgebung 6050.
  • Detaillierte Beschreibung der Erfindung
  • Die Erfindung wird nun basierend auf den bevorzugten Ausführungsformen beschrieben, welche nicht beabsichtigen, den Geltungsbereich der vorliegenden Erfindung zu begrenzen, sondern die Erfindung exemplarisch darstellen. Alle der Merkmale und der Kombinationen davon, welche in der Ausführungsform beschrieben werden, sind nicht notwendigerweise essentiell für die Erfindung.
  • 1 ist ein Blockdiagramm, welches eine Konfiguration einer Prüfvorrichtung 10 gemäß einer Ausführungsform der vorliegenden Erfindung zeigt. Die Prüfvorrichtung 10 erzeugt ein Prüfsignal, übermittelt es an eine DUT 100 (zu testende Vorrichtung, von engl. Device Under Test) und beurteilt die Eignung der DUT 100 basierend darauf, ob ein Ergebnissignal, welches von der DUT 100 als ein Ergebnis von der DUT 100, welche basierend auf dem Prüfsignal betrieben wird, ausgegeben wird, mit einem erwarteten Wert übereinstimmt. Die Testvorrichtung 100 gemäß der vorliegenden Ausführungsform wird durch eine offene Architektur realisiert und verschiedene Arten von Modulen werden, basierend auf der offenen Architektur, als ein Prüfmodul 170 und ähnliches verwendet, um das Prüfsignal an die DUT 100 zu übermitteln. Darüberhinaus weist die Prüfvorrichtung 10 einen Prüfemulator 190 auf, zum Emulieren einer realen Prüfung der DUT 1000, und der Prüfemulator 190 stellt eine Emulationsumgebung zur Verfügung zum geeigneten Ändern einer Konfiguration als Antwort auf die Änderung des Prüfmoduls 170 und ähnliches, welches für die reale Prüfung verwendet wird, und zum geeigneten Emulieren der realen Prüfung der DUT 1000.
  • Die Prüfvorrichtung 10 beinhaltet einen Systemcontroller 110, ein Telekommunikationsnetzwerk 120, Standortcontroller 130a-130c, einen Busschalter 140, synchrone Module 150a-150b, synchrone Verbindungsmodule 160a-160b, die Prüfmodule 170a-170b, eine Lastplatine 180 und den Prüfemulator 190. Die Prüfvorrichtung 10 koppelt an die DUTs 100a-100b.
  • Der Systemcontroller 110 empfängt und speichert ein Prüfsteuerungsprogramm, ein Prüfprogramm, Prüfdaten und ähnliches, welche für die Prüfung der DUTs 100a-100b von der Testvorrichtung 10 verwendet werden, durch ein externes Netzwerk oder ähnliches. Das Telekommunikationsnetzwerk 120 verbindet den Systemcontroller 110, die Standortcontroller 130a-130c und den Prüfemulator 190 und leitet eine Kommunikation zwischen ihnen weiter.
  • Die Standortcontroller 130a-130c sind Beispiel der Steuervorrichtung gemäß der vorliegenden Erfindung und steuern die Prüfung der DUTs 100. Hier steuert jeder der mehreren Standortcontroller 130 jeweils die Prüfung einer der DUTs 100. Beispielsweise steuert in 1 der Standortcontroller 130a die Prüfung der DUT 100a und der Standortcontroller 130b steuert die Prüfung der DUT 100b. Alternativ dazu steuern die mehreren Standortcontroller 130 jeweils die Prüfung der mehreren DUTs 100.
  • Genauer gesagt erwirbt der Standortcontroller 130 das Prüfsteuerprogramm von dem Systemcontroller 110 durch das Telekommunikationsnetzwerk 120 und führt es aus. Danach erwirbt der Standortcontroller 130 das Prüfprogramm und die Prüfdaten, welche für die Prüfung der DUT 100 verwendet werden, basierend auf dem Prüfsteuerprogramm von dem Systemcontroller 110 und speichert sie in einem Modul wie beispielsweise den synchronen Modulen 150 oder einen oder mehreren der Prüfmodule 170, welches für die Prüfung der DUT 100 verwendet wird, durch den Busschalter 140. Danach weist der Standortcontroller 130 den Start der Prüfung an das synchrone Modul 150 durch den Busschalter 140 an basierend auf dem Prüfprogramm und den Prüfdaten. Dann empfängt der Stanortcontroller 130 eine Unterbrechung, welche anzeigt, dass die Prüfung beendet ist, von beispielsweise dem synchronen Modul 150 und veranlasst jedes der Module, die nächste Prüfung basierend auf dem Prüfungsergebnis durchzuführen.
  • Der Busschalter 140 verbindet jeden der mehreren Standortcontroller 130 mit den synchronen Modulen 150 und mit einem oder mehreren der Prüfmodule 170, welche durch den Standortcontroller 130 gesteuert werden, und leitet die Kommunikation zwischen ihnen weiter. Hier richtet ein vorbestimmter Standortcontroller 130 den Busschalter 140 ein, um jeden der mehreren Standortcontroller 130 mit dem synchronen Modul 150 und einem oder mehreren der Prüfmodule 170, welche von dem Standortcontroller 130 für die Prüfung der DUT 100 verwendet werden, basierend auf der An weisung eines Benutzers der Prüfvorrichtung 10, des Prüfsteuerprogramms usw. zu verbinden. Beispielsweise wird in 1 der Standortcontroller 130 so eingerichtet, dass er mit dem synchronen Modul 150a und den mehreren Prüfmodulen 170a koppelt, wodurch die DUT 100a getestet wird. Darüberhinaus wird der Standortcontroller 130b so eingerichtet, dass er mit dem synchronen Modul 150b und den Prüfmodulen 170b koppelt, wodurch die DUT 100b getestet wird.
  • Hier wird, da die Konfiguration und die Arbeitsweise des Standortcontrollers 130b zur Prüfung der DUT 100b unter Verwendung des synchronen Moduls 150b, des synchronen Verbindungsmoduls 160b und der einen oder mehreren der Prüfmodule 170b im wesentlichen dieselben sind als die Konfiguration und die Arbeitsweise des Standortcontrollers 130a zum Prüfen der DUT 100a unter Verwendung des synchronen Moduls 150a, des synchronen Verbindungsmoduls 160a und der einen oder mehreren der Prüfmodule 170a, die Konfiguration und die Arbeitsweise des Standortcontrollers 130a zum Testen der DUT 100a hauptsächlich hiernach beschrieben soweit es keinen Unterschied gibt.
  • Das synchrone Modul 150a erzeugt einen Prüfsignal-Erzeugungszeitpunkt, zu welchem die mehreren Prüfmodule 170, welche für die Prüfung der DUT 100a verwendet werden, das Prüfsignal erzeugen sollen basierend auf der Anweisung des Standortcontrollers 130a. Darüberhinaus empfängt das synchrone Modul 150a das Prüfergebnis von einem oder von mehreren der Prüfmodule 170a durch das synchrone Verbindungsmodule 160a und veranlasst eines oder mehrere der Prüfmodule 170a die Abfolge des Prüfprogramms gemäß der Eignung des Prüfergebnisses durchzuführen.
  • Das synchrone Verbindungsmodul 160a benachrichtigt das Prüfmodul 170a von dem Prüfsignal-Erzeugungszeitpunkt, welcher durch das synchrone Modul 150a erzeugt wurde, wobei das Prüfmodul 170a entsprechend des Prüfsignal-Erzeugungszeitpunkts zu betreiben ist. Dann veranlasst das synchrone Verbindungsmodul 160a jedes der einen oder mehreren Prüfmodule 170a zu einem vorbestimmten Zeitpunkt zu arbeiten. Darüberhinaus empfängt das synchrone Verbindungsmodul 160a das Prüfergebnis von einer oder einer Mehrzahl der Prüfmodule 170a und übermittelt es an das synchrone Modul 150a.
  • Die mehreren Prüfmodule 170a koppeln jeweils mit einem Teil einer Mehrzahl von Endgeräten der DUT 100a und prüfen die DUT 100a basierend auf dem Prüfprogramm und den Prüfdaten, welche in dem Standortcontroller 130a gespeichert sind. Während der Prüfung der DUT 100a erzeugt das Prüfmodul 170a das Prüfsignal aus den Prüfdaten basierend auf der Folge, welche durch das Prüfprogramm definiert wurde, und versorgt die Endgeräte der DUT 100a, welche mit den Prüfmodulen 170a verbunden sind, mit dem Prüfsignal. Danach erwirbt das Prüfmodul 170a das Ergebnissignal, welches als ein Ergebnis der DUT 100a, welche basierend auf dem Prüfsignal betrieben wird, ausgegeben wird, und das Ergebnissignal wird mit einem erwarteten Wert verglichen. Dann übermittelt das Prüfmodul 170a das Vergleichsergebnis des Ergebnissignals und des erwarteten Wertes an das synchrone Verbindungsmodul 160a als das Prüfergebnis. Hier erzeugen die mehreren Prüfmodule 170a das Prüfsignal basierend auf unterschiedlichen Zyklen, um den Zyklus des Prüfsignals dynamisch basierend auf dem Prüfprogramm und den Prüfdaten zu ändern.
  • Darüberhinaus erzeugt das Prüfmodul 170a eine Unterbrechung für den Standortcontroller 130a, wenn die Verarbeitung des Prüfprogramms beendet wird oder wenn eine Abnormalität während der Ausführung des Prüfprogramms auftritt. Diese Unterbrechung wird an den dem Prüfmodul 170a entsprechenden Standortcontroller 130a durch den Busschalter 140 mitgeteilt und eine Unterbrechungsverarbeitung wird durch den Prozessor des Standortcontrollers 130a durchgeführt.
  • Die mehreren DUTs 100 sind auf die Lastplatine 180 montiert, über welche die mehreren Prüfmodule 170 und die zugehörigen Endgeräte der DUTs 100 verbunden sind.
  • Der Prüfemulator 190 emuliert die Prüfvorrichtung 10 basierend auf dem Prüfsteuerprogramm, dem Prüfprogramm und den Prüfdaten, welche in dem Systemcontroller 110 gespeichert sind. Dann simuliert der Prüfemulator 190 die Prüfung der DUT 100 unter Verwendung des Simulationsmodells der DUT 100. In der vorliegenden Ausführungsform simuliert der Prüfemulator 190 die Arbeitsweise des Standortcontrollers 130, des synchronen Moduls 150 und der synchronen Verbindungsmodule 160 und einer oder mehrerer der Prüfmodule 170, welche durch den Standortcontroller 130 gesteuert werden, und der DUT 100, welche durch den zugehörigen Standortcontroller 130 zu testen ist. Indem er den Prüfemulator 190 verwendet, startet der Benutzer der Prüfvorrichtung 10 die Verifikation des Prüfsteuerprogramms, des Prüfprogramms und/oder der Prüfdaten vor der Vorbereitung der DUT 100, des synchronen Moduls 150, des synchronen Verbindungsmoduls 160, des Prüfmoduls 170 usw. Darüberhinaus werden, indem die mehreren Prüfemulatoren 190 zur Verfügung gestellt werden, das Prüfsteuerprogramm, das Prüfprogramm und/oder die Prüfdaten entwickelt, ohne dass jeder der mehreren Benutzer die teure reale Prüfumgebung belegt.
  • Wie oben stehend beschrieben, wird die Prüfvorrichtung 10 durch eine offene Architektur realisiert und mehrere Arten von Modulen, welche die Spezifikation der offenen Architektur erfüllen, werden verwendet. Dann wird die Prüfvorrichtung 10 verwendet, indem die Module wie beispielsweise das synchrone Modul 150, das synchrone Verbindungsmodul 160 und das Prüfmodul 170 in beliebige Verbindungsschächte des Busschalters 140 eingeführt werden. Zu dieser Zeit ändert der Benutzer der Prüfvorrichtung 10 usw. die Topologie des Busschalters 140 beispielsweise durch den Standortcontroller 130a, bewirkt, dass die mehreren Module, welche für die Prüfung der DUT 100 verwendet werden, mit dem Standortcontroller 130 koppeln zum Steuern der Prüfung der DUT 100. Dadurch wählt der Benutzer der Prüfvorrichtung 10 ein geeignetes Modul gemäß der Anzahl der Endgeräte, der Anordnung der Endgeräte, des Typs der Endgeräte oder des Typs der Prüfung für jede der mehreren DUTs 100 aus und montiert das Modul auf die Prüfvorrichtung 10.
  • Alternativ dazu, als ein Ersatz für das oben angeführte Beispiel, werden das synchrone Verbindungsmodul 160a und das synchrone Verbindungsmodul 160b durch einen synchronen Verbindungsabschnitt, welcher für alle der Prüfmodule 170, welche für die Testvorrichtung 10 verwendet werden, zur Verfügung gestellt wird, realisiert. In diesem Fall wählt der Benutzer der Testvorrichtung 10 usw. ein geeignetes Modul gemäß der Eigenschaft der mehreren DUTs 100, indem er die Topologie des synchronen Verbindungsabschnitts und des Prüfmoduls 170 mit der Änderung der Topologie des Busschalters 140 ändert.
  • 2 ist ein Blockdiagramm, welches eine funktionelle Konfiguration des Prüfemulators 190 gemäß der Ausführungsform der vorliegenden Erfindung zeigt. Der Prüfemulator 190 beinhaltet einen Standort-Steueremulationsabschnitt 230, einen Busschalter-Emulationsabschnitt 240, einen Synchronmodul-Emulationsabschnitt 250, einen Synchronverbindungsmodul-Emulationsabschnitt 260, einen oder mehrere Prüfmodul-Emulationsabschnitte 270, einen DUT-Verbindungsabschnitt 280, einen DUT-Simulationsabschnitt 200 und einen Ablaufsteuerabschnitt 275. Hiernach wird ein Fall, bei dem der Prüfemulator 190 die Prüfung der DUT 100a durch den Standortcontroller 130a emuliert, erläutert.
  • Der Standort-Steueremulationsabschnitt 230 emuliert den in 1 illustrierten Standortcontroller 130a. Das heißt, dass der Standort-Steueremulationsabschnitt 230 das Prüfsteuerprogramm von dem Systemcontroller 110 durch das Telekommunikationsnetzwerk 120 erwirbt und es ausführt. Danach erwirbt der Standort-Steueremulationsabschnitt 230 das Prüfprogramm und die Prüfdaten, welche für die Prüfung der DUT 100a basierend auf dem Prüfsteuerprogramm verwendet werden, von dem Systemcontroller 110 und speichert sie in Modulemulationsabschnitten, wie beispielsweise dem Synchronmodulemulationsabschnitt 250 oder in einem oder mehreren der Prüfmodul-Emulationsabschnitte 270 durch den Busschalter-Emulationsabschnitt 240.
  • Hier gibt der Standort-Steueremulationsabschnitt 230 Simulationsbefehle, wie beispielsweise Auslese-Zugriffe und Einlese-Zugriffe von/an einen Speicher bereich in dem Modul, an den Busschalter-Emulationsabschnitt 240 aus, wo reale Befehle durch den Standortcontroller 130a an die synchronen Module 150a und an eines oder mehrere der Prüfmodule 170a auszugeben sind. Der Standort-Steueremulationsabschnitt 230 speichert das Prüfprogramm und die Prüfdaten in Synchronmodul-Emulationsabschnitten 250, in einem oder mehreren der Prüfmodul-Emulationsabschnitte 270 usw. durch den Busschalter-Emulationsabschnitt 240, indem der Einlese-Zugriff des Prüfprogramms und der Prüfdaten als Simulation an den Busschalter-Emulationsbschnitt ausgegeben wird.
  • Darüberhinaus empfängt der Standort-Steueremulationsabschnitt 230 die von dem Synchronmodul-Emulationsabschnitt 250 und dem Prüfmodul-Emulationsabschnitt 270 simulierte Unterbrechung durch den Busschalter-Emulationsabschnitt 240 und simuliert die Unterbrechungsverarbeitung des Standortcontrollers 130a.
  • Der Busschalter-Emulationsabschnitt 240 emuliert den Busschalter 140, welcher in 1 illustriert ist, und leitet die Kommunikation zwischen dem Standort-Steueremulationsabschnitt 230 und den Synchronmodul-Emulationsabschnitten 250 und einem oder einer Mehrzahl der Prüfmodul-Emulationsabschnitte 270 weiter.
  • Der Synchronmodul-Emulationsabschnitt 250 emuliert das in 1 illustrierte synchrone Modul 150 und erzeugt den Prüfsignal-Erzeugungszeitpunkt, zu dem jede der mehreren Prüfmodul-Emulationsschaltungen 270 das Prüfsignal in einer Simulation entsprechend der Zykluszeit der Prüfmodul-Emulationsschaltung 270 erzeugen soll auf der Grundlage von den Befehlen von dem Standortsteuerungs-Emulationsabschnitt 230. Als nächstes empfängt der synchrone Modulemulationsabschnitt 250 den Zyklusendzeitpunkt, welcher dem Endzeitpunkt der Zykluszeit entspricht, von dem Prüfmodul-Emulationsabschnitt 270, welcher das Prüfsignal erzeugt. Dann erzeugt der Synchronmodul-Emulationsabschnitt 250 gemäß dem Zyklusendzeitpunkt: Einen Prüfsignal-Erzeugungszeitpunkt, zu welchem der Prüfmodul-Emulationsabschnitt 270 das nächste Prüfsignal erzeugen soll; einen Prüfergebnis-Sammlungszeitpunkt zur Sammlung der Prüfergebnisse von dem Prüfmodul-Emulationsabschnitt 270; einen Zyklusbeendigungszeitpunkt, um den Prüfmodul-Emulationsabschnitt 270 zu veranlassen, die Verarbeitung der Zykluszeit zu beenden und einen Unterbrechungssammlungszeitpunkt zum Sammeln der Unterbrechung an den Standortsteuerungs-Emulationsabschnitt 230 von dem Prüfmodul-Emulationsabschnitt 270. Hier entspricht die Unterbrechung an den Standortsteuerungs-Emulationsabschnitt 230 von dem Prüfmodul-Emulationsabschnitt 270 der simulierten Unterbrechung, welche von jedem der mehreren Prüfmodul-Emulationsabschnitte 270 für den Standortcontroller 130a während der Erzeugung des Prüfsignals in der dem Prüfsignal-Erzeugungszeitpunkt entsprechenden Zykluszeit erzeugt wurde.
  • Der synchrone Verbindungsmodul-Emulationsabschnitt 260 emuliert das synchrone Verbindungsmodul 160, welches in 1 illustriert ist, und benachrichtigt den Ablaufsteuerabschnitt 275 von dem Prüfsignal-Erzeugungszeitpunkt, welcher von dem synchronen Modulemulationsabschnitt 250 simuliert erzeugt wurde, von dem Prüfergebnis-Sammlungszeitpunkt und dem Zyklusbeendigungszeitpunkt und dem Unterbrechungssammlungszeitpunkt, welche von dem synchronen Modulemulationsabschnitt 250 für Emulation erzeugt werden. Darüberhinaus empfängt der synchrone Verbindungsmodul- Emulationsabschnitt 260 das Prüfergebnis von einer oder mehreren der Prüfmodul-Emulationsabschnitte 270 und überträgt es an den synchronen Modulemulationsabschnitt 250.
  • Der Prüfmodul-Emulationsabschnitt 270 empfängt einen Befehl eines Zyklusstarts von dem synchronen Modulemulationsabschnitt 250, welcher Befehle von einer Prüfsignalerzeugung empfing, und erzeugt das simulierte Prüfsignal in der Zykluszeit, welche dem Prüfsignal-Erzeugungszeitpunkt entspricht, basierend auf dem Prüfprogramm und den Prüfdaten, welche in dem Standortsteuerungs-Emulationsabschnitt 230 gespeichert sind. Genauer gesagt erzeugt der Prüfmodul-Emulationsabschnitt 270 einen Änderungszeitpunkt des simulierten Prüfsignals in der Zykluszeit während der Erzeugung des Prüfsignals in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt. Alternativ dazu erzeugt der Prüfmodul-Emulationsabschnitt 270 Änderungszeitpunkte entsprechend einer Zykluszeit als ein Änderungszeitpunkt des Prüfsignals, wobei die Anzahl der Änderungszeitpunkte durch Spezifikation des Prüfmoduls 170 entsprechend des Prüfmodul-Emulationsabschnitts 270 definiert ist. Darüberhinaus erwirbt der Prüfmodul-Emulationsabschnitt 270 das Ausgangssignal, welches als ein Ergebnis des DUT-Simulationsabschnitts 200, welcher in Simulation basierend auf dem Prüfsignal betrieben wird, ausgegeben wurde und vergleicht das Ergebnis mit dem erwarteten Wert, welcher basierend auf dem Prüfprogramm und den Prüfdaten definiert ist. Dann überträgt der Prüfmodul-Emulationsabschnitt 270 das Vergleichsergebnis des Ergebnissignals und des erwarteten Wertes an den Synchronmodul-Emulationsabschnitt 250 durch den synchronen Verbindungsmodul-Emulationsabschnitt 260 als das Prüfergebnis.
  • Darüberhinaus benachrichtigt, in Erwiderung auf einen Befehl der Unterbrechung von dem Ablaufabschnitt 277, der Prüfmodul-Emulationsabschnitt 270 den Standortsteuerungs-Emulationsabschnitt 230 durch den Busschalter-Emulationsabschnitt 240 von der Unterbrechung, welche simuliert in der Zykluszeit, während welcher das letzte Prüfsignal vor dem Empfang des Befehls der Unterbrechung erzeugt wird, erzeugt wird.
  • Der DUT-Verbindungsabschnitt 280 erwirbt die mehreren Änderungszeitpunkte, welche von den mehreren Prüfmodul-Emulationsabschnitten 270 erzeugt werden, und ändert das Prüfsignal in Simulation in zeitlicher Reihenfolge basierend auf den mehreren Änderungszeitpunkten.
  • Der DUT-Simulationsabschnitt 200 simuliert die Arbeitsweise der beschriebenen DUT 100 mittels Hardware-Beschreibungssprachen, wie beispielsweise Verilog-HDL oder VHDL, basierend auf dem von dem DUT-Verbindungsabschnitt 280 erworbenen Prüfsignal. Dann erzeugt der DUT-Simulationsabschnitt 200 ein Ergebnissignal durch die Simulation, welches als ein Ergebnis der basierend auf dem Prüfsignal betriebenen DUT 100 ausgegeben wird, und übermittelt es an den Prüfmodul-Emulationsabschnitt 270 durch den DUT-Verbindungsabschnitt 280.
  • Der Ablaufsteuerabschnitt 275 steuert den Ablauf, welcher jeden der Modulemulationsabschnitte betreibt, basierend auf verschiedenen Arten von Zeitpunkten, welche durch die mehreren Modulemulationsabschnitte in der simulierten Prüfung der DUT 100 durch den synchronen Modulemulationsabschnitt 250, den synchronen Verbindungsmodulemulationsabschnitt 260, die mehreren Prüfmodul-Emulationsabschnitte 270 und den DUT-Verbindungsabschnitt 280 erzeugt werden. Der Ablaufsteuerabschnitt 275 beinhaltet einen Zeitausrichtungsabschnitt 276 und einen Ablaufabschnitt 277.
  • Der Zeitausrichtungsabschnitt 276 richtet die mehreren Prüfsignal-Erzeugungszeitpunkte, die mehreren Unterbrechungssammlungszeitpunkte, die mehreren Zyklusbeendigungszeitpunkte und die mehreren Prüfergebnis-Sammlungszeitpunkte, welche durch den synchronen Modulemulationsabschnitt 250 erzeugt werden, und die mehreren Änderungszeitpunkte, welche mittels eines oder mehrerer der Prüfmodul-Emulationsabschnitte 270 erzeugt werden und durch den DUT-Verbindungsabschnitt 280 bereitgestellt werden, in zeitlicher Reihenfolge aus. Dann gibt der Zeitausrichtungsabschnitt 276 diese ausgerichteten Zeitpunkte nacheinander an den Ablaufabschnitt 277. Der Ablaufabschnitt 277 benachrichtigt den Modulemulationsabschnitt und den DUT-Verbindungsabschnitt 280 entsprechend der Zeitpunkte von jedem der von dem Zeitausrichtungsabschnitt 276 nacheinander ausgegebenen Zeitpunkten. Dann veranlasst der Ablaufabschnitt 277 den Modulemulationsabschnitt oder den DUT-Verbindungsabschnitt 280 den Arbeitsablauf entsprechend der Zeitpunkte durchzuführen. Der Arbeitsablauf des Ablaufabschnitts 277 gemäß der Art des von dem Zeitausrichtungsabschnitt 276 ausgegebenen Zeitpunkts wird hiernach erläutert.
    • (1) Im Fall, dass der Zeitausrichtungsabschnitt 276 den Prüfsignal-Erzeugungszeitpunkt ausgibt: Der Ablaufabschnitt 277 benachrichtigt den synchronen Modulemulationsabschnitt 250 von dem Prüfsignal-Erzeugungszeitpunkt und weist die Erzeugung des Prüfsignals durch den Prüfmodul-Emulationsabschnitt 270 entsprechend des Prüfsignal-Erzeugungszeitpunkts durch den synchronen Modulemulationsabschnitt 250 an. Hierdurch veranlasst der Ablaufabschnitt 277 den Prüfmodul-Emulationsabschnitt 270 entsprechend des Prüfsignal-Erzeugungszeitpunkts das Prüfsignal in der Zykluszeit entsprechend des Prüfsignal-Erzeugungszeitpunkts durch den synchronen Modulemulationsabschnitt 250 in Simulation zu erzeugen.
    • (2) Im Fall, dass der Zeitausrichtungsabschnitt 276 den Unterbrechungssammlungszeitpunkt ausgibt: Der Ablaufabschnitt 277 weist die Erzeugung der Unterbrechung an den Prüfmodul-Emulationsabschnitt 270, welcher entsprechend des Unterbrechungssammlungszeitpunkts bestimmt ist, an. Hierdurch veranlasst der Ablaufabschnitt 277 den Prüfmodul-Emulationsabschnitt 270 den Standortsteuerungs-Emulationsabschnitt 230 durch den Busschalter-Emulationsabschnitt 240 zu benachrichtigen von der Unterbrechung, welche in Simulation in der Zykluszeit, während derer das Prüfsignal direkt vor den Unterbrechungssammlungszeitpunkt erzeugt wird, erzeugt wird.
    • (3) Im Fall, dass der Zeitausrichtungsabschnitt 276 den Zyklusbeendigungszeitpunkt ausgibt: Der Ablaufabschnitt 277 benachrichtigt den Prüfmodul-Emulationsabschnitt 270 entsprechend des Zyklusbeendigungszeitpunkts, dass der Zyklusendzeitpunkt gekommen ist.
    • (4) Im Fall, dass der Zeitausrichtungsabschnitt 276 den Prüfergebnis-Sammlungszeitpunkt ausgibt: Der Ablaufabschnitt 277 benachrichtigt den Prüfmodul-Emulationsabschnitt 270 entsprechend dem Prüfergebnis-Sammlungszeitpunkt, dass der Prüfergebnis-Sammlungszeitpunkt gekommen ist. In Erwiderung darauf benachrichtigt der Prüfmodul-Emulationsabschnitt 270 den synchronen Modulemulationsabschnitt 250 durch den synchronen Verbindungsmodul-Emulationsabschnitt 260 von dem Vergleichsergebnis des Ergebnissignals und des erwarteten Wertes in der Zykluszeit.
    • (5) Im Fall, dass der Zeitausrichtungsabschnitt 276 den Änderungszeitpunkt ausgibt: Der DUT-Verbindungsabschnitt 280 stellt den Zeitausrichtungsabschnitt 276 die mehreren Änderungszeitpunkte, welche von den mehreren Prüfmodul-Emulationsabschnitten 270 erworben wurden, zur Verfügung. In Erwiderung darauf richtet der Zeitausrichtungsabschnitt 276 die mehreren Änderungszeitpunkte und andere verschiedene Zeitpunkte insgesamt in zeitlicher Reihenfolge aus.
  • Wenn der Zeitausrichtungsabschnitt 276 den Änderungszeitpunkt ausgibt, benachrichtigt der Ablaufabschnitt 277 den DUT-Verbindungsabschnitt 280, dass der Änderungszeitpunkt gekommen ist, um das Prüfsignal in Simulation zu dem Änderungszeitpunkt zu ändern. In Erwiderung darauf ändert der DUT-Verbindungsabschnitt 280 das Prüfsignal in Simulation zu dem Änderungszeitpunkt.
  • Hier benachrichtigt der Prüfmodul-Emulationsabschnitt 270 den Ablaufsteuerungsabschnitt 275 über den Ergebnissignal-Erwerbungszeitpunkt, welcher ein Zeitpunkt des Erwerbs des Ergebnissignals ist. Dann richtet der Zeitausrichtungsabschnitt 276 den Ergebnissignal-Erwerbszeitpunkt und die anderen verschiedenen Zeitpunkte in zeitlicher Reihenfolge aus. In diesem Fall veranlasst, wenn der Zeitausrichtungsabschnitt 276 den Ergebnissignal-Erwerbungszeitpunkt ausgibt, der Ablaufabschnitt 277 den DUT-Verbindungsabschnitt 280 das Ergebnissignal dem Prüfmodul-Emulationsabschnitt 270 zur Verfügung zu stellen, was bedeutet, das Ergebnissignal zu dem Ergebnissignal-Erwerbszeitpunkt zu erwerben.
  • Darüberhinaus erwirbt der DUT-Verbindungsabschnitt 280 die mehreren Änderungszeitpunkte, welche durch die mehreren Prüfmodul-Emulationsabschnitte 270 erzeugt werden, und stellt sie dem DUT-Simulationsabschnitt 200 zur Verfügung, ohne sie in zeitlicher Reihenfolge auszurichten. In diesem Fall richtet der DUT-Simulationsabschnitt 200 die mehreren zur Verfügung gestellten Änderungszeitpunkte in zeitlicher Reihenfolge aus und führt die Simulation der DUT 100 basierend auf einer Mehrzahl von ausgerichteten Änderungszeitpunkten durch.
  • Gemäß dem oben beschriebenen Prüfemulator 190 können die Modulemulationsabschnitte einfach als andere Modulemulationsabschnitte ersetzt werden, indem der synchrone Modulemulationsabschnitt 250, der synchrone Verbindungsmodul-Emulationsabschnitt 260 und einer oder mehrere Prüfmodul-Emulationsabschnitte 270, welche jeweils dem synchronen Modul 150, den synchronen Verbindungsmodulen 160 und einem oder mehreren der Prüfmodule 170 des realen Systems der Prüfvorrichtung 10 entsprechen, zur Verfügung gestellt werden. Hierdurch wird im Fall, dass das eine Modul als ein anderes Modul in dem realen System der Prüfvorrichtung 10 ersetzt wird, ein Modulemulationsabschnitt entsprechend dem Modul durch einen Modulemulationsabschnitt entsprechend des anderen Moduls ersetzt. Dann wird im wesentlichen dieselbe Prüfumgebung wie das reale System der Prüfvorrichtung 10 auf dem Prüfemulator 190 zur Verfügung gestellt.
  • Alternativ dazu, als ein Ersatz für das oben genannte Beispiel, werden der Standortsteuerungs-Emulationsabschnitt 230, der Busschalter-Emulationsabschnitt 240, der synchrone Modulemulationsabschnitt 250, der Prüfmodul-Emulationsabschnitt 270, der Ablaufsteuerabschnitt 275, der DUT-Verbindungsabschnitt 280 und der DUT-Simulationsabschnitt 200 über ein verteiltes System, welches eine Mehrzahl von Computern beinhaltet, realisiert.
  • 3 ist ein Blockdiagramm, welches exemplarisch eine Hardwarekonfiguration des Prüfemulators 190 gemäß dem gegenwärtigen Ausführungsbeispiel der Erfindung zeigt. Der Prüfemulator 190 gemäß der gegenwärtigen Ausführungsform wird über einen Computer 20 realisiert, welcher eine CPU 300, einen ROM-Speicher 310, einen RAM-Speicher 320, ein Kommunikationsinterface 330, ein Festplattenlaufwerk 340, ein Laufwerk für flexible Platten 350 und ein CD-ROM-Laufwerk 360 beinhaltet.
  • Die CPU 300 arbeitet basierend auf dem in dem ROM 310 und dem RAM 320 abgespeicherten Programm und steuert jeden Teil. Der ROM-Speicher 310 speichert ein Bootprogramm, welches die CPU 300 während des Starts eines Computers 20 ausführt, wobei das Programm von der Hardware des Computers 20 usw. abhängt. Der RAM-Speicher 320 speichert ein Programm, welches die CPU 300 ausführt und Daten, welche die CPU 300 verwendet. Das Kommunikationsinterface 330 kommuniziert mit anderen Ausrüstungen durch ein Telekommunikationsnetzwerk. Das Festplattenlaufwerk 340 speichert das Programm und die Daten, welche der Computer 20 verwendet, und stellt sie der CPU 300 durch den RAM-Speicher 320 zur Verfügung. Das Laufwerk für flexible Platten 350 liest ein Programm oder Daten auf einer flexiblen Platte 390 und stellt sie dem RAM-Speicher 320 zur Verfügung. Das CD-ROM-Laufwerk 360 liest ein Programm oder Daten von einer CD-ROM 395 und stellt sie dem RAM 330 zur Verfügung.
  • Das der CPU 300 durch den RAM-Speicher 320 zur Verfügung gestellte Programm wird auf einem Aufzeichnungsmedium, wie beispielsweise einer flexiblen Platte 390, dem CD-ROM 395 oder einer IC-Karte, welche von einem Benutzer zur Verfügung gestellt wird, gespeichert. Das Programm wird von dem Aufzeichnungsmedium gelesen, durch den RAM-Speicher 320 in dem Computer installiert und durch den Computer 20 ausgeführt.
  • Die Programmmodule, welche in dem Computer 20 installiert werden und durch den Computer ausgeführt werden und den Computer 20 veranlassen, als der Prüfemulator 190 zu arbeiten, beinhalten ein DUT-Simulationsmodul, ein Standortsteuerungs-Emulationsmodul, ein Busschalter-Emulationsmodul, ein Synchronmodul-Emulationsmodul, ein Emulationsmodul für ein synchrones Verbindungsmodul, ein Prüfmodul-Emulationsmodul, ein Ablaufsteuerungsmodul, ein Zeitpunktausrichtungsmodul, ein Ablaufmodul und ein DUT-Verbindungsmodul. Die Programme oder die Module veranlassen den Computer 20 als der DUT-Simulationsabschnitt 200, der Standortsteuerungs-Emulationsabschnitt 230, der Busschalter-Emulationsabschnitt 240, der synchrone Modulemulationsabschnitt 250, der synchrone Verbindungsmodul-Emulationsabschnitt 260, der Prüfmodul-Emulationsabschnitt 270, der Ablaufsteuerungsabschnitt 275, der Zeitpunktausrichtungsabschnitt 276, der Ablaufabschnitt 277 und der DUT-Verbindungsabschnitt 280 jeweils zu arbeiten.
  • Alternativ dazu werden die Programme oder die Module, wie sie oben beschrieben sind, auf einem externen Aufzeichnungsmedium gespeichert. Es ist möglich, ein optisches Aufzeichnungsmedium, wie beispielsweise eine DVD oder eine PD, ein magnetooptisches Aufzeichnungsmedium, wie beispielsweise eine Minidisk, ein Kassettenmedium, ein magnetisches Aufzeichnungsmedium oder einen Halbleiterspeicher, wie beispielsweise eine IC-Karte als ein Aufzeichnungsmedium anstelle der flexiblen Platte 390 und des CD-ROMS 395 zu verwenden. Darüberhinaus wird ein Speichergerät, wie beispielsweise eine Festplatte oder ein RAM-Speicher in einem Serversystem auf einem geeigneten Telekommunikationsnetzwerk oder dem Internet als ein Aufzeichnungsmedium verwendet und das Programm kann dem Computer 20 über das Telekommunikationsnetzwerk zur Verfügung gestellt werden.
  • 4 ist ein Blockdiagramm, welches eine funktionelle Konfiguration des Prüfmodul-Emulationsabschnitts 270 gemäß der Ausführungsform der vorliegenden Erfindung zeigt. In 4 ist der Prüfmodul-Emulationsabschnitt 270 dadurch realisiert, dass das Prüfmodul-Emulationsprogramm oder das Prüfmodul-Emulationsmodul entsprechend des Prüfmodul-Emulationsabschnitts 270 durch den Computer 20 betrieben wird.
  • Der Prüfmodul-Emulationsabschnitt 270 beinhaltet mehrere Hardware-Emulationsfunktionen, welche entsprechend jedes der mehreren Befehle, welche von dem Prüfmodul 170 durch den Busschalter 140 von dem Standortcontroller 130 empfangen werden, zur Verfügung gestellt werden und eine Steuerungsfunktion, welche aufgerufen wird, um den Prüfmodul-Emulationsabschnitt 270 über verschiedene Arten von Zeitpunkten zu benachrichtigen. Der Prüfmodul-Emulationsabschnitt 270 arbeitet in Erwiderung auf den Aufruf von diesen Funktionen von dem Busschalter-Emulationsabschnitt 240 und dem Ablaufsteuerungsabschnitt 275. Hier wird die Steuerungsfunktion verwendet, um den Ablaufsteuerungsabschnitt 275 zu veranlassen, die Erzeugung des Prüfsignals in Simulation in der Zykluszeit entsprechend des Prüfsignal-Erzeugungszeitpunkts anzuordnen und anzuordnen, den Standortsteuerungs-Emulationsabschnitt 230 von der Unterbrechung, welche in Simulation in der Zykluszeit erzeugt wird, zu benachrichtigen, wenn der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal direkt vor dem Unterbrechungssammlungszeitpunkt erzeugt.
  • Der Prüfmodul-Emulationsabschnitt 270 beinhaltet einen Prüfmodul-IF-Emulationsabschnitt 400 (Prüfmodulinterface-Emulationsabschnitt), einen Mustererzeugungs-Emulationsabschnitt 430, einen Wellenformgeber-Emulationsabschnitt 440, einen Anschlusssteuerungs-Emulationsabschnitt 450 und einen Parametermessungs-Emulationsabschnitt 460.
  • Der Prüfmodul-IF-Emulationsabschnitt 400 wird in Betrieb gesetzt, wenn die Hardwareemulationsfunktion von dem Busschalter-Emulationsabschnitt 240 aufgerufen wird und wenn die Steuerungsfunktion von dem Ablaufsteuerabschnitt 275 aufgerufen wird. Der Prüfmodul-IF-Emulationsabschnitt 400 steuert die Arbeitsweise des Prüfmodul-Emulationsabschnitts 270 entsprechend diesen Funktionsaufrufen. Der Prüfmodul-IF-Emulationsabschnitt 400 beinhaltet eine Maschinenwort-Datenbank 420 und einen Steuerungsfunktions-Verarbeitungsabschnitt 410.
  • Die Maschinenwort-Datenbank 420 emuliert einen Speicherbereich, welcher in dem Speicherbereich, welcher in dem Testmodul 170 zur Verfügung gestellt wird, ge speichert ist. Wenn die Maschinenwort-Datenbank 420 einen Befehl von dem Standortsteuerungs-Emulationsabschnitt 230 in Simulation durch den Busschalter-Emulationsabschnitt 240 durch den Aufruf der Hardware-Emulationsfunktion empfängt, greift sie auf den Speicherbereich in der Maschinenwort-Datenbank 420 entsprechend des Befehls zu.
  • Genauer gesagt speichert der Prüfmodul-IF-Emulationsabschnitt 400 gemäß der vorliegenden Ausführungsform mehrere Hardware-Emulationsfunktionen zum Emulieren der Arbeitsweise des Prüfmodul-Emulationsabschnitts 270 jeweils entsprechend einer Mehrzahl von Befehlen, wie beispielsweise Auslese-Zugriff und Einschreib-Zugriff. Wenn der Auslese-Zugriff von dem Standortsteuerungs-Emulationsabschnitt 230 durch den Busschalter-Emulationsabschnitt 240 empfangen wird, gibt der Prüfmodul-IF-Emulationsabschnitt 400 die Daten in der Maschinenwort-Datenbank 420 entsprechend des Speicherbereichs für den Auslese-Zugriff an den Standortsteuerungs-Emulationsabschnitt 230 durch den Busschalter-Emulationsabschnitt 240 zurück. Darüberhinaus speichert, wenn die Maschinenwort-Datenbank 420 den Einschreib-Zugriff empfängt, sie die in den Speicherbereich der Maschinenwort-Datenbank 420 zu schreibenden Daten entsprechend des Speicherbereichs für den Einschreib-Zugriff. Beispielsweise speichert, wenn die Maschinenwort-Datenbank 420 den Einschreib-Zugriff des Testprogramms oder die Prüfdaten von dem Standortsteuer-Emulationsabschnitt 230 durch den Busschalter-Emulationsabschnitt 240 empfängt, sie das Prüfprogramm oder die Testdaten in dem Speicherbereich der Maschinenwort-Datenbank 420 entsprechend dem Einschreib-Zugriff.
  • Wenn der Steuerungsfunktions-Verarbeitungsabschnitt 410 den Steuerungsfunktionsaufruf von dem Ablaufsteuerungsabschnitt 275 empfängt, veranlasst der Steuerungsfunktions-Verarbeitungsabschnitt 410 den Mustererzeugungs-Emulationsabschnitt 430, den Wellenformgeber-Emulationsabschnitt 440, den Anschlusssteuerungs-Emulationsabschnitt 450 und den Parametermessungs-Emulationsabschnitt 460 die Arbeitsweise des Prüfmoduls 170 gemäß der Steuerungsfunktion in Erwiderung auf den Befehl der Steuerungsfunktion zu emulieren. Genauer gesagt liest der Steuerungsfunktions-Verarbeitungsabschnitt 410, wenn der Ablaufsteuerungsabschnitt 275 die Erzeugung des Testsignals unter Verwendung der Steuerfunktion in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt anweist, einen Teil des Programms und einen Teil der Daten aus dem Prüfprogramm und den Prüfdaten, welche in der Maschinenwort-Datenbank 420 gespeichert sind, wobei der Teil des Programms und der Daten von dem Prüfmodul-Emulationsabschnitt 270 während der Zykluszeit zu verarbeiten sind. Dann veranlasst der Steuerfunktions-Verarbeitungsabschnitt 410 den Mustererzeugungs-Emulationsabschnitt 430, den Wellenformgeberemulationsabschnitt 440, den Anschlusssteuerungs-Emulationsabschnitt 450 und den Parametermessungs-Emulationsabschnitt 460 die Verarbeitung entsprechend des Teils des Programms und des Teils der Daten durchzuführen.
  • Der Mustererzeuger-Emulationsabschnitt 430 emuliert den Mustererzeuger des Prüfmoduls 170. Das heißt, der Mustererzeuger-Emulationsabschnitt 430 empfängt das Prüfprogramm und die Prüfdaten, welche in der Maschinenwort-Datenbank 420 gespeichert sind, von dem Steuerungsfunktions-Verarbeitungsabschnitt 410 durch beispielsweise den Funktionsaufruf. Dann wird der Befehl, welcher anzeigt, dass das Prüfsignal für eine bestimmte Zykluszeit zu erzeugen ist, von dem Ablaufsteuerungsabschnitt 275 mittels des Funktionsaufrufs durch den Steuerungsfunktions-Verarbeitungsabschnitt 410 empfangen, und das Prüfsignal, welches in der Zykluszeit erzeugt werden soll, wird in Simulation erzeugt.
  • Darüberhinaus erwirbt der Mustererzeuger-Emulationsabschnitt 430 das Ergebnissignal durch den DUT-Verbindungsabschnitt 280 und den Wellenformformgeber-Emulationsabschnitt 440, welches in Simulation als ein Ergebnis des DUT-Simulationsabschnitts 200, welcher basierend auf dem Prüfsignal betrieben wird, in Simulation ausgegeben wird, und das Ergebnissignal wird mit dem erwarteten Wert verglichen.
  • Der Wellenformformgeber-Emulationsabschnitt 440 emuliert den Wellenformformgeber des Prüfmoduls 170. Das heißt, der Wellenformformgeber-Emulationsabschnitt 440 formt die Wellenform des Prüfsignals in Simulation in Erwiderung auf das Prüfsignal von dem Mustererzeuger-Emulationsabschnitt 430. Dann wird die Wellenform an den DUT-Verbindungsabschnitt 280 ausgegeben.
  • Der Anschlusssteuerungs-Emulationsabschnitt 450 emuliert den Anschlusssteuerungsabschnitt des Prüfmoduls 170. Das heißt, der Anschlusssteuerungs-Emulationsabschnitt 450 setzt Parameter, wie beispielsweise die Betriebsspannung, für jedes Endgerät, von dem das Prüfsignal in Simulation durch den Wellenformformgeber-Emulationsabschnitt 440 und/oder den Parametermessungs-Emulationsabschnitt 460 in Simulation ausgegeben wird.
  • Der Parametermessungs-Emulationsabschnitt 460 emuliert den Parametermessungsabschnitt des Prüfmoduls 170. Das heißt, dass beispielsweise der Parametermessungs-Emulationsabschnitt 460 einen Befehl über einen Gleichstromtest (DC-Parametertest von engl. DC = Gleichstrom) von dem Ablaufsteuerungsabschnitt 275 durch den Steuerungsfunktions-Verarbeitungsabschnitt 410 mittels des Funktionsaufrufs empfängt und das Prüfsignal, welches in der Zykluszeit der Gleichstromprüfung zu erzeugen ist, in Simulation erzeugt. Darüberhinaus erwirbt der Parametermessungs-Emulationsabschnitt 460 das Ergebnissignal, welches als ein Ergebnis des DUT-Simulationsabschnitts 200, welcher basierend auf dem Prüfsignal der Gleichstromprüfung betrieben wurde, in Simulation ausgegeben wird.
  • Darüberhinaus benachrichtigt der Steuerungsfunktions-Verarbeitungsabschnitt 410 in dem Fall, dass der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal in der Zykluszeit entsprechend des Prüfsignal-Erzeugungszeitpunkts erzeugt, den synchronen Modulemulationsabschnitt 250 von dem Zyklusendzeitpunkt, bei welchem der Zyklus, welcher dem Prüfsignal-Erzeugungszeitpunkt entspricht, endet.
  • Wie oben beschrieben, benachrichtigt der Steuerungsfunktions-Verarbeitungsabschnitt 410 den synchronen Modulemulationsabschnitt 250 durch den Ablaufsteuerungsabschnitt 275 von dem Zyklusendzeitpunkt, bei welchem der Zyklus endet, in dem Erzeugen des Prüfsignals in der Zykluszeit entsprechend des Prüfsignal-Erzeugungszeitpunkts. Dadurch veranlasst der Steuerungsfunktions-Verarbeitungsabschnitt 410 den synchronen Modulemulationsabschnitt 250 weiter den Prüfsignal-Erzeugungszeitpunkt, zu welchem der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal in Simulation für die nächste Zeit basierend auf dem Zyklusendzeitpunkt erzeugen soll, zu erzeugen.
  • Darüberhinaus übermittelt, wenn der Steuerungsfunktions-Verarbeitungsabschnitt 410 den Befehl der Unterbrechungserzeugung von dem Ablaufsteuerungsabschnitt 275 empfängt, der Steuerungsfunktions-Verarbeitungsabschnitt 410 den Befehl der Unterbrechungserzeugung an den Mustererzeugungs-Emulationsabschnitt 430, den Wellenformformgeber-Emulationsabschnitt 440 und den Anschlusssteuerungs-Emulationsabschnitt 450 beispielsweise über den Funktionsaufruf. Der Mustererzeugungs-Emulationsabschnitt 430, der Wellenformformgeber-Emulationsabschnitt 440 und der Anschlusssteuerungs-Emulationsabschnitt 450, welche den Befehl der Unterbrechungserzeugung empfangen, benachrichtigen den Steuerungsfunktions-Verarbeitungsabschnitt 410 von der in Simulation erzeugten Unterbrechung in der Zykluszeit direkt vor dem Unterbrechungssammlungszeitpunkt unter den Zykluszeiten, während welcher der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal erzeugt. Wenn die Unterbrechung mitgeteilt wird, benachrichtigt der Steuerungsfunktions-Verarbeitungsabschnitt 410 den Standortsteuerungs-Emulationsabschnitt 230 von der Unterbrechung durch den Bussteuerungs-Emulationsabschnitt 240, indem die Hardwareemulationsfunktion für die Benachrichtigung der Unterbrechung, welche in dem Busschalter-Emulationsabschnitt 240 enthalten ist, beispielsweise aufgerufen wird.
  • 5 zeigt ein Beispiel einer Klassenhierarchiestruktur 500 gemäß dem Ausführungsbeispiel der vorliegenden Erfindung. In dem gegenwärtigen Ausführungsbeispiel wird ein Modulemulationsprogramm, welches die Modulemulationsabschnitte, wie beispielsweise den synchronen Modulemulationsabschnitt 250, den synchronen Verbindungsmodul-Emulationsabschnitt 260 und den Prüfmodul-Emulationsabschnitt 270 realisiert, unter Verwendung von Klassenfunktionen erzeugt, welche Rahmenwerke des Modulemulationsprogramms sind, welches definiert ist, um die offene Architektur der Prüfvorrichtung 10 in Simulation zu realisieren.
  • Die Simulationskomponentenklasse 510 ist eine Klasse, welche Regeln zum Aufruf einer Mehrzahl von Parametern, Rückgabewerten usw. von Methodenfunktionen, welche in das Modulemulationsprogramm einzuarbeiten sind, mit einer virtuellen Methodenfunktion definiert. Die Simulationskomponentenklasse 510 beinhaltet eine Mehrzahl von virtuellen Hardwareemulationsfunktionen 512 und eine Mehrzahl von virtuellen Steuerungsfunktionen 514.
  • Hier ist read() eine Methodenfunktion zum Emulieren der Arbeitsweise des Moduls entsprechend des Auslese-Zugriffs, welche aufgerufen wird, wenn der Standortsteuerungs-Emulationsabschnitt 230 den Auslesezugriffsbefehl in Simulation ausgibt. write() ist eine Methodenfunktion zum Emulieren der Arbeitsweise des Moduls entsprechend des Einschreibe-Zugriffs, welche aufgerufen wird, wenn der Standortsteuerungs-Emulationsabschnitt 230 den Einschreibe-Zugriffbefehl in Simulation ausgibt. setBaseAddress() ist eine Methodenfunktion, welche aufgerufen wird, wenn der Standortsteuerungs-Emulationsabschnitt 230 in Simulation den Basisadressen-Setzbefehl ausgibt, welcher von dem Standortcontroller 130 ausgegeben wird, wenn die Basisadresse des Speicherbereichs des Prüfmoduls 170 eingerichtet wird.
  • registerEvent() ist eine Methodenfunktion, welche aufgerufen wird, wenn der synchrone Verbindungsmodul-Emulationsabschnitt 260, der Prüfmodul-Emulations abschnitt 270 und der DUT-Verbindungsabschnitt 280, welche die Nachrichten von dem synchronen Modulemulationsabschnitt 250 erhalten, den Zeitausrichtungsabschnitt 276 über den Unterbrechungssammlungszeitpunkt, den Änderungszeitpunkt, den Ergebnissignal-Erwerbszeitpunkt usw. benachrichtigen und die Zeitpunkte an den Zeitausrichtungsabschnitt 276 registrieren. handleEvent() ist eine Methodenfunktion, welche durch den Ablaufsteuerabschnitt 275 aufgerufen wird, um den synchronen Modulemulationsabschnitt 250, den synchronen Verbindungsmodul-Emulationsabschnitt 260, den Prüfmodul-Emulationsabschnitt 270 und den DUT-Verbindungsabschnitt 280 zu veranlassen, die Verarbeitung in Erwiderung auf die Zeitpunkte durchzuführen, wenn der Prüfsignal-Erzeugungszeitpunkt, der Unterbrechungssammlungszeitpunkt, der Änderungszeitpunkt, der Ergebnissignal-Erwerbszeitpunkt usw. gekommen sind. raiseEvent() ist eine Methodenfunktion, welche aufgerufen wird, wenn der synchrone Modulemulationsabschnitt 250, der synchrone Verbindungsmodul-Emulationsabschnitt 260, der Prüfmodul-Emulationsabschnitt 270 und der DUT-Verbindungsabschnitt 280 den Ablaufsteuerungsabschnitt 275 über ein Ereignis benachrichtigen, welches asynchron ohne Rücksicht auf die Zeitpunkte zu verarbeiten ist.
  • Eine Klasse eines Moduls von einem Unternehmen A 520 und eine Klasse eines Moduls von einem Unternehmen B 530 sind Klassen, welche von der Simulationskomponentenklasse 510 abgeleitet sind, d.h. Modulemulationsprogramme, welche beispielsweise durch Hersteller der Module zur Verfügung gestellt werden, um gemeinsame Funktionen, welche ein den Modulen der Hersteller gemeinsam enthalten sind, zu emulieren. Die Klasse des Moduls von einem Unternehmen A 520 und die Klasse des Moduls von einem Unternehmen B 530 beinhalten jeweils eine Mehrzahl von realen Hardwareemulationsfunktionen 522 und eine Mehrzahl von realen Steuerungsfunktionen 524. Jede der mehreren realen Hardwareemulationsfunktionen 522 und der mehreren realen Steuerungsfunktionen 524 sind Modulemulationsprogramme, welche jeweils entsprechend der Mehrzahl von virtuellen Hardwareemulationsfunktionen 512 und der Mehrzahl von virtuellen Steuerungsfunktionen 514 beschrieben werden, und beschreiben die Inhalte der Verarbeitung der realen Methodenfunktionen (nicht-virtuelle Methodenfunktionen) entsprechend der virtuellen Methodenfunktionen.
  • Die Klasse des Moduls von einem Unternehmen A 520 und die Klasse des Moduls von einem Unternehmen B 530 beinhalten Klassen, welche weiter abgeleitet werden. Beispielsweise wird in 5 die Klasse des Moduls von einem Unternehmen B 530 weiter in eine digitale Prüfmodulklasse 540, eine Energiequellenmodulklasse 560 und eine synchrone Modulklasse 590 abgeleitet.
  • Die digitale Prüfmodulklasse 540 ist eine Klasse eines Prüfmodul-Emulationsprogramms zum Emulieren des Prüfmoduls 170 zum Durchführen der funktionalen Prüfung der DUT 100. Die digitale Prüfmodulklasse 540 ist weiter abgeleitet in eine 250 MHz digitale Prüfmodulklasse 550 zum Emulieren des Prüfmoduls 170, welche die funktionale Prüfung der DUT 100 bei einer Frequenz von 250 MHz durchführt. Die Energiequellenmodulklasse 560 ist eine Klasse eines Modulemulationsprogramms zum Emulieren des Moduls zum Zurverfügungstellen von elektrischer Leistung für die DUT 100. Die Energiequellenmodulklasse 560 ist weiter abgeleitet in eine Hochspannungs-Energiequellenmodulklasse 570 zum Emulieren des Moduls, welches Hochspannungsenergie für die DUT 100 zur Verfügung stellt und die Niederspannungs-Energiequellenmodulklasse 580 zum Emulieren des Moduls, welches Niederspannungsleistung für die DUT 100 zur Verfügung stellt. Die synchrone Modulklasse 590 ist eine Klasse eines Modulemulationsprogramms zum Emulieren des synchronen Moduls 150.
  • Jede von der 250 MHz digitalen Prüfmodulklasse 550, der Hochspannungs-Energiequellenmodulklasse 570, der Niederspannungs-Energiequellenmodulklasse 580 und der synchronen Modulklasse 590 beinhaltet die reale Methodenfunktion handleEvent() zum Emulieren der originalen Funktion von jedem der Module, welche verwendet wird, indem das handleEvent() in der Klasse des Moduls von einem Unternehmen B ersetzt (überschrieben) wird.
  • Jeder des synchronen Modulemulationsabschnitts 250, des synchronen Verbindungsmodul-Emulationsabschnitts 260, des einen oder der Mehrzahl der Prüfmodul-Emulationsabschnitte 270 usw., welche in dem Prüfemulator 190 eingearbeitet sind, wird als eine Instanz von den Klassen der Modulemulationsprogramme, welche in der Klassenhierarchiestruktur 500 enthalten sind, realisiert.
  • Wie oben beschrieben, wird jeder des synchronen Modulemulationsabschnitts 250, des synchronen Verbindungsmodul-Emulationsabschnitts 260, des Modulemulationsabschnitts des Prüfmodul-Emulationsabschnitts 270 usw., welcher in dem Prüfemulator 190 enthalten ist, durch das Modulemulationsprogramm beispielsweise entsprechend einer der Klassen, welche in der Klassenhierarchiestruktur 500 enthalten sind, realisiert. Ein Benutzer des Prüfemulators 190 baut im wesentlichen dieselbe Prüfumgebung als das reale System der Prüfvorrichtung 10 in dem Prüfemulator 190 auf, indem er die Instanzen der Modulemulationsprogramme aus den Kombinationen der Klassen entsprechend der Kombination der Module, welche in dem realen System der Prüfvorrichtung 10 zu montieren sind, erzeugt. Darüberhinaus werden, im Falle der Erzeugung einer neuen Klasse entsprechend eines neuen Moduls, Mannstunden zum Erzeugen eines Modulemulationsprogramms reduziert, indem eine neue Klasse als eine vererbte Klasse einer der existierenden Klassen erzeugt wird.
  • 6 zeigt ein Flussdiagramm einer Prüfsignal-Erzeugung des Prüfemulators 190 gemäß der Ausführungsform der vorliegenden Erfindung, welche durch den Prüfmodul-Emulationsabschnitt 270 ausgeführt wird.
  • Wenn der Standortsteuerungs-Emulationsabschnitt 230 den Start der Prüfung an den synchronen Modulemulationsabschnitt 250, wobei das Prüfprogramm und die Prüfdaten in dem synchronen Modulemulationsabschnitt 250 gespeichert sind, den synchronen Verbindungsmodul-Emulationsabschnitt 260 und einen oder eine Mehrzahl von den Prüfmodul-Emulationsabschnitten 270 anweist, fährt der Prüfemulator 190 mit der Prüfung in Simulation gemäß eines hiernach beschriebenen Verfahrensablaufs fort. Zuerst ruft, im Fall, dass der Zeitausrichtungsabschnitt 276 den Prüfsignal-Erzeugungszeitpunkt ausgibt, der Ablaufabschnitt 277 des Ablaufsteuerabschnitts 275 (als SCHED in der Figur gezeigt) die handleEvent()-Funktion des synchronen Modulemulationsabschnitts 250 (als SYNC in der Figur gezeigt) auf und teilt mit, dass der Prüfsignal-Erzeugungszeitpunkt gekommen ist (S600). Hierdurch veranlasst der Ablaufsteuerabschnitt 275 den Prüfmodul-Emulationsabschnitt 270 entsprechend des Prüfsignal-Erzeugungszeitpunkts das Prüfsignal in Si mulation in der Zykluszeit entsprechend des Prüfsignal-Erzeugungszeitpunkts durch den synchronen Modulemulationsabschnitts 250 zu erzeugen. Hier benachrichtigt der Ablaufsteuerabschnitt 275 den synchronen Modulemulationsabschnitt 250 von dem Prüfsignal-Erzeugungszeitpunkt durch Einarbeiten des Ereignisidentifizierers, welcher anzeigt, dass der Prüfsignal-Erzeugungszeitpunkt des zugehörigen Prüfmodul-Emulationsabschnitts 270 gekommen ist, in einen Parameter der handleEvent()-Funktion.
  • Als nächstes benachrichtigt der synchrone Modulemulationsabschnitt 250 den Prüfmodul-Emulationsabschnitt 270 (als TM in der Figur gezeigt), welcher das Prüfsignal in Simulation in dem Prüfsignal-Erzeugungszeitpunkt erzeugen soll, von dem Zyklusstart, was die Anweisungen darstellt zum Starten der Verarbeitung der Zykluszeit und zum Erzeugen des Prüfsignals (S605). Hier benachrichtigt der synchrone Modulemulationsabschnitt 250 den Prüfmodul-Emulationsabschnitt 270 von dem Zyklusstart durch den Ablaufsteuerabschnitt 275 asynchron zu den Zeitpunkten, welche durch den Zeitausrichtungsabschnitt 276 in zeitlicher Reihenfolge ausgerichtet werden, indem der Ereignisidentifizierer, welcher den Zyklusstart anordnet in den Parameter einer raiseEvent()-Funktion eingearbeitet wird, und indem der Ablaufsteuerabschnitt 275 aufgerufen wird.
  • Danach erzeugt der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal in Simulation in der zugehörigen Zykluszeit in Erwiderung auf die Mitteilung des Zyklusstarts (S610). Das heißt, in S600, dass wenn der Ablaufsteuerabschnitt 275 den synchronen Modulemulationsabschnitt 250 von dem Prüfsignal-Erzeugungszeitpunkt benachrichtigt, um das Prüfsignal in Simulation in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt zu erzeugen, und wenn der synchrone Modulemulationsabschnitt 250, welcher die Benachrichtigung empfängt, den Prüfmodul-Emulationsabschnitt 270 von den Zykluszeit durch den Ablaufsteuerabschnitt 275 benachrichtigt, der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal in Simulation in der Zykluszeit erzeugt. Hier erzeugt der Prüfmodul-Emulationsabschnitt 270 den Änderungszeitpunkt des Prüfsignals in Simulation in der Zykluszeit während der Erzeugung des Prüfsignals in der Zykluszeit.
  • Als nächstes benachrichtigt der DUT-Verbindungsabschnitt 280 (als LB in der Figur gezeigt) den Zeitausrichtungsabschnitt 276 über den Änderungszeitpunkt in Erwiderung auf den Änderungszeitpunkt des Prüfsignals von dem Prüfmodul-Emulationsabschnitt 270 und registriert ihn (S615).
  • Als nächstes benachrichtigt der Prüfmodul-Emulationsabschnitt 270 den synchronen Modulemulationsabschnitt 250 über den Zeitpunkt für das Ende des Zyklus (S620). Hier erzeugt der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal durch den Mustererzeugungs-Emulationsabschnitt 430 basierend auf der Angabe durch das Prüfprogramm und die Prüfdaten, wodurch jede Zykluszeit dynamisch geändert wird. Aus diesem Grund erwirbt der Steuerungsfunktion-Verarbeitungsabschnitt 410 in dem Prüfmodul-IF-Emulationsabschnitt 400 des Prüfmodul-Emulationsabschnitts 270 den Beendigungszeitpunkt von jedem der Zyklen von dem Mustererzeugungs-Emulationsabschnitt 430 und benachrichtigt den synchronen Modulemulationsabschnitt 250 von dem Endzeitpunkt und veranlasst den synchronen Modulemulationsabschnitt 250 den nächsten Prüfsignal-Erzeugungszeitpunkt genau zu erzeugen.
  • Als nächstes erzeugt der synchrone Modulemulationsabschnitt 250 basierend auf dem von dem Testmodul-Emulationsabschnitt 270 in S620 mitgeteilten Zyklusendzeitpunkt den Prüfsignal-Erzeugungszeitpunkt, bei welchem der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal in Simulation gemäß der nächsten Zykluszeit erzeugen soll, benachrichtigt den Zeitausrichtungsabschnitt 276 über den Zeitpunkt und registriert ihn (S625). Darüberhinaus erzeugt der synchrone Modulemulationsabschnitt 250 weiter einen Prüfergebnis-Sammlungszeitpunkt für das Sammeln der Prüfergebnisse von dem Prüfmodul-Emulationsabschnitt 270, einen Zyklusbeendigungszeitpunkt zum Beendigen der Zykluszeit des Prüfmodul-Emulationsabschnitts 270 und den Unterbrechungssammlungszeitpunkt zum Sammeln der Unterbrechung, welche durch den Prüfmodul-Emulationsabschnitt 270 in Simulation während der Erzeugung des Prüfsignals in der Zykluszeit erzeugt wird. Dann benachrichtigt der synchrone Modulemulationsabschnitt 250 den Zeitausrichtungsabschnitt 276 über die Zeitpunkte und registriert sie (S625). Hier registriert der synchrone Modulemulationsabschnitt 250 die Zeitpunkte in dem Zeitausrichtungsabschnitt 276, indem die registerEvent()-Funktion in dem Ablaufsteuerabschnitt 275 aufgerufen wird.
  • Darüberhinaus erzeugt der synchrone Modulemulationsabschnitt 250 im wesentlichen denselben Zeitpunkt wie den von dem Prüfmodul-Emulationsabschnitt 270 empfangenen Zyklusendzeitpunkt als den Prüfsignal-Erzeugungszeitpunkt, den Testergebnis-Sammlungszeitpunkt, den Zyklusbeendigungszeitpunkt und den Unterbrechungssammlungszeitpunkt für die nächste Zeit in dem Prüfmodul-Emulationsabschnitt 270.
  • Als nächstes benachrichtigt der Ablaufabschnitt 277, wenn der Zeitausrichtungsabschnitt 276 den Änderungszeitpunkt, welcher in S615 registriert wird, ausgibt, den DUT-Verbindungsabschnitt 280, dass der Änderungszeitpunkt gekommen ist, um das Prüfsignal in Simulation bei dem Zeitpunkt zu ändern (S630).
  • Als nächstes erzeugt der DUT-Verbindungsabschnitt 280, wenn der Änderungszeitpunkt von dem Ablaufabschnitt 277 mitgeteilt wird, das Prüfsignal, indem das Prüfsignal in Simulation bei dem Änderungszeitpunkt geändert wird, und teilt es an den DUT-Simulationsabschnitt 200 mit (S635). Der DUT-Simulationsabschnitt 200 simuliert die Arbeitsweise der DUT 100 basierend auf dem von dem DUT-Verbindungsabschnitt 280 erworbenen Prüfsignal. Dann erzeugt der DUT-Simulationsabschnitt 200 das Ergebnissignal in Simulation, welches als ein Ergebnis der DUT 100, welche basierend auf dem Prüfsignal betrieben wird, ausgegeben wird, und versorgt den Prüfmodul-Emulationsabschnitt 270 durch den DUT-Verbindungsabschnitt 280 mit ihm. Der Prüfsignal-Emulationsabschnitt 270 vergleicht das Ergebnissignal mit dem erwarteten Wert und erwirbt ein Vergleichsergebnis.
  • Als nächstes benachrichtigt der Ablaufabschnitt 277, wenn der Zeitausrichtungsabschnitt 276 den Prüfergebnis-Sammlungszeitpunkt, welcher in S625 registriert wurde, ausgibt, den Prüfmodul-Emulationsabschnitt 270, dass der Prüfergebnis-Sammlungszeitpunkt gekommen ist, um die Eignung des Ergebnisses basierend auf dem Ergebnissignal, welches dem Prüfmodul-Emulationsabschnitt 270 von dem DUT-Simulationsabschnitt 200 zur Verfügung gestellt wurde, zu sammeln (S640). Wenn der Prüfergebnis-Sammlungszeitpunkt mitgeteilt wird, benachrichtigt der Prüfmodul-Emulationsabschnitt 270 den synchronen Modulemulationsabschnitt 250 durch den synchronen Verbindungsmodulemulationsabschnitt 260 von dem Vergleichsergebnis des Ergebnissignals und von dem erwarteten Wert in der Zykluszeit. Der synchrone Modulemulationsabschnitt 250 bewertet die Eignung (durchgehen oder durchfallen) des Prüfergebnisses basierend auf dem Vergleichsergebnis, welches von jedem der Prüfmodul-Emulationsabschnitte 270 gesammelt wurde, und benachrichtigt jeden der Prüfmodul-Emulationsabschnitte 270 von der Eignung eines Prüfergebnisses (S645). Basierend auf der Eignung dieses Prüfergebnisses werden das Prüfprogramm und die Prüfdaten, welche den mehreren Prüfmodul-Emulationsabschnitten 270 zur Verfügung gestellt werden, beschrieben, um die Folge der Prüfung, welche nach der Zykluszeit durchgeführt wird, zu ändern.
  • Als nächstes benachrichtigt der Ablaufabschnitt 277, wenn der Zeitausrichtungsabschnitt 276 den Zyklusbeendigungszeitpunkt in S625 ausgibt, den Prüfmodul-Emulationsabschnitt 270, dass der Beendigungszeitpunkt des Zyklusses gekommen ist (S650).
  • Als nächstes benachrichtigt der Ablaufabschnitt 277, wenn der Zeitausrichtungsabschnitt 276 den in S625 registrierten Unterbrechungssammlungszeitpunkt ausgibt, den Prüfmodul-Emulationsabschnitt 270, dass der Unterbrechungssammlungszeitpunkt gekommen ist (S655). Wenn der Unterbrechungssammlungszeitpunkt mitgeteilt wird, benachrichtigt der Prüfmodul-Emulationsabschnitt 270 in Simulation den Standortsteuerungs-Emulationsabschnitt 230 durch den Busschalter-Emulationsabschnitt 240 von der Unterbrechung, welche in Simulation in der Zykluszeit erzeugt wird, bei welcher der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal direkt vor dem Unterbrechungssammlungs zeitpunkt erzeugt.
  • Der Prüfemulator 190 wiederholt das in den oben erwähnten Schritten S600-S655 erläuterte Verarbeiten bis die Prüfung beendet ist (S660).
  • Darüberhinaus richtet der Ablaufsteuerungsabschnitt 275, wenn die Prüfung durch die Mehrzahl der Prüfmodul-Emulationsabschnitte 270 beendet ist, die Zeitpunkte von jedem der Arbeitsabläufe der Prüfmodul-Emulationsabschnitte 270 in zeitlicher Reihenfolge aus und macht den Ablauf. Aus diesem Grunde werden S600, S630, S640, S650 und S655 über die Mehrzahl von Prüfmodul-Emulationsabschnitten 270 in zeitlicher Reihenfolge durchgeführt.
  • 7 ist eine Zeichnung, welche exemplarisch das in Simulation durch den Prüfemulator 190 gemäß der Ausführungsform der vorliegenden Erfindung erzeugte Prüfsignal zeigt. In dieser Zeichnung beinhaltet der Prüfemulator 190 einen Prüfmodul-Emulationsabschnitt 270a zum Emulieren eines Prüfmoduls A und einen Prüfmodul-Emulationsabschnitt 270b zum Emulieren eines Prüfmoduls B als den Prüfmodul-Emulationsabschnitt 270.
  • Vor dem Zeitpunkt t1 werden der Prüfsignal-Erzeugungszeitpunkt t1 des Prüfmodul-Emulationsabschnitts 270a und der Prüfsignal-Erzeugungszeitpunkt t2 des Prüfmodul-Emulationsabschnitts 270b in dem Zeitausrichtungsabschnitt 276 registriert. Da die Zeitpunkte in zeitlicher Reihenfolge auszugeben sind, wird der Prüfsignal-Erzeugungszeitpunkt t1 zuerst ausgegeben. In Erwiderung auf das Ergebnis benachrichtigt der Ablaufabschnitt 277 den synchronen Modulemulationsabschnitt 250, dass der Prüfsignal-Erzeugungszeitpunkt gekommen ist, während die Zeit auf t1 vorwärts gesetzt wird.
  • Wenn der Prüfsignal-Erzeugungszeitpunkt t1 mitgeteilt wird, benachrichtigt der synchrone Modulemulationsabschnitt 250 den Prüfmodul-Emulationsabschnitt 270a entsprechend des Prüfsignal-Erzeugungszeitpunkts t1 durch den synchronen Verbindungsmodul-Emulationsabschnitt 260 und den Prüfmodul-Emulationsabschnitt 270 von dem Start des Zyklusses. In Erwiderung darauf erzeugt der Prüfmodul-Emulationsabschnitt 270a das Prüfsignal in Simulation in der angegebenen Zykluszeit als ein Zyklus 1 in der Figur. Hier benachrichtigt der Testmodul-Emulationsabschnitt 270a den DUT-Verbindungsabschnitt 280, dass das Prüfsignal sich auf einen H-Pegel bei dem Änderungszeitpunkt t4 in der Zykluszeit ändert. In Erwiderung darauf registriert der DUT-Verbindungsabschnitt 280 den Änderungszeitpunkt t4 in dem Zeitausrichtungsabschnitt 276.
  • Als nächstes benachrichtigt der Prüfmodul-Emulationsabschnitt 270a, nachdem die Erzeugung des Prüfsignals in dem Zyklus 1 beendet ist, den synchronen Modulemulationsabschnitt 250 von dem Zyklusendzeitpunkt t6 des Zyklusses 1. In Erwiderung darauf erzeugt der synchrone Modulemulationsabschnitt 250 den Prüfsignal-Erzeugungszeitpunkt t6, den Prüfergebnis-Sammlungszeitpunkt t6-Δ, den Zyklusbeendigungszeitpunkt t6-Δ und den Unterbrechungssammlungszeitpunkt t6-Δ für die nächste Zeit basierend auf dem Zyklusendzeitpunkt t6 und registriert sie in dem Zeitausrichtungsabschnitt 276. Hier ist t6-Δ eine Zeit direkt vor dem nächsten Prüfsignal-Erzeugungszeitpunkt t6.
  • Als nächstes richtet der Zeitausrichtungsabschnitt 276 die registrierten Zeitpunkte in zeitlicher Reihenfolge aus und gibt den Prüfsignal-Erzeugungszeitpunkt t2 aus. In Erwiderung darauf setzt der Ablaufabschnitt 277 die Zeit vorwärts auf t2 und benachrichtigt den synchronen Modulemulationsabschnitt 250, dass der Prüfsignal-Erzeugungszeitpunkt t2 gekommen ist.
  • Wenn der Prüfsignal-Erzeugungszeitpunkt t2 mitgeteilt wird, benachrichtigt der synchrone Modulemulationsabschnitt 250 den Prüfmodul-Emulationsabschnitt 270 entsprechend dem Prüfsignal-Erzeugungszeitpunkt t2 durch den Ablaufsteuerabschnitt 275 von dem Zyklusstart. In Erwiderung darauf erzeugt der Prüfmodul-Emulationsabschnitt 270b das Prüfsignal des Prüfmodul-Emulationsabschnitts 270b in Simulation in dem Zyklus 1. Als ein Ergebnis erzeugt der Prüfmodul-Emulationsabschnitt 270b Änderungszeitpunkte der Prüfsignale t3 und t5 und der DUT-Verbindungsabschnitt 280 registriert die Änderungszeitpunkte in dem Zeitausrichtungsabschnitt 276.
  • Als nächstes benachrichtigt der Prüfmodul-Emulationsabschnitt 270b den synchronen Modulemulationsabschnitt 250 über den Zyklusendzeitpunkt t7 des Zyklusses 1 nachdem das Erzeugen des Prüfsignals in einem Zyklus 1 beendet ist. In Erwiderung darauf erzeugt der synchrone Modulemulationsabschnitt 250 basierend auf dem Zyklusendzeitpunkt t7 den Prüfsignal-Erzeugungszeitpunkt t7, den Prüfergebnis-Sammlungszeitpunkt t7-Δ, den Zyklusbeendigungszeitpunkt t7-Δ und den Unterbrechungssammlungszeitpunkt t7-Δ für die nächste Zeit und registriert sie in dem Zeitausrichtungsabschnitt 276.
  • Als nächstes richtet der Zeitausrichtungsabschnitt 276 die registrierten Zeitpunkte in zeitlicher Reihenfolge aus und gibt die Änderungszeitpunkte t3, t4 und t5 nacheinander aus. Gemäß jedem der Änderungszeitpunkte benachrichtigt der Ablaufabschnitt 277 den DUT-Verbindungsabschnitt 280 von den Änderungszeitpunkten. Als ein Resultat ändert der DUT-Verbindungsabschnitt 280 das Prüfsignal in Simulation während des Änderungszeitpunkts und es wird dem DUT-Simulationsabschnitt 200 zur Verfügung gestellt.
  • Als nächstes gibt der Zeitausrichtungsabschnitt 276 den Prüfergebnis-Sammlungszeitpunkt t6-Δ aus. In Erwiderung darauf setzt der Ablaufabschnitt 277 die Zeit vorwärts auf t6-Δ und benachrichtigt den Prüfmodul-Emulationsabschnitt 270a von dem Prüfergebnis-Sammlungszeitpunkt t6-Δ. Als ein Ergebnis werden eine Sammlung und eine Verteilung des Prüfergebnisses zwischen dem Prüfmodul-Emulationsabschnitt 270a und dem synchronen Modulemulationsabschnitt 250 durchgeführt.
  • Als nächstes gibt der Zeitausrichtungsabschnitt 276 den Zyklusbeendigungszeitpunkt t6-Δ aus. In Erwiderung darauf benachrichtigt der Ablaufabschnitt 277 den Prüfmodul-Emulationsabschnitt 270a von dem Ende des Zyklusses 1.
  • Als nächstes gibt der Zeitausrichtungsabschnitt 276 den Unterbrechungssammlungszeitpunkt t6-Δ aus. In Erwiderung darauf benachrichtigt der Ablaufabschnitt 277 den Prüfmodul-Emulationsabschnitt 270a von dem ausgegebenen Unterbrechungssammlungszeitpunkt t6-Δ. Als ein Ergebnis benachrichtigt der Prüfmodul-Emulationsabschnitt 270a den Standortsteuerungs-Emulationsabschnitt 230 von der in Simulation in dem Zyklus 1 erzeugten Unterbrechung.
  • Als nächstes gibt der Zeitausrichtungsabschnitt 276 den Prüfsignal-Erzeugungszeitpunkt t6 aus. In Erwiderung darauf setzt der Ablaufabschnitt 277 die Zeit vorwärts auf t6 und benachrichtigt den synchronen Modulemulationsabschnitt 250, dass der Prüfsignal-Erzeugungszeitpunkt t6 gekommen ist. Nunmehr erzeugt der Prüfemulator 190 den Änderungszeitpunkt t8, den Ergebnissignal-Erwerbszeitpunkt t11, welcher den Zeitpunkt zu dem das Ergebnissignal zu erwerben ist, anzeigt, den Prüfsignal-Erzeugungszeitpunkt t12, den Prüfergebnis-Sammlungszeitpunkt t12-Δ, den Zyklusbeendigungszeitpunkt t12-Δ und den Unterbrechungssammlungszeitpunkt t12 für die nächste Zeit auf dieselbe Art und Weise zur Zeit t1. Dann registriert der Prüfemulator 190 diese Zeitpunkte in dem Zeitausrichtungsabschnitt 276 auf dieselbe Art und Weise zur Zeit t1.
  • Als nächstes richtet der Zeitausrichtungsabschnitt 276 die registrierten Zeitpunkte in zeitlicher Reihenfolge aus und gibt den Prüfsignal-Erzeugungszeitpunkt t7 aus. In Erwiderung darauf setzt der Ablaufabschnitt 277 die Zeit vorwärts auf die t7 und benachrichtigt den synchronen Modulemulationsabschnitt 250, dass der Prüfsignal-Erzeugungszeitpunkt t7 gekommen ist. Fortan erzeugt der Prüfemulator 190 die Änderungszeitpunkte t9 und t10, den Prüfsignal-Erzeugungszeitpunkt t13, den Prüfergebnis-Sammlungszeitpunkt t13-Δ, den Zyklusbeendigungszeitpunkt t13-Δ und den Unterbrechungssammlungszeitpunkt t13 für die nächste Zeit auf die gleiche Art und Weise zur Zeit t2. Dann registriert der Prüfemulator 190 diese Zeitpunkte in dem Zeitausrichtungsabschnitt 276 auf die gleiche Art und Weise zur Zeit t2.
  • Wie oben beschrieben richtet der Ablaufsteuerab schnitt 275 gemäß dem Prüfemulator 190 der vorliegenden Ausführungsform verschiedene Arten von Zeitpunkten, wie beispielsweise den Prüfsignal-Erzeugungszeitpunkt, den Prüfsignal-Änderungszeitpunkt, den Prüfergebnis-Sammlungszeitpunkt, den Ergebnissignal-Erwerbszeitpunkt und den Unterbrechungssammlungszeitpunkt in zeitlicher Reihenfolge aus, so dass der Ablauf ausgeführt wird. Aus diesem Grund emuliert der Prüfemulator 190 die Arbeitsweise der Testvorrichtung 10 geeignet im Falle, dass die mehreren auf unterschiedlichen Zyklen basierenden Prüfmodule 170 montiert sind.
  • Alternativ dazu kann das folgende Verfahren anstelle des oben erwähnten Verfahrens in der vorliegenden Ausführungsform eingesetzt werden, obwohl der synchrone Verbindungsmodul-Emulationsabschnitt 260 im Falle, dass der Zyklusendzeitpunkt von dem Prüfmodul 170 empfangen wird, den Prüfergebnis-Sammlungszeitpunkt, den Zyklusbeendigungszeitpunkt und den Unterbrechungssammlungszeitpunkt in dem Zeitausrichtungsabschnitt 276 registriert.
  • In dem in 6 illustrierten S625 erzeugt der synchrone Modulemulationsabschnitt 250 basierend auf dem Zyklusendzeitpunkt den Prüfsignal-Erzeugungszeitpunkt, zu dem der Prüfmodul-Emulationsabschnitt 270 das Prüfsignal in Simulation entsprechend der Zykluszeit erzeugen soll, und benachrichtigt den Zeitausrichtungsabschnitt 276 von dem Zeitpunkt und registriert den Zeitpunkt in dem Zeitausrichtungsabschnitt 276. Andererseits erzeugt der synchrone Modulemulationsabschnitt 250 zu dieser Zeit nicht den Prüfergebnis-Sammlungszeitpunkt, den Zyklusbeendigungszeitpunkt und den Unterbrechungssammlungszeitpunkt und registriert sie nicht in dem Zeitausrich tungsabschnitt 276.
  • Als ein Ergebnis fährt der Prüfemulator 190, nachdem die Verarbeitung in den Schritten S630 und S635 getan ist, mit dem Schritt S600 fort unter Auslassung der Schritte S640, S650 und S655. Darüberhinaus benachrichtigt der Ablaufabschnitt 277 in dem Fall, dass der Zeitausrichtungsabschnitt 276 den Prüfsignal-Erzeugungszeitpunkt entsprechend der nächsten Zykluszeit in S600 ausgibt, den synchronen Modulemulationsabschnitt 250, dass der Prüfsignal-Erzeugungszeitpunkt gekommen ist. In Erwiderung darauf weist der synchrone Modulemulationsabschnitt 250 an den Prüfmodul-Emulationsabschnitt 270 die Sammlung des Prüfergebnisses, die Benachrichtigung des Zyklusendes und die Sammlung der Unterbrechung entsprechend dem Prüfsignal-Erzeugungszeitpunkt vor dem Erzeugen der Prüfsignalerzeugung der nächsten Zykluszeit an.
  • Gemäß dem oben beschriebenen Verarbeiten veranlasst der Ablaufsteuerabschnitt 275 den synchronen Modulemulationsabschnitt 250, den synchronen Verbindungsmodul-Emulationsabschnitt 260, den Prüfmodul-Emulationsabschnitt 270 usw., die in S640, S645, S650 und S655 beschriebene Verarbeitung vor dem Erzeugen des Prüfsignals der nächsten Zykluszeit durchzuführen. Genauer gesagt veranlasst der Ablaufsteuerabschnitt 275 den synchronen Modulemulationsabschnitt 250 und den synchronen Verbindungsmodul-Emulationsabschnitt 260 dazu, die Eignung des Prüfergebnisses basierend auf dem Ergebnissignal, welches dem Prüfmodul-Emulationsabschnitt 270 während des Erzeugens des Prüfsignals in der Zykluszeit direkt vor dem Prüfsignal-Erzeugungszeitpunkt zur Verfügung gestellt wurde, zu sammeln und zu verteilen und den Standortsteuer-Emulationsabschnitt 230 von der in Simulation durch den Prüfmodul-Emulationsabschnitt 270 erzeugten Unterbrechung zu unterrichten.
  • Obwohl die vorliegende Erfindung durch ein exemplarisches Ausführungsbeispiel beschrieben worden ist, sollte es verstanden werden, dass die Fachleute viele Änderungen und Ersetzungen vornehmen können. Es ist basierend auf der Definition der anhängigen Ansprüche offensichtlich, dass Ausführungsformen mit solchen Modifikationen ebenfalls zum Schutzumfang der vorliegenden Erfindung gehören.
  • Beispielsweise werden die reale Prüfung der DUT 100 durch das synchrone Modul 150, das synchrone Verbindungsmodul 160, das Testmodul 170 usw. und eine Simulationsprüfung der DUT 100 durch den synchronen Modulemulationsabschnitt 250, den synchronen Verbindungsmodul-Emulationsabschnitt 260, den Prüfmodul-Emulationsabschnitt 270, den DUT-Simulationsabschnitt 200 usw. einem Benutzer der Prüfvorrichtung 10 zur Verfügung gestellt, was durch ein identisches Prüfsteuerungsprogramm und/oder das identische Prüfprogramm ausführbar ist. Alternativ dazu kann der Prüfmodus der Prüfvorrichtung zwischen der realen Prüfung und der Simulationsprüfung manuell durch den Benutzer umgeschaltet werden.
  • Das heißt beispielsweise, dass der Standortcontroller 130 Befehle der Auswahl zwischen der realen und der simulierten Prüfung der DUT 100 als eine Option eines Prüfstartbefehls oder ähnliches eingibt. Dann, wenn die Befehle verlangen, dass die reale Prüfung der DUT 100 durchzuführen ist, stellen der Systemcontroller 110 oder der Standortcontroller 130 ein Prüfprogramm für die Prüfung der DUT 100 für ein oder mehrere der Prüfmodule 170 durch den Busschalter 140 zur Verfü gung und veranlassen das Prüfmodul 170, die DUT 100 zu prüfen. Andererseits stellt der Standortcontroller 130, wenn die Befehle fordern, die simulierte Prüfung der DUT 100 durchzuführen, ein Prüfprogramm an den Prüfmodul-Emulationsabschnitt 270, welches über Software auf dem Prüfemulator 190 oder dem Standortcontroller 130 oder ähnlichen realisiert ist, zur Verfügung und veranlasst den Prüfmodul-Emulationsabschnitt 270 oder ähnliches, die Prüfung der DUT 100 zu simulieren.
  • In den Ausführungsformen wie sie oben beschrieben wurden kann der Standortcontroller 130 Kommunikationssoftware (Kommunikationsbibliothek), welche eine Kommunikationsverarbeitung zwischen den Steuereinheiten und den Prüfmodulen 170 so durchführt, dass die reale Prüfumgebung und die Simulationsprüfumgebung zugreifbar sein können, ausführen. In diesem Fall führt das durch den Standortcontroller 130 ausgeführte Prüfsteuerungsprogramm die reale Prüfung durch, indem die identischen Zugangsfunktionen (Lese-/Schreibfunktionen usw.), welche durch die Kommunikationssoftware zur Verfügung gestellt werden, verwendet werden und indem auf das synchrone Modul 150, das synchrone Verbindungsmodul 160, das Prüfmodul 170 usw. zurückgegriffen wird. Gleichermaßen führt das Prüfsteuerungsprogramm, welches durch den Standortcontroller 130 ausgeführt wird, die Simulationsprüfung durch, indem die identischen Zugriffsfunktionen, welche durch die Kommunikationssoftware zur Verfügung gestellt werden, verwendet werden, und indem auf den synchronen Modulemulationsabschnitt 250, den synchronen Verbindungsmodul-Emulationsabschnitt 260, den Prüfmodul-Emulationsabschnitt 270 usw. zugegriffen wird. Hier kann die oben beschriebene Kommunikationssoftware in Kooperation mit dem Standortcontroller 130 das Ziel des Prüfprogramms zwischen dem Prüfmodul 170 oder ähnlichem und dem Prüfmodul-Emulationsabschnitt 270 oder ähnlichem basierend auf den Befehlen, über welche die reale Prüfumgebung oder die Simulationsprüfumgebung auszuwählen sind, auswählen. Ein Beispiel einer solchen Implementation wird nachfolgend weiter in der zusätzlichen Information C.2.4.3. beschrieben.
  • Darüberhinaus kann beispielsweise der vorstehend beschriebene Prüfmodul-Emulationsabschnitt 270 eine Konfiguration, wie sie nachfolgend beschrieben ist, beinhalten. Als erstes empfängt jeder Prüfmodul-Emulationsabschnitt 270 ein Signal für einen Prüfsignal-Erzeugungszeitpunkt, eingeplant durch den Ablaufabschnitt 277 in dem Ablaufsteuerabschnitt 275, durch Funktionsaufruf. Dann gibt jeder Prüfmodul-Emulationsabschnitt 270 eine Variation der Spannung des Prüfsignals in der Zykluszeit entsprechend des Prüfsignal-Erzeugungszeitpunkts aus, indem Spannungssetzungsmethoden (Setzmethoden) von dem ausgegebenen Kanalobjekt, welches den Ausgabekanal emuliert, mehrfach aufgerufen werden. Dann benachrichtigt, nachdem die Ausgabe der Spannungsvariation des Prüfsignals entsprechend der Zykluszeit beendet ist, der Prüfmodul-Emulationsabschnitt 270 den Ablaufabschnitt 277 und ähnliche, dass die Ausgabe der Variation der Spannung des Prüfsignals entsprechend der Zykluszeit beendet worden ist, indem die Endmethoden des ausgegebenen Kanalobjekts aufgerufen werden. Ein Beispiel einer solchen Implementation wird nachstehend weiter in der zusätzlichen Information B.3.3. und ähnlichem beschrieben.
  • Dann berechnet der Ablaufabschnitt 277 eine Periode, während welcher alle Prüfmodul-Emulationsabschnitte die Ausgabe der Variation der Spannung des Prüfsignals basierend auf den Endmethoden, welche von jeder der mehreren Prüfmodul-Emulationsabschnitte 270 mitgeteilt wurden, beenden und verlangt von dem DUT-Simulationsabschnitt 200 die Simulation der Arbeitsweise der DUT 100 während dieser Periode. In Erwiderung darauf erwirbt die DUT-Verbindungseinheit 280 das Prüfsignal während der Periode und simuliert die Arbeitsweise der zu prüfenden Geräte basierend auf dem Prüfsignal. Wie oben dargelegt, verbietet, nachdem die Endmethoden aufgerufen wurden, das ausgegebene Kanalobjekt die Variation der Spannung in der Periode, während welcher die Ausgabe der Variation der Spannung des Prüfsignals beendet wird, wobei die Variation der Spannung durch die Endmethoden mitgeteilt wird. Dadurch kann eine Inkonsistenz des Simulationsergebnisses, welches bereits simuliert worden ist, verhindert werden. Ein Beispiel einer solchen Implementation wird nachfolgend näher in der zusätzlichen Information B.3.4. und ähnlichem beschrieben.
  • Nachstehend beschrieben ist die zusätzliche Information über verschiedene Arten von Beispielen und Spezifikationen zum Realisieren der Prüfvorrichtung 10 und des Prüfemulators 190 gemäß der vorliegenden Ausführungsform.
  • Ergänzende Information A: Ein Beispiel einer Softwarearchitektur
  • 8 illustriert eine Softwarearchitektur 2200 gemäß einer Ausführungsform der vorliegenden Erfindung. Die Softwarearchitektur 2200 repräsentiert ein verteiltes Betriebssystem, welches Elemente für den Systemcontroller 2200, zumindest einen Standortcontroller 2240 und zumindest ein Modul 2260 in Übereinstim mung mit zugehörigen Hardwaresystemelementen 110, 130, 150, 160 und 170 aufweist. Zusätzlich zu dem Modul 2260 weist die Architektur 2200 eine entsprechende SW (Software) Modulemulation 2280 auf.
  • Als eine beispielhafte Auswahl kann die Entwicklungsumgebung für diese Plattform auf Microsoft Windows basieren. Die Verwendung dieser Architektur hat einen Nebennutzen in der Programm- und Unterstützungsportabilität (beispielsweise könnte ein Feldservice-Ingenieur einen Laptop, auf welchem das Prüfer-Betriebssystem läuft, verbinden, um fortgeschrittene Diagnostikmaßnahmen durchzuführen). Jedoch kann für große, berechnungsintensive Operationen (wie beispielsweise kompilierte Prüfmuster) die relevante Software als eine unabhängige Einheit ausgestaltet werden, welche fähig ist, unabhängig zu laufen, um eine Arbeitsablauf-Koordination über verteilte Plattformen zu erlauben. Zugehörige Softwarewerkzeuge für Stapelverarbeitungsabläufe können demgemäß auf mehreren Plattformtypen ablaufen.
  • Als eine exemplarische Auswahl kann der ANSI/ISO-Standard C++ als natürliche Sprache für die Software verwendet werden. Natürlich gibt es eine Vielzahl von verfügbaren Optionen (eine Schicht über den nominalen C++-Interfaces zur Verfügung zu stellen), welche einer dritten Partei erlauben, sich in dem System mit einer alternativen Sprache der eigenen Wahl zu integrieren.
  • 8 illustriert eine Schraffur von Elementen gemäß ihrer Organisation durch eine nominale Quelle (oder eine kollektive Entwicklung als ein Untersystem), welche die Prüfer-Betriebssystem-Interfaces 2290, Benutzerkomponenten 2292 (beispielsweise für Prüfzwecke von einem Benutzer zur Verfügung gestellt), Systemkomponenten 2294 (beispielsweise als eine Softwareinfrastruktur für die grundlegende Verbindungsfähigkeit und die grundlegende Kommunikation zur Verfügung gestellt), Modulentwicklungskomponenten 2296 (beispielsweise durch einen Modulentwickler zur Verfügung gestellt) und externe Komponenten 2298 (beispielsweise über externe Quellen, welche andere sind als die Modulentwickler, zur Verfügung gestellt) aufweist.
  • Aus der Perspektive einer quellbasierten Organisation beinhaltet das Prüferbetriebssystem (TOS von engl. Tester Operating System)-Interface 2290: Systemcontroller bis Standortcontroller-Interfaces 2222; Rahmenwerkklassen 2224; Standortcontroller bis Modulinterfaces 2245; Rahmenwerkklassen 2246, vorbestimmte Modulniveauinterfaces 2247, Backplanekommunikationsbibliotheken 2249, Chassisschacht IF (Interface) 2262, Loadboard-Hardware IF 2264, Backplanesimulation IF 2283, Loadboardsimulation IF 2285, DUT-Simulation IF 2287, Verilog PLI (Programmsprachen-Interface von engl. Programming Language Interface) 2288 für das Verilog-Modell der DUTs und C/C++ Sprachunterstützung 2289 für das C/C++ Modell der DUTs.
  • Die Benutzerkomponenten 2292 beinhalten: Einen Benutzerprüfplan 2242, Benutzertestklassen 2243, Hardwareloadboard 2265 und DUT 2266, ein DUT-Verilog-Modell 2293 und ein DUT C/C++ Modell 2291.
  • Die Systemkomponenten 2294 beinhalten: Systemwerkzeuge 2296, Kommunikationsbibliotheken 2230, Testklassen 2244, einen Backplane-Treiber 2250, die HW-Backplane 2261, welche den Busschalter 140 beinhaltet, Simulationsrahmenwerk 2281, Backplane-Emulation 2282 und Loadboard-Simulation 2286.
  • Die Modul-Entwicklungskomponenten 2296 beinhalten: Modulbefehlimplementierungen 2248, Modulhardware 2263 und Modulemulation 2284.
  • Die externen Komponenten 2298 beinhalten externe Werkzeuge 2255. Der Systemcontroller 2200, welcher auf den in 1 illustrierten Prüfstandorten 2110 softwarebetrieben ist, beinhaltet Interfaces 2222 zu Standortcontrollern, Rahmenwerkklassen 2224, Systemwerkzeuge 2226, externe Werkzeuge 2225 und eine Kommunikationsbibliothek 2230. Die Systemcontrollersoftware ist der primäre Punkt der Interaktion für den Benutzer. Sie stellt die Schnittstelle zu den Standortcontrollern der Ausführungsform und die Synchronisation der Standortcontroller in einer Multi-Standort/DUT-Umgebung, wie in der US-Anmeldung Nr. 60/449622 vom selben Anmelder beschrieben, zur Verfügung. Benutzeranwendungen und Werkzeuge, graphische Benutzerinterfaces, (GUI)-basiert oder andere, laufen auf dem Systemcontroller. Der Systemcontroller kann auch als der Aufbewahrungsort für die gesamte prüfplanbezogene Information, inklusive der Prüfpläne, Prüfmuster und Prüfparameterdateien dienen. Eine Prüfparameterdatei beinhaltet Parametrisierungsdaten für eine Prüfklasse in der objektorientierten Umgebung der Ausführungsform.
  • Entwickler einer dritten Partei können Werkzeuge zusätzlich zu den (oder als Ersatz für die) Standardsystemwerkzeuge(n) 2226 zur Verfügung stellen. Die Standardinterfaces 2222 auf dem Systemcontroller 2200 beinhalten Interfaces, welche die Werkzeuge verwenden, um auf den Prüfer und die Prüfobjekte zuzugreifen. Die Werkzeuge (Anwendungen) 2225, 2226 erlauben eine interaktive Steuerung und eine Stapelverarbei tungssteuerung der Prüfung und der Prüfobjekte. Die Werkzeuge beinhalten Anwendungen, um Automatisierungsfähigkeiten zur Verfügung zu stellen (beispielsweise durch die Verwendung von SECS/TSEM usw).
  • Die Kommunikationsbibliothek 2230, welche in dem Systemcontroller 2200 angesiedelt ist, stellt den Mechanismus zur Kommunikation mit den Standortcontrollern 2240 auf eine Art und Weise zur Verfügung, die transparent für Benutzeranwendungen und Prüfprogramme ist.
  • Die Interfaces 2222, welche im Speicher, welcher dem Systemcontroller 2200 zugeordnet ist, angesiedelt sind, stellen offene Interfaces zu den Rahmenwerkobjekten, welche auf dem Systemcontroller ablaufen, zur Verfügung. Eingebunden sind Interfaces, welche der standortcontrollerbasierten Modulsoftware erlauben, auf Musterdaten zuzugreifen und diese wiederzugewinnen. Auch sind Interfaces eingebunden, welche Anwendungen und Werkzeuge verwenden, um auf den Prüfer und die Prüfobjekte zuzugreifen, ebenso wie Scripting-Interfaces, welche die Fähigkeit zur Verfügung stellen, auf den Prüfer und Prüfkomponenten durch einen Scriptingengine zuzugreifen und diese zu manipulieren. Dies erlaubt einen gemeinsamen Mechanismus für interaktive Anwendungen, Stapelverarbeitungsanwendungen und Remote-Anwendungen, um ihre Funktionen durchzuführen.
  • Die dem Systemcontroller 2200 zugeordneten Rahmenwerkklassen 2224 stellen einen Mechanismus zur Verfügung, um mit diesen oben genannten Objekten zu interagieren, was eine Referenzimplementation eines Standardinterfaces zur Verfügung stellt. Beispielsweise stellt der Standortcontroller 2240 der Ausführungsform ein funktionales Prüfobjekt zur Verfügung. Die Systemcontroller-Rahmenwerkklassen können einen entsprechenden funktionalen Prüfproxy als ein controllerbasiertes Ersatz-Remotesystem des funktionalen Prüfobjekts zur Verfügung stellen. Das funktionale Standardprüfinterface wird den Werkzeugen demgemäß auf dem Systemcontroller 2200 zur Verfügung gestellt. Das System, die Modulentwicklung und die Interfacekomponenten 294, 296 und 290 können jeweils als ein Betriebssystem, welches zwischen dem Systemcontroller und den Standortcontrollern verteilt ist, angesehen werden. Die Rahmenwerkklassen stellen effizient ein Betriebssysteminterface, welches dem Hostsystemcontroller zugeordnet ist, zur Verfügung. Sie bilden auch die Softwareelemente aus, welche die Schnittstelle zu den Standortcontrollern zur Verfügung stellen und stellen eine Synchronisation der Standortcontroller in einer Vielfach-Standort/DUT-Umgebung zur Verfügung. Diese Schicht stellt demgemäß ein Objektmodell in einer Ausführungsform der Erfindung zur Verfügung, welches geeignet ist zum Manipulieren von und zum Zugriff auf Standortcontroller, ohne dass eine unmittelbare Befassung mit den Kommunikationsschichten notwendig ist.
  • Der Standortcontroller 2240, welcher auf den Standortcontrollern 130, welche in 1 illustriert sind, softwarebetrieben ist, beinhaltet einen Benutzerprüfplan 2242, Benutzerprüfklassen 2243, Standardprüfklassen 2244, Standardinterfaces 2245, Standortcontroller-Rahmenwerkklassen 2246, Modul-Hochpegelbefehlsinterfaces (d.h. vorbestimmte Modul-Pegelinterfaces) 2247, Modul-Befehlsimplementationen 2248, Backplane-Kommunikationsbibliotheken 2249 und einen Backplane-Treiber 2250. Vorzugsweise wird der größte Anteil der Prüffunktionalität durch die Standortcontroller 2104/2240 gehandhabt, was eine unabhängige Ar beitsweise der Prüfstandorte 2110 erlaubt.
  • Ein Prüfplan 2242 wird von dem Benutzer geschrieben. Der Plan kann unmittelbar in einer Standardcomputersprache, wie beispielsweise C++, geschrieben werden, oder in einer Prüfprogrammsprache eines höheren Niveaus, um einen C++ Code zu produzieren, welcher dann in das ausführbare Prüfprogramm kompiliert werden kann.
  • Der Prüfplan erzeugt Prüfobjekte unter Verwendung der Rahmenwerkklassen 2246 und/oder von Standard-Prüfklassen oder von Benutzern zur Verfügung gestellten Prüfklassen 2244, welche den Standortcontrollern zugeordnet sind, konfiguriert die Hardware unter Verwendung der Standardinterfaces 2245 und definiert den Prüfplanablauf. Er stellt auch jede zusätzliche Logik, welche während der Ausführung des Prüfplans benötigt wird, zur Verfügung. Der Prüfplan unterstützt einige Basisservices und stellt ein Interface für die Services von darunterliegenden Objekten, wie beispielsweise Fehlersuchservices (beispielsweise Unterbrechungspunkt-Setzen) und den Zugriff auf darunterliegende Rahmenwerk- und Standardklassen zur Verfügung.
  • Die den Standortcontrollern zugeordneten Rahmenwerkklassen 2246 sind eine Menge von Klassen und Methoden, welche gewöhnliche prüfungsbezogene Operationen implementieren. Das Standortcontroller-Pegelrahmenwerk beinhaltet beispielsweise Klassen zur Energieversorgung und Anschlusselektronik-Ablaufsteuerung, zum Setzen von Pegel- und Zeitpunktbedingungen, zum Erhalten von Messungen und zum Kontrollieren des Prüfflusses. Das Rahmenwerk stellt auch Methoden zur Verfügung für Laufzeit-Services und zur Fehlersuche.
  • Die Rahmenwerkobjekte können durch Implementierung der Standardinterfaces arbeiten. Beispielsweise ist die Implementierung der Prüferanschluss-Rahmenwerkklasse darin standardisiert, dass ein allgemeines Prüferanschluss-Interface, welches Prüfklassen zur Interaktion mit Hardware-Modulanschlüssen verwenden können, implementiert wird.
  • Bestimmte Rahmenwerkobjekte können so implementiert werden, dass sie unter Zuhilfenahme der Modulpegel-Interfaces 2247 arbeiten, um mit den Modulen zu kommunizieren. Die Standortcontroller-Rahmenwerkklassen handeln gewissermaßen als lokales Betriebssystem-Interface, welches jeden Standortcontroller unterstützt.
  • Üblicherweise sind mehr als 90% des Programmcodes Daten für den Gerätetest und die übrigen 10% des Codes realisieren die prüftechnischen Gesichtspunkte. Die Geräteprüfdaten sind DUT-abhängig (beispielsweise Energieversorgungsbedingungen, Signalspannungsbedingungen, Zeitpunktbedingungen usw.). Der Prüfcode besteht aus Methoden, um die spezifizierten Gerätebedingungen auf die ATE-Hardware zu laden und auch diejenigen, welche notwendig sind, um benutzerspezifizierte Aufgaben zu realisieren (wie beispielsweise die Datenprotokollierung). Das Rahmenwerk einer Ausführungsform der Erfindung stellt eine hardwareunabhängige Prüfung und hardwareunabhängige Prüferobjektmodelle zur Verfügung, was dem Benutzer erlaubt, die Aufgabe der DUT-Prüfprogrammierung durchzuführen.
  • Um die Wiederverwendbarkeit von Prüfcode zu erhöhen, kann solcher Code unabhängig von jeglichen gerätespezifischen Daten (beispielsweise Anschlussname, Anregungsdaten usw.) oder geräteprüfspezifischen Daten (beispielsweise Bedingungen für Gleichstromeinheiten, Messanschlüsse, Anzahl von Zielanschlüssen, Namen von Musterdateien, Adressen von Musterprogrammen) gemacht werden. Wenn Code für eine Prüfung mit Daten dieser Typen kompiliert würde, würde die Wiederverwendbarkeit des Prüfcodes abnehmen. Demgemäß können gemäß einer Ausführungsform der Erfindung jegliche gerätespezifische Daten oder geräteprüfspezifischen Daten dem Prüfcode als Eingaben während der Ausführungszeit des Codes extern zur Verfügung gestellt werden.
  • In einer Ausführungsform der Erfindung realisiert eine Prüfklasse, welche eine Implementierung eines Standardprüfinterfaces ist, welche hier als ITest bezeichnet ist, die Trennung von Prüfdaten und Code (und somit die Wiederverwendbarkeit von Code) für einen bestimmten Typ von Prüfung. Eine solche Prüfklasse kann als eine „Schablone" für getrennte Instanzen von sich selbst angesehen werden, welche sich untereinander lediglich auf Basis der gerätespezifischen und/oder geräteprüfspezifischen Daten unterscheiden. Prüfklassen werden in der Prüfplandatei spezifiziert. Jede Prüfklasse implementiert typischerweise eine spezifische Art einer Geräteprüfung oder eines Setups zur Geräteprüfung. Beispielsweise kann eine Ausführungsform der Erfindung eine spezifische Implementierung des ITest-Interfaces, beispielsweise Functional-Test, als die Basisklasse für alle funktionalen Prüfungen der DUTs zur Verfügung stellen. Sie stellt die Basisfunktionalität des Setzens von Prüfbedingungen, Ausführungsmustern und des Bestimmens des Zustands der Prüfung basierend auf dem Vorhandensein von verfehlten, regelmäßig wiederholten Abtastpulsen zur Verfügung. Andere Arten von Implementierungen können AC- und DC-Prüfklassen beinhalten, welche hier als ACParametricTests und DCParametricTests bezeichnet werden.
  • Alle Arten von Prüfungen können Standardeinstellungs-Implentationen von einigen virtuellen Methoden (beispielsweise init(), preExec() und postExec()) zur Verfügung stellen. Diese Methoden werden die Eintrittspunkte für den Prüfingenieur zum Überschreiben des standardmäßigen Verhaltens und zum Setzen von jeglichen prüfspezifischen Parametern. Jedoch können auch gewöhnliche Prüfklassen in Prüfplänen verwendet werden.
  • Prüfklassen erlauben dem Benutzer, das Klassenverhalten zu konfigurieren, indem Parameter zur Verfügung gestellt werden, welche verwendet werden zum Spezifizieren der Optionen für eine bestimmte Instanz dieser Prüfung. Beispielsweise kann eine funktionale Prüfung Parameter PList und TestConditions verwenden, um die auszuführende Musterliste und die Pegel- und Zeitpunktbedingungen für die Prüfung jeweils zu spezifizieren. Ein Spezifizieren unterschiedlicher Werte für diese Parameter (durch die Verwendung von verschiedenen „Prüfungs"-Blöcken in einer Prüfungsplan-Beschreibungsdatei) erlaubt es dem Benutzer, verschiedene Instanzen einer funktionalen Prüfung zu erzeugen. 4 illustriert, wie verschiedene Prüfungsinstanzen von einer einzelnen Prüfungsklasse abgeleitet werden können. Eine Schablonenbibliothek kann als die Bibliothek für allgemeine Zwecke von generischen Algorithmen und Datenstrukturen eingesetzt werden. Diese Bibliothek kann für einen Benutzer des Prüfers sichtbar sein, so dass der Benutzer beispielsweise die Implementierung einer Prüfungsklasse modifizieren kann, um eine benutzerdefinierte Prüfungsklasse zu erzeugen.
  • Was die benutzerentwickelten Prüfungsklassen betrifft, unterstützt eine Ausführungsform des Systems die Integration von solchen Prüfungsklassen in das Rahmenwerk dadurch, dass alle Prüfungsklassen sich von einem einzelnen Prüfungsinterface, beispielsweise ITest, ableiten, so dass das Rahmenwerk sie auf dieselbe Art und Weise wie die Standardmenge von Systemprüfungsklassen manipulieren kann. Es steht den Benutzern frei, zusätzliche Funktionalitäten in ihre Prüfungsklassen aufzunehmen, mit dem Verständnis, dass sie gemeinsamen Code in ihren Prüfungsprogrammen zu verwenden haben, um den Vorteil von diesen zusätzlichen Einrichtungen zu erhalten.
  • Jeder den Standortcontroller 130, das synchrone Modul 150, das synchrone Verbindungsmodul 160 und das Prüfmodul 170 enthaltende Prüfungsstandort 2110 ist für die Prüfung eines oder mehrerer DUTs 100 reserviert und arbeitet durch eine konfigurierbare Sammlung von Prüfungsmodulen wie beispielsweise das Prüfungsmodul 170. Jedes Prüfungsmodul ist eine Einheit, welche eine bestimmte Prüfungsaufgabe erfüllt. Beispielsweise könnte ein Prüfungsmodul eine DUT-Energieversorgung, eine Anschlusskarte, eine analoge Karte usw. sein. Dieser modulare Ansatz stellt einen hohen Grad an Flexibilität und Konfigurierbarkeit zur Verfügung.
  • Die Modulbefehls-Implementationsklassen 2248 können von Modulhardware-Anbietern zur Verfügung gestellt werden und implementieren entweder die Modulpegel-Interfaces für Hardwaremodule oder stellen modulspezifische Implementationen von Standardinterfaces zur Verfügung, abhängig von der von dem Anbieter ausgewählten Befehlsimplementation. Die externen Interfaces von diesen Klassen sind über vorab bestimmte Modulpegel-Interfaceanforderungen und Backplane- Kommunikationsbibliotheksanforderungen definiert. Diese Schicht stellt auch Erweiterungen der Standardmenge von Prüfbefehlen zur Verfügung, was die Hinzufügung von Methoden (Funktionen) und Datenelementen erlaubt.
  • Die Backplane-Kommunikationsbibliothek 2249 stellt das Interface für Standardkommunikationen über die Backplane zur Verfügung und liefert hierdurch die Funktionen, welche zur Kommunikation mit den Modulen, welche mit dem Prüfungsstandort verbunden sind, notwendig sind. Dies erlaubt einer anbieterspezifischen Modulsoftware, einen Backplane-Treiber 2250 zu verwenden, um mit den entsprechenden Hardwaremodulen zu kommunizieren. Die Backplane-Kommunikationsprotokolle können ein paketbasiertes Format verwenden.
  • Prüfungsanschlussobjekte repräsentieren physikalische Prüfungskanäle und leiten sich von einem Prüfungsanschluss-Interface, hier als ITesterPin bezeichnet, ab. Der Softwareentwicklerbausatz (SDK von englisch Software Development Kit) einer Ausführungsform der Erfindung stellt eine Standardimplementation von ITesterPin zur Verfügung, was als TesterPin bezeichnet werden kann und was vermittels eines vorbestimmten Modulpegel-Interfaces IChannel implementiert ist. Anbieter haben die Freiheit, TesterPin zu verwenden, wenn sie die Funktionalität ihrer Module vermittels IChannel implementieren können; anderenfalls müssen sie eine Implementation von ITesterPin zur Verfügung stellen, um mit ihren Modulen zu arbeiten.
  • Das Standardmodulinterface, hier als IModule bezeichnet, welches von dem Prüfersystem der Ausführungsform zur Verfügung gestellt wird, repräsentiert allgemein ein Hardwaremodul eines Anbieters. Von einem Anbieter zur Verfügung gestellte, modulspezifische Software für das System kann in Form von ausführbaren Dateien, wie beispielsweise dynamischen Verbindungsbibliotheken (DLLs von englisch Dynamic Link Libraries) zur Verfügung gestellt werden. Software für jeden Modultyp eines Anbieters kann in einer einzelnen DLL gekapselt werden. Jedes solche Softwaremodul ist verantwortlich für das Zurverfügungstellen von anbieterspezifischen Implementationen für die Modulinterface-Befehle, welche die API zur Modulsoftwareentwicklung umfassen.
  • Es existieren zwei Aspekte der Modulinterface-Befehle: Als Erstes dienen sie als das Interface für Benutzer, um (indirekt) mit einem bestimmten Hardwaremodul in dem System zu kommunizieren, und als Zweites stellen sie die Interfaces zur Verfügung, welche Entwickler einer dritten Partei vorteilhafterweise nutzen können, um ihre eigenen Module in das Standortcontroller-Pegelrahmenwerk zu integrieren. Demgemäß sind die von dem Rahmenwerk zur Verfügung gestellten Modulinterfacebefehle in zwei Typen eingeteilt:
    Die ersten und offensichtlichsten sind diejenigen „Befehle", welche für den Benutzer durch die Rahmenwerk-Interfaces freigelegt werden. Somit stellt ein Prüfer-Anschlussinterface (ITesterPin) Methoden zur Verfügung, um Pegel- und Zeitpunktwerte zu erhalten und zu setzen, während ein Energieversorgungsinterface (IPowerSupply) beispielsweise Methoden zum Hochfahren und zum Herunterfahren zur Verfügung stellt.
  • Darüber hinaus stellt das Rahmenwerk die spezielle Kategorie der vorbestimmten Modulpegel-Interfaces zur Verfügung, welche verwendet werden kann, um mit den Modulen zu kommunizieren. Dies sind die Interfaces, welche von Rahmenwerkklassen (beispielsweise „Standard"-Implementationen von Rahmenwerkinterfaces) verwendet werden, um mit Anbietermodulen zu kommunizieren.
  • Die Verwendung des zweiten Aspektes, der Modulpegel-Interfaces, ist jedoch optional. Der Vorteil, dies zu tun, liegt darin, dass Anbieter dann die Vorteile der Implementationen von Klassen wie beispielsweise ITesterPin und IPowerSupply usw. nutzen können, während sie auf den Inhalt von spezifischen, an ihre Hardware gesendeten Mitteilungen fokussieren können, indem sie die Modulpegel-Interfaces implementieren. Wenn diese Interfaces ungeeignet für den Anbieter sind, kann er jedoch wählen, seine maßgeschneiderten Implementationen der Rahmenwerk-Interfaces zur Verfügung zu stellen (beispielsweise Anbieterimplementationen von ITesterPin, IPowerSupply usw.). Dies würde dann die maßgeschneiderte Funktionalität bieten, welche für seine Hardware geeignet ist.
  • Die Integration von modulspezifischer Anbietersoftware kann demgemäß durch zwei unterschiedliche Maßnahmen erreicht werden: maßgeschneiderte Implementationen von relevanten Rahmenwerkklassen und Interfaces oder maßgeschneiderte Implementationen von der Spezialkategorie von Modulpegel-Interfaces.
  • Eine Beispielanwendung beider Methoden wird nachstehend mithilfe von 10 präsentiert, welche ein universelles Modellsprachklassendiagramm (UML-Klassendiagramm von englisch Universal Modelling Language) darstellt, welches die Interaktion des Prüfersystems einer Ausführungsform der Erfindung mit von Anbietern zur Verfügung gestellten Modulen herausstellt.
  • Ein Anbieter eines neuen Digitalmoduls, eine dritte Partei A (TPA von englisch Third Party A), stellt ein Softwaremodul zur Verfügung, um mit seinen Hardwaremodulen zu kommunizieren. Dieses Softwaremodul wird das Standardinterface, IModule, implementieren. Es wird angenommen, dass dieses Modulobjekt mit TPAPinModule bezeichnet wird. Der Anbieter TPA kann die Standardsystemimplementation des ITesterPin-Interfaces verwenden, welches hier als TesterPin bezeichnet wird, indem das relevante vorbestimmte Modulpegel-Interface – in diesem Fall IChannel – in seinem Modul implementiert wird. Dies wird durch die Tatsache ermöglicht, dass TesterPin vorbestimmte Standardmodul-Pegelinterfaces, wie beispielsweise IChannel, verwendet, um mit Modulen zu kommunizieren. Demgemäß stellt TPAPinModule Anschlüsse zur Verfügung, indem einfach TesterPin-Objekte erzeugt und offen gelegt werden.
  • Nun wird ein unterschiedlicher Anbieter, eine dritte Partei B (TPB) angenommen, welche entscheidet, dass das IChannel-Interface nicht gut mit ihrer Hardware arbeitet. Demgemäß muss TPB nicht nur ihre eigene IModule-Implementation (TPBPinModule) zur Verfügung stellen, sondern auch eine Implementation des I-TesterPin-Interfaces, TPBTesterPin.
  • Dieser Ansatz ermöglicht Entwicklern einer dritten Partei eine erhebliche Flexibilität in der Auswahl darin, wie ihre Hardware und Unterstützungssoftware zu entwickeln ist. Während es für sie notwendig ist, das IModule-Interface zu implementieren, können sie die Implementation von Modulpegel-Interfaces oder von Objekten wie TesterPins so auswählen, wie sie es für passend halten.
  • Tatsächlich können Anbieter auswählen, TesterPins zu implementieren, um Erweiterungen zur Verfügung zu stellen, welche nicht durch das ITesterPin-Interface unterstützt werden. Das Rahmenwerk wird Benutzern einen Mechanismus zur Verfügung stellen, um ein spezifisches Interface oder einen spezifischen Implementationszeiger auf ein Objekt wiederzufinden. Das bedeutet, dass, wenn Benutzercode einen ITesterPin-Zeiger aufweist, das Rahmenwerk fähig ist zu bestimmen, ob er z.B. auf ein TPBTesterPin-Objekt zeigt, wenn das notwendig ist. (Dabei ist zu beachten, dass diese Eigenschaft über die Standard-C++-Laufzeittypidentifikation (RTTI von englisch Run Time Type Identification) zur Verfügung gestellt werden kann.) Mit anderen Worten kann das Interface, wenn der Prüfplan das ITesterPin-Interface aufruft, unmittelbar die Prüferanschlussimplementation des Anbieters der TesterPin-Klasse aufrufen, welche modulspezifische Informationen beinhaltet (beispielsweise Adressen von Registern, welche zu setzen sind, um einen bestimmten DUT-Anreiz zur Verfügung zu stellen).
  • Zusammenfassend sind die Benutzer frei in ihrer Entscheidung, spezifische Eigenschaften und Erweiterungen, welche von Modulanbietern wie benötigt zur Verfügung gestellt werden, zu nutzen, während der Rahmenwerk-Code immer das ITesterPin-Interface verwenden wird. Mit anderen Worten kann ein Modulanbieter beispielsweise Methoden (Funktionen) zu der Standardsystem-Implementation der Klasse hinzufügen. Der Kompromiss für den Anwender ist, dass das Nutzen der Vorteile von spezifischen Anbietererweiterungen den Prüfcode weniger verwendbar mit den Modulen anderer Anbieter macht.
  • Auf der modularen Ebene besitzt die Prüfvorrichtung 10 nominell zwei Arbeitsmodi. In einem Online-Operationsmodus werden Modulelemente 2260 (beispielsweise Hardwareelemente), welche den Busschalter 140, das synchrone Modul 150, das synchrone Verbindungsmodul 160, das Prüfmodul 170, die Loadplatine 180 und die DUT 100 beinhalten, verwendet, und in einem Offline-Operationsmodus wird Modulemulationssoftware 2280, welche den Busschalter-Emulationsabschnitt 240, den synchronen Modulemulationsabschnitt 250, den synchronen Verbindungsmodulemulationsabschnitt 260, den Prüfmodul-Emulationsabschnitt 270, den Ablaufsteuerabschnitt 275, den DUT-Verbindungsabschnitt 280 und den DUT-Simulationsabschnitt 200 beinhaltet, verwendet.
  • Für den Online-Operationsmodus beinhaltet das Modulelement 2260 die HW(Hardware)-Backplane 2261, welche den in 1 illustrierten Busschalter 140 beinhaltet, das Chassis-Schacht-IF (Interface) 2262, die Modulhardware 2263, welche das synchrone Modul 150 beinhaltet, das synchrone Verbindungsmodul 160, das Prüfmodul 170 und Ähnliches, das Loadboard-Hardware-IF 2264, das Hardware-Loadboard 2265, welches dem Loadboard 180 entspricht, und die DUT 2266, welche der DUT 100, welche in 10 gezeigt ist, entspricht.
  • Für den Offline-Operationsmodus beinhaltet die in Software ausgeführte Modulemulation 2280 ein Simulations-Rahmenwerk 2281, welches den Ablaufsteuerabschnitt 275, welcher in 2 illustriert ist, beinhaltet, die Backplane-Emulation 2282, welche den Busschalter-Emulationsabschnitt 240 beinhaltet, das Backplane-Simulation-IF 2283, die Modulemulation 2284, welche den synchronen Modulemulationsabschnitt 250 beinhaltet, den synchronen Verbindungsmodul-Emulationsabschnitt 260, den Prüfmodul-Emulationsabschnitt 270 und Ähnliches, das Loadboard-Simulations-IF 2285, die Loadboard-Simulation 2286, welche den DUT-Verbindungsabschnitt 280 beinhaltet, und das DUT-Simulations-IF 2287. Zwei Modelle werden für die DUT-Simulation gezeigt. Ein Verilog verwendendes Modell beinhaltet die Verilog-PLI (Programmierspracheninterface von englisch Programming Language Interface) 2288 und ein DUT-Verilogmodell 2293. Ein C/C++ verwendendes Modell beinhaltet eine C/C++-Sprachunterstützung 2289 und ein DUT-C/C++-Modell 2291. Hierbei ist zu beachten, dass die Simulation auf jedem Computer, beispielsweise einem PC, durchgeführt werden kann.
  • Im Online-Modus stellen die Modulanbieter physikalische Hardwarekomponenten zur Unterstützung der Prüfung, wie beispielsweise digitale Prüferkanäle, DUT-Energieversorgungen oder DC-Messeinheiten zur Verfügung. Die Module koppeln an die HW-Backplane 2261 durch den Chassisschacht 2262.
  • Für die Offline-Arbeitsweise würde zusätzlich eine PC-basierte oder andere Umgebung, auf welcher das Äquivalent des Systemcontrollers läuft, all die Verantwortung übernehmen, das Standardortcontroller-Pegelrahmenwerk und die Laufzeit-Umgebung für die tieferen Schichten der Software zur Verfügung zu stellen, ebenso wie die Hardware zu emulieren.
  • Die Backplane-Emulation 2282 stellt einen Softwareersatz für die physikalische Backplane 2261 zur Verfügung. Diese kommuniziert mit der (vom Anwender zur Verfügung gestellten) Modulemulationssoftware 2284 durch das Backplane-Simulationsinterface 2283.
  • Die Modulemulationssoftware 2284 wird vorzugsweise durch den Modulanbieter zur Verfügung gestellt und ist typischerweise eng mit einer bestimmten Anbieterimplementation eines Moduls 2263 verbunden. Demgemäß wird die Modulemulationssoftware typischerweise in den Details über Module, welche von unterschiedlichen Anbietern zur Verfügung gestellt werden, variieren. In diesem Fall erlaubt die Modulsimulation dem Anbieter, Hardwarefunktionalitäten durch ein Softwaremodell darzulegen (beispielsweise die Modulemulationssoftware 2284), Stimulationssignale an das simulierte Loadboard 2286 zu senden und DUT-Antwortsignale von dem simulierten Loadboard 2286 zu empfangen und zu verarbeiten, wobei das simulierte Loadboard 2286 mit der DUT-Modellierungssoftware 2291, 2293 durch das DUT-Simulations-IF 2287 verbunden ist. In manchen Fällen mögen es Anbieter als vorteilhaft empfinden, eine einfache, funktionale Simulation des Moduls und eine Umgehungsemulation der Modul-Firmware zur Verfügung zu stellen. Die Modulemulationssoftware vergleicht die Antwort der simulierten DUT auf die simulierten Modulstimulationssignale mit einer bekannten, guten DUT-Antwort. Basierend auf diesem Vergleich bestimmt die Software, ob die Prüfung, welche durch das Modul ausgeführt wird, ihr Ziel der Prüfung der DUT wie gewünscht erreicht und hilft dem Anwender, das Modul auszutesten, bevor es auf einem IC (physikalische DUT) auf dem physikalischen Onlineprüfer verwendet wird.
  • Das Loadboard-Simulationsinterface 2285 dient als die Leitung für Signale zu und von der Modulemulationsschicht und dem simulierten Loadboard 2286. Die Load board-Simulationskomponente 2286 unterstützt die Gerätesockelabbildung und die Signalfortpflanzung zu und von dem DUT-Simulations-IF 2287.
  • Die DUT-Simulation kann eine Simulation 2291 in nativem Code (d. h. C/C++) sein oder ein Verilog-Programmspracheninterface (PLI) zu einem funktionalen Modell des Zielgerätes 2293, welches zu testen ist. Das Modell koppelt mit dem simulierten Loadboard durch das DUT-Simulationsinterface 2287.
  • Es ist zu beachten, dass die Gesamtsteuerung dieser Schichten durch das Simulationsrahmenwerk 2281 zur Verfügung gestellt wird. Das Simulationsrahmenwerk misst die simulierte DUT-Antwort auf bekannte Stimulationssignale. Das Verfahren der Systememulation ist in der US-Anmeldung Nr. 10/403,817 offenbart.
  • Kommunikation und Steuerung
  • Die Kommunikation und die Steuerung werden durch das Management von zugehörigen Softwareobjekten ausgeführt. Vorzugsweise ist ein Kommunikationsmechanismus hinter einem Objektmodell auf dem Systemcontroller versteckt. Dieses Objektmodell stellt den Klassen und den auf dem Standortcontroller gefundenen Objekten einen Proxy zur Verfügung und stellt hierdurch ein komfortables Programmiermodell zur Applikationsentwicklung (beispielsweise zum IC-Gerätetesten) zur Verfügung. Dies erlaubt Anwendungsentwicklern (beispielsweise Verwendern des ATE-Systems) unnötige Details, welche mit den Besonderheiten der Kommunikationen zwischen der Anwendung und den Standort-/System-Controllern verbunden sind, zu vermeiden.
  • 11 illustriert eine spezifische Ausführungsform eines Standortcontroller-Objektes, wie es in der Standortcontroller-Software 2240 des Standortcontrollers 130 gehalten wird. Das Standortcontroller-Objekt beinhaltet CmdDispatcher 2602, FunctionalTestMsgHandler 2604 und FunctionalTest 2606. Die Interfaces beinhalten IMsgHandler 2608 und ITest 2610.
  • Die Standortcontrollersoftware 2240 beinhaltet vorzugsweise alle der funktionellen Klassen, welche eine Anwendung zum Zugriff benötigen könnte. Diese Klassen können beispielsweise Prüfungen, Module, Anschlüsse usw. beinhalten. Da die Prüfungen der Anwender und Softwarewerkzeuge typischerweise auf verschiedenen Computern angeordnet sind, werden Mitteilungen von den Werkzeugen auf dem Systemcontroller an einen Server auf dem Standortcontroller gesendet. Dieser Server wird eine Methode auf einem Befehlsausführungsobjekt aufrufen.
  • Das Befehlsausführungsobjekt (CmdDispatcher) 2602 hält eine Karte von Mitteilungshandhaberobjekten, welche das IMsgHandler-Interface 2608 implementieren. 11 illustriert eine spezifische Implementation von IMsgHandler, FunctionalTestMsgHandler 2604. Mitteilungen, welche durch das CmdDispatcher-Objekt 2602 empfangen wurden, beinhalten einen Identifizierer eines Objektes, mit dem kommuniziert wird. Dieser Identifizierer wird in einer internen Karte gefunden, welche sich in die spezifische Implementation, in diesem Fall das gezeigte FunctionalTestMsgHandler-Objekt 2604, löst.
  • In diesem Fall besteht IMsgHandler 2608 aus einer einzelnen Methode, handleMessage(). Diese Methode wird vorzugsweise als eine einzelne Implementati onsklasse implementiert. In dem gezeigten Fall wird der FunctionalTestMsgHandler 2604 die Mitteilung auf ein bis sechs Methoden, abhängig von der genauen Natur der empfangenen Mitteilung, weiterleiten. Der Kopf der empfangenen Mitteilung beinhaltet eine Mitteilungsid, welche es dem Mitteilungshandhaber erlaubt zu entscheiden, wie die Mitteilung zu interpretieren und wohin sie weiterzuleiten ist.
  • Die entsprechende Kommunikationsumgebung bei dem Systemcontroller 110 bezieht sich auf die Werkzeugabschnitte 2225, 2226 der Systemcontrollersoftware 2220. 12 illustriert eine Ausführungsform eines Werkzeugobjektes (oder eines Systemcontrollerobjektes), welches auf dem Systemcontroller 110 in der Systemcontrollersoftware 2220 in Übereinstimmung mit dem in 11 gezeigten Standortcontrollerobjekt gehalten wird. Das Werkzeugobjekt beinhaltet ein Objekt CmdDispatcher 2702, FunctionalTestMsgHandler 2704 und FunctionalTestProxy 2706. Interfaces beinhalten IMsgHandler 2708, ITestClient 2710 und I-Dispatch 2712. Auch enthalten ist eine Dienstprogrammanwendung 2714.
  • Für dieses Beispiel sind die Klassen CmdDispatcher 2702, IMsgHandler 2708 und FunctionalTestMsgHandler 2704 dieselben wie in 11. Jedoch werden keine Instantiierungen von FunctionalTest 2606 (oder jeglicher anderen Standortcontrollerklasse) verwendet. Anstelle dessen weist das Werkzeugobjekt Proxyklassen zur Kommunikation mit jedem Objekt auf dem Standortcontroller 130 auf. Demgemäß beinhaltet beispielsweise das Werkzeugobjekt die Klasse FunctionalTestProxy 2706 anstelle des FunctionalTest 2606. Gleichermaßen ist ITestClient 2710 in dem Werkzeugobjekt nicht dasselbe wie ITest 2610 in dem Standortcontrollerobjekt.
  • Im Allgemeinen werden Anwendungen, welche auf dem Standortcontroller 130 laufen, nicht die genauen Interfaces, wie sie auf dem Standortcontroller 130 zur Verfügung gestellt werden, verwenden. In diesem Fall werden die drei Methoden von ITest 2610 (nämlich preExec(), execute() und postExec()) durch eine einzelne Methode in ITestClient 2710 ersetzt (nämlich runTest()). Darüber hinaus ist ITestClient 2710 vorzugsweise ein duales Interface; das heißt, es erbt von IDispatch 2712, welches als ein Microsoft-Komponentenobjektmodell (COM von englisch Component Objekt Model) implementiert ist. Es stellt ein Interface zur Verfügung, welches es einem Scripting-Engine ermöglicht, auf das Objekt, welches dieses Interface implementiert, zuzugreifen. Dies erlaubt dem System, auf der Microsoft Windows-Plattform als ein Skript ausgebildet zu werden.
  • Als ein Beispiel für die Arbeitsweise der in 11 bis 12 gezeigten Ausführungsformen kann eine Anwendung, welche auf dem Systemcontroller 110 läuft (beispielsweise in einer der Werkzeugabschnitte 2226, 2228) mit einem Standortcontroller 130 kommunizieren, wobei ein Prüfplan 2242 ein oder mehrere FunctionalTest-Objekte 2606 beinhaltet. Während der Initialisierung des Prüfplanes 2242 auf dem Standortcontroller 130 wird ein zugehöriges Prüfplanobjekt auf den Standortcontroller 130 geladen, welches ein TestPlanMessageHandler-Objekt konstruiert und es mit dem CmdDispatcher-Objekt 2602 registriert. Dies weist dem Mitteilungshandhaber eine eindeutige ID zu. Ähnliche Arbeitsweisen treten mit anderen TestPlan-Objekten, welche den Testplan 2242 ausmachen, auf.
  • Die Anwendung (beispielsweise in den Werkzeugen 2226, 2228) auf dem Systemcontroller 110 initialisiert die Kommunikationsbibliothek 2230, verbindet sich mit dem Standortcontroller 130 über einen Kommunikationskanal und erhält eine ID für das TestPlan-Objekt. Die Bibliothek konstruiert ein TestPlanProxy-Objekt und initialisiert es mit dieser ID. Während der Initialisierung bestimmt dieses Proxy-Objekt, wie viele Prüfungen es enthält, und ihre Typen und IDs. Es lädt die geeigneten DLLs für jeden Typ (in diesem Fall lediglich einen Typ) und konstruiert die Proxy-Objekte für sie, indem es sie mit ihren ID-Werten initialisiert.
  • Die TestProxy-Objekte initialisieren sich wiederum ebenso. Um dies auszuführen, konstruieren sie geeignete Mitteilungen, um ihre Namen zu bekommen (indem sie ihre ID-Werte verwenden) und senden sie an einen Kommunikationsserver auf dem Standortcontroller 130, welcher die Mitteilung an den CmdDispatcher 2602 weiterleitet. Dieses Objekt schaut nach den Bestimmungs-IDs in seiner internen Karte und leitet die Mitteilung weiter an die handleMessage()-Methoden des FunctionalTestMsgHandler-Objekts 604. Beispielsweise erhalten diese Objekte ihre jeweiligen Namen der Prüfungen und antworten auf die TestProxy-Objekte der Anwendung mit den geeigneten Namens-Zeichenfolgen, wenn die Mitteilung eine Anforderung war, Prüfungsnamen zu erhalten.
  • Nachdem die Initialisierung beendet worden ist, hat die Anwendung einen Fernzugriff auf ein Testplan-Objekt und, durch es, beide Testobjekte. Der Anwender kann nun beispielsweise einen „Run Test Plan"-Knopf auf der Anwendung drücken. Als ein Ergebnis ruft die Anwendung die RunTestPlan()-Methode auf dem TestPlanProxy-Objekt auf. Diese Methode konstruiert eine RunTestPlan-Mitteilung mit der Ziel-ID des TestPlan-Objekts und ruft die sendMessage()-Funktion auf dem RPC-Proxy auf, welche die Mitteilung an den Standortcontroller sendet.
  • Der Kommunikationsserver auf dem Standortcontroller 104 ruft die handleMessage()-Methode auf dem CmdDispatcher-Objekt 2602 auf, indem er ihr die ID des TestPlan-Objekts weiterleitet. Das CmdDispatcher-Objekt 2602 schaut nach dieser ID in seiner internen Karte, findet den Mitteilungshandhaber für das TestPlan-Objekt und ruft die handleMessage()-Methode auf diesem Objekt auf, welche wiederum die RunTestPlan()-Methode auf dem TestPlan-Objekt aufruft. Auf eine ähnliche Art und Weise kann die Anwendung die Namen und die letzten Laufzustände der Prüfobjekte erhalten.
  • Methode zur Verwendung der Kommunikationsbibliothek
  • Das Folgende ist ein Beispiel für die Verwendung der Kommunikationsbibliothek 2230.
  • Die Kommunikationsbibliothek 2230 ist vorzugsweise eine statische Bibliothek. Eine Anwendung kann diese Kommunikationsbibliothek durch eine CommLibrary.h-Datei verwenden. Eine Applikation, welche den Export der Kommunikationsbibliothekklassen benötigt, sollte die Präprozessordefinitionen COMMLIBRARY_EXPORTS, COMMLIBRARY_FORCE_LINKAGE zusätzlich zur Einbindung der oben genannten Einbindungsdatei definiert haben. Eine Anwendung, welche die Kommunikationsbibliothek importiert, muss keine Präprozesser-Definitionen definieren. Wenn die Kommunikationsbibliothek als Server verwendet wird, muss die Anwendung die folgende statische Funktion von CcmdDispatcher aufrufen: InitializeServerunsigned long portNo().
  • Die portNo ist die portNo, auf welche der Server hören sollte. Der Befehlsausführer, welcher dem Server entspricht, kann wiedergefunden werden, indem die statische Funktion getServerCmdDispatcher auf der CCmdDispatcher-Klasse aufgerufen wird.
  • Wenn die Kommunikationsbibliothek als Client verwendet wird, sollte die Anwendung die statische Funktion „InitializeClientconst(const OFCString serverAddress, unsigned long serverPortNo, CcmdDispatcher **pCmdDispatcher, OFCString serverId)" aufrufen.
  • Die serverAddress und ServerPortNo, zu welcher der Client sich verbinden muss. Diese Funktion initialisiert den Befehlsausführungszeiger für den Client und für serverId, mit welchem er sich verbunden hat. Auch kann zu einem späteren Zeitpunkt der Client den Befehlsausführer entsprechend der serverId wiedergewinnen, indem er die statische Funktion getClientCmdDispatcher aufruft.
  • Wenn die Kommunikationsbibliothek kompiliert wird, ist das Kompilierte auf den Dateien ClientInterface.idl und ServerInterface.idl ausgeschlossen worden. Die bevorzugte Ausführungsform wendet die bereits erzeugten Stub- und Proxy-Dateien für die Interface-Definitionsdateien an, um die Proxy- und Stub-Implementationsdateien in dieselbe Bibliothek einzulinken. Demgemäß können der Server und der Client in demselben Adressraum instantiiert werden. Die folgenden Änderungen in den Interface-Definitionsdateien und den Stub-Dateien werden vorzugsweise gemacht, um die Kommunikationsbibliothek als Server und als Client in demselben Adressraum arbeiten zu lassen.
  • Änderungen in Interface-Definitionsdateien
  • Die folgende Namensraum-Deklaration wird vorzugsweise in jeder der Interface-Definitionsdateien hinzugefügt. Dies dient dazu, die Namenskollision zwischen den Proxy-Implementationsfunktionen und unseren eigenen Implementationen von den Interfacefunktionen zu vermeiden. Die folgende Namensraum-Deklaration wird in der serverInterface.idl hinzugefügt.
  • Die Funktionen in der Stub-Implementationsdatei werden geändert, um unsere eigenen Implementationsfunktionen für die Funktionen, welche in den Interfaces deklariert sind, aufzurufen, d. h. wir haben eine unterschiedlich benannte Funktion entsprechend jeder der Funktionen, welche in den Interfaces deklariert sind.
  • Um den Konflikt beim Funktionsaufruf zu vermeiden, werden vorzugsweise die Implementationsfunktionsnamen mit einer „COMM_"-Zeichenfolge als Präfix versehen. So wird der Code in den Stub-Funktionen geändert, um „COMM functionName" anstelle von „functionName" aufzurufen.
  • Damit diese Methode arbeitet, sollten all die funktionalen Klassen, welche existieren, ebenfalls ihre entsprechenden Mitteilungshandhaberobjekte und Proxy-Klassen aufweisen. Alle Mitteilungshandhaberobjekte sollten von der IMsgHandler-Klasse, welche durch die Kommunikationsbibliothek zur Verfügung gestellt wird, abgeleitet werden. Die IMsgHandler-Klasse ist eine abstrakte Klasse. Vorzugsweise ist es die Verantwortlichkeit desjenigen, der die Mitteilungshandhaber implementiert, eine Definition für die handleMsg, setObjectId, handleError zur Verfügung zu stellen.
  • All die Mitteilungstypen sollten von eins starten (wir reservieren null für handleError). Die funktionalen Klassen haben vorzugsweise ihren entsprechenden Mitteilungshandhaber als ihre Member-Variable. In dem Konstruktor der funktionalen Klasse sollte die funktionale Klasse sich selbst mit dem Mitteilungshandhaber registrieren, indem eine Funktion aufgerufen wird, welche durch ihren Mitteilungshandhaber zur Verfügung gestellt wird. Als Nächstes sollte das Mitteilungshandhaberobjekt mit dem Befehlsausführer registriert werden, indem eine addMsgHandler-Funktion auf dem Befehlsausführer mit dem Befehlshandhaber als dem Parameter aufgerufen wird. Die addMsgHandler-Funktion wird eine ID an den Mitteilungshandhaber und die funktionale Klasse zuweisen. Der Destruktor der funktionalen Klasse sollte die removeMsgHandler-Funktion auf dem Befehlsausführer aufrufen, indem der Funktionsklassenidentifizierer als Parameter gesendet wird. Proxy-Klassen sollten auch derselben Prozedur der Registrierung, wie sie für die funktionalen Klassen erklärt wurde, folgen.
  • Systemkonfigurationen und Prüfung
  • 13 illustriert eine nominale Prüfungssequenz 2800 gemäß einer Ausführungsform der vorliegenden Erfindung. Die Prüfungssequenz 2800 beinhaltet eine Installation 2815 von Modulen in einer Prüfumgebung 804, welche Prüfungsvorbereitungen 2806 und Systemprüfungen 2808 umfasst. Zu Beginn wird ein neues Modul (Hardware oder Software oder eine Kombination davon) 2810 zertifiziert 2812 (durch eine externe Prozedur, möglicherweise basierend auf Anbieter-Qualitätskontrollen). Die Installation 2815 benötigt zunächst Prüfungsvorbereitungen 2806, welche die Installation einer Hardware-Modulemulation zur Offline- Simulation 2809, eine Installation von Modul-Ressourcendateien und von Interfaces für eine Prüfprogrammentwicklung 2814 und eine Installation eines modulspezifischen Mustercompilers für die Kompilierung von Mustern 2816 beinhalten. Als Nächstes wird die Systemprüfung 2808 unter Eingabe von einer Kalibration 2817, von einer Diagnostik 2818 und einer Konfiguration durchgeführt. Dann wird die Systemprüfung 2808 für das neue Modul ausgeführt, wobei sie beinhaltet: (1) Interface-Steuerung, (2) Synchronisation, Sequenzierung und Wiederholbarkeit, (3) Fehler-/Alarm-Handhabung, (4) Vielfachstandort-Steuerung und (5) Vielfachinstrumenten-Modulsteuerung.
  • Ergänzende Information B: ein Beispiel einer Spezifikation eines Rahmenwerkes der Systemsoftware der DUT 100
  • 3.1 Einleitung
  • Diese Spezifikation ist eine Anleitung für einen Anwender und einen Entwickler, welche ein Rahmenwerk der Systemsoftware der DUT 100 beschreibt, welche auf die Emulationsumgebung (Offline-Umgebung) durch das verteilte System des Prüfemulators 190 oder des Systemcontrollers 110 und des Standortcontrollers 130 fokussiert.
  • 3.2 Anleitung für den Anwender
  • Dieses Kapitel ist eine Anleitung für den Anwender, welche das Rahmenwerk der Systemsoftware einer Prüfvorrichtung 10 beschreibt.
  • B.2.1 SimTester
  • „SimTester (simulierte Prüfvorrichtung von englisch simulated test apparatus)" ist ein Anwendungsprogramm, welches den Computer 20 veranlasst, als der in 2 illustrierte Prüfemulator 190 zu handeln. SimTester lädt alle Module und DUT-DLLs und antwortet auf Befehle von der Systemsoftware und emuliert die Prüfvorrichtung, wobei die Systemsoftware Laufzeit-Software ist, um das Musterladen und die Ausführung zu simulieren.
  • Wenn SimTester hochgefahren wird, lädt es die Simulations-Konfigurations-Datei. Dies resultiert im Laden aller Modul-Emulations-DLLs, welche den Prüfemulator 190 veranlassen, der synchrone Modulemulationsabschnitt 250, der synchrone Verbindungsmodul-Emulationsabschnitt 260 und der Prüfmodul-Emulationsabschnitt 270 zu sein. Nach dem Laden der DLLs wartet SimTester auf eine Verbindung von dem Systemcontroller 110. Der Systemcontroller 110 verbindet sich mit SimTester, wenn ein Prüfplan geladen ist. Ein Teil der Information in dem Prüfplan ist der Name der Offline-Konfigurationsdatei. Bevor der Systemcontroller 110 tatsächlich die Prüfplandaten lädt, sendet er die Offline-Konfigurationsdatei an SimTester, so dass es seine Initialisierung beenden kann. Ein erfolgreiches Laden der Offline-Konfigurationsdatei bedeutet, dass SimTester die DUT-Modelle geladen hat und sie als den Testmodul-Emulationsabschnitt 270, als den DUT-Verbindungsabschnitt 280 und den DUT-Simulationsabschnitt 200 an den Modulemulator angehängt hat. Zu diesem Zeitpunkt ist die Simulation bereit zum Laden von Mustern und hiernach zur Ausführung von Mustern.
  • Wenn ein Prüfplan ausgeladen wird, wird SimTester signalisiert, die DUT-Modelle auszuladen und auf eine neue Offline-Konfigurationsdatei zu warten.
  • 3.2.2 Konfigurationsdateien
  • SimTester verwendet zwei Konfigurationsdateien. Die erste ist die Simulations-Konfigurationsdatei. Diese Datei spezifiziert, welche Prüfmodule während der Simulation verfügbar sein werden. Die zweite Datei ist die Offline-Konfigurationsdatei. Diese Datei spezifiziert, welche DUT-Modelle geladen werden und wie sie mit dem Prüfer verbunden werden.
  • 3.2.2.1 Simulations-Konfigurationsdateien
  • 14 und 15 sind Beispiele für eine Simulations-Konfigurationsdatei. Die Datei ist in hierarchische Blöcke aufgebrochen.
  • Der globale Abschnitt 5010 führt ein globales Setzen durch. Der InitVoltage-Parameter entspricht der anfänglichen Spannung auf all den Drähten in der Simulation am Beginn. Nachfolgende Muster beginnen mit dem Zustand, welcher auf dem Draht durch das vorangegangene Muster zurückgelassen wurde.
  • Der RecoveryRate-Parameter ist ein optionaler Parameter, welcher verwendet wird, um zwei analoge Signale, welche gegeneinander treiben, aufzulösen. Genauer gesagt gibt der Parameter eine Spannungsvariation pro vordefinierter Zeiteinheit an, welche verwendet wird, um zu bestimmen, wie lang eine Spannung braucht, um ihren stabilen Zustandspegel zu erreichen, wenn dieser Fall auftritt.
  • Der Modulemulationsabschnitt 5020 spezifiziert die Modul-DLL und richtet die Modul-DLL ein.
  • Der Wellenformabschnitt, welche Typen von Wellenformmodellen für jede Modulressource verwendet werden. Das Wellenformmodell, wie beispielsweise eine Stufenwellenform, eine Flanken-Wellenform, eine analoge Wellenform oder ähnliche, wird für jeden Kanal, welcher sich mit einem Anschluss der DUT verbindet, spezifiziert.
  • Ein Anschlussabschnitt deklariert eine Instanz des Modulemulators, welche den Prüfemulator 190 veranlasst, als der synchrone Modulemulationsabschnitt 250, der synchrone Verbindungsmodul-Emulationsabschnitt 260, der Modulemulationsabschnitt 270 und/oder Ähnliches zu handeln.
  • Der LogicalPort-Parameter wird so zur Verfügung gestellt, dass, wenn ein in einen Kanal eingegebenes Modul zu einem anderen Kanal aufgrund der Fehlerhaftigkeit des Kanals versetzt wird, der LogicalPort-Parameter die Ersetzung bereithält.
  • Der Params-Abschnitt in dem Modulemulationsabschnitt 5020 hält den Parameter, welcher an die Modul-DLL weiterzuleiten ist.
  • 3.2.2.2 Offline-Konfigurationsdatei
  • 16 und 17 sind Beispiele für Offline-Konfigurationsdateien. Der globale Abschnitt 5110 führt eine Gesamt-Einrichtung durch. RegSelect spezifiziert eine Datei, welche das Register auswählt, welches zum Musterverfolgen verfolgt werden soll.
  • Der Wellenform-Parameter richtet ein Wellenformmodell für jeden Anschluss jeder DUT ein. Der DUT-Block beinhaltet hauptsächlich den Params-Block und den PinConnections-Block.
  • Der PinConnections-Block spezifiziert die Verbindung zwischen einer Ressource der Prüfvorrichtung und einem Anschluss der DUT. Beispielsweise zeigt „L3.11 10 1.0ns" an, dass die Ressource 11 von LogicalPort 3 mit dem DUT-Anschluss 10 verbunden ist, mit einer Transportverzögerung von 1.0 ns. Hier ist der LogicalPort ein Anschluss, an dem ein Modul implementiert ist, und die Ressource ist logisch oder Ähnliches, was einem Kanal, welcher in dem Modul zur Verfügung gestellt wird, entspricht, usw.
  • B.3 Anleitung für Entwickler
  • Prüfermodule und DUT-Modelle werden durch das Rahmenwerk des in 5 illustrierten Emulationsprogrammes erzeugt, beispielsweise indem C++-Klassen von einigen Basisklassen abgeleitet werden. Die Ableitung beinhaltet das Implementieren einiger weniger virtueller Funktionen in der Basisklasse. Darüber hinaus stellt das Rahmenwerk einige Klassen zur Verfügung, welche die Eingabe/Ausgabe zwischen Prüfermodulen und DUT-Modellen vereinfachen. Schließlich kann die erhaltene DLL, indem das Rahmenwerk implementiert wird, mit einer anderen Komponente in dem Prüfemulator 190 verbunden werden, um die Emulation laufen zu lassen.
  • B.3.1 Offline-Rahmenwerk-Klassenstruktur
  • 18 ist eine hierarchische Struktur von Klassen 5200, welche die Details der in 5 illustrierten hierarchischen Struktur von Klassen illustriert. Jede Methode in der ThirdPartyModule-Klasse und in den ThirdPartyDUT-Klassen entspricht den virtuellen Methoden, welche implementiert werden müssen, um das Verhalten des Modells zu definieren. Die createDomain-, registerDomain-, releaseDomain-, getDomain-, registerEvent- und raiseEvent-Methoden in der SimComponent-Basisklasse stellen einen Service zum Zugriff auf den Softwaresimulations-Engine der DUT 100 zur Verfügung, welcher den Testemulator 190 veranlasst, als der Ablaufsteuerungsabschnitt 275 oder Ähnliches zu handeln.
  • 19 illustriert ein Diagramm zur Spezifikation des Kanalobjektes, welches als ein Interface in dem Rahmenwerk verwendet wird. Prüfermodule und DUT-Modelle werden ein Array von SimChannel-Objekten beinhalten. Jede Instanz von SimChannel entspricht einem Eingabe/Ausgabe-Kanal für das Modell. Kanäle werden identifiziert, indem SimChanID-Objekte verwendet werden. Die SimChannel-Klasse erlaubt dem Modul oder dem DUT-Modell, die zeitliche Geschichte der Spannung auf die Ausgangskanäle zu schreiben und die Spannungen zu bestimmten Zeitpunkten von Eingabekanälen zu lesen. Wenn es notwendig ist, einen Eingangskanal nach Kanten in einem Zeitfenster abzutasten, kann eine Instanz von SimWaveformIter von der SimChannel::getWaverformIter-Methode erhalten werden. Das SimWaveformIter-Objekt erlaubt der aufrufenden Routine, durch all die Kanten in einem endlichen Zeitfenster zu iterieren.
  • B.3.2 Implementation eines Prüfermoduls
  • In diesem Abschnitt wird die Implementation eines einfachen digitalen Treibermoduls und eines digitalen Moduls für einen regelmäßig wiederholten Abtastimpuls als Beispiel der Modulimplementationsmethode erläutert.
  • 21 zeigt die Basisklasse des einfachen Digitalmoduls als ein Beispiel des Moduls der Prüfvorrichtung. Die Klasse des digitalen Treibermoduls und des digitalen Moduls für regelmäßig wiederholte Abtastimpulse werden als eine abgeleitete Klasse von der Basisklasse erzeugt.
  • Der Entwickler implementiert einen Konstruktor der Basisklasse, die getChannel-Methode, welche das Kanalobjekt zurückgibt, setBaseAddress, welche den Speicheradressraum des Moduls einrichtet, die setBusNumber-Methode, welche die Schachtnummer des Busschalters 140 einrichtet, die lockInterrupt/unlockInterrupt-Methode, welche das Sperren/Entsperren von Unterbrechungen einrichtet, und die read/write-Methode, welche auf den Speicheradressraum in dem Modul zugreift, basierend auf der Basisklasse.
  • 3.3.2.1 Örtliche Ereignisse
  • Die Offline-Simulation ist ein ereignisgetriebener Prozess. Das heißt, dass jedes Modul Ereignisse registriert. Dann wird die handleEvent-Methode des Moduls, von dem das Ereignis registriert wird, aufgerufen.
  • Die Ereignisse werden durch die SimEvent-Klasse definiert und in synchrone Ereignisse und asynchrone Ereignisse klassifiziert. Asynchrone Ereignisse werden darüber hinaus in Systemereignisse und lokalasynchrone Ereignisse klassifiziert. Systemereignisse sind beispielsweise eine Systemunterbrechung und ein Ende der Mustererzeugung, usw.
  • B.3.2.1.1 Lokal asynchrone Ereignisse
  • Lokal asynchrone Ereignisse werden verwendet, um Inter-Modul-Kommunikationen zu handhaben. Wie der Name angibt, existiert kein Zeitpunkt, welcher mit diesem Ereignis verknüpft ist. Um anzuzeigen, dass ein Modul wünscht, ein bestimmtes asynchrones Ereignis zu erhalten, sollte es für es registriert werden durch das Überladen der registerEvent-Methode, welche kein Zeitargument verwendet. Wenn ein Modul ein Ereignis bereitstellen muss, sollte die raiseEvent-Methode aufgerufen werden. Hierbei ist zu beachten, dass das Ereignisobjekt Argumente unterstützt, welche zu einem Ereignis hinzuzufügen sind. Das empfangende Modul sollte asynchrone Ereignisse in der überladenen handleEvent-Methode, welche kein Zeitargument aufweist, handhaben.
  • B.3.2.1.2 Lokal synchrone Ereignisse
  • Der gewöhnlichste Typ eines verwendeten Ereignisses ist das lokal synchrone Ereignis (oder einfach synchrone Ereignis). Diese Ereignisse werden von Modulen verwendet, um Lese- oder Schreibereignisse (Treiben oder Abtasten für digitale Module von englisch „drive" oder „strobe") zu planen. Synchrone Ereignisse werden lediglich durch ein Modul verwendet, um einen Nachricht zu einem bestimmten Zeitpunkt zu erhalten, und werden niemals für die Kommunikation zwischen Modulen verwendet.
  • B.3.3 Einfaches digitales Treibermodul
  • 22 illustriert eine Klassendeklaration eines einfachen digitalen Treibermoduls. Der Entwickler implementiert eine getModuleIDs-Methode, welche Informationen über den Konstruktor und den Anbieter/das Modul der Klasse zurückgibt, und eine initEvents-Methode, welche das Treibermodul initialisiert.
  • 23 ist ein Beispiel der handleEvent-Methode des digitalen Treibermoduls.
  • Das Treibermodul schreibt Kanten für all die Kanäle in dem gegenwärtigen Zyklus. Dieses Schreiben wird durch die Setz-Methode in jedem Element von m_channels durchgeführt, welches ein Array von SimChannel-Objekten ist. Zusätzlich zu der Setz-Methode beinhaltet das SimChannel-Objekt eine Aus-Methode und eine Ende-Methode. Die Aus-Methode beendet das Treiben des Signals. Die Ende-Methode benachrichtigt das Rahmenwerk, dass die Erzeugung des Signals während einer vorbestimmten Periode, beispielsweise einer Zyklusperiode, beendet ist. Nach dem Empfang der Nachricht wird ein Signal, welches das Auslesen eines Kanals anzeigt, an eine Komponente gegenüber dem Kanal gesendet, beispielsweise an die DUT-Verbindungseinheit 280. Demgemäß wird das erzeugte Signal durch die Komponente gelesen. Typischerweise wird der Benutzer, um das Signal während der vorbestimmten Periode zu erzeugen und zu übermitteln, verschiedene Methodensetz-Aufrufe durchführen, um die Spannung über einen Zeitbereich zu spezifizieren und dann die Ende-Methode einmal am Ende der vorbestimmten Periode aufrufen. Das Verhältnis zwischen der Setz-Methode und der Ende-Methode wird im Detail in B.3.4 beschrieben.
  • 3.3.4 Einfaches digitales Abtastmodul
  • 24 zeigt die Klassendeklaration eines einfachen digitalen Abtastmoduls. Der Entwickler implementiert den Konstruktor, die getModuleID-Methode, die initEvents-Methode usw. auf dieselbe Art und Weise in dem digitalen Treibermodul. Was das digitale Abtastmodul betrifft, werden die Lese- und Schreib-Methoden geändert, da das Vergleichsergebnis des Ausgabewertes der DUT und eines erwarteten Wertes in einem Fehlerspeicher gespeichert wird.
  • 25 ist ein Beispiel der handleEvent-Methode des digitalen Abtastmoduls. Ein digitales Abtastmodul liest die Spannung des Kanals zu einem spezifizierten Zeitpunkt, indem die Lese-Methode des SimChannels verwendet wird. Dann, nach dem Beendigen der Verarbeitung während der Zyklusperiode, veranlasst es das SimEventMgr-Objekt, ein Ereignis zu erzeugen, indem der Endzeitpunkt des nächsten Zyklus gesendet wird, dann wird das Ereignis durch die registerEvent-Methode registriert.
  • 3.3.4 Implementation eines DUT-Modells
  • Die DUT-Modellierung verwendet denselben Ansatz wie die Prüfermodule; jedoch ist die Simulation der DUTs nicht ereignisgetrieben. Demgemäß stellt SimComponentStepped, die Basisklasse für DUT-Modelle, Implementationen für initEvents-, handleEvent- und Bus-Eingabe/Ausgabe-Methoden zur Verfügung. Stattdessen muss der Funktionslauf implementiert werden, um das DUT-Modellverhalten während der Musterausführung zu definieren.
  • 27 zeigt ein Beispiel der Laufmethode in dem DUT-Modell. Die Laufmethode verwendet zwei Argumente, einen Startzeitpunkt und einen Endzeitpunkt. Diese Argumente geben an, dass das DUT-Modell seine internen Zustände von dem Startzeitpunkt zu dem Endzeitpunkt basierend auf einem Stimulus von den Eingabeanschlüssen vorwärtsbringen und jegliche Daten, welche von diesen Änderungen des DUT-Zustandes resultieren, ausgeben sollte. Eingaben sollten von den SimChannel-Objekten erhalten werden. Darüber hinaus können Ausgaben nach dem Endzeitpunkt auftreten.
  • Die Laufmethode beinhaltet Schritte des Abtastens der Eingabeanschlüsse, des Aktualisierens der internen Zustände der DUT und des Ausgebens von Daten an die Ausgabekanäle der DUT.
  • Sogar wenn eine Ausgabekante außerhalb des Ausführungszeitfensters fallen würde, müsste die absteigende Kante durch die Setz-Methode zu dem Ausgabekanal geschrieben werden. Darüber hinaus muss, wenn die Ende-Methode aufgerufen wird, das Ausgabesignal abgefallen sein.
  • Hierdurch zeigt der Ende-Aufruf dem System an, dass das Objekt auf der anderen Seite des Kanals den Kanal bis zum spezifizierten Zeitpunkt auf sichere Art und Weise lesen kann, weil sich das Signal nicht ändern wird. Das Rahmenwerk stellt sicher, dass dieses wahr ist, indem jegliche Schreibversuche auf den Kanal für Zeitpunkte, welche vor dem letzten Ende-Aufruf liegen, blockiert werden. Dies kann Probleme in nachfolgenden Laufaufrufen an das DUT-Modell verursachen.
  • Offline-DLL-Interface
  • Als Nächstes wird eine DLL des Moduls und das DUT-Modell basierend auf dem Rahmenwerk gebildet, und die Funktionen, welche eine Instanz dieser Modelle erzeugen und jegliche Aufräumarbeiten nach dem Ende des Prozesses durchführen, werden exportiert, so dass die DLL, welche das Modul der Prüfvorrichtung emuliert, und die DLL, welche die DUT emuliert, erzeugt werden können.
  • Ergänzende Information C: Ein Beispiel der Spezifikation einer Systembus-Zugriffsbibliothek
  • C.1 Einführung
  • 28 zeigt eine Positionierung der Systembus-Zugriffsbibliothek 6014 in der realen Umgebung 6000 und in der Emulationsumgebung 6050. Sie wird gemeinsam in der realen Umgebung 6000 der DUT 100 und in der Emulationsumgebung 6050 durch den Prüfemulator 190 verwendet.
  • 28A zeigt die Positionierung der Systembus-Zugriffsbibliothek 6014 in der realen Umgebung 6000 (Online-Umgebung). Die Software 6010 ist eine Software, welche auf dem in 1 illustrierten Standortcontroller 130 läuft. Die Software 6010 beinhaltet: einen HLC-Verarbeitungsabschnitt 6012, welcher einen HLC (Hochpegel-Befehl von englisch High Level Command) von dem Programm, welches die Prüfung der Prüfvorrichtung 10 steuert, empfängt und interpretiert und den Zugriffsbefehl auf die Hardware 6030 erzeugt; eine Systembus-Zugriffsbibliothek 6014, welche eine Kommunikationsbibliothek, welche eine Kommunikationsverarbeitung basierend auf einem Zugriffsbe fehl durchführt, und eine Buszugriffsbibliothek, welche auf einen Systembus (PCI-Bus in der vorliegenden Ausführungsform) basierend auf Befehlen von der Kommunikationsbibliothek zugreift, beinhaltet; und einen PCI-Bustreiber 6016, welcher einen Systembus basierend auf Befehlen von der Systembus-Zugriffsbibliothek 6014 steuert.
  • Die Hardware 6030 beinhaltet: ein Bus-IF 6032, welches in dem Standortcontroller 130, welcher in 1 illustriert ist, eingeschlossen ist; den Busschalter 140 und verschiedene Module wie beispielsweise das synchrone Modul 150, das synchrone Verbindungsmodul 160 und/oder Testmodul 170. Das Bus-IF 6032, welches mit dem Busschacht des Standortcontrollers 130 verbunden ist, übermittelt einen durch den PCI-Bustreiber 6016 ausgegebenen Zugriff an die Module wie beispielsweise das synchrone Modul 150 und/oder Testmodul 170 durch den Busschalter 140, so dass der Zugriff verarbeitet wird.
  • 28B illustriert das Positionieren der Systembus-Zugriffsbibliothek 6014 in der Emulationsumgebung 6050 (Offline-Umgebung). Der Offline-Prozess 6060 ist eine Software, welche auf dem Standortcontroller 130 oder dem Prüfemulator 190, welche in 1 illustriert sind, läuft und welche den Prüfemulator 190 veranlasst, als der Standortsteuerungs-Emulationsabschnitt 230 zu arbeiten. Der Offline-Prozess 6060 ist ein Prozess, um den Prüfvorrichtungs-Emulationsprozess 6080 zu steuern, anstelle der Steuerung der Hardware 6030 durch die Software 6010. Der Offline-Prozess 6060 stellt dem Benutzer der Software 6010 ein Benutzerpegel-Interface gemeinsam mit der Software 6010 zur Verfügung, indem der HLC-Verarbeitungsabschnitt 6012 und die Systembus-Zugriffsbibliothek 6014, welche im Wesentlichen dieselben wie die Software 6010 sind, verwendet wird. Der Prüfvorrichtungs-Emulationsprozess 6080 ist ein Prozess, welcher die Prüfvorrichtung 10 emuliert und welcher einen Systembusemulator 6084, welcher den Busschalter 140 emuliert, und den Modulemulator 6086, welcher das synchrone Modul 150, das synchrone Verbindungsmodul 160 und/oder das Prüfmodul 170 emuliert, beinhaltet. Der Systembusemulator 6084 veranlasst den Prüfemulator 190, als der Busschalter-Emulationsabschnitt 240 zu handeln. Der Modulemulator 6086 veranlasst den Prüfemulator 190, als der synchrone Modulemulationsabschnitt 250, der synchrone Verbindungsmodul-Emulationsabschnitt 260 und/oder der Prüfmodul-Emulationsabschnitt 270 zu handeln. Hiernach hat, sofern nicht anders speziell dargelegt und klar so geschrieben, ein Wort „Modul" die Bedeutung von zumindest einem Modul aus dem synchronen Modul 150, dem synchronen Verbindungsmodul 160 und dem Prüfmodul 170 in der Online-Umgebung und dem synchronen Modulemulationsabschnitt 250, dem synchronen Verbindungsmodul-Emulationsabschnitt 260 und dem Prüfmodul-Emulationsabschnitt 270 in der Offline-Umgebung.
  • C.2 Allgemeine Funktionen zum Steuern der Prüfermodule
  • Dieses Kapitel beschreibt allgemeine Funktionen, welche in dem Modultreiber, welcher auf dem Standortcontroller 130 läuft und das synchrone Modul 150, das synchrone Verbindungsmodul 160 und/oder das Prüfmodul 170 steuert, verwendet werden. In dem Modultreiber wird diese Bibliothek verwendet, um auf Register und Speicher in dem Prüfermodul zuzugreifen und um die für die Gerätemessung notwendigen Daten zu lesen und zu schreiben. Die in diesem Kapitel beschriebenen Hauptfunktionen sind wie folgt:
    • 1. Buszugriff unter Verwendung von Programm-Eingabe/Ausgabe
    • 2. Buszugriff unter Verwendung der DMA-Funktion
    • 3. Unterbrechungshandhabung
    • 4. Steuerung des Bibliotheks-/Systembusses
  • C.2.1 Buszugriff unter Verwendung der Programm-Eingabe/Ausgabe
  • Es gibt zwei Typen von Zugriffen auf den Systembus, einen, in welchem ein MW (Maschinenwort) direkt auf das Register des Prüfermoduls, welches mit dem Bus verbunden ist, geschrieben wird, und den anderen, in welchem der HLC (Hochpegel-Befehl) dem Prüfermodul übertragen wird.
  • In beiden Fällen fließen Adressen und Daten auf dem Systembus. Wenn sie als HLC durch die Adresse auf der Prüfermodulseite erkannt wird, wird die Verarbeitung entsprechend der HLC auf der Prüfermodulseite durchgeführt. Um Daten von der Standort-CPU (dem Standortcontroller 130) an das Prüfermodul zu schreiben, wer den dieselben Daten an jedes Prüfermodul, welches mit der Standort-CPU verbunden ist, geschrieben, und jedes Prüfermodul erwirbt die entsprechenden Daten.
  • FIFO wird in dem Systembus und in dem Prüfermodul angeordnet, und demgemäß wird die Schreibhandlung der CPU gestoppt, ohne auf die Beendigung der Schreibhandlung des Prüfermoduls zu warten, wenn irgendwelche Daten von der Standort-CPU an das Prüfermodul übertragen werden. Die Zeit, bis die Daten tatsächlich in dem Register gespeichert werden, wird durch die Verfügbarkeit von zwischen der CPU und dem Register des Ziels existierenden FIFO beeinflusst. Um zu garantieren, dass die Daten tatsächlich alle Prüfermodule erreicht haben, wird die Leer-Warte-Funktion des FIFO verwendet. Wenn die FIFOs unter Verwendung des von dem Register in dem Prüfermodul Gelesenen geleert werden, kann garantiert werden, dass lediglich der FIFO des zu lesenden Prüfermoduls geleert worden ist.
  • In dem Beispiel, welches in dem folgenden Diagramm gezeigt ist, wird die Lesehandlung veranlasst zu warten, bis der FIFO des Prüfermoduls 2 geleert ist, wenn das Lesen des Registers gegen das Prüfermodul 2 ausgeführt wird, aber es existiert keine Garantie, dass der FIFO des Prüfermoduls 1 geleert worden ist. Wenn diese Garantie gewünscht wird, ist das Lesen des Prüfermoduls 2 unter Verwendung der Leer-Warte-Funktion des FIFO in dem Prüfermodul auszuführen, nachdem der FIFO jedes Prüfermoduls geleert worden ist.
  • <Offline>
  • Kein FIFO ist in dem Offline-Systembusemulator 6084 angeordnet. Demgemäß kehrt er von der Funktion nach dem Speichern von Daten in dem Register des Modulemulators 6086 zurück, wenn PIO-Schreiben gegen einen Modulemulator 6086, welcher keinen FIFO aufweist, ausgeführt wird.
  • Wenn jegliche Daten in den Modulemulator 6086, welcher einen FIFO wie in online aufweist, geschrieben werden, wird der Schreibprozess unmittelbar nach Speichern von Daten in dem FIFO des Modulemulators 6086 beendet.
  • C.2.1.1 Schreiben unter Verwendung der Programm-Eingabe/Ausgabe
  • Schreiben der Daten an das Register in dem Prüfermodul. Die Standort-CPU beendet die Schreiboperation, bevor die geschriebenen Daten das Prüfermodul erreichen (verbuchtes Schreiben).
  • Figure 01010001
  • C.2.1.2 Lesen unter Verwendung der Programm-Eingabe/Ausgabe
  • Einlesen der Daten in das Register des Prüfermoduls. Die Standort-CPU wartet, bis die Daten gelesen sind. Das Lesen des Zielregisters wird veranlasst zu war ten, bis die Daten in dem FIFO zwischen der CPU und dem Zielregister geleert sind.
  • Figure 01020001
  • C.2.1.3 Blockschreiben unter Verwendung der Programm-Eingabe/Ausgabe
  • Schreiben der Blöcke von Daten in das Register in dem Prüfermodul. Spezifizieren des Datenformates unter Verwendung der Adresse und der Daten als ein Paar. Der Systembus führt die Schreibzyklen für die bestimmte Häufigkeit aus.
  • Wenn Daten in verschiedene Adressen geschrieben werden, kann dies mit höherer Geschwindigkeit, als jedes Mal mit der BCL_GBI_write()-Funktion zu schreiben, durchgeführt werden. Dies resultiert daraus, dass der Aufruf der Funktion lediglich einmal notwendig ist und dass verschiedene Ausschlüsse nicht ausgeführt werden.
  • Figure 01020002
  • Figure 01030001
  • C.2.1.4 Blocklesen unter Verwendung der Programm-Eingabe/Ausgabe
  • Lesen der Daten in das Register des Prüfermoduls als Blöcke. Die Adresse des Registers kann mit diskontinuierlichen Werten spezifiziert werden. Der Systembus führt die Lesezyklen für die spezifizierte Häufigkeit aus.
  • Wenn Daten in mehrere Adressen eingelesen werden, kann dies mit höherer Geschwindigkeit ausgeführt werden, als jedes Mal das Lesen mit der BCL_GBI_read()-Funktion durchzuführen. Dies resultiert daraus, dass der Aufruf der Funktion lediglich einmal notwendig ist und dass mehrfache Ausschlüsse nicht ausgeführt werden.
  • Figure 01030002
  • Figure 01040001
  • C.2.1.5 Kontinuierliches Blockschreiben unter Verwendung der Programm-Eingabe/Ausgabe
  • Das Datenarray wird in das Register geschrieben, welches in den gleichförmig beabstandeten Adressen des Prüfermoduls angeordnet ist. Das Datenarray wird von der spezifizierten Anfangsadresse geschrieben, und der Offset-Wert wird zu der Adresse jedes Mal, wenn die Daten geschrieben werden, hinzuaddiert. Der Offset-Wert kann als ein Wert zwischen 0 und 0x3ffffff spezifiziert werden. Der Systembus führt die Schreibzyklen mit der spezifizierten Häufigkeit durch.
  • Wenn Daten an mehrere festgelegte Offset-Adressen geschrieben werden, kann dies mit höherer Geschwindigkeit ausgeführt werden als das Schreiben unter Verwendung von BCL_GBI_writeBlock(). Dies liegt daran, dass das Hinzufügen von Adressen mittels Hardware abgewickelt wird und demgemäß die Anzahl von über den PCI-Bus fließenden Paketen kleiner wird.
  • Figure 01040002
  • Figure 01050001
  • C.2.1.6 Kontinuierliches Blocklesen unter Verwendung der Programm-Eingabe/Ausgabe
  • Das Datenarray wird von dem Register, welches in den gleichmäßig beabstandeten Adressen des Prüfermoduls angeordnet ist, gelesen. Das Datenarray wird von der spezifizierte Anfangsadresse gelesen, und der Offset-Wert wird zu der Adresse jedes Mal, wenn Daten gelesen werden, hinzuaddiert. Der Offset-Wert kann als ein Wert zwischen 0 und 0×3ffffff spezifiziert werden. Der Systembus führt den Lesezyklus mit der spezifizierten Häufigkeit durch.
  • Wenn Daten von mehreren festgelegten Offset-Adressen gelesen werden, kann dies mit höherer Geschwindigkeit durchgeführt werden, als jedes Mal mit der BCL_GBI_readBlock()-Funktion zu lesen. Dies resultiert aus der Tatsache, dass das Addieren von Adressen durch Hardware abgewickelt wird und demgemäß die Anzahl von Paketen, welche auf dem PCI-Bus fließen, geringer wird.
  • Figure 01050002
  • Figure 01060001
  • C.2.2 Buszugriff unter Verwendung der DMA-Funktion
  • Die folgenden vier Typen von Funktionen sind für den Datentransfer unter Verwendung von DMA verfügbar.
    Nr. Funktionen
    1 Synchrones DMA-Schreiben mit Signalfolge/einzeln
    2 Synchrones DMA-Lesen mit Signalfolge/einzeln
    3 Asynchrones DMA-Schreiben mit Signalfolge/einzeln
    4 Asynchrones DMA-Lesen mit Signalfolge/einzeln
  • 1. Synchroner/asynchroner DMA
  • Im Falle des synchronen DMA wartet die Funktion auf die Beendigung des DMA und beendet sich dann. Auch wenn die Funktion lediglich nach dem Beenden des DMA beendet wird, können die übertragenen Daten in den FIFO in dem Systembus I/F oder Prüfermodul in bestimmten Fällen verbleiben.
  • Im Falle eines asynchronen DMA wird die Funktion ohne Warten auf die DMA-Beendigung beendet. Demgemäß ist es notwendig, dass der Lebenszyklus des Datenbereiches durch den Benutzer garantiert wird. Darüber hinaus wird die Funktion gezwungen zu warten, bis der vorherige DMA-Transfer abgeschlossen ist, wenn eine beliebige Funktion unter Verwendung der DMA ausgeführt wird, bevor der Transfer des asynchronen DMA abgeschlossen worden ist.
  • Die Transfer-ID wird als die Identifikationsinformation vorbereitet, um auf den Abschluss der asynchronen DMA-Verarbeitung zu warten. Diese Transfer-ID stellt 32-Bit-Daten ohne einen Code dar und gibt 0 zurück, wenn die Anzahl von DMA-Transfers 32 Bit überschreitet, und wird wiederverwendet.
  • 2. Signalfolgen-/Einzel-DMA
  • Im Signalfolgen-DMA-Transfer werden Daten mit Paketen, welche spezifisch für eine Signalfolge auf dem Systembus sind, übertragen. Bei dieser Übertragung werden eine Adresse und N (64 maximal) Daten als ein Paket verwendet, und die Übertragung von Paketen wird wiederholt, bis die Übertragung der spezifizierten Anzahl von Daten abgeschlossen ist. Demgemäß ist ein Hochgeschwindigkeits-Transfer möglich.
  • Darüber hinaus kann der zunehmende Wert für die Adresse auf der Prüfermodulseite spezifiziert werden, indem der DMA-Transfer durchgeführt wird. Dieser zunehmende Wert wird verwendet, um die Kopfadresse des Paketes zur Übertragung des Paketes nach der zweiten Gruppe zu berechnen. (Adresse des Paketes) = (spezifierter zunehmender Wert) (Anzahl von Daten in dem vorhergehenden Paket) +(Kopfadresse des vorhergehenden Paketes)
  • Darüber hinaus ist es notwendig zu überprüfen, ob das Register ein verwendbares ist, da das Register, mit welchem ein Signalfolgen-Transfer möglich ist, von dem Prüfermodul abhängt.
  • In Einzel-DMA-Übertragungen werden die Adresse und die Daten als eine Gruppe auf dem Systembus übertra gen, genauso wie in der Programm-Eingabe/Ausgabe. Demgemäß ist die Übertragungsgeschwindigkeit geringer als diejenige für Signalfolgen-DMA, aber die Übertragung zu jedem Register ist möglich. Wenn der DMA-Transfer abgewickelt wird, kann der zunehmende Wert für die Adresse auf der Systembusseite spezifiziert werden. Dieser zunehmende Wert wird jedes Mal zu der Adresse addiert, wenn eine Adresse erzeugt wird.
  • <Offline>
  • Im Falle von offline wird, auch wenn ein Signalfolgen-Transfer spezifiziert ist, dieser intern als ein Einzel-Transfer behandelt. Demgemäß ist eine Übertragung zu jedem Register, welches einen Signalfolgen-Transfer nicht unterstützt, möglich. Berücksichtigt man eine Online-Verwendung, ist jedoch jede Benutzung für Register, in welchen ein Signalfolgen-Transfer nicht durch die Hardware unterstützt wird, zu vermeiden. Darüber hinaus sind offline-synchrone und offline-asynchrone DMAs gleich wie diejenigen bei online.
  • C.2.2.1 Synchrones Schreiben unter Verwendung der DMA- Funktion
  • Überträgt Daten, welche in dem Speicher der Standort-CPU angeordnet sind, an das Prüfermodul unter Verwendung von DMA. Diese Funktion kann Signalfolgen oder Einzeln für synchrones Schreiben spezifizieren.
  • Figure 01080001
  • Figure 01090001
  • C.2.2.2 Synchrones Lesen unter Verwendung der DMA- Funktion
  • Daten werden unter Verwendung der DMA von dem Register in dem Prüfermodul in den Speicher der Standort-CPU gelesen. Diese Funktion kann Signalfolgen oder Einzeln für synchrones Lesen spezifizieren.
  • Figure 01090002
  • C.2.2.3 Asynchrones Schreiben unter Verwendung der DMA-Funktion
  • Die in dem Speicher der Standort-CPU angeordneten Daten werden an das Prüfermodul unter Verwendung von DMA übertragen. Diese Funktion kann Signalfolgen oder Einzeln für asynchrones Schreiben spezifizieren.
  • Figure 01100001
  • C.2.2.4 Asynchrones Lesen unter Verwendung der DMA-Funktion
  • Daten werden unter Verwendung der DMA von dem Register in dem Prüfermodul in den Speicher der Standort-CPU gelesen. Diese Funktion kann Signalfolgen oder Einzeln für asynchrones Lesen spezifizieren.
  • Figure 01110001
  • C.2.2.5 Abwarten der Beendigung des asynchronen DMA-Transfers
  • Wartet die Beendigung der Übertragung im asynchronen Transfer unter Verwendung der DMA ab. Diese Funktion wird beendet, wenn der DMA abgeschlossen ist oder wenn die spezifizierte Zeit abgelaufen ist. Da die Auflösung 1 ms 32-Bit mit Vorzeichen versehene Zeitgeber verwendet, ist die Reichweite zur Zeitspezifikation 0 – (INT_MAX/1000). Jegliche außerhalb dieses Bereiches gemachte Spezifikation wird so behandelt, wie wenn BCL_GBI_INFINITE spezifiziert ist.
  • Wenn transferID mit einem falschen Wert spezifiziert wird, wird BCL_GBI_OK unmittelbar zurückgegeben und diese Funktion beendet.
  • Figure 01120001
  • C.2.2.6 Status des asynchronen DMA-Transfers
  • Gibt eine Nachricht über den gegenwärtigen Status des asynchronen DMA-Transfers. Wenn eine falsche transferID spezifiziert ist, wird eine Nachricht desselben Status wie bei Beendigung der DMA gegeben.
  • Figure 01120002
  • C.2.3 Unterbrechungs-Handhabung
  • In der Systembus-Zugriffsbibliothek werden Funktionen zur Ausführung von grundlegenden Unterbrechungs-Operationen zur Verfügung gestellt. Es gibt vier Typen von Unterbrechungen (Interrupts), welche unter Verwendung der Systembus-Zugriffsbibliothek durchführbar sind.
    • 1. Busfehlerunterbrechung (lediglich für online) Bis zu 65 Unterbrechungs-Handhaber können registriert werden.
    • 2. Bus-Zeitüberschreitungsunterbrechung Bis zu 65 Unterbrechungs-Handhaber können registriert werden.
    • 3. Sync-Fehlerunterbrechung (lediglich für online) Bis zu 65 Unterbrechungs-Handhaber können registriert werden.
    • 4. Vom Prüfermodul erzeugte Unterbrechung Bis zu 2 Unterbrechungs-Handhaber können mit jeder Busnummer registriert werden.
  • Sie wird mit einem Unterbrechungs-Thread zusammen mit oben genannten Unterbrechungen ausgeführt. Eine Busfehler-, eine Buszeitüberschreitungs- oder eine Sync-Fehler-Unterbrechung, welche durch den Systembus I/F erzeugt wurden, schalten die Unterbrechung im Inneren des Unterbrechungs-Threads ab und führen dann wiederum die Unterbrechungs-Handhaber des registrierten Ziels aus. Nachdem die Ausführung der Zielunterbrechungs-Handhaber abgeschlossen ist, leert der Unterbrechungs-Thread den Faktor der Unterbrechung und ermöglich die Unterbrechung intern.
  • Für die Akzeptanz der Unterbrechung kann die Steuerung von Ermöglichen/Deaktivieren durch die Funktion dieser Bibliothek separat vom Ermöglichen/Deaktivieren innerhalb des Unterbrechungs-Threads gesteuert werden. Für die Unterbrechung, welche in dem Prüfermodul erzeugt wird, deaktiviert der Unterbrechungs-Thread die Unterbrechung intern und führt die Blockierung der Unterbrechung für das Prüfermodul durch. Dann werden wiederum Unterbrechungs-Handhaber entsprechend der Busnummer, welche die Unterbrechung verursacht, ausgeführt. Nach Beendigung der Ausführung der Zielunterbrechungs-Handhaber leert der Unterbrechungs-Thread den Faktor der Unterbrechung für das Prüfermodul. Dann wird die Blockierung der Unterbrechung gelöst und die Unterbrechung wird intern ermöglicht.
  • Für die Akzeptanz der Unterbrechung kann die Steuerung von Ermöglichen/Deaktivieren durch die Funktion dieser Bibliothek separat vom Ermöglichen/Deaktivieren innerhalb des Unterbrechungs-Threads gesteuert werden. Die Verhinderung/Zulassung für eine Unterbrechung kann sowohl auf der Systembus-Leiterplatine als auch durch das Prüfermodul gesteuert werden.
  • Die Verhinderung/Zulassung auf der Systembus I/F Seite ermöglicht/deaktiviert einfach die Unterbrechung von dem Prüfermodul. Blockierung/Ermöglichung der Unterbrechung auf der Prüfermodulseite steuert eine Erzeugung einer Unterbrechung an der Unterbrechungsquelle auf der Prüfermodulseite. Während der Blockierung wird eine Erzeugung einer neuen Unterbrechung in dem Prüfermodul verhindert und eine Änderung in dem Status, welcher mit der Unterbrechung verknüpft ist, wird ebenso verhindert. Nach der Beendigung der Blockade wird eine Erzeugung einer Unterbrechung auf der Prüfermodulseite möglich.
  • C.2.3.1 Registrierung des Modul-Unterbrechungs-Handhabers
  • Die Unterbrechungs-Handhaberfunktion zum Zeitpunkt des Auftretens der Unterbrechung von dem Prüfermodul wird registriert. Wenn eine Unterbrechung aufgetreten ist, wird die registrierte Funktion mit dem exklusiven Thread für den Unterbrechungs-Handhaber ausgeführt. Der Unterbrechungs-Handhaber wird zusammen mit der Busnummer registriert, und der Unterbrechungs-Handhaber, welcher dieselbe registrierte Busnummer wie diejenige von dem Prüfermodul hat, welches die Unterbrechung mitgeteilt hat, wird aktiviert.
  • Darüber hinaus wird der zum Zeitpunkt der Registrierung gesetzte Wert an den Unterbrechungs-Handhaber zurückgegeben. Zwei Unterbrechungs-Handhaber können zur selben Zeit für jede Busnummer registriert werden. Busnummern können von 1 bis 64 spezifiziert werden. Sofern erfolgreich registriert, wird die Schlüsselnummer als der Rückgabewert zurückgegeben. Wenn eine Registrierung unter Verwendung dieser Schlüsselnummer durchgeführt wird, wird die erneute Registrierung und Löschung des Unterbrechungs-Handhabers mit dieser Schlüsselnummer möglich. Wenn eine beliebige Registrierung ausgeführt wird, indem O als die Schlüsselnummer spezifiziert wird, wird der Unterbrechungs-Handhaber auf eine unbesetzte Schlüsselnummer gesetzt. Wenn keine unbesetzte Schlüsselnummer existiert, tritt ein Fehler auf und (-1) wird als der Rückgabewert zurückgegeben. Bezug nehmend auf die Ausführung von Unterbrechungs-Handhabern in dem Fall, in welchem zwei Unterbrechungs-Handhaber registriert worden sind, wird die Ausführung von der jüngeren Schlüsselnummer durchgeführt.
  • Die Löschung des Unterbrechungs-Handhabers wird registriert, indem die Adresse der Rückruf-Funktion auf BCL_GBI_IGNORE_MODULE_HANDLER gesetzt wird. Der Unterbrechungs-Thread führt den Unterbrechungs-Handhaber von BCL_GEI_IGNORE_MODULE_HANDLER nicht aus. Wenn beide der zwei Unterbrechungs-Handhaber für jede Busnummer BCL_GBI_IGNORE_MODULE_HANDLER werden, kehren Unterbrechungs-Handhaber von dieser Busnummer auf den Vorgabewert zurück. (Der Standard-Unterbrechungs-Handhaber in der Zugriffsbibliothek wird gesetzt.)
    Figure 01160001
  • C.2.3.2 Registrierung des Busfehler-Unterbrechungshandhabers
  • Die Fehlerverarbeitungsfunktion für den Fall, in welchem ein Fehler in dem Systembus auftritt, wird re gistriert. Wenn ein beliebiger Fehler in dem Systembus auftritt, führt der Unterbrechungs-Thread die registrierte Funktion aus. Darüber hinaus wird, wenn ein beliebiger Fehler in dem Systembus auftritt, die Unterbrechung durch den Unterbrechungs-Thread gelöscht. Es ist nicht notwendig, innerhalb des Unterbrechungs-Handhabers zu löschen.
  • Bis zu 65 Unterbrechungs-Handhaber für Busfehler können registriert werden. Sofern erfolgreich registriert, wird die Schlüsselnummer als der Rückgabewert zurückgegeben. Wenn eine Registrierung unter Verwendung dieser Schlüsselnummer durchgeführt wird, wird die erneute Registrierung und Löschung des Unterbrechungs-Handhabers mit dieser Schlüsselnummer möglich. Wenn eine beliebige Registrierung ausgeführt wird, indem 0 als die Schlüsselnummer spezifiziert wird, wird der Unterbrechungs-Handhaber auf eine unbesetzte Schlüsselnummer gesetzt. Wenn es keine unbesetzte Schlüsselnummer gibt, tritt ein Fehler auf und (-1) wird als der Rückgabewert zurückgegeben. Das Löschen des Unterbrechungs-Handhabers wird registriert, indem die Adresse der Rückruf-Funktion auf BCL_GBI_IGNORE_BUSERROR_HANDLER gesetzt wird.
  • Der Unterbrechungs-Thread führt den Unterbrechungs-Handhaber von BCL_GBI_IGNORE_BUSERROR_HANDLER nicht durch. Wenn alle 65 Unterbrechungs-Handhaber BCL_GBI_IGNORE_BUSERROR_HANDLER werden, kehren sie auf den vorgegebenen Wert zurück. (Der Standard-Unterbrechungs-Handhaber in der Zugriffsbibliothek wird gesetzt.) Ein Busfehler kann aufgrund eines Fehlers in der Kommunikation des Systembusses oder einer fehlerhaften Hardware auftreten.
  • <Offline>
  • Da es keinen Faktor gibt, welcher einen beliebigen Fehler in dem Bus offline verursacht, funktioniert der Handhaber, welcher mit dieser Funktion registriert wird, nicht.
  • Figure 01180001
  • C.2.3.3 Registrierung des Buszeitüberschreitungs-Unterbrechungs-Handhabers
  • Die Fehlerverarbeitungsfunktion für den Fall, in welchem eine Zeitüberschreitung in dem Systembus auftritt, wird registriert. Wenn eine beliebige Zeitüberschreitung in dem Systembus auftritt, führt der Unterbrechungs-Thread die registrierte Funktion durch. Darüber hinaus wird die Unterbrechung durch den Unterbrechungs-Thread gelöscht, wenn eine beliebige Zeitüberschreitung in dem Systembus auftritt.
  • Es ist nicht notwendig, innerhalb des Unterbrechungs-Handhabers zu löschen. Bis zu 65 Unterbrechungs-Handhaber für die Buszeitüberschreitung können registriert werden. Sofern erfolgreich registriert, wird die Schlüsselnummer als der Rückgabewert zurückgegeben. Wenn eine Registrierung durchgeführt wird, indem diese Schlüsselnummer verwendet wird, wird die erneute Registrierung und die Löschung des Unterbrechungs-Handhabers mit dieser Schlüsselnummer möglich. Wenn eine beliebige Registrierung ausgeführt wird, indem 0 als die Schlüsselnummer spezifiziert wird, wird der Unterbrechungs-Handhaber auf eine unbesetzte Schlüsselnummer gesetzt. Wenn es keine unbesetzte Schlüsselnummer gibt, tritt ein Fehler auf und (-1) wird als der Rückgabewert zurückgegeben. Das Löschen des Unterbrechungs-Handhabers wird registriert, indem die Adresse der Rückruf-Funktion auf BCL_GBI_IGNORE_TIMEOUT_HANDLER gesetzt wird.
  • Der Unterbrechungs-Thread führt den Unterbrechungs-Handhaber von BCL_GBI_IGNORE_TIMEOUT_HANDLER nicht durch. Wenn alle 65 Unterbrechungs-Handhaber BCL_GBI_IGNORE_TIMEOUT_HANDLER werden, gehen sie auf den vorgegebenen Wert zurück. (Der Standard-Unterbrechungs-Handhaber in der Zugriffsbibliothek wird gesetzt.) Eine Buszeitüberschreitung tritt zum Lesezeitpunkt unter der Bedingung auf, dass eine Kabelverbindung gelöst wird oder dass der Empfänger nicht existiert. Fehlerhafte Hardware kann auch den Grund bilden.
  • Figure 01190001
  • Figure 01200001
  • C.2.3.4 Registrierung des Sync-Fehler-Unterbrechungs-Handhabers
  • Die Fehlerverarbeitungsfunktion für den Fall, in welchem ein Sync-Fehler in dem Systembus auftritt, wird registriert. Wenn ein beliebiger Sync-Fehler in dem Systembus auftritt, führt der Unterbrechungs-Thread die registrierte Funktion durch. Darüber hinaus wird die Unterbrechung durch den Unterbrechungs-Thread gelöscht, wenn ein beliebiger Sync-Fehler in dem Systembus auftritt. Es ist nicht notwendig, innerhalb des Unterbrechungs-Handhabers zu löschen.
  • Bis zu 65 Unterbrechungs-Handhaber für einen Sync-Fehler können registriert werden. Sofern erfolgreich registriert, wird die Schlüsselnummer als der Rückgabewert zurückgegeben. Wenn eine Registrierung unter Verwendung dieser Schlüsselnummer ausgeführt wird, wird die erneute Registrierung und das Löschen des Unterbrechungs-Handhabers mit dieser Schlüsselnummer möglich. Wenn eine beliebige Registrierung durchgeführt wird, indem 0 als die Schlüsselnummer spezifiziert wird, wird der Unterbrechungs-Handhaber auf eine unbesetzte Schlüsselnummer gesetzt. Wenn es keine unbesetzte Schlüsselnummer gibt, tritt ein Fehler auf und (-1) wird als der Rückgabewert zurückgegeben.
  • Das Löschen des Unterbrechungs-Handhabers wird registriert, indem die Adresse der Rückruffunktion auf BCL_GBI_IGNORE_SYNCERROR_HANDLER gesetzt wird. Der Unterbrechungs-Thread führt den Unterbrechungs-Handhaber von BCL_GBI_IGNORE_SYNCERROR_HANDLER nicht durch. Wenn alle 65 Unterbrechungs-Handhaber BCL_GBI_IGNORE_SYNCERROR_HANDLER werden, gehen sie auf den vorgegebenen Wert zurück. (Der Standard-Unterbrechungs-Handhaber in der Zugriffsbibliothek wird gesetzt.)
  • Ein Sync-Fehler kann durch unsauberes Setzen von Software oder durch ein fehlerhaftes Design von Hardware verursacht werden. Fehlerhafte Hardware kann auch die Ursache sein.
  • <Offline>
  • Weil es keinen Faktor gibt, welcher einen beliebigen Sync-Fehler in dem Bus offline verursacht, funktioniert der Handhaber, welcher mit dieser Funktion registriert ist, nicht.
  • Figure 01210001
  • Figure 01220001
  • C.2.4 Steuerung der Bibliothek/des Systembusses
  • C.2.4.1 Warten auf FIFO-Leerung
  • Es wird auf das Leeren des FIFO in allen Prüfermodulen, welche mit dem Systembus verbunden sind, der mit der Standort-CPU verbunden ist, gewartet. FIFOs existieren in der Systembus I/F Platine und in dem Prüfermodul. Wenn diese Funktion beendet wird, bedeutet dies, dass all die Daten, welche in dem FIFO unmittelbar vor dem Ausführen dieser Funktion existierten, an das Prüfermodul geschrieben werden. Da die CPU einen Lesezyklus an den PCI-Bus während der Durchführung dieser Funktion ausgibt, wird der Bus mittels Hardware blockiert, bis der FIFO geleert ist. Danach kann eine Verzögerung in dem DMA-Transfer bei der Unterbrechungs-Akzeptanz usw. auftreten. Darüber hinaus kann in bestimmten Fällen eine Zeitüberschreitung aufgrund der Ausführung dieser Funktion auftreten.
  • Darüber hinaus kann in bestimmten Fällen eine Zeitüberschreitung aufgrund der Ausführung dieser Funktion auftreten.
  • <Offline>
  • Offline existiert der FIFO des Systembus I/F Emulators nicht. Darüber hinaus ist die Existenz des FIFOs in dem Prüfermodul anbieterabhängig.
  • Figure 01230001
  • C.2.4.2 Zurücksetzungsmodul
  • Prüfermodule, welche mit der Standort-CPU verbunden sind, werden zurückgesetzt. In dieser Funktion wird die folgende Verarbeitung ausgeführt:
    • 1. Aussenden des Bus-Zurücksetzungs-Pakets an den Systembus
    • 2. Aussenden des Paketes zum Löschen der Unterbrechung an den Systembus
    • 3. Aussenden des Paketes zum Lösen der Blockierung der Unterbrechung an den Systembus.
  • Die Zurücksetzungshandlung und die benötigte Zeit hängen von jedem Prüfermodul ab.
  • Figure 01240001
  • C.2.4.3 Initialisierung der Bibliothek
  • Die Systembus-Zugriffsbibliothek wird initialisiert. Wenn die Systembus-Zugriffsbibliothek benutzt wird, ist es notwendig, zunächst diese Initialisierung durchzuführen. In dieser Funktion werden die folgenden Prozesse ausgeführt.
    • 1. Initialisierung der Variable der Zugriffsbibliothek
    • 2. Aktivierung des Threads zum Ausführen des Unterbrechungs-Handhabers
  • Die Unterbrechung auf dem Systembus I/F ist in einem deaktivierten Status.
  • <Offline>
  • Im Falle von offline wird eine Kommunikation zwischen den Prozessen mit dem Systembus-Emulator durch diese Funktion vorbereitet. Eine Zeitüberschreitung tritt auf, wenn die Verbindung mit dem Systembus-Emulator nicht innerhalb von 30 Sekunden etabliert wird.
  • Figure 01240002
  • Figure 01250001
  • BCL_GBI_TIMEOUT kann mit dem Systembusemulator nicht innerhalb von 30 Sekunden verbinden
  • C.2.4.4 Freigabe der Bibliothek
  • Die Verarbeitung zum Beenden der Verwendung der Systembus-Zugriffsbibliothek wird ausgeführt.
  • Figure 01250002
  • C.2.4.5 Bestimmen von online/offline
  • Bestimmt, ob die gegenwärtig laufende Systembus-Zugriffsbibliothek online oder offline arbeitet.
  • Figure 01260001
  • C.2.4.6. Überprüfung der Verbindung mit GBSC
  • Verifiziert, ob oder ob nicht der Systembus I/F mit der GBSC verbunden werden kann. Dies kann auch überprüfen, ob die GBSC angeschaltet ist oder nicht.
  • Figure 01260002
  • C.2.4.7 Erwerben detaillierter Fehlerinformation
  • Gibt detaillierte Informationen des Fehlers zurück, welcher auftrat, wenn die Systembus-Zugriffsbibliothek BCL_GEI_ERROR zurückgab.
  • Figure 01260003
  • Figure 01270001
  • C.2.4.8 Erwerben der detaillierten Fehlerinformationsgeschichte
  • Gibt detaillierte Informationen der letzten 16 Fehler (Maximum) zurück, welche auftraten, wenn die Systembus-Zugriffsbibliothek BCL_GBI_ERROR zurückgab.
  • Figure 01270002
  • Figure 01280001
  • C.3 Zeitgeberfunktionen
  • Dieses Kapitel beschreibt die Funktionen, welche die Zeitgeber-Hardware auf der Systembus I/F-Platine steuern.
  • Die Auflösung der Zeitgeber-Hardware auf der Systembus I/F-Platine beträgt 1 [us].
  • C.3.1 Lesen der abgelaufenen Zeit
  • C.3.1.1 Lesen der Zeit
  • Die abgelaufene Zeit, nachdem die Systembus-Zugriffsbibliothek initialisiert worden ist, kann in Sekunden gelesen werden [s].
  • <Einschränkungen>
  • Die Auflösung beträgt 1 [us]. Wenn jedoch der gelesene Wert größer ist als die signifikanten Stellen von double·1 [us], kann eine Auflösung von 1 [us] nicht erhalten werden, weil die Daten in den Double-Typ konvertiert sind und dann gelesen werden. Die signifikanten Stellen von double sind 15 Stellen im Dezimalsystem, demgemäß kann theoretisch eine Auflösung von 1 [us] nicht für ungefähr 31 Jahre von der Initialisierung an erhalten werden.
  • Der Hardware-Zähler arbeitet mit 64 Bits, demgemäß wird er auf 0 nach ungefähr 580.000 Jahren, nachdem die Systembus-Zugriffsbibliothek initialisiert worden ist, zurückkehren. In dem Programm kann die Differenz (vergangene Zeit) zwischen Leseereignissen in regelmäßigen Intervallen aufgrund der Lastbedingungen der CPU oder des PCI-Busses oder aufgrund der FIFO-Bedingungen nicht dieselbe sein.
  • <Offline>
  • Bei offline wird die vergangene Zeit, nachdem die Standort-CPU gestartet ist, in Sekunden gelesen [s].
  • Figure 01290001
  • C.3.1.2 Lesen des Zeitgeber-Zählers
  • Die nach der Initialisierung der Systembus-Zugriffsbibliothek vergangene Zeit kann in einen Zählerwert gelesen werden. Der Zählerwert nimmt um 1 mit einem Vergehen von 1 [us] zu.
  • <Einschränkungen>
  • Der Hardware-Zähler arbeitet mit 64 Bits, demgemäß wird er theoretisch auf 0 nach 580.000 Jahren, nachdem die Systembus-Zugriffsbibliothek initialisiert worden ist, zurückkehren. In dem Programm kann die Differenz (vergangene Zeit) zwischen in regelmäßigen Intervallen durchgeführten Leseereignissen aufgrund der Lastbedingungen der CPU oder des PCI-Busses oder aufgrund der FIFO-Bedingungen nicht dieselbe sein.
  • <Offline>
  • Im Falle von offline wird die von dem Zeitpunkt, zu dem die Standort-CPU gestartet wird, vergangene Zeit als der Zählerwert gelesen.
  • Figure 01300001
  • C.3.2 Wartefunktionen
  • C.3.2.1 Wartezeit
  • Diese Funktion veranlasst die nächste Funktion, so lange zu warten, bis die spezifizierte Zeit vergangen ist. Wenn ein Wert kleiner als 1 [us] als die Wartezeit spezifiziert ist, wird die nächste Funktion unmittelbar beginnen.
  • <Einschränkungen>
  • Die Wartezeit kann länger als die spezifizierte Zeit sein, abhängig von den Lastbedingungen der CPU.
  • <Offline>
  • Im Falle von offline basiert die Wartezeit auf dem Wert, in welchem weniger als 1 [ms] abgerundet wird. Beispielsweise wird die Funktion unmittelbar zurückgegeben werden, wenn ein Wert kleiner als 1 [ms] als die Wartezeit (time) spezifiziert ist. Die maximale Wartezeit ist 4.294.967,296 [s] (ungefähr 49 Tage).
  • Figure 01310001
  • C.3.2.2 Abbrechen der Wartefunktion
  • Alle Prozesse der gegenwärtig laufenden BCL_TMR_wait-Funktion können abgebrochen werden. Wenn die Funktion in mehreren Threads durchgeführt wird, werden all die Prozesse der BCL_TMR_wait-Funktion abgebrochen.
  • Figure 01310002
  • Figure 01320001
  • C.4 Funktionen speziell für die Konfiguration/Diagnostik
  • Dieses Kapitel beschreibt die Funktionen, welche für die Hardware-Konfiguration und die Hardware-Diagnose verwendet werden. Der Datentransfer an das Prüfermodul oder die Unterbrechungs-Operation können nicht sauber durchgeführt werden, wenn sie für einen beliebigen anderen Zweck als die Hardware-Konfiguration und die Hardware-Diagnose verwendet werden. Diese Funktionen sind für die Hardware-Konfiguration und die Hardware-Diagnose nach Lernen der Hardware-Strukturen der Systembus I/F Platine, des Busschalters und des Prüfermoduls usw. zu verwenden.
  • Während des Laufens tritt kein Laufzeitfehler in dieser Bibliothek auf, aber, wenn sie in einer beliebigen anderen Funktion als für die Buskonfiguration und die Hardware-Diagnose verwendet wird, wird die Funktion dieser Bibliothek und der Systembus I/F-Platine im Hinblick auf Unterbrechungen des Gerätetreibers nicht garantiert.
  • C.4.1 Konfigurationssteuerung (Spezialfunktion)
  • Die Funktion, welche in diesem Kapitel beschrieben wird, ist eine Funktion, welche zur Konfiguration des Systembus I/F und des Prüfermoduls verwendet wird. Da der Datentransfer an das Prüfermodul unmöglich wird, wenn sie ohne Sorgfalt betrieben wird, ist sie zu verwenden, nachdem man sich gründlich mit der Struk tur der Hardware und der Software vertraut gemacht hat.
  • C.4.1.1 Buskonfigurations-Schreiben
  • Daten werden an das Systembus I/F Register und an das Prüfermodul-Konfigurationsregister geschrieben. Diese Funktion wird beendet, nachdem die Konfigurationsdaten in dem Systembus I/F und dem Prüfermodul gespeichert sind.
  • Figure 01330001
  • C.4.1.2 Buskonfigurations-Schreiben
  • Daten werden von dem Systembus I/F Register und dem Prüfermodul-Konfigurationsregister gelesen.
  • Figure 01330002
  • Figure 01340001
  • C.4.1.3 Beendigen der Busschalter-Konfigurationseinstellungen
  • Im Falle von Online wird nichts ausgeführt.
  • <Offline>
  • Eine Offline-Busverbindung kann geschaltet werden, indem diese Funktion ausgeführt wird, wenn das Busschaltungs-Konfigurationsschreiben beendet ist.
  • Figure 01340002
  • C.4.2 Unterbrechungssteuerung (Spezialfunktion)
  • Die Funktion, welche in diesem Kapitel beschrieben wird, ist eine Funktion, welche zur Buskonfiguration und zur Hardware-Diagnose verwendet wird. Da die Unterbrechung der Systembus I/F-Platine unmittelbar gesteuert wird, können der Gerätetreiber der Systembus I/F-Platine und diese Bibliothek die Unterbrechungs verarbeitung nicht ausführen, wenn ein Betrieb ohne Sorgfalt vorliegt.
  • C.4.2.1 Ermöglichung der Bus I/F-Platinenunterbrechung
  • Verschiedene Unterbrechungssignale werden auf der Systembus I/F-Platine ermöglicht. Es gibt vier Typen von Unterbrechungssignalen: Unterbrechung von dem Prüfermodul, einem Busfehler, einem Buszeitablauf und einem Sync-Fehler. Diese Signale können als die definierte Bitinformation wie folgt gesetzt werden. Bei der Spezifizierung mehrerer Unterbrechungssignale sind sie als logisches ODER zu setzen. Diese Funktion wird beendet, nachdem sichergestellt ist, dass die Unterbrechung auf dem Systembus I/F ermöglicht worden ist.
  • Figure 01350001
  • C.4.2.2 Bus I/F-Platinen-Unterbrechungs-Abschaltung
  • Verschiedene Unterbrechungssignale werden auf der Systembus I/F-Platine abgeschaltet. Es gibt vier Typen von Unterbrechungssignalen: Unterbrechung von dem Prüfermodul, Busfehler, Buszeitablauf und Sync-Fehler. Diese Signale können als die definierte Bitinformation wie folgt gesetzt werden. Beim Spezifizieren mehrerer Unterbrechungssignale sind sie als logisches ODER zu setzen. Diese Funktion wird beendet, nachdem sichergestellt ist, dass die Unterbrechung auf dem Systembus I/F abgeschaltet worden ist.
  • Figure 01360001
  • C.4.2.3 Bus I/F-Platinen-Unterbrechungs-Lesen
  • Verschiedene Unterbrechungssignale werden auf der Systembus I/F-Platine gelesen. Es gibt vier Typen von Unterbrechungssignalen: Unterbrechung von dem Prüfermodul, Busfehler, Buszeitablauf und Sync-Fehler. Diese Signale können als die Bitinformation gelesen werden, wie es im Folgenden definiert ist:
    Figure 01370001
  • C.4.2.4 Bus I/F-Platinen-Unterbrechungs-Löschung
  • Verschiedene Unterbrechungssignale werden auf der Systembus I/F-Platine gelöscht. Es gibt vier Typen von Unterbrechungssignalen: Unterbrechung von dem Prüfermodul, Busfehler, Buszeitablauf und Sync-Fehler. Diese Signale können als die Bitinformation gesetzt werden, welche wie folgt definiert ist. Beim Spezifizieren mehrerer Unterbrechungssignale sind sie als logisches ODER zu setzen. Diese Funktion löscht die Unterbrechung auf dem Systembus I/F, nachdem der FIFO von jedem Prüfermodul, unmittelbar bevor diese Funktion ausgeführt wurde, geleert worden ist. Diese Funktion wird beendet, nachdem sichergestellt worden ist, dass die Unterbrechnung auf dem Systembus I/F gelöscht worden ist.
  • Wenn lediglich die Unterbrechung von dem Prüfermodul (BCL_GBI_INT_MODULE) spezifiziert wird, ist der FIFO von jedem der Prüfermodule unmittelbar vor Ausführung dieser Funktion zu löschen, ist die Unterbrechung auf dem Systembus I/F zu löschen, ist zu bestätigen, dass die Unterbrechung auf dem Systembus gelöscht ist und ist der Prozess zu beenden.
  • Figure 01380001
  • C.4.2.5 Setzen der Anzahl von Modulen, welche zu synchronisieren sind
  • Die Anzahl von allen Prüfermodulen, welche mit dem Systembus verbunden sind, der mit der Standort-CPU verbunden ist, wird auf der Systembus I/F-Platine ge setzt. Mit dieser Einstellung wird die Anzahl von Modulen zum Synchronisieren des FIFOs bestimmt.
  • <Offline>
  • Bei offline existiert der FIFO des Systembus I/F-Emulators nicht. Darüber hinaus ist die Existenz des FIFOs in dem Prüfermodul anbieterabhängig.
  • Figure 01390001
  • C.4.2.6 Abspeichern von Unterbrechungseinstellungen
  • Die Einstellung des Unterbrechungssignals (ermöglichen oder deaktivieren) auf der Systembus I/F-Platine und die Einstellung des Unterbrechungsauftretens (gesperrt oder entsperrt) von dem Prüfermodul werden gespeichert. Diese Funktion wird verwendet, um die gegenwärtigen Einstellungen abzuspeichern, bevor eine Unterbrechung in der Diagnose oder in anderen Operationen ausgeführt wird. Die abgespeicherten Einstellungen werden wiederhergestellt, indem die BCL_GBI_restoreInterruptCondition()-Funktion verwendet wird. Wenn diese Funktion mehr als einmal ausgeführt wird, werden die vorher gespeicherten Einstellungen gelöscht und lediglich die jüngst abgespeicherten Einstellungen werden wirksam.
  • <Offline>
  • Im Falle von offline ist dieses Merkmal ungültig, und nichts passiert in dieser Funktion.
  • Figure 01400001
  • C.4.2.7 Wiederherstellen von Unterbrechungseinstellungen
  • Die Einstellung des Unterbrechungssignals (ermöglichen oder abschalten) auf der Systembus I/F-Platine und die Einstellung des Unterbrechungsauftretens (gesperrt und entsperrt) von dem Prüfermodul, welche unter Verwendung der BCL_GBI_saveInterruptCondition()-Funktion abgespeichert wurden, werden wiederhergestellt. Nachdem die Unterbrechung in einer Diagnose oder in anderen Operationen ausgeführt wird, wird diese Funktion verwendet, um die Einstellungen vor der Operation wiederherzustellen. Wenn diese Funktion ausgeführt wird, ohne die BCL_GBI_saveInterruptCondition()-Funktion zu verwenden, um die Einstellungen abzuspeichern, gibt die Funktion einen Fehler zurück. Wenn diese Funktion mehr als einmal ausgeführt wird, tritt kein Fehler auf und die jüngst abgespeicherten Einstellungen werden wiederhergestellt.
  • <Offline>
  • Im Falle von offline ist dieses Merkmal ungültig, und nichts passiert in dieser Funktion.
  • Figure 01410001
  • C.4.2.8 Lesen von Modulunterbrechungsfaktoren
  • Wenn die Unterbrechung von dem Prüfermodul auftritt, werden die Faktoren und die Anzahl von Faktoren gelesen. Ein Maximum von 256 (4 Bytes pro Faktor) Unterbrechungsfaktoren existiert. Unter diesen werden lediglich Faktoren, bei denen Unterbrechungen auftraten, zurückgegeben. Es ist die maximale Anzahl von Faktoren, bei denen Unterbrechungen auftreten können (256 vorzeichenloser Integertyp) zu berücksichtigen und eine ausreichende Anzahl von Puffern zum Lesen der Faktoren zu zuzuweisen.
  • <Offline>
  • Im Falle von offline ist dieses Merkmal ungültig, und nichts passiert in dieser Funktion.
  • Figure 01410002
  • Figure 01420001
  • C.5 Hängige Funktionen
  • Hängige Funktionen
  • C.5.1.1 Aufhebung vom asynchronen DMA-Transfer (Nichtangabe)
  • Hebt die Ausführung des asynchronen DMA-Transfers auf. Der synchrone DMA kann nicht aufgehoben werden. Wenn eine falsche Transfer-ID spezifiziert ist, wird eine Aufhebung des DMA nicht durchgeführt, und der Status der normalen Beendigung wird zurückgegeben.
  • Figure 01420002
  • C.5.1.2 Erwerb der PCI-Basisadresse (Nichtangabe)
  • Die Basisadresse des PCI-Busses, welche in der Systembus I/F-Platine verwendet wird, kann erworben werden. Diese Funktion wird in dem Diagnoseprozess für die Systembus I/F-Platine verwendet usw. Diese Adresse kann lediglich für einen Prozess verwendet werden, von welchem die Adresse erworben worden ist. Wenn die erworbene Adresse NULL ist, ist die Bibliothek nicht initialisiert worden. Die Bibliothek ist zu initialisieren unter Verwendung der BCL_GBI_init-Funktion, und dann ist diese Funktion zu verwenden.
  • <Notiz>
  • Diese Funktion wird lediglich im Fehlersuch-Prozess verwendet und kann für kein Produkt in keiner Weise verwendet werden.
  • <Offline>
  • Im Falle von offline ist dieses Merkmal ungültig, und nichts passiert in dieser Funktion.
  • Figure 01430001
  • C.5.1.3 Prüfermodul-Unterbrechungssperrung (Nichtangabe)
  • Auftreten von Unterbrechungen von dem Prüfermodul können an der Quelle der Unterbrechungen abgestellt werden. Nach Setzen der Unterbrechungssperrung wird von dem Prüfermodul keine Unterbrechung ausgegeben. Diese Funktion wird beendet, nachdem der Sperrbefehl vollständig in jedem der Prüfermodule abgespeichert ist.
  • Figure 01440001
  • C.5.1.4 Prüfermodul-Unterbrechungsentsperrung (Nichtangabe)
  • Das Auftreten von Unterbrechungen von dem Prüfermodul kann an der Quelle der Unterbrechungen zugelassen werden. Das Ausführen dieser Funktion erlaubt dem Prüfermodul, Unterbrechungen, welche durch die Unterbrechungssperrfunktion außer Kraft gesetzt worden sind, oder Unterbrechungen, welche nach dem Entsperren erzeugt werden, auszugeben.
  • Diese Funktion wird beendet, nachdem der Entsperrbefehl vollständig in jedem der Prüfermodule abgespeichert ist.
  • Figure 01450001
  • C.5.1.5 Ausgabe von detaillierten Fehlerinformationen (Nichtangabe)
  • Gibt die detaillierte Information über den Fehler, welcher auftrat, als die Systembus-Zugriffsbibliothek BCL_GBI_ERROR zurückgab, an den Standardausgabestrom.
  • Figure 01450002
  • C.5.1.6 Ausgabe der detaillierten Fehlerinformationsgeschichte (Nichtangabe)
  • Gibt die detaillierte Information über die letzten 16 Fehler (Maximum), welche auftraten, als die Systembus-Zugriffsbibliothek BCL_GBI_ERROR zurückgab, an den Standardausgabestrom aus.
  • Figure 01450003
  • Figure 01460001
  • C.5.1.7 Fehlersuchmodus-Steuerung (Nichtangabe)
  • Steuert den für die Zugriffsbibliothek implementierten Fehlersuchmodus.
  • Figure 01460002
  • C.5.1.8 Ermöglichen der Ablaufverfolgungsfunktion (Nichtangabe)
  • Ermöglicht die Ablaufverfolgungsfunktion der Zugriffsbibliothek. Wenn die Ablaufverfolgungsfunktion ermöglicht wird, wird es möglich, den Buszugriff und die Funktionen im Ablauf zu verfolgen. Die Ablaufverfolgung des Buszugriffs erlaubt es, die Adresse, auf welche zugegriffen wurde, und Daten und die Lese/Schreib-Identifikation in dem Standardausgabestrom anzuzeigen. Die Funktionsablaufverfolgung erlaubt es, die ausgeführten Funktionsnamen in dem Standardausgabestrom anzuzeigen. Eine beliebige Funktion kann als eine Funktion, welche eine Ablaufverfolgung ausführt, registriert werden und für eine vorher registrierte Funktion ersetzt werden.
  • Die Zugriffsbibliothek beinhaltet die folgenden Funktionen, welche eine Buszugriffs-Ablaufverfolgung durchführen:
    BCL_GBI_write
    BCL_GBI_read
    BCL_GBI_writeBlock
    BCL_GBI_readBlock
    BCL_GBI_writeSeq
    BCL_GBI_readSeq
    BCL_GBI_writeSyncDMA
    BCL_GBI_readSyncDMA
    BCL_GBI_writeAsyncDMA
    BCL_GBI_readAsyncDMA
    BCL_GBI_writeConfig
    BCL_GBI_readConfig
  • Die Zugriffsbibliothek beinhaltet die folgenden Funktionen, welche eine Ablaufverfolgung von Funktionen ausführen:
    BCL_GBI_waitFlushFIFO
    BCL_GBI_waitDMA
    BCL_GBI_cancelDMA
    BCL_GBI_conditionDMA
    BCL_GBI_syncCount
    BCL_GBI_resetModule
    Figure 01470001
    Figure 01480001
  • C.5.1.9 Abschalten der Ablaufverfolgungsfunktion (Nichtangabe)
  • Schaltet die Ablaufverfolgungsfunktion der Zugriffsbibliothek ab. Wenn die Ablaufverfolgungsfunktion abgeschaltet ist, wird es unmöglich, den Buszugriff und die Funktionen im Ablauf zu verfolgen.
  • Figure 01480002
  • C.5.1.10 Adressfilterspezifikation für die Ablaufverfolgungsfunktion (Nichtangabe)
  • Spezifiziert den Adressfilter für die Ablaufverfolgung des Buszugriffs. Eine einzelne Adresse oder kontinuierliche Adressen können, abhängig von dem Filtermodus, für das Filtern spezifiziert werden. Bis zu 16 Adressspezifikationen sind erlaubt. Wenn die Ablaufverfolgungsfunktion ermöglicht ist, werden lediglich diejenigen Adressen, welche auf eine beliebige der Adressspezifikationen passen, im Ablauf verfolgt.
  • Figure 01480003
  • Figure 01490001
  • C.5.1.11 Ausgabe der Information, welche für die Ablaufverfolgungsfunktion gesetzt wurde (Nichtangabe)
  • Gibt die gegenwärtig für die Ablaufverfolgungsfunktion gesetzte Information an den Standardausgabestrom. Diese Funktion ist zu verwenden, um zu überprüfen, ob die Ablaufverfolgungsfunktion ermöglicht oder abgeschaltet ist oder um die Einstellungen des Adressfilters zu überprüfen.
  • Figure 01490002
  • Figure 01500001
  • C.5.1.12 Vereinfachte Hilfsinformationsausgabe für die Ablaufverfolgungsfunktion (Nichtangabe)
  • Gibt die vereinfachte Hilfsinformation von der Ablaufverfolgungsfunktion an den Standardausgabestrom.
  • Figure 01500002
  • C.5.1.13 Registrierung der Ablaufverfolgungsfunktion (Nichtangabe)
  • Ersetzt eine vorgegebene Ablaufverfolgungsfunktion, welche die Ablaufverfolgung mit einer anderen Ablaufverfolgungsfunktion ausführt. Wenn die Ablaufverfolgungsfunktion ermöglicht ist, wird die registrierte Ablaufverfolgungsfunktion von der Zugriffsbibliotheksfunktion ausgeführt, um unmittelbar nach Registrierung im Ablauf verfolgt zu werden. Lediglich eine Funktion kann registriert werden. Wenn ein Versuch unternommen wird, eine Funktion zu registrieren, wenn bereits eine registriert ist, wird die vorher registrierte Funktion überschrieben. Die BCL_GBI_ioTraceResetHandler-Funktion ist auszuführen, um die Ablaufverfolgungsfunktion auf den vorgegebenen Wert zurückzusetzen.
  • Die Zugriffsbibliothek beinhaltet die folgenden Funktionen, welche die Ablaufverfolgung ausführen:
    BCL_GBI_write
    BCL_ GBI_read
    BCL_GBI_writeBlock
    BCL_GBI_readBlock
    BCL_GBI_writeSeq
    BCL_GBI_readSeq
    BCL_GBI_writeSyncDMA
    BCL_GBI_readSyncDMA
    BCL_GBI_writeAsyncDMA
    BCL_GBI_readAsyncDMA
    BCL_GBI_writeConfig
    BCL_GBI_readConfig
    BCL_GBI_waitFlushFIFO
    BCL_GBI_waitDMA
    BCL_GBI_cancelDMA
    BCL_GBI_conditionDMA
    BCL_GBI_syncCount
    BCL_GBI_resetModule
    Figure 01520001
  • C.5.1.14 Registrierung der vorgegebenen Ablaufverfolgungsfunktion (Nichtangabe)
  • Setzt eine durch die BCL_GBI_ioTraceHandler-Funktion ersetzte Ablaufverfolgungsfunktion auf den vorgegebenen Wert zurück.
  • Figure 01520002
  • C.5.1.15 Ausführung der vorgegebenen Ablaufverfolgungsfunktion (Nichtangabe)
  • Führt die vorgegebene Ablaufverfolgungsfunktion von einer von der BCL_GBI_ioTraceHandler-Funktion registrierten Ablaufverfolgungsfunktion aus.
  • Figure 01530001
  • Industrielle Anwendbarkeit
  • Wie oben beschrieben, werden gemäß der vorliegenden Erfindung der Prüfemulator, der Prüfmodul-Emulator und das Aufzeichnungsmedium, welches die Programme zum geeigneten Emulieren der Prüfvorrichtung, welche mit verschiedenen Modulen verwendet wird, zur Verfügung gestellt.

Claims (9)

  1. Prüfemulator (190) zum Emulieren einer Prüfvorrichtung (10), die mehrere Prüfmodul (170) zum jeweiligen Zuführen eines Prüfsignals zu geprüften Vorrichtungen (100) aufweist, welcher aufweist: mehrere Prüfmodul-Emulationsschaltungen (270) zum Emulieren der mehreren Prüfmodule (170), die das Prüfsignal auf der Grundlage verschiedener Zyklen erzeugen; eine Steueremulationsschaltung (230) zum Emulieren einer Steuervorrichtung (130) zum Steuern der Prüfung der geprüften Vorrichtungen (100); und eine synchrone Emulationsschaltung (250) zum Erzeugen von Prüfsignal-Erzeugungszeitpunkten, zu denen jede der mehreren Prüfmodul-Emulationsschaltungen (270) das Prüfsignal in einer Simulation entsprechend der Zykluszeit der Prüfmodul-Emulationsschaltung (270) erzeugen soll auf der Grundlage von Befehlen von der Steueremulationsschaltung (230); gekennzeichnet durch eine Zeitausrichtungsschaltung (276) zum Ausrichten der mehreren Prüfsignal-Erzeugungszeitpunkte, die von der synchronen Emulationsschaltung (250) erzeugt wurden, in zeitlicher Reihenfolge, und Ausgeben von diesen nacheinander; und eine Ablaufschaltung (277) zum Bewirken, dass die Prüfmodul-Emulationsschaltung (270) entsprechend einem der von der Zeitausrichtungsschaltung (276) ausgegebenen Prüfsignal-Erzeugungszeitpunkte das Prüfsignal in Simulation in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt erzeugt.
  2. Prüfemulator nach Anspruch 1, weiterhin aufweisend eine Simulationsschaltung (200) für eine geprüfte Vorrichtung zum Simulieren der Operation einer geprüften Vorrichtung (100) auf der Grundlage des simuliert erzeugten Prüfsignals.
  3. Prüfemulator nach Anspruch 1, bei dem die synchrone Emulationsschaltung (250) weiterhin Unterbrechungssammlungs-Zeitpunkte zum Sammeln von Unterbrechungen zu der simuliert durch jede der mehreren Prüfmodul-Emulationsschaltungen (270) erzeugten Steuervorrichtung (130) erzeugt während der Erzeugung des Prüfsignals in der Zykluszeit entsprechend den Prüfsignal-Erzeugungszeitpunkten, welche Zeitausrichtungsschaltung (276) die mehreren Prüfsignal-Erzeugungszeitpunkte und die mehreren Unterbrechungssammlungs-Zeitpunkte in zeitlicher Reihenfolge ausrichtet und sie nacheinander ausgibt, und die Ablaufschaltung (277) bewirkt, dass die Prüfmodul-Emulationsschaltung (270) entsprechend dem Unterbrechungssammlungs-Zeitpunkt der Steueremulationsschaltung (230) von der in der Zykluszeit, in der die Prüfmodul-Emulationsschaltung (270) das Prüfsignal direkt vor dem Unterbrechungssammlungs-Zeitpunkt erzeugt, simuliert erzeugten Unterbrechung unterrichtet, für den Fall, dass die Zeitausrichtungsschaltung (276) einen der Unterbrechungssammlungs-Zeitpunkte ausgibt.
  4. Prüfemulator nach Anspruch 1, bei dem jede der mehreren Prüfmodul-Emulationsschaltungen (270) Änderungszeitpunkte des Prüfsignals in der Zykluszeit bei der Erzeugung des Prüfsignals in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt erzeugt, und der Prüfemulator (190) weiterhin eine DUT-Verbindungsschaltung 280) zum Erwerben der mehreren Änderungszeitpunkte, die von den mehreren Prüfmodul-Emulationsschaltungen (270) erzeugt wurden, und zum simulierten Ändern des Prüfsignals nacheinander in zeitlicher Reihenfolge auf der Grundlage der mehreren Änderungszeitpunkte aufweist.
  5. Prüfemulator nach Anspruch 4, bei dem die DUT-Verbindungsschaltung (280) die mehreren Änderungszeitpunkte, die von den mehreren Prüfmodul-Emulationsschaltungen (270) erworben wurden, zu der Zeitausrichtungsschaltung (276) liefert, die Zeitausrichtungsschaltung (276) die mehreren Änderungszeitpunkte, die mehreren Prüfsignal-Erzeugungszeiten und die mehreren Unterbrechungssammlungs-Zeitpunkte in zeitlicher Reihenfolge ausrichtet und sie nacheinander ausgibt, und die Ablaufschaltung (277) bewirkt, dass die DUT-Verbindungsschaltung (280) das Prüfsignal zu dem Änderungszeitpunkt simuliert ändert, für den Fall, dass die Zeitausrichtungsschaltung (276) einen der Änderungszeitpunkte ausgibt.
  6. Prüfemulator nach Anspruch 1, bei dem jede der mehreren Prüfmodul-Emulationsschaltungen (270) die synchrone Emulationsschaltung (250) von der Zyklusendzeit unterrichtet, zu der die Zykluszeit während der Erzeugung des Prüfsignals in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt endet, und die synchrone Emulationsschaltung (250) die Prüfsignal-Erzeugungszeitpunkte erzeugt, zu denen die Prüfmodul-Emulationsschaltung (270) das Prüfsignal entsprechend der nächsten Zykluszeit simuliert erzeugt auf der Grundlage der von jeder der mehreren Prüfmodul-Emulationsschaltungen (270) mitgeteilten Zyklusendzeit.
  7. Prüfemulator nach Anspruch 6, bei dem die Ablaufschaltung (277) bewirkt, dass die von der Prüfmodul-Emulationsschaltung (270) entsprechend dem Prüfsignal-Erzeugungszeitpunkt simuliert erzeugte Unterbrechung der Steueremulationsschaltung (230) während der Erzeugung des Prüfsignals in der Zykluszeit direkt vor dem Prüfsignal-Erzeugungszeitpunkt mitgeteilt wird für den Fall, dass die Zeitausrichtungsschaltung (276) den Prüfsignal-Erzeugungszeitpunkt entsprechend der nächsten Zykluszeit ausgibt.
  8. Prüfemulator nach Anspruch 1, bei dem jede der mehreren Prüfmodul-Emulationsschaltungen (270) realisiert ist durch Betätigen eines Prüfmodul-Emulationsprogramms entsprechend der Prüfmodul-Emulationsschaltung (270) mittels eines Computers, wobei das Prüfmodul-Emulationsprogramm aufweist: mehrere Hardware-Emulationsfunktionen, die entsprechend mehreren Befehlen vorgesehen sind, die jeweils durch das Prüfmodul (170) von der Steu ervorrichtung (130) empfangen sind, zum Emulieren der Operation des Prüfmoduls (170) entsprechend dem Befehl, und eine Steuerfunktion, die verwendet wird, damit die Ablaufschaltung (277) bewirkt, dass der Prüfemulator (190) das Prüfsignal in der Zykluszeit entsprechend dem Prüfsignal-Erzeugungszeitpunkt erzeugt.
  9. Aufzeichnungsmedium, das ein Programm speichert, das bewirkt, dass ein Computer als ein Prüfemulator nach Anspruch 1 funktioniert.
DE602004007498T 2003-03-31 2004-03-30 Testemulationseinrichtung Expired - Lifetime DE602004007498T2 (de)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US10/403,817 US7290192B2 (en) 2003-03-31 2003-03-31 Test apparatus and test method for testing plurality of devices in parallel
US404002 2003-03-31
US403817 2003-03-31
US10/404,002 US7460988B2 (en) 2003-03-31 2003-03-31 Test emulator, test module emulator, and record medium storing program therein
PCT/JP2004/001649 WO2004072670A1 (en) 2003-02-14 2004-02-16 Method and structure to develop a test program for semiconductor integrated circuits
WOPCT/JP2004/001 2004-02-16
PCT/JP2004/001648 WO2004072669A1 (en) 2003-02-14 2004-02-16 Method and apparatus for testing integrated circuits
PCT/JP2004/004527 WO2004090562A1 (ja) 2003-03-31 2004-03-30 試験エミュレート装置、試験モジュールエミュレート装置、及びこれらのプログラムを記録した記録媒体

Publications (2)

Publication Number Publication Date
DE602004007498D1 DE602004007498D1 (de) 2007-08-23
DE602004007498T2 true DE602004007498T2 (de) 2008-03-13

Family

ID=33161956

Family Applications (2)

Application Number Title Priority Date Filing Date
DE602004016891T Expired - Lifetime DE602004016891D1 (de) 2003-03-31 2004-03-30 Testvorrichtung
DE602004007498T Expired - Lifetime DE602004007498T2 (de) 2003-03-31 2004-03-30 Testemulationseinrichtung

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE602004016891T Expired - Lifetime DE602004016891D1 (de) 2003-03-31 2004-03-30 Testvorrichtung

Country Status (7)

Country Link
EP (3) EP1870724A1 (de)
JP (1) JP3735636B2 (de)
KR (1) KR20050113273A (de)
DE (2) DE602004016891D1 (de)
MY (1) MY134825A (de)
TW (1) TWI389033B (de)
WO (1) WO2004090562A1 (de)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7460988B2 (en) 2003-03-31 2008-12-02 Advantest Corporation Test emulator, test module emulator, and record medium storing program therein
US7913002B2 (en) 2004-08-20 2011-03-22 Advantest Corporation Test apparatus, configuration method, and device interface
JP2006275986A (ja) 2005-03-30 2006-10-12 Advantest Corp 診断プログラム、切替プログラム、試験装置、および診断方法
KR100731106B1 (ko) * 2005-12-29 2007-06-22 동부일렉트로닉스 주식회사 라이브러리 테스트 회로 및 그 방법
KR100768916B1 (ko) * 2006-07-03 2007-10-19 삼성전자주식회사 패킷 수집/분석 장치 및 이를 이용한 에뮬레이션 방법
JP5023582B2 (ja) * 2006-07-05 2012-09-12 横河電機株式会社 半導体集積回路試験装置及び方法
KR100873956B1 (ko) * 2006-08-17 2008-12-15 삼성전자주식회사 에뮬레이션 시스템
KR100884983B1 (ko) * 2007-06-26 2009-02-23 주식회사 동부하이텍 표준 셀 라이브러리의 성능 개선을 위한 측정 장치
US20090119084A1 (en) * 2007-11-05 2009-05-07 Advantest Corporation System, method, and program product for simulating test equipment
US7779313B2 (en) * 2008-03-30 2010-08-17 Advantest Corporation Testing apparatus and testing method
US8165027B2 (en) 2008-12-08 2012-04-24 Advantest Corporation Test apparatus and test method
KR20110003182A (ko) 2009-07-03 2011-01-11 삼성전자주식회사 인쇄 회로 기판 설계 방법 및 인쇄 회로 기판을 포함하는 패키지 테스트 디바이스
JP2013113665A (ja) * 2011-11-28 2013-06-10 Advantest Corp 試験パターン生成装置、試験プログラム生成装置、生成方法、プログラム、および試験装置
KR101310609B1 (ko) * 2012-03-30 2013-09-24 주식회사 이노와이어리스 Ｙａｍｌ을 이용하여 ｌｔｅ 계측 장비를 위한 데이터 및 인터페이스 생성장치 및 생성방법
CN108628734B (zh) * 2017-03-21 2023-03-28 中兴通讯股份有限公司 一种功能程序调试方法和终端
KR102583174B1 (ko) 2018-06-12 2023-09-26 삼성전자주식회사 테스트 인터페이스 보드, 이를 포함하는 테스트 시스템 및 이의 동작 방법
CN111949365B (zh) * 2019-05-17 2024-06-18 中车株洲电力机车研究所有限公司 离线仿真方法及计算机存储介质
US11302412B2 (en) * 2019-06-03 2022-04-12 Advantest Corporation Systems and methods for simulated device testing using a memory-based communication protocol
CN111447016B (zh) * 2020-04-02 2022-06-21 上海创远仪器技术股份有限公司 针对信道模拟器的信道模型实现正确性验证处理的方法
CN113624250B (zh) * 2020-05-09 2024-05-10 航天科工惯性技术有限公司 一种自动温循测试装置和方法
TWI719917B (zh) * 2020-07-14 2021-02-21 金麗科技股份有限公司 將類比動態電路運用於數位測試工具的處理方法
CN113157573B (zh) * 2021-04-19 2024-06-07 上海湃星信息科技有限公司 一种软件测试验证系统及其构建方法
TWI772189B (zh) * 2021-09-24 2022-07-21 英業達股份有限公司 硬碟模擬裝置及應用該裝置的測試系統及其測試方法
CN115774663B (zh) * 2022-09-15 2024-07-09 江苏瑞蓝自动化设备集团有限公司 一种LabVIEW的测试系统的优化方法、装置、设备及存储介质
KR102558492B1 (ko) * 2022-10-12 2023-07-25 한국철도기술연구원 열차자동운행장치 시뮬레이션 고속화 시스템 및 이를 이용한 고속화 방법

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2570558B2 (ja) * 1992-11-20 1997-01-08 日本電気株式会社 ハードウェア・エミュレータ
JP2001184225A (ja) * 1999-12-27 2001-07-06 Toshiba Microelectronics Corp エミュレータ及びエミュレート方法

Also Published As

Publication number Publication date
JP3735636B2 (ja) 2006-01-18
KR20050113273A (ko) 2005-12-01
TWI389033B (zh) 2013-03-11
EP1870724A1 (de) 2007-12-26
EP1767955A1 (de) 2007-03-28
EP1610136A1 (de) 2005-12-28
EP1767955B1 (de) 2008-10-01
MY134825A (en) 2007-12-31
DE602004007498D1 (de) 2007-08-23
WO2004090562A1 (ja) 2004-10-21
JPWO2004090562A1 (ja) 2006-07-06
EP1610136A4 (de) 2006-05-17
DE602004016891D1 (de) 2008-11-13
EP1610136B1 (de) 2007-07-11
TW200428200A (en) 2004-12-16

Similar Documents

Publication Publication Date Title
DE602004007498T2 (de) Testemulationseinrichtung
DE602004012714T2 (de) Verfahren und Struktur zum Entwickeln eines Prüfprogramms für Halbleiterschaltkreise
DE112020000469T5 (de) Automatisierte testeinrichtung, die ein auf-chip-system-teststeuergerät verwendet
DE602004011320T2 (de) Verfahren und struktur zur entwicklung eines testprogramms für integrierte halbleiterschaltungen
DE602005003225T2 (de) Verfahren und system zum simulieren eines modularen testsystems
DE69834892T2 (de) Eingebetteter Logikanalysator
DE10196310B4 (de) Vorrichtung und Verfahren zum Verifizieren eines Chip-Designs und zum Testen eines Chips
DE3787431T2 (de) Verfahren zur Generierung einer Kandidatenliste von fehlerhaften Schaltungselementen und Verfahren zur Isolierung von Fehlern in einer logischen Schaltung unter Verwendung dieser Kandidatenliste.
DE10010043C2 (de) Halbleitervorrichtung-Simulationseinrichtung und zugehörige Halbleitertestprogramm-Debugging-Einrichtung
DE60113780T2 (de) Verfahren und Vorrichtung zum Verfolgen von Hardwarezustanden mit dynamischen rekonfigurierbaren Testschaltungen
DE19959157C2 (de) Verbessertes Funktionstesten durch das Filtern von groben Mutationen
DE10392667T5 (de) Ereignisbasiertes IC-Testsystem
DE10392497T5 (de) Herstellungsverfahren und Herstellungsvorrichtung zum Vermeiden eines Prototypen-Aufschubs bei der ASIC/SOC-Herstellung
JP2004509425A (ja) テストコントローラアクセスデータを用いて回路をテスト及び／または診断する方法及びシステム
DE10333817A1 (de) Emulationsschnittstellensystem
JP2006518460A5 (de)
US7047174B2 (en) Method for producing test patterns for testing an integrated circuit
DE10004198C2 (de) System und Verfahren für eine intelligente Analysesonde
JP2007057541A (ja) 試験エミュレート装置
DE60118089T2 (de) Abtastschnittstelle mit Zeitmultiplexmerkmal zur Signalüberlagerung
DE69030792T2 (de) Methode und Gerät zur Wechselwirkung-Emulation zwischen einer anwendungsspezifischen integrierten Schaltung (ASIC) während der Entwicklung und ein Zielsystem
CN1618082A (zh) 用户定义处理功能
EP1469320B1 (de) Verfahren zur Generierung von Testersteuerungen
JP2005285092A (ja) 試験エミュレート装置
EP1632855A1 (de) Funktionseinheit zur Ausführung von logischen Testfällen auf einem an eine zu prüfende Einheit angekoppelten Testsystem und entsprechendes Verfahren

Legal Events

Date Code Title Description
8364 No opposition during term of opposition