KR20140030660A - Performance analysis method and performance analysis apparatus for at least one execution unit - Google Patents

Abstract

The present invention relates to a performance analysis method and performance analysis apparatus for at least one execution unit. The performance analysis method comprises the steps of: (a) loading task graph information including dependency between tasks; (b) selecting a task on the task graph, based on a specified priority; (c) calculating an execution time boundary of the selected task using the mapping relationship of the selection task to at least one execution unit, and the dependency between the tasks; and (d) repeating the step (b) and the step (c) for the remaining tasks on the task graph. By using the present invention, performance can be predicted at high speed in consideration of various scheduling types in a variety of embedded systems. [Reference numerals] (AA) A:= Task graph set; (BB) Q:= Order list of tasks aligned in the descending order of priority without breaking the dependency of an ancestor-descendant order of a task graph; (CC) S: Complete queue of a task (Task group in which minimum and maximum values are calculated); (S100) Start; (S200) Read a task graph set(A); (S300) Set Q; (S500) Calculate the execution time boundaries of all tasks; (S600) Execution time of at least one task is changed?; (S700) End

Description

PERFORMANCE ANALYSIS METHOD AND PERFORMANCE ANALYSIS APPARATUS FOR AT LEAST ONE EXECUTION UNIT}

The present invention relates to a performance analysis method and a performance analysis apparatus for one or more execution units. Specifically, each task graph is performed by using a task graph executed in one or more execution units and a mapping relationship between tasks included in the task graph to execution units. A performance analysis method and a performance analysis apparatus for one or more execution units that enable predicting or determining performance of a task graph, such as a maximum response time, at high speed and close to best results.

Embedded systems, such as automobiles, airplanes, consumer electronics, portable devices, etc., have one or more processors for performing a given application and a bus (e.g., CAN bus) for connecting the processors, depending on the application of each device.

Such embedded systems perform specialized functions for each application, and each application needs to be designed according to the response time specified according to the real time of each embedded system. As a result, the software constituting the application needs to be designed to be optimized for the computer architecture of a given embedded system, and if the computer architecture of the embedded system fails to meet the specified response time, it may be equipped with a higher speed processor or a hardware accelerator. Design changes are needed to further include).

To know whether these design changes or application optimizations are tailored to the specified response time, an analysis device or analysis tool to see how the application's software runs within the hardware of the embedded system or whether each application meets the specified response time. This is necessary.

As such an analysis device or analysis tool, a simulation based approach is known. This simulation-based approach allows applications to be run directly on a virtual prototype system that can simulate the actual hardware being measured, so that each application can be tuned for a given response time.

This simulation-based approach requires a lot of time (ie simulation time) to measure the execution time or response time of each application, and does not support various architectures, resulting in inflexibility and the need for various test cases for each application. Unexpected performance results on the virtual prototype's system may occur on the real device because the results are measurable and thus all possible test cases cannot be entered on the virtual prototype's system.

As a result, developers have a tendency to design computer architectures that can perform beyond the performance required by a given application in order to prevent inadvertent performance results and to reduce the incidence of unexpected performance results. There is a tendency to increase development costs or production costs.

An analytical method is known as an alternative to the simulation-based approach, and the analytical method is known as a holistic approach and a compositional approach.

For example, the holistic approach is pessimistic by integrating scheduling for a given application's tasks in a given embedded system and communication within a given embedded system into a single analysis framework. Calculate the Worst Case Response Time of a specific task according to the scenario (K. Tindel and J. Clark, "Holistic Schedulability Analysis of Distributed Hard Real-time Systems", Microprocessing and microprogramming, Vol 40, pp. 117-134, April, 1994 and F. Slomka, J. Zant, and L. Lambert, "Schedulability analysis of heterogeneous systems for performance message sequence chart", Proceedings of the 6th international workshop on Hardware / software codesign, pp. .. 91-95, March, 1998.]

This holistic approach does not take into account the contention of communications resources that are limited or preemptive scheduling, so this holistic approach is universally applicable to embedded systems with various computer architectures in their application. There is a problem that is not applicable.

