DE10125364A1 - Verfahren zum Simulieren einer zu verifizierenden Schaltungseinheit - Google Patents

Abstract

Die Erfindung schafft ein Verfahren zum Anpassen von Signalverläufen an Diskretisierungsraster zur direkten Verwendung von Signalverläufen und Testmustern aus der Simulation der zu verifizierenden Schaltungseinheit (101) in den Tests des zu testenden Bausteins/der zu testenden Schaltungseinheit in Testanordnungen an einem Tester. Bei dem Verfahren sind Signalverzögerungen von Testmustern einstellbar, wobei zunächst ein Testtakt (309), zum Beispiel aus einer Testanordnung, die eine zu verifizierende Schaltungseinheit (101) einschließt, als Referenztakt abgeleitet wird, anschließend mindestens eine aktive Signalflanke des empfangenen Testtakts (309) bestimmt wird, mindestens ein Testmuster von einem Testbench-Controller (103) empfangen wird, Signalverzögerungszeiten für mindestens ein Testmuster eingestellt werden, Simulationssignalverläufe (401, 402) erzeugt werden und Testmuster verzögert über entsprechende Signale der zu verifizierenden Schaltungseinheit (101) zugeführt werden.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Durch­ führen von Simulationen zur Überprüfung einer funktionalen Korrektheit einer Schaltungseinheit und betrifft insbesondere ein Verfahren zum Simulieren einer zu verifizierenden Schal­ tungseinheit.

Testmuster, die zum Durchführen von Simulationen eingesetzt werden, werden in Testmustergeneratoren im allgemeinen auto­ matisch mittels spezieller Software erzeugt. Dieses als ATPG (Automated Test Pattern Generation = Automatische Testmuster­ erzeugung) bekannte Verfahren weist eine Reihe von Einschrän­ kungen auf, die sich insbesondere auch auf die Einstellungen von Signalverzögerungszeiten oder das Anpassen von Testmus­ tern an Diskretisierungsraster beziehen. Dies ist insofern ein Problem, als mit diesen Testmustern anschließend auch Testanordnungen in einem Tester beaufschlagt werden.

In einer Testanordnung werden beispielsweise eine gefertigte Schaltungsanordnung bzw. ein Schaltungs-/Schaltkreis-Baustein oder ein erster Prototyp/ein erstes Modell eines Schaltungs­ kreises/Bausteins auf Funktion und Fertigungsfehler hin ge­ testet, wobei in vielen Fällen neben einer Funktionalität der Schaltungseinheit auch ein Zeitverhalten zu berücksichtigen ist.

Testbenches hingegen bilden beispielsweise eine Simulations­ anordnung einer Schaltungseinheit mit entsprechenden Ein­ gangssignalen und von diesen Eingangssignalen abhängigen Aus­ gangssignalen wie Signalantworten zu Simulationszwecken nach.

Derartige Testbenches sind z. B., aber nicht ausschließlich, mit Hardware-Beschreibungssprachen wie VERILOG und VHDL aus­ geführt. In vielen Fällen ist eine Co-Simulation von Hard­ ware- und Software-Einheiten realisierbar, wie beispielsweise in "Matthias Bauer, Wolfgang Ecker: Hardware/Software Co- Simulation in a VHDL-based Test Bench Approach, DAC 97, Ana­ heim, California, U.S.A." beschrieben.

Testbenches nach dem Stand der Technik sind beispielsweise derart ausgebildet, dass ein oder mehrere Testbenchelemente als logische Schnittstellen zwischen einem Testbench- Controller und einer zu verifizierende Schaltungseinheit be­ reitgestellt werden. Ein Testbenchelement kann beispielsweise als ein Transaktor oder als ein Protokollgenerator ausgeführt sein, wobei das jeweilige Testbenchelement die für eine logi­ sche Schnittstelle benötigten Signalwertverläufe erzeugt. Ei­ ne Zusammenfassung von Signalen zu sogenannten Bussen, sowie eine Festlegung der entsprechenden Signalwertverläufe auf diesen Bussen entspricht einem Protokoll, wobei spezifische Abfolgen von Signalwertverläufen zu Protokolloperationen, wie beispielsweise die Operationen:

• - "Speicher lesen";
• - "ATM (asynchroner Transfer Modus)-Zelle schicken";
• - etc.

