JP5542643B2 - Simulation apparatus and simulation program - Google Patents

Description

  The present invention relates to a simulation apparatus and a simulation program for simulating a program executed by, for example, an embedded apparatus.

Means for providing a virtual environment for modeling the functions of the hardware of the embedded device with software and executing the target software 131 on it for the purpose of architecture design, operation verification, performance analysis, software development, etc. of the embedded device As a simulator. There are various types of simulators depending on the target range of simulation, the purpose, and the level of abstraction and accuracy when modeling hardware functions. As one form, the object code compiled and linked for the CPU used in the target embedded device is interpreted by a host computer that operates on a CPU different from the target, and changes in the contents of the memory and registers are interpreted. There is an instruction set simulator that reproduces the simulation. Since the instruction set simulator can execute the instruction sequence of the target CPU as it is, it does not participate in the configuration or processing contents of the target software 131. Therefore, even in the CPU idle process where there is no process to be executed and the CPU is in an empty state, the instruction sequence is interpreted and executed in the same manner as the actual CPU.
The CPU idle process is often realized by a simple loop process that repeatedly executes a jump instruction. On the other hand, in Patent Document 1, loop processing is detected from the history of executed instruction sequences, the contents of the memory and register after the loop is repeated a specified number of times, and the result is reflected, thereby reflecting the number of loops. Means for shortening instruction execution are disclosed.

JP-A-8-69392

  In an embedded device such as a controller that requires completion of input / output processing in real time, a real-time operating system (RTOS) is introduced, and processing is executed in units of tasks and interrupt handlers. The processing contents of normal tasks and interrupt handlers are designed with the worst case execution time so that the processing can be completed with certain real time constraints (deadline). Therefore, in the normal case, the margin is CPU idle processing, and an instruction sequence for consuming time is executed to wait for the next interrupt event.

Since the CPU idle process is a meaningless process executed in the idle time, even if the instruction sequence is faithfully simulated, a meaningful calculation result cannot be obtained. Even for this meaningless instruction execution, CPU resources of the host computer are allocated, and a certain processing time is required. Therefore, if the CPU resource is not used for the CPU idle process, the simulation time is shortened and the execution result can be obtained quickly.
As one means for that, Patent Document 1 discloses a method of skipping instructions related to a loop. Note that the CPU idle processing may be implemented as a processing that stops the CPU core, shifts to a low power consumption state, and waits in addition to the simple loop processing. In this case, the CPU instruction execution is stopped. Therefore, the method of shortening the loop described in Patent Document 1 cannot be used.

  Here, when attention is paid to the condition for releasing the CPU idle process, it is understood that an external event such as an interrupt needs to be given to the CPU. Therefore, in the present invention, when it is detected that the target software has shifted to the execution of the CPU idle process by the means for detecting that it is a part of the CPU idle process of the instruction currently being simulated, the next input / output Force the simulator's internal time until the event occurs. As a result, in the target software, the next interrupt occurs at the moment of entering the CPU idle process, the CPU idle process is canceled, and the interrupt handler and task process are executed. This aims at shortening the simulation time related to the CPU idle process.

The simulation apparatus of the present invention
In a simulation device that simulates target software,
An instruction set simulator for executing instructions of the software;
A simulation time management unit for advancing a simulation time different from the actual time due to the progress of real time, according to the execution of the instruction by the instruction set simulator unit;
An idle process determination unit for executing an idle determination process for determining whether the instruction being executed by the instruction set simulator unit is an idle process;
A time correction unit that advances the simulation time managed by the simulation time management unit until the end of the idle processing when the idle processing determination unit determines that the instruction being executed by the instruction set simulator unit is idle processing; It is provided with.

  According to the present invention, in a simulation apparatus that simulates target software, it is possible to provide a simulation apparatus that shortens the simulation time for CPU idle processing.

FIG. 3 is a block diagram of target system simulator 100 in the first embodiment. 3 is a flowchart of an instruction set simulator unit 110 in the first embodiment. 5 is a flowchart of an idle process determination unit 170 in the first embodiment. 5 is a flowchart of a time correction unit 180 in the first embodiment. The figure which connected FIG.2, FIG.3, FIG.4. 6 is a flowchart showing registration processing in the event management unit 150 by the I / O simulator unit 120 according to the first embodiment. FIG. 3 is a diagram illustrating an event queue included in the event management unit 150 according to the first embodiment. 6 is a flowchart showing an event processing operation by the event management unit 150 according to the first embodiment. FIG. 6 illustrates an event processing operation of the event management unit 150 in the first embodiment. FIG. 6 illustrates an event processing operation of the event management unit 150 in the first embodiment. FIG. 5 shows effects in the first embodiment. FIG. 10 is a block diagram of a target system simulator 100-2 in the second embodiment. 9 is a flowchart of real time adjustment unit 190 in the second embodiment. The external appearance of the computer which runs the target system simulator in Embodiment 3. FIG. FIG. 10 is a hardware configuration of a computer that executes a target system simulator according to Embodiment 3. FIG.

