Subsystem for configuration, security, and management of adaptive systems

Abstract

The integrated circuit (IC) may include a processor system configured to execute program code, programmable logic, and a platform management controller coupled to the processor system and the programmable logic, the platform management controller adapted to independently configure and control the processor system and the programmable logic.

Description

[Technical field]

[0001] Technical Field The present disclosure relates to integrated circuits (ICs) and, more particularly, to configuration, security, and management of adaptive systems implemented as ICs. [Background technology]

[0002] Background technology A programmable integrated circuit (IC) refers to a type of device that contains programmable logic. An example of a programmable device or IC is a field programmable gate array (FPGA). Some modern programmable ICs have evolved to include programmable logic as a subsystem in combination with one or more other subsystems. For example, some programmable ICs include programmable logic in combination with a hardwired processor. These types of programmable ICs are sometimes called systems-on-chips or "SoCs." Summary of the Invention [Means for solving the problem]

[0003] Summary of the Invention In one aspect, an integrated circuit (IC) includes a processor system configured to execute program code, programmable logic, and a platform management controller coupled to the processor system and the programmable logic, the platform management controller adapted to independently configure and control the processor system and the programmable logic.

[0004] In another aspect, a method includes providing a processor system on an IC, the processor system configured to execute program code. The method can include providing programmable logic on the IC and providing a platform management controller on the IC. The platform management controller is coupled to the processor system and the programmable logic and adapted to independently configure and control the processor system and the programmable logic.

[0005] This summary section is provided merely to introduce certain concepts and is not intended to identify key or essential features of the claimed subject matter. Other features of the inventive subject matter will be apparent from the accompanying drawings and the detailed description that follows.

[0006] BRIEF DESCRIPTION OF THE DRAWINGS Arrangements of the present invention are illustrated by way of example in the accompanying drawings. The drawings should not, however, be construed as limiting the arrangements of the present invention to only the particular embodiments shown. Various aspects and advantages will become apparent upon consideration of the following detailed description and upon reference to the drawings. [Brief description of the drawings]

[0007] [Figure 1] 1 shows an exemplary architecture for a system-on-chip (SoC) type integrated circuit (IC). [Diagram 2] 2 illustrates an exemplary implementation of the network-on-chip (NoC) of FIG. [Diagram 3] 2 illustrates an exemplary implementation of the data processing engine (DPE) array of FIG. 1. [Figure 4] 2 illustrates an exemplary implementation of the processor system of FIG. [Diagram 5] 2 illustrates another exemplary implementation of the SoC of FIG. [Figure 6] 1 illustrates an exemplary embodiment of a platform management controller (PMC). [Figure 7]1 illustrates an exemplary redundant implementation of a processor in a PMC. [Figure 8] 1 illustrates further structural and functional aspects of the SoC. [Figure 9] 9 illustrates an exemplary implementation of the programmable protection circuit of FIG. 8. [Figure 10] 1 illustrates exemplary features of a PMC. [Figure 11] 1 illustrates an exemplary method for booting a SoC. [Figure 12] 4 illustrates another exemplary method for booting a SoC. [Figure 13] 1 illustrates an example of a programming device image that may be used to boot an SoC. [Figure 14] 1 illustrates an example of a cross-sectional side view of an IC structure having multiple dies. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present disclosure is concluded by the claims that define the novel features, however, it is believed that the various features described in the present disclosure will be better understood by considering the description in conjunction with the drawings. The processes, machines, manufactures, and any variations thereof described herein are provided for illustrative purposes. The specific structural and functional details described in the present disclosure should not be construed as limiting, but merely as a basis for the claims, and as a representative basis for teaching those skilled in the art to variously use the described features in substantially any appropriately detailed structure. Moreover, the terms and phrases used in the present disclosure are not intended to be limiting, but rather to provide an understandable description of the described features.

[0009] The present disclosure relates to integrated circuits (ICs), and more particularly to configuration, security, and management of adaptive systems implemented as ICs. In accordance with the inventive arrangements described within this disclosure, a platform management controller (PMC) is incorporated into the IC. The IC, being an adaptive system, includes a number of different subsystems, one or more of which are programmable. Examples of these subsystems include a processor system (PS) and a programmable logic (PL).

[0010] The PMC is a subsystem within an IC that can manage each of the other subsystems across the entire IC. For example, the PMC may provide unified programmable control over power-up, boot / configuration, security, power management, safety monitoring, debug, and / or IC-wide error handling for different subsystems. The functionality provided by the PMC may also be operable at the device level within each subsystem. The use of a PMC subsystem dedicated to platform management provides a single, unified, and programmable platform for the PS. of PL from Thus, the PS and PL may be independently managed, configured, and / or powered on and / or off by the PMC. In other words, the PMC can perform the described operations for the PS independently of the PL, and for the PL independently of the PS.

[0011] Conventional field programmable gate arrays (FPGAs) with a processor (e.g., PS) utilized separate configuration interfaces and separate protocols to control and / or manage the PS and PL. For example, in previous generation FPGAs that included a PS for executing user applications (e.g., executable program code) and a PL for implementing user circuit designs, configuration of the PL passed through the PS. Thus, in such architectures, the PL was dependent on the PS being powered and configured (e.g., started and functional) before performing any operations with respect to the PL. Due to this dependency between the PS and the PL, separation or independent control of the PL from the PS was often desirable but not possible. The use of a PMC facilitates separation of the PL from the PS.

[0012] In another aspect, from a security perspective, the PMC can act as a root of trust for the entire device (e.g., IC). As an example, the PMC is responsible for authenticating the programming image loaded into the device and protecting the device from tampering during operation. By using the PMC as a root of trust, the PMC can monitor and verify the operation of the PS, PL, and / or any other subsystems that may be included in the device. Furthermore, the root of trust functions performed by the PMC are distinct and separate from each of the PS and PL and / or any operations performed by the PS and / or PL.

[0013] In another aspect, the PMC may operate from a dedicated power source. In this way, the PMC is powered by a power source that is separate and independent from the power source of the PS and the power source of the PL. This power independence allows the PMC, PS, and PL to be mutually protected against electrical noise and glitches (e.g., attacks). Furthermore, one or both of the PS and PL may be powered down (e.g., completely off, suspended, or placed in a low-power hibernate mode) while the PMC continues to operate. For example, the PMC may be configured to remain on at all times while other subsystems are powered on or off. This feature allows any subsystem of a device that has been powered down to be started up more quickly and restored to an operational state without the need for the entire device to go through a full power-up and startup process.

[0014] In yet another aspect, the PMC may execute firmware. In this manner, the PMC is configurable by modifying the firmware loaded and executed by the PMC. Such PMC configurability allows the same management hardware (e.g., the same PMC architecture) to be used to accommodate devices having different feature sets. The use of firmware also supports configurability and segmentation of global device functions such as reset, clocking, and protection to provide flexibility in creating separate processing domains (different from "power domains" that may be subsystem specific) that may include a mix or combination of one or more subsystems of the device.

[0015] The PMC supports additional features that are described in more detail below. For example, the PMC may include a debug interface for a unified debug infrastructure for devices operable across subsystems. Use of the debug interface is not dependent on availability of the PS or PL. Furthermore, the debug interface and infrastructure does not intrude on the device's resources available to the user (e.g., PS and / or PL resources). The PMC may also include security components that cannot be accessed by user applications implemented on the device (e.g., in the PS, PL, and / or other subsystems). The PMC also provides security so that access to the debug interface is protected.

[0016] Further aspects of the inventive arrangement are described in more detail below with reference to the drawings. For simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, dimensions of some elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding, similar or like features.

[0017] FIG. 1 illustrates an example architecture of a system-on-chip (SoC) 100. SoC 100 is an example of a programmable IC and adaptive system. In the example of FIG. 1, various different subsystems or regions of the illustrated SoC 100 may be implemented on a single die provided within a single integrated package. In other examples, different subsystems may be implemented on multiple interconnected dies provided as a single integrated package.

[0018] In this example, SoC 100 includes multiple regions having circuits with different functions. In this example, SoC 100 optionally includes a data processing engine (DPE) array 102. SoC 100 includes PL 104, PS 106, optional network-on-chip (NoC) 108, PMC 110, and optionally one or more hardwired circuit blocks 112.

[0019] DPE array 102 is implemented as an array of multiple interconnected hardwired and programmable processors, e.g., DPEs, with interfaces to other areas of SoC 100. The DPEs in DPE array 102 are hardwired. Each DPE in DPE array 102 contains one or more cores and dedicated memory. A core of a DPE can access memory within the same DPE and memory of any other DPEs adjacent to the core of the DPE, either vertically, horizontally, or vertically. The cores of the DPE see each of these memories as a unified region of memory. This facilitates data sharing between DPEs.

[0020] The DPEs of the DPE array 102 are interconnected by programmable interconnect circuitry, allowing groups of one or more DPEs to be arranged into groups or clusters. For example, the interconnect circuitry may include a configuration network (e.g., providing instructions for execution and / or data) for configuring each DPE, a programmable stream network that allows different DPEs in the DPE array 102 to communicate using packetized data (e.g., rather than establishing connections bit by bit as in the case of the PL 104), and a debug network that allows debug information to be obtained.

[0021] The configuration network allows configuration data, such as instructions for execution by each DPE, stream switch programming that establishes logic links between the DPEs, etc., to be loaded into the DPE array 102. Each DPE can have different program code therein to implement one or more different kernels. In another aspect, the cores of DPEs in the same row may be directly connected by a cascade interface, and the cores of an edge DPE in one row may be directly connected to the cores of another edge DPE in a different row directly above or below.

[0022] PL 104 is a circuit that can be programmed to perform a specified function. As an example, PL 104 may be implemented as a field programmable gate array type circuit. PL 104 may include an array of programmable circuit blocks. As defined herein, the term "programmable logic" refers to a circuit used to build a reconfigurable digital circuit. Programmable logic is formed from many programmable circuit blocks, sometimes called "tiles," that provide basic functions. The topology of PL 104 is highly configurable, unlike hardwired circuits. Each programmable circuit block of PL 104 typically includes programmable elements (e.g., functional elements) and programmable interconnects. The programmable interconnects provide the highly configurable topology of PL 104. The programmable interconnects may be configured on a wire-by-wire basis to provide connectivity between programmable circuit blocks of PL 104, which is configurable on a bit-by-bit basis (e.g., where each wire carries one bit of information), unlike the connectivity between DPEs.

[0023] Examples of programmable circuit blocks in PL 104 include configurable logic blocks with look-up tables and registers. Unlike hardwired circuits, described below and sometimes referred to as hard blocks, these programmable circuit blocks have functions that are not defined at the time of manufacture. PL 104 can include other types of programmable circuit blocks that also provide basic and defined functions with more limited programmability. These circuit blocks include digital signal processing blocks (DSPs), phase-locked loops (PLLs), block random access memories (BRAMs), and the like. These types of programmable circuit blocks are as numerous as others in PL 104 and are intermingled with other programmable circuit blocks in PL 104.

[0024] Prior to use, PL 104, e.g., programmable interconnects and programmable elements, must be programmed or "configured" by loading data, called a configuration bitstream, into internal configuration memory cells that, when loaded with the configuration bitstream, define how PL 104 is configured, e.g., the topology, and operation (e.g., the particular function to be performed). Within this disclosure, a "configuration bitstream" is not equivalent to program code executable by a processor or computer.

[0025] CFrame Interface (CFI) 114 is an interface through which configuration data, e.g., a configuration bitstream, can be provided to PL 104 to implement different user-specified circuits and / or circuits therein. CFI 114 can also be used to initialize memory contained within PL 104. CFI 114 is accessible by PMC 110 to provide configuration data to PL 104 and perform memory initialization as described. In some cases, PMC 110 can initially configure PS 106 such that PS 106 can provide configuration data to PL 104 once configured by PMC 110.

[0026] The PS 106 is implemented as a hardwired circuit that is fabricated as part of the SoC 100. The PS 106 may be implemented as or include any of a variety of different processor types, each capable of executing program code. For example, the PS 106 may be implemented as an individual processor, e.g., a single core capable of executing program code. In another example, the PS 106 may be realized as a multi-core processor. In yet another example, the PS 106 may include one or more cores, modules, co-processors, interfaces, controllers, and / or other resources. The PS 106 may be implemented using any of a variety of different types of architectures. Exemplary architectures that may be used to implement the PS 106 may include, but are not limited to, an ARM processor architecture, an x86 processor architecture, a graphics processing unit (GPU) architecture, a mobile processor architecture, a DSP architecture, or any other suitable architecture capable of executing computer-readable instructions or program code.

[0027] The NoC 108 is an interconnect network for sharing data between endpoint circuits in the SoC 100. The endpoint circuits may be located in the DPE array 102, the PL 104, the PS 106, and / or the hardwired circuit blocks 112. The NoC 108 may include high-speed data paths with dedicated switching. In one example, the NoC 108 includes one or more horizontal paths, one or more vertical paths, or both horizontal and vertical paths. The arrangement and number of regions shown in FIG. 1 are merely examples. The NoC 108 is an example of a common infrastructure that may be utilized within the SoC 100 to connect selected components and / or subsystems.

[0028] The NoC 108 provides connections to selected ones of the PL 104, the PS 106, and the hardwired circuit blocks 112. The NoC 108 is programmable. For a programmable NoC used with the SoC 100, the nets to be routed through the NoC 108 are unknown until a user circuit design is created for implementation within the SoC 100. The NoC 108 can be programmed by loading configuration data into internal configuration registers that define how elements within the NoC 108, such as switches and interfaces, are configured and operate to pass data between switches and between NoC interfaces to connect to endpoint circuits.

[0029] The NoC 108 is fabricated as part of the SoC 100 and is not physically modifiable, but can be programmed to establish connections between different master circuits and different slave circuits of a user circuit design. The NoC 108 does not implement data paths or routes therein upon power-up. However, when configured by the PMC 110, the NoC 108 implements data paths or routes between end-point circuits. For example, the NoC 108 can include multiple programmable switches that can establish a packet-switched network connecting user-specified master and slave circuits. In this regard, the NoC 108 can accommodate different circuit designs, each different circuit design having a different combination of master and slave circuits implemented at different locations within the SoC 100 that can be coupled by the NoC 108. The NoC 108 can be programmed to route data, such as application data and / or configuration data, between the master and slave circuits of a user circuit design. For example, NoC 108 may be programmed by PMC 110 to couple different user-specified circuits to each other, whether implemented using PL 104, PS 106, and / or DPE array 102. Additionally, NoC 108 may couple user-specified circuits to different hardwired circuit blocks 112 and / or different circuits and / or systems external to SoC 100.

