Locking execution of cores to licensed programmable devices in data center

Abstract

To provide a hardware accelerator in which execution of cores is locked to licensed programmable devices in a data center.SOLUTION: In a computing system 100, a hardware accelerator for a server includes a programmable device, kernel logic configured in a programmable fabric of the programmable device, and an IP checker formed in the kernel logic. The IP checker is configured to: obtain a device ID of the programmable device and a signed whitelist; verify a signature of the signed whitelist, compare the device ID against a list of device IDs; and selectively assert or deassert an enable of the kernel logic in response to presence or absence of the device ID in the list of device IDs and verification of the signature. The signed whitelist includes the list of device IDs and the signature.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] Technical Field Examples of the present disclosure relate generally to electronic circuits and, more particularly, to locking the execution of a core to a licensed programmable device in a data center. [Background technology]

[0002] background Traditionally, a third party developer of intellectual property (IP) cores (e.g., pre-implemented circuit designs) for programmable devices licenses the IP to a system integrator on a project basis. This allows the system integrator to use the IP on any number of programmable devices. For data center applications, a different usage model is desired. Thus, the IP owner permits the data center owner to run the IP owner's IP on a specific number of authorized programmable devices. Preferably, if the data center owner or a third party attempts to use the IP on a device other than the one it was licensed for, the IP will not be able to operate. Summary of the Invention [Means for solving the problem]

[0003] overview Techniques are described for locking execution of a core to a licensed programmable device in a data center. In one example, a hardware accelerator of a computer system includes a programmable device and further includes kernel logic formed in a programmable fabric of the programmable device and an intellectual property (IP) checker circuit formed in the kernel logic. The IP checker circuit is configured to obtain a device identifier (ID) of the programmable device and a signed whitelist, the signed whitelist including a device ID list and a signature, verify the signature of the signed whitelist, compare the device ID to the device ID list, and selectively assert or deassert the enable of the kernel logic in response to the presence or absence of the device ID in the device ID list and the verification of the signature.

[0004] In another example, a computer system includes a processing system and a hardware accelerator coupled to the processing system. The hardware accelerator includes kernel logic formed in a programmable fabric of the programmable device and an intellectual property (IP) checker circuit formed in the kernel logic. The IP checker circuit is configured to obtain a device identifier (ID) of the programmable device and a signed whitelist, the signed whitelist including a device ID list and a signature, verify a signature of the signed whitelist, compare the device ID to the device ID list, and selectively assert or deassert an enable of the kernel logic in response to the presence or absence of a device ID in the device ID list and verification of the signature.

[0005] In another example, a method for locking kernel logic to a programmable device of a hardware accelerator provided in a computer system includes forming the kernel logic in a programmable fabric of the programmable device, and an intellectual property (IP) checker circuit formed in the kernel logic obtains a device identifier (ID) and a signed whitelist of the programmable device, the signed whitelist including a device ID list and a signature, verifying a signature of the signed whitelist, and D to a device ID list, and the IP checker circuit selectively asserts or deasserts the enable of the kernel logic depending on the presence or absence of the device ID in the device ID list and the verification of the signature.

[0006] These and other aspects may be understood by reference to the following detailed description.

[0007] So that the above-recited features can be understood in detail, a more particular description than the brief summary above can be had by reference to implementations illustrated in the accompanying drawings, which are merely illustrative of representative implementations and should not be considered as limiting the scope of the invention. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram illustrating a computing system according to an example. [Diagram 2] FIG. 2 is a block diagram illustrating an acceleration circuit according to an example. [Diagram 3] FIG. 2 is a block diagram illustrating a design tool according to an example. [Figure 4] FIG. 1 is a block diagram showing a programmable device according to an example. [Diagram 5] FIG. 1 is a block diagram showing a programmable IC according to an example. [Figure 6] FIG. 1 is a block diagram illustrating a system-on-chip (SoC) implementation of a programmable IC according to an example. [Figure 7] FIG. 1 illustrates a Field Programmable Gate Array (FPGA) implementation of a programmable IC. [Figure 8] FIG. 1 is a block diagram illustrating a cloud computing system according to an example. [Figure 9] 4 is a flow chart illustrating a method for locking execution of a kernel onto a particular programmable device, according to one example. [Figure 10] 1 is a block diagram illustrating a method for generating a signed whitelist of device IDs according to an example. [Figure 11] 1 is a block diagram illustrating a method for verifying the validity of a signed whitelist, according to an example. [Figure 12] 1 is a flow chart illustrating a method for updating a whitelist, according to one example. [Figure 13] FIG. 2 is a block diagram illustrating an example of an IP checker. [Figure 14] FIG. 13 is a block diagram showing an IP checker according to another example. [Figure 15] FIG. 2 is a block diagram showing a checker circuit of an IP checker according to an example. [Figure 16A] FIG. 2 is a block diagram showing an example of the arrangement of device IDs in a programmable device. [Figure 16B] FIG. 2 is a block diagram showing an example of the arrangement of device IDs in a programmable device. [Figure 16C] FIG. 2 is a block diagram showing an example of the arrangement of device IDs in a programmable device. [Figure 17] 1 is a flow chart illustrating a method for locking kernel logic to a programmable device of a hardware accelerator provided in a computer system, according to one example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Detailed Description To facilitate understanding, wherever possible, the same reference numbers will be used to refer to identical elements common to the figures, and elements of one example may be beneficially incorporated in other examples.

