DE102008030163A1 - Embedded system i.e. computer system, simulating method, involves simulating dynamic characteristics reacting with events by simulator core, and determining actually required execution times of program sequence on target system - Google Patents

Abstract

The method involves forming a simulation model (8), and simulating temporal and functional characteristics of processes. Characteristics and operations of an application program are realistically simulated on a special hardware by the model. Information about execution times of all partial operations of the special hardware and about the application program is provided to a hardware component (5). Dynamic characteristics reacting with events are simulated by a simulator core (10). Actually required execution times of a program sequence on a target system (1) are determined.

Description

Description of the initial situation

The ever-increasing complexity of embedded systems, as well as the increasing integration density of modern, integrated circuits (IC's), such as. System-on-Chip (SoC) solutions require new, improved methods of system analysis, especially with regard to on the predictability of the real-time behavior of these systems. Often it is about the fulfillment of specific requirements including the development of highly complex applications the specially tailored, customized IC's.

Desirable would be such a detailed functional and temporal preliminary analysis, that not only basic statements about the feasibility of a system, but also important ones Clues for choosing the best hardware and software design result. A proven method is the simulation of a Embedded Systems, in this context often as a target system or english target system, on a host computer.

State of the art

The easiest way to simulate an embedded system, is a software simulation where the source code is easy for translates the host processor and then runs on it becomes. In doing so environmental parameters may possibly be considered find by z. For example, the memory configuration or I / O is simulated by writing or reading on virtual ports.

Most of time But it is also necessary to include the hardware of the target system emulate the host computer. For this one uses today usually so-called Instruction Set Simulators (ISS), which real hardware, eg. B. Processors, controllers or other active processing units mimic the machine code on a host machine for which the corresponding hardware was created. Such simulators are often already today with so-called. Cross-development environments supplied, but then especially to the functionality and correctness of the programs developed.

better Simulation tools have properties a more detailed analysis of the timings enable.

• • die Verringerung der Übersetzungs- bzw. Umsetzungszeiten (TargetCode → HostCode)
• • die Erhöhung der Simulationsgeschwindigkeit (wünschenswert wäre eine Simulation in Echtzeit!)
• • die Möglichkeit einer genauen Ablaufverfolgung (Traceability, z. B. mit Protokollierung)
• • Übertragbarkeit des fertigen Simulationsprogramms auf andere Hostsysteme (z. B. mit höherer Leistungsfähigkeit)
• • Flexibilität der Simulation bzgl. dynamischer Vorgänge im Programmablauf (ermöglicht z. B. oft genauere Echtzeit-Abschätzungen)
• • Anpassbarkeit an die Hard- und Software-Gegebenheiten des Zielsystems (z. B. Verwendung anderer Zielprozessoren, anderer Bibliotheken etc.)

Important additional goals from the point of view of applicability; are

• • the reduction of the translation or conversion times (TargetCode → HostCode)
• • Increasing the simulation speed (a real-time simulation would be desirable!)
• • the possibility of accurate tracing (traceability, eg with logging)
• • Transferability of the finished simulation program to other host systems (eg with higher performance)
• • Flexibility of the simulation regarding dynamic processes in the program flow (eg often enables more accurate real-time estimations)
• • Adaptability to the hardware and software conditions of the target system (eg use of other target processors, other libraries, etc.)

These Goals are sometimes diametrically opposed, so again and again for improvements and new approaches to avoiding Disadvantages are sought.

So are still the most frequently interpretive working today ISSs used because they have the greatest flexibility and promise the best manageability, though static-compiled ISSs are indisputably superior in their simulation speed are. A middle ground is tried with different proposals for dynamic-compiled ISSs that have one on one side expect improved simulation speed on the other side but higher flexibility and thus promise a greater detail of the simulation.

[1] describes an approach that takes place through the use of ob ject instead Binary format as simulator input and the use of dynamic jump handlers a reduction in translation times while at the same time Improved flexibility. So can the dynamic Part of the code whose content is due to dynamic data only can be determined at run time, simulated much more accurately and estimated become.

[2] describes the simulation of an application program on a simulated Hardware system, with the application program instrumented first is broken down into program segments and tagged becomes. The following analysis of the target assembler code becomes a Table with description data for the individual program segments built up. The simulation on the host system calculates each time one is reached Tags from the information of the associated function data block the table and hardware parameters from a hardware configuration file Estimate the execution time for the corresponding segment and adds this to the total execution time for the application program.

[3] deals with new techniques to accelerate the simulation significantly. On the Ba In the case of a statically-translated instruction set architecture (ISA), instead of generating C code, a special low-level code generation interface is defined. For the virtual machine's intermediate code, a RISC structure is proposed which has a predefined, minimal instruction set but an unlimited number of virtual registers. Compared to dynamically compiled solutions, the use of intermediate code supports portability to other host systems, and unlike traditional approaches using statically-compiled ISA, direct manipulation of host machine resources is possible.

[4] examines strategies for estimating execution time at the level of a system design tool. Two methods to reduce costs and execution time estimates for an embedded system are introduced, partially improved and compared with each other. The first method is the source code an application program for a virtual instruction set. In the second case, using the Assembler option of the target system compiler An assembler listing of the application program created that is functional to "assemblerlevel" equivalent C for the host is implemented. In both variants, the code is containing information about the execution time and other time-relevant entries provided as an accurate and sufficiently fast simulation model used. These approaches are regarding accuracy and Simula tion speed in relation to conventional cycle-based processor models set.

• • Filtern von Information, die zwischen einer zyklusgenauen ISS und einem Hardware-Simulator ausgetauscht werden. D. h. die Zugriffszeiten, die der Hardware-Simulator zum Beschaffen von Befehlen und Daten benötigt, werden herausgerechnet. Diese Technik ist zwar sehr präzise, aber vergleichsweise langsam und erfordert ein detailliertes, fertiges Hard- und Softwaremodell. Nachträgliche Änderungen an der Systemarchitektur sind nur mit hohem Aufwand nachzuvollziehen.
• • Analyse des Codes von Basisblöcken des Programmablaufgraphen. Bei gleichzeitiger Verwendung eines zyklus-genauen Hardware-Modells können Pipelining und Cache-Benutzungsstrategien berücksichtigt werden, während durch die detaillierte Codeanalyse Compileroptimierungen, Registerbelegung, Befehlsauswahl, Scheduling u. ä. Eingang in die Abschätzung finden. Diese Technik ist zweifellos aufwendig, liefert aber sehr gute Ergebnisse. Die oben als zweites beschriebene Methode erlaubt bei entsprechend sorgfältiger Ausgestaltung diese Art von hochgenauer Abschätzung.
• • Abschätzung der Ausführungszeit auf der Basis von Hochsprachen-Anweisungen, die mit Zeitinformationen versehen sind, welche unter Berücksichtigung von Compileroptimierungen abgeschätzt wurden. Die Technik ist relativ einfach, hat aber den Vorteil, dass keine vollständige Design-Umgebung des gewählten Prozessors bzw. Systems verfügbar sein muss. Andererseits können keine compiler-spezifischen Eigenschaften oder komplexeren Systemarchitekturen beachtet werden, sodass die Abschätzung i. a. eher grob ausfallen wird. Der quellcode-basierte Ansatz der ersten oben beschriebenen Methode kann nur dadurch bessere Ergebnisse liefern, dass der vom Simulator verwendete C-Code von Hand geschrieben und optimiert wird und nicht durch automatische Generierung aus dem Assemblerlistung entsteht.
• • Verwendung von linearen Gleichungen zur impliziten Beschreibung der ausgeführten Programmpfade und deren Ausführungszeitabschätzungen. Diese Technik hat den Vorteil, dass gar kein Simulationsprogramm benötigt wird. Sie ist durchaus für Worst-Case-Abschätzungen bei einzelnen Programmen geeignet. Eine Abschätzung komplexerer Embedded Systeme ist aber kaum möglich, da die hohe Dynamik der Systeme nicht abgebildet werden kann und die Berechnung dann mit unkalkulierbaren Fehlern behaftet ist.

For the actual estimation of the execution time, four techniques are distinguished:

• • Filter information exchanged between a cycle-accurate ISS and a hardware simulator. Ie. The access times required by the hardware simulator to obtain commands and data are eliminated. Although very precise, this technique is relatively slow and requires a detailed, finished hardware and software model. Subsequent changes to the system architecture can only be reconstructed with great effort.
• • Analysis of the code of basic blocks of the program flow graph. Using a cycle-accurate hardware model, pipelining and cache usage strategies can be considered, while detailed code analysis includes compiler optimizations, register mapping, command selection, scheduling, and the like. Ä. Find entry in the estimate. This technique is undoubtedly expensive, but gives very good results. The method described above as second allows this type of highly accurate estimation, with due diligence.
• Estimation of the execution time on the basis of high-level language instructions, which are provided with time information, which was estimated under consideration of compiler optimizations. The technique is relatively simple, but has the advantage that no complete design environment of the selected processor or system needs to be available. On the other hand, no compiler-specific properties or more complex system architectures can be considered, so that the estimate will generally be rather crude. The source code-based approach of the first method described above can only provide better results by manually writing and optimizing the C code used by the simulator and not by automatically generating it from the assembler listing.
• • Using linear equations to implicitly describe the executed program paths and their execution time estimates. This technique has the advantage that no simulation program is needed at all. It is quite suitable for worst-case estimates in individual programs. An estimation of complex embedded systems is hardly possible, since the high dynamics of the systems can not be mapped and the calculation is then subject to incalculable errors.

These it is the target system to an embedded system, which may have several. even different processors and / or other hardware components for interactions with each other or with the outside world (eg with sensors or actuators), so are the overwhelmed by the approaches described above.

[5] proposes a co-simulation design system, wherein a host-based model-based processor simulator with a model-based hardware simulator that adds an extra imitates digital circuitry via an interface mechanism which controls communication between the two. During the simulative execution of the application program, this decomposes into linear blocks in a preliminary analysis and with time delay information is provided, the execution time can be very in this simulation arrangement be calculated exactly.

Bibliography

• [1] Moo-Kyong Chung, Chong-Min Kyung, "Improvement of Compiled Instruction Set Simulator by Increasing Flexibility and Reducing Compile Time", Proceedings of the 15th IEEE International Workshop on Rapid System Prototyping (RSP'04), 1074-6005 / 0 © 2004 IEEE
• [2] Patent WO 01/35223 A1 , "Method and System for Simulating Execution of a Target Program in a Simulated Target System "
• [3] Jianwen Zhu, Daniel D. Gajski, "An Ultra-Fast Instruction Set Simulator", IEEE Transactions on Very Large Scale Integration (VLSI) Systems, Vol. 3, June 2002, 1063-8210 / 02 © 2002 IEEE
• [4] Jwahar R. Bammi, Edwin Harcourt, Wido Kruijtzer, Luciano Lavagno, Mihai T. Lazarescu, Software Performance Estimation Strategies in a System-Level Design Tool, CODES 2000, San Diego, CA USA © ACM2000 1-58113-268-9 / 00/05
• [5] Patent US 6,230,114 B1 , "Hardware and Software Co-Simulation including executing an Analyzed User Program"

all Treated designs is common that they are very fast reach their limits when it comes to the simulated System is a more complex system that z. B. from several cooperating processors, as well as additional hardware components composed. So the simulation requires using ISSs or similar model-based Single simulators, not just the (quasi) parallel design several such simulators, but also a time-invariant replica the cooperation and communication mechanisms, as well as the synchronization the different time bases of the individual subsystems.

All in all must be found that conventional simulation methods despite all attempts to improve performance, especially for more complex systems, still considerable execution times on require the host computer while statements regarding the functionality and in particular the real-time behavior are often difficult to derive, because the temporal conditions in this type of simulation are not determined, but only estimated more or less roughly can be.

task

task the present invention is to simulate an embedded system so that an application program is functionally tested and based on its real-time capability analyzed and optimized. After another goal the application program should also run optimally as well the selection, configuration and possibly even the development customer-specific target hardware can be supported.

The Concept is intended from the ground up for the simulation of be designed more complex systems, d. H. also for inhomogeneous ones Multiprocessor systems with additional hardware components.

The In addition, the simulation method described should make it possible to with reasonable effort different variants of system architectures and to examine and compare configurations before the Hardware is physically available. Special Significance comes thereby over the accuracy of the statements the real-time behavior too.

Inventive solution the task

These The object is solved by the features of claim 1. Advantageous embodiments will be apparent from the dependent claims.

following is a preferred embodiment of the invention explained in more detail.

image 1 shows an overview of the architecture of these integrated simulation method.

A target system ( 1 ) can be used on a host system ( 2 ) are simulated by z. From assembler listing of the intended application ( 3 ), the parameter files of the participating PEs ( 4 ), the behavioral models of other HW components in the system ( 5 ), and a project file describing the target system ( 6 ) in a preliminary analysis ( 7 ) a simulation model ( 8th ), which is then calculated using a specifically configured simulator ( 9 ) is executed and analyzed.

One special procedure makes it possible during the Simulator run needed for each process Calculating times and then continuing To carry out analyzes of the timelines.

The simulation model ( 8th ) consists in turn of a set of information, description blocks and configuration data, which are advantageously built up in a preparation phase as lists or data structures of objects in the memory of the host system, and properties and capabilities of these objects can be mapped as attributes and methods of these objects. With corresponding losses on access but also a realization of the simulation model in the form of files, as database entries o. Ä. Conceivable.

terms in the sense of the simulation model Processing Element (PE) is a Generic term for active hardware / software components that manage and execute one or more processes. Examples are processors, possibly equipped with operating system, controller, "smaller" active HW components, such as UARTs, active interfaces, routers, bus switches u. ä.

A process in the sense of the simulation model can correspond to a task, a thread, an operating system process or an interrupt service routine (ISR), ie it simulates the execution a task, a thread, an operating system process or a. Interrupt service routine (ISR) on the corresponding processor of the real system.

One BasicBlock (BB) is part of the command sequence of a program, characterized in that it has a maximum sequence on each other following instructions. A sequence is defined as that the execution of the first instruction the (unconditional) Execution of all other instructions must follow.

One IPC object is a synchronization object, that of interprocess communication (English InterProcess Communication (IPC)) is used. Each IPC object manages a lot of processes that point to a state change just wait for this IPC object. Examples are semaphores, mutexes u. ä.

• • Die PE-Liste (12) enthält alle Processing Elemente des Zielsystems. Sie wird z. B. aus der Beschreibung des Target systems in einer Projektdatei bzw. den Parameterblöcken der PEs (4) und evtl. den Verhaltensmodellen aktiver HW-Komponenten (5) aufgebaut.
• • Für jede PE wird eine Prozessliste (13) aufgebaut, die alle auf dieser PE verwalteten Prozesse enthält. Weitere Prozesse können aus den Verhaltensmodellen von HW-Komponenten (5) abgeleitet oder zur Simulation externer Stimulatoren, die in der Projektdatei (6) beschrieben sind, ergänzt werden.
• • Für jeden Prozess einzeln oder für alle Prozesse einer PE gemeinsam wird ein gerichteter Graph, der sog. Basisblock(BB)-Graph (14) erstellt, der durch Analyse der Assemblercode-Abfolge so entsteht, dass die Basisblöcke als Knoten und die funktionalen Übergänge zwischen den Basisblöcken als Kanten dargestellt werden. Bedingte Anweisungen beispielsweise beenden zwar die Sequenz, die einen Basisblock definiert (s. o.), bestimmen aber über welche Kante der nächste auszuführende Block erreicht wird.

In detail, the simulation model contains the following elements (see Figure 1):

• • The PE list ( 12 ) contains all processing elements of the target system. It is z. From the description of the target system in a project file or the parameter blocks of the PEs ( 4 ) and possibly the behavioral models of active HW components ( 5 ) built up.
• • For each PE, a process list ( 13 ), which contains all the processes managed by this PE. Other processes can be derived from the behavioral models of HW components ( 5 ) or to simulate external stimulators contained in the project file ( 6 ) are supplemented.
• • For each process individually or for all processes of a PE together, a directed graph, the so-called basic block (BB) graph ( 14 ), which is created by analyzing the assembly code sequence so that the basic blocks are represented as nodes and the functional transitions between the basic blocks as edges. For example, conditional statements terminate the sequence that defines a basic block (see above), but determine which edge will be used to reach the next block to be executed.

• • Bei der Erstellung des BBGraphen wird daher gleichzeitig eine Liste mit den statischen Anteilen der Ausführungszeit eines Prozesses (15) angelegt.
• • Aus dem analysierten Target-Quell- oder -Assemblercode eines Prozesses wird gleichzeitig ein funktional identischer, aber in Basisblöcke unterteilter Host-Quellcode erstellt, der per Host-Compiler in Objectcode übersetzt den funktionalen Teil des Simulationsmodells stellt.
• • Schließlich werden noch Informationen benötigt, die den Simulator entsprechend dem Zielsystem konfigurieren (16). Dies bezieht sich auf die Art des Scheduling, z. B. Auswahl des Schedulingverfahrens, wie ”First Come, First Serve” ”Preemptive” oder ”Round Robin” u. ä. oder die Art der Speicherstrukturierung und -verwaltung, die aufgrund dieser Angaben im Speicher des Hostsystems nachgebildet und bei der folgenden Simulation verwendet wird.

The basic block graph thus breaks a process into sections, the basic blocks in the nodes whose time requirement is statically determinable, and sections, the edges, which allow the simulator to track the dynamic behavior of a process.

• • When creating the BBGraph, therefore, a list of the static portions of the execution time of a process ( 15 ).
• • From the analyzed target source or assembler code of a process, a functionally identical, but subdivided in basic blocks host source code is created, which is translated by the host compiler in object code is the functional part of the simulation model.
• • Finally, information is needed to configure the simulator according to the target system ( 16 ). This refers to the type of scheduling, eg. B. Selection of scheduling method such as "First Come, First Serve""Preemptive" or "Round Robin" u. or the type of memory structuring and management, which, based on this information, is reproduced in the memory of the host system and used in the following simulation.

Figure 2 shows the procedure of the simulator based on an execution cycle. The scheduler (1st stage) of the simulator selects from the list of PE ( 1 ) make an entry. A scheduler (2nd stage) of this PE chooses ( 2 ) the next process to be performed on this PE. The behavior of the scheduler or the scheduling method (cooperative, preemptive, etc.) of the PE is selectable by the user.

For execution, the selected process is taken from the set of ready-to-process and the processing of the next basic block ( 3 ) of the basic block graphs of this process takes place. After the processing of each block, it is checked whether a new scheduling process is necessary due to the changed system state of the simulated system ( 4 + 5 + 6 ). If this is the case, the process that has just been processed is returned to the set of active processes of the PE ( 7 ). Otherwise the next basic block will be processed.

One Scheduling process becomes necessary when according to the Scheduling procedure on one PE (like or another) another active process must be performed. Especially this is the case when the process just finished ends or is no longer ready to report due to a change of state.

Figure 3 shows the simulated process of interprocess communication via synchronization mechanisms. For example, a process may no longer be ready to compute if it corresponds to an operating system process of an RTOS on the simulated PE and that operating system contains a blocking wait. This can be done using semaphores and mutexes as well as communication queues. These elements are called IPC objects. Each IPC object manages a set of processes waiting for a state change of that IPC object. If the process currently being processed is blocking an IPC object, it is not included in the set of processes of the PE, but is inserted into the set of processes of the IPC object ( 12 ). Is replaced by a state change ( 14 ) of the IPC object a process in The number of processes of the IPC object is ready for calculation again, so it is removed from the set of the IPC object and reinserted into the set of active processes of a PE ( 15 ).

The simulated interaction between the software components and the Hardware components of the real system is done by simulated Accesses to the registers of the hardware component, as it is also in the real system takes place. These accesses change the internal one State of the hardware component and can also be the one Hardware component corresponding process in the set of active processes insert the assigned PE. The more functional and temporal behavior of the hardware component then becomes independent processed by the temporal and functional behavior of the software component.

The Interaction of the hardware components of the real system with each other takes place by the exchange of electrical signals on the terminals of the real components. In the simulator will increase the Simulation speed abstracted from the electrical levels and transmit complex data packets instead of individual levels. In the invention for this purpose data from the hardware components passed on to a link mechanism that attaches the data which in the real system associated with the issuing hardware components Forwarding hardware components. There is done according to the Behavior of the hardware component a change of the internal State of the hardware component. It can also be the hardware component corresponding process in the set of active processes to the hardware component be included in the PE.

The temporal behavior of the processes belonging to a PE depends on the local clock of the PE. For example, any crystal that generates the power stroke for a PE may be modeled as a local clock. Particularly advantageous here is the design of the watches according to the WO 02/21261 , For the scheduling operations of the 1st and the 2nd stage, the local times of the PE and the associated processes are converted into a common global time base.

The Stimulation of the simulated system takes place via activation of processes. For example, for ISR inputs the associated processes in the set of active processes registered a PE. Inputs of hardware components (UART inputs, levels of digital inputs, etc.) activated with the same procedure as in the communication between simulated hardware components.

QUOTES INCLUDE IN THE DESCRIPTION

This list The documents listed by the applicant have been automated generated and is solely for better information recorded by the reader. The list is not part of the German Patent or utility model application. The DPMA takes over no liability for any errors or omissions.

Cited patent literature

• WO 02/21261 [0039]

Claims (20)

Method for simulating an embedded system, ie a computer system that performs integrated functions in an overall environment within an overall system and is required for operation, control, regulation or the like of the overall system, characterized in that one integrated for hardware and software components Simulation model is formed, where - a set of processing elements (PE) is managed, - each PE manages a set of processes, - a scheduler (1st stage) from the set of processing elements selects the next to be simulated processing element, - next process simulated on this PE is selected by another scheduler (2nd stage), - the temporal and functional behavior of the selected process is simulated by the execution of a basic block graph, - each PE has at least one local clock, - the temporal Behavior of processes belonging to a PE from this lok This simulation model realistically simulates the properties and processes of the application program on the special hardware, as well as the properties and processes in the hardware itself, and information about the execution times of all sub-processes of the specific hardware and the application program on this hardware while the simulator core mimics the dynamic properties, responds to unpredictable events in the same way as the simulated target system determines the actual execution times of a program run on the target system. The method of claim 1, wherein in the simplest Version the target system of a similar processor type is like the host system used for simulation, so the simulation model is simple by translating the application program on the host computer arises. Method according to claims 1 and 2, wherein variations of the target system in the form of a list of environmental parameters into the simulation model. The method of claim 1 to 3, wherein the simulation model through a file with execution times for individual or all sub-processes of the special hardware and the application program on this hardware is added from the simulation the time behavior of the target system is reconstructed and calculated can. The method of claim 1, wherein in another Version the simulation model arises because the application program piloted as assembler code for the target system with a com Instruction Set Simulator (ISS) of the target system becomes. Method according to claims 1 and 5, wherein variations of the target system in the form of a list of environmental parameters into the simulation model. The method of claim 1 and the claims 5 and 6, where the simulation model by a file with execution times for individual or all partial processes of the special Hardware and the application program is supplemented on this hardware, from which the simulation reconstructs the time behavior of the target system and can be calculated. The method of claim 1 and the claims 5 to 7, where the ISS is replaced by a virtual ISS, the technical information from the datasheet of the target system, from its hardware specification or VHDL code or similar documentation was generated. The method of claim 1 and the claims 5 to 8, wherein for the simulation model the application program based on information from the datasheet of the target system its hardware specification or VHDL code or similar Documentation is programmed manually as host source code. The method of claim 1, wherein in another Version where the application program cooperates on several Target systems, the simulation model is created, that by means of a more complex preprocessing program the various Application program modules corresponding to the respective target system compiled ISSs are executed. Method according to claims 1 and 10, wherein variations the target systems and the communication systems connecting them in the form of a list of environmental parameters in the simulation model incorporated. The method of claim 1 and the claims 10 and 11, where the simulation model by a file with execution times for individual or all partial processes of the special Hardware and the application program is supplemented on this hardware, from the simulation of the time behavior of the target and communication systems can be reconstructed and calculated. The method of claim 1 and the claims 10 to 12, with the ISSs partially or all through virtual ISSs to be replaced, based on technical information from the data sheet the respective target systems, from their hardware specification or VHDL code or similar documents were generated. The method of claim 1 and the claims 10 to 13, wherein for the simulation model the application program based on information from the datasheet of some or all Target systems, from their hardware specification or VHDL code or similar Documentation is programmed manually as host source code. The method of claim 1, wherein the temporal and functional behavior of the selected process through simulates the execution of a compiled basic block graph becomes. Method according to claims 1 and 15, wherein variations of the target system in the form of a list of environmental parameters into the simulation model. The method of claim 1 and the claims 15 and 16, where the simulation model by a file with execution times for individual or all partial processes of the special Hardware and the application program is supplemented on this hardware, from which the simulation reconstructs the time behavior of the target system and can be calculated. The method of claim 1 and the claims 15 to 17, where the ISS is replaced by a virtual ISS, the technical information from the datasheet of the target system, from its hardware specification or VHDL code or similar Documentation was generated. The method of claim 1 and the claims 15 to 18, wherein for the simulation model the application program based on information from the datasheet of the target system its hardware specification or VHDL code or similar Documentation is manually programmed as host source code before the Target hardware including tools is available. The method of claim 1 to 4 or 1 and the claims 5 to 9 or 1 and claims 10 to 14 or claim 1 and claims 15 to 19, wherein the simulation core the information stored in the simulation model, such as environmental parameters and uses timestamp sequences to the application program on the host system to replicate optimally.