-
Die
Erfindung betrifft ein System sowie ein Verfahren zur Darstellung
von Signalen einer Vorrichtung zur Hardware-Simulation sowie ein Fehlersuchwerkzeug.
-
Aus
US 5 768 567 ist ein Hardware-Software-Cosimulator
zur Simulation eines Hardware-Software-Systems bekannt, welcher
einen logischen Simulator, Busschnittstellenmodelle, Speichermodelle,
Befehlssatzsimulatoren und einen sogenannten Cosimulations-Optimierungs-Manager
aufweist. Die gleichzeitige Simulation von Hardware und Software
wird auch Cosimulation genannt. Dabei wird die Cosimulation mit
einem einzigen kohärenten
Blick auf den Speicher des Hardware-Software-Systems durchgeführt, welcher
durch den Cosimulations-Optimierungs-Manager sowohl für Hardware- als auch für Software-Simulationen
transparent aufrechterhalten wird.
-
Der
Erfindung liegt die Aufgabe zugrunde, die gemeinsame Darstellung
von Signalen einer Vorrichtung zur Hardware-Simulation und Elementen eines Listings
eines Programms zu ermöglichen.
-
Diese
Aufgabe wird durch ein System zur Verknüpfung und Darstellung von Signalen
einer Vorrichtung zur Hardware-Simulation
und Elementen eines Listings eines Programms gelöst,
- • wobei die
Vorrichtung zur Hardware-Simulation das Verhalten einer Schaltung
mit einem Prozessor, einem Programmspeicher, welcher den Programmcode
des Programms enthält,
und applikationsspezifischen Hardwarekomponenten simuliert und Signale
als Ergebnis der Simulation erzeugt,
- • wobei
die Elemente des Listings des Programms mit den bei der simulierten
Ausführung
des im Programmspeicher enthaltenen, mit diesen Elementen korrespondierenden
Programmcodes erzeugten Signalen verknüpft werden,
- • wobei
die Elemente des Listings des Programms in einem ersten Teilbereich
eines grafischen Anzeigemittels und die Signale in einem zweiten
Teilbereich des Anzeigemittels darstellbar sind.
-
Diese
Aufgabe wird durch ein Verfahren zur Verknüpfung und Darstellung von Signalen
einer Vorrichtung zur Hardware-Simulation
und Elementen eines Listings eines Programms gelöst,
- • wobei die
Vorrichtung zur Hardware-Simulation das Verhalten einer Schaltung
mit einem Prozessor, einem Programmspeicher, welcher den Programmcode
des Programms enthält,
und applikationsspezifischen Hardwarekomponenten simuliert und Signale
als Ergebnis der Simulation erzeugt,
- • wobei
die Elemente des Listings des Programms mit den bei der simulierten
Ausführung
des im Programmspeicher enthaltenen, mit diesen Elementen korrespondierenden
Programmcodes erzeugten Signalen verknüpft werden,
- • wobei
die Elemente des Listings des Programms in einem ersten Teilbereich
eines grafischen Anzeigemittels und die Signale in einem zweiten
Teilbereich des Anzeigemittels dargestellt werden.
-
Diese
Aufgabe wird durch ein Fehlersuchwerkzeug zur Verknüpfung und
Darstellung von Signalen einer Vorrichtung zur Hardware-Simulation
und Elementen eines Listings eines Programms gelöst,
- • wobei die
Vorrichtung zur Hardware-Simulation das Verhalten einer Schaltung
mit einem Prozessor, einem Programmspeicher, welcher den Programmcode
des Programms enthält,
und applikationsspezifischen Hardwarekomponenten simuliert und Signale
als Ergebnis der Simulation erzeugt,
- • wobei
das Fehlersuchwerkzeug Mittel zur Verknüpfung der Elemente des Listings
des Programms mit den bei der simulierten Ausführung des im Programmspeicher
enthaltenen, mit diesen Elementen korrespondierenden Programmcodes
erzeugten Signalen aufweist,
wobei die Elemente des Listings
des Programms in einem ersten Teilbereich eines grafischen Anzeigemittels und
die Signale in einem zweiten Teilbereich des Anzeigemittels darstellbar
sind.
-
Der
Erfindung liegt die Erkenntnis zugrunde, dass das Design von Hardware-Software-Systemen durch
eine verknüpfte
Darstellung der Signale eines Hardware-Simulators und der Elemente
des Listings eines Programms wesentlich vereinfacht wird. Das erfindungsgemäße System
und Verfahren ermöglicht
eine einfache und fehlersichere Verfolgung der Ausführung eines
Programms. Die Darstellung des Listings des Programms stellt einen
direkten Bezug zum eigentlichen Programm her, insbesondere können auch
aufgrund der Verwendung des Listfiles die im Original-Quelltext
eingefügten
Kommentare angezeigt werden. Zur Verknüpfung und Darstellung der Signale
der Vorrichtung zur Hardware-Simulation und der Elemente des Listings
des Programms ist das Vorliegen eines abstrahierten Software-Modells des Prozessors
nicht erforderlich. Es ist somit gewährleistet, dass tatsächlich der
in der Schaltung verwendete Prozessor simuliert wird. Somit werden durch
eine Beschreibung des Prozessors mittels eines Modells verursachte
Fehler bei der Simulation ausgeschlossen. Die Visualisierung des
Programmablaufs erfolgt in ähnlicher
Form wie bei üblichen
Entwicklungswerkzeugen zum Debuggen von reiner Software. Die Einarbeitungszeit
für Anwender
des Systems bzw. des Verfahrens, welche Erfahrung bei der Entwicklung
von Software oder Firmware haben, ist daher relativ gering.
-
Gemäß einer
vorteilhaften Ausgestaltung der Erfindung ist eine Markierung eines
Elements des Listings des Programms im ersten Teilbereich des grafischen
Anzeigemittels und eine Markierung der mit diesem Element verknüpften Signale
im zweiten Teilbereich des Anzeigemittels vorgesehen. Die grafische
Darstellung orientiert sich somit an üblichen Software-Debug-Werkzeugen.
Der Programmverlauf kann durch eine Markierung eines Elements des
Listings des Programms verfolgt werden. Im zweiten Teilbereich des
Anzeigemittels bewegt sich eine Markierung synchronisiert zur Markierung
im ersten Teilbereich des Anzeigemittels, so dass auch Querbeziehungen
zur übrigen
Hardware erfasst werden können.
-
Vorteilhafterweise
ist ein dritter Teilbereich des grafischen Anzeigemittels zur Darstellung
mindestens eines Teils der Signale, insbesondere weiterer Werte,
vorgesehen. Weitere Werte können
beispielsweise Registerwerte sein.
-
Die
Verwendung üblicher
Vorrichtungen zur Hardware-Simulation wird erleichtert, wenn gemäß einer vorteilhaften
Ausgestaltung der Erfindung die Schaltung mit dem Prozessor, dem
Programmspeicher und den applikationsspezifischen Hardwarekomponenten
in einer Hardware-Beschreibungssprache beschrieben sind.
-
Das
System lässt
sich mit geringem Aufwand an verschiedene Prozessoren anpassen,
wenn gemäß einer
vorteilhaften Ausgestaltung der Erfindung Mittel zum Anpassen des
Systems an verschiedene Prozessortypen vorgesehen sind.
-
Nachfolgend
wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele
näher beschrieben
und erläutert.
-
Es
zeigen:
-
1 eine schematische Darstellung
eines Systems zur Verknüpfung
und Darstellung von Signalen einer Vorrichtung zur Hardware-Simulation
und Elementen eines Listings eines Programms,
-
2 einen Ausschnitt einer
Darstellung von Signalen einer Vorrichtung zur Hardware-Simulation
und
-
3 eine Darstellung von Signalen
einer Vorrichtung zur Hardware-Simulation und Elementen eines Listings
eines Programms.
-
1 zeigt ein System zur Verknüpfung und
Darstellung von Signalen 4, 5 einer Vorrichtung
zur Hardware-Simulation 1 und Elementen 15 eines
Listings 2 eines Programms 3 in schematischer
Darstellung. Die Vorrichtung zur Hardware-Simulation 1 simuliert
das Verhalten einer Schaltung 6 mit einem Prozessor 7,
einem Programmspeicher 8 und applikationsspezifischen Hardwarekomponenten 10.
Der Prozessor 7 kann z. B. ein Mikroprozessor oder Mikrocontroller
sein. Der Programmspeicher 8 enthält den Programmcode 9 des
Programms 3. Die Schaltung 6 wird mit Hilfe einer
Hardware-Beschreibungssprache, abgekürzt HDL (HDL = Hardware Description
Language), im Ausführungsbeispiel
mittels VHDL (VHDL = Very High Speed Integrated Circuit Hardware
Description Language) beschrieben. Mit dem Bezugszeichen 17 wird
der Quellcode in VHDL bezeichnet. Die Vorrichtung zur Hardware-Simulation 1 wird
entsprechend auch als HDL-Simulator bezeichnet. Ein Beispiel für einen
HDL-Simulator ist
das Produkt "ModelSim" der Firma Model
Technology, Portland, Oregon, USA. Die Schaltung 6 ist
z. B. ein sogenannter ASIC (ASIC = Application Specific Integrated
Circuit = Anwendungsspezifische integrierte Schaltung). Der HDL-Quellcode 17 wird
mit einem geeigneten Compiler in ein HDL-Simulator-Format 18 umgewandelt,
welches von der Vorrichtung zur Hardware-Simulation 1 verarbeitet
werden kann. Die Vorrichtung zur Hardware-Simulation 1 erzeugt
Signale 4, 5 als Ergebnis der Simulation. Das
Programm 3, bzw. der Programmcode 9 des Programms 3 wird
mittels eines Compilers in ein Datenfile 16 (üblicherweise
mit Daten in hexadezimaler Form) und ein Listing 2, auch
Listfile genannt, umgewandelt. Das Listing 2 enthält sowohl
die Programmbefehle als auch die zu gehörigen Kommentare. Das Listing 2 ist zeilenweise
aufgebaut, wobei jede Zeile jeweils einen Programmbefehl bzw. eine
Anweisung enthält,
gegebenenfalls mit dem zugehörigen
Kommentar. Eine Zeile, ein Programmbefehl, eine Anweisung bzw. ein
Kommentar sind Elemente 15 des Listings 2. Ein
Debugger 19 verknüpft
die Elemente 15 des Listings 2 des Programms 3 mit
den bei der simulierten Ausführung
des im Programmspeicher 8 enthaltenen, mit diesen Elementen 15 korrespondierenden
Programmcodes 9 erzeugten Signalen 4, 5.
Die Elemente 15 des Listings 2 des Programms 3 werden
in einem ersten Teilbereich 11 des grafischen Anzeigemittels 14 und
die Signale 4, 5 in einem zweiten Teilbereich 12 bzw.
in einem dritten Teilbereich 13 des Anzeigemittels 14 dargestellt.
-
2 zeigt einen Ausschnitt 30 einer
Darstellung von Signalen 4, 5 einer Vorrichtung
zur Hardware-Simulation 1. Die Signale 4, 5 werden
als sogenannte Waveforms 35, 36 und 37 dargestellt.
-
3 zeigt eine Darstellung 23 von
Signalen 4, 5 einer Vorrichtung zur Hardware-Simulation 1 und Elementen 15 eines
Listings 2 eines Programms 3. Die Elemente 15 des
Listings 2 werden in einem ersten Teilbereich 11,
die Signale 4, 5 in einem zweiten 12 bzw.
einem dritten 13 Teilbereich eines Anzeigemittels 14 dargestellt.
Die Elemente 15 können
mit einer Markierung 20, z. B. einer farblichen Kennzeichnung,
versehen werden. Die Signale 4 können mit einer Markierung 21,
z. B. einem Cursor, gekennzeichnet werden. Ein Anzeigemittel 14 kann
eine Bildschirmoberfläche
sein, die Teilbereiche 11 bis 13 können als
Anzeigefenster realisiert sein. Der Ablauf des Programms 3 im
Prozessor 7 (siehe 1)
wird mit Hilfe des grafischen Frontends, des Debuggers 19,
welcher auf die Signale 4, 5 der Vorrichtung zur
Hardware-Simulation 1 aufsetzt, visualisiert. Die Visualisierung
des Programmablaufes erfolgt durch Zugriff auf Signale des Prozessors 7,
deren Werte durch die Vorrichtung zur Hardware-Simulation 1 berechnet
wurden.
-
Gemäß dem Ausführungsbeispiel
ist der Debugger 19 in der Skriptsprache TCL/TK realisiert
(TCL/TK = Tool Command Language/Toolkit) und benutzt die TCL/TK-Schnittstelle
zu HDL-Objekten,
die ein HDL-Simulator zur Verfügung
stellt. Solche HDL-Objekte können
z. B. als Waveforms dargestellt werden. Um den Debugger 19 möglichst
flexibel zu gestalten, d. h. in diesem Zusammenhang, dass er relativ
einfach an verschiedene Prozessoren angepasst werden kann, wird
der Debugger 19 in zwei Abschnitte aufgeteilt. Ein erster
allgemeiner Teil stellt Prozeduren zur Visualisierung bereit. Ein
zweiter prozessorspezifischer Teil ist dem jeweiligen Prozessor
anpassbar und setzt sich z. B. aus folgenden Prozeduren zusammen:
- • Prozeduren
für Single-Step
rechts/links
- • Prozeduren
zum Bestimmen der Registerwerte
- • Prozeduren
für die
Kopplung von Signalen und Elementen des Listings
- • Prozeduren
zur Konfiguration
-
In
den Prozeduren für
Single-Step rechts/links (Bezugszeichen 22 in 3) wird der Cursor in einem Waveform-Fenster
auf den nächsten
gültigen
Befehl gesetzt. Für
das Beispiel eines KRISC8-Prozessors (KRISC8 = Kommunikations-RISC
8 Bit, Spezial-Core für
die Kommunikation in Feldbussystemen der Firma Siemens AG, München, Deutschland)
ist dies in 2 veranschaulicht.
-
Der
im Folgenden wiedergegebene Ausschnitt aus einem Listing zeigt eine
Prozedur für
Single-Step-Right.
-
-
-
-
Dabei
wird vereinfacht wie folgt vorgegangen (siehe 2):
- • Zum momentanen
Simulationszeitpunkt wird der Wert des Programmcounters 36 (pc,
Programmcounter = Programmzähler)
ermittelt. Der momentan ausgeführte
Befehl ist in 2 mit
dem Bezugszeichen 31 gekennzeichnet)
- • Der
Beginn des nächsten
Befehles wird gesucht. Der Cursor wird solange um Vielfache der
Taktperiode weitergeschoben, bis eine Änderung des Programmzählers auftritt.
- • Es
wird überprüft, ob der
nun erreichte Befehl ausgeführt
wird.
- • Handelt
es sich um einen Befehl, welcher nicht ausgeführt wird, so wird der übernächste Befehl
getestet (Wiederholung solange, bis ein ausgeführter Befehl erreicht ist oder
das Simulationsende erreicht ist). Im Beispielsfall gemäß 2 sind die nicht ausgeführten, d.
h. ungültigen
Befehle mit dem Bezugszeichen 32 gekennzeichnet.
- • Wird
der erreichte Befehl ausgeführt,
dann wird der Cursor im Waveform-Fenster (entspricht dem zweiten Teilbereich 12 des
Anzeigemittels 14 gemäß 3) zu diesem Zeitpunkt platziert.
Im Beispielsfall gemäß 2 ist der nächste ausgeführte, d.
h. gültige
Befehl mit dem Bezugszeichen 33 gekennzeichnet.
-
Die
Ermittlung des gültigen
Befehls erfolgt prozessorspezifisch. Es genügt bei modernen Prozessorarchitekturen üblicherweise
nicht, den Programcounter 36 zu verfolgen, sondern es sind
zusätzliche
Signale 4, 5 auszuwerten, die angeben, ob der
momentane Befehl gültig
ist (z. B. das der Waveform 34 zugrundeliegende Signal).
Wenn ein gültiger
Befehl ermittelt wurde, so erfolgt die Markierung 20 des
momentan ausgeführten Befehls
im angezeigten Listing im ersten Teilbereich 11 des Anzeigemittels 14 und
es werden die Registerwerte im dritten Teilbereich 13 des
Anzeigemittels 14 angezeigt (siehe folgenden Ausschnitt
eines Listings).
-
-
Um
den simulierten Ablauf eines Programms 3 auf einem Prozessor 7 zu
verfolgen, gab es bisher keine zufriedenstellenden Möglichkeiten.
Die manuelle Verfolgung des Programmablaufes anhand der von einem Simulator
ausgegebenen Waveform und einem Ausdruck eines Listfiles hat den
Nachteil, dass bei den üblicherweise
verwendeten Prozessoren (Pipelines, Caches, u. Ä.) eine Programmverfolgung
sehr aufwendig und fehlerträchtig
wird. Bei einer Verfolgung des Programmablaufes anhand eines Disassemblerausdruckes
muss ein Benutzer keine direkte Auswertung der Waveform vornehmen.
Es wird nur eine Liste der vom Prozessor bearbeiteten Befehle ausgegeben.
Somit fehlt aber der direkte Bezug zum eigentlichen Programm und
damit werden auch die im Quelltext eingefügten Kommentare nicht angezeigt.
Beim Verwenden eines Debuggers, der auf ein abstrahiertes C-Modell
aufsetzt, ergeben sich im Wesentlichen zwei Nachteile. Zum einen
benötigt man
ein C-Modell für
den eingesetzten Prozessor, welches normalerweise nicht vorliegt
und somit aufwendig erstellt werden muss. Zum anderen stellt das
C-Modell des Prozessors eine erneute Beschreibung des Prozessors
dar und es ist nicht ausgeschlossen, dass der tatsächliche
Prozessor ein vom C-Modell abweichendes Verhalten aufweist. Da bei
dem hier vorgeschlagenen Verfahren kein C-Modell für den Prozessor 7 benötigt wird,
ist zum einen gewährleistet,
dass der gleiche Prozessor 7 simuliert wird, der auch in
der Schaltung 6 implementiert ist. Zum anderen hält sich
der Aufwand zum Anpassen des Debuggers 19 an verschiedene
Prozessoren 7 bzw. Prozessortypen in Grenzen.
-
Zusammengefasst
betrifft die Erfindung somit ein System und ein Verfahren zur Verknüpfung und
Darstellung von Signalen 4, 5 einer Vorrichtung
zur Hardware-Simulation 1 und Elementen 15 eines
Listings 2 eines Programms 3 sowie ein Fehlersuchwerkzeug.
Um eine gemeinsame Darstellung der Signale der Vorrichtung zur Hardware-Simulation
und der Elemente des Listings des Programms zu ermöglichen,
wird vorgeschlagen, dass die Vorrichtung zur Hardware-Simulation 1 das
Verhalten einer Schaltung 6 mit einem Prozessor 7,
einem Programmspeicher 8, welcher den Programmcode 9 des
Programms 3 enthält,
und applikationsspezifischen Hardwarekomponenten 10 simuliert
und Signale 4, 5 als Ergebnis der Simulation erzeugt,
dass die Elemente 15 des Listings 2 des Programms 3 mit
den bei der simulierten Ausführung
des im Programmspeicher 8 enthaltenen, mit diesen Elementen 15 korrespondierenden
Programmcodes 9 erzeugten Signalen 4, 5 verknüpft werden
und dass die Elemente 15 des Listings 2 des Programms 3 in
einem ersten Teilbereich 11 eines grafischen Anzeigemittels 14 und
die Signale 4, 5 in einem zweiten Teilbereich 12 des
Anzeigemittels 14 darstellbar sind.
-
Im
Folgenden werden der technische Hintergrund der Erfindung und verwendete
Begriffe näher
erläutert.
-
Die
beschriebenen Schaltungen werden z. B. in sogenannten eingebetteten
Systemen (gebräuchlicher
ist der entsprechende englische Begriff "embedded systems") eingesetzt. Beispiele für Programmiersprachen
für den
Einsatz in eingebetteten Systemen sind C, Assembler, C++ und Java.
Diesen Sprachen gemeinsam ist der Einsatz eines Compilers, der eine
schrittweise Vorgehensweise bei der Codeentwicklung vorschreibt,
die sogenannten edit-compile-load-debug Zyklen. Debugger genannte
Fehlersuchwerkzeuge werden allgemein verwendet, um Fehler in der
Software-Programmierung aufzuspüren.
Da die meisten Software-Entwicklungssysteme hierfür eine integrierte
Entwicklungsumgebung zur Verfügung
stellen, können
Debugger relativ einfach den Programmcode verändern und mit Einzelschritten
oder gesetzten Kontrollpunkten auf ihrem Zielsystem überprüfen. Man
kann damit ein Programm kontrolliert ausführen, also das Programm Zeile
für Zeile
ausführen
und die Werte von Variablen abfragen und ändern. Software Debugger bieten
folgende Basisfunktionen an:
- • Einzelschritt-Ausführung von
Assembler- und Hochsprachencode
- • Setzen
von Haltepunkten (Breakpoints) an definierten Stellen in Hochsprache
oder Maschinencode, an denen das Programm vorübergehend angehalten wird
- • Anzeigen
von Variablenwerten, logischen Ausdrücken, Speicheradressen und
CPU-Registern
-
TCL
ist eine plattformübergreifende
Script-Programmiersprache. Durch die Kombination aus Textverarbeitungs-,
Dateibearbeitungs- und Systemsteuerungsfunktionen ist TCL für diesen
Zweck optimiert. EDA-Tools (EDA = Electronic Design Automation)
verwenden TCL häufig
zusammen mit dem Grafik-Toolkit TK, um eine flexible und plattformunabhängige grafische
Benutzeroberfläche
zu bieten. Hierzu gehört
beispielsweise ModelSim.
-
Im
Bereich der eingebetteten Systeme hat der parallele Entwurf von
Hardware und Software den klassischen, rein sequentiellen Entwurfsablauf
weitgehend abgelöst.
Eingebettete Systeme spielen eine dominierende Rolle in der Automatisierungstechnik.
Basis ihres Erfolgs ist die exponentiell steigende Komplexität integrierter
Schaltungen und die damit wachsenden Möglichkeiten für neue Systemfunktionen,
die zunehmend in Software realisiert werden. Die daraus resultierende
Systemkomplexität
verlangt bei gleichzeitig absinkenden Entwicklungszeiten eine drastische
Erhöhung
der Entwurfsproduktivität.
Diese Erhöhung
ist nur durch Entwurfsautomation und systematische Wiederverwendung
von Systemfunktionen erreichbar. Ein wesentlicher Schritt ist die
Integration von Hardware- und
Softwareentwurf, der Hardware/Software-Coentwurf.
-
Hardware-
und Softwareentwurf beginnen oft vor der Vollendung der Systemarchitektur
oder gar vor der endgültigen
Festlegung der Spezifikation. Systemarchitekten, Anwender und Kunden
oder Marketingexperten entwickeln gemeinsam Anforderungsdefinition
und Spezifikation. Der Systemarchitekt entwickelt daraus ein System
kooperierender Systemfunktionen als Grundlage eines anschließenden,
parallelen Entwurfs von Hardware und Software. An dieser Stelle
wird auch die Grobarchitektur der Zielhardware festgelegt. Der Hardware-/Software-Schnittstellenentwurf
erfordert eine Beteiligung von Hardware- und Softwareentwicklern. Die
Integration der Hardware und Softwarekomponenten und der Test des
integrierten Systems folgt als letzter Schritt. In allen Phasen
führen
Abweichungen von erwarteten Entwurfsergebnissen oder Änderungen
der Spezifikation zu einer Wiederholung von Entwurfsschritten. Ein
zentrales Problem im Entwurfsprozess ist die Überwachung und Integration
des parallelen Hardware- und Software-Entwurfs. Eine frühe Fehlererkennung
erfordert die Kontrolle von Konsistenz und Korrektheit, die um so
aufwendiger wird, je detaillierter der Entwurf ausgearbeitet ist.
-
Bei
der Hardware-Software Cosimulation wird die Ausführung der Software auf der
(Prozessor-)Hardware zusammen mit applikationsspezifischen Hardwarekomponenten
simuliert. Da eine Simulation mit hohem Detaillierungsgrad, wie
er im Hardwareentwurf üblich
ist, zu langsam für
eine praktisch nutzbare Softwaresimulation ist, werden üblicherweise
abstrakte Prozessormodelle benötigt.
Zu diesem Zweck werden die Prozessoren abstrakter ("auf einer höheren Abstraktionsebene") modelliert als
die anderen Hardwarekomponenten. Dabei wird das Zeitverhalten des
Prozessors nicht mehr taktgenau, d. h, für jeden Taktzyklus aufgeschlüsselt, dargestellt,
sondern nur noch die Programme mit ihren Ein- und Ausgaben. Das
Problem der Cosimulation liegt nun in der Kopplung der unterschiedlich
abstrakten Modelle, derart dass eine hinreichende Genauigkeit der
Simulation erreicht wird. Im ungünstigsten
Fall greifen Prozessor und andere Hardwarekomponenten auf den gleichen
Speicher zu. Eine genaue Modellierung erfordert in diesem Fall angepasste
Speicher- und Busmodelle und spezielle Simulationstechniken. Ein
Beispiel hierfür
bietet der Cosimulator Seamless CVS der Firma Mentor Graphics, Wilsonville,
Oregon, USA. Das Produkt Seamless CVS benutzt ein abstraktes Prozessormodell,
das die Befehlsausführung
nachbildet (ein sogenannter Instruction Set Simulator). Für den Speicher zugriff
werden Busmodelle verwendet, deren Abstraktion abhängig vom
gleichzeitigen Zugriff von Prozessor und Hardware ist. Speicher,
auf die lediglich der Prozessor zugreift, werden folglich abstrakter
modelliert als solche, in denen Konflikte auftreten können. Voraussetzung
ist also die Verfügbarkeit
einer Bibliothek von Modellen, die vom CAD-Anbieter oder dem Prozessorhersteller
bezogen wird.
-
Ein
abstrakterer Ansatz reduziert das Prozessormodell auf die reine
Programmausführung
auf dem PC oder der Workstation und modelliert lediglich das Interface
mit Zeitverhalten. Die Kopplung der Software-Ausführung zum
Hardwaremodell erfolgt dann über
ein simulatorspezifisches Kommunikationsprotokoll, das der Entwickler
in die Software einfügen
muss. Für
diese Modellierung sind nur Interface-Modelle erforderlich, was
die Bibliotheksproblematik wesentlich vereinfacht. Andererseits
wird das Zeitverhalten nur auf der Hardwareseite korrekt modelliert.
Beispiel für
einen solchen Cosimulator ist das Produkt Eagle der Firma Synopsys,
Mountain View, Kalifornien, USA.
