WO2005001720A1 - Verknüpfung und darstellung von signalen einer vorrichtung zur hardware-simulation und elementen eines listings eines programms - Google Patents

Verknüpfung und darstellung von signalen einer vorrichtung zur hardware-simulation und elementen eines listings eines programms Download PDF

Info

Publication number
WO2005001720A1
WO2005001720A1 PCT/EP2004/004991 EP2004004991W WO2005001720A1 WO 2005001720 A1 WO2005001720 A1 WO 2005001720A1 EP 2004004991 W EP2004004991 W EP 2004004991W WO 2005001720 A1 WO2005001720 A1 WO 2005001720A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
signals
elements
listing
display means
Prior art date
Application number
PCT/EP2004/004991
Other languages
English (en)
French (fr)
Inventor
Axel Andersch
Wolfgang MÄNDL
Wolfgang Sehr
Michael Klier
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to US10/562,303 priority Critical patent/US20060178863A1/en
Priority to EP04731897A priority patent/EP1639508A1/de
Publication of WO2005001720A1 publication Critical patent/WO2005001720A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking

Definitions

  • the invention relates to a system and a method for displaying signals of a device for hardware simulation and a troubleshooting tool.
  • a hardware software cosimulator for simulating a hardware software system which has a logical simulator, bus interface models, memory models, instruction set simulators and a so-called co-simulation optimization manager.
  • the simultaneous simulation of hardware and software is also called cosimulation.
  • the cosimulation is carried out with a single, coherent look at the memory of the hardware software system, which is maintained transparently by the cosimulation optimization manager for both hardware and software simulations.
  • the invention has for its object to enable the common representation of signals from a device for hardware simulation and elements of a program listing.
  • a system for linking and displaying signals from a device for hardware simulation and elements of a program listing wherein the device for hardware simulation is the behavior of a circuit with a processor, a program memory, which contains the program code of the program contains and simulates application-specific hardware components and generates signals as a result of the simulation, • the elements of the program listing are linked to the signals generated during the simulated execution of the program code contained in the program memory and corresponding to these elements, • the elements of the program listing in a first partial area of a graphic display means and the signals in a second Part of the display means can be displayed.
  • This object is achieved by a method for linking and displaying signals from a device for hardware simulation and elements of a program listing,
  • the device for hardware simulation simulates the behavior of a circuit with a processor, a program memory which contains the program code of the program, and application-specific hardware components and generates signals as a result of the simulation,
  • the device for hardware simulation simulates the behavior of a circuit with a processor, a program memory which contains the program code of the program, and application-specific hardware components and generates signals as a result of the simulation, •
  • the debugging tool has means for linking the elements of the listing of the program with the signals generated during the simulated execution of the program code contained in the program memory and corresponding with these elements, the elements of the listing of the program in a first partial area of a graphic display means and the signals can be represented in a second partial area of the display means.
  • the invention is based on the knowledge that the design of hardware software systems is considerably simplified by a linked representation of the signals of a hardware simulator and the elements of the listing of a program.
  • the system and method according to the invention enables simple and fail-safe tracking of the execution of a program.
  • the presentation of the program's listing provides a direct link to the actual program, in particular the comments inserted in the original source text can also be displayed due to the use of the list file.
  • An abstract software model of the processor is not required to link and display the signals of the hardware simulation device and the elements of the program listing. It is therefore guaranteed that the processor used in the circuit is actually simulated. Errors in the simulation caused by a description of the processor by means of a model are thus excluded.
  • the visualization of the program flow takes place in a form similar to that of conventional development tools for debugging pure software.
  • the training period for users of the system or the method, who have experience in the development of software or firmware, is therefore relatively short.
  • a marking of an element of the listing of the program in the first partial area of the graphic display means and Marking of the signals associated with this element is provided in the second section of the display means.
  • the graphic representation is thus based on conventional software debugging tools.
  • the program progress can be followed by marking an element of the program listing.
  • a marker moves synchronized to the mark in the first part of the display means, so that cross-relationships to the other hardware can also be detected.
  • a third sub-area of the graphic display means is advantageously provided for displaying at least a part of the signals, in particular further values.
  • Other values can be register values, for example.
  • the system can be adapted to different processors with little effort if, in accordance with an advantageous embodiment of the invention, means are provided for adapting the system to different processor types.
  • 1 shows a schematic representation of a system for linking and representing signals of a device for hardware simulation and elements of a program listing
  • 2 shows a section of a representation of signals from a device for hardware simulation
  • FIG. 3 shows a representation of signals from a device for hardware simulation and elements of a program listing.
  • the device for hardware simulation 1 simulates the behavior of a circuit 6 with a processor 7, a program memory 8 and application-specific hardware components 10.
  • the processor 7 can e.g. B. be a microprocessor or microcontroller.
  • the program memory 8 contains the program code 9 of the program 3.
  • the reference code 17 denotes the source code in VHDL.
  • the device for hardware simulation 1 is accordingly also referred to as an HDL simulator.
  • An example of an HDL simulator is the "ModelSim” product from Model Technology, Portland, Oregon, USA.
  • the HDL source code 17 is converted with a suitable compiler into an HDL simulator format 18, which can be processed by the hardware simulation device 1.
  • the device for hardware simulation 1 generates signals 4, 5 as a result of the simulation.
  • Program 3, or program code 9 of program 3 is converted by means of a compiler into a data file 16 (usually with data in hexadecimal form) and a listing 2, also called a list file.
  • Listing 2 contains both the program commands and the due comments.
  • Listing 2 is structured line by line, with each line containing a program command or instruction, possibly with the associated comment.
  • a line, a program command, an instruction or a comment are elements 15 of the listing 2.
  • a debugger 19 links the elements 15 of the listing 2 of the program 3 with the program codes which correspond to these elements 15 when the execution of the program contains 8 9 generated signals 4, 5.
  • the elements 15 of the listing 2 of the program 3 are shown in a first partial area 11 of the graphic display means 14 and the signals 4, 5 in a second partial area 12 or in a third partial area 13 of the display means 14.
  • the 2 shows a section 30 of a representation of signals 4, 5 of a device for hardware simulation 1.
  • the signals 4, 5 are represented as so-called waveforms 35, 36 and 37.
  • the 3 shows a representation 23 of signals 4, 5 of a device for hardware simulation 1 and elements 15 of a listing 2 of a program 3.
  • the elements 15 of the listing 2 are in a first partial area 11, the signals 4, 5 in a second 12 or a third 13 partial area of a display means 14.
  • the elements 15 can be marked 20, e.g. B. a color coding.
  • the signals 4 can be marked 21, e.g. B. a cursor.
  • a display means 14 can be a screen surface, the partial areas 11 to 13 can be realized as a display window.
  • the sequence of the program 3 in the processor 7 (see FIG. 1) is visualized with the help of the graphic front end, the debugger 19, which is based on the signals 4, 5 of the device for hardware simulation 1.
  • the program sequence is visualized by accessing signals of the processor 7, the values of which have been calculated by the hardware simulation device 1.
  • HDL objects can e.g. B. are represented as waveforms.
  • the debugger 19 is divided into two sections.
  • a first general part provides procedures for visualization.
  • a second processor-specific part is adaptable to the respective processor and is set, for. B. from the following procedures:
  • frame_toolbar. autostep_right configure -background gray -activebackground khaki2 .mainFrame.
  • label_message configure -bg DimGray -fg red -text "End of Simulation reached.” set minideb (auto_step_right) 0 .mainFrame. frame_toolbar. autostep right configure -background gray -activebackground khaki2 .mainFrame.
  • the command currently being executed is identified in FIG. 2 by the reference symbol 31)
  • the valid command is determined on a processor-specific basis. In modern processor architectures, it is usually not sufficient to track the program counter 36, but rather additional signals 4, 5 are to be evaluated which indicate whether the current command is valid (e.g. the signal on which the waveform 34 is based). If a valid command has been determined, the marking 20 of the command currently being executed takes place in the displayed listing in the first partial area 11 of the display means 14 and the register values are displayed in the third partial area 13 of the display means 14 (see the following section of a listing).
  • progadr_int [hex2int $ progadr] set progadr_int [expr $ minideb (address multiplier) * $ progadr_int] set progadr [int2hex $ progadr_int]
  • the invention thus relates to a system and a method for linking and displaying signals 4, 5 of a device for hardware simulation 1 and elements 15 of a listing 2 of a program 3, and a troubleshooting tool.
  • the device for hardware simulation 1 determine the behavior of a circuit 6 with a processor 7, a program memory 8, which contains the program code 9 of the program 3, and simulates application-specific hardware components 10 and generates signals 4, 5 as a result of the simulation that the elements 15 of the listing 2 of the program 3 with those contained in the program memory 8 in the simulated execution signals 4, 5 generated with these elements 15 corresponding program codes 9 are linked and that the elements 15 of the listing 2 of the program 3 can be represented in a first partial area 11 of a graphic display means 14 and the signals 4, 5 in a second partial area 12 of the display means 14 are.
  • the circuits described are e.g. B. in so-called embedded systems (more commonly the corresponding English term "embedded systems") is used.
  • Examples of programming languages for use in embedded systems are C, assembler, C ++ and Java. Common to these languages is the use of a compiler, which prescribes a step-by-step approach to code development, the so-called edit-compile-load-debug cycles.
  • Debugging tools called debuggers, are commonly used to track down software programming errors. Since most software development systems provide an integrated development environment for this, debuggers can change the program code relatively easily and check them on their target system with individual steps or set control points. You can use it to execute a program in a controlled manner, i.e.
  • TCL is a cross-platform script programming language.
  • the combination of word processing, file processing and system control functions optimizes TCL for this purpose.
  • EDL tools Electronic Design Automation
  • TCL uses TCL together with the graphic toolkit TK to offer a flexible and platform-independent graphical user interface. This includes, for example, ModelSim.
  • Hardware and software design often begin before the system architecture is completed or even before the specification is finally finalized.
  • System architects, users and customers or marketing experts jointly develop requirement definition and specification.
  • the system architect uses this to develop a system of cooperating system functions as the basis for a subsequent, parallel design of hardware and Software.
  • the rough architecture of the target hardware is also specified here.
  • the hardware / software interface design requires the involvement of hardware and software developers.
  • the integration of the hardware and software components and the test of the integrated system follows as the last step. In all phases, deviations from expected design results or changes in the specification lead to a repetition of design steps.
  • a central problem in the design process is the monitoring and integration of the parallel hardware and software design. Early detection of errors requires control of consistency and correctness, which becomes more complex the more detailed the design is worked out.
  • exact modeling requires adapted memory and Bus models and special simulation techniques, such as the Seamless CVS cosulator from Mentor Graphics, Wilsonville, 0-regon, USA, provide an example.
  • the Seamless CVS product uses an abstract processor model that simulates instruction execution (a so-called instruction set simulator).
  • instruction set simulator For the storage Access bus models are used, the / abstraction of which depends on the simultaneous access of processor and hardware. Memories that are only accessed by the processor are therefore modeled more abstractly than those in which conflicts can occur.
  • the prerequisite is the availability of a library of models, which is obtained from the CAD provider or the processor manufacturer.
  • a more abstract approach reduces the processor model to pure program execution on the PC or workstation and only models the interface with time behavior.
  • the software version is then linked to the hardware model using a simulator-specific communication protocol that the developer must insert into the software. Only interface models are required for this modeling, which considerably simplifies the library problem.
  • the time behavior is only correctly modeled on the hardware side.
  • An example of such a cosimulator is the product Eagle from Synopsys, Mountain View, California, USA.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft 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.

