Computer-implemented method, parallel compiler and parallel compiling device for generating a parallelized program and vehicle on-board device

Abstract

Computer-implemented method for generating a parallelized program for a multiprocessor system mounted in a vehicle on-board device (400), comprising: Dividing a sequential program into multiple macro-tasks according to a predetermined procedure using a parallelization compiler running on a computer, which controls an embedded system, wherein the sequential program is executed by a single-processor system; Generating, using the compiler, a macroflow graph based on an analysis of control dependencies and data dependencies between the macro tasks; Specify, by means of the compiler, based on the control dependency specified in the macroflow graph, at least one pair consisting of a start-end task and a finish-end task, wherein the start-end task is a macro task having a conditional branch, and the finish-end task is a macro task that is the first macro task executed common to all of several series of macro tasks executed sequentially from the start-end task as a starting point, wherein the specification includes: analyzing all possible execution paths from the start-end task and identifying the first macro task executed common to all of the series of macro tasks as the finish-end task; Merge, using the compiler, (i) the initiating end task, (ii) the termination end task, and (iii) all macro tasks that are executed after the start-up end-task and before the finish-up end-task into a block task to hide the conditional branch of the start-up end-task in the block task, wherein the block task is designed such that, from the perspective of tasks outside the block task, the conditional branch in the start-up end-task is hidden from tasks outside the block task, and the merging is performed in such a way as to eliminate control dependencies between block tasks, thereby enabling static scheduling; Extracting, by means of the compiler, based on the data dependencies between the macro-tasks, including the block-tasks after fusion, from parallel-executable macro-tasks that can be executed in parallel by multiple processor units included in the multiprocessor system mounted in the vehicle on-board device (400), wherein the block-tasks have no control dependencies among themselves after fusion and the extraction is performed based on data dependencies between the block-tasks and remaining macro-tasks, so that static scheduling between the block-tasks is possible; Execution, using the compiler, a static schedule that assigns the parallel-executable macro tasks to the processor units, thereby executing the parallel-executable macro tasks in parallel by the multiple processor units; and Generating, by means of the compiler, a parallelized program to be executed by the multiprocessor system mounted in the vehicle on-board device (400), based on a result of the static scheduling.

Description

[0001] The present invention relates to a computer-implemented method for generating a parallelized program, a parallelization compiler for generating a parallelized program, a parallelization compiler device for generating a parallelized program, and an on-board vehicle device on which a multiprocessor system is mounted. The method, the parallelization compiler, and the parallelization compiler device generate a parallelized program for a multiprocessor system from a sequential program for an on-board vehicle device for an embedded system. The multiprocessor system is mounted on the on-board device, and the sequential program is executed in parallel by a single-processor system.

[0002] To develop a next-generation vehicle that is safer, more comfortable, cheaper and more energy-efficient, it is important to improve and integrate (i) a real-time control system such as engine control and (ii) an information system such as a presentation of information required for human detection, ambient vehicle detection and driving, and the output of music, video images or the like.

[0003] Upgrading a processor is crucial for implementing improvements and integration of the control and information systems. For example, improving the engine control system, which is essential for developing a safer, more comfortable, and fuel-efficient vehicle, may inevitably lead to increased computing loads due to improved control algorithms, the implementation of new control functions, and similar changes. A processor upgrade for real-time control implementations may therefore be necessary.

[0004] The applicants of the invention discovered the following: Improving the operating frequency of a processor, as is conventionally done, can be difficult because energy consumption can increase proportionally to the cube of the frequency. Therefore, high-speed multi-core processors can become more widespread. A key feature of a multi-core processor is the integration of several processor cores with low operating frequencies on a single chip. These multiple processor cores operate in parallel at a low frequency and low voltage to reduce energy consumption. This allows for both processing acceleration and low-voltage operation.

[0005] For a multi-core processor to execute a task faster than a single-core processor, the processing of a sequential program must be shared between the single-core processor and each processing step. This allocation is then distributed among the processor cores in a way that minimizes communication between them. Traditionally, a person performs the parallelization of the sequential program. However, this task can be very difficult and time-consuming, leading to numerous problems such as increased development costs and reliability issues with the parallelized program.

[0006] Non-patent document 1 discloses a method for increasing throughput in which functions are distributed to each processor core in a board device that has a multi-core processor.

[0007] However, to fully utilize the processing capacity of each processor core, it may be necessary to extract a process that can be executed in parallel and allocate it to other processor cores. Therefore, simply distributing a function across all processor cores only improves throughput; latency cannot be reduced. Processing cannot be executed at high speed.

[0008] Non-Patent Literature 1: K. Seo, J. Yoon, J. Kim, T. Chung, K. Yi, and N. Chang, “Coordinated implementation and processing of a unified chassis control algorithm with multi-central-processing unit,” JAUTO1346 IMechE, 2009, Vol.224 Part D.

[0009] DE 690 29 956 T2 discloses a program parallelization device for generating an executable object program from a source program that can be processed in parallel by several processors of a multiprocessor. The device includes a communication mechanism to enable communication between the processors and a synchronization mechanism to enable parallel processing through coordination. Object programs suitable for parallel processing by the multiprocessor system are generated from different source programs, regardless of the type of processor.

[0010] Furthermore, the publication by Akimasa Yoshida et al.: “A Data-Localization Scheme using Task-Fusion for Macro-Dataflow Computation. In: Proceedings of the IEEE Pacific Rim Conference on Communications, Computers, and Signal Processing, 1995” and the publication by Wen-mei W. Hwu et al.: “Inline Function Expansion for Compiling C Programs. In PLDI '89 Proceedings of the ACM SIGPLAN 1989 conference on Programming language design and implementation, 1989. pp. 246-257” concern the generation of parallelized programs.

[0011] It is an object of the present invention to provide a method for generating a parallelized program with a compiler, a parallelization compiler, a parallelization compiler device, and a vehicle on-board device, wherein a parallelization program or the like for an embedded system for an on-board device is reliable, operates at high speed, and results in a reduced development period and reduced costs. This object is achieved by a method with the features of claim 1, a parallelization compiler with the features of claim 4, a parallelization compiler device with the features of claim 5, and a vehicle on-board device with the features of claim 6. The dependent claims are directed to advantageous embodiments of the invention.

[0012] According to the invention, it is possible to automatically generate a reliable, high-speed parallelized program from the sequential program for the embedded system of the on-board device. Additionally, generating a parallelized program for the embedded system of the on-board device reduces development time and costs.

[0013] The foregoing and further tasks, features and advantages of the present invention will become more apparent from the following detailed description in conjunction with the drawings.

[0014] In the drawings: Fig. Figure 1 is a block diagram illustrating a configuration of an automatic parallelization compiler; Fig. Figure 2 is a drawing illustrating macro-tasks that are determined hierarchically; Fig. Figure 3 is a drawing illustrating an example of a macroflow graph; Fig. Figure 4 is a drawing illustrating an example of a macro-task graph; Fig. Figure 5 is a drawing illustrating a compilation order when a profile automatic address return function is used; Fig. Figure 6 is a flowchart regarding the compilation order when the profile automatic address return function is used; Fig. Figure 7 is a drawing illustrating an example of the macro-task graph; Fig. Figure 8 is a drawing illustrating an example of the macro-task graph shared for global optimization of a cache between dependency loops; Fig. 9 is a drawing that illustrates a situation of assigning split loops to a processor; Fig. Figure 10 is a drawing illustrating a running state of the macro task that is assigned to each processor group in a shortest execution mode; Fig. Figure 11 is a drawing illustrating a running state of the macro task that is assigned to each processor group in a real-time mode; Fig. Figure 12 is a drawing illustrating an example of an automatic parallelization API; Fig. Figure 13 is a block diagram illustrating a multi-core architecture of the present embodiment; Fig. Figure 14 is a drawing illustrating a standard translator for automatic parallelization API and a development environment; Fig. Figure 15 is a drawing illustrating an example of a directive from the automatic parallelization API; Fig. Figure 16 is a drawing illustrating an example of a runtime library function generated by the standard automatic parallelization API translator; Fig. Figure 17 is a block diagram illustrating a configuration of a PC in which an automatic parallelization compiler has been installed; Fig. Figure 18 is a flowchart of automatic parallel processing; Fig. Figure 19 is a drawing illustrating an example of a vehicle control program; Fig. Figure 20 is a drawing illustrating an example of the vehicle control model and a vehicle control program written in the C language, which is automatically generated based on the vehicle control model; Fig. Figure 21 is a drawing illustrating an example of the macroflow graph after an inline extension; Fig. Figure 22 is a drawing illustrating an example of the macro-task graph before inline extension; Fig. Figure 23 is a drawing illustrating an example of the macro-task graph after inline extension; Fig. Figure 24 is a drawing illustrating an example of the vehicle control program in which local variables are used repeatedly; Fig. Figure 25 is a drawing illustrating an example of the macroflow graph before a task fusion; Fig. Figure 26 is a drawing illustrating an example of the macro-task graph before task fusion; Fig. 27 is a drawing illustrating an example of the macroflow graph after task fusion; Fig. Figure 28 is a drawing illustrating an example of the macro-task graph after task fusion; and Fig. Figure 29 is a block diagram illustrating a configuration of an engine control ECU.