[0010] Various features will now be described with reference to the drawings, in which the drawings may not be drawn to scale and in which elements having similar structures or functions are indicated by similar reference numerals throughout the drawings, and the drawings are intended only to facilitate the description of features and are not intended to exhaustively describe the invention or to limit the scope of the invention. Moreover, the illustrated examples need not include all aspects or advantages, as an aspect or advantage described in connection with a particular example is not necessarily limited to that example and may be implemented in any other example even if not so illustrated or explicitly described.

[0011] Techniques are described for locking execution of cores to licensed programmable devices in a data center. In one example, each programmable device can be identified by integrating an IP check function into a partially reconfigurable kernel in a data center application. If a programmable device is on a "white list," the IP check function allows operation of the IP in the kernel on that programmable device. If not, the IP check function disables operation of the IP on unauthorized programmable devices. The IP check function can resist attacks, for example, by disguising one programmable device as another programmable device or modifying the "white list" to include other programmable devices. The IP check function assists in adding additional programmable devices to the "white list" that are agreed upon by the data center and the IP owner. The IP check function prevents mass deployment of acceleration circuits without proper authorization from the developer of the acceleration circuits. These and other aspects of the technology are described below with reference to the drawings.

[0012] FIG. 1 is a block diagram illustrating an example computing system 100. The computing system 100 may be located in a data center or the like. The data center may include multiple computing systems configured similarly to the computing system 100. The computing system 100 includes a server computer (server 102). The server 102 includes a hardware platform (hardware 104) and a software platform (software 106) that operates on the hardware 104. The hardware 104 includes a processing system 110, a system memory 116, storage (storage 118), and a hardware accelerator 122. The software 106 includes an operating system (OS) 144, driver software (driver 146), and applications 150.

[0013] The processing system 110 includes a microprocessor 112, support circuits 114, and a peripheral bus 115. The microprocessor 112 may be any type of general-purpose central processing unit (CPU), such as an x86-based processor, an ARM-based processor, or the like. The microprocessor 112 may include one or more cores and associated circuit elements (e.g., cache memory, memory management unit (MMU), interrupt controller). The microprocessor 112 is configured to execute program code that performs one or more operations described herein. The program code may be stored in a system memory 116 and / or storage 118. The support circuits 114 include various devices that cooperate with the microprocessor 112 to manage data flow between the microprocessor 112 and the system memory 116, storage 118, hardware accelerator 122, or any other peripheral devices. For example, the support circuits 114 may include a chipset (e.g., a northbridge, a southbridge, a platform host controller), a voltage regulator, firmware (e.g., a BIOS), and the like. The support circuits 114 manage the flow of data between the microprocessor 112 and a peripheral bus 115 to which various peripheral devices, such as a hardware accelerator 122, are connected. In some examples, the microprocessor 112 may be a system-in-package (SiP), a system-on-a-chip (SoC), or the like, that incorporates all or most of the functionality of a chipset (e.g., north bridge, south bridge). The peripheral bus may be an expansion bus, such as a Peripheral Component Interconnect Express (PCIe), In this example, the processing system 110 is shown separate from the hardware accelerator 122. In other examples, which are described further below, , the processing system 110 and the hardware accelerator 122 may be implemented on the same integrated circuit (IC).

[0014] The system memory 116 is a device that allows for the storage and retrieval of information, such as executable instructions and data. The system memory 116 may include one or more random access memory (RAM) modules, such as double data rate (DDR) dynamic RAM (DRAM). The storage 118 includes local storage devices (e.g., one or more hard disks, flash memory modules, solid state disks, and optical disks) and / or storage interfaces that allow communication between the server 102 and one or more network data storage systems. The hardware 104 may include various other conventional devices and peripherals of a computing system, such as a graphics card, a universal serial bus (USB) interface, and the like.

[0015] The hardware accelerator 122 includes a programmable device 128, an optional non-volatile memory 124, and a RAM 126. The programmable device 128 may be a field programmable gate array (FPGA), or a SoC with an FPGA, etc. The NVM 124 may include any type of non-volatile memory, such as flash memory. The RAM 126 may include DDR DRAM, etc. The programmable device 128 is coupled to the NVM 124 and the RAM 126. The programmable device 128 is also coupled to the peripheral bus 115 of the processing system 110.

[0016] The OS 144 may be any commercial operating system known in the art, such as Linux, Microsoft Windows, Mac OS. The driver 146 provides the hardware accelerator 122 with an application programming interface (API) for commanding and controlling the hardware accelerator 122. The application 150 includes software that runs on the microprocessor 112 and calls the hardware accelerator 122 through the driver 146 to perform some work. The application 150 may include a neural network, a video processing application, a network processing application, or similar application that offloads some functionality to the hardware accelerator 122.

[0017] In operation, the programmable device 128 is configured to have an acceleration circuit 130. In one example, the acceleration circuit 130 includes a shell circuit 130A and an application circuit 130B. For example, the acceleration circuit 130 may be implemented using a static region 134 and a programmable region 136. The shell circuit 130A is implemented in the static region 134. The application circuit 130B is implemented in the programmable region 136, e.g., kernel logic 138.

