Lock the core's execution to a licensed programmable device in the data center

Abstract

An example hardware accelerator (122) for a computer system (102) includes a programmable device (128) and further includes core logic (138) configured in a programmable fabric (3) of the programmable device and an intellectual property (IP) checker circuit (180) in the core logic. The IP checker circuit is configured to obtain (1302) a device identifier (ID) of the programmable device and a signature whitelist (1004), the signature whitelist including a device ID list (1002) and a signature (1010), verify (1104) a signature of the signature whitelist, compare (1106) the device ID to the device ID list, and selectively assert or deassert enablement of the core logic in response to the presence or absence of the device ID in the device ID list and verification of the signature, respectively.

Description

Technical Field

[0001] Examples of the present disclosure relate generally to electronic circuits, and particularly to locking execution of cores to permissive programmable devices in a data center. Background Art

[0002] Historically, third-party developers of intellectual property (IP) cores (e.g., pre-implemented circuit designs) for programmable devices have licensed their IP to system integrators on a project-by-project basis. This allows system integrators to use the IP on any number of programmable devices. For data center applications, a different usage model is required, where the IP owner allows the data center owner to execute its IP on a specific number of licensed programmable devices. It is desirable that the IP be rendered inoperable if the data center owner or a third party attempts to use the IP on any device other than the licensed device. Summary of the Invention

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

[0004] In another example, a computer system includes a processing system and a hardware accelerator coupled to the processing system. The hardware accelerator includes core logic configured in a programmable fabric of a programmable device and intellectual property (IP) checker circuitry in the core logic. The IP checker circuitry is configured to obtain a device identifier (ID) of the programmable device and a signature whitelist, the signature whitelist including a list of device IDs and a signature; verify a signature of the signature whitelist; compare the device ID with the device ID list; and selectively assert or deassert enablement of the core logic in response to the presence or absence of the device ID in the device ID list and verification of the signature, respectively.

[0005] In another example, a method of locking core logic to a programmable device of a hardware accelerator in a computer system includes: configuring the core logic in a programmable fabric of the programmable device; obtaining a device identifier (ID) and a signature whitelist of the programmable device at an intellectual property (IP) checker circuit in the core logic, the signature whitelist including a device ID list and a signature; verifying a signature of the signature whitelist; comparing the device ID to the device ID list; and selectively asserting or deasserting, by the IP checker circuit, enabling of the core logic in response to the presence or absence of the device ID in the device ID list and verification of the signature, respectively.

[0006] These and other aspects can be understood with reference to the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to enable a detailed understanding of the above features, a more particular description (briefly summarized above) may be made by reference to example implementations, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings illustrate only typical example implementations and therefore should not be considered as limiting the scope thereof.

[0008] Figure 1 is a block diagram depicting a computing system according to an example.

[0009] Figure 2 is a block diagram depicting an acceleration circuit according to an example.

[0010] Figure 3 is a block diagram depicting a design tool according to an example.

[0011] Figure 4 is a block diagram depicting a programmable device according to an example.

[0012] Figure 5 is a block diagram depicting a programmable IC according to an example.

[0013] Figure 6 is a block diagram depicting a system-on-chip (SoC) implementation of a programmable IC according to an example.

[0014] Figure 7 A field programmable gate array (FPGA) implementation of a programmable IC is shown.

[0015] Figure 8 is a block diagram depicting a cloud computing system according to an example.

[0016] Figure 9 is a flowchart depicting a method of locking a kernel for execution on a particular programmable device according to an example.

[0017] Figure 10 is a block diagram depicting a method of generating a signed whitelist of device IDs according to an example.

[0018] Figure 11 is a block diagram depicting a method of checking validity of a signature whitelist according to an example.

[0019] Figure 12 is a flowchart depicting a method of updating a whitelist according to an example.

[0020] Figure 13 is a block diagram depicting an IP inspector according to an example.

[0021] Figure 14 is a block diagram depicting an IP inspector according to another example.

[0022] Figure 15 is a block diagram depicting checker circuitry of an IP checker according to an example.

[0023] Figure 16A -C is a block diagram depicting an example of a device ID location in a programmable device.

[0024] Figure 17 is a flow chart depicting a method of locking core logic into a programmable device of a hardware accelerator in a computer system according to an example.

[0025] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements of one example may be beneficially incorporated in other examples. DETAILED DESCRIPTION

