阅读说明：本技术 被配置为支持多租户的远程信任锚的可编程集成电路 (Programmable integrated circuit configured to support multi-tenant remote trust anchor ) 是由 S·舒尔茨 P·克贝勒 A·N·特里维迪 S·韦伯 于 2020-12-16 设计创作，主要内容包括：提供了一种多租户系统,其包括主机提供商、可编程器件和多个租户。主机提供商可以公布多租户模式共享和分配策略,其包括可编程器件和租户可以遵守的条款的列表。可编程器件可以包括安全设备管理器,该安全设备管理器被配置为以多租户模式操作以将租户角色加载到可编程器件上的给定的部分重配置(PR)沙盒区域中。安全设备管理器可以用于实施不同的PR沙盒区域之间的空间隔离以及一个PR沙盒区域中的连续的租户之间的时间隔离。(A multi-tenant system is provided that includes a host provider, a programmable device, and a plurality of tenants. The host provider can publish a multi-tenant schema sharing and allocation policy that includes a list of terms that the programmable device and tenant can comply with. The programmable device may include a security device manager configured to operate in a multi-tenant mode to load a tenant role into a given Partial Reconfiguration (PR) sandbox area on the programmable device. The secure device manager may be used to implement spatial isolation between different PR sandbox regions as well as temporal isolation between successive tenants in one PR sandbox region.)

1. An integrated circuit, comprising:

a static area;

reconfiguring (PR) the sandboxed area using a first portion of the first tenant workload configuration;

reconfiguring (PR) the sandboxed area using a second portion of the second tenant workload configuration; and

a Secure Device Management (SDM) circuit configured to provide spatial isolation between the first PR sandbox region and the second PR sandbox region by preventing the first tenant workload and the second tenant workload from interfering with each other.

2. The integrated circuit of claim 1, wherein the first tenant workload comprises a partial reconfiguration area mask defining a range of configurations, and wherein the first PR sandbox area is configured using the partial reconfiguration area mask.

3. Integrated circuit according to claim 2, wherein said partial reconfiguration region mask is implemented as a logical AND mask.

4. The integrated circuit of claim 2, wherein the first tenant workload further includes a partial reconfiguration role mask defining configured content, and wherein the first PR sandbox region is further configured using the partial reconfiguration role mask.

5. The integrated circuit of claim 4, wherein the partial reconfiguration role mask is implemented as a logical or mask.

6. The integrated circuit of claim 1, further comprising:

a programmable logic resource assigned to: the static area; or one of the first and second PR sandbox regions.

7. The integrated circuit of claim 1, further comprising:

a routing connection coupling the first PR sandbox region to the second PR sandbox region, wherein the routing connection is assigned to: the static area; or one of the first and second PR sandbox regions.

8. The integrated circuit of claim 1, further comprising:

a hard function block assigned to: the static area; or one of the first and second PR sandbox regions.

9. The integrated circuit of claim 8, wherein the hard functional blocks comprise blocks selected from the group consisting of: a Random Access Memory (RAM) block and a Digital Signal Processing (DSP) block.

10. The integrated circuit of claim 1, further comprising:

an additional fill region surrounding the first and second PR sandbox regions and configured to mitigate electrical interference between the first and second PR sandbox regions.

11. The integrated circuit of any of claims 1 to 10, wherein the SDM circuit is further configured to provide temporal isolation between successive tenant workloads occupying the first and second PR sandboxed areas.

12. The integrated circuit of claim 11, wherein the SDM circuit ensures the temporal isolation by using a clean-up role for cleaning up residual data when changing tenant workloads at the first PR sandbox region or the second PR sandbox region.

13. The integrated circuit of claim 11, wherein the SDM circuitry ensures the temporal isolation by preventing the integrated circuit from entering a debug mode or returning to single user operation.

14. The integrated circuit of any of claims 1 to 10, wherein the first PR sandbox region has a first unique identifier, and wherein the second PR sandbox region has a second unique identifier.

15. The integrated circuit of any of claims 1 to 10, wherein the SDM circuit is further configured to monitor usage status and statistics of the first and second PR sandbox regions.

16. A method of operating an integrated circuit, comprising:

receiving a multi-tenant schema sharing and allocation policy from a host platform provider;

in the received multi-tenant schema sharing and allocation policy, configuring the integrated circuit using a base static image; and

operating the integrated circuit in a multi-tenant mode that ensures temporal isolation between tenants running on multiple Partial Reconfiguration (PR) sandboxed areas on the integrated circuit.

17. The method of claim 16, further comprising:

using a quasi-tenant's certificate of authenticity to determine whether the quasi-tenant is authorized.

18. The method of claim 16, further comprising:

receiving a Partial Reconfiguration (PR) sandbox workload from a tenant; and

checking the received PR sandbox workload against one or more terms in the multi-tenant schema sharing and allocation policy.

19. The method of claim 18, wherein checking the received PR sandbox workload for one or more terms of the multi-tenant schema sharing and allocation policy comprises: comparing a region mask in the PR sandboxed workload of the tenant with a partial reconfiguration region whitelist in the multi-tenant schema sharing and allocation policy.

20. The method of claim 18, further comprising:

after checking the received PR sandbox workload for one or more terms in the multi-tenant schema sharing and allocation policy, loading a tenant role into a selected one of the PR sandbox regions using a role mask in the PR sandbox workload.

21. The method of any of claims 16 to 20, further comprising:

determining whether a new tenant is replacing a previous tenant in a given one of the PR sandboxed areas; and

in response to determining that the new tenant is replacing the previous tenant in a given one of the PR sandbox areas, performing a security offload operation by loading a clean role associated with the previous tenant and cleaning residual data from the previous tenant.

22. A system, comprising:

a cloud service provider configured to define a multi-tenant schema contract;

a programmable integrated circuit using a basic static image configuration in the multi-tenant mode contract; and

a tenant operable to upload a tenant workload into a selected one of a plurality of partial reconfiguration regions on the programmable integrated circuit, wherein the programmable integrated circuit uses the multi-tenant mode contract to determine whether the tenant is allowed to upload its tenant workload into the selected one of the plurality of partial reconfiguration regions.

23. An integrated circuit, comprising:

a unit for receiving a multi-tenant schema sharing and allocation policy from a host platform provider;

means for configuring the integrated circuit using a base static image in the received multi-tenant mode sharing and allocation policy; and

a unit for operating the integrated circuit in a multi-tenant mode that ensures temporal isolation between tenants running on multiple Partial Reconfiguration (PR) sandboxed areas on the integrated circuit.

