DE10160633C1 - Verfahren und Vorrichtung zum Simulieren einer zu verifizierenden Schaltungseinheit - Google Patents

Abstract

Die Erfindung schafft ein Verfahren zum Simulieren einer zu verifizierenden Schaltungseinheit (101), bei dem Schaltungskomponenten einer Testbench (100) zeiteffizient zusammenwirken, wobei die zu verifizierende Schaltungseinheit (101) an mindestens ein Testbenchelement (102a-102c) zum Durchleiten von Schnittstellendatenströmen (115a-115c) angeschlossen wird, die Testbenchelemente (102a-102c) mit Befehlsdatenströmen (117a-117c) aus einer Befehlsspeichereinheit (107) beaufschlagt werden, die Testbenchelemente (102a-102c) und die zu verifizierende Schaltungseinheit (101) mittels eines von einem Taktgenerator (106) bereitgestellten Taktsignals (105) getaktet werden, mindestens ein Simulationsergebnis durch Ergebnisdatenströme (118a-118c) aus den Testbenchelementen (102a-102c) nach einem Simulieren der zu verifizierenden Schaltungseinheit (101) zu einer Ergebnisspeichereinheit (108) ausgegeben wird, und das mindestens ein Simulationsergebnis in einer über einen Testbench-Controller (103) angeschlossenen Recheneinrichtung (116) ausgewertet wird, wobei der steuerbare Taktgenerator (106) zum Anhalten und Wiederaufnehmen des Taktsignals (105) gesteuert wird.

Description

Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum Simulieren einer zu verifizierenden Schal­ tungseinheit.

Aus der WO 01/37089 A2 sind ein Verfahren und eine Vorrich­ tung zum Simulieren einer zu verifizierenden Schaltungsein­ heit bekannt, wobei Testbenchelemente an die zu verifizieren­ de Schaltungseinheit angeschlossen sind, die mit Befehlsda­ tenströmen beaufschlagt werden. Es werden Ergebnisdatenströme aus den Testbenchelementen ausgegeben, welche in einem Rech­ ner ausgewertet werden. Die Schaltungskomponenten werden durch einen gemeinsamen Takt getaktet.

Bei einem Entwurf einer Hardware ist eine Durchführung von Tests und Simulationen zur Überprüfung einer funktionalen Korrektheit eines Schaltungsentwurfs besonders wichtig, wobei der Aufwand zur Erstellung sogenannter "Testbenches" mit der Komplexheit eines Schaltungsentwurfs ständig zunimmt.

Testbenches sind beispielsweise Modelle, welche die Umgebung eines Schaltungsentwurfs und entsprechende Eingangssignale und von diesen Eingangssignalen abhängige Ausgangssignale, beispielsweise Signalantworten, nachbilden. Derartige Testbenches können als Hardware-Testbenches, wie in der vor­ liegenden Erfindung, oder als Software-Testbenches ausgebil­ det sein.

Testbench-Modelle sind z. B., aber nicht ausschließlich, in Hardware-Beschreibungssprachen wie VERILOG und VHDL ausge­ führt. In vielen Fällen ist eine Co-Simulation von Hardware- und Software-Einheiten realisierbar, wie beispielsweise in "Matthias Bauer, Wolfgang Ecker: Hardware/Software Co-Simu­ lation in a VHDL-based Test Bench Approach, DAC 97, Anaheim, California, U.S.A." beschrieben.

In einer Testbench wird beispielsweise ein Modell einer Schaltungseinheit bzw. eines Schaltungs-/Schaltkreis-Bau­ steins simuliert, wobei in vielen Fällen neben einer Funktio­ nalität des Schaltungsentwurfs auch ein Zeitverhalten bzw. ein zeiteffizientes Zusammenwirken von Schaltungskomponenten zu berücksichtigen ist.

Testbenches nach dem Stand der Technik sind beispielsweise derart ausgebildet, dass mindestens ein Testbenchelement als logische Schnittstelle zwischen einem Testbench-Controller und einer zu verifizierenden Schaltungseinheit bereitgestellt ist.

Ein Testbenchelement kann beispielsweise als ein Transaktor oder als ein Protokollgenerator ausgeführt sein, wobei das jeweilige Testbenchelement die für eine logische Schnittstel­ le benötigten Signalwertverläufe erzeugt. Eine Verknüpfung der Signale sowie eine Festlegung der entsprechenden Signal­ wertverläufe 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, und wobei derartige Protokollopera­ tionen wiederum ineinander geschachtelt sein können, um bei­ spielsweise folgende Operationen auszuführen:

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

Eine derartige protokolloperations-bezogene Beschreibung erleichtert eine Auslegung von Testbenchelementen, welche wiederum mehrfach bei einer Durchführung von Simulationen wiederverwendet werden können.

Es existieren unterschiedliche Schnittstellen, welche im Zusammenhang mit Testbenches einsetzbar sind.

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 gemischte analoge und digitale Signale verarbeitet wer­ den.