[0018] If NVM 124 is provided, at least a portion of the configuration data of programmable device 128 may be stored in NVM 124. If NVM 124 is not provided, the configuration data may be stored outside hardware accelerator 122, for example in storage 118. The configuration data of programmable device 128 may be generated by design tool 108 running on a computer system external to server 102. Design tool 108 compiles a circuit design into configuration data that is then sent to server 102 for configuring programmable device 128 and stored on server 102. In one example, the configuration data includes a base platform (BP) archive 132 for implementing shell circuit 130A and a kernel archive 120 for implementing one or more kernel logics 138. In one example, BP archive 132 is stored in NVM 124 and kernel archive 120 is stored in storage 118. However, , the BP archive 132 may be stored in the storage 118.

[0019] Static region 134 is "static" in that the circuitry within it is not changed upon reconfiguration of programmable region 136. In one example, static region 134 includes interface circuitry, such as PCIe endpoint circuitry, direct memory access (DMA) controllers, interconnects, memory controllers, memory interface circuitry, decoupler circuitry (to support partial reconfiguration), flash programmers, debug circuitry, etc.

[0020] In one example, the kernel logic 138 includes an IP checker 180. The IP checker 180 is configured to verify that the kernel logic 138 is authorized to execute on the programmable device 128. The IP checker 180 accesses a signed whitelist 121 that includes a list of valid device identifiers (IDs) of programmable devices authorized to execute the kernel logic 138. In one example, the signed whitelist 121 is stored in the storage 118 as a separate file or as part of the kernel archive 120. The signed whitelist 121 may be loaded into the programmable device 128 at configuration time or may be accessed from the storage 118 at run time. In one example, the signed whitelist 121 is a certificate that includes a list of valid device IDs and a signature generated by a provider of the kernel logic 138 (referred to herein as a system integrator). After verifying the signature of the signed whitelist 121, the IP checker 180 checks the device ID of the programmable device 128 against the list of device IDs in the signed whitelist 121. If both conditions are met, the IP checker 180 allows the kernel logic 138 to execute on the programmable device 128. If not, the IP checker 180 prohibits the kernel logic 138 from executing.

[0021] FIG. 2 is a block diagram illustrating an example of an acceleration circuit 130. The acceleration circuit 130 includes an interface circuit 140 and a kernel logic 138. In this example, the interface circuit 140 includes a PCIe endpoint circuit (PCIe endpoint 202), a DMA controller 204, an interconnect circuit (interconnect 206), a memory controller 210, and a memory interface 212. The interface circuit 140 may include other support circuits (e.g., decoupler circuits, debug circuits, etc.) that are omitted for clarity. The PCIe endpoint 202 provides a physical interface to the peripheral bus 115. The DMA controller 204 facilitates DMA operations to the RAM 126, the memory 142, and the kernel 138. The interconnect 206 couples the DMA controller 204 to the memory 142 and to an input interface of the kernel 138. The interconnect 206 is coupled to an output interface of the kernel logic 138 and to the memory controller 210. The memory controller 210 is coupled to a memory interface 212. The memory interface 212 is coupled to the RAM 126 (shown in FIG. 1).

[0022] In operation, the driver 146 can directly access the kernel logic 138 via the DMA controller 204. The kernel logic 138 can access the RAM 126 via the memory controller 210. Data can be exchanged between the software 106 and the kernel logic 138 using DMA operations between the system memory 116 and the RAM 126. In some examples, the IP checker 180 receives the signed whitelist 121 at run time using DMA operations (if not configured to have the signed whitelist 121 at configuration time).

[0023] 3 is a block diagram illustrating an example of a design tool 108. The design tool 108 includes a hardware platform 304 and a software platform 306. The hardware platform 304 includes a computer 302. The hardware platform 304 includes a CPU 308, a memory 310, a storage device 312, and an input / output (IO) device 314. The CPU 308 may be any type of microprocessor. The memory 310 may include one or more RAM modules, e.g., DDR DRAM. The storage device 312 includes local storage (e.g., one or more hard disks, flash memory modules, solid state disks, and optical disks) and / or a storage interface that allows the computer 302 to communicate with one or more network data storage systems. The IO device 314 allows communication with the computer 302. The software platform 306 includes an OS 316 and a circuit design tool 318. The OS 316 may be any commercial operating system known in the art, e.g., Linux, Microsoft Windows, Mac OS, etc. The circuit design tool 318 is configured to generate a circuit design that can be used to program a programmable device. A user generates a kernel design for the acceleration circuit 130 by interacting with the circuit design tool 318. As described further below, the circuit design tool 318 adds an IP checker 180 to each kernel design. The software platform 306 may include other application software 319 that performs other functions such as public / private key generation, encryption, decryption, etc., as described further herein.

[0024] 4 is a block diagram illustrating a programmable device 54 according to an example. The programmable device 54 includes a plurality of programmable integrated circuits (ICs) 1, e.g., programmable ICs 1A, 1B, 1C, and 1D. In an example, each programmable IC 1 is an IC die provided on an interposer 51. Each programmable IC 1 includes a super logic region (SLR) 53 of the programmable device 54, e.g., SLRs 53A, 53B, 53C, and 53D. The programmable ICs 1 are interconnected via conductors (referred to as super long lines (SLLs) 52) on the interposer 51.