zusammengefasst werden, wobei derartige Protokolloperationen wiederum ineinander geschachtelt sein können, um beispiels­ weise folgende Operationen auszuführen:

• - "DMA-Übertragung durchführen";
• - "ATM-Zellensequenz schicken", um ATM-Schalter umzuprogram­ mieren,
• - etc.

Eine derartige protokolloperations-bezogene Beschreibung er­ leichtert eine Auslegung von Testbenchelementen, welche wie­ derum mehrfach bei einer Durchführung von Simulationen wie­ derverwendet werden können.

Die zu verifizierende Schaltungseinheit kann durch eine be­ liebige Schaltungseinheit, wie beispielsweise einen Mikropro­ zessor, eine Mikrochip-Grafikkarte, etc. ausgebildet sein, wobei vorherrschend digitale Signale, gegebenenfalls aber auch analoge und digitale Signale verarbeitet werden.

In sinnvoller Weise werden Testbenchelemente derart ausge­ legt, dass sie unter möglichst vielen Rahmenbedingungen bei möglichst vielen zu verifizierenden Schaltungseinheiten ein­ gesetzt werden können. Herkömmlicherweise wird ein Testbench- Controller als ein zentrales Steuerelement eingesetzt, durch welchen es ermöglicht wird, den Gesamtablauf einer Simulation zu steuern. Der Testbench-Controller wird herkömmlicherweise mit einem Simulationsprogramm beaufschlagt, das zentral be­ reitgestellt wird.

Weiterhin kommuniziert der Testbench-Controller mit jedem einzelnen Testbenchelement über einen Steuerdatenstrom, wobei eine Verbindung zwischen dem Testbench-Controller und dem je­ weiligen Testbenchelement bereitgestellt ist. Eine Abfolge von Protokolloperationen kann in einem Testbenchelement spe­ zifiziert sein, wobei diese Abfolge entweder fest codiert ist oder aus einer Datei eingelesen werden.

In manchen Fällen können (bzw. müssen) die Testbenchelemente untereinander synchronisiert werden. Hierbei müssen bei einer Simulation von übergreifenden Testfällen zeitgleich ablaufen­ de Protokolloperationen an unterschiedlichen Stellen, d. h. in einem jeweiligen Testbenchelement, spezifiziert werden. Bei einer derartigen Simulation sind sämtliche Protokolloperatio­ nen sämtlicher Testbenchelemente auszuführen.

Herkömmliche Simulationsverfahren basieren auf Simulationsan­ ordnungen, welche von einem Testbench-Controller als zentra­ ler Einheit gesteuert werden, wobei den einzelnen Testbenche­ lementen übermittelt wird, welche Protokolloperationen zu welcher Zeit, bezogen auf einen Systemtakt bzw. einen Master- Takt, auszuführen sind. Weiterhin muss sichergestellt sein, dass die Testbenchelemente dem Testbench-Controller mitteilen können, mit welchem Erfolg und mit welchen Daten ein Ablauf der spezifischen Protokolloperationen ausgeführt bzw. beendet wurde.

Im folgenden sei zunächst allgemein ein Verfahren zum Simu­ lieren einer zu verifizierende Schaltungseinheit beschrieben, wobei auf die spezifischen Probleme, die bei einem Einstellen von Signalverzögerungszeiten oder Anpassen von Signalverläu­ fen an ein Diskretisierungsraster auftreten, weiter untenste­ hend unter Bezugnahme auf die Fig. 4 eingegangen wird.

Fig. 3 zeigt ein herkömmliches Verfahren zum Simulieren ei­ ner zu verifizierenden Schaltungseinheit 101 mittels eines in einem Steuerelement 104 abgelegten Simulationsprogramms. Wie in Fig. 3 gezeigt, ist das Steuerelement 104, welches ein spezifisches Simulationsprogramm enthält, an den Testbench- Controller 103 angebunden, wobei ein Steuerdatenstrom 114 von dem Steuerelement 104 zu dem Testbench-Controller 103 über­ mittelt wird.

Ein herkömmlicher Anschluss von Testbenchelementen 102a-102n erfolgt in herkömmlicher Weise mittels Steuerdatenströmen 111a-11n. Es sei darauf hingewiesen, dass ein oder mehrere Testbenchelemente 102a, . . . 102i, . . . 102n vorhanden sein können, wobei i einen Laufindex darstellt.