In sinnvoller Weise werden Testbenchelemente derart ausge­ legt, dass sie unter möglichst vielen Simulations-Randbedin­ gungen bei möglichst vielen zu verifizierenden Schaltungsein­ heiten eingesetzt werden können.

In herkömmlicher Weise wird ein Testbench-Controller als ein zentrales Steuerelement eingesetzt, durch welchen es ermög­ licht wird, den Gesamtablauf einer Simulation zu steuern. Der Testbench-Controller wird in herkömmlicher Weise mit einem Simulationsprogramm beaufschlagt, das zentral bereitgestellt wird.

Herkömmliche Test- und Simulationsverfahren verwenden somit überwiegend Testbench-Architekturen, welche von einem Testbench-Controller als zentrale Einheit gesteuert werden, wobei den einzelnen Testbenchelementen übermittelt wird, welche Protokolloperationen 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 Protokollopera­ tionen ausgeführt bzw. beendet wurde.

Fig. 2 zeigt ein herkömmliches Verfahren zum Simulieren und Testen einer zu verifizierenden Schaltungseinheit 101 mittels eines in einem Steuerelement 104 abgelegten Testprogramms. Wie in Fig. 2 gezeigt, ist das Steuerelement 104, welches ein spezifisches Testprogramm enthält, an den Testbench- Controller 103 anschlossen, wobei ein Datenstrom 114 von dem Steuerelement 104 zu dem Testbench-Controller 103 übermittelt wird. Ein üblicher Anschluss von Testbenchelementen 102a-102n erfolgt in herkömmlicher Weise mittels Steuerdatenströmen 111a-111n.

Es sei darauf hingewiesen, dass ein oder mehrere Testbenche­ lemente 102a, . . .102i, . . .102n vorhanden sein können, wobei i einen Laufindex darstellt.

Beispielhaft sind in Fig. 2 fünf unterschiedliche Testben­ chelemente dargestellt, wobei das Testbenchelement 102a bei­ spielsweise einer seriellen Schnittstelle entspricht, die Daten mittels eines seriellen Datenstroms (verdeutlicht durch eine einzelne Linie in Fig. 2) mit der zu verifizierenden Schaltungseinheit 101 austauscht.

Als weiteres Beispiel ist das Testbenchelement 102n als eine parallele Schnittstelle dargestellt, die Daten mit der zu verifizierenden Schaltungseinheit 101 mittels eines paralle­ len Datenstroms (verdeutlicht durch drei Linien in Fig. 2) austauscht.

In ähnlicher Weise erfolgt ein Datenaustausch zwischen den übrigen Testbenchelementen und der zu verifizierenden Schal­ tungseinheit 101, wobei spezifizierte Datenströme (nicht gezeigt) ausgetauscht werden. Veranschaulichend sind in Fig. 2 fünf Testbenchelemente 102a, 102b, 102i, 102i + 1 und 102n dargestellt, es können jedoch weniger oder mehr Testbenchele­ mente 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.

Bei einer Hardware-Testbench besteht in nachteiliger Weise das Problem, dass nur ein konkreter definierbarer Speicher - mit einer beschränkten Speicherkapazität für die zur Simula­ tion einer zu verifizierenden Schaltungseinheit benötigten Befehlsdatenströme - zur Verfügung steht. Gleiches gilt für die bereitgestellten Ergebnisdatenströme, die erhalten wer­ den, nachdem eine zu verifizierende Schaltungseinheit verifi­ ziert wurde.

Bei herkömmlichen Verfahren und Vorrichtungen zur Simulation von zu verifizierenden Schaltungseinheiten müssen, wenn vor­ gegebene Speichereinheiten nicht ausreichen, aufwändige und kostenintensive Nachrüstungen bereitgestellt werden.

Weiterhin ist es nachteilig, dass bei einer festen, vorgege­ benen Speicherkapazität die Befehlsdatenströme in passende Datenstromeinheiten aufgeteilt werden müssen, so dass die Speicherkapazität möglichst effizient genutzt wird. In nachteiliger Weise müssen die einzelnen Datenstromeinheiten dann nacheinander mit neu zu erstellenden Verifikations- bzw. Simulationsläufen gestartet werden.

Um bei einer Überprüfung einer funktionalen Korrektheit eines Schaltungsentwurfs im Hardware-Bereich arbeiten zu können, müssen generische, wiederverwendbare Hardware-Testbenches erstellt werden, die weiterhin voll synthesefähig sind und für möglichst viele Hardware-Schaltungskonzepte, wie bei­ spielsweise Beschleuniger, FPGAs, unterschiedliche Boards, etc. verfügbar sind.

Während bei einer Software-Testbench mit Hilfe einer Defini­ tion von Simulationszyklen, welche in einer Recheneinrichtung beliebig lange andauern können, zusätzliche Aktivitäten, beispielsweise Zusatzberechnungen von Werten für die Generie­ rung oder Evaluierung von Testvektoren, ohne einen Zyklenver­ lust bereitgestellt werden können, sind derartige Aktivitäten bei einer Hardware-Testbench nicht durchführbar. Bei einer herkömmlichen Hardware-Testbench besteht das Problem, dass keine Simulationszyklen zur Verfügung stehen, die keine Simu­ lationszeit verbrauchen, wie beispielsweise sogenannte "Del­ ta-Zyklen" in VHDL.

