WO2015155839A1

WO2015155839A1 - Simulation system, simulation method and program

Info

Publication number: WO2015155839A1
Application number: PCT/JP2014/060214
Authority: WO
Inventors: 中田　啓明
Original assignee: 株式会社日立製作所
Priority date: 2014-04-08
Filing date: 2014-04-08
Publication date: 2015-10-15

Abstract

The present invention makes it possible to easily operate a plurality of simulators in coordination with one another. When simulating by operating software for performing a plurality of simulations in coordination with one another, one software serves as a primary simulator, while a software for performing a simulation other than the primary simulator serves as a secondary simulator. The primary simulator prepares functions for providing: the ability to receive the simulation time of the secondary simulator, and synchronize with the simulation time of the secondary simulator; the ability to receive a simulation value required for simulation from the secondary simulator; and the ability to transfer a value required for simulation by the secondary simulator to the secondary simulator. Thus, the primary simulator and the secondary simulator operate in coordination with one another as a result of the secondary simulator being linked to the primary simulator and calling these functions.

Description

Simulation system, simulation method, and program

The present invention relates to a technique for simulating by coordinating a plurality of simulators that internally manage simulation times in a simulation using an electronic computer.

Patent Document 1 discloses a synchronization matching unit that recognizes simulators having a connection relationship and synchronizes the simulators in time with respect to simulation as a method of performing simulation by integrating information while exchanging information among a plurality of simulators. A method comprising: In Patent Document 2, a simulator function group prepared for each type, a table for registering a function pointer necessary for synchronous execution in the function group, and a function for controlling the execution of each simulator are prepared. It shows how to configure a mix simulator by linking functions.

JP 2004-38785 A JP-A-5-258002

However, when a simulation is performed by coordinating a plurality of simulators as in the method disclosed in Patent Document 1, a communication path that connects the simulators is prepared, and values are exchanged while appropriately synchronizing the simulation times. In particular, when the value exchange frequency is high, the overhead associated with communication increases and the simulation speed decreases. Further, when an attempt is made to modify an existing simulator so as to correspond to the cooperative simulation, it is necessary to incorporate communication software after determining the communication protocol in consideration of the type and value of the signal to be exchanged.

Further, in the method disclosed in Patent Document 2, it is necessary for the simulation execution control unit to call each simulator in a processing unit corresponding to one simulation unit time, so that the frequency of calling each simulator is very high and processing overhead increases. End up. Further, when modifying an existing simulator and using it, it is difficult to deal with it unless the processing of one simulation unit time is clearly separated. Patent Document 2 also shows a method of calling the processing of each simulator only at a necessary time in order to suppress the frequency of calling the simulator. The “execution time” needs to be transmitted to the simulation execution control unit, and cannot be used in a situation where the “next processing time” cannot be obtained in advance when an existing simulator is used.

The present invention has been made in view of such a background, and an object of the present invention is to provide a simulation system, a simulation method, and a program capable of easily cooperating a plurality of simulators.

A main invention of the present invention for solving the above-described problem is a simulation system that operates first and second simulators that are software for performing simulation, wherein the first simulator performs processing related to the simulation. A plurality of modules; and an execution control processing unit that executes the modules in synchronization with each other. The module includes an activation unit that activates the second simulator, and a predetermined function from the second simulator. A link module including a function execution unit that synchronizes the execution of the module with the execution process control unit in response to a call, and the second simulator needs to be synchronized with the first simulator Are configured to call the function.

Other problems and solutions disclosed in the present application will be clarified in the column of the embodiment of the invention and the drawings.

∙ Multiple simulators can be easily operated in a coordinated manner.

It is an example of a block diagram of a simulation system. It is a figure explaining an example of the simulator before modification. It is an example of a basic composition at the time of making a some simulator cooperate. It is a figure explaining the method in which the simulator A cooperates with the simulator B via the module for a link. It is a figure showing an example of detailed operation of simulator B. It is a flowchart which shows the example of the process sequence of the module for a link in case the simulator A links simulator B dynamically. It is a flowchart which shows the example of the process sequence of an API function. A processing procedure for executing an example of simulation that is the simulator A will be described. The example of the relationship at the time of making the simulator A and the simulator B which added the offset to the simulation time cooperate is shown. It is a flowchart which shows the example of the process procedure of the module for a link in case the simulator A dynamically links the simulator B, when making the simulator A and the simulator B which added the offset to the simulation time cooperate. It is a flowchart which shows the example of the process sequence of an API function at the time of making the simulator A and the simulator B which added the offset to the simulation time cooperate. It is an example which changed the composition of the API function of simulator A. This is an example in which a simulator B and a simulator C are added to the simulator A as simulators that cooperate.

Hereinafter, a simulation system according to an embodiment of the present invention will be described with reference to the drawings.