Beispielhaft sind in Fig. 3 fünf unterschiedliche Testben­ chelemente dargestellt, wobei das Testbenchelement 102a einer seriellen Schnittstelle entspricht, die Daten mittels eines seriellen Testdatenstroms 112 mit der zu verifizierenden Schaltungseinheit 101 austauscht. Als weiteres Beispiel ist das Testbenchelement 102n als parallele Schnittstelle darge­ stellt, welche die Testdaten mit der zu verifizierenden Schaltungseinheit 101 mittels eines parallelen Testdaten­ stroms 113 austauscht.

In gleicher Weise erfolgt ein Datenaustausch zwischen den üb­ rigen Testbenchelementen und der zu verifizierenden Schal­ tungseinheit 101, wobei spezifizierte Datenströme (nicht ge­ zeigt) ausgetauscht werden. Beispielhaft sind in Fig. 3 fünf Testbenchelemente 102a, 102b, 102i, 102i + 1 und 102n darge­ stellt, es können jedoch weniger oder mehr Testbenchelemente bereitgestellt werden. Es ist klar erkennbar, dass die Anzahl der Steuerdatenströme 111a, . . . 111i, (i = Laufindex), . . . 111n der Anzahl von Testbenchelementen 102a-102n entsprechen muss.

Dieser herkömmliche Anschluss von Testbenchelementen 102a-102n an einen zentralen Testbench-Controller 103 als zentra­ les Steuerelement weist eine Reihe von Nachteilen auf.

Nach dem Stand der Technik erfolgt eine Erzeugung von Signal­ takten und Erwartungswerten über eine spezielle Software, die, wie oben erwähnt, als eine ATPG (Automated Testpattern Generation = automatische Testmustererzeugung) bezeichnet wird, wobei aus der Schaltungstopologie benötigte Werte bzw. Wertverläufe bestimmt werden.

Es sei darauf hingewiesen, dass diese Signale auch aus einer Simulation erhalten werden können, was es ermöglicht, dass in einer Testanordnung im Tester neben dem Test auf Fertigungs­ fehler auch vorhandene funktionale Fehler lokalisiert werden können.

Der Hauptnachteil herkömmlicher Verfahren besteht insbesonde­ re darin, dass nicht beliebig genaue Zeitverläufe an eine zu testende Schaltungseinheit im Tester angelegt werden können, sondern dass eine spezifische Diskretisierungsgröße aufrecht erhalten werden muss, die beispielsweise mit einem Master- Takt einer Testanordnung an einem Tester korreliert.

Ein weiterer Nachteil herkömmlicher Verfahren zum Durchführen von Simulationen zur Überprüfung einer funktionalen Korrekt­ heit einer Schaltungseinheit besteht darin, dass Signaltakte auch von unabhängigen Einzeltaktsignalen herrühren können, die wegen einer festgelegten Diskretisierung nicht direkt in eine Testanordnung eingebracht werden können.

In herkömmlicher Weise werden Software-Werkzeuge eingesetzt, welche Simulationssignalverläufe einer Simulation in ein vor­ bestimmtes Diskretisierungsraster einzwängen, wodurch in nachteiliger Weise eine zeitliche Abfolge von Testmustern bzw. Simulationssignalverläufen verändert wird.

Noch ein weiterer Nachteil herkömmlicher Verfahren zum Durch­ führen von Simulationen zur Überprüfung einer funktionalen Korrektheit eines Schaltungsentwurfs besteht darin, dass auf­ grund einer Einzwängung in Diskretisierungsraster Testmuster­ signalverläufe bzw. Simulationssignalverläufe verändert wer­ den, was zu ungültigen funktionalen Testmustern bzw. zu dis­ kretisierungs-gerasterten Simulationssignalverläufen führt, welche für Tests zur Überprüfung einer funktionalen Korrekt­ heit eines Schaltungsentwurfs im Tester nicht verwendbar sind, wodurch eine Re-Simulation erforderlich wird.

Darüber hinaus besteht ein Nachteil herkömmlicher Verfahren zum Durchführen von Simulationen darin, dass im Falle eines Auftretens nicht verarbeitbarer Testmuster ein manuelles Ein­ greifen erforderlich wird.