Weiterhin ist es bei einer herkömmlichen Hardware-Testbench unzweckmäßig, dass die Simulationszyklen durch einen Takt, welcher nicht zur Laufzeit verändert werden kann, in ein starres zeitliches Raster eingepasst sind.

Bei herkömmlichen Hardware-Testbenches kann somit in nachtei­ liger Weise nicht sichergestellt werden, dass gegebenenfalls erforderliche Berechnungen in der zur Verfügung stehenden Zeit (in einem Simulationszyklus) ausführbar sind, wodurch beispielsweise fehlerhafte Zustandsänderungen auftreten kön­ nen, so dass das simulierte Verhalten nicht mehr der schluss­ endlich erstellten Schaltungseinrichtung entspricht.

Ein Gleichlauf der Testbench und der zu verifizierenden Schaltungseinheit muss daher bereitgestellt und gesichert werden können. Andernfalls sind, wenn die Testbench und die zu verifizierende Schaltungseinheit mit dem gleichen Takt bzw. dem gleichen Taktsignal laufen, Synchronisationen zwi­ schen einzelnen Testbenchelementen, eine Kommunikation mit externen, nicht unmittelbar in der Hardware-Testbench enthal­ tenen Komponenten, aufwändigere Berechnungen oder weitere untenstehend beschriebene Betriebsweisen wie z. B. ein Nachla­ den von Speicherwerten oder ein zusätzliches Auslesen von Speicherinhalten in herkömmlichen Test- und Simulationsanord­ nungen nicht möglich.

Weiterhin kann eine Testbench mit einem Vielfachen des Taktes der zu verifizierenden Schaltungseinheit betrieben werden, wodurch Berechnungen und optionale Betriebsweisen zwar einen ausreichenden zeitlichen Spielraum erhalten und ohne einen Zyklenverlust ausgeführt werden können, wobei jedoch in nachteiliger Weise die zu verifizierende Schaltungseinheit die langsamste Schaltungskomponente einer Hardware-Testbench darstellt. Dadurch wird in beträchtlicher Wesie Simulations­ zeit verschwendet, da die zu verifizierende Schaltungseinheit lediglich mit einem Bruchteil der maximal möglichen Geschwin­ digkeit betreibbar ist und somit der gesamte Testablauf ver­ zögert wird.

Damit bei einem Einsatz von Hardware-Testbenches Werte und Abläufe wie Befehlssequenzen (bzw. Datenstromeinheiten) und Simulationsergebnisse gewertet und korreliert werden können, ist ein Zeitmaß bzw. eine Zeitgebung erforderlich. Bei einem Auftreten von unerwarteten oder falschen Werten bzw. Signalen müssen somit sinnvolle und aussagekräftige Meldungen mit einem in einfacher Weise zuzuordnenden Zeitpunkt im Ablauf erzeugbar sein.

In nachteiliger Weise ist bei herkömmlichen Hardware- Testbenches keine Möglichkeit vorgesehen, einen Zeitfort­ schritt abzulesen. Bisher wurden bei Software-Simulationen virtuelle Zeiten bereitgestellt. Bei einem Software-Simulator kann bei einem kontinuierlich gleichlaufenden Takt auf eine Taktzeit mittels einer Skalierung geschlossen werden. Es bestehen daher bei herkömmlichen Hardware-Testbenches Nach­ teile in der Auswertung, der Interpretation und der Kontrolle von Testabläufen/Simulationsabläufen, da keine Referenzzeit­ punkte bereitgestellt und der Testablauf/Simulationsablauf nicht eindeutig rekonstruiert werden kann.

Es bestehen darüber hinaus erhebliche Nachteile von herkömm­ lichen Hardware-Testbenches darin, dass Befehlssequenzen bzw. Datenstromeinheiten in einem Speicher abgelegt werden müssen, der bei einer Erhöhung der Anzahl von Befehlen zunehmend größer und kostenaufwändiger wird. Ein Problem hierbei be­ steht auch darin, dass der Umfang und die Komplexität eines Testablaufs durch den vorhandenen Speicher eingeschränkt wird und somit eine Verwendung hinreichend aussagekräftiger Test­ ablaufe erst durch eine ausreichend großen Speicher sicherge­ stellt werden kann. Eine Alternative wäre eine gekoppelte Hardware-Software-Simulation, bei welcher einzelne Module bereits in Hardware realisiert sind, während weitere Module in einer Recheneinrichtung bereitgestellt werden. In unzweck­ mäßiger Weise entsteht durch eine aufwändige Software- Hardware-Kommunikation ein erheblicher Zeitverlust, so dass ein durch den Hardware-Teil erzielter Geschwindigkeitsgewinn teilweise oder gänzlich verloren geht.