[0015] Embodiments of the present invention are explained with reference to the drawings. 1. Automatic Parallelization Compiler

[0016] An automatic parallelization compiler 1 of the present embodiment has a function that generates a parallelized program (parallelization program) for a multiprocessor system for an embedded system from a source program (a sequential program) for a single processor system for an embedded system. 1-1. Design concept of the automatic parallelization compiler 1

[0017] The automatic parallelization compiler 1 of the present embodiment has the following functions: (1) Multigranular parallel processing; (2) Insertion of a static scheduling code at compilation time; (3) Generation of a dynamic scheduling code at the time of execution; (4) Implementation of a hierarchical macro data flow; (5) Parallelism extraction of a split / merge of a macro-task, a loop distribution / loop exchange or the like; (6) Improving data transmission efficiency through data localization; and (7) Energy reduction by the compiler. 1-2. Internal processing of the automatic parallelization compiler

[0018] The automatic parallelization compiler 1 includes three stages: a front-end (FE) 3, a middle path (MP) 5 and a back-end (BE) 7 (see Fig. 1) Each stage is executed independently. Intermediate languages ​​4 and 6 are generated from FE 3 and MP 5, respectively. Code transfer is performed by intermediate languages ​​4 and 6.

[0019] Furthermore, FE 3 performs a lexical and a syntax analysis of the source code 2 of a sequential program and generates the intermediate language 4, which is parsed in MP 5. The intermediate language 4 generated by FE 3 is essentially expressed by a syntax tree with four operands. The intermediate language 4 forms a block and is unstructured.

[0020] MP 5 performs tax dependency analysis, data dependency analysis, optimization, or similar tasks. MP 5 performs coarse-grained (macro data flow, MDF) parallelization, medium-grained (micro-tasking / Doall loop parallelization), and near-fine-grained parallelization.

[0021] The BE 7 reads the parallelized intermediate language 6 generated by the MP 5 and produces actual machine code. BE 7 includes a sub-BE that generates assembly code 8a for the target multi-core architecture, and another sub-BE that generates parallelization FORTRAN code for an OpenMP or C code. Additionally, BE 7 includes another sub-BE that outputs code corresponding to different architectures. For example, BE 7 includes a BE that generates parallelization codes 8b and 8c for memory allocation and data transfer. Memory allocation and data transfer are performed by a parallelization API 9, as described below. 1-3. Parallelism analysis of the automatic parallelization compiler

[0022] The automatic parallelization compiler 1 performs macro data flow processing in which a sequential program is divided into three types of coarse-grained tasks (referred to as a macro task, MT): a base block (BB), a repeat block (RB), and a subroutine block (SB).

[0023] However, the utilization efficiency of a processor for macro data flow processing cannot increase according to the form of a program. Coarse-grained parallelism cannot be sufficiently extracted. Therefore, in automatic parallelization compiler 1, a conventional single-hierarchy macro data flow processing method is extended, and hierarchical macro data flow processing is used. In hierarchical macro data flow processing, macro data flow processing is used hierarchically within the MT. In hierarchical macro data flow processing, the MT is defined hierarchically, as in Fig. 2 is described. In addition, a parallelism between the macro-tasks generated in each hierarchy is analyzed. (Generation of the macroflow graph)

[0024] The automatic parallelization compiler 1 analyzes the control dependencies and data dependencies between the macro-tasks generated in each hierarchy. This analysis result is displayed as a macroflow graph (MFG) (see...). Fig. 3) expressed.

[0025] In Fig. 3 represents a node, a macro-task; a solid line (also referred to as a solid line edge) represents a data dependency; a dotted line (also referred to as a dotted line edge) represents a control dependency; and a small circle within the node represents a conditional branch. Furthermore, the arrowheads of the edges in the MFG are omitted, assuming that one direction of the edges points downwards. The number of each rectangle represents the macro-task number. (Generation of the macro-task graph)

[0026] The MFG represents the tax dependency and data dependency between macro-tasks. The MFG does not represent the parallelism between macro-tasks. To extract the parallelism between macro-tasks, both tax dependency and data dependency must be considered, and an analysis of earliest executable conditions must be performed. The earliest executable conditions represent a condition under which the MT can be executed earliest. The earliest executable condition is derived from the following execution conditions. (1) If an MTi has a data dependency on an MTj, the MTi will not be executed until an execution of the MTj has been completed. (2) If the conditional branch point of MTj is determined, even if the execution of MTj is not complete, MTi, which has the control dependency on MTj, can be executed. Here, symbol “i” and symbol “j” represent positive integers that represent a rank of MT.

[0027] Accordingly, a general form of the earliest executable conditions is described as follows: (the MTj, which has the tax dependency to the MTi, branches off to the MTi) AND (An MTk (0≤k≤|N|) that has the data dependency on the MTi is completed) OR (it is determined that the MTk is not executed). Here, a symbol "k" and a symbol "N" represent positive integers. For example, the earliest executable conditions of MT6 of the MFG in Fig. 3 as described below. ((The MT branches off to the MT3) OR (the MT2 branches off to the MT4)) AND ((the MT3 is completed) OR (the MT1 branches off to form the MT2)).

[0028] When the MFG's control dependency is taken into account, a state in which MT3 is completed includes a state in which MT1 branches off to MT3, and a state in which MT2 branches off to MT4 represents a state in which MT1 branches off to MT2. Therefore, the above conditions can be simplified and represented as follows. ((The MT3 is completed) OR (the MT2 branches off to become the MT4)).

[0029] The earliest executable condition of the macro-task is represented by the macro-task graph (MTG), as shown in Fig. 4 is described.

[0030] A node in the MTG of Fig. 4 represents a macro task, a solid line (also referred to as a solid line edge) represents a data dependency, a dotted line (also referred to as a dotted line edge) represents an extended control dependency, and a small circle in the node represents a conditional branch, similar to the MFG in Fig. There are three. The number of a rectangle represents the number of the macro task. Furthermore, the extended control dependency includes the normal control dependency and a conditional branch. The conditional branch includes a state that confirms that a priority node will not execute, thus satisfying the data dependency and the control dependency in a complex manner.

[0031] A curved bundling of the edges in Fig. 4 represents two different meanings. A solid arc indicates that the edges grouped with the solid arc have an AND relationship. A dotted arc indicates that the edges grouped with the dotted arc have an OR relationship.

[0032] Furthermore, the arrowheads of the edges in the MTG are omitted; it is assumed that one direction of the edges points downwards. Additionally, edges with an arrowhead represent an original control dependency that is inherent in the sequential program and is not created by the extended control dependency. 1-4. Multigranular parallel processing

[0033] In the automatic parallelization compiler 1, in addition to conventional loop parallelization, multigranular parallel processing is implemented, effectively combining the parallel processing of coarse-grained tasks and near-fine-grained parallel processing (see Reference 1). The parallel processing of coarse-grained tasks uses parallelism between the coarse-grained tasks in loops and subroutines. The near-fine-grained parallel processing uses parallelism between statements.

[0034] Reference 1: Hiroki Honda, Masahiko Iwata, and Hironori Kasahara, “Coarse grain parallelism detection scheme of a Fortran program,” Transactions of IEICE DI. Vol. J73-DI No. 12, pp. 951-960, December 1990. (Parallel processing of coarse-grained tasks)