24. The integrated circuit of claim 23, further comprising:

a unit for using a certificate of authenticity of a quasi-tenant to determine whether the quasi-tenant is authorized.

25. The integrated circuit of any of claims 23 to 24, further comprising:

a unit for receiving a Partial Reconfiguration (PR) sandbox workload from a tenant; and

a unit for checking a received PR sandbox workload for one or more terms of the multi-tenant schema sharing and allocation policy.

Background

The programmable logic device may be configured to support a multi-tenant usage model. A multi-tenant usage model arises where a single appliance is provided by a server to support N clients. It is assumed that clients do not trust each other, that clients do not trust the server, and that the server does not trust the clients. The multi-tenant model is configured using a basic configuration followed by an arbitrary number of partial reconfigurations (i.e., a process that changes only a subset of the configuration bits while the rest of the devices continue to execute). The server is typically managed by some trusted party (e.g., a cloud service provider).

In a conventional multi-tenant scenario, programming and sharing of resources on programmable logic devices is managed by a cloud service provider. In particular, the cloud service provider may validate bitstreams from multiple tenants using a software constraint checker to determine whether each tenant bitstream complies with a set of predefined multi-tenant rules established for the programmable device. However, the software constraint checker requires plain text access, so this solution is not suitable for encrypted client Intellectual Property (IP) and is even more difficult to extend to third party IP. Furthermore, tenants cannot guarantee that the cloud service provider will execute the software constraint checker correctly before uploading other tenant bitstreams, and that the cloud service provider will manage multiple tenants according to predefined rules.

Within this context, the embodiments described herein appear.

Drawings

FIG. 1 is a diagram of an illustrative programmable integrated circuit in accordance with an embodiment.

FIG. 2 is a diagram that illustrates how configuration data is created by a logic design system and loaded into a programmable device to configure the device for operation in the system, according to an embodiment.

FIG. 3 is an illustration of a circuit design system that may be used to design an integrated circuit, according to an embodiment.

Fig. 4 is a diagram of an illustrative computer-aided design (CAD) tool that may be used in a circuit design system, according to an embodiment.

FIG. 5 is a flow diagram of illustrative steps for designing an integrated circuit, according to an embodiment.

Fig. 6 is a diagram of an illustrative multi-tenant system, according to an embodiment.

Fig. 7 is a diagram of a programmable integrated circuit having a static region and multiple Partial Reconfiguration (PR) sandboxed regions according to an embodiment.

Fig. 8A is a diagram of an illustrative PR sandbox payload according to an embodiment.

Fig. 8B is a diagram illustrating operations of a Partial Reconfiguration (PR) area mask and a Partial Reconfiguration (PR) role mask according to an embodiment.

Figures 9A-9C are flow diagrams of illustrative steps for operating a multi-tenant system, according to embodiments.

Detailed Description

The present embodiments relate to methods and apparatus for supporting flexible and secure sharing of programmable integrated circuit resources in a cloud between multiple tenants. A modular multi-tenant security system architecture is provided that can be customized by a Cloud Service Provider (CSP) to meet resource allocation requirements while ensuring that isolation between multiple tenants is maintained on a programmable integrated circuit device.

The programmable integrated circuit may be configured to allow only well-defined partial reconfigurations and to implement a valid instantiated remote trust anchor. Configured in this manner, the programmable integrated circuit can run parallel workload execution from multiple tenants in separate execution units (e.g., run tenant payloads in well-defined partial reconfiguration sandboxes), which reduces the burden and trust requirements on the CSP, while enabling additional applications, such as performing third party encrypted Intellectual Property (IP) in a PR sandbox, as part of the customer design.

It will be recognized by one skilled in the art that the present exemplary embodiments may be practiced without some or all of these specific details. In other instances, well-known operations have not been described in detail so as not to unnecessarily obscure the present embodiments.

Programmable integrated circuits use programmable memory elements to store configuration data. During programming of the programmable integrated circuit, configuration data is loaded into the memory elements. The memory elements may be organized in an array having a number of rows and columns. For example, memory array circuits may be formed in hundreds or thousands of rows and columns on a programmable logic device integrated circuit.

During normal operation of the programmable integrated circuit, each memory element is configured to provide a static output signal. The static output signal supplied by the memory element serves as a control signal. These control signals are applied to programmable logic on the integrated circuit to customize the programmable logic for performing the desired logic function.

It may sometimes be desirable to reconfigure only a portion of the memory elements during normal operation. This type of reconfiguration, in which only a subset of the memory elements are loaded with new configuration data during runtime, is sometimes referred to as a "partial reconfiguration". During partial reconfiguration, new data should be written to selected portions of the memory elements (sometimes referred to as "memory cells").

An illustrative programmable integrated circuit (e.g., Programmable Logic Device (PLD)10) is shown in fig. 1. As shown in fig. 1, programmable integrated circuit 10 may have input-output circuitry 12 for driving signals off device 10 and for receiving signals from other devices via input-output pins 14. Interconnect resources 16 (e.g., global and local vertical and horizontal wires and buses) may be used to route signals on device 10. Interconnect resources 16 include fixed interconnects (wires) and programmable interconnects (i.e., programmable connections between respective fixed interconnects). Programmable logic 18 may include combinational and sequential logic circuits. Programmable logic 18 may be configured to perform custom logic functions.

Programmable integrated circuit 10 contains memory element 20, which memory element 20 can be loaded with configuration data (also referred to as programming data) using pins 14 and input-output circuitry 12. Once loaded, memory elements 20 may each provide a corresponding static control output signal that controls the state of an associated logic component in programmable logic 18. Typically, the memory element output signal is used to control the gate of a Metal Oxide Semiconductor (MOS) transistor. Some of the transistors may be p-channel metal oxide semiconductor (PMOS) transistors. Many of these transistors may be n-channel metal oxide semiconductor (NMOS) pass transistors in a programmable component (e.g., a multiplexer). When the memory element output is high, the NMOS pass transistor controlled by the memory element will be turned on to pass the logic signal from its input to its output. When the memory element output is low, the pass transistor is turned off and does not pass logic signals.

A typical memory element 20 is formed from a plurality of transistors configured to form cross-coupled inverters. Other arrangements (e.g., cells with more distributed inverter-like circuits) may also be used. By one suitable approach, Complementary Metal Oxide Semiconductor (CMOS) integrated circuit technology is used to form the memory element 20, and thus embodiments of CMOS-based memory elements are described herein as examples. In the context of programmable integrated circuits, memory elements store configuration data and are therefore sometimes referred to as Configuration Random Access Memory (CRAM) cells.