The simulation system according to the present embodiment is a system for operating a plurality of simulators in a coordinated manner. Here, “simulator” means a program (software) for performing processing related to simulation. In the present embodiment, a process for performing a process related to simulation, which is realized by an electronic computer executing a simulator, is also referred to as a “simulator”. When referring to a simulator as a system, it is described as a “simulation system”. The cooperative operation of a plurality of simulators includes synchronizing execution of the plurality of simulators, and in this embodiment, further includes setting and referring to data (variables) between simulators.

FIG. 1 is a configuration example of an electronic computer constituting the simulation system according to the present embodiment. It is possible to operate as a simulation system by operating the simulator with an electronic computer as shown in FIG.

The electronic computer includes a central processing unit 101, a main storage device 102, and an input / output device 103, which are connected by an internal bus 111 and can exchange data with each other. The external storage device 121, the input device 122, and the display device 123 are connected to the internal bus 111 via the input / output control device 103, and the central processing unit 101, the main storage device 102, and data are connected via the input / output control device 103. Can be exchanged.

In the electronic computer, in accordance with an instruction input from the input device 122, the central processing unit 101 reads the simulator A 300 and the simulator B 400 stored in the external storage device 121 into the main storage device 102, and the simulator read into the main storage device 102. A simulation is performed by interpreting A300 and the simulator B400 and outputting the calculation result to the display device 123 or writing to the external storage device 121.

In this embodiment, the simulator A300 and the simulator B400 that can be started as independent simulators are modified and linked to form one integrated program, and the simulator A300 and the simulator B400 are operated in cooperation by executing this integrated program. A simulation is performed.

2 and 3 are basic configuration examples of a plurality of simulators according to this embodiment. In this embodiment, it is assumed as an example that the simulator A300 and the simulator B400 are cooperatively operated. The simulator A300 and the simulator B400 incorporate a module for performing a specific simulation process corresponding to a predetermined model, and the simulator A300 and the simulator B400 each manage a time corresponding to a simulation execution content at a certain point, that is, a simulation time. A time management function A361 and a time management function B407, and a simulation kernel A370 and a simulation kernel B404 that control module execution according to the simulation time.

As shown in FIG. 2, module X380 and module Y390 corresponding to a model that can be simulated by simulator A300 are incorporated inside simulator A300 before simulator A300 is modified. Although two modules are incorporated here, a necessary number of modules can actually be incorporated into the simulator A 300 according to the simulation contents. In the simulator A300, the time management function A361 manages the progress of processing in the modules X380 and Y390 (that is, the simulation time), and controls the execution of the modules X380 and Y390 so that the simulation kernel A370 synchronizes the simulation time of each module. To do. Thereby, each module cooperates. Note that the synchronization control of the module is a well-known technique such as SystemC, and therefore detailed description thereof is omitted.

Also, before the modification of the simulator B400, a module I401, a module J402, and a module K403 corresponding to models that can be simulated by the simulator B400 exist inside the simulator B400. Although three modules are incorporated here, in practice, a necessary number of modules can be incorporated into the simulator B 400 according to the simulation contents. The modules (modules I401, J402, and K403) corresponding to models that can be simulated by the simulator B400 may be in a format that cannot be incorporated into the simulator A300 as it is.

Also in the simulator B400, the time management function B407 manages the simulation times of the modules I401, J402, and K403, and the simulation kernel 404 controls the execution of the modules I401, J402, and K403, so that each module performs a cooperative operation.

As shown in FIG. 3, a link module 310 is added to the modified simulator A300. The link module 310 is a module for connecting another simulator. In this embodiment, the simulator B400 is connected to the simulator A300 via the link module 310.

The link module 310 is programmed to start another simulator (simulator B400 in this embodiment) when the module is started, and provides a function (API function 320) that is called from another simulator. The linking module 310 is programmed to request the simulation kernel A 370 to perform module synchronization when the API function 320 is called. The API function 320 is given the simulation time of another simulator as an argument. The link module 310 adjusts its own simulation time to the simulation time given as an argument. This is because the linking module 310 waits for a difference time between its own simulation time (that is, when another simulator calls it) and the simulation time when the other simulator performs processing. This is realized by requesting A370. This can be realized, for example, by calling the wait () function in SystemC.

A structure for exchanging information is also passed as an argument to the API function 320 (by reference or by pointer). The information exchange structure is a variable for storing a value (reference signal value) referring to the signal of the simulator A300 and a value (setting signal value) for updating the signal of the simulator A300, or information for accessing these variables. including. Which variable is used and which signal is exchanged is determined in advance. When the API function 320 is called, the link module 310 refers to the information exchange structure, obtains the setting signal value from the variable that can be specified by the information exchange structure, and obtains the corresponding signal in the simulator A300. It is programmed to write to a variable that holds a value, and to obtain a reference signal value from a variable that holds the value of the corresponding signal in simulator A300 and write it to a variable that can be specified by a structure for information exchange.

As described above, in this embodiment, the simulator A 300 and the simulator B 400 are linked and combined into one software program for execution. That is, the simulator A300 is handled as a main simulator, and the simulator B400 is handled as a subordinate simulator. In order to operate as one software program, the simulator B 400 is statically linked with the simulator A 300 at the time of compilation. Alternatively, the simulator B400 may be converted into a dynamic link library in advance and dynamically linked from the simulator A300.

