JP5066013B2 - Simulation apparatus and program - Google Patents

Description

  The present invention relates to a simulation apparatus and a program that can detect a zero-definite infinite loop in a simulation apparatus that collaboratively verifies a hardware model and a software model, and that can advance the simulation when the infinite loop is detected.

  Development and verification of a system including a hardware model including a processor and a software model operating on the hardware model is performed using a simulation apparatus. As this simulation device, a hardware model in which a hardware model on a verification target system is described in a system level design language of C-based language and a software model that operates on a target processor are operated in parallel (cooperative operation) for verification. There was a simulation device (cooperative verification).

  In such a simulation apparatus, as a method of detecting the occurrence of an infinite loop of the software model, a method of detecting an oscillating loop circuit (for example, refer to Patent Document 1 below), a reference of values at the time of polling, and a simulation execution right A method of simulating a polling operation of a software model by combining the opening (for example, see Patent Document 2 below), a simulator for detecting a closed loop of a state transition and measuring a route coverage rate (for example, see Patent Document 3 below) .), A system monitoring device that determines unconditional branching and branch destination addresses and determines the occurrence of an infinite self-loop (for example, see Patent Document 4 below), and processing is executed within a predetermined period for each of a plurality of processings And one of the multiple processes is executed outside the predetermined time. Sometimes, a software model monitoring circuit (for example, see Patent Document 5 below) for detecting an abnormality of the software model, a method of detecting runaway detection by repeating the same address at a predetermined time interval and performing runaway detection (for example, (See Patent Document 6 below).

  In addition, when a process in a task falls into an infinite loop due to a logical abnormality or a hardware model abnormality, 1. Identify the task that is running, 2. detect the operation address of the determined task; 3. Determine that the detected address has only changed within the specified range (task is not moving); 4. An abnormal state is recognized by this determination. There is an abnormality detection method (see, for example, Patent Document 7 below) having a restart function for changing the operation address of the task to the head of the task when the abnormal state is recognized.

JP 2002-169852 A JP 2005-018623 A Japanese Patent Laid-Open No. 06-004616 JP 2000-250785 A JP 2000-010824 A JP-A-10-161908 JP 05-241872 A

However, the techniques described in the above patent documents have the following problems.
1. Consider a case where the software model is operated at high speed in an untimed manner to verify the cooperative operation. Here, the software model described below is, for example, a software model (untimed) described in a C-based language, and the hardware model is a C-based system level design language description model (timed). It is. In the following description, the software model and the hardware model are also referred to as software and hardware, respectively.

  In this case, although the state of the hardware model on the system changes as the processing time elapses on the system, the processing time becomes zero because the software model at the time of simulation is untimed, and an infinite loop may occur. The above untimed is a model having no processing delay time during simulation.

2. When operating a software model untimed and at high speed with a simulation device, the software model processing time during simulation is zero as described above, so even if the software model processing time is monitored, an infinite loop is detected. Can not do it.
3. Even during simulation of the hardware model, an infinite loop can occur due to a bug in the hardware model.

4). Even if a method of detecting that the same address is repeatedly executed at the same time interval a predetermined number of times (see, for example, Patent Document 6 above) is applied, an infinite loop is created because the processing time of the software model at the time of simulation is zero. It cannot be detected.
5. In the case of a large infinite loop including a plurality of tasks, even if a zero delay infinite loop is detected, the cause analysis of the infinite loop cannot be easily performed.
6). If the execution state such as a branch address is monitored for infinite loop detection, the simulation speed of a problem-free portion is reduced.
7). If the process of outputting the execution state to, for example, a file for infinite loop analysis is performed, the simulation speed is significantly reduced.

  The disclosed simulation apparatus and program solve the above-mentioned problems, and an infinite loop with zero processing delay time is included in the software model when collaborating with an untimed software model that does not have processing delay time and a hardware model. The purpose is to prevent the situation where the simulation does not proceed even if the occurrence of the error occurs and to continue the simulation.

  The disclosed simulation apparatus and program include a software model that operates on a target processor and a simulation apparatus that verifies the cooperative operation between the hardware model, a scheduler that performs execution scheduling of the hardware model, and a processing time of the software model A software model that monitors the simulation time at a preset timer interval based on the timer value calculated from the verification time in the verification platform, and has no processing delay time due to no change in the simulation time Monitoring means for detecting the infinite loop, and the scheduler is required to stop the execution of the software model when the monitoring means detects the infinite loop.

  According to the above configuration, the scheduler includes the simulation time monitoring device based on the timer that measures the CPU time on the verification platform. The scheduler that controls the execution of the simulation monitors the simulation time at a set timer interval. If the simulation time does not change from the previous value during this timer interval, the scheduler detects it as an infinite loop and stops the execution of the software model. Also, the target time can be advanced to the next time event of the timed model.

  According to the disclosed simulation apparatus and program, it is possible to detect an infinite loop of zero delay that occurs in an untimed simulation of a software model. Also, the execution of the software model having an infinite loop with zero delay is stopped, the next model can be executed, and the simulation can be executed.

  Exemplary embodiments of a simulation apparatus and a program according to the present invention will be described below in detail with reference to the accompanying drawings.

