JP2003177943A - Method, device, and program for simulating roughly multitask software - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To limit detailed design conditions more and to shorten a development period by avoiding the repetition of designing and an actual machine test by roughly designing hardware and software and simulating them before they are designed in detail. <P>SOLUTION: To roughly simulate the timing of input and output signals of a computer 21 to and from a peripheral device 22 before multitask software processing the input and output signals in real time is designed in detail, model tasks task1 to taskN are generated which represent detailed processes of respective tasks as wait processes for waiting for their estimated times to pass and one cycle time is determined as the minimum value of the wait process times included in the model tasks task1 to taskN; and a task execution control part 23 determines which of the model task is executed in a next cycle, cycle by cycle, by specified algorithm and multitask processing is simulated. The task execution control part 23 generates threads (actual flow of processes) corresponding to the respective tasks according to the contents of the task1 to taskN and executes or stops (sleeps) the tasks. At this time, the states of the respective threads are stored in a state storage part 24. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention performs a simulation of general multitask software for simulating the outline of the timing of input / output signals of the multitask software before the detailed design of the multitask software for processing the input / output signals in real time. A method, an apparatus, and a program.

[0002]

2. Description of the Related Art For example, in a system in which a processor controls a vehicle engine, it is necessary to perform multitask processing in real time based on a large number of input data. In the development of this system, if real-time control is not possible due to processing delay, this problem may be solved by using a higher performance processor. However, as the cost of hardware increases, the OS becomes complicated and the cost of software also increases. Therefore, it is necessary to solve the problem so that the cost is as low as possible in terms of both software and hardware.

Conventionally, by developing software, loading it into an existing or newly developed processor, and executing it under various input / output conditions between the processor and an external peripheral device, desired real time processing is performed. I was doing a comprehensive timing verification of software and hardware to see if it was possible to control.

[0004]

However, as a result of the verification,
When a problem is confirmed, it is necessary to redesign the software (and hardware), and if the timing is partially shifted, the timing may be shifted in other portions. For this reason, repeated design and actual tests have been a cause of lengthening the development period.

In view of the above problems, an object of the present invention is to further limit the detailed design conditions by designing the software (and hardware) in detail before performing the detailed design and simulating the software. It is an object of the present invention to provide a method, a device and a program for simulating general multi-task software which can avoid the repetition of design and actual test and shorten the development period.

[0006]

According to one aspect of the general multitask software simulation method of the present invention, (a) before the detailed design of the multitask software that processes input / output signals in real time, the multitask software is executed. In order to simulate the outline of the timing of the input / output signals of the above, a plurality of model tasks are created by representing the detailed processing of each task by waiting processing for waiting for the estimated time to elapse, and (b) one cycle time Of the plurality of model tasks, and (c) which of the plurality of model tasks is to be executed in the next cycle is determined for each cycle by a predetermined algorithm, and the multitask processing is simulated. .

According to this configuration, the processing time and the processing timing required for each task for normally performing real-time control can be known before the detailed design of software (and hardware). By designing the hardware (and software) in detail based on this, it is possible to avoid extending the development period due to the repetition of the conventional design and actual test.

Other objects, configurations and effects of the present invention will be apparent from the following description.

[0009]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention will be described below with reference to the drawings.

[First Embodiment] FIG. 1 shows a schematic multitask software simulation method according to a first embodiment of the present invention.

This general multi-task software simulation method uses software (and hardware).
Prior to the detailed design of the detailed design, whether or not the processor can perform the desired real-time processing is roughly checked, and if a problem occurs, the detailed design conditions for solving it This is to avoid repeating the actual test.

The general multi-task software simulation method is a general computer system in which an input device 11 and a display device 12 are connected to a computer 10. In FIG. 1, the software configuration of the computer 10 is shown by functional blocks. A model 20 is stored in the storage unit of the computer 10. The model 20 is a schematic one, and is created before the detailed design of the processor for real-time control and the software for operating this processor.

The model 20 includes a computer 21, a peripheral device 22, and a register REG1 connected between them.
~ REGm. The computer 21 is a model of a configuration including a processor, a memory, an input / output interface, and a bus interconnecting them, and is configured by one chip or a plurality of chips, but its specific configuration is not considered. . The peripheral device 22 is, for example, a model of a home electric appliance, and supplies the computer 21 with signals SG1 to SGn indicating the state of the peripheral device 22 or its surroundings. The computer 21 generates control data based on these signals and stores the control data in the registers REG1 to REGm. The peripheral device 22 is controlled in real time based on the contents of the registers REG1 to REGm.