Regarding the simulator B400, in order to link the simulator A300 and the simulator B400, the function name of the entry function (the so-called main () function) of the simulator B400 is changed to another function name. In this embodiment, the name of the changed function is referred to as a lib # main () function. Also, so that the simulator B 400 does not end the program regardless of the simulator A 300 when the simulation processing ends, at least when the simulation of the simulator B 400 ends normally, the program returns to the caller of the lib # main () function.

The simulation kernel A370 of the simulator A300 handles the linking module 310 in the same manner as the module X380 and the module Y390. That is, in the simulator A300, the simulation kernel A370 schedules the execution of each module so that the simulation times of the module X380, the module Y390, and the link module 310 are synchronized. Since this control is a well-known technique such as SystemC or the like, a detailed description thereof will be omitted, but an example of operation timing will be described later with reference to FIG.

Further, API functions provided by the linking module 310 of the simulator A300 are necessary in each module (modules I401, J402, and K403) that operate in the simulator B400 in a place where a value that requires information exchange with the simulator A300 is required. Modify to call 320.

As described above, in the modified simulator A300, when the API function 320 is called by the linking module 310, a synchronization request is issued to the simulation kernel A370, and synchronization processing between modules is performed. Thereby, the modules X380 and Y390 are synchronized, and the link module 310 is also synchronized. Therefore, the module that refers to and updates values that need information exchange with the simulator A300 in the simulator B400 is also synchronized, and each module (modules I401, J402, and K403) is also synchronized by the simulation kernel B404 in the simulator B400. Become.

A flow in which the simulator A 300 operates in cooperation with the simulator B 400 via the link module 310 will be described with reference to FIG.

When the control is transferred by the simulation kernel A370, the link module 310 calls the entry function (lib # main () function) and starts the processing of the simulator B400. When the simulator B400 is prepared as a dynamic library and dynamically linked, a parameter (API) transmitted to the simulator B400, predetermined initialization processing, that is, loading of the library, resolution of necessary symbols before calling the lib # main () function A process such as writing a pointer to the function 320 or a module identification code into a specific variable of the simulator B 400 is performed.

When the simulator B400 starts the simulation process by calling the lib # main () function, the simulator B400 continues the process until a signal value reference or update process that requires information exchange with the simulator A300 occurs. When a signal value reference or update process occurs, the update value is reflected in the information exchange structure in the exchange value update / acquisition process B430, and then the simulation time and information exchange corresponding to the reference or update process are reflected. The API function 320 of the simulator A300 is called by giving a structure as an argument.

When the API function 320 is called, the link module 310 first calculates a difference time between the simulation time of the link module 310 managed by the simulator A300 and the simulation time passed from the simulator B400 in the time synchronization process L321. To do. The link module 310 requests the simulation kernel A370 to advance the simulation time of the simulator A300 by the difference time. This request can be made, for example, by calling the wait () function in SystemC. The simulation kernel A370 requested to advance the simulation time causes the module X300 and the module Y300 to execute processing as necessary, and then returns control to the linking module 310 (running the API function 320).

Next, the link module 310 fetches the setting value designated in the information exchange structure into the variable of the setting destination designated in the information exchange structure in the value acquisition / update 330, and then in the simulator A300 Then, the value that has been updated to be passed to the simulator B 400 (the value of the reference destination variable specified in the information exchange structure) is set in the information exchange structure. Thereafter, the process returns to the caller of the simulator B400.

When all the simulation execution processes have been completed, the simulator B400 executes the exchange value update / acquisition process B430 to inform the simulator A300 of the final state of the simulator B400, and then the lib # main () function of the simulator A300 Returns to the place where was called. After returning, the linking module 310 requests the simulation kernel A370 to end the simulation or waits for the completion of other modules in the simulator A300.

As described above, in the simulation system according to the present embodiment, the following modifications are made to allow the simulator A300 and the simulator B400, which can be operated independently, to operate cooperatively as one simulation program. That is, a window module (link module 310) for connecting the simulator A300 as a main simulator and the simulator B400 as a slave simulator was prepared. The linking module provides an API function 320. The entry function (so-called main function) of the simulator B400 is replaced with a function name (a function having a name that is not a reserved word) that can be called from the simulator A300, and used as a function for starting the simulator B400. After that, the object codes of the simulator A 300 and the simulator B are combined by link processing. As a result, the simulator A 300 and the simulator B 400 can operate cooperatively as one simulation program. Further, when one linked simulation program is executed, the simulator A300 calls a function for starting the simulator B400 when the simulation process of the simulator B400 is first required. Furthermore, the simulator B400 calls the API function 320 of the simulator A300 when it is necessary to pass a value to the simulator A300 or when the value of the simulator A300 needs to be acquired. When the API function 320 is called from the simulator B400, the simulator A300 advances the processing until the simulation time of each simulation module processed by the simulator A300 becomes after the simulation time of the simulator B400 (the link module 310 is set to wait ()). It waits with a function), fetches a value from the simulator B400 and updates a value to be passed to the simulator B400 via the information exchange structure, and then returns the process to the simulator B400. The simulator B 400 returns from the activation function at the end of the simulation, and returns the processing to the simulator A 300.