An illustrative system environment for device 10 is shown in fig. 2. The device 10 may be mounted on a board 36 in a system 38. In general, programmable logic device 10 may receive configuration data from a programming device or from other suitable devices or devices. In the example of fig. 2, programmable logic device 10 is of the type that receives configuration data from an associated integrated circuit 40. With this type of arrangement, circuitry 40 may be mounted on the same board 36 as programmable logic device 10, if desired.

Circuitry 40 may be an erasable programmable read-only memory (EPROM) chip, a programmable logic device configuration data loading chip with built-in memory (sometimes referred to as a "configuration device"), or other suitable device. When system 38 is started (or at another suitable time), configuration data for configuring the programmable logic device may be supplied from device 40 to the programmable logic device, as schematically illustrated by path 42. The configuration data supplied to the programmable logic device may be stored in the programmable logic device in its configuration random access memory element 20.

System 38 may include processing circuitry 44, storage 46, and other system components 48 in communication with device 10. The components of system 38 may be located on one or more boards (e.g., board 36 or other suitable mounting structure or housing) and may be interconnected by buses, traces, and other electrical pathways 50.

Configuration device 40 may be supplied with configuration data for device 10 via a path such as path 52. Configuration device 40 may receive configuration data, for example, from configuration data loading apparatus 54 or other suitable apparatus that stores this data in configuration device 40. Device 40 may be loaded with data before or after mounting on board 36.

As shown in FIG. 2, configuration data generated by logic design system 56 may be provided to device 54 via a path, such as path 58. Device 54 provides configuration data to device 40 so that device 40 can later provide this configuration data to programmable logic device 10 via path 42. Logic design system 56 may be based on one or more computers and one or more software programs. In general, software and data may be stored on any computer-readable medium (storage device) in system 56, and is schematically illustrated in FIG. 2 as storage device 60.

In a typical scenario, logic design system 56 is used by a logic designer to create a custom circuit design. System 56 generates corresponding configuration data that is provided to configuration device 40. At power up, data loading circuitry on configuration device 40 and programmable logic device 10 is used to load configuration data into CRAM cells 20 of device 10. The device 10 may then be used in normal operation of the system 38.

After device 10 initially loads a set of configuration data (e.g., using configuration device 40), device 10 may be reconfigured by loading a different set of configuration data. It may sometimes be desirable to reconfigure only a portion of the memory cells on device 10 via a process sometimes referred to as partial reconfiguration. Since the memory cells are typically arranged in an array, partial reconfiguration may be performed by writing new data values to only selected portions of the array while leaving portions of the array other than the selected portions in their original state.

Designing and implementing desired (custom) logic circuits in programmable logic devices can be a significant task. Logic designers therefore often use Computer Aided Design (CAD) tool based logic design systems to assist them in designing circuits. Logic design systems may assist logic designers in designing and testing complex circuits for a system. When the design is complete, the logic design system may be used to generate configuration data for electrically programming the appropriate programmable logic device.

An illustrative logic circuit design system 300 in accordance with an embodiment is shown in FIG. 3. If desired, the circuit design system of FIG. 3 may be used in a logic design system, such as logic design system 56 shown in FIG. 2. The circuit design system 300 may be implemented on an integrated circuit design computing device. For example, the system 300 may be based on one or more processors, such as personal computers, workstations, and the like. The processors may be linked using a network (e.g., a local area network or a wide area network). The memory in these computers or external memory and storage devices such as internal and/or external hard disks may be used to store instructions and data.

Software-based components, such as computer-aided design tools 320 and databases 330, reside on the system 300. During operation, executable software, such as the software of computer-aided design tool 320, runs on the processor of system 300. Database 330 is used to store data for the operation of system 300. In general, software and data can be stored on non-transitory computer-readable storage media (e.g., tangible computer-readable storage media). Software code may sometimes be referred to as software, data, program instructions, or code. The non-transitory computer-readable storage medium may include a computer memory chip, non-volatile memory such as non-volatile random access memory (NVRAM), one or more hard disk drives (e.g., magnetic drives or solid state drives), one or more removable flash drives or other removable media, a Compact Disc (CD), a Digital Versatile Disc (DVD), a blu-ray disc (BD), other optical media, and a floppy disk, tape, or any other suitable memory or storage device.

Software stored on a non-transitory computer-readable storage medium may be executed on the system 300. When the software of system 300 is installed, the storage of system 300 has instructions and data that cause the computing devices in system 300 to perform the various methods (processes). When performing these processes, the computing device is configured to implement the functionality of circuit design system 300.

Computer-aided design (CAD) tools 320 (some or all of which are sometimes collectively referred to as CAD tools), circuit design tools, or Electronic Design Automation (EDA) tools may be provided by a single vendor or by multiple vendors. The tools 320 may be provided as one or more kits of tools (e.g., a set of compilers for performing tasks associated with implementing circuit designs in programmable logic devices) and/or as one or more separate software components (tools). Database 330 may include one or more databases that are only accessible by one or more particular tools, and may include one or more shared databases. The shared database may be accessed by multiple tools. For example, the first tool may store data of the second tool in a shared database. The second tool may access the shared database to retrieve the data stored by the first tool. This allows one tool to transmit information to another tool. If desired, the tools may also transfer information between each other without storing the information in a shared database.

Fig. 4 shows an illustrative computer-aided design tool 420 that may be used in a circuit design system, such as the circuit design system 300 of fig. 3.

The design process may begin with the formulation of a functional specification for the integrated circuit design (e.g., a functional or behavioral description of the integrated circuit design). The circuit designer may use design and constraint input tools 464 to specify the functional operation of the desired circuit design. The design and constraint input tools 464 may include tools such as design and constraint input assistance tools 466 and design editor 468. Design and constraint input assist tools, such as assist tool 466, may be used to assist a circuit designer in locating a desired design from a library of existing circuit designs, and may provide computer-aided assistance to the circuit designer for inputting (specifying) the desired circuit design.

As an example, the design and constraint input assistant 466 may be used to present a screen of options for the user. The user may click on an on-screen option to select whether the circuit being designed should have certain functionality. The design editor 468 may be used to enter a design (e.g., by entering a line of hardware description language code), may be used to edit a design obtained from a library (e.g., using design and constraint entry assistance tools), or may assist a user in selecting and editing an appropriate prepackaged code/design.