[0035] The automatic parallelization compiler 1 generates the macroflow graph (MFG), which expresses control and data dependencies between MTs such as the BB, RB, and SB, or similar. Additionally, the automatic parallelization compiler 1 expresses the parallelism between MTs derived from the MFG by analyzing the earliest executable conditions as the macrotask graph (MTG) (see Reference 1 and Reference 2).

[0036] Reference 2: Hironori Kasahara, Kento Aida, Akimasa Yoshida, Masami Okamoto, and Hiroki Honda “A Macro-Task Generation Scheme for Fortran Macro-Dataflow Computation,” Transactions of IEICE DI. Vol. J75-DI, No.8, pp. 511-525. August 1992.

[0037] The automatic parallelization compiler 1 assigns the MTs of the MTG to the processor groups (PGs) in which one or more processor elements (PEs) have been grouped. (Medium-granular parallel processing)

[0038] If the MT assigned to the PG can perform parallel processing at a DOALL loop or iteration level, the processor in a processor cluster performs medium-granular parallel processing with respect to the MT. Medium-granular parallel processing represents parallel processing using parallelism between DO loop iterations and is a type of general parallel processing within the multiprocessor. (Almost fine-grained parallel processing)

[0039] Near-fine parallel processing represents the parallel processing of a near-fine-grained task at the statement level. Near-fine parallel processing enables the parallel execution of a single statement without dependencies, thus reducing execution time. Near-fine parallel processing is implemented for a base block, which is executed sequentially without branching, and for the body of a sequential loop. In near-fine parallel processing, the statement is assigned to each of the statements via static scheduling by a compiler. The automatic parallelization compiler generates only one statement, which includes the required synchronization code and data transfer code, as the macro task code for each statement.Near-fine parallel processing is parallel processing using a task with a small granular size, called a statement, and the execution time of the task can often be short. Therefore, to efficiently execute near-fine parallel processing, high-speed data transfer between PEs may be necessary. 1-5. Macro Task Scheduling

[0040] In the parallel processing of coarse-grained tasks, the macro-task generated in each hierarchy is assigned to the relevant program group (PG) and executed. Dynamic and static scheduling methods are used to determine which PG the macro-task is assigned to. The scheduling method is selected based on the shape of the macro-task graph, non-determinism at the execution time of the macro-task graph, or similar criteria. (Dynamic scheduling)

[0041] If there is uncertainty at an execution time, such as in the case of a conditional branch or similar, the macro task is assigned to the PG by dynamic scheduling at that time. Upon completion of the macro task or determination of a branch direction for the macro task, a dynamic scheduling routine operates a macro task execution control table and inspects the earliest executable condition of each macro task.

[0042] If the macro task is executable, it is added to a ready queue. Macro tasks in the ready queue are sorted by priority. The macro task at the top of the ready queue is assigned to the processor cluster in an idle state.

[0043] When dynamic scheduling code is generated, a centralized scheduling system and a distributed scheduling system can be used, depending on the total number of processors and the synchronous overhead of the system. In the centralized scheduling system, one processor is dedicated exclusively to scheduling. In the distributed scheduling system, each processor performs the scheduling function. (Static scheduling)

[0044] Static scheduling is used when the macro-task graph has only one data dependency edge, and in static scheduling, the automatic parallelization compiler 1 determines an assignment of the macro-task to the PG at a compile time.

[0045] Since static scheduling can eliminate scheduling overhead at execution time and minimize data transfer and synchronization overhead, it is possible that static scheduling can be used effectively with respect to tasks that have a fine granular size.

[0046] When static scheduling is executed, an estimated task cost (also referred to as estimated cost) is used in the automatic parallelization compiler 1. Alternatively, the actual cost of the task can be applied by using a profile automatic feedback function of the automatic parallelization compiler 1.

[0047] Fig. 5 and Fig. Figure 6 illustrates a compilation flow when the profile automatic return function is used. When the profile automatic return function is used, in a first phase the sequential program is decomposed into MTs, and a profiler function is inserted for each MT to generate the sequential program (see Figure 6). Fig. 5, and Fig. 601, Fig. 602, Fig. 603). The profiler function measures task execution costs (also referred to as a clock cycle) and a total number of task executions.

[0048] In a second phase, the automatic parallelization compiler 1 receives the output file and the sequential program to generate a parallelization program in which a schedule based on the actual costs is executed (see below). Fig. 6) The sequential program, including the profiler function, is compiled by the sequence compiler (604) to generate binary code (605). When the sequential program, including the profiler function, is executed once on a target machine (606), the profiler function outputs an information file (real cost) of the task execution cost and the number of task executions on the target machine (607). The automatic parallelization compiler performs the parallelism analysis of the sequential program by referencing the output file, which represents the real cost, and generates an OSCAR API parallelization program (608). An automatic parallelization API program is generated (609).The automatic parallelization compiler converts the automatic parallelization API into a runtime library by using a standard automatic parallelization API translator (610) and the runtime library parallelization program is generated (611). 1-6. Data localization

[0049] The automatic parallelization compiler 1 can perform cache optimization across the entire program. The automatic parallelization compiler 1 analyzes the parallelism between loops or similar components, and in a case where the automatic parallelization compiler 1 detects a data dependency between loops MTs 2, 3, 7, 8, 11, and 14, which includes a data localization group located in Fig. The shaded area 7 indicates that the automatic parallelization compiler 1 attempts to perform a global optimization of a cache between loops with data dependencies (see Reference 3: Japanese Patent No. 4177681). Furthermore, the data dependency of the macro-tasks is represented by the data dependency edge, illustrated by a solid line. The number within a rectangle represents the macro-task number.

[0050] In particular, (i) the automatic parallelization compiler 1 examines an array that is accessed by each loop, (ii) divides the macro tasks into four loops 20, 21, 22, 23 (as in Fig. 8 as the MTG after division is described) and (iii) matches the split loops so that a given split loop accesses the identical part of the array, and (iv) assigns the given split loop to a given processor (cf. Fig. 9, which illustrates a schedule for two processors). Accordingly, in the specified split loop, all array data in a cache is reused. The number of a rectangle in Fig. 8 and Fig. 9 represents the number of the macro task.

[0051] This localization procedure concerns the following local storage management procedure and the following data transfer procedures (see Reference 5: UK patent number 2478874). (1) Given a local memory or a distributed shared memory of an arbitrary size, before accessing the local memory or the distributed shared memory using DMA (or DTU) (see Reference 4: Japanese Patent No. 4476267), the local memory or the distributed shared memory is preloaded into a local memory or a distributed shared memory near the processor and reused by a program. DMA represents Direct Memory Access (DMA), and DTU represents a Data Transfer Unit. (2) When a receiver memory is full, and a source processor or the like is informed by a synchronous flag representing that a DTU of a receiver processor has flushed data to a shared memory or the like based on a flush priority, the source processor or the like will automatically transfer data to the receiver memory. (3) If data intended for future use is stored in a memory space and is not used for a period of time, and it is necessary to leave the memory space free, the DTU moves the data to a centralized, shared memory behind a task execution by a CPU and loads it at the time of use. 1-7. Energy reduction or power reduction through automatic parallelization compiler

[0052] According to the automatic parallelization compiler 1, since a scheduling result is analyzed for the processor of the task, frequency / voltage control of each processor and power gating control are performed automatically, making it possible to reduce energy consumption.

[0053] Fig. Figure 10 illustrates a shortest execution time mode in (i) normally scheduled results, (ii) an EV control mode, and (iii) an energy control or power control mode. A set of tasks on a critical path of the task graph must be executed at full speed (corresponding to 100% of the frequency), and MT1, assigned to PG0, and MT3, assigned to PG1, are executed at a maximum frequency.

[0054] However, since MT3 requires a computation result from MT1 after PG1 has executed MT2, PG1 enters a busy-waiting state for synchronization until (i) PG0 stores output data from MT1 in distributed, shared memory within PG1 and (ii) sets the synchronization flag on the distributed, shared memory that indicates the completion of MT1.

[0055] Since the busy-wait state consumes energy, the automatic parallelization compiler 1 can run the MT2 at a low frequency and / or low electrical energy (as described in the EV control) or, if the automatic parallelization compiler 1 has sufficient latency to perform a power interruption, the automatic parallelization compiler 1 temporarily cuts off a power source of the PG1 (as described in the power control).