[0030] The hardwired circuit blocks 112 are dedicated circuit blocks fabricated as part of the SoC 100. Although hardwired, the hardwired circuit blocks 112 can be configured by loading configuration data into control registers to implement one or more different operating modes. The hardwired circuit blocks 112 can include, by way of example, input / output (I / O) blocks and / or transceivers for sending and receiving signals to circuits and / or systems external to the SoC 100, memory controllers, and video encoders. Examples of different I / O blocks can include single-ended and pseudo-differential I / O. Examples of transceivers can include high-speed differential clock transceivers. Other examples of the hardwired circuit blocks 112 include, but are not limited to, encryption engines, digital-to-analog converters (DACs), analog-to-digital converters (ADCs), and the like. The hardwired circuit blocks 112 in the SoC 100 may sometimes be referred to herein as "hard blocks." The hardwired circuit blocks 112 are typically more complex in function than the programmable circuit blocks of the PL 104. Furthermore, there are typically few hardwired circuit blocks 112 in the SoC 100 compared to the programmable circuit blocks or tiles of the PL 104 .

[0031] In the example of FIG. 1, PL 104 is shown in four separate regions. In another example, PL 104 may be implemented as a unified region of programmable circuitry. In yet another example, PL 104 may be implemented as more than four distinct regions of programmable circuitry or less than four distinct regions of programmable circuitry. The particular organization of PL 104 is not intended to be limiting. Here, SoC 100 includes PL 104 having one or more regions, PS 106, and PMC 110. NoC 108 may also be included. DPE array 102 may also be included.

[0032] In other exemplary implementations, the SoC 100 may include two or more DPE arrays 102 located in different areas of the IC. In yet other examples, the SoC 100 may be implemented as a multi-die IC. In one example, each subsystem may be implemented on a different die. In another example, one or more or all of the subsystems may be replicated across each die. The different dies may be communicatively linked using any of a variety of available multi-die IC techniques, such as stacking the dies side-by-side on an interposer using a stacked die architecture where the IC is implemented as a multi-chip module (MCM), or the like. It should be understood that in the multi-die IC example, each die may include a single subsystem, two or more subsystems, a subsystem and another sub-subsystem, or any combination thereof. In one exemplary implementation, each die may include a PMC, where the PMC implemented on the die designated as the "master" is the master PMC, and the PMCs implemented on the other dies designated as slaves operate as slave PMCs coupled to the master PMC.

[0033] 2 illustrates an exemplary implementation of the NoC 108. The NoC 108 includes a NoC Master Unit (NMU) 202, a NoC Slave Unit (NSU) 204, a network 214, a NoC Peripheral Interconnect (NPI) 210, and a register 212. Each NMU 202 is an ingress circuit that connects an endpoint circuit to the NoC 108. Each NSU 204 is an egress circuit that connects the NoC 108 to an endpoint circuit. The NMUs 202 are connected to the NSUs 204 via a network 214. In one example, the network 214 includes a NoC Packet Switch 206 (NPS) and routing 208 between the NPSs 206. Each NPS 206 performs switching of NoC packets. The NPSs 206 are connected to each other and to the NMUs 202 and NSUs 204 via the routing 208 to implement multiple physical channels. The NPSs 206 also support multiple virtual channels per physical channel.

[0034] The NPI 210 includes circuitry for programming the NMU 202, NSU 204, and NPS 206. For example, the NMU 202, NSU 204, and NPS 206 may include registers 212 that determine their functionality. The NPI 210 includes a peripheral interconnect coupled to the registers 212 for programming thereof to set functions. The registers 212 in the NoC 108 support interrupts, quality of service (QoS), error handling and reporting, transaction control, power management, and address mapping control. The registers 212 may be initialized in a usable state before being reprogrammed, such as by the PMC 110 writing to the registers 212 using a write request. Configuration data for the NoC 108 may be stored in a non-volatile memory (NVM), for example, as part of a programming device image (PDI), and provided to the NPI 210 to program the NoC 108 and / or other endpoint circuits.

[0035] NMUs 202 are traffic ingress points. NSUs 204 are traffic egress points. The endpoint circuitry coupled to NMUs 202 and NSUs 204 may be hardened circuitry (e.g., hardwired circuit blocks 112), circuitry implemented in the PL 104, and / or circuitry of the DPE array 102. A given endpoint circuit may be coupled to multiple NMUs 202 or multiple NSUs 204.

[0036] In this example, endpoint circuit 216 is connected to endpoint circuit 218 through NoC 108. Endpoint circuit 216 is a master circuit coupled to NMU 202 of NoC 108. Endpoint circuit 218 is a slave circuit coupled to NSU 204 of NoC 108. Each endpoint circuit 216 and 218 may be circuitry within PS 106, circuitry within PL domain 104, or circuitry in another subsystem (e.g., within hardwired circuit block 112 and / or DPE array 102).

[0037] The network 214 includes multiple physical channels. The physical channels are implemented by programming the NoC 108. Each physical channel includes one or more NPSs 206 and associated routing 208. The NMUs 202 connect with the NSUs 204 through at least one physical channel. A physical channel may also have one or more virtual channels.

[0038] The connections over network 214 use a master-slave configuration. In one example, the most basic connection over network 214 involves a single master connected to a single slave. However, in other examples, more complex structures can be implemented.

[0039] As shown in the example of FIG. 1, the NoC 108 can include one or more vertical portions, called vertical NoCs or “VNoCs,” and one or more horizontal portions, called “HNoCs.” Each VNoC is located between PL regions 104. The HNoC is typically located between a region of the PL 104 and a hardwired circuit block 112, or between a region of the PL 104 and the DPE array 102. The NoC 108 can be connected to a memory interface (e.g., other hardwired circuit blocks 112). The PS 106 can be coupled to the HNoC.

[0040] In this example, the PS 106 includes multiple NMUs 202 coupled to the HNoC. The VNoC includes both NMUs 202 and NSUs 204 located in the PL 104. Certain hardwired circuit blocks 112, such as memory interfaces, include NSUs 204 coupled to the HNoC. Both the HNoC and the VNoC include NPSs 206 connected by routing 208. In the VNoC, the routing 208 extends vertically. In the HNoC, the routing 208 extends horizontally. In each VNoC, each NMU 202 is coupled to an NPS 206. Similarly, each NSU 204 is coupled to an NPS 206. The NPSs 206 are coupled to each other to form a matrix of switches. Some NPSs 206 in each VNoC are coupled to other NPSs 206 in the HNoC.

[0041] The NoC 108 may be programmed and / or used as part of a larger boot or programming process, or may be programmed independently of other subsystems within the SoC 100. In general, programming the NoC 108 may include the PMC 110 receiving NoC programming data at boot time. The NoC programming data may be part of the PDI. The PMC 110 is responsible for managing the SoC 100. The PMC 110 may maintain a safe and secure environment, boot the SoC 100, and manage the SoC 100 during normal operation.

[0042] The PMC 110 loads the NoC programming data into the registers 212 via the NPI 210 to create the physical channels. In one example, the programming data may also include information for configuring the routing tables in the NPS 206. The PMC 110 further boots the SoC 100. Thus, the NoC 108 includes at least configuration information for the physical channels between the NMU 202 and the NSU 204. The remaining configuration information for the NoC 108 may be received during run-time, as described further below. In another example, all or a portion of the configuration information described below as being received during run-time may be received at boot time.

[0043] With respect to run-time, the PMC 110 can receive NoC programming data during run-time. The PMC 110 loads the programming data into the registers 212 via the NPI 210. In one example, the PMC 110 configures the routing tables in the NPS 206. The PMC 110 configures QoS paths on the physical channels. The PMC 110 configures address space mappings. The PMC 110 sets the ingress / egress interface protocols, widths, and frequencies.

[0044] FIG. 3 illustrates an exemplary implementation of a DPE array 102. In the example of FIG. 3, the DPE array 102 is implemented as a two-dimensional array of DPEs 302 that includes an SoC interface block 304. The DPEs 302 and the SoC interface block 304 are hardwired and programmable. The DPE array 102 may be implemented using any of a variety of different architectures. For purposes of illustration and not limitation, FIG. 3 illustrates the DPEs 302 arranged in aligned rows and aligned columns. In the example, the DPEs 302 are arranged such that the DPEs in a selected row are horizontally inverted or mirrored relative to the DPEs in an adjacent row. In one or more other embodiments, the rows and / or columns of DPEs 302 may be offset relative to adjacent rows and / or columns. In this example, each DPE 302 includes a core 306 and a memory module 308. Each core 306 can access data from an adjacent memory module, whether in the same DPE 302 or another DPE 302. The number of DPEs 302, the particular placement of the DPEs 302, and / or the orientation of the DPEs 302 are not intended to be limiting.

[0045] The DPEs 302 are interconnected by a DPE interconnect network, which includes core-memory interface connections, core-core cascading connections, streaming connections, and memory-mapped connections. The DPE interconnect network may also include a separate debug network and / or a separate event broadcast network (neither shown).

[0046] The SoC interface block 304 is both hardwired and programmable and can couple the DPE 302 to one or more other subsystems of the SoC 100. In one or more embodiments, the SoC interface block 304 is coupled to an adjacent DPE 302. For example, the SoC interface block 304 can be directly coupled to each DPE 302 in the lowest tier of DPEs in the DPE array 102. The SoC interface block 304 communicates with one or more selected DPEs 302 in the DPE array 102 that are directly connected to the SoC interface block 304, and can communicate with any DPE 302 in the DPE array 102 by utilizing a DPE interconnect network formed from various configurable switches (not shown) included within each DPE 302. The SoC interface block 304 can couple each DPE 302 in the DPE array 102 to one or more other subsystems of the SoC 100. For example, the SoC interface block 304 can couple the DPE array 102 to the NoC 108 and the PL 104. Thus, the DPE array 102 (eg, a selected DPE 302 ) can communicate with circuit blocks implemented in either the PL 104 , the PS 106 , and / or the hardwired circuit blocks 112 .

[0047] The cores 306 provide the data processing capabilities of the DPE 302. Each core 306 may be implemented as any of a variety of different processing circuits. In an exemplary implementation, each core 306 is implemented as a processor capable of executing program code, e.g., computer readable instructions. Each core 306 may then include a program memory that may only be accessed by the particular core in which the program memory is located. The program memory within each core 306 may store instructions to be executed by the respective core 306. The cores 306 may be implemented, for example, as a CPU, GPU, DSP, vector processor, or other type of processor capable of executing instructions. The cores 306 may be implemented using any of a variety of CPU and / or processor architectures described herein. In another example, the cores 306 are implemented as a very long instruction word (VLIW) vector processor or DSP.

[0048] The cores 306 and memory modules 308 may be controlled by configuration data loaded into registers within each DPE 302. For example, each core 306 and / or memory 308 may be activated and / or deactivated based on the configuration data loaded into the registers. The registers and memory modules 308 are addressable (e.g., may be read and / or written) via memory-mapped connections of the DPE interconnect network by specific masters within the SoC 100. For example, the PMC 110 may read and / or write any memory within the DPE array 102 that is addressable using the memory-mapped connections of the DPE interconnect network.

[0049] In one or more embodiments, the memory module 308 can store data used and / or generated by any adjacent core 306. For example, the memory module 308 can include a read / write memory, such as a random access memory (RAM). Thus, the memory module 308 can store data that can be read and consumed by the core 306. The memory module 308 can also store data (e.g., results) that are written by the core 306. Each memory module 308 may be directly read from and written to by a core 306 that is directly adjacent to it in the top, bottom, left, right, or right directions (e.g., the four cardinal directions). Thus, a core 306 can directly access the memory module 308 in the same DPE 302, as well as the memory modules of three other nearby adjacent DPEs 302, as long as the core 306 is not in an edge column or edge row of a DPE 302 that has a memory module 308 that is directly adjacent to the core 306. The direct memory access is performed by a core-memory interface connection. Each core 306 can view the memory modules 308 that it can access (e.g., the four memory modules configured within the same DPE and the memory modules of three other DPEs) as a single contiguous memory (e.g., as a single address space), which allows DPEs 302 (e.g., cores 306) to also communicate through the shared memory.

[0050] The DPE array 102 can be programmed by loading configuration data into registers (not shown) in each DPE 302 that defines the connectivity between the DPE 302 and the SoC interface block 304, and how the DPE 302 and the SoC interface block 304 operate. For example, if a particular DPE 302 or group of DPEs 302 communicate with a subsystem, the DPE 302 and the SoC interface block 304 are programmed to do so. Similarly, if one or more particular DPEs 302 communicate with one or more other DPEs 302, the DPEs are programmed to do so. The configuration data indicates whether the DPEs 302 communicate via stream connections or using core-core cascade connections.

[0051] 3, the streaming connections, the core-core cascade connections (direct core-core connections), and the core-memory interface connections facilitate the exchange of application data between the DPEs 302. The memory-mapped connections facilitate the exchange of configuration data, control data, debug data, etc.

[0052] Streaming connections can be implemented by including one or more stream switches in each DPE 302. The stream switches are interconnected. For example, each stream switch can include ports that connect to other DPEs 302 in the four cardinal directions and can include ports that connect to circuit structures within the same DPE 302 (e.g., cores 306, memory modules 308 via one or more direct memory access circuits, and memory-mapped switches within the same DPE 302). Streaming connections allow adjacent and non-adjacent DPEs 302 to communicate. In general, stream switches are programmed to operate as circuit-switched stream interconnects or packet-switched stream interconnects. Circuit-switched stream interconnects can implement point-to-point dedicated streams suitable for high-bandwidth communication between DPEs 302. Packet-switched stream interconnects allow sharing of streams to time-multiplex multiple logic streams into one physical stream for medium-bandwidth communication. The operation of the stream switches can be controlled by writing to the aforementioned registers via memory-mapped connections (e.g., created using memory-mapped switches).

[0053] The memory-mapped connections can be implemented by including one or more memory-mapped switches in each DPE 302. Each memory-mapped switch can include multiple memory-mapped interfaces. For example, each memory-mapped switch in a DPE 302 can include interfaces for connecting to memory-mapped switches in the DPE 302 above and below (or to tiles 310 below), and interfaces for connecting to circuit structures in the same DPE 302, such as cores 306, which include program memory, memory modules 308, and stream switches (for their configuration). The memory-mapped connections are used to communicate configuration, control, and debug data for the DPE array 102.

[0054] The DPE array 102 may be mapped into the address space of a processor system, such as the PS 106 or the PMC 110. Thus, any configuration registers and / or memory of the four configured memory modules in the DPE 302 or in the SoC interface block 304 may be accessed via a memory-mapped interface. For example, memory, program memory, and registers in memory module 308 may be read and / or written via a memory-mapped connection. Thus, using the memory-mapped connection, program code may be written to the cores 306, the DPE 302, data may be read or written to the memory module 308, streaming connections between the DPEs 302, etc.

[0055] The cores 306 may further communicate directly with adjacent cores 306 via core-core cascade connections. A core-core cascade connection is a unidirectional or bidirectional direct connection between cores, as depicted in FIG. 3. Each core 306 may include a cascade interface connected to an adjacent core, for example, as shown. The cascade interface may be connected to an internal storage register of the core 306 such that internal data within the core 306 loaded into the storage register may be transmitted (e.g., streamed) to another adjacent core 306. The core-core cascade connections may be programmed based on configuration data loaded into registers of the DPE 302. For example, based on the configuration data loaded into the registers, the input cascade interface and the output cascade interface of each core may be independently activated or deactivated on a core-by-core basis.