Design and constraint input tools 464 may be used to allow a circuit designer to provide a desired circuit design using any suitable format. For example, design and constraint entry tools 464 may include tools that allow a circuit designer to enter a circuit design using a truth table. The truth table may be specified using a text file or a timing diagram and may be imported from a library. The truth table circuit design and constraint inputs may be used for a portion of a larger circuit or for the entire circuit.

As another example, the design and constraint input tools 464 may include schematic capture tools. The schematic capture tool may allow a circuit designer to intuitively build an integrated circuit design from constituent parts (e.g., logic gates and groups of logic gates). A library of pre-existing integrated circuit designs may be used to allow for the introduction of desired portions of the design with a schematic capture tool.

If desired, the design and constraint input tools 464 may allow a circuit designer to provide a circuit design to the circuit design system 300 using a hardware description language such as: verilog hardware description language (Verilog HDL), very high speed integrated circuit hardware description language (VHDL), systemveilog, or higher level circuit description languages (e.g., OpenCL or SystemC, to name a few). A designer of an integrated circuit design may enter the circuit design by writing hardware description language code with the editor 468. If desired, the code blocks may be imported from a user-maintained library or a commercial library.

After the design has been entered using the design and constraint input tools 464, a behavior simulation tool 472 may be used to simulate the functionality of the circuit design. If the function of the design is incomplete or incorrect, the circuit designer may use the design and constraint input tools 464 to make changes to the circuit design. The behavioral simulation tool 472 may be used to verify the functional operation of the new circuit design before the synthesis operation has been performed using the tool 474. Simulation tools, such as behavior simulation tool 472, may also be used at other stages in the design flow (e.g., after logic synthesis), if desired. The output of the behavior simulation tool 472 may be provided to the circuit designer in any suitable format (e.g., truth table, timing diagram, etc.).

Once the functional operation of the circuit design has been determined to be satisfactory, the logic synthesis and optimization tool 474 may generate a gate-level netlist of the circuit design, for example, using gates from a particular library associated with a target process that has been selected to be supported by a foundry that produces the integrated circuit. Alternatively, the logic synthesis and optimization tool 474 may use the gates of the target programmable logic device to generate a gate-level netlist of the circuit design (i.e., in the logic and interconnect resources of a particular programmable logic device product or product family).

Logic synthesis and optimization tool 474 may optimize a design by making appropriate selections of hardware to implement different logic functions in a circuit design based on circuit design data and constraint data entered by a logic designer using tool 464. As an example, logic synthesis and optimization tool 474 may perform multi-level logic optimization and technology mapping based on the length of the combined path between registers in the circuit design and the corresponding timing constraints input by the logic designer using tool 464.

After logical synthesis and optimization using the tool 474, the circuit design system may perform physical design steps (layout synthesis operations) using tools such as the placement, routing, and physical synthesis tool 476. Tool 476 may be used to determine the location of each gate that lays out the gate level netlist generated by tool 474. For example, if two counters interact with each other, the tool 476 may place the counters in adjacent regions to reduce interconnect delay or meet timing requirements specifying a maximum allowed interconnect delay. The tool 476 creates an ordered and efficient implementation of a circuit design for any target integrated circuit, e.g., for a given programmable integrated circuit such as a Field Programmable Gate Array (FPGA).

The tools, such as tools 474 and 476, may be part of a compiler suite (e.g., part of a compiler suite of tools provided by a programmable logic device vendor). In certain embodiments, tools such as tools 474, 476, and 478 may also include a timing analysis tool such as a timing estimator. This allows tools 474 and 476 to meet performance requirements (e.g., timing requirements) before the integrated circuit is actually produced.

After the implementation of the desired circuit design has been generated using tool 476, the implementation of the design can be analyzed and tested using analysis tool 478. For example, analysis tools 478 may include a timing analysis tool, a power analysis tool, or a form verification tool, to name a few.

After the tool 420 has been used and satisfactory optimization operations have been completed depending on the target integrated circuit technology, the tool 420 may generate a mask level layout description of the integrated circuit or configuration data for programming the programmable logic device.

Illustrative operations involved in generating a mask level layout description of an integrated circuit using the tool 420 of FIG. 4 are shown in FIG. 5. As shown in FIG. 5, a circuit designer may first provide a design specification 502. Design specification 502 can generally be a behavioral description provided in the form of application code (e.g., C code, C + + code, SystemC code, OpenCL code, etc.). In some scenarios, the design specification may be provided in the form of a Register Transfer Level (RTL) description 506.

The RTL description may have any form of circuit function describing the register transfer level. For example, a hardware description language such as: verilog hardware description language (Verilog HDL or Verilog), SystemVerilog hardware description language (SystemVerilog HDL or SystemVerilog), or very high speed integrated circuit hardware description language (VHDL). If desired, some or all of the RTL description can be represented schematically or provided in code using OpenCL, MATLAB, Simulink, or other high-level synthesis (HLS) languages.

In general, behavior design specification 502 may include un-timed or partially timed functional code (i.e., application code does not describe cycle-by-cycle hardware behavior), while RTL description 506 may include a fully-timed design description detailing the cycle-by-cycle behavior of the circuitry at the register transfer level.

The design specification 502 or the RTL description 506 may also include target criteria (e.g., area usage, power consumption, delay minimization, clock frequency optimization, or any combination thereof). The optimization constraints and the target criteria may be collectively referred to as constraints.

These constraints may be provided for an individual data path, a portion of a design, or the entire design. For example, constraints may be provided with design specification 502, RTL description 506 (e.g., as a compilation directive or assertion), in a constraint file or by user input (e.g., using design and constraint input tool 464 of FIG. 4), to name a few.

At step 504, behavior synthesis (also sometimes referred to as algorithmic synthesis) may be performed to convert the behavior description to an RTL description 506. If the design specification has been provided in the form of an RTL description, step 504 may be skipped.

At step 518, the behavior simulation tool 472 may perform an RTL simulation of the RTL description, which may verify the functionality of the RTL description. If the function of the RTL description is incomplete or incorrect, the circuit designer may change the HDL code (as an example). During RTL simulation 518, actual results obtained from simulating the behavior described by the RTL may be compared to expected results.

During step 508, the logic synthesis operation may use the logic synthesis and optimization tool 474 from FIG. 4 to generate a gate level description 510. The output of the logic synthesis 508 is a gate level description 510 of the design.

During step 512, the placement operation (using, for example, the placement tool 476 of fig. 4) may place the different gates in the gate level description 510 at preferred locations on the target integrated circuit to meet given target criteria (e.g., minimize area and maximize routing efficiency or minimize path delay and maximize clock frequency or minimize overlap between logic elements, or any combination thereof). The output of the arrangement 512 is a arranged gate level description 513 that satisfies the legal arrangement constraints of the underlying target device.