[0056] Fig. Figure 11 illustrates a real-time execution mode (or a real-time processing mode) with deadline constraints. With a typically scheduled result, PG0 and PG1 wait after processing is complete and consume energy during this waiting period. Therefore, to reduce (or eliminate) energy consumption during the waiting period between processing completion and a deadline, the frequency of MT1 is reduced to one-quarter and the frequency of MT2 is reduced to one-half to operate at lower electrical energy (as described in EV control), or each of the PGs is stopped by clock gating or power gating (as described in energy control).

[0057] In real-time execution mode, the automatic parallelization compiler 1 takes into account a state transition overhead of a power supply and automatically selects a suitable power mode using a heuristic (see reference 6: Japanese patent number 4082706). 1-8. Generation of the parallelization program

[0058] A parallelization program in the automatic parallelization compiler 1 can be generated by an automatic parallelization API in a source-to-source parallelization manner, such as parallelization C or parallelization FORTRAN (see Reference 7: “Optimally Scheduled Advanced Multiprocessor Application Program Interface” WASEDA University, 2008).

[0059] In this case, the automatic parallelization compiler 1 converts a directive part of C or Fortran for each processor into a runtime library call using a standard automatic parallelization API compiler, which is explained below. This allows the parallelization program to be executable on different platforms. After converting to the runtime library call, the automatic parallelization compiler 1 compiles code for each processor using a sequential compiler to generate binary numbers (a binary code or binary file). These binary numbers are concatenated, and the parallelization program can then be executed on a target multiprocessor. 1-9. Automatic Parallelization API

[0060] The automatic parallelization API is designed for a multi-core architecture for information applications, as described below. Accordingly, the automatic parallelization API may perform data memory allocation, data transfer using DMA, power management, group barrier synchronization, and real-time control, all of which are required for a multi-core processor with shared memory.

[0061] An example of the automatic parallelization API is an intermediary between automatic parallelization compiler 1 and a compiler for a multi-core architecture, according to a target. For example, automatic parallelization compiler 1 translates a Fortran 77 program or a sequential C program with a pointer usage restriction or similar limitation into a parallelized Fortran or a parallelized C program to which the automatic parallelization API is automatically added. When the parallelization program is run on a server, it is compiled by the OpenMP compiler to generate execution binaries.

[0062] When the parallelization program is used in a multi-core processor for the embedded system, an exclusive API interpreter generates code including a runtime library, and the generated code is compiled by the sequential compiler so that execution binary numbers can be generated.

[0063] In an example of the automatic parallelization API in Fig. 12 represent “threadprivate”, “distributedshared”, and “onchipshared” memory allocation APIs, and denote a memory location in which a variable is placed.

[0064] Additionally, "parallel subsections" represents the automatic parallelization API, and by arranging two "subsections," two threads are created, making processing executable. Furthermore, "dma transfer" represents a data transfer API, and "dma contiguous parameter" represents an API that enables successive transfers through the DTU. Specifically, in the successive transfer API, the first argument represents a source address, the second argument represents a destination address, the third argument represents a transfer size, the fourth argument represents a flag variable set at the time of transfer completion, and the fifth argument represents a value set for a flag. 1-10. Multi-core architecture and standard translator for automatic parallelization API

[0065] The standard translator for the automatic parallelization API implements portability of the parallelization program generated by the automatic parallelization compiler 1. To enable a generated parallelization program to operate in different architectures, the automatic parallelization compiler 1 converts the generated code into the runtime library using the standard translator for the automatic parallelization API, making it possible to generate the parallelization program that is adapted to the different platforms.

[0066] In the multi-core architecture described below, the automatic parallelization compiler 1 and the automatic parallelization API automatically perform parallelization of a sequential program and power management. However, in order to utilize the memory allocation API and the data transfer API of the automatic parallelization API, an API interpreter must be prepared for each target platform. Developing an API interpreter for each platform can be a significant burden at a time when shortening the development cycle and simplifying development are essential.

[0067] Accordingly, a portion of the processing that exhibits low platform dependency is provided as the standard translator for the automatic parallelization API. This low-platform-dependency portion includes, for example, the part where a directive and a source program are interpreted and modified. Therefore, if the runtime library, including the many embedded multi-core processors, and the relatively simple runtime library are prepared for each platform, it is possible to generate the parallelization program. Consequently, in different multi-core processors, the automatic parallelization compiler 1 can perform parallelization and power management very cost-effectively.

[0068] An example of the multi-core architecture for an information application, a structure of the standard translator for automatic parallelization API, and another example of the standard translator for automatic parallelization API are explained below. 1-11. Multi-core architecture

[0069] A local memory architecture, which is one of the memory architectures in the multi-core processor, differs from a cache architecture. It is possible that the local memory architecture can yield performance improvements through explicit software-based local memory management.

[0070] The multi-core architecture 50 in the present embodiment includes several processor elements (PEs 51, 52, 53) on one chip (cf. Fig. 13) Each of the PEs 51, 52, 53 includes a central processing unit (CPU 51a), a local program memory (LPM 51b), a local data memory (LDM 51c), a distributed shared memory (DSM 51d), and a data transfer unit (DTU 51d). The DTU 51d operates asynchronously with the CPU to perform the data transfer. All PEs on the chip are connected to a centralized shared on-chip memory (OnChipCSM 55) and a centralized shared off-chip memory via an interconnect network 54, such as a bus and a crossbar. 1-12. Structure of the standard translator for automatic parallelization API

[0071] The standard translator 70 for automatic parallelization API in the present embodiment receives a C program 71 (or a FORTRAN program) including the automatic parallelization API as an input and outputs a C program 73 (or a FORTRAN program) including the runtime library function according to a setting of a configuration file 72 (see Fig. 14).

[0072] Configuration file 72 can describe the settings for each architecture. Configuration file 72 can specify (i) a distributed storage management (DSM) address, (ii) a "comment directive" that allows instruction propagation to a native compiler, (iii) a conversion between a data transfer API and a power control API, (iv) a "grouparrier directive" that implements barrier synchronization through arbitrary groups between processor cores, (v) a matching of a module name and module number, or the like.

[0073] The C program 73, including the output runtime library function, is compiled by a compiler 81 of a development environment 80. In this embodiment, the compiler 81 is a C compiler. The compiled files are linked to runtime libraries 82 and 83, resulting in a multi-core execution file 84. The runtime library 82 is, for example, a runtime library header file. The runtime library 83 is, for example, a runtime library file. The development environment 80 is used for each multi-core architecture. 1-13. Conversion to runtime library call

[0074] An automatic parallelization API directive is described by "pragma" in a C program. The automatic parallelization API directive is converted into the runtime library function by the standard automatic parallelization API compiler. (Parallel Execution Directive)

[0075] In the directive of the automatic parallelization API in Fig. The `parallel subsections directive` in step 15 creates four threads. As in a source program from... Fig. As described in section 16, in the standard compiler for automatic parallelization API, a portion of the program that executes as a thread is extracted as functions using `thread_function_000-003`. Among the extracted functions, `thread_function_001-003` is executed as threads by the `oscar_thread_create` function, and `thread_function_000` is executed as a normal function. The `oscar_threadjoin` function performs the joining of threads.

[0076] If the "pthread library" is usable in the platform, it may be possible to implement "oscar_thread_create" and "oscar_threadjoin" by using pthread create and pthread join, respectively. 1-14. Assignment of the memory allocation attribute

[0077] Memory allocation rules, such as "thread private directive" or similar, cannot be implemented by the runtime library. Therefore, it is necessary to convert the memory allocation rule into a description of a memory attribute mapping for a native compiler.

[0078] For example, a description “#pragma oscar onchipshared (var1)” assigns a variable “var1” to a centralized, shared on-chip memory (“onchipshared directive”).

[0079] When gcc is used as the native compiler, the above description is converted to a description like `int_attribute ((subsection ("OSCAR_SHARED"))) var1;`. In the converted description, the variable "var1" is located in the "OSCAR SHARED section" by the attribute description. By arranging the "OSCAR SHARED" section on the centralized, shared on-chip memory through the configuration file of a linker form for an object platform, the variable "var1" is located on the centralized, shared on-chip memory. 2. Parallelization procedure and methods of the vehicle control program

