Fault Characterization System and Method for Programmable Logic Devices

Abstract

Systems and methods for fault characterization of a secure programmable logic device (PLD) are disclosed. An exemplary system includes a secure PLD that includes a programmable logic block (PLB) and a configuration engine. The programmable logic block (PLB) is arranged in the PLD fabric of the secure PLD, and the configuration engine is configured to program the PLD fabric according to a configuration image stored in a non-volatile memory (NVM) of the secure PLD and / or coupled to the configuration engine via a configuration input / output (I / O) of the secure PLD. The secure PLD is configured to receive a fault characterization (FC) command from the PLD fabric or from an external system coupled to the secure PLD via the configuration I / O and execute the FC command to at least partially erase and / or invalidate portions of the NVM. The secure PLD may also be configured to boot a debug configuration for the PLD fabric that identifies and / or characterizes operational faults of the secure PLD.

Description

[0001] Cross - Reference to Related Applications

[0002] This patent application claims priority and the benefit of U.S. Provisional Patent Application No. 62 / 846,365, filed on May 10, 2019, entitled "SECURE BOOT SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES", the entire content of which is incorporated herein by reference.

[0003] This patent application claims priority and the benefit of U.S. Provisional Patent Application No. 62 / 756,021, filed on November 5, 2018, entitled "ASSET MANAGEMENT SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES", the entire content of which is incorporated herein by reference.

[0004] This patent application claims priority and the benefit of U.S. Provisional Patent Application No. 62 / 756,001, filed on November 5, 2018, entitled "KEY PROVISIONING SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES", the entire content of which is incorporated herein by reference.

[0005] This patent application claims priority and the benefit of U.S. Provisional Patent Application No. 62 / 756,015, filed on November 5, 2018, entitled "FAILURE CHARACTERIZATION SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES", the entire content of which is incorporated herein by reference.

[0006] This patent application claims priority and the benefit of U.S. Provisional Patent Application No. 62 / 670,487, filed on May 11, 2018, entitled "DEVICES WITH PROGRAMMABLE LOGIC AND SECURITY FEATURES AND METHODS OF USING", the entire content of which is incorporated herein by reference. TECHNICAL FIELD

[0007] The present invention generally relates to programmable logic devices, and more particularly, to characterizing faults in the security configuration and / or operation of such devices. BACKGROUND OF THE INVENTION

[0008] A programmable logic device (PLD) (e.g., a field programmable gate array (FPGA), a complex programmable logic device (CPLD), a field programmable system on chip (FPSCo), or other types of programmable devices) can be configured with various user designs to implement desired functions. Generally, a user design is synthesized and mapped to configurable resources (e.g., programmable logic gates, look-up tables (LUTs), embedded hardware, or other types of resources) and interconnects available in a particular PLD. Then, a physical layout and routing of the synthesized and mapped user design can be determined to generate configuration data for a particular PLD.

[0009] Clients of PLDs typically expend a significant amount of resources in developing a configuration for the type and / or capabilities of the PLD they have selected, and protecting the configuration data and preventing the disruption of desired operations or capabilities associated with the selected PLD and / or the developed configuration is critical for many PLD clients. Accordingly, there is a need in the art for systems and methods for manufacturing, protecting, distributing, upgrading, and testing PLDs and PLD configurations, particularly in the context of trusted computing applications and trusted computing architectures. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A block diagram of a programmable logic device (PLD) in accordance with an embodiment of the present disclosure is shown.

[0011] Figure 2 A block diagram of a logic block of a PLD in accordance with an embodiment of the present disclosure is shown.

[0012] Figure 3 A design process of a PLD in accordance with an embodiment of the present disclosure is shown.

[0013] Figure 4 A block diagram of a secure PLD in accordance with an embodiment of the present disclosure is shown.

[0014] Figure 5A A block diagram of a secure PLD supply system in accordance with an embodiment of the present disclosure is shown.

[0015] Figure 5B A block diagram of a secure PLD supply system in accordance with an embodiment of the present disclosure is shown.

[0016] Figure 6 A block diagram of a user device including a secure PLD in accordance with an embodiment of the present disclosure is shown.

[0017] Figure 7 A supply process for a locked secure PLD in accordance with an embodiment of the present disclosure is shown.

[0018] Figure 8 A fault characterization process for a locked secure PLD in accordance with an embodiment of the present disclosure is shown.

[0019] Figure 9 Shows a fault characterization process for a locked secure PLD according to an embodiment of the present disclosure.

[0020] Embodiments of the present disclosure and their advantages can be best understood by reference to the following detailed description. It should be understood that the same reference numerals are used to identify the same elements shown in one or more of the drawings, wherein the illustrations herein are for the purpose of illustrating embodiments of the present disclosure and not for the purpose of limiting the embodiments of the present disclosure. Detailed Description

[0021] The present disclosure provides systems and methods for facilitating secure return and fault characterization of a locked secure programmable logic device (PLD) (which is used in trusted computing applications and architectures), as described herein. For example, embodiments provide systems and methods for securely erasing a secure PLD that is locked to a client-defined configuration and / or operating environment suspected of harboring physical or other types of operational faults, such that a debug process can be performed on or by the secure PLD, and faults can be identified, characterized, and / or repaired / mitigated without risking loss or extraction of client data, and in some cases, without the need to isolate or otherwise destroy or waste the secure PLD, to protect secure client data or limit the distribution of unlocked secure PLDs that can be freely programmed (e.g., which can otherwise be programmed with non-client data and potentially be used to undermine various security operations for a trusted platform, such as including securely configuring and / or booting such a platform / user device), as described herein.

[0022] According to embodiments set forth herein, techniques for securely implementing a user design in a programmable logic device (PLD) are provided. In various embodiments, a user design can be converted into a set of PLD components (e.g., configured for logic, arithmetic, or other hardware functions) and their associated interconnections available in the PLD, and / or represented by the set of PLD components and their associated interconnections available in the PLD. For example, a PLD can include a plurality of programmable logic blocks (PLBs) and configurable routing resources that can be used to interconnect the PLBs and / or logic units, with each PLB including a plurality of logic units. In some embodiments, each PLB can be implemented with between 2 and 16 or between 2 and 32 logic units.

[0023] Typically, a PLD (e.g., an FPGA) structure includes one or more routing structures and an array of similarly arranged logic units disposed within programmable function blocks (e.g., PFBs and / or PLBs). The purpose of the routing structure is to programmatically connect the ports of the logic units / PLBs to each other in the necessary combinations to achieve the desired functionality. A secure PLD may include various additional “hard” engines or modules that are configured to provide operations that can be linked into the PLD structure to provide a configurable set of trusted computing functions and / or security features for the architecture. When synthesizing, mapping, placing, and / or routing a user design into multiple PLD components, routing flexibility and configurable functionality can be used. As a result of various user design optimization processes (which can result in significant design time and cost), the user design can be implemented relatively efficiently, thereby freeing up configurable PLD components that would otherwise be occupied by additional operations and routing resources. In some embodiments, the optimized user design can be represented by a netlist that identifies the various types of components provided by the PLD and their associated signals. In embodiments where a netlist of the transformed user design is generated, an optimization process can be performed on such a netlist. Once optimized, such a configuration can be encrypted and signed and / or otherwise protected for distribution to a secure PLD, and such a process can include one or more key provisioning processes as described herein.

[0024] Referring now to the drawings, Figure 1 FIG. 5 shows a block diagram of a PLD 100 in accordance with an embodiment of the present disclosure. The PLD 100 (e.g., a field programmable gate array (FPGA), complex programmable logic device (CPLD), field programmable system on chip (FPSC), or other type of programmable device) typically includes input / output (I / O) blocks 102 and logic blocks 104 (e.g., also referred to as programmable logic blocks (PLBs), programmable function units (PFUs), or programmable logic cells (PLCs)). More generally, the individual elements of the PLD 100 may be referred to as the PLD fabric.

[0025] The I / O blocks 102 provide I / O functionality for the PLD 100 (e.g., to support one or more I / O and / or memory interface standards), while the programmable logic blocks 104 provide logic functionality for the PLD 100 (e.g., LUT-based logic or logic gate array-based logic). Additional I / O functionality can be provided by serializer / deserializer (SERDES) blocks 150 and physical coding sublayer (PCS) blocks 152. The PLD 100 may also include hard intellectual property core (IP) blocks 160 to provide additional functionality (e.g., a substantially predetermined function provided in hardware that can be configured with less programming than the logic blocks 104).

[0026] The PLD 100 may also suitably include a memory block 106 (e.g., an EEPROM block, a block SRAM, and / or a flash memory), clock-related circuitry 108 (e.g., a clock source, a PLL circuit, and / or a DLL circuit), and / or various routing resources 180 (e.g., interconnects and appropriate switching logic to provide paths for routing signals throughout the PLD 100, such as for clock signals, data signals, or others). Generally, as will be understood by those skilled in the art, the various elements of the PLD 100 can be used to perform its intended functions for a desired application.

[0027] For example, certain I / O blocks 102 can be used to program the memory 106 or transfer information (e.g., various types of user data and / or control signals) to / from the PLD 100. Other I / O blocks 102 include a first programming port (which may represent a central processing unit (CPU) port, a peripheral data port, an SPI interface, and / or a sysCONFIG programming port) and / or a second programming port such as a Joint Test Action Group (JTAG) port (e.g., by adopting standards such as Institute of Electrical and Electronics Engineers (IEEE) 1149.1 or 1532 standards). In various embodiments, the I / O blocks 102 may be included to receive configuration data and commands (e.g., via one or more connections 140) to configure the PLD 100 for its intended use and support serial or parallel device configuration and information transfer with the SERDES block 150, the PCS block 152, the hard IP block 160, and / or the logic block 104 as appropriate.

[0028] It should be understood that the number and location of the various elements are not restrictive and may depend on the desired application. For example, various elements may not be required for a desired application or design specification (e.g., for the type of programmable device selected).

[0029] In addition, it should be understood that, for clarity, the elements are shown in block form and the various elements are typically distributed throughout the PLD 100, such as within and among the logic block 104, the hard IP block 160, and the routing resources (e.g., Figure 2 the routing resources 180) to perform their normal functions (e.g., storing configuration data for configuring the PLD 100 or providing an interconnect structure within the PLD 100). It should also be understood that, as will be understood by those skilled in the art, the various embodiments disclosed herein are not limited to programmable logic devices such as the PLD 100 and can be applied to various other types of programmable devices.

[0030] An external system 130 can be used to create a desired user configuration or design for the PLD 100 and generate corresponding configuration data to program (e.g., configure) the PLD 100. For example, the system 130 can provide such configuration data to one or more I / O blocks 102, SERDES blocks 150, and / or other parts of the PLD 100. Thus, the programmable logic blocks 104, various routing resources, and any other suitable components of the PLD 100 can be configured to operate according to a user-specified application.