(Embodiment 1)
(Outline configuration of simulation device)
FIG. 1 is a diagram showing a configuration of a simulation apparatus according to the present invention. The simulation apparatus 1 according to the first embodiment includes a verification platform 10 and a scheduler 20 that is an application operating on the verification platform 10 and controls execution of the simulation.

  The simulation apparatus 1 verifies the cooperative operation between the software model SW, which is a model that operates on a target processor (not shown), and the hardware model HW. The software model SW is an untimed software component described in a C-based language such as SystemC. The hardware model HW describes a hardware model of a target system (not shown) in a system level design language (timed) such as SystemC.

  The scheduler 20 performs execution scheduling of the software model SW and the hardware model HW. Specifically, the evaluation timing of the software model SW and the hardware model HW is scheduled by event-driven (or also timing-driven).

  The scheduler 20 includes monitoring means 22 for monitoring the progress of the schedule. The monitoring unit 22 includes a timer 21 that measures the verification time (CPU time) 11 on the verification platform 10 and a target time monitoring unit 23. The timer 21 obtains a virtual software model processing time and is used as an infinite loop monitoring timer. The target time monitoring unit 23 monitors the target time (simulation time) t at a time interval set in advance based on the timer 21.

  When the target time (simulation time) t does not change from the previous value, the target time monitoring unit 23 detects that an infinite loop with zero delay has occurred. When the target time monitoring unit 23 detects an infinite loop with zero delay, the scheduler 20 advances the target time (simulation time) t to the next time event. The scheduler 20 includes log output control means, and can enable log output control when an infinite loop is detected. When log output is performed, the state trace information of the untimed model can be output during a timer interval set corresponding to the time required for log output.

  The event includes the meaning of notification processing such as notification of completion of predetermined processing in the software model or hardware model, for example. Furthermore, the time event includes, for example, the meaning of the time of the event from the software model to the software model, from the software model to the hardware model, from the hardware model to the hardware model, or from the hardware model to the software model. Furthermore, the event time queue includes, for example, the meaning of waiting for an event until a time event.

  The timer 21 counts up a counter that measures the verification time 11 at regular intervals, and outputs an interrupt request to the scheduler 20 when the counter value becomes equal to or greater than a reference value. It also has a function of resetting the verification time counter (to 0).

  The scheduler 20 is as follows. If an interrupt occurs during execution of the model (SW or HW), the model execution is suspended and the target time is advanced. 2. When the target time is advanced, the count value of the timer 21 is reset.