[0025] FIG. 5 is a block diagram of a programmable IC 1 according to an example. The programmable IC 1 includes a programmable logic 3 (also referred to as a programmable fabric), a configuration logic 25, and a configuration memory 26. The programmable IC 1 may be coupled to external circuits such as a non-volatile memory 27, a DRAM 28, and other circuits 29. The programmable logic 3 includes logic cells 30, support circuits 31, and programmable interconnects 32. The logic cells 30 include circuits that can be configured to implement a general logic function of multiple inputs. The support circuits 31 include dedicated circuits such as transceivers, input / output blocks, digital signal processors, memories, etc. The logic cells and support circuits 31 may be interconnected via the programmable interconnects 32. Information for programming the logic cells 30, information for setting parameters of the support circuits 31, and information for programming the programmable interconnects 32 are stored in the configuration memory 26 by the configuration logic 25. Configuration logic 25 may obtain configuration data from non-volatile memory 27 or any other source, such as DRAM 28 or other circuitry 29. In some examples, programmable IC 1 includes a processing system 2. Processing system 2 may include a microprocessor, memory, support circuitry, IO circuitry, and the like.

[0026] 6 is a block diagram illustrating a system-on-chip (SoC) implementation of a programmable IC 1 according to one example. In this example, the programmable IC 1 includes a processing system 2 and programmable logic 3. The processing system 2 includes various processing units, such as a real-time processing unit (RPU) 4, an application processing unit (APU) 5, a graphics processing unit (GPU) 6, a configuration and security unit (CSU) 12, a platform management unit (PMU) 122, etc. The APU 5 includes various support circuits, such as on-chip memory (OCM) 14, transceiver 7, peripherals 8, interconnect 16, DMA circuitry 9, memory controller 10, peripherals 15, multiplexed IO (MIO) circuitry 13, etc. The processing units and support circuits are interconnected by interconnect 16. PL 3 is also coupled to interconnect 16. Transceiver 7 is coupled to external pin 24. PL 3 is coupled to external pin 23. Memory controller 10 is coupled to external pin 22. MIO 13 is coupled to external pin 20. PS 2 is typically coupled to external pin 21. APU 5 may include a CPU 17, memory 18, and support circuits 19.

[0027] In the example of Figure 6, programmable IC 1 may be provided in hardware accelerator 122 and may function as described above. Acceleration circuit 130 may be programmed in PL 3 and may function as described above. In another example, the functionality of hardware 104 described above may be realized using PS 2 rather than the hardware of the computing system. In this case, software 106 runs on PS 2 and functions as described above.

[0028] With reference to PS 2, each processing unit includes one or more central processing units (CPUs) and associated circuitry, such as memory, an interrupt controller, a direct memory access (DMA) controller, a memory management unit (MMU), and a floating point unit (FPU), etc. Interconnect 16 includes various switches, buses, communication links, etc. configured to interconnect the processing units as well as to interconnect other components within PS 2 to the processing units.

[0029] The OCM 14 includes one or more RAM modules that may be distributed throughout the PS 2. For example, the OCM 14 may include a battery-backed RAM (BBRAM), a tightly-coupled memory (TCM), and the like. The memory controller 10 may include a DRAM interface for accessing an external DRAM. The peripherals 8 and 15 may include one or more components that provide an interface to the PS 2. For example, the peripherals 15 may include a graphics processing unit (GPU), a display interface (e.g., a display port, an HDMI port), a universal serial bus (USB) port, an Ethernet port, a universal asynchronous transceiver (UART) port, a serial peripheral interface (SPI) port, a general purpose IO (GPIO) port, a serial advanced technology attachment (SATA) port, a PCIe port, and the like. The peripherals 15 may be coupled to the MIO 13. The peripherals 8 may be coupled to the transceiver 7. The transceiver 7 may include a serializer / deserializer (SERDES) circuit, an MGT, and the like.

[0030] 7 shows a field programmable gate array (FPGA) implementation of programmable IC 1. The FPGA includes a number of different programmable tiles, including transceivers 37, configurable logic blocks (CLBs) 33, random access memory blocks (BRAMs) 34, input / output blocks (IOBs) 36, configuration and clock logic (CONFIG / CLOCKS) 42, digital signal processing blocks (DSPs) 35, dedicated input / output blocks (I / Os) 41 (e.g., configuration and clock ports), and other programmable logic 39 (e.g., digital clock managers, analog-to-digital converters, and system monitoring logic, etc.). The FPGA may also include a PCIe interface 40, an analog-to-digital converter (ADC) 38, etc.