Es ist somit eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Simulieren einer zu verifizierenden Schaltungs­ einheit zur Überprüfung einer funktionalen Korrektheit der Schaltungseinheit bereitzustellen, welches alle bei einem Durchführen von Simulationen vorkommenden Signalverzögerungs­ zeiten und Einzeltaktsignale bzw. Simulationssignalverläufe explizit oder implizit auf einen einzigen Testtakt bezieht.

Diese Aufgabe wird durch ein Verfahren zum Simulieren einer zu verifizierenden Schaltungseinheit nach Anspruch 1 gelöst.

Kern der Erfindung ist ein Verfahren zum Simulieren einer zu verifizierenden Schaltungseinheit, wobei ein Testtakt (Refe­ renztakt) bereits in die Simulation eingebracht wird und alle Signalverzögerungszeiten und Einzeltaktsignale bzw. Simulati­ onssignalverläufe auf den Testtakt bezogen werden.

Es ist somit ein Vorteil der vorliegenden Erfindung, dass be­ liebige Simulationssignalverläufe von funktionalen Simulatio­ nen, wie beispielsweise auch von Simulationen, die von unab­ hängigen Einzeltaktsignalen herrühren können, direkt in eine Testanordnung im Tester eingebracht und übernommen werden können.

Ein weiterer wesentlicher Vorteil der vorliegenden Erfindung besteht darin, dass eine Einzwängung von funktionalen Test­ mustern in Diskretisierungsraster nicht erfolgt, wodurch un­ gültige funktionale Testmuster bzw. unerwünschte diskretisie­ rungs-gerasterte Simulationssignalverläufe vermieden werden.

Weiterhin werden Testmuster für Simulationen zur Überprüfung einer funktionalen Korrektheit eines Schaltungsentwurfs wie­ derverwendbar, wodurch eine Re-Simulation vermieden wird.

Ferner ist es vorteilhaft, dass sämtliche Signalverzögerungs­ zeiten und Einzeltaktsignale, die zum Durchführen von Simula­ tionen eingesetzt werden, auf einen einzigen Testtakt bezogen werden.

In den Unteransprüchen finden sich vorteilhafte Weiterbildun­ gen und Verbesserungen des jeweiligen Gegenstandes der Erfin­ dung.

Gemäß einer bevorzugten Weiterbildung der vorliegenden Erfin­ dung werden vorgebbare Simulationssignalverläufe bereits wäh­ rend sämtlicher Simulationen in ein Zeitraster eines mögli­ chen Testtakts eingebracht.

Gemäß einer weiteren bevorzugten Weiterbildung der vorliegen­ den Erfindung erfolgt eine explizite testtakt-bezogene Be­ reitstellung von Signalverzögerungszeiten, indem sämtliche Signalverzögerungen direkt auf einen Testtakt bezogen werden.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung erfolgt eine implizite Testtakt-bezogene Bereitstellung von Signalverzögerungszeiten, indem sämtliche Signalverzögerungen in ganzzahligen Vielfachen einer vorgeb­ baren Testtaktperiode bereitgestellt werden.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung wird als eine aktive Signalflanke eines Testtakts eine positive Signalflanke bestimmt.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung wird als eine aktive Signalflanke eines Testtakts eine negative Signalflanke bestimmt.

Zeichnungen

Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher er­ läutert.

In den Zeichnungen zeigen:

Fig. 1 eine zu verifizierende Schaltungseinheit, die über eine Testbenchelementschale mit mindestens einem Testbenchelement verbunden ist, welches durch einen Testbench-Controller angesteuert wird;

Fig. 2 eine Anordnung zum Durchführen von Simulationen, wobei die in Fig. 1 gezeigte Synchronisation in der Testbenchelementschale durch eine Synchronisa­ tion in den Testbenchelementen selbst ersetzt ist;

Fig. 3 eine Anordnung zur Durchführung von Simulationen zur Überprüfung einer funktionalen Korrektheit ei­ ner Schaltungseinheit nach dem Stand der Technik; und

Fig. 4 ein Zeitverlaufsdiagramm eines Simulatiossignalver­ laufs im Vergleich zu einem Zeitverlaufsdiagramm eines diskretisierungs-gerasterten Simulatios­ signalverlaufs gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

Ausführungsbeispiele