Es ist somit eine Aufgabe der vorliegenden Erfindung, ein Verfahren und eine Hardware-Testbench zum Simulieren einer zu verifizierenden Schaltungseinheit bereitzustellen, wobei Speicherinhalte für Befehlsspeichereinheiten und Ergebnis­ speichereinheiten nachladbar sind, Taktsignale flexibel vor­ gebbar und Taktzyklen abzählbar sind, um eine effiziente Zeitgebung bei einer Zusammenwirkung von Schaltungskomponen­ ten der Testbench bereitzustellen, ein Referenzzeitmaß be­ reitzustellen, sowie die Ausführung komplexer und umfangrei­ cher Testabläufe zu ermöglichen.

Diese Aufgabe wird erfindungsgemäß durch das im Patentan­ spruch 1 angegebene Verfahren sowie durch eine Vorrichtung mit den Merkmalen des Patentanspruchs 15 gelöst. Weitere Ausgestaltungen der Erfindung ergeben sich aus den Unteran­ sprüchen.

Ein wesentlicher Gedanke der Erfindung besteht darin, dass Speicherinhalte flexibel nachladbar und Simulationsergebnisse flexibel ausgebbar sind, indem in einer Testbench mindestens eine Einheit zur Speicherung von Befehlen und Ergebnissen bereitgestellt wird, die bevorzugtermaßen als jeweils eine explizite Befehlsspeichereinheit bzw. eine explizite Ergeb­ nisspeichereinheit ausgebildet sein kann, wobei Zeitgebungen mittels eines steuerbaren Taktgenerators, der vorgebbar an­ gehalten werden kann, einstellbar sind, und wobei ein Taktzy­ klenzähler Taktzyklen mitzählt und ein Maß eines Zeitfort­ schritts liefert.

Es ist somit ein Vorteil der vorliegenden Erfindung, dass vorhandene Hardware-Testbenches zeiteffizient genutzt werden können, ohne kostenintensive und vom Installationsaufwand aufwändige Zusatzspeichereinrichtungen bereitstellen zu müs­ sen.

Weiterhin ist es zweckmäßig, dass durch die vorliegende Er­ findung ein unnötiger Zeitverlust durch eine Software- Hardware-Kommunikation vermieden wird, indem der Simulation­ sablauf vollständig in Hardware abgearbeitet wird, lediglich Befehle und Meldungen, die in der mindestens einen Spei­ chereinheit abgelegt werden, zeiteffizient übertragen werden, Taktsignale flexibel anhaltbar sind und Taktzyklen zählbar sind.

Dies führt zu dem weiteren Vorteil, dass komplexe Test- und Simulationsabläufe zur Simulation von zu verifizierenden Schaltungseinheiten bereitgestellt werden können, wobeigemäß einer vorgebbaren Zeitgebung Befehle nachgeladen werden bzw. Simulationsergebnisse aus Ergebnisspeichereinheiten abgerufen bzw. ausgelesen werden.

In vorteilhafter Weise werden vorgebbare, für Test- und Simu­ lationsabläufe erforderliche Zeitpunkte als Bezugszeitpunkte dadurch bestimmt, dass mittels mindestens eines Taktzyklen­ zählers spezifische Taktzyklen gezählt werden.

Weitere Vorteile des erfindungsgemäßen Verfahrens und der Vorrichtung zur Simulation einer zu verifizierenden Schal­ tungseinheit bestehen in einer Austauschbarkeit von Software- Testbenches und Hardware-Testbenches, wobei beide Versionen von Testbenches sich bezüglich von Schnittstellen zu einer zu verifizierenden Schaltungseinheit identisch verhalten und eine Synchronisation zwischen Testbenchelementen ohne einen Taktzyklenverlust bei der zu verifizierenden Schaltungsein­ heit ermöglicht wird. Ein Taktsignal für eine zu verifizie­ rende Schaltungseinheit kann angehalten werden, wenn Befehls­ sequenzen, die sich aktuell in einer Befehlsspeichereinheit befinden, abgearbeitet sind und ein Auslesen von Registerin­ halten der zu verifizierenden Schaltungseinheit kann bereit­ gestellt werden. Eine Bearbeitung von Einstellbefehlen kann ermöglicht werden, ohne dass die zu verifizierende Schal­ tungseinheit ihren Zustand ändert, und aufwändige Berechnun­ gen innerhalb der Testbench, die nicht innerhalb eines Takt­ zyklus erfolgen können, erhalten mit Hilfe eines Taktabschal­ tens ausreichend Abarbeitungszeit.

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 Speicherinhalte der Befehlsspeichereinheit mit­ tels des Testbench-Controllers nachgeladen, wobei in vorteil­ hafter Weise eine spezifische Zeitgebung in der Hardware- Testbenchangehalten werden kann.

Gemäß einer bevorzugten Weiterbildung der vorliegenden Er­ findung ist die Zeitgebung vorgebbar und die Taktzyklen können in vorteilhafter Weise gezählt werden.