The model 20 starts its operation based on a start command from the input device 11. The operation trace unit 30 is
It is a program for detecting and tracing the internal state of the model 20, and the result is supplied to the display device 12 and displayed.

The outline of the application program of the computer 21 is a model task for real-time control.
Represented by task1 to taskN. Hereinafter, for simplification, the model task is simply referred to as a task. Task execution control unit 23
Is a program, N tasks stored in the storage unit
A thread (actual processing flow) corresponding to each task is generated based on the contents of 1 to taskN, and the task is executed or stopped (sleep). At this time, the state of each thread (task execution or stop state) is stored in the state storage unit 24.

In FIG. 1, threads SL1 to SL4 correspond to, for example, task1 to task4, respectively. Figure 1
The main thread SL1 is generated at time t0, and ta is generated at time t1.
The sub-thread SL2 is generated by sk1, and tas is generated at time t2.
It is indicated that the sub-threads SL3 and SL4 are generated by k2, the processing of task4 and task3 is completed at time t3 and t4, respectively, and the processing of task1 and task2 is completed at time t5.

For processing other than input / output in each task, only the processing time τ is considered. τ is a relative time, and its unit is u. For example, task1 to task3 are represented as shown in FIG. That is, task1 is represented by the sequence of functions f11 and f12, task2 is represented by the sequence of functions f21, f22 and f23, and task3 is represented by the sequence of functions f31 and f32 or the sequence of functions f31 and f33. The functions f32 and f33 are selected based on the value of the input signal SG1 in the processing of the function f31.