[0056] In an exemplary implementation, the DPE 302 does not include a cache memory. By omitting a cache memory, the DPE array 102 can achieve predictable, e.g., deterministic, performance. Furthermore, there is no need to maintain consistency between cache memories located in different DPEs, thus avoiding significant processing overhead. In a further example, the cores 306 of the DPE 302 do not have input interrupts. Thus, the cores 306 of the DPE 302 can operate uninterrupted. Omitting the input interrupts to the cores 306 of the DPE 302 also enables the DPE array 102 to achieve predictable, e.g., deterministic, performance.

[0057] The SoC interface block 304 includes multiple interconnected tiles 310 organized in a row. In particular embodiments, different architectures can be used to implement the tiles in the SoC interface block 304, with each different tile architecture supporting communication with a different type or combination of subsystems of the SoC 100. The tiles 310 are coupled such that data can be propagated bidirectionally from one tile to another. Each tile 310 can act as an interface for a row of DPEs 302 above.

[0058] For example, each tile 310 may receive data from other sources, such as the PS 106, the PL 104, and / or from another hardwired circuit block 112, e.g., an application-specific IC or "ASIC" block. A tile 310 may provide portions of data addressed to DPEs in an upper row to such DPEs 302 while transmitting data addressed to DPEs in other rows onto other tiles 310 so that such tiles may route the data addressed to DPEs 302 in their rows accordingly. In this manner, data may propagate from tile to tile in the SoC interface block 304 until it reaches a tile that acts as an interface for the DPE to which the data is addressed (e.g., a "target DPE"). The tile that acts as an interface for the target DPE may use the DPE's memory-mapped switch (e.g., for configuration) and / or the DPE's stream switch (e.g., for application data) to direct the data to the target DPE.

[0059] In one aspect, the SoC interface block 304 includes two different types of tiles 310. The first type of tiles 310 has an architecture configured to act as an interface between only the DPE 302 and the PL 104. The second type of tiles 310 has an architecture configured to act as an interface between the DPE 302 and the NoC 108 and between the DPE and the PL 104. The SoC interface block 304 may include a combination of tiles of the first and second types or tiles of only the second type.

[0060] A first type of tile 310 may include a PL interface and a stream switch connected to an upstream DPE 302. The PL interface connects to boundary logic interface (BLI) circuitry located in the PL 104. A second type of tile 310 includes a NoC and PL interface and a stream switch connected to an upstream DPE 302. The NoC and PL interface also connects to BLI circuitry in the PL 104, as well as one or more NMUs 202 and one or more NSUs 204 of the NoC 108.

[0061] The tiles 310 include stream switches and memory-mapped switches. The stream switches of adjacent tiles 310 are connected. The memory-mapped switches of adjacent tiles 310 are connected. As described, the stream switches establish streaming connections that convey application data, and the memory-mapped switches establish memory-mapped connections that convey configuration, control, and / or debug data. With respect to the DPE array 102, application data is data operated on by the cores 306. Configuration data is data used to program components of the DPE 302, such as the stream switches, the cores 306, and may include program code for the cores 306. The stream switches in each tile 310 are connected to the stream switches in the DPE 302 immediately above. Similarly, the memory-mapped switches in each tile 310 are connected to the memory-mapped switches in the DPE immediately above.

[0062] The DPE array 102 may be initially programmed as part of the boot process of the SoC 100. During run-time, the DPE array 102 may be reconfigured. Thus, the PMC 110 may initially configure the DPE array 102 to establish which DPEs 302 are connected to each other and / or to other subsystems or circuits, implement kernels in the DPEs 302, load program code, etc. At any point during run-time, the PMC 110 may reconfigure all or a portion of the DPE array 102 by establishing different connections between the DPEs 302 and / or with different subsystems or circuits, implement different kernels in the DPEs 302 to load different program code, etc.

[0063] The DPE array 102 can also generate various events. The events generated by the DPE array 102 may be routed globally to other subsystems of the SoC 100. For example, selected events generated by the DPE array 102 may be routed to the PMC 110 to indicate detected errors in the DPE array 102. In another example, selected events may be routed to the PMC 110 and / or the PS 106 and serviced as interrupts.

[0064] FIG. 4 illustrates an exemplary implementation of the PS 106 of FIG. 1. The PS 106 is implemented as a hardwired subsystem. In this example, the PS 106 includes multiple processors capable of executing program code and multiple peripherals. In one aspect, the PS 106 includes two separate power domains 456 and 458. Each power domain may be powered by a different power source. In this manner, the power domains 456 and 458 are powered by different power rails in the SoC 100 and may be powered on or off (or placed in a low power mode or hibernate mode) independently of the other power domains under the control of the PMC 110. For example, the power domain 456 may continue to operate using a real-time processing unit (RPU) while the power domain 458 including the application processing unit (APU) is powered off. Other power domains that may be included in the SoC 100 may be the PL 104 operating as an independent power domain, the DPE array 102 operating as another independent power domain, and the NoC 108 operating as yet another independent power domain.

[0065] The power domain 456 includes the RPUs 402 and 404. The RPUs 402 and 404 may each include a level 1 (L1) cache (not shown) and a tightly coupled memory (TCM) interface 414, 416, e.g., the TCM 414 corresponds to the RPU 402 and the TCM 416 corresponds to the RPU 404. In the example of FIG. 4, the power domain 456 includes various peripherals that allow external devices to communicate with the PS 106 via various industry standard protocols. For example, the power domain 456 includes one or more Gigabit Ethernet controllers (GbE) 420, one or more Controller Area Network (CAN) and / or CAN Flexible Data Rate (CAN-FD) controllers 422, one or more Universal Asynchronous Receiver-Transmitter Controllers (424), one or more I2C controllers 426, a serial peripheral interface (SPI) 428, and / or a watchdog timer and triple timer counter (TTC) 430. Power domain 456 may include additional circuit blocks, such as a direct memory access engine (DMA) 440, a clock and reset circuit (Clk / Rst) 442, a PS (processing system) manager 444, a CoreSight™ controller 446, and / or an interconnect 452. CoreSight™ controller 446 is a hardwired core or intellectual property (IP) configured to provide debug and / or trace capabilities for PS 106 (e.g., any of the processors contained therein).

[0066] 4, PS 106 may include an error aggregation module (EAM) 460. EAM 460 may receive and aggregate errors from other programmable resources (e.g., subsystems) in SoC 100. In one aspect, EAM 460 may aggregate received errors, generate summary error events, and provide the summary error events to PMC 110. EAM 460 may be programmed, for example, by PMC 110, to generate particular summary error events, e.g., interrupts, to PMC 110 in response to particular received errors and / or combinations of errors. PMC 110 may process the errors in response to the events generated by EAM 460. In another aspect, the processors of PS106 (e.g., RPU402, RPU404, APU406, APU408) can interrupt each other and / or PMC110 by an interrupt circuit (not shown) referred to as an inter-processor interrupt mechanism (IPI), which may be utilized for error management purposes and coupled to EAM460.

[0067] The power domain 458 includes the APUs 406, 408, 410, and 412. Each of the APUs 406, 408, 410, and 412 may include an L1 cache (not shown). Additionally, the APUs 406, 408, 410, and 412 may share a level 2 (L2) cache 418. The power domain 458 includes various peripherals that allow external devices to communicate with the PS 106 via various industry standard protocols. For example, the power domain 458 may include peripherals such as, for example, one or more Universal Serial Bus (USB) controllers 432, one or more Serial AT Attachment (SATA) controllers 434, one or more Peripheral Component Interconnect Express (PCIe) controllers 436, one or more DisplayPort (DP) controllers 438, and the like. The power domain 458 may include one or more GPUs 448, a serializer / deserializer (SerDes) circuit 450, and / or a coherency interconnect 454. The interconnects 452 and 454 can establish connections between each of the circuit blocks shown in FIG.

[0068] Figure 4 is provided for purposes of illustration and not limitation. PS 106 may include other circuit blocks not shown in Figure 4. Examples of such circuit blocks include, but are not limited to, one or more interrupt request units (IRQs) and snoop control units (SCUs).

[0069] In another aspect, the PCIe 436 may be included in a separate subsystem called a coherent PCIe module or "CPM." The CPM may be implemented external to the PS 106. In one aspect, the CPM includes one or more PCIe endpoints. The CPM may also include interfaces that directly connect the PCIe endpoints therein with gigabit transceivers (GTs) of the SoC 100, the PL 104, and / or the PS 106.

[0070] FIG. 5 illustrates another exemplary implementation of the SoC 100 of FIG. 1. FIG. 5 illustrates a logic diagram of various components and / or subsystems of the SoC 100. In the example of FIG. 5, the SoC 100 includes the DPE array 102, the PL 104, the PS 106, and a system interconnect 502. The system interconnect 502 includes, for illustrative purposes, the NoC 108, the CFI 114, and the NPI 210. The SoC 100 further includes the PMC 110, one or more memory interfaces 504, 506 (e.g., hardwired circuit blocks), a video codec unit (VCU) 508 (e.g., hardwired circuit blocks), and an I / O subsystem 510.

[0071] 5, each of the depicted subsystems is connected to a system interconnect 502. For example, the DPE array 102, the PL 104, the PS 106, the PMC 110, the memory interfaces 504 and 506, the VCU 508, and / or the I / O subsystem 510 are connected to the system interconnect 502. In one aspect, the PMC 110 can program (e.g., configure) the DPE array 102, the PL 104, the PS 106, the memory interfaces 504 and 506, the VCU 508, and the I / O subsystem 510 via the system interconnect 502.

[0072] The PMC 110 operates as the root of trust for the SoC 100. In one aspect, the PMC 110 includes one or more processors capable of executing program code. The PMC 110 may include additional resources such as control circuitry, memory, and one or more interfaces. The PMC 110 may perform various security and safety functions within the SoC 100. For example, the PMC 110 may boot the SoC 100, configure the DPE array 102, configure the PL 104, configure the PS 106, configure the NoC 108, and / or perform partial reconfiguration of various subsystems of the SoC 100 through the system interconnect 502. For example, with respect to the NoC 108, the PMC 110 may configure the NoC 108 initially and configure the DPE array 102 with data paths formed in the NoC 108 from the initial configuration upon initial configuration of the NoC 108. The PMC 110 may write to control registers to set various functions and configurations of the SoC 100 across the chip.

[0073] Memory interface 504 includes one or more configurable DDR controllers 512, a physical interface (PHY) 514, and configurable I / O 516. Memory interface 506 includes one or more configurable high bandwidth memory (HBM) controllers 518, a physical interface (PHY) 520, and configurable I / O 522. VCU 508 is connected to system interconnect 502 and can perform a variety of different video encoding, decoding, and / or processing operations.

[0074] The I / O subsystem 510 may include one or more additional hard blocks 524, one or more user-defined I / O interfaces 526 implemented using the PL 104, and a GT and I / O 528. Examples of such additional hard blocks may include, but are not limited to, a configurable forward error correction block, a configurable encryption block, and a configurable analog mixed signal block (e.g., including one or more configurable DACs and / or ADCs). It should be understood that the SoC 100 may include fewer or more hardwired circuit blocks than shown in FIG. 5.

[0075] For illustrative purposes, a simplified version of the PS 106 is shown in FIG. 5. In the example of FIG. 5, the power domains are not shown in the PS 106. The PS 106 includes one or more RPUs 402, 404, one or more APUs 406, 408, 410, 412, and one or more GPUs 448. The PS 106 may further include a PS memory 530, which may represent a level 2 cache, an on-chip memory (OCM), and a system memory management unit (SMMU). The PS 106 may further include one or more interconnects 532 and one or more peripherals 534. The interconnect 532 may include a coherent interconnect and snoop control unit (SCU) that allows other masters to read and / or write to the level 2 cache memory and / or the OCM. For example, the RPUs 402, 404 and master circuit blocks in the PL 104 may snoop the level 2 cache memory. The peripherals 534 may include one or more different I / O controllers, as previously described. The PS manager 444 may control the operation of the components within the PS 106, including, for example, powering on or off power domains within the PS. In one aspect, the PS manager 444 may perform operations in response to instructions from the PMC 110. In the example of FIG. 5, the PMC 110 may communicate with the PS 106 via the system interconnect 502. Additionally, the PMC 110 may be directly connected to the PS 106 via a separate or different direct connection.

[0076] The PL 104 may include a lookup table (LUT) 536, a BRAM 538, an UltraRAM (URAM) 540, and a DSP 542, interconnected by the fabric interconnect, as previously described. The PL 104 is connected to the system interconnect 502 and the fabric interconnect. The DPE array 102 may include multiple interconnected hardwired and programmable DPEs 302. The DPEs 302 connect to the system interconnect 502 and the fabric interconnect via the SoC interface block 304.

[0077] 5, NoC 108 may also be connected or coupled to other NoCs located on other dies and / or ICs. For example, if SoC 100 is formed from multiple dies interconnected via interposers or other carriers, NoC 108 may be coupled to NoCs of other dies via interposers or carriers.

[0078] 6 illustrates an exemplary implementation of PMC 110. PMC 110 is a hardwired circuit block on SoC 100. In the example of FIG. 6, PMC 110 includes a PMC processing unit 602 (separate and distinct from PS 106). PMC processing unit 602 may include a physical unclonable function (PUF) 604, one or more ROMs 606, one or more RAMs 608, one or more timers 610, one or more processors 612, and local registers 614. In an exemplary implementation, PMC 110 is on a separate power domain (e.g., has a separate, independent power supply) independent of PL 104, DPE array 102, and / or PS 106.

[0079] In one aspect, the processors 612 of the PMC processing unit 602 can operate in lockstep using appropriate voting circuitry. In another aspect, a first subset of the processors 612 that can operate in lockstep is dedicated to accessing the ROM 606 (e.g., executing code stored in the ROM 606) and a second subset of the processors 612 that can operate in lockstep is dedicated to accessing the RAM 608 (e.g., executing code stored in the ROM 608). The first subset of the processors 612 may be mutually exclusive with the second subset of the processors 612.

[0080] For example, one or more processors 612 are dedicated to executing code stored in ROM 606. The ROM-only processors 612 corresponding to a first subset of processors 612 are the first processors of SoC 100 that are active through reset during boot of SoC 100. In executing code stored in ROM 606, the ROM-only processors 612 may perform operations such as device initialization, boot interface verification, releasing additional processors 612 of PMC 110 from reset, etc. At the same time , load the PMC platform loader and manager into RAM 608 can The ROM-only processors 612 may also perform secure boot, post-boot security monitoring, and PUF management. A second subset of the processors 612, the RAM-only processors 612, may execute code stored in the RAM 608 when released from reset.