Embodiment 1 FIG.
FIG. 1 shows a configuration of a target system simulator 100 according to the first embodiment. The target system simulator 100 is a device that simulates a target embedded device with software. The target system simulator 100 includes an instruction set simulator unit 110 that simulates CPU instructions, an I / O simulator unit 120 (event simulator) that simulates interrupts and input / output of peripheral devices, a target memory 130, a target register 140, An event management unit 150, a simulation time management unit 160, an idle process determination unit 170, and a time correction unit 180 are provided.

  The target memory 130 reproduces and holds the target memory contents. The target register 140 reproduces and holds the target register contents. Target software 131 executed by the target system simulator 100 is loaded into the target memory 130.

  The instruction set simulator unit 110 takes out the instruction code of the target software 131 from the target memory 130, interprets it, and executes it. At that time, the operation result of the instruction is reflected on the target register 140, the target memory 130, and the I / O simulator unit 120.

  The I / O simulator unit 120 models the functions of peripheral devices other than the CPU with software. In addition to supplying data in response to an input / output request from the instruction set simulator unit 110, the I / O simulator unit 120 issues an interrupt request to the instruction set simulator unit 110 at a timing specified by the specification.

  The event management unit 150 manages the occurrence timing of the event by using the occurrence of the interrupt or the change in input / output as an event. The event management unit 150 grasps the event occurrence timing according to the simulation time managed by the simulation time management unit 160.

  The simulation time management unit 160 manages not the actual time required for the simulation execution but the time that is progressed and grasped in the simulation target system. For example, it is assumed that it takes 1 millisecond to execute 10,000 instructions on an actual embedded device, and 10 milliseconds to execute 10,000 instructions in the simulator. At this time, even if 10 milliseconds have elapsed in real time, the internal state of the target has progressed only for 1 millisecond, so the simulation time is 1 millisecond. The simulation time is obtained by notifying the simulation time management unit 160 of the number of machine cycles required to execute the instruction as a result of the instruction set simulator unit 110 executing the simulation, and the simulation time management unit 160 corresponds to the notified machine cycle. To proceed.

  The idle process determination unit 170 is a means for determining whether the target software 131 being executed has transitioned to the idle state. When the idle process determination unit 170 detects an idle state, the idle process determination unit 170 requests the time correction unit 180 to advance the simulation time.

  The time correction unit 180 inquires of the event management unit 150 about the time until the next event occurs, and issues a request to forcibly advance the time to the simulation time management unit 160 based on the result.

(Description of operation)
Next, the operation will be described.
FIG. 2 is a flowchart showing the processing contents added to the instruction set simulator unit 110.
FIG. 3 is a flowchart showing the processing contents of the idle processing determination unit 170.
FIG. 4 shows a flowchart of the time correction unit 180.
FIG. 5 shows the relationship between FIG. 2, FIG. 3, and FIG.

  The instruction set simulator unit 110 normally has five execution stages of CPU instruction fetch, decode, data fetch, instruction execution, and result storage as functional units, and executes simulation by rotating one loop per instruction while advancing the program counter. Will continue. The addition process shown in FIG. 2 is added after the result storage stage. In S100, the instruction set simulator unit 110 determines the type of instruction executed in the current execution loop. If a jump instruction has been executed, the idle process determination unit 170 is called in S101.

  As shown in FIG. 3, in S200, the idle process determination unit 170 determines whether the jump destination address of the executed jump instruction is within the address range where the CPU idle process instruction code of the target software 131 is located. Determine if. The CPU idle processing address can be obtained from the symbol information. If it is detected that the jump destination is the CPU idle process, the idle process determination unit 170 calls the time correction unit 180 in S201.