Fig. 1 zeigt eine zwischen einer zu verifizierenden Schal­ tungseinheit 101 und entsprechenden Testbenchelementen 102a, 102b und 102c angeordnete Testbenchelementschale 201. Bei der in Fig. 1 gezeigten Schaltungsanordnung ist allgemein eine Testbenchelementschale 201 bereitgestellt, welche als Verbin­ dungselement zwischen mindestens einem Testbenchelement 102a-102c und einer zu verifizierenden Schaltungseinheit 101 dient, wobei beispielhaft drei Testbenchelemente 102a, 102b und 102c gezeigt sind, wobei die Testbenchelemente 102a und 102b serielle Schnittstellen aufweisen, um mit einer Testbench­ elementschale 201 serielle Testdatenströme 112 auszutau­ schen, und das Testbenchelement 102c mit einer parallelen Schnittstelle versehen ist, um einen parallelen Testdaten­ strom 113 mit der Testbenchelementschale 201 auszutauschen.

Es sei jedoch darauf hingewiesen, dass mehr als drei Testbench­ elemente an die Testbenchelementschale 201 anschliessbar sind.

In dem in Fig. 1 gezeigten Ausführungsbeispiel ist die Testbenchelementschale 201 wiederum mit einer zu verifizie­ rende Schaltungseinheit 101 über Schnittstellendatenströme P0(0)-P0(7) verbunden, wobei hier insgesamt acht Leitungen für einen Austausch der Datenströme zwischen den Schnittstel­ len bereitgestellt sind. Jedes einzelne Testbenchelement 102a-102c enthält spezifische Steuerdatenströme 111a-111c von einem Testbench-Controller 103.

Weiterhin wird, wie durch eine gestrichelte Linie 111d ange­ zeigt, ein Steuerdatenstrom direkt von dem Testbench- Controller 103 zu der Testbenchelementschale 201 geleitet, um ein Festlegen spezifischer Konfigurationen von Schnittstellen zu ermöglichen. Weitere Steuerdatenströme, wie durch einen gestrichelten Pfeil 111i angezeigt (i = Laufindex), verdeut­ lichen, dass mehr als drei Testbenchelemente 102a-102c von dem Testbench-Controller 103 angesteuert werden können.

Fig. 2 verdeutlicht ein weiteres Ausführungsbeispiel der vorliegenden Erfindung, wobei die in Fig. 1 gezeigte Testbenchelementschale 201 nicht mehr vorhanden ist.

Gleiche Bezugszeichen wie in Fig. 1 bezeichnen gleiche oder funktionsgleiche Komponenten, deren Erklärung hier zur Ver­ einfachung, und um eine überlappende Beschreibung zu vermei­ den, weggelassen wird.

Ein Steuerelement 104, das als eine Datei oder ein Software- Programm bereitgestellt werden kann, versorgt einen Testbench-Controller 103 mit einem Controller-Datenstrom 114. Ein Testtakt 309 wird den hier gezeigten drei Testbenchele­ menten 102a, 102b und 102c direkt zugeführt, wodurch die Testbenchelemente 102a-102c befähigt sind, selbst eine Syn­ chronisation auszuführen. Diese Synchronisation wird intern ausgeführt und kann explizit oder implizit bereitgestellt werden, was folgendes bedeutet:

• a) "explizit":
  "wait until event" bzw. warten auf ein Ereignis, worauf dann eine entsprechende Synchronisation vorgenommen wird, wobei ein Ereignis in der Regel von einem Testtakt abgeleitet wird und beispielsweise als
  • - eine Über- oder Unterschreitung eines Schwellwerts,
  • - ein Auftreten einer vorbestimmten Signalflanke,
  • - etc.
  bereitgestellt wird; und
• b) "implizit"
  "wait for N *clock_period" oder "after M *clock_period", wo­ bei N und M ganzzahlige Ausdrücke sind und clock_period die Dauer einer Periode des Referenztaktes (Testtaktes) ist, bzw. warten für eine vorbestimmte Zeit, bis eine entsprechende Synchronisation vorgenommen wird.

Obwohl nur drei Testbenchelemente 102a, 102b und 102c in der Fig. 2 veranschaulicht sind, sei darauf hingewiesen, dass auch mehr als drei oder weniger als drei Testbenchelemente, allgemein eine Anzahl von n Testbenchelementen vorhanden sein kann (i = Laufindex).