[0080] A feature of a vehicle control program automatically generated by a model-based design is explained, along with a parallelization procedure using the automatic parallelization compiler 1. Specifically, the automatic parallelization compiler 1 is configured from conditional branching and mapping instructions and performs inline extension and renaming of the vehicle control program with fine-tuning, extracting the parallelism. The automatic parallelization compiler 1 performs task fusion to hide conditional branching while maintaining real-time performance and executes static scheduling to reduce overhead. Additionally, the automatic parallelization compiler 1 can utilize the profile automatic return function to execute the static scheduling with real-time cost. 2-1. Operating environment of the automatic parallelization compiler

[0081] The automatic parallelization compiler 1 is provided to a user stored in a storage medium 180 corresponding to an optical disk such as DVD, CD-ROM or the like, a USB storage device, a memory card (registered trademark), a magnetic disk, a semiconductor memory or the like (see Fig. 17). Alternatively, the automatic parallelization compiler 1 can be made available to the user via a network.

[0082] A personal computer (PC) 100, with the automatic parallelization compiler 1 installed, operates as an automatic parallelization compiler. The PC 100 includes a display 110, a hard disk drive (HDD) 120, a CPU 130, a ROM 140, a RAM 150, an input device 160, a read / write head 170, or the like.

[0083] Display 110 shows the user a video image of a video signal received by CPU 130. Input device 160 includes a keyboard, mouse, or similar device. When the user operates input device 160, it outputs a signal according to the operation of CPU 130.

[0084] The read section 170 reads data from memory 180, where the automatic parallelization compiler 1 or similar is stored. RAM 150 is readable and writable volatile memory, ROM 140 is non-volatile read-only memory, and HDD 120 is readable and writable non-volatile memory. A program or similar, which CPU 130 reads and executes, is pre-stored in ROM 140 and HDD 120.

[0085] When the CPU 130 executes the program stored in the ROM 140 or the HDD 120, the RAM 150 functions as a memory region for temporarily storing a program and working data.

[0086] The CPU 130 reads and executes an operating system (OS) from the HDD 120 and runs various programs stored on the HDD 120 as processing within the OS. The CPU 130 receives signal input from the input device 160 when required, outputs the video signal to the display 110, and controls the reading / writing of data to the RAM 150 or the HDD 120.

[0087] The PC 100 has the automatic parallelization compiler 1 installed, which was read from memory 180 via read section 170. The automatic parallelization compiler 1 is one of the applications stored on HDD 120 and executed as a process within the operating system.

[0088] Furthermore, the automatic parallelization compiler is used for developing the parallelization program for the embedded system, for an onboard device, or the like. However, the automatic parallelization compiler is not limited to this type of development and, for example, according to the present disclosure, the automatic parallelization compiler can be used for developing different parallelization programs for embedded systems for different applications, such as an information application or the like, and can be used for developing a parallelization program for applications other than the embedded system. 2-2. Parallelization procedure

[0089] In the present embodiment, the automatic parallelization compiler 1 generates a parallelization program from a vehicle control program (a sequential program), which is automatically generated, for example, by the model-based design using Matlab (registered trademark) and Simulink (registered trademark) from MathWork.

[0090] In particular, by using an embedded encoder, a vehicle control program described in C is automatically generated from a vehicle control model developed using model-based design with Simulink. The automatic parallelization compiler 1 performs the automatic parallelization processing, analyzes the vehicle control program 250, and generates the parallelization program 251 (see...). Fig. 18).

[0091] In automatic parallel processing, the automatic parallelization compiler 1 performs an inline extension of the vehicle control program 250 and renames a local variable within the vehicle control program 250 (S205). The automatic parallelization compiler 1 divides the vehicle control program 250, which has performed the aforementioned processing, into macro tasks and analyzes the data and control dependencies to generate the MFG (S210).

[0092] In S214, the automatic parallelization compiler 1 specifies a start-end task that branches off to another macro task, based on the control dependency specified by the MFG. Additionally, the automatic parallelization compiler 1 specifies a termination end task, which is the first macro task executed among macro tasks that are jointly executed in multiple sequential processing operations. These multiple sequential processing operations share a common start-end task as a starting point and are executed in parallel.

[0093] In S215, the automatic parallelization compiler 1 merges (i) the specified start-up task, (ii) the specified termination end-task, in which the start-up task is a starting point among the processing operations, and (iii) all macro tasks that are executed after the start-up end-task and before the termination end-task, and continues processing at S220. This processing is otherwise referred to as task fusion.

[0094] Furthermore, the MFG loses its control dependency by performing task fusion. To achieve a more granular macro-task size, it may be preferable for the termination end task to be the first macro task executed among the macro tasks that are typically run in multiple sequential processes, as described in S214. These multiple sequential processes share the common initiation end task as their starting point and are executed in parallel. However, specifying the termination end is not limited to this method, and therefore, one of the macro tasks executed second among the multiple macro tasks can be designated as the termination end task.

[0095] At S220, the automatic parallelization compiler 1 analyzes the earliest executable condition of each macro-task based on the MFG after task fusion and generates the MTG. The automatic parallelization compiler 1 then performs static scheduling based on the MTG, assigns the macro-tasks that can be executed in parallel to other PES, and generates the parallelization program 251 (S225).

[0096] Furthermore, so that the parallelization program 251 can operate on different platforms, by using the standard translator for automatic parallelization API, the automatic parallelization compiler 1 can convert a parallelization program to which the automatic parallelization API has been added into the parallelization program in which the runtime library has been implemented.

[0097] The automatic parallelization compiler 1 generates the binary data 252 from the parallelization program 251 (S230). 2-3. Feature of the vehicle control program

[0098] For example, the vehicle control program, which fundamentally executes engine control, includes an initialization function and a prime engine control calculation function that is executed repeatedly.

[0099] The vehicle control program for engine control, exemplified in Fig. As shown in Figure 19, real-time control is achieved by repeatedly executing the "Model_step function". Since the timing in vehicle control is short-term, a cycle period in the "Model_step function" can be at most one microsecond, resulting in a very fine program granularity. In the "Model_step function", all processing operations are calculated according to blocks described by a Simulink model.

[0100] Fig. Figure 20 illustrates vehicle control models 300 and 301 and vehicle control programs 302 and 303 in C language. Vehicle control programs 302 and 303 are automatically generated based on vehicle control models 300 and 301. As shown in Fig. As described in section 20, for example, a "Saturation block" in Model 301 is converted into a program with "if", "if else", and "else". Similarly, the "Switch block" in Model 301 is converted into a program with "if" and "else".

[0101] Since “Model_step function” in the vehicle control program corresponds to a control function in the vehicle control model in the present embodiment, the control function is parallelized and accelerated.

[0102] One of the characteristics of vehicle control programs is that a loop, for which a conventional parallelization compiler performs parallelization as a subject, does not exist (or alternatively: there are very few loops). As in Fig. As described in section 20, in vehicle control, since it is necessary to change processing by sensor information or the like, a design is carried out by liberal use of “a Switch block” and “Saturation block” to include a combination of a conditional branch structure and an assignment instruction.

[0103] Therefore, parallelization for the iteration within the loop, which was conventionally performed, cannot be applied to the vehicle control program. Consequently, in automatic parallelization processing, the automatic parallelization compiler 1 extracts the parallelization at the Simulink model level by using the coarse-grained task parallelization function.

[0104] Since the control function generated by the model-based design lacks parallelism between subroutines, and this parallelism must be extracted precisely, the automatic parallelization compiler 1 performs the inline extension (corresponding to S200 in automatic parallelization processing). An example of the MFG after the inline extension is shown in Fig. 21 described. As in the MFG in Fig. As described in section 21, the sequential program generated by the model-based design does not contain a loop to which parallelization can be applied, as this would result in high processing costs. Instead, there are many base blocks that feature conditional branching, represented by a small circle within a node. Furthermore, in the MFG, a symbol "BB" represents a base block, a symbol "SB" represents a subroutine block, and a symbol "EMT" represents the end of a macro task.

[0105] The processing time of each node is at most approximately a tenth of the clock cycle; the processing is very precise, and it is important to reduce overhead as much as possible. This type of processing is difficult to reduce using conventional methods. 2-4. Restructuring and parallelization procedures of the vehicle tax program