FIG. 4 is a flowchart showing the processing of the time correction unit 180.
The event queue and event occurrence time managed by the event management unit 150 will be described later with reference to FIGS.
In S500, the time correction unit 180 refers to the event queue managed by the event management unit 150 and acquires the next event occurrence time. Set to 0 if no event is registered. Next, in S501, the time correction unit 180 requests the simulation time management unit 160 to add the next event occurrence time acquired in S500 to the simulation time. As a result, an event always occurs in the next periodic process of the event management unit 150. As a result, if an interrupt occurs, the target software 131 immediately exits the CPU idle process and executes the interrupt handler process.

  FIG. 6 shows the timing of generating an event (event identifier) corresponding to the event (event identifier) in order for the I / O simulator unit 120 to realize an input / output event that occurs asynchronously with respect to CPU instruction execution such as an interrupt. 6 is a flowchart illustrating a process of registering in the event management unit 150 together with an occurrence time). This process is called by using an event identifier corresponding to an interrupt process or the like performed in the I / O simulator unit 120 and its occurrence time (additional event occurrence time) as parameters. Note that the event occurrence time (described in FIG. 5 to be described later) is based on the simulation time instead of the actual time, and specifies how much time has elapsed from the present time as a relative time.

  FIG. 7 is a diagram illustrating a structure of an event queue included in the event management unit 150. 6 is the I / O simulator unit 120. First, in S300, the I / O simulator unit 120 checks the event queue having the structure shown in FIG. 7 to check whether an event has already been registered. The event queue is a structure in which individual structure elements that manage events are connected by pointers. The event occurrence time stores the elapsed time from the previous structure element. The pointer of the last element is NULL. If no event is registered, the event queue itself becomes NULL. Accordingly, if the event queue is NULL, the I / O simulator unit 120 adds an event element to the queue in S308. Otherwise, the process proceeds to S301. In S301, an event identifier and an event occurrence time (queue event occurrence time) are acquired by referring to the head element of the event queue. In S302, the queue event occurrence time is compared with the value of the additional event occurrence time. If the queue event occurrence time is larger, the additional event occurrence time is subtracted from the queue event occurrence time, and the additional event element is inserted before the queue event element in S308. If the additional event occurrence time is greater, the queue event occurrence time is subtracted from the additional event occurrence time in S303, and the next element of the queue event is referred to in S304. Then, in S305, it is checked whether the event element is the terminal NULL, and if it is NULL, an additional event element is inserted immediately before (the end of the queue) in S308. If there is a next event element, the process returns to S302, and the same processing is repeated to sort the events in the order in which the events occur, and each event element is managed by the elapsed time from the previous event occurrence point. Become.

FIG. 8 is a flowchart showing a process in which the event management unit 150 is periodically called from the instruction set simulator unit 110 to check whether an event has occurred. The subject of the operation in FIG. 8 is the event management unit 150.
9 and 10 are diagrams for explaining FIG. 8 will be described with reference to FIGS.

In S400, the event management unit 150 checks the elements of the event queue of FIG. 7. If NULL, the current simulation time managed by the simulation time management unit 160 is referred to in S410, and the event processing time is set as the internal event processing time. After saving, the process is terminated.
If there is an event element, the process proceeds to S401. In the following description, the simulation time is used for explanation, but the unit of time is “second” for convenience of explanation.

In S401, referring to the current simulation time (20:19:23) managed by the simulation time management unit 160,
The event processing time (20:19:18) indicating the previous processing time stored in S410 is acquired, and the elapsed time (23-18 = 5 seconds) is calculated from the difference.
In S402, the head element of the event queue is referred to, and in S403, the elapsed time obtained in S401 is compared with the queue event occurrence time. As described above, since the event occurrence time is the elapsed time from the previous structural element (in other words, the previous event processing time (S410)), it is possible to compare the elapsed time with the event occurrence time.

(Elapsed time <event occurrence time)
As shown in FIG. 9, if the elapsed time (5 seconds) is smaller (for example, the event occurrence time is 8 seconds), the elapsed time (5 seconds) is subtracted from the queue event occurrence time (8 seconds) in S404 to obtain 3 seconds. And the event occurrence time of the acquired event queue is rewritten to the calculated difference (3 seconds). Then, it progresses to S410 and is updated to the present time (20:19:23) which acquired event processing time. That is, rewriting the occurrence time of the acquired event to be generated next time with a difference (3 seconds) means that the event occurrence time is from the updated current time (20:19:23).

