JP2018120307A - Accelerator processing management apparatus, host apparatus, accelerator processing execution system, method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To allow accelerator processing to be invoked in parallel by multiple tasks executed by multiple cores without considering exclusive control and allocation processing for shared resources and multiple accelerators on an application side.SOLUTION: An accelerator processing management apparatus comprises: an accelerator use state storage unit 131 storing use state information on each accelerator connected to multiple cores; an invocation data string generation unit 132 generating an invocation data string in response to an invocation of accelerator processing from a task, and storing it in a dedicated memory area for the task; an accelerator selection transfer unit 133 selecting the accelerator which is not in use based on the use state information, transferring the invocation data string, and updating the use state information on the accelerator; a response data string receiving unit 134 storing a response data string from the accelerator in the dedicated memory area for the invocation source task and updating the use state information on the accelerator; and a processing result output unit 135.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a system including a multi-core processor and a plurality of accelerators.

  Systems that include multi-core processors and multiple accelerators are known. The multi-core processor has a plurality of processor cores. Hereinafter, the processor core is also simply referred to as a core. The multi-core processor can operate different tasks in parallel in a plurality of cores. Note that processes and threads operating on a multi-core processor are collectively referred to as tasks. When a plurality of accelerators are connected to a multi-core processor, a plurality of tasks share a plurality of accelerators, thereby enabling load distribution.

  As an example of such an accelerator, there is a module in which analog signal processing such as radio and digital signal processing such as baseband signals are integrated into an IC (Integrated Circuit). Such a module is connected to an external bus or internal bus of a CPU (Central Processing Unit) and operates as a hardware accelerator.

  As described above, in a system in which a plurality of accelerators are connected to a multi-core processor via a bus, tasks that can be executed in parallel in the plurality of cores need to call the accelerator for each processing unit and perform data transfer. During data transfer, a main storage device such as a memory (hereinafter also referred to as a memory area) is used as a temporary output area. At this time, resources such as a memory area used for data transfer are generally shared by each task. Therefore, exclusive control is required for shared resources.

  When exclusive control for a shared resource is implemented in such a system, while a specific task occupies the resource, other tasks cannot access the resource, and thus the processing performance as a whole may deteriorate. In addition, processing overhead that occurs in connection with the exclusive control processing also causes a reduction in processing capability.

  Examples of techniques related to resource access by such a multi-core processor are disclosed in Patent Documents 1 and 2.

  In the related technology described in Patent Document 1, a dedicated memory area is prepared for each core, and tasks are dynamically allocated to the core according to the availability of the dedicated memory area. As a result, this related technology increases the efficiency of resource access performed in parallel by a plurality of tasks.

  Further, the related technology described in Patent Document 2 calculates a contention period in which threads operating on different cores generate access contention for shared resources. And this related technology is a thread assigned at the time when any one of the threads assigned in the calculated contention period is assigned, and at any time before or after the contention period in the core to which the thread is assigned. Swap the time. As a result, this related technique avoids access contention for resources and minimizes the overhead of exclusive processing.

  Furthermore, in a system in which a plurality of accelerators are connected to a multi-core processor via a bus, exclusive control and distribution processing for the accelerators are necessary. This is because each accelerator cannot accept another request while executing a process for a certain request. Then, a distribution process is required in which a process required for the accelerator from each task that can be executed in parallel is distributed to such a plurality of accelerators.

  Technologies related to a method for causing an accelerator to execute processing are disclosed in Patent Documents 3 to 4.

  The related technique described in Patent Document 3 provides a synchronization flag area in a system having a general-purpose processor and an accelerator. Then, when the flag indicating the completion of the process by the general-purpose processor is written in the synchronization flag area, the accelerator starts the acceleration process corresponding to the flag even if the general-purpose processor is executing another process. In addition, when the flag indicating the completion of the acceleration process is written in the synchronization flag area, the general-purpose processor starts the process corresponding to the flag even if the accelerator is executing another process. As described above, this related technology efficiently performs synchronization control by setting and checking the synchronization flag with each other by the general-purpose processor and the accelerator. In this related technique, a source code is analyzed by a parallelizing compiler, and a section in which the processor and the accelerator can operate in parallel is determined. And this related technique produces | generates the program using a synchronous flag separately for a processor and an accelerator regarding the area which can operate | move in parallel. Alternatively, the programmer analyzes the source code and generates the program as described above.

  Further, the related technology described in Patent Document 4 stores in a storage area program data obtained by integrating program data executed by an accelerator such as a GPU (Graphics Processing Unit) and scenario data indicating the program execution order. To enter. As a result, this related technique reduces the exchange of data performed between the CPU and the accelerator, and realizes efficient processing.