During step 515, the gates may be connected according to the arranged gate level description 513 using, for example, routing operations of the routing tool 476 of fig. 4. The routing operation may attempt to meet a given target criteria (e.g., minimize congestion, minimize path delay and maximize clock frequency, meet minimum delay requirements, or any combination thereof). The output of the route 515 is a mask level layout description 516 (sometimes referred to as a route gate level description 516). The mask level layout description 516 generated by the design flow of fig. 5 may sometimes be referred to as a device configuration bitstream or a device configuration image.

While placement and routing is being performed at steps 512 and 515, a physical synthesis operation 517 may be performed simultaneously to further modify and optimize the circuit design (e.g., using the physical synthesis tool 476 of fig. 4).

Programmable integrated circuit device 10 may be configured using the tools described in fig. 2-5 to support a multi-tenant usage model or scenario. Examples of programmable logic devices include Programmable Array Logic (PAL), Programmable Logic Arrays (PLA), Field Programmable Logic Arrays (FPLA), Electrically Programmable Logic Devices (EPLD), Electrically Erasable Programmable Logic Devices (EEPLD), Logic Cell Arrays (LCA), Complex Programmable Logic Devices (CPLD), and Field Programmable Gate Arrays (FPGA), to name a few. System configurations in which device 10 is a programmable logic device such as an FPGA are sometimes described as examples, but are not intended to limit the scope of the present embodiments.

Fig. 6 is an illustration of a multi-tenant system, such as system 600, according to an embodiment. As shown in fig. 6, system 600 may include at least a host platform provider 602 (e.g., a server, cloud service provider, or "CSP"), a programmable integrated circuit device 10 such as an FPGA, and a plurality of tenants 604 (sometimes referred to as "clients"). CSP 602 may interact with FPGA 10 via communications path 680 and may interact in parallel with tenant 604 via communications path 682. FPGA 10 can interact with tenants 604 individually via communication path 684. In the multi-tenant usage model, FPGAs 10 may be provided by CSPs 602 to support each of the individual tenants/clients 604 running their own separate applications. It may be assumed that tenants do not trust each other, that clients do not trust CSPs, and that CSPs do not trust tenants.

Cloud service provider 602 may provide cloud services to a plurality of cloud customers (i.e., tenants) that are accelerated on one or more accelerator devices, such as Application Specific Integrated Circuits (ASICs), Graphics Processor Units (GPUs), and FPGAs. In the context of an FPGA-as-a-service usage model, cloud service provider 602 can offload more than one workload to FPGA 10, such that multiple tenant workloads can run simultaneously on the FPGA as different Partial Reconfiguration (PR) workloads. In such a scenario, the FPGA 10 needs to provide the necessary security guarantees and PR workload isolation when executing security-sensitive workloads (or payloads) on the FPGA.

Cloud service provider 602 may define a multi-tenant mode (MTM) sharing and allocation policy 610. The MTM sharing and allocation policy 610 may set forth a base configuration bitstream such as a base static image 612, a partial reconfiguration region whitelist such as a PR whitelist 614, peek and snoop vectors (peek and poke vectors) 616, timing and energy constraints 618 (e.g., timing and power requirements of each potential tenant or the entire multi-tenant system), deterministic data assets 620 (e.g., a hash list of binary assets or other reproducible components that may be used to verify proper loading of tenant workloads into each PR region), and so forth. Policy 610 is sometimes referred to as an FPGA multi-tenant mode contract. One or more components of the MTM sharing and allocation policy 610 (e.g., the base static image 612, the PR region whitelist 614, and the peek/snoop vector 616) may be generated by a cloud service provider using the engineering tool 420 of fig. 4.

The base static image 612 may define a base design of the device 10 (see, e.g., fig. 7). As shown in fig. 7, the base static image 612 may define an input-output interface 704, one or more static zones 702, and a plurality of Partial Reconfiguration (PR) zones, each of which may be assigned to a respective tenant to support isolated workloads. Static area 702 may be an area that: where all parties agree that the configuration bits cannot be changed by a partial reconfiguration initiated or triggered by one of the tenants. For example, the static area may be owned and optionally updated or reconfigured by the server/host/CSP. The static area 702 may also be part of a server/host/CSP shell (shell) or platform logic. Any resources on the device 10 should be assigned to one of the PR regions or to the static region 702 (but not to both).

The PR region whitelist 614 may define a list of available PR regions 630 (see fig. 6). Each PR region used to host a particular tenant may be referred to as a PR "sandbox" in the sense of providing a Trusted Execution Environment (TEE) for providing spatial/physical isolation and preventing potential undesirable interference between multiple tenants. Each PR sandbox may provide such guarantees: the contained PR tenant workload (sometimes referred to as a PR client role) is limited to configuring a specified subset of its FPGA fabric and is protected from access by other PR workloads. The exact assignment of the PR sandbox area and the boundary 660 of each PR sandbox may also be defined by the base still image. Additional reserved fill areas, such as area 706 in fig. 7, may be used to avoid electrical interference and coupling effects such as crosstalk. Additional circuitry may also be formed in fill area 706 for actively detecting and/or compensating for unwanted effects generated due to electrical interference, noise, or surge.

Any wires, such as wire 662 that crosses the boundary of a PR sandbox, may be assigned to the associated PR sandbox or static region 702. If a wire 662 that crosses a boundary is assigned to a PR sandbox area, the routing multiplexers outside that sandbox area of the control wire should be marked as unused. If wires 662 that cross a boundary are assigned to a static region, routing multiplexers within that sandboxed region of the control wire should be marked as not belonging to that sandboxed region (e.g., these routing multiplexers should be removed from the corresponding PR region masks described later in connection with FIG. 8A).

Any hard (non-reconfigurable) embedded Intellectual Property (IP) blocks (e.g., memory blocks (e.g., random access memory blocks) or Digital Signal Processing (DSP) blocks) formed on the FPGA 10 may also be assigned to PR sandboxes or static areas. In other words, any given hard IP functional block should be fully owned by a single entity (e.g., any fabric configuration for the corresponding embedded functional block is assigned to the corresponding PR sandbox or static region).

In the example of FIG. 7, there may be six PR sandboxed areas (e.g., sandboxed areas SB1-SB 6). The PR regions may be the same size or may be different sizes and/or shapes. In general, the device 10 may include any suitable number of PR sandboxed regions separate from the static region 702.