(Hardware configuration of simulation device)
Next, the hardware configuration of the simulation apparatus will be described. FIG. 2 is an explanatory diagram illustrating a hardware configuration of the simulation apparatus. The simulation apparatus 1 shown in FIG. 1 can be constituted by, for example, a personal computer (PC) and its peripheral devices.

  In FIG. 2, the simulation apparatus 1 includes a computer main body 210, an input device 220, and an output device 230, and is connected to a network 240 such as a LAN, WAN, or the Internet via a router or a modem (not shown). Is possible.

  The computer main body 210 has a CPU, a memory, and an interface. The CPU controls the entire simulation apparatus 1. The memory is composed of ROM, RAM, HD, optical disk 211, and flash memory. The memory is used as a work area for the CPU.

  Various programs are stored in the memory, and loaded according to instructions from the CPU. In the HD and the optical disk 211, reading / writing of data is controlled by a disk drive. The optical disk 211 and the flash memory are detachable from the computer main body 210. The interface controls input from the input device 220, output from the output device 230, and transmission / reception with respect to the network 240.

  The input device 220 includes a keyboard 221, a mouse 222, a scanner 223, and the like. The keyboard 221 includes keys for inputting characters, numbers, various instructions, and the like, and inputs data. Further, it may be a touch panel type. The mouse 222 performs cursor movement, range selection, window movement, size change, and the like. The scanner 223 optically reads an image. The read image is captured as image data and stored in a memory in the computer main body 210. Note that the scanner 223 may have an OCR function.

  Examples of the output device 230 include a display 231, a printer 232, and a speaker 233. The display 231 displays data such as a document, an image, and function information as well as a cursor, an icon, a tool box, and the like. The printer 232 prints image data and document data. The speaker 233 outputs sound such as sound effects and reading sounds.

FIG. 3 is a diagram illustrating state transition of each function of the scheduler.
1. Initialization When starting the simulation, the scheduler 20 shown in FIG. 1 initializes these models by executing the simulation process of the software model SW or the hardware model HW once by one (S1).

2. Evaluation A simulation process that is in an executable state at a certain verification time (simulation time) is placed in an execution queue. The scheduler 20 evaluates the simulation process in the execution queue at the simulation time in the state “evaluation” (S2). If an event occurs as a result of the evaluation, the scheduler 20 stores a simulation process to be executed in the execution queue or the time event queue depending on the event generation condition. In the case of an immediate event, the event is stored in the execution queue, and the scheduler 20 performs “evaluation” again on the updated execution queue.

  When the content of the execution queue becomes empty, the scheduler 20 shifts to the state “time progress” (S3). Further, the scheduler 20 is notified of the detection of an infinite loop with zero delay from the monitoring unit 22 and the log output control is not valid, or the log output control is valid and the log output is notified from the monitoring unit. Shift to time progress. If the log output control is valid even if the monitoring means 22 notifies the detection of the detection of an infinite loop with zero delay, the scheduler 20 validates the trace log output of each model and continues the simulation.

3. Time progress The scheduler 20 acquires the target time (simulation time) of the next event to be executed from the time event queue, and advances the target time (simulation time) to that time. After advancing the target time (simulation time), the scheduler shifts to the state “evaluation” (S4).

  FIG. 4 is a diagram illustrating a data management state during simulation execution. As shown in the figure, the time event queue 401 manages the time when the models (software model SW or hardware model HW) A to H to be executed next exist. Further, the execution queue 402 manages models (SW or HW) A to H executed at each time. The data structure shown in FIG. 4 is a general data structure of simulation including time.

(Simulation operation details)
FIG. 5 is a flowchart showing the contents of the simulation operation according to the first embodiment. The processing contents of the scheduler 20 and the timer 21 shown in FIG.

  The scheduler 20 first takes out models (A to H) that can be executed at the current target time from the execution queue 402. Further, the time event queue 401 confirms whether there is a model to be executed at the current target time with reference to the time event queue 401. One model to be extracted is taken out (step S501).

  Next, the scheduler 20 confirms whether there is an executable model (step S502). If there is an executable model (step S502: Yes), the process proceeds to step S503. If there is no executable model (step S502: No), the process proceeds to step S506.

  In step S503, the extracted executable model is executed. If an interrupt request is received from the timer 21 during model execution (step S504: Yes), model execution is temporarily stopped (step S505), and the process proceeds to step S506. If there is no interrupt request from the timer 21 during the model execution (step S504: No), the execution is continued until the execution becomes impossible. When the execution is completed, the process returns to the step S501.

  In step S <b> 506, when there is a next executable model in the time event queue 401, the target time is advanced to the time in the next time event queue 401. Thereafter, the counter of the timer 21 is reset (step S507), and the process returns to step S501.

  After resetting the count value of the counter (step S511), the timer 21 waits for a preset time interval (fixed time) t (step S512). Thereafter, the count value of the timer 21 at the verification time is counted up (step S513). Thereafter, if there is a counter reset request from the scheduler 20 (step S514: Yes), the process returns to step S511 to reset the count value. On the other hand, if there is no counter reset request from the scheduler 20 (step S514: No), it is determined whether the counter value exceeds the reference value (step S515). If it does not exceed the reference value (step S515: No), the process returns to step S512. If it exceeds the reference value (step S515: Yes), an interrupt request is issued to the scheduler 20 (step S516), and the process returns to step S511.