By such a modification, the synchronization function of each module in the main simulator A300 (simulation execution control processing by the simulation kernel A370) is used, and not only the module incorporated in the simulator A300 but also the value on the simulator A300 side in the simulator B400. Modules that need to be acquired or updated can also be synchronized, and each module incorporated in the simulator B400 by the simulation execution control process by the simulation kernel B404 of the simulator B400 can be synchronized in the same manner. That is, a plurality of simulators can be easily coordinated. In addition, since communication between programs is not required between simulators, the execution speed of cooperative simulation by a plurality of simulators can be improved. Furthermore, if the linking module 310 is created for the simulator A300, the simulator B400 changes the entry function name and changes the value between the simulators so that the API function 320 of the simulator A300 is called at the reference point. Therefore, when using an existing simulator, it is possible to reduce the number of man-hours for modifying the simulator and efficiently perform the modification.

In the simulation system according to the present embodiment, the API function 320 is called from the simulator B 400 to synchronize the module incorporated in the simulator A 300 with the module incorporated in the simulator B 400 and to refer to variables in the simulator A 300. And updates can be made. Therefore, it is possible to easily realize reference and update of signal values between the simulator A 300 and the simulator B 400 via the information exchange structure.

Further, in the simulation system of the present embodiment, the simulator B400 can be prepared as a dynamic link library. Therefore, even when changing the simulation process in the simulator B400 connected to the simulator A300, only the simulator B400 needs to be modified, and the development efficiency can be improved.

FIG. 5 shows an example of the operation of the simulator B 400 with respect to the contents shown in FIG. 4, and shows a more detailed operation. The overall processing flow is as already described in the description of FIG. When the simulator A 300 starts processing as the main simulator, initialization A 302 initializes internal variables and the like, and then starts a simulation execution control process 360.

The time management function A361 of the simulation execution control process 360 manages the simulation time and execution status of each module in the simulator A300, and the simulation execution control process 360 has the earliest simulation time for a module that has not been processed. Process to transfer control to. At this time, if the module to which the control is transferred is not started, the first process of the module is called, and if the module has been started (that is, the simulation execution control process 360 is performed by the time synchronization request from the module). If so, return to the module that called the time synchronization request. When there are a plurality of modules having the earliest simulation time, any one of those modules is selected and control is transferred.

The simulation execution control process 360 receives a waiting time from the module when receiving a time synchronization request from the module, and updates the simulation time of the module by integrating the waiting time.

Immediately after the start of the simulation execution control process 360, the simulation time is 0 for all modules in the simulator A300, so that the modules are sequentially activated. For example, as shown in FIG. 5, when the module X380 is first activated and the process proceeds in the module X380 and the time synchronization process X382 is executed, a time synchronization request is generated and the control returns to the simulation execution control process 360. The simulation execution control process 360 updates the simulation time of the module X382, and then activates the link module 310. The linking module 310 activates the simulator B400 at the simulator B activation 311 and transfers control to the simulator B400.

The simulator B400 performs the actual processing of the simulation after the processing is started, after initialization of the simulator is performed in initialization B405. The simulation actual process is a loop process, and the simulation time is updated by the time update B1 (421) and the time update B2 (422) existing in the loop. In the simulator B400, the process proceeds and reaches an inter-simulator exchange value update B431 and an inter-simulator exchange value reference B432 in which a value that needs to be exchanged between simulators in a certain module or a value that needs to be exchanged between simulators is generated. Then, the API function 320 of the link module 310 is called.

Simulator B400 performs simulator processing by repeating a loop until the simulation end condition is satisfied, for example, the simulation time reaches a certain time. When the end condition is satisfied, the simulator B400 executes the end process B406 and calls the API function 320 of the simulator A300 to inform the simulator A300 of the final state of the simulator B400. When the end process B406 is completed, the process returns to the module end process 341 of the link module 310 of the simulator A300.

The link module 310 generates a time synchronization request so as to wait for a difference time between the simulation time passed from the simulator B 400 and the simulation time of the link module 310 in the time synchronization process L321 in the API function 320, and the simulation execution control process Control returns to 360. The simulation execution control process 360 updates the simulation time of the linking module 310, and the simulation time of the linking module 310 becomes the simulation time of the module that called the API function 320 in the simulator B400. Next, the simulation execution control apparatus 360 activates the module Y390. When processing proceeds in module Y390 and time synchronization processing Y392 is executed, a time synchronization request is generated by module Y390, and control returns to simulation execution control processing 360.

In this way, all modules in the simulator A300 are activated.

After all modules of the simulator A 300 are activated, the simulation execution control process 360 can return to the time synchronization request source of the module with the earliest simulation time, so that each module can continue the process.