[0081] The ROM 606 and the RAM 608 are accessible only by the processor 612. In another embodiment, each processor 612 has a ROM 606 and a RAM 608, and each processor 612 has an independent dedicated ROM 606 and an independent dedicated RAM 608. The RAM 608 may be protected by an error correction coding (ECC) circuit. The processor 612 may be used to power up and configure the SoC 100 by executing code stored in the ROM 606 and firmware loaded into the RAM 608 from a primary boot device by executing code stored in the ROM 606. The local registers 614 are configuration registers for the PMC processing unit 602 and may be accessed only by the PMC processing unit 602.

[0082] One aspect of having the PMC 110 operate as the root of trust for the SoC 100 is to load firmware into the RAM 608 using code stored in the ROM 606. The ROM-only processor 612, upon executing code from the ROM 606, can authenticate any firmware loaded into the SoC 100 to be executed by the RAM-only processor 612, and / or authenticate any PDI loaded into the SoC 100 prior to execution and / or use of such firmware or image by subsystems of the SoC 100 other than the PMC 110. Thus, any PDI used to configure and / or program any portion of the SoC 100 can first be authenticated by the PMC 110.

[0083] In another aspect, the PMC 110 may perform operations such as zeroizing a particular subsystem or portion of the SoC 100 that the PMC 110 is configuring. Thus, the PMC 110 may erase any and / or all of the previous data stored in the portion of the SoC 100 being reconfigured as part of the configuration. For example, a ROM-only processor may zeroize PMC components and / or boot devices (e.g., platform loader and manager or "PLM") through which data is loaded into the SoC 100 in response to a particular condition or event. A RAM-only processor may zeroize other resources within the SoC 100 external to the PMC 110 by executing firmware in response to a particular condition or event.

[0084] After booting, processor 612 can perform a variety of different functions using various components included in PMC 110. For example, processor 612 can perform power management, voltage and temperature monitoring, safety and security event response, etc. for SoC 100. As shown, PMC processing units 602, such as processor 612, can receive interrupt and wake signals, which can include signals originating from outside SoC 100 and / or signals originating from within SoC 100, and indicate particular power domains and / or islands that should be powered on and / or off for these purposes.

[0085] The PMC processing unit 602 is connected to an interconnect 616. The PMC processing unit 602 can communicate with the PMC 110 and other components in the SoC 100 through the interconnect 616. The interconnect 616 can include multiple memory mapped switches and interfaces and multiple stream switches and interfaces. The interconnect 616 is connected to a PMC shared RAM 618, a global register 620, an I / O controller 622, DMAs 624 and 626, a secure stream switch 628, a slave boot interface (SBI) 630, a security accelerator 632, an analog system 634, a real-time clock (RTC) 636, a power management and reset 638, an error management circuit 640, a debug packet controller 642, and a configuration frame unit (CFU) 644.

[0086] The PMC shared RAM 618 may be used to store configuration data (e.g., PDI) and / or other data for the SoC 100 during processing and as a general purpose data processing RAM for the PMC 110. The global registers 620 are configuration registers accessible by any (e.g., all) masters in the PMC 110. The global registers 620 may include general purpose power control registers, error management registers, and a service interrupt request interface. The I / O controller 622 may include one or more I / Os coupled to a multiplexed input / output (MIO) 668. As shown, the MIO 668 further connects to the SelectMap 670, the PS 106, and the PL 104. The MIO 668 may selectively connect I / O signals to the SelectMap 670, the PS 106, the PL 104, and / or the I / O controller 622. Examples of the I / O controller 622 include I2C, as well as SPI and / or SD / eMMC (secure digital audio and video). l / embedded MultiMediaCard) and one or more flash interfaces, such as a USB interface.

[0087] MIO 668 provides connectivity to I / O pins of SoC 100 that can provide a number of different functions depending on the configuration. For example, MIO 668 may be configured to connect signals to SelectMap 670 for configuration or to an I / O controller 622, such as a flash memory controller and / or a USB interface.

[0088] DMA 624 and 626 are used to transfer data within PMC 110 for configuration of SoC 100 and processing of configuration data. Secure stream switch 628 ensures that the data stream provided to security accelerator 632 for processing is secure. SBI 630 facilitates slave boot and / or configuration in a multi-die SoC configuration. Although not shown, SBI 630 may be connected to SelectMap 670 and NoC 108.

[0089] The security accelerator 632 may include an encryption / decryption block 646 that may perform encryption and / or decryption, an authentication block 648 that may perform authentication, and a hash block 650 that may generate a hash on received data. In one example, the encryption / decryption block 646 is a symmetric key encryption engine that may perform the Advanced Encryption Standard (AES) using Galois Counter Mode (GCM) (AES-GCM). In one example, the authentication block 648 may perform public key cryptography. For example, the authentication block 648 may implement the Elliptic Curve Digital Signature Algorithm and / or the Rivest-Shamir-Adleman. The hash block 650 may perform a secure hash operation 3 / 394. The security accelerator 632 may also include a true random number generator (TRNG) circuit 652 and a battery backed RAM (BBRAM) 654 circuit block that may generate random numbers. The particular circuit blocks included in the security accelerator 632 are provided for purposes of illustration and not limitation. In one aspect, the security accelerator 632Only blocks 646 , 648 and 650 are accessible only through secure stream switch 628 , while blocks 652 and 654 are accessible by interconnect 616 .

[0090] The analog system 634 may include a system monitor 656 capable of monitoring voltages and temperatures from one or more remote system monitor circuits, which may be located at various locations around the SoC 100 and / or in various subsystems; a system oscillator 658 capable of generating clock signals for the PMC 110; an e-fuse controller 660 capable of maintaining and / or managing the e-fuse circuitry on the SoC 100; a bandgap circuit 662 capable of generating one or more reference voltages for analog devices in the SoC 100, such as DACs and / or ADCs, which may be implemented on the SoC 100 as hardwired and programmable circuit blocks; one or more phase-locked loops (PLLs) 664 capable of generating clock signals for the PMC 110, the NoC 108, the NPI 210, and the PS 106; and a power-on reset (POR) circuit 666.

[0091] POR circuit 666 can sense voltages within SoC 100 and signal (e.g., release) a power-on reset. In response to POR circuit 666 signaling a power-on reset, power management and reset 638 can include control logic that can perform zeroization (e.g., writing zeros) to all memory in PMC 110, except for ROM 606, and each of the other subsystems of SoC 100, for security purposes.

[0092] An e-fuse controller 660 can read the e-fuse circuits. The e-fuse circuits (e.g., e-fuse memory elements) may be used to store design information such as device DNA and / or security keys. The e-fuse circuits can further control functions such as disabling the Joint Test Action Group (JTAG) 672.

[0093] The RTC 636 is a clock circuit that can operate with a highly accurate crystal oscillator. The RTC 636 can be used to measure the current time and generate alarms at specific times for various operating system and device management functions within the SoC 100. The power management and reset circuit 638 implements the necessary logic and interfaces to control the power islands, power domains, and resets to other circuit blocks on the SoC 100. The power management and reset circuit 638 further connects to the PS 106 to control the domains and islands implemented in the PS 106.

[0094] Error management circuitry 640 can receive, record, and respond to errors from other subsystems in SoC 100. For example, error management circuitry 640 can capture errors from throughout SoC 100. Error management circuitry 640 may be programmed by PMC 110 to generate specific events, e.g., interrupts, of PMC 110 in response to specific received errors and / or combinations of errors. PMC 110, e.g., processor 612, can process the errors in response to the events generated by error management circuitry 640.

[0095] In one aspect, the error management circuit 640 may be programmed to send a signal via an I / O pin from the SoC 100 to a circuit external to the SoC 100 (e.g., a circuit located on the circuit board on which the SoC 100 is located) indicating the occurrence of an error. In another aspect, the error management circuit 640 may be programmed to trigger a power-on reset in response to a specific error, or a system reset in response to other specific errors. This function maintains the secure state of the SoC 100. In the case of a system reset, the PMC 110 can reset a specific circuit block or subsystem within the SoC 100 without changing the security context already programmed. In the case of a system reset, no zeroization is performed on the subsystem, which results in faster recovery.

[0096] The debug packet controller 642 is a packet controller for the high speed debug port (HSDP) that processes packets passed from other interfaces on the SoC 100, such as high speed serial interfaces, other debug circuits in other subsystems, and / or PCIe blocks (e.g., in the PS 106 or in the CPM). In one example, the debug packet controller 642 can operate at speeds of over 10 Gbps. The debug packet controller 642 can be accessed, for example, by a specific transceiver (high speed), JTAG 672, or PCIe 436 in the PS 106. The debug packet controller can further access the debug circuits of the PS 106 (e.g., CoreSight 446) and / or other subsystems. Thus, the PMC processing unit 602 provides centralized access to the debug data of the SoC 100. Providing centralized access to the debug data is another aspect of the PMC 110 acting as a root of trust for the SoC 100.

[0097] In one aspect, the debug packet controller 642 has two connections to the CoreSight™ controller 446. The first connection supports debug operations. Debug operations may include reading registers, memory, moving data from one register and / or memory to another, and / or writing data to registers and / or memories. These operations may be performed on any such locations accessible via the debug packet controller 642 and may be performed using the CoreSight™ controller 446, at least in the PS 106. The second connection supports trace operations. Trace operations involve capturing the state of the processor or processor system as program code executes at each clock cycle and require significant bandwidth beyond the capabilities of the JTAG 672. JTAG is a slow serial connection. Thus, with high speed access to the SoC 100 via the debug packet controller 642 and the internal connection to the CoreSight™ controller 446, it is possible to use the trace functionality in the PS 106.

[0098] The debug packet controller 642 may, for example, decode packets received from the host and execute commands contained therein. The commands may indicate where to read or write data (e.g., a particular destination such as the CoreSight™ controller 446, other debug circuitry, the interconnect 616, and / or other memory or registers in a particular subsystem accessible by the interconnect 616). In general, the debug packet controller 642 may read and / or write memory-mapped memory and / or circuit structures in the SoC 100, either in the DPE array 102, the PL 104, the PS 106, or the NoC 108.

[0099] Thus, in one aspect, the debug packet controller 642 may be used to debug the PL 104. In one example, an integrated logic analyzer may be implemented in the PL 104 with a user circuit design. The integrated logic analyzer may capture signals from buses, registers, etc. of the user circuit design each clock cycle. The debug packet controller 642 may be connected to the integrated logic analyzer to receive debug data from the integrated logic analyzer. Thus, the integrated logic analyzer may be read quickly from the host system via the debug packet controller 642 as opposed to using other slower mechanisms such as boundary scan.

[0100] In another aspect, the debug packet controller 642 can perform a readback of flip-flops in the PL 104. The debug packet controller 642 can read any configuration or status data from the PL 104, for example, via the CFU 644. The debug packet controller 642 can perform the readback at a much faster rate than using other mechanisms such as boundary scan. Unlike using an integrated logic analyzer, the readback does not consume resources of the PL 104 that would otherwise be available for use in the user circuit design.

[0101] The debug data captured by the debug packet controller 642 may be output as a packetized data stream to the host via a high-speed connection. In one aspect, the debug packet controller 642 is connected to a high-speed interface implemented in the PS 106 connected to one or more GTs of the SoC 100 that allows for a high-speed connection to the host system (not shown in FIG. 4). This connection requires that the PS 106 is powered on and that the PL 104, which contains the GTs, is also powered on. In another aspect, the debug packet controller 642 can access the MIO 668 via the interconnect 616.

[0102] In another example, the debug packet controller 642 may be connected to a host system via the JTAG 672. Although the JTAG 672 is a low-speed interface, such a connection does not depend on other subsystems of the SoC 100, such as the PL 104 and / or the PS 106. Furthermore, while using the JTAG 672, a single packet provided to the debug packet controller 642 may be used to initiate multiple operations. For example, repetition may be specified by the packet so that the debug packet controller 642 may perform more complex operations, such as initializing a RAM (where multiple operations, such as writing, are performed in response to a single packet), in response to a packet received via the JTAG 672. In another example, the packet may express a conditionality to be implemented by the debug packet controller 642.

[0103] In another example, when the SoC 100 is deployed and not accessed by physically connecting a cable for debug (e.g., a data center application), the debug packet controller 642 may be accessed by the PCIe 436 (whether in the PS 106 or implemented as a CPM as described in connection with FIG. 4). In yet another example, the debug packet controller 642 may be connected via the PL 104. For example, circuits such as an Ethernet controller or a USB controller may be implemented in the PL 104 that may be connected to the debug packet controller 642.

[0104] In another aspect, the debug packet controller 642 can configure the PL 104 directly via the CFU 644. In another aspect, the debug packet controller 642 can configure the PL 104, the PS 106, the DPE array 102, or any other portion of the SoC 100 by receiving data that the debug packet controller 642 writes to the SBI 630. The write to the SBI 630 generates an interrupt to the PMC processing unit 602. The PMC processing unit 602 can then authenticate the data and then begin a process to configure the SoC 100 using the received data under control of firmware executing in the PMC processing unit 602.

[0105] Configuration of SoC 100 may be initiated by Debug Packet Controller 642 writing to SBI 630, by JTAG 672 writing to SBI 630, by PCIe receiving data written to SBI 630, or by writing to SelectMap 670 (using a process similar to that described in connection with SBI 630). In these examples, PMC 110 acts as a slave. When PMC 110 acts as a master, it is retrieving configuration data for SoC 100 from a specific location, such as external flash, external RAM, USB, etc.

[0106] Including the debug packet controller 642 within the PMC 110 provides several advantages. In one aspect, the PMC 110 is always powered on, thereby ensuring that debug is available even though other subsystems may be powered off. For example, some designs may not use the PS 106 or the PL 104. In such cases, debug functionality is still available for the SoC 100. Furthermore, the PMC 110 can provide secure access to the debug packet controller 642 by selectively enabling the debug packet controller 642. For example, the PMC processing unit 602 may not enable the debug packet controller 642 until the SoC 100 is operational and the device image loaded into the (authenticated) SoC 100 indicates that the debug packet controller 642 should be activated.

[0107] In another aspect, the debug packet controller 642 may be isolated from peripheral circuitry within the PMC 110 by one or more security gates operating under the control of the PMC processing unit 602. The PMC processing unit 602 must enable the security gates, e.g., control the gates to allow signals to pass, in order to use the debug packet controller 642. Otherwise, the debug packet controller 642 remains isolated and unreachable.

[0108] CFU 644 can perform configuration and readback of configuration data provided or loaded into configuration registers of PL 104. PMC 110, for example, transfers the PL bitstream (e.g., configuration data) through CFU 644 to configure PL 104.

[0109] SoC 100 may be implemented to include multiple power domains controlled by power management and reset circuitry 638 under control of PMC processing unit 602. The power domains include a low power domain in PS 106 including the RPU and OCM, a full power domain in PS 106 including the APU and high speed I / O, an NoC 108 and system dual data rate (DDR) power domain, and a PL 104 power domain.

[0110] Other power domains may be created within SoC 100 that SoC 100 can control through circuit boards located under the control of PMC 110. These other power domains may include, but are not limited to, additional I / O power domains, a battery power domain, a PMC power domain (e.g., if the PMC has its own power domain and power supply), a PL RAM power domain, and a DPE array power domain.