JP-A-2015-170270 International Publication No. 2012/014313 International Publication No. 2013/065687 Japanese Patent Laying-Open No. 2015-18379

  However, applying the related techniques described in Patent Documents 1 to 4 to a system including a multi-core processor and a plurality of accelerators has the following problems.

  The related technology described in Patent Document 1 outputs data in a dedicated memory area to a specific file system or database. If there are multiple output file systems and databases, the final output destination allocation must be performed on the application side. Therefore, when a plurality of accelerators are applied as output destinations in this related technology, it is necessary to program which accelerator is allocated to the accelerator process called from each task on the application side. As a result, there is a problem that the application program becomes complicated.

  Moreover, the related art described in Patent Document 2 eventually shares one resource among a plurality of cores. Therefore, complicated calculation for avoiding access competition for resources is required, and there is a problem in mounting ease. Further, when there are a plurality of output destinations, there is a problem similar to that of Patent Document 1 in that it is necessary to perform final output destination allocation on the application side.

  In the related technique described in Patent Document 3, it is necessary that the general-purpose processor program and the accelerator program are closely linked. For example, these programs need to be programmed with a common algorithm. Alternatively, these programs need to be generated by a common compiler. For example, a program that operates on an accelerator of a third-party product may be implemented on the third-party side, and only an API (Application Programming Interface) may be provided. In this case, it is difficult to apply this related technique in a system including a plurality of accelerators and multi-core processors.

  Further, although the related technique described in Patent Document 4 reduces the data exchange performed between the CPU and the accelerator, no consideration is given to the implementation in multicore or multitasking.

  As described above, in order to enable the accelerator processing to be invoked in parallel by a plurality of tasks, these related technologies must consider exclusive control and distribution processing for shared resources and a plurality of accelerators on the application side. There is a problem of not becoming.

  The present invention has been made to solve the above-described problems. In other words, the present invention is a technique that enables accelerator processing to be called in parallel by a plurality of tasks executed by a plurality of cores without considering exclusive control and distribution processing for shared resources and a plurality of accelerators on the application side. The purpose is to provide.

  The accelerator processing management apparatus according to the present invention stores usage status information representing usage status by tasks that can be executed in parallel by the plurality of processor cores for each of the plurality of accelerators connected to a multi-core processor including a plurality of processor cores. Accelerator usage status storage means for generating a call data string representing the call process according to the accelerator call process from the task, and generating the call data string for the task among a plurality of dedicated memory areas Call data string generating means for storing in the dedicated memory area, and when the call data string is stored in the dedicated memory area, one of the accelerators not in use is selected by referring to the accelerator usage status storage means Select the access Accelerator selection for transferring the call data string stored in the dedicated memory area to the accelerator and updating the usage status information of the accelerator in the accelerator usage status storage means to indicate that it is in use A transfer means, and a response data string received as a response to the call data string from the accelerator, is stored in the dedicated memory area for the call source task of the call processing, and the accelerator in the accelerator usage status storage means A response data string receiving means for updating the usage status information to indicate that it is not in use, and a call process for the task of the caller based on the response data string stored in the dedicated memory area Processing result output means for outputting results , Comprising a.

  A host device according to the present invention includes the accelerator processing management device described above, a memory region including the plurality of dedicated memory regions, and a multi-core processor including the plurality of processor cores.

  An accelerator processing execution system according to the present invention includes the above-described host device and the plurality of accelerators.

  Further, the method of the present invention is a usage status that represents a usage status of a plurality of accelerators connected to a multi-core processor including a plurality of processor cores by a task that can be executed in parallel by the plurality of processor cores. Using an accelerator usage status storage means for storing information, a call data string representing the call process is generated according to the accelerator call process from the task, and the generated call data string is stored in a plurality of dedicated memory areas. Is stored in the dedicated memory area for the task, and when the call data string is stored in the dedicated memory area, one of the accelerators that are not in use is selected by referring to the accelerator usage status storage means. For the selected accelerator, The call data string stored in the dedicated memory area is transferred, and the use status information of the accelerator in the accelerator use status storage means is updated to indicate that the accelerator is being used, and the call data is sent from the accelerator. The response data string received as a column response is stored in the dedicated memory area for the caller task of the call process, and the use status information of the accelerator in the accelerator use status storage means is not in use The call processing result is output to the caller task based on the response data string stored in the dedicated memory area.

  The program of the present invention stores usage status information representing usage status by tasks that can be executed in parallel by the plurality of processor cores for each of a plurality of accelerators connected to a multi-core processor including a plurality of processor cores. Using an accelerator usage status storage unit, a call data string representing the call process is generated according to the accelerator call process from the task, and the generated call data string is stored in the task in a plurality of dedicated memory areas. A call data string generating step for storing in a dedicated memory area for the memory, and when the call data string is stored in the dedicated memory area, one of the accelerators not in use is referred to by referring to the accelerator usage status storage means Select the selected access Accelerator selection for transferring the call data string stored in the dedicated memory area to the accelerator and updating the usage status information of the accelerator in the accelerator usage status storage means to indicate that it is in use A transfer step, and a response data sequence received as a response to the call data sequence from the accelerator is stored in the dedicated memory area for the task that is the call source of the call processing, and the accelerator usage status storage means A response data string receiving step for updating the use status information of the accelerator to indicate that it is not in use, and a call to the task of the caller based on the response data string stored in the dedicated memory area Processing to output the processing result Executing a result output step, to the computer device.

  The present invention provides a technology that enables accelerator processing to be called in parallel by a plurality of tasks executed on a plurality of cores without considering exclusive control and distribution processing on a shared resource or a plurality of accelerators on the application side. can do.

It is a block diagram which shows the structure of the accelerator process execution system as the 1st Embodiment of this invention. It is a figure which shows an example of the hardware constitutions of the accelerator process execution system as the 1st Embodiment of this invention. It is a flowchart explaining operation | movement of the accelerator process execution system as the 1st Embodiment of this invention. It is a block diagram which shows the structure of the accelerator process execution system as the 2nd Embodiment of this invention. It is a figure which shows an example of the software configuration which implement | achieves the accelerator process management apparatus in the 2nd Embodiment of this invention. It is a flowchart explaining operation | movement of the API library in the accelerator process management apparatus of the 2nd Embodiment of this invention. It is a flowchart explaining the operation | movement at the time of the API buffer manager transferring the call data sequence in the accelerator processing management apparatus of the 2nd Embodiment of this invention. It is a flowchart explaining the operation | movement at the time of the API buffer manager receiving the response data sequence in the accelerator processing management apparatus of the 2nd Embodiment of this invention. It is a figure explaining the specific example of the calling format of the API function in the 2nd Embodiment of this invention. It is a figure explaining the specific example of the usage status information in the 2nd Embodiment of this invention. It is a figure explaining the specific example of the call data sequence in the 2nd Embodiment of this invention. It is a figure explaining the specific example of the information stored in the exclusive memory area for transfer in the 2nd Embodiment of this invention. It is a figure explaining the specific example after the update of the usage condition information in the 2nd Embodiment of this invention. It is a figure explaining the specific example of the information stored in the exclusive memory area for reception in the 2nd Embodiment of this invention. It is a block diagram which shows the structure of the accelerator process management apparatus which is the minimum structure of embodiment of this invention. It is a block diagram which shows the structure of the host apparatus which is the other minimum structure of embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