[0106] The automatic parallelization compiler 1 according to the present disclosure extracts the parallelism from the vehicle control program that is automatically generated by the Simulink model and performs a restructuring of a program so that parallelization is carried out in a state where the overhead is lower. (Inline extension of the function (S200 of automatic parallel processing))

[0107] The vehicle control program has fine-grained processing capabilities, making parallelization difficult with its coarse-grained scale. Therefore, the vehicle control program of the present embodiment can effectively utilize parallelism in the subroutines within the control function. The automatic parallelization compiler 1 performs the inline extension of the subroutines in the control function. That is, a description for calling the subroutine is transposed into a description of the processing defined by the subroutine.

[0108] As an example of how effective inline expansion can be, the MTG 320 from Fig. 22. “sb2” and “sb3” have a dependency and parallelism does not exist. However, as described in MTG 321 of “sb2” and MTG 322 of “sb3”, since parallelism exists in internal processing of the subroutines, the parallelism of the subroutines can be used by executing the inline extension of “sb2” and “sb3”. Furthermore, this illustrates Fig. 23 the MTG 323 after executing the inline extension of “sb2” and “sb3.” (Renaming the local variable (S205 of Automatic Parallelization Processing))

[0109] In the vehicle control program, which is automatically generated by the Simulink model, a local variable is repeatedly used in many parts of the processing to reduce the ROM amount. As an example, in the vehicle control program... Fig. 24 a local variable “tmp” is used repeatedly in program sections 330, 331.

[0110] Therefore, if a data dependency is specified in the parallelism analysis, it is possible that the parallelism will not be sufficiently highlighted. Consequently, in S205 of the automatic parallelization processing, the local variable that is used repeatedly is renamed.

[0111] In particular, the automatic parallelization compiler 1 specifies several processing blocks in which a local variable having the same name is used in the control function, and modifies the vehicle control program so that a local variable having a unique name is used in each of the specified processing blocks.

[0112] Furthermore, the processing blocks can be a loop processing instruction, a branching processing instruction such as an "if statement", a switch-case instruction or the like, and an accumulation of descriptions configured by the foregoing instructions and an assignment instruction accompanying the foregoing instruction or the like.

[0113] Furthermore, the processing block can, for example, be an accumulation of a description corresponding to each block in the Simulink model that is generated in the vehicle control program.

[0114] For example, the vehicle control program in Fig. 24. A local variable “tmp” with the same name is used in processing blocks 330 and 331, including an if-else statement, an assignment statement, and a function call. Therefore, renaming the local variable “tmp” changes the name of the local variable accessed by processing block 330 to “tmp1” and the name of the local variable accessed by processing block 331 to “tmp2”, for example.

[0115] Alternatively, if the vehicle control program is automatically generated from the Simulink model using the embedded encoder, the embedded encoder can be configured to avoid reusing local variables. In this setting, a local variable with a different name is used for each description, corresponding to each block. Therefore, even if S205 processing is not performed, it is possible to avoid unnecessary data dependencies between macro tasks. (Task fusion to hide conditional branches (S215 of automatic parallel processing))

[0116] As described above, since the loop structure does not exist in the vehicle control program, it is possible to apply either near-fine-grained or coarse-grained task parallelization. To relatively reduce the execution overhead of the vehicle control programs, the automatic parallelization compiler 1 uses coarse-grained task parallelization.

[0117] In the vehicle control program, the cost of each macro-task is approximately several tenths of a clock cycle. If the automatic parallelization compiler 1 performs dynamic scheduling, an overhead of several tens to several hundred clock cycles occurs. Therefore, dynamic scheduling may be unsuitable for the vehicle control program.

[0118] However, since a branch target of the macro task with conditional branching is dynamically determined at execution time, a static schedule that allocates processor cores at compile time cannot be applied to the macro task with conditional branching.

[0119] In S215 of the automatic parallelization processing of the present embodiment, task fusion is performed by using a task fusion algorithm to fuse a macro task with the conditional branch and a macro task that is at a branch target into a coarse-grained task (the block task).

[0120] In particular, an MTG 351 (see Fig. 26) from an MFG 350 (see Fig. 25) by executing task fusion. If task fusion is executed for the MFG 350, an MFG 352 is created (see below). Fig. 27) and an MTG 353 (see Fig. 28) produced by MFG 352.

[0121] In the task fusion for the MFG 350, "bb1" and "bb6", which have conditional branching, are specified as start-up end tasks. A series of processes including "bb1" as the starting point, a process including "bb1", "bb2", "bb4", or the like, and a process including "bb1", "bb3", "bb4", or the like are specified as well. As in Fig. As described in section 25, "bb4" corresponds to the first macro task that is executed together among the macro tasks that are carried out in the series of processing operations. "bb4" is specified as a termination end task. “bb1”, which is the start-up end-task, “bb4”, is the termination end-task, “bb2” and “bb3” are merged into a macro-task (“Block 1” of MFG 352), since “bb2” and “bb3” are executed after “bb1” and before “bb4” is executed.

[0122] The task fusion for the MFG 350 specifies a series of processes, including "bb6" as the starting point, followed by a process including "bb6", "bb7", "bb12", or similar, and a further process including "bb6", "bb8", "bb10", "bb11", "bb12", or similar. "bb12" corresponds to the first macro task executed among the macro tasks in the series of processes. "bb12" is specified as the final end task. "bb6", which is the start-up end-task, "bb12", which is the stop-up end-task, and "bb7-11" are combined into a macro task ("Block 3" of MFG 352). "bb7-11" are executed before "bb12" and after "bb6".

[0123] Since the conditional branch does not exist in the MFG 352 created by the task fusion (i.e., no control dependency exists), it is possible to execute the static scheduling. 3. Performance evaluation

[0124] A result of a performance evaluation of the onboard device on which the multi-core processor is mounted is explained. The multi-core processor is operated by the parallelization program generated by the automatic parallelization compiler 1 of the present embodiment. 3-1. Configuration of the on-board device

[0125] A configuration of an engine control ECU 400, operated by the parallelization program generated by the automatic parallelization compiler 1, is explained (see below). Fig. 29).

[0126] The engine control ECU 400 includes a ROM 410, a RAM 420, a communication section 430, a multi-core processor 440, a sensor section 450, and an input / output connector 460 or the like. The ROM 410 stores binary data of the parallelization program generated by the automatic parallelization compiler 1. The multi-core processor 440 operates according to the binary data and integrally controls the engine control ECU 400.

[0127] The RAM 420 is accessed by the multi-core processor 440. The communication section 430 communicates with other ECUs connected via a vehicle-integrated LAN or similar system.

[0128] The sensor unit 450 contains various sensors for detecting the condition of the motor 470. The input / output port 460 transmits and receives various signals for controlling the motor 470.

[0129] The multi-core processor 440 has several PEs 441, 442. The multi-core processor 440 could be an RP2, which is a multi-core processor for an information application, a V850E2R from Renesas Electronics, or the like.

[0130] The RP2 is a homogeneous multi-core architecture with eight SH4a cores (SH-X3), each core having a central processing unit (CPU), a local program memory (LPM), a local data memory (LDM), and a distributed shared memory (DSM). Each core includes a data transfer unit (DTU) that operates asynchronously with the CPU and performs data transfers.

[0131] Furthermore, the parallelization program is not limited to the engine control ECU 400 and other ECUs on which the multi-core processor is mounted, and can be operated by the parallelization program generated by the automatic parallelization compiler 1. Other ECUs may include, for example, a navigation system ECU or the like. Alternatively, the parallelization program is not limited to the vehicle's onboard equipment, and electronic devices such as an information application or information device on which the multi-core processor is mounted can be operated by the parallelization program generated by the automatic parallelization compiler 1. 3-2. Evaluation result of the engine control ECU

[0132] A model of the engine control ECU 400 control system has four subsystems, including an ECU model, a driver model, a car model, and a sensor model. The results of a performance evaluation of the entire engine control ECU 400 control system and a performance evaluation of each of the subsystems are explained in a case where the RP2 or the V850E2R is used as the multi-core processor 440. (Performance evaluation of RP2)

[0133] The RP2, which operates in parallel with two cores, and the RP2, which operates sequentially with one core, handle the ECU model, the driver model, the sensor model, and the car model. Furthermore, a program generated from these models is optimized primarily for size.