Description

Beschreibung
Verknüpfung und Darstellung von Signalen einer Vorrichtung zur Hardware-Simulation und Elementen eines Listings eines Programms
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 Co- simulations-Opti ierungs-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 Verhal- ten 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 Hard- ware-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 E- lemente 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 ge- wä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 Hardwarekompo- nenten in einer Hardware-Beschreibungssprache beschrieben sind.
Das System lässt sich mit geringem Aufwand an verschiedene Prozessoren anpassen, wenn gemäß einer vorteilhaften Ausges- taltung 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äu- tert.
Es zeigen:
FIG 1 eine schematische Darstellung eines Systems zur Verknüpfung und Darstellung von Signalen einer Vorrichtung zur Hardware-Simulation und Elementen eines Listings eines Programms, FIG 2 einen Ausschnitt einer Darstellung von Signalen einer Vorrichtung zur Hardware-Simulation und
FIG 3 eine Darstellung von Signalen einer Vorrichtung zur Hardware-Simulation und Elementen eines Listings eines Programms.
FIG 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 schemati- scher 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ührungsbei- spiel 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 Da- tenfile 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.
FIG 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 .
FIG 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 An- zeigemittels 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 FIG 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 Langu- age/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 FIG 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, Spezi- al-Core für die Kommunikation in Feldbussystemen der Firma Siemens AG, München, Deutschland) ist dies in FIG 2 veran- schaulicht.
Der im Folgenden wiedergegebene Ausschnitt aus einem Listing zeigt eine Prozedur für Single-Step-Right . # Prozedur für Single-Step-Right jf ACHTUNG: pc uss im Wave-Fenster selektiert sein (Das right-Kommando wirkt auf das
# selektierte Signal)!!!!! proc right_krisc8. Proc {} { global minideb global DEBUG set time_now [lindex [getactivecursortime] 0] set address [examine -time $time_now $minideb (TIME_UNIT) -hex $minideb (pc-path) ] set address_tmp [examine -time [expr $time_now + $minideb (C K_PERIOD) ] $minideb (TIME_UNIT) -hex $minideb (pc-path) ] set i 1 if {$DEBUG == "on"} {echo "anfang von right.Proc"} if {$address_tmp == "No_Data"} { .mainFrame.label_message configure -bg DimGray -fg red -text "End of Simulation reached." set minideb (auto_step_right) 0 .mainFrame. frame_toolbar . autostep_right configure -background grey -activebackground khaki2 .mainFrame. f ame_toolbar .label_info configure -text "" return } # Anfang vom naechsten Befehl suchen while {$address == $address_tmp} { if {$DEBUG == "on"} {echo "right.Proc: while-Schleife 1") inσr i set address_tmp [examine -time [expr $time_now + $i * $minideb(CLK_PERIOD) ] $minideb (TIME_UNIT) -hex $minideb (pc-path) ] } set time_now [expr $time_now + $i * $minideb(CLK_PERIOD) ] if ($DEBUG == "on") {echo "right . Proc: time_now —> $time_now"} set schleife 1 |f Suche den naechseten gueltigen Befehl while {$schleife == 1) { if {$DEBUG == "on") {echo "right.Proc: while-Schleife 2") il Ende des Befehls suchen set address [examine -time $time_now $minideb (TIME__UNIT) -hex $minideb (pc-path) ] set address_tmp [examine -time [expr $time_now + $minideb (CLK_PERIOD) ] $minideb (TIME_UNIT) -hex $minideb (pc-path) ] if {$address_tmp == "No Data"} { .mainFrame. label_message configure -bg DimGray -fg red -text "End of Simulation reached." set minideb (auto_step_right) 0 .mainFrame. frame_toolbar. autostep right configure -background grey -activebackground khaki2 .mainFrame. frame_toolbar.label_info configure -text "" return } set i 1 while {$address == $address_tmp} { if {$DEBUG == "on"} {echo "right.Proc: while-Schleife 3"} set address_tmp [examine -time [expr $time_now + $i * $minideb (C K_PERIOD) ] $mini- deb ( TIME_UNIT ) -hex $minideb (pc-path) ] } set time_now_tmp [expr $time_now + $i * $minideb (CLK_PERIOD) ] ff Befehl ist 16 Bit breit? set instruction [examine -time $time_now $minideb (TIME_UNIT) -hex $minideb (instruction) ] set digit [split $instruction ""] set kl "[lindex $digit 0] [lindex $digit 1]" if {$DEBUG == "on"} {echo "right.Proc: splitted instruction —> <$kl>"} if {$kl == "1E"} { ff Befehl ist 16 Bit breit, 1 Befehl weitergehen if {$DEBUG == "on"} {echo "right.Proc: 16 Bit Befehl"} set time_now $time_now_tmp } eise { set read_time [expr $time_now_tmp - 0.5 * $minideb(C K_PERIOD) ] if {$DEBUG == "on"} {echo "right . Proc: time_now —> $time_now; tirae_now__tmp —> $time_now_tmp; read_time —> $read_time"} if {$DEBUG == "on"} {echo "en_pipe —> [examine -time $read_time $minideb (TIME_UNIT) -bin $minideb ( en_pipe ) ] ; \ res_pipe —> [expr ! [examine -time $read_time $minideb (TIME_UNIT)
-bin $minideb(res_pipe) ] ] "} if {[examine -time $read_time $minideb (TIME_UNIT) -bin $minideb (en_pipe) ] && ! [examine -time $read_time $rainideb(TIME_UNIT) -bin $minideb(res_pipe) ] } { If naechsten gueltigen Befehl gefunden set schleife 0 } eise { if {$DEBUG == "on"} {echo "right.Proc: Der Befehl ist ungueltig!"} # Befehl wird nicht ausgefuehrt, da # - pipe enable nicht gesetzt ist ff - pipe reset gesetzt ist ff 1 Befehl weiter gehen set tιme_now $tιme_now_tmp } } } set address_mt [examine -time $tιme_now $mιnιdeb (TIME_UNIT) -hex $mιnιdeb (pc-path) ] if {[catch { .$mιnιdeb(wave_name) . tree right -value 'h$address_mt 1} result] '=0} { # Wenn PC nicht markiert ist, deaktiviere Auto-Step und zeige eine Fehlermeldung an set minideb (auto_step_πght) 0 .mainFrame. frame_toolba . autostep__nght configure -background grey -activebackground khakι2 -mainFrame. frame_toolbar. label_mfo configure -text "" notιce_show "$result \nPlease select pc in the wave-Wmdow1 "
} trace. Proc
Dabei wird vereinfacht wie folgt vorgegangen (siehe FIG 2) :
• Zum momentanen Si ulationsZeitpunkt wird der Wert des Pro- grammcounters 36 (pc, Program counter = Programmzähler) ermittelt. Der momentan ausgeführte Befehl ist in FIG 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äß FIG 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 Teilbe- reich 12 des Anzeigemittels 14 gemäß FIG 3) zu diesem Zeitpunkt platziert. Im Beispielsfall gemäß FIG 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 folgen- den Ausschnitt eines Listings) . proc trace.Proσ {} { global progadr_alt global minideb global DEBUG if {$minideb(configure_done) == 1} { if {$minideb(cursor_move_enable) == 1} { DisableCursorMove . Proc } ff Progra mzaehler auslesen set timenow [lindex [getactivecursortime] 0] ff aktuelle Programmadresse lesen if {$DEBUG == "on"} {echo "trace.Proc: timenow eingelesen"} set progadr [string tolower [examine -time $timenow $minideb(TIME_UNIT) -hex $minideb (pc- path) ] ] if {$DEBUG == "on"} {echo "trace.Proc: progadr gelesen <$progadr>"} # Programmadresse ist Undefiniert (Anfang von der Simulation) ? if {!{regexp { [0-9a-fA-F] +} $progadr] } { set progadr 0 } ff gelesenen Programmcounter mit 2 multiplizieren, um die Programmadresse zu erhalten (bei NIOS) # vorangestellte Nullen werden abgeschnitten ff da mit hex-Zahlen nicht gerechnet werden kann, wird auf eine Dezimalzahl umgerechnet, ff das Ergebnis mit 2 multipliziert (bei NIOS, 1 bei KRISC) und anschließend wieder in eine ff hex-Zahl konvertiert. set progadr_int [hex2int $progadr] set progadr_int [expr $minideb (adressmultiplikator ) *$progadr_int] set progadr [int2hex $progadr_int]
SearchCodeLine. Proc $progadr GetRegisterValues_$minideb(mode) .Proc set progradr_alt $progadr } eise { bell .mainFrame. label_message configure -bg DimGray -fg red -text "Before tracing you have to configu- re the program." } 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 ei- nem 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 di- rekte 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 Fehlersuch- werkzeug. Um eine gemeinsame Darstellung der Signale der Vorrichtung zur Hardware-Simulation und der Elemente des Lis- tings 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 E- lemente 15 des Listings 2 des Programms 3 mit den bei der si- mulierten 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 Sys- te en 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 o- der 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-, Datei- bearbeitungs- und Systemsteuerungsfunktionen ist TCL für die- sen 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 Mo- delSim.
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 Automatisierungs- technik. 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 Entwick- lungszeiten 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 o- der Marketingexperten entwickeln gemeinsam Anforderungsdefi- nition 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-Schnitt- stellenentwurf erfordert eine Beteiligung von Hardware- und Softwareentwicklern. Die Integration der Hardware und Soft- warekomponenten 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 Integ- ration 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 Cosi u- lator Seamless CVS der Firma Mentor Graphics, Wilsonville, 0- regon, 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 Kon- flikte 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.

Claims

Patentansprüche
1. 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),
• wobei 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 Hard- Warekomponenten (10) simuliert und Signale (4, 5) als Ergebnis der Simulation erzeugt,
• wobei 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) kor- respondierenden Programmcodes (9) erzeugten Signalen (4, 5) verknüpft werden,
• wobei 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 Teil- bereich (12) des Anzeigemittels (14) darstellbar sind.
2. System nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , dass eine Markierung (20) eines Elements (15) des Listings (2) des Programms (3) im ersten Teilbereich (11) des grafischen Anzeigemittels (14) und eine Markierung (21) der mit diesem Element (15) verknüpften Signale (4, 5) im zweiten Teilbereich (12) des Anzeigemittels (14) vorgesehen ist.
3. System nach Anspruch 1 oder 2, d a d u r c h g e k e n n z e i c h n e t , dass ein dritter Teilbereich (13) des grafischen Anzeigemittels (14) zur Darstellung mindestens eines Teils der Signale (4, 5) vorgesehen ist.
4. System nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass die Schaltung (6) mit dem Prozessor (7), dem Programmspeicher (8) und den applikationsspezifischen Hardwarekomponenten (9) in einer Hardware-Beschreibungssprache beschrieben sind.
5. System nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass Mittel zum Anpassen des Systems an verschiedene Prozessortypen vorgesehen sind.
6. 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), • wobei die Vorrichtung zur Hardware-Simulation (1) das Ver- halten 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, • wobei 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, • wobei 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) dargestellt werden.
7. Verfahren nach Anspruch 6, d a d u r c h g e k e n n z e i c h n e t , dass ein Element (15) des Listings (2) des Programms (3) im ersten Teilbereich (11) des grafischen Anzeigemittels (14) und die mit diesem Element (15) verknüpften Signale (4, 5) im zweiten Teilbereich (12) des Anzeigemittels (14) markiert werden.
8. Verfahren nach Anspruch 6 oder 7, d a d u r c h g e k e n n z e i c h n e t , dass in einem dritten Teilbereich (13) des grafischen Anzeigemittels (14) mindestens ein Teil der Signale (4, 5) darge- stellt wird.
9. Verfahren nach einem der Ansprüche 6 bis 8, d a d u r c h g e k e n n z e i c h n e t , dass die Schaltung (6) mit dem Prozessor (7), dem Programm- Speicher (8) und den applikationsspezi ischen Hardwarekomponenten (9) in einer Hardware-Beschreibungssprache beschrieben sind.
10. Verfahren nach einem der Ansprüche 6 bis 9, d a d u r c h g e k e n n z e i c h n e t , dass das Verfahren an verschiedene Prozessortypen anpassbar ist.
11. Fehlersuchwerkzeug zur Verknüpfung und Darstellung von Signalen (4, 5) einer Vorrichtung zur Hardware-Simulation (1) und Elementen (15) eines Listings (2) eines Programms (3) ,
• wobei 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,
• wobei das Fehlersuchwerkzeug Mittel zur Verknüpfung der E- lemente (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) aufweist, wobei 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.
PCT/EP2004/004991 2003-06-27 2004-05-10 Verknüpfung und darstellung von signalen einer vorrichtung zur hardware-simulation und elementen eines listings eines programms WO2005001720A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/562,303 US20060178863A1 (en) 2003-06-27 2004-05-10 Combining and representing signals of a hardware simulation device and elements of a program listing
EP04731897A EP1639508A1 (de) 2003-06-27 2004-05-10 Verknüpfung und darstellung von signalen einer vorrichtung zur hardware-simulation und elementen eines listings eines programms

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10329147A DE10329147A1 (de) 2003-06-27 2003-06-27 Verknüpfung und Darstellung von Signalen einer Vorrichtung zur Hardware-Simulation und Elementen eines Listings eines Programms
DE10329147.4 2003-06-27