Unter Bezugnahme auf Fig. 1 sind in der in Fig. 2 gezeigten Anordnung zwei Schnittstellendatenströme zur Verbindung der zu verifizierenden Schaltungseinheit 101 mit den Testbenche­ lementen 102a-102c bereitgestellt, wobei die seriellen Testbenchelemente 102a, 102b über einen seriellen Testdaten­ strom 112 mit der zu verifizierenden Schaltungseinheit 101 verbunden sind, während das gezeigte parallele Testbenchele­ ment 102c über einen parallelen Testdatenstrom 113 mit der zu verifizierende Schaltungseinheit 101 verbunden ist.

Fig. 4 zeigt ein Zeitverlaufsdiagramm eines Simulationssig­ nalverlaufs im Vergleich zu einem Zeitverlaufsdiagramm eines diskretisierungs-gerasterten Simulationssignalverlaufs gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

In dem in Fig. 4 gezeigten Zeitverlaufsdiagramm ist erkenn­ bar, dass ein beliebiger, durch eine Simulationsanordnung vorgegebener Simulationssignalverlauf 401 nicht exakt oder überhaupt nicht in ein durch Diskretisierungsraster-Zyklen 403a, 403b, 403c, . . . 403l definiertes Diskretisierungsraster einpassbar ist. Wird der Simulationssignalverlauf 401 in das durch die Diskretisierungsraster-Zyklen 403a, 403b, 403c, . . . 403l definierte Diskretisierungsraster gezwängt, ergeben sich nicht tolerierbare Signalverlaufsverfälschungen, die zu einem diskretisierungs-gerasterten Signalverlauf 402 führen, wel­ cher in dem in Fig. 4 gezeigten Zeitverlaufsdiagramm unter­ halb des vorgegebenen Simulationssignalverlaufs 401 darge­ stellt ist.

Unter Bezugnahme auf das in der Fig. 1 gezeigte Schalenkon­ zept wird eine Testbenchelementschale bzw. mindestens eine Signalverzögerungsschale bereitgestellt, die als eine Syn­ chronisationsschale verwendet wird.

Hierbei werden vorgebbare Simulationssignalverläufe, d. h. nur taktbezogene, auf unabhängige Testtakte bezogene oder auf Testtakte mit einer Signalverzögerungszeit bezogene Simulati­ onssignalverläufe bereits während sämtlicher Simulationen in ein Zeitraster eines möglichen Testtakts eingezwängt.

Bei einer expliziten taktbezogenen Bereitstellung von Signal­ verzögerungszeiten bei Testmustern zum Durchführen von Simu­ lationen zur Überprüfung einer funktionalen Korrektheit einer Schaltungseinheit werden sämtliche Signalverzögerungen direkt auf einen Testtakt bezogen, der als ein virtueller Takt (vc = virtual clock) bezeichnet wird. Eine Bezugnahme auf einen Testtakt kann kontrollflussorientiert, z. B. in VHDL durch "wait until virtual_clock = '1'" durchgeführt werden. VHDL- Codes (VHDL = very high speed integrated circuits hardware description language) sind beispielsweise aus: "Basic, Jür­ gen: Entwicklung digitaler Systeme mit VHDL-Einsatz und An­ wendungen von VHDL zur Simulation und zur Synthese von digi­ talen Systemen, Eigenverlag, 1999, ISBN 3-00-005081-7" be­ kannt.

Weiterhin kann eine Bezugnahme von Signalverzögerungszeiten auf einen Testtakt datenflussorientiert mittels nur testtakt­ bezogener Signalverzögerungen durchgeführt werden, was in VHDL durch Signalverzögerungsprozeduren ermöglicht wird, wo­ bei ein Quelltext einer derartigen Prozedur beispielsweise wie folgt lautet:

Weiterhin ist eine implizit testtakt-bezogene Bereitstellung von Signalverzögerungszeiten durch das gezeigte Ausführungs­ beispiel des erfindungsgemäßen Verfahrens ermöglicht. Bei ei­ ner impliziten Testtakt-bezogenen Bereitstellung von Signal­ verzögerungen werden sämtliche Signalverzögerungszeiten nur in ganzzahligen Vielfachen einer global spezifizierten Test­ taktperiode bereitgestellt, wobei die Testtaktperiode in ei­ nem VHDL-Code wie folgt definiert werden kann:
package virutal_clock_period_package is
constant virtual_clock_period: time: = 1 ns;
end virtual_clock_period_package;