On the other hand, in some holistic approaches, timed automata (G. Behrmann, A. David, KG Larsen, J. Hakansson, P. Petterson, W. Yi, and M. Hendriks. "UPPAAL 4.0" (See QEST, 2006.) or ILP (integer linear programming) -based model checking techniques are also known, but the complexity of measuring these performances is exponential, which can improve performance for complex applications in real embedded systems. There is a limit to measuring or determining.

As such, the holistic approach has serious problems in terms of scalability and flexibility.

On the other hand, a compositional approach is also known to solve the problem of the holistic approach. This constructive approach is described in SymTA / S (K. Richter, M. Jersak., And R. Ernst, "A formal approach to MpSoC performance verifcation", IEEE Comput., 36 (4), pp. 60-67, Apr. 2003.) and MPA (L. Thiele, E. Wandeler, and S. Chakraborty, "Performance analysis of multiprocessor DSPs: A stream-oriented component model", IEEE Signal Process.Mag., 22 (3) , pp. 38-46, May 2005.].

Although this constructive approach is more scalable than the holistic approach, and can provide its performance results with faster execution time, the constructive approach takes advantage of the dependencies between the execution order of each task. The WCRT (Worst Case Response Time) provided as a result of that performance provides a loose time boundary.

These loose time boundaries also have to be expanded as the given application becomes more complex, eventually leading to design induces over-specified computer architectures, thereby increasing design or production costs. .

Accordingly, there is a need for a performance analysis method and a performance analysis apparatus for one or more execution units, which can be applied to the application of an embedded system by solving various problems derived from the aforementioned conventional approach.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-described problems, and at least one of them enables more accurate performance prediction, such as WCRT of a task or task graph, compared to known holistic approaches and constructive approaches. An object thereof is to provide a performance analysis method and a performance analysis apparatus for an execution unit.

It is also an object of the present invention to provide a performance analysis method and a performance analysis apparatus for one or more execution units, which can provide the performance prediction at a faster rate than the conventional approach for performance analysis. have.

Another object of the present invention is to provide a performance analysis method and a performance analysis apparatus for one or more execution units, which integrate various task scheduling techniques to enable performance prediction on various computer architectures.

It is also an object of the present invention to provide a performance analysis method and a performance analysis apparatus for one or more execution units, which can reduce design and production costs in the design of hardware and software of an embedded system.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, unless further departing from the spirit and scope of the invention as defined by the appended claims. It will be possible.

In order to achieve the above object, a performance analysis method for one or more execution units includes the steps of (a) loading task graph information including dependencies between tasks and (b) Selecting a task; (c) calculating a run time boundary of the selected task using a mapping relationship between one or more execution units of the selected task and the task; and (d) for the remaining tasks in the task graph. repeating steps (b) and (c).

In addition, to achieve the above object, a performance analysis method for one or more execution units includes the steps of (c) determining whether (c-1) the execution time boundary of the selected task can be calculated; and (c -2) inserting the selected task into the wait queue if the runtime boundary cannot be computed and (c-3) if the runtime boundary can be computed, then executing the runtime boundary to the computed completion queue Inserting the selected task.

In addition, to achieve the above object, the performance analysis apparatus for one or more execution units, the task graph loading unit for loading the task graph information including the dependency between the tasks and the task of the task graph based on the specified priority A task execution time calculation unit that calculates an execution time boundary of the selected task using a task graph selection unit to select a mapping relationship between one or more execution units of the selected task and a task; The time calculation unit selects all tasks in the task graph to calculate execution time boundaries.

In addition, in order to achieve the above object, the performance analysis apparatus for one or more execution units, the task graph loading unit, each of the execution cycle determination unit for determining the execution cycle of the plurality of task graphs and the execution cycle of each of the plurality of task graphs And a task graph instance generating unit for generating a task graph instance of each of the plurality of task graphs, wherein the number of instances of the generated task graph is determined using a least common multiple between execution cycles of the plurality of task graphs. The task execution time calculation unit calculates an execution time boundary for the task selected from the generated instance of the task graph.

The performance analysis method and the performance analysis device for one or more execution units as described above are more accurate than the conventional holistic approach and the constitutional approach known to enable more accurate performance prediction such as WCRT of a task or task graph. It works.

In addition, the performance analysis method and the performance analysis device for the one or more execution units as described above, it is effective to provide the performance prediction at a faster rate than the conventional approach for performance analysis.

In addition, the performance analysis method and the performance analysis apparatus for one or more execution units as described above have an effect of integrating various task scheduling techniques to enable performance prediction on various computer architectures.

In addition, the performance analysis method and the performance analysis device for one or more execution units as described above, it is effective to reduce the design cost and production cost in the design of hardware and software of the embedded system.

The effects obtained by the present invention are not limited to the above-mentioned effects, and other effects not mentioned can be clearly understood by those skilled in the art from the following description will be.

1 is a diagram illustrating an exemplary hardware block diagram of a performance analysis apparatus.
2 is an example illustrating a mapping relationship between an exemplary task graph and an execution unit graph and a task graph and an execution unit graph.
3 is a diagram illustrating a basic control flow for performance analysis of a task graph.
4 is a diagram illustrating a detailed control flow of step S500 of FIG. 3.
FIG. 5 is a diagram illustrating a detailed control flow for step S550 of FIG. 4.
6 is a diagram illustrating a scheduling result according to the application of the Min-Max analysis method to the example of FIG. 2.
FIG. 7 is a diagram illustrating a mapping relationship between another exemplary task graph and execution units for applying the Min-Max analysis method and execution time boundaries of each task calculated according to the mapping relationship.
FIG. 8 is a diagram illustrating a mapping relationship between task graphs and execution units including impossible exclusions and thus execution time boundaries that change according to repetition.
FIG. 9 is a diagram illustrating a mapping relationship between calculated task graphs and execution units and calculated execution time boundaries for tight calculation of minimum start time and minimum end time.
10 is a diagram illustrating an exemplary functional block diagram of a performance analysis apparatus according to the present invention.

The above and other objects, features and advantages of the present invention will become more apparent from the following detailed description of the present invention when taken in conjunction with the accompanying drawings, in which: It can be easily carried out. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail. Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

The present invention relates to a holistic analysis method and apparatus therefor for analyzing the performance of execution of a given task (graph) for one or more execution units. This analysis method is referred to as "Min-Max analysis method" below. This Min-Max analysis method provides more accurate or tight time bounds than the constitutional approach, and the complexity reaches polynomial complexity, such as WCRT in a task or task graph in a short time. Allows you to provide performance prediction results.

First, referring to a hardware block diagram (FIG. 1) of a performance analyzing apparatus according to the present invention, the performance analyzing apparatus includes a memory 101, a mass storage medium 103, an input interface 105, an output interface 107, and communication. And a system bus / control bus 113 for transmitting and receiving data or control signals between the interface 109 and the processor 111 and each hardware block.

The performance analyzing apparatus may be configured to omit some of the blocks in the hardware block diagram according to the function or use of the performance analyzing apparatus. For example, the performance analysis device may be, for example, a personal PC or the like for an individual user (or developer), in which case the communication interface 109 may be omitted. Alternatively, the performance analysis device may be a remote server connected to multiple users and capable of processing performance analysis requests of multiple users, in which case the input interface 105 and output interface 107 may be omitted as necessary. .

Looking briefly at each hardware block of the performance analysis device, memory 101 is a volatile memory, such as SDRAM. The memory 101 can load the information of the task graph stored in the mass storage medium 103 or received through the communication interface 109 under the control of the processor 111, or the mass storage medium 103 or the like. A program for performing the stored Min-Max analysis method is loaded under the control of the processor 111 so that the program can be executed.

The mass storage medium 103 is a storage medium that can store a large number of data, such as a hard disk or a USB memory. The mass storage medium 103 stores various programs to be used for the processor 111 and stores various data.

For example, the mass storage medium 103 may include a program for the Min-Max analysis method performed by the processor 111, one or more task graphs to be analyzed by the Min-Max analysis method, and the target hardware on which the task graph is performed. It contains an execution unit graph that represents the connection of execution units, such as processors or buses, that can perform tasks in the architecture or target hardware architecture.

Here, the task graph or execution unit graph does not necessarily need to be expressed in the form of an image, but is represented by a data structure that can express a connection or dependency relationship between tasks or execution units included in the task graph or execution unit graph. It can be represented with an image.

Of course, this task graph and execution unit graph may be received through the communication interface 109 according to the application of the performance analysis apparatus.

Here, the task graph and the execution unit graph will be described with examples.

Referring to FIG. 2, referring to the mapping relationship between a task graph, an execution unit graph, and a task of the task graph and one or more execution units on the execution unit graph, the task graph represents a task model performed on the execution unit graph.

This task graph is represented by an acyclic graph, for example, and is represented by each task graph T = {V, E}. Where V represents a set of tasks included in the task graph, and E represents a set of edges representing dependencies between tasks.

(

의 후행 또는 자손 태스크, 이하에서는 후행 태스크 및 자손 태스크란 용어를 혼용하여 사용한다.)은

(

의 선행 또는 선조 태스크, 이하에서는 선행 태스크 및 선조 태스크란 용어를 혼용하여 사용한다.)의 수행이 완료된 후에 수행될 수 있다. 또한 각 태스크 그래프는 선행하는 태스크에 의존하지 않는 소스 태스크(

,

)를 포함하며 이러한 소스 태스크는 (p,j,d)의 튜플에 의한 제어하에 시간의 흐름에 따라 실행될 수 있는 태스크이다. 여기서 p는 소스 태스크 또는 이 소스 태스크를 포함하는 태스크 그래프의 실행 주기(period)를 나타내고, j는 소스 태스크 또는 태스크 그래프가 맵핑된 실행 유닛으로 릴리스 되는 시간의 오차 범위, d는 이 태스크 그래프가 다수의 태스크 그래프 인스턴스(instance)로 생성될 때에 태스크 그래프 인스턴스의 릴리스 되는 시간 간의 최소 시간 거리를 나타낸다.For example, an edge included in a set of E may be represented as a pair of two tasks, and this dependency defines the order of execution of the two tasks. For example, as can be seen in Figure 2 (a)

(

Trailing or descendant tasks in, hereinafter, the terms trailing task and descendant task are used interchangeably.)

(

In the preceding or ancestor task, hereinafter, the terms preceding task and ancestor task are used interchangeably. In addition, each task graph is a source task (depending on the preceding task).

,

This source task is a task that can be executed over time under the control of a tuple of (p, j, d). Where p represents the period of execution of the source task or task graph that contains this source task, j is the margin of error in the time that the source task or task graph is released to the mapped execution unit, d is the number of this task graph Represents the minimum time distance between when a task graph instance is released when it is created by a task graph instance.

는 주기 100을 가지고 주기적으로 수행되고 태스크 그래프

도 동일한 주기를 가지고 주기적으로 수행된다.As can be seen in Figure 2 (b), the task graph

Is performed periodically with cycle 100 and the task graph

Also performed periodically with the same period.

On the other hand, Fig. 2 (c) shows the execution unit graph, each task, the priority given to each execution unit, the scheduling scheme, and the mapping relationship. This information includes the minimum and maximum execution times of each task, the priority between each task, and the scheduling scheme of each execution unit. This information comes from the developer or the user. The scheduling method may include a preemptive type ( P ) and a non-preemptive type ( N ).

,

를 수행하도록 맵핑되고 PE0는 선점형(P) 스케쥴링 방식을 가지고, PE1은 버스로서 태스크 간의 데이터를 전달하거나 수신하기 위한 통신 태스크인

,

를 맵핑하여 비선점형(N) 스케쥴링 방식을 가질 수 있다.Each of the execution units PE0 and PE1 may execute one or more tasks, and these execution units represent hardware resources such as a target processor on which a task graph is actually executed or a bus for connecting the processor and the processor. For example, in FIG. 2C, PE0 is

,

PE0 has a preemptive ( P ) scheduling scheme, and PE1 is a communication task for transferring or receiving data between tasks as a bus.

,

By mapping to have a non-preemptive ( N ) scheduling scheme.

Here, the task is a basic unit mapped to the execution unit of the execution unit graph, as can be seen in FIG. These tasks are given a minimum execution time and a maximum execution time. This minimum (maximum) execution time is the time taken by the minimum (maximum) when this task is executed in the mapped target execution unit, which is given in hours or the number of instructions or the equivalent of this instruction in hours. .

And the task mapped to the communication network (PE1 in Fig. 2) of the execution unit graph is considered as the communication task.

These task graphs and execution unit graphs and mappings and various information are given by the developer (user), and the information is used to execute each task or execution time of each task graph when each task in the task graph is mapped to a specific execution unit and executed. Allows performance analysis methods or performance analysis devices to make performance predictions such as boundaries (eg WCRT).

Such task graphs, execution unit graphs, and mapping information may be represented in the form of data structures that can be recognized by the program, and the information expressed in the form of such data structures enables the processor 111 to predict or analyze performance. See below for more details.

The input interface 105 is an interface for receiving control input from a developer or the like and includes a control port for receiving control input from, for example, a mouse or a keyboard.

The output interface 107 is an interface for outputting a result performed under the control of a developer, and includes a control port for outputting an image or sound to a display or a speaker, for example.

The communication interface 109 is an interface for connecting to the Internet or an intranet via a wired LAN or a wireless LAN. The communication interface 109 may receive information such as a graph or a control command from a remote developer or the like, and perform performance analysis or prediction using the graph information given according to the control command.

The processor 111 includes one or more processing cores that control each block of the performance analysis apparatus, for example, by loading a program through the memory 101 and controlling each hardware block according to the loaded program.

The processor 111 loads various programs stored in the mass storage medium 103, for example, and performs performance of each task graph according to control from a developer received through the input interface 105 or the communication interface 109, or the like. The predicted result is output through the communication interface 109 or the output interface 107.

The Min-Max analysis method performed on the processor 111 will be described in more detail with reference to the following drawings.

The system bus / control bus 113 may be, for example, a parallel bus or a serial bus that connects each hardware block to transmit and receive data or control signals from the hardware blocks.

First, prior to entering the Min-Max analysis method in detail, the problems and basic terms to be solved in the present invention are summarized.

Input: Set of Task Graphs and Execution Units Mapping Information between Graphs and Tasks and Execution Units

에 대해서 WCRT,

의 결정.
Problem: each task graph

About WCRT,

Decision.

Of course, the present invention is not limited to the calculation of the Worst Case Response Time (WCRT) of each task graph, and the WCRT of each task derived from or generated during the determination of the WCRT of this task graph. The results of other performance analysis or prediction, such as the range of response time, etc. can also be self-explanatory according to the idea of the present invention.

Mark Type ^* Explanation

v

Release time

v

Release time for

v

Minimum start time for

v

Maximum start time of

v

Start time

v

Minimum end time of

v

Max end time of

v

End time of

c

(Lower) execution time of lower bound

c

Upper bound execution (execute) time

c

Set of predecessor tasks

c

Set of successor tasks

c

Priority of

,

,

c Source task

Period, maximum jitter, and minimum delay information between instances

v

Offset after initial time for task starting first in

c

Of execution units that are mapped

v

Set of tasks that can preempt

v

Set of tasks that cannot preempt

v

Set of tasks that were scheduled earlier P c Set of execution units using preemptive scheduling N c Set of execution units using non-preemptive scheduling scheme

* Type v represents the variable to be calculated and type c represents a parameter given by the developer or the like.

For each variable, briefly, the release time represents the time when the task became available to run on a given (mapped) execution unit, the start time represents the time when it was scheduled to start execution in the mapped execution unit, and the end time is Represents the time when the execution is completed in the mapped execution unit. These release times, start times and end times are expressed in the form of minimum and maximum times. These minimum and maximum release times, start time, and end time can be calculated for each task. Such release time, start time, and end time can be included in execution time boundaries for analyzing the performance of each task, from which WCRT, etc. of the task graph can be calculated.

In order to solve the problem according to the present invention, Figure 3 shows the basic control flow for performance analysis of the task graph. This control flow is performed by the processor 111 of the performance analysis device and may be preferably configured using a program in software.

First, it starts according to the performance analysis request by the developer (S100), and ends according to the performance analysis end request (S700).

,

)과 같은 주어진 파라미터 등을 태스크 그래프 정보로서 태스크 그래프로부터 추출하거나 혹은 주어진 자료 구조를 통해 결정하여 결정된 태스크 그래프 정보를 예를 들어 메모리(101)에 임시로 저장한다. In step S200, a set of task graphs for which performance analysis is requested from a developer or the like is read (loaded and loaded into the memory 101). In this step S200, the dependency (edge) between the tasks in each task graph and the execution (execution) time of each task (from the set of task graphs including one or more task graphs)

,

A given parameter such as e.g.) may be extracted from the task graph as task graph information or determined through a given data structure to temporarily store the determined task graph information in the memory 101, for example.