[0111] In one aspect, SoC 100 includes multiple banks of I / O. JTAG 672 can be connected to one bank of I / O (not shown in FIG. 6). These I / O may be fixed. A power-on reset signal, an error signal output to the circuit board on which SoC 100 is located, and a reference clock received by SoC 100 may also be part of the fixed I / O set.

[0112] The secure stream switch 628 may be used to stream configuration information, such as an image, to the SoC 100. For example, an image (e.g., PDI) may be pushed to the SelectMap 670 via the MIO 668. The image may also be received via the JTAG 672. In either case, the image is pushed to the SBI 630, which may generate an interrupt to the PMC processing unit 602. The PMC processing unit 602 may configure the DMA 624, 626 to perform the data transfer. The DMA 624, 626 operating via the secure stream switch 628 may unload a buffer included in the SBI 630 and store the data in the PMC shared RAM 618 for further processing. The PMC processing unit 602 may further push data to the CFI via the CFU 644 to configure the PL 104 or another interface to configure the DPE array 102 and / or the PS 106.

[0113] In one aspect, the secure stream switch 628 can implement a crossbar function. For example, the PMC processing unit 602 may execute firmware that configures the secure stream switch 628 (e.g., connects selected ports of the secure stream switch 628). The PMC processing unit 602 can also configure the DMAs 624, 626 to implement data transfer using the secure stream switch 628. Once configuration data is received, the DMAs 624, 626 can place such data in the PMC shared RAM 618 via the secure stream switch 628. At the same time, the DMAs 624, 626 can direct data from the PMC shared RAM 618 through the secure stream switch 628 to the security accelerator 632 for processing (e.g., authentication).

[0114] In another aspect, the secure stream switch 628 may be configured by the PMC processing unit 602 to perform a broadcast function. In that case, data received at one port of the secure stream switch 628 may be broadcast (e.g., sent simultaneously) to two or more different ports of the secure stream switch 628, and thus to two or more different destinations at the same time. In yet another aspect, the secure stream switch 628 may be used to perform memory copies. The DMA 624 and / or 626 may be configured to read from a particular memory location and provide the data read from memory to the secure stream switch 628. The secure stream switch 628 may be configured to output data to another port also connected to the DMA 624 and / or 626 to write the data to a particular destination memory location.

[0115] The PMC 110 can control the powering on and / or powering off of any of the different power domains implemented in the SoC 100. The powering on and / or powering off of any power domain can be controlled by the PMC 110 in response to any of a variety of different events received by the PMC 110. In this regard, the PMC 110 can respond to any of a variety of different events that can be interpreted, for example by executed firmware, as a wake event that powers on a particular power domain or domains. Examples of events that are interpreted as wake events can include, but are not limited to, a selected interrupt received by the PMC 110, an I / O event that references a signal received from an external source via an I / O of the SoC 100, an event generated by the RTC 636, a software initiated wake, a wake by any peripheral IP event, or a debugger initiated wake.

[0116] The term "wake by software" refers to a subsystem, such as the APU, that is powered down. Software running in another subsystem, for example the RPU, can issue a request to the PMC 110 to power up the APU subsystem. The term "wake by debugger" refers specifically to a request from a debugger, for example CoreSight 446 of the PS 106. The request, which is a request to power up a power domain, may be initiated by a register in the debugger. Subsystems such as the PS 106, PMC 110, and / or CPM include debug circuitry that is part of an overall debug system in the SoC 100. The debugger may request any one or more of these subsystems to power up. The request is generated by the debugger writing to a dedicated register that generates an interrupt to the PMC 110 or PS 106 to power up the requested power domain or power island. In general, the debugger may be accessed by debug software via the packet controller 642.

[0117] In another example, the PMC 110 may be implemented in a power mode referred to as "power down mode USB" and the SoC 100 may be powered on and / or powered off via USB. For example, the MIO 668 may be connected to a USB interface external to the SoC 100. The MIO 668 may connect a USB signal to the I / O controller 622. In this manner, the PMC 110 may remain powered on and monitor for a wake signal received via USB. In this example, the PS 106, which may include a USB controller not included in the PMC 110, is powered off since the PMC 110 is monitoring for a wake signal via USB. Powering on the PMC 110 allows the USB interface to remain active using the I / O controller 622 to at least monitor for a wake signal received via USB while the USB controller implemented in the PS 106 is powered off. The PMC 110 does not need to provide full USB functionality. Rather, in this example, the PMC 110 only needs to detect a specific signal, e.g., a wake signal, via USB. Because the PMC 110 is on an entirely different power rail than the PS 106, the PMC 110 can detect the wake signal through the USB interface. In response to receiving the wake signal, the PMC 110 can perform wake processing to power on the PS 106 and / or any other subsystems of the SoC 100. Additionally, the PMC 110 can restore the USB interface to full functionality by waking up the power domain and / or power island of the PS 106, including the USB controller connected to the MIO 668.

[0118] In the above example, USB was used for illustrative purposes. In other examples, MIO 668 may be connected to other external interfaces and / or devices. I / O controller 622 may be configured to detect a specific wake signal through such an interface and / or from such a device while powered off, where the actual controller used for the interface is located elsewhere in SoC 100, outside of PMC 110. In response to detecting the wake signal, PMC 110 may wake up the specific power domain in which the actual controller is located.

[0119] FIGURE 7 illustrates an exemplary redundant implementation of processors in PMC 110. In the example of FIGURE 7, processors 612 are arranged in a redundant architecture. More specifically, FIGURE 7 illustrates a triple redundant architecture. In one exemplary implementation, processor 612 is implemented as a hardwired Microblaze processor, although other types of processors may be used.

[0120] Each processor 612 is connected to a triple modulo redundancy (TMR) manager 702 and an I / O module 704. The TMR managers 702-1, 702-2, and 702-3 are interconnected. The I / O modules 704-1, 704-2, and 704-3 are also interconnected. A voting circuit 710-1 is coupled to each of the I / O modules 704. Each I / O module 704 may include an interrupt controller, a timer, a general purpose I / O (GPIO), and / or a universal asynchronous receiver-transmitter (UART). Each TMR manager 702 may manage the state of each of the processors 612, including fault detection and error recovery.

[0121] Each voting circuit 710 can compare the input signals it receives. Each voting circuit 710 can detect a mismatch in the received signals, accept the majority result, and continue to operate. The particular processor 612 that provides a mismatch (e.g., a result is lost) is reset, and the remaining two processors 612 continue to operate in lockstep. If all three processors 612 are in mismatch, each processor 612 is reset.

[0122] In the example of FIG. 7, each processor 612 is connected to a RAM control circuit 706 and a RAM control circuit 708. The RAM control circuit 706 is connected to a voting circuit 710, which is connected to an instruction RAM, e.g., RAM 608. The RAM control circuit 708 is connected to a voting circuit 710-5, which is connected to a data RAM, e.g., RAM 608. As shown, the RAM 608 and the voting circuits 710-4 and 710-5 are part of the ECC domain. In the example of FIG. 7, each RAM control circuit 706 (e.g., 706-1, 706-2, and 706-3) for the instruction RAM is connected to a voting circuit 710-3. Each of the processors 612-1, 612-2, and 612-3 is connected to a voter circuit 710-2. A control interface, such as an Advanced eXtensible Interface (AXI) 4-Lite or other suitable control interface, is connected to each of the processors 612-1, 612-2, and 612-3.

[0123] 7 illustrates an example of triple modular redundancy where processor 612 is dedicated to accessing RAM 608. Here, FIG. 7 illustrates an example of a RAM-only processor 612. As previously mentioned, a similar architecture may be used for a ROM-only processor in PMC 110. In another example, fewer than three processors 612 may be used, with one or two processors 612 (in lockstep) dedicated to executing code stored in ROM 606 and one or two other processors 612 (in lockstep) dedicated to executing firmware stored in RAM 608.

[0124] PMC 110 is the root of trust within SoC 100. PMC 110 can create a chain of trust by ensuring that any external code / data loaded by PMC 110 to configure any portion of SoC 100 is authenticated and decrypted (as needed). For example, PMC 110 can perform authentication using authentication block 648 and / or hash block 650 and decryption using encryption / decryption block 646. In general, once the configuration data has been authenticated and decrypted by PMC 110, PMC 110 can load the configuration data into the appropriate configuration registers of the appropriate subsystems and / or circuit blocks of SoC 100.

[0125] FIG. 8 illustrates further structural and functional aspects of SoC 100. In the example of FIG. 8, SoC 100 includes various additional circuits that can implement security functions. These additional circuits can be used to create different independent partitions within SoC 100 and implement firewalls between different partitions. Each partition can run its own application therein. In the example of FIG. 8, multiple system management identifier (SMID) circuits 802 and a programmable protection circuit (PPC) 818 are included.

[0126] The processor 612, RPU 402, APU 406, other masters 808, and I / O devices 812 are connected to a local interconnect 816 via SMID circuitry 802. The I / O devices 812 are further connected to the local interconnect 816 via an SMMU 814. The local interconnect 816 is connected to the NoC 108. The PL 104 and / or DPE array 102 are connected to the NoC 108. The RPU 402 includes a memory management unit (MMU) 804-1 and a cache 806. The APU 406 includes an MMU 804-2 and a cache 810.

[0127] Each SMID circuit 802 is programmable to use a particular SMID. During configuration, PMC 110, e.g., processor 612, can assign and write a SMID to the configuration registers of the various SMID circuits 802 being used, or at least each of those SMID circuits 802. The SMID circuit 802 of each of the various components, e.g., processor 612, RPU 402, APU 406, other masters 808, I / O devices 812, PL 104, and / or DPE array 102, can attach or insert a SMID to transactions initiated by the respective component. Thus, each transaction originating from processor 612 includes a SMID in the transaction, e.g., inserted by SMID circuit 802-2 assigned by PMC 110. Similarly, each transaction originating from RPU 402 has a SMID inserted by SMID circuit 802-2 assigned by PMC 110. In this manner, the source of a transaction from various components in SoC 100 can be identified by the particular SMID in the transaction. The SMID assigned to the SMID circuit 802 may be unique across the SoC 100.

[0128] The PPCs 818 can protect access to slave circuits in the SoC 100. Each of the PPCs 818 can check the specific SMID of each transaction that enters a circuit block. Each PPC 818 can check whether the SMID of the transaction is an authorized SMID, for example, on a list of authorized SMIDs maintained by the respective PPC 818. Each PPC 818 can also check that the address or address range accessed by the transaction is an address range that the SMID is authorized to access. In this regard, the PPCs 818 can enforce access privileges by ensuring that only authorized circuit blocks (based on the SMID) can access other circuit blocks, and further, that a particular SMID can only access address ranges that it is authorized to access.

[0129] In one aspect, the PPC 818 includes a first type of circuitry configured to protect configuration registers of a circuit block. Such a PPC 818 can allow only authorized SMIDs to access the configuration registers, and can only allow certain configuration registers with addresses specified on a list of authorized addresses for each authorized SMID. Examples of such PPCs 818 include, but are not limited to, PPCs 818-1, 818-2, 818-3, and 818-5. These PPCs 818 provide fine-grained protection. The PPC 818 can also include a second type configured to protect memory. The second type of PPC 818 provides memory protection and isolation. Examples of such PPCs 818 include, but are not limited to, 818-4 and 818-6.

[0130] The SMID circuit 802 and the PPC 818 are configured by the PMC 110. For example, the PMC 110 may write to configuration registers in each SMID circuit 802 and each PPC 818 used by a given design (e.g., for each PDI loaded into the SoC 100). The PMC 110, for example, assigns SMIDs to various circuit components of the SoC 100 and configures the SMID circuit 802 accordingly. The PMC 110 further writes to the configuration registers of the PPC 818 a list of permitted SMIDs and / or permitted addresses and / or address ranges that each SMID is permitted to access. These operations may create two or more partitions of the SoC 100 that are at least partially isolated from one another.

[0131] In this regard, PPC 818-1 can allow only authorized transactions from authorized sources to access PMC slave 820. PPC 818-2 can allow only authorized transactions from authorized sources to access NPI 210. PPC 818-3 can allow only authorized transactions from authorized sources to access RPU slave 822. PPC 818-4 can allow only authorized transactions from authorized sources to access OCM 530. PPC 818-5 can allow only authorized transactions from authorized sources to access APU slave 826. PPC 818-6 can allow only authorized transactions from authorized sources to access DDR memory controller 512.

[0132] In the example of FIG. 8, specific locations of the SMID circuitry 802 and PPC 818 are shown for illustrative purposes. The SMID circuitry 802 and PPC 818 may be implemented within a circuit block as part of an interface, within a signal path between circuit blocks, etc. The SMID circuitry 802 and PPC 818 may be implemented in different physical locations that provide logical equivalence. For example, multiple blocks may have an aggregated repeater that couples to a global path such as the NoC 108. In that case, the aggregated repeater may include the SMID circuitry 802 and / or the PPC 818 rather than each of the individual circuit blocks being aggregated via a repeater. This may be true for both entry and exit points of the NoC 108.

[0133] In the example of Figure 8, local interconnect 816 may represent one physical circuit block that may merge multiple logic functions. In another example, NoC 108 may be implemented to include one or more SMID join points. In other words, SMID circuits 802 (e.g., 802-6 and 802-7) may be implemented in NoC 108 (e.g., as SMID circuits 802-8 and 802-9) rather than in PL 104 and / or DPE array 102. SMID circuits 802 may be implemented in NoC 108 at entry points, exit points, or a combination of entry and exit points.

[0134] In the example of Figure 8, the various connections to the local interconnect 816 enter and exit the NoC 108 through one gateway. Each port of the NoC 108 can receive transactions from one logical source or from multiple logical sources. Similarly, each port of the NoC 108 can receive transactions from one physical source or from multiple physical sources. A physical source can be a circuit block within a particular subsystem, but different physical sources are different circuit blocks in different subsystems.

[0135] For example, processor 612, RPU 402, and APU 406 each have a SMID circuit 802. Each of processor 612, RPU 402, and APU 406 can initiate a transaction with a unique SMID assigned to it based on configuration performed by PMC 110. The transaction flows to NoC 108 with the respective SMID as the destination. Similarly, transactions from PL 104 or DPE array 102 each have a SMID inserted by SMID circuit 802-6 or SMID circuit 802-7, as the case may be. Transactions from PL 104 and DPE array 102 carry the SMID to their destination.

[0136] As an illustrative example, consider a circuit block implemented in PL 104 initiates transactions A, B, and C. Each of transactions A, B, and C carries a SMID assigned by SMID circuit 802-6 (or SMID circuit 802-8 if implemented in NoC 108). If transaction A is directed to DDR memory controller 512, NoC 108 acts as both an ingress path and an egress path. PPC 818-6 can check that the circuit block in PL 104 has the right to access DDR memory controller 512 (e.g., based on the SMID) and has the right to access the particular address of memory specified by the transaction. PPC 818-6 can reject transaction A if the source of transaction A does not have the appropriate rights.