According to the above processing, the conventional problem can be solved as follows.
1. When Execution of Executable Model Taken Out in Step S503 is not Completed Even in this case, the counter of the timer 21 is not reset, so that the verification time counter can be counted up. When the counter reaches the reference value or more, the process of step S506 can be performed, and execution can be shifted to the next model.

2. Even if the simulation does not eliminate the model that can be executed at the current target time, even in this case, since the control does not move to step S506, the counter of the timer 21 is not reset. You can count up. When the counter reaches the reference value or more, the process of step S506 can be performed, and execution can be shifted to the next model. That is, the conventional infinite loop problem can be solved.

(Example of simulation execution in Embodiment 1)
Next, an execution example of the simulation of the first embodiment will be specifically described. FIG. 6 is a timing chart showing an execution example of a plurality of models in the first embodiment. Here, it is assumed that the models A and B are software models SW and the model C is a hardware model HW.

Description will be made in the order of the elapse of the target time t monitored by the target time monitoring unit 23.
t1: Since the simulation process of the model (C) is stored in the execution queue 402 at the target time (simulation time) t1, the scheduler 20 executes the simulation process of the model (C). That is, it shifts to evaluation.

  After execution of the simulation process of the model (C), since the execution queue 402 is empty, the scheduler 20 shifts to the state “time progress”, and at the next time event stored in the time event queue 401. The target time (simulation time) is advanced at a certain t2. At this time, the scheduler 20 clears (cancels) the verification time timer (infinite loop monitoring timer) 21.

  t2: Since the simulation process of the model (B) is stored in the execution queue 402 at the target time (simulation time) t2, the scheduler 20 executes the simulation process of the model (B). That is, it shifts to evaluation.

  After execution of the simulation process of the model (B), the execution queue 402 is empty, so the scheduler 20 shifts to time advance and at t3, which is the next time event stored in the time event queue 401. Advance the target time (simulation time). At this time, the scheduler 20 clears the timer 21 at the verification time.

  t3: Since the simulation process of the model (C) is stored in the execution queue 402 at the target time (simulation time) t3, the scheduler 20 executes the simulation process of the model (C). That is, it shifts to evaluation.

  After executing the simulation process of the model (C), since the execution queue 402 is empty, the scheduler 20 shifts to time advance and at t4 which is the next time event stored in the time event queue 401. Advance the target time (simulation time). At this time, the scheduler 20 clears the timer 21 at the verification time.

  t4: Since the simulation process of the model (A) is stored in the execution queue 402 at the target time (simulation time) t4, the scheduler 20 executes the simulation process of the model (A). That is, it shifts to evaluation.

  Here, as shown in the figure, when an immediate event for starting the model (B) occurs during the execution of the simulation process of the model (A), the model (B) is registered in the execution queue 402. After execution of the simulation process of model (A), since there is model (B) in execution queue 402, scheduler 20 executes the simulation process of model (B). These models (A, B) are all untimed software models.

  Further, as shown in the figure, when an immediate event for starting the model (A) occurs during the execution of the simulation process of the model (B), the model (A) is registered in the execution queue 402. After execution of the simulation process of the model (B), the scheduler 20 executes the simulation process of the model (A) because the execution queue 402 has the model (A).

  Here, as shown in the figure, the model (A) and the model (B) are alternately executed, and the target time does not advance (infinite loop). The verification time is counted up by the timer 21, and the verification time is not reset. That is, the target time cannot be changed to the time of the next executable model in the time event queue 401, and the simulation does not proceed.

  At this time, the verification time timer (infinite loop monitoring timer) 21 counts up using the CPU time 11 of the computer device of the verification platform 10 and sets the time interval (in this example, the verification time of the verification time). When the timer 21 count value T = 15) is reached, an infinite loop is detected (step S601), and the scheduler 20 is notified of the detection of the infinite loop by an interrupt request.

  Upon receiving the interrupt request, the scheduler 20 stops the simulation process of the model (A or B) being executed (step S602). Further, the verification time timer (infinite loop monitoring timer) 21 is cleared (cancelled).

  Thereafter, in order to escape from the infinite loop, the scheduler 20 shifts to time advance and advances the target time (simulation time) to t5 which is the next time event stored in the time event queue 401.

  t5: Since the simulation process of the model (C) is stored in the execution queue 402 at the target time (simulation time) t5, the scheduler 20 executes the simulation process of the model (C). That is, it shifts to evaluation.

  As shown in the figure, when an immediate event for starting the model (B) occurs during the execution of the simulation process of the model (C), the model (B) is registered in the execution queue 402. After execution of the simulation process of the model (B), the execution queue 402 is empty. Therefore, the scheduler 20 shifts to time advance, and the next time event stored in the time event queue 401 is t6. Advance the target time (simulation time). At this time, the scheduler 20 clears (cancels) the verification time timer (infinite loop monitoring timer) 21.

  According to the first embodiment, it is possible to detect an infinite loop with zero delay that occurs in an untimed simulation of a software model. In addition, since the execution of the software model having an infinite loop with zero delay is stopped and the target time is advanced to the time of the next time event queue, the next model can be executed and the simulation can be performed. This simulation is not limited to the infinite loop of the software model, and can proceed even if it is caused by a bug in the hardware model. Furthermore, since the timer is updated and monitored only at the time interval set in the timer, a decrease in simulation speed for detecting an infinite loop with zero delay can be suppressed to a very small level.