[0026] Various features are described below with reference to the accompanying drawings. It should be noted that these figures may or may not be drawn to scale, and that elements of similar structure or function are represented by the same reference numerals throughout the figures. It should be noted that these figures are merely intended to facilitate the description of the features. They are not intended to be an exhaustive description of the claimed invention or to limit the scope of the claimed invention. In addition, the examples shown do not necessarily have all the aspects or advantages shown. An aspect or advantage described in conjunction with a particular example is not necessarily limited to that example and can be practiced in any other example, even if not so stated or not so explicitly described.

[0027] Techniques for locking the execution of a core to licensed programmable devices in a data center are described. In one example, an IP check function is integrated into a partially reconfigurable core in a data center application, which allows identification of individual programmable devices. If the programmable device is on a "white list," the IP check function enables operation of the IP in the core on that programmable device. Otherwise, the IP check function disables operation of the IP on the unauthorized programmable device. The IP check function can resist attacks, such as making one programmable device look like another programmable device or by modifying the "white list" to include other programmable devices. The IP check function helps the data center and the IP owner agree to add additional programmable devices to the "white list." The IP check function can prevent large-scale deployment of such acceleration circuits without proper authorization from the developer of the acceleration circuits. These and other aspects of these techniques are described below with reference to the accompanying figures.

[0028] Figure 1 1 is a block diagram depicting a computing system 100 according to an example. Computing system 100 may be located in a data center, etc. The data center may include multiple computing systems configured similarly to computing system 100. Computing system 100 includes a server computer (server 102). Server 102 includes a hardware platform ("hardware 104") and a software platform ("software 106") executed on hardware 104. Hardware 104 includes a processing system 110, system memory 116, a storage device ("storage 118"), and hardware accelerators 122. Software 106 includes an operating system (OS) 144, driver software (driver 146), and applications 150.

[0029] Processing system 110 includes a microprocessor 112, support circuits 114, and a peripheral bus 115. Microprocessor 112 may be any type of general-purpose central processing unit (CPU), such as an x86-based processor, a The microprocessor 112 may include one or more cores and associated circuitry (e.g., cache memory, memory management unit (MMU), interrupt controller, etc.). The microprocessor 112 is configured to execute program code that performs one or more operations described herein and may be stored in the 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, 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., northbridge, southbridge, platform host controller, etc.), voltage regulators, firmware (e.g., BIOS), etc. The support circuits 114 manage data flow between the microprocessor 112 and a peripheral bus 115 to which various peripheral devices such as the hardware accelerator 122 are connected. In some examples, the microprocessor 112 may be a system-in-package (SiP), a system-on-chip (SoC), etc. that absorbs all or most of the functionality of a chipset (e.g., northbridge, southbridge, etc.). The peripheral bus may implement an expansion bus standard, such as Peripheral Component Interconnect Express (PCIe). In this example, the processing system 110 is shown separate from the hardware accelerator 122. In other examples discussed further below, the processing system 110 and the hardware accelerator 122 may be implemented on the same integrated circuit (IC).

[0030] System memory 116 is a device that allows information, such as executable instructions and data, to be stored and retrieved. System memory 116 may include, for example, one or more random access memory (RAM) modules, such as double data rate (DDR) dynamic RAM (DRAM). Storage 118 includes local storage devices (e.g., one or more hard disks, flash memory modules, solid-state drives, and optical disks) and / or storage interfaces that enable server 102 to communicate with one or more network data storage systems. 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.

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

[0032] OS 144 may be any commercial operating system known in the art, such as Microsoft Mac Driver 146 provides an application programming interface (API) to the hardware accelerator 122 for command and control. Application 150 includes software executed on the microprocessor 112, which calls the hardware accelerator 122 through driver 146 to perform a certain task. Application 150 may include a neural network, video processing, network processing, or similar type of application that offloads some functions to the hardware accelerator 122.

[0033] In operation, programmable device 128 is configured with acceleration circuitry 130. In one example, acceleration circuitry 130 includes shell circuitry 130A and application circuitry 130B. For example, acceleration circuitry 130 can be implemented using static region 134 and programmable region 136. Shell circuitry 130A is implemented in static region 134. Application circuitry 130B is implemented in programmable region 136, such as core logic 138.

[0034] If present, at least a portion of the configuration data for programmable device 128 may be stored in NVM 124. If NVM 124 is omitted, the configuration data may be stored external to hardware accelerator 122, for example, in storage 118. The configuration data for programmable device 128 may be generated by design tool 108, which may be executed on a computer system external to server 102. Design tool 108 is used to compile a circuit design into configuration data, which is then transmitted to and stored in server 102 to configure programmable device 128. In one example, the configuration data includes a base platform (BP) archive 132 for implementing shell circuit 130A and core archive(s) 120 for implementing one or more core logic 138. In one example, BP archive 132 is stored in NVM 124, and core archive(s) 120 are stored in storage 118. However, BP archive 132 may be stored in storage 118.