[0137] Transaction B may be directed to PMC slave 820, and transaction C is directed to RPU slave 822. For transaction B, PPC 818-1 checks whether the source of transaction B (based on SMID) is authorized to access the specific PMC slave 820 specified by the transaction. For transaction C, PPC 818-3 checks whether the source of transaction C (based on SMID) is authorized to access the specific RPU slave 822 specified by the transaction. Each PPC 818-1 and PPC 818-3 allows or denies the respective transaction based on the SMID and the particular target of the transaction (e.g., a particular PMC slave 820 or a particular RPU slave 822). Thus, the logic functions of SMID attachment and exit checks (e.g., as performed by PPC 818) may be physically distributed within SoC 100.

[0138] In another example, the I / O device 812 may be an external flash device from which a boot image is loaded into the first PMC slave 820. In this example, the PMC slave 820 may be a memory slave, such as a memory in which boot code is stored, or registers for programming or configuring other blocks in the SoC 100, such as a set of registers for configuring the PL 104 and / or the DPE array 102. In another example, the boot image may be program code that the processor 612 boots. In this example, various gateways, e.g., the PPC 818 and the SMID circuit 802, are configured by the PMC 110 to only allow the boot image to be loaded into a specific PMC slave 820. Thus, the I / O device 812 is only allowed to write the contents of the image file to the designated, e.g., the first PMC slave 820, as regulated by the PPC 818-1. The I / O device 812 is not allowed to read or write to other PMC slaves 820.

[0139] Continuing with the example, the processor 612 is authorized to load the boot image via an authentication scheme (described in more detail herein). For example, the PPC 818-1 may be configured to authorize the processor 612 to read the PMC slave 820 based on the SMID corresponding to the SMID circuit 802-1, where the boot image is stored by the I / O device 812 (which only had write access). The processor 612 can only read the boot image and decrypt the boot image into a working memory for the second PMC slave 820, e.g., the processor 612. The processor 612 may then use the decrypted boot image stored in the second PMC slave 820 to program other configuration registers, e.g., by writing to the third PMC slave 820. The third PMC slave 820 may be the configuration registers for the PL 104 or the configuration registers for other circuit blocks.

[0140] In another aspect, the RPU 402 may have a local interconnect separate from other processors (e.g., APU 406) of the PMC 110 and / or PS 106. The RPU 402 suitable for real-time operation may operate in the low power domain described above and therefore may have a local interconnect separate from the local interconnects of the PMC 110 and / or APU 406. This allows the RPU 402 to react quickly to different events, e.g., real-time sensor data that may be received and / or processed by the RPU 402.

[0141] 9 shows an exemplary implementation of a PPC 818. The PPC 818 includes a SMID check circuit 902, an address range check circuit 904, and a configuration register 906.

[0142] The SMID check circuit 902 may check the SMID of a received transaction. The SMID check circuit 902 determines the SMID in the received transaction and compares the SMID to a list of permitted SMIDs specified in configuration registers 906. The address range check circuit 904 determines the specific address to be accessed within the destination specified by the transaction. The address range check circuit 904 checks whether the specified address of the received transaction is within the set or range of addresses permitted for the SMID of the transaction per configuration register 906.

[0143] The PPC 818 may prohibit (e.g., reject) transactions that do not satisfy the checks performed by the SMID check circuitry 902 and the address range check circuitry 904. The PPC 818 may further generate an interrupt signal in response to determining that a received transaction is rejected based on the checks performed by the SMID check circuitry 902 and / or the address range check circuitry 904.

[0144] FIG. 10 illustrates exemplary features of the PMC 110. In the example of FIG. 10, the PMC 110 can control power on and power off of various subsystems within the SoC 100. In the example of FIG. 10, the PMC 110 is connected to a boot device 1002. The boot device 1002 can be memory located off-chip or external to the SoC 100. The boot device 1002 can be located on the same circuit board as the SoC 100. In one example, the boot device 1002 is a flash memory. The PMC 110 can be coupled to the boot device 1002 via the MIO 668 and an appropriate I / O controller 622 (e.g., a flash memory controller) as described in connection with FIG. 6.

[0145] The PMC 110 acts as the main power manager of the SoC 100. For example, the PMC 110 executes firmware that can control the implementation of different power modes (e.g., low power mode or power off and power on) across the SoC 100. The PMC 110 is also responsible for managing the power rails within the SoC 100. In one aspect, each different power domain in the SoC 100 may be connected to its own set of power rails controlled by the PMC 110. Within this disclosure, the term "power domain" as used with respect to the SoC 100 means a set of components of the SoC 100 that are powered by the same or a common set of power rails. In one aspect, each different subsystem is an example of a power domain. Thus, the power domains within the SoC 100 include the PL 104, the PS 106, the NoC 108, and selected ones of the hardwired circuit blocks 112. As described, the PS 106 may include two different power domains.

[0146] In the example of FIG. 10, the PMC 110 is also connected to one or more voltage regulators 1004. The voltage regulators 1004 may be external to the SoC 100 and located on the same circuit board as the SoC 100. In one aspect, the PMC 110 is connected to the voltage regulators 1004 via the MIO 668 and a suitable I / O controller 622, such as an I2C, PM bus, or other suitable I / O controller. The PMC 110, e.g., the PMC processing unit 602, can communicate with the voltage regulators 1004 and send instructions to turn on or off any of the various power rails (e.g., power lines) in the SoC 100 controlled by the voltage regulator 1004 to turn on or off any power domain of the SoC 100. Additionally, the PMC 110 can command the voltage regulator 1004 to supply a particular voltage to a particular power rail in the SoC 100. In this manner, the PMC 110 can power on or off any power domain independently of each of the other power domains.

[0147] In one embodiment, the PMC 110 is directly connected to the PS 106. More specifically, the PMC 110 may be directly connected to the PS manager 444. The PS manager 444 may be implemented as a hardwired processor capable of executing program code. As part of the boot process of the PS 106, the PMC 110 may access the firmware of the PS manager 444, authenticate the firmware, and provide the firmware to the PS manager 444. The PMC 110 may, for example, place the firmware in the RAM of the PS 106 for execution by the PS manager 444.

[0148] In general, the PS 106 includes a variety of different circuit resources. Although the PMC 110 can control the PS 106, the PMC 110 does not need to know the details regarding the control of the many different components included in the PS 106. However, the PS manager 444 can have detailed control over the various components in the PS 106. For example, the PMC 110 may send an instruction to the PS manager 444 instructing the PS 106 to transition from a first power mode to a second, different power mode. The transition may include turning on some power islands in the PS 106 and turning off other power islands in the PS 106. In one aspect, the PS manager 444 can control a header cell (e.g., a power switch) in the PS 106 to power on and / or power off the power islands in the PS 106 according to instructions from the PMC 110. As used herein, the term "power island" refers to one or more components that are part of the same power domain that are turned on or off by a power switch in the SoC 100. Thus, a power domain may include multiple power islands that may be powered assuming the power rails for the power domain are powered. The power islands may be powered off independently of one another and each is under the control of switches present on the SoC 100. The PS manager 444 may control these switches that correspond to the power islands within the PS 106 and / or in other power domains.

[0149] As an illustrative and non-limiting example, each peripheral in the first or second power domain of PS 106 may be an individual island. PMC 110 controls the power on and off of a power domain through communication with an off-chip voltage regulator 1004, but PMC 110 may control the power on and off of a power island by providing instructions to PS manager 444 and / or other power managers in other domains.

[0150] In response to instructions received from PMC 110, PS manager 444 can perform more detailed power on and power off procedures for each individual power domain and / or power island in PS 106. For example, if each component in a power island (or power domain) is turned on at the same time, a large inrush of current can occur in SoC 100 that can damage the circuitry. PS manager 444 can sequence the power on and power off of the components of each individual power island and / or power domain to avoid large surges of current. PMC 110 does not need to be aware of the detailed procedures performed by PS manager 444.

[0151] In a particular implementation, each of the different power domains has power isolation circuits 1006, 1008, 1010, and 1012. The power isolation circuits allow one power domain to be turned off while other power domains remain on. The PMC 110 can control (e.g., enable and disable) the power isolation circuits 1006, 1008, 1010, and 1012 to facilitate independent power on and off of the various power domains. In one aspect, the power isolation circuits are implemented to include clamps and level shifters that reside between the power rails for the power domains in the SoC 100.

[0152] The example of FIG. 10 includes a local power manager 1014. The example of FIG. 10 illustrates an implementation in which one or more local power managers may be included to manage and / or control one or more other remote circuit blocks (e.g., hardwired circuit block 112) implemented in SoC 100. Local power manager 1014 may, for example, control power islands within these other circuit blocks. As an illustrative and non-limiting example, a VCU circuit block may be its own power domain and may include multiple different power islands. Not all components within a VCU circuit block are always required. Local power manager 1014 may manage the power on and power off of power islands within the VCU circuit block (e.g., the sequence of components within various power islands powered on and off). Local power manager 1014 may, for example (like PS manager 444), sequence the activation or deactivation of header cells (switches) of power islands within the particular circuit block being managed.

[0153] The DPE array 102 may include a power-on reset (POR) circuit 1016. The POR 1016 may initialize the DPE array 102 upon power-up. The PMC 110 may control the operation of the POR 1016.

[0154] In the example of FIG. 10, the PMC 110 includes a system monitor (SysMon) 656. The system monitor 656 can monitor the voltages of the internal rails of the SoC 100. Thus, while the PMC 110 can provide instructions to the voltage regulator 1004 to power a particular rail at a particular voltage, the PMC 110, via the system monitor 656, can monitor the voltages of the rails within the SoC 100 to ensure (e.g., verify) that the voltages of the rails measured within the SoC 100 conform to the voltages expected based on the instructions provided from the PMC 110 to the voltage regulator 1004. In one aspect, the PMC 110 does not consider a power domain to be powered on until the voltage of the rail corresponding to the power domain reaches the expected voltage as determined by the system monitor 656. For example, the PMC 110 verifies that the voltage of the rail determined by the system monitor 656 reaches a target voltage for the power domain before commanding the associated isolation circuitry for the power domain to deactivate. The system monitor 656 can also perform the same or similar verification with respect to temperature. System monitor 656 may, for example, measure the temperature at one or more locations across SoC 100 (e.g., across different subsystems) and compare the measured temperatures to the expected temperatures at each respective location. Obviously, the expected temperature at one location may differ from the expected temperature at another location.

[0155] FIG. 11 illustrates an exemplary method 1100 for booting the SoC 100. Generally, the method 1100 includes two distinct phases. Phase 1 includes blocks 1102, 1104, and 1106. Phase 1 includes operations considered to be pre-firmware. More specifically, the operations performed in phase 1 are operations performed by hardwired circuitry or logic or are operations defined by program code stored in the ROM 606 of the PMC processing unit 602, referred to as the BootROM. The BootROM is executable by a processor 612 dedicated to accessing the ROM 606 (hereinafter the "ROM PMC processor"). The operations performed in phase 2 are firmware operations. The operations performed in phase 2 are defined by firmware that is loaded into the RAM 608 from a source external to the SoC 100 for execution by a processor 612 dedicated to the RAM 608 (hereinafter the "RAM PMC processor").

[0156] In block 1102, the PMC 110 is powered up. For example, the PMC 110 includes logic that can power up the PMC 110. In block 1104, the PMC 110 sets up a boot device external to the SoC 100. For example, the ROM PMC processor can start executing a BootROM from the ROM 606 to access the boot device. In block 1106, the ROM PMC processor loads firmware stored in the boot device. The ROM PMC processor can authenticate the firmware loaded from the boot device. As generally described in connection with FIG. 6, when the ROM PMC processor executes the BootROM, it can route the firmware to one or more blocks in the security accelerator 632 for authentication and / or decryption purposes. Additionally, the ROM PMC processor can load the firmware into the RAM of the PMC 110. The firmware may be included in the PDI.

[0157] Phase 2 includes blocks 1108 (including blocks 1110, 1112, and 1114), 1116, and 1118. In phase 2, the PMC 110 begins to build an initial system within the SoC 100. For example, the RAM PMC processor begins executing firmware loaded into the RAM 608. In block 1108, the RAM PMC processor can sequence the power-on and configuration of the remainder of the SoC 100. The RAM PMC processor sequences the power-on based on the execution of the firmware. Thus, the firmware loaded into the SoC 100 defines the power-on and configuration sequence of the SoC 100 beyond the operations performed during phase 1.

[0158] Blocks 1110, 1112, and 1114 depict example operations that may be performed as part of block 1108. In block 1110, for example, the RAM PMC processor may monitor power rails in the SoC. In block 1112, the RAM PMC processor may control power regulators on the circuit board on which the SoC 100 is placed. In block 1114, the RAM PMC processor may load, authenticate, and / or decrypt PDIs, which may include programming data for the NoC 108, a configuration bitstream for the PL 104, firmware for the DDRC (DDR controller), initialization data, PS manager firmware, and a first stage boot loader (FSBL) for the PS 106, and configuration / programming data for the DPE array 102.

[0159] The RAM PMC processor processes and reports any errors that may have been detected in block 1116. In block 1118, the RAM PMC processor initializes and enables the debug infrastructure in SoC 100.

[0160] Method 1100 illustrates a process in which PMC 110 utilizes BootROM and / or hardware (e.g., dedicated logic) to bring up certain portions of SoC 100 prior to loading firmware. Variations in operation of SoC 100 during this boot mode can be controlled via I / O to SoC 100 and / or e-fuses. Initial firmware execution sets up an initial system within SoC 100 for each particular PDI loaded. Additionally, firmware execution prepares PMC 110 to respond to future service requests. As PMC 110 executes firmware, it also performs operations such as configuration of SoC 100 and / or subsystems of SoC 100, partial reconfiguration of SoC 100 and / or subsystems of SoC 100, power management, error handling, and system checks.

[0161] 12 illustrates another example method 1200 for booting the SoC 100. The method 1200 may be performed to implement an application within the SoC 100 that utilizes the various subsystems described herein.

[0162] In block 1202, hardwired logic in the PMC 110 executes a power-on reset sequence. In one embodiment, the hardwired logic is the POR circuit 666 described in connection with FIG. 6. The power-on reset sequence refers to the initial operations performed after powering up the SoC 100. In general, the power-on reset sequence executed by the SoC 100 executes initial steps before passing control to the ROM PMC processor to execute the BootROM code in the ROM 606. The power-on reset sequence may include an analog component that detects if the voltage supply is powered up and qualifies the power-on reset deassertion. Additionally, a boot mode pin may be obtained that specifies the boot mode of the SoC 100. The e-fuse bits may be read and cached by the e-fuse controller 660. A state clearing operation is performed on the PMC 110 (e.g., zeroing). In one embodiment, the POR circuit 666 may authenticate the BootROM stored in the ROM 606. The BootROM may be authenticated, for example, using the hash circuit block 650 of the PMC 110. The completion of power-on reset causes the remainder of PMC 110 to be released from reset.