The set of task graphs includes one or more task graphs that can be performed simultaneously on a given execution unit graph. And the tasks in this task graph can be executed on the same execution unit or can be executed on different execution units. Accordingly, a task mapped to a specific execution unit may be excluded during execution by the priority of each task according to a scheduling technique (for example, preemptive) by another task while performing the task. In addition, each task graph may have a different execution period. Accordingly, one task graph may be affected by performance over several periods of another task graph according to differences in execution cycles of other task graphs.

In consideration of this problem, step S200 determines each of the execution cycles of the plurality of task graphs in the set of task graphs. The task graph may be configured to generate an instance of the task graph according to the execution cycle of each task graph, and calculate an execution time boundary for the task of the generated instance.

The number of instances of each task graph generated here may be determined by (minimum common multiple of all task graph execution cycles) / (execution cycle of each task graph).

는 태스크 그래프

에 대하여 생성된 인스턴스의 세트를 나타낸다. In Table 1,

Task graph

Represents a set of instances created for.

에 포함되는 인스턴스)에 대해서 각각의 실행 시간 경계가 계산될 수 있도록 한다. 여기서 이 인스턴스는 원 태스크 그래프로부터 추출되거나 획득된 태스크 그래프 정보를 공유하고 이에 따라 태스크의 실행 유닛에 대한 맵핑 정보나 우선 순위 정보 등을 공유하고, 다만 각 인스턴스는 실행 주기에 의해서 각 인스턴스의 실행 순서가 결정되고 실행 시기가 한정될 수 있다.Therefore, in a later step, an instance of this task graph (

Each runtime boundary can be calculated for each instance included in. Here, this instance shares the task graph information extracted or obtained from the original task graph and accordingly, the mapping information or priority information of the execution unit of the task, etc. Can be determined and the timing of execution can be limited.

By using the least common multiple, multiple task graphs can accurately predict the change in execution time boundaries according to the scheduling of each task graph to another task graph even though the execution cycles are different.

In operation S200, information related to an execution unit (eg, a mapping relationship between a task and the execution unit, a connection relationship between the execution unit, etc.) may be further loaded and stored in the memory 101.

Subsequently, in step S300, all the tasks of the task graph set are set and stored according to the priority between the tasks and further reflect the topology order, and the ordered list 260 (Sorted list, Q ) is stored, and in step S400, the execution time boundary Initializes a completion queue 250 ( S ) for storing the computed task.

Looking at an exemplary generation (setting) process of the order list 260 here, one or more tasks mapped to each execution unit in the execution unit graph are sorted according to a specified priority, for example in descending order, for each execution unit. Create a sort list.

는 에지에 의해서

의 자손 태스크이고

의 선조 태스크이다. 단, 도 2에서는 다른 실행 유닛에 맵핑되어 재정렬이 일어나지 않는다), 이 에지에 의한 의존 관계가 반영되도록 재정렬된다. Then, one or more tasks arranged in order of priority for each execution unit are rearranged by further considering the topology. In other words, if there is a dependency by edge between one or more tasks mapped to a particular execution unit (for example, two tasks mapped to one execution unit have a predecessor task and a descendant) successor) in the relationship of the task,

By the edge

Is a descendant of

The ancestor task of. However, in FIG. 2, it is mapped to another execution unit so that realignment does not occur), and the reordering is reflected to reflect the dependency relationship by this edge.

Accordingly, the order of tasks in sorting in descending order may be changed, for example, a task having a higher priority in one execution unit may have a lower priority in accordance with a dependency by edge. The sort list may be rearranged so as to be located after the ancestor task of the higher priority task. This allows the dependencies by topology to be prioritized over the specified priority among tasks mapped to the same execution unit.