[0134] Regarding the ECU model, the execution time per cycle is 119 microseconds in the single-core RP2. In contrast, the execution time per cycle is reduced to 63 microseconds in the dual-core RP2. In terms of performance improvement, the dual-core RP2 offers a 1.89-fold performance increase compared to the single-core RP2.

[0135] Regarding the driver model, the execution time per cycle is 41 microseconds in the single-core RP2. In contrast, the execution time per cycle is reduced to 27 microseconds in the dual-core RP2. In terms of speed improvement rate, the performance of the dual-core RP2 is improved by a factor of 1.52 compared to the single-core RP2.

[0136] Regarding the sensor model, the execution time per cycle is 40 microseconds in the single-core RP2. In contrast, the execution time per cycle is reduced to 26 microseconds in the dual-core RP2. In terms of performance improvement, the dual-core RP2 offers a 1.52-fold performance increase compared to the single-core RP2.

[0137] Regarding the car model, the execution time in one cycle is 2382 microseconds in the single-core RP2. In contrast, the execution time in one cycle is reduced to 1291 microseconds in the dual-core RP2. In terms of performance improvement, the dual-core RP2 offers a 1.84-fold performance increase compared to the single-core RP2.

[0138] The entire control system of the engine control ECU 400 is operated by the RP2, which operates four cores in parallel, or by the RP2, which operates sequentially and has two cores. Furthermore, a program generated from the model of the entire control system is optimized with priority given to size.

[0139] In the single-core RP2, the execution time per cycle is 4161 microseconds. In the dual-core RP2, the execution time per cycle is 2397 microseconds. In the quad-core RP2, the execution time per cycle is reduced to 1273 microseconds. In terms of performance improvement, the dual-core RP2 offers a 1.74-fold performance improvement compared to the single-core RP2. The quad-core RP2 offers a 3.27-fold performance improvement compared to the single-core RP2. (Performance evaluation of the V850E2R)

[0140] The ECU model was created using either the V850E2R, which operates in parallel with two cores, or the V850E2R, which operates sequentially with one core. Furthermore, a program generated from the ECU model is optimized primarily for size.

[0141] In terms of speed improvement rate, the performance of the V850E2R, which has two cores, is improved by 1.91 times compared to the V850E2R, which has one core. 3-3. Evaluation result in engine fuel injection control model

[0142] A result of a performance evaluation when the parallelization program generated by an engine fuel injection control model through the automatic parallelization compiler 1 is operated by the RP2 and the V850E2R is explained. (Performance evaluation of RP2)

[0143] The engine fuel injection control model is implemented by the RP2 operating in parallel with four cores, by the RP2 operating in parallel with two cores, or by the RP2 operating sequentially with one core. Furthermore, a program generated from the engine fuel injection control model is optimized with priority given to size.

[0144] The execution time in one cycle is 157 microseconds in the single-core RP2. In contrast, the execution time in one cycle is 87 microseconds in the dual-core RP2. In the quad-core RP2, the execution time in one cycle is reduced to 42 microseconds. In terms of performance improvement, the dual-core RP2 offers a 1.81-fold performance improvement compared to the single-core RP2, and the quad-core RP2 offers a 3.76-fold performance improvement compared to the single-core RP2. (Performance evaluation of the V850E2R)

[0145] The engine fuel injection control model is operated by the V850E2R, which operates in parallel with two cores, and the V850E2R, which operates sequentially with one core. Furthermore, a program generated from the engine fuel injection control model is optimized with priority given to size.

[0146] In terms of speed improvement rate, the performance of the V850E2R, which has two cores, is improved by a factor of 1.79 compared to the V850E2R, which has one core. (Another embodiment) (1) The automatic parallelization compiler 1 of the present embodiment performs the inline extension of the sequential program of automatic parallelization processing at S200 and renames the local variable at S205. The inline extension and renaming need not be performed, or only one of the processes can be performed. In such a case, the same effects can be achieved according to a configuration of the sequential program. (2) The automatic parallelization compiler 1 of the present embodiment can optimize the generated parallelization program for speculative execution. According to this optimization, the performance of the parallelization program can be further improved.

[0147] S200 of automatic parallelization processing corresponds to an example of executing an inline extension (or a substitute procedure) of the parallelization compiler procedure. S205 corresponds to an example of renaming (or a renaming procedure). S210 corresponds to an example of splitting (or a splitting procedure) of a parallelization compiler procedure and the parallelization compiler, and a splitting device (or means) of the parallelization compiler device. S214 corresponds to an example of specifying (or a specification procedure) of the parallelization compiler procedure and the parallelization compiler, and a specification device (or a specification means) of the parallelization compiler device.S215 corresponds to an example of a fusion (or fusion procedure) of the parallelization compilation method and the parallelization compiler and a fusion device (or fusion means) of the parallelization compilation device.

[0148] S220 corresponds to an example of extracting (or an extraction procedure) the parallelization compiler process and the parallelization compiler and an extraction device (or means) of the parallelization compiler device. S225 corresponds to an example of executing a static scheduling (or a scheduling procedure) of the parallelization compiler process and the parallelization compiler and a scheduling device (or a scheduling means) of the parallelization compiler device.

[0149] S225 and S230 represent an example of a generation (or generation procedure) of the parallelization compiler method and the parallelization compiler, and a generation device (or generation means) of the parallelization compiler device. The PE, the PG, and the processor core represent an example of a processor unit.

[0150] The engine control ECU 400 is an example of an on-board device.

[0151] According to the present disclosure, a parallelization compilation method comprises dividing a sequential program for an embedded system for an on-board device into several macro-tasks according to a predetermined procedure, wherein the sequential program is executed by a single-processor system; and specifying, based on a control dependency between the macro-tasks, (i) a start-end task of the macro-tasks as a starting point, wherein the start-end task has processing that is branched into different macro-tasks, and (ii) a termination end task of the macro-tasks, wherein the termination end task is one of the macro-tasks that are executed jointly under several processing series that are executed sequentially starting from the start-end task.

[0152] Furthermore, the parallelization compilation procedure includes merging (i) the start-end task specified by the specification, (ii) the termination-end task executed from the start-end task in the processing, and (iii) a group of macro-tasks executed after the start-end task and before the termination-end task into a new macro-task; extracting a group of new macro-tasks, executable in parallel by multiple processor units included in a multiprocessor system attached to the onboard device, from the new macro-tasks that are merged in the merging process, based on a data dependency.

[0153] Furthermore, the parallelization compilation process involves performing a static schedule that assigns the new macro-tasks to the processor units so that the group of new macro-tasks can be executed in parallel by the processor units; and generating a parallelization program that is executed by the multiprocessor system based on a result of the static schedule.

[0154] Multigranular parallel processing is a known method for parallelizing a sequential program. It combines coarse-grained, medium-grained, and near-fine-grained parallelization. In a sequential program for an embedded system, a loop structure is either nonexistent or minimal. Furthermore, the loop structure consists of a conditional branch and an assignment statement. Therefore, medium-grained parallelization is not applicable to this sequential program. Medium-grained parallelization corresponds to parallelization at a single iteration level within the loop. Moreover, because the processing is very fine, overhead must be reduced when executing it in parallel on a multiprocessor system.

[0155] In the parallelization compilation method disclosed herein, a sequential program for an embedded system for a board device is divided into macro-tasks, a parallelism of each of the macro-tasks is extracted, and coarse-grained parallelization is performed to allocate the macro-tasks that can be executed in parallel to another processor unit. The sequential program is executed by a single-processor system.

[0156] Since the cycle of each macro-task generated from the sequential program for the embedded system's onboard device is short, using dynamic scheduling can increase overhead and make acceleration difficult. Static scheduling cannot be used for every macro-task if control dependencies exist between them. The processing time of each node is approximately one-tenth of the clock cycle at most; the processing is very precise, and minimizing overhead is crucial.

[0157] In the parallelization compilation method according to the present disclosure, after the several macro-tasks that are in the control dependency are merged into one task, the static scheduling is performed so that the macro-tasks that can be executed in parallel are allocated to other processor units.

[0158] According to this configuration, it is possible to automatically generate a high-speed parallelization program from the sequential program for the embedded system's onboard device. Therefore, compared to parallelizing the sequential program manually, it is possible to reduce development time and costs and generate a reliable parallelization program for the embedded system's onboard device.