Task1 to taskN are described in the SystemC (trademark, http://www.systemc.org) language, for example.
The above task1 and task3 are described as follows, for example. // −−−−−−−−−−−−−−−−−−−−−−−−−−−−− task1 () {f11 (); f12 ();} f11 () {spend_time ( 10) // f11 simulation content} f12 () {spend_time (20) // f12 simulation content} // −−−−−−−−−−−−−−−−−−−−−−−− −−−−−−− task3 () {f31 (); f32 ();} f31 () {spend_time (20) if (SG1 == 0) f32 (); else f33 (); // f31 simulation Content} f32 () {spend_time (10) // f32 simulation content} f33 () {spend_time (20) // f33 simulation content} // −−−−−−−−−−−−−−− --------------- Although the above task shows the case where there is no output process for simplification, the output process may be included before or after each spend_time (τ).

FIG. 3 shows the contents of the function spend_time (τ) in the task Ti, which is executed by the task execution control section 23 of FIG. Hereinafter, the numbers in parentheses indicate the step identification codes in the drawings.

(S1) The time unit u of the argument τ of spend_time (τ) is converted into the cycle time c. One cycle time is the minimum value of the argument τ of spend_time (τ) used in all tasks, and in the case of FIG. 2, for example, 5u = 1c is determined. In this case, τ / 5 is substituted for τ. It One cycle time is usually several μm to several msec.

(S2) If τ = 0, the process is terminated. If not, the process proceeds to step S3.

(S3) In order to synchronize all threads,
That is, in order to match the current times on the time axis of all threads, if there is a thread that has not elapsed until the current cycle, the thread waits for the elapse.

(S4) Task T to be executed in the next cycle
X is determined as described below.

(S5) If the task Ti that has called spend_time (τ) matches the next cycle execution task TX, the process proceeds to step S6. If not, the process returns to step S3.

(S6) Decrement the value of τ by 1,
Return to step S2.

FIG. 4 shows the details of step S4 in FIG.
9 is a flowchart showing a case where a round robin method is adopted, and in this method, a next cycle execution task is determined so that the task is cyclically switched and executed.

(S10) If there is a task candidate that can be executed in the next cycle in the state storage unit 24, step S
11. If not, that is, if all tasks on the thread are in the sleep state (stop state), go to step S11.
Proceed to 14.

(S11) The head task name TN in the task list as shown in FIG. 5 is taken out. Since the task list corresponds to the state of the current cycle in the state storage unit 24,
There is no need to create a new one. The task name in the task list corresponds to the thread existing in the current cycle.

(S12) The retrieved task name TN is moved substantially to the end of the task list. "Substantially"
The term “includes the case where it can be regarded as logically moved even if it is not actually moved. For example, a flag is provided for each thread, the flag of "1" is regarded as the first row of the task list, and the task name TN is substantially moved by shifting "1" in the flag column.

(S13) The task with the retrieved task name TN is determined as the task TX to be executed in the next cycle, and the process is terminated.

(S14) TX = φ is set, and the process ends. Here, φ indicates that it is empty.

If the task to be executed in the next cycle is determined by such a method, the task that is not in the sleep state on the existing thread is switched and executed every cycle.

FIG. 6 shows the two tasks task1 () and t described above.
5 is a time chart showing a case where ask2 () is executed by the method of FIG.

Through the above processing, the signals SG1 to SG
The execution content of the task changes according to Gn, which changes the update time of the content of the registers REG1 to REGm,
The control result of the peripheral device 22 controlled using these control data also changes. When the real-time processing by the computer 21 is delayed and the content update cycle of the registers REG1 to REGm is delayed, the value of the argument τ of spend_time (τ) is changed to adjust the timing of executing and stopping the task,
Alternatively, the processing speed of the processor is improved. The change of the value of the argument τ corresponds to the change of the processing method and the change of the programming language.

According to the first embodiment, the processing time and the processing timing required for each task for normally performing real-time control can be known before the detailed design of software (and hardware). By designing the software (and hardware) in detail based on this, it is possible to avoid the extension of the development period due to the repetition of the conventional design and actual test.

[Second Embodiment] FIG. 7 is a flowchart showing another processing method of step S4 of FIG. 3 as a second embodiment of the present invention. In this method, the next cycle is executed based on the task priority. Determine the task.

Steps S10 and S11 are the same as the corresponding steps in FIG.

(S20) As initial values, φ is assigned to the next cycle execution task TX, and the lowest priority PLmin is assigned to the priority PLX of the task.

(S21) The initial value 1 is assigned to the variable i indicating the i-th row of the task list.

FIG. 8 shows a task list, and each line consists of a task name and the priority of the task. The task name and priority of the i-th row are assigned to the task TN (i) and PLN, respectively.
It is represented by (i). The priority is, for example, levels 0 to 7, and the smaller the value, the higher the priority.

(S22) With reference to the state storage unit 24 in FIG. 1, it is determined whether the task of the task TN (i) is in the sleep state in the next cycle. If the task is in the sleep state, the process proceeds to step S25. If not, step S
Proceed to 23.

(S23) If the priority PLX of the next cycle execution task TX is higher than the priority PLN (i), that is, if PLX <PLN (i), proceed to step S24, otherwise proceed to step S25. .

(S24) TX and PLX are respectively TN
Substitute (i) and PLN (i).

(S25) Increment i by 1.

(S26) If the task TN (i) exists, the process returns to step S22, and if not, TX is set as the task to be executed in the next cycle, and the process of FIG. 7 ends.

By such processing, among the tasks in the next cycle on the thread, the task having the highest priority, not in the sleep state, is determined as the next cycle execution task TX. When there are a plurality of tasks having the same priority as the task TX, the execution task TX is determined according to the order (arrangement order in the storage device) in these task lists.

FIG. 9 shows the following two tasks having different priorities.
The case where task1 () and task2 () are executed is shown.

[0048] The above task shows the case where there is no input process for simplification, but the input process may be included before or after each spend_time (τ). Since the minimum value of the argument τ of spend_time (τ) is 1, it is determined that 1c = 1u.

The thread SL1 is a thread of task1 (), the control data dt1 is stored in the register REG1 of FIG. 1 at the time t = 0, and the thread SL1 is ta at the time t = 1c.
A thread SL2 of sk2 () is generated. task2 () is task
It is required to execute a calculation process having a higher priority than 1 (), and it is assumed that the priority of task2 () is set higher than that of task1 (). There are task1 () and task2 () that are not in sleep state in the task list.
() Has higher priority, so next cycle execution task TX
Task2 () is selected as and the send_time (4) is executed.

Next, the thread SL2 is deleted, only task1 () which is not in the sleep state exists in the task list, task1 () is selected as the next cycle execution task TX, and the control data dt2 is stored in the register REG1.
spend_time (3) is executed.

In FIG. 1, the peripheral device 22 has a register R.
It is assumed that the control data of the EG1 is read every 3u, and the control data must be updated by the computer 21 before this reading.

In the case of FIG. 9, this requirement is not satisfied, so this requirement is satisfied, for example, by setting one or more of the following as detailed design conditions.

(1) The processing content of task2 () is reduced.

(2) The execution timing of task2 () is shifted.

(3) A faster machine language code is generated for task2 ().

(4) A computer 21 faster than that is used.

[Third Embodiment] FIG. 10 is a flow chart showing still another processing method of step S4 of FIG. 3 as a third embodiment of the present invention. In this method, an interrupt is issued rather than a task priority. Prioritize and determine that task as the next cycle execution task. The peripheral device of FIG. 1 is, for example, a model of a car engine including a sensor.

There are eight interrupt factors for one interrupt, which are identified by 0 to 7, the interrupt process of factor i is executed by task Ti, and task Ti is pointer PTR.
Suppose it is specified in (i). Further, when there is an interrupt request for the factor i, the interrupt flag IF becomes "1" and the IRQ of the interrupt factor flags IRQ (0) to IRQ (7) is set.
It is assumed that only (i) becomes "1". In FIG. 1, the flags IF and IRQ (0) to IRQ (7) are the computer 2
It corresponds to the internal register 1 and the flag is set by a signal from the peripheral device 22 to the computer 21.

(S30) If IF = '0', the process proceeds to step S10 in FIG. 7, and if not, the process proceeds to step S31.

(S31) The initial value 0 is substituted for i.

(S32) If i <8, step S33
Go to step I, otherwise IRQ (0) to IR
If all of Q (7) are '0', step S1 in FIG.
Go to 0.

(S33) If IR (i) = '1', the process proceeds to step S35, and if not, the process proceeds to step S34.

(S34) The value of i is incremented by 1, and the process returns to step 32.

(S35) The thread of the task Ti designated by the pointer PTR (i) is generated.

(S36) IF = '0' and IRQ (i)
= '0' to avoid re-accepting the same interrupt request.

(S37) The task Ti is determined as the next cycle execution task TX.

FIG. 11 is a time chart showing the operation when the next task is executed by using the method of FIG.

[0068] The above task shows the case where there is no input process for simplification, but the input process may be included before or after each spend_time (τ). The function sleep (τ) is a process that suspends execution for a time τ to execute another task. In the above case, ta
During execution of sk1 (), an interrupt occurs in each of the second to fourth cycles, and task2 () is executed for each interrupt. As in the second embodiment described above, the peripheral device 22 shown in FIG.
It is assumed that the control data of G1 is read every 3u, and the control data must be updated by the computer 21 before this reading. Since this requirement is not met,
This requirement is satisfied by, for example, setting one or both of the following as detailed design conditions.

(1) The interrupt occurrence interval is set to a fixed cycle or more.

(2) Interrupt processing task2 () includes the function sleep (τ), that is, the interrupt processing is executed after a lapse of a predetermined time from the occurrence of the interrupt.

The present invention includes various modifications other than the above.

For example, one cycle time may be determined as 1 / (natural number) of the minimum value of the waiting processing time included in all tasks. This makes it possible to change the timing of reading the input signal, outputting the signal, and interrupting.

In the third embodiment, the case where the interrupt priorities are the same has been described for simplification, but the present invention is naturally applied to the case where interrupts with different priorities are present. Is.

Further, the model task is a concept including a model of what corresponds to each thread when one process is executed by a plurality of threads.

[Brief description of drawings]

FIG. 1 is a schematic block diagram showing a schematic multitask software simulation method according to a first embodiment of the present invention.

FIG. 2 is a schematic explanatory diagram of a task executed by a task execution control unit 23 of FIG.

FIG. 3 is a flowchart showing the processing contents of a function spend_time (τ) in task Ti, which is executed by the task execution control unit 23 of FIG. 1.

FIG. 4 is a flowchart showing details of step S4 in FIG. 3 when a round robin method is adopted.

FIG. 5 is a diagram showing a task list for explaining the processing of FIG. 4;

6 is a time chart showing a case where two tasks, task1 () and task2 (), are executed by the method of FIG.

FIG. 7 is a flowchart showing another processing method of step S4 of FIG. 3 as a second embodiment of the present invention.

8 is a diagram showing a task list for explaining the processing of FIG. 7. FIG.

[Fig. 9] The following two tasks task1 () and t with different priorities
8 is a time chart showing a case where ask2 () is executed by the method of FIG. 7.

FIG. 10 is a flowchart showing yet another processing method of step S4 of FIG. 3 as a third embodiment of the present invention.

[Figure 11] Figure 1 shows the main task task1 () and interrupt task task2 ().
It is a time chart which shows the case where it performs by the method of 0.

[Explanation of symbols]

10 computers 11 Input device 12 Display 20 models 21 computer 22 Peripheral device 23 Task execution control unit 24 State storage 30 Motion trace section SL1 to SL4 threads SG1 to SGn signals task1 to taskN model tasks REG1 to REGm registers

Claims (10)

[Claims] 1. (a) Prior to detailed design of multi-task software that processes input / output signals in real time, detailed processing of each task is performed to estimate the timing of input / output signals of the multi-task software. A plurality of model tasks represented by waiting processing for waiting for the elapse of time, (b) 1 cycle time is determined based on the waiting processing time included in the plurality of model tasks, and (c) in the next cycle. A general multi-task software simulation method characterized in that which of a plurality of model tasks is to be executed is determined for each cycle by a predetermined algorithm, and multi-task processing is simulated. 2. In the step (a), at least one of the plurality of model tasks executes a first or second waiting process and the first or second waiting process based on an input signal value. The general multitask software simulation method according to claim 1, further comprising conditional branch processing. 3. In the step (a), at least one of the plurality of model tasks includes a waiting process and a process of simulatedly outputting a control data signal before or after the waiting process. The general multi-task software simulation method according to claim 1. 4. The step (b) is characterized in that the one cycle time is determined to be 1 / (natural number) of a minimum value of waiting processing times included in the plurality of model tasks. Outline of multi-task software simulation method. 5. In the step (c), for each model task, a thread is created that indicates a temporal change in the execution and suspension states of the model task in the cycle time unit, and the thread is referred to in the predetermined algorithm. 2. The general multitask software simulation method according to claim 1, further comprising: selecting a model task candidate that can be executed in the next cycle, and determining one of the model task candidates as a next cycle execution task. 6. The predetermined algorithm of the step (c) determines the next cycle execution task such that the next cycle execution task is sequentially selected for each cycle from the model task candidates that can be executed in the next cycle. The general multi-task software simulation method according to claim 1, wherein 7. The model tasks in step (a) have priorities as attributes, and the predetermined algorithm of step (c) has the highest priority among the model task candidates that can be executed in the next cycle. A high model task candidate is selected, and when there is one selected model task candidate, it is determined as the next cycle execution task, and when there are a plurality of selected model task candidates, an array in these storage devices is selected. The general multitask software simulation method according to claim 1, wherein the next cycle execution task is determined in order. 8. In the step (a), at least one of the plurality of model tasks is an interrupt process, and in the predetermined algorithm of the step (c), when the interrupt occurs, the interrupt process is executed. The general multi-task software simulation method according to claim 1, wherein the next cycle execution task is determined. 9. A detailed design of multitasking software, comprising: a processor, a storage device coupled to the processor, and a display device coupled to the processor, the storage device including: multi-task software for processing input / output signals in real time. Before, in order to simulate the outline of the timing of the input / output signals of the multi-task software, a plurality of model tasks that represent detailed processing of each task by waiting processing for waiting for the estimated time to pass are stored,
Further, a program for causing the processor to execute the model task in a simulated manner is stored. The program determines one cycle time based on waiting processing time included in the plurality of model tasks, and A general multi-task software simulation device characterized by including a process of simulating a multi-task process by determining which of a plurality of model tasks is to be executed for each cycle by a predetermined algorithm. 10. A program for simulating execution of a model task by a processor, the model task comprising input / output signals of the multitask software before detailed design of the multitask software for real-time processing of input / output signals. The detailed processing of each task is represented by a wait processing for waiting for the estimated time to elapse in order to simulate the outline of the timing of the It is determined based on the waiting processing time included in the task, and which of the plurality of model tasks is to be executed in the next cycle is determined for each cycle by a predetermined algorithm to simulate the multitask processing. An outline multi-task software simulation program.