[0031] In the illustrated embodiment, the system 130 is implemented as a computer system. In this regard, the system 130 includes, for example, one or more processors 132 that can be configured to execute instructions, such as software instructions, provided in one or more memories 134 and / or stored in a non-transitory form in one or more non-transitory machine-readable media 136 (e.g., which can be internal or external to the system 130). For example, in some embodiments, the system 130 can run PLD configuration software, such as the Lattice Diamond System Planner software available from Lattice Semiconductor Corporation, to allow a user to create a desired configuration and generate corresponding configuration data to program the PLD 100.

[0032] The system 130 also includes, for example, a user interface 135 (e.g., a screen or display) for presenting information to the user, and one or more user input devices 137 (e.g., a keyboard, mouse, trackball, touchscreen, and / or other devices) for receiving user commands or design entries to prepare a desired configuration of the PLD 100.

[0033] Figure 2 A block diagram of the logic block 104 of the PLD 100 according to an embodiment of the present disclosure is shown. As discussed, the PLD 100 includes a plurality of logic blocks 104 that include various components to provide logical and arithmetic functions. In Figure 2In the exemplary embodiment shown, the logic block 104 includes a plurality of logic units 200, and the plurality of logic units 200 can be internally interconnected within the logic block 104 and / or externally interconnected using the routing resources 180. For example, each logic unit 200 may include various components, such as: a look-up table (LUT) 202, pattern logic circuitry 204, a register 206 (e.g., a flip-flop or a latch), and various programmable multiplexers (e.g., programmable multiplexers 212 and 214) for selecting a desired signal path between the logic unit 200 and / or the logic units 200. In this example, the LUT 202 accepts four inputs 220A - 220D, making it a four-input LUT (which may be abbreviated as "4-LUT" or "LUT4"), and the four-input LUT can be programmed by the configuration data of the PLD 100 to implement any suitable logic operation having four or fewer inputs. The pattern logic 204 may include various logic elements and / or additional inputs, such as the input 220E, to support various modes of functionality, as described herein. In other examples, the LUT 202 may have any other suitable size and any other suitable number of inputs for a particular implementation of the PLD. In some embodiments, different-sized LUTs may be provided for different logic blocks 104 and / or different logic units 200.

[0034] In some embodiments, the output signal 222 from the LUT 202 and / or the pattern logic 204 may pass through the register 206 to provide the output signal 233 of the logic unit 200. In various embodiments, as shown, the output signal 223 from the LUT 202 and / or the pattern logic 204 may be directly passed to the output 223. Depending on the configuration of the multiplexers 210 - 214 and / or the pattern logic 204, the output signal 222 may be temporarily stored (e.g., latched) in the latch 206 according to the control signal 230. In some embodiments, the configuration data for the PLD 100 may configure the outputs 223 and / or 233 of the logic unit 200 to be provided as one or more inputs to another logic unit 200 (e.g., in another logic block or the same logic block) in a hierarchical or cascaded arrangement (e.g., including multiple levels) to configure logic operations that cannot be implemented in a single logic unit 200 (e.g., a logic operation having too many inputs to be implemented by a single LUT 202). Additionally, the logic unit 200 may be implemented with multiple outputs and / or interconnections to facilitate selectable operating modes, as described herein.

[0035] The mode logic circuit 204 can be used for some configurations of the PLD 100 to effectively implement arithmetic operations, such as adders, subtracters, comparators, counters, or other operations, to effectively form some extended logic operations (e.g., higher-order LUTs, working on multi-bit data), to effectively implement a relatively small RAM, and / or to allow selection between logic, arithmetic, extended logic, and / or other alternative operation modes. In this regard, the mode logic circuits 204 across multiple logic units 202 can be chained together to transfer carry signals 205 and carry output signals 207, and / or other signals (e.g., output signal 222) between adjacent logic units 202, as described herein. In Figure 2 the example of, the carry signal 205 can be directly transferred to the mode logic circuit 204, for example, or can be transferred to the mode logic circuit 204 by configuring one or more programmable multiplexers, as described herein. In some embodiments, the mode logic circuit 204 can be linked across multiple logic blocks 104.

[0036] Figure 2 The logic unit 200 shown in is only an example, and the logic unit 200 according to different embodiments can include different combinations and arrangements of PLD components. In addition, although Figure 2 the logic block 104 is shown with eight logic units 200, the logic block 104 according to other embodiments can include fewer logic units 200 or more logic units 200. Each logic unit 200 of the logic block 104 can be used to implement a part of the user design implemented by the PLD 100. In this regard, the PLD 100 can include many logic blocks 104, and each logic block 104 can include logic units 200 and / or other components for jointly implementing the user design.

[0037] As further described herein, when the PLD 100 is configured to implement a user design, parts of the user design can be adjusted to occupy fewer logic units 200, fewer logic blocks 104, and / or less burden on the routing resources 180. Such adjustment according to various embodiments can identify certain logic, arithmetic, and / or extended logic operations to be implemented in the arrangements of multiple embodiments that occupy logic units 200 and / or logic blocks 104. As further described herein, the optimization process can route various signal connections associated with the arithmetic / logic operations described herein, such that logic, ripple arithmetic, or extended logic operations can be implemented into one or more logic units 200 and / or logic blocks 104 in association with previous arithmetic / logic operations.

[0038] Figure 3 shows a design process 300 of a PLD according to an embodiment of the present disclosure. For example, Figure 3The process can be performed by system 130 running Lattice Diamond software to configure PLD 100. In some embodiments, Figure 3 The various files and information referenced in Figure 3 can be stored in one or more databases and / or other data structures such as, for example, memory 134, machine-readable medium 136, and / or other data structures. In various embodiments, such files and / or information can be encrypted or otherwise protected when stored and / or transmitted to PLD 100 and / or other devices or systems.

[0039] In operation 310, system 130 receives a user design that specifies the desired functionality of PLD 100. For example, a user can interact with system 130 (e.g., via user input device 137 and hardware description language (HDL) code representing the design) to identify various features of the user design (e.g., high-level logic operations, hardware configuration, and / or other features). In some embodiments, the user design can be provided in a register transfer level (RTL) description (e.g., gate-level description). System 130 can perform one or more rule checks to confirm that the user design describes a valid configuration of PLD 100. For example, system 130 can reject invalid configurations and / or request that the user provide appropriate new design information.

[0040] In operation 320, system 130 synthesizes the design to create a netlist (e.g., synthesizing the RTL description) that identifies the abstract logical implementation of the user design as a plurality of logic components (e.g., also referred to as netlist components), the plurality of logic components can include both programmable components and hard IP components of PLD 100. In some embodiments, the netlist can be stored in a local generic database (NGD) file in electronic design interchange format (EDIF).

[0041] In some embodiments, synthesizing the design into a netlist in operation 320 can involve converting (e.g., translating) a high-level description of the logical operations, hardware configuration, and / or other features in the user design into a set of PLD components (e.g., logic blocks 104, logic units 200, and other components of PLD 100 configured to implement the logic, arithmetic, or other hardware functions of the user design) and their associated interconnections or signals. Depending on the embodiment, the converted user design can be represented as a netlist.

[0042] In some embodiments, synthesizing the design into a netlist in operation 320 may further involve performing an optimization process on the user design (e.g., a user design that is transformed / translated into a set of PLD components and their associated interconnections or signals) to reduce propagation delay, consumption of PLD resources and routing resources, and / or optimize the performance of the PLD when configured to implement the user design. Depending on the embodiment, the optimization process may be performed on the netlist representing the transformed / translated user design. Depending on the embodiment, the optimization process may represent the optimized user design in the netlist (e.g., to produce an optimized netlist).

[0043] In some embodiments, the optimization process may include optimizing certain instances of logic function operations, ripple arithmetic operations, and / or extended logic function operations that, when the PLD is configured to implement the user design, will occupy multiple configurable PLD components (e.g., logic unit 200, logic block 104, and / or routing resource 180). For example, the optimization process may include detecting multiple patterns or configurable logic units that implement logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in the user design, swapping the operation modes of the logic units implementing the various operations to reduce the number of PLD components and / or routing resources used to implement the operations and / or reduce the propagation delay associated with the operations, and / or reprogramming the corresponding LUTs and / or mode logic to account for the swapped operation modes.

[0044] In another example, the optimization process may include detecting extended logic function operations and / or corresponding routing resources in the user design, implementing the extended logic operations as multi-mode or convertible logic units having a single physical logic unit output, routing or coupling the logic unit outputs of a first set of logic units to the inputs of a second set of logic units to reduce the number of PLD components used to implement the extended logic operations and / or routing resources and / or reduce the propagation delay associated with the extended logic operations, and / or programming the corresponding LUTs and / or mode logic to at least utilize the first set of logic units and the second set of logic units to implement the extended logic function operation.

[0045] In another example, the optimization process may include detecting multiple patterns or configurable logic units that implement logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in the user design, swapping the operation modes of the logic units implementing the various operations to provide programmable registers along the signal path within the PLD to reduce the propagation delay associated with the signal path, and reprogramming the corresponding LUTs, mode logic, and / or other logic unit control bits / registers to account for the swapped operation modes and / or programming the programmable registers to store or latch signals on the signal path.

[0046] In operation 330, system 130 performs a mapping process that identifies components of the PLD 100 that can be used to implement the user design. In this regard, system 130 can map an optimized netlist (e.g., stored in operation 320 as a result of an optimization process) to the various types of components provided by the PLD 100 (e.g., logic blocks 104, logic units 200, embedded hardware, and / or other portions of the PLD 100) and their associated signals (e.g., in a logical manner, but without yet specifying placement or routing). In some embodiments, the mapping can be performed on one or more previously stored NGD files, and the mapping result is stored as a physical design file (e.g., also referred to as an NCD file). In some embodiments, the mapping process can be performed as part of the synthesis process in operation 320 to produce a netlist that is mapped to the PLD components.

[0047] In operation 340, system 130 performs a placement process to assign the mapped netlist components to specific physical components (e.g., to specific logic units 200, logic blocks 104, routing resources 180, and / or other physical components) residing at specific physical locations of the PLD 100, and thus determines the layout of the PLD 100. In some embodiments, the placement can be performed on one or more previously stored NCD files, and the placement result is stored as another physical design file.

[0048] In operation 350, system 130 performs a routing process to route the connections between the components of the PLD 100 (e.g., using the routing resources 180) based on the placement layout determined in operation 340 to achieve physical interconnection between the placed components. In some embodiments, the routing can be performed on one or more previously stored NCD files, and the routing result is stored as another physical design file.

[0049] In various embodiments, routing the connections in operation 350 can further involve performing an optimization process on the user design to reduce propagation delay, consumption of PLD resources and / or routing resources, and / or optimize the performance of the PLD when configured to implement the user design. In some embodiments, the optimization process can be performed on a physical design file representing the transformed / translated user design, and the optimization process can represent the optimized user design in the physical design file (e.g., to produce an optimized physical design file).