Here, the sorting is performed in order of priority, and the rearrangement is performed according to the topology, that is, the dependency of edges. However, the order of sorting may be reversed.

The rearranged tasks for each execution unit are then incorporated into the order list 260. As an example of how to integrate, extract tasks sequentially from the sorted list of reordered tasks for each execution unit, one by one in the reordering order (for example, if the execution unit is PE0, PE1, the best from the reorder list of PE0). And then extract the best task from the reorder list of PE1 and then repeat it) and store the extracted task in the order list 260.

The order list 260 configured as described above is set in consideration of not only the priority but also the order by topology.

Subsequently, in step S500, execution time boundaries are calculated for all tasks included in the order list 260 Q. This step S500 consists of one or more nested loops and will be described in detail with reference to FIGS. 4 and 5.

Here, the execution time boundary is configured to include one or more time information among the minimum start time minS, the maximum start time maxS, the minimum end time minF, and the maximum end time maxF of each task. Accordingly, one or more time information changed according to scheduling of other tasks can be obtained for each task, and performance analysis or prediction of a task or a task graph including the task can be performed in consideration of the effect of the scheduling therefrom. .

In step S600, it is determined whether the execution time boundary of at least one task among all the tasks is changed, and if the execution time boundary of one or more tasks is changed, the process proceeds to step S400 to reflect the changed execution time boundary again. The execution time boundary for the task is calculated, otherwise the performance analysis result for each task graph, for example, WCRT, is calculated and transferred to step S700.

This step S600 monitors the change in the execution time boundary and, if it is changed, changes the value of the execution time boundary of another task again using the changed execution time boundary so that the correct execution time boundary can be converged.

This performance analysis result can be generated for each task graph, from which the worst response time of each task graph can be seen as to whether the task graph has the desired response time on a given execution unit graph.

4 is a diagram illustrating a detailed control flow of step S500 of FIG. 3.

According to the entry of step S500 of FIG. 3, in step S510 of FIG. 4, the waiting queue 240 ( W ) and the variable n for the number of repetitions are initialized. This wait queue 240 is not yet computed for the execution time boundary of the task that attempted the calculation according to the high priority and topology order in the order list 260 (due to edges, etc.) on the task graph of this task. It is a queue to temporarily store this task when the execution time boundary is not calculated. The wait queue 240 is revisited as the execution time boundary of another task is calculated, so that the execution time boundary can be calculated again for each task stored in the wait queue 240.

In operation S520, the task having the highest priority (order) is selected from the ordered list 260 ( Q ) according to the priority and topology order specified for each task.

Subsequently, in step S530, the execution time boundary of the selected task is calculated by using the mapping relationship of the selected task to the execution unit graph and the dependency relation according to the edge on the task graph.

The calculation of the execution time boundary made by this step S530 will be described later in detail.

In step S530, if the execution time boundary of the selected task cannot be calculated, the process shifts to step S560, and if it can be calculated, the process shifts to step S540.

In step S540, the selected task is inserted into the completion queue 250, and in step S550 it is determined whether the execution time boundary can be recalculated by the selected task for the task stored in the waiting queue 240 again. This step S550 will be described again with reference to FIG. 5.

If the execution time boundary cannot be calculated, the task selected in step S560 is inserted into the waiting queue 240 ( W ), and then the variable n for the number of iterations is incremented.

Then, in step S580 and step S590, it is determined whether to repeat the step of FIG. 4 using the variable (n, etc.), and according to the determination in each step, repeating step S520 or less for the remaining tasks or performing step S510 or less. Repeat again.

FIG. 5 is a diagram illustrating a detailed control flow for step S550 of FIG. 4. According to FIG. 5, in step S551, the variable k and the variable n for determining the number of iterations of the loop are initialized. This variable k represents the total number of tasks inserted into the waiting queue 240.

In operation S552, one task is extracted from the waiting queue 240, and in operation S553, an execution time boundary is calculated.

When the calculation of the execution time boundary is made in step S553, the process proceeds to step S554, and the extracted task is stored in the completion queue 250, otherwise, the process proceeds to step S555 again and wait queue 240 again ( W ). Variable n is incremented (S556).

After that, it is determined whether the termination condition is satisfied in step S557, and the process returns to step S552 or terminates according to the determination.

으로 한정된다. As can be seen from FIG. 3 to FIG. 5, the Min-Max analysis method according to the present invention enables the execution time boundary of each task to be determined and the execution time boundary is determined according to the topology order with high priority. Loss is decided sequentially. The execution time boundary of each of these tasks is determined by the loops of FIGS. 3 to 5, and the time complexity by the Min-Max analysis method is

It is limited to.

This time complexity is limited to the number of tasks and does not depend on the number of execution unit graphs or the scheduling method of execution units, so that performance analysis can be performed at a faster speed than conventional performance analysis methods. It also allows you to provide the results of that performance analysis within the foreseeable time (ie with polynomial time complexity).

4 to 5, step S530 and step S553 calculate an execution time boundary for one selected task. Such step S530 and step S553 are calculated according to the dependency relation along the edge between the task graph and the mapping relation to the execution unit of the task graph. And each execution unit may have a scheduling scheme such as preemptive or non preemptive, and this scheduling scheme is also reflected in the calculation of the execution time boundary.

Hereinafter, a description will be given using a formula for calculating the execution time boundary of the selected task reflecting various conditions. Applying these equations, the minimum start time, maximum start time, minimum end time and / or maximum end time for each task are calculated in an analytical manner.

Of course, such minimum start time, maximum start time, minimum end time and / or maximum end time should be calculated from a conservative point of view, but it is necessary to be able to be calculated as close as possible to the time information that can be calculated in practice. In this regard, the equations are modified and the equations changed according to the modifications are expressed.

Each task on the task graph can be released (performed) after the preceding (or ancestor) task of this task is completed. Thus, by examining the topology of the task graph, the minimum and maximum release time can be determined accordingly.

에 대해서는 최소, 최대 릴리스 시간은, 아래 수학식 1 및 2에 의해서 결정될 수 있고 예를 들어 아무런 선행 태스크가 없는 소스 태스크는 태스크 그래프에 대해서 주어지는 오프셋과 이 태스크 그래프 또는 소스 태스크에 대해서 주어지는 지터(예를 들어 시작의 변화 범위)에 의해서 최소, 최대 릴리스 시간이 결정되어 질 수 있다. For example, source task