[0163] In block 1204, the POR circuit 666 determines whether an error condition has occurred. If an error condition has occurred, the method 1200 proceeds to block 1206, where the error pin is asserted and the boot process of the SoC 100 is halted.

[0164] In block 1208, the PMC 110 executes the BootROM execution stage. The BootROM execution stage may be executed by the ROM PMC processor. In one aspect, the BootROM execution stage is uninterruptible. For example, in block 1208, the ROM PMC processor clears the PMC shared RAM 618. The ROM PMC processor initializes the system monitor 656 so that the system monitor 656 can check the voltages in the SoC 100 (e.g., continuously for continued detection of tampering). The ROM PMC processor initializes the PLL 664 and ensures that the PLL 664 achieves lock. The ROM PMC processor tests the PMC shared RAM 618. The ROM PMC processor further disables (powers down) the power islands that are disabled by the e-fuses based on the e-fuse data read by the e-fuse controller 660. The ROM PMC processor can further configure the PS 106 and the NoC 108, if applicable.

[0165] In block 1210, the ROM PMC processor determines whether an error condition occurred for any of the operations performed during the BootROM Execution stage of block 1208. If an error condition occurred, method 1200 proceeds to block 1212, where the error is captured in error aggregation logic, the error pin is asserted, and booting of SoC 100 continues.

[0166] In block 1214, the ROM PMC processor performs boot header / authentication certification processing. Typically, the ROM PMC processor executes BootROM code, loads the boot header from the boot source, and authenticates the boot header. Typically, the boot header specifies subsequent operations to be performed by the PMC 110. The operations may include loading a PLM from the PDI to be executed on the RAM PMC processor, which may optionally be followed by configuration of the PL 104 and / or configuration of the DPE array 102. The PLM includes a secure header and one or more blocks of firmware code.

[0167] As part of block 1214, the ROM PMC processor can process the boot header and authentication certificate from the PDI. When the ROM PMC processor executes the BootROM, it can authenticate and decrypt as necessary and load the PLM or PMC firmware into the PMC shared RAM 618. For example, the ROM PMC processor loads the boot header and authentication certificate from an external boot device into the PMC shared RAM 618. Based on the boot header, the ROM PMC processor can determine how the remainder of the PDI is authenticated, decrypted as necessary, and interpreted. From the boot header, the ROM PMC processor determines subsequent operations to be performed, such as loading the PLM to be executed by the RAM PMC processor and optionally configuring the PL 104 and / or the DPE array 102. The boot header can include an initialization vector to be used with the device key and the PUF encrypted black key. The authentication certificate can include a primary public key (e.g., an ECDSA / RSA primary public key) and a secondary public key. The primary public key is used to authenticate the secondary public key, which is used for subsequent stages of authentication.

[0168] For example, the e-fuses of the SoC 100 may store a hash value of the public key. The ROM PMC processor may use the security accelerator 632 to generate a hash of the public key obtained from the boot header and compare the generated hash value to the hash value stored in the e-fuses. With the public key certified as described, the ROM PMC processor may store the public key in a key register in the PMC 110 for use in all verification operations until the public key is changed.

[0169] At block 1216, the ROM PMC processor determines whether an error condition has occurred. If an error condition has occurred, method 1200 proceeds to block 1218, where SoC 100 is locked down, e.g., boot is aborted. In one aspect, the "lockdown state" of SoC 100 is a state in which PMC 110, in response to detecting an error, clears or erases all data (e.g., memory contents) and configuration data within SoC 100 across all subsystems (e.g., within DPE array 102, PL 104, PS 106, NoC 108, and PMC 110). For illustrative purposes, the errors described in connection with blocks 1216 and 1222 may be considered "tamper events" that initiate the lockdown state of SoC 100. Other examples of events that may be considered tamper events that, when detected by PMC 110, cause PMC 110 to initiate a lockdown state or other error recovery procedure include, but are not limited to, out-of-range temperature (e.g., higher or lower than a specified temperature range), out-of-range voltage (e.g., higher or lower than a specified voltage range), unauthorized access of a circuit block by another circuit block and / or system, and lack of authentication of configuration data and / or program code loaded into SoC 100. Any of the foregoing example tamper events may be detected during power-on or boot and / or at any time thereafter during operation of SoC 100.

[0170] In block 1220, the ROM PMC processor may perform authentication when executing the BootROM. The ROM PMC processor may, for example, load, authenticate, and decrypt the programming partition of the PDI. In one example, configuration information for different subsystems (e.g., DPE array 102, PL 104, and / or PS 106) may be specified as different partitions in the same PDI, in which case the different subsystems may be configured one after the other as part of bring-up of SoC 100. In another example, configuration information for different subsystems may be specified in different PDIs, in which case the subsystems may be configured on demand as needed.

[0171] In accordance with the inventive configurations described herein, processing a PDI partition requires that the partition be authenticated using techniques described herein (e.g., one of security accelerators 632) before the partition can be decrypted and used. Thus, a configuration image that has been authenticated must first be stored within SoC 100, e.g., within PMC 110 for processing as described. A partition can only be used to program portions of SoC 100 after it has been authenticated.

[0172] In block 1222, the ROM PMC processor determines whether an error condition has occurred. If an error condition has occurred, the method 1200 proceeds to block 1224 where the SoC 100 is locked down, e.g., boot is aborted.

[0173] In block 1226, the ROM PMC processor loads the PLM. The PLM may include a secure header followed by one or more blocks of firmware code. If so configured in the e-fuse and / or boot header, the entire PLM may be authenticated using hash block 650 (e.g., ECDSA / RSA). If authentication passes, the secure header is decrypted using the decryption circuitry and the device key. The secure header contains an AES key for decrypting the next block of the PLM or the remainder of the PLM.

[0174] Once the PLM is loaded and authenticated by the ROM PMC processor, execution transfers from the ROM PMC processor to the RAM PMC processor, which may perform configuration tasks such as loading a PS boot loader for the PS 106, configuring the SoC 100 blocks, such as the NoC 108, the DDR controller 512, the GT 528, the DPE array 102, etc., via the NPI 210, and / or loading a configuration bitstream (e.g., in whole or in part) into the PL 104 for its configuration.

[0175] As described, the RAM PMC processor executing the firmware may perform any of a variety of operations depending on the instructions contained in the firmware. For example, in block 1228, the RAM PMC processor may execute a PS boot loader stage. The RAM PMC processor may load a PS boot loader from an external source, authenticate the PS boot loader, and copy the PS boot loader to the OCM 530 in the PS 106 for execution by the PS processor. Once copied to the OCM 530, the RAM PMC processor releases the PS 106 from reset. The PS 106 may execute the PS boot loader.

[0176] In block 1230, the RAM PMC processor, as it executes the firmware, can configure the PL 104. For example, the RAM PMC processor can load a configuration bitstream from an external source, authenticate the configuration bitstream, and provide the configuration bitstream to the PL 104 (e.g., write the configuration bitstream to a configuration register of the PL 104).

[0177] In block 1232, the RAM PMC processor can configure the DPE array 102. The RAM PMC processor can load DPE array programming segments (e.g., a configuration image of the DPE array) from an external source, authenticate the DPE array programming segments, and write the DPE programming segments to the appropriate destination (a particular DPE 302 within the DPE array 102) via the NPI 210 and the NoC 108.

[0178] In block 1234, the RAM PMC processor can configure one or more circuit blocks. The circuit blocks may be hardwired circuit blocks or circuit blocks implemented in the PL 104 that require configuration data, such as programming of internal configuration registers. The RAM PMC processor can load register programming segments from an external source, authenticate the register programming, and write the register programming to a destination via the NPI 210 and the NoC 108. As an illustrative and non-limiting example, the RAM PMC processor can write register data to hardwired circuit blocks, such as, for example, a memory controller, a cryptographic circuit block, a video codec, a DAC, an ADC, etc. In another aspect, the RAM PMC processor can also write register data to the SMID circuit block 802 and / or the PPC 818.

[0179] In block 1236, the RAM PMC processor may configure the NoC 108. As an illustrative and non-limiting example, the RAM PMC processor may configure the NoC 108 to establish data paths connecting the endpoint circuits. In block 1238, the RAM PMC processor may configure any memory. For example, the RAM PMC processor may write configuration data to any memory controller and / or interface with external memory accessible by the SoC 100.

[0180] The various operations performed as a result of loading the PLM at block 1226 by the RAM PMC processor may or may not be independent of one another. In some cases, the operations may be performed synchronously. For example, although not explicitly described, images for the NPI 210 may be loaded before the PL 104 and / or DPE array 102 can be configured. The particular order of blocks 1228-1238 is not intended to limit the configuration of the present invention.

[0181] 12 shows that PMC 110 is responsible for configuring PS 106, PL 104, DPE array 102, and selected other circuit blocks. In one or more other embodiments, PMC 110, in response to, for example, a boot header, can configure PS 106 with program code that enables PS 106 to configure PL 104 and DPE array 102. In that case, in response to the setting of the PS in block 1228, blocks 1230, 1232, and 1234 can be executed by PS 106 as opposed to a RAM PMC processor in PMC 110.

[0182] As method 1200 progresses, each level in the progression enables or revokes permission for components to access other components within SoC 100. The process described in connection with FIG. 12 is hierarchical in that authorization may be denied or granted to increasingly narrower subsets of subsystems and / or components within SoC 100.

[0183] 13 illustrates an example of a PDI 1300 that may be used to boot the SoC 100. In the example of FIG. 13, the PDI 1300 includes a boot header 1302. The PDI 1300 further includes a PLM 1304. The PLM 1304 may include a secure header 1306 and firmware 1308 executable by the RAM PMC processor of the PMC 110. The PDI 1300 also includes an authentication certificate 1314.

[0184] Next image 1310 of PDI 1300 may include multiple different blocks, shown as block 0, block 1 through block N. The various blocks included in next image 1310 may be specified in secure header 1312. Generally, the various blocks 0 through N correspond to PS 106 boot code, configuration bitstream for PL 104, DPE array programming segment, and register programming data referenced in blocks 1228, 1230, 1232, and 1234 of FIG. 12. In a particular embodiment, these blocks may be organized according to application (e.g., partition), with multiple blocks representing one application for implementation in a first partition and a different set of blocks representing another application that may be implemented in a second partition concurrently with the first application or in the first partition after the first application has finished executing.

[0185] Partial reconfiguration of one or more portions of SoC 100 may be performed by PMC 110 selectively executing different ones of blocks 1228-1238 using available and / or different blocks or sets of blocks included in PDI 1300 (or different PDIs) over time and depending on certain conditions. Partial reconfiguration of SoC 100 facilitates layering into subsets or wholes of physical components within SoC 100 or logical subsets thereof. For example, PMC 110 may control partition isolation, unloading (and loading) of software drivers (as appropriate for changed applications), delivery of programming images from any secondary boot interfaces, and image authentication and integrity checks before programming occurs.

[0186] 14 illustrates an example cross-sectional side view of an IC structure 1400. The IC structure 1400 is a multi-die IC structure. The IC structure 1400 illustrates an example of a packing technique for stacking multiple dies within a single package. As shown, the IC structure 1400 can include a silicon interposer (interposer) 1405, a die 1410, and a die 1415.

[0187] The interposer 1405 can be a die having a planar surface on which the dies 1410 and 1415 can be stacked horizontally. In general, the interposer 1405 can be implemented with a silicon wafer substrate. As shown, the interposer 1405 can provide a common mounting surface and electrical coupling points for two or more dies of a multi-die IC structure. In one aspect, the interposer 1405 can function as an intermediate layer for interconnect routing between the dies. In another aspect, the interposer 1405 can function as a ground or power plane for the IC structure 1400.

[0188] The dies 1410 and 1415 can be arranged side-by-side on the plane of the interposer 1405. Although implemented with two horizontally stacked dies in FIG. 14, the IC structure 1400 can also be implemented with three or more horizontally stacked dies. In another aspect, the die 1415 can be vertically stacked on top of the die 1410. The interposer 1405 can also be used as an intermediate layer between two vertically stacked dies. In that case, for example, the interposer 1405 can separate the vertically stacked dies from each other in a multi-die IC package.

[0189] The interposer 1405 may include an interconnect region 1420 that includes one or more conductive layers. The conductive layers may be formed of materials such as, for example, aluminum, gold, copper, nickel, various silicides, and the like. In one aspect, the interposer 1405 may be implemented as a completely passive structure that does not include any active circuit elements. However, in another aspect, one or more additional process layers may be added to the interposer 1405 to create one or more active devices, as needed. In either case, the interposer 1405 is generally characterized as including one or more through vias (TVs) and inter-die wires. If the interposer 1405 is formed using silicon, the TVs may be "through silicon vias," although the interposer 1405 may be formed of other suitable materials.

[0190] Each of the dies 1410 and 1415 can be electrically coupled to the interposer 1405 via a number of solder bumps 1425. In one embodiment, the solder bumps 1425 can be implemented as "microbumps." Each of the solder bumps 1425 can serve to physically attach, e.g., bond, the dies 1410 and 1415 to the interposer 1405. Although the bonding of the dies 1410 and 1415 to the interposer 1405 is accomplished via the solder bumps 1425, various other techniques can be used to bond the interposer 1405 to the dies 1410 and 1415. For example, bond wires or edge wires can be used to bond the dies 1410 and 1415 to the interposer 1405. In another example, an adhesive material can be used to physically attach the dies 1410 and 1415 to the interposer 1405. Thus, the coupling of dies 1410 and 1415 to interposer 1405 via solder bumps 1425 is provided for purposes of example and not limitation.

[0191] One or more conductive layers in the interconnect region 1420 can be used to form inter-die wires between the die 1410 and the die 1415. For example, the inter-die wires 1430 can be formed from one or more portions of a conductive layer, such as a patterned conductive layer. A vertical portion of the inter-die wires 1430 can be formed from one or more vias in the interconnect region 1420 that couple adjacent conductive layers to one another. The inter-die wires 1430 can be implemented in two or more conductive layers that are coupled to one another using vias in the interposer 1405, for example. By using multiple conductive layers to implement the interconnects in the interposer 1405, a greater number of signals can be routed and more complex routing of signals can be achieved within the interposer 1405. As shown, the inter-die wires 1430 couple each of the solder bumps 1425A and 1425B to one another, thereby enabling the exchange of inter-die signals between the die 1410 and the die 1415.

[0192] The interposer 1405 can be electrically coupled to the surface 1445 using solder bumps 1440. In one aspect, the solder bumps 1440 can be implemented as controlled collapse chip connections or "C4" type bumps. The surface 1445 can represent a multi-die IC package, e.g., a substrate of the multi-die IC package on which the IC structure 1400 is implemented. For example, the solder bumps 1440 can be used to physically attach the interposer 1405 to the surface 1445. As shown, the solder bumps 1440 can directly couple the IC structure 1400 to a node external to the IC structure 1400, e.g., external to the multi-die IC package.