Publications (1)

Publication Number Publication Date
WO2005001720A1 true WO2005001720A1 (de) 2005-01-06

Family

ID=33521136

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/004991 WO2005001720A1 (de) 2003-06-27 2004-05-10 Verknüpfung und darstellung von signalen einer vorrichtung zur hardware-simulation und elementen eines listings eines programms

Country Status (4)

Country Link
US (1) US20060178863A1 (de)
EP (1) EP1639508A1 (de)
DE (1) DE10329147A1 (de)
WO (1) WO2005001720A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007128753A1 (en) * 2006-05-03 2007-11-15 International Business Machines Corporation Method, system and program product supporting specification of signals for simulation result viewing

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8893065B2 (en) * 2012-07-11 2014-11-18 Mentor Graphics Corporation Biometric markers in a debugging environment
US20160070457A1 (en) * 2014-09-04 2016-03-10 Home Box Office, Inc. Platform-independent user interface system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001095161A2 (en) * 2000-06-02 2001-12-13 Virtio Corporation Method and system for virtual prototyping

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6760866B2 (en) * 1987-06-02 2004-07-06 Texas Instruments Incorporated Process of operating a processor with domains and clocks
US5544067A (en) * 1990-04-06 1996-08-06 Lsi Logic Corporation Method and system for creating, deriving and validating structural description of electronic system from higher level, behavior-oriented description, including interactive schematic design and simulation
TW421761B (en) * 1994-04-12 2001-02-11 Yokogawa Electric Corp Verification support system
US5768567A (en) * 1996-05-14 1998-06-16 Mentor Graphics Corporation Optimizing hardware and software co-simulator
US6182258B1 (en) * 1997-06-03 2001-01-30 Verisity Ltd. Method and apparatus for test generation during circuit design
US6298320B1 (en) * 1998-02-17 2001-10-02 Applied Microsystems Corporation System and method for testing an embedded microprocessor system containing physical and/or simulated hardware
US6272451B1 (en) * 1999-07-16 2001-08-07 Atmel Corporation Software tool to allow field programmable system level devices
US6230114B1 (en) * 1999-10-29 2001-05-08 Vast Systems Technology Corporation Hardware and software co-simulation including executing an analyzed user program
US7124376B2 (en) * 2000-05-02 2006-10-17 Palmchip Corporation Design tool for systems-on-a-chip
US7143021B1 (en) * 2000-10-03 2006-11-28 Cadence Design Systems, Inc. Systems and methods for efficiently simulating analog behavior of designs having hierarchical structure
US7031899B2 (en) * 2001-04-09 2006-04-18 Novas Software, Inc. System for characterizing simulated circuit logic and behavior
US20030004699A1 (en) * 2001-06-04 2003-01-02 Choi Charles Y. Method and apparatus for evaluating an integrated circuit model
US7080365B2 (en) * 2001-08-17 2006-07-18 Sun Microsystems, Inc. Method and apparatus for simulation system compiler
US6948155B2 (en) * 2002-11-22 2005-09-20 Texas Instruments Incorporated Little offset in multicycle event maintaining cycle accurate tracing of stop events
US7051299B2 (en) * 2003-07-31 2006-05-23 International Business Machines Corporation Method for generating reusable behavioral code

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001095161A2 (en) * 2000-06-02 2001-12-13 Virtio Corporation Method and system for virtual prototyping

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GUERRA L ET AL: "Cycle and phase accurate DSP modeling and integration for HW/SW co-verification", DESIGN AUTOMATION CONFERENCE, 1999. PROCEEDINGS. 36TH NEW ORLEANS, LA, USA 21-25 JUNE 1999, PISCATAWAY, NJ, USA,IEEE, US, 21 June 1999 (1999-06-21), pages 964 - 969, XP010344032, ISBN: 1-58113-092-9 *
LE MARREC P ET AL: "Hardware, software and mechanical cosimulation for automotive applications", RAPID SYSTEM PROTOTYPING, 1998. PROCEEDINGS. 1998 NINTH INTERNATIONAL WORKSHOP ON LEUVEN, BELGIUM 3-5 JUNE 1998, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 3 June 1998 (1998-06-03), pages 202 - 206, XP010283205, ISBN: 0-8186-8479-8 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007128753A1 (en) * 2006-05-03 2007-11-15 International Business Machines Corporation Method, system and program product supporting specification of signals for simulation result viewing

