-
GEBIET DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft den Bereich von automatisierten Messeinrichtungen
(ATE). Im Speziellen betrifft die vorliegende Erfindung ein Verfahren
und System zur Simulierung eines modularen Testsystems.
-
Modulare
Testsysteme in einer offenen Architektur sind beschrieben in:
- 1.)
RAJSUMAN R: "An
overview of the open architecture test system" PROCEEDINGS. DELTA 2004. SECOND IEEE
INTERNATIONAL WORKSHOP ON ELECTRONIC DESIGN, TEST AND APPLICATIONS
IEEE COMPUT. SOC LOS ALAMITOS, CA, USA, 30. Januar 2004, Seiten
341–346,
XP002336194 ISBN: 0-7695-2081-2
- 2.) US4 807 161
A1 (COMFORT ET AL.) 21. Februar 1989
-
HINTERGRUND DER ERFINDUNG
-
Ein
Hauptkostenfaktor bei der Halbleiterherstellung ist die Entwicklung
und Wartung von Testprogrammen, die integrierte Schaltungen auf
Realisierbarkeit und Funktionalität testen. Diese Aktivität führt normalerweise
zu stundenlanger Arbeit an der eigentlichen Messgeräte-Hardware. Bestehende
Halbleitermessgeräte haben
jedoch kaum oder kein Potential zur Simulation von Testprogrammen,
außer
dem Überprüfen der
Semantik der Sprache der Testprogrammierung. Diese Beschränkung zwingt
Ingenieure dazu, Fehler ihrer Testprogramme auf der eigentlichen
Messgeräte-Hardware
zu suchen und zu beseitigen. Aber die Verwendung von Messgeräte-Hardware
zur Testprogrammentwicklung ist keine kosteneffiziente Anwendung
der teuren Messeinrichtungen. Außerdem ist die Zeit, die zur
Verwendung des Messgeräts
zur Verfügung
steht, begrenzt, da ein Messgerät
normalerweise von Gruppen von Ingenieuren gemeinsam genutzt wird,
was einen Engpass bei der Entwicklung von Testprogrammen schafft,
der einen Prozess zur Folge hat, in dem Entwicklung seriell auftritt.
Solche Beschränkungen
bei der Testprogrammentwicklung können die Herstellung der integrierten Schaltungen
verzögern,
wodurch die Freigabe des Produkts verzögert werden könnte und
Marktchancen verloren gehen.
-
Daher
besteht Bedarf an einem Verfahren und System zur Verifizierung der
Testprogrammfunktionalität
ohne Verwendung von teuren Messeinrichtungen. Im Speziellen besteht
Bedarf an einem Verfahren und System zur Simulierung eines modularen
Testsystems mit Testprogrammen, Lieferantenmodulen und ihren entsprechenden
zu testenden Vorrichtungen (DUTs).
-
Eine
Aufgabe der vorliegenden Erfindung ist es, den Verwendungsumfang
von Messgeräte-Hardware zur Testprogrammentwicklung
zu verringern, um dabei die Verwendung der wertvollen Messeinrichtungen
zu optimieren. Eine weitere Aufgabe der vorliegenden Erfindung ist
die Identifizierung von Problemen bei den Testprogrammen, Modulen
und DUTs bevor sie auf den Messgeräts-Einrichtungen ausgeführt werden.
Noch eine weitere Aufgabe der vorliegenden Erfindung ist es, eine
Umgebung für
die parallele Entwicklung von Testprogrammen, Modulen und DUTs bereitzustellen,
um dabei die Gesamtentwicklungszeit des Produkts zu verringern.
-
ZUSAMMENFASSUNG
-
Das
offenbarte Verfahren zur Simulierung eines modularen Testsystems
stellt einen Simulationsrahmen bereit, der von einem Endanwender
konfiguriert werden kann. Der Rahmen wird verwendet, um eine Simulationsumgebung
zu schaffen, um Lieferantenemulationsmodule und DUT-Modelle zu laden
und um Testprogramme durch die API des Simulationsrahmens auszuführen. Dieses
Verfahren ermöglicht
es, neue Lieferantenmodule zu einer bestehenden Installation hinzuzufügen, indem
die Softwareemulation des Lieferanten installiert wird und eine
Systemkonfigurations-Datei editiert wird. Dieses Verfahren ermöglicht es
Ingenieuren ebenfalls, Testprogramme auf ihren eigenen Arbeitsplatzsystemen
mit verringerter Verwendung der teuren Messeinrichtungen zu entwickeln.
-
Bei
einer Ausführungsform
beinhaltet ein Verfahren zur Simulierung eines modularen Testsystems
das Bereitstellen eines Kontrollers, wo der Kontroller mindestens
ein Lieferantenmodul und sein entsprechendes DUT-Modell kontrolliert,
wobei ein Simulationsrahmen zur Erstellung von Standard-Schnittstellen
zwischen dem mindestens einen Lieferantenmodul und seinem entsprechenden
DUT-Modell erstellt wird, der Simulationsrahmen konfiguriert wird
und das modulare Testsystem unter Verwendung des Simulationsrahmens
simuliert wird.
-
Bei
einer weiteren Ausführungsform
beinhaltet ein modulares Testsystem eines oder mehrere Lieferantenmodule,
eines oder mehrere DUT-Modelle, einen Kontroller zum Kontrollieren
der Lieferantenmodule und ihrer entsprechenden DUT-Modelle und einen
Simulationsrahmen zur Erstellung von Standard-Schnittstellen zwischen
den Lieferantenmodulen und den DUT-Modellen. Das modulare Testsystem beinhaltet
ferner Mittel zur Konfigurierung des Simulationsrahmens und Mittel
zur Simulierung des modularen Testsystems unter Verwendung des Simulationsrahmens.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Die
vorstehend erwähnten
Merkmale und Vorteile der Erfindung sowie zusätzliche Merkmale und Vorteile
davon werden nachstehend vollständiger
verstanden werden als Ergebnis der ausführlichen Beschreibungen der
erfindungsgemäßen Ausführungsformen,
wenn sie mit den folgenden Zeichnungen in Verbindung gebracht werden.
-
1a stellt
ein offenes Architektur-Testsystem dar.
-
1b stellt
einen Überblick über das
Simulationssystem einer erfindungsgemäßen Ausführungsform dar.
-
2 stellt
einen Simulationsrahmen zur Simulierung des modularen Testsystems
dar.
-
3a stellt
einen Simulationsrahmen zur Handhabung von Simulationskanal-Objekten
gemäß einer erfindungsgemäßen Ausführungsform
dar.
-
3b stellt
den Schritt, den Anstieg und analoge Wellenformen gemäß einer
erfindungsgemäßen Ausführungsform
dar.
-
4 stellt
einen Simulationsrahmen zur Handhabung von Simulationskomponenten
gemäß einer
erfindungsgemäßen Ausführungsform
dar.
-
5 stellt
einen Simulationsrahmen zur Handhabung von Simulations-Ereignis-Objekten
gemäß einer
erfindungsgemäßen Ausführungsform
dar.
-
6 stellt
einen Kanal zwischen dem Emulationsmodul und dem Ladebord-Modell
gemäß einer
erfindungsgemäßen Ausführungsform
dar.
-
BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
-
Verfahren
und Systeme sind bereit gestellt zur Simulierung eines modularen
Testsystems. Die folgenden Beschreibungen werden vorgestellt, um
es jedem Fachmann zu ermöglichen,
die Erfindung zu fertigen und zu verwenden. Beschreibungen bestimmter
Ausführungsformen
und Anwendungen werden nur als Beispiele bereitgestellt. Verschiedene Änderungen
und Kombinationen der hier beschriebenen Beispiele werden den Fachleuten
sofort offenkundig sein und die hier definierten allgemeinen Grundsätze können auf
andere Beispiele und Anwendungen angewandt werden, ohne von dem
Umfang der Erfindung abzuweichen. Somit soll die vorliegende Erfindung
nicht auf die beschriebenen und gezeigten Beispiele beschränkt sein,
sondern ihr wird der größte Umfang
eingeräumt,
der mit den hier offenbarten Grundsätzen und Merkmalen in Einklang steht.
-
1a stellt
ein offenes Architektur-Testsystem dar. Ein System-Kontroller (SysC) 102 ist
mit multiplen Site-Kontrollern (SiteCs) 104 gekoppelt.
Der System-Kontroller kann ebenfalls mit einem Netzwerk verbunden sein,
um auf zugeordnete Dateien zuzugreifen. Durch einen Modul-Verbindungsenabler 106 ist
jeder Site-Kontroller gekoppelt, um eines oder mehrere Testmodule 108 zu
kontrollieren, die an einem Testort 110 angeordnet sind.
Der Modul-Verbindungsenabler 106 ermöglicht die
Rekonfiguration verbundener Hardware-Module 108 und dient
ebenfalls als ein Bus zum Datentransfer (zum Laden von Muster-Daten,
Sammeln von Antwort-Daten, Bereitstellen von Kontrolle, etc.). Zusätzlich kann
ein Modul an einer Site durch den Modul-Verbindungsenabler auf ein
Modul an einer anderen Site zugreifen. Der Modul-Verbindungsenabler 106 ermöglicht es,
dass verschiedene Testorte die gleichen oder verschiedene Modul-Konfigurationen
aufweisen. Mit anderen Worten kann jeder Testort eine verschiedene
Anzahl und Typen von Modulen einsetzen. Mögliche Hardware- Implementierungen
beinhalten zugeordnete Verbindungen, Schalter-Verbindungen, Bus-Verbindungen, Ring-Verbindungen
und Stern-Verbindungen. Der Modul-Verbindungsenabler 106 kann
durch eine Schalter-Matrix implementiert sein. Jeder Testort 110 ist
beispielsweise an einen DUT 112 angeschlossen, der mit
den Modulen der entsprechenden Sites über ein Ladebord 114 verbunden
ist. Bei einer weiteren Ausführungsform
kann ein einzelner Site-Kontroller
mit multiplen DUT-Sites verbunden sein.
-
Der
System-Kontroller 102 dient als der Gesamt-Systemmanager.
Er koordiniert die Site-Kontroller
Aktivitäten,
regelt die parallelen Teststrategien auf Systemebene und gewährleistet
zusätzlich
Steuerungsbetrieb-/Messfühlerkontrollen
sowie Datenerfassung auf Systemebene und Fehlerbehebungsunterstützung. Der System-Kontroller 102 ist
der Hauptpunkt der Interaktion für
einen Testingenieur bei der Verifizierung und Fehlersuche sowie
-beseitigung der Testumgebung. Er stellt eine Schnittstelle zu den
Site-Kontrollern 104 bereit und regelt die Synchronisation
der Site-Kontroller Aktivitäten
in einer multi-DUT-Umgebung. Er führt ferner Benutzeranwendungen
und Werkzeuge, wie das Test-Simulations-Modul, aus. Abhängig von
der Betriebseinstellung kann der System-Kontroller 102 auf
eine CPU angewandt werden, die von dem Betrieb von Site-Kontrollern 104 getrennt
ist. Alternativ kann eine herkömmliche
CPU von dem System-Kontroller 102 und den Site-Kontrollern 104 geteilt
werden. Ebenso kann jeder Site-Kontroller 104 auf seine
eigene zugeordnete CPU (central processing unit) angewandt werden
oder als separater Prozess oder Thread innerhalb der gleichen CPU.
-
Die
Site-Kontroller 104 sind verantwortlich dafür, dass
ein Testplan durchgeführt
wird, um die DUTs zu testen. Der Testplan erzeugt spezifische Tests
unter Verwendung der Rahmen-Klassen
sowie Standard- oder Benutzergelieferte Test-Klassen, die die prüftechnischen
Gesichtspunkte kapseln. Zusätzlich
konfiguriert der Testplan die verwendende Hardware über die
Standard-Schnittstellen und definiert den Testablauf.
-
Die
erfindungsgemäße Systemarchitektur
kann konzeptionell wie das in 1 gezeigte
verteilte System vorgesehen sein, vorausgesetzt, dass die einzelnen
Systemkomponenten ebenfalls als logische Komponenten eines integrierten
monolithischen Systems gesehen werden können und nicht notwendigerweise
als physikalische Komponenten eines verteilten Systems. Die Plug-and-Plag-
oder austauschbaren Module werden durch Verwendung von Standard-Schnittstellen
sowohl auf Hardware- als auch auf Softwareebene unterstützt. Ein Messgeräte-Betriebssystem
(TOS) ermöglicht
es einem Benutzer, Testplan-Programme unter Verwendung einer Testplan-Programmiersprache
zu schreiben und das Testsystem auf eine einer bestimmten zu testenden
Vorrichtung (DUT) spezifischen Art und Weise zu betreiben. Es ermöglicht dem
Benutzer ebenfalls, Sequenzen der Testsystem-Vorgänge, die üblicherweise
in den Testplan-Programmen verwendet werden, als Bibliotheken zusammenzufassen.
Diese Bibliotheken werden manchmal als Test-Klassen und Test-Vorlagen bezeichnet.
-
1b stellt
einen Überblick
des Simulationssystems einer erfindungsgemäßen Ausführungsform dar. Das Simulationssystem
beinhaltet ein Kontroller-Modell 121, eines oder mehrere
Lieferantenemulationsmodule 122 (beachten Sie, dass der
Begriff Lieferantenemulationsmodul ebenfalls als Lieferantenmodul
oder Emulationsmodul bezeichnet wird), eines oder mehrere zu testende
Vorrichtungs-(DUT)-Modelle 124 und ein Ladebord-Modell 126.
Um die Simulationsumgebung zusammenzustellen, erzeugt der Benutzer
eine System-Konfigurations-Datei und eine Offline-Konfigurations-Datei
(beide werden nachstehend ausführlich
beschrieben), die beschreiben, wie die Emulationsmodule, Ladebord-Modelle
und DUT-Modelle durch den Simulationsrahmen verbunden sind. Die
Simulations-Durchführung
wird auf dem Muster durchgeführt,
das in die Modul-Modelle durch das Testprogramm geladen ist.
-
Der
Simulationsrahmen versorgt das Ladebord-Modell 106, einen
oder mehrere Messgerätskanäle 128 und
einen oder mehrere DUT-Kanäle 130.
Die Module werden von dynamic link libraries (DLLs) von Lieferanten
geladen. Jeder Block steht für
eine einzige Instanz eines Moduls. Ein DLL kann mehrmals geladen werden,
um viele Instanzen des gleichen Modultyps zu erzeugen. Die DUT-Modelle 124 können entweder
als DLLs versorgt werden, wenn das Modell in C++ geschrieben ist,
oder als Verilog-Modi.
-
Das
Ladebord-Modell 126 kann durch den Benutzer konfiguriert
werden. Der Benutzer bildet die Messgerätskanäle 128 auf die entsprechenden
DUT-Kanäle 130 ab
und spezifiziert eine mit jeder Verbindung in Zusammenhang stehende
Transportverzögerung.
Alle Verbindungen sind bidirektional, somit muss Nichts speziell
beachtet werden, um Verbinder als Ausgangstreiber oder Impulseingang
zu kennzeichnen.
-
Simulationsrahmen
-
Ein
Hauptteil der Testsystem-Simulation ist der Simulationsrahmen, der
ebenfalls als der Rahmen bezeichnet wird. Der Rahmen stellt zwei
grundlegende Leistungen bereit. Erstens ermöglicht er es jedem Lieferantenmodul
auf im Wesentlichen die gleiche Art und Weise programmiert zu werden,
wie während
normaler Messgerätsvorgänge durch
den System-Bus. Indem Bus-Aufrufe simuliert werden. kann ein Testprogramm
in nachgeahmte Modulverzeichnisse schreiben, wobei Tests aufgestellt
werden. Die andere Leistung ist die Simulation einer Testdurchführung. Der
Rahmen stellt ein Modell für
die physikalischen Verbindungen zwischen den nachgeahmten Modulen
und dem DUT-Modell bereit. Der Rahmen versorgt ebenfalls eine Maschine
zur Aufrechterhaltung der Durchführungssequenz
der verschiedenen Simulationskomponenten.
-
Wenn
sich das Testsystem in dem Simulationsmodus (Offline Modus) befindet,
ersetzt es den Gerätetreiber,
der verwendet wird, um mit der Messgeräts-Modul-Hardware zu kommunizieren,
durch ein Softwaremodul, das mit dem Rahmen über einen gemeinsam genutzten
Speicher kommuniziert. Bei dem eigentlichen Messgerät wird die
Kommunikation zu den Modulen durch ein als ein Bus bekanntes Hardware-Modul
erleichtert. Ein Bus verwendet typischerweise Befehle, die ein binäres Muster
an ein adressierbares Verzeichnis in einem Hardwaremodul eines Lieferanten
senden. In der Simulation wird der gleiche Befehl empfangen und durch
den Rahmen interpretiert, um auf ein spezifisches nachgeahmtes Modul
zu zielen. Der Rahmen sendet dann die Verzeichnisadresse und -daten
an das Modul, sodass es die Daten in seinem simulierten Verzeichnis speichern
kann. Da das Laden des Testprogramms schließlich in diese grundlegenden
Einheiten von Adress-/Datenpaaren zerlegt ist, unterstützt dieses
einfache Modell alle Interaktionen, die das Testprogramm mit den
Modulen hat. Ein Nebenprodukt dieses Prozesses ist eine Simulation,
die ebenfalls Kalibrierung und diagnostische Programmentwicklung
unterstützt.
-
Da
der einzige Unterschied der Laufzeit-Software zwischen Online- und
Offline-Modi in dem Systembus-Gerätetreiber liegt, gibt es ein
hohes Maß an Übereinstimmung
zwischen dem Verhalten eines Testprogramms in der Online-Umgebung
und seinem entsprechenden Verhalten in der Offline-Umgebung. Somit
ist die Simulation hinsichtlich des Verhaltens des Testprogramms
des Benutzers und dem zugrunde liegenden Messgeräts-Betriebssystem (TOS) genau.
-
Der
Rahmen stellt ebenfalls ein detailliertes Modell der physikalischen
Verbindungen zwischen den Messgeräts-Modulen und dem DUT bereit.
Alle Verbindungen sind als Spannungen auf einem Draht modelliert,
wodurch sie die zugrunde liegende Physik wiedergeben. Da es keine
Voraussetzungen bezüglich
der Datenformate bei den Modul/DUT-Interaktionen gibt, arbeitet der Rahmen
mit jeder Kombination von Emulationsmodulen und DUT-Modellen, solange
sie die von dem Rahmen erstellte Anwendungs-Programmier-Schnittstelle (API)
verwenden. Der Rahmen stellt einen automatischen Abgleich von Spannungen
bereit, wenn zwei Versorgungen gleichzeitig auf dem gleichen Draht
laufen.
-
Um
die Simulation während
der Durchführung
eines Testprogramms zu kontrollieren, stellt der Rahmen verschiedene
Methoden in seiner API bereit, die es den Modulen eines Lieferanten
ermöglichen,
sich für Ereignisse
zu registrieren und diese zu empfangen. Der Rahmen verwendet diese
Ereignisse, um die Durchführungssequenz
der nachgeahmten Module und DUT-Modelle zu kontrollieren. Indem
diese Ereignisse geregelt werden und indem einige grundlegende Regeln
bezüglich
der Handhabung eines Ereignisses durch ein Modul spezifiziert werden,
wird den Benutzern des modularen Testsystems eine flexible Vorlage
zur Erzeugung von Modul-Emulationen bereitgestellt.
-
2 stellt
einen Simulationsrahmen zur Simulierung des modularen Testsystems
dar. Der Simulationsrahmen beinhaltet eine Simulationsmanager-(SimMgr)-Klasse 202,
eine Simulationskanal-(SimChannel)-Klasse 204, eine Simulationskomponenten-(SimComponent)-Klasse 206 und
eine Simulations-Ereignis-Manager-(SimEventMgr)-Klasse 208.
Die SimMgr-Klasse 202 regelt den Simulationsprozess. Die
SimComponent 206 ist eine Basisklasse zur Verwendung für Lieferanten.
Bestimmte benötigte
Verhalten sind in dieser Klasse implementiert. Viele der Methoden
sind virtuell (in C++) und erfordern eine Lieferantenimplementierung.
Die CAnalogModule-Klasse 210, welche von der SimComponent-Klasse 206 erbt,
wird für
das Hinzufügen
der benötigten
lieferantenspezifischen Funktionalität verwendet.
-
Die
CAnalogModule-Klasse 210 beinhaltet eine Menge von SimChannel-abgeleiteten
Objekten, nämlich
ein CSimAWG-Objekt 212 und ein CsimDigitizer-Objekt 214.
Diese Objekte stellen die Systemressourcen (IResource-abgeleitete
Klassen in der Kontrollstruktur) dar, wo das CSimAWG-Objekt ein
analoger Wellenformgeber ist, der einen D/A-Kanal (analoger Ausgang
von einem digitalen Befehl) modelliert und das CSimDigitizer-Objekt
einen entsprechenden A/D-Kanal (digitaler Eingang von einem analogen
Aufruf) modelliert. Die IResource-abgeleiteten Klassenanforderungen
sind in diese Implementierungsklassen eingebracht und diese Klassen
verwenden vom System bereitgestellte Hilfsmittel zur Erzeugung und
zum Lesen von Wellenformen. Die SimEventMgr-Klasse 208 beinhaltet
ferner ein Simulationsereignis-Objekt 216. Eine ausführliche Beschreibung
jeder Komponente des Simulationsrahmens ist nachstehend beschrieben.
-
Der
Simulationsrahmen setzt einen Satz von vordefinierten Schnittstellen
und Beschränkungen
im Entwurf für
die Emulationsmodul- und DUT-Modell-Entwickler durch. Dies stellt
sicher, dass Modelle, die den Anforderungen des Simulationsrahmens
entsprechen, mit anderen Komponenten in der Simulation kompatibel sind.
Der Simulationsrahmen ist in drei Teile geteilt, wobei ein erster
Teil für
die API, die sowohl den Emulationsmodulen als auch den DUT-Modellen
gemeinsam ist, ein zweiter Teil, der spezifisch für die Modul-Modelle ist und ein
dritter Teil, der spezifisch für
die DUT-Modelle ist. Bei einer Implementierung gelten Lieferantenemulationsmodule
als ereignisbasierte Modelle, während
DUT-Modelle als zeitbasierte Modelle gelten. Bei anderen Ausführungsformen
können
sowohl Emulationsmodule als auch die DUT-Modelle entweder ereignisbasierte
oder zeitbasierte Modelle sein.
-
Simulationskanal
-
3a stellt
einen Simulationsrahmen zur Handhabung von Simulationskanal-Objekten
gemäß einer erfindungsgemäßen Ausführungsform
dar. Der Simulationsrahmen beinhaltet eine Modul-Klasse 302,
eine DUT-Klasse 304 und eine Simulationskanal-(SimChannel)-Klasse 306.
Die SimChannel-Klasse 306 beinhaltet eine Simulationsfrequenz-Iterator-(SimWaveformIter)-Klasse 308 und
die Modul-Klasse 302 beinhaltet eine Simulationskanal-Identifikator-(SimChanlD)-Klasse 310.
-
Die
SimChannel-Klasse 306 stellt den Emulationsmodulen und
den DUT-Modellen I/O-Potentiale über die
Modul-Klasse 302 bzw. die DUT-Klasse 304 während der
Musterdurchführung
bereit. Um diese Klasse zu verwenden, wird für jeden Modul-Kanal oder DUT-Pin
ein leeres Kanal-Objekt geschaffen. Basierend auf den Einstellungen
in der Simulations-Konfigurations-Datei (nachstehend beschrieben),
sind diese Kanäle
mit dem entsprechenden Kanal auf dem Ladebord durch den Simulationsrahmen
verbunden. Der Simulationsrahmen erhält eine Referenz an das SimChannel-Objekt über die
getChannel()-Methode,
die verwendet wird, um die Ladebord-Verbindung herzustellen.
-
Die
sowohl dem Modul und den DUT-Modellen gemeinsamen Elemente sind
die I/O-Aufrufe an die Kanäle.
Alle I/O-Aufrufe zwischen Modulen und DUTs werden ausgeführt, indem
die Spannungsniveaus zu bestimmten Zeiten eingestellt werden. Dies
wird durch die set()-Methode
von der SimChannel-Klasse 306 bereitgestellt. Diese Methode
ermöglicht
es der aufrufenden Routine, eine Spannung zu einer bestimmten Zeit
festzulegen, indem ein Eintrag in den mit der SimChannel-Klasse 306 verbundenen
Ausgabepuffer geschrieben wird.
-
Bei
einer Ausführungsform
schreibt die set()-Methode einen Zeitpunkt in die Spannungs-Zeit-Historie. Die Form
der Wellenform hängt
davon ab, wie der Kanal konfiguriert ist. 3b stellt
den Schritt, den Anstieg und analoge Wellenformen gemäß einer
erfindungsgemäßen Ausführungsform
dar. Bei einem Schritt-Kanal ist der Spannungswechsel unverzögert, sodass
jedes Lesen zwischen t1 und t2 eine Spannung von v1 ergibt. Bei einem
Anstiegs-Kanal, nimmt der Spannungswechsel von seinem gegenwärtigen Zustand
zu dem befohlenen Zustand eine endliche Zeit in Anspruch. Der Anstieg
des Wechsels wird durch die slewRate-Parameter im Anstiegsteil der
System-Konfigurations-Datei bestimmt. In einem analogen Kanal schließlich bleibt
die Spannung nicht gleich. Spannungen zwischen Zeitpunkten werden über eine
stückweise,
lineare Interpolation berechnet. Wenn ein Lesen nach dem letzten
Punkt durchgeführt
wird, dann wird der Wert von den letzten beiden Punkten extrapoliert;
wenn folglich nach dem set-Aufruf für t2 keine Punkte hinzugefügt werden,
stellt die gestrichelte Linie dar, welche Spannung von dem Kanal
gelesen werden würde.
-
Die
off()-Methode wird hauptsächlich
verwendet, um die Ansteuerung durch die Spannung abzuschalten. Dies
geschieht, wenn zwei Komponenten gleichzeitig auf die entgegengesetzte
Seite eines Kanals schreiben. Wenn eine Seite die set()-Methode
aufruft, dann wird diese Spannung als angesteuert angesehen. Wenn die
andere Seite die off()-Methode aufruft, dann wird diese Spannung
als passiv angesehen. In diesem Fall setzt sich die steuernde Spannung
durch und nachdem die Spannungen auf beiden Seiten aufgelöst sind,
ist die von einem Kanal gelesene Spannung die Spannungseingabe mit
dem set()-Befehl. Wenn beide Seiten die set()-Methode aufrufen oder wenn beide Seiten
die off()-Methode aufrufen, dann wird die Spannungshistorie auf
einen mittleren Spannungswert festgesetzt.
-
Der
end()-Methodenaufruf zeigt dem Simulationsrahmen an, dass der Kanal
zur Rasterung und danach zum Lesen durch eine Komponente auf der
anderen Seite des Kanals bereit ist. Wenn die end()-Methode nicht
auf einem Kanal aufgerufen wird, dann können sich die Signale auf diesem
Kanal nicht durch den Rest der Simulation verbreiten, da den Komponenten
auf der entgegengesetzten Seite des Kanals nicht signalisiert wird,
aus dem Kanal zu lesen. Typischerweise macht der Benutzer mehrere
set-Aufrufe, um die Spannung über
einen Zeitraum zu beschreiben und ruft dann die end()-Methode einmal
am Ende des Zeitraumes auf.
-
Die
SimWaveformIter-Klasse 308 identifiziert Wechsel bei Wellenformen.
Der Benutzer erhält
eine Instanz eines Wellenform-Iterators, indem die getWaveformIter()-Methode
in der SimChannel-Klasse 308 aufgerufen wird. Diese Methode
erfordert vom Benutzer, dass höchste
und niedrigste Spannungen sowie Anfangs- und Endzeiten angegeben
werden. Unter Verwendung dieser Daten sendet die getWaveformIter()-Methode eine
Instanz der SimWaveformIter-Klasse 308 zurück. Die
getWaveformIter()-Methode ermöglicht
es dem Benutzer ferner, alle Flankenwechsel bei einer Wellenform
schrittweise durchzugehen. Für
jeden Wechsel sendet es den Zeitpunkt des Wechsels und den dem Wechsel
folgenden Zustand der Wellenform zurück. Der Zustand wird als ein
einzeln benannter Typ State_t bestimmt. Die möglichen Werte für diesen
Typ sind H (hoch). L (niedrig) und Z (hochohmig).
-
Bei
einer Implementierung der vorliegenden Erfindung ist ein Beispiel
der getWaveformIter()-Methode nachstehend gezeigt.
-
-
Die
SimWaveformIter-Klasse 308 beinhaltet die folgenden Methoden.
- • start():
Setzen Sie den Iterator auf den ersten Wechsel.
- • end():
Die end()-Methode überprüft, ob der
Iterator am Ende der Flankensequenz ist. Beachten Sie, dass, wenn
diese Methode true zurückliefert,
die Ergebnisse von getTime und getState unbestimmt sind.
- • next():
Die next()-Methode bewegt den Iterator zum nächsten Wechsel.
- • getTime():
Die getTime()-Methode liefert die Zeit für den gegenwärtigen Wechsel
zurück.
- • getState():
Die getState()-Methode bekommt den Zustand der gegenwärtigen Flanke.
Die Flanke gilt für den
Zustand der zugrunde liegenden Wellenform nach der Flankenzeit.
-
Bei
einer weiteren Ausführungsform
stellt die SimChannel-Klasse 306 die Möglichkeit bereit, die Spannung
auf einem Kanal zu einer bestimmten Zeit zu lesen. Dies erfolgt
durch die read()-Methode unter Verwendung eines einzigen Zeitarguments.
Der durch den read() zurückgelieferte
Wert wird aus Daten interpoliert, die in einer Tabelle mit Zeit-gegen-Spannungs-Informationen
gespeichert sind. Das Interpolationsverfahren basiert auf der Kanal-Konfiguration,
wie in der Simulations-Konfigurations-Datei definiert. Wenn der
Kanal als Schritt-Kanal konfiguriert ist, dann wird ein Rechteck-Modell
verwendet. Wenn der Kanal als ein Anstiegs-Kanal konfiguriert ist,
dann wird ein Anstiegs-Modell verwendet, um die Spannungswechsel,
die über
einen endlichen Zeitraum stattfinden, zu interpolieren. Wenn der
Kanal ein analoger Kanal ist, dann wird die Spannung unter Verwendung
einer stückweisen,
linearen Interpolation berechnet.
-
Zusätzlich obliegt
es dem Benutzer, die Daten in einem Kanal zu regeln. Dies wird durch
die flush()-Methode erzielt. Diese Methode registriert den Kanal
für eine
Aufräumphase.
Sie gibt an, dass kein Lesen vor- der durch das Flush-Argument bestimmten
Zeit stattfinden kann. Wenn die flush()-Methode aufgerufen wird,
werden alle Aufzeichnungen vor der bestimmten Zeit während des
nächsten
Aufräum-Zyklus
aus dem Kanal entfernt. Die flush()-Methode wird regelmäßig für lange
Muster aufgerufen, bei denen Speicherbeschränkungen den Abschluss der Simulation
verhindern können.
-
Bei
noch einer weiteren Ausführungsform
um in einen Kanal zu schreiben, ist die Hauptmethode zur Bestimmung
einer Ausgabespannung die set()-Methode, wo der Benutzer einen Zeitpunkt
und eine zugehörige
Spannung als Parameter angibt. Diese Methode liefert eine Eingabe
an die Zeithistorie des Kanals. Wenn eine Steuerung abgeschaltet
wird, kann die off()-Methode verwendet werden. Dies gibt an, dass
es, wenn ein Signal von der anderen Seite der Schnittstelle gesteuert
wird, die Spannung auf dem Kanal diktiert. Die off()-Methode wird hauptsächlich für bidirektionale
Kanäle
verwendet, die sowohl Steuerungs- als auch Abtastimpulsvorgänge durchführen.
-
Der
Benutzer kann angeben, dass der Satz an Werten, die in den Kanal
eingegeben wurden, zur Übermittlung
an die andere Seite der Schnittstelle bereit ist. Dies erfolgt durch
die überladene
end()-Methode. Die end()-Methode gibt dem Simulationsrahmen an,
dass die Werte auf dem Kanal zum Lesen bereit sind, bis zu und einschließlich der
in dem end()-Aufruf
angegebenen Zeit. Beachten Sie, dass eine end()-Methode ohne Argument
als Standardwert die maximale Zeit entweder des set()- oder des
off()-Aufrufs annimmt. Die end()-Methode setzt die set()-Methode
voraus, um wirksam zu werden. Wenn die end()-Methode nicht aufgerufen wird, werden
keine Daten zum anderen Ende des Kanals übermittelt.
-
Bei
einer Ausführungsform
werden die herkömmlichen
API-Klassen wie folgt verwendet.
-
-
-
-
Beachten
Sie, dass für
analoge Signale alle Ecken der Wellenform bestimmt sein müssen, wobei
bei den Schritt- und den Anstiegs-Wellenformen nur die Wechsel bestimmt
sein müssen.
-
Die
getWaveformIter()-Methode ermöglicht
es dem Aufrufer, den Zustand zurückzusenden,
der von einem Fenster-Abtastimpuls erhältlich ist. Sie benötigt eine
hohe Eingabespannung, eine niedrige Eingabespannung und ein Zeitfenster
als Argumente und sendet ein Objekt zurück, das die Zeiten enthält, bei
denen die Spannungen gekreuzt sind.
-
Die
SimChanID-Klasse 310 kapselt Kanal-Indizes. Es gibt zwei
Sätze von
Kanal-Indizes in dem Testsystem, einen für den Messgeräts-Kanal-Raum
und den anderen für
den DUT-Kanal-Raum.
Die SimChanID-Klasse kapselt ein 20-Bit-Wort, das einen Index in
einem der beiden Räume
beschreibt. Das höchstwertige Bit
gibt an, ob der Kanal-Index für
den Messgeräts-Kanal-Raum oder für den DUT-Kanal-Raum
bestimmt ist. Das nächste
Bit ist ein Flag, das angibt, ob alle Kanäle verwendet werden. Die nächsten 7
Bits sind der Anschluss- oder DUT-Index für entweder das Messgeräts-Modul
bzw. das DUT. Die niederwertigsten 12 Bits werden für lokale
Index-Werte (4K-Kanäle)
verwendet.
-
Die
SimChanID-Klasse 310 beinhaltet die folgenden Methoden.
- • SimChanID():
Die SimChanID()-Methode liefert true zurück, wenn alle Kanal-Bits gesetzt
sind.
- • getIndex():
Die getIndex()-Methode liefert den Index im lokalen Kanalraum zurück. Die
isTestChannel- und isDUTChannel-Methoden geben an, ob der Index
für den
Messgeräts-
bzw. den DUT-Raum bestimmt ist. Wenn die all()-Methode true zurückliefert,
dann ist das Ergebnis dieser Methode unbestimmt.
- • getPort():
Die getPort()-Methode liefert den Anschluss für die festgelegte Kanal-ID
zurück.
Die Kombination von Anschluss und Index identifiziert eindeutig
alle Kanäle
auf einer Seite des Ladebords.
- • isDUTChannel():
Die isDUTChannel()-Methode liefert true zurück, wenn sich der Kanal in
dem DUT-Kanal-Raum befindet.
- • isTesterChannel():
Die isTesterChannel()-Methode liefert true zurück, wenn sich der Kanal in
dem Messgeräts-Kanal-Raum
befindet.
-
Simulationskomponenten
-
4 stellt
einen Simulationsrahmen zur Handhabung von Simulationskomponenten
gemäß einer
erfindungsgemäßen Ausführungsform
dar. Der Simulationsrahmen beinhaltet eine Simulationskomponenten-Basis-(SimComponentBase)-Klasse 401.
Die SimComponent-Klasse 402 und
die SimComponentStepped-Klasse 406 sind von der SimComponentBase-Klasse abgeleitet.
Die Lieferantenemulationsmodul-(Module)-Klasse 404 ist
von der SimComponent-Klasse abgeleitet. Virtuelle Funktionen werden
innerhalb der SimComponent-Klasse 402 entwickelt, um das
Verhalten des Moduls zu definieren. Ebenso ist die DUT-Klasse 408 von
der SimComponentStepped-Klasse 406 abgeleitet. Die SimComponentBase 401 ist
die übliche
Basisklasse, die die Methoden beinhaltet, die sowohl von den SimComponent- 402 als
auch von den SimComponentStepped- 406 Klassen gemeinsam
genutzt werden.
-
Die
Module-Klasse 404 ruft die handleEvent()-Methode zur Handhabung
von Simulationsereignis-Objekten auf. Die handleEvent()-Methode
wird in Verbindung mit einigen Diensten verwendet, die von registerEvent()
und raiseEvent() von der SimComponent-Klasse bereitgestellt werden.
Die registerEvent()-Methode ermöglicht
es einem Modul, ein Ereignis mit dem Simulationsrahmen zu erfassen.
Ereignisse können
mit einem einzelnen Kanal, einer Gruppe von Kanälen oder einem ganzen Modul
in Zusammenhang stehen. Ereignisse können ebenfalls mit einer bestimmten
Zeit erfasst werden, wobei der Aufrufer in diesem Fall das Ereignis
als entweder ein Lese- oder Schreib-Ereignis identifiziert. Wenn das Ereignis
ein Schreib-Ereignis ist, dann wird die handleEvent()-Callback für das Modul
aufgerufen, sobald die Simulation den Erfassungszeitpunkt erreicht. Wenn
das Ereignis ein Lese-Ereignis ist, dann wird die handleEvent()-Callback
erst aufgerufen, nachdem jeder der Kanäle, mit denen das Ereignis
in Zusammenhang steht, aufgelöst
und zum Lesen bereit ist.
-
Wenn
der handleEvent()-Aufruf in Antwort auf ein Ereignis mit einem zugehörigen Zeitpunkt
(d. h. synchrones Ereignis) gegeben wird, dann muss das Modul den
durch die API vorgegebenen Regeln gehorchen, wie in dem Simulationsrahmen
definiert, damit die Simulation richtig funktioniert:
- • Für Schreib-Ereignisse
kann das Modul nur Spannungswerte für Zeitpunkte nach dem Zeitpunkt
des Schreib-Ereignisses festlegen.
- • Für Lese-Ereignisse
kann das Modul nur Spannungswerte für Zeitpunkte vor dem Zeitpunkt
des Lese-Ereignisses lesen.
-
Ereignisse
können
ebenfalls ohne Zeitpunkte (d. h. asynchrone Ereignisse) erfasst
werden. Diese Ereignisse werden von anderen Modulen oder durch den
Simulationsrahmen ausgelöst.
Diese Ereignisse unterstützen
zwei Funktionen. Die erste Funktion ist zur Handhabung bestimmter
gut bekannter Ereignisse in dem System, wie Unterbrechungen. Die
zweite Funktion ist zur Abwicklung der Kommunikation zwischen Modulen. Asynchrone
Ereignisse ermöglichen
es einem Modul, ein anderes Modul zu benachrichtigen, dass ein bestimmter
Satz an Bedingungen eingetroffen ist. Ein Beispiel ist ein synchrones
Modul, das digitale Pin-Module zu
Beginn eines Zyklus benachrichtigt, sodass die digitalen Pin-Module
die mit dem gegenwärtigen
Zyklus in Zusammenhang stehenden Flanken ausgeben.
-
Damit
ein Lieferantenmodul in den Rahmen geladen wird, exportiert der
Lieferant vorzugsweise einige vordefinierte Funktionen aus seiner
DLL, das die Erzeugung und Zerstörung
von Objekten unterstützt,
die das Emulationsmodul-Modell aufrechterhalten. Diese standardisierte
Schnittstelle versteckt die Details des Ladens eines jeden Modells.
-
Simulationsmodelle
sind von der SimComponent-Klasse abgeleitet, die dem Simulationsrahmen
zugänglich
gemacht sind. Um die Modelle zu definieren, implementiert ein Benutzer
die in der SimComponent-Klasse spezifizierten virtuellen Funktionen.
Die virtuellen Funktionen eines Moduls fallen in zwei Kategorien:
- • virtuelle
Methoden, die die abgeleitete Klasse bereitstellen muss; und
- • Basisfunktionen,
die vorgegebene Implementierungen haben, die der Benutzer neu definieren
kann.
-
Neben
diesen Funktionen stellt diese Klasse den abgeleiteten Klassen ebenfalls
Leistungen zum Ereignismanagement bereit.
-
DUT-Modelle
werden implementiert, indem sie von der SimComponentStepped-Klasse 406 des
Simulationsrahmens abgeleitet werden. Der Entwickler implementiert
die virtuellen Funktionen in der SimComponentStepped-Klasse 406,
um das Verhalten des Moduls zu definieren. Die run()-Methode beispielsweise
ruft das DUT-Modell auf, über
ein bestimmtes Zeitfenster abzulaufen. Aufgrund der Einfachheit
der Schnittstelle ist dem Modell-Gestalter große Freiheit gewährt, wie
das DUT modelliert sein kann. Diese Freiheit wird durch die herkömmliche
Schnittstelle für
C/C++-Modelle oder DLLs unterstützt,
die mit einem Server, auf dem Verilog-Modelle ablaufen, verbinden.
Die Details darüber,
wie die DUT-Modelle implementiert sind, sind vom Rest der Simulation
isoliert, wodurch es solchen Modellen ermöglicht wird, austauschbar verwendet
zu werden. Um cm DUT-Modell in dem Simulationsrahmen bereitzustellen,
beinhaltet die SimComponentStepped-Klasse die folgenden virtuellen
Methoden:
- • run():
Der Benutzer lässt
das DUT_Modell durch ein bestimmtes Zeitfenster ablaufen. Aufeinanderfolgende
run()-Aufrufe beginnen, wo der letzte run()-Aufruf geendet hat.
- • handleISVM():
Diese Methode liefert die Messung von einer parametrischen Messeinheit
(PMU) für
den bestimmten Kanal zurück.
Beachten Sie, dass eine PMU verwendet wird, um statische DC-Messungen
an einem Kanal durchzuführen,
während
der Test sich in einem Verweilstadium oder zwischen Tests befindet.
- • handleVSIM():
Diese Methode liefert die PMU-Messung für den bestimmten Kanal zurück.
- • handleVSVM():
Diese Methode liefert die PMU-Messung für den bestimmten Kanal zurück.
-
Um
ein DUT-Modell in den Simulationsrahmen zu laden, exportiert das
DLL einen Satz vordefinierter Funktionen, die die Erzeugung und
Zerstörung
von Objekten unterstützen,
die das DUT-Modell warten. Diese standardisierte Schnittstelle versteckt
die Details des Ladens eines jeden Modells.
-
Simulationsereignis-Manager
-
5 stellt
einen Simulationsrahmen zur Handhabung von Simulationsereignis-Objekten
gemäß einer
erfindungsgemäßen Ausführungsform
dar. Der Simulationsrahmen beinhaltet eine Modul-Klasse 502,
eine Simulationsereignis-Manager-(SimEventMgr)-Klasse 504 und
eine Simulationsereignis-(SimEvent)-Klasse 506.
-
Die
SimEventMgr-Klasse 504 erzeugt Instanzen der SimEvent-Klasse 506.
Die SimEventMgr-Klasse 504 wird verwendet, um einen Lieferantenindex
aufrechtzuerhalten. Dieser Index identifiziert eine Familie von Ereignissen
eindeutig. Normalerweise steht die Familie von Ereignissen mit einem
Lieferanten in Zusammenhang, der einen zugehörigen Lieferanten-ID-String
aufweist. Die Klasse ermöglicht
es dem Benutzer ebenfalls, eine weitere Familie von Ereignissen
zu erzeugen, sodass zwei oder mehr Gruppen von Modulen Ereignisse in
einem separaten Ereignisraum teilen können.
-
Bei
einer Ausführungsform
wird der folgende Konstruktor verwendet, um ein SimEventMgr-Objekt für einen
bestimmten Lieferantenindex zu erzeugen:
SimEventMgr(const
OFCString&, SimChanID::ChannelSpace_t)
-
Das
String-Argument bestimmt die Ereignisfamilie. Der Kanal-Raum-Typ
gibt an, ob die Kanäle
für die Ereignisse
Messgeräts-Kanäle (SimChanID::TESTER_SPACE)
oder DUT-Kanäle (SimChanID::DUT_SPACE)
sind. Wenn der Benutzer beispielsweise wünscht, Ereignisse für „ADVANTEST"-Messgeräts-Modele
zu erzeugen, wird die folgende Methode aufgerufen:
SimEventMgr
emgr(_T("ADVANTEST"), SimChanID::TESTER_SPACE);
-
Ein
Modulentwickler erzeugt eine Instanz des SimEventMgr für jede Domäne, zu der
das Modul gehört.
Diese Objekte werden für
die Lebensdauer eines Moduls verwendet. Der folgende Satz an Aufrufen
dient beispielsweise dazu, Ereignisse für verschiedene Domänen zu erzeugen:
-
Während dem
Verlauf einer Simulation, kann jedes dieser Objekte Ereignisse für jede der
Domänen erzeugen.
Auf diese Weise können
von verschiedenen Lieferanten erzeugte Module Ereignisse teilen,
indem sie sich auf einen eindeutigen Namen für ihre gemeinsam genutzte Domäne einigen.
Falls sich DUT-Modelle für
Ereignisse registrieren müssen,
wird die clientmgr()-Methode verwendet. Beachten Sie, dass eine
Unterscheidung zwischen dem DUT-Raum und dem Messgeräts-Raum
gemacht wird, da die beiden Kanäle
zu verschiedenen Index-Räumen
gehören.
SimEventMgr
clientmgr("CLIENT" SimChanID::DUT_SPACE);
-
Verschiedene
Methoden werden verwendet, um Ereignisse zu erzeugen. Die Methoden
zur Erzeugung synchroner Ereignisse beinhalten:
- • SimEvent
makeReadEvent(SimEvent::LocaiCode_t): Diese Methode erzeugt ein
Lese-Ereignis für alle Kanäle in dem
Modul.
- • SimEvent
makeReadEvent(SimChanID::Index_t, SimEvent::LocalCode_t): Diese
Methode erzeugt ein Lese-Ereignis für einen einzelnen Kanal.
- • SimEvent
makeReadDomainEvent(SimEvent::Domain_t, SimEvcnt::LocalCode_t):
Diese Methode erzeugt ein asynchrones Ereignis für eine bestimmte Domäne.
- • SimEvent
makeWriteEvent(SimEvent::LocalCode_t): Diese Methode erzeugt ein
Schreib-Ereignis
für alle Kanäle in dem
Modul.
- • SimEvent
makeWriteEvent(SimChanID::Index_t, SimEvent::LocalCode_t): Diese
Methode erzeugt ein Schreib-Ereignis für einen einzelnen Kanal.
- • SimEvent
makeWriteDomainEvent(SimEvent::Domain_t, SimEvent::LocalCode_t):
Diese Methode erzeugt ein Schreib-Ereignis für einen einzelnen Kanal.
-
Die
Funktionen, die den Kanalindex nicht als Parameter nehmen, erzeugen
Ereignisse für
alle Kanäle. Die
Funktionen, die den benutzerspezifizierten Kanalindex und den lokalen
Code als Parameter nehmen, erzeugen SimEvents für bestimmte Kanäle. Die
Funktionen, die die Domäne
als ein Argument nehmen, werden für eine Gruppe von Kanälen verwendet,
die an eine bestimmte Domäne
gebunden wurden.
-
Die
Methoden zur Erzeugung asynchroner Ereignisse beinhalten:
- • makeAsyncEvent():
Diese Methode wird verwendet, um ein asynchrones, Seriennummern-basiertes
Ereignis zu erzeugen.
- • makeDomainEvent():
Diese Methode wird verwendet, um ein asynchrones, Domänebasiertes
Ereignis für einen
bestimmten Kanal zu erzeugen.
- • makeSysEvent():
Diese Methode wird verwendet, um ein Systemereignis zu erzeugen.
- • isMyEvent():
Diese Methode kontrolliert die Domäne eines Ereignisses. Es liefert
true zurück,
wenn das bestimmte Ereignis in die gleiche Domäne gehört wie der Ereignismanager.
-
Bei
einer Ausführungsform
kann, wenn der Modulentwickler, der die drei Ereignismanager in
dem vorstehenden Konstruktor-Beispiel erzeugt, bestimmen muss, zu
welcher Domäne
ein Ereignis gehört,
der folgende Ansatz verwendet werden.
-
-
Die
SimEvent-Klasse 506 beinhaltet die folgenden Methoden.
- • isChannelEvent():
Diese Methode überprüft, ob das
Ereignis für
einen einzelnen Kanal ist. Die Methode liefert true zurück, wenn
das Ereignis ein Kanal-basiertes Ereignis ist.
- • isDomainEvent():
Diese Methode überprüft, ob das
Ereignis für
eine Domäne
ist. Die Methode liefert true zurück, wenn das Ereignis ein Domäne-basiertes
Ereignis ist.
- • isReadEvent():
Diese Methode überprüft, ob das
Objekt ein Lese-Ereignis ist. Die Methode liefert true zurück, wenn
das Ereignis ein Lese-Ereignis ist.
- • isSerialNumberEvent():
Diese Methode überprüft, ob das
Ereignis für
eine bestimmte Seriennummer ist. Die Methode liefert true zurück, wenn
das Ereignis für
eine bestimmte Seriennummer ist.
- • isSysEvent():
Diese Methode überprüft, ob das
Objekt ein Systemereignis ist. Die Methode liefert true zurück, wenn
das Ereignis ein Systemereignis ist.
- • isWriteEvent():
Diese Methode überprüft, ob das
Ereignis ein Schreib-Ereignis ist. Die Methode liefert true zurück, wenn
das Ereignis ein Schreib-Ereignis ist.
- • getChan():
Diese Methode holt das SimChanID-Objekt.
- • getCode():
Diese Methode holt den lokalen Benutzercode.
- • getDomain():
Diese Methode holt die Domäne,
die den Domäne-Index
des Ereignisses zurücksendet.
- • getSerialNumber():
Diese Methode holt die Seriennummer.
- • getSysCode():
Diese Methode holt den Systemereignis-Code.
- • numArgs():
Die Methode liefert die Anzahl an Benutzer-Argumenten zurück.
- • popArg():
Diese Methode ruft das nächste
Benutzer-Argument in der Warteschlange ab. Beachten Sie, dass Argumente
in der gleichen Reihenfolge abgerufen werden, wie sie hinzugefügt werden.
Sobald ein Argument abgerufen wurde, steht es von dem Ereignis nicht
mehr länger
zur Verfügung.
Das Aufrufen von popArg öfter
als numArgs() hat das Auswerfen eines Fehlers (Exception) zur Folge.
- • pushArg():
Diese Methode fügt
ein Benutzer-Argument hinzu.
-
Konfigurations-Dateien
-
Der
Simulationsrahmen verwendet zwei Konfigurations-Dateien, eine Simulations-Konfigurations-Datei
und eine Offline-Konfigurations-Date. Die Simulations-Konfigurations-Datei
bestimmt, welche Messgeräts-Module
während
der Simulation verfügbar
sind. Die Offline-Konfigurations-Datei bestimmt. welche DUT-Modelle
geladen werden und wie sie mit dem Messgerät verbunden sind.
-
Die
Simulations-Konfigurations-Datei wird geladen, wenn die Funktion
SimTester initial gestartet wird. Die Einstellungen in dieser Datei
bleiben für
die Laufzeit des SimTester-Prozesses
wirksam. Die Offline-Konfigurations-Datei wird als Teil des Testplans
des Benutzers geladen. Der Name der Datei wird mit einem Testprogramm-Sprachen-(TPL)-Befehl OfflineDef
bestimmt. Dieser Befehl kann überall
in dem Testprogramm des Benutzers erscheinen, ist aber herkömmlicherweise
in der testplan.tpl-Datei mit den anderen High-level-Befehlen angeordnet.
-
Bei
einer Ausführungsform
ist eine Beispiels-Simulations-Konfigurations-Datei nachstehend
gegeben. Wie nachstehend gezeigt, ist die Datei in hierarchische
Blöcke
unterteilt. Der Global-Block enthält systemweite Parameter. Der
EMUModule-Block benennt die das Emulationsmodell enthaltende DLL
und bestimmt die Anschlüsse,
wo ein Modell geladen wird. Der EMUModule-Block enthält die Modul-Schnittstelle
für den
Simulationsrahmen.
-
-
-
Der
Benutzer kann die Offline-Kontigurations-Datei versorgen, um die
DUT-Modelle zu bestimmen, die in der Simulation verwendet werden
sollen, und zeigen, wie diese Modelle den Messgeräts-Ressourcen
zugeordnet sind. Bei einer Ausführungsform
ist eine Beispiels-Offline-Konfigurations-Datei
nachstehend gezeigt. Beachten Sie, dass mit Ausnahme des PinConnections-Blocks
diese Datei eine ähnliche
Struktur wie die Simulations-Kontigurations-Datei
aufweist. Der Global-Block beschreibt systemweite Einstellungen.
Der DUTModel-Block beschreibt die das DUT-Modell enthaltende DLL
und bestimmt die Anschlüsse
zum Laden des DUT-Modells. Der PinConnections-Block gibt an, wie
jeder Anschluss mit dem Messgerät
verbunden ist.
-
-
Rahmenkonfiguration
-
Wie
vorstehend diskutiert, werden Modul-Lieferanten benötigt, um
Emulationen ihrer Hardware-Module bereitzustellen. Aufgrund dieser
Anforderung erwirbt ein Benutzer, der ein Lieferantenmodul erwirbt,
ebenfalls ein Emulations-Modul dieser Komponente. Das Emulations-Modul
kommt in Form einer DLL, die eine Schnittstelle besitzt, um das
Modul durch den Simulationsrahmen ladbar zu machen. Dies wird durch
einen Satz vordefinierter Schnittstellen-Anforderungen bestimmt,
die auf der DLL des Lieferanten angeordnet sind. Um ein Emulations-Modul
in den Simulationsrahmen zu laden, wird eine Simulations-Konfigurations-Datei
entweder durch den Benutzer bereitgestellt oder durch das Testsystem
erzeugt. Die Simulations-Konfigurations-Datei spezifiziert jede
zu ladende DLL. Zusätzlich
zur Benennung der DLL bestimmt die Simulations-Konfigurations-Datei
Parameter, die den Hardware-Einstellungen des zu simulierenden Testsystems
entsprechen. Dies beinhaltet die Modul-Anschlussanzahl, die Modul-Seriennummer,
die Anzahl an Kanälen,
das Format der Wellenform auf jedem Kanal und die Referenzspannung,
die während
der Simulation verwendet wird, etc. Die Simulations-Konfigurations-Datei
beinhaltet andere Parameter, die Gegenstand der Simulation sind.
Diese beinhalten die logischen Referenzen, die verwendet werden,
um die Kanäle
von einem Modul mit DUT-Pins zu verbinden und bestimmte Parameter,
die an das DLL geleitet werden, wenn die Module geladen sind.
-
Bei
einer Ausführungsform
führt der
Simulationsmanager die folgenden Funktionen durch, um die Simulation
zu konfigurieren:
- • Laden aller Komponenten, wie
durch die Simulations-Konfigurations-Datei angeordnet;
- • Aufteilen
der Komponenten und Ressourcen unter die verschiedenen Sites; und
- • Bereitstellen
eines zentralen Objekts zur Handhabung der Musterdurchführung auf
allen Threads.
-
Zusätzlich verwendet
der Simulationsmanager die Konfigurations-Dateien, um die folgenden
Funktionen durchzuführen:
- • Instanziieren
aller Komponenten- und Schnittstellen-Objekte;
- • Verbinden
aller Komponenten wie durch die Konfigurations-Dateien bestimmt;
und
- • Bereitstellen
von Abbildungen von Komponenten-Kanälen auf Schnittstellen-Objekte.
-
Beachten
Sie, dass die create()-Methode die einzige allgemeine Methode ist,
um sicherzustellen, dass es nur eine Instanz von SimMgr gibt. Eine
passende release()-Methode wird verwendet, um Ressourcen nach einer
Simulation aufzuräumen.
Die create()-Methode erzeugt die Simulationsbasis auf der in der
Argumentliste spezifizierten Simulations-Konfigurations-Date. Das Pfad-Argument
wird verwendet, um einen Basispfad für andere Textdateien zu bestimmen,
die innerhalb der Simulations-Konfigurations-Datei referenziert
sind. Diese Dateien werden als zu dem Basispfad relative Pfade bestimmt.
-
Sobald
der Simulationsrahmen konfiguriert ist, wartet er auf ein Testprogramm
und ein zu bestimmendes Ziel-DUT-Modell. Bevor das Testprogramm
geladen wird, meldet das TOS dem Simulationsrahmen, dass eines oder
mehrere DUT-Modelle bestimmt wurden. Dies erfolgt über eine
weitere Konfigurations-Datei, die Offline-Konfigurations-Datei genannt
wird. Das DUT-Modell kommt entweder in Form einer vom Endanwender bereitgestellten,
in C/C++ geschriebenen DLL, die einen Satz vordefinierter Schnittstellen-Anforderungen
erfüllt
oder als ein auf einem Server ablaufendes Verilog-Modell, das auf
Verbindungen von einer Simulation wartet. Die Offline-Konfigurations-Datei
bestimmt eine oder mehrere zu ladende DUT-Modell DLLs. Zusätzlich bestimmt
die Datei Parameter, die den Hardware-Einstellungen der DUT entsprechen. Dies
beinhaltet die Kanäle und
Formate der Wellenform, die elektrische Verdrahtung der logischen
Messgeräts-Kanäle mit den
DUT-Pins und die Transportverzögerungen,
die mit dieser Verdrahtung in Zusammenhang stehen. Die Offline-Konfigurations-Datei
beinhaltet ebenfalls weitere Parameter, die Gegenstand der Simulation
sind. Diese beinhalten die bestimmten Parameter, die an die DLL
weitergeleitet werden, wenn DUT-Modelle geladen werden. Um Verilog-DUT-Modelle
aufzurufen, stellt der Rahmen eine spezielle DUT-Modell DLL bereit.
Dieses Modell kann konfiguriert werden, um an einen bestimmten Server
zu verbinden, auf dem das das bestimmte Verilog-Modell ausführende Programm
abläuft.
-
Rahmeninitialisierung
-
Bei
einer Ausführungsform
beinhaltet die Initialisierung des Simulationsrahmens die folgenden
Vorgehensweisen:
- 1. Laden von Modul-DLLs und
Instanziieren von Modul-Emulations-Objekten im Speicher, basierend
auf der Simulations-Konfigurations-Datei;
- 2. Warten auf die vom Benutzer bereitzustellende Offline-Konfigurations-Datei
(die die zu ladenden DUT-Modelle beschreibt und wie sie mit den
Modulen verbunden sind);
- 3. Verwenden beider Konfigurations-Dateien, um wie folgt eine
Simulation zu erstellen:
a. Verwenden der Site-Information,
die über
die Bus-Emulation in das System programmiert wurde, um Module und
DUTs verschiedenen Sites zuzuordnen;
b. Verbinden der Module
mit einem Ladebord-Modell in dem Simulationsrahmen, das diesem bestimmten Site
gewidmet ist; und
c. Verbinden der DUT-Modelle an jeder Site
mit der entsprechenden Site des Ladebord-Modells.
- 4. Wenn der Testplan entladen ist, Entladen der in Schritt 3
erzeugten Struktur und Warten auf eine weitere Offline-Konfigurations-Datei.
-
Der
Rahmen bricht die Simulation pro Site auf, um eine multi-threaded
Simulation zu erleichtern. Die Sites können parallel simuliert werden.
Als Ergebnis werden die Simulationen durch das Aufbrechen gemäß vordefinierter
Simulationssites untereinander thread-sicher und vermeidet die Notwendigkeit
eines Sperrmechanismus, der die Ausführung beeinflussen könnte.
-
Nach
dem Laden der Konfigurationsdaten beginnt der Simulationsrahmen
damit, eine Simulation zu erstellen, indem für jeden Kanal in einem Modul über das
Ladebord eine Verbindung zu einem Objekt in dem Simulationsrahmen
geschaffen wird. 6 stellt einen Kanal zwischen
dem Emulations-Modul und dem Ladebord-Modell gemäß einer erfindungsgemäßen Ausführungsform
dar. Der Kanal beinhaltet ein Emulations-Modul 602, ein
bidirektionales Schnittstellen-Modell 604 und ein Ladebord-Modell 606.
Das Emulations-Modul 602 enthält einen
I/O-Anschluss SimChannelA 603 und entsprechend enthält das Ladebord-Modell einen
I/O-Anschluss SimChannel B 607. Es gibt zwei Puffer innerhalb
der bidirektionalen Schnittstelle 604, einen SimWaveform
A2B-Puffer 608 zum Übertragen
von Daten von dem Emulations-Modul 602 zum Ladebord-Modell 606,
und einen SimWaveform B2A-Puffer 610 zum Übertragen
von Daten von dem Ladebord-Modell 606 zum Emulations-Modul 602.
Wie in 6 gezeigt, schreibt das Emulations-Modul 602 an
den SimWaveform A2B-Puffer 608 und liest von dem SimWaveform
B2A-Puffer 610. Auf der anderen Seite schreibt das Ladebord-Modell 606 an
den SimWaveform B2A-Puffer 610 und liest von dem SimWaveform
A2B-Puffer 608.
-
Jeder
der SimWaveform A2B- und SimWaveform B2A-Puffer enthält eine
Tabelle zum Speichern von Informationen über den Kanal. Im Speziellen
speichern die Puffer Spannungen, die von einem Kanal-Objekt zu beliebigen
Zeitpunkten gelesen wurden.
-
Zwischen
den Zeiten der Tabelleneinträge
gelesene Spannungswerte des Kanals werden unter Verwendung eines
der verschiedenen vorstehend in 3b beschriebenen
Standardmodellen interpoliert. Die Auswahl des mit einem bestimmten
Kanal zu verwendenden Modells ist benutzerkonfigurierbar. Modelle
werden ausgetauscht, indem SimWaveform eine Basisklasse für andere
Wellenformklassen gemacht wird. SimWaveform besitzt eine virtuelle
Funktion read(), die eine Spannung einer bestimmten Zeit wiedergibt.
Jede abgeleitete Klasse implementiert read() gemäß der zu modellierenden Wellenform
(z. B. modelliert der SimWaveformStep ein Rechtecksignal). Ein analoges
Verfahren wird verwendet, um Fenster-Abtastimpluse zu modellieren.
-
Wie
in 6 gezeigt, sind DUT-Modelle 612 an das
Ladebord gekoppelt. Diese Verbindung wird erzielt, indem eine Instanz
der SimWire-Klasse des Simulationsrahmens verwendet wird. Die SimWire-Klasse hat
Zugriff auf die Puffer in den bidirektionalen Schnittstellen-Objekten.
Die SimWire-Klasse löst
Ansteuerungskonflikte zwischen der DUT und den Modulen. Beachten
Sie, dass die Verbindung zwischen dem Ladebord 606 und
dem DUT-Modell 612 in 6 ein Spiegelbild
der Verbindung zwischen dem Emulations-Modul 602 und dem
Ladebord 606 ist. Die Details dieser Verbindung sind in
dem Diagramm weggelassen, sodass die Details der Verbindung zwischen
dem Modul und dem Ladebord klarer gezeigt werden können.
-
Nachdem
die Simulation geschaffen ist, wird das Testprogramm geladen. Dies
beinhaltet das Ausführen
von Aufrufen in den Systembus-Gerätetreiber. Im Offline-Modus
wird der Gerätetreiber-Zugang
zu der Hardware zu einem gemeinsam genutzten Speicher I/O umgewandelt,
der es einem Site-Kontroller-Prozess ermöglicht, mit dem Simulationsrahmen-Prozess zu kommunizieren.
Es gibt einen engen Zusammenhang zwischen den Verhaltensweisen einer
Online- und Offline-Testsimulation, da die einzige unterschiedliche
Komponente der beiden Simulationsaufbauten in dem Gerätetreiber
liegt.
-
Rahmendurchführung
-
Es
gibt zwei Arten von Simulationen, die während der Testplan-Durchführung ablaufen.
Die erste ist eine ereignisbasierte Simulation. Die simulierten
Komponenten sind normalerweise die Emulations-Module. Diese Komponenten
sind ereignisbasierter Natur, weil ihr Verhalten durch das Testprogramm
bestimmt wird bevor die Simulation begonnen hat. Der andere Typ
von Simulation ist eine zeitbasierte Simulation. Die simulierten
Komponenten sind normalerweise die DUT-Modelle. Diese Komponenten
sind zeitbasierter Natur, weil ihre Zustände basierend auf externen
Impulsen und dem gegenwärtigen
inneren Zustand verbreitet werden. Der Simulationsrahmen koordiniert
die Durchführung
und den Datentransfer zwischen den ereignisbasierten und zeitbasierten
Simulationen.
-
Die
ereignisbasierte Simulation verwendet einen Registrierungs- und
Handhabungs-Prozess. Simulationskomponenten, die typischerweise
Emulations-Module sind, müssen
für jedes
Simulationsereignis registriert werden. Nach der Registrierung,
wenn die Bedingungen eines Testereignisses eintreten, wird der Eventhandler-Callback
der Komponente ausgeführt,
die es den entsprechenden Simulationsvorgehensweisen ermöglicht,
durchgeführt
zu werden.
-
Die
zeitbasierte Simulation beruht auf der Ausgabe der ereignisbasierten
Komponenten. Der Simulationsrahmen berechnet ein Zeitfenster, das
die Impulse einfängt,
die durch die ereignisbasierten Komponenten für alle Kanäle, die die zeitbasierten Komponenten
speisen, erzeugt wurden. Die zeitbasierten Komponenten werden dann
mit dem berechneten Zeitfenster aufgerufen. Die von den ereignisbasierten
Komponenten an die zeitbasierten Komponenten gesandten Daten müssen gleich
bleibend sein. Dieses Stabilitäts-Kriterium
wird verstärkt,
indem die ereignisbasierten Komponenten einen Satz vordefinierter
zeitlicher Anforderungen erfüllen,
wenn sie an ihre Ausgabekanäle
schreiben.
-
Der
Simulationsrahmen stellt eine automatische Lösung von Ansteuerungskonflikten
zwischen den Emulations-Modulen und den DUT-Modellen bereit. Ein
Ansteuerungskonflikt wird typischerweise durch zeitliche Fehler
in dem Testprogramm hervorgerufen. Die Identifizierung dieser Fehler,
bevor sie auf eigentlicher Hardware auftreten, ist essentiell, da
dies Schaden sowohl an den DUTs als auch an den Messeinrichtungen vermeiden
kann. Das SimWire-Objekt in dem Ladebord-Modell löst Ansteuerungskonflikte.
Nachdem Komponenten auf beiden Seiten des SimWire ihre Eingaben
empfangen haben, ruft der Simulationsrahmen das SimWire-Objekt auf,
um die Aufrufe von beiden Seiten aufzulösen. Wenn nur ein Kanal eine
Ansteuerungseingabe hat, dann wird sie zu den anderen Kanälen kopiert,
wobei die entsprechende Transportverzögerung angewandt wird. Wenn
mehrere Seiten des SimWire-Objekts Ansteuerungseingaben empfangen
haben, dann werden die Spannungen in den Ausgabe-Puffern eingestellt,
um diesen Konflikt zu reflektieren. Sobald die Ausgabe-Puffer eingestellt
sind, werden die sich registrierten Module aufgerufen, von ihnen
zu lesen. Die aufgelösten
Spannungsdaten werden sodann abgerufen. Da die Spannungsauflösung in
dem SimWire-Objekt gekapselt ist, ist der Prozess für den Rest
der Simulation transparent.
-
Es
gibt eine Anzahl an Vorteilen, die durch das offenbarte Verfahren
zur Simulierung eines modularen Testsystems erzielt werden. Erstens
ermöglicht
es das offenbarte Verfahren Ingenieuren durch Bereitstellen einer
genauen und ausführlichen
Simulation des Testprogramms, die Testprogramme auf ihrem eigenen
Arbeitsplatzsystem zu entwickeln, im Gegensatz zu einer Entwicklung
auf der teuren Messgeräts-Einrichtung. Zweitens
identifiziert das offenbarte Verfahren Probleme in den Testprogrammen,
Emulations-Modulen und DUT-Modellen
bevor sie auf der Messeinrichtung ablaufen, wobei es ermöglicht wird,
solche Probleme früher zu
lösen.
Drittens unterstützt
das offenbarte Verfahren ein paralleles Entwicklungs-Modell, das
einen kürzeren Testprogramm-Entwicklungszyklus
und eine schnellere Markteinführung
der DUTs ermöglicht.
-
Ein
Fachmann auf diesem Gebiet erkennt, dass viele mögliche Änderungen und Kombinationen
der offenbarten Ausführungsformen
verwendet werden können,
während
immer noch die gleichen zugrunde liegenden Grundmechanismen und
-methodiken angewandt werden. Die vorhergehende Beschreibung wurde zum
Zwecke der Erklärung
unter Bezugnahme auf die spezifischen Ausführungsformen geschrieben. Die
veranschaulichenden vorstehenden Diskussionen sollen jedoch nicht
umfassend sein oder die Erfindung auf die exakten offenbarten Formen
beschränken.
Viele Änderungen
und Variationen sind in Hinblick auf die vorstehenden Belehrungen
möglich.
Die Ausführungsformen
wurden ausgewählt
und beschrieben, um die Grundsätze
der Erfindung und ihre praktischen Anwendungen zu erklären und
um es anderen Fachleuten zu ermöglichen,
die Erfindung auf bestmögliche
Weise anzuwenden, und verschiedene Ausführungsformen mit verschiedenen Änderungen,
wie für
die spezielle vorgesehene Verwendung geeignet.