(Embodiment 2)
Next, a simulation apparatus according to Embodiment 2 will be described. The scheduler 20 of the second embodiment has a function for outputting a log when an infinite loop is detected.

(Simulation operation details)
FIG. 7 is a flowchart showing the contents of the simulation operation according to the second embodiment. The processing contents of the scheduler 20 and the timer 21 shown in FIG. The timer 21 includes an execution monitoring timer 21a and a log output monitoring timer 21b for monitoring log output in accordance with the addition of the log output function. Among them, the execution monitoring timer 21a functions as an infinite loop monitoring timer, like the timer 21 shown in FIG. Both the execution monitoring timer 21a and the log output monitoring timer 21b perform a counting operation using the verification time (CPU time) 11 of the verification platform 10.

  The monitoring contents of the infinite loop performed by the execution monitoring timer 21a are the same as those in the first embodiment (FIG. 5), and are assigned the same step numbers. The log output monitoring timer 21b operates in response to a timer start instruction from the scheduler 20.

  First, it waits for a preset time interval (fixed time) (step S521). Thereafter, the count value of the execution monitoring timer 21a is counted up (step S522). Thereafter, if the count-up stop request is received from the scheduler 20 (step S523: Yes), the process is terminated. On the other hand, if the stop request is not received (step S523: No), the process proceeds to step S524.

  In step S524, it is determined whether the count value of the execution monitoring timer 21a exceeds a counter reference value corresponding to the time required for log output. If the count value does not exceed the counter reference value (step S524: No), step S521 is performed. Return to. On the other hand, when the count value exceeds the counter reference value (step S524: Yes), an interrupt request is issued to the scheduler 20 (step S525).

  The processing contents of the scheduler 20 are basically the same as those in the first embodiment (FIG. 5) with the same step numbers. Up to step S504, processing similar to that in the first embodiment (FIG. 5) is executed.

  If there is an interrupt request in step S504 (step S504: Yes), then the interrupt type is determined (step S508). When the interrupt type is one issued from the log output monitoring timer 21b (step S508: a), the process proceeds to step S506, and the target time is set to the time event queue 401 at a time when there is a next executable model. Transition. Thereafter, the counter of the execution monitoring timer 21a is reset, the log output monitoring timer 21b is stopped (step S510), and the process returns to step S501.

  If the interrupt type is issued from the execution monitoring timer 21a (step S508: b), the execution of the model is temporarily stopped (step S505), the log output monitoring timer 21b is started (step S509), and step Return to S501.