[0031] In some FPGAs, as shown by the example at the top of FIG. 7, each programmable tile has input and output terminals 48 of the programmable logic elements within the same tile. Each programmable interconnect element 43 may include at least one programmable interconnect element (INT) 43 having a connection to a programmable interconnect segment 49 of an adjacent programmable interconnect element in the same tile or other tiles. Each programmable interconnect element 43 may also include a connection to an interconnect segment 50 of a general routing resource between logic blocks (not shown). The general routing resource may include routing channels between logic blocks (not shown) that include tracks of interconnect segments (e.g., interconnect segment 50) and switch blocks (not shown) for connecting the interconnect segments. The general routing resource interconnect segments (e.g., interconnect segment 50) may extend across one or more logic blocks. The programmable interconnect elements 43 together with the general routing resources implement a programmable interconnect structure (programmable interconnect) for the illustrated FPGA.

[0032] In an exemplary implementation, the CLB 33 may include configurable logic elements (CLEs) 44 that can be programmed to implement user logic, and a single programmable interconnect element (INT) 43. The BRAM 34 may include a BRAM logic element (BRL) 45 in addition to one or more programmable interconnect elements. In general, the number of interconnect elements included in a tile depends on the height of the tile. In the illustrated example, the BRAM tile has a height similar to five CLBs, but may have a height similar to other numbers of CLBs (e.g., four). The DSP tile 35 may include a DSP logic element (DSPL) 46 in addition to any suitable number of programmable interconnect elements. The IOB 36 may include, for example, two instances of input / output logic elements (IOLs) 47 in addition to one instance of the programmable interconnect element 43. As will be apparent to one skilled in the art, for example, the actual I / O pads connected to the I / O logic element 47 are generally not limited to the area of ​​the input / output logic element 47.

[0033] In the illustrated example, a horizontal region near the center of the die (shown in FIG. 6) is used for configuration, clocks and other control logic. Vertical columns 51 extending from this horizontal region or column are used to distribute clock and configuration signals across the entire width of the FPGA.

[0034] Some FPGAs utilizing the architecture shown in Figure 7 include additional logic blocks to disrupt the regular column structure that makes up most of the FPGA. The additional logic blocks may be programmable blocks and / or dedicated logic.

[0035] It should be noted that Figure 7 is intended to illustrate only an example SOC architecture. For example, the number of logic blocks in a row, the relative width of the rows, the number and order of the rows, the types of logic blocks included in the rows, the relative sizes of the logic blocks, and the interconnect / logic implementations shown at the top of Figure 7 are merely exemplary. For example, in an actual FPGA, to facilitate efficient implementation of user logic, typically two or more adjacent columns of CLBs will be included in any occurrence of a CLB, and the number of adjacent CLB rows will vary depending on the overall size of the FPGA.

[0036] In one example, the PL 3 in a programmable device includes a non-volatile memory (e.g., electronic fuses) that stores a device ID 90. The device ID may be any unique identifier (e.g., a 96-bit binary number) used by the manufacturer of the programmable device. If the programmable device includes multiple programmable ICs, each programmable IC may include a unique device ID 90.

[0037] 8 is a block diagram illustrating an example of a cloud computing system 800. The cloud computing system 800 includes a plurality of computers 802. Each computer 802 includes one or more hardware accelerators 804. Each hardware accelerator 804 includes one or more programmable devices, each having one or more device IDs 806. For a particular kernel, the cloud owner can provide a list of device IDs 806 of programmable devices that will run that kernel. Computer 302 can receive and process the device ID list 806 as described below.

[0038] 9 is a flow chart illustrating a method 900 for locking execution of a kernel onto a particular programmable device, according to one example. Method 900 includes step 902. In step 902, a system integrator (e.g., a kernel developer) generates a public / private key pair using any public key encryption system. In one example, the public key encryption system is the Rivest-Shamir-Adleman (RSA) system, such as the RSA-4000. 96. In such a system, public key 906 is the encryption key and private key 908 is the decryption key. However, in the system of the present invention, private key 908 is used to encrypt and public key 906 is used to decrypt. The concept of signing with private key encryption and public key decryption is used throughout this specification.

[0039] In RSA-4096, the public / private keys are 4096-bit keys. Those skilled in the art will appreciate that other public key encryption systems may be used. For clarity, RSA-4096 is described as an example in the examples herein. Step 902 may be performed by software running on computer 302.

[0040] In step 904, the DC owner retrieves from the data center a device ID list 910 of programmable devices 128 that are authorized to execute the kernel logic 138 (e.g., device IDs of devices licensed to execute the kernel by a system integrator). In one example, the cloud owner can obtain the device ID by loading an unauthorized kernel onto the programmable device. The IP checker 180 can prevent the kernel from executing but provide the device ID as output (e.g., the IP checker 180 can read the device ID from the programmable device).

[0041] In step 912, the system integrator generates a signed whitelist 914 from the device IDs 910 using software running on the computer 302. The signed whitelist 914 includes the device IDs 910 and a signature generated by the system integrator. The signature is generated by computing a hash of the device ID list (e.g., a string concatenation of the device IDs). The hash can be calculated using any hash function known in the art, such as the 256-bit Secure Hash Algorithm (SHA-256). For clarity, as an example, SHA-256 is used as the hash function herein. The hash value and the private key are then fed into an encryption algorithm (e.g., using RSA-4096), which generates a ciphertext signature (e.g., an encrypted hash value) by encrypting the plaintext hash value.

[0042] In step 916, the system integrator uses circuit design tools 318 to generate a kernel that includes IP checker 180. IP checker 180 is configured with a public key 906. The system integrator provides files for the kernel and signed whitelist 914.

