JP2015125503A - Multi-processor program generation method, multi-processor device and multi-processor firmware - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a multi-processor program and the like that can reduce a time required for calling up processing.SOLUTION: A computer is configured to: read communication route information including position information on a processor and core executing a process, position information on a processor having a memory mounted, and position information on an interface usable upon access to the memory from the core executing the process; then, specify a parameter to be set in an API (Application Programming Interface) executing transmission/reception of data via the memory between the processes on the basis of the read information; generate a code of the API operated by the specified parameter; and, in a main processing program, execute processing of embedding the code of the generated API at an execution portion of transmission/reception of the data between the processes.

Description

  The present invention relates to a multiprocessor program generation method, a multiprocessor device, and multiprocessor firmware.

  In the development of multi-processor and multi-core embedded devices, there is a case in which a process executed on one core is changed to be executed on another core. In such a case, the communication means between the core executing the process and the memory accessed by the process is changed by changing the physical positional relationship between the core executing the process and the memory accessed by the process. It may become.

  There is a method of virtualizing the communication part as a method of reducing the load of changing the communication means accompanying the change of the physical position. In virtual communication, it is described that an API (Application Programming Interface) that executes communication processing is called at a location where communication is performed in the main processing program. The definitions of the communication source and the communication destination are initialized at the time of initial startup, and based on the defined communication source and communication destination, a communication processing API that performs actual communication is dynamically called from the library and executed.

JP 2009-104422 A JP 2000-181881 A

  However, in the above virtual communication, an API is called and communication processing is executed at the time of communication execution, so pre-processing for calling the communication processing and post-processing after the called communication processing ends. Such overhead of pre-processing and post-processing occupies a large proportion of the total processing time in communication processing that occurs frequently with a short execution time, such as read / write to the memory.

  In one aspect, an object of the present invention is to provide a multiprocessor program generation method, a multiprocessor device, and a multiprocessor firmware that can reduce the time taken to call a process.

  In one proposal, the computer includes location information of a processor and a core executing a process, location information of a processor in which a memory is mounted, and an interface usable when accessing the memory from the core executing the process. Based on the communication path information including the information, a process for specifying a parameter to be set in the API for executing data transmission / reception between the processes via the memory is executed. Then, the computer executes a process of generating an API code that operates with the specified parameters. In the main processing program, the computer executes a process of embedding the generated API code in an execution location of data transmission / reception between the processes.

  In one aspect, the present invention can reduce the time spent invoking a process.