(Example of simulation execution in Embodiment 2)
Next, an execution example of the simulation of the second embodiment will be specifically described. FIG. 8 is a timing chart showing an execution example of a plurality of models in the second embodiment. The processing similar to that of the first embodiment (FIG. 6) is performed until the processing of stopping the simulation process of the model (A or B) being executed by the scheduler 20 (step S602) by detecting the infinite loop (step S601). Do.

  Thereafter, the scheduler 20 enables the log output function of each model and clears (cancels) the execution monitoring timer (infinite loop monitoring timer) 21a. Then, the simulation process is executed again from the execution queue 402 at time t4.

  Since the simulation process of the model (A) is stored in the execution queue 402, the scheduler 20 first executes the simulation process of the model (A). That is, it shifts to evaluation. Thereafter, the infinite loop of the model (A, B) is continued to be executed again.

  The log output monitoring timer 21b counts up the counter using the CPU time (verification time) 11 of the computer device of the verification platform 10, and outputs the log of the model (A, B) (step S603). This log output is performed during a timer interval (in this example, the count value T = 4 of the log output monitoring timer 21b) set corresponding to the time required for log output. When the timer interval is reached, the log output monitoring timer is reached. 21b notifies the scheduler 20 of log output stop by an interrupt request (step S604).

  Thereafter, in order to escape from the infinite loop, the scheduler 20 shifts to time advance and advances the target time (simulation time) to t5 which is the next time event stored in the time event queue 401. Further, since the scheduler 20 is an interrupt request from the log output monitoring timer 21b, the scheduler 20 stops the log output monitoring timer 21b, updates the target time, and resets the execution monitoring timer 21a.

  t5: Since the simulation process of the model (C) is stored in the execution queue 402 at the target time (simulation time) t5, the scheduler 20 executes the simulation process of the model (C). That is, Evaluate. In the illustrated example, an immediate event for starting the model (B) occurs during execution of the simulation process of the model (C), and the model (B) is registered in the execution queue 402.

  After execution of the model (C) simulation process, the scheduler executes the model (B) simulation process because the execution queue 402 has the model (B). After execution of the simulation process of the model (B), the execution queue 402 becomes empty. Therefore, the scheduler 20 shifts to time advance, and the target time (simulation) is set to the next time event stored in the time event queue 401. Time). At this time, the scheduler 20 resets the execution monitoring timer (infinite loop monitoring timer) 21a.

  According to the second embodiment, in addition to the effects of the first embodiment, it is possible to obtain state trace information of an untimed software model necessary for loop analysis when an infinite loop occurs. As a result, the generated infinite loop can be easily analyzed.

  The simulation method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. This program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer. The program may be a transmission medium that can be distributed via a network such as the Internet.

  Regarding the above embodiment, the following additional notes are disclosed.

(Supplementary note 1) In a simulation apparatus for verifying cooperative operation between a software model operating on a target processor and a hardware model,
A scheduler for performing execution scheduling of the hardware model;
A timer for calculating the processing time of the software model from the verification time in the verification platform;
Monitoring means for monitoring the simulation time at a preset timer interval based on the value of the timer, and detecting an infinite loop of the software model having no processing delay time due to no change in the simulation time;
With
The scheduler stops the execution of the software model by detecting the infinite loop by the monitoring unit.

(Supplementary note 2) The scheduler advances the simulation time to the next time event of the hardware model having the processing delay time by detecting the infinite loop by the monitoring means, and executes the simulation of the hardware model. The simulation apparatus according to appendix 1, which is characterized.