The processing procedure of the simulator B 400 shown in FIG. 5 is an example, and is a simulator in which the simulation time update process and the exchange value between the simulators are updated or referred to, and programmed to call the API function 320 at that time. Any simulator can be handled as the simulator B400.

FIG. 6 is a flowchart showing an example of a processing procedure of the linking module 310 when the simulator A 300 dynamically links the simulator B 400.

First, in module B400 reading S801, the linking module 310 reads the simulator B400 that has been made into a dynamic link library. Next, in symbol resolution S802, the linking module 310 acquires a pointer to the entry function of the simulator B 400, a pointer to a variable indicating access information to the API function 320, and a pointer to a parameter registration structure. In API function setting S803, the link module 310 registers access information to the API function 320 in a variable indicating access information to the API function. A variable indicating access information to the API function 320 is a pointer to the function in the case of the C language, and a pointer to an instance of the link module 310 in the case of the C ++ language (for example, the link module 310 is defined as a class. Is prepared as a member function of the linking module, and the member function is called using a pointer to the instance).

In parameter setting S804, the link module 310 writes a parameter to be passed to the simulator B 400 in the information exchange structure. In the simulator B process S805, the linking module 310 calls the simulator B400. When the process of the simulator B400 is completed, the linking process of the linking module 310 is performed in the ending process S806.

In FIG. 6, the process from the simulator B reading S801 to calling the simulator B 400 in the simulator B process S805 corresponds to the simulator B activation 311 in FIG. 5, and the end process S806 corresponds to the module end process 341 in FIG.

The parameter registration structure has the initial conditions of the simulator B 400 and the like, and is set in the parameter setting S804. However, if there is no parameter to be passed including the initial conditions, the parameter registration structure is unnecessary, and the parameters in the symbol resolution S802 Acquisition of a pointer to the registration structure and processing of parameter setting S804 can be omitted.

Even if the simulator A300 is described in SystemC (C ++ as a programming language) and the simulator B400 is described in C language, the linking module 310 should have an API function 320 accessible from C language. It is possible. At this time, in order to exchange values between simulators, it is necessary to access the member variables of the link module 310 during the processing of the API function 320. Therefore, a pointer to the instance of the module 310 for linking when the simulator B 400 is activated is included in the parameters set in the parameter setting S804, and the pointer to the instance is passed as a parameter for calling the API function 320 from the simulator B 400 side. The API function 320 can cope with this by accessing a member variable using a pointer to an instance received as a parameter.

FIG. 7 is a flowchart showing an example of the processing procedure of the API function 320. When the API function 320 is called from the simulator B 400 side, the simulation time difference calculation S811 calculates the difference between the simulation time of the simulator A 300 and the simulation time of the module that called the API function 320 in the simulator B 400 received as a parameter when the API function is called. . Next, in simulation time synchronization S812, a time waiting process is performed for the difference time, thereby matching the simulation time of the simulator A300 with the simulation time of the module that called the API function 320 in the simulator B. The time waiting process is performed by requesting the simulation kernel A370. For example, when the simulator A300 is described in SystemC, the wait () function is called by designating the difference time.

The pointer to the instance of the linking module 310 and the simulation time of the simulator B400 are transferred from the simulator B400 to the simulator A300 using the structure (information exchange structure) used for information exchange between the simulator A300 and the simulator B400. It doesn't matter.

Simulator B signal value acquisition (refer to information exchange structure) In S813, the signal value to be received by the simulator A300 from the simulator B400 is included in the information exchange structure passed as a parameter when the simulator B400 calls the API function 320. The member variables holding these signal values are copied to the variables managed by the simulator A300.

In signal update to simulator B (update structure for information exchange) S814, when simulator B 400 calls API function 320 from a variable managed by simulator A 300 regarding the signal value to be sent from simulator A 300 to simulator B 400 Copy these signal values contained in the information exchange structure passed as parameters to the member variables.

FIG. 8 shows an example of a procedure executed by each module in the simulator A300 in synchronization. The simulator A300 first executes process 1 (501) by the module X380. When the process 1 (501) is completed, the module X380 becomes the simulation time T1. At this time, the modules with the shortest simulation time are the link module 310 and the module Y 390 at the simulation time 0, so the processing of any one of these modules is executed next. In the example of FIG. 8, the processing of the link module 310 is executed.

The process 2 (502) of the link module 310 is executed and the process is completed at the simulation time T2, and the link module 310 reaches the simulation time T2. Since the module having the smallest simulation time at this time is the module Y390 at the simulation time 0, processing 3 (503) is executed next at the module Y390, and the processing is completed at the simulation time T3. The module Y390 becomes the simulation time T3. . Since the module having the smallest simulation time at this time is the module X380 at the simulation time T1, processing 4 (504) is executed at the module X380, and the processing is completed at the simulation time T4. The simulator X380 becomes the simulation time T4. Since the module having the smallest simulation time at this time is the link module 310 at the simulation time T2, the link module 310 executes the process 5a (505).