[0050] In some embodiments, the optimization process may include optimizing certain instances of logic function operations, ripple arithmetic operations, and / or extended logic function operations, which, when the PLD is configured to implement a user design, will occupy multiple configurable PLD components (e.g., logic units 200, logic blocks 104, and / or routing resources 180). For example, the optimization process may include detecting multiple patterns or configurable logic units that implement logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in the user design, swapping the operation modes of the logic units that implement various operations to reduce the number of PLD components and / or routing resources used to implement the operations and / or reduce the propagation delay associated with the operations, and / or reprogramming the corresponding LUTs and / or mode logic to account for the swapped operation modes.

[0051] In another example, the optimization process may include detecting extended logic function operations and / or corresponding routing resources in the user design, implementing the extended logic operations as multi-mode or convertible logic units with a single physical logic unit output, routing or coupling the logic unit outputs of a first set of logic units to the inputs of a second set of logic units to reduce the number of PLD components used to implement the extended logic operations and / or routing resources and / or reduce the propagation delay associated with the extended logic operations, and / or programming the corresponding LUTs and / or mode logic to at least utilize the first set of logic units and the second set of logic units to implement the extended logic function operations.

[0052] In another example, the optimization process may include detecting multiple patterns or configurable logic units that implement logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in the user design, swapping the operation modes of the logic units that implement various operations to provide programmable registers along the signal path within the PLD to reduce the propagation delay associated with the signal path, and reprogramming the corresponding LUTs, mode logic, and / or other logic unit control bits / registers to account for the swapped operation modes and / or programming the programmable registers to store or latch signals on the signal path.

[0053] Changes in routing can propagate back to previous operations, such as synthesis, mapping, and / or placement, to further optimize various aspects of the user design.

[0054] Accordingly, after operation 350, one or more physical design files may be provided that specify the user design (e.g., by combining the results of the respective previous operations) after the user design has been synthesized (e.g., transformed and optimized), mapped, placed, and routed (e.g., further optimized) for the PLD 100. In operation 360, the system 130 generates configuration data for the synthesized, mapped, placed, and routed user design. In various embodiments, such configuration data may be encrypted and / or otherwise protected as part of such a generation process, as more fully described herein. In operation 370, the system 130 configures the PLD 100 with the configuration data bitstream (e.g., "configuration") by loading it into the PLD 100, e.g., via connection 140. For example, such a configuration may be provided in an encrypted, signed, or unprotected / unauthenticated form, and the PLD 100 may be configured to treat secure and unprotected configurations differently, as described herein.

[0055] Figure 4 FIG. shows a block diagram of a secure PLD 410 according to an embodiment of the present disclosure. In various embodiments, the secure PLD 410 may be implemented by elements similar to those described with respect to the PLD 100, but having additional configurable and / or hard IP elements that are configured to facilitate the operation of the secure PLD 410 in trusted computing applications and / or architectures, as described herein. In particular, the secure PLD 410 may include: a PLD fabric 400 linked to a security engine 420 via various buses; a configuration engine 440; a non-volatile memory (NVM) 450; programmable I / O 404 and / or other integrated circuit (IC) modules 480, as shown, all of which are implemented on a single monolithic IC. Generally, the PLD fabric 400 may be implemented by any of the various elements described with respect to the PLD 100, and the PLD fabric 400 may be configured using a design process similar to the process 300 described with respect to Figure 1 to generate and program the PLD fabric 400 according to a desired configuration. More specifically, the secure PLD 400 may be configured to receive, decrypt, authenticate, and / or verify the received configuration using the various identified hard IP elements before programming the PLD fabric 400 according to the received configuration. Figure 3 In operation 370, the system 130 configures the PLD 100 with the configuration data bitstream (e.g., "configuration") by loading it into the PLD 100, e.g., via connection 140. For example, such a configuration may be provided in an encrypted, signed, or unprotected / unauthenticated form, and the PLD 100 may be configured to treat secure and unprotected configurations differently, as described herein. Figure 4 to receive, decrypt, authenticate, and / or verify the received configuration using the various identified hard IP elements before programming the PLD fabric 400 according to the received configuration.

[0056] The security engine 420 may be implemented as a hard IP resource that is configured to provide various security functions for use by the PLD fabric 400 and / or the configuration engine 440. In Figure 4In the illustrated embodiment, the security engine 420 includes a device ID 422 (e.g., a 64-bit unique and device-specific ID), a true random number generator 424, a Secure Hash Algorithm (SHA) service 426 (e.g., SHA256, SHA-2, and / or SHA-3 services), an Advanced Encryption Standard (AES) service 428 (e.g., AES128 / 256 encryption / decryption services), a public key / private key pair generator (P / PKG) 430, an Elliptic Curve Digital Signature Algorithm (ECDSA) authentication service 432 (e.g., ECDSA256 service), and / or other security services 434. Also as Figure 4 illustrated, the security engine 420 can be communicatively linked to the PLD structure 400 via a limited bus 406 and to the configuration engine 440 via a security bus 446. Generally, the limited bus 406 can be configured to allow the PLD structure 400 to access a limited set of security functions hosted by the security engine 420 and / or access such security functions in a limited manner, e.g., not allowing configuration of any one or all of the security functions hosted by the security engine 420, not allowing access to the device ID 422, and / or not allowing access to the private key of the public key / private key pair generated by the P / PKG 430. In contrast, the security bus 446 can be configured to allow the configuration engine 440 to access and / or modify all security functions, data, and / or configurations of the security engine 420. Generally, either or both of the limited bus 406 and the security bus 446 can be configured to provide encrypted and / or otherwise secure communication between the security engine 420 and other elements of the security PLD 410.

[0057] The configuration engine 440 can be implemented as a hard IP resource configured to manage the configuration of the various elements of the security PLD 410 and / or communication between the various elements of the security PLD 410. For example, the configuration engine 440 can be configured to receive an encrypted / secure configuration of the PLD structure 400 from an external system 130 / machine-readable medium 136 via a configuration I / O 448, authenticate and / or decrypt such a configuration using the security functions of the security engine 420, store the authenticated and / or decrypted configuration in the NVM 450, soft or hard lock a portion of the NVM 450 corresponding to the stored configuration, mark the stored configuration as authenticated and / or verified bootable, and / or program the PLD structure 400 according to the authenticated, decrypted, verified, and / or locked configuration, as described herein. In a further embodiment, the configuration engine 440 can be configured to configure at least a portion of the programmable I / O 404 via a configuration port 444 (e.g., enable and / or disable at least a portion of the programmable I / O 404), as illustrated.

[0058] More generally, the configuration engine 440 can be configured to manage or control the configuration of the elements of the secure PLD 410, the lock states of the elements of the secure PLD 410, the boot of the PLD structure 400, and the flow control of the entire secure PLD 410. For example, the configuration engine 440 can be configured to, for example, soft-lock or unlock or hard-lock any one or part of buses 408, 442, 443, 446, and / or soft-lock or unlock or hard-lock any part or sector of the NVM 450. In a default unlocked configuration, buses 408, 442, and 446 can be implemented as secure buses that are functionally similar to the secure bus 446. The external access bus 443 of the configuration I / O 448 can be implemented according to one or more of JTAG, I2C, SPI, and / or other external access buses or protocols, for example, configured to provide lockable / unlockable access to / from the external system 130 / machine-readable medium 136. In a particular embodiment, the secure bus 408 can be implemented according to the wishbone bus / interface.

[0059] The NVM 450 can be implemented as a hard IP resource that is configured to provide secure non-volatile storage of data for facilitating the secure operation of the secure PLD 410. For example, the NVM 450 can include a lock policy 460 corresponding to memory locations in the NVM 460, and the lock policy 460 indicates the lock states of the data stored in the NVM 450. The content of the lock policy 460 can be transferred to a shadow register within the configuration engine 440 when the secure PLD 410 is powered on, for example, to allow such content to be dynamically modified by the configuration engine 440 and / or the PLD structure 400 according to the settings / lock states in the lock policy 460. Generally, with respect to the PLD structure 400, the configuration I / O 448 / external access bus 443, and / or other elements of the secure PLD 410, the lock state of a particular resource indicates read, write / program, and / or erase access to that resource.

[0060] As described herein, a "soft" lock refers to the read, write, and / or erase access status of a bus / port or memory location in the NVM 450, which can be programmatically enabled or disabled by the PLD structure 400 and / or across the external access bus 443 to granularly allow or disallow read, write, and / or erase access to the corresponding resources. A "hard" lock refers to the read, write, and / or erase access status of a bus / port or memory location in the NVM 450, which can be programmatically enabled via the external access bus 443, but cannot be enabled or disabled by the PLD structure 400 and cannot be disabled via the external access bus 443. In various embodiments, the assertion of a hard lock is typically unidirectional and eliminates the ability of the PLD structure 400 and / or the external access bus 443 to further modify the lock status of all secure resources within the secure PLD 410. In some embodiments, such a locking scheme can be implemented by four bits for each resource (e.g., a bus port or a memory sector within the NVM 450), each bit for hard lock enable, read lock enable, write lock enable, and erase lock enable.

[0061] As Figure 4As shown in the illustrated embodiments, the NVM 450 may include a plurality of distinguishable lockable sectors, each of which may have its own lock state. Such lockable sectors may include, for example, a first configuration image sector 452, a second configuration image sector 454, a manufacturer-specified trim sector 456, a device key sector 458 (e.g., an AES key sector and a separate public key / key pair sector), a lock policy sector 460, a user flash memory (UFM) sector 462, and / or one or more of other defined securely storable sectors 464, as shown. In some embodiments, the UFM sector 462 may be further divided into sub-sectors, each of which may have its own lock state. The lock policy sector 460 may store the lock state of each sector of the NVM 450, e.g., including its own lock state. For example, the first configuration image sector 452 and the second configuration image sector 454 may each store a configuration of the PLD structure 400 and may, for example, be further tagged by version and / or date and pre-certified to allow them to be selected (e.g., based on version or date) and used to program the PLD structure without performing an authentication process. The trim sector 456 may be used to store manufacturer trimming and / or other data specific to a particular secure PLD 410, e.g., as described herein, a modifiable client-specific ordered part number derived from the device ID 422 and a generated client ID number. The device key sector 458 may be used to store encryption / decryption keys, public key / private keys, and / or other security keys specific to a particular secure PLD 410. The lock policy sector 460 may be configured to store the lock state of resources of the NVM 450, the configuration engine 440, the configuration I / O 448, and / or other elements of the secure PLD 410. The UFM sector 462 may be used to store user data that may generally be accessed by the PLD structure 400, such as configuration or application-specific security keys, certificates, and / or other secure user data. The other securely storable sectors 464 may be used to store other device-specific secure data. Any one or more individual elements, parts, or sectors of the NVM 450 may be implemented as, for example, configurable memory or one-time programmable (OTP) memory, as described herein.