[0035] Static region 134 is “static” because its circuitry remains unchanged across reconfigurations of programmable region 136. In one example, static region 134 includes interface circuits (e.g., PCIe endpoint circuits, direct memory access (DMA) controllers, interconnects, memory controllers, memory interface circuits, decoupler circuits (to support partial reconfiguration), flash programmers, debug circuits, etc.).

[0036] In one example, the core logic 138 includes an IP checker 180. The IP checker 180 is configured to verify that the core logic 138 is authorized to execute in the programmable device 128. The IP checker 180 accesses a signature whitelist 121, which includes a list of valid device identifiers (IDs) of programmable devices that are authorized to execute the core logic 138. In one example, the signature whitelist 121 is stored in the storage unit 118 as a separate file or as part of the core archive 120. The signature whitelist 121 can be loaded into the programmable device 128 at configuration time or accessed from the storage 118 during runtime. In one example, the signature whitelist 121 is a certificate that includes a list of valid device IDs and a signature generated by the provider of the core logic 138 (referred to herein as the system integrator). The IP checker 180 verifies the signature of the signature whitelist 121 and then checks the device ID of the programmable device 128 against the list of device IDs in the signature whitelist 121. If both conditions are met, IP checker 180 allows core logic 138 to execute in programmable device 128. Otherwise, IP checker 180 blocks execution of core logic 138.

[0037] Figure 2 is a block diagram depicting acceleration circuitry 130 according to an example. Acceleration circuitry 130 includes interface circuitry 140 and core logic 138. In one example, interface circuitry 140 includes PCIe endpoint circuitry ("PCIe endpoint 202"), DMA controller 204, interconnect circuitry ("interconnect 206"), memory controller 210, and memory interface 212. Interface circuitry 140 may include other support circuitry (e.g., decoupler circuitry, debug circuitry, etc.) that are omitted for clarity. PCIe endpoint 202 provides a physical interface to peripheral bus 115. DMA controller 204 facilitates DMA operations to RAM 126, memory 142, and core(s) 138. Interconnect 206 couples DMA controller 204 to memory 142 and input interfaces of core(s) 138. Interconnect 206 is coupled to output interfaces of core logic 138 and memory controller 210. Memory controller 210 is coupled to memory interface 212. Memory interface 212 is coupled to RAM 126 ( Figure 1 shown).

[0038] In operation, the driver 146 can directly access the core logic 138 through the DMA controller 204. The core logic 138 can access the RAM 126 through the memory controller 210. Data can be exchanged between the software 106 and the core logic 138 using DMA operations between the system memory 116 and the RAM 126. In some examples, the IP checker 180 receives the signature whitelist 121 during runtime using DMA operations (if the signature whitelist 121 is not configured at configuration time).

[0039] Figure 3 3 is a block diagram depicting a design tool 108 according to an example. The design tool 108 includes a computer 302 having a hardware platform 304 and a software platform 306. 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 can be any type of microprocessor. The memory 310 can include, for example, one or more RAM modules, such as DDR DRAM. The storage device 312 includes a local storage device (e.g., one or more hard disks, flash memory modules, solid-state drives, and optical disks) and / or a storage interface that enables the computer 302 to communicate with one or more network data storage systems. The IO device 314 enables communication to and from the computer 302. The software platform 306 includes an OS 316 and a circuit design tool 318. The OS 316 can be any commercial operating system known in the art, such as Microsoft , Mac etc. Circuit design tool 318 is configured to generate a circuit design that can be used to program a programmable device. A user interacts with circuit design tool 318 to generate (multiple) core designs for acceleration circuit 130. Circuit design tool 318 adds IP checker 180 to each core design, as further described below. Software platform 306 may include other application software 319 for performing other functions, such as public / private key generation, encryption, decryption, etc., as further discussed herein.

[0040] Figure 4 is a block diagram depicting a programmable device 54 according to an example. The programmable device 54 includes a plurality of programmable integrated circuits (ICs) 1, such as programmable ICs 1A, 1B, 1C, and 1D. In one example, each programmable IC 1 is an IC die disposed on an interposer 51. Each programmable IC 1 includes a super logic region (SLR) 53 of the programmable device 54, such as 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.