Eine Bereitstellung von Signalverzögerungszeiten erfolgt mit­ tels wait for N *virtual_clock_period kontrollflussorientiert oder mittels M *virtual_clock_period datenflussorientiert, wobei N und M beliebige ganzzahlige Ausdrücke darstellen.

Obwohl die vorliegende Erfindung vorstehend anhand bevorzug­ ter Ausführungsbeispiele beschrieben wurde, ist sie darauf nicht beschränkt, sondern auf vielfältige Weise modifizier­ bar.

Bezugszeichenliste

101

Zu verifizierende Schaltungseinheit

102

a, . . .

102

i, . . .

102

n Testbenchelemente (i = Laufindex)

103

Testbench-Controller

104

Steuerelement

111

a, . . .

111

i, . . .

111

n Steuerdatenstrom (i = Laufindex)

112

Serieller Testdatenstrom

113

Paralleler Testdatenstrom

114

Controller-Datenstrom

201

Testbenchelementschale

309

Testtakt
P0(0), . . ., P0(7) Erste Schnittstellendatenströme
P1(0), . . ., P1(7) Zweite Schnittstellendatenströme

401

Simulationssignalverlauf

402

diskretisierungs-gerastertes Simulationssig­ nalverlauf

403

a, . . .

403

l Diskretisierungsraster-Zyklen

Claims (7)

1. Verfahren zum Simulieren einer zu verifizierenden Schal­ tungseinheit (101) in einer Testanordnung, bei dem Simulati­ onssignalverläufe (401, 402) von Testmustern vorgebbar sind, mit den folgenden Schritten:

• a) Ableiten mindestens eines Testtakts (309) aus einer Test­ anordnung, die eine zu verifizierende Schaltungseinheit (101) einschließt;
• b) Bestimmen mindestens einer aktiven Signalflanke des emp­ fangenen Testtakts (309);
• c) Empfangen mindestens eines Testmusters aus der Testanord­ nung;
• d) Einstellen von Signalverzögerungszeiten für mindestens ein Testmuster;
• e) Erzeugen von mindestens einem Simulationssignalverlauf (401, 402) aus dem verzögerten Testmuster; und
• f) Zuführen des mindestens einen Simulationssignalverlaufs (401, 402) als Einzeltaktsignal zu der zu verifizierenden Schaltungseinheit (101).

2. Verfahren zum Simulieren einer zu verifizierenden Schal­ tungseinheit (101) nach Anspruch 1, dadurch gekennzeichnet, dass vorgebbare Simulationssignalverläufe (401) in ein Zeit­ raster eines Testtakts (309) eingebracht werden.

3. Verfahren zum Simulieren einer zu verifizierenden Schal­ tungseinheit (101) nach einem oder beiden der Ansprüche 1 und 2, dadurch gekennzeichnet, dass eine explizite Testtakt-bezogene Bereitstellung von Sig­ nalverzögerungszeiten erfolgt, indem sämtliche Signalverzöge­ rungen direkt auf den Testtakt (309) bezogen werden.

4. Verfahren zum Simulieren einer zu verifizierenden Schal­ tungseinheit (101) nach einem oder mehreren der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass eine implizite testtakt-bezogene Bereitstellung von Sig­ nalverzögerungszeiten erfolgt, indem sämtliche Signalverzöge­ rungen in ganzzahligen Vielfachen einer vorgebbaren Testtakt­ periode bereitgestellt werden.

5. Verfahren zum Simulieren einer zu verifizierenden Schal­ tungseinheit (101) nach einem oder mehreren der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass als eine aktive Signalflanke des Testtakts (309) eine positive Signalflanke bestimmt wird.

6. Verfahren zum Simulieren einer zu verifizierenden Schal­ tungseinheit (101) nach einem oder mehreren der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass als eine aktive Signalflanke des Testtakts (309) eine negative Signalflanke bestimmt wird.

7. Verfahren zum Simulieren einer zu verifizierenden Schal­ tungseinheit (101) nach einem oder mehreren der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass eine vorgebbare zeitliche Abfolge von Testmustern be­ reitgestellt wird.