(Supplementary Note 3) The scheduler includes log output control means,
The log output control means logs the state trace information of the software model that does not have the processing delay time during a preset verification time in the verification platform when the monitoring means detects the infinite loop. The simulation apparatus according to appendix 1 or 2, characterized by:

(Supplementary note 4) After the log output by the log output control means, the simulation time is advanced to the next time event of the hardware model having the processing delay time, and the simulation of the hardware model is executed. 3. The simulation apparatus according to 3.

(Additional remark 5) The said scheduler schedules the evaluation timing of the said hardware model by event driven, The simulation apparatus as described in any one of Additional remark 1-4 characterized by the above-mentioned.

(Supplementary note 6) The simulation apparatus according to any one of supplementary notes 1 to 5, wherein the software model is described in a C base language.

(Supplementary note 7) The simulation apparatus according to any one of supplementary notes 1 to 6, wherein the hardware model is described in a system level design language.

(Additional remark 8) In the program which makes a computer perform the process which verifies cooperation operation | movement with the software model and hardware model which operate | move on a target processor,
Computer
A scheduler for performing execution scheduling of the hardware model;
A timer for calculating the processing time of the software model from the verification time in the verification platform;
Based on the value of the timer, monitor the simulation time at a preset timer interval, and function as monitoring means for detecting an infinite loop of the software model that does not have a processing delay time due to no change in the simulation time,
The scheduler stops the execution of the software model when the monitoring unit detects the infinite loop.

It is a figure which shows the structure of the simulation apparatus of this invention. It is explanatory drawing which shows the hardware constitutions of a simulation apparatus. It is a figure which shows the state transition of each function of a scheduler. It is a figure which shows the data management state at the time of simulation execution. 3 is a flowchart showing the contents of a simulation operation according to the first embodiment. 3 is a timing chart illustrating an execution example of a plurality of models in the first embodiment. 10 is a flowchart showing the contents of a simulation operation according to the second embodiment. 10 is a timing chart illustrating an execution example of a plurality of models in the second embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Simulation apparatus 10 Verification platform 20 Scheduler 21 Timer 22 Monitoring means 23 Target time monitoring part 210 Computer main body 211 Optical disk 240 Network 401 Time event queue 402 Execution queue SW Software model HW Hardware model

Claims (6)

In the simulation device that verifies the cooperative operation between the software model that runs on the target processor and the hardware model,
A scheduler for performing execution scheduling of the hardware model;
A timer for calculating the processing time of the software model from the verification time in the verification platform;
Monitoring means for monitoring the simulation time at a preset timer interval based on the value of the timer, and detecting an infinite loop of the software model having no processing delay time due to no change in the simulation time;
With
The scheduler stops the execution of the software model by detecting the infinite loop by the monitoring unit.   The scheduler advances a simulation time to a next time event of a hardware model having a processing delay time by detecting the infinite loop by the monitoring unit, and executes the simulation of the hardware model. Item 2. The simulation device according to Item 1. The scheduler includes log output control means,
The log output control means logs the state trace information of the software model that does not have the processing delay time during a preset verification time in the verification platform when the monitoring means detects the infinite loop. The simulation apparatus according to claim 1, wherein:   4. The simulation of the hardware model is executed by advancing the simulation time to the next time event of the hardware model having the processing delay time after the log output by the log output control means. Simulation equipment.   The simulation apparatus according to claim 1, wherein the scheduler schedules the evaluation timing of the hardware model in an event-driven manner. In a program that causes a computer to execute a process of verifying cooperative operation between a software model that operates on a target processor and a hardware model,
Computer
A scheduler for performing execution scheduling of the hardware model;
A timer for calculating the processing time of the software model from the verification time in the verification platform;
Based on the value of the timer, monitor the simulation time at a preset timer interval, and function as monitoring means for detecting an infinite loop of the software model that does not have a processing delay time due to no change in the simulation time,
The scheduler stops the execution of the software model when the monitoring unit detects the infinite loop.

Images