[0041] Figure 5is a block diagram depicting a programmable IC 1 according to an example. The programmable IC 1 includes programmable logic 3 (also referred to as programmable fabric), configuration logic 25, and configuration memory 26. The programmable IC 1 can be coupled to external circuitry, such as nonvolatile memory 27, DRAM 28, and other circuitry 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 general logic functions for multiple inputs. The support circuits 31 include specialized circuits such as transceivers, input / output blocks, digital signal processors, and memories. The logic cells and support circuits 31 can be interconnected using programmable interconnects 32. Information used to program the logic cells 30, to set parameters for the support circuits 31, and to program the programmable interconnects 32 is stored in configuration memory 26 by the configuration logic 25. The configuration logic 25 can retrieve configuration data from the nonvolatile memory 27 or any other source (e.g., DRAM 28 or from other circuitry 29). In some examples, the programmable IC 1 includes a processing system 2. The processing system 2 may include microprocessor(s), memory, support circuits, IO circuits, and the like.

[0042] Figure 6 1 is a block diagram depicting a system-on-chip (SoC) implementation of a programmable IC 1 according to an example. In this example, programmable IC 1 includes a processing system 2 and programmable logic 3. 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) 11, and the like. Processing system 2 also includes various support circuits, such as on-chip memory (OCM) 14, a transceiver 7, peripherals 8, an interconnect 16, a DMA circuit 9, a memory controller 10, peripherals 15, and a multiplexed IO (MIO) circuit 13. The processing units and support circuits are interconnected via 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 generally coupled to external pin 21. The APU 5 may include a CPU 17 , memory 18 , and support circuits 19 .

[0043] exist Figure 6 In the example of FIG, programmable IC 1 can be used in hardware accelerator 122 and can function as described above. Acceleration circuit 130 can be programmed in PL 3 and function as described above. In another example, the functions of hardware 104 described above can be implemented using PS 2 rather than the hardware of the computing system. In this case, software 106 executes on PS 2 and functions as described above.

[0044] Referring to PS 2, each of the processing units 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), a floating point unit (FPU), etc. Interconnect 16 includes various switches, buses, communication links, etc., which are configured to interconnect the processing units, as well as to interconnect other components in PS 2 to the processing units.

[0045] OCM 14 includes one or more RAM modules, which can be distributed throughout PS 2. For example, OCM 14 can include battery-backed RAM (BBRAM), tightly coupled memory (TCM), etc. Memory controller 10 can include a DRAM interface for accessing external DRAM. Peripheral devices 8 and 15 can include one or more components that provide an interface to PS 2. For example, peripheral device 15 can include a graphics processing unit (GPU), a display interface (e.g., DisplayPort, High-Definition Multimedia Interface (HDMI) port, etc.), a universal serial bus (USB) port, an Ethernet port, a universal asynchronous receiver / transmitter (UART) port, a serial peripheral interface (SPI) port, a general-purpose IO (GPIO) port, a serial advanced technology attachment (SATA) port, a PCIe port, etc. Peripheral device 15 can be coupled to MIO 13. Peripheral device 8 can be coupled to transceiver 7. Transceiver 7 can include serializer / deserializer (SERDES) circuitry, an MGT, etc.

[0046] Figure 7 A field programmable gate array (FPGA) implementation of a programmable IC 1 is shown that includes a number of different programmable blocks, 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, specialized input / output blocks ("I / Os") 41 (e.g., configuration ports and clock ports), and other programmable logic 39, such as a digital clock manager, analog-to-digital converters, system monitoring logic, etc. The FPGA may also include a PCIe interface 40, an analog-to-digital converter (ADC) 38, etc.

[0047] In some FPGAs, each programmable block may include at least one programmable interconnect element ("INT") 43 having connections to input and output terminals 48 of programmable logic elements within the same block, such as Figure 7, as shown in the example included at the top of . Each programmable interconnect element 43 may also include a connection to an interconnect segment 49 of (multiple) adjacent programmable interconnect elements in the same block or (multiple) other blocks. 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 resources may include routing channels between logic blocks (not shown), including tracks of interconnect segments (e.g., interconnect segments 50) and switch blocks (not shown) for connecting the interconnect segments. The interconnect segments (e.g., interconnect segments 50) of the general routing resources may span 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 FPGA shown.