For the minimum and maximum release times, the minimum and maximum release times can be determined by Equations 1 and 2 below, for example, a source task without any predecessor task has an offset given for the task graph and jitter given for this task graph or source task (eg For example, the minimum and maximum release times can be determined by the starting range.

And the minimum, maximum release time for a task with a dependency, such as an edge in the task graph,

As can be seen from Equations 1 to 4, each task is classified into a task having a source task and a preceding task, so that the source task can be released to the mapped execution unit using the offset and jitter of the task. The release time can be calculated, while other tasks can use the minimum and / or maximum end time of the preceding task to calculate the minimum and maximum release time.

This minimum and maximum release time is determined using the dependencies of the task graph, and the minimum or maximum completion time of the preceding task allows the user to know how long each task can be released in the mapped execution unit.

Using the equations (1) through (4), the minimum start time and the maximum start time, which are boundary times that can start execution in the mapped execution unit of each task, can be calculated using the following equations (5) through (6). have.

와

는 태스크 그래프의 다른 태스크들의 실행 유닛에서의 실행을 고려하여 태스크

가 맵핑된 실행 유닛(PE)이 이용가능한 상태가 되는 최소 시간과 최대 시간을 나타낸다. 이 실행 유닛은 태스크

가 릴리스 될 때 다른 태스크를 수행할 수 있으므로, 계산하고자 하는 태스크

는 맵핑된 실행 유닛에서 현재 실행되고 있는 태스크의 수행이 완료될 때까지 기다릴 필요가 있다. 이러한 기다림은 실행 유닛의 스케쥴링 방식에 따라 달라질 수 있다. 예를 들어 선점형 스케쥴링에서는 현재 수행되는 태스크가 더 높은 우선 순위를 가지고 있다면 기다릴 필요가 있다. 반면에 비-선점형 스케쥴링 방식에서는 이미 스케쥴링되어 수행되고 있는 현재의 태스크의 우선 순위에 상관없이 기다려야 한다. here

Wow

The task takes into account the execution in the execution unit of other tasks in the task graph.

Represents the minimum time and the maximum time for which the mapped execution unit PE becomes available. This execution unit is a task

You can perform other tasks when the

Needs to wait until the execution of the task currently being executed in the mapped execution unit is completed. This wait may vary depending on the scheduling scheme of the execution units. In preemptive scheduling, for example, you need to wait if the task currently being performed has a higher priority. On the other hand, non-preemptive scheduling requires waiting regardless of the priority of the current task that is already scheduled and performed.

와

는 스케쥴링 방식에 따라 상이한 형식으로 정규화된다. Accordingly

Wow

Is normalized to a different format according to the scheduling scheme.

For preemptive scheduling,

= {

|

=

,

>

, 그리고

<=

},

= {

|

=

,

>

, And

<=

},

For non preemptive scheduling,

= {

|

=

그리고 ((

>

, 그리고

<=

) 또는 (

<

그리고

<=

<

))},

= {

|

=

And ((

>

, And

<=

) or (

<

And

<=

<

))},

는 태스크가 시간 t 이후에 맵핑된 실행 유닛에 이 태스크를 수행 가능한 상황이 되는 시간을 나타내고 이

는 릴리스 가능한 시점 이후에 태스크의 시작을 지연시킬 수 있는 다른 태스크의 상태를 고려하여 반영되며, 수학식 5에 따른

는

로부터 시작하여 계산하여 이

가 수렴될 때까지 계산된다. Looking at the meaning of this equation 7,

Represents the time when the task becomes available to perform this task in the mapped execution unit after time t

Is reflected in consideration of the status of other tasks that may delay the start of the task after the release possible point,

The

Starting from

Until is converged.

는 이미 스케쥴된 태스크 들 중에서 태스크

의 최소 시작 시간을 지연할 수 있도록 하는 조건에 해당하는 태스크를 나타내고, 수학식 7에서 알 수 있는 바와 같이, 태스크

와 같은 실행 유닛에 맵핑되어 있고, 태스크

보다 우선 순위가 높고,

의 최대 시작 시간이 태스크

의 최소 시작 시간보다 작거나 같은 것에 해당하는 태스크에 의해서 태스크

의 최소 시작 시간이 계산된다. And of equation (7)

Is one of the tasks already scheduled

A task corresponding to a condition for delaying the minimum start time of the task is represented, and as can be seen from Equation 7,

Mapped to an execution unit, such as

Higher priority,

Maximum start time of the task

Task by a task less than or equal to the minimum start time of

The minimum start time is calculated.

도

<=

<

조건을 만족한 다면 해당 태스크

의 최소 시작 시간을 지연시킬 수 있는 태스크의 집합에 해당함을 알 수 있다. The non-preemptive scheduling method has a lower priority in addition to the preceding conditions.

Degree

<=

<

If the condition is met, the task

You can see that this corresponds to a set of tasks that can delay the minimum start time of.

가 맵핑된 특정 실행 유닛에서 수행될 수 있는 최소 시작 시간을 나타내고, 이에 따라 이 최소 시작 시간에 대하여 영향을 줄 수 있는 다른 태스크의 실행 시간 경계의 정보를 반영하여 계산된다. The condition of Equation 7 is a task

Represents the minimum start time that can be performed in the mapped specific execution unit, and is thus calculated by reflecting information of execution time boundaries of other tasks that may affect this minimum start time.

Here, for the preemptive scheduling method,

= {

|

=

,

>

그리고

<=

},

= {

|

=

,

>

And

<=

},

For non preemptive scheduling,

= {

|

=

그리고 ((

>

, 그리고

<=

) 또는 ( <

그리고

<=

<

))},

= {

|

=

And ((

>

, And

<=

) or ( <

And

<=

<

))},

의 최대 시작 시간의 계산에서

에 속하는 태스크의 최대 종료 시간 값들을 기준으로 하여

에서의 태스크의 최대 종료 시간 값이

의 최대 시작 시간을 가지는 것을 의미한다. 그리고

의

는 이 주어진 태스크

의 최대 시작 시간을 지연할 수 있는 조건에 해당하는 태스크이다. Equation 8 is given a task

In the calculation of the maximum start time of

Based on the maximum end time values of the tasks belonging to

The maximum end time value for the task at

Means having a maximum start time. And

of

Is given the task

This task corresponds to a condition that can delay the maximum start time.

의 최대 시작 시간을 지연시킬 수 있다. 이러한 태스크

는 이미 스케쥴링된 태스크 중에서

의 최대 시작 시간을 지연시킬 수 있도록 하는 태스크이다.As can be seen from Equation 8 above, a task that meets different conditions in a preemptive scheduling scheme and a non-preemptive scheduling scheme is a given task.

Can delay the maximum start time. These tasks

Of the tasks already scheduled

This task allows you to delay the maximum start time of.

As such, using Equations 5 to 8, the start time of each task may be calculated. This start time can also be changed in accordance with a change in the start time or end time of the task that affects the start time of each task. In addition, a task may have a dependency that has not yet been computed for its predecessor by its dependencies, in which case it is inserted into a wait queue ( W ), whereby the execution boundary for that predecessor is not calculated. Is recalculated.

Meanwhile, an end time of each task on each task graph may be calculated using Equations 9 to 12 below.

와

는 이 태스크

가 더 높은 우선 순위를 가진 태스크에 의해서 태스크

의 맵핑된 실행 유닛에서 수행 시작 후 수행 동안에 스케쥴링이 배제(preemption)되는 시간 기간의 최소 및 최대 시간을 나타낸다. 물론 비선점형 스케쥴링 방식에서는 이러한 변수가 0으로 설정되고, 선점형 스케쥴링 방식에서는, 이

와

가 다음과 같은 수학식으로 결정된다. here,

Wow

Is this task

By a task with a higher priority

Represents a minimum and maximum time of a time period during which scheduling is excluded during execution after the start of execution in a mapped execution unit of. Of course, in non-preemptive scheduling, this variable is set to 0. In preemptive scheduling,

Wow

Is determined by the following equation.

= {

|

=

,

>

그리고

<=

<=

<=

}here

= {

|

=

,

>

And

<=

<=

<=

}

는 태스크

가 실행 동안에 동일한 실행 유닛에 스케쥴링되는 우선 순위가 높은 모든 태스크를 포함한다. This task set

Is a task

Contains all high priority tasks that are scheduled in the same execution unit during execution.

= {

|

=

,

>

,

<=

그리고

<=

}here

= {

|

=

,

>

,

<=

And

<=

}

는 태스크

가 실행 동안에 주어진 조건에 부합하고 스케쥴링되는 우선 순위가 높은 모든 태스크를 포함한다.
This task set

Is a task

Contains all of the high priority tasks that meet the given conditions and are scheduled during execution.

Using Equations 1 to 12, an execution time boundary of a task may be calculated. This execution time boundary includes the minimum start time, maximum start time, minimum end time and maximum end time of each task when a given plurality of task graphs are performed on the architecture of a given execution unit graph.

As can be seen from Equations 1 to 12, the calculation of the execution time boundary in the Min-Max analysis method is calculated using the dependencies between tasks according to the topology between the tasks together with the priority. Thus, even if a higher priority task first computes a runtime boundary, if the runtime boundary for the preceding task is not computed, the task is written to the wait queue 240 and subsequently After the calculation of the execution time boundary of the task is completed, the execution time boundary for the task of the wait queue 240 may be calculated again.

In order to apply the Min-Max analysis method, as shown in FIGS. 3 to 5, the calculation is performed using at least three loops, and when the value of the execution time boundary of one or more tasks is changed again, the current change is performed. By using the execution time boundary values again, the calculation is made until there is no change in the execution time value of all tasks.

Of course, if the execution time value for at least one task is not calculated before the calculation of all execution time is completed in this process, it may mean that the task graph that cannot be scheduled is included.

And the execution time boundaries calculated by Equations 1 to 12 guarantee minimum accuracy. This accuracy can be proved.

Using the equations 1 to 12 and FIGS. 3 to 5, when an execution time boundary of each task is determined, the WCRT of each task graph may be calculated as in Equation 13.

Of course, Equation 13 calculates the execution time boundary for the task conservatively as a result of response time larger than the actual WCRT value.

Of course, if the task graph includes one or more task graph instances, the WCRT for each task graph instance may be calculated, and the maximum WCRT among the calculated WCRTs may be determined as the WCRT of the task graph.

)은 0으로 설정되어 소스 태스크는 시간 유닛 0에서 릴리스된다. 도 6의 스케쥴링 결과를 간단히 살펴보면, 가장 우선 순위가 높은 소스 태스크인