As described above, the configuration bit provisioning is done such that the set of configuration bits associated with control of an Intellectual Property (IP) block is owned by a single party. For the compute elements and the memory IP blocks, an ownership set of configuration bits is organized such that configuration bits that control communication to and from the IP blocks are separate from configuration bits that control functionality of the compute elements or the memory IP blocks. Communication between IP blocks is controlled by the configuration of the routing multiplexer, and the configuration bit for the routing multiplexer is owned by a single party.

To build the design, the compute elements and memory use a routing multiplexer to create the communication channel. For this disclosure, it is assumed that the provision of the set of configuration bits for the compute elements, memory, and route IPs is done in a non-malicious manner, enabling the partial reconfiguration region and static region owners to create a functional design that they fully control, including how it interfaces with other partial reconfiguration regions and/or static regions.

The ability of a region to peek and/or snoop on another region not owned by the region stems from the fact that: configurable devices have a large routing network and routing multiplexers owned by one area that may be configured to attach to wires driven by another area. With the described ownership model, this configuration will not be considered illegal and will allow the owning region to snoop other regions and/or create parasitic loads to disrupt the functionality of the non-owning region.

If the zone with drivers is one that creates this malicious connection, it can corrupt the receiving zone by placing multiple drivers on the routing multiplexer. For the described ownership model, this configuration will be considered illegal. However, the problem is symmetrical and is therefore also addressed in this disclosure, and may occur if one party is compromised and can violate ownership of the configuration bits.

To facilitate a "peeking" attack, the basic configuration of the static region and the partial reconfiguration region or a subsequent partial reconfiguration of the partial reconfiguration region would have to configure its own routing multiplexer to snoop on another region. To prevent this, the exclusion area configuration is extracted based on providing the configuration bits to the parties involved. This exclusion zone configuration also protects against symmetric "snoop" attacks. In other words, the exclusion zone defines a bit (when cleared) that halts the peek/snoop attack. In some embodiments, peeking and snooping attacks are disabled by applying this exclusion zone configuration using partial reconfiguration. In some embodiments, dynamic checking for exclusion zone configuration is applied to avoid and detect peeking and snooping attacks.

After the trusted compilation flow has completed providing all configuration bits to the involved parties in their entirety, and after each configuration bit is owned by a partial reconfiguration region or a static region, analysis on the route occurs to create an excluded region configuration. The trusted compilation process has the ability to analyze where peeking and snooping possibilities exist based on physical routing and configuration resources. Thus, the exclusion zone may be generally defined as a set of configuration bits set to zero to prevent any malicious peeking/snooping attacks between different parties in a multi-tenant usage scenario on device 10. Such exclusion zones may be defined by peek/snoop vectors 616 (fig. 6) and may effectively serve to break any long wires that actively communicate signals between adjacent PR sandboxes.

As shown in fig. 6, the FPGA 10 may include control circuitry (e.g., Secure Device Management (SDM) circuitry 650) that controls the overall FPGA fabric configuration. The Secure Device Manager (SDM)650 provides the ability to authorize and decrypt new configuration bitstreams based on previously provided platform owner keys. The secure device manager 650 may also control the overall FPGA platform operation (e.g., allow the FPGA to enter debug mode or handle hardware errors). Operating in this manner, SDM 650 may act as a platform root of trust that may enable secure operation of authorized tenant workloads. During runtime, the SDM 650 supports partial configuration by loading a new configuration bitstream associated with a given tenant (sometimes referred to as a PR "role") targeting a particular PR sandboxed area. In the example of fig. 6, a first tenant 604 may load a first tenant role X into a corresponding PR sandbox area on the device 10, while a second tenant may load a second tenant role Y into another PR sandbox area on the device 10, and so on. Each tenant may have a certificate 605 (or key) for authenticating the device 10.

As described above, partial reconfiguration allows the FPGA platform owner to modify a portion of the deployed FPGA configuration during runtime. Each PR sandbox area may be partially reconfigured using a PR sandbox workload (sometimes also referred to as a tenant payload). As shown in fig. 8A, the PR sandboxed workload 800 may include a Partial Reconfiguration (PR) area mask 802, a Partial Reconfiguration (PR) role mask 804, a partial reconfiguration sort command 806, a partial reconfiguration clear role 808, one or more unique identifiers 810, and/or the like.

The PR region mask 802 may be used to define the range of configuration changes on the FPGA fabric and is sometimes referred to as a region "ownership" mask. PR role mask 804 may be used to define the contents of the configuration change. The PR bitstream may be applied in a read-modify-write fashion (as an example) to deploy detailed modifications to a particular logic design. Fig. 8B illustrates how the PR region mask 802 may be implemented as a logical and mask that defines the locations where potential tenants may set or modify bits in the FPGA fabric. Fig. 8B also shows how the PR personal mask 804 may be implemented as a logical or mask that writes the actual content/character into the area defined by the PR region and mask.

A unique Identifier (ID)810 may be used to track a given workload (e.g., any individual PR sandbox should be given a unique ID). For example, a cryptographic hash of the PR region mask 802, along with the target chip manufacturer/model, may be used as a string that uniquely identifies a set of configuration bits that define a PR sandbox.

The PR ordering command 806 defines a series of steps to ensure successful partial reconfiguration of the FPGA fabric. For example, the timing and order of commands to reset or reconfigure portions of the FPGA fabric should be guaranteed by the FPGA device independent of the cloud service provider. For this purpose, a security device manager on the FPGA may monitor relevant parameters in the PR ordering command 806 during partial reconfiguration and raise an exception if a violation is identified. An exception should be raised to the relevant PR requester (e.g., tenant or cloud service provider) followed by an appropriate clean-up sequence for cleaning up the potential "dirty" role.

Roles may be marked as dirty if the desired partial configuration has been aborted unsuccessfully or is no longer needed by the tenant. In this case, a reset/erase sequence may be used to clear the configuration of the PR sandbox region and also clear any potential remnant data remaining in the intermediate buffer and memory (e.g., ensuring that no intermediate state remains in the PR sandbox). For example, the purge logic may be implemented as a dedicated PR purge role 808. A cleanup role 808 can be automatically loaded between actual tenant workloads to clean up buffers or memory owned by previous tenants in the PR sandbox. The cleanup role 808 may be specific to a particular role in order to minimize additional latency for cleaning sensitive data, or may be generic code that cleans any data defined by a particular PR sandbox. If the cleanup role 808 is specific to a particular role, the cleanup role 808 is embedded as part of the corresponding tenant workload (as shown in FIG. 8A). If the cleanup role is some generic cleanup code, the cleanup roles for the various defined PR sandboxed areas can be embedded as part of the base static image and uploaded to the FPGA as part of the initial device configuration.