(First embodiment)
First, FIG. 1 shows the configuration of an accelerator processing execution system 1 as a first embodiment of the present invention. In FIG. 1, the accelerator processing execution system 1 includes a host device 10 and a plurality of accelerators 20. The host device 10 includes a multi-core processor 110, a memory area 120, and an accelerator processing management device 130.

  The multi-core processor 110 includes a plurality of processor cores 111. Hereinafter, the processor core 111 is also simply referred to as the core 111. The memory area 120 includes a plurality of dedicated memory areas 121. The accelerator process management apparatus 130 includes an accelerator usage status storage unit 131, a call data sequence generation unit 132, an accelerator selection transfer unit 133, a response data sequence reception unit 134, and a processing result output unit 135.

  Although FIG. 1 shows three cores 111, four dedicated memory areas 121, and three accelerators 20, the number of these is not limited.

  Here, the accelerator processing execution system 1 can be configured by hardware elements as shown in FIG. In FIG. 2, the host device 10 includes a multi-core processor 110, an API (Application Programming Interface) memory 1002, a memory controller 1003, a code storage memory 1004, and a device connection interface 1005. As described above, the multi-core processor 110 includes a plurality of cores 111. The API memory 1002 stores data used by the accelerator processing management device 130. The API memory 1002 can be accessed from the multi-core processor 110 via the memory controller 1003. The memory controller 1003 controls input / output to the API memory 1002 and data arrangement. The code storage memory 1004 stores a code of a program for operating the accelerator processing management apparatus 130 and the like. The device connection interface 1005 is connected to a later-described device connection interface 2005 constituting the accelerator 20.

  In this case, the memory area 120 is configured by the API memory 1002. Further, the accelerator usage status storage unit 131 of the accelerator processing management apparatus 130 is configured by the API memory 1002. Each of the other functional blocks of the accelerator processing management apparatus 130 includes a multi-core processor 110 that reads the code of a program stored in the code storage memory 1004 and controls each hardware element.

  The accelerator 20 includes a processor 2001, an API memory 2002, a memory controller 2003, a code storage memory 2004, a device connection interface 2005, and an IP (Intellectual property) core block 2006. The API memory 2002 stores data used when the processor 2001 executes a process called from the host device 10. The API memory 2002 is accessible from the processor 2001 via the memory controller 2003. The memory controller 2003 controls input / output to the API memory 2002 and data arrangement. The code storage memory 2004 stores codes such as the firmware of the accelerator 20. The device connection interface 2005 is connected to the device connection interface 1005 of the host apparatus 10. The IP core block 2006 executes processing for realizing functions specific to the accelerator 20. The accelerator 20 reads and executes the firmware stored in the code storage memory 2004 by the processor 2001 and controls each unit.

  Note that the hardware configuration of the accelerator processing execution system 1 and each functional block thereof is not limited to the above-described configuration.

  Next, each functional block will be described.

  Each core 111 can execute a task in parallel with other cores 111. That is, the tasks executed in each core 111 can be executed in parallel. Hereinafter, a plurality of tasks that can be executed in parallel are also simply referred to as a plurality of tasks. In addition, other tasks that can be executed simultaneously with respect to a certain task are simply referred to as other tasks. Each task calls an accelerator process to be executed by the accelerator 20 at an arbitrary timing.

  A plurality of dedicated memory areas 121 are secured on the memory area 120. One dedicated memory area 121 is exclusively used by any of a plurality of tasks. Hereinafter, the dedicated memory area 121 used exclusively by a task is also referred to as a dedicated memory area 121 for the task. The dedicated memory area 121 for a certain task is determined not to be used for another task.

  For example, a different dedicated memory area 121 may be associated with each of a plurality of tasks. In this case, even when the core 111 assigned to each task is dynamically switched, each task does not share an area on the memory area 120 with other tasks. In this case, as many dedicated memory areas 121 as the number of tasks are secured on the memory area 120.

  Alternatively, it is assumed that any core 111 is statically assigned to a plurality of tasks. In this case, a different dedicated memory area 121 may be associated with each of the plurality of cores 111. As a result, in this case as well, each task uses the dedicated memory area 121 associated with the core 111 that is statically allocated to itself, and therefore does not share the area on the memory area 120 with other tasks. . In this case, dedicated memory areas 121 corresponding to the number of cores 111 are secured on the memory area 120.

  Next, details of each functional block of the accelerator processing management apparatus 130 will be described.

  The accelerator usage status storage unit 131 stores usage status information representing the usage status by the task for each of the plurality of accelerators 20. The usage status information indicates whether each accelerator 20 is in use, that is, whether the processing is being executed.

  The call data string generation unit 132 generates a call data string representing the call process according to the call process of the accelerator 20 from the task. Further, the call data string generation unit 132 stores the generated call data string in the dedicated memory area 121 for the task.

  When the call data string is stored in the dedicated memory area 121, the accelerator selection transfer unit 133 selects one of the accelerators 20 that is not in use by referring to the accelerator usage status storage unit 131. Further, the accelerator selection transfer unit 133 transfers the call data string stored in the dedicated memory area 121 to the selected accelerator 20. Further, the accelerator selection transfer unit 133 updates the usage status information of the selected accelerator 20 in the accelerator usage status storage unit 131 so as to indicate that it is being used.

  The response data string receiving unit 134 stores the response data string received as a response to the call data string from the accelerator 20 in the dedicated memory area 121 for the caller task of the call process. In addition, the response data string receiving unit 134 updates the usage status information of the accelerator 20 that is the transmission source of the response data string in the accelerator usage status storage unit 131 to indicate that it is not in use.

  The processing result output unit 135 outputs the call processing result to the caller task based on the response data string stored in the dedicated memory area 121.

  The accelerator 20 executes processing in response to a request from the host device 10 and returns a processing result to the host device 10. Specifically, when the accelerator 20 receives a call data string from the host device 10, the accelerator 20 executes a process based on the call data string. Then, the accelerator 20 transmits a response data string including a processing result to the host device 10.

  The operation of the accelerator processing execution system 1 configured as described above will be described with reference to FIG.

  In FIG. 3, the task executed in the multi-core processor 110 calls an accelerator process (step S1).

  Next, the call data string generation unit 132 of the accelerator process management device 130 generates and stores a call data string representing the call process in the dedicated memory area 121 for the caller task (step S2).

  Next, the accelerator selection transfer unit 133 of the accelerator process management device 130 refers to the accelerator usage status storage unit 131 to select one of the accelerators 20 that is not in use (step S3).

  Next, the accelerator selection transfer unit 133 of the accelerator processing management device 130 updates the usage status information of the selected accelerator 20 in the accelerator usage status storage unit 131 to indicate that it is in use (step S4).

  Next, the accelerator selection transfer unit 133 of the accelerator process management apparatus 130 transfers the call data string stored in step S2 to the accelerator 20 selected in step S3 (step S5).

  Next, the accelerator 20 executes processing based on the call data string (step S6).

  Next, the accelerator 20 transmits a response data string to the host device 10 (step S7).

  Next, when the response data string receiving unit 134 of the accelerator processing management apparatus 130 receives the response data string from the accelerator 20, the response data string receiving unit 134 stores the response data string in the dedicated task memory area 121 corresponding to the response data string. (Step S8).

  Next, the process result output unit 135 of the accelerator process management device 130 outputs the call process result to the caller task based on the response data string stored in the dedicated memory area 121 (step S9).

  Above, description of operation | movement of the accelerator process execution system 1 is complete | finished.

  Next, effects of the first exemplary embodiment of the present invention will be described.

  In the first embodiment of the present invention, an accelerator process is performed in parallel by a plurality of tasks executed by a plurality of cores without considering exclusive control and distribution processing for shared resources and a plurality of accelerators on the application side. Make callable.

  The reason will be described. In the present embodiment, a host device connected to a plurality of accelerators includes an accelerator process management device. In the accelerator processing management apparatus, the accelerator usage status storage unit stores usage status information indicating usage status by tasks that can be executed in parallel by a plurality of cores for each of the plurality of accelerators. Then, the call data string generation unit generates a call data string representing the call process in accordance with the accelerator call process from the task, and stores the generated call data string in the dedicated memory area for the task. Further, when the call data string is stored in the dedicated memory area, the accelerator selection transfer unit selects one of the accelerators that is not in use by referring to the accelerator use state storage unit. Then, the accelerator selection transfer unit transfers the call data string stored in the dedicated memory area to the selected accelerator. In addition, the accelerator selection transfer unit updates the accelerator usage status information in the accelerator usage status storage unit to indicate that the accelerator is being used. Further, the response data string receiving unit stores the response data string received as a response to the call data string from the accelerator in the dedicated memory area for the task that called the call process. Then, the response data string receiving unit updates the usage status information of the accelerator to indicate that it is not in use in the accelerator usage status storage unit. This is because the processing result output unit outputs the call processing result to the caller task based on the response data string stored in the dedicated memory area.

  As described above, the present embodiment requests processing from the accelerator via the dedicated memory area for each task that can be executed in parallel. As a result, this embodiment eliminates the need for exclusive control between tasks or between cores for resources used for transmission and reception with the accelerator. In the present embodiment, accelerator process call processing from a task is distributed to free accelerators using a dedicated memory area and an accelerator usage status storage unit. Therefore, if this embodiment is used, on the application side, it is not necessary to perform exclusive control for resources and accelerators and programming considering the accelerator destination.

(Second Embodiment)
Next, the configuration of the accelerator processing execution system 2 as the second exemplary embodiment of the present invention is shown in FIG. In FIG. 4, the accelerator processing execution system 2 is different from the accelerator processing execution system 2 in that a host device 30 is provided instead of the host device 10 as the first embodiment of the present invention. The host device 30 differs from the host device 10 according to the first embodiment of the present invention in that it includes a memory area 320 instead of the memory area 120. The memory area 320 includes a plurality of dedicated memory areas 321. Further, the difference is that an accelerator processing management device 330 is included instead of the accelerator processing management device 130.

  The accelerator process management device 330 includes an accelerator usage status storage unit 331, a call data sequence generation unit 332, an accelerator selection transfer unit 333, a response data sequence reception unit 334, and a process result output unit 335.

  Here, the accelerator processing execution system 2 and each functional block thereof can be configured by hardware elements similar to those of the first embodiment of the present invention described with reference to FIG. However, the hardware configuration of the accelerator processing execution system 2 and each functional block thereof is not limited to the above-described configuration.

  Next, among the functional blocks, a configuration different from the first embodiment of the present invention will be described.

  The memory area 320 includes a plurality of dedicated memory areas 321. Each of the plurality of dedicated memory areas 321 includes a transfer dedicated memory area 321T and a response dedicated memory area 321R. The dedicated memory areas 321T and 320R are assigned buffer numbers as identification information. Hereinafter, the dedicated memory areas 321T and 320R to which the buffer number i (i is 1 to n: n is the number of dedicated memory areas 321) are also referred to as dedicated memory areas 321Ti and 320Ri. A set of dedicated memory areas 321Ti and 320Ri is also collectively referred to as a dedicated memory area 321i.

  Note that the set of dedicated memory areas 321i is for any one task and is not for other tasks, as in the first embodiment of the present invention. Further, when a different set of different dedicated memory areas 321i are associated with each of the plurality of tasks, the dedicated memory areas 321Ti and 320Ri are secured by the number of tasks. In addition, when any one of the cores 111 is statically assigned to a plurality of tasks, and each of the plurality of cores 111 is associated with a different set of dedicated memory areas 321i, the dedicated memory areas 321Ti and 320Ri have a plurality of cores. The number of 111 is secured.

  The accelerator processing management device 330 implements each functional block with a software configuration as shown in FIG. 5, for example, by executing the code of the program stored in the code storage memory 1004. In FIG. 5, the software executed by the accelerator processing management device 330 includes an API library and an API buffer manager. The API library provides API functions to a host application executed by the core 111. The API library includes an API driver that operates when an API function is called, and a data link layer driver called from the API driver. The API buffer manager includes an interface to a driver that controls the device connection interface 1005 in order to transmit / receive data in the dedicated memory area 321 i to / from the accelerator 20.

  In this case, the call data string generation unit 332 and the processing result output unit 335 are configured by an API library. Further, the accelerator selection transfer unit 333 and the response data string reception unit 334 are configured by an API buffer manager. However, the software configuration in which the accelerator processing management device 330 realizes each functional block is not limited to the above-described configuration.

  Next, details of each functional block of the accelerator processing management apparatus 330 will be described.

  The accelerator usage status storage unit 331 stores the following information as usage status information indicating the usage status by the task for each of the plurality of accelerators 20. That is, when the accelerator 20 is in use, the accelerator usage status storage unit 331 stores the identification information (buffer number i) of the dedicated memory area 321i for the task that has requested the accelerator 20 to process. Further, the accelerator usage status storage unit 331 stores information indicating that the accelerator 20 is not in use when the accelerator 20 is not in use. For example, when the above-described buffer number is applied as usage status information when it is in use, the information indicating that it is not in use may be a value that does not correspond to the buffer number of any dedicated memory area 321i. For example, when buffer numbers 1 to n are assigned to n sets of dedicated memory areas 321i, information indicating that they are not in use may be represented by 0.

  The call data string generation unit 332 includes the identification information of the dedicated memory area 321i for the task in the call data string generated according to the calling process of the accelerator 20 from the task. For example, the call data string may include a buffer number i of the dedicated memory area 321i for the task, a request command for requesting processing to the accelerator 20, and a parameter of the request command.

  Note that the identification information of the dedicated memory area 321i for the task may be included in information representing the calling process from the task. That is, a call process defined to specify the identification information of the dedicated memory area 321i as one of the arguments may be provided as an API function. In this case, each task calls the accelerator process by specifying the buffer number i assigned to the dedicated memory area 321i for itself as an argument of the API function.

  It is also assumed that the call process includes a plurality of request commands. In this case, the call data string generation unit 332 generates a call data string for each request command.

  Further, the call data string generation unit 332 stores the generated call data string in the dedicated memory area 321Ti for the task that is the caller of the call process. As described above, it is assumed that the call process includes a plurality of request commands. In this case, the call data string generation unit 332 stores one call data string in the dedicated memory area 321Ti, and after the call data string is transferred, stores the next call data string in the dedicated memory area 321Ti. You can repeat that.

  When the call data string is stored in the dedicated memory area 321Ti, the accelerator selection transfer unit 333 stores the accelerator 20 associated with information (for example, 0 described above) indicating that it is not in use in the accelerator usage status storage unit 331. Select one of the following. Then, the accelerator selection transfer unit 333 updates the usage status information of the selected accelerator 20 in the accelerator usage status storage unit 331 to the buffer number i of the dedicated memory area 321Ti in which the call data string is stored. As a result, the buffer number i of the dedicated memory area 321i for the calling task is stored as the usage status information of the selected accelerator 20.

  Further, the accelerator selection transfer unit 333 transfers the call data string stored in the dedicated memory area 321Ti to the selected accelerator 20.

  The response data string receiving unit 334 stores the response data string received as a response to the call data string from the accelerator 20 in the dedicated memory area 321Ri for the task that is the caller of the call process. Also, the response data string receiving unit 334 updates the usage status information of the accelerator 20 that is the transmission source of the response data string so as to indicate that it is not in use in the accelerator usage status storage unit 331.

  Here, it is assumed that the response data string from the accelerator 20 includes the buffer number i of the dedicated memory area 321i for the calling task. That is, it is assumed that the accelerator 20 is configured to include the buffer number i included in the call data string in the response data string that responds to the call data string. For example, the response data string may include a buffer number i included in the call data string, a response command responding to the request command, and a processing result by the request command.

  Based on the response data string stored in the dedicated memory area 321i, the processing result output unit 335 outputs whether or not it is a normal response as a call processing result to the caller task. Here, the call process includes one or more request commands. Therefore, the processing result output unit 335 may output a normal response when all the processing results included in each of the response data strings corresponding to one or more request commands indicate normality. Further, the processing result output unit 335 may output that the response is not normal when the processing result included in at least one of the response data strings corresponding to one or more request commands does not indicate normality.

  The operation of the accelerator processing execution system 2 configured as described above will be described with reference to the drawings. Here, as described above, it is assumed that the call data string generation unit 332 and the processing result output unit 335 are configured by an API library. Further, it is assumed that the accelerator selection transfer unit 333 and the response data string reception unit 334 are configured by an API buffer manager.

  First, the operation of the API library is shown in FIG.

  In FIG. 6, first, the call data string generation unit 332 starts processing for the first request command defined by the API function, triggered by the API function call (step S101).

  Next, the call data string generation unit 332 generates a call data string including this request command (step S102).

  For example, the call data string is composed of a data string representing the buffer number i of the dedicated memory area 321 i for the caller task, the ID of the request command, and the parameter.

  Next, the call data string generation unit 332 stores the generated call data string in the caller task dedicated memory area 321Ti (step S103).

  Then, the API buffer manager operates when the call data string is stored in the dedicated memory area 321Ti. The operation of the API buffer manager will be described later. By the operation of the API buffer manager, the calling data string in the dedicated memory area 321Ti is transferred to one of the accelerators 20, and the response data string received from the accelerator 20 is stored in the dedicated memory area 321Ri.

  Next, the processing result output unit 335 determines whether or not reception of the response data string is notified from the API buffer manager (step S104). If not notified, the process waits for reception by repeating step S104.

  Next, when reception of the response data string is notified from the API buffer manager (Yes in Step S104), the processing result output unit 335 reads the response data string from the dedicated memory area 321Ri indicated by the notified information (Step S104). S105).

  Next, the processing result output unit 335 determines whether or not the processing result included in the response data string is normal (step S106).

  If it is determined that the processing result is normal (Yes in step S106), the processing result output unit 335 determines whether there is a next request command defined in the API function being executed (step S106). S107).

  If there is a next request command (Yes in step S107), the call data string generation unit 332 starts processing for the next request command (step S108).

  Then, the call data string generation unit 332 repeats the process from step S102.

  On the other hand, a case where it is determined in step S106 that the processing result is not normal will be described (No in step S106). In this case, the processing result output unit 335 outputs information indicating that it is not normal to the caller task (step S109), and ends the operation.

  A case where it is determined in step S107 that there is no next request command will be described (No in step S107). In this case, the processing result output unit 335 outputs information indicating that the processing result is normal to the calling task (step S110), and ends the operation.

  This is the end of the description of the API library operation.

  Next, the operation in which the API buffer manager transfers the call data string is shown in FIG.

  In FIG. 7, first, the accelerator selection transfer unit 333 initializes an index i indicating a buffer number (step S201). For example, when buffer numbers 1 to n are assigned to n dedicated memory areas 321, the index i is initialized to 1.

  Next, the accelerator selection transfer unit 333 determines whether the call data string is stored in the dedicated memory area 321Ti (step S202).

  Here, when the call data string is stored in the dedicated memory area 321Ti, the accelerator selection transfer unit 333 refers to the accelerator usage status storage unit 331 to determine whether there is an accelerator 20 that is not in use. (Step S203).

  Here, if there is an accelerator 20 that is not in use, the accelerator selection transfer unit 333 selects one accelerator 20 that is not in use (step S204).

  Next, the accelerator selection transfer unit 333 updates the usage status information of the selected accelerator 20 to the buffer number i in the accelerator usage status storage unit 331 (step S205).

  Next, the accelerator selection transfer unit 333 transfers the call data string stored in the dedicated memory area 321Ti to the selected accelerator 20 (step S206).

  Specifically, the accelerator selection transfer unit 333 may notify the device connection interface driver of the start pointer address of the dedicated memory area 321Ti, the size of the call data string, and the identification information of the selected accelerator 20. As a result, the call data string in the dedicated memory area 321Ti is transmitted to the selected accelerator 20.

  On the other hand, if it is determined in step S203 that there is no accelerator 20 that is not in use, the accelerator selection transfer unit 333 repeats step S203 until it is determined that there is an accelerator 20 that is not in use.

  A case will be described in which the transfer process to the accelerator 20 in step S206 is completed, or in the case where it is determined in step S202 that the call data string is not stored in the dedicated memory area 321Ti.

  In this case, the accelerator selection transfer unit 333 determines whether the index i is equal to or less than the maximum value n (step S207).

  Here, if i is n or less, the accelerator selection transfer unit 333 increments i by 1 and repeats the processing from step S202.

  On the other hand, if i exceeds n (No in step S208), the accelerator selection transfer unit 333 repeats the processing from step S201. That is, the index i is initialized, and the process is repeated again for all the dedicated memory areas 321Ti.

  This is the end of the description of the operation in which the API buffer manager transfers the call data string.

  Next, FIG. 8 shows an operation in which the API buffer manager receives the response data string.

  First, the response data string receiving unit 334 stores the response data string received from the accelerator 20 in the dedicated memory area 321Ri for the caller task of the call process corresponding to the response data string (step S301).

  As described above, the response data string from the accelerator 20 includes the buffer number i which is identification information of the dedicated memory area 321 for the caller task. Therefore, the response data string receiving unit 334 may store the response data string received from the accelerator 20 in the dedicated memory area 321Ri corresponding to the buffer number i included in the response data string.

  Next, the response data string receiving unit 334 searches the accelerator 20 in which the buffer number i included in the response data string is stored as usage status information in the accelerator usage status storage unit 331. Then, the response data string receiving unit 334 updates the searched usage status information of the accelerator 20 to information indicating that it is not in use (step S302).

  Next, the response data string receiving unit 334 notifies the API library that the response data string has been received in the dedicated memory area 321Ri (step S303). Specifically, the response data string receiving unit 334 may notify the head address of the dedicated memory area 321Ri. Thereby, in the API library, the operation from step S105 in FIG. 6 is executed.

  Above, description of operation | movement of the accelerator process execution system 2 is complete | finished.

  Next, the operation of the accelerator processing execution system 2 will be shown as a specific example.

  Here, it is assumed that the API_Func01 function is defined as an API function for calling an accelerator process by the API library. It is assumed that the API_Func01 function is defined to make a function call in the format illustrated in FIG. That is, the buffer number for the calling task is specified as the first argument. In this example, “0x0001” representing buffer number 1 is designated. In addition, a parameter setting value specific to the API_Func01 function is designated as the second argument. In this example, “0x0000” is designated as the setting value. The API_Func01 function defines a scenario in which a plurality of request commands are transmitted to the accelerator 20. Here, it is assumed that the API_Func01 function is defined to sequentially transmit the request command 0x0001 and the request command 0x0011 to the accelerator 20. The request command with the command ID “xxxxxxxx” is described as “request command xxxxxxxx”.

  Also, here, the identification information of each of the plurality of accelerators 20 is represented as “#x (x is a positive integer)”. Further, the accelerator 20 whose identification information is “#x” is also referred to as “accelerator 20 # x”.

  Here, it is assumed that usage status information is stored in the accelerator usage status storage unit 331 as shown in FIG. In this example, “0x0002” indicating that the accelerator 20 # 1 is being used by a task dedicated to the buffer number 2 is stored as usage status information. As the usage status of the accelerator 20 # 2, “0x0000” representing 0 which is not in use is stored as usage status information.

  Here, it is assumed that the device connection interfaces 1005 and 2005 for connecting the host device 30 and the accelerator 20 are SPI (Serial Peripheral Interface).

  First, in the API library, the call data string generation unit 332 starts processing for the first request command 0x0001 defined in the API_Func01 function scenario, triggered by the execution of the API_Func01 function (step S101 in FIG. 6).

  Next, the call data string generation unit 332 generates a call data string for the request command 0x0001 (step S102). Here, the generated call data string is as shown in FIG.

  Next, the call data string generation unit 332 stores the generated call data string in the dedicated memory area 321T1 indicated by the buffer number 0x0001 specified by the first argument of the API_Func01 function (step S103).

  Information stored in the dedicated memory area 321T1 is as shown in FIG.

  Then, the API buffer manager operates when the call data string is stored in the dedicated memory area 321T1.

  First, the accelerator selection transfer unit 333 determines that the call data string is stored in the dedicated memory area 321T1 (Yes in steps S201 and S202).

  Next, the accelerator selection transfer unit 333 refers to the accelerator usage status storage unit 331, and selects the accelerator 20 # 2 that is not in use (Yes in step S203, S204).

  Next, in the accelerator usage status storage unit 331, the accelerator selection transfer unit 333 updates the usage status information of the accelerator 20 # 2 from “0x0001” indicating that it is not in use to “0x0001” indicating the buffer number 1. (Step S205).

  Accordingly, the usage status information stored in the accelerator usage status storage unit 331 is as shown in FIG.

  Next, the accelerator selection transfer unit 333 notifies the SPI driver of the start pointer address and size of the dedicated memory area 321T1 and the identification information “# 2” of the selected accelerator 20 (step S206). As a result, the call data string in the dedicated memory area 321T1 is transmitted to the selected accelerator 20 # 2.

  Then, the accelerator 20 # 2 performs processing according to the instruction command 0x0001 included in the received call data string. As a result, a response data string is returned from the accelerator 20 # 2 to the host device 30 via the SPI. This response data string includes a buffer string 1, which is identification information of the dedicated memory area 321 for the caller task, the ID of the response command, and a data string representing the processing result. The SPI driver notifies the API buffer manager that the response data string has been received by an interrupt.

  Therefore, the response data string receiving unit 334 stores the received response data string in the dedicated memory area 321R1 corresponding to the buffer number “0x0001” included in the response data string. In this specific example, it is assumed that a response data string as shown in FIG. 14 is stored in the dedicated memory area 321R1.

  Next, the response data string receiving unit 334 searches the accelerator usage status storage unit 331 for the accelerator 20 associated with the buffer number “0x0001” included in the response data string as usage status information. Here, the accelerator 20 # 2 is searched. Therefore, the response data string receiving unit 334 updates the use status information of the searched accelerator 20 # 2 to “0x0000” representing 0 that is not in use (step S302).

  As a result, the usage status information stored in the accelerator usage status storage unit 331 is as shown in FIG.

  Next, the response data string receiving unit 334 notifies the API library of the start address of the dedicated memory area 321R1 (step S303).

  Therefore, in the API library, the processing result output unit 335 reads the response data string from the dedicated memory area 321R1 of the notified address (step S105).

  Next, it is assumed that the processing result output unit 335 determines that the processing result is normal based on the response data string (Yes in step S106).

  Therefore, next, the processing result output unit 335 determines that there is a next request command 0x0011 defined in the API_Func01 function being executed (Yes in step S107).

  Therefore, the call data string generation unit 332 starts processing for the next request command 0x0011 (step S108).

  Then, the call data string generation unit 332 repeats the process from step S102.

  Steps S102 to S103, S201 to S206, S301 to S303, and S105 are executed in substantially the same manner as in the case of the instruction command 0x0001. Here, it is assumed that the processing result of the response data string for the instruction command 0x0011 is also normal (Yes in step S106).

  Next, the processing result output unit 335 determines that there is no next request command defined in the API_Func01 function being executed (No in step S107).

  Therefore, the processing result output unit 335 outputs information indicating that the processing result is a normal response to the caller task (step S110).

  Above, description of the specific example of operation | movement of the accelerator process execution system 2 is complete | finished.

  Next, the effect of the second exemplary embodiment of the present invention will be described.

  The second embodiment of the present invention is more efficient in parallel with a plurality of tasks executed by a plurality of cores without considering exclusive control and distribution processing for shared resources and a plurality of accelerators on the application side. To make the accelerator process callable.

  The reason will be described. This is because the present embodiment is configured as follows in addition to the same configuration as that of the first embodiment of the present invention. That is, the dedicated memory area includes a dedicated memory area for transfer and a dedicated memory area for response. Then, the call data string generation unit stores the call data string in the dedicated memory area for transfer for the caller task. This is because the accelerator selection transfer unit operates when the call data string is stored in the dedicated memory area for transfer. In addition, the response data string receiving unit stores the response data string in a dedicated memory area for response for the caller task. This is because the processing result output unit operates based on the response data string stored in the response dedicated memory area.

  As described above, since the present embodiment operates depending on whether the data string is stored in the dedicated memory area for transfer or response, the dedicated memory area that does not require exclusive control of resources is It can be used efficiently.

  A further reason will be described. In the present embodiment, the call data string generation unit generates the call data string including the identification information of the dedicated memory area for the caller task. Further, the accelerator selection transfer unit updates the usage status information of the selected accelerator to the identification information of the dedicated memory area included in the call data sequence to be transferred, thereby indicating that the accelerator is being used. Further, the response data string receiving unit stores the response data string in the dedicated memory area indicated by the identification information included in the response data string, and uses the accelerator usage status information in which the identification information is stored as usage status information. This is because it is updated to indicate that it is not in the middle.

  As a result, each functional block can easily identify the call source task of the call process based on the identification information of the dedicated memory area included in the call data string, the response data string, or the usage status information, and efficiently. Can perform actions.

  As a result, this embodiment eliminates the need for exclusive control between tasks or cores for memory when processing is requested from the accelerator via a dedicated memory area for each task that can be executed in parallel. Processing can be performed more efficiently. In addition, according to the present embodiment, it is possible to more efficiently perform the process of allocating the accelerator process from the task to the free accelerator using the dedicated memory area and the accelerator usage status storage unit. . Therefore, if this embodiment is used, on the application side, it is not necessary to perform exclusive control for resources and accelerators and programming considering the accelerator destination.

  Next, FIG. 15 shows an accelerator processing management apparatus 130 which is the minimum configuration of the embodiment of the present invention. In FIG. 15, the accelerator processing management device 130 includes an accelerator usage status storage unit 131, a call data sequence generation unit 132, an accelerator selection transfer unit 133, a response data sequence reception unit 134, and a processing result output unit 135. .

  The accelerator processing management device 130 is included in a host device having a multi-core processor. The multi-core processor is connected to a plurality of accelerators outside the host device.

  Each functional block of the accelerator processing management apparatus 130 is configured as described in the first embodiment of the present invention, and operates as described with reference to FIG.

  Thereby, the accelerator processing management device 130 which is the minimum configuration of the embodiment of the present invention has the following effects by being included in a host device including a multi-core processor connected to a plurality of accelerators. That is, the accelerator process management device 130 enables parallel accelerator process calls by a plurality of tasks that can be executed in parallel by a plurality of cores. In addition, there is an advantage that the application side does not need to consider exclusive control and distribution processing for resources and accelerators.

  Further, FIG. 16 shows a host apparatus 10 having another minimum configuration according to the embodiment of the present invention. In FIG. 16, the host device 10 includes a plurality of cores 111, a plurality of dedicated memory areas 121, and an accelerator processing management device 130. The host device 10 is connected to a plurality of external accelerators.

  Each functional block of the host device 10 is configured as described in the first embodiment of the present invention. Then, the accelerator processing management device 130 operates in the host device 10 as described with reference to FIG.

  Thereby, the host device 10 which is another minimum configuration of the embodiment of the present invention has the following effects when connected to a plurality of accelerators. In other words, the host device 10 enables parallel accelerator processing to be called by a plurality of tasks that can be executed in parallel by a plurality of cores. In addition, there is an advantage that the application side does not need to consider exclusive control and distribution processing for resources and accelerators.

  In the above-described second embodiment of the present invention, the example in which the SPI is applied as the device connection interface for connecting the host device and the accelerator has been described. However, the present invention is not limited to this. For example, the device connection interface may be a system bus such as PCI (Peripheral Component Interconnect) or Ethernet (registered trademark).

  Further, in each of the embodiments of the present invention described above, the memory for securing the dedicated memory area may be constituted by, for example, a volatile RAM (Random Access Memory).

  Further, in each of the above-described embodiments, as an accelerator, for example, an application-specific IC (Integrated Circuit) such as a wireless module can be applied. For example, a DSP (Digital Signal Processor), an FPGA (field-programmable gate array), or the like may be applied as the accelerator.

  Further, in each of the above-described embodiments of the present invention, the example in which each functional block of the accelerator processing management apparatus is realized by a processor that executes a program stored in a memory has been described. However, the present invention is not limited to this, and some, all, or a combination of each functional block may be realized by dedicated hardware.

  In each of the embodiments of the present invention described above, the operation of the accelerator processing management apparatus described with reference to the flowcharts is stored in the storage device (storage medium) of the computer apparatus as the computer program of the present invention. . Then, the computer program may be read and executed by the CPU. In such a case, the present invention is constituted by the code of the computer program or a storage medium.

  Moreover, each embodiment mentioned above can be implemented in combination as appropriate.

  The present invention is not limited to the above-described embodiments, and can be implemented in various modes.

1, 2 Accelerator processing execution system 10, 30 Host device 20 Accelerator 110 Multi-core processor 111 Core 120, 320 Memory region 121, 321 Dedicated memory region 130, 330 Accelerator processing management device 131, 331 Accelerator usage status storage unit 132, 332 Call data Sequence generation unit 133, 333 Accelerator selection transfer unit 134, 334 Response data sequence reception unit 135, 335 Processing result output unit 2001 Processor 1002, 2002 API memory 1003, 2003 Memory controller 1004, 2004 Code storage memory 1005, 2005 Device connection interface 2006 IP core block

Claims (8)

Accelerator usage status storage means for storing usage status information representing usage status by tasks that can be executed in parallel by the plurality of processor cores for each of a plurality of accelerators connected to a multi-core processor including a plurality of processor cores;
In response to the accelerator call process from the task, a call data string representing the call process is generated, and the generated call data string is stored in a dedicated memory area for the task among a plurality of dedicated memory areas Data string generation means;
When the call data string is stored in the dedicated memory area, one of the accelerators that are not in use is selected by referring to the accelerator usage status storage unit, and the selected accelerator is stored in the dedicated memory area. An accelerator selection transfer means for transferring the stored call data string and updating the accelerator usage status information in the accelerator usage status storage means to indicate that the accelerator is being used;
The response data sequence received as a response to the call data sequence from the accelerator is stored in the dedicated memory area for the call source task of the call processing, and the usage status of the accelerator in the accelerator usage status storage means A response data string receiving means for updating the information to indicate that the information is not in use;
Based on the response data string stored in the dedicated memory area, processing result output means for outputting a call processing result to the task of the caller;
Accelerator processing management device. When the dedicated memory area consists of a dedicated memory area for transfer and a dedicated memory area for response,
The call data string generation means stores the generated call data string in the dedicated memory area for transfer for the caller task,
The accelerator selection transfer means operates when the call data string is stored in the dedicated memory area for transfer,
The response data string receiving means stores the response data string in the response dedicated memory area for the caller task,
The accelerator processing management apparatus according to claim 1, wherein the processing result output unit operates based on a response data string stored in the dedicated memory area for the response. The call data string generation means generates the call data string including identification information of the dedicated memory area for the caller task,
When the response data string includes the identification information of the dedicated memory area of the caller task, the response data string receiving means stores the response data in the dedicated memory area indicated by the identification information included in the response data string. The accelerator processing management apparatus according to claim 1, wherein the accelerator processing management apparatus stores a column. The accelerator usage status storage means stores, as the usage status information, identification information of the dedicated memory area for the task that is calling the process being executed by the accelerator for each of the accelerators in use,
The accelerator selection transfer means updates the usage status information of the selected accelerator to identification information of the dedicated memory area in which a call data string to be transferred to the selected accelerator is stored,
The response data string receiving unit updates the usage status information of the accelerator in which the identification information of the dedicated memory area in which the response data string is stored is stored as the usage status information to information indicating that the accelerator is not in use. The accelerator process management apparatus according to claim 1, wherein the accelerator process management apparatus is any one of claims 1 to 3. The accelerator process management device according to any one of claims 1 to 4,
A memory area including the plurality of dedicated memory areas;
A multi-core processor including the plurality of processor cores;
Host device with A host device according to claim 5;
The plurality of accelerators;
Accelerator processing execution system with Computer equipment
For each of a plurality of accelerators connected to a multi-core processor including a plurality of processor cores, using an accelerator usage status storage unit that stores usage status information indicating usage status by tasks that can be executed in parallel by the plurality of processor cores ,
In response to the accelerator call process from the task, generate a call data string representing the call process, store the generated call data string in a dedicated memory area for the task among a plurality of dedicated memory areas,
When the call data string is stored in the dedicated memory area, one of the accelerators that are not in use is selected by referring to the accelerator usage status storage unit, and the selected accelerator is stored in the dedicated memory area. Transferring the stored call data string, and updating the use status information of the accelerator in the accelerator use status storage means to indicate that it is in use;
The response data sequence received as a response to the call data sequence from the accelerator is stored in the dedicated memory area for the call source task of the call processing, and the usage status of the accelerator in the accelerator usage status storage means Update the information to indicate that it is not in use,
A method for outputting a call processing result to the caller task based on the response data string stored in the dedicated memory area. For each of a plurality of accelerators connected to a multi-core processor including a plurality of processor cores, using an accelerator usage status storage unit that stores usage status information indicating usage status by tasks that can be executed in parallel by the plurality of processor cores ,
In response to the accelerator call process from the task, a call data string representing the call process is generated, and the generated call data string is stored in a dedicated memory area for the task among a plurality of dedicated memory areas A data string generation step;
When the call data string is stored in the dedicated memory area, one of the accelerators that are not in use is selected by referring to the accelerator usage status storage unit, and the selected accelerator is stored in the dedicated memory area. Transferring the stored call data sequence, and updating the accelerator selection transfer step of updating the accelerator usage status information in the accelerator usage status storage means to indicate that it is in use;
The response data string received as a response to the call data string from the accelerator is stored in the dedicated memory area for the task that is the caller of the call process, and the use of the accelerator in the accelerator usage status storage unit A response data string receiving step for updating the status information to indicate that it is not in use;
Based on the response data string stored in the dedicated memory area, a process result output step for outputting a call process result to the caller task;
That causes a computer device to execute the program.

Images