가 스케쥴링되어

와

는 0으로 결정된다. 그리고

의 실행 시간이 10에서 20 시간 유닛이므로

는 10으로

는 20으로 결정된다. 유사하게 다음으로 우선 순위가 높은 다른 소스 태스크인

에 대하여 계산하여 최소 및 최대 시작 시간이 0으로 결정되고 최소 및 최대 종료 시간이 각각 20으로 결정된다. FIG. 6 illustrates scheduling results of applying the Min-Max analysis method of FIGS. 3 to 5 with respect to the example of FIG. 2. In Figure 2, there are two task graphs, each task graph has a period of 100 units of time, and each task graph has a delay offset (

) Is set to 0 so that the source task is released in time unit 0. Referring briefly to the scheduling result of Figure 6, the highest priority source task

Is scheduled

Wow

Is determined to be zero. And

Since the execution time of 10 to 20 time units

To 10

Is determined to be 20. Similarly, the next higher priority source task

The minimum and maximum start times are determined to be zero and the minimum and maximum end times are determined to be 20, respectively.

은

로부터의 의존 관계(에지)가 있으므로 이 태스크는

의 종료 후에 시작할 수 있고 이에 따라 이 태스크의 최소 및 최대 시작 시간은 각각 10과 20으로 계산된다. 그리고 이 태스크

이 맵핑되는 PE1은 비선점형 스케쥴링 정책을 이용하므로, 이 태스크의 최소 및 최대 종료 시간은 다른 우선 순위가 높은 태스크의 선점에 따른 영향 없이 15와 40으로 각각 결정된다. Next highest priority task

silver

Since there are dependencies (edges) from

You can start after the end of, so the minimum and maximum start times for this task are calculated to be 10 and 20, respectively. And this task

Since this mapped PE1 uses a non-preemptive scheduling policy, the minimum and maximum end times of this task are determined to be 15 and 40, respectively, without affecting the preemption of other higher priority tasks.

의 스케쥴링 시에는 이전에 스케쥴링된 태스크

이 고려되어야 한다. 이에 따라

의 최소 시작 시간은

의 최소 종료 시간이

의 최소 릴리스 시간보다 작기에 토폴로지 의존 관계에 따라 결정되어 20으로 계산된다. 그리고 최대 시작 시간은

에 의해 야기되는 지연을 고려하여 결정되고 이에 따라 40으로 계산되고 그리고 최소 종료 시간은 30으로 최대 종료 시간은 60으로 결정된다. 유사하게 나머지

와

에 대해서도 실행 시간 경계가 계산된다. 이러한 모든 태스크의 실행 시간 경계로부터 태스크 그래프

의 WCRT는 60으로, 그리고 태스크 그래프

의 WCRT는 80으로 결정된다. And tasks

Previously scheduled tasks when scheduling

This should be considered. Accordingly

Minimum start time of

Has a minimum end time of

It is determined according to the topology dependence on the smaller than the minimum release time of 20 is calculated. And the maximum start time

It is determined taking into account the delay caused by and calculated accordingly and the minimum end time is 30 and the maximum end time is 60. Similarly rest

Wow

The run time boundary is also calculated for. Task graph from the run time boundary of all these tasks

WCRT is 60, and the task graph

The WCRT is determined to be 80.

As described above, the Min-Max analysis method according to the present invention allows accurate and fast calculation in consideration of the priority of each task and the dependency between the tasks.

2 to 5, allowing the execution time boundary of the Min-Max analysis method to be more tightly calculated to approximate the ideal result may provide a number of developmental benefits. Hereinafter, some application techniques through the analysis of the task graph to bring the execution time boundary of the Min-Max analysis method according to Equations 1 to 12 to the ideal execution time boundary according to FIGS. Let's see.

FIG. 7 is a diagram illustrating a mapping relationship between another exemplary task graph and execution units for applying the Min-Max analysis method and execution time boundaries of each task calculated according to the mapping relationship.

의 WCRT는

의 최대 종료 시간에 따라 45로 결정된다. 여기서 실제의

의 WCRT는 35로 계산될 수 있다. 이러한 과(over) 예측의 이유는

이 태스크 그래프

의 그래프 체인 상에서의

의 최대 종료 시간과

의 최대 시작 시간의 계산에 2회에 걸쳐서 영향을 미쳤기 때문이다. 즉

에 의해 야기되는 배제가

의 WCRT의 계산에서 복수회에 걸쳐서 고려되었기 때문이다. As can be seen in Figure 7 (b)

WCRT

Is determined by 45 depending on the maximum end time. Where real

The WCRT can be calculated as 35. The reason for this over prediction is

This task graph

On the graph chain

With the maximum end time of

This is because two times influenced the calculation of the maximum start time of. In other words

Exclusion caused by

Is considered multiple times in the calculation of the WCRT.

As a result, it is necessary to ensure that one task reflects the impact of exclusion only once in the calculation of the execution time boundary of another task, thus checking the exclusion history in the calculation of the maximum start time and the maximum end time. Needs to be.

의 최대 종료 시간과 최대 시작 시간에 영향을 미치는 태스크의 세트인 프리엠트(preemptor) 세트

를 정의한다. 이

는 초기에는 빈 세트로 정의되고, 이후 수학식 4에 따라 최대 릴리스 시간을 계산할 때, 태스크 그래프 상에서 의존 관계(에지)에 따른 선행 태스크의 프리엠트 세트를 물려 받아 태스크의 프리엠트 세트를, 아래 수학식 14에 따라 계산한다.Accordingly task

Set of preemptors, which is a set of tasks that affects the maximum end time and the maximum start time

. this

Is initially defined as an empty set, and then, when calculating the maximum release time according to Equation 4, the pre-set set of the task is inherited by inheriting the pre-set set of the preceding task according to the dependency (edge) on the task graph. Calculate according to equation 14.

는 태스크

의 최대 릴리스 시간을 결정하는 데 이용되는 선행하는 태스크이다. 그리고 수학식 8과 수학식 12에 따라 태스크의 스케쥴링 지연(delay)를 계산할 때 이

에 속하지 않는 태스크만을 고려하도록 수정하면 된다.here

Is a task

The preceding task is used to determine the maximum release time of the. When calculating the scheduling delay of the task according to Equations 8 and 12,

You only need to modify it to consider only tasks that do not belong.

= {

|

=

,

>

,

<=

그리고

}로 수정되고, 수학식 12의

= {

|

=

,

>

,

<=

,

<=

그리고

}로 수정되어 태스크 그래프 상에서 의존 관계에 따라 의존하는 선행 태스크에서 이미 반영한 다른 태스크를 이후의 태스크에서는 더 이상 실행 시간 경계의 계산에 반영되지 않도록 하여, 더욱더 타이트한 실행 시간 경계를 계산할 수 있도록 한다.Accordingly, Equation 8

= {

|

=

,

>

,

<=

And

}, And in Equation 12

= {

|

=

,

>

,

<=

,

<=

And

}, So that other tasks already reflected in the preceding task that depend on the dependency on the task graph are no longer reflected in the calculation of execution time boundaries in later tasks, so that a tighter execution time boundary can be calculated.

,

와

의 체인)에서 단 1회만 실행 시간 경계의 계산에 반영되도록 한다. That is, these other tasks may be chained together by an edge (dependency relationship) on the task graph that includes the target task for which the current maximum start time and / or maximum end time are to be calculated (eg, in FIG. 7).

,

Wow

Only one time in the chain of.

This same change can also be applied to the non-preemptive scheduling case.

Although managing this set of premets for all tasks, the calculation of loose time boundaries may also occur.

가

에 속하고 의 최소 시작 시간이

의 최대 종료 시간보다 작기에 태스크

는 태스크

의 최대 종료 시간의 계산에 영향을 미친다. 그리고 태스크

는 복수의 배제를 회피하기 위해서 태스크

의 프리엠트 세트에 삽입되고 의존 관계에 따라