[0062] The programmable I / O 404 can be implemented as at least partially configurable resources that are configured to provide or support a communication link between the PLD structure 400 and an external controller, memory, and / or other devices, such as across a bus 402 (e.g., a bus configured to link portions of the PLD structure 400 to the programmable I / O 404). In some embodiments, the bus 402 and / or the programmable I / O 404 can be integrated with the PLD structure 400. The configuration I / O 448 can be implemented as a hard IP resource that is configured to support one or more external bus interfaces and / or protocols 449 to support communication with the external system 130 / machine-readable medium 136, as described herein. In some embodiments, the configuration I / O 448 and / or the bus 443 can be integrated with the configuration engine 440. More generally, in Figure 4 one or more elements shown as a separate security PLD 410 can be integrated with each other and / or integrated within each other. Other IC modules 480 can be implemented as hard and / or configurable IP resources that are configured to facilitate the operation of the security PLD 410.

[0063] Figure 5A A block diagram of a security PLD provisioning system 500 in accordance with an embodiment of the present disclosure is shown. For example, one or more elements of the provisioning system 500 can be configured to perform at least part of the provisioning process described with respect to Figure 7 In the embodiment shown in Figure 5A the security PLD provisioning system 500 includes a security PLD client 510 and a security PLD manufacturer 520 that are configured to communicate with each other via a communication link 512 and a communication network 514. Generally, the communication link 512 can be implemented by one or more wired and / or wireless communication links that are configured to support data communication to and from the communication network 514, and the communication network 514 can be implemented by one or more local area networks and / or wide area networks that are configured to generally support data communication (e.g., an Internet service provider, a cellular network, and / or the Internet). Each of the remaining elements of the security PLD provisioning system 500 represents an entity in, for example, the manufacturing and delivery chain of the security PLD 410 and can generally be implemented by a network communication device, each network communication device being similar in scope to Figure 1 the external system 130 and being configured to communicate across the communication link 512 and the communication network 514. In various embodiments, the security PLD provisioning system 500 can be configured to provision keys and / or other secure communication elements and / or mechanisms for a security PLD similar to the security PLD 410.

[0064] AsFigure 5A As shown, the secure PLD client 510 and the secure PLD manufacturer 520 can be considered trusted entities within the supply system 500, while all other components of the supply system 500 can be considered untrusted entities, such that the software and / or hardware of the client and / or manufacturer should generally be protected or otherwise safeguarded against unwanted access or manipulation by the downstream client 550 and / or the optional secure PLD programmer 530 and user device assembler 540. For example, in normal operation, the secure PLD client 510 requests one or more secure PLDs 410 from the secure PLD manufacturer 520 and generates a proprietary configuration to be programmed into the PLD structure 400 of the secure PLD 410. The secure PLD manufacturer 520 prepares the requested one or more secure PLDs 410 by manufacturing individual ICs and programming them with a security mechanism (e.g., locking them) to prohibit further programming with configurations not provided by the secure PLD client 510 and / or the secure PLD manufacturer 520. The secure PLD client 510 can provide a device-specific encrypted configuration to the optional secure PLD programmer 530, and the secure PLD manufacturer 520 can provide the locked secure PLDs 410 to the secure PLD programmer 530, such that the secure PLD programmer 530 can only program each locked secure PLD 410 with its device-specific encrypted configuration and such that the secure PLD programmer 530 cannot easily determine the unencrypted content of the device-specific encrypted configuration.

[0065] The secure PLD programmer 530 can deliver the programmed and locked secure PLDs 410 to the optional user device assembler 540 (e.g., a motherboard assembler, a smart phone assembler, and / or other user device / embedded device assembler / manufacturer), and the optional user device assembler 540 integrates the programmed and locked secure PLDs 410 with the user device and provides the integrated user device to the downstream client 550, all without the secure PLD programmer 530 and the downstream client 550 being able to determine the unencrypted content of the device-specific encrypted configuration or reprogram the locked secure PLDs with an alternative configuration. The secure PLD client 510 can then audit the programmed and locked secure PLDs 410 in the corresponding user devices at the downstream client 550 without revealing the unencrypted content of the device-specific encrypted configuration or unlocking the secure PLDs 410. Although shown as separate entities in Figure 5A , the secure PLD programmer 530 and the user device assembler can be combined and / or individually integrated with the secure PLD client 510, the secure PLD manufacturer 520, and / or the downstream client 550.

[0066] Figure 5BFIG. 0 shows a block diagram of a secure PLD supply system 502 according to an embodiment of the present disclosure. For example, one or more elements of the supply system 502 may be configured to perform at least part of the supply process described with respect to Figure 7 In one embodiment, the secure PLD supply system 502 may generally correspond to the secure PLD manufacturer 520 in Figure 5A More generally, systems similar to the elements of the secure PLD supply system 502 or including the elements of the secure PLD supply system 502 may be used to implement any one or more of the elements of the secure PLD supply system 500 shown in Figure 5A

[0067] In the embodiment shown in Figure 5B the secure PLD supply system 502 includes a secure PLD locking system 522 configured to lock and / or redirect a plurality of secure PLDs 410 (e.g., unlocked / blank secure PLDs 410 and / or previously locked secure PLDs 410 destined to be redirected to a different secure PLD client or request) sourced from a secure PLD inventory 524 in response to a request issued by a secure PLD client 510. Once locked by the secure PLD locking system 522, the locked secure PLD may be programmed with a configuration provided by the secure PLD client 510, e.g., programmed by the locking system 522 or more generally by a secure PLD programmer 530 as described herein. In various embodiments, the secure PLD locking system 522 may include a hardened security module (HSM) 526 configured to receive a client public key from the secure PLD client 510 via, e.g., a non-secure communication link 512 and control an external system 130 via a secure communication link 527 to lock secure PLDs 410 provided via a device delivery link 525 (e.g., a mechanical and / or electronic delivery link configured to retrieve secure PLDs 420 from a PLD inventory / storage area 524 and interface the configuration I / O 448 of the secure PLD 410 with the external system 130 via an external bus interface 449). The locked secure PLD 410 may then be physically delivered to the secure PLD programmer 530 via a similar device delivery link 528. For example, the HSM 526 may generally be implemented similar to the external system 130 but placed in a secure factory location with monitored and limited physical access to eliminate the risk of external manipulation and / or monitoring of the HSM 526. In some embodiments, the external system 130 and the HSM 526 and / or their functionality may be integrated into a single external system 130.

[0068] ​In general operation, the secure PLD client 510 may provide a request to the HSM 526 for multiple locked secure PLDs 410, the request including the client public key of a client public key / private key pair (e.g., generated within the secure PLD client 510, such as by its own HSM). The HSM 526 may generate a client-specific programming public key / private key pair (e.g., for encrypting, decrypting, and / or authenticating the configuration for the locked secure PLD 410, such as locking the secure PLD 410 and unlocking the secure PLD 410 for programming) and a programming secret (e.g., a 256-bit random number to further authenticate the provided configuration), and provide the programming private key, the programming secret, and the factory public key to the external system 130 for loading into a blank or unlocked secure PLD 410 and locking the blank or unlocked secure PLD 410. For example, the HSM 526 may be configured to locally generate a factory public key / private key pair and / or retrieve such factory keys from the memory 134, and such factory keys may be factory-specific and / or client-specific. The configuration engine 440 may receive a device-specific trace ID (e.g., which may identify the manufacturing lot, wafer, and wafer location corresponding to the manufacturing process of the secure PLD 410), the programming private key, the programming secret, the factory public key, and an initial programming image (IPI) configuration of the PLD structure 400, which may all be stored in one or more sectors of the NVM 450 to lock the secure PLD 410.

[0069] Then, the configuration engine 440 can store the trace ID in the MFG trim 456 of the NVM 450 and / or in the device ID 422 of the security engine 420, and generate a device-unique seed by appending a random number (e.g., generated by the TRNG 424) to the end of the trace ID, and such a device-unique seed can be stored in the MFG trim 456 and / or used for seed generation of the device public / private key pair (e.g., generated by the P / PKG 430 of the security engine 420), and the device public / private key pair can be stored in the device key sector 458 of the NVM 450. Then, the configuration engine 440 can provide the resulting device public key and the trace ID to the external system 130, and the external system 130 can relay the device public key and the trace ID to the HSM 526 to be added to the locked PLD manifest, which includes line items for each locked security PLD 410 requested by the secure PLD client 510, where each line item includes a device-specific trace ID and a device public key. Then, the HSM 526 can encrypt and sign the programming secrets using the client public key and the programming private key, and can provide the resulting encrypted programming packet to the secure PLD client 510 along with the programming public key (e.g., to assist in generating the encrypted and signed configuration of the PLD structure 400 of the secure PLD 410). Once the entries for all the locked security PLDs 410 requested by the secure PLD client 510 are complete, the HSM 526 can sign the locked PLD manifest using the programming private key and provide the signed locked PLD manifest to the secure PLD client 510, and the secure PLD client 510 can then use the locked PLD manifest, the programming secrets, and the programming public key to manage the programming of the locked security PLDs 410 by the secure PLD programmer 530, as described herein.

[0070] In some embodiments, the HSM 526 may be configured to generate a client programming key token corresponding to a particular secure PLD client 510 and / or a particular request received from the secure PLD client 510 for the locked secure PLD 410. Such a client programming key token can be used to reference (e.g., within a client database stored in the HSM 526) all information stored regarding the secure PLD client 510 and / or requests received from the secure PLD client 510 for the locked secure PLD 410. Such stored information may include programming public key / private key pairs, programming secrets, factory public key / private key pairs, a locked PLD manifest, and / or other information or subsets of information associated with the operation of the secure PLD provisioning system 502 and / or 500. In embodiments where the PLD inventory 524 includes one or more pre-locked secure PLDs 410 for redirection (e.g., locked to a different secure PLD client or different secure PLD request), the HSM 526 may be configured to use a previous client programming key token to retrieve information for locking the locked secure PLD, provide new information to the secure PLD 410 signed with the previous factory private key (e.g., via the external system 130), and provide a redirection command to the secure PLD 410 (e.g., to be executed by the secure PLD 410), where the redirection command is executed by the PLD fabric 400 and / or the configuration engine 440 to authenticate the new information with the previous factory public key stored in the NVM 450 and replace the previous information stored in the NVM 450 with the corresponding new or updated information (e.g., device public key / private key pair, programming private key, programming secret, factory public key, and / or IPI).

[0071] Figure 6FIG. shows a block diagram of a user equipment 610 including a security PLD 410 according to an embodiment of the present disclosure. In one embodiment, the security PLD 410 may be configured to provide a secure boot mechanism for the user equipment 610 (e.g., a motherboard, a smart phone, and / or other user / embedded devices). For example, when the user equipment 610 is powered on, the security PLD 410 may be configured to generate a temporary public key / private key pair using the P / PKG 430 of the security engine 420, and provide the temporary public key and the controller boot loader 662 (e.g., which may be pre-authenticated and / or stored in the UFM 462 of the NVM 450) to the controller 620 via the bus 604 (e.g., a bus supported by the programmable I / O 404). The execution engine 624 of the controller 620 may be configured to execute the controller boot loader 662 when receiving the controller boot loader 662 from the security PLD 410. The security PLD 410 may configure the execution engine 624 to generate a temporary session key (e.g., using the power-on RAM value derived from the power-on state of the volatile memory (VM) 612), encrypt the temporary session key using the temporary public key and the cryptographic salt provided by the security PLD 410, and provide the resulting first encrypted packet to the security PLD 410 via the bus 604.