The process 5a (505) performs a series of processes together with the process 5b (515). Since the signal value of the other module is referred to at the simulation time T6 that is the completion time of the process 5a (505), the simulation time is The process proceeds to the execution of the module Y390 at the simulation time T3, which is the smallest module, and the process 6 (506) is executed. Process 6 (506) is completed at simulation time T5, and module Y390 is at simulation time T5. At this time, the process moves to the execution of the module X380 at the simulation time T4, which is the module with the smallest simulation time, and the process 7 (507) is executed. After the completion of the process 7 (507), the simulation time of the module X380 becomes the completion time of the process 7 (507). Since the module having the smallest simulation time at this time is the module Y390 at the simulation time T5, the process Y (508) is executed at the module Y390, the process is completed at the simulation time T7, and the module Y390 becomes the simulation time T7. Since the module with the smallest simulation time at this time is the link module 310 at the simulation time T6, the process 5b (515) is executed by the link module 310, and the process is completed at the simulation time T8. Simulation time T8 is reached. Since the module having the smallest simulation time at this time is the module Y390 at the simulation time T7, the process Y (510) is executed by the module Y390, and the simulation time of the module Y390 becomes the completion time of the process 10. Since the module with the smallest simulation time at this time is the link module 310 at the simulation time T8, the link module 310 executes the process 9 (509) and completes the process 9 (509). At this time, all the processes of the simulator A300 are completed.

When the value is updated by each process, the timing at which the updated value can be referred from other than the module that performed the process is the time when the next process executed by the module is started. For example, the value updated by the process 1 (501) can be referred to by the link module 310 or the module Y 390 at the start of the process 4 (504). This is because when the processing 1 (501) is completed, the simulation time of the modules other than the module X380 may be before the time T1. For convenience of the simulation processing, the reference value of the module to be processed next is the processing value. This is because the value before reflecting the processing result of 1 (501) is required. That is, processing 2 (502) and processing 3 (503) need to refer to values before reflecting the processing result of processing 1 (501). Further, at the timing of starting the process 4 (504), the simulation time of modules other than the module X380 is guaranteed to be after the time T1, so the processing result of the process 1 (501) is referred from other modules at this timing. If possible, the result of the process 1 (501) can be correctly referred to in other modules as in the process in the module X380.

FIG. 8 assumes a situation where there is no timing at which only a reference is made without updating a value, except for the boundary between the processing 5a (505) and the processing 5b (515). Also, it is possible to refer to the values of other modules at the value update timing.

In FIG. 8, the processing portion of the link module 310 indicates that the simulator B 400 is actually processed via the link module 310.

By proceeding with the processing as described above, the simulator A300 can reproduce the operation of executing a plurality of modules in a pseudo parallel manner.

As described with reference to FIG. 8, it is actually necessary for a certain module to request the simulation time to be a certain time, that is, to request that the simulation kernel A 370 in FIG. This means that the simulation process is continued until the module other than the request source is after the specified time.

In the present embodiment, an example in which an offset can be added to the simulation time of the simulator B400 when the simulator A300 and the simulator B400 perform a cooperative operation will be described.

FIG. 9 shows an example of the relationship between the simulator A300 and the simulator B400 in which an offset is added to the simulation time.

In the simulator A300, the simulation of the initialization process is performed by the initialization unit simulation 901 during the simulation, and then the simulation of the actual process is performed by the actual process simulation A902. The simulator B 400 does not simulate the initialization process, and the actual process simulation 912 is performed from the beginning. That is, the simulation times of the simulator A 300 and the simulator B 400 are executed while being offset from each other.

The simulation in which the offset time is added to the simulation time in this way is, for example, a simulator in which the simulator A300 simulates a microcomputer, and when the software for the microcomputer is executed on the model and the simulator B400 simulates the operation of the machine. It is valid. In such a case, in the simulator A300, after executing software corresponding to hardware initialization and operating system activation, machine control software is operated, and simulation and cooperation processing of the machine operating in the simulator B400 starts. When the simulator A300 and the simulator B400 are started at the same time and the cooperative simulation is executed, the simulation of the simulator B400 becomes a useless process until the machine control software operates in the simulator A300. Therefore, by delaying until the initialization-related processing is completed in the simulator A300, the simulator B400 is started, so that the processing of the simulator B400 during the period of executing the initialization-related simulation processing can be suppressed, and the initialization-related simulation processing can be performed. The speed can be increased.

FIG. 10 is a flowchart showing an example of a processing procedure of the linking module 310 when the simulator A 300 dynamically links the simulator B 400 when the simulator A 300 and the simulator B 400 to which an offset is added to the simulation time are cooperatively operated. For the processing shown in FIG. 6, an offset time waiting S807 is inserted between the API function setting S803 and the parameter setting S804.

In the waiting for offset time S807, the linking module 310 requests the simulation kernel A370 to advance the simulation time by the offset time. This request causes the simulation time of the simulator A300 to advance by the offset time.