Gemäß einer weiteren bevorzugten Weiterbildung der vorliegen­ den Erfindung werden Speicherinhalte aus der Ergebnisspei­ chereinheit als Simulationsergebnisse mittels des Testbench- Controllers ausgelesen, wobei ein Auslesen der Simulationser­ gebnisse in vorteilhafter Weise entsprechend einem Nachladen von Befehlssequenzen in die Befehlsspeichereinheit ausgeführt wird.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung wird ein Takt mittels einer Steuerung durch den Takt-Controller angehalten, um eine Synchronisation der Schaltungskomponenten der Testbench - beispielsweise auch explizit durch den Testbench-Controller - bereitzustellen, wobei insbesondere eine Synchronisation zwischen der zu veri­ fizierenden Schaltungseinheit und den angeschlossenen Testbenchelementen bereitgestellt wird.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung wird ein Takt mittels des Takt- Controllers angehalten, um zusätzliche Rechenzyklen zum Durchführen von Rechenoperationen zu erhalten, so dass ein effizientes Zusammenwirken der Schaltungskomponenten der Testbench ermöglicht wird.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung analysiert eine Schaltungslogik in dem Takt-Controller Datenströme, die von den Testbenchelementen ausgegeben werden, um eine spezifisch vorgebbare oder automa­ tisch adaptierbare Taktgebung bereitzustellen.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung werden Taktzyklen mittels eines Taktzy­ klenzählers gezählt, um der Testbench vorgebbare Taktzeit­ punkte bereitzustellen.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung wird durch ein Steuern des Taktsignals mittels des Takt-Controllers ein vorgebbares Ausblenden und/oder Anhalten von Taktsignalen bereitgestellt, um eine optimale Zeitgebung zu ermöglichen.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung zählt der Taktzyklenzähler Taktzyklen mindestens eines Taktsignals, um eine Synchronisation auf unterschiedliche Zeitgebungen von Schaltungskomponenten in der Testbench bereitzustellen.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung wird der Taktzyklenzähler für Simulati­ onstakte und für Takte der Testbench gleichermaßen bereitge­ stellt.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung wird ein Nachladen von Speicherinhalten der Befehlsspeichereinheit durch einen Adresszeiger, durch eine Befehlssequenz oder durch einen externen Plattenspeicher gesteuert. Weiterhin kann ein Nachladen von Speicherinhalten der Befehlsspeichereinheit in einer kontinuierlichen Weise bereitgestellt werden.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung wird ein Auslesen von Speicherinhalten der Ergebnisspeichereinheit durch einen Adresszeiger, durch eine Befehlssequenz oder durch einen externen Plattenspeicher gesteuert. Weiterhin kann ein Auslesen von Speicherinhalten der Befehlsspeichereinheit in einer kontinuierlichen Weise bereitgestellt werden.

Gemäß noch einer weiteren bevorzugten Weiterbildung der vor­ liegenden Erfindung wird mindestens ein Zählwert des Taktzy­ klenzählers als ein virtuelles Zeitmaß und/oder ein Referenz­ zeitpunkt bereitgestellt, um einen Simulationsablauf derart zu protokollieren und/oder zu dokumentieren, dass eine exter­ ne Überwachung und eine Auswertung ermöglicht werden.

Weiterhin ist mindestens ein Taktzyklenzähler bereitgestellt, der Taktzyklen des von dem Takt-Controller gelieferten Takt­ signals zählt, so dass in vorteilhafter Weise eine Synchroni­ sation von Schaltungskomponenten der Hardware-Testbench er­ reichbar ist. Der mindestens eine Taktzyklenzähler ist in vorteilhafter Weise als ein Binär-Zähler oder als ein Dezi­ mal-Zähler ausgebildet.

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 Schaltungsanordnung zur Simulation einer zu verifizierenden Schaltungseinheit gemäß einem be­ vorzugten Ausführungsbeispiel der vorliegenden Erfindung;

Fig. 2 eine herkömmliche Schaltungsanordnung zur Simulati­ on einer zu verifizierenden Schaltungseinheit;

Fig. 3 eine Schaltungsanordnung zur Simulation einer zu verifizierenden Schaltungseinheit gemäß einem wei­ teren bevorzugten Ausführungsbeispiel der vorlie­ genden Erfindung, bei der ein Taktzyklenzähler zum Zählen von Taktzyklen bereitgestellt ist;

Fig. 4 ein weiteres Prinzip-Blockbild einer Schaltungsan­ ordnung für eine erfindungsgemäße Hardware- Testbench; und

Fig. 5 ein Zeitverlauf von Befehlssequenzen einer Hard­ ware-Testbench bezüglich eines von einem Takt- Controller bereitgestellten Taktsignals.

In den Figuren bezeichnen gleichen Bezugszeichen gleiche oder funktionsgleiche Komponenten oder Schritte.

In einer in Fig. 1 gezeigten Testbench 100 sind beispielhaft drei Testbenchelemente 102a, 102b und 102c mit einer zu veri­ fizierenden Schaltungseinheit 101 verbunden.

Es sei darauf hingewiesen, dass eine Anzahl von drei Testben­ chelementen 102a-102c nur beispielhaft ist, d. h. es können weniger oder mehr Testbenchelemente an die zu verifizierende Schaltungseinheit 101 angeschlossen sein. Mit den beispiel­ haft gezeigten drei Testbenchelementen 102a-102c tauscht die zu verifizierende Schaltungseinheit 101 jeweils Schnittstel­ lendatenströme 115a, 115b und 115c aus.