[0193] The interconnect region 1420 may be coupled to one or more TVs 1435. Generally, each TV 1435 represents a via filled with a conductive material that forms an electrical connection that traverses vertically, e.g., extends through a substantial portion, if not the entirety, of the interposer 1405. Each TV 1435 may be formed of a conductive material, e.g., copper, aluminum, gold, copper, nickel, various silicides, and the like. As shown, each TV 1435 may substantially pass through the interposer 1405 to couple a conductive layer, e.g., a wire, in the interconnect region 1420 to a solder bump 1440. In this regard, each TV 1435 may form a signal path from a solder ball 1440 through the interconnect region 1420 to a solder bump 1425, thereby facilitating signal propagation to the die 1410 and / or die 1415.

[0194] In one embodiment, the interposer 1405 can be formed of a material that provides the interposer 1405 with a substrate resistivity that is higher than the substrate resistivity of the die 1410 and higher than the substrate resistivity of the die 1415. For example, the interposer 1405 can be implemented using a material having a substrate resistivity of about 40 ohms per centimeter or higher. In this regard, the interposer 1405 can be implemented using a process technology that is different from that used to implement either one of the dies 1410 and / or 1415. For example, the conductive layer in the interconnect region 1420 can be implemented with a thickness that is greater than the conductive layer implemented in one or both of the dies 1410 and 1415. In one example, the conductive layer in the interconnect region 1420 can be about four times the thickness of the conductive layer in the die 1410 and / or 1415.

[0195] In the example of FIG. 14, each of die 1410 and die 1415 may be implemented to include one or more subsystems and PMC 110. In particular examples, each of die 1410 and 1415 may be implemented with an architecture that is the same as or similar to the architecture described in connection with FIG. 1. For purposes of illustration, die 1410 is MasterIn the example shown in FIG. 14, the first die is designated as the master die, and die 1415 is designated as the slave die. If both die 1410 and 1415 have NoCs, then the NoCs of each die may be connected by inter-die wires, such as 1430, within interposer 1405.

[0196] Additionally, the PMC implemented in die 1410, which is the master die, is considered the master PMC. The PMC in die 1415 operates as a slave to the PMC in die 1410. Although the PMC in die 1415 may perform the operations described herein, any data operated on and / or used on the PMC of die 1415 is received from the PMC in die 1410 as opposed to being received directly from a source external to IC structure 1400. In one aspect, only the PMC in die 1410 has access to I / O to obtain data, e.g., firmware and / or PDI, from a source external to IC structure 1400. Thus, any firmware and / or PDI used by the PMC in die 1415 is first retrieved by the PMC in die 1410 and provided to die 1415 by the PMC in die 1410. In any case, each die is configured by the PMC in that particular die.

[0197] In another embodiment, each PMC is equipped to perform encryption and decryption using a key specific to the die in which the PMC is contained. For example, the key to be used by a given PMC may be stored in a dedicated e-fuse in the same die as the PMC, allowing each PMC to use a different key. In one aspect, only encrypted data is exchanged between PMCs in different dies. In this way, each PMC can decrypt encrypted data received from other PMCs and encrypt data before sending the data to other PMCs.

[0198] For purposes of explanation, specific nomenclature is set forth to provide a thorough understanding of the various inventive concepts disclosed herein. However, the terminology used herein is for the purpose of describing particular aspects of the inventive configurations only and is not intended to be limiting.

[0199] As defined herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise.

[0200] As defined herein, the term "approximately" means nearly exact or exact, close to but not exact in value or amount. For example, the term "approximately" can mean that a recited property, parameter, or value is within a given amount of the exact property, parameter, or value.

[0201] As defined herein, the terms "at least one," "one or more," and "and / or" are open-ended expressions that are both conjunctive and disjunctive in operation unless otherwise specified. For example, the phrases "at least one of A, B, and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C," and "A, B, and / or C" mean A only, B only, C only, A and B together, A and C together, B and C together, or A, B, and C together, respectively.

[0202] As defined herein, the term "automatically" means without user intervention. As defined herein, the term "user" means a human being.

[0203] As defined herein, the term "computer-readable storage medium" refers to a storage medium that contains or stores program code for use by or in connection with an instruction execution system, apparatus, or device. As defined herein, a "computer-readable storage medium" is not a transitory propagating signal itself. A computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The various forms of memory described herein are examples of computer-readable storage media. A non-exhaustive list of more specific examples of computer-readable storage media may include portable computer diskettes, hard disks, RAM, read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), electronically erasable programmable read-only memory (EEPROM), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, and the like.

[0204] As defined herein, the term "if" means "when" or "when" or "in response to" or "in response to," depending on the context. Thus, the phrase "when determined" or "when [described condition or event] is detected" can be interpreted to mean "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detection of [described condition or event]," depending on the context.

[0205] As defined herein, the term "in response" and similar terms such as "when," "when," or "upon," means to readily respond or react to an action or event. The response or reaction occurs automatically. Thus, when a second action occurs "in response" to a first action, there is a causal relationship between the occurrence of the first action and the occurrence of the second action. The term "in response" indicates a causal relationship.

[0206] As defined herein, the terms "one embodiment," "embodiment," "one or more embodiments," "particular embodiment," or similar terms mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment described within the disclosure. Thus, throughout this disclosure, appearances of the phrases "in one embodiment," "in an embodiment," "in one or more embodiments," "in a particular embodiment," and similar language may, but do not necessarily, all refer to the same embodiment. The terms "embodiment" and "arrangement" are used interchangeably within this disclosure.

[0207] As defined herein, the term "real-time" means a level of processing responsiveness that a user or system perceives as immediate enough for a particular process or decision to occur, or that allows the processor to keep up with some external process.

[0208] As defined herein, the term "substantially" means that the recited property, parameter, or value need not be achieved exactly, but that deviations or variations including, for example, tolerances, measurement errors, measurement accuracy limits, and other factors known to those of ordinary skill in the art, may occur in an amount that does not eliminate the effect that the property is intended to provide.

[0209] Terms such as first, second, etc. may be used herein to describe various elements. These elements should not be limited by these terms, as they are only used to distinguish one element from another, unless otherwise noted or the context clearly indicates otherwise.

[0210] A computer program product may include a computer-readable storage medium having computer-readable program instructions for causing a processor to execute aspects of the inventive arrangements described herein. Within this disclosure, the term "program code" is used interchangeably with the term "computer-readable program instructions." The computer-readable program instructions described herein may be downloaded from the computer-readable storage medium to the respective computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network. The network may include edge devices including copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in the respective computing / processing device.

[0211] The computer readable program instructions for performing the operations for the inventive arrangements described herein may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, or source or object code written in any combination of one or more programming languages, including object-oriented and / or procedural programming languages. The computer readable program instructions may include state setting data. The computer readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some cases, for example, an electronic circuit including a programmable logic circuit, an FPGA, or a programmable logic array (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuit to perform aspects of the inventive arrangements described herein.

[0212] Certain aspects of the inventive arrangement are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions, e.g., program code.

[0213] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, and the instructions executing via the processor of the computer or other programmable data processing apparatus create means for performing the functions / acts specified in the flowchart and / or block diagram blocks. These computer readable program instructions may also be stored on a computer readable storage medium capable of directing a computer, programmable data processing apparatus, and / or other device to function in a particular manner, and a computer readable storage medium having instructions stored thereon includes an article of manufacture including instructions for performing aspects of the acts specified in the flowchart and / or block diagram blocks.

[0214] The computer readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause a sequence of operations to be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, where the instructions executing on the computer, other programmable apparatus, or other device perform the functions / operations specified in the flowchart and / or block diagram blocks.

[0215] The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various aspects of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions that includes one or more executable instructions for performing the specified operations.

[0216] In some alternative implementations, the operations noted in the blocks may occur in a different order than that depicted in the figures. For example, two blocks shown in succession may be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. In other examples, the blocks may generally be executed in ascending order, while in still other examples, one or more blocks may be executed in various orders, with the results stored and utilized in a subsequent block or in other blocks that do not immediately follow. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0217] The corresponding structure, materials, acts, and equivalents of all means-plus-function or step-plus-function elements that may be found in the following claims are intended to include any structure, material, or act for performing a function in combination with other claimed elements that are specifically claimed.

[0218] The IC includes a processor system configured to execute program code, programmable logic, and a platform management controller coupled to the processor system and the programmable logic, the platform management controller adapted to independently configure and control the processor system and the programmable logic.

[0219] The platform management controller may include a dedicated read-only memory, a first processor dedicated for executing first instructions stored in the dedicated read-only memory, a dedicated random access memory, and a second processor dedicated for executing second instructions stored in the dedicated random access memory.

[0220] In another aspect, each of the first and second processors is implemented with redundancy.

[0221] In another aspect, a first processor performs a first stage of a boot process, executing first instructions from a dedicated read-only memory, obtaining and authenticating second instructions from an external source, and storing the second instructions in a dedicated random access memory for execution by the second processor.

[0222] In another aspect, the first processor establishes the platform management controller as the root of trust for the IC.

[0223] In another aspect, the platform management controller is powered independently of the processor system and the programmable logic.

[0224] In another aspect, the processor system is powered independently of the programmable logic.

[0225] In another aspect, the platform management controller is configured to power off the processor system and the programmable logic independently of one another and to power on the processor system and the programmable logic independently of one another.

[0226] In another aspect, a platform management controller includes an interface and a circuit configured to detect a wake signal received via the interface, the platform management controller responsive to the wake signal powers on a power domain of the IC that was previously powered off.

[0227] In another aspect, the platform management controller includes a debug interface that is accessible external to the IC and independent of the processor system and programmable logic.

[0228] In another aspect, the platform management controller includes an error management interface configured to receive an error notification from the processor system and the programmable logic, the error management interface configured to at least one of generate a signal output from the IC indicative of the detected error or generate an interrupt to a processor in the platform management controller.

[0229] In another aspect, the platform management controller is configured to program protection circuitry implemented throughout the IC that controls functional and physical isolation between subsystems of the IC, the subsystems including a processor system and programmable logic.

[0230] In another aspect, the platform management controller is configured to detect an out-of-temperature or out-of-voltage range event of the integrated circuit.

[0231] In another aspect, the platform management controller is configured to erase the IC in response to detecting an out-of-temperature or out-of-voltage range event.

[0232] In another aspect, the platform management controller is configured to erase the IC in response to detecting a tamper event.

[0233] In another aspect, an IC includes a first die including a platform management controller and at least one of a processor system or programmable logic. The IC further includes a second die including an additional platform management controller operating as a slave to the platform management controller of the first die. The second die includes at least one of a processor system or programmable logic.

[0234] In another aspect, an IC includes a processor array and a programmable network-on-chip connecting the processor array with programmable logic and a platform management controller.

[0235] In another aspect, the platform management controller is adapted to configure the programmable network-on-chip and to configure the processor array using the programmable network-on-chip once configured.

[0236] In another aspect, the platform management controller is configured to detect a tamper event occurring within the IC and initiate a lockdown state in response.

[0237] The method includes providing a processor system on an IC, the processor system configured to execute program code. The method may include providing programmable logic on the IC and providing a platform management controller on the IC. The platform management controller is coupled to the processor system and the programmable logic and adapted to independently configure and control the processor system and the programmable logic.

[0238] In another aspect, the method includes providing, as part of a platform management controller, a dedicated read-only memory, a dedicated first processor for executing first instructions stored in the dedicated read-only memory, a dedicated random access memory, and a dedicated second processor for executing second instructions stored in the dedicated random access memory. The method also includes performing a first stage of a boot process using the first processor to execute the first instructions from the dedicated read-only memory, obtain and authenticate second instructions from an external source, and store the second instructions in the dedicated random access memory for execution by the second processor.

[0239] The description of the inventive configurations provided herein is for illustrative purposes and is not intended to be exhaustive or limited to the disclosed forms and examples. The terms used herein are selected to explain the principles of the inventive configurations, practical applications or technical improvements to the art found in the market, and / or to enable those skilled in the art to understand the inventive configurations disclosed herein. Modifications and variations may be apparent to those skilled in the art without departing from the scope and spirit of the inventive configurations described. Accordingly, reference should be made to the following claims, rather than the foregoing disclosure, as indicating the scope of such features and embodiments.

Claims

1. a processor system configured to execute program code; Programmable logic; a platform management controller coupled to the processor system and to the programmable logic; Equipped with the platform management controller is adapted to independently configure and control the processor system and the programmable logic; The platform management controller: A dedicated read-only memory; a dedicated first processor for executing first instructions stored in said dedicated read-only memory; A dedicated random access memory; a dedicated second processor for executing second instructions stored in said dedicated random access memory; Equipped with performing a first stage of a boot process in which the first processor executes the first instructions from the dedicated read-only memory, obtains and authenticates the second instructions from an external source, and stores the second instructions in the dedicated random access memory for execution by the second processor; An integrated circuit, wherein each of the first processor and the second processor are implemented with redundancy.

2. 2. The integrated circuit of claim 1, wherein the platform management controller is powered independently of the processor system and the programmable logic.

3. The integrated circuit of claim 2 , wherein the processor system is powered independently of the programmable logic.

4. 3. The integrated circuit of claim 2, wherein the platform management controller is configured to power off the processor system and the programmable logic independently of one another and to power on the processor system and the programmable logic independently of one another.

5. the platform management controller comprising an interface and circuitry configured to detect a wake signal received via the interface; the platform management controller, in response to the wake signal, powering on a power domain of the integrated circuit that was previously powered off; 10. The integrated circuit of claim 1.

6. 2. The integrated circuit of claim 1, wherein the platform management controller comprises a debug interface that is accessible external to the integrated circuit and that is accessible independently of the processor system and the programmable logic.

7. the platform management controller comprising an error management interface configured to receive error notifications from the processor system and the programmable logic; the error management interface is configured to at least one of: generate a signal output from the integrated circuit indicative of a detected error; or generate an interrupt to a processor within the platform management controller.

10. The integrated circuit of claim 1.

8. 2. The integrated circuit of claim 1, wherein the platform management controller is configured to program protection circuitry implemented throughout the integrated circuit that controls functional and physical isolation between subsystems of the integrated circuit, the subsystems including the processor system and the programmable logic.

9. The integrated circuit of claim 1 , wherein the platform management controller is configured to detect an out-of-temperature or out-of-voltage range event of the integrated circuit.

10. 10. The integrated circuit of claim 9, wherein the platform management controller is configured to erase the integrated circuit in response to detecting the temperature out-of-range event or the voltage out-of-range event.

11. a first die including the platform management controller and at least one of the processor system or the programmable logic; a second die including a slave platform management controller and at least the other of the processor system or the programmable logic; The integrated circuit of claim 1 further comprising:

12. A processor array; a programmable network-on-chip connecting said processor array to said programmable logic and to said platform management controller; Further equipped with the platform management controller is adapted to configure the programmable network-on-chip and to configure the processor array using the programmable network-on-chip once configured; 10. The integrated circuit of claim 1.

13. The integrated circuit of claim 1 , wherein the platform management controller is configured to detect a tamper event occurring within the integrated circuit and to initiate a lockdown state in response thereto.

Images