In scenarios where the clean role cannot be guaranteed (e.g., even after power cycling the FPGA device), a full erase of the PR region may be performed. The steps and operations involved in ensuring successful partial reconfiguration and subsequent clearing of unwanted roles can effectively help provide temporal isolation to ensure that no sensitive information leaks from previous tenants to newly imported tenants across time, and are sometimes referred to as part of a multi-tenant mode (MTM) supported by FPGA devices using a security device manager. When operating in multi-tenant mode, SDM enables secure provisioning and lifecycle management of PR sandboxed workloads.

One or more components of PR workload 800 (e.g., PR region mask 802 and PR role mask 804) may be generated by a tenant using design tool 420 of fig. 4. This build process can be verified by a third party to confirm the spatial and temporal isolation of a given role loaded into a given PR sandbox area. To enable verification of the security of the PR sandbox definition and the overall FPGA platform configuration settings, the components of the PR sandbox workload may be checked against the MTM sharing and allocation policy 610 (fig. 6) to establish trust in the remote cloud infrastructure.

Figures 9A-9C are flow diagrams of illustrative steps for operating a multi-tenant system 600 of the type described in connection with at least figure 6. At step 902 of fig. 9A, a host platform provider, such as cloud service provider 602 (fig. 6), may define an MTM sharing and allocation policy, such as policy 610. At sub-step 904, the CSP may utilize a logic design tool (e.g., design tool 420 of fig. 4) to generate a base design such as base still image 612 with defined PR sandboxed areas and boundaries. At sub-step 906, the CSP may identify that the PR boundary crosses a wire (sometimes referred to as a "long" wire). At sub-step 908, the CSP may identify, for each PR sandbox region, any long wires that terminate in that PR region and disable the associated control bits corresponding to those wires in the respective PR region mask. Operating in this manner, the disabled long conductor is assigned to another PR sandbox area or static area.

At step 910, the FPGA device 10 may be configured using the substantially static image generated by the CSP, and then may enter a multi-tenant mode (MTM). When operating in multi-tenant mode, the FPGA device may implement an agreed MTM sharing/allocation policy or contract over the lifecycle of any deployed tenant workload independent of the platform owner (typically CSP). To support this, the secure device manager 650 on the FPGA may support the MTM mode by enforcing any PR sandbox load/unload constraints during runtime.

Upon entering the multi-tenant mode, the FPGA platform owner (e.g., CSP) may be prevented from exiting the multi-tenant mode. For example, after entering MTM, the FPGA may enforce an owner lockout mechanism (e.g., to prevent available on-chip debug functions from compromising the confidentiality of PR sandbox workloads) by, for example, prohibiting CSPs from entering debug mode or from returning single-tenant operations. If desired, the SDM 650 can also implement the CSP's management interface to view current static and statistical information associated with each PR tenant workload. For example, the SDM may monitor the type and number of PR sandboxes used by the "available PR sandboxes vs", the energy consumed, and the amount of hard IP blocks used per occupied PR sandbox, the latency per PR zone, etc. Additionally, the FPGA may provide privileged access by the CSP (as opposed to more restricted access by the tenant) to perform shutdown or throttle one or more workload operations (e.g., modify the current operating frequency of the FPGA chip).

At step 912, the CSP may publish the MTM sharing and allocation policy to existing tenants or quasi-tenants that desire to run their workloads on the shared FPGA platform.

Figure 9B shows illustrative steps that may be performed by the tenant and FPGA after step 912 of figure 9A. At step 920, the tenant may check and verify the MTM sharing and allocation policies 610 published by the CSP. For example, the tenant may validate the PR region mask in its own payload against the published peek/snoop vector in policy 610 to ensure that there are no conflicts (i.e., validate the PR region mask against the known peek/snoop vector to ensure that the PR region mask does not overlap with the exclusive peek/snoop configuration bits).

At step 922, the tenant may use the MTM sharing and allocation policy 610 to generate a partial reconfiguration bitstream to fit the target PR sandbox area on the FPGA (e.g., the tenant may use the design tool 420 of fig. 4 to generate the desired client role).

At step 924, the FPGA may send its current device configuration to the tenant using the security device manager. At step 926, the tenant may check the FPGA device configuration and certify the FPGA device configuration (e.g., by confirming whether the received device configuration or settings match the expected base design in the published policy). Once FPGA attestation is complete, the tenant may upload its PR sandbox workload to the FPGA (at step 928). As indicated by path 927, processing can optionally loop back to step 920 for each tenant in the multi-tenant system.