(Elapsed time> event occurrence time)
FIG. 10 shows a case where the queue event occurrence time is smaller. As shown in FIG. 10, if the queue event occurrence time (3 seconds) is smaller or the same as the elapsed time (5 seconds), the event occurrence time has elapsed. Therefore, the event management unit 150 proceeds to the event notification process after S405.
In S405, the queue event occurrence time (3 seconds) is subtracted from the elapsed time (5 seconds). Then, as shown in FIG. 10, only the obtained difference (2 seconds) is subtracted from the next event occurrence time. This is because the event processing time is updated to the current time (20:19:23) acquired when the process proceeds to S410, and the next event (20:19:23) is used as a reference. This is for generating "T-2" seconds later).
In S406, the corresponding queue event element (the element that has reached the event occurrence time) is deleted from the connection structure of the event queue by operating the pointer,
In S407, the event identifier (an example of the execution request notification) of the corresponding queue event is transmitted to the I / O simulator unit 120 to notify that the specified event occurrence time has come. Corresponding to this processing, the I / O simulator unit 120 simulates an event corresponding to the event identifier, and if an interrupt request is generated as a result, an interrupt request is output to the instruction set simulator unit 110. become.
In S408, the event management unit 150 refers to the next element of the queue event,
If it is determined in S409 that there is no next event element (NO in S409), the process proceeds to S410 (a process for updating to the acquired current simulation time). If there is a next event element, the process returns to S403 and the same processing is repeated.

According to the first embodiment, the occurrence of an interrupt that triggers the exit from the CPU idle process is accelerated. For this reason, the simulation of the instruction sequence that should be executed as the CPU idle process is skipped, and as a result, the actual time required for the simulation is reduced. Further, since the CPU idle processing instruction sequence is not operated, the CPU operation itself is stopped by the CPU sleep command in order to reduce power consumption even if the CPU idle processing is realized by simple busy loop processing. Even if it is realized by processing, it is applicable.
FIG. 11A shows a case where the method of the target system simulator 100 is not applied (before implementation), and FIG. 11B shows a case where the method of the target system simulator 100 is applied (after implementation). As shown in FIG. 11, a handler is activated in response to a timer interrupt that occurs at an interval of 100 ms, a task process is performed from there, and then a processing model for transitioning to a CPU idle state. The simulation execution speed is 1/10 of the execution speed of the target embedded device, that is, the simulation time is 10 times longer. In the case of (a) in which the method of the first embodiment is not applied, the CPU idle process starts from the time point of 1700 ms in real time, and the CPU idle process is exited when an interrupt occurs at the time point of 2000 ms in real time. It is carried out. On the other hand, in the case of (b) to which the first embodiment is applied, the simulation time is forcibly advanced at the time of 1700 ms, which is supposed to enter the CPU idle process. Processing is executed. In this example, the actual simulation time required to execute this periodic process can be reduced by 300 ms.

Embodiment 2. FIG.
The second embodiment will be described with reference to FIGS.
FIG. 11 shows a functional configuration of the target system simulator 100-2 in the second embodiment. The difference from FIG. 1 is that FIG. 12 includes a real time adjustment unit 190. When the simulation time management unit 160 is called when advancing the simulation time, the real time adjustment unit 190 sets the simulation time to the real time when the simulation time is ahead of the real time. It has a function of releasing CPU resources of the host computer on which 100-2 is executed.

Next, the operation will be described.
FIG. 13 is a flowchart showing the processing contents of the real-time adjustment unit 190 added in the second embodiment.
First, in S600, "real time" that has elapsed since the start of simulation execution is calculated. The time information is obtained by referring to the timer of the host computer using the API of the OS running on the host computer. The actual time as a starting point is held as internal information at the start of simulation execution.
In step S601, the simulation time managed by the simulation time management unit 160 is compared with the actual time calculated in step S600. When a target embedded device having a low-speed CPU is simulated on a host computer having a high-speed CPU, the simulation execution speed may be faster than the execution speed of the actual target embedded device. Further, the simulation time may pass the real time by skipping the time corresponding to the CPU idle processing. In such a case, since the simulation time is larger than the real time, the processing after S602 is executed at that time.
In S602, the relative time difference is calculated by subtracting the actual time from the simulation time that is proceeding.
In step S <b> 603, the simulator process or thread is stopped by “the difference time” by the API of the OS of the host computer. Thereby, the use of the CPU resource of the host computer by the target system simulator 100-2 is abandoned. That is, when the simulation time matches the real time, execution of the simulator is resumed.

  According to the second embodiment, when simulating a low processing load state such as when the target embedded device is in a standby state, the simulation time is forcibly advanced in order to skip instruction execution of CPU idle processing. The CPU resources of the host computer are released only for the time that has advanced too much compared to the real time. For this reason, the processing load on the host computer at the time of simulation execution can be reduced, and more CPU resources can be allocated for execution of other applications (for example, editors). As a simulation method, there are a case where processing is performed while occupying the CPU resources of the host computer in order to obtain a result as soon as possible, and a case where the operation is to be confirmed at the same timing as the target embedded device. Is realized more efficiently with lower load.