In the parameter setting S804, in addition to the contents shown in FIG. 6, a value to be passed from the simulator A300 to the simulator B400 at the simulation time is set as an initial parameter of the simulator B400 so that the simulator B400 can match the state of the simulator A300 with respect to the initial conditions. To.

10 except for the offset time waiting S807 and the parameter setting S804 in FIG. 10 is the same as the content described in FIG.

FIG. 11 is a flowchart showing an example of the processing procedure of the API function 320 when the simulator B 400 and the simulator B 400 are operated in cooperation by adding an offset to the simulation time. The simulation time difference calculation S811 in FIG. 7 is changed to a simulation time offset added difference calculation S819 in FIG. In the difference calculation with simulation time offset S819, the difference between the simulation times on the simulator A300 side and the simulator B400 side is calculated in consideration of the influence of the offset time. That is, the link module 310 calculates the difference between the simulation time received from the simulator B 400 and the time when the offset time is returned from its own simulation time. The processing of the other parts in FIG. 11 is the same as that described in FIG.

As described above, according to the contents shown in FIGS. 10 and 11, an offset can be added to the simulation time of the simulator B400. That is, by specifying the offset, the activation timing of the simulator B400 can be easily changed as necessary.

In this embodiment, an example in which the configuration of the API function 320 of the simulator A300 is changed will be described with reference to FIG.

In the third embodiment, the configuration of the API function 320 shown in the first embodiment is divided into three functions instead of one function. By dividing into three functions, the respective processes of the time synchronization process L321, the value acquisition 331, and the value update 332 can be directly controlled from the simulator B400. By dividing the functions of the value acquisition 331 and the value update 332, when an update occurs to the value to be sent to the simulator A300 by the simulator B400, the exchange value update processing B440 is performed. When it is necessary to refer to the exchange value, the exchange value reference processing B450 can be performed.

In the exchange value update processing B440, first, a function that executes the time synchronization processing L321 by the time synchronization request B1 (441) is called by giving the simulation time of the module that called the API function 320 by the simulator B400 as an argument. In the exchange value update B442, a function for executing the value acquisition 331 is called by giving a pointer to the information exchange structure as an argument. In the value acquisition 331, the simulation kernel A370 of the simulator A300 performs a process of fetching a necessary value from the information exchange structure from the simulator B400.

In the exchange value reference process B450, first, a function for executing the time synchronization process L321 by the time synchronization request B1 (441) is called by giving the simulation time of the simulator B400 as an argument, and then the value is updated by the exchange value reference B452. Is called with a pointer to the information exchange structure as an argument. In the value update 332, the link module 310 in the simulator A300 performs a process of writing a value to be passed to the simulator B400 into the information exchange structure.

By dividing the API function into three functions, the process of passing values from the simulator A 300 to the simulator B 400 and the process of passing values from the simulator B 400 to the simulator A 300 can be separated. This is necessary when calling the API function 320 on the simulator A 300 side. Only processing can be performed.

Note that the API function 320 may have two configurations: a function that performs time synchronization processing L321 and value acquisition 331, and a function that performs time synchronization processing L321 and value update 332. It is also conceivable to provide both the function shown in the first embodiment and the function shown in the third embodiment as the configuration of the API function 320. Further, by combining this embodiment with the second embodiment, an offset can be added to the simulation time of the simulator B400.

In this embodiment, an example in which a simulator C600 is connected to the simulator A300 in addition to the simulator B400 as a cooperatively operating simulator will be described with reference to FIG. That is, in addition to the link module 310 for connecting the simulator B 400 to the simulator A 300, a link module 350 is prepared, and the simulator B 400 and the simulator C 600 are connected to each.

Since the method for connecting the linking module 310 and the simulator B400 and the method for connecting the linking module 350 and the simulator C600 are the same as the method for connecting the linking module 310 and the simulator B400 shown in the first embodiment, respectively. Description is omitted.

When it is necessary to exchange simulation values between the simulator B400 and the simulator C600, the simulation is performed via the simulator A300. As the simulator A300, the simulator B400 is handled as the linking module 310 and the simulator C600 is handled as the linking module 350, and the simulation processing proceeds so that the entire consistency can be obtained as the simulator A300. If this idea is extended, it is possible to connect not only two but also more simulators to the main simulator for cooperative operation.

In FIG. 13, the linking module 310 and the linking module 350 are the same as the module, and it is also conceivable that only the instances are separated. For example, when mounting with SystemC, it is possible to prepare the link module 310 as one class, and to create and correspond to the number of simulators to be connected.

Thus, by incorporating the two link modules (310, 350) into the simulator A300, a plurality of other simulators (B400, C600) and the simulator A300 can be operated in a coordinated manner.

This embodiment can be combined with the second embodiment to add an offset to the simulation time of the simulator B400 and the simulation time of the simulator C600. At this time, by using different offsets in the link module 310 and the link module 350 to synchronize the simulation times, the simulator B400 and the simulator C600 can also perform cooperative simulation using different simulation times. In combination with the third embodiment, the API function provided by the simulator A300 can be provided as a plurality of functions.