Also Published As

Publication number Publication date
DE10329147A1 (de) 2005-01-20
US20060178863A1 (en) 2006-08-10
EP1639508A1 (de) 2006-03-29

Similar Documents

Publication Publication Date Title
DE60115007T2 (de) Verbessertes programmierbares kernmodell mit integrierter graphischer fehlersuchfunktionalität
US9754059B2 (en) Graphical design verification environment generator
US5920490A (en) Integrated circuit test stimulus verification and vector extraction system
CN109032577B (zh) 一种数据仿真方法
US5752002A (en) Method and apparatus for performance optimization of integrated circuit designs
DE102006019292A1 (de) Modellieren programmierbarer Einrichtungen
DE10127170A1 (de) Fehlersuchverfahren und Fehlersuchvorrichtung
DE69816381T2 (de) Vorrichtung zur Unterstützung von Fehlersuche in symbolische Programme und entsprechender Kompiler.
US7409602B2 (en) Methodology for debugging RTL simulations of processor based system on chip
KR20080055913A (ko) 집적회로 디자인 시뮬레이션을 위한 어써션의 개발 방법 및시스템과 장치
Van Campenhout et al. Collection and analysis of microprocessor design errors
JP6763153B2 (ja) ハードウェア／ソフトウェア協調検証装置およびハードウェア／ソフトウェア協調検証方法
US7739655B1 (en) Version control in modeling environments
DE102013101300A1 (de) Wahlfreier Zugriff auf Signalwerte eines FPGA zur Laufzeit
DE10038499A1 (de) Verfahren und System für die verbesserte Entwicklungsprüfung mittels angepasster Ablaufverfolgung
CN1815480B (zh) 从波形图产生硬件设计语言触发的方法与系统
US5276854A (en) Method of multiple CPU logic simulation
Klein Miami: a hardware software co-simulation environment
EP1771799B1 (de) Verfahren zur bewertung der güte eines testprogramms
EP1639508A1 (de) Verknüpfung und darstellung von signalen einer vorrichtung zur hardware-simulation und elementen eines listings eines programms
Goli et al. Through the looking glass: Automated design understanding of SystemC-based VPs at the ESL
US8893065B2 (en) Biometric markers in a debugging environment
DE10041111A1 (de) Verfahren zum Überarbeiten eines in einer Programmiersprache verfaßten Computerprogramms
DE102008030163A1 (de) Verfahren zur Simulation von eingebetteten Systemen durch ein für Hardware- und Software-Komponenten integriertes Simulationsmodell
US20040260531A1 (en) Emulation system and method

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004731897

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2006178863

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10562303

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2004731897

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10562303

Country of ref document: US