Embodiment 3 FIG.
The third embodiment will be described with reference to FIGS. 14 and 15. In the third embodiment, the hardware configuration of the target system simulators 100 and 100-2, which are computers, will be described.
FIG. 14 is a diagram illustrating an example of the appearance of a target system simulator that is a computer.
FIG. 15 is a diagram illustrating an example of hardware resources of the target system simulator.

  In FIG. 14 showing the appearance, the target system simulator includes a system unit 830, a display device 813 having a CRT (Cathode / Ray / Tube) or LCD (liquid crystal) display screen, a keyboard 814 (Key / Board: K / B), Hardware resources such as a mouse 815 and a compact disk device 818 (CDD: Compact Disk Drive) are provided, and these are connected by cables and signal lines. The system unit 830 is connected to the network.

  In FIG. 15 showing hardware resources, the target system simulator includes a CPU 810 (Central Processing Unit) for executing a program. The CPU 810 is connected to a ROM (Read Only Memory) 811, a RAM (Random Access Memory) 812, a display device 813, a keyboard 814, a mouse 815, a communication board 816, a CDD 818, and a magnetic disk device 820 via a bus 825. Control hardware devices. Instead of the magnetic disk device 820, a storage device such as an optical disk device or a flash memory may be used.

  The RAM 812 is an example of a volatile memory. Storage media such as the ROM 811, the CDD 818, and the magnetic disk device 820 are examples of nonvolatile memories. These are examples of a “storage device” or a storage unit, a storage unit, and a buffer. The communication board 816, the keyboard 814, and the like are examples of an input unit and an input device. The communication board 816, the display device 813, and the like are examples of an output unit and an output device. The communication board 816 is connected to the network.

  The magnetic disk device 820 stores an operating system 821 (OS), a window system 822, a program group 823, and a file group 824. The programs in the program group 823 are executed by the CPU 810, the operating system 821, and the window system 822.

  The program group 823 stores programs that execute the functions described as “˜units” in the description of the above embodiments. The program is read and executed by the CPU 810.

  In the description of the above embodiment, the file group 824 includes “to determination result”, “to calculation result”, “to extraction result”, “to generation result”, and “to processing result”. The described information, data, signal values, variable values, parameters, and the like are stored as items of “˜file” and “˜database”. The “˜file” and “˜database” are stored in a recording medium such as a disk or a memory. Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 810 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. Used for CPU operations such as calculation, processing, output, printing, and display. Information, data, signal values, variable values, and parameters are temporarily stored in the main memory, cache memory, and buffer memory during the CPU operations of extraction, search, reference, comparison, operation, calculation, processing, output, printing, and display. Is remembered.

  In the description of the embodiment described above, the data and signal values are the memory of the RAM 812, the compact disk of the CDD 818, the magnetic disk of the magnetic disk device 820, other optical disks, mini disks, and DVDs (Digital Versatile Disk). Or the like. Data and signals are transmitted on-line via the bus 825, signal lines, cables, and other transmission media.

  In the above description of the embodiment, what has been described as “to part” may be “to means”, and “to step”, “to procedure”, and “to processing”. May be. That is, what has been described as “˜unit” may be implemented by software alone, a combination of software and hardware, or a combination of firmware. Firmware and software are stored as programs in a recording medium such as a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, and a DVD. The program is read by the CPU 810 and executed by the CPU 810. That is, the program causes the computer to function as the “˜unit” described above. Alternatively, the computer executes the procedure and method of “to part” described above.

  In the above embodiment, the target system simulator as a simulation apparatus has been described. However, it is obvious from the above description that the target system simulator can also be grasped as a simulation program.