Fig. 9C shows illustrative steps that may be performed after step 910 of fig. 9A and may therefore optionally be performed in parallel with step 912 or the steps of fig. 9B. At step 940, the FPGA may check whether the quasi-tenant is authorized (e.g., using each tenant's certificate of authenticity or key).

At step 942, the FPGA may receive the PR sandboxed workload from the tenant and may compare the contents of the received workload to published parameters in the MTM sharing and allocation policy 610. For example, the FPGA may check whether the received tenant workload matches a corresponding component in the published sharing and allocation policies. The expected MTM partial reconfiguration must be authenticated by a valid tenant and matched to one of the PR white list regions declared in policy 610. To accomplish this, the SDM may first validate the signature of the PR sandbox bitstream against the list of tenant signing keys provided by the CSP (see certificate 605 in fig. 6). Upon matching, the SDM may then use the PR region mask included in the tenant workload to compute a unique identifier and match it to a (white) list of allowed/declared PR region masks in the policy 610.

If there is a match, and assuming the target PR sandbox region is not currently in use, the PR process is initiated and the SDM will define the scope of the partial reconfiguration using the PR region mask (e.g., AND mask) in the PR workload (at step 944). For example, the FPGA may use SDM to authorize PR requests and will use a PR role mask (e.g., or a mask) in the PR workload to load PR content into a target PR sandbox area on the FPGA.

At step 946, the FPGA may allow the loaded PR sandbox to run the tenant application while ensuring spatial isolation from other tenants currently occupying other PR sandbox areas on the FPGA. At step 948, the SDM may check whether the tenant workload is complete. If the tenant workload is not complete, processing may loop back to step 946 to continue running the tenant application (as shown by path 950). If the tenant workload is complete, the SDM may determine whether there is a tenant ownership change at the PR sandbox area (at step 952). If there is no tenant ownership change at the PR sandbox area, the process may loop back to step 942 to receive a new tenant workload from the same tenant (as shown by path 954).

If the FPGA detects that a new tenant will be occupying the PR sandbox area, the FPGA may perform a secure offload (e.g., using a clean-up role such as clean-up role 808 of FIG. 8A), and optionally clean up the residual data and keys (step 956). As described above in connection with fig. 8A, a cleanup role 808 can be automatically loaded between actual tenant workloads to clean up buffers or memory owned by previous tenants in the PR sandbox to implement time isolation between successive tenants. The cleanup role 808 may be specific to a particular role in order to minimize additional latency for cleaning sensitive data, or may be generic code that cleans any data defined by a particular PR sandbox. In a scenario where a character clear cannot be guaranteed, a complete erasure of the PR region may be performed.

Although the method of operations is described in a particular order, it is to be understood that other operations may be performed between the described operations, the described operations may be adjusted so that they occur at slightly different times, or the described operations may be distributed in a system that allows processing operations to occur at various intervals associated with the processing as long as the processing covering the operations is performed in a desired manner.

Example (c):

the following examples relate to further embodiments.

Example 1 is an integrated circuit, comprising: static areas that cannot be modified by partial reconfiguration; reconfiguring (PR) the sandboxed area using a first portion of the first tenant workload configuration; reconfiguring (PR) the sandboxed area using a second portion of the second tenant workload configuration; and Secure Device Management (SDM) circuitry configured to provide spatial isolation between the first PR sandbox region and the second PR sandbox region by preventing the first tenant workload and the second tenant workload from interfering with one another.

Example 2 is the integrated circuit of example 1, wherein the first tenant workload optionally includes a partial reconfiguration region mask defining a range of configurations, and wherein the first PR sandbox region is optionally configured using the partial reconfiguration region mask.

Example 3 is the integrated circuit of example 2, wherein the partial reconfiguration region mask is optionally implemented as a logical and mask.

Example 4 is the integrated circuit of any of examples 2-3, wherein the first tenant workload optionally further includes a partial reconfiguration role mask defining content of the configuration, and wherein the first PR sandbox region is further configured using the partial reconfiguration role mask.

Example 5 is the integrated circuit of example 4, wherein the partial reconfiguration role mask is optionally implemented as a logic or mask.

Example 6 is the integrated circuit of any one of examples 1-5, optionally further comprising: a programmable logic resource assigned to: a static area; or one of the first and second PR sandbox regions.

Example 7 is the integrated circuit of any of examples 1-6, optionally further comprising a routing connection coupling the first PR sandbox region to the second PR sandbox region, wherein the routing connection is assigned to: a static area; or one of the first and second PR sandbox regions.

Example 8 is the integrated circuit of any one of examples 1-7, optionally further comprising: a hard function block assigned to: a static area; or one of the first and second PR sandbox regions.

Example 9 is the integrated circuit of example 8, wherein the hard functional blocks optionally include blocks selected from the group consisting of: a Random Access Memory (RAM) block and a Digital Signal Processing (DSP) block.

Example 10 is the integrated circuit of any of examples 1-9, optionally further comprising: an additional fill region surrounding the first and second PR sandbox regions and configured to mitigate electrical interference between the first and second PR sandbox regions.

Example 11 is the integrated circuit of any of examples 1-10, wherein the SDM circuit is optionally further configured to provide temporal isolation between successive tenant workloads occupying the first PR sandbox area and the second PR sandbox area.

Example 12 is the integrated circuit of example 11, wherein the SDM circuit optionally ensures temporal isolation by using a clean role for cleaning residual data when changing the tenant workload at the first PR sandbox region or the second PR sandbox region.

Example 13 is the integrated circuit of any of examples 11-12, wherein the SDM circuitry optionally ensures temporal isolation by preventing the integrated circuit from entering debug mode or returning to single user operation.

Example 14 is the integrated circuit of any of examples 1-13, wherein the first PR sandbox region optionally has a first unique identifier, and wherein the second PR sandbox region optionally has a second unique identifier.

Example 15 is the integrated circuit of any of examples 1-14, wherein the SDM circuit is optionally further configured to monitor usage status and statistics of the first and second PR sandbox regions.

Example 16 is a method of operating an integrated circuit, comprising: receiving a multi-tenant schema sharing and allocation policy from a host platform provider; in the received multi-tenant schema sharing and allocation policy, configuring the integrated circuit using the base static image; and operating the integrated circuit in a multi-tenant mode that ensures temporal isolation between tenants running on multiple Partial Reconfiguration (PR) sandboxed areas on the integrated circuit.

Example 17 is the method of example 16, optionally further comprising: a quasi-tenant's certificate of authenticity is used to determine whether the quasi-tenant is authorized.

Example 18 is the method of any one of examples 16-17, optionally further comprising: receiving a Partial Reconfiguration (PR) sandbox workload from a tenant; and checking the received PR sandbox workload against one or more terms (term) in the multi-tenant schema sharing and allocation policy.

Example 19 is the method of example 18, wherein checking the received PR sandbox workload for one or more terms of the multi-tenant schema sharing and allocation policy optionally comprises: the region mask in the tenant's PR sandbox workload is compared to the partial reconfiguration region whitelist in the multi-tenant schema sharing and allocation policy.

Example 20 is the method of any one of examples 18-19, optionally further comprising: after checking the received PR sandbox workload for one or more terms in the multi-tenant schema sharing and allocation policy, the tenant role is loaded into a selected one of the PR sandbox regions using a role mask in the PR sandbox workload.

Example 21 is the method of any one of examples 16-20, optionally further comprising: determining whether a new tenant is replacing a previous tenant in a given one of the PR sandboxed areas; and in response to determining that the new tenant is replacing a previous tenant in a given one of the PR sandbox areas, performing a security offload operation by loading a clean role associated with the previous tenant and cleaning residual data from the previous tenant.

Example 22 is a system, comprising: a cloud service provider configured to define a multi-tenant schema contract; a programmable integrated circuit using a basic static image configuration in a multi-tenant mode contract; and a tenant operable to upload a tenant workload into a selected one of a plurality of partial reconfiguration regions on the programmable integrated circuit, wherein the programmable integrated circuit uses a multi-tenant mode contract to determine whether the tenant is allowed to upload its tenant workload into the selected one of the plurality of partial reconfiguration regions.

For example, all optional features of the apparatus described above may also be implemented with respect to the methods or processes described herein. The foregoing is only illustrative of the principles of the present disclosure and various modifications can be made by those skilled in the art. The foregoing embodiments may be implemented individually or in any combination.