[0159] Furthermore, the present disclosure can be implemented by different embodiments in addition to the parallelization compilation method described in the present embodiment. An example of other embodiments includes a parallelization compiler that is a program for causing a computer to implement the parallelization compilation method, a parallelization compilation device for implementing the parallelization compilation method, or the like. Additionally, an example of the present disclosure may be an onboard device or the like comprising a multiprocessor system operated by a program generated by the parallelization compilation method.

[0160] It should be noted that a flowchart or processing of the flowchart in the present application includes steps (also referred to as sections), each of which is represented, for example, as S100. Furthermore, each step can be divided into several subsections, and several sections can be combined into a single section. Each of the configured sections can also be referred to as a device, a module, or a means. Any combination of steps described above can be (i) software steps in combination with a hardware unit (for example, a computer), or (ii) a hardware section, including or excluding a function of a related device; furthermore, the hardware section (for example, an integrated circuit, hard-wired logic circuit) can be constructed within a microcomputer.

Claims

[1] Computer-implemented method for generating a parallelized program for a multiprocessor system mounted in a vehicle on-board device (400), comprising: Dividing a sequential program into multiple macro-tasks according to a predetermined procedure using a parallelization compiler running on a computer, which controls an embedded system, wherein the sequential program is executed by a single-processor system; Generating, using the compiler, a macroflow graph based on an analysis of control dependencies and data dependencies between the macro tasks; Specify, by means of the compiler, based on the control dependency specified in the macroflow graph, at least one pair consisting of a start-end task and a stop-end task, wherein the start-end task is a macro task having a conditional branch, and the stop-end task is a macro task that is the first macro task executed common to all of several series of macro tasks executed sequentially from the start-end task as a starting point, wherein the specification includes: analyzing all possible execution paths from the start-end task and identifying the first macro task executed common to all of the series of macro tasks as the stop-end task; Merge, using the compiler, (i) the initiating end task, (ii) the termination end task, and (iii) all macro tasks that are executed after the start-up end-task and before the finish-up end-task into a block task to hide the conditional branch of the start-up end-task in the block task, wherein the block task is designed such that, from the perspective of tasks outside the block task, the conditional branch in the start-up end-task is hidden from tasks outside the block task, and the merging is performed in such a way as to eliminate control dependencies between block tasks, thereby enabling static scheduling; Extracting, by means of the compiler, based on the data dependencies between the macro-tasks, including the block-tasks after fusion, from parallel-executable macro-tasks that can be executed in parallel by multiple processor units included in the multiprocessor system mounted in the vehicle on-board device (400), wherein the block-tasks have no control dependencies among themselves after fusion and the extraction is performed based on data dependencies between the block-tasks and remaining macro-tasks, so that static scheduling between the block-tasks is possible; Execution, using the compiler, a static schedule that assigns the parallel-executable macro tasks to the processor units, thereby executing the parallel-executable macro tasks in parallel by the multiple processor units; and Generating, by means of the compiler, a parallelized program to be executed by the multiprocessor system mounted in the vehicle on-board device (400), based on a result of the static scheduling. [2] Computer-implemented method according to claim 1, further comprising Executing an inline extension that transposes a description calling a function in the sequential program into another description representing the processing within the function. where, in the case of splitting, the sequential program is divided into macro tasks after the inline extension has been executed. [3] Computer-implemented method according to claim 1 or claim 2, further comprising: a procedure for finding a first processing block and a second processing block using local variables with identical names, where the first processing block and the second processing block represent collections of descriptions for realizing a particular object in the function described in the sequential program; and a renaming procedure that changes the descriptions in functions so that the local variables in the first processing block and the second processing block have different names from each other, The specification is performed after the names of the local variables have been changed by the renaming procedure and after the control flow between the macro tasks has been analyzed. [4] Parallelization compiler for generating a parallelized program for a multiprocessor system mounted in a vehicle on-board device (400), wherein the parallelization compiler, when executed on a computer, is configured to execute: Receiving a sequential program that controls an embedded system through an input section; Dividing (S210) the sequential program controlling the embedded system into multiple macro-tasks according to a predetermined procedure, wherein the sequential program is executed by a single-processor system; Generating a macro flow graph based on an analysis of tax dependencies and data dependencies between macro tasks; Specify (S214) based on the control dependency specified in the macroflow graph, at least one pair of a start-end task and a stop-end task, wherein the start-end task is a macro task having a conditional branch, and the stop-end task is a macro task that is the first macro task executed jointly in all of several series of macro tasks executed sequentially starting from the start-end task as a starting point, wherein the specifying includes: an analysis of all possible execution paths from the start-up end-task and an identification of the first macro-task that is executed common in all of the series of macro-tasks as the termination end-task; Merger (S215) (i) the initiating end task, (ii) the termination end task, and (iii) combine all macro tasks that are executed after the start-up end-task and before the finish-up end-task into a block task to hide the conditional branch of the start-up end-task in the block task, wherein the block task is designed such that, from the perspective of tasks outside the block task, the conditional branch in the start-up end-task is hidden from tasks outside the block task, and the merging is performed in such a way as to eliminate control dependencies between block tasks, thereby enabling static scheduling; Extraction (S220) based on the data dependency between the macro-tasks, including the block-tasks, after merging parallel-executable macro-tasks, which can be executed in parallel by multiple processor units included in the multi-processor system mounted in the vehicle on-board device (400), wherein the block-tasks have no control dependencies after merging and the extraction is performed based on data dependencies between the block-tasks and remaining macro-tasks, so that static scheduling between the block-tasks is possible; Executing (S225) a static schedule that assigns parallel-executable macro tasks to the processor units, thereby executing the parallel-executable macro tasks in parallel by the multiple processor units; Generating (S230) a parallelized program to be executed by the multiprocessor system mounted in the vehicle on-board device (400), based on a result of static scheduling; and Output of the generated parallelized program. [5] Parallelization compiler for generating a parallelized program for a multiprocessor system mounted in a vehicle on-board device (400), the parallelization compiler comprising: a partitioning device (S210) for dividing a sequential program controlling an embedded system into multiple macro-tasks according to a predetermined procedure, wherein the sequential program is executed by a single-processor system; a generation device for generating a macro flow graph based on an analysis of a tax dependency and a dependency between the macro tasks; a specification device (S214) for specifying, based on the control dependency specified in the macroflow graph, at least one pair of a start-end task and a stop-end task, wherein the start-end task is a macro task having a conditional branch, and the stop-end task is a macro task that is the first macro task executed common to all of several series of macro tasks executed sequentially from the start-end task as a starting point, wherein the specification includes: analyzing all possible execution paths from the start-end task and identifying the first macro task executed common to all of the series of macro tasks as the stop-end task; a merger facility (S215) for merging (i) the initiating end task, (ii) the termination end task, and (iii) combine all macro tasks that are executed after the start-up end-task and before the finish-up end-task into a block task to hide the conditional branch of the start-up end-task in the block task, wherein the block task is designed such that, from the perspective of tasks outside the block task, the conditional branch in the start-up end-task is hidden from tasks outside the block task, and the merging is performed in such a way as to eliminate control dependencies between block tasks, thereby enabling static scheduling; an extraction device (S220) for extracting based on the data dependency between the macro-tasks, including the block-tasks, after merging parallel executable macro-tasks, which can be executed in parallel by multiple processor units included in the multiprocessor system mounted in the vehicle on-board device (400), wherein the block-tasks have no control dependencies among themselves after merging and the extraction is performed based on data dependencies between the block-tasks and remaining macro-tasks, so that static scheduling between the block-tasks is possible; a scheduling device (S225) for executing a static schedule that assigns the parallel-executable macro tasks to the processor units, thereby executing the parallel-executable macro tasks in parallel by the multiple processor units; and a generation device (S230) for generating a parallelized program that is executed by the multiprocessor system mounted in the vehicle on-board device (400), based on a result of the static scheduling. [6] Vehicle on-board device (400), comprising: a multi-core processor; a memory that stores a parallelized program generated by the method according to claim 1; and a multiprocessor system (440) that includes the multicore processor and operates according to the parallelized program. [7] Computer-implemented method according to claim 1, wherein: The extraction of the parallel executable macro-tasks is performed by generating a macro-task graph based on an analysis of the earliest executable condition of the macro-tasks, including the block-tasks.

Images