FIG. 1 is an explanatory diagram illustrating an example of a program generation device according to the first embodiment. FIG. 2 is an explanatory diagram illustrating an example of communication path information. FIG. 3 is an explanatory diagram illustrating an example of virtual communication information. FIG. 4 is an explanatory diagram showing an example of physical position information related to a task. FIG. 5 is an explanatory diagram illustrating an example of physical position information related to the memory. FIG. 6 is an explanatory diagram illustrating an example of a multiprocessor device. FIG. 7A is a diagram for explaining an example of data transfer by a pointer. FIG. 7B is a diagram for explaining an example of data transfer by a pointer. FIG. 7C is a diagram for explaining an example of data transfer by a pointer. FIG. 8 is an explanatory diagram showing a detailed example of data transfer between tasks. FIG. 9A is a diagram for explaining an example of data transfer (Read Local) by core access. FIG. 9B is a diagram for explaining an example of data transfer (Read Local) by core access. FIG. 9C is a diagram for explaining an example of data transfer (Read Local) by core access. FIG. 10A is a diagram for explaining an example of data transfer (Write Local) by core access. FIG. 10B is a diagram for explaining an example of data transfer (Write Local) by core access. FIG. 10C is a diagram for explaining an example of data transfer (Write Local) by core access. FIG. 11A is a diagram for explaining an example of data transfer by the shared memory. FIG. 11B is a diagram for explaining an example of data transfer by the shared memory. FIG. 11C is a diagram for explaining an example of data transfer by the shared memory. FIG. 12A is a diagram for explaining an example of data transfer by DMA. FIG. 12B is a diagram for explaining an example of data transfer by DMA. FIG. 12C is a diagram for describing an example of data transfer by DMA. FIG. 13A is a diagram for explaining an example of data transfer by SRIO. FIG. 13B is a diagram for describing an example of data transfer by SRIO. FIG. 13C is a diagram for describing an example of data transfer by SRIO. FIG. 14 is a flowchart illustrating an example of the operation of the program generation device according to the first embodiment. FIG. 15 is an explanatory diagram illustrating an example of a program generation device according to the second embodiment. FIG. 16 is a flowchart illustrating an example of the operation of the program generation device according to the second embodiment. FIG. 17 is an explanatory diagram illustrating an example of a computer that implements the functions of the program generation device.

  Embodiments of a multiprocessor program generation method, a multiprocessor device, and multiprocessor firmware disclosed in the present application will be described in detail below. The disclosed technology is not limited by the present embodiment. Moreover, you may combine suitably each Example shown below in the range which does not cause contradiction.

  FIG. 1 is an explanatory diagram illustrating an example of a program generation device 10 according to the first embodiment. For example, as illustrated in FIG. 1, the program generation device 10 includes a communication path information storage unit 11, a specification unit 12, a generation unit 13, and an embedding unit 14. In the present embodiment, the program generation device 10 generates a program for a multiprocessor device having a plurality of processors having one or more cores, for example. In the present embodiment, the multiprocessor device functions as, for example, a radio base station or a radio terminal.

  For example, communication path information 110 as shown in FIG. 2 is stored in the communication path information storage unit 11. FIG. 2 is an explanatory diagram illustrating an example of the communication path information 110. The communication path information 110 includes an API name 111, an access type 112, access source information 113, access destination information 114, a minimum access size 115, an area size 116, and an IF (InterFace) type 117. The API name 111 is a name for identifying an API that executes data transfer from the task to the memory and data transfer from the memory to the task. A task is an example of a process. The access type 112 is information indicating whether the data transfer is writing from the task to the memory or reading from the memory. In the access type 112 illustrated in FIG. 2, “W” indicates that the data transfer is a write from the task to the memory, and “R” indicates that the data transfer is a read from the memory.

  The access source information 113 includes the name of the access source task that accesses the memory, the name of the core on which the task is executed, and the name of the processor having the core. By referring to the names of the processor and the core included in the access source information 113, the position of the core where the task is executed and the position of the processor including the core can be specified.

  The access destination information 114 includes the name of the memory to be accessed by the task, the name of the processor, the name of the core, and the type of memory. The type of memory indicates the type of memory such as local memory or shared memory. In the type of the access destination information 114 illustrated in FIG. 2, “local” indicates that the memory type is a local memory. The name of the core is the name of the core that mainly accesses the memory when the memory is a local memory. The name of the processor is the name of the processor in which the memory is mounted. By referring to the names of the processor and the core included in the access destination information 114, the position of the processor in which the memory is mounted and the position of the core to which the memory is mainly accessed can be specified.

  The minimum access size 115 indicates the minimum size of data to be transferred. The area size 116 indicates the size of an area for holding transferred data. The IF type 117 indicates the type of interface used in accessing the memory from the task. In the IF type 117 illustrated in FIG. 2, “Bus” indicates that the type of interface used in accessing the memory from the task is a bus.

  Here, the communication path information 110 illustrated in FIG. 2 includes, for example, the virtual communication information 200 illustrated in FIG. 3, the physical position information 210 of the task illustrated in FIG. 4, and the physical position information of the memory illustrated in FIG. 214. The virtual communication information 200 and the physical position information 210 of the task are created by, for example, a programmer. The physical location information 214 of the memory is created by, for example, a designer of a multiprocessor device.

  FIG. 3 is an explanatory diagram illustrating an example of the virtual communication information 200. In the virtual communication information 200, for example, as shown in FIG. 3, the access source task name 202, the access destination memory name 203, the minimum access size 204, the area size 205, the access type 206, and the API name are associated with the number 201. 207 is included. The access source task name 202 is the name of the access source task that accesses the memory. The access destination memory name 203 is the name of the access destination memory accessed by the task. The minimum access size 204 indicates the minimum size of data to be transferred. An area size 205 indicates the size of an area for holding transferred data. The API name 207 is a name for identifying an API that executes data transfer from the task to the memory and data transfer from the memory to the task.

  FIG. 4 is an explanatory diagram illustrating an example of the physical position information 210 related to a task. The task physical position information 210 includes a task name 211, a processor name 212, and a core name 213. The task name 211 is a name for identifying each task. The processor name 212 is a name of a processor having a core on which a task is executed. The core name 213 is the name of the core that executes the task.

  FIG. 5 is an explanatory diagram showing an example of the physical position information 214 regarding the memory. The memory physical location information 214 includes a memory name 215, a processor name 216, a core name 217, a type 218, and a use IF 219. The memory name 215 is a name for identifying each memory. The processor name 216 is the name of the processor in which the memory is mounted. The core name 217 is a name of a core that mainly accesses the memory when the memory is a local memory. The type 218 indicates the type of memory such as local memory or shared memory. The use IF 219 indicates an interface that can be used when accessing the memory.

  Returning to FIG. 1, the description will be continued. The specifying unit 12 refers to the communication path information 110 and determines the IF type of the interface used for data communication between tasks according to the type of memory accessed from the task, the position of the core on which the task is executed, and the like. Correct it. For example, the specifying unit 12 refers to the access destination information in the communication path information 110 and specifies a pair of tasks whose access destination is the same memory. Then, the specifying unit 12 determines whether the type of memory accessed by the specified task pair is local.

  When the type of memory to be accessed is local, the specifying unit 12 sets the IF type in the communication path information 110 as data by a pointer if the specified pair of tasks is executed by the same core in the same processor. Change to forwarding. In this way, the specification unit 12 can speed up data transfer between tasks by changing the data transfer of a task executed by the same core in the same processor to a data transfer by a pointer. .

  On the other hand, when the identified task pair is executed by different cores in the same processor, the identifying unit 12 determines whether or not the minimum access size in the communication path information 110 is equal to or larger than a predetermined size. The predetermined size is, for example, the size of data for which data transfer using an interface using hardware dedicated to data transfer is faster data transfer. An interface using hardware dedicated to data transfer is, for example, DMA (Direct Memory Access). When the minimum access size in the communication path information 110 is equal to or larger than the predetermined size, the specifying unit 12 changes the IF type in the communication path information 110 to data transfer by DMA. As described above, when the amount of data transferred between tasks is equal to or larger than a predetermined size, the specifying unit 12 can set higher-speed data transfer by changing the IF type to data transfer by DMA.

  On the other hand, when the minimum access size in the communication path information 110 is less than the predetermined size, the specifying unit 12 changes the IF type in the communication path information 110 to core access. Core access is a data transfer method in which a task executed in a different core transfers data via the local memory of the core in which any task is executed. In this way, even when the task is executed in a different core, when data transfer is performed via any of the local memories, the specifying unit 12 can be changed by changing the IF type to core access. High-speed data transfer can be set.

  Next, the specifying unit 12 specifies a parameter to be set in an API that performs data transmission / reception between tasks via a memory based on the communication path information 110. For example, the specifying unit 12 refers to the IF type in the communication path information 110 and specifies the API source code for realizing communication using the interface indicated by the IF type in the existing source library. Then, the specifying unit 12 specifies a parameter used for starting the specified API.

  The generation unit 13 generates API source code that operates with the parameters specified by the specification unit 12. For example, the generation unit 13 refers to the IF type in the communication path information 110, and acquires the API source code for realizing communication using the interface indicated by the IF type from the existing source library. Then, the generation unit 13 rewrites the acquired setting value of the API source code with the parameter specified by the specifying unit 12 to generate the API source code. The API source code generated here is the virtual communication API source code specialized for the multiprocessor device of this embodiment.

  The embedding unit 14 embeds the generated API source code in the execution point of data transmission / reception between tasks in the source code of the main processing program. Here, the main processing program in this embodiment is, for example, a program that executes a plurality of tasks for performing individual processing and executes predetermined processing. Further, when the multiprocessor device that operates based on the multiprocessor program generated by the program generation device 10 functions as, for example, a radio base station, the predetermined process executed by the main processing program is, for example, a transmission process . The task executed by the main processing program executes individual processing such as encoding processing.

  For example, the embedding unit 14 specifies a location where an API for executing data communication between tasks is called in the source code of the main processing program. Then, the embedding unit 14 embeds the API source code generated by the generating unit 13 in the specified location, and generates the source code of the multiprocessor program.

  The embedding unit 14 may store the generated source code of the multiprocessor program in a storage unit in the program generation device 10 or may output it to a device external to the program generation device 10. The embedding unit 14 compiles and links the source code of the generated multiprocessor program and the source code of another API, and stores it in the storage unit in the program generation device 10 as an execution code for the multiprocessor. You may let them. The embedding unit 14 may output the generated execution code for the multiprocessor to a device (for example, a multiprocessor device) external to the program generation device 10.

  Here, a multiprocessor device that operates based on the multiprocessor program generated by the program generation device 10 will be described. FIG. 6 is an explanatory diagram illustrating an example of the multiprocessor device 30. The multiprocessor device 30 in this embodiment includes a plurality of processors DSP1 and DSP2, a multiprocessor firmware 31 and a ROM that stores various data. The multiprocessor firmware 31 is an execution code of a multiprocessor program generated by the program generation device 10 and is stored in advance in a ROM in the multiprocessor device 30 before the multiprocessor device 30 is activated.

  The DSP 1 includes Core 11 and Core 12, which are a plurality of cores, and MEM 11, MEM 12 and MEM 13, which are a plurality of memories. The DSP 1 also includes a DMA that is an interface for transferring memory between cores in the DSP 1 and an SRIO (Serial Rapid IO) that is an example of an interface that performs serial communication with an external device of the DSP 1. . In addition to SRIO, Ethernet (registered trademark), RS232C, PCI, or the like may be included in DSP 1 as an interface for performing serial communication with an external device of DSP 1.

  The MEM 11 is a local memory of the Core 11 and is mainly accessed from the Core 11. The MEM 11 can be accessed from a core other than the Core 11 (for example, Core 12), but the data transfer rate with the Core 11 is faster than the data transfer rate with the core other than the Core 11. .

  The MEM 12 is a local memory of the Core 12, and is mainly accessed from the Core 12. The MEM 12 can also be accessed from a core other than the Core 12 (for example, the Core 11), but the data transfer rate with the Core 12 is faster than the data transfer rate with the core other than the Core 12. .

  The MEM 13 is a shared memory of the Core 11 and the Core 12, and is accessed from both the Core 11 and the Core 12, and the data transfer rate with the Core 11 and the data transfer rate with the Core 12 are approximately the same.

  The DSP 2 includes Core21 and Core22 that are a plurality of cores, and MEM21, MEM22, and MEM23 that are a plurality of memories. The DSP 2 includes DMA and SRIO.

  The multiprocessor firmware 31 in the ROM includes an execution code for each task. The DSP 1 or DSP 2 reads the multiprocessor firmware 31 from the ROM, and expands the execution code of each task in the local memory of the core that executes the task. Note that the execution codes of all tasks need not always be expanded in any local memory, and only the execution codes of tasks used for processing may be expanded in the local memory.

  In transmitting data, each task writes data in the memory specified by the instruction using the interface specified by the instruction in accordance with the instruction embedded in the execution code of the task. In addition, each task reads data from the memory specified by the instruction using the interface specified by the instruction in accordance with the instruction embedded in the execution code of the task.

  Each core causes the execution code in the local memory to function as a task. Each task expands various data read from the local memory in an area allocated to itself on the local memory or the shared memory, and executes various processes based on the expanded data.

  Next, the relationship between the multiprocessor program generated by the program generation device 10 based on the communication path information 110 and the multiprocessor device 30 operating based on the multiprocessor program will be described with reference to FIGS. explain. 7 to 13 show the operation of the multiprocessor device 30 illustrated in FIG.

  7A to 7C are explanatory diagrams illustrating an example of data transfer using a pointer. In the virtual communication information 200 illustrated in FIG. 7A, virtual communication in which data transfer from Task A to Task B is performed via the MEM 12 is defined.

  As illustrated in the communication path information 110 of FIG. 7B, Task A and Task B are executed by the same Core 12 in the same DSP 1. Further, as illustrated in FIG. 7C, since the MEM 12 is the local memory of the Core 12, the specifying unit 12 changes the IF type in the data transfer from Task A to Task B via the MEM 12, for example, data transfer by a pointer. To do. FIG. 7B illustrates communication path information 110 after the IF type is changed by the specifying unit 12.

  FIG. 8 is an explanatory diagram showing a detailed example of data transfer between tasks. In data transfer from Task A as the data transfer source to Task B as the data transfer destination, the data transmission unit 32 in Task A writes the data to be transferred to the MEM 12, and the data reception unit 33 in Task B stores the data to be transferred. Read from MEM12. However, since the IF type has been changed to data transfer using a pointer, the data itself is not transferred in the example of FIGS. 7A to 7C, and pointer information indicating the location in the MEM 12 where the data is stored is the data transmission. The data is sent from the unit 32 to the data receiving unit 33.

  9A to 9C are explanatory diagrams illustrating an example of data transfer (Read Local) by core access. In the virtual communication information 200 illustrated in FIG. 9A, virtual communication in which data transfer from Task A to Task B is performed via the MEM 12 is defined.

  As illustrated in the communication path information 110 of FIG. 9B, TaskA and TaskB are executed in the same DSP1, but TaskA is executed in Core11, and TaskB is executed in Core12. Further, as illustrated in FIG. 9C, since the MEM 12 is the local memory of the Core 12, the specifying unit 12 determines whether or not the minimum access size in the communication path information 110 is a predetermined size (for example, 512 bytes) or more. .

  Since the minimum access size (256 bytes in the example of FIG. 9B) in the communication path information 110 is less than the predetermined size, the specifying unit 12 sets the IF type in data transfer from Task A to Task B via the MEM 12 to, for example, core access. change. FIG. 9B illustrates communication path information 110 after the IF type is changed by the specifying unit 12. In data transfer from Task A as the data transfer source to Task B as the data transfer destination, the data transmission unit 32 in Task A writes the data to be transferred to the MEM 12 by core access, and the data reception unit 33 in Task B receives the transfer target data. Read data from MEM12.

  10A to 10C are explanatory diagrams illustrating an example of data transfer (Write Local) by core access. In the virtual communication information 200 illustrated in FIG. 10A, virtual communication in which data transfer from Task B to Task A is performed via the MEM 12 is defined.

  As illustrated in the communication path information 110 of FIG. 10B, TaskA and TaskB are executed in the same DSP1, but TaskA is executed in Core11, and TaskB is executed in Core12. Further, as illustrated in FIG. 10C, since the MEM 12 is a local memory of the Core 12, the specifying unit 12 determines whether or not the minimum access size in the communication path information 110 is a predetermined size (for example, 512 bytes) or more. .

  Since the minimum access size (256 bytes in the example of FIG. 10B) in the communication path information 110 is less than the predetermined size, the specifying unit 12 sets the IF type in data transfer from Task B to Task A via the MEM 12 to, for example, core access. change. FIG. 10B illustrates communication path information 110 after the IF type is changed by the specifying unit 12. In data transfer from Task B as the data transfer source to Task A as the data transfer destination, the data transmission unit 32 in Task B writes the data to be transferred to the MEM 12, and the data reception unit 33 in Task A transfers the data by core access. Is read from the MEM 12.

  11A to 11C are explanatory diagrams illustrating an example of data transfer by the shared memory. In the virtual communication information 200 illustrated in FIG. 11A, virtual communication in which data transfer from Task A to Task B is performed via the MEM 13 is defined.

  As illustrated in the communication path information 110 of FIG. 11B, TaskA and TaskB are executed in the same DSP1, but TaskA is executed in Core11, and TaskB is executed in Core12. As illustrated in FIG. 11C, since the MEM 13 is not the local memory of the Core 11 or the Core 12, the specifying unit 12 does not change the IF type in the data transfer from the Task A to the Task B via the MEM 13. In the communication path information 110 illustrated in FIG. 11B, the IF type remains Bus before change. In data transfer from Task A as the data transfer source to Task B as the data transfer destination, the data transmission unit 32 in Task A writes the data to be transferred to the MEM 13, and the data reception unit 33 in Task B stores the data to be transferred. Read from MEM13.

  12A to 12C are explanatory diagrams illustrating an example of data transfer by DMA. In the virtual communication information 200 illustrated in FIG. 12A, virtual communication in which data transfer from Task A to Task B is performed via the MEM 12 is defined. However, the definition of the minimum access size is 512 bytes.

  As illustrated in the communication path information 110 of FIG. 12B, TaskA and TaskB are executed in the same DSP1, but TaskA is executed in Core11, and TaskB is executed in Core12. Further, as illustrated in FIG. 12C, since the MEM 12 is the local memory of the Core 12, the specifying unit 12 determines whether or not the minimum access size in the communication path information 110 is equal to or larger than a predetermined size (for example, 512 bytes). .

  Since the minimum access size (512 bytes in the example of FIG. 12B) in the communication path information 110 is equal to or larger than the predetermined size, the specifying unit 12 sets the IF type in data transfer from Task A to Task B via the MEM 12, for example, data by DMA Change to forwarding. In FIG. 12B, the communication path information 110 after the IF type is changed by the specifying unit 12 is illustrated. In data transfer from Task A as the data transfer source to Task B as the data transfer destination, the data transmission unit 32 in Task A sends the data to be transferred to the DMA via the MEM 11, and the data reception unit 33 in Task B transfers the data. Read target data from MEM 12.

  13A to 13C are explanatory diagrams illustrating an example of data transfer by SRIO. In the virtual communication information 200 illustrated in FIG. 13A, virtual communication in which data transfer from Task A to Task B is performed via the MEM 21 is defined.

  As illustrated in the communication path information 110 of FIG. 13B, Task A and Task B are executed in cores in different processors. That is, TaskA is executed by Core11 in DSP1, and TaskB is executed by Core21 in DPS2. As illustrated in FIG. 13C, since Task A and Task B are executed in different processors, the specifying unit 12 does not change the IF type in data transfer from Task A to Task B via the MEM 13. In the communication path information 110 illustrated in FIG. 13B, the IF type remains the SRIO before the change. In data transfer from Task A as the data transfer source to Task B as the data transfer destination, the data transmission unit 32 in Task A sends the data to be transferred to SRIO via MEM 11, and the data reception unit 33 in Task B transfers the data. Read target data from MEM21. When there are a plurality of interfaces (for example, SRIO, Ethernet, PCI, etc.) that can be used for data transfer between processors, the interface with the highest data transfer rate is employed, for example.

  FIG. 14 is a flowchart illustrating an example of the operation of the program generation device 10. The program generation device 10 starts the operation shown in this flowchart at a predetermined timing, for example, when an instruction from a user is received via an input device (not shown).

  First, the specifying unit 12 refers to the communication path information 110 and selects one unselected memory from among the access destination memories (S100). Then, the identifying unit 12 refers to the communication path information 110 and identifies a pair of a task that writes data and a task that reads data in the selected memory (S101). Then, the specifying unit 12 refers to the communication path information 110 and determines whether or not the type of memory accessed by the task pair is local (S102).

  When the memory type of the access destination is local (S102: Yes), the identifying unit 12 refers to the communication path information 110 and determines whether or not the task pair is executed in the same processor ( S103). When the type of memory accessed by the task pair is not local (S102: No), or when the task pair is executed in a different processor (S103: No), the specifying unit 12 proceeds to step S109. The process shown is executed.

  When the task pair is executed in the same processor (S103: Yes), the specifying unit 12 refers to the communication path information 110 and determines whether the task pair is executed in the same core. (S104). When the task pair is executed by the same core (S104: Yes), the specifying unit 12 changes the IF type in the communication path information 110 to data transfer by a pointer (S105), and performs the process shown in step S109. Run.

  On the other hand, when the task pair is executed by a different core (S104: No), the specifying unit 12 refers to the minimum access size in the communication path information 110 and determines whether the minimum access size is equal to or larger than a predetermined size. Determine (S106). When the minimum access size is less than the predetermined size (S106: No), the specifying unit 12 changes the IF type in the communication path information 110 to data transfer by core access (S107), and executes the process shown in step S109. To do.

  On the other hand, when the minimum access size is equal to or larger than the predetermined size (S106: Yes), the specifying unit 12 changes the IF type in the communication path information 110 to data transfer by DMA (S108). Then, the specifying unit 12 refers to the IF type in the communication path information 110, and acquires the API source code that realizes communication using the interface indicated by the IF type from, for example, an existing source library (S109). Then, the specifying unit 12 specifies a parameter used for starting the acquired API (S110).

  Next, the generation unit 13 generates a virtual communication API by rewriting the source code acquired in step S109 so as to start with the parameters specified in step S110 (S111). Then, the generation unit 13 holds the generated virtual communication API in the storage unit in the program generation device 10. Then, the specifying unit 12 refers to the communication path information 110 and determines whether all the access destination memories have been selected (S112). When there is an unselected memory (S112: No), the specifying unit 12 executes the process shown in step S100 again.

  On the other hand, when all the access destination memories are selected (S112: Yes), the embedding unit 14 embeds an API code that embeds the generated API source code at the execution point of data transmission / reception between tasks in the main processing program. The process is executed (S113). Then, the program generation device 10 ends the operation shown in this flowchart.

  In step S113, the embedding unit 14 specifies, for example, a location where an API for executing data communication between tasks is called in the source code of the main processing program. Then, the embedding unit 14 embeds the API source code generated by the generating unit 13 in the specified location, and generates a multiprocessor program.

  In the above, Example 1 was demonstrated. According to the program generation device 10 in the present embodiment, in the multiprocessor device, it is possible to reduce the time required for the process call and to reduce the overall processing time.

  FIG. 15 is an explanatory diagram illustrating an example of a program generation device according to the second embodiment. For example, as illustrated in FIG. 15, the program generation device 10 ′ in the present embodiment includes a communication path information storage unit 11, a specification unit 12, a generation unit 13, and an embedding unit 14. In addition, the program generation device 10 ′ includes a virtual communication information storage unit 20, a physical location information storage unit 21, a reception unit 22, a communication path information generation unit 23, an API source library storage unit 24, and a main processing program storage. Unit 25 and an execution code generation unit 26. Except for the points described below, in FIG. 15, the components denoted by the same reference numerals as those in FIG. 1 have the same or similar functions as those in FIG.

  The receiving unit 22 receives the virtual communication information 200 illustrated in FIG. 3, the physical position information 210 of the task illustrated in FIG. 4, and the physical position information 214 of the memory illustrated in FIG. 5 from an external device such as a user computer. Accept. Then, the reception unit 22 stores the received virtual communication information 200 in the virtual communication information storage unit 20. In addition, the reception unit 22 stores the physical position information 210 of the received task and the physical position information 214 of the memory in the physical position information storage unit 21.

  Based on the virtual communication information 200 in the virtual communication information storage unit 20, the physical position information 210 of the task in the physical position information storage unit 21, and the physical position information 214 of the memory, the communication path information generation unit 23 performs the processing shown in FIG. The communication path information 110 illustrated in FIG. Then, the communication path information generation unit 23 stores the generated communication path information 110 in the communication path information storage unit 11.

  The API source library storage unit 24 stores an API source library that realizes communication using an interface for each interface. In the present embodiment, the generation unit 13 refers to the IF type in the communication path information 110 and acquires the API source code that realizes communication using the interface indicated by the IF type from the API source library storage unit 24. .

  The main processing program storage unit 25 stores the source code of the main processing program. The embedding unit 14 acquires the source code of the main processing program from the main processing program storage unit 25. The execution code generation unit 26 compiles and links the source code of the multiprocessor program generated by the embedding unit 14 together with the source code of another API, and generates an execution code for the multiprocessor. Then, the execution code generation unit 26 outputs the generated execution code to an external device (for example, the multiprocessor device 30).

  FIG. 16 is a flowchart illustrating an example of the operation of the program generation device 10 ′ according to the second embodiment. The program generation device 10 ′ starts the operation shown in this flowchart at a predetermined timing, for example, when an instruction from a user is received via an input device (not shown).

  First, the receiving unit 22 receives virtual communication information 200, task physical position information 210, and memory physical position information 214 from an external device such as a user's computer (S200). Then, the reception unit 22 stores the received virtual communication information 200 in the virtual communication information storage unit 20, and stores the received physical position information 210 and physical position information 214 of the memory in the physical position information storage unit 21. (S201).

  Next, the communication path information generation unit 23 uses the task name and the memory name as keys based on the virtual communication information 200, the physical position information 210 of the task, and the physical position information 214 of the memory, and the communication path information illustrated in FIG. 110 is generated (S202). Then, the program generation device 10 'executes the processes of steps S100 to S113 illustrated in FIG.

  According to the program generation device 10 ′ of the present embodiment, even when the position of a core or the like that executes a task is changed, the virtual communication information, the physical position information of the task, and the physical position information of the memory are changed. Thus, an execution code corresponding to the change can be generated. As a result, it is possible to reduce the burden of changing the main processing program that accompanies the change of the position of the core executing the task and the memory to be accessed. Therefore, it is possible to reduce the workload of programmers and the like in developing a multiprocessor device and firmware applied to the multiprocessor device.

  Various processes in the program generation apparatus described in the first or second embodiment can be realized by executing a prepared program on a computer such as a personal computer or a workstation.

  FIG. 17 is an explanatory diagram illustrating an example of a computer that implements the functions of the program generation device. As illustrated in FIG. 17, the computer 100 includes an operation unit 110a, a speaker 110b, a camera 110c, a display 120, and a communication unit 130. Further, the computer 100 includes a CPU 150, a ROM 160, an HDD 170, and a RAM 180. These units 110 to 180 are connected via a bus 140.

  For example, as shown in FIG. 17, a generation program 170 a is stored in the HDD 170 in advance. In the first embodiment, when the generation program 170 a is read into the computer 100, the computer 100 exhibits the same functions as the specifying unit 12, the generation unit 13, and the embedding unit 14. In the first embodiment, the RAM 180 or the HDD 170 stores data in the communication path information storage unit 11.

  In the second embodiment, when the generation program 170a is read into the computer 100, the computer 100 causes the specification unit 12, the generation unit 13, the embedding unit 14, the reception unit 22, the communication path information generation unit 23, and the execution code. The same function as that of the generation unit 26 is exhibited. In the second embodiment, the RAM 180 or the HDD 170 includes the communication path information storage unit 11, the virtual communication information storage unit 20, the physical location information storage unit 21, the API source library storage unit 24, and the main processing program storage unit 25. Is stored.

  The generation program 170a may be appropriately integrated or separated as in the case of each component shown in FIG. 14 or FIG. In addition, it is not always necessary that all data stored in the HDD 170 is stored in the HDD 170, and only data used for processing may be stored in the HDD 170.

  Then, the CPU 150 reads the generation program 170 a from the HDD 170 and expands it in the RAM 180. Accordingly, as illustrated in FIG. 17, the generation program 170a functions as a generation process 180a. The generation process 180a expands various data read from the HDD 170 in an area allocated to itself on the RAM 180, and executes various processes based on the expanded data.

  Note that the generation process 180a in each of the above-described embodiments includes the processing executed in the specifying unit 12, the generation unit 13, and the embedding unit 14 shown in FIGS. 1 and 15, for example, the processing shown in FIG. 14 or FIG. Including. Each processing unit virtually realized on the CPU 150 does not always require that all processing units operate on the CPU 150, and only the processing unit used for processing needs to be virtually realized.

  Note that the generation program 170a is not necessarily stored in the HDD 170 or the ROM 160 from the beginning. For example, each program is stored in a “portable physical medium” such as a flexible disk inserted into the computer 100, so-called FD, CD-ROM, DVD disk, magneto-optical disk, or IC card. Then, the computer 100 may acquire and execute each program from these portable physical media. In addition, each program is stored in another computer or server device connected to the computer 100 via a public line, the Internet, a LAN, a WAN, etc., and the computer 100 acquires and executes each program from these. It may be.