[0048] In an example implementation, the CLB 33 may include a configurable logic element ("CLE") 44 that can be programmed to implement user logic plus a single programmable interconnect element ("INT") 43. In addition to one or more programmable interconnect elements, the BRAM 34 may also include a BRAM logic element ("BRL") 45. Typically, the number of interconnect elements included in a block depends on the height of the block. In the example shown, the BRAM block has the same height as five CLBs, but other numbers (e.g., four) may also be used. In addition to an appropriate number of programmable interconnect elements, the DSP block 35 may also include a DSP logic element ("DSPL") 46. In addition to one instance of the programmable interconnect element 43, the IOB 36 may also include, for example, two instances of an input / output logic element ("IOL") 47. It will be clear to those skilled in the art that, 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.

[0049] In the example shown, a horizontal region near the center of the die (e.g. Figure 6 ) is used for configuration, clock and other control logic. Vertical columns 51 extending from this horizontal area or column are used to distribute clock and configuration signals across the width of the FPGA.

[0050] use Figure 7 Some FPGAs of the illustrated architecture include additional logic blocks that disrupt the regular columnar structure that makes up the majority of the FPGA. The additional logic blocks can be programmable blocks and / or dedicated logic.

[0051] Notice, Figure 7 This is intended to illustrate only an exemplary FPGA architecture. For example, the number of logic blocks in a row, the relative widths 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 Figure 7The interconnect / logic implementation included at the top is exemplary only. For example, in a real FPGA, any location where a CLB appears typically includes more than one adjacent CLB row to facilitate efficient implementation of user logic, but the number of adjacent CLB rows varies with the overall size of the FPGA.

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

[0053] Figure 8 8 is a block diagram illustrating a cloud computing system 800 according to an example. Cloud computing system 800 includes multiple computers 802, each computer 802 having 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 given kernel, a cloud owner may provide a list 806 of device IDs of programmable devices that require kernel execution. Device ID list 806 may be received by computer 302 and processed as described below.

[0054] Figure 9 900 is a flow chart depicting a method 900 for locking a kernel for execution on a specific programmable device according to an example. Method 900 includes step 902, in which a system integrator (e.g., a kernel developer) generates a public / private key pair using any public key cryptography system. In one example, the public key cryptography system is a Rivest-Shamir-Adleman (RSA) system, such as RSA-4096. In such a system, public key 906 is the encryption key and private key 908 is the decryption key. However, in the present system, private key 908 is used for encryption and public key 906 is used for decryption. The following signing concept will be used throughout the description: that is, encryption is performed using a private key and decryption is performed using a public key.

[0055] In RSA-4096, the public / private key is a 4096-bit key. Those skilled in the art will appreciate that other public key cryptosystems may be used. For clarity of illustration, RSA-4096 is described in the examples provided herein. Step 902 may be performed by software executed on computer 302.

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