[0072] The security PLD 410 may be configured to extract the temporary session key from the first encrypted packet provided by the controller 620 (e.g., using the temporary private key), encrypt the controller application image decryptor 663 using the session key, and provide the resulting second encrypted packet to the controller 620 via the bus 604. The execution engine 624 of the controller 620 may be configured to extract the controller application image decryptor 663 from the second encrypted packet when receiving the second encrypted packet from the security PLD 410. The security PLD 410 may configure the execution engine 624 to retrieve, authenticate, and decrypt the controller application image 632 stored in the NVM 630 (e.g., via the buses 602 and 604), store the authenticated and decrypted controller application image 632 in the VM 622, and execute the authenticated and decrypted controller application image 632. In addition, the security PLD 410 and the controller 620 may be configured to register a secure communication path with each other.

[0073] In another embodiment, the secure PLD 410 can be configured to use the controller 620 to verify the configuration of the PLD structure 400 for programming the secure PLD 410. For example, the secure PLD 410 can be configured to use the P / PKG 430 of the security engine 420 to generate a temporary public key / private key pair and provide the temporary public key to the controller 620. The execution engine 624 of the controller 620 can be configured to generate a temporary session key, encrypt the temporary session key using the temporary public key and a password salt provided by the secure PLD 410, and provide the resulting third encrypted packet to the secure PLD 410 via the bus 604. The controller 620 can also be configured to use the session key to encrypt a request to extract identification data from one or more configuration images stored, for example, in the NVM 450 of the secure PLD 410, and send the resulting fourth encrypted packet to the secure PLD 410 via the bus 604.

[0074] The secure PLD 410 can be configured to extract the temporary session key from the third encrypted packet provided by the controller 620, use the temporary session key to extract the request from the fourth encrypted packet to extract the requested identification data from one or more configuration images stored in the NVM 450 of the secure PLD 410, encrypt the requested identification data using the temporary session key, and provide the resulting fifth encrypted packet to the controller 620 via the bus 604. Once received, the controller 620 can be configured to verify the version, release date, and / or other characteristics of one or more configuration images stored in the NVM 450 by comparing them with a database of versions, release dates, and / or other characteristics of one or more configuration images stored in the NVM 450 that reside in the user device 610 (e.g., in the NVM 630 or the VM 622) and / or are accessible via the network (e.g., the communication network 514, accessible via other user device modules 680, which can include network interface devices) or retrieved from the network. In a further alternative embodiment, the secure PLD 410 can replace the controller 620 and be used to control the operation of the user device 600.

[0075] Figure 7 A provisioning process for a locked secure PLD according to an embodiment of the present disclosure is shown. In some embodiments, Figure 7 The operations can be implemented as software instructions that are executed by one or more logic devices associated with the Figures 1 to 6 corresponding electronic devices, modules, and / or structures shown. More generally, Figure 7The operations can be implemented using any combination of software instructions and / or electronic hardware (e.g., inductors, capacitors, amplifiers, actuators, or other analog and / or digital components). It should be understood that any step, sub-step, sub-process, or block of process 700 can be performed in a different order or arrangement than that of the Figure 7 illustrated embodiment. For example, in other embodiments, one or more blocks can be omitted from process 700, and other blocks can be included. Additionally, block inputs, block outputs, various sensor signals, sensor information, calibration parameters, and / or other operating parameters can be stored in one or more memories before moving to subsequent portions of process 700. Although process 700 is described with reference to the Figures 1 to 7 systems, devices, and elements, process 700 can be performed by other systems, devices, and elements and includes different selections of electronic systems, devices, elements, components, and / or arrangements. At the start of process 700, for example, various system parameters can be populated by a previous execution of a process similar to process 700, or can be initialized to zero and / or one or more values corresponding to typical, stored, and / or learned values derived from past operations of process 700, as described herein.

[0076] In block 710, the logic device receives a request to lock the PLD. For example, a network communication device of the secure PLD manufacturer 520 (e.g., external system 130, HSM 526) can be configured to receive a request for the locked secure PLD 410 from a network communication device of the secure PLD client 510 (e.g., external system 130, HSM 526). For example, such a request can be sent via communication link 512 and / or via communication network 514 and can include the client public key of the corresponding client public key / private key pair, as well as the number of the requested device and any specific model or other identification information associated with the particular desired secure PLD 410.

[0077] In block 720, a logic device generates a locked PLD. For example, a secure PLD manufacturer 520 may be configured to generate a locked secure PLD 410. In some embodiments, the secure PLD manufacturer 520 may use an IC manufacturing system to manufacture the secure PLD 410, which may include, for example, programming or storing or otherwise embedding a device ID 422 in the secure engine 420 and / or MFG trim 456 of the NVM 450. The secure PLD manufacturer 520 may also use an external system 130 to lock the secure PLD 410, as described herein. In one embodiment, the secure PLD locking system 522 of the secure PLD manufacturer 520 may be configured to assign a client ID to the secure PLD client 510 and / or the request received in block 710, and then this client ID may be combined with the device ID 422 and / or the device order part number (e.g., generated at the time of manufacture) to provide a client-specific order part number, which may be used, for example, to reference or identify the secure PLD 410 in an unencrypted database stored in the HSM 526.

[0078] The HSM 526 may also be configured to generate a client programming key token corresponding to the client public key in the secure PLD client 510 and / or the request received in block 710 by generating a corresponding random and unique client programming key token and / or client-specific order part number and referring to all stored information related to the locked secure PLD that generates such a token or number. The HSM 526 may also be configured to generate a programming public key / private key pair and a programming secret, all of which are specific to the secure PLD client 510 and / or the request received in block 710, all of which may be stored in the HSM 526. The HSM 526 may also be configured to generate a factory public key / private key pair, which may be specific to the secure PLD manufacturer 520, the secure PLD client 510, and / or the request received in block 710, and which may also be stored in the HSM 526.

[0079] For example, the HSM 526 can be configured to provide a factory public key, a programming private key, and a programming secret to an external system 130 for programming / locking the secure PLD 410 and, in response, receive a device-specific trace ID and a device public key. The HSM 526 can also be configured to encrypt and sign the programming secret using the client public key and the programming private key, and the resulting encrypted programming packet can be provided to the secure PLD client 510 along with the programming public key (e.g., to assist the secure PLD client 510 in generating an encrypted and signed configuration of the PLD structure 400 for the secure PLD 410). The secure PLD 410 can be configured to use the TRNG 424 of the security engine 420 to generate a device-unique seed based on the trace ID stored in the MFG trim 456 and / or the device ID 422, and use the device-unique seed and / or the P / PKG 430 of the security engine 420 to generate a device public key / private key pair, all specific to the secure PLD 410, and all of which can be stored in the NVM 450 (e.g., together with the programming private key, the programming secret, the factory public key, and / or the IPI configuration provided by the external system 130 and / or the HSM 526).

[0080] In another embodiment, the HSM 526 can be configured to retrieve the programming private key, the programming secret, and the device public key from a securely stored database using the client programming key token and provide them to the external system 130. The external system 130 can then be configured to use the programming private key, the programming secret, and / or the device public key to provide an IPI configuration to the secure PLD 410 and program the PLD structure 400 with the IPI. This programming may constitute an insecure write operation and may therefore require a secure environment (e.g., occurring entirely within the secure PLD manufacturer 520). In a further embodiment, the HSM 526 can be configured to receive from the external system 130 a locked PLD inventory entry including a trace ID corresponding to the secure PLD 410 and the corresponding device public key, generate a complete locked PLD inventory corresponding to the request received in block 710, sign the locked PLD inventory with the programming private key, and provide the signed locked PLD inventory to the secure PLD client 510.

[0081] In another embodiment, it may be useful to redirect a programmed and locked secure PLD to a different client or application (e.g., with different programming key pairs, programming secrets, and public device keys). Generally, it is not necessary to reprogram a programmed IPI (e.g., the same IPI configuration of the PLD structure 400 may be used). For example, the HSM 526 may be configured to use a client programming key token and / or a tracking ID to retrieve previous information used to lock the secure PLD 410 (e.g., the original programmed private key, programming secret, and device public key stored in the HSM 526). Then, the HSM 526 may be configured to use an external system 130 to provide new information to the secure PLD 410 signed with the previous factory private key, and provide a redirect command to the secure PLD 410 (e.g., to be executed by the secure PLD 410), where the redirect command may be executed by the PLD structure 400 and / or the configuration engine 440 to authenticate the new information with the previous factory public key stored in the NVM 450, and replace the previous information stored in the NVM 450 (e.g., device public key / private key pair, programmed private key, programming secret, factory public key, and / or IPI) with the corresponding new or updated or redirected information, as described herein.

[0082] In block 730, the logic device provides a secure unlock package for locking the PLD. For example, the HSM 526 of the secure PLD manufacturer 520 may be configured to provide a secure unlock package for the locked secure PLD 410 generated in block 720 to the secure PLD client 510. In one embodiment, the HSM 526 may be configured to provide an encrypted programming packet, a programming public key, and / or a client programming key token generated in block 720 to the secure PLD client 510. The secure PLD client 510 may use such information to generate a protected configuration of the secure PLD 410 as locked in block 720.

[0083] In block 740, the logic device provides an authenticated inventory identifying the locked PLD. For example, the secure PLD manufacturer 520 may be configured to provide an authenticated locked PLD inventory identifying the locked secure PLD 410 generated in block 720. In one embodiment, the HSM 526 may be configured to generate an inventory of tracking IDs and device public keys (e.g., an inventory of device public keys referenced by the tracking IDs) to sign the locked PLD inventory using the programmed private key generated in block 720, and provide the signed locked PLD inventory to the secure PLD client 510. The secure PLD client 510 may use such information to audit the selection of the deployed and / or locked secure PLD 410.

[0084] In block 750, the logic device generates a protected configuration of the locked PLD. For example, the external system 130 of the secure PLD client 510 can be configured to generate a protected configuration for the locked secure PLD 410 generated in block 720. In one embodiment, the external system 130 can be configured to use a process similar to process 300 discussed with reference to Figure 3 to generate an unprotected configuration of the PLD structure 400 of the secure PLD 410. Such a configuration can include, for example, an application bitstream / configuration to be primarily loaded into the PLD structure 400 and configure the PLD structure 400, and a feature bitstream / configuration to be primarily loaded into the locked policy sector 460, the UFM sector 462, and / or other defined securely storable sectors 464 and configure the lock policy sector 460, the UFM sector 462, and / or other defined securely storable sectors 464. Such a feature bitstream / configuration can include security keys, functions, and / or other features that can be executed by the configuration engine 440 and / or otherwise used to implement any of the processes described herein.