DESCRIPTION OF SYMBOLS 10 Program production | generation apparatus 11 Communication path information storage part 12 Identification part 13 Generation part 14 Embedding part

Claims (6)

Computer
Communication path information including position information of a processor and a core executing a process, position information of a processor on which a memory is mounted, and information on an interface usable when accessing the memory from the core executing the process On the basis of parameters to be set in an API (Application Programming Interface) that transmits and receives data between processes via the memory,
Generate API code that operates with the specified parameters,
A multiprocessor program generation method, characterized in that, in a main processing program, a process of embedding a generated API code in an execution position of data transmission / reception between the processes is executed. The computer is
Virtual communication information including information of the memory accessed by the process in transmission / reception of data between the processes;
Physical location information of the task including location information of the processor and core executing the process;
Physical location information of the memory including location information of a processor in which the memory is mounted and interface information that can be used when accessing the memory;
Is accepted from the outside,
The multiprocessor according to claim 1, further comprising a process of generating the communication path information based on the received virtual communication information, the physical position information of the task, and the physical position information of the memory. Program generation method. The communication path information includes
Contains information on the minimum data size when the process accesses the memory;
In the process of specifying the computer,
When the minimum data size is equal to or greater than a predetermined value, interface information that can be used when accessing the memory from the core executing the process is transferred to an interface using hardware dedicated to data transfer. The multiprocessor program generation method according to claim 1, wherein the multiprocessor program generation method is changed.   4. The multiprocessor program generation method according to claim 3, wherein the interface using hardware dedicated to data transfer is DMA (Direct Memory Access). A first processor having a first core and a second core;
A second processor having a third core;
A data transmission unit for transmitting data from the first process to the second process;
A data receiving unit for receiving data transmitted from the first process to the second process;
The first process is executed in the first core;
The second process is executed on a predetermined core among the first core, the second core, or the third core;
The data transmitter is
Transmitting data using a predetermined interface in data transmission from the first process to the second process;
The data receiver is
A multiprocessor apparatus for receiving data using a predetermined interface in receiving data transmitted from the first process to the second process. A first processor having a first core and a second core;
A computer having a second processor having a third core;
Executing a first process on the first core;
Executing a second process on a predetermined core of the first core, the second core, or the third core;
Transmitting data from the first process to the second process using a predetermined interface in transmitting data from the first process to the second process;
Processing for receiving data transmitted from the first process to the second process by using a predetermined interface in receiving data transmitted from the first process to the second process Firmware for multiprocessors, characterized in that

Images