In the above embodiment, a simulation apparatus having the following features has been described.
(1) The target system simulator 100 implements the hardware configuration of the target embedded device in software, and an instruction set for interpreting and executing the CPU instruction code of the target software 131 compiled and linked for the target embedded device The simulator unit 110 includes a combination of the simulator unit 110 and an I / O simulator unit 120 that virtually generates an interrupt or an input / output to / from the instruction set simulator unit 110 according to the hardware specifications of the target embedded device.
(2) The instruction set simulator unit 110 includes a target memory 130 and a target register 140 to be operated according to the CPU instruction code of the target software 131, and the target software 131 is loaded in the target memory 130.
(3) An event management unit 150 that centrally manages interrupts and inputs / outputs of the I / O simulator unit 120 as events, and a simulation time management unit 160 for grasping the occurrence timing of events are provided.
(4) An idle process determination unit 170 that determines whether the instruction code being executed by the instruction set simulator unit 110 is included in the CPU idle process, and a time correction unit that forcibly advances the simulation time when the CPU idle process is detected 180.
(5) The target simulator is executed as an application of the host computer.

In the above embodiment, a simulation apparatus having the following features has been described.
(1) When the instruction set simulator unit 110 executes a jump instruction, the idle process determination unit 170 is called.
(2) When the idle process determination unit 170 detects that the CPU instruction code of the target software 131 being executed by the instruction set simulator unit 110 is included in the CPU idle process, the time correction unit 180 registers it in the event management unit 150 The simulation time managed by the simulation time management unit 160 is forcibly advanced until the occurrence time of the event that occurs at the earliest timing.

In the above embodiment, a simulation apparatus having the following features has been described.
(1) A real-time adjustment unit 190 that controls the operation / stop state of the target system simulator 100 in order to match the simulation time with the real time is provided.

In the above embodiment, a simulation apparatus having the following features has been described.
When the simulation time is ahead of the real time, the execution of the target system simulator 100 is stopped by the difference time progressed by the real time adjustment unit 190, and the CPU resources of the host computer are released.

  100, 100-2 Target system simulator, 110 Instruction set simulator section, 120 I / O simulator section, 130 Target memory, 131 Target software, 140 Target register, 150 Event management section, 160 Simulation time management section, 170 Idle processing determination section , 180 hours correction unit, 190 hours adjustment unit.

Claims (5)

In a simulation device that simulates target software,
An instruction set simulator for executing instructions of the software;
A simulation time management unit for advancing a simulation time different from the actual time due to the progress of real time, according to the execution of the instruction by the instruction set simulator unit;
An idle process determination unit for executing an idle determination process for determining whether the instruction being executed by the instruction set simulator unit is an idle process;
A time correction unit that advances the simulation time managed by the simulation time management unit until the end of the idle processing when the idle processing determination unit determines that the instruction being executed by the instruction set simulator unit is idle processing; A simulation apparatus comprising: The simulation apparatus further includes:
Upon receiving an execution request notification for notifying the execution request for simulation of a predetermined event, the simulation of the event notified by the execution request notification is executed, and depending on the result of the simulation of the event, the instruction set simulator unit An event simulator that sends an interrupt request;
Managing at least one event to be simulated by the event simulator unit having an event occurrence time indicating an occurrence time based on the simulation time, and managing the simulation time managed by the simulation time management unit When it is determined that the event has reached the occurrence time by referring to, the event management unit that notifies the event simulator unit of the execution request notification related to the event that has reached the occurrence time,
The time correction unit is
When the idle process determination unit determines that the instruction being executed by the instruction set simulator unit is an idle process, the generation time of the event to be generated next among the events managed by the event management unit is referred to The simulation apparatus according to claim 1, wherein the simulation time managed by the simulation time management unit is advanced to the generation time of the event to be generated next. The instruction set simulator unit is
When the jump instruction is executed, the idle process determination unit is called,
The idle process determination unit
The simulation apparatus according to claim 1, wherein the idle determination process is executed when called by the instruction set simulator unit. The simulation apparatus further includes:
When the simulation time managed by the simulation time management unit is advanced from the actual time, the software instruction is executed by the instruction set simulator unit. The simulation apparatus according to claim 1, further comprising: a real-time adjustment unit that temporarily stops the simulation and adjusts the simulation time managed by the simulation time management unit to the actual time. . In a simulation program that simulates target software,
(1) processing for executing instructions of the software;
(2) a process of advancing a simulation time that is a time to be advanced in accordance with the execution of the instruction and is different from an actual time due to the progress of real time;
(3) a process of determining whether the instruction being executed is an idle process;
(4) When the instruction being executed is determined to be idle processing, processing to advance the simulation time until the end of the idle processing;
A simulation program for causing a computer to execute.

Images