Weiterhin erhält die zu verifizierende Schaltungseinheit 101 ein Taktsignal 105 von einem Takt-Controller 106, welcher dieses Taktsignal 105 ebenfalls den Testbenchelementen 102a-­ 102c bereitstellt, um eine Synchronisation zwischen Testben­ chelementen 102a-102c und der zu verifizierenden Schaltungs­ einheit 101 bereitzustellen.

Erfindungsgemäß ist mindestens eine Speichereinheit vorhan­ den, wobei es aufgrund einer vereinfachten Handhabung und Verwaltung der Daten zweckmäßig und praktikabel ist, minde­ stens zwei Speichereinheiten 107 und 108 vorzusehen. Diese Speichereinheiten 107 und 108 speichern einerseits Befehlsse­ quenzen, die z. B. durch einen Testbench-Controller 103 aufbe­ reitet werden, andererseits Simulationsergebnisse aus den Testbenchelementen 102a-102c, bevor diese an den Testbench- Controller 103 weitergeleitet werden. Der Testbench- Controller 103 ist mit einer externen Recheneinrichtung 116 verbunden, welche beispielsweise dazu dient, spezifische Befehlssequenzen vorzugeben bzw. zu erzeugen und die erhalte­ nen Simulationsergebnisse nach einer Simulation der zu veri­ fizierenden Schaltungseinheit 101 auszuwerten.

Weiterhin ist der Testbench-Controller 103 mit dem Takt- Controller 106 zur Steuerung desselben und zum Erhalt von Taktsignalen 105 verbunden. Darüber hinaus kann der Testbench-Controller mit einer ersten Anschlusseinheit 109 und einer zweiten Anschlusseinheit 110 zum Anschluss von weiteren Schaltungseinheiten, beispielsweise weitern Testben­ ches, verbunden sein.

Werden der Befehlsspeichereinheit 107 von dem Takt-Controller Befehlssequenzen zugeführt, so werden diese in der Befehls­ speichereinheit 107 zwischengespeichert und nach einer Steue­ rung durch den Testbench-Controller 103 wird der Takt- Controller 106 aktiviert, und die abgelegten Befehle werden den Testbenchelementen 102a-102c bereitgestellt. Von der Befehlsspeichereinheit 107 werden Befehlsdatenströme 117a, 117b und 117c zu den Testbenchelementen 102a-102c geführt. Die Steuerung des Nachladens von Speicherinhalten in die Befehlsspeichereinheit 107 erfolgt über den Testbench- Controller 103, welcher beispielsweise immer dann aktiv wird, wenn der letzte Speicherinhalt ausgelesen wurde, worauf dann Speicherinhalte neu in die Befehlsspeichereinheit 107 einge­ schrieben werden.

In vorteilhafter Weise ist die externe Recheneinrichtung 116 als ein PC oder als eine Workstation ausgebildet, welche Speicherinhalte beispielsweise in Form von Dateien, Daten­ strukturen oder Tabellen bereitstellt. Weiterhin können Spei­ cherinhalte über die ersten und zweiten Anschlusseinheiten 109 bzw. 110 bereitgestellt werden.

Ein Auslesen von Simulationsergebnissen erfolgt über die Ergebnisspeichereinheit 108. In ähnlicher Weise wie in der Befehlsspeichereinheit 107 erfolgt in der Ergebnisspei­ chereinheit 108 eine Zwischenspeicherung. Die Ergebnisdaten­ ströme 118a, 118b und 118c werden von den entsprechenden Testbenchelementen 102a-102c zu der Ergebnisspeichereinheit 108 geführt.

Fig. 3 zeigt eine Testbench 100 mit einer zu verifizierenden Schaltungseinheit 101, einem Takt-Controller 106 und einem Taktzyklenzähler 302. Der Taktzyklenzähler 302 kann über ein Rücksetzsignal 303 von der Testbench 100 zurückgesetzt wer­ den. Sowohl die Testbench 100 selbst, wie auch die zu verifi­ zierende Schaltungseinheit 101 erhalten das von dem Takt- Controller 106 erzeugte Taktsignal 105.

Der Taktzyklenzähler 302 ist in bevorzugter Weise als ein Binär-Zähler oder als ein Dezimal-Zähler ausgebildet. Es sei jedoch darauf hingewiesen, dass weitere unterschiedliche Ausprägungen und Realisierungen des mindestens einen Taktzy­ klenzählers 302 wie z. B. ein Binärzähler, ein Aiken-Code- Zähler, ein Gray-Code-Zähler etc. möglich sind. Der Zählwert des Taktzyklenzählers 302, d. h. die Anzahl der Taktzyklen 301, werden der Testbench 100 für eine Steuerung einer effi­ zienten Zeitgebung bei einem Zusammenwirken von Schaltungs­ komponenten in der Hardware-Testbench 100 bereitgestellt.