As mentioned above, although this embodiment was described, the said embodiment is for making an understanding of this invention easy, and is not for limiting and interpreting this invention. The present invention can be changed and improved without departing from the gist thereof, and the present invention includes equivalents thereof.

101 Central processing unit 102 Main storage device 103 Input / output control device 111 Internal bus 121 External storage device 122 Input device 123 Display device 300 Simulator A
301 Start 302 Initialization A
303 End processing A
304 End 310 Link module 311 Simulator B start 320 API function 321 Time synchronization processing L
330 Value acquisition / update 331 Value acquisition 332 Value update 341 Module end processing 360 Simulation execution control processing 361 Time management function A
370 Simulation kernel A
380 module X
381 Module X execution 382 Time synchronization processing X
390 module Y
391 Module Y execution 392 Time synchronization processing Y
400 Simulator B
401 Module I
402 Module J
403 Module K
404 Simulation kernel B
405 Initialization B
407 Time management function B
406 End processing B
421 Time update B1
422 Time update B2
430 Exchange value update / acquisition processing B
431 Inter-simulator exchange value update B
432 Inter-simulator exchange value reference B
440 Exchange value update process B
441 Time synchronization request B1
442 Exchange value update B
450 Exchange value reference process B
451 Time synchronization request B2
452 Exchange value reference B
501 Processing 1
502 Processing 2
503 treatment 3
504 Processing 4
505 treatment 5a
506 Processing 6
507 treatment 7
508 Processing 8
509 treatment 9
510 treatment 10
515 Process 5b
600 Simulator C
607 Time management function C
630 Exchange value update / acquisition processing C
901 Initialization simulation 902 Actual processing simulation A
912 Actual processing simulation B
S801 Simulator B reading S802 Symbol resolution S803 API function setting S804 Parameter setting S805 Simulator B processing S806 End processing L
S811 Simulation time difference calculation S812 Simulation time synchronization S813 Signal value acquisition of simulator B (see structure)
S814 Simulator B signal value update (structure update)

Claims

A simulation system for operating first and second simulators, which is software for performing simulation,
The first simulator includes a plurality of modules that perform processing related to the simulation, and an execution control processing unit that executes the modules in synchronization with each other,
The module includes an activation unit that activates the second simulator, a function execution unit that synchronizes execution of the module with the execution processing control unit in response to a call of a predetermined function from the second simulator, A linking module comprising
The simulation system, wherein the second simulator is configured to call the function when it is necessary to synchronize with the first simulator.
2. The simulation system according to claim 1, wherein the function execution unit synchronizes execution of the module in response to the call of the function, and refers to a value of a variable set by the first simulator. A simulation system characterized by responding to a second simulator and setting a value given from the second simulator as a variable that can be referred to by the first simulator.
3. The simulation system according to claim 1, wherein the activation unit included in the first simulator delays activation of the second simulator by the offset time when an offset time is given. A featured simulation system.
4. The simulation system according to claim 1, wherein the module includes a plurality of the link modules corresponding to each of the plurality of second simulators. 5. Simulation system.
5. The simulation system according to claim 1, wherein the second simulator is implemented as a dynamically linkable library program, and the second simulator is executed when the first simulator is executed. 6. A simulation system characterized by being linked.
A program for executing a simulation in synchronization with another simulator,
A computer realizes an execution control processing function for executing a module for performing the processing related to the simulation in synchronization,
The module includes an activation function for activating the other simulator, and a function execution function for synchronizing execution of the module by the execution process control function in response to a call of a predetermined function from the other simulator. A linking module that is a program to be realized by the computer is included;
The other simulator is configured to call the function when it is necessary to synchronize.
The program according to claim 6, wherein the function execution function synchronizes execution of the module in response to the call of the function, and refers to a value of a variable set by the first simulator. A program that includes a function of responding to a second simulator and setting a value given from the second simulator to a variable that can be referred to by the first simulator.
8. The program according to claim 6, wherein the start function delays start of the other simulator by the offset time when an offset time is given.
The program according to any one of claims 6 to 8, wherein the module includes a plurality of link modules corresponding to the plurality of other simulators, respectively, and a function of managing a simulation time A program characterized in that a plurality of different software for performing simulation can be connected.
10. The program according to claim 6, wherein the other simulator is implemented as a dynamically linkable library program, and the library program is linked to the program. Program to do.
A method for cooperatively operating first and second simulators, which are software for performing simulations,
The first simulator includes a plurality of modules that perform processing related to the simulation, and an execution control processing unit that executes the modules in synchronization with each other,
The module includes a linking module,
The linking module activates the second simulator, calls the execution control processing unit in response to a call of a predetermined function from the second simulator,
The execution control processing unit synchronizes execution of the module,
The simulation method, wherein the second simulator is configured to call the function when it is necessary to synchronize with the first simulator.
12. The simulation method according to claim 11, wherein the link module delays activation of the second simulator by the offset time when an offset time is given.