[0057] In step 912, the system integrator generates a signature whitelist 914 based on the device ID 910 using software executed on the computer 302. The signature whitelist 914 includes the device ID 910 and the signature generated by the system integrator. The signature is generated by calculating the hash of the device ID list (e.g., the 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 by way of example, SHA-256 is described as the hash function used herein. The hash value and the private key are then fed into an encryption algorithm (e.g., using RSA-4096), which encrypts the plaintext hash value to generate a ciphertext signature (e.g., an encrypted version of the hash value).

[0058] At step 916, the system integrator generates a core with IP checker 180 using circuit design tool 318. IP checker 180 is configured with public key 906. The system integrator provides file(s) for the core and signature whitelist 914.

[0059] Figure 10 1 is a block diagram illustrating a method 1000 for generating a signed whitelist of device IDs according to an example. A device ID list 1003 includes a plurality of approved device IDs 1002 for programmable devices for which a kernel is sought to execute. Device ID list 1003 (e.g., a concatenation of device IDs 1002) is processed by a hash function 1006 (e.g., SHA-256) to generate a hash of device ID list 1003. The hash is processed by a cryptographic function 1008 using a private key of the system integrator to generate a signature 1010. A whitelist 1004 includes approved device IDs 1002 and signature 1010.

[0060] Figure 111 is a block diagram illustrating a method 1100 for checking the validity of a signed whitelist according to an example. Approved device ID 1002 is processed by hash circuitry 1102 of IP checker 180 to generate a hash value (e.g., using SHA-256). Signature 1010 is also processed by decryption circuitry 1104 of IP checker 180, which has access to the system integrator's public key. Decryption circuitry 1104 decrypts signature 1010 to generate a plaintext hash value (e.g., recovering the hash value calculated by the system integrator). Comparison circuitry 1106 compares the two hash values ​​to determine whether whitelist 1004 is valid (e.g., has not been tampered with).

[0061] Figure 12 1 is a flow chart depicting a method 1200 for updating a whitelist according to an example. The method 1200 includes step 902, in which the data center owner provides an updated list 1208 of device IDs for programmable devices that are allowed to execute kernels (e.g., the device IDs of the devices that the system integrator will approve to execute kernels). In one example, the cloud owner can obtain the device IDs by loading an unauthorized kernel into the programmable device. The IP checker 180 will prevent the kernel from executing but will provide the device ID as output (e.g., the IP checker 180 can read the device ID back from the programmable device).

[0062] At step 1210, the system integrator uses software executing on computer 302 to generate a signed whitelist 1212 based on device ID 1208 and private key 1206. Signed whitelist 1212 includes device ID 1208 and a signature generated by the system integrator. The signature is generated by calculating a hash of the device ID list and encrypting the plaintext hash to generate a ciphertext signature, as described above. At step 1216, the system integrator provides file(s) for signed whitelist 1212.

[0063] Figure 13 13 is a block diagram illustrating an example IP checker 180. IP checker 180 includes a device ID reading circuit 1302, an interface circuit 1312, a memory 1304, a control circuit 1308, and a checker circuit 1310. The output of device ID reading circuit 1302 is coupled to the inputs of checker circuit 1310 and interface circuit 1312. Control circuit 1308 is coupled to memory 1304 and has an output coupled to checker circuit 1310. The output of checker circuit 1310 is coupled to the input of interface circuit 1312.

[0064] The device ID reading circuit 1302 is configured to read the device ID of the programmable device. In this example, the memory 1304 is configured to store the signature whitelist 1306. The checker circuit 1310 is configured to receive the device ID and the signature whitelist 1306 (via the control circuit 1308). The checker circuit 1310 performs Figure 11 Method 1100 is used to verify the signature whitelist 1306. Checker circuit 1310 also compares the device ID to the verified whitelist 1306 to determine whether the device is authorized. If so, checker circuit 1310 asserts the enable output (e.g., the core is enabled). Otherwise, checker circuit 1310 deasserts the enable output (e.g., the core is disabled). IP checker 180 can output the device ID from device ID reading circuit 1302 via interface circuit 1312.

[0065] Figure 14 1 is a block diagram illustrating IP checker 180 according to another example. In this example, memory 1304 and control circuit 1308 are omitted. Instead, IP checker 180 obtains a signature whitelist from an external source (e.g., from a host computer system) via interface circuit 1312. Otherwise, IP checker 180 functions as described above.

[0066] Figure 15 1 is a block diagram depicting an example of a checker circuit 1310. 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. Device ID comparison circuit 1502 receives a signature whitelist and a device ID. Device ID comparison circuit 1502 determines whether the device ID exists in the device ID list in the signature whitelist. If so, signature decryption circuit 1506 uses the public key configured in IP checker 180 (i.e., the system integrator's public key) to decrypt the signature in the signature whitelist and recover the plaintext hash value. Message hash calculation circuit 1504 is configured to generate a hash value based on the approved device ID 1002 in the signature whitelist. Hash comparison circuit 1508 is configured to compare the two hash values ​​output by message hash calculation circuit 1504 and signature decryption circuit 1506, respectively. If the two hash values ​​match, hash comparison circuit 1508 asserts an enable output. Otherwise, hash compare circuit 1508 deasserts the enable output.

[0067] As described above, IP checker 180 operates based on the unique identifiers of programmable devices. Core developers who wish to license individual instances of their IP need access to the unique IDs of the authorized devices in order to lock the IP for execution on those devices.

[0068] Figure 16A-C is a block diagram depicting an example of a device ID location in a programmable device. Figure 16A As shown, programmable device 1602 comprises a single programmable IC (e.g., not a multi-die device). A core 1606 is configured within programmable device 1602. Core 1606 is a complete configuration of programmable device 1602 and operates without shell circuitry. In this case, core 1606 has access to all functions of programmable device 1602, including circuitry for reading device ID 1604 of programmable device 1602.

[0069] like Figure 16B As shown, programmable device 1602 comprises a single programmable IC (e.g., not a multi-die device). However, in this example, static region 1608 comprises shell circuitry that supports core 1606. Programmable device 1602 includes circuitry for reading device ID 1604. Core 1606 can access circuitry for reading device ID 1604.

[0070] like Figure 16C As shown, programmable device 1609 includes multiple programmable ICs (e.g., a multi-die device). Static region 1608 is configured in one SLR 1610 of programmable device 1609, and core 1606 is configured in another SLR 1612 of programmable device 1609. In some devices, one of the SLRs serves as a "master SLR" and one or more "slave SLRs." Assume that SLR 1610 is the master SLR with static region 1608 and SLR 1612 is the slave SLR with core 1606. Both SLR 1610 and SLR 1612 have unique device IDs and circuitry for reading the device IDs. Due to the lack of specificity, the circuitry for reading the device ID of programmable device 1609 is designed to read the device ID of the master SLR. However, it is not feasible to export the device ID from static region 1608 to core 1606 in a manner that can be proven to prevent device ID spoofing. In some cases, the data center owner can control the configuration of static region 1608. Therefore, in one example, circuit design tool 318 is configured to perform IP checks using device ID 1604 of SLR 1612. Since kernel 1606 fully configures SLR 1612, kernel 1606 can access circuitry for reading device ID 1604 of SLR 1612. Therefore, instead of performing IP checks using device ID 1604 of SLR 1610, IP checker 180 uses device ID 1604 of SLR 1612. Therefore, system integrators can be confident that device ID 1604 cannot be spoofed.

[0071] Figure 1717 is a flow chart depicting a method 1700 for locking core logic to a programmable device of a hardware accelerator in a computer system, according to an example. Method 1700 begins at step 1702, where the core logic is configured in the programmable fabric of the programmable device. In optional step 1703, a shell circuit is additionally configured in the programmable fabric of the programmable device. In step 1704, IP checker circuit 180 obtains a device ID and a signature whitelist of the programmable device. In step 1706, IP checker circuit 180 verifies the signature of the signature whitelist. In step 1708, IP checker circuit 180 compares the device ID to the device ID list. In step 1710, IP checker circuit 180 selectively asserts or deasserts the enablement of the core logic in response to the presence or absence of the device ID in the device ID list and the verification of the signature. The operations of IP checker circuit 180 for performing these steps are substantially as described above.

[0072] In one example, a hardware accelerator for a computer system is described. The hardware accelerator includes a programmable device and further includes: core logic configured in a programmable fabric of the programmable device; and intellectual property (IP) checker circuitry in the core logic. The IP checker circuitry is configured to: obtain a device identifier (ID) of the programmable device and a signature whitelist, the signature whitelist including a list of device IDs and a signature; verify a signature of the signature whitelist; compare the device ID with the device ID list; and selectively assert or deassert enablement of the core logic in response to the presence or absence of the device ID in the device ID list and verification of the signature, respectively.

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

[0074] In one example, the programmable structure is a first programmable structure, and the hardware accelerator further includes: a shell circuit configured in a second programmable structure of the programmable device, the shell circuit configured to provide an interface between the computer system and the core logic. The IP checker circuit obtains a device ID from the first programmable structure of the programmable device.

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

[0076] In one example, the IP checker circuit is configured with a signature whitelist. In one example, the IP checker circuit receives the signature whitelist from a computer system in which the hardware accelerator is disposed.

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

[0078] In one example, the IP checker circuit includes: a device ID read circuit configured to read a device ID; a memory configured to store a signature whitelist; and a checker circuit configured to compare the device ID to the device ID list and selectively assert or deassert enable of core logic.

[0079] 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 signature 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 enablement of core logic.

[0080] In one example, a method of locking core logic to a programmable device of a hardware accelerator in a computer system is described, the method comprising: configuring the core logic in a programmable fabric of the programmable device; obtaining a device identifier (ID) and a signature whitelist of the programmable device at an intellectual property (IP) checker circuit in the core logic, the signature whitelist comprising a list of device IDs and a signature; verifying a signature of the signature whitelist; comparing the device ID to the list of device IDs; and selectively asserting or deasserting, by the IP checker circuit, enabling of the core logic in response to the presence or absence of the device ID in the list of device IDs and the verification of the signature, respectively.

[0081] In one example, the method further includes configuring shell circuitry in the programmable fabric, the shell circuitry configured to provide an interface between the computer system and the core logic.

[0082] In one example, the programmable structure includes a first programmable structure, and the method further includes: configuring a shell circuit in a second programmable structure of the programmable device, the shell circuit being configured to provide an interface between the computer system and the core logic; wherein the IP checker circuit obtains the device ID from the first programmable structure of the programmable device.

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

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

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

[0086] While the foregoing is directed to particular examples, other and further examples may be devised without departing from the basic scope thereof, and the scope of the same is to be determined by the claims that follow.

Claims

1. A hardware accelerator for a computer system, the hardware accelerator comprising a programmable device, the hardware accelerator comprising: The static region, including static circuitry that is not reconfigurable; as well as core logic, configured in the programmable device, wherein the core logic is at least partially reconfigurable, and operations of the core logic are configured to be selectively enabled or disabled; and wherein the core logic includes intellectual property (IP) checker circuitry, the IP checker circuitry being configured to: Obtaining a device identifier ID and a signature whitelist of the programmable device, wherein the signature whitelist includes a device ID list and a signature; Verifying the signature of the signature whitelist; comparing the device ID with the device ID list; as well as Operation of the core logic is selectively enabled or disabled by selectively asserting or deasserting enable of the core logic based on the presence or absence of the device ID in the device ID list and verification of the signature, respectively.

2. The hardware accelerator according to claim 1, further comprising: A shell circuit is configured in the programmable fabric, the shell circuit being configured to provide an interface between the computer system and the core logic.

3. The hardware accelerator of claim 1 , wherein the core logic is configured in a first programmable structure of the programmable device, and wherein the hardware accelerator further comprises: a shell circuit configured in a second programmable structure of the programmable device, the shell circuit being configured to provide an interface between the computer system and the core logic; The IP checker circuit obtains the device ID from the first programmable structure of the programmable device. 4 . The hardware accelerator according to claim 3 , wherein the programmable device comprises a first programmable integrated circuit (IC) having the first programmable structure and a second programmable IC having the second programmable structure.

5. The hardware accelerator according to any one of claims 1 to 4, wherein the IP checker circuit is configured with the signature whitelist.

6. The hardware accelerator of any one of claims 1-4, wherein the IP checker circuit receives the signature whitelist from the computer system in which the hardware accelerator is disposed.

7. The hardware accelerator according to any one of claims 1 to 4, wherein the IP checker circuit is configured to verify the signature of the signature whitelist by: decrypting the signature using a public key of a public / private key pair, the signature being encrypted using a private key of the public / private key pair; determining a hash of the device ID list; as well as The hash is compared to the decrypted signature.

8. The hardware accelerator according to any one of claims 1 to 4, wherein the IP checker circuit comprises: a device ID reading circuit configured to read the device ID; a memory configured to store the signature whitelist; as well as A checker circuit is configured to compare the device ID with the device ID list and selectively assert or deassert the enable of the core logic.

9. The hardware accelerator according to any one of claims 1 to 4, wherein the IP checker circuit comprises: a device ID reading circuit configured to read the device ID; an interface circuit configured to receive the signature whitelist from a computer system; as well as A checker circuit is configured to compare the device ID with the device ID list and selectively assert or deassert the enable of the core logic.

10. A method for locking core logic, the method comprising: configuring core logic in a programmable device of a hardware accelerator, wherein the hardware accelerator includes a static region comprising static circuitry that is not reconfigurable, and wherein operation of the core logic is configured to be selectively enabled or disabled; Obtaining a device identifier (ID) and a signature whitelist of the programmable device at an intellectual property (IP) checker circuit in the core logic, the signature whitelist including a device ID list and a signature; Verifying the signature of the signature whitelist; comparing the device ID with the device ID list; as well as Operation of the core logic is selectively enabled or disabled by the IP checker circuit by selectively asserting or deasserting enable of the core logic based on the presence or absence of the device ID in the device ID list and verification of the signature, respectively.

11. The method according to claim 10, further comprising: A shell circuit is configured in the programmable fabric, the shell circuit being configured to provide an interface between a computer system and the core logic.

12. The method of claim 10, wherein the core logic is configured in a first programmable structure of the programmable device, and wherein the method further comprises: configuring a shell circuit in a second programmable structure of the programmable device, the shell circuit being configured to provide an interface between a computer system and the core logic; The IP checker circuit obtains the device ID from the first programmable structure of the programmable device. 13 . The method according to claim 12 , wherein the programmable device comprises a first programmable integrated circuit (IC) having the first programmable structure and a second programmable IC having the second programmable structure.

14. The method of any one of claims 11-13, wherein the IP checker circuit is configured with the signature whitelist or receives the signature whitelist from the computer system.

15. The method according to any one of claims 10 to 13, wherein the IP checker circuit is configured to verify the signature of the signature whitelist by: decrypting the signature using a public key of a public / private key pair, the signature being encrypted using a private key of the public / private key pair; determining a hash of the device ID list; as well as The hash is compared to the decrypted signature.

Images