Fig. 4 zeigt ein weiteres bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung. Gleiche Bezugszeichen entsprechen gleichen Komponenten wie unter Bezugnahme auf Fig. 1 be­ schrieben, so dass eine Erklärung davon hier weggelassen wird. In Fig. 4 ist eine Speichereinheit 401 dargestellt, die die Funktionen der Befehlsspeichereinheit 107 und der Ergebnisspeichereinheit 108, die unter Bezugnahme auf Fig. 1 beschrieben wurden, zusammenfasst. Somit wird ein einfacherer Schaltungsaufbau ermöglicht. Die übrigen Funktionen und Schaltungskomponenten der Fig. 4 entsprechen jenen der in Fig. 1 gezeigten.

Fig. 5 zeigt schließlich Befehlssequenzen CMD1-CMD6, die bezüglich des von dem Takt-Controller 106 gelieferten Taktsi­ gnals 105 als ein Zeitverlauf dargestellt sind. Die beiden vertikalen Striche in der Fig. 5 veranschaulichen, wie ein Taktsignal erfindungsgemäß angehalten werden kann, um eine Synchronisation einzelner Befehlssequenzen bereitzustellen. Nach einem Anhalten des Taktes (in der Mitte der Fig. 5) werden die drei Testbenchelemente 102a, 102b und 102c syn­ chronisiert, wobei eine Synchronisation in vorteilhafter Weise unter den Taktelementen wie auch bezüglich des Taktsi­ gnals 105, das der zu verifizierenden Schaltungseinheit 101 bereitgestellt wird, erreicht wird.

Bezüglich der in Fig. 2 dargestellten herkömmlichen Schal­ tungsanordnung zur Simulation einer zu verifizierenden Schal­ tungseinheit wird auf die Beschreibungseinleitung verwiesen.

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.

Insbesondere könnten die Befehlsspeichereinheit und die Er­ gebnisspeichereinheit zu einer einzigen Speichereinheit zu­ sammengefaßt sein.

Bezugszeichenliste

In den Figuren bezeichnen gleiche Bezugszeichen gleiche oder funktionsgleiche Komponenten.

100

Testbench

101

Zu verifizierende Einheit

102

a, . . .

102

i,

102

n Testbenchelement (i = Laufindex)

103

Testbench-Controller

104

Steuerelement

105

Taktsignal

106

Takt-Controller

107

Befehlsspeichereinheit

108

Ergebnisspeichereinheit

109

Erste Busanschlusseinheit

110

Zweite Busanschlusseinheit
111a, . . .111i,. . .111n Steuerdatenstrom (i = Laufindex)

112

Serieller Testdatenstrom

113

Paralleler Testdatenstrom

114

Datenstrom

115

a,

115

b,

115

c Schnittstellendatenstrom

116

Recheneinrichtung

117

a,

117

b,

117

c Befehlsdatenstrom

118

a,

118

b,

118

c Ergebnisdatenstrom

301

Taktzyklen

302

Taktzyklenzähler

303

Rücksetzsignal

401

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

Claims (17)

1. Verfahren zum Simulieren einer zu verifizierenden Schal­ tungseinheit (101), wobei Schaltungskomponenten einer Testbench (100) zusammenwirken, mit den Schritten:

• a) Anschließen der zu verifizierenden Schaltungseinheit (101) an mindestens ein Testbenchelement (102a-102c) zum Durchlei­ ten von Schnittstellendatenströmen (115a, 115b, 115c);
• b) Beaufschlagen der Testbenchelemente (102a-102c) mit Be­ fehlsdatenströmen (117a-117c) aus einer von einem Testbench- Controller (103) gesteuerten Befehlsspeichereinheit (107);
• c) Takten der Testbenchelemente (102a-102c), der zu verifi­ zierenden Schaltungseinheit (101) und des Testbench- Controllers (103) mittels eines von einem steuerbaren Taktge­ nerator (106) bereitgestellten Taktsignals (105);
• d) Ausgeben mindestens eines Simulationsergebnisses durch Ergebnisdatenströme (118a-118c) aus den Testbenchelementen (102a-102c) nach einem Simulieren der zu verifizierenden Schaltungseinheit (101) zu einer Ergebnisspeichereinheit (108);
• e) Auswerten des Simulationsergebnisses in einer über den Testbench-Controller (103) angeschlossenen Recheneinrichtung (116);

wobei der steuerbare Taktgenerator (106) zum Anhalten und Wiederaufnehmen des Taktsignals (105) gesteuert wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass Speicherinhalte der Befehlsspeichereinheit (107) mittels des Testbench-Controllers (103) nachgeladen werden.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Nachladen der Speicherinhalte der Befehlsspei­ chereinheit (107) des Testbench-Controllers (103) durch An­ halten des Taktsignals (105) ermöglicht wird.

4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass Speicherinhalte aus der Ergebnisspeichereinheit (108) als Simulationsergebnisse mittels des Testbench-Controllers (103) entsprechend einem Nachladen der Befehlsspeichereinheit (107) ausgegeben werden.