[0085] In various embodiments, the external system 130 and / or the HSM 526 of the secure PLD client 510 can be configured to generate an application public key / private key pair, an application encryption key (e.g., an AES encryption key), and a programming packet public key / private key pair. The external system 130 can be configured to sign the application and feature configurations using the application private key and encrypt the signed application and feature configurations using the application encryption key. The external system 130 can also be configured to generate a programming key digest by signing a combination / list of the application public key, the application program encryption key, and the programming secret (e.g., extracted from the encrypted programming packet of the secure unlock package provided in block 730) with the application private key, derive an encryption key based on the programming public key and the programming packet private key (e.g., using the elliptic curve Diffie-Hellman key derivation function), encrypt the signed combination of keys using the derived encryption key, and combine the encrypted and signed combination of keys with the programming packet public key (e.g., append the programming packet public key to the encrypted and signed combination of keys) to create a programming key digest. The external system 130 can also be configured to sign the locked PLD manifest (e.g., received in block 740) with the packet private key for authenticated delivery to the downstream secure PLD programmer 530, the user device assembler 540, and / or the downstream client 550. The external system 130 can be configured to generate a protected configuration for the secure PLD 410 by combining the encrypted application and feature configurations with the programming key digest to create a single protected information packet.

[0086] In block 760, the logic device provides the locked PLD to the configuration programmer. For example, the secure PLD manufacturer 520 may be configured to provide the locked secure PLD 410 generated in block 720 to the secure PLD programmer 530, as described herein.

[0087] In block 770, the logic device programs the locked PLD according to the protected configuration. For example, the external device 130 of the secure PLD programmer 530 may be configured to program the locked secure PLD 410 generated in block 720 according to the protected configuration generated in block 750 and provided by the secure PLD client 510. In one embodiment, the external system 130 of the secure PLD programmer 530 may be configured to provide the protected configuration / packet generated in block 750 to the secure PLD 410, and the secure PLD 410 may be configured to boot according to the IPI provided to the secure PLD 410 in block 720. Then, the secure PLD 410 may verify the protected configuration and program elements of the secure PLD 410, including parts of the PLD structure 400 and the NVM 450, through one or more buses of the secure PLD 410. More specifically, the secure PLD 410 may be configured to decrypt the encryption key in the programming key digest using the programming private key stored in the NVM 450 in block 720 and the packet public key generated in block 750. In block 720, the secure PLD 410 may also be configured to authenticate the decrypted key digest with the application public key and verify that the programming secret in the programming key digest matches the programming secret stored in the NVM 450. If both checks pass, the secure PLD 410 may store the application public key and application encryption key from the key digest in the NVM 450.

[0088] Once the application public key and application encryption key from the key digest are stored in the NVM 450, the secure PLD 410 may then decrypt the application and feature configurations and authenticate the decrypted application and feature configurations. For example, the application and feature configurations can be programmed into the secure PLD 410 only if the bitstream is successfully decrypted and authenticated using the application encryption key and application public key. In the case where the application configuration is successfully authenticated, the secure PLD 410 may be configured to program / store the application configuration into one of the configuration image sectors 452 or 454, set the pre-authentication bit for the appropriate image, erase the IPI from the PLD structure 400, and / or program the PLD structure 400 according to the stored application configuration. The feature configuration may be programmed into one or more parts of the NVM 450. Other security checks to be performed before programming the secure PLD 410 may include verifying the locked PLD manifest, checking for a match of the trace ID within the locked PLD manifest, and / or other security checks, as described herein.

[0089] In block 780, the logic device assembles a user device that includes a locked and programmed PLD. For example, the pick-and-place system of the user device assembler 540 can be configured to assemble a user device 610 that includes a locked secure PLD 410 generated in block 720 and programmed in block 770.

[0090] In block 790, the logic device audits the locked and programmed PLD based on an attestable inventory. For example, the secure PLD client 510 can be configured to audit the locked secure PLD generated in block 720 and programmed in block 770 based on the attestable inventory of locked PLDs provided in block 740. In one embodiment, an external system 130 of the secure PLD client 510 or the downstream client 550 can be configured to authenticate the inventory of locked PLDs provided by the secure PLD manufacturer 520 or the secure PLD client 510 in block 740, query the secure PLD 410 for its trace ID and / or device public key, compare the trace ID and device public key with those in the inventory of locked PLDs, and challenge the secure PLD 410 using the device public key, e.g., by encrypting a random number using the device public key, providing the resulting encrypted packet to the secure PLD 410 in a device key challenge, and comparing the returned result with the original random number (e.g., a matching result indicates a successful audit of the operational secure PLD 410). In some embodiments, such an audit can occur before erasing the IPI configuration in block 770. A successful audit indicates a functionally locked secure PLD 410.

[0091] Thus, by employing the systems and methods described herein, embodiments of the present disclosure are capable of providing flexible and secure key provisioning and configuration of secure PLDs across client orders of secure PLDs. A protected configuration of one client cannot be used to program a personalized secure PLD or a blank secure PLD of another client. The protected configuration can be programmed within the system or using an external device. Application keys can only be decrypted within the secure PLD. A client can use a key inventory to prevent device and / or application spoofing or overbuilding. In various embodiments, the programming keys and inventory are managed by the secure engine 420 of the secure PLD 410.

[0092] Figure 8 A fault characterization process 800 for a locked secure PLD 410 according to an embodiment of the present disclosure is shown. In some embodiments, Figure 8 operations can be implemented as software instructions executed by one or more logic devices associated with the corresponding electronic devices, modules, and / or structures described in Figures 1 to 6 More generally, Figure 8The operations can be implemented with any combination of software instructions and / or electronic hardware (e.g., inductors, capacitors, amplifiers, actuators, or other analog and / or digital components). It should be understood that any step, sub-step, sub-process, or block of process 800 can be performed in a different order or arrangement than that of the Figure 8 illustrated embodiment. For example, in other embodiments, one or more blocks can be omitted from process 800, and other blocks can be included. Additionally, prior to moving to a subsequent portion of process 800, the block inputs, block outputs, various sensor signals, sensor information, calibration parameters, and / or other operating parameters can be stored in one or more memories. Although process 800 is described with reference to the Figures 1 to 6 systems, devices, and elements, process 800 can be performed by other systems, devices, and elements, including different selections of electronic systems, devices, elements, components, and / or arrangements. At the start of process 800, for example, various system parameters can be populated by a prior execution of a process similar to process 800, or can be initialized to zero and / or initialized to one or more values such as: the one or more values corresponding to typical, stored, and / or learned values derived from past operations of process 800, as described herein.