의 프리엠트 세트를 상속받는(inherited) 태스크

의 프리엠트 세트 역시

을 포함한다. 이에 따라

의 최대 시작 시간과 최대 종료 시간은 이에 따라 변경된다. 그리고 3번째 반복에서

의 최대 시작 시간과 최대 종료 시간은 또한 변경된다. 그리고 태스크 그래프의 WCRT는

에 연결된

에 의해 100으로 예측된다.For example, referring to FIG. 8, the priority of the three tasks does not follow the order of the topology. In this example, the execution time boundary of each task as shown in FIG. 8 (b) is calculated by the first iteration of step S500 of FIG. 3, and in Equation 12 in the second iteration of step S500.

end

Belong to Has a minimum start time of

Task less than the maximum end time of

Is a task

Affects the calculation of the maximum end time. And tasks

To avoid multiple exclusions

Is inserted into the prem set of

Tasks inheriting a preempt set from

Prem set

. Accordingly

The maximum start time and the maximum end time of are changed accordingly. And in the third iteration

The maximum start time and maximum end time are also changed. And the WCRT in the task graph

Connected to

Is predicted by 100.

에 대한 태스크

에 의한 일어날 수 없는 배제에 기인한다. 이러한 불가능한 배제의 가능성을 제거하기 위해서, 각 태스크에 대해서 또 다른 태스크 세트인 제외(exclusion) 세트

를 정의한다. In this example, the cause of over-estimation is the predecessor task.

Task for

Due to exclusion that cannot occur by. To eliminate this possibility of exclusion, an exclusion set, which is another set of tasks for each task

.

는 태스크

과

의 제외 세트에 포함된다. 물론 이러한 제외 세트는 Min-Max 분석이 이루어지기 전에 우선 순위와 태스크 그래프의 토폴로지를 검색 혹은 분석하여 먼저 결정될 수 있다.The exclusion set of these tasks is the high priority task upon which the task depends on the topology order. Task in the example of FIG. 8

Is a task

and

Included in the exclusion set. Of course, this exclusion set can be determined first by searching or analyzing the priority and topology of the task graph before the Min-Max analysis is performed.

This exclusion set allows the calculation of tighter (strict) execution time boundaries by allowing the higher priority tasks to be mapped to the same execution unit, taking into account the topology order, and excluding them from the calculation of the execution time boundaries of those tasks. To lose.

와 수학식 12의

는 아래와 같이 수정된다.
Given this set of exclusions,

And of Equation 12

Is modified as follows.

= {

|

=

,

>

,

<=

,

그리고

},

= {

|

=

,

>

,

<=

,

And

},

= {

|

=

,

>

,

<=

,

<=

,

그리고

}

= {

|

=

,

>

,

<=

,

<=

,

And

}

This excludes tasks that cause scheduling exclusion that cannot actually occur even if they have a higher priority than the task that is currently calculating the execution time, but instead of calculating the maximum start time and maximum end time, instead of lower priority than the current task. Only tasks with are reflected in the calculation of maximum start time and maximum end time.

In the example of FIG. 7 and FIG. 8, the application technique for calculating the tight execution time boundary in calculating the maximum start time and the maximum end time has been described.

In addition to the applied calculation technique of the maximum start time and the maximum end time, a technique applicable to the minimum start time and the minimum end time will be described with reference to FIG. 9.

The technique applied to the minimum start time and the minimum end time also affects the calculation of the maximum start time and the maximum end time so that the maximum start time and the maximum end time can also provide tight results.

As can be seen in FIG. 9, five tasks are assigned to one execution unit following the preemptive scheduling technique. The execution time boundaries calculated for the tasks in this task graph are shown in FIG.

와

의 최대 시작 시간이 태스크

의 최소 릴리스 시간보다 크기에

와

는 태스크

의

에 포함되지 않는다. 이에 따라

의 최소 시작 시간은 태스크

와

에 따라 야기되는 스케쥴링 지연을 고려하지 않아 과소 평가(under estimated) 된다. 이에 따라 태스크

의 최대 종료 시간은 또한 과 평가(over estimated)된다. Task in this example

Wow

Maximum start time of the task

In size less than the minimum release time

Wow

Is a task

of

Not included in Accordingly

Minimum start time for a task

Wow

It is underestimated without taking into account the scheduling delay caused by. Accordingly task

The maximum end time of is also over estimated.

에 앞서 스케쥴링되는 태스크를 포함하는

을 구성한다. 이 예에서 태스크

와

는 태스크

보다 먼저 스케쥴링되기에

의

에 포함된다. 그리고 수학식 7은 아래의 수학식 15로 변경되어 최소 시작 시간이 선 스케쥴된 태스크의 최소 종료 시간보다 작지 않은 경우로 수정된다.To avoid this underestimation problem, the task in all cases

Which contains tasks that are scheduled prior to

Configure Task in this example

Wow

Is a task

Is scheduled ahead of time

of

. Equation (7) is changed to Equation (15) below to modify the case where the minimum start time is not smaller than the minimum end time of the pre-scheduled task.

를 고려하는 경우").The application of Equation 15 enables the calculation of the tighter minimum start time and the minimum end time, and also allows the calculation of the maximum start time and the maximum end time to be made even tighter (see FIG. 9 ").

If you consider ").

In FIGS. 7 to 9, the Min-Max analysis method according to FIGS. 3 to 5 can calculate the execution time boundary more accurately in consideration of the type or form of dependency relationship and also priority of the task graph. We looked at the technique. These techniques allow for larger task graph sizes (eg, the number of tasks in the task graph, etc.) to provide more effective results of boundary calculations.

10 is a functional block diagram of a performance analysis device for one or more execution units.

This functional block diagram is implemented on the hardware block diagram of FIG. 1 and is implemented, for example, in the form of a program that utilizes the memory 101 and is executed on the processor 111.

In FIG. 10, a brief review will be made within a range that does not overlap with FIGS. 2 to 5.

According to FIG. 10, the functional block diagram of the performance analysis apparatus includes a task graph loading unit 210, a task graph selecting unit 220, a task execution time calculating unit 230, and an iteration control unit 270, and are also in standby. A queue 240, a completion queue 250, and an order list 260 are included.

The wait queue 240 here stores a task whose calculation of execution time of this task has not been completed, for example because of a topology dependence, even if the task is first selected with a high priority, and the completion queue 250 ) Stores the task for which the execution time boundary has been calculated. This waiting queue 240 and completion queue 250 may be configured on memory 101, for example.

Referring to each of the functional blocks, the task graph loading unit 210 may include a task graph indicating a dependency relationship between tasks according to a control input of a developer (or user) received or input through the input interface 105 or the communication interface 109. This task graph loads various parameter information related to the task graph and the execution unit graph, such as the execution unit graph to which the task graph is mapped and the priority of each task included in the task graph, the scheduling technique related to the execution unit, and the like. And / or to mass storage medium 103.

Such parameter information includes, for example, various parameters described in Table 1. Using these parameters, the execution time boundary of a task included in a task graph or a task graph can be calculated.

To this end, the task graph loading unit 210 includes an execution cycle determiner 211 and a task graph instance generator 213. The execution cycle determination unit 211 determines the execution cycle included in the parameters of the loaded task graph, and the task graph instance generator 213 determines each task graph according to the least common multiple of the execution cycles of each of the plurality of task graphs. Create an instance of. The created instance is then used to calculate runtime boundaries.

The number of instances of each task graph generated here is calculated to have a common execution cycle by the least common multiple determined from the execution cycles of the plurality of task graphs.

In addition, the task graph instance generator 213 may further generate an instance of the task graph when the WCRT of each task graph is larger than the execution period of each task graph. For example, tasks in the next cycle can affect the execution of tasks in the previous cycle.

This task graph instance generating unit 213 not only generates each instance of each task graph, but also sequentially generates instances of the task graph, calculates execution time boundaries for the instances, and generates new instances later. It can also be configured repeatedly. This implementation method is a matter of selection, and according to the hardware structure to which the performance analyzer is applied or the structure of a program, one of several selection methods can be selected.

The task graph selecting unit 220 controls the tasks included in the plurality of task graphs under the control of the repeating control unit 270 in the order list 260 (Q) ordered according to the priority order of the tasks and the topology order. The one with the highest order position is selected, and the subsequent selection selects the task with the next highest order position.