5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Taktsignal (105) des Takt-Controllers (106) angehal­ ten wird, um zusätzliche Rechenzyklen der Recheneinrichtung (116) zum Durchführen von Rechenoperationen zu erhalten.

6. Verfahren nach den Ansprüchen 1, dadurch gekennzeichnet, dass das Taktsignal (105) des Takt-Controllers (106) angehal­ ten wird, um eine Synchronisation der Schaltungskomponenten der Testbench (100) bereitzustellen.

7. Verfahren nach den Ansprüchen 1, dadurch gekennzeichnet, dass eine Schaltungslogik in dem Takt-Controller (106) von den Testbenchelementen (102a-102c) ein Bestätigungssignal erhält und/oder ausgegebene Datenströme analysiert, um ein Anhalten und Wiederaufnehmen des Taktsignals (105) bereitzu­ stellen.

8. Verfahren nach den Ansprüchen 1, dadurch gekennzeichnet, dass Taktzyklen (301) des Taktsignals (105) mittels minde­ stens einem Taktzyklenzähler (302) gezählt werden, um der Testbench (100) referenzierbare Taktzeitpunkte bereitzustel­ len.

9. Verfahren nach einem oder mehreren der Ansprüche 1, dadurch gekennzeichnet, dass das Anhalten des Taktsignals (105) des Takt-Controllers (106) durch ein vorgebbares Ausblenden von Taktflanken be­ reitgestellt wird.

10. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass der mindestens eine Taktzyklenzähler (302) Taktzyklen (301) des Taktsignals (105) zählt, um eine Synchronisation auf unterschiedliche Zeitgebungen bereitzustellen.

11. Verfahren nach Anspruch 8, 9 oder 10, dadurch gekennzeichnet, dass der mindestens eine Taktzyklenzähler (302) für Simulati­ onstakte und Takte der Testbench (100) bereitgestellt wird.

12. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Nachladen von Speicherinhalten der Befehlsspei­ chereinheit (107) durch einen Adresszeiger, durch eine Be­ fehlssequenz oder durch einen externen Plattenspeicher ge­ steuert wird und/oder in einer kontinuierlichen Weise er­ folgt.

13. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Auslesen von Speicherinhalten der Ergebnisspei­ chereinheit (108) durch einen Adresszeiger, durch eine Be­ fehlssequenz oder durch einen externen Plattenspeicher ge­ steuert wird und/oder in einer kontinuierlichen Weise er­ folgt.

14. Verfahren nach einem der Ansprüche 8 bis 13, dadurch gekennzeichnet, dass mindestens ein Zählwert des Taktzyklenzählers (302) als ein virtuelles Zeitmaß bereitgestellt wird, um einen Simula­ tionsablauf derart zu protokollieren und/oder zu dokumentie­ ren, dass eine externe Überwachung und/oder Auswertung ermög­ licht werden.

15. Vorrichtung zur Simulation einer zu verifizierenden Schaltungseinheit (101) mit:

• a) mindestens einem Testbenchelement (102a-102c) zum An­ schluss der zu verifizierenden Schaltungseinheit (101) und zur Durchleitung von Schnittstellendatenströmen (115a, 115b, 115c)
• b) einer von einem Testbench-Controller (103) gesteuerten Befehlsspeichereinheit (107), die den Testbenchelementen (102a-102c) Befehlsdatenströme (117a-117c) zuführt;
• c) einem steuerbaren Takt-Controller (106), der ein Taktsi­ gnal (105) bereitstellt, um die Testbenchelemente (102a-­ 102c), die zu verifizierenden Schaltungseinheit (101) und den Testbench-Controller (103) zu takten;
• d) einer Ergebnisspeichereinheit (108) zur Ausgabe mindestens eines Simulationsergebnisses, das durch Ergebnisdatenströme (118a-118c) aus den Testbenchelementen (102a-102c) nach einer Simulation der zu verifizierenden Schaltungseinheit (101) erhältlich ist; und
• e) einer Recheneinrichtung (116), die über einen Testbench- Controller (103) an die Befehlsspeichereinheit (107) und an die Ergebnisspeichereinheit (108) angeschlossenen ist, zur Bereitstellung von Befehlen für die Befehlsspeichereinheit (107) und zur Auswertung der von der Ergebnisspeichereinheit (108) erhaltenen Simulationsergebnisse;

wobei der steuerbare Taktgenerator (106) zum Anhalten und Wiederaufnehmen des Taktsignals (105) steuerbar ist.

16. Vorrichtung nach Anspruch 15, dadurch gekennzeichnet, dass mindestens ein Taktzyklenzähler (302) bereitgestellt ist, der Taktzyklen des von dem Takt-Controller (106) gelie­ ferten Taktsignals (105) zählt.

17. Vorrichtung nach einem oder beiden der Ansprüche 15 oder 16, dadurch gekennzeichnet, dass der mindestens eine Taktzyklenzähler (302) als ein Bi­ när-Zähler, Gray-Code-Zähler, Aiken-Code-Zähler, Dezimal- Zähler oder LFSR ausgebildet ist.