[0093] In block 810, the logic device receives a fault characterization command. For example, the configuration engine 440 of the locked and / or programmed secure PLD 410 can be configured to receive a fault characterization (FC) command, which can be issued, for example, by an external system 130 coupled to the secure PLD client 510 or the secure PLD manufacturer 520 of the secure PLD 410 through the configuration I / O 448, or the fault characterization (FC) command is issued by the PLD fabric 400 running the client configuration programmed into the secure PLD 410 (e.g., using a similar method as described with respect to Figure 7issued in accordance with the process described in process 700. In some embodiments, the secure PLD client 510 may issue such an FC command (e.g., or provide such a command to another element of the secure PLD supply system 500 or 502 to issue on its behalf) after detecting a fault in the operation of the secure PLD 410, such as when preparing to send the secure PLD 410 to the secure PLD manufacturer 520 for fault characterization. In other embodiments, such fault characterization may occur within any element of the secure PLD supply system 500 or 502 and / or when the secure PLD 410 is integrated with the user device 610. In various embodiments, such an FC command may be signed, encrypted, and / or include additional information to enable the secure PLD 410 to authenticate the FC command. In a particular embodiment, such an FC command may include the trace ID of the specific secure PLD 410 being characterized (e.g., extracted from the list of locked PLDs provided by the secure PLD manufacturer 520), and the external system 130 and / or HSM 526 of the secure PLD client 510 may be configured to sign such an FC command using its application private key, as described herein.

[0094] In block 820, the logic device authenticates the FC command. For example, the configuration engine 440 and / or the PLD structure 400 of the locked and / or programmed secure PLD 410 may be configured to authenticate the FC command received in block 810. In one embodiment, the secure PLD 410 may be configured to authenticate an FC command signed by an application private key using the application public key stored in the NVM 450 during the locking, programming, or other provisioning steps in the provisioning process, as described herein. In another embodiment, the secure PLD 410 may be configured to authenticate such an FC command by comparing the FC trace ID in the FC command with the trace ID stored in the MFG trim sector 456 and / or other sectors of the NVM 450 or with the device ID 422 of the security engine 420, such that a matching trace ID in the FC command indicates an authenticated FC command. In a further embodiment, such an authentication process may include decrypting the FC command using the public key stored in the NVM 450, as described herein.

[0095] In block 830, the logic device executes the FC command. For example, the configuration engine 440 and / or the PLD fabric 400 of the locked and / or programmed secure PLD 410 can be configured to execute the FC command authenticated in block 820. In embodiments where the NVM 450 includes rewritable and / or unlocked memory sectors, such FC execution may include erasing one or more sectors of the NVM 450, such as one or more of the image sectors 452 and 454, the UFM 462, the lock policy sector 460, the device key 458, and / or other securely storable sectors 464. In embodiments where the NVM 450 includes OTP memory sectors, such FC execution may include invalidating one or more sectors of the NVM 450, such as one or more of the image sectors 452 and 454, the UFM sector 462, the lock policy sector 460, the device key 458, and / or other securely storable sectors 464. Such invalidation of a sector may include setting all bits within the sector to "1" to indicate the invalidated state of the sector. Generally, the MFG trim sector 456 may remain intact and not be erased or invalidated by executing such FC commands.

[0096] In various embodiments, such erasure and / or invalidation of sectors of the NVM 450 may include first erasing and / or invalidating less critical assets / sectors and then more critical assets / sectors. For example, one such prioritized erasure / invalidation order may include the UFM sector 462, the image sectors 452 and 454, other securely storable sectors 464 (e.g., including stored feature bitstreams / configurations including security functions and / or other features), the device key sector 458, and the lock policy sector 460. Such a prioritization order may be designed to ensure secure erasure / invalidation of specific client data and / or data types before potentially unlocking access to the specific client data and / or data types by erasing / invalidating the lock policy sector 460 and resetting all lock states to the unlocked state (e.g., such that all assets / sectors / ports are accessible by the PLD fabric 400 and / or via the configuration I / O 448). In other embodiments, in addition to the MFG trim sector 456, one or more sectors of the NVM 450 may remain intact and not be erased or invalidated, such as sectors such as the UFM sector 462 and / or other securely storable sectors 464, in order to retain various security functions or features (e.g., decryption, authentication, and / or other security functions or features) in the NVM 450 for use, for example, in performing a debug process or re-initializing the debugged secure PLD 410.

[0097] In block 840, the logic device performs a debug process. For example, the configuration engine 440 and / or the PLD fabric 400 of the secure PLD 410 that has been erased and / or invalidated by executing an authenticated FC command in block 830 can be configured to: perform a debug process, including receiving a debug configuration (e.g., for execution by the PLD fabric 400) and / or generating a resulting debug summary to help explicitly characterize a failure of the secure PLD 410, as more fully described with respect to the failure characterization / debug process 840 of Figure 9 In some embodiments, such a debug process may include iteratively updating the MFG trim 456, possibly, to mitigate or eliminate the cause of the failure characterized and / or otherwise identified in the generated debug summary. In further embodiments, such a debug process may include additional authentication processes to help eliminate the risk that the erased / invalidated secure PLD is provided and / or used with third-party configurations and / or other data that may be used to compromise or invalidate the operation of the user equipment (e.g., user equipment 610). In various embodiments, such a debug process can be configured to verify that one or more sectors of the NVM 450 are erased and / or invalidated before allowing the debug process to proceed further.

[0098] Generally, block 830 and block 840 can be performed entirely by, or within, the secure PLD client 510, the secure PLD manufacturer 510, and / or other elements of the secure PLD supply system 500 and / or 502. In a particular embodiment, block 830 can be performed by the secure PLD client 510 to ensure that client data is erased before delivery to the secure PLD manufacturer 510 for debugging according to block 840. More generally, block 830 can be performed by the secure PLD client 510, the secure PLD programmer 530, the user equipment assembler, and / or the downstream client 550 before the secure PLD 410 and / or the user equipment 610 are delivered to the secure PLD manufacturer 520 for debugging according to block 840.

[0099] In the optional box 850, the logic device re-supplies the secure PLD. For example, in an embodiment where the NVM 450 includes rewritable and / or unlocked memory sectors that are erased by the execution of the FC command in box 830, the configuration engine 440 of the debugged secure PLD 410 in box 840 can be configured to: receive updated MFG trim, trace ID, device key, IPI, and / or other data (e.g., issued / generated by an external system 130 and / or HSM 526 coupled to the secure PLD client 510 or secure PLD manufacturer 520 of the secure PLD 410 via the configuration I / O 448), and be configured to: use a process similar to Figure 7 the supply process 700 to re-supply the secure PLD 410 and / or place the secure PLD 410 in a state to be re-supplied, thereby allowing the debugged secure PLD 410 to be placed back in service. In an embodiment where: the debug process of box 840 includes an additional authentication process before allowing a debug configuration or any other configuration to be loaded into the PLD structure 400 and bootstrapped by the PLD structure 400, as described herein, such a re-supply process may include: authenticating the updated MFG trim, trace ID, device key, IPI, and / or other data before storing them within the NVM 450. In an embodiment where the NVM 450 includes OTP memory sectors that are invalidated by the execution of the FC command in box 830, the corresponding secure PLD 410 typically cannot be re-supplied.

[0100] Thus, by adopting the systems and methods described herein, embodiments of the present disclosure are capable of providing flexible and secure fault characterization of secure PLDs across client orders of secure PLDs. Secure PLDs that are client-locked and / or otherwise exhibit faults can be securely erased and provided back to the manufacturer for fault characterization and / or repair (e.g., re-calibration) to assist the client in identifying the fault modes of the secure PLD and / or the integrated user device without risking exposure of client data. Additionally, in cases where the fault mode is traced back to a misconfiguration of the secure PLD, e.g., due to an error in the configuration provided by the client rather than a physical fault of the secure PLD, the secure PLD can be re-supplied based on, e.g., updated client data or based on a new client application, without requiring the secure PLD to be isolated or otherwise disrupted by the fault characterization process.

[0101] Figure 9 A fault characterization process 840 for a locked secure PLD 410 according to an embodiment of the present disclosure is shown. In various embodiments, Figure 9 the fault characterization process 840 may generally correspond to Figure 8 box 840 of the fault characterization process 800 in

[0102] In some embodiments, Figure 9 the operations of Figures 1 to 6 may be implemented as software instructions executed by one or more logic devices associated with the corresponding electronic devices, modules, and / or structures described in Figure 9 . More generally, the operations of Figure 9 may be implemented with any combination of software instructions and / or electronic hardware (e.g., inductors, capacitors, amplifiers, actuators, or other analog and / or digital components). It should be understood that any step, sub-step, sub-process, or block of process 900 may be performed in a different order or arrangement than that of the Figures 1 to 6 illustrated embodiments. For example, in other embodiments, one or more blocks may be omitted from process 900, and other blocks may be included. Additionally, prior to moving to a subsequent portion of process 900, the block inputs, block outputs, various sensor signals, sensor information, calibration parameters, and / or other operating parameters may be stored in one or more memories. Although process 900 is described with reference to the Figures 1 to 6 systems, devices, and elements, process 900 may be performed by other systems, devices, and elements and includes different selections of electronic systems, devices, elements, components, and / or arrangements. At the start of process 900, for example, various system parameters may be populated by a prior execution of a process similar to process 900, or may be initialized to zero and / or initialized to one or more values such as those corresponding to typical, stored, and / or learned values derived from past operations of process 900, as described herein.

[0103] In block 910, the logic device receives a debug configuration. For example, in Figure 8 block 830 of

[0104] For example, in some embodiments, such a debug configuration may be configured to cause the PLD structure 400 to implement a signal or data generator that is configured to operate at one or more selected clock speeds of the PLD structure 400 and provide one or more known signals or data to elements of the secure PLD 410 to elicit corresponding expected responses; provide such signals or data to elements of the secure PLD 410 and monitor the corresponding actual responses; and compare the actual responses with the expected responses to generate a debug summary that identifies one or more failing comparisons and / or characteristics of such comparisons. More generally, such a debug configuration may be configured to identify and / or characterize faults in the operation of any one element or combination of elements of the secure PLD 410, and such a debug configuration may be performed in combination with an external debug application (e.g., performed by an external system 130 coupled to the secure PLD 410 via the configuration I / O 448), the external debug application being configured to assist in generating a debug summary that identifies and / or characterizes such faults in the operation of the secure PLD 410. In various embodiments, the debug configuration may be signed (e.g., by a factory private key stored in the HSM 526) prior to being provided to the secure PLD 410, for example, and / or the debug configuration may include a trace ID corresponding to the particular secure PLD 410 to be debugged.

[0105] In optional block 920, the logic device authenticates the debug configuration. For example, the configuration engine 440 of the secure PLD 410 and / or the PLD structure 400 may be configured to authenticate the debug configuration of the PLD structure 400 and / or the secure PLD 410 received in block 910. In some embodiments, the secure PLD 410 may be configured to retrieve security functions or features and / or one or more keys (e.g., residing in sectors not erased or invalidated by an executed FC command) from the NVM 450 and use such security functions, features, and / or keys to authenticate the debug configuration received in block 910. In embodiments where the debug configuration is signed by a factory private key of the secure PLD manufacturer 520, the secure PLD 410 may be configured to use a factory public key residing in the un-erased / un-invalidated portion of the NVM 450 (e.g., in the MFG trim sector 456) to authenticate the signed debug configuration. In embodiments where the debug configuration includes a trace ID, the secure PLD 410 may be configured to compare the trace ID in the debug configuration with the trace ID stored in the NVM 450 and / or the security engine 420. The secure PLD 410 may be configured to only allow booting of the received debug configuration, or any configuration received after execution of an authenticated FC command (e.g., in Figure 8in the frame 830), if the debug configuration is signed and authenticated and / or if the trace ID in the debug configuration matches the trace ID stored in the NVM 450 and / or the security engine 420. In various embodiments, the erased / invalidated secure PLD 410 may be configured to: after each power loss, check the authentication of the received and / or stored debug configuration.

[0106] In a separate embodiment, the configuration engine 440 of the secure PLD 410 and / or the PLD structure 400 may be configured to: authenticate the coupled external system 130 through the configuration I / O 448 before allowing the external system 130 to provide debugging or any other configuration through the configuration I / O 448. For example, the configuration engine 440 of the secure PLD 410 and / or the PLD structure 400 may be configured to: receive an authentication message in the frame 910 separately from and before receiving the debug configuration, where the authentication message includes a trace ID, and / or other information signed by a factory key corresponding to the secure PLD manufacturer 520, and / or other information encrypted using the device public key corresponding to the secure PLD 410 (e.g., having the corresponding device private key stored in the NVM 450). The secure PLD 450 may be configured to authenticate the authentication message using the factory public key, the trace ID, and / or the device private key, as described herein, and then allow the external system 130 to provide the debug configuration through the configuration I / O 448. Such a debug configuration itself may include a trace ID, be signed and / or encrypted for further authentication, as described herein.

[0107] In the frame 930, the logic device boots the debug configuration. For example, the configuration engine 440 of the secure PLD 410 and / or the PLD structure 400 may be configured to: load, boot, and / or execute the debug configuration of the PLD structure 400 and / or the secure PLD 410 received in the frame 910 and / or authenticated in the optional frame 920. In various embodiments, such booting may occur when the debug configuration is received in the frame 910 and / or when the received debug configuration is optionally authenticated as described with respect to the optional frame 920. Such booting may include signaling to the external system 130 to notify of the booting of the received debug configuration in order to initiate complementary execution of a debug application by the external system 130, as described herein.

[0108] Within block 940, the logic device generates a debug summary. For example, the configuration engine 440 and / or the PLD fabric 400 of the secure PLD 410 can be configured to generate a debug summary based on the execution of the debug configuration of the PLD fabric 400 and / or the secure PLD 410 booted in block 930. In some embodiments, such a debug summary can include a list of faults of the secure PLD 410 and / or elements of the secure PLD 410, a characterization of such faults, and / or other debug information associated with the execution of the debug configuration received in block 910. In some embodiments, the secure PLD 410 can be configured to generate such a debug summary and provide it to the external system 130 via the configuration I / O 448. For example, where the debug summary includes debug information determined by the secure PLD 410. In other embodiments, the secure PLD 410 can be configured to provide fault information to the external system 130, and the external system 130 can be configured to monitor the operation of the secure PLD 410 (e.g., via the configuration I / O 448 and / or the programmable I / O 404) and generate the debug summary at least partially external to the secure PLD 410.

[0109] In various embodiments, the secure PLD 410 and / or the external system 130 can be configured to determine updated MFG trims based on the debug summary, which is configured to mitigate or eliminate the faults identified and / or characterized in the debug summary. Such updated MFG trims can be stored in the NVM 450 and / or overwrite the MFG trim sector 456 in the NVM 450 to, for example, reconfigure the secure PLD 410 to operate without faults. In some embodiments, such a fault characterization / debug process can be iteratively performed with multiple updated MFG trims to converge to an acceptable MFG trim that eliminates detectable faults in the operation of the secure PLD 410 and converts the secure PLD 410 into a verified secure PLD 410. After completion of the execution of the debug configuration, generation of the debug summary, and / or update of the MFG trims, the secure PLD 410 can be resupplied (e.g., according to optional block 850 of the fault characterization process 800), or isolated, or otherwise destroyed, as identified in the generated debug summary, as desired, and / or as indicated by the debug results.

[0110] Thus, by adopting the systems and methods described herein, embodiments of the present disclosure are capable of providing flexible, secure, and accurate fault characterization of secure PLDs across client orders of secure PLDs. Secure PLDs that exhibit faults and are locked by the client and / or provided otherwise can be securely erased and provided back to the manufacturer for fault characterization and / or repair (e.g., readjustment) to assist the client in identifying fault modes of the secure PLD and / or the integrated user device without risking exposure of client data. Additionally, faults in the secure PLD can be characterized and / or debugged without the risk of a post-debugged secure PLD, which is typically programmable by a third party without access to the factory private key and / or without the permission of at least the secure PLD manufacturer 520, as described herein.

[0111] In applicable cases, various embodiments provided by the present disclosure can be implemented using hardware, software, or a combination of hardware and software. Additionally, in applicable cases, the various hardware components and / or software components described herein can be combined into composite components including software, hardware, and / or both without departing from the spirit of the present disclosure. In applicable cases, the various hardware components and / or software components described herein can be separated into sub-components including software, hardware, or both without departing from the spirit of the present disclosure. Further, in applicable cases, it is contemplated that software components can be implemented as hardware components and vice versa.

[0112] Software according to the present disclosure, such as non-transitory instructions, program code, and / or data, can be stored on one or more non-transitory machine-readable media. It is also contemplated that one or more general-purpose or special-purpose computers and / or computer systems can be used to implement the software identified herein, which are networked and / or otherwise. In applicable cases, the order of the various steps described herein can be changed, combined into composite steps, and / or separated into sub-steps to provide the features described herein.

[0113] The above embodiments illustrate but do not limit the invention. It should also be understood that many modifications and variations are possible in accordance with the principles of the present invention. Therefore, the scope of the present invention is defined only by the following claims.

Claims

1. A safety programmable logic device (PLD) fault characterization system, comprising: A safety PLD, wherein the safety PLD includes: a plurality of programmable logic blocks (PLBs) arranged in a PLD structure of the safety PLD; and a configuration engine configured to program the PLD structure according to a configuration image stored in a non-volatile memory (NVM) of the safety PLD and / or coupled to the configuration engine through a configuration I / O of the safety PLD, wherein the safety PLD is configured to execute a computer-implemented method, and the computer-implemented method includes: Receiving a fault characterization (FC) command from the PLD structure or from an external system coupled to the safety PLD through the configuration I / O; Executing the FC command, wherein executing the FC command includes erasing and / or invalidating at least a portion of the NVM of the safety PLD; and Executing a debug process, wherein executing the debug process includes guiding a debug configuration by the PLD structure, the debug configuration being received from the external system through the configuration I / O, loaded in the PLD structure, and configured to identify and / or characterize a fault in the operation of any one element or combination of elements of the safety PLD.

2. The safety programmable logic device (PLD) fault characterization system according to claim 1, wherein the computer-implemented method further includes: Authenticating the received FC command before executing the FC command, wherein the FC command is signed using an application private key associated with a safety PLD client for the safety PLD, a corresponding application public key is stored in the NVM, and the authentication includes authenticating the FC command signed using the application private key associated with the safety PLD client using the application public key.

3. The safety programmable logic device (PLD) fault characterization system according to claim 1, wherein the computer-implemented method further includes: Authenticating the received FC command before executing the FC command, wherein the FC command includes an FC trace ID, a trace ID associated with the safety PLD is stored in the NVM, and the authentication includes comparing the FC trace ID with the trace ID stored in the NVM.

4. The safety programmable logic device (PLD) fault characterization system according to claim 2 or 3, wherein the NVM includes rewritable and / or unlocked sectors, and wherein executing the authenticated FC command includes: Erasing respective sectors of the NVM according to a prioritized erasure order, wherein the prioritized erasure order includes a user flash sector, an image sector, a safety storage sector including safety features stored therein, a device key sector, and a lock policy sector.

5. The safety programmable logic device (PLD) fault characterization system according to claim 2 or 3, wherein the NVM includes one-time programmable sectors, and wherein executing the authenticated FC command includes: Invalidate each sector of the NVM according to a prioritized erase order, where the invalidation includes setting all bits in a specific sector to "1", and where the prioritized erase order includes user flash sectors, image sectors, secure storage sectors including security features stored therein, device key sectors, and lock policy sectors.

6. The secure programmable logic device (PLD) fault characterization system according to claim 1, wherein performing the debug process includes: Receiving a debug configuration through the configuration I / O; Loading, booting, and / or executing the received debug configuration in the PLD structure; And Generating a debug summary associated with the debug configuration, where the debug summary includes a list of faults associated with the execution of the debug configuration by the PLD structure.

7. The secure programmable logic device (PLD) fault characterization system according to claim 6, wherein performing the debug process further includes: Authenticating the debug configuration before loading, booting, and / or executing the received debug configuration in the PLD structure; And Providing the debug summary to an external system coupled to the secure PLD through the configuration I / O.

8. The secure programmable logic device (PLD) fault characterization system according to claim 1, wherein the computer-implemented method further includes re-supplying the secure PLD after performing the debug process, and wherein re-supplying the secure PLD includes: Receiving a programming private key, a programming secret, and an initial programming image (IPI) configuration through the configuration I / O of the secure PLD; Storing the IPI configuration in the NVM; And Programming the PLD structure of the secure PLD according to the IPI configuration.

9. The secure programmable logic device (PLD) fault characterization system according to claim 1, further comprising: An external system including a processor and a memory, and configured to be coupled to the secure PLD through the configuration I / O of the secure PLD, wherein the memory includes machine-readable instructions that, when executed by the processor of the external system, are adapted to cause the external system to: Provide a debug configuration to the secure PLD through the configuration I / O; Receive a debug summary from the secure PLD associated with the boot and / or execution of the debug configuration by the PLD structure of the secure PLD; Determine an updated manufacturer trim at least in part based on the received debug summary; And Provide the updated manufacturer trim to the secure PLD through the configuration I / O.

10. The secure programmable logic device (PLD) fault characterization system according to claim 1, further comprising: An external system including a processor and a memory, and configured to be coupled to the secure PLD through the configuration I / O of the secure PLD, wherein the memory includes machine-readable instructions that, when executed by the processor of the external system, are adapted to cause the external system to: Generate or receive a protected configuration for the secure PLD; and Program the secure PLD according to the protected configuration; wherein the protected configuration includes an application configuration, a feature configuration, and a programming key digest, the application configuration and the feature configuration are each signed by an application private key associated with a secure PLD client and encrypted by an application encryption key associated with the secure PLD client, the programming key digest includes an encrypted and signed combination of an application public key, the application encryption key, and a programming secret, and the programming secret is associated with the secure PLD client.

11. A secure programmable logic device (PLD) fault characterization system, comprising: An external system, including a processor and a memory, and configured to be coupled to the secure PLD through a configuration I / O of the secure PLD, wherein the memory includes machine-readable instructions that, when executed by the processor of the external system, are adapted to cause the external system to perform a computer-implemented method, the computer-implemented method including: Providing a fault characterization (FC) command and / or a debug configuration to the secure PLD through the configuration I / O; Receiving from the secure PLD a debug summary associated with the boot and / or execution of the debug configuration performed by the PLD fabric of the secure PLD; Determining an updated manufacturer trim at least in part based on the received debug summary; and Providing the updated manufacturer trim to the secure PLD through the configuration I / O.

12. The secure programmable logic device (PLD) fault characterization system according to claim 11, further comprising: The secure PLD, wherein the secure PLD includes: a plurality of programmable logic blocks (PLBs) arranged in the PLD fabric of the secure PLD; a configuration engine configured to program the PLD fabric according to a configuration image stored in a non-volatile memory (NVM) of the secure PLD and / or coupled to the configuration engine through the configuration I / O; and a security engine configured to provide a plurality of security functions for the PLD fabric and / or the configuration engine, wherein the secure PLD is configured to perform a secure PLD-implemented method, the secure PLD-implemented method including: Receiving the FC command from the external system coupled to the secure PLD through the configuration I / O; Authenticating the received FC command using one or more security functions of the security engine of the secure PLD, wherein the authentication includes authenticating the FC command signed using an application private key associated with a secure PLD client for the secure PLD using an application public key stored in the NVM; Executing the FC command, wherein executing the FC command includes erasing and / or invalidating at least a portion of the NVM of the secure PLD; and Perform a debug process corresponding to the debug configuration provided by the external system, where performing the debug process includes generating a debug summary that includes debug information that identifies and / or characterizes a fault in the operation of any one or combination of elements of the secure PLD.

13. A method for fault characterization of a secure programmable logic device (PLD), the method comprising: Receiving a fault characterization (FC) command from the PLD structure or from an external system coupled to the secure PLD via the configuration I / O of the secure PLD; Executing the FC command, where executing the FC command includes erasing and / or invalidating at least a portion of the non-volatile memory (NVM) of the secure PLD; And Performing a debug process, where performing the debug process includes the PLD structure guiding a debug configuration that is received via the configuration I / O from the external system, loaded in the PLD structure, and configured to identify and / or characterize a fault in the operation of any one or combination of elements of the secure PLD.

14. The method according to claim 13, further comprising: Authenticating the received FC command before executing the FC command, where the FC command is signed using an application private key associated with a secure PLD client for the secure PLD, a corresponding application public key is stored in the NVM, and the authentication includes using the application public key to authenticate the FC command signed using the application private key associated with the secure PLD client.

15. The method according to claim 13, further comprising: Authenticating the received FC command before executing the FC command, where the FC command includes an FC trace ID, a trace ID associated with the secure PLD is stored in the NVM, and the authentication includes comparing the FC trace ID with the trace ID stored in the NVM.

16. The method according to claim 14 or 15, where the NVM includes rewritable and / or unlocked sectors, and where executing the authenticated FC command includes: Erasing the respective sectors of the NVM according to a prioritized erase order, where the prioritized erase order includes user flash sectors, image sectors, secure storage sectors including security features stored therein, device key sectors, and lock policy sectors.

17. The method according to claim 14 or 15, where the NVM includes one-time programmable sectors, and where executing the authenticated FC command includes: Invalidating the respective sectors of the NVM according to a prioritized erase order, where the invalidation includes setting all bits in a specific sector to "1", and where the prioritized erase order includes user flash sectors, image sectors, secure storage sectors including security features stored therein, device key sectors, and lock policy sectors.

18. The method according to claim 13, where performing the debug process includes: Receiving a debug configuration via the configuration I / O; Load, boot, and / or execute the received debug configuration in the PLD structure; and Generate a debug summary associated with the debug configuration, wherein the debug summary includes a list of faults associated with the execution of the debug configuration by the PLD structure.

19. The method according to claim 18, wherein performing the debug process further comprises: Authenticate the debug configuration before loading, booting, and / or executing the received debug configuration in the PLD structure; and Provide the debug summary to an external system coupled to the secure PLD via the configuration I / O.

20. The method according to claim 13 further comprises: After performing the debug process, re-provision the secure PLD, wherein re-provisioning the secure PLD comprises: Receiving a programming private key, a programming secret, and an initial programming image IPI configuration via the configuration I / O of the secure PLD; Storing the IPI configuration in the NVM; and Programming the PLD structure of the secure PLD according to the IPI configuration.

Images