The order list 260 (Q) may order the tasks initially under the control of the repeating control unit 270, and then select the tasks selected according to the task selection by the task graph selector 220 on the order list 260. Can be configured to delete. Of course, when resuming the repetition of the calculation can be ordered again in the order between the initial tasks.

Here, the order of tasks ordered in the order list 260 is ordered according to priority, for example, and further considering the topology order of the task graph.

Here, the same task graph may be generated by several instances, in which case, the order of tasks included in the instance is ordered on the order list 260 according to the generation order of each instance.

The task execution time calculation unit 230 executes the execution time using the mapping relationship with the execution unit loaded by the task graph loading unit 210 and the dependency relationship between the tasks with respect to the task selected by the task graph selection unit 220. Calculate the boundary.

The task execution time calculation unit 230 and the task graph selection unit 220 repeatedly calculate and repeatedly select all the tasks of all the task graphs loaded under the control of the repetition control unit 270 in order.

The task execution time calculator 230 includes an execution time boundary determiner 231 that determines whether an execution time boundary of the selected task may be calculated. The execution time boundary determination unit 231 calculates each execution time boundary using Equations 1 to 15 above, and if the execution time boundary for the task to which the selected task is preceded by the topology order is not calculated, The currently selected runtime boundary may not be calculated.

In this case, the selected task whose execution time boundary is not calculated is inserted into the standby queue 240 by using the standby queue insertion unit 233 further included in the task execution time calculator 230.

On the other hand, if the execution time boundary can be calculated, the selected task is inserted into the completion queue 250 using the completion queue insertion unit 235.

In addition, the iteration control unit 270 controls each function block so that execution time boundaries of all tasks can be completed, for example, controls the iteration of the Min-Max analysis method according to FIGS. 3 to 5 and sets each variable. Initialize

Accordingly, the iteration control unit 270 initializes the order list 260 based on the information of the task graph loaded by the task graph loading unit 210, and executes the execution time in the execution time boundary determination unit 231. Monitor if the boundary is calculated and control the calculation of the run time boundary for the task inserted into the wait queue 240 as a result, and change the run time boundary of one or more tasks according to the overall iteration for all tasks. Then decide whether to repeat again (see Figure 3). The control flow of the repeating control unit 270 will be easily understood with reference to FIGS. 3 to 5.

By using the performance analysis apparatus according to the functional block diagram of FIG. 10, it is possible to provide more tight performance analysis results at a high speed.

By using the performance analysis method and the performance analysis device according to the present invention, it has been determined to provide at least 30% more tight performance analysis prediction results than the conventionally known constitutional approaches, and performance analysis close to the analytical approach. It can be seen that the prediction results are obtained. Of course, the conventional analytical approach is known to have a problem that the actual execution time increases exponentially as the number of tasks in the task graph increases.

And the application of various scheduling techniques provides a lot of usefulness. For example, most computer architectures include one or more processors and a bus to connect between them. Such processors typically include preemptive or non-preemptive scheduling techniques, depending on the operating system (OS). Buses, on the other hand, generally use non-preemptive scheduling techniques using hardware (hardwire-type FIFO) for high speed, automated transmission. Of course, the bus itself can also be applied to preemptive scheduling based on specific logic embedded in the bus.

와

)로 모델링할 수 있도록 한다. And according to the invention the bus itself can also be modeled as a single execution unit (e.g. PE1 in FIG. 2) and the communication task on the bus is also a task (e.g. in FIG.

Wow

To be modeled.

The application of these various modeling and scheduling techniques provides the developer with the flexibility of embedded system design as well as the rapid prediction of performance analysis results that can shorten the development period.

Such a performance analysis method according to the present invention can be recorded and distributed on a computer-readable recording medium in the form of a program. Such a recording medium may be, for example, a USB memory or a mass storage medium capable of recording a program such as a CD or a DVD.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. The present invention is not limited to the drawings.

101: memory 103: mass storage media
105: input interface 107: output interface
109: communication interface 111: processor
113: system bus / control bus
210: task graph loading unit
211: execution cycle determination unit 213: task graph instance generation unit
220: task graph selector
230: task execution time calculation unit
231: execution time boundary determination unit 233: standby queue insertion unit
235: completion queue insertion unit
240: waiting queue 250: completion queue
260: order list 270: repeat control

Claims (12)

A method of performance analysis of one or more execution units,
(a) loading task graph information including dependency relationships between tasks;
(b) selecting a task in the task graph based on the specified priority;
(c) calculating an execution time boundary of the selected task using a dependency relationship between a task and a mapping relationship in the one or more execution units of the selected task; And
(d) repeating steps (b) and (c) for the remaining tasks in the task graph;
Performance analysis method. The method of claim 1,
The step (c)
(c-1) determining whether an execution time boundary of the selected task can be calculated;
(c-2) inserting the selected task into a wait queue if the execution time boundary cannot be calculated; And
(c-3) if the execution time boundary can be calculated, inserting the selected task into the completion queue for which the execution time boundary has been calculated;
Performance analysis method. 3. The method of claim 2,
The step (c)
(c-4) if the execution time boundary can be calculated, calculating an execution time boundary for a task in a wait queue using the calculated execution time boundary of the selected task;
Performance analysis method. 3. The method of claim 2,
(e) determining whether an execution time boundary of one or more of the tasks in the task graph has changed; And
(f) repeating steps (b) to (d) using the changed execution time boundary when the execution time boundary of the one or more tasks has changed;
Performance analysis method. The method of claim 1,
The step (a)
(a-1) determining execution cycles of the plurality of task graphs; And
(a-2) generating a task graph instance of each of the plurality of task graphs according to an execution period of each of the plurality of task graphs;
The number of instances of the generated task graph is determined using the least common multiple between execution periods of the plurality of task graphs, and step (c) calculates execution time boundaries for tasks selected from the instances of the generated task graph. doing,
Performance analysis method. 3. The method of claim 2,
The execution time boundary includes at least one time information of a minimum start time, a maximum start time, a maximum start time, a minimum finish time, and a maximum finish time.
In step (c-1), the execution time boundary of the selected task is calculated based on the scheduling type of the execution unit to which the selected task is mapped and the priority and execution time boundary of other tasks included in the task graph.
Performance analysis method. The method according to claim 6,
The other task included in a task graph different from the selected task is determined by comparing the execution time boundary of the other task with the execution time boundary of the selected task.
The other task is selected to be reflected only once in the calculation of the execution time boundary for tasks on the chain of dependencies in the task graph containing the selected task,
Performance analysis method. The method according to claim 6,
In the step (c-1), the execution time boundary of the selected task is calculated by determining the other task according to the topology order in the task graph of the selected task and the priority of the task.
The other task that is determined is a task having a lower priority than the task selected in the topology order,
Performance analysis method. A performance analysis device for one or more execution units,
A task graph loading unit that loads task graph information including dependency relationships between tasks;
A task graph selecting unit that selects a task of the task graph based on a specified priority; And
And a task execution time calculation unit configured to calculate an execution time boundary of the selected task using a mapping relationship between the at least one execution unit of the selected task and the task.
The task graph selecting unit and the task execution time calculating unit selects all tasks of the task graph to calculate execution time boundaries.
Performance analysis device. 10. The method of claim 9,
The task execution time calculation unit,
An execution time boundary determining unit that determines whether an execution time boundary of the selected task may be calculated;
A standby queue insertion unit inserting the selected task into a standby queue when the execution time boundary cannot be calculated; And
If the execution time boundary can be calculated, Completion queue insertion unit for inserting the selected task in the completion queue, the execution time boundary has been completed; including;
Performance analysis device. 10. The method of claim 9,
The task graph loading unit,
An execution cycle determination unit for determining execution cycles of the plurality of task graphs, respectively; And
A task graph instance generating unit generating a task graph instance of each of the plurality of task graphs according to an execution cycle of each of the plurality of task graphs,
The number of instances of the generated task graph is determined using a least common multiple between execution cycles of a plurality of task graphs, and the task execution time calculator calculates an execution time boundary for a task selected from the instances of the generated task graph. doing,
Performance analysis device. A computer-readable recording medium having recorded thereon a program for performing a method for performance analysis of one or more execution units according to claim 1.

Images