[0043] FIG. 10 is a block diagram illustrating a method 1000 for generating a signed whitelist of device IDs according to one example. The whitelist 1004 includes a plurality of approved device IDs 1002 for programmable devices. A hash function 1006 (e.g., SHA-256) generates a hash value of the device ID list 1003 by processing the device ID list 1003 (e.g., a string concatenation of the device IDs 1002). An encryption function 1008 generates a signature 1010 by processing the hash value with a system integrator's private key. The whitelist 1004 includes the approved device IDs 1002 and the signatures 1010.

[0044] 11 is a block diagram illustrating a method 1100 for verifying the validity of a signed whitelist, according to an example. A hash circuit 1102 in the IP checker 180 generates a hash value by processing the approved device ID 1002 (e.g., using SHA-256). A decryption circuit 1104 in the IP checker 180, which has access to the system integrator's public key, processes the signature 1010. The decryption circuit 1104 generates a plaintext hash value by decrypting the signature 1010 (e.g., recovering the hash value calculated by the system integrator). A comparison circuit 1106 determines whether the whitelist 1004 is valid (e.g., has been tampered with) by comparing the two hash values.

[0045] 12 is a flow chart illustrating a method 1200 for updating a whitelist, according to an example. Method 1200 includes step 902. In step 902, a data center owner provides an updated list 1208 of device IDs of programmable devices that are authorized to run kernels (e.g., device IDs of devices licensed to run kernels by a system integrator). In one example, a cloud owner can obtain the device IDs by loading an unauthorized kernel onto a programmable device. An IP checker 180 can prevent the kernel from running but provide the device ID as an output (e.g., IP checker 180 can read the device ID from the programmable device).

[0046] In step 1210, the system integrator, using software running on computer 302, generates a signed whitelist 1212 from the device ID 1208 and private key 1206. The signed whitelist 1212 includes the device ID 1208 and a signature generated by the system integrator. As described above, the signature is generated by computing a hash value of the device ID list and encrypting the plaintext hash to generate a ciphertext signature. In step 1216, the system integrator provides a file for the signed whitelist 1212.

[0047] 13 is a block diagram illustrating an example of an IP checker 180. The IP checker 180 includes a device ID read circuit 1302, an interface circuit 1312, a memory 1304, a control circuit 1308, and a checker circuit 1310. An output of the device ID read circuit 1302 is coupled to an input of the checker circuit 1310 and an input of the interface circuit 1312. The control circuit 1308 is coupled to the memory 1304, and an output of the control circuit 1308 is coupled to the checker circuit 1310. An output of the checker circuit 1310 is coupled to an input of the interface circuit 1312.

[0048] The device ID read circuit 1302 is configured to read the device ID of the programmable device. In this example, the memory 1304 is configured to store a signed whitelist 1306. The checker circuit 1310 is configured to receive (via the control circuit 1308) the device ID and the signed whitelist 1306. The checker circuit 1310 verifies the signed whitelist 1306 by performing the method 1100 of FIG. 11. The checker circuit 1310 also determines whether the device is authorized by comparing the verified whitelist 1306 with the device ID. If the device is authorized, If so, checker circuit 1310 asserts the enable output (i.e., enables the kernel). If not, checker circuit 1310 deasserts the enable output (i.e., disables the kernel). IP checker 180 can output the device ID from device ID read circuit 1302 via interface circuit 1312.

[0049] 14 is a block diagram illustrating another example of IP checker 180. In this example, memory 1304 and control circuitry 1308 are not provided. Instead, IP checker 180 obtains the signed whitelist from an external source (e.g., from a host computer system) via interface circuitry 1312. In other respects, IP checker 180 functions as described above.

[0050] FIG. 15 is a block diagram illustrating an example of a checker circuit 1310. The checker circuit 1310 includes a device ID comparison circuit 1502, a message hash calculation circuit 1504, a signature decryption circuit 1506, and a hash comparison circuit 1508. The device ID comparison circuit 1502 receives a signed whitelist and a device ID. The device ID comparison circuit 1502 determines whether the device ID is present in the device ID list of the signed whitelist. If present, the signature decryption circuit 1506 uses a public key provided in the IP checker 180 (i.e., the public key of the system integrator) to decrypt the signature in the signed whitelist and recover the plaintext hash value. The message hash calculation circuit 1504 is configured to generate a hash value of the approved device ID 1002 from the signed whitelist. The hash comparison circuit 1508 compares the two hash values, i.e., the hash value output from the message hash calculation circuit 1504 and the hash value output from the signature decryption circuit 1506. If the two hash values ​​match, the hash comparison circuit 1508 asserts the enable output, otherwise the hash comparison circuit 1508 deasserts the enable output.

[0051] As mentioned above, IP checker 180 operates based on the unique identifier of the programmable device. Kernel developers who wish to license individual instances of IP need access to the unique ID of the authorized device in order to lock the execution of their IP to the authorized device.

[0052] 16A-16C are block diagrams illustrating example arrangements of device IDs in a programmable device. As shown in FIG. 16A, a programmable device 1602 includes a single programmable IC (i.e., it is not a multi-die device). A kernel 1606 is provided in the programmable device 1602. The kernel 1606 is a complete configuration of the programmable device 1602 and functions without shell circuitry. In this case, the kernel 1606 has access to all functions of the programmable device 1602, including circuitry for reading the device ID 1604 of the programmable device 1602.

[0053] 16B, programmable device 1602 includes a single programmable IC (i.e., not a multi-die device). In this example, however, static area 1608 includes shell circuitry that supports kernel 1606. Programmable device 1602 includes circuitry for reading device ID 1604. Kernel 1606 has access to the circuitry for reading device ID 1604.

[0054] 16C, programmable device 1609 includes multiple programmable ICs (i.e., is a multi-die device). Static region 1608 is located in one SLR 1610 of programmable device 1609, and kernel 1606 is located in another SLR 1612 of programmable device 1609. In some devices, one SLR 1609 serves as a "master SLR" and one or more other SLRs serve as "slave SLRs." Assume SLR 1610 is a master SLR with static domain 1608 and SLR 1612 is a slave SLR with kernel 1606. Both SLR 1610 and SLR 1612 have unique device IDs and have circuitry to read the device IDs. Although not shown for clarity, the circuit design that reads the device ID of programmable device 1609 reads the device ID of the master SLR. However, it is not feasible to export the device ID from static domain 1608 to kernel 1606 to prevent device ID spoofing. In some cases, the data center owner controls the configuration of static domain 1608. Thus, in one example, circuit design tool 318 is configured to check the IP using device ID 1604 of SLR 1612. The kernel 1606 has access to circuitry to read the device ID 1604 of the SLR 1612 in order to fully configure the SLR 1612. Therefore, the IP checker 180 uses the device ID 1604 of the SLR 1612 rather than checking the IP using the device ID of the SLR 1610. Thus, the system integrator is assured that the device ID 1604 has not been spoofed.

[0055] FIG. 17 is a flow chart illustrating a method 1700 for locking kernel logic to a programmable device of a hardware accelerator provided in a computer system, according to one example. Method 1700 begins at step 1702. In step 1702, kernel logic is formed in the programmable fabric of the programmable device. In optional step 1703, a shell circuit is formed in the programmable fabric of the programmable device. In step 1704, IP checker circuit 180 obtains a device ID and a signed whitelist for the programmable device. In step 1706, IP checker circuit 180 verifies the signature of the signed whitelist. In step 1708, IP checker circuit 180 compares the device ID to a device ID list. In step 1710, IP checker circuit 180 selectively asserts or deasserts the enable of the kernel logic in response to the presence or absence of the device ID in the device ID list and the verification of the signature. The operation of IP checker circuit 180 to perform these steps is substantially similar to that described above.

[0056] In one example, a hardware accelerator for a computer system is described. The hardware accelerator includes a programmable device, the hardware accelerator further includes kernel logic formed in a programmable fabric of the programmable device, and an intellectual property (IP) checker circuit formed in the kernel logic. The IP checker circuit is configured to obtain a device identifier (ID) of the programmable device and a signed whitelist, the signed whitelist including a device ID list and a signature, verify a signature of the signed whitelist, compare the device ID to the device ID list, and selectively assert or deassert an enable of the kernel logic in response to the presence or absence of the device ID in the device ID list and verification of the signature.

[0057] In one example, the hardware accelerator further includes a shell circuit formed in the programmable fabric, the shell circuit configured to provide an interface between the computer system and the kernel logic.

[0058] In one example, the programmable fabric is a first programmable fabric and the hardware accelerator further includes a shell circuit formed in a second programmable fabric of the programmable device. The shell circuit is configured to provide an interface between the computer system and the kernel logic. The IP checker circuit is configured to obtain a device ID from the first programmable fabric of the programmable device. do.

[0059] In one example, a programmable device includes a first programmable IC having a first programmable fabric and a second programmable IC having a second programmable fabric.

[0060] In one example, the IP checker circuitry is configured to have a signed whitelist. In one example, the IP checker circuitry receives the signed whitelist from a computer system that includes a hardware accelerator.

[0061] In one example, the IP checker circuit is configured to verify the signature of the signed whitelist by decrypting a signature encrypted with the private key of a public key / private key pair using the public key of the public key / private key pair, determining a hash of the device ID list, and comparing the hash to the decrypted signature.

[0062] In one example, the IP checker circuit includes a device ID reading circuit configured to read a device ID, a memory configured to store a signed whitelist, and a checker circuit configured to compare the device ID with the device ID list and selectively assert or deassert an enable of the kernel logic.

[0063] In one example, the IP checker circuit includes a device ID reading circuit configured to read a device ID, an interface circuit configured to receive a signed whitelist from a computer system, and a checker circuit configured to compare the device ID to the device ID list and selectively assert or deassert an enable of the kernel logic.

[0064] In one example, a method is described for locking kernel logic to a programmable device of a hardware accelerator provided in a computer system, the method including forming kernel logic in a programmable fabric of the programmable device, an intellectual property (IP) checker circuit formed in the kernel logic obtaining a device identifier (ID) and a signed whitelist of the programmable device, the signed whitelist including a device ID list and a signature, verifying a signature of the signed whitelist, comparing the device ID to the device ID list, and the IP checker circuit selectively asserting or deasserting an enable of the kernel logic in response to the presence or absence of the device ID in the device ID list and verification of the signature.

[0065] In one example, the method further includes configuring a shell circuit within the programmable fabric, the shell circuit configured to provide an interface between the computer system and the kernel logic.

[0066] In one example, the programmable fabric includes a first programmable fabric and the method further includes configuring a shell circuit in a second programmable fabric of the programmable device, the shell circuit configured to provide an interface between the computer system and the kernel logic, and the IP checker circuit obtains a device ID from the first programmable fabric of the programmable device.

[0067] In one example, a programmable device includes a first programmable IC having a first programmable fabric and a second programmable IC having a second programmable fabric.

[0068] In one example, the IP checker circuit is configured with or receives a signed whitelist from a computer system.

[0069] In one example, the IP checker circuit is configured to verify the signature of the signed whitelist by decrypting a signature encrypted with the private key of a public key / private key pair using the public key of the public key / private key pair, determining a hash of the device ID list, and comparing the hash to the decrypted signature.

[0070] While the above describes particular examples, other and further examples can be devised without departing from the basic scope of the invention, the scope of the invention being defined by the claims that follow.

Claims

1. 1. A hardware accelerator for a computer system, the hardware accelerator comprising a programmable device, the hardware accelerator comprising: kernel logic formed in the programmable fabric of the programmable device; an intellectual property (IP) checker circuit formed in the kernel logic; The IP checker circuit includes: configured to obtain a device identifier (ID) and a signed whitelist for the programmable device, the signed whitelist including a list of device IDs and a signature; Verifying the signature of the signed whitelist; comparing the device ID to the device ID list; and A hardware accelerator configured to selectively assert or deassert an enable of the kernel logic in response to the presence or absence of the device ID in the device ID list and verification of the signature.

2. a shell circuit formed in the programmable fabric; The hardware accelerator of claim 1 , wherein the shell circuitry is configured to provide an interface between a computer system and the kernel logic.

3. the programmable fabric is a first programmable fabric; the hardware accelerator further comprises a shell circuit formed in a second programmable fabric of the programmable device; the shell circuitry is configured to provide an interface between a computer system and the kernel logic; 2. The hardware accelerator of claim 1, wherein the IP checker circuitry obtains the device ID from the first programmable fabric of the programmable device.

4. 4. The hardware accelerator of claim 3, wherein the programmable device includes a first programmable IC having the first programmable fabric and a second programmable IC having the second programmable fabric.

5. The hardware accelerator of claim 1 , wherein the IP checker circuit is configured to include the signed whitelist.

6. 5. The hardware accelerator of claim 1, wherein the IP checker circuit receives the signed whitelist from a computer system in which the hardware accelerator is located.

7. 7. The hardware accelerator of claim 1, wherein the IP checker circuitry is configured to verify the signature of the signed whitelist by decrypting the signature, encrypted with a private key of a public / private key pair, with a public key of the public / private key pair, determining a hash of the device ID list, and comparing the hash to the decrypted signature.

8. The IP checker circuit includes: a device ID reading circuit configured to read the device ID; a memory configured to store the signed whitelist; and a checker circuit configured to compare the device ID to the device ID list and selectively assert or deassert the enable of the kernel logic. The hardware accelerator according to any one of claims 1 to 7.

9. The IP checker circuit includes: a device ID reading circuit configured to read the device ID; an interface circuit configured to receive the signed whitelist from a computer system; and a checker circuit configured to compare the device ID with the device ID list and to selectively assert or deassert the enable of the kernel logic.

10. 1. A method for locking kernel logic to a programmable device of a hardware accelerator provided in a computer system, the method comprising: forming kernel logic in a programmable fabric of the programmable device; an intellectual property (IP) checker circuit formed in the kernel logic for obtaining a device identifier (ID) of the programmable device and a signed whitelist, the signed whitelist including a device ID list and a signature; verifying the signature of the signed whitelist; comparing the device ID to the device ID list; the IP checker circuitry selectively asserting or deasserting an enable of the kernel logic in response to the presence or absence of a device ID in the device ID list and verification of the signature.

11. forming a shell circuit in the programmable fabric; The method of claim 10 , wherein the shell circuitry is configured to provide an interface between a computer system and the kernel logic.

12. the programmable fabric includes a first programmable fabric; The method further includes forming a shell circuit in a second programmable fabric of the programmable device; the shell circuitry is configured to provide an interface between a computer system and the kernel logic; 11. The method of claim 10, wherein the IP checker circuitry obtains the device ID from the first programmable fabric of the programmable device.

13. 13. The method of claim 12, wherein the programmable device includes a first programmable IC having the first programmable fabric and a second programmable IC having the second programmable fabric.

14. The method of any of claims 10 to 13, wherein the IP checker circuitry is configured with the signed whitelist or receives the signed whitelist from the computer system.

15. 15. The method of claim 10, wherein the IP checker circuitry is configured to verify the signature of the signed whitelist by decrypting the signature, encrypted with the private key of a public / private key pair, with the public key of the public / private key pair, determining a hash of the device ID list, and comparing the hash to the decrypted signature.

Images