FPGA system

Abstract

An FPGA (2a) is provided with: a reconfigurable circuit area (31); an access reception unit (23) which transfers, to function circuits (20-0, 20-1) built in the circuit area (31), data to be processed that is included in a function use request from a client, and returns the processing result to the client; and a function token table (24) which stores function IDs that are identification information of each portion of the circuit area (31), function names that represent the functions of the function circuits (20-0, 20-1), and tokens that are identification information of the function circuits (20-0, 20-1), in association with each other.

Description

Technical Field

[0001] The present invention 、F relates to an FPGA system that performs data processing using PGA.

Background Art

[0002] Conventional data centers have adopted an architecture centered around a CPU (Central Processing Unit). However, in recent years, since the performance improvement of CPUs has slowed down, data centers incorporating accelerators other than CPUs have emerged to meet the performance requirements of applications. Among them, an accelerator called FPGA (Field Programmable Gate Array) has attracted attention because (I) it has the characteristic that the internal configuration can be flexibly changed, and (II) it incorporates a network transceiver inside.

[0003] There is an FPGA manager as a software-based component for efficiently controlling an FPGA accelerator in a data center (see Non-Patent Document 1). The operation of the FPGA manager mainly aims at managing the circuits of the FPGA defined by the client on the host device and controlling access from the application executed by the client on the host device to the circuits inside the FPGA.

[0004] The operation of the FPGA manager will be described with reference to FIG. 6 below. The client installs the created application program on the host device 1. The FPGA manager 10 installed on the host device 1 creates bitstream data for defining a function circuit that realizes the function to be processed by the FPGA 2 among the processes executed by the application execution unit (App). The FPGA manager 10 incorporates the function circuit 20 into the FPGA 2 by transmitting the bitstream data to the FPGA 2.

[0005] The host device 1 and the FPGA 2 are connected by PCIe (PCI Express) interface units 11 and 21. When the App causes the FPGA 2 to execute processing, it calls the runtime 12, which is a program for using the function circuit 20. The runtime 12 requests processing from the function circuit 20 in the FPGA 2 via the PCIe interface units 11 and 21. The function circuit 20 returns the result of the requested processing to the runtime 12. The runtime 12 passes the processing result to the App. Data transfer between the host device 1 and the FPGA 2 is performed by DMA transfer by the DMA bridge controller 22.

[0006] In a conventional FPGA manager, when there is a function usage request from a client connected to the host device via a network, the request needs to be taken into the host device once, resulting in an increase in execution delay.

[0007] The operation of the FPGA manager when there is a request from the client will be described with reference to FIG. 7. The client terminal 3 connected to the host device 1 via the network needs to access the access reception unit 14 outside the FPGA manager 10 via the network interface unit 13 of the host device 1. The access reception unit 14 operates asynchronously with the App. Therefore, it is necessary to interrupt the App from the access reception unit 14 or perform polling in which the App inquires of the access reception unit 14 when accessing from the client terminal 3.

[0008] By means of interruption or polling, when the App detects the arrival of a function usage request from the client terminal 3, it calls the runtime 12 to activate the function circuit 20 in the FPGA 2. The App returns the processing result by the function circuit 20 to the client terminal 3 as a response to the request.

[0009] When attempting to directly start the function circuit 20 from the network and execute processing, the execution path cannot be controlled by the FPGA manager 10. For this reason, flexible circuit rewriting, execution right management, etc. become impossible. Therefore, as shown in FIG. 7, it is necessary to provide the access reception unit 14 in the host device 1, but the intervention of the access reception unit 14 increases the execution delay of the processing.

Prior Art Documents

Non-Patent Documents

[0010]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0011] The present invention has been made to solve the above problems, and can execute processing without extra delay in response to a function use request from a client. F An object is to provide a PGA system.

Means for Solving the Problems

[0012] The FPGA of the present invention System is comprising an FPGA and a host device, wherein the FPGAA reconfigurable circuit area, an access reception unit configured to transfer data to be processed included in a function use request from a client to a function circuit constructed in the circuit area and return a processing result by this function circuit to the client, a function ID which is identification information for each part of the circuit area, a function name representing the function of the function circuit, and a table in which a token which is identification information of the function circuit are stored in association with each other, and the access reception unit specifies a function circuit to which the data to be processed is to be transferred based on the contents stored in the table, the function name, and the token included in the function use request and the host device is configured to generate a token to be assigned to the function for which the utilization application has been made when receiving a resource request for the utilization application of a function from the client before the function usage requirement, and transmit the generated token and the function name representing the function for which the utilization application has been made to the FPGA and the client, and comprises an application execution unit It is characterized by this.

[0013] Also In one configuration example of the FPGA system of the present invention, the application execution unit is characterized by generating different tokens for each client. Also, in one configuration example of the FPGA system of the present invention, the FPGA further includes a controller configured to write the function name and the token received from the application execution unit into the table and return a function ID assigned to the row of the written table to the application execution unit. Also, in one configuration example of the FPGA system of the present invention, the host device further includes a function circuit management unit configured to transmit bitstream data for reconfiguring the function circuit to the FPGA corresponding to the contents stored in the table.

[0014] In addition, in one configuration example of the FPGA system of the present invention, when the function circuit management unit receives the resource request from the client, it transmits bitstream data for reconfiguring the function circuit corresponding to the content stored in the table to the FPGA, and when receiving a resource release notification from the client, it transmits bitstream data for returning the function circuit to an undefined state to the FPGA. In addition, in one configuration example of the FPGA system of the present invention, the FPGA further includes a network interface unit for communicating with the client via a network, and the access acceptance unit receives a function usage request from the client via the network interface unit and returns a processing result by the function circuit to the client via the network interface unit. In addition, in one configuration example of the FPGA system of the present invention, the application execution unit transmits a function usage request from the client to the FPGA, returns a processing result received from the FPGA to the client, and the access acceptance unit receives the function usage request from the application execution unit and returns a processing result by the function circuit to the application execution unit.

Advantages of the Invention

[0015] According to the present invention, by providing an access acceptance unit in the FPGA, the client can cause the function circuit of the FPGA to process data without accessing the host device only by transmitting a function usage request to the FPGA. As a result, the client can obtain a processing result without unnecessary delay.

Brief Description of the Drawings

[0016]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0017] [First Embodiment] Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram showing the configuration of an FPGA system according to the first embodiment of the present invention. The FPGA 2a of this embodiment has an access reception unit 23. In the conventional configuration shown in FIG. 7, an access reception unit 14 for responding to a function use request from a client was provided in the host device 1. On the other hand, in this embodiment, the access reception unit 23 is mounted on the board of the FPGA 2a.

[0018] The access reception unit 23 interprets a function use request received from the client terminal 3 via the network interface unit 25 of the FPGA 2a, and transmits the function use request to appropriate function circuits 20-0 and 20-1 based on the result of the interpretation. The access reception unit 23 returns the processing result by the function circuits 20-0 and 20-1 to the client terminal 3 that is the request source as a response to the function use request.

[0019] Also, when the access reception unit 23 receives a function usage request from the application execution unit (App) implemented in the host device 1a, it similarly interprets the function usage request and transmits the function usage request to appropriate function circuits 20-0 and 20-1 based on the result of the interpretation. The access reception unit 23 returns the processing result by the function circuits 20-0 and 20-1 to the requesting App as a response to the function usage request.

[0020] The FPGA manager 10a of the host device 1a has a function circuit management unit 15. In the configuration of the conventional FPGA system shown in FIG. 7, a part of the processing executed by the App was executed by the function circuit 20 of the FPGA 2. On the other hand, in this embodiment, it is also assumed that the client terminal 3 issues a function usage request to the function circuits 20-0 and 20-1 of the FPGA 2a, and the App and the function management are separated.

[0021] Before execution, the App registers the function it wants to execute in the function token table 24 of the FPGA 2a. The function circuit management unit 15 reads out the bitstream data corresponding to the content registered in the function token table 24 from the previously prepared bitstream data. The function circuit management unit 15 transmits the bitstream data to the FPGA 2a. The bitstream data is written into the configuration memory 26 of the FPGA 2a. As a result, the circuit area 31 of the FPGA 2a is reconfigured, and the function circuits 20-0 and 20-1 are constructed in the circuit area 31. The device file 16 will be described in the second embodiment.

[0022] FPGA2a has a function token table 24 in which function IDs, function names, and tokens are stored. The function ID is an identification number for each part of the reconfigurable circuit area 31 of FPGA2a. For example, even if it is a function circuit that realizes the same function, different function IDs are assigned when it is written to different parts of the circuit area 31.

[0023] The function name is a name representing the function of the function circuit. The function name is managed by the function circuit management unit 15 of the host device 1a. For example, in the example of FIG. 1, the function name is "grayscale". This example shows that the function circuit performs grayscale processing on data.

[0024] The client issues a function usage request by specifying the function circuit to be used. A token, which is an identifier for specifying the function circuit, is added to the function usage request. In the example of FIG. 1, the token of the function circuit with function ID "0" is "hoge", and the token of the function circuit with function ID "1" is "fuga".

[0025] Next, the operation of the FPGA system of this embodiment will be described. The developer of the FPGA system develops the functions of FPGA2a to be provided to the client, and stores the bitstream data for defining the function circuit that realizes the functions in the function circuit management unit 15 of the host device 1a.

[0026] A client who wants to use the functions of FPGA2a applies to the developer of the FPGA system to use the desired functions using the client terminal 3. The developer who has received the application starts the App of the host device 1a.

[0027] The started App generates a token to be assigned to the function for which an application was made from the client, and transmits the function name representing the function for which an application was made from the client and the generated token to FPGA2a. Note that the App generates different tokens even if the functions for which application requests were made are the same but the clients are different.

[0028] The DMA bridge controller 22 of FPGA2a writes the function name and token received from the App into the function token table 24. Then, the DMA bridge controller 22 returns the function ID assigned to the row of the function token table 24 in which the function name and token were written as a response to the App.

[0029] The App notifies the function circuit management unit 15 of the function ID received from FPGA2a and the function name representing the function for which an application was made from the client. The function circuit management unit 15 reads out the bitstream data corresponding to the function name from the pre-registered bitstream data. The function circuit management unit 15 transmits the read bitstream data to FPGA2a to write it into the area of the configuration memory 26 corresponding to the function ID received from the App.

[0030] When the bitstream data is written into the area of the configuration memory 26 corresponding to the function ID via the DMA bridge controller 22 of FPGA2a, the circuit area 31 of FPGA2a corresponding to the function ID is reconfigured, and a function circuit corresponding to the function ID and the function name is constructed.

[0031] The DMA bridge controller 22 returns a circuit write completion notification as a response to the function circuit management unit 15. The function circuit management unit 15 passes the circuit write completion notification to the App.

[0032] Upon receiving the circuit writing completion notice, the App notifies the client terminal 3 of the resource requester of the completion of resource allocation via the network interface unit 13 of the host device 1a. This resource allocation completion notice is appended with the function name representing the function for which the client has made a request and the token assigned to the function for which the client has made a request.

[0033] Upon receiving the resource allocation completion notice, the client uses the client terminal 3 to send a function usage request to the FPGA 2a. The function usage request is appended with the function name and token notified by the App and the data to be processed.

[0034] The access reception unit 23 of the FPGA 2a interprets the function usage request received from the client terminal 3 via the network interface unit 25 of the FPGA 2a. Based on the content stored in the function token table 24 and the function name and token included in the function usage request, the access reception unit 23 identifies the function circuit to which the data to be processed included in the function usage request should be transferred. The access reception unit 23 transfers the data to be processed to the identified function circuit.

[0035] For example, when the function name is "grayscale" and the token is "hoge", the data to be processed is transferred to the function circuit 20-0 to which the function ID "0" is assigned. The access reception unit 23 returns the processing result by the function circuit 20-0 to the client terminal 3 of the requester as a response to the function usage request.

[0036] Upon receiving the processing result of the data, the client terminal 3 sends a usage completion notice to the App. The App that has received the notification of completion of use from the client terminal 3 via the network interface unit 13 of the host device 1a requests the FPGA 2a to delete the function name and token corresponding to the function that has finished being used from the function token table 24.

[0037] The DMA bridge controller 22 of the FPGA 2a deletes the row containing the function name and token specified by the App from the function token table 24. Then, the DMA bridge controller 22 returns the function ID assigned to the deleted row as a response to the App.

[0038] The App notifies the function circuit management unit 15 of the function ID received from the FPGA 2a. The function circuit management unit 15 transmits to the FPGA 2a the bitstream data for deleting the function circuit to be written into the area of the configuration memory 26 corresponding to the function ID received from the App.

[0039] When the bitstream data is written into the area of the configuration memory 26 corresponding to the function ID via the DMA bridge controller 22 of the FPGA 2a, the circuit area 31 of the FPGA 2a corresponding to the function ID returns to an undefined state. Thus, the operation of the FPGA system ends.

[0040] In this embodiment, once the client has completed the settings, it can cause the function circuit of the FPGA 2a to process data without accessing the host device 1a. That is, the client can execute the process without any unnecessary delay.

[0041] In a conventional FPGA manager, since the App manages the FPGA, it was necessary to share the App among multiple clients in a time-division manner. On the other hand, in this embodiment, by assigning different tokens to each client and using different circuit regions, multiple clients can use the FPGA2a simultaneously, and the utilization efficiency when sharing the FPGA2a among multiple clients can be improved. The improvement in the utilization efficiency of the FPGA2a leads to an improvement in the utilization efficiency of the services provided by the FPGA system, which is beneficial to the developers operating the FPGA system in terms of profitability.

[0042] Also, conventionally, the access reception unit was provided in the host device. Therefore, when the function circuit of the FPGA executes processing in response to a function usage request from the client, the memory of the host device, the CPU of the host device, and the FPGA are used, resulting in an increase in power consumption. In this embodiment, by providing the access reception unit 23 in the FPGA2a, the host device 1a is not used when the function circuit of the FPGA executes processing in response to a function usage request from the client, so the power consumption of the system can be reduced.

[0043] Also, in this embodiment, except when the function circuit of the FPGA2a executes processing in response to a usage application from the client, the function circuit is set in an undefined state, so standby power of the function circuit does not occur, and the power consumption of the FPGA2a can be reduced. Also, in this embodiment, since a vendor-dependent runtime is not used, the FPGA system does not depend on the technology of a specific vendor.

[0044] [Second Embodiment] Next, a second embodiment of this example will be described. FIG. 2 is a block diagram showing the configuration of an FPGA system according to the second embodiment of the present invention. In this embodiment, Kubernetes is used as the platform for constructing the FPGA system. Regarding Kubernetes, it is disclosed, for example, in the document "Kubernetes Documentation", Linux Foundation (registered trademark), 2021, <https: / / kubernetes.io / ja / docs / home / >. Hereinafter, Kubernetes will be abbreviated as K8s.

[0045] The K8s master node 4 and the K8s worker node 5 of the host device 1b constitute the App of the first embodiment.

[0046] The K8s master node 4 acts on the Kubelet 51 of the K8s worker node 5 via the API (Application Programming Interface) server 40. Specifically, the K8s master node 4 performs communication with the client, management of access tokens, and startup / delete requests for the Function Manager Pod 50.

[0047] The K8s worker node 5 includes a function manager pod 50, a Kubelet 51 that manages the function manager pod 50, a device plugin 52 in which the function manager pod 50 is described, a device file 53, and a memory area 54.

[0048] In FIG. 2, there is one FPGA 2b, but a plurality of function manager pods 50, a plurality of device plugins 52, and a plurality of FPGA 2bs are associated with one K8s worker node 5.

[0049] Part of the function manager pod 50 corresponds to the function circuit management unit 15 of the first embodiment. The function manager pod 50 includes a plurality of containers. In this embodiment, it includes three containers 500 to 502. The function manager pod 50 is activated for each usage application from the client.

[0050] The container 500 writes the function name representing the function for which an application has been made from the client and the token assigned to the function for which an application has been made from the client to the function token table 24 of the FPGA 2b via the DMA bridge controller 22. Also, the container 500 deletes the function name and token corresponding to the function whose usage has ended from the function token table 24.

[0051] The container 501 manages the bitstream data 503 for reconfiguring the circuit area 31 of the FPGA 2b, manages the rewriting operation of the circuit area 31, and monitors the function token table 24. This container 501 constitutes the function circuit management unit 15 of the first embodiment.

[0052] The container 502 is a container for the client on the host device side to log in and control the FPGA 2b for which the settings have been completed.

[0053] The device file 53 (device file 16 of the first embodiment) is a file that serves as an interface with the FPGA 2b connected to the K8s worker node 5. The device file 53 includes a device file 530 for exchanging bitstream data and a device file 531 for controlling the FPGA 2b. The device file 53 exists for each FPGA 2b. There may be a plurality of device files 53 in the function manager pod 50.

[0054] In the case of Kubernetes, the configuration information within the pod 50 is described in the device plugin 52. The configuration within the pod 50 operates via the kubelet 51 at startup. At this time, the FPGA - specific resources are generated in the memory area 54. In the example of Figure 2, as resources, there is an empty directory. The name of this directory is function name_function ID. Also, although it is shown as an empty directory in Figure 2, it could also be a list with the function name and function ID noted down.

[0055] The DMA bridge controller 22 of FPGA2b connects FPGA2b and the host device 1b. The DMA bridge controller 22 issues a session ID as a side channel.

[0056] The TOE (TCP / IP offload engine) 27 of FPGA2b manages the transport protocol of the packets sent from the network. In this embodiment, TCP / IP (Transmission Control Protocol / Internet Protocol) is taken as an example of the communication protocol between the internet layer and the transport layer for explanation, but the communication protocol is not limited to TCP / IP. The TOE 27 issues a session ID as a side channel. The session IDs issued by the TOE 27 and the DMA bridge controller 22 do not overlap.

[0057] The switch 28 selects the output direction of the data according to whether the input data is a request or a response to a request. The HTTP (Hypertext Transfer Protocol) parser 29 interprets the content of the request and performs processing based on the result of the interpretation on the function circuit or the function token table 24.

[0058] The HTTP parser 30 generates a response message to the request. The TOE 27, the switch 28, the HTTP parser 29, and the HTTP parser 30 constitute the access reception unit 23 of the first embodiment. In this embodiment, HTTP is taken as an example to illustrate the communication protocol of the application layer, but the communication protocol is not limited to HTTP.

[0059] The circuit area 31 is a rewritable area of the FPGA 2b. The function token table 24 is implemented on the DRAM (Dynamic Random Access Memory), BRAM (Block Random Access Memory), or URAM (Unified Random Access Memory) of the FPGA 2b. As described in the first embodiment, the function token table 24 stores a function ID, a function name, and a token. The function realized by the function circuit for a function ID is uniquely determined. On the other hand, there may be multiple tokens for a function ID.

[0060] Next, the operation of the FPGA system of this embodiment will be described. The following three parties are involved in the FPGA system. The administrator of the FPGA system provides all platforms. The developer of the FPGA system develops a service using the FPGA system on the platform and provides it to the client. The client uses the service provided by the developer. Also, there are two types of clients: a client that sends a function usage request to the FPGA 2b via the network and a client that uses the host device 1b.

[0061] First, the operation of the FPGA system when a function usage request is sent from the client terminal 3 on the network and the processing result is received will be described with reference to FIG. 3. The developer of the FPGA system develops the function of the FPGA 2b that wants to be provided to the client and stores the bitstream data 503 for defining the function circuit that realizes the function in the host device 1b.

[0062] Clients who want to use the functions of FPGA2b send resource requests for applying to use the functions they want to the developers of the FPGA system using client terminal 3 (step S100 in Fig. 3). Func0×1 and Func1×1 in Fig. 3 indicate that the client requests to use two functions for grayscaling of data.

[0063] The developer who receives the application request starts App on host device 1b (K8s master node 4, K8s worker node 5). K8s master node 4 generates a token to be assigned to the function requested by the client (step S101 in Fig. 3). In the example of Fig. 3, the generated token is "XXX". K8s master node 4 starts pod 50 via kublet 51 according to device plugin 52 (steps S102 - S105 in Fig. 3).

[0064] By passing the resource request from the client by K8s master node 4 to device plugin 52 via kublet 51, device plugin 52 creates as many directories as the number of functions the client wants to use in memory area 54. The directory name is function name_function ID. In the example of Fig. 2, two directories named grayscale_0 and grayscale_1 are created. Note that the function ID used in the directory name may be different from the function ID written in function token table 24 described later.

[0065] The container 500 of the started pod 50 reads the directory name from memory area 54 and checks the function ID at the end of the directory name. Container 500 sends the function name and the token to FPGA2b as many times as the number of directory names and function IDs (step S106 in Fig. 3).

[0066] The DMA bridge controller 22 of FPGA2b writes the function name and token received from the container 500 into the function token table 24. Then, the DMA bridge controller 22 returns the function ID assigned to the row of the function token table 24 in which the function name and token were written to the container 500.

[0067] The container 500 notifies the container 501 of the function ID received from FPGA2b and the function name read from the directory name. The container 501 reads out the bitstream data corresponding to the function name from among the bitstream data 503 pre-registered in the host device 1b. The container 501 transmits the read bitstream data to FPGA2b to write it into the area of the configuration memory 26 corresponding to the function ID received from the container 500.

[0068] When the bitstream data is written into the area of the configuration memory 26 corresponding to the function ID via the DMA bridge controller 22 of FPGA2b, the circuit area of FPGA2b corresponding to the function ID is reconfigured, and a function circuit corresponding to the function ID and the function name is constructed. The DMA bridge controller 22 returns a circuit write completion notification as a response to the pod 50.

[0069] The pod 50 that has received the circuit write completion notification notifies the client terminal 3 of the resource allocation completion via the kublet 51 (Steps S107 to S109 in FIG. 3). This resource allocation completion notification is appended with the function name representing the function for which the client has made an application and the token assigned to the function for which the client has made an application.

[0070] Upon receiving the resource allocation completion notice, the client uses client terminal 3 to send a function usage request (HTTP request) to FPGA2b (step S110 in FIG. 3). The function usage request is appended with the IP (Internet Protocol) number and port number of the network interface unit 25 of FPGA2b, the function name and token notified from pod 50, and the data to be processed.

[0071] The TOE27 of FPGA2b performs transport protocol processing on the function usage request received via the network interface unit 25. Based on the session ID issued by TOE27, the switch 28 of FPGA2b detects that the data received from TOE27 is data from the client. Then, since the data received from TOE27 is a function usage request, the switch 28 transfers the function usage request to the HTTP parser 29.

[0072] The HTTP parser 29 interprets the content of the function usage request. Based on the content stored in the function token table 24 and the function name and token included in the function usage request, the HTTP parser 29 identifies the function circuit to which the data to be processed included in the function usage request should be transferred. The HTTP parser 29 transfers the data to be processed to the identified function circuit.

[0073] For example, when the function name is "grayscale" and the token is "hoge", the data to be processed is transferred to the function circuit 20-0 to which the function ID "0" is assigned. The HTTP deparser 30 of FPGA2b creates the processing result by the function circuit 20-0 as response data for the function usage request.

[0074] Since the data received by switch 28 from the HTTP parser 30 is the response data for the function usage request, switch 28 transfers the response data to the TOE 27. The TOE 27 assembles a response packet from the response data received from the switch 28, and returns the response packet to the requesting client terminal 3 via the network interface unit 25.

[0075] The transmission of the function usage request and the reception of the processing result are repeated until the processing desired by the client is completed. After the desired processing is completed, the client uses the client terminal 3 to send a resource release notification to the K8s master node 4 of the host device 1b (step S111 in FIG. 3).

[0076] Upon receiving the resource release notification, the K8s master node 4 sends a pod deletion request to the pod 50 via the kublet 51 (steps S112 and S113 in FIG. 3). The container 500 of the pod 50 that has received the pod deletion request requests the FPGA 2b to delete the function name and token corresponding to the function whose usage has ended from the function token table 24 (step S114 in FIG. 3).

[0077] The DMA bridge controller 22 of the FPGA 2b deletes the row containing the function name and token specified by the container 500 from the function token table 24. Then, the DMA bridge controller 22 returns the function ID assigned to the deleted row to the container 500.

[0078] The container 500 notifies the container 501 of the function ID received from the FPGA 2b. The container 501 transmits to the FPGA 2b the bitstream data for deleting the function circuit to be written to the area of the configuration memory 26 corresponding to the function ID received from the container 500.

[0079] When bitstream data is written into the area of the configuration memory 26 corresponding to the function ID via the DMA bridge controller 22 of the FPGA2b, the circuit area of the FPGA2b corresponding to the function ID returns to an undefined state.

[0080] The container 501 terminates the pod 50 and sends a pod deletion completion notification to the K8s master node 4 via the kublet 51 (steps S115 and S116 in FIG. 3). Thus, the operation of the FPGA system ends.

[0081] Next, the operation of the FPGA system when a function usage request is sent from the client terminal 3 accessing the host device 1b and a processing result is received will be described with reference to FIG. 4. The developer of the FPGA system develops the functions of the FPGA2b to be provided to the client and stores the bitstream data 503 for defining the function circuit that realizes the functions in the host device 1b.

[0082] A client who wants to use the functions of the FPGA2b sends a resource request for an application to use the desired functions to the developer of the FPGA system using the client terminal 3 (step S200 in FIG. 4). Func0×1 and Func1×1 in FIG. 4 indicate that the client requests to use two functions for grayscale conversion of data.

[0083] The developer who has received the application request starts the App (K8s master node 4, K8s worker node 5) of the host device 1b. The K8s master node 4 generates a token to be assigned to the function for which an application has been made from the client (step S201 in FIG. 4). In the example of FIG. 4, the generated token is set to "XXX". The K8s master node 4 starts the pod 50 in accordance with the device plugin 52 via the kublet 51 (steps S202 to S205 in FIG. 4).

[0084] By passing the resource requests from the client to the device plugin 52 via the kublet 51 in the K8s master node 4, the device plugin 52 creates directories in the memory area 54 for the number of functions the client wants to use. The directory name is the function name_function ID.

[0085] The container 500 of the launched pod 50 reads the directory name from the memory area 54 and checks the function ID at the end of the directory name. The container 500 sends the function name and the token to the FPGA 2b for the number of the directory name and the function ID (step S206 in FIG. 4).

[0086] The DMA bridge controller 22 of the FPGA 2b writes the function name and the token received from the container 500 to the function token table 24. Then, the DMA bridge controller 22 returns the function ID assigned to the row of the function token table 24 where the function name and the token are written to the container 500.

[0087] The container 500 notifies the container 501 of the function ID received from the FPGA 2b and the function name read from the directory name. The container 501 reads the bitstream data corresponding to the function name from the bitstream data 503 pre-registered in the host device 1b. The container 501 sends the read bitstream data to the FPGA 2b to write it to the area of the configuration memory 26 corresponding to the function ID received from the container 500.

[0088] When the bitstream data is written to the area of the configuration memory 26 corresponding to the function ID via the DMA bridge controller 22 of the FPGA 2b, the circuit area of the FPGA 2b corresponding to the function ID is reconfigured, and the function circuit corresponding to the function ID and the function name is constructed. The DMA bridge controller 22 returns a circuit write completion notice as a response to the pod 50.

[0089] The pod 50 that has received the circuit write completion notice notifies the cublet 51 of the completion of the circuit write (step S207 in FIG. 4). The cublet 51 creates a container 502 for the client to use the function circuit (steps S208 to S210 in FIG. 4). After creating the container 502, the cublet 51 notifies the client terminal 3 of the completion of resource allocation (steps S211 and S212 in FIG. 4). This resource allocation completion notice is attached with a function name representing the function applied from the client and a token assigned to the function applied from the client.

[0090] The client that has received the resource allocation completion notice logs in to the host device 1b using the client terminal 3 and transmits a function usage request (HTTP request) to the host device 1b (step S213 in FIG. 4). The function usage request is attached with the function name and token notified from the cublet 51 and the data to be processed. The container 502 of the host device 1b transmits the function usage request from the client to the FPGA 2b (step S214 in FIG. 4).

[0091] The DMA bridge controller 22 of the FPGA 2b passes the function usage request received from the host device 1b to the switch 28. The switch 28 of the FPGA 2b detects that the data received from the DMA bridge controller 22 is data from the client based on the session ID issued by the DMA bridge controller 22. Then, since the data received from the DMA bridge controller 22 is a function usage request, the switch 28 transfers the function usage request to the HTTP parser 29.

[0092] The HTTP parser 29 interprets the content of the function usage request. Based on the content stored in the function token table 24, the function name and token included in the function usage request, the HTTP parser 29 identifies the function circuit to which the data to be processed included in the function usage request should be transferred. The HTTP parser 29 transfers the data to be processed to the identified function circuit. The HTTP dep parser 30 of the FPGA 2b creates the processing result by the function circuit as response data for the function usage request.

[0093] Since the data received from the HTTP dep parser 30 is the response data for the function usage request, the switch 28 transfers the response data to the DMA bridge controller 22. The DMA bridge controller 22 returns the response data received from the switch 28 to the host device 1b.

[0094] The container 502 of the host device 1b returns the response data received from the FPGA 2b to the requesting client terminal 3. Until the processing desired by the client is completed, the transmission of the function usage request and the reception of the processing result are repeated.

[0095] After the completion of the desired processing, the client uses the client terminal 3 to send a resource release notification to the K8s master node 4 of the host device 1b (step S216 in FIG. 4). The K8s master node 4 that has received the resource release notification sends a pod deletion request to the kublet 51 (step S217 in FIG. 4).

[0096] The kublet 51 sends a container deletion request to the container 502 of the pod 50 to delete the container 502 that has finished being used (steps S218 and S219 in FIG. 4). Further, the kublet 51 sends a container deletion request to the container 500 of the pod 50 (step S220 in FIG. 4).

[0097] Upon receiving a container deletion request, the container 500 requests the FPGA 2b to delete the function name and token corresponding to the function that has finished being used from the function token table 24 (step S221 in FIG. 4).

[0098] The DMA bridge controller 22 of the FPGA 2b deletes the row containing the function name and token specified by the container 500 from the function token table 24. Then, the DMA bridge controller 22 returns the function ID assigned to the deleted row to the container 500.

[0099] The container 500 notifies the container 501 of the function ID received from the FPGA 2b. The container 501 transmits to the FPGA 2b the bitstream data for deleting the function circuit to be written into the area of the configuration memory 26 corresponding to the function ID received from the container 500.

[0100] When the bitstream data is written into the area of the configuration memory 26 corresponding to the function ID via the DMA bridge controller 22 of the FPGA 2b, the circuit area of the FPGA 2b corresponding to the function ID returns to an undefined state.

[0101] The container 501 terminates the pod 50 and sends a pod deletion completion notification to the K8s master node 4 via the kublet 51 (steps S222 and S223 in FIG. 4). Thus, the operation of the FPGA system ends.

[0102] In this embodiment, as described with reference to FIG. 3, once the client has completed the settings, it can cause the function circuit of the FPGA 2b to process data without accessing the host device 1b. Conventionally, there was a large delay in accessing the host device, but in this embodiment, the client can execute the processing without unnecessary delay.

[0103] In the conventional FPGA manager, since the App manages the FPGA, it is necessary to share the App among multiple clients in a time-division manner. On the other hand, in this embodiment, by assigning different tokens to each client and using different circuit regions, multiple clients can use the FPGA2b simultaneously, and the utilization efficiency when sharing the FPGA2b among multiple clients can be improved. The improvement in the utilization efficiency of FPGA2b leads to an improvement in the utilization efficiency of the services provided by the FPGA system, which in turn leads to an improvement in profitability for the developers operating the FPGA system.

[0104] Also, conventionally, the access reception unit was provided in the host device. For this reason, when the function circuit of the FPGA executes processing in response to a function usage request from a client, the memory of the host device, the CPU of the host device, and the FPGA are used, resulting in an increase in power consumption.

[0105] In this embodiment, by providing the access reception unit (TOE27, switch 28, HTTP parser 29, HTTP deparser 30) in the FPGA2b, the host device 1b is not used when the function circuit of the FPGA2b executes processing in response to a function usage request from a client, so the power consumption of the system can be reduced. The host device 1b only manages the function token table 24 and does not need to perform data transfer in response to a function usage request.

[0106] Also, in this embodiment, except when the function circuit of the FPGA2b executes processing in response to a usage application from a client, the function circuit is left in an undefined state, so standby power of the function circuit does not occur, and the power consumption of the FPGA2b can be reduced.

[0107] Conventionally, even if the network has a wide bandwidth, if the PCIe interface section does not have a wide bandwidth, the service throughput is limited. Therefore, investments in both the network and PCIe were required. On the other hand, in this embodiment, in the case of the operation described in FIG. 3, since the service throughput is determined by the network bandwidth, the investment efficiency can be improved. Also, in this embodiment, since a vendor-dependent runtime is not used, the FPGA system does not depend on the technology of a specific vendor.

[0108] Note that in this embodiment, Kubernetes is used as the platform for constructing the FPGA system, but it goes without saying that other tools may be used.

[0109] The host devices 1a and 1b described in the first and second embodiments can be realized by a computer including a CPU, a storage device, and an interface, and a program for controlling these hardware resources. A configuration example of this computer is shown in FIG. 5. The computer includes a CPU 200, a storage device 201, and an interface device (I / F) 202.

[0110] For example, the hardware of the network interface section 13 is connected to the I / F 202. In such a computer, the program for realizing the FPGA system of the present invention is stored in the storage device 201. The CPU 200 executes the processes described in the first and second embodiments according to the program stored in the storage device 201.

Industrial Applicability

[0111] This embodiment can be applied to a system using an FPGA.

Explanation of Signs

[0112] 1a, 1b... host device, 2a, 2b... FPGA, 3... client terminal, 4... K8s master node, 5... K8s worker node, 10a... FPGA manager, 13, 25... network interface unit, 15... function circuit management unit, 20-0, 20-1... function circuit, 22... DMA bridge controller, 23... access reception unit, 24... function token table, 26... configuration memory, 27... TOE, 28... switch, 29... HTTP parser, 30... HTTP deparser, 31... circuit area, 40... API server, 50... function manager pod, 51... kublet, 52... device plugin, 53, 530, 531... device file, 54... memory area, 500~502... container, App... application execution unit.

Claims

1. An FPGA and, a host device, comprising: The FPGA includes: a reconfigurable circuit area; an access reception unit configured to transfer data to be processed included in a function usage request from a client to a function circuit constructed in the circuit area and return a processing result by this function circuit to the client; a table in which a function ID that is identification information for each part of the circuit area, a function name that represents the function of the function circuit, and a token that is identification information of the function circuit are stored in association with each other; The access reception unit identifies a function circuit to which the data to be processed is to be transferred based on the content stored in the table and the function name and token included in the function usage request; The host device includes an application execution unit configured to generate the token to be assigned to the function for which the usage application has been made when receiving a resource request for applying for use of a function from the client before the function usage request, and transmit the generated token and the function name that represents the function for which the usage application has been made to the FPGA and the client. An FPGA system characterized by that.

2. In the FPGA system according to Claim 1, The application execution unit is characterized in that it generates different tokens for each client. An FPGA system.

3. In the FPGA system according to Claim 1 or 2, The FPGA further includes a controller configured to write the function name and token received from the application execution unit into the table and return a function ID assigned to the row of the table in which the writing has been performed to the application execution unit. An FPGA system characterized by that.

4. In the FPGA system according to Claim 3, The host device further includes a function circuit management unit configured to transmit bitstream data for reconfiguring the function circuit corresponding to the content stored in the table to the FPGA. An FPGA system characterized by that.

5. In the FPGA system according to Claim 4, When the function circuit management unit receives the resource request from the client, it transmits bitstream data for reconfiguring the function circuit corresponding to the content stored in the table to the FPGA, and when it receives a resource release notification from the client, it transmits bitstream data for returning the function circuit to an undefined state to the FPGA. An FPGA system characterized by this.

6. In the FPGA system according to any one of Claims 1 to 5, the FPGA further includes a network interface unit for communicating with the client via a network, the access reception unit receives a function usage request from the client via the network interface unit, and returns a processing result by the function circuit to the client via the network interface unit. An FPGA system characterized by this.

7. In the FPGA system according to any one of Claims 1 to 5, the application execution unit transmits a function usage request from the client to the FPGA, returns a processing result received from the FPGA to the client, the access reception unit receives the function usage request from the application execution unit, and returns a processing result by the function circuit to the application execution unit. An FPGA system characterized by this.

Images