Adaptable Integrated Programmable Device Platform

Abstract

To provide a device for and a method of separating a plurality of tenants in an integrated circuit including a programmable logic circuit, a processor system, and a network-on-chip.SOLUTION: The present invention is directed to a system-on-chip (SoC) 100 having a programmable logic (PL) circuit 104 arranged to operate with a plurality of tenants, a processor system (PS) 106 coupled with the PL circuit 104, and a network-on-chip (NoC) 108 coupled with the PL circuit 104 and the processor system. The PL circuit 104 is equipped with one or more hardware acceleration functions for the plurality of tenants and routes data between a first interface communicating with a host data processing system so as to separate the plurality of tenants and a second interface operating with the plurality of tenants.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to integrated circuits (ICs), and more particularly to integrated programmable device platforms that provide a variety of heterogeneous subsystems. [Background technology]

[0002] 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). FPGAs are characterized by the inclusion of programmable circuit blocks. Examples of programmable circuit blocks include, but are not limited to, input / output blocks (IOBs), configurable logic blocks (CLBs), dedicated random access memory blocks (BRAMs), digital signal processing blocks (DSPs), processors, clock managers, and delay-locked loops (DLLs).

[0003] Modern programmable ICs have evolved to include programmable logic in combination with one or more other subsystems. For example, some programmable ICs have evolved into systems-on-chips or "SoCs" that include both programmable logic and hardwired processors. Other types of programmable ICs include additional and / or different subsystems. Summary of the Invention [Means for solving the problem]

[0004] The device may include a programmable logic circuit, a processor system coupled to the programmable logic circuit, and a network-on-chip coupled to the programmable logic circuit and the processor system. The network-on-chip and the programmable logic circuit may be configured to implement a plurality of independent partitions. The network-on-chip may be programmable to establish, for each of the plurality of independent partitions, a user-specified data path that communicatively links circuit blocks implemented in the programmable logic circuit and the processor system. The device may further include a platform management controller that configures the programmable logic circuit, the network-on-chip, and the processor system to implement the plurality of independent partitions.

[0005] In one aspect, each of the multiple independent partitions implements a different application, and the applications are isolated from one another.

[0006] In another aspect, the device includes a data processing engine array coupled to a network-on-chip, and one or more of the plurality of independent partitions includes one or more data processing engines of the data processing engine array.

[0007] In another aspect, the data processing engine array is configured to implement a portion of an application in each of one or more of the plurality of independent partitions.

[0008] In another aspect, the device includes an application-specific hardwired circuit block coupled to a network-on-chip, and the application-specific hardwired circuit block and the circuit block implemented in the programmable logic circuit of each of the multiple independent partitions can have a common interface.

[0009] In another aspect, the device may A programmable protection circuit configured to isolate the multiple independent partitions by comparing the identifier to a list of authorized transaction sources is included.

[0010] In another aspect, the programmable protection circuit further compares the address specified in the received transaction with the allowed addresses of the transaction source identifier.

[0011] In another aspect, the processor system and the circuit blocks implemented in the programmable circuit use a common descriptor format for communication.

[0012] The method can include providing a device including a programmable logic circuit, a processor system coupled to the programmable logic circuit, and a network-on-chip coupled to the programmable logic circuit and the processor system. The method can include configuring the network-on-chip and the programmable logic circuit to implement a plurality of independent partitions. The network-on-chip can be programmable to establish, for each of the plurality of independent partitions, a user-specified data path that communicatively links circuit blocks implemented in the programmable logic circuit and the processor system. The method can include configuring the programmable logic circuit, the network-on-chip, and the processor system to implement the plurality of independent partitions using a platform management controller located within the device.

[0013] In one aspect, each partition of the multiple independent partitions implements a different application, and the applications are isolated from one another.

[0014] In another aspect, the device includes a data processing engine array coupled to a network-on-chip, and one or more of the plurality of independent partitions includes one or more data processing engines of the data processing engine array.

[0015] In another aspect, the method may include configuring the data processing engine array to implement a portion of the application in each of one or more of the plurality of independent partitions.

[0016] In another aspect, the device can include application-specific hardwired circuit blocks coupled to the network-on-chip, in which case the method can include providing a common interface for the application-specific hardwired circuit blocks and circuit blocks implemented in the programmable logic circuit of each of the multiple independent partitions.

[0017] In another aspect, the method can include dynamically reconfiguring at least one of the plurality of independent partitions.

[0018] In another aspect, a method may include isolating the multiple independent partitions by providing a programmable protection circuit in the device and configuring the programmable protection circuit to compare an identifier of a transaction source in a received transaction to a list of authorized transaction sources.

[0019] 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 arrangement will be apparent from the accompanying drawings and the detailed description that follows.

[0020] BRIEF DESCRIPTION OF THE DRAWINGS Arrangements of the invention are illustrated by way of example in the accompanying drawings, in which:

[0013] Various aspects and advantages will become apparent upon consideration of the following detailed description and upon reference to the drawings. [Brief explanation of the drawings]

[0021] [Figure 1]1 illustrates an exemplary architecture for a system-on-chip (SoC) type of integrated circuit (IC). [Figure 2] 2 illustrates an exemplary implementation of a data processing engine (DPE) array for the SoC of FIG. 1. [Figure 3] 3 illustrates an exemplary architecture of a DPE of the DPE array of FIG. 2. [Figure 4] 4 illustrates further aspects of the exemplary architecture of FIG. 3. [Figure 5] 1 illustrates another exemplary architecture of a DPE array. [Figure 6] 1 illustrates an exemplary architecture of a tile of an SoC interface block of a DPE array. [Figure 7] 2 illustrates an exemplary implementation of the network-on-chip (NoC) of FIG. 1. [Figure 8] 2 is a block diagram illustrating the connection between the endpoint circuitry in the SoC of FIG. 1 and the NoC. [Figure 9] FIG. 10 is a block diagram illustrating an NoC according to another example. [Figure 10] 1 illustrates an exemplary method for programming an NoC. [Figure 11] 1 illustrates another exemplary method for programming an NoC. [Figure 12] 1 illustrates an exemplary data path through an NoC between endpoint circuits. [Figure 13] 1 illustrates an exemplary method for processing read / write requests and responses associated with an NoC. [Figure 14] 1 illustrates an exemplary implementation of an NoC master unit. [Figure 15] 1 illustrates an exemplary implementation of an NoC slave unit. [Figure 16] 1 illustrates an exemplary connection to a register block of a NoC via an NoC peripheral interconnect. [Figure 17] 1 shows an exemplary table used by the NoC. [Figure 18] 1 illustrates an exemplary method for operating an SoC. [Figure 19] 1 is an exemplary method for partially reconfiguring an NoC. [Figure 20] 2 illustrates another exemplary implementation of the SoC of FIG. 1. [Figure 21] 1 illustrates an exemplary implementation of a platform management controller (PMC). [Figure 22] 22 illustrates an exemplary implementation of a processor of the PMC of FIG. 21. [Figure 23] 2 illustrates further structural and functional aspects of the SoC of FIG. 1. [Figure 24] 2 illustrates further structural and functional aspects of the SoC of FIG. 1. [Figure 25] 25 illustrates an exemplary implementation of the programmable protection circuit of FIG. 24. [Figure 26] 2 illustrates an exemplary method for booting the SoC of FIG. 1. [Figure 27] 1 illustrates an example of a programming device image that may be used to boot an SoC. [Figure 28] 1 illustrates an exemplary SoC implementing different partitions. [Figure 29] 1 illustrates another exemplary SoC implementing different partitions. [Figure 30] 1 illustrates an exemplary method for implementing a programming device image (PDI) within an SoC. [Figure 31] 1 illustrates another exemplary method for implementing PDI within an SoC and reconfiguring the SoC over time. [Figure 32] 1 illustrates another exemplary method for implementing PDI within an SoC to perform partial reconfiguration of the SoC over time. DETAILED DESCRIPTION OF THE INVENTION

[0022] The present disclosure concludes with claims defining novel features, but the present disclosure is not limited to the claims themselves. The various features described herein 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. Specific structural and functional details described within this 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 the various uses of the described features in substantially any appropriately detailed structure. Furthermore, the terms and phrases used within this disclosure are not intended to be limiting, but rather to provide an understandable description of the described features.

[0023] This disclosure relates to integrated circuits (ICs), and more particularly to integrated programmable device platforms (platforms) that provide various heterogeneous subsystems. The platforms leverage the various subsystems described to provide numerous advantages. For example, the platforms can leverage the area and power efficiency of fixed-function components (e.g., application-specific integrated circuits or "ASICs"), the flexibility and functionality of programmable logic, and extend that flexibility to the fixed-function components, providing common services to both the fixed-function components and the programmable logic.

[0024] The platform can extend the flexibility of fixed-function components by providing a common infrastructure within the device that can be shared and used among different subsystems. This common infrastructure can provide functionality including, but not limited to, data paths, firewalls, interrupt and doorbell paths, performance monitors, and configuration. The different subsystems can be implemented such that the circuit blocks within these different subsystems, when implemented as part of a user application, can use standard interfaces configured to connect to and utilize the common infrastructure.

[0025] The common infrastructure increases the flexibility, functionality, area efficiency, power efficiency, and performance of a device despite the heterogeneity of the various subsystems contained therein. Unused platform resources of the common infrastructure for one component may be applied to another component within the platform. As an example, unused network-on-chip (NoC) buffers, virtual channels, and physical paths assigned to a set of unused components of the platform may be assigned to another set of components used by a user's application within the platform. Furthermore, the platform allows any of the device's various components to utilize the common infrastructure to access subsystems such as programmable logic.

[0026] In another aspect, certain functions may be quickly remapped from one component of the platform to another component or subsystem within the platform. As an example, a standard encryption acceleration function, such as Advanced Encryption Standard Galois / Counter Mode (AES-GCM), may be implemented using programmable logic. The function may be remapped, e.g., moved, to another device, such as a hardwired or hardened encryption accelerator block. This remapping frees up programmable logic resources and increases device flexibility. The terms "hardwired" and "hardened" are used interchangeably within this disclosure.

[0027] The remapping is facilitated, at least in part, by a common infrastructure, which may include a common interface for both circuit blocks implemented in programmable logic and hardwired circuit blocks. The firewall allows the attributes of the function, such as communication paths, data paths, and interrupt paths, to be maintained despite the remapping of the function from one subsystem to another. Other components within the platform that interact with the encryption acceleration function are prevented from unauthorized access to the component by the firewall, regardless of where it is implemented. As an example, other components cannot access or view unencrypted data or the encryption keys used by the encryption acceleration function. Firewalling can also be used to prevent unauthorized components from accessing or viewing encrypted data. Other components within the platform can continue to operate in the same manner despite the remapping of the encryption acceleration function. Remapping one function of an application implemented on the platform does not require remapping all components and / or functions of the application across the entire platform.

[0028] The platform also supports the creation of multiple different partitions within the device simultaneously. Each partition can implement a different application within it. Each partition, and the applications running within it, may be isolated from each other partition within the platform. As used herein with respect to the platform and exemplary SoC described herein, the term "application" refers to any data, whether executable program code, configuration bitstream, register programming data, or other images used to configure the SoC or a portion thereof (e.g., the entire device or a partition thereof). The described partitions also support multi-client or multi-tenant use cases, in which different applications corresponding to the same or different end users can run simultaneously within the device, each in a different partition. The platform allows any of the device's various components to utilize a common infrastructure to access subsystems such as programmable logic.

[0029] 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, the dimensions of some elements may be exaggerated relative to other elements for clarity. Furthermore, where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding, similar, or like features.

[0030] FIG. 1 illustrates an exemplary architecture for a system-on-chip (SoC) 100. The SoC 100 is an example of a programmable IC and integrated programmable device platform. 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.

[0031] 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 a programmable logic (PL) region 104 (hereinafter PL region or PL), a processing system (PS) 106, a network-on-chip (NoC) 108, and one or more hardwired circuit blocks 110. DPE array 102 is implemented as multiple interconnected hardwired and programmable processors with interfaces to other regions of SoC 100.

[0032] The PL 104 is a circuit that can be programmed to perform a specified function. As such, PL 104 may be implemented as a field programmable gate array type circuit. PL 104 may include an array of programmable circuit blocks. Examples of programmable circuit blocks within PL 104 include, but are not limited to, configurable logic blocks (CLBs), dedicated random access memory blocks (BRAM and / or UltraRAM or URAM), digital signal processing blocks (DSPs), clock managers, and / or delay locked loops (DLLs).

[0033] Each programmable circuit block in PL 104 typically includes both programmable interconnect circuitry and programmable logic circuitry. The programmable interconnect circuitry typically includes a number of interconnect wires of various lengths interconnected by programmable interconnect points (PIPs). The interconnect wires are typically configured (e.g., wire-by-wire) to provide connections on a bit-by-bit basis (e.g., where each wire carries one bit of information). The programmable logic circuitry implements the logic of a user design using programmable elements that may include, for example, look-up tables, registers, arithmetic logic, etc. The programmable interconnect and programmable logic circuitry can be programmed by loading configuration data into internal configuration memory cells that define how the programmable elements are configured and operate.

[0034] The PS 106 is implemented as hardwired circuitry 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 a separate 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, coprocessors, interfaces, 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 GPU architecture, a mobile processor architecture, a DSP architecture, or any other suitable architecture capable of executing computer-readable instructions or program code.

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

[0036] The NoC 108 provides connections to selected ones of the PL 104, the PS 106, and the hardwired circuit blocks 110. The NoC 108 is programmable. In the case of a programmable NoC used in conjunction with other programmable circuits, 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 NoC interfaces.

[0037] The NoC108 is manufactured as part of the SoC100 and is not physically modifiable, The NoC 108 can be programmed to establish connections between different master circuits and different slave circuits of a user circuit design. For example, the NoC 108 can include multiple programmable switches capable of establishing a packet-switched network connecting user-specified master and slave circuits. In this regard, the NoC 108 can accommodate different circuit designs, each having a different combination of master and slave circuits implemented in 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, the NoC 108 can be programmed to couple different user-specified circuits implemented within the PL 104 to the PS 106 and / or the DPE array 102, to different hardwired circuit blocks, and / or to different circuits and / or systems external to the SoC 100.

[0038] The hardwired circuit blocks 110 may include input / output (I / O) blocks and / or transceivers for sending and receiving signals to circuits and / or systems external to the SoC 100, such as a memory controller. Examples of different I / O blocks may include single-ended and pseudo-differential I / O and high-speed differential clock transceivers. Additionally, the hardwired circuit blocks 110 may be implemented to perform specific functions. Examples of hardwired circuit blocks 110 include, but are not limited to, encryption engines, digital-to-analog converters, analog-to-digital converters, etc. The hardwired circuit blocks 110 within the SoC 100 may sometimes be referred to herein as application-specific blocks.

[0039] In the example of FIG. 1, PL 104 is shown in two 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 three or more distinct regions of programmable circuitry. The particular organization of PL 104 is not intended to be limiting. Here, SoC 100 includes one or more PL regions 104, PS 106, and NoC 108. DPE array 102 may optionally be included.

[0040] In other exemplary implementations, SoC 100 may include two or more DPE arrays 102 located in different regions of the IC. In yet other examples, SoC 100 may be implemented as a multi-die IC, in which case each subsystem may be implemented on a different die. The different dies may be communicatively linked using any of a variety of available multi-die IC technologies, such as stacking the dies side-by-side on an interposer using a stacked die architecture in which the IC is implemented as a multi-chip module (MCM), etc. It should be understood that in multi-die IC examples, each die may include a single subsystem, two or more subsystems, a subsystem and another sub-subsystem, or any combination thereof.

[0041] FIG. 2 illustrates an exemplary implementation of the DPE array 102. In the example of FIG. 2, the DPE array 102 is implemented as a two-dimensional array of DPEs 204, including an SoC interface block 206. The DPE array 102 may be implemented using any of a variety of different architectures, which are described in more detail below. For purposes of illustration and not limitation, FIG. 2 illustrates the DPEs 204 arranged in aligned rows and aligned columns. However, in other embodiments, the DPEs 204 may be arranged such that the DPEs in selected rows and / or columns are horizontally inverted or flipped relative to the DPEs in adjacent rows and / or columns. In one or more other embodiments, the rows and / or columns of DPEs may be offset relative to adjacent rows and / or columns. One or more or all of the DPEs 204 may be implemented to include one or more cores, each capable of executing program code. The DPEs 204 The number, the particular placement of the DPEs 204, and / or the orientation of the DPEs 204 are not intended to be limiting.

[0042] The SoC interface block 206 can couple the DPE 204 to one or more other subsystems of the device IC 200. In one or more embodiments, the SoC interface block 206 is coupled to an adjacent DPE 204. For example, the SoC interface block 206 can be directly coupled to each DPE 204 in the lowest tier of DPEs in the DPE array 202. In an illustrative example, the SoC interface block 206 may be directly connected to DPEs 204-1, 204-2, 204-3, 204-4, 204-5, 204-6, 204-7, 204-8, 204-9, and 204-10.

[0043] 2 is provided for illustrative purposes. In other embodiments, SoC interface block 206 may be located above DPE array 202, to the left of DPE array 202 (e.g., as a column), to the right of DPE array 202 (e.g., as a column), or in multiple locations within and around DPE array 202 (e.g., as one or more intervening rows and / or columns within DPE array 202). Depending on the layout and location of SoC interface block 206, the particular DPE coupled to SoC interface block 206 may vary.

[0044] For illustrative purposes, if SoC interface block 206 is located to the left of DPE 204, SoC interface block 206 may be directly coupled to the left column of DPEs including DPE 204-1, DPE 204-11, DPE 204-21, and DPE 204-31. If SoC interface block 206 is located to the right of DPE 204, SoC interface block 206 may be directly coupled to the right column of DPEs including DPE 204-10, DPE 204-20, DPE 204-30, and DPE 204-40. If SoC interface block 206 is located on top of DPE 204, SoC interface block 206 may be coupled to an upper tier of DPEs, including DPE 204-31, DPE 204-32, DPE 204-33, DPE 204-34, DPE 204-35, DPE 204-36, DPE 204-37, DPE 204-38, DPE 204-39, and DPE 204-40. If SoC interface block 206 is located in multiple locations, the particular DPEs directly connected to SoC interface block 206 may vary. For example, if the SoC interface blocks are implemented as rows and / or columns within DPE array 202, the DPEs directly coupled to SoC interface block 206 may be the DPEs adjacent to SoC interface block 206 on one or both sides of SoC interface block 206.

[0045] The DPEs 204 are interconnected by DPE interconnects (not shown), which, taken collectively, form a DPE interconnect network. Thus, the SoC interface block 206 communicates with one or more selected DPEs 204 of the DPE array 102 that are directly connected to the SoC interface block 206, and can communicate with any DPE 204 of the DPE array 102 by utilizing the DPE interconnect network formed from the DPE interconnects implemented within each DPE 204.

[0046] The SoC interface block 206 can couple each DPE 204 in the DPE array 102 with one or more other subsystems of the SoC 100. For example, the SoC interface block 206 can couple the DPE array 102 to the NoC 108 and the PL 104. Thus, the DPE array 102 can communicate with circuit blocks implemented in either the PL 104, the PS 106, and / or the hardwired circuit block 110. For example, the SoC interface block 206 can couple selected A connection can be established between the DPE 204 and the PL 104. The SoC interface block 206 can also establish a connection between a selected DPE 204 and the NoC 108. Through the NoC 108, the selected DPE 204 can communicate with the PS 106 and / or the hardwired circuit block 110. The selected DPE 204 can communicate with the hardwired circuit block 110 via the SoC interface block 206 and the PL 104. In particular embodiments, the SoC interface block 206 can be directly coupled to one or more subsystems of the SoC 100. For example, the SoC interface block 206 may be directly coupled to the PS 106 and / or other hardwired circuit blocks 110. In particular embodiments, the hardwired circuit blocks 110 can be considered examples of ASICs.

[0047] In one or more embodiments, the DPE array 102 includes a single clock domain. Other subsystems, such as the NoC 108, PL 104, PS 106, and various hardwired circuit blocks 110, may be in one or more separate or different clock domains. Additionally, the DPE array 102 may include additional clocks that may be used to interface with the clocks of other subsystems. In particular embodiments, the SoC interface block 206 includes a clock signal generator that can generate one or more clock signals that can be provided or distributed to the DPEs 204 of the DPE array 102.

[0048] The DPE array 102 may be programmed by loading configuration data into internal configuration memory cells (also referred to herein as "configuration registers") that define the connectivity between the DPEs 204 and the SoC interface block 206 and how the DPEs 204 and the SoC interface block 206 operate. For example, if a particular DPE 204 or group of DPEs 204 communicate with a subsystem, the DPEs 204 and the SoC interface block 206 are programmed to do so. Similarly, for one or more particular DPEs 204 to communicate with one or more other DPEs 204, the DPEs are programmed to do so. The DPEs 204 and the SoC interface block 206 may be programmed by loading configuration data into configuration registers within the DPEs 204 and the SoC interface block 206, respectively. In another example, a clock signal generator that is part of the SoC interface block 206 may be programmable using configuration data to vary the clock frequency provided to the DPE array 102.

[0049] Figure 3 shows an example architecture of a DPE 204 of the DPE array 102 of Figure 2. In the example of Figure 3, the DPE 204 includes cores 302, memory modules 304, and a DPE interconnect 306. Each DPE 204 is implemented as a hardwired and programmable circuit block on the SoC 100.

[0050] Core 302 provides data processing capabilities for DPE 204. Core 302 may be implemented as any of a variety of different processing circuits. In the example of FIG. 3, core 302 includes optional program memory 308. In an exemplary implementation, core 302 is implemented as a processor capable of executing program code, e.g., computer-readable instructions. In that case, program memory 308 may be included to store instructions executed by core 302. Core 302 may be implemented, for example, as a CPU, GPU, DSP, vector processor, or other type of processor capable of executing instructions. Core 302 may be implemented using any of the various CPU and / or processor architectures described herein. In another example, core 302 is implemented as a very long instruction word (VLIW) vector processor or DSP.

[0051] In certain implementations, program memory 308 is dedicated to core 302 (e.g., core 3 302). Program memory 308 may be used only by cores of the same DPE 204. Thus, program memory 308 may be accessed only by core 302 and is not shared with other DPEs or components of other DPEs. Program memory 308 may include a single port for read and write operations. Program memory 308 may support program compression and is addressable using a memory-mapped network portion of DPE interconnect 306, which is described in more detail below. For example, via the memory-mapped network of DPE interconnect 306, program memory 308 may be loaded with program code that may be executed by core 302.

[0052] Core 302 may include configuration registers 324. Configuration registers 324 may be loaded with configuration data to control the operation of core 302. In one or more embodiments, core 302 may be activated and / or deactivated based on the configuration data loaded into configuration registers 324. In the example of Figure 3, configuration registers 324 are addressable (e.g., readable and / or writable) via a memory-mapped network of DPE interconnect 306, which is described in more detail below.

[0053] In one or more embodiments, memory module 304 may store data used and / or generated by core 302. For example, memory module 304 may store application data. Memory module 304 may include read / write memory, such as random access memory (RAM). Thus, memory module 304 may store data that may be read and consumed by core 302. Memory module 304 may also store data (e.g., results) written by core 302.

[0054] In one or more other embodiments, memory module 304 may store data, e.g., application data, that may be used and / or generated by one or more other cores of other DPEs in the DPE array. One or more other cores of a DPE may also read from and / or write to memory module 304. In particular embodiments, the other cores that may read from and / or write to memory module 304 may be cores of one or more adjacent DPEs. Another DPE that shares a boundary or border with (e.g., is adjacent to) DPE 204 is said to be an “adjacent” DPE with respect to DPE 204. By allowing core 302 and one or more other cores from adjacent DPEs to read and write to memory module 304, memory module 304 implements a shared memory that supports communication between different DPEs and / or cores that may access memory module 304.

[0055] 2, for example, DPEs 204-14, 204-16, 204-5, and 204-25 are considered neighbors of DPE 204-15. In one example, cores within each of DPEs 204-16, 204-5, and 204-25 can read from and write to the memory modules within DPE 204-15. In certain embodiments, only the neighboring DPEs adjacent to a memory module can access the memory module of DPE 204-15. For example, DPE 204-14 is adjacent to DPE 204-15 because a core of DPE 204-15 may be located between a core of DPE 204-14 and a memory module of DPE 204-15. Thus, in certain embodiments, a core of DPE 204-14 may not access the memory module of DPE 204-15.

[0056] In certain embodiments, a core of a DPE can access a memory module of another DPE. Whether a core is connected to one of the memory modules depends on the number of memory interfaces included in the memory module and whether such core is connected to an available one of the memory modules' memory interfaces. In the example above, the memory module of DPE 204-15 includes four memory interfaces, and each of the cores of DPEs 204-16, 204-5, and 204-25 is connected to such a memory interface. Core 302 in DPE 204-15 itself is connected to the fourth memory interface. Each memory interface may include one or more read and / or write channels. In certain embodiments, each memory interface includes multiple read and write channels so that a particular core attached to it can simultaneously read and / or write to multiple banks in memory module 304.

[0057] In other examples, more than four memory interfaces may be available. Such other memory interfaces may be used to enable DPEs diagonally opposite DPE 204-15 to access DPE 204-15's memory modules. For example, if cores of DPEs such as DPEs 204-14, 204-24, 204-26, 204-4, and / or 204-6 are also coupled to available memory interfaces of DPE 204-15's memory modules, such other DPEs may also access DPE 204-15's memory modules.

[0058] Memory module 304 may include configuration registers 336. Configuration registers 336 may be loaded with configuration data to control the operation of memory module 304. In the example of Figure 3, configuration registers 336 (and 324) are addressable (e.g., readable and / or writable) via a memory-mapped network of DPE interconnect 306, which is described in more detail below.

[0059] 3, DPE interconnect 306 is specific to DPE 204. DPE interconnect 306 facilitates various operations, including communication between DPE 204 and one or more other DPEs in DPE array 102 and / or communication with other subsystems of SoC 100. DPE interconnect 306 also enables configuration, control, and debugging of DPE 204.

[0060] In particular embodiments, DPE interconnect 306 is implemented as an on-chip interconnect. One example of an on-chip interconnect is an Advanced Microcontroller Bus Architecture (AMBA) eXtensible Interface (AXI) bus (e.g., or switch). The AMBA AXI bus is an embedded microcontroller bus interface for use in establishing on-chip connections between circuit blocks and / or systems. The AXI bus is provided herein as one example of an interconnect circuit that may be used with the inventive configurations described within this disclosure and, therefore, is not intended as a limitation. Other examples of interconnect circuitry may include other types of buses, crossbars, and / or other types of switches.

[0061] In one or more embodiments, DPE interconnect 306 includes two distinct networks. A first network can exchange data with other DPEs in DPE array 102 and / or other subsystems of SoC 100. For example, the first network can exchange application data. A second network can exchange data such as DPE configuration, control, and / or debug data.

[0062] In the example of FIG. 3, the first network of DPE interconnect 306 is formed from a stream switch 326 and one or more stream interfaces (not shown). For example, the stream switch 326 includes stream interfaces for connecting to each of the cores 302, memory modules 304, memory-mapped switch 332, upper DPE, left DPE, right DPE, and lower DPE. Each stream interface can include one or more masters and one or more slaves.

[0063] The stream switch 326 can enable non-adjacent DPEs and / or DPEs not coupled to the memory interfaces of the memory modules 304 to communicate with the cores 302 and / or memory modules 304 via a DPE interconnect network formed by the DPE interconnects of each DPE 204 in the DPE array 102.

[0064] 2 and using DPE 204-15 as a reference point, stream switch 326 is coupled to and can communicate with another stream switch located in the DPE interconnect of DPE 204-14. Stream switch 326 is coupled to and can communicate with another stream switch located in the DPE interconnect of DPE 204-25. Stream switch 326 is coupled to and can communicate with another stream switch located in the DPE interconnect of DPE 204-16. Stream switch 326 is coupled to and can communicate with another stream switch located in the DPE interconnect of DPE 204-5. Thus, core 302 and / or memory module 304 can also communicate with any of the DPEs in DPE array 102 via the DPE interconnect within the DPEs.

[0065] The stream switch 326 may also be used to interface with subsystems such as the PL 104 and / or NoC 108. Generally, the stream switch 326 is programmed to operate as either a circuit-switched stream interconnect or a packet-switched stream interconnect. A circuit-switched stream interconnect can implement point-to-point dedicated streams suitable for high-bandwidth communication between DPEs. A packet-switched stream interconnect allows for stream sharing, time-multiplexing multiple logical streams into one physical stream for medium-bandwidth communication.

[0066] The stream switch 326 may include a configuration register (abbreviated as "CR" in FIG. 3) 334. Configuration data may be written to the configuration register 334 via the memory-mapped network of the DPE interconnect 306. The configuration data loaded into the configuration register 334 dictates with which other DPEs and / or subsystems (e.g., NoC 108, PL 104, and / or PS 106) the DPE 204 will communicate, and whether such communications will be established as circuit-switched, point-to-point connections or as packet-switched connections.

[0067] The second network of DPE interconnect 306 is formed from memory-mapped switch 332. Memory-mapped switch 332 includes multiple memory-mapped interfaces (not shown). Each memory-mapped interface may include one or more masters and one or more slaves. For example, memory-mapped switch 332 includes memory-mapped interfaces for connecting to each of cores 302, memory modules 304, memory-mapped switches in DPEs above DPE 204, and memory-mapped switches in DPEs below DPE 204.

[0068] The memory mapped switch 332 is used to communicate configuration, control, and debug data for the DPE 204. In the example of FIG. 3. The memory-mapped switch 332 may receive configuration data used to configure the DPE 204. The memory-mapped switch 332 may receive configuration data from a DPE located below the DPE 204 and / or from the SoC interface block 206. The memory-mapped switch 332 may forward the received configuration data to one or more other DPEs above the DPE 204, the core 302 (e.g., program memory 308 and / or configuration registers 324), the memory module 304 (e.g., memory and / or configuration registers 336 in the memory module 304), and / or the configuration registers 334 in the stream switch 326.

[0069] The DPE interconnect 306 is coupled to the DPE interconnect of each adjacent DPE and / or SoC interface block 206, depending on the location of the DPE 204. Taken together, the DPE interconnects of the DPEs 204 form a DPE interconnect network (which may include a stream network and / or a memory-mapped network). The configuration registers of each DPE's stream switch can be programmed by loading configuration data through the memory-mapped switch. Through configuration, the stream switch and / or stream interface are programmed to establish connections with other endpoints, whether packet-switched or circuit-switched, whether in one or more other DPEs 204 and / or SoC interface blocks 206.

[0070] In one or more embodiments, the DPE array 102 is mapped into the address space of a processor system, such as the PS 106. Thus, any configuration register and / or memory within the DPE 204 can be accessed via a memory-mapped interface. For example, memory within memory module 304, program memory 308, configuration register 324 within core 302, configuration register 336 within memory module 304, and / or configuration register 334 can be read and / or written via memory-mapped switch 332.

[0071] In the example of Figure 3, the memory-mapped interface can receive configuration data for the DPE 204. The configuration data can include program code (if included) to be loaded into the program memory 308, configuration data for loading into the configuration registers 324, 334, and / or 336, and / or data to be loaded into the memory (e.g., memory banks) of the memory module 304. In the example of Figure 3, the configuration registers 324, 334, and 336 are shown as being located within the particular circuit structures that the configuration registers are intended to control, e.g., the core 302, the stream switch 326, and the memory module 304. The example of Figure 3 is for illustrative purposes only and illustrates that elements within the core 302, the memory module 304, and / or the stream switch 326 may be programmed by loading configuration data into the corresponding configuration registers. In other embodiments, the configuration registers may be consolidated within particular regions of the DPE 204, despite controlling the operation of components distributed throughout the DPE 204.

[0072] Thus, the stream switch 326 may be programmed by loading configuration data into the configuration registers 334. The configuration data programs the stream switch 326 to operate in circuit switching mode between two different DPEs and / or other subsystems, or in packet switching mode between selected DPEs and / or other subsystems. Thus, the connections established by the stream switch 326 to other stream interfaces and / or switches are programmed by loading the appropriate configuration data into the configuration registers 334 to establish the actual connections or application data paths within the DPE 204, other DPEs, and / or other subsystems of the IC 300.

[0073] Figure 4 illustrates further aspects of the exemplary architecture of Figure 3. In the example of Figure 4, details regarding the DPE interconnect 306 are not shown. Figure 4 illustrates connectivity between the core 302 and other DPEs via shared memory. Figure 4 also illustrates additional aspects of the memory module 304. For illustrative purposes, Figure 4 references DPE 204-15.

[0074] As shown, memory module 304 includes multiple memory interfaces 402, 404, 406, and 408. In FIG. 4, memory interfaces 402 and 408 are abbreviated as "MI." Memory module 304 further includes multiple memory banks 412-1 through 412-N. In particular embodiments, memory module 304 includes eight memory banks. In other embodiments, memory module 304 may include fewer or more memory banks 412. In one or more embodiments, each memory bank 412 is single-ported, thereby allowing a maximum of one access to each memory bank per clock cycle. If memory module 304 includes eight memory banks 412, such a configuration supports eight parallel accesses per clock cycle. In other embodiments, each memory bank 412 is dual-ported or multi-ported, thereby allowing more parallel accesses per clock cycle.

[0075] In the example of FIG. 4, each of memory banks 412-1 through 412-N includes a respective arbiter 414-1 through 414-N. Each arbiter 414 can generate a stall signal in response to detecting a conflict. Each arbiter 414 can include arbitration logic. Additionally, each arbiter 414 can include a crossbar. Thus, any master can write to any particular one or more of memory banks 412. As described in connection with FIG. 3, memory module 304 is connected to memory-mapped switch 332, thereby facilitating the reading and writing of data to memory banks 412. Thus, certain data stored in memory module 304 can be controlled, e.g., written, as part of a configuration, control, and / or debug process via memory-mapped switch 332.

[0076] Memory module 304 further includes a direct memory access (DMA) engine 416. In one or more embodiments, DMA engine 416 includes at least two interfaces. For example, one or more interfaces can receive an input data stream from DPE interconnect 306 and write the received data to memory banks 412. One or more other interfaces can read data from memory banks 412 and send the data through a stream interface (e.g., a stream switch) of DPE interconnect 306. For example, DMA engine 416 can include a stream interface for accessing stream switch 326 of FIG. 3.

[0077] The memory module 304 can operate as a shared memory that can be accessed by multiple different DPEs. In the example of FIG. 4 , the memory interface 402 is coupled to the core 302 via a core interface 428 included in the core 302. The memory interface 402 provides the core 302 with access to the memory bank 412 via an arbiter 414. The memory interface 404 is coupled to the core of the DPE 204-25. The memory interface 404 provides the core of the DPE 204-25 with access to the memory bank 412. The memory interface 406 is coupled to the core of the DPE 204-16. The memory interface 406 provides the core of the DPE 204-16 with access to the memory bank 412. The memory interface 408 is coupled to the core of the DPE 204-5. The memory interface 408 provides the core of the DPE 204-5 with access to the memory bank 412. Thus, in the example of FIG. 4 , the memory interface 402 is coupled to the core of the DPE 204-25. The memory interface 406 provides the core of the DPE 204-25 with access to the memory bank 412. Each DPE that has a shared boundary with memory module 304 of DPE 204-15 can read and write to memory bank 412. In the example of Figure 4, the core of DPE 204-14 cannot directly access memory module 304 of DPE 204-15.

[0078] Core 302 can access memory modules of other adjacent DPEs via core interfaces 430, 432, and 434. In the example of FIG. 4, core interface 434 is coupled to the memory interface of DPE 204-25. Thus, core 302 can access the memory module of DPE 204-25 via core interface 434 and the memory interface included in the memory module of DPE 204-25. Core interface 432 is coupled to the memory interface of DPE 204-14. Thus, core 302 can access the memory module of DPE 204-14 via core interface 432 and the memory interface included in the memory module of DPE 204-14. Core interface 430 is coupled to the memory interface in DPE 204-5. Thus, core 302 can access the memory module of DPE 204-5 via core interface 430 and the memory interface included in the memory module of DPE 204-5. As explained, the core 302 can access the memory module 304 within the DPE 204-15 via the core interface 428 and the memory interface 402.

[0079] In the example of Figure 4, core 302 can read from and write to any of the memory modules of the DPEs that share a boundary with core 302 in DPE 204-15 (e.g., DPEs 204-25, 204-14, and 204-5). In one or more embodiments, core 302 can view the memory modules in DPEs 204-25, 204-15, 204-14, and 204-5 as a single contiguous memory (e.g., as a single address space). Core 302 can generate addresses for reads and writes assuming this contiguous memory model. Based on the generated addresses, core 302 can direct read and / or write requests to the appropriate core interfaces 428, 430, 432, and / or 434.

[0080] As described above, core 302 can map read and / or write operations to the correct direction through core interfaces 428, 430, 432, and / or 434 based on the address of such operations. When core 302 generates an address for a memory access, core 302 can decode the address to determine the direction (e.g., the particular DPE to be accessed) and forward the memory operation to the correct core interface in the determined direction.

[0081] Thus, core 302 can communicate with cores of DPE 204-25 via shared memory, which may be a memory module within DPE 204-25 and / or memory module 304 of DPE 204-15. Core 302 can communicate with cores of DPE 204-14 via shared memory, which may be a memory module within DPE 204-14. Core 302 can communicate with cores of DPE 204-5 via shared memory, which may be a memory module within DPE 204-5 and / or memory module 304 of DPE 204-15. Additionally, core 302 can communicate with cores of DPE 204-16 via shared memory, which may be memory module 304 within DPE 204-15.

[0082] As described, the DMA engine 416 may include one or more stream-memory interfaces. Through the DMA engine 416, application data may be received from other sources within the SoC 100 and stored in the memory module 304. For example, data may be received by the stream switch 326 from other DPEs that may or may not share a boundary with the DPE 204-15. Data may also be received by the SoC interface block 206 from other subsystems of the SoC (e.g., the NoC 108, the hardwired circuit block 110, the PL 104, and / or the PS 106) via the DPE's stream switch. The DMA engine 416 can receive such data from the stream switch and write the data to the appropriate memory bank or banks 412 within the memory module 304.

[0083] The DMA engine 416 may include one or more memory-to-stream interfaces. Via the DMA engine 416, data may be read from the memory bank or memory bank 412 of the memory module 304 and sent to other destinations via the stream interface. For example, the DMA engine 416 may read data from the memory module 304 and send such data to other DPEs that may or may not share a boundary with the DPE 204-15 via a stream switch. The DMA engine 416 may also send such data to other subsystems (e.g., the NoC 108, the hardwired circuit block 110, the PL 104, and / or the PS 106) via the stream switch and the SoC interface block 206.

[0084] In one or more embodiments, the DMA engine 416 is programmed by a memory-mapped switch 332 in the DPE 204-15. For example, the DMA engine 416 may be controlled by a configuration register 336. The configuration register 336 may be written using the memory-mapped switch 332 of the DPE interconnect 306. In particular embodiments, the DMA engine 416 may be controlled by a stream switch 326 in the DPE 204-15. For example, the DMA engine 416 may include control registers that may be written by the stream switch 326 connected to it. Streams received through the stream switch 326 in the DPE interconnect 306 may be connected to the DMA engine 416 in the memory module 304 and / or directly to the core 302 depending on the configuration data loaded into the configuration registers 324, 334, and / or 336. The streams may be sent from the DMA engine 416 (eg, memory module 304 ) and / or core 302 depending on the configuration data loaded into configuration registers 324 , 334 and / or 336 .

[0085] Memory module 304 may further include a hardware synchronization circuit 420 (abbreviated as "HSC" in FIG. 4). Generally, hardware synchronization circuit 420 may synchronize the operation of different cores (e.g., cores of adjacent DPEs), cores 302 of FIG. 4, DMA engine 416, and other external masters (e.g., PS 106) that may communicate via DPE interconnect 306. As an illustrative and non-limiting example, hardware synchronization circuit 420 may synchronize two different cores, stream switches, memory-mapped interfaces, and / or DMAs in different DPEs that access the same, e.g., shared, buffer in DPE 204-15 and / or memory module 304.

[0086] If two DPEs are not adjacent, the two DPEs cannot access a common memory module. In that case, application data may be transferred via a data stream (the terms "data stream" and "stream" may sometimes be used interchangeably within this disclosure). Thus, a local DMA engine may convert the transfer from a local memory-based transfer to a stream-based transfer. In that case, the core 302 and the DMA engine 416 may be synchronized using a hardware synchronization circuit 420.

[0087] The PS 106 can communicate with the core 302 via the memory-mapped switch 332. For example, the PS 106 can access the memory module 304 and the hardware synchronization circuit 420 by initiating memory reads and writes. In another embodiment, the hardware synchronization circuit 420 may also send an interrupt to the PS 106 when the state of the lock changes, avoiding the PS 106 polling the hardware synchronization circuit 420. The PS 106 can also communicate with the DPE 204-15 via a stream interface.

[0088] In addition to communicating with adjacent DPEs via a shared memory module and adjacent and / or non-adjacent DPEs via DPE interconnect 306, core 302 may include cascade interfaces. In the example of FIG. 4, core 302 includes cascade interfaces 422 and 424 (abbreviated as "CI" in FIG. 4). Cascade interfaces 422 and 424 may provide direct communication with other cores. As shown, cascade interface 422 of core 302 receives input data streams directly from cores of DPE 204-14. The data streams received via cascade interface 422 may be provided to data processing circuitry within core 302. Cascade interface 424 of core 302 may send output data streams directly to cores of DPE 204-16.

[0089] In the example of FIG. 4 , each of cascade interface 422 and cascade interface 424 may include a first-in, first-out (FIFO) interface for buffering. In particular embodiments, cascade interfaces 422 and 424 may carry data streams that may be hundreds of bits wide. The particular bit widths of cascade interfaces 422 and 424 are not intended as limitations. In the example of FIG. 4 , cascade interface 424 is coupled to an accumulator register 436 (abbreviated as “AC” in FIG. 4 ) within core 302. Cascade interface 424 may output the contents of accumulator register 436, and may do so every clock cycle. Accumulation register 436 may store data generated and / or operated on by data processing circuitry within core 302.

[0090] 4, cascade interfaces 422 and 424 may be programmed based on configuration data loaded into configuration registers 324. For example, cascade interface 422 may be activated or deactivated based on configuration registers 324. Similarly, cascade interface 424 may be activated or deactivated based on configuration registers 324. Cascade interface 422 may be activated and / or deactivated independently of cascade interface 424.

[0091] In one or more other embodiments, cascade interfaces 422 and 424 are controlled by core 302. For example, core 302 may include instructions for reading from and writing to cascade interfaces 422 and / or 424. In another example, core 302 may include hardwired circuitry capable of reading from and / or writing to cascade interfaces 422 and / or 424. In particular embodiments, cascade interfaces 422 and 424 may be controlled by an entity external to core 302.

[0092] In the embodiment described within this disclosure, the DPE 204 does not include a cache memory. By omitting a cache memory, the DPE array 202 can achieve predictable, e.g., deterministic, performance. Furthermore, there is no need to maintain consistency between cache memories located in different DPEs, thereby avoiding significant processing overhead.

[0093] According to one or more embodiments, the cores 302 of the DPE 204 do not have incoming interrupts. Thus, the cores 302 of the DPE 204 can operate uninterrupted. Eliminating incoming interrupts to the cores 302 of the DPE 204 also allows the DPE array a02 to achieve predictable, e.g., deterministic, performance.

[0094] Figure 5 shows another exemplary architecture of a DPE array. In the example of Figure 5, an SoC interface block 206 provides an interface between the DPE 204 and other subsystems of the SoC 100. The SoC interface block 206 integrates the DPE into the device. The SoC interface block 206 can communicate configuration data to the DPE 204, communicate events from the DPE 204 to other subsystems, communicate events from other subsystems to the DPE 204, generate and communicate interrupts to entities external to the DPE array 102, communicate application data between the other subsystems and the DPE 204, and / or communicate trace and / or debug data between the other subsystems and the DPE 204.

[0095] In the example of FIG. 5, SoC interface block 206 includes multiple interconnected tiles. For example, SoC interface block 206 includes tiles 502, 504, 506, 508, 510, 512, 514, 516, 518, and 520. In the example of FIG. 5, tiles 502-520 are organized in a row. In other embodiments, tiles may be arranged in a column, a grid, or another layout. For example, SoC interface block 206 may be implemented as a column of tiles to the left of DPE 204, to the right of DPE 204, between columns of DPE 204, etc. In another embodiment, SoC interface block 206 may be located above DPE array 202. SoC interface block 206 may be implemented such that tiles are located in any combination below DPE array 202, to the left of DPE array 202, to the right of DPE array 202, and / or above DPE array 202. In this regard, FIG. 5 is provided for purposes of illustration and not limitation.

[0096] In one or more embodiments, tiles 502-520 have the same architecture. In one or more other embodiments, tiles 502-520 may be implemented with two or more different architectures. In particular embodiments, different architectures may be used to implement tiles within SoC interface block 206, with each different tile architecture supporting communication with a different type or combination of subsystems of SoC 100.

[0097] In the example of FIG. 5, tiles 502-520 are coupled such that data can propagate from one tile to another. For example, data can propagate from tile 502, through tiles 504 and 506, down the line of tiles to tile 520. Similarly, data can propagate in the reverse direction from tile 520 to tile 502. In one or more embodiments, each of tiles 502-520 can interface with multiple DPEs. For example, each of tiles 502-520 can interface with a subset of DPEs 204 in DPE array 102. The subset of DPEs to which each tile interfaces can be mutually exclusive, such that a DPE is not interfaced by multiple tiles in SoC interface block 206.

[0098] In one example, tiles 502-520 each provide an interface for a row of DPEs 204. For purposes of illustration, tile 502 provides an interface to DPEs in row A. Tile 504 provides an interface to DPEs in row B. In either case, A tile also includes a direct connection to an adjacent DPE in a row of DPEs, which in this example is the bottom DPE. Referring to row A, for example, tile 502 is directly connected to DPE 204-1. Other DPEs in row A can communicate with tile 502, but through the DPE interconnects of intervening DPEs in the same row.

[0099] For example, tile 502 may receive data from another source, such as PS 106, PL 104, and / or another hardwired circuit block 110, e.g., an ASIC block. Tile 502 may provide those portions of data addressed to DPEs in column A to such DPEs, while transmitting data addressed to DPEs in other columns (e.g., DPEs to which tile 502 does not interface) onto tile 504. Tile 504 may transmit data addressed to DPEs in other columns to tile 506, while performing the same or similar processing where data received from tile 502 addressed to DPEs in column B is provided to such DPEs.

[0100] In this way, data can propagate from tile to tile in the SoC interface block 206 until it reaches the tile that acts as the interface for the DPE to which the data is addressed (e.g., the "target DPE") The tile that acts as the interface for the target DPE can direct the data to the target DPE using the DPE's memory-mapped switch and / or the DPE's stream switch.

[0101] As noted above, the use of columns is an exemplary implementation. In other embodiments, each tile of SoC interface block 206 may provide an interface to a row of DPEs in DPE array 102. Such a configuration may be used when SoC interface block 206 is implemented as a column of tiles, whether to the left, right, or between columns of DPEs 204. In other embodiments, the subset of DPEs to which each tile provides an interface may be any combination of fewer than all DPEs in DPE array 102. For example, DPEs 204 may be assigned to tiles in SoC interface block 206. The specific physical layout of such DPEs may vary based on the DPE connectivity established by the DPE interconnect. For example, tile 502 may provide interfaces to DPEs 204-1, 204-2, 204-11, and 204-12. Another tile of SoC interface block 206 may provide interfaces to four other DPEs, etc.

[0102] 6 shows an example architecture of tiles for SoC interface block 206. In the example of FIG. 6, two different types of tiles for SoC interface block 206 are shown. Tile 602 is configured to function as an interface between only the DPE and PL 104. Tile 610 is configured to function as an interface between the DPE and NoC 108 and between the DPE and PL 104. SoC interface block 206 can include a combination of tiles using both architectures as illustrated for tile 602 and tile 610, or in another example, can include only tiles having the architecture as illustrated for tile 610.

[0103] 6, tile 602 includes a PL interface 606 and a stream switch 604 connected to a DPE, such as DPE 204-1, directly above it. PL interface 606 connects to a boundary logic interface (BLI) circuit 620 and a BLI circuit 622, each located within PL 104. Tile 610 includes an NoC and PL interface 614 and a stream switch 612 connected to a DPE, such as DPE 204-5, directly above it. NoC and PL interface 614 connects to a BLI circuit 624 within PL 104. and 626 , as well as NoC Master Unit (NMU) 630 and NoC Slave Unit (NSU) 632 of NoC 108 .

[0104] 6, each stream interface 604 can output six different 32-bit data streams to its coupled DPE and receive four different 32-bit data streams therefrom. PL interface 606 and NoC-and-PL interface 614 can each provide six different 64-bit data streams to PL 104 via BLI 620 and BLI 624, respectively. In general, each of BLIs 620, 622, 624, and 626 provides an interface or connection point within PL 104 to which PL interface 606 and / or NoC-and-PL interface 614 connect. PL interface 606 and NoC-and-PL interface 614 can each receive eight different 64-bit data streams from PL 210 via BLI 622 and BLI 624, respectively.

[0105] The NoC and PL interface 614 is also connected to the NoC 108. In the example of Figure 6, the NoC and PL interface 614 connects to one or more NMUs 630 and one or more NSUs 632. In one example, the NoC and PL interface 614 can provide two different 128-bit data streams to the NoC 108, each data stream being provided to a different NMU 630. The NoC and PL interface 614 can receive two different 128-bit data streams from the NoC 108, each data stream being received from a different NSU 632.

[0106] The stream switches 604 of adjacent tiles are connected. In one example, the stream switches 604 in adjacent tiles can communicate with four different 32-bit data streams in each of the left and right directions (e.g., as far as the tiles are to the right or left, as the case may be).

[0107] Each tile 602 and 610 may include one or more memory-mapped switches for communicating configuration data. For purposes of illustration, the memory-mapped switches are not shown. The memory-mapped switches may, for example, be vertically connected to memory-mapped switches in other adjacent tiles in the SoC interface block 206 in the same or similar manner as the memory-mapped switches of the DPE immediately above, the stream switches 604, configuration registers in the tiles 602 and 610 (not shown), and / or the PL interface 608 or the NoC and PL interface 614, as the case may be.

[0108] The various bit widths and numbers of data streams described in connection with the various switches included in DPE 204 and / or tiles 602 and / or 610 of SoC interface block 206 are provided for illustrative purposes and are not intended to limit the inventive configurations described within this disclosure.

[0109] FIG. 7 illustrates an exemplary implementation of the NoC 108. The NoC 108 includes an NoC master unit (NMU) 702, an NoC slave unit (NSU) 704, a network 714, an NoC peripheral interconnect (NPI) 710, and a register 712. Each NMU 702 is an ingress circuit connecting an endpoint circuit to the NoC 108. Each NSU 704 is an egress circuit connecting the NoC 108 to an endpoint circuit. The NMUs 702 are connected to the NSUs 704 via a network 714. In one example, the network 714 includes NoC packet switches 706 (NPSs) and routing 708 between the NoC packet switches 706. Each NoC packet switch 706 switches NoC packets. The NoC packet switches 706 are connected to each other and to the NMUs 702 and NSUs 704 via the routing 708 to implement multiple physical channels. The oC packet switch 706 also supports multiple virtual channels per physical channel.

[0110] The NPI 710 includes circuitry for programming the NMU 702, NSU 704, and NoC packet switch 706. For example, the NMU 702, NSU 704, and NoC packet switch 706 may include registers 712 that determine their functionality. The NPI 710 includes peripheral interconnects coupled to the registers 712 for programming to set functions. The registers 712 in the NoC 108 support interrupts, quality of service (QoS), error handling and reporting, transaction control, power management, and address mapping control. The registers 712 may be initialized to a usable state before being reprogrammed, such as by writing to the registers 712 using a write request. Configuration data for the NoC 108 may be stored in nonvolatile memory (NVM), for example, as part of a programming device image (PDI), and provided to the NPI 710 for programming the NoC 108 and / or other endpoint circuits.

[0111] NMU 702 is a traffic entry point. NSU 704 is a traffic exit point. The endpoint circuitry coupled to NMU 702 and NSU 704 can be hardened circuitry (e.g., hardwired circuit block 110) or circuitry implemented in PL 104. A given endpoint circuit can be coupled to multiple NMUs 702 or multiple NSUs 704.

[0112] 8 is a block diagram illustrating connections between endpoint circuits within SoC 100 via NoC 108, according to an example. In this example, endpoint circuit 802 is connected to endpoint circuit 804 via NoC 108. Endpoint circuit 802 is a master circuit coupled to NMU 702 of NoC 108. Endpoint circuit 804 is a slave circuit coupled to NSU 704 of NoC 108. Each endpoint circuit 802 and 804 may be a circuit within PS 106, a circuit within PL domain 104, or a circuit within another subsystem (e.g., hardwired circuit block 110).

[0113] The network 714 includes multiple physical channels 806. The physical channels 806 are implemented by programming the NoC 108. Each physical channel 806 includes one or more NoC packet switches 706 and associated routing 708. The NMU 702 connects with the NSU 704 through at least one physical channel 806. A physical channel 806 may also have one or more virtual channels 808.

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

[0115] 9 is a block diagram illustrating an NoC 108 according to another example. In this example, the NoC 108 includes vertical portions 902 (VNoCs) and horizontal portions 904 (HNoCs). Each VNoC 902 is disposed between PL regions 104. The HNoCs 904 are disposed between the PL regions 104 and I / O banks 910 (e.g., I / O blocks and / or transceivers corresponding to hardwired circuit blocks 110). The NoCs 108 are connected to memory interfaces 908 (e.g., other hardwired circuit blocks 110). The PS 106 is coupled to the HNoCs 904.

[0116] In this example, the PS 106 includes multiple NMUs 702 coupled to a HNoC 904. The VNoC 902 includes both the NMUs 702 and NSUs 704 located within the PL region 104. The memory interface 908 includes NSUs 704 coupled to the HNoC 904. Both the HNoC 904 and the VNoC 902 include NPSs 706 connected by routing 708. In the VNoC 902, the routing 708 extends vertically. In the HNoC 904, the routing extends horizontally. In each VNoC 902, each NMU 702 is coupled to an NPS 706. Similarly, each NSU 704 is coupled to an NPS 706. The NPSs 706 are coupled to each other to form a matrix of switches. Some NPSs 706 in each VNoC 902 are coupled to other NPSs 706 in the HNoC 904.

[0117] Although only a single HNoC 904 is shown, in other examples, the NoC 108 can include multiple HNoCs 904. Additionally, while two VNoCs 902 are shown, the NoC 108 can include more than two VNoCs 902. While the memory interface 908 is shown by way of example, it should be understood that other hardwired circuit blocks 110 can be used in place of or in addition to the memory interface 908.

[0118] 10 illustrates an exemplary method 1000 for programming NoC 108. Although described independently of other subsystems of SoC 100, method 1000 may be included and / or used as part of a larger boot or programming process of SoC 100.

[0119] In block 1002, a platform management controller (PMC) implemented in the SoC 100 receives NoC programming data at boot time. The NoC programming data may be part of the PDI. The PMC is responsible for managing the SoC 100. The PMC can maintain a safe and secure environment, boot the SoC 100, and manage the SoC 100 during normal operation.

[0120] In block 1004, the PMC loads NoC programming data into registers 712 via NPI 710 to create physical channel 806. In one example, the programming data may also include information for configuring routing tables in NPS 706. In block 1006, the PMC boots SoC 100. Thus, NoC 108 includes configuration information for at least physical channel 806 between NMU 702 and NSU 704. The remaining configuration information for NoC 108 may be received during runtime, as described further below. In another example, all or part of the configuration information described below as being received during runtime may be received at boot time.

[0121] 11 illustrates an example method 1100 for programming the NoC 108. In block 1102, the PMC receives NoC programming data during runtime. In block 1104, the PMC loads the programming data into the NoC registers 712 via the NPI 710. In one example, in block 1106, the PMC configures routing tables in the NPS 706. In block 1108, the PMC configures QoS paths on the physical channel 806. In block 1110, the PMC configures address space mapping. In block 1112, the PMC sets ingress / egress interface protocols, widths, and frequencies. QoS paths, address space mapping, routing tables, and ingress / egress configuration are described further below.

[0122] 12 illustrates an exemplary data path 1200 through NoC 108 between endpoint circuits. Data path 1200 includes endpoint circuit 1202, AXI master circuit 1204, NMU 1206, NPS 1208, NSU 1210, AXI slave circuit 1212, and endpoint circuit 1214. Endpoint circuit 1202 is coupled to AXI master circuit 1204. AXI master circuit 1204 is coupled to NMU 1206. In another example, the AXI master circuit 1204 is part of the NMU 1206.

[0123] The NMU 1206 is coupled to the NPS 1208. The NPSs 1208 are connected to each other to form a chain of NPSs 1208 (e.g., a chain of five NPSs 1208 in this example). Generally, there is at least one NPS 1208 between the NMU 1206 and the NSU 1210. The NSU 1210 is connected to one of the NPSs 1208. The AXI slave circuit 1212 is coupled to the NSU 1210. In another example, the AXI slave circuit 1212 is part of the NSU 1210. The endpoint circuit 1214 is coupled to the AXI slave circuit 1212.

[0124] The endpoint circuits 1202 and 1214 can be hardened circuits (e.g., PS circuits, hardwired circuits 110, one or more DPEs 204) or circuits configured in the PL 104. The endpoint circuit 1202 acts as a master circuit and sends read / write requests to the NMU 1206. In this example, the endpoint circuits 1202 and 1214 communicate with the NoC 108 using the AXI protocol. While AXI is described in this example, it should be understood that the NoC 108 may be configured to receive communications from the endpoint circuits using other types of protocols known in the art. For clarity by example, the NoC 108 is described herein as supporting the AXI protocol. The NMU 1206 relays the request through the set of NPSs 1208 to reach the destination NSU 1210. The NSU 1210 passes the request to an attached AXI slave circuit 1212 for processing and distribution of the data to the endpoint circuit 1214. The AXI slave circuit 1212 can send the read / write response back to the NSU 1210. The NSU 1210 can forward the response to the NMU 1206 via the set of NPSs 1208. The NMU 1206 communicates the response to the AXI master circuit 1204, which delivers the data to the endpoint circuit 1202.

[0125] FIG. 13 illustrates an example method 1300 for processing read / write requests and responses. The method 1300 begins at block 1302, where the endpoint circuit 1202 sends a request (e.g., a read request or a write request) to the NMU 1206 via the AXI master 1204. At block 1304, the NMU 1206 processes the response. In one example, the NMU 1206 performs asynchronous crossover and rate matching between the clock domain of the endpoint circuit 1202 and the NoC 108. The NMU 1206 determines the destination address of the NSU 1210 based on the request. The NMU 1206 can perform address remapping if virtualization is used. The NMU 1206 also performs AXI translation of the request. The NMU 1206 further packetizes the request into a stream of packets.

[0126] In block 1306, the NMU 1206 sends the request packet to the NPS 1208. Each NPS 1208 performs a table lookup for the target output port based on the destination address and routing information. In block 1308, the NSU 1210 processes the request packet. In one example, the NSU 1210 depacketizes the request, performs AXI conversion, and performs asynchronous crossover and rate matching from the NoC clock domain to the clock domain of the endpoint circuit 1214. In block 1310, the NSU 1210 sends the request to the endpoint circuit 1214 via the AXI slave circuit 1212. The NSU 1210 can also receive a response from the endpoint circuit 1214 via the AXI slave circuit 1212.

[0127] In block 1312, the NSU 1210 processes the response. In one example, the NSU 1210 performs asynchronous crossover and rate matching from the clock domain of the endpoint circuit 1214 and the clock domain of the NoC 108. The NSU 1210 also packetizes the response into a stream of packets. In block 1314, the NSU 1210 The endpoint circuit 1202 then sends the packet via the NPS 1208. Each NPS 1208 performs a table lookup for the target output port based on the destination address and routing information. In block 1316, the NMU 1206 processes the packet. In one example, the NMU 1206 depacketizes the response, performs AXI conversion, and performs asynchronous crossing and rate matching from the NoC clock domain to the clock domain of the endpoint circuit 1202. In block 1318, the NMU 1206 sends the response to the endpoint circuit 1202 via the AXI master circuit 1204.

[0128] FIG. 14 shows an exemplary implementation of the NMU 702. The NMU 702 includes an AXI master interface 1402, a packetization circuit 1404, an address map 1406, a depacketization circuit 1408, a QoS circuit 1410, a VC mapping circuit 1412, and a clock management circuit 1414. The AXI master interface 1402 provides the NMU 702 with an AXI interface for the endpoint circuits. In other examples, different protocols may be used, and thus the NMU 702 may have different master interfaces that conform to the selected protocols. The NMU 702 routes inbound traffic to the packetization circuit 1404, which generates packets from the inbound data. The packetization circuit 1404 determines a destination ID from the address map 1406, which is used to route the packet. The destination ID is used within the NoC 108 to specify the destination interface to which the packet is being sent. The QoS circuit 1410 can provide ingress rate control to control the injection rate of packets into the NoC 108. The VC mapping circuit 1412 manages the QoS virtual channels on each physical channel. The NMU 702 can be configured to select which virtual channel a packet is mapped to. The clock management circuit 1414 performs rate matching and asynchronous data crossing to provide an interface between the AXI clock domain and the NoC clock domain. The depacketization circuit 1408 is configured to receive return packets from the NoC 108 and depacketize the packets for output by the AXI master interface 1402.

[0129] FIG. 15 shows an exemplary implementation of the NSU 704. The NSU 704 includes an AXI slave interface 1502, a clock management circuit 1504, a packetization circuit 1508, a depacketization circuit 1506, and a QoS circuit 1510. The AXI slave interface 1502 provides the NSU 704 with an AXI interface for the endpoint circuits. In other examples, different protocols may be used, and thus the NSU 704 may have different slave interfaces that conform to the selected protocols. The NSU 704 routes inbound traffic from the NoC 108 to the depacketization circuit 1506, which generates depacketized data. The clock management circuit 1504 performs rate matching and asynchronous data crossing to provide an interface between the AXI clock domain and the NoC clock domain. The packetization circuit 1508 is configured to receive return data from the slave interface 1502 and packetize the return data for transmission through the NoC 108. QoS circuitry 1510 may provide ingress rate control for controlling the rate at which packets are injected into NoC 108 .

[0130] 16 illustrates an exemplary connection to a register block 712 of an NoC 108 via an NPI 710. To connect to the register block 712, the NPI 710 includes a root node 1604, one or more NPI switches 1608, and a protocol block 1610. The root node 1604, in some examples, resides in a PMC 1602. In some examples, the PMC 1602 resides within the PS 106, but in other examples, the root node 1604 and the PMC 1602 may be separate circuits or may reside on different systems or circuits. In general, the root node 1604 routes transaction requests to the NPI 16. The memory-mapped transaction request may be packetized into a format implemented by the NPI 710 and sent to the NPI switch 1608, which may further send the memory-mapped transaction request to another NPI switch 1608 or to the protocol block 1610 based on the destination identification of the memory-mapped transaction request. The NPI switches 1608 may be interconnected in any suitable topology. In some examples, the NPI switches 1608 are interconnected to the root node 1604 as a tree topology. The protocol block 1610 may then convert the memory-mapped transaction request into a format implemented by the register block 712. The register block 712 is shown in FIG. 16 as an example of a slave endpoint circuit to which the NPI 710 may be connected. The NPI 710 may be further connected to other slave endpoint circuits.

[0131] PMC 1602 is further connected to configuration interconnect 1612, which is connected to PL region 104. PMC 1602 is configured to program the fabric of PL region 104 via configuration interconnect 1612. Configuration interconnect 1612 is a distribution mechanism for programming programmable units on SoC 100 that is independent of the distribution mechanism of NPI 710 for programming other programmable units (e.g., slave endpoint circuits) on SoC 100.

[0132] As previously described, the register block 712 includes registers programmed to create a corresponding routing table for the NPS 706. FIG. 17 illustrates a routing table 1700, according to one example. The routing table 1700 packs registers according to a destination identification. Each packet received by the NPS 706 and subsequently transmitted includes a destination identification used by the routing table 1700 to transmit and route the packet. In this example, the NPS 706 has four ports (Ports 0-3) and eight virtual channels (VCs 0-7). Rows in the routing table correspond to the port-virtual channel combinations (Port-VCs) on which the packets are received. Columns in the routing table correspond to the destination identifications (IDs) included in the received packets. An entry in the routing table indicates the outgoing port to which the packet is to be transmitted based on the Port-VC and ID. In some examples, an entry for a given ID is packed into one or more registers in the register block 712. Predefined bits in one or more registers are entries in the routing table, and the predefined bits correspond to the Port-VCs. NPS706 is configured to receive a packet, determine on which port the packet is received, determine the virtual channel of the packet, determine the destination identification contained in the packet, identify an outgoing port of NPS706 based on the receiving port, virtual channel, and destination identification programmed into registers forming a routing table, and transmit the packet on the outgoing port of NPS706.

[0133] In this example, there are 32 port-VC combinations based on 4 ports and 8 virtual channels, and each entry for an outgoing port is at least 2 bits based on 4 ports. Therefore, in this example, a 232-bit register is implemented per IDy. Other examples may implement the routing table registers differently.

[0134] In some examples, packing registers based on destination identification allows routing tables to be more easily reconfigured when routes are changed in a partial reconfiguration without having to reconfigure or interrupt other routes that should not be reconfigured.

[0135] In other examples, other functions may be implemented in the routing table, for example, adding multiple destination identities to the routing table to reduce overhead and / or packet processing. A routing table may be segmented within a register, e.g., multiple destination identities may be packed into one or more registers. In such instances, the segmentation may affect the ability to reconfigure routes. For example, if a portion of a route to be persisted during a partial reconfiguration corresponds to an entry in a segment of the routing table, the presence of the route to be persisted may prevent the reconfiguration of another route in the same segment.

[0136] FIG. 18 illustrates an exemplary method 1800 for operating an SoC such as SoC 100. In block 1802, NoC 108 is configured. More generally, NoC 108 may be configured as part of a system-level configuration and / or any reconfiguration thereof (e.g., partially or fully). Other subsystems of SoC 100 may also be configured during operation 1802. For example, PL domain 104 and / or DPE array 102 may be configured. NoC 108 may be configured via memory-mapped transactions through NPI 710 to write to register blocks 712 of NMUs 702, NSUs 704, and NPSs 706, as described above. PL domain 104 may be configured via configuration interconnect 1612. DPE array 102 may be configured via NoC 108 and SoC interface block 206 of DPE array 102 after NoC 108 is configured. The configuration of the PL region 104 and / or the DPE array 102 can instantiate one or more applications, or any subset thereof, on the PL region 104 and / or the DPE array 102. Configuring the NoC 108 and any other components can be under the control of the PMC 1602. The PMC 1602 can, for example, retrieve a PDI from memory, which can include configuration data for the NoC 108, a configuration bitstream for the PL region 104, and / or configuration data for the DPE array 102. The PMC 1602 can then adjust and control the configuration of the components based on the PDI.

[0137] In block 1804, communication occurs via the NoC 108. More generally, the SoC 100 operates based on the configuration of the SoC 100, including the configuration of the NoC 108. Once configured, the PMC 1602 can enable and initiate operation of the components. Various subsystems on the SoC 100 communicate application data with each other, for example, via the NoC 108. For example, applications or subsets thereof instantiated on the PL region 104 and / or DPE array 102 can communicate with each other or with other subsystems (e.g., the PS 106 and / or the memory controller) via the NoC 108.

[0138] At block 1806, a partial reconfiguration event trigger occurs. The partial reconfiguration event trigger may be usage-specific. For example, an application or a subset thereof instantiated on the PL domain 104 and / or DPE array 102 may finish its task and generate an interrupt to trigger a partial reconfiguration. The interrupt may be communicated to the PMC 1602 via the NoC 108, a dedicated interconnect, or another interconnect, and in response to receiving the interrupt, the PMC 1602 assumes control for the partial reconfiguration.

[0139] In block 1808, the NoC 108 is partially reconfigured. More generally, the NoC 108 may be configured as part of a larger partial reconfiguration. Other subsystems of the SoC 100 may also be partially reconfigured during block 1808. The instances of circuit components of the NoC 108 and any other subsystems that are reconfigured during the partial reconfiguration are referred to herein as reconfiguration partitions (RPs). Circuit components or regions of an RP may be reconfigured to transition from an unused state to a used state, from a used state to an unused state, and / or from a used state to a different used state during the partial reconfiguration. Other subsystems, such as the PL region 104 and the DPE array 102, may also be partially reconfigured during the partial reconfiguration. By reference, various applications can be disabled and / or overridden, and different applications, or any subset thereof, can be instantiated on those subsystems through partial reconfiguration. The partial reconfiguration of the NoC 108 and any other subsystems can be under the control of the PMC 1602. The PMC 1602 can retrieve a PDI from memory, which can include configuration data and / or a configuration bitstream for the reconfiguration partition. The PMC 1602 can then adjust and control the partial configuration of the circuit components based on the PDI.

[0140] A partial reconfiguration may reconfigure components within the RP, but not other components outside the RP. Furthermore, with respect to the NoC, communication (e.g., occurring in block 1804) may continue via paths in the NoC that should not be reconfigured (e.g., paths outside the RP). Thus, a subset of the NoC's resources may be changed, while another subset of the NoC's resources may remain active and undisturbed. Further details of partial reconfiguration of the NoC 108 are described with respect to FIG. 19 below.

[0141] In block 1810, communication occurs via the NoC 108. More generally, the SoC 100 operates based on the partially reconfigured configuration of the SoC 100. Once the partial reconfiguration is complete, the PMC 1602 enables and can initiate operation of the components. The various subsystems on the SoC 100 communicate application data with each other, for example, via the NoC 108, as previously described.

[0142] FIG. 19 is an exemplary implementation of block 1808 of FIG. 18 for partially reconfiguring the NoC 108. As previously described, in block 1808, the partial reconfiguration of the NoC 108 is under the control of the PMC 1602. In block 1902, the PMC 1602 controls the NMU 702 in the RP to be reconfigured. The PMC 1602 obtains the address or identification information of the NMU 702 in the RP to be reconfigured from the PDI. The PMC 1602 then sends a transaction request via the NPI 710 to the register block 712 of the NMU 702 in the RP to control the NMU 702. The transaction requests that the NMU 702 write a value to the register block 712 of the NMU 702 that causes the NMU 702 to stop sending further packets to the NoC 108 and clear any pending packets. The PMC 1602 may then wait a predetermined amount of time to allow the packets to be cleared. After a predetermined amount of time, the PMC 1602 may read the status register of each NMU 702 via a transaction request via the NPI 710 to determine whether any NMUs 702 still have packets pending. If an NMU 702 still has packets pending, an error may be generated. If no NMUs 702 have packets pending, the PMC 1602 may disable or stop operation of the NMUs 702 via a transaction request via the NPI 710.

[0143] In block 1904, the PMC 1602 controls the NSUs 704 in the RP to be reconfigured. The PMC 1602 obtains the addresses or identification information of the NSUs 704 in the RP to be reconfigured from the PDI. The PMC 1602 then sends a transaction request via the NPI 710 to the register block 712 of the NSU 704 in the RP to control the NSU 704. The transaction requests that a value be written to the register block 712 of the NSU 704 that causes the NSU 704 to reject any subsequently received packets from the NoC 108 and clear any pending packets. The PMC 1602 may then wait a predetermined amount of time to allow the packets to be cleared. After the predetermined amount of time, the PMC 1602 may read the status register of each NSU 704 via the transaction request via the NPI 710 to determine whether any NSUs 704 still have packets pending. If an NSU 704 is still pending, If the NSU 704 has no packets pending, an error may be generated. If the NSU 704 does not have any packets pending, the PMC 1602 disables or stops the operation of the NSU 704 via a transaction request through the NPI 710.

[0144] When the NMU 702 and NSU 704 are controlled as described in connection with blocks 1902 and 1904, traffic on paths within the NoC 108 in the RP is quiesced. Once traffic is quiesced, the RP can be reconfigured. In block 1906, the PMC 1602 reconfigures the NPS 706, NMU 702, and NSU 704 in the RP. The PMC 1602 reconfigures the NPS 706, NMU 702, and NSU 704 according to the configuration data included in the PDI. The PMC 1602 reconfigures the NPS 706, NMU 702, and NSU 704 via memory-mapped transactions via the NPI 710, as described above. Traffic can continue on paths that do not enter or exit the NoC 108 in the RP during reconfiguration, or that are independent. Because the NPSs 706, NMUs 702, and NSUs 704 that are not part of the RP are not reconfigured and are not affected by the reconfiguration, the paths between these NPSs 706, NMUs 702, and NSUs 704 can continue to operate during the reconfiguration of the NPSs 706, NMUs 702, and NSUs 704 within the RP.

[0145] In block 1908, the PMC 1602 enables the NSU 704 that has been reconfigured to the used state. After the reconfiguration, any NSUs 704 that were disabled or stopped before the reconfiguration are enabled and enter normal operation. In block 1910, the PMC 1602 enables the NMU 702 that has been reconfigured to the used state. After the reconfiguration, any NMUs 702 that were disabled or stopped before the reconfiguration are enabled and enter normal operation. Thus, communication via the NPS 706, NMU 702, and NSU 704 in the reconfigured RP is permitted to occur in block 1810 of FIG. 18 .

[0146] Figure 20 illustrates another exemplary implementation of SoC 100. Figure 20 illustrates a logical diagram of various components and / or subsystems of SoC 100. In the example of Figure 20, SoC 100 includes DPE array 102, PL 104, PS 106, and NoC 108. SoC 100 further includes PMC 1602, one or more hardwired circuit blocks 2012, 2018, 2024, 2034, and 2036, fabric interconnect 2038, and configuration interconnect 1612.

[0147] Fabric interconnect 2038 represents the interconnect circuitry used in PL region 104. As shown, various different subsystems, such as DPE array 102, PL region 104, PS 106, PMC 1602, hardwired circuit blocks 2034 and 2036, and selected components within hardwired circuit blocks 2012, 2018, and 2024, are connected to fabric interconnect 2038. Configuration interconnect 1612 is used to program (e.g., configure) DPE array 102, PL region 104, PS 106, PMC 1602, and hardwired circuit blocks 2034 and 2036. For example, configuration interconnect 1612 can enable frame-based programming of PL region 104 by PMC processing unit 2004 of PMC 1602.

[0148] PMC 1602 acts as the root of trust for SoC 100. In the example of FIG. 20, PMC processing unit 2004 may include one or more processors capable of executing program code. PMC 1602 further includes control circuitry 2006, memory 2008, and one or more interfaces 2010. PMC processing unit 2004 may execute control software from memory 2008, which may include RAM and / or ROM. PMC processing unit 2004 controls various security and For example, PMC processing unit 2004 may boot SoC 100, perform a partial reconfiguration of SoC 100, configure DPE array 102, configure PL region 104, configure PS 106, and configure NoC 108 via configuration interconnect 1612, fabric interconnect 2038, and / or NoC 108 (e.g., once initially configured as described in connection with FIG. 10 ).

[0149] The PMC processing unit 2004 can communicate with a control circuit 2006. The control circuit 2006 can include security circuitry, safety circuitry, system monitor circuitry, e-fuse circuitry, and power management circuitry for the entire SoC 100. In this regard, the PMC processing unit 2004 can write to control registers within the circuitry for setting various functions and configurations of the SoC 100 chip-wide. The interface 2010 can include any of a variety of flash memory interfaces (e.g., to read configuration data such as a PDI for the SoC 100 from an external source), a memory card interface for receiving one or more different types of memory cards, a SelectMAP configuration interface, a JTAG interface, and one or more other off-chip connections and / or interfaces.

[0150] Hardwired circuit block 2012 includes one or more configurable memory (e.g., DDR) controllers 2014 connected to NoC 108 and configurable I / O 2016. Hardwired circuit block 2018 includes one or more configurable high-bandwidth memory (HBM) controllers 2020 connected to NoC 108 and configurable I / O 2022. Hardwired circuit block 2024 includes a cache coherent interconnect for accelerators (CCIX) block 2026, one or more configurable peripheral component interconnect express (PCIe) blocks 2028, and one or more configurable media access control (MAC) blocks 2030, each coupled to a configurable gigabit transceiver (GT) 2032. Hardwired circuit blocks 2034 and 2036 may implement one or more of a configurable video codec block, a configurable forward error correction block, a configurable encryption block, and a configurable analog mixed-signal block (e.g., including one or more configurable digital-to-analog converters (DACs) and / or analog-to-digital converters (ADCs)). It should be understood that SoC 100 may include fewer or more hardwired circuit blocks than shown in FIG. 20.

[0151] The PS 106 is connected to the NoC 108, the fabric interconnect 2038, and the configuration interconnect 1612. As shown, the PS 106 may include one or more real-time processing units (RPUs) 2042, one or more application processing units (APUs) 2044, and one or more graphics processing units (GPUs) 2046. The PS 106 may further include a PS memory 2048, which may include a level 2 cache and a system memory management unit (SMMU). The PS 106 may further include a coherent interconnect 2050, a snoop control unit (SCU—not shown), and one or more peripherals 2052. The coherent interconnect 2050 and the SCU allow other masters to read and write to the level 2 cache memory. For example, the RPU 2042 and master circuit blocks in the PL 104 can snoop the level 2 cache memory. The peripherals 2052 may include one or more different I / O interfaces, including, but not limited to, a Universal Serial Bus (USB), Ethernet, Universal Asynchronous Receiver / Transmitter (UART), Controller Area Network Flexible Data Rate (CAN FD), a serial peripheral interface, DisplayPort, High-Definition Multimedia Interface (HDMI), an I2C interface, and a Serial ATA interface.

[0152] The PL domain 104 may include LUTs 2054, BRAMs 2056, URAMs 2058, and DSPs 2060, as previously described, interconnected by a fabric interconnect 2038. As shown, the PL domain 104 is connected to the NoC 108, the fabric interconnect 2038, and the configuration interconnect 1612. The DPE array 102 may include multiple interconnected hardwired and programmable DPEs 204. The DPEs 204 connect to the NoC 108, the fabric interconnect 2038, and the configuration interconnect 1612 via an SoC interface block 206.

[0153] 20, NoC 108 may also be connected or coupled to another NoC located on another die and / or IC. For example, if SoC 100 is formed from multiple dies interconnected via an interposer or other carrier, NoC 108 may be coupled to the NoC of the other die via the interposer or carrier.

[0154] 20, the CCIX2026, or other multi-chip cache coherent equivalent, may also be connected or coupled to another CCIX located on another die and / or IC. For example, if the SoC 100 is comprised of multiple SoCs interconnected via a multi-chip cache coherency protocol, the CCIX2026 may be coupled via the GT2032 of the other SoC.

[0155] 20 illustrates different structural and functional aspects of the programmable device platform implemented by SoC 100. In this regard, SoC 100 provides a flexible platform in which different functions may be remapped from one subsystem to another. For example, a particular function may be remapped from DPE array 102 to PL area 104, from PL area 104 to DPE array 102, from DPE array 102 to a hardwired circuit block, from a hardwired circuit block to DPE array 102, from PL area 104 to a hardwired circuit block, and / or from a hardwired circuit block to PL area 104. This remapping may be performed without interrupting user applications in other portions of SoC 100.

[0156] While SoC 100 has been described primarily according to the different subsystems contained therein, e.g., PL 104, PS 106, DPE array 102, NoC 108, and / or hardwired circuit blocks, the platform also provides resources in the form of "computation engines," "hardware acceleration engines," "memory resources," "external interfaces," and "pervasive interconnects" that extend across the different subsystems described.

[0157] As defined herein, the term "compute engine" refers to a processor capable of executing program code. A compute engine is also referred to as a "Group A" type circuit block. Various types of compute engines are described in connection with SoC 100, such as any of the various processors implemented in PS 106 (e.g., RPU 2042, APU 2044, and / or GPU 2046). Other examples of compute units that may be implemented in SoC 100 include soft processors implemented within PL region 104. An illustrative and non-limiting example of a soft processor is the MicroBlaze® Soft processor core available from Xilinx, Inc. of San Jose, California. It should be understood that custom soft processors may also be implemented in PL region 104.

[0158] As defined herein, the term "hardware acceleration engine" refers to dedicated or application-specific circuitry that may be implemented as a hardwired circuit block 110 or as a circuit block within the PL region 104. A hardware acceleration engine is a "Group B" type circuit block. Examples of hardware acceleration engines include, but are not limited to, DPEs, ADCs, DACs, DSPs, video codecs, encryption engines, and custom circuit blocks implemented in the PL region 104.

[0159] With respect to SoC 100, the term “memory resources” includes any memory structure available in PS 106 and / or PL region 104. Memory resources are also referred to as “Group C” type circuit blocks. For example, memory resources may include on-chip memory (OCM) and cache memory available in PS 106 (e.g., shown as PS memory 2048) and / or LUTs (e.g., LUTRAM), URAM, and / or BRAM available in PL region 104. Memory resources may also include off-chip or external memory, such as DDR, HBM, or other memory that may be accessible using hardwired and / or custom memory controllers implemented in PL region 104.

[0160] With respect to SoC100, the term "external interface" refers to industry-standard protocols and controllers for communication with circuits and / or systems located off-chip. External interfaces are also referred to as "Group D" type circuit blocks. Examples of external interfaces for SoC100 include, but are not limited to, CCIX2026, PCIe2028, MAC2030, Ethernet (in PS106), and custom controllers implemented in PL region 104 for standard and / or non-standard protocols.

[0161] In the context of SoC 100, the term "pervasive interconnect" refers to a common infrastructure used to communicate information such as data and interrupts or other control signals, and also enables a flexible platform so that different functions can be remapped from one subsystem to another. The pervasive interconnect is also referred to as a "Group E" type circuit or circuit block. Examples of common infrastructure included in the pervasive interconnect include NoC 108, the coherent interconnect 2050 of PS 106, and custom signal paths implemented in PL region 104. The pervasive interconnect of SoC 100 is used for configuration, connectivity, configurability, firewalls, and communication between the various subsystems described herein.

[0162] For illustrative purposes, the coherent interconnect 2050 may establish connections with hardwired circuit blocks 110 (e.g., 2012, 2018, 2024, 2034, and / or 2036), circuit blocks implemented in the PL region 104, and / or DPEs 204 of the DPE array 102 via the NoC 108 and / or fabric interconnect 2038. For example, the compute units of the PS 106 and the compute units implemented in the PL region 104 may access the coherent interconnect 2050. Similarly, hardware accelerator engines, whether hardwired or implemented in the PL region 104, may access the coherent interconnect 2050. Memory resources, whether external, within the PL region 104, or within the PS 106, may be connected to the coherent interconnect 2050.

[0163] The NoC 108 can implement data paths and messaging between computational engines, hardware acceleration engines, memory resources, external interfaces, and a coherent interconnect 2050 for extensive data and messaging paths between any and all of such components.

[0164] The PL region 104 provides customization for user-defined, custom, hardware accelerator engines, peripherals, and / or other computational blocks that may be implemented in the PL region 104. A reduced data path can be implemented.

[0165] FIG. 20 illustrates the use of pervasive configuration and interrupt paths for static and dynamic configuration, control, and status of components in groups A, B, C, D, and E. Pervasive configuration may be achieved by using PMC 1602 to access a common set of configuration, control, and status registers (CCSRs) across a heterogeneous set of components (e.g., in various subsystems) of SoC 100, regardless of whether such components perform the same or different functions. For example, FIG. 23 illustrates that components implemented in different subsystems of SoC 100, regardless of whether they perform the same or different functions, may have commonly configurable interrupt status registers, error control and status registers, and / or performance control and status registers.

[0166] The pervasive architecture illustrated for SoC 100 can be used to enable higher-level composite functions or macro-functions. An example of a macro-function that can be enabled is DMA data movement between components on SoC 100. Another type of macro-function is a task pipeline. A task pipeline can be a pipeline stage of acceleration (e.g., hardwired circuit blocks or user-defined accelerators in the PL) followed by a pipeline stage of computation (e.g., processing performed by a computation device in a PS or DPE of a DPE array).

[0167] In one example, pervasive configurations for both DMA-type macro functions and pipeline task execution-type macro functions may be implemented in SoC 100 using a common descriptor definition that is universally interpreted across a heterogeneous set of components of SoC 100 (e.g., either circuitry within the PL, one or more DPEs, a PS processor, or hardwired circuit blocks).

[0168] As an illustrative example, a component within SoC 100 interprets an inbound descriptor to perform a pipeline stage function. Based on the results of that function, the component generates an outbound descriptor for the next heterogeneous component to interpret to perform the next pipeline stage function. This common descriptor approach also allows for the intermixing of heterogeneous component types that may be used in performing a task. As described above, a PL element that interprets descriptors and communicates with other components on SoC 100 can be replaced with a hardware acceleration engine that interprets the same descriptors and communicates with the same adjacent components when implemented in a different SoC 100 using the same platform architecture or by a different application within the same SoC 100.

[0169] FIG. 21 illustrates an exemplary implementation of PMC 1602. PMC 1602 is a hardwired circuit block on SoC 100. In the example of FIG. 21, PMC 1602 includes a PMC processing unit 2004 (separate and distinct from PS 106). PMC processing unit 2004 may include a physical unclonable function (PUF) 2104, one or more ROMs 2106, one or more RAMs 2108, one or more timers 2110, one or more processors 2112, and local registers 2114. In the exemplary implementation, PMC 1602 is on a separate power domain (e.g., has a separate, independent power supply) independent from PL 104, DPE array 102, and / or PS 106.

[0170] In one embodiment, the PMC processing unit 2004 includes multiple processors 2112 that operate in lockstep using appropriate voting circuitry. In another embodiment, the PMC processing unit 2004 includes multiple processors 2112, with one or more processors that may operate in lockstep. The processor 2112 is dedicated to accessing RAM 2208 (e.g., executing code stored in ROM 2208), and one or more other processors 2112, which may also operate in lockstep, are dedicated to accessing ROM 2206 (e.g., executing code stored in ROM 2206).

[0171] For example, one or more processors 2112 are dedicated to executing code stored in ROM 2106. The ROM-only processor 2112 is the first processor active out of reset during boot of SoC 100. In executing code stored in ROM 2106, the ROM-only processor 2112 can perform operations such as device initialization, boot interface verification, releasing additional processors 2112 of PMC 1602 from reset, and loading the PMC platform loader and manager into RAM 2108. The ROM-only processor 2112 can also perform secure boot, post-boot security monitoring, and PUF management. The RAM-only processor 2112 can execute code stored in RAM 2108 once released from reset.

[0172] In either case, ROM 2106 and RAM 2108 are accessible only by processor 2112. In another embodiment, each processor 2112 has ROM 2106 and RAM 2108, with each processor 2112 having a separate, dedicated ROM 2106 and separate, dedicated RAM 2108. RAM 2108 may be protected by error correction coding (ECC) circuitry. Processor 2112 may be used to power on and configure SoC 100 by executing code stored in ROM 2106 and firmware loaded into RAM 2108 from a primary boot device by executing code stored in ROM 2106. Local registers 2114 are configuration registers for PMC processing unit 2004 and may be accessed only by PMC processing unit 2004.

[0173] After booting, processor 2112 can perform a variety of different functions using various components included in PMC 1602. For example, processor 2112 can perform power management, voltage and temperature monitoring, safety and security event response, etc. for SoC 100. As shown, processor 2112 can receive interrupt and wake signals for these purposes.

[0174] The PMC processing unit 2004 is connected to an interconnect 2116. The PMC processing unit 2004 can communicate with the PMC 1602 and other components within the SoC 100 via the interconnect 2116. The interconnect 2116 can include multiple memory-mapped switches and interfaces and multiple stream switches and interfaces. The interconnect 2116 is connected to a PMC shared RAM 2118, global registers 2120, I / O 2122, DMAs 2124 and 2126, a secure stream switch 2128, a slave boot interface 2130, a security accelerator 2132, an analog system 2134, a real-time clock (RTC) 2136, power management and reset 2138, error management 2140, a debug packet controller 2142, and a configuration frame unit (CFU) 2144.

[0175] PMC shared RAM 2118 can be used to store configuration data for SoC 100 during processing and as general-purpose data processing RAM for PMC 1602. Global registers 2120 are configuration registers accessible by any (e.g., all) masters within PMC 1602. Global registers 2120 can include general-purpose power control registers, error management registers, and a service interrupt request interface. I / O 2122 can be one or more I / Os coupled to multiplexed input / output (MIO) 2168. As shown, MIO 2168 further connects to PS 106 and PL 104. Examples of I / O circuit blocks that may be included in I / O 2122 include, but are not limited to, I2C and one or more flash interfaces such as SPI and / or SD / eMMC.

[0176] DMAs 2124 and 2126 are used to transfer data within PMC 1602 for configuration of SoC 100 and processing of configuration data. Secure stream switch 2128 ensures that the data stream provided to security accelerator 2132 for processing is secure. Slave boot interface (SBI) 2130 facilitates slave boot and / or configuration in multi-die SoC configurations. Although not shown, SBI 2130 may be connected to SelectMap 2170 and NoC 108.

[0177] The security accelerator 2132 may include an AES-GCM circuit block 2146, an Elliptic Curve Digital Signature Algorithm / Rivest-Shamir-Adleman (ECDSA / RSA) circuit block 2148, a Secure Hash Algorithm 3 / 394 (SHA-3 / 394) circuit block 2150, a True Random Number Generator (TRNG) circuit 2152, and a Battery Backed RAM (BBRAM) 2154 circuit block. The AES-GCM circuit block 2146 is a symmetric key encryption engine capable of performing encryption and / or decryption. The ECDSA / RSA circuit block 2148 is a public key encryption engine capable of performing authentication. The SHA-3 / 394 circuit block 2150 can perform secure hash operations. The TRNG circuit 2152 can generate random numbers.

[0178] The analog system 2134 may include a system monitor 2156 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 2158 capable of generating clock signals for the PMC 1602; an e-fuse controller 2160 capable of maintaining and / or managing the e-fuse circuits on the SoC 100; a bandgap circuit 2162 capable of generating one or more reference voltages for analog devices within 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) 2164 capable of generating clock signals for the PMC 1602, the NoC 108, the NPI 710, and the PS 106; and a power-on reset (POR) circuit 2166.

[0179] The e-fuse controller 2160 can read the e-fuse circuits (e.g., e-fuse memory elements) that may be used to store design information such as device DNA and security keys. The e-fuse circuits can further control functions such as disabling JTAG 2168.

[0180] The RTC 2136 is a clock circuit that can operate with a high-precision crystal oscillator. The RTC 2136 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 2138 implements the logic and interfaces necessary to control power islands, power domains, and resets to other circuit blocks on the SoC 100. The power management reset circuit 2138 further connects to the PS 106 to control the power islands implemented in the PS 106. The error management circuit 2140 can receive, log, and respond to errors from other subsystems within the SoC 100. The debug packet controller 2142 can communicate with the high-speed serial interface and / or PCI. This is a packet controller for the High Speed ​​Debug Port (HSDP), which handles packets passed from other interfaces on the SoC100, such as the e-block.

[0181] CFU 2144 can configure and read configuration data provided or loaded into configuration registers of PL 104. PMC 1602, for example, transfers the PL bitstream (e.g., configuration data) through CFU 2144 to configure PL 104.

[0182] SoC 100 may be implemented to include several major power domains controlled by power management and reset circuit 2138. The power domains include a low power domain including the RPU and OCM, a full power domain including the APU and high-speed I / O, an NoC and system dual data rate (DDR) power domain, and a PL power domain.

[0183] Other power domains may be created within SoC 100 that can be controlled through the circuit board on which SoC 100 is located. 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.

[0184] Figure 22 shows an exemplary arrangement of processors 2112 of PMC processing unit 2004. In the example of Figure 22, processors 2112 are arranged in a triple redundant architecture. In the exemplary implementation, processors 2112 are implemented as hardwired Microblaze processors, although other types of processors may be used.

[0185] Each processor 2112 is connected to a triple modulo redundancy (TMR) manager 2202 and an I / O module 2204. TMR managers 2202-1, 2202-2, and 2202-3 are interconnected. I / O modules 2204-1, 2204-2, and 2204-3 are also interconnected. A voting circuit 2210-1 is coupled to each of the I / O modules 2204. Each I / O module 2204 may include an interrupt controller, a timer, a general-purpose I / O (GPIO), and / or a UART. Each TMR manager 2202 can manage the state of each of the processors 2112, including fault detection and error recovery.

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

[0187] Each processor 2112 is also connected to RAM control circuitry 2206 and RAM control circuitry 2208. RAM control circuitry 2206 is connected to voting circuitry 2210, which is connected to an instruction RAM, e.g., RAM 2118. RAM control circuitry 2208 is connected to voting circuitry 2210-5, which is connected to a data RAM, e.g., RAM 2118. As shown, RAM 2118 and voting circuits 2110-4 and 2110-5 are part of the ECC domain. In the example of Figure 22, each RAM control circuit 2206 for an instruction RAM (e.g., 2206-1, 2206-2, and 2206-3) is connected to voting circuit 2210-3. Each of processors 2112-1, 2112-2, and 2112-3 is connected to voter circuit 2210-2. A control interface, such as AXI4-Lite or other suitable control interface, is connected to each of processors 2112-1, 2112-2, and 2112-3.

[0188] 22 shows an example of triple modular redundancy in which processors 2112 are dedicated to accessing RAM 2118. As previously mentioned, a similar architecture may be used for ROM-only processors in PMC 1602. In another example, fewer than three processors 2112 may be used, with one or two processors 2112 (in lockstep) dedicated to executing code stored in ROM 2106 and one or two other processors 2112 (in lockstep) dedicated to executing firmware stored in RAM 2108.

[0189] PMC 1602 is the root of trust within SoC 100. PMC 1602 can establish a chain of trust by ensuring that any external code loaded by PMC 1602 to configure any portion of SoC 100 is authenticated and decrypted (as needed). For example, PMC 1602 can perform authentication using ECDSA / RSA circuit block 2148 and decryption using AES-GCM circuit block 2146. In general, configuration data is authenticated and decrypted, and PMC 1602 can load the configuration data into the appropriate configuration registers of the appropriate subsystems and / or circuit blocks of SoC 100.

[0190] FIG. 23 illustrates further structural and functional aspects of SoC 100. FIG. 23 illustrates an exemplary configuration in which different types of compute engines and hardware acceleration engines are implemented across different subsystems of SoC 100. In the example of FIG. 23, the compute engines, hardware acceleration engines, memory resources, and external interfaces are implemented using standardized or common interfaces to other components and / or subsystems within SoC 100. These common interfaces allow the illustrated components to couple to global interconnect resources on SoC 100, which in this example is NoC 108.

[0191] In the example of FIG. 23 , PS 106 includes multiple RPUs 2042 and multiple APUs 244, each coupled to a coherent interconnect 2050 via a level 2 cache 2302 (e.g., a portion of PS memory 2048). Coherent interconnect 2050 is further connected to memory 2304. Memory 2304 may be memory located within PL domain 104, external memory, or memory within PS 106 accessible by other circuit blocks in other subsystems. As shown, memory 2304 is also connected to NoC 108. Various other types of circuit blocks are connected to NoC 108, such as one or more external I / Os 2308 and one or more hardware acceleration engines 2310.

[0192] External I / O 2308 includes a fixed peripheral interface 2312 and a user-defined peripheral interface 2314. Fixed peripheral interface 2312 is implemented as a hardwired circuit block, while user-defined peripheral interface 2314 is implemented in PL domain 104. Both fixed peripheral interface 2312 and user-defined peripheral interface 2314 are connected to system I / O interconnect 2315 (e.g., local interconnect) and GT 2316 and / or I / O 2318.

[0193] The hardware acceleration engine 2310 includes a user-defined accelerator 2320 implemented in the PL region 104, one or more DPEs 204 (e.g., one or more groups) of the DPE array 102, where each group of one or more DPEs 204 is configured to perform a specific function, a DSP hardwired circuit block 2334, and a cryptographic hardwired circuit block 2336.

[0194] In the example of FIG. 23 , fixed peripheral interface 2312, user-defined peripheral interface 2314, user-defined accelerator 2320, DPE 204, DSP 2334, and crypto engine (cipher) 2336 utilize a common interface despite performing different operations and being implemented across different subsystems. For example, each of the described components may include data path interface 2322, MMU interface 2324, interrupt interface 2326, DMA 2328, performance monitor 2330, trace / debug interface 2332, and configuration interface 2334. Thus, even though the various components belong to different groups as described above and / or are implemented across different subsystems of SoC 100, each may have the same or common interfaces. The common interface supports remapping of functions from one subsystem to another within SoC 100, because the signaling of functional blocks remains constant even when moved from PL domain 104 to hardwired circuit blocks or DPEs, etc.

[0195] Data path interface 2322 is an interface circuit that can connect to a global interconnect, which in this example is NoC 108. Data path interface 2322 can provide a standard interface for connecting to, for example, an NMU and / or NSU of NoC 108. Memory management unit (MMU) interface 2324 can perform address translation between virtual and physical addresses within SoC 100. For example, MMU interface 2324 can access page tables stored in memory and / or maintain locally cached copies of such tables to perform address translations that may be used for transactions received and / or transmitted via data path interface 2322. MMU interface 2324 can also enforce read / write permissions and authorizations to prevent circuit blocks including MMU interface 2324 from performing illegal reads and / or writes to memory addresses.

[0196] Interrupt interface 2326 implements standard interrupts or user-defined and / or specific interrupts for the circuit blocks. In some cases, interrupts for two or more circuit blocks may be shared, for example, if such circuit blocks are located in the same partition within SoC 100. In that case, interrupt destinations may be shared between the circuit blocks. Further discussion of partitions within SoC 100 is provided in more detail with reference to the remaining figures.

[0197] The DMA 2328 can transfer data via the NoC 108 and the data path interface 2322. The performance monitor 2330 can be coupled to other circuits and / or interfaces throughout the SoC 100. The performance monitor 2330 can measure quantities such as bandwidth and latency of the circuit block to which the performance monitor 2330 belongs. In one aspect, the performance monitor 2330 can filter and measure data signals entering and leaving the circuit block to measure the number of transactions or other quantities sent to a particular address range over a period of time. The performance monitor 2330 can communicate any measurement data to a programmed destination via the NoC 108 (e.g., the PS 106 or the PMC 1602). The trace / debug interface 2332 can send and receive trace and / or debug data via the NoC 108 for receipt by the PMC 1602. For example, the debug / trace interface can receive commands and send trace / debug data to the debug packet controller 2142 in the PMC 1602.

[0198] The configuration interface 2334 may be configured to configure the circuit block according to the particular subsystem in which it is located. 2334. The PMC 1602 may be connected to the NoC 108 and / or other interconnects (e.g., configuration interconnect 1612 or fabric interconnect 2038) via a configuration interface 2334. For example, the PMC 1602 may configure a circuit block by providing configuration data to the configuration interface 2334. The configuration interface 2334 may enable the PMC 1602 to read and write configuration registers located within the circuit block (not shown), for example.

[0199] In another aspect, different circuit blocks may include fewer or any combination of data path interface 2322, MMU interface 2324, interrupt interface 2326, DMA 2328, performance monitor 2330, trace / debug interface 2332, and / or configuration interface 2334. In one aspect, interrupt interface 2326 is configured to receive and / or generate interrupts. In an exemplary embodiment, interrupt interface 2326 is implemented as a memory-mapped interface. Interrupts may be received from other circuit blocks connected to interrupt interface 2326 and / or provided to other circuits connected to interrupt interface 2326. Interrupt signaling may be routed through NoC 108 to specific hardwired circuit blocks 110, PS 106, or any other circuit block shown in FIG. 23 .

[0200] In an illustrative example, the interrupt interface 2326 can generate and / or receive a doorbell interrupt. A doorbell interrupt is an interrupt that travels from one domain, e.g., one partition, to another within the SoC 100. For example, across two partitions that may be isolated from each other, one or more interrupts may be allowed in and out of the partitions to the other partition and / or the PMC 1602 to communicate a message or trigger / initiate a predetermined action. A doorbell interrupt can travel from one domain or partition to another domain or partition via the NoC 108.

[0201] In one example, a PCIe controller may be implemented in the PL 104. The PCIe controller is connected to the DDR memory via the NoC 108. In this example, the PCIe controller uses a common interface and may include an interrupt interface 2326. A host system communicating with the SoC 100 can generate a new job for the PCIe controller to execute and submit the new job (e.g., memory access) to the PCIe controller in the PL 104 of the SoC 100. The host system, for example, may generate an interrupt to the PCIe controller to cause the PCIe controller to program one or more DMAs to perform the memory access.

[0202] 23 illustrates the modularity of functions and services across components in groups A, B, and C of SoC 100. Components can maintain this modularity even when they perform different functions from one another. For example, components implemented in PL domain 104 are modularized so that PL components have standard interfaces to components in groups D, E, and F. Each PL component can be deployed to service any of the other functions implemented as components in groups A, B, or C. Each component in groups A, B, or C also has communication and data paths to either another PL component or a different component in groups A, B, and C.

[0203] In another example of modularity achieved using SoC 100, certain functionality deployed as a PL component can be deployed to other parts of PL 104 to implement multiple concurrent instances of the same functionality. Common interfaces provide common interrupt, address translation, debug, and performance monitoring schemes that are deployed across components in SoC 100, regardless of whether they are in Group A, B, or C. Despite providing a common interface, in another aspect, components implemented in groups A, B, or C may implement their own or custom sets of interrupt, address translation, debugging, and performance monitoring schemes.

[0204] FIG. 24 illustrates further structural and functional aspects of SoC 100. In the example of FIG. 24, 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 firewalls between different partitions. Each partition can run its own application within it. In the example of FIG. 24, multiple system management identifier (SMID) circuits 2402 and programmable protection circuits (PPC) 2418 are included.

[0205] The processor 2112, RPU 2042, APU 2044, other masters 2408, and I / O devices 2412 are connected to a local interconnect 2416 via an SMID circuit 2402. The I / O devices 2412 are further connected to the local interconnect 2416 via an SMMU 2414. The local interconnect 2416 is connected to the NoC 108. The PL 104 and / or DPE array 102 are connected to the NoC 108. The RPU 2042 includes an MMU 2404-1 and a cache 2406. The APU 2044 includes an MMU 2404-2 and a cache 2410.

[0206] Each SMID circuit 2402 is programmable to use a specific SMID. During configuration, the PMC 1602 can assign and write an SMID to the configuration registers of the various SMID circuits 2402, or at least each of those SMID circuits 2402, being used. The SMID circuit 2402 of each of the various components, e.g., the processor 2112, the RPU 2042, the APU 2044, the other masters 2408, the I / O devices 2412, the PL 104, and / or the DPE array 102, can attach or insert an SMID into transactions initiated by the respective component. Thus, each transaction originating from the processor 2112 includes an SMID inserted into the transaction by, for example, the SMID 2402-2 assigned by the PMC 1602. Similarly, each transaction originating from the RPU 2042 has an SMID inserted by the SMID 2402-2 assigned by the PMC 1602. In this manner, the source of a transaction from various components within SoC 100 may be identified by the particular SMID within that transaction. The SMID assigned to SMID circuit 2402 may be unique across SoC 100.

[0207] The PPCs 2418 can protect access to slave circuits within the SoC 100. Each of the PPCs 2418 can check the specific SMID of each transaction entering a circuit block. Each PPC 2418 can check whether the SMID of the transaction is an authorized SMID, for example, on a list of authorized SMIDs maintained by each PPC 2418. Each PPC 2418 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 2418 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.

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

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

[0210] In this regard, PPC 2418-1 can allow only authorized transactions from authorized sources to access PMC slave 2420. PPC 2418-2 can allow only authorized transactions from authorized sources to access NPI 710. PPC 2418-3 can allow only authorized transactions from authorized sources to access RTP slave 2422. PPC 2418-4 can allow only authorized transactions from authorized sources to access OCM 2424. PPC 2418-5 can allow only authorized transactions from authorized sources to access APU slave 2426. PPC 2418-6 can allow only authorized transactions from authorized sources to access DDR memory controller 2428.

[0211] In the example of FIG. 24 , specific locations of the SMID circuit 2402 and PPC 2418 are shown for illustrative purposes. The SMID circuit 2402 and PPC 2418 may be implemented within a circuit block as part of an interface, within a signal path between circuit blocks, etc. The SMID circuit 2402 and PPC 2418 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 circuit 2402 and / or the PPC 2418 rather than each of the individual circuit blocks that are aggregated via a repeater. This may be true for both entry and exit points of the NoC 108.

[0212] 24, local interconnect 2416 may represent a single physical circuit block that can merge multiple logical functions. In another example, NoC 108 may be implemented to include one or more SMID join points. In other words, SMID circuitry 2402 (e.g., 2402-8 and 2402-9) may be implemented within NoC 108 rather than within PL domain 104 and / or DPE array 102. SMID circuitry 2402 may be implemented in NoC 108 at an entry point, an exit point, or a combination of entry and exit points.

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

[0214] For example, processor 2112, RPU 2042, and APU 2044 each have SMID circuitry 2402. Processor 2112, RPU 2042, and APU 2044 can each initiate transactions with a unique SMID assigned to it based on configuration performed by PMC 1602. The transactions flow to NoC 108 with their respective SMIDs as destinations. Similarly, transactions from PL region 104 or DPE array 102 each have an SMID inserted by SMID 2402-6 or SMID 2402-7, as the case may be. Transactions from PL region 104 and DPE array 102 carry the SMID to their destination.

[0215] As an illustrative example, consider a circuit block implemented in PL domain 104 initiates transactions A, B, and C. Transactions A, B, and C each carry an SMID assigned by SMID circuit 2402-6 (or SMID circuit 2402-8, if implemented in NoC 108). If transaction A is directed to DDR memory controller 2428, NoC 108 serves as both the ingress and egress paths. PPC 2418-6 can check that the circuit block in PL domain 104 has the right to access DDR memory controller 2428 (e.g., based on the SMID) and the right to access the particular address of memory specified by the transaction. PPC 2418-6 can reject transaction A if the source of transaction A does not have the appropriate rights.

[0216] Transaction B may be directed to PMC slave 2420, and transaction C is directed to RTP slave 2422. For transaction B, PPC 2418-1 checks whether the source of transaction B (based on the SMID) is authorized to access the particular PMC slave 2420 specified by the transaction. For transaction C, PPC 2418-3 checks whether the source of transaction C (based on the SMID) is authorized to access the particular RTP slave 2422 specified by the transaction. Each PPC 2418-1 and PPC 2418-3 either permits or denies the respective transaction based on the SMID and the particular target of the transaction (e.g., a particular PMC slave 2420 or a particular RTP slave 2422). Thus, the logical functions of SMID attachment and exit checks (e.g., as performed by PPU 2418) may be physically distributed within SoC 100.

[0217] In another example, the I / O device 2412 may be an external flash device from which a boot image is loaded into the first PMC slave 2420. In this example, the PMC slave 2420 may be a memory slave, such as a memory in which boot code is stored, or registers for programming or configuring other blocks within the SoC 100, such as a register set for configuring the PL region 104 and / or the DPE array 102. In another example, the boot image may be program code that the processor 2112 boots. In this example, various gateways, e.g., the PPU 2418 and the SMID circuit 2402, are configured by the PMC 1602 to only allow the boot image to be loaded into a specific PMC slave 2420. Thus, the I / O device 2412 is only permitted to write the contents of an image file to a designated, e.g., the first PMC slave 2420, as regulated by the PPU 2418-1. The I / O device 2412 is not permitted to read from or write to other PMC slaves 2420. I can't.

[0218] Continuing the example, processor 2112 is authorized to load the boot image via an authentication scheme (described in more detail herein). For example, PPC 2418-1 may be configured to authorize processor 2112, based on the SMID corresponding to SMID circuit 2402-1, to read PMC slave 2420, where the boot image is stored by I / O device 2412 (which has only write access). Processor 2112 can only read the boot image and decrypt it into working memory for second PMC slave 2420, e.g., processor 2112. Processor 2112 may then use the decrypted boot image stored in second PMC slave 2420 to program other configuration registers, e.g., by writing to third PMC slave 2420. Third PMC slave 2420 may be configuration registers for PL region 104 or configuration registers for other circuit blocks.

[0219] In another aspect, the RPU 2042 may have a local interconnect separate from the PMC 1602 and / or other processors (e.g., APU 2044) of the PS 106. An RPU 2042 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 interconnect of the PMC 1602 and / or APU 2044. This allows the RPU 2042 to react quickly to different events, such as real-time sensor data that may be received and / or processed by the RPU 2042.

[0220] 25 shows an exemplary implementation of PPC 2418. PPC 2418 includes SMID check circuitry 2502, address range check circuitry 2504, and configuration registers 2506.

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

[0222] The PPC 2418 may prohibit (e.g., reject) transactions that do not satisfy the checks performed by the SMID check circuit 2502 and the address range check circuit 2504. The PPC 2418 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 circuit 2502 and / or the address range check circuit 2504.

[0223] 26 illustrates an example method 2600 for booting SoC 100. Method 2600 may be performed to implement an application within SoC 100 that utilizes the various subsystems described herein.

[0224] In block 2602, hardwired logic within the SoC 100 executes a power-on reset sequence. In one aspect, the hardwired logic is the POR circuit 2166 described in connection with FIG. 21. The power-on reset sequence is a sequence in which the SoC 100 The power-on reset sequence performed by the SoC 100 typically performs initial steps before transferring control to the PMC 1602 processor to execute BootROM code. The power-on reset sequence may include analog components to detect whether the voltage supply is powered on and qualify the power-on reset deassertion. Additionally, a boot mode pin may be acquired to specify the boot mode of the SoC 100. The e-fuse bits may be read and cached by the e-fuse controller 2160. A state clear operation is performed on the PMC 1602. The POR circuit 2166 can authenticate the BootROM. The BootROM may be authenticated, for example, using the SHA-3 / 384 circuit block 2150 of the PMC 1602. The completion of the power-on reset releases the remainder of the PMC 1602 from reset.

[0225] In block 2604, the POR circuit 2166 determines whether an error condition has occurred. If an error condition has occurred, the method 2600 proceeds to block 2606, where the error pin is asserted and the boot process of the SoC 100 is stopped.

[0226] In block 2608, the PMC 1602 executes the BootROM execution stage. The BootROM execution stage may be executed by one or more of the processors 2112 of the PMC 1602. For example, the BootROM execution stage may be executed by the ROM-only processor 2112 of the PMC 1602. In one aspect, the BootROM execution stage is uninterruptible. In block 2608, the processor 2112 clears the PMC shared RAM 2118. The processor 2112 initializes the system monitor 2156, and the voltages therein are checked. The processor 2112 initializes the PLL 2164. The processor 2112 tests the PMC RAM 2118. The processor 2112 further disables (powers down) power islands that have been disabled by e-fuses based on the e-fuse data read by the e-fuse controller 2160.

[0227] In block 2610, the PMC processor 2112 determines whether an error condition has occurred. If an error condition has occurred, the method 2600 proceeds to block 2612, where the error is captured in the error aggregation logic, the error pin is asserted, and booting of the SoC 100 continues.

[0228] In block 2614, the PMC 1602 performs boot header / authentication certificate processing. Generally, the processor 2112 executes BootROM code, loads the boot header from the boot source, and authenticates the boot header. The processor 2112 can authenticate and decrypt (if necessary) the main PMC firmware. The processor 2112 loads the boot header and authentication certificate from the external boot device into the PMC shared RAM 2118. The processor 2112 can determine how the remainder of the PDI image is authenticated, decrypted as necessary, and interpreted based on the boot header. The boot header can include an initialization vector used with the device key and the PUF-encrypted black key. The authentication certificate can include an ECDSA / RSA primary public key and a secondary public key. The primary key is used to authenticate the secondary public key, which is used for subsequent stages of authentication.

[0229] In block 2616, the processor 2112 determines whether an error condition has occurred. If an error condition has occurred, the method 2600 proceeds to block 2618, where the SoC 100 is locked down, e.g., boot is aborted.

[0230] In block 2620, the processor 2112, when executing the BootROM, The PDI programming partition may be loaded, authenticated, and decrypted. At block 2622, the processor 2112 determines whether an error condition has occurred. If an error condition has occurred, the method 2600 proceeds to block 2624, where the SoC 100 is locked down, e.g., boot is aborted.

[0231] In block 2626, the processor 2112 executes a platform loader and manager stage. In one aspect, the RAM-only processor 2112 may execute the platform loader and manager stage. Depending on the instructions included in the boot header, the processor 2112 may perform any of a variety of operations. For example, in block 2628, the processor 2112 may execute a PS boot loader stage. The processor 2112 may load PS boot code from an external source, authenticate the PS boot code, and copy the PS boot code to the OCM within the PS 106 for execution by the PS processor.

[0232] In block 2630, the processor 2112 may configure the PL. For example, the processor may load a configuration bitstream from an external source, authenticate the configuration bitstream, and provide the configuration bitstream to the PL (e.g., write the configuration bitstream to a configuration register of the PL).

[0233] In block 2632, the processor 2112 can configure the DPE array. The processor 2112 can load DPE array programming segments (e.g., a configuration image for 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 within the DPE array) via the NPI 710 and NoC 108.

[0234] In block 2634, the processor 2112 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 internal configuration registers. The processor 2112 can load register programming segments from an external source, authenticate the register programming, and write the register programming to a destination via the NPI 710 and NoC 108. As an illustrative and non-limiting example, the processor 2112 can write register data to the SMID circuit block 2402, the PPC 2418, and / or other hardwired circuit blocks (e.g., cryptographic circuit blocks, ADCs, DACs, etc.).

[0235] At block 2636, the processor 2112 may configure the NoC 108. As an illustrative and non-limiting example, the processor 2112 may configure the NoC 108 as described in connection with FIG. 11. At block 2638, the processor 2112 may configure any memory. For example, the processor 2112 may write configuration data to any memory controller and / or interface with external memory accessible by the SoC 100.

[0236] The various operations performed by the processor 2112 during the platform loader and manager stages may or may not be independent of one another. In some cases, operations may be performed synchronously. For example, although not explicitly described, the image for the NPI 710 may be loaded before the PL 104 can be configured. The particular order of the sub-blocks within block 2626 is not a limitation of the present invention.

[0237] FIG. 26 shows that PMC 1602 is responsible for configuring PS 106, PL 104, DPE array 102, and selected other circuit blocks. In response to, for example, a boot header, PMC 1602 may configure PS 106 with program code that enables PS 106 to configure PL 104 and DPE array 102. In that case, depending on the PS configuration in block 2628, blocks 2630, 2632, and 2634 may be executed by PS 106, as opposed to processor 2112 in PMC 1602.

[0238] As method 2600 progresses, each level in the progression enables or disables permission for components to access other components within SoC 100. The process described in connection with FIG. 26 is hierarchical in that authorization may be denied or granted to increasingly narrower subsets of subsystems and / or components within SoC 100. The hierarchical aspect of the technique illustrated in FIG. 26 can support SoC 100 configuration for use in a field-programmable gate array (FPGA)-as-a-service or “FaaS” processing environment. For example, PMC 1602 can create multiple partitions in SoC 100. In creating a partition, PMC 1602 can map many logical destinations mapped to one physical destination (e.g., multiple circuit blocks implemented in PL 104, multiple independent DPE clusters implemented in DPE array 102, etc.). Similarly, PMC 1602 can create partitions in SoC 100 in which many physical destinations are mapped to one logical destination.

[0239] At runtime of SoC 100, SMID circuit block 2402 and PPC 2418 can support multiple different partitions based on the described SMID-to-PPC permission bindings. These different partitions can be serviced by specific functions and / or components available on SoC 100. Because SoC 100 can be configured, reconfigured, and / or partially reconfigured across different subsystems, the permission and authentication mappings that create the partitions and implement firewall functions between them can be dynamically changed.

[0240] 27 shows an example of a PDI 2700 that may be used to boot SoC 100. In the example of FIG. 27, PDI 2700 includes a boot header 2702. PDI 2700 further includes a platform loader and manager (PLM) 2704. PLM 2704 may include a secure header 2706 and firmware 2708 executable by processor 2112 of PMC 1602. PDI 2700 also includes authentication certificate 2714.

[0241] Next image 2710 of PDI 2700 may include multiple different blocks, designated as Block 0, Block 1 through Block N. The various blocks included in next image 2710 may be specified in secure header 2712. Generally, the various Blocks 0 through N correspond to PS boot code, configuration bitstream for the PL, DPE array programming segments, and register programming data referenced in blocks 2628, 2630, 2632, and 2634 of Figure 26. In particular embodiments, 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.

[0242] Partial reconfiguration of one or more portions of SoC 100 may be performed by PMC 1602 selectively executing different ones of blocks 2628-2638 using available and / or different blocks or sets of blocks contained in PDI 2700 (or different PDIs) over time and in response to specific conditions. Partial reconfiguration of SoC 100 facilitates layering of physical components within SoC 100 into subsets or wholes or logical subsets thereof. For example, PMC 1602 may facilitate partition isolation (including reconfiguration of changed applications) and layering of physical components within SoC 100 into logical subsets. It can control the unloading (and loading) of software drivers (as appropriate for the application), delivery of programming images from any secondary boot interface, and image authentication and integrity checking before programming occurs.

[0243] 28 illustrates another example of SoC 100 implementing different partitions. In the example of FIG. 28, various different images may be sequentially loaded onto SoC 100. These different images implement different partitions therein, illustrating a FaaS processing environment, where a platform provider may implement a "shell" design within SoC 100 to facilitate communication with SoC 100 within a larger system and simultaneously facilitate implementation of user applications corresponding to multiple different users within SoC 100 (e.g., users of a host processing system coupled to SoC 100 via a PCIe link).

[0244] In the example of FIG. 28 , system 2800 is shown including host data processing system 2802. Host data processing system 2802 may be implemented as a computer system such as a server. Host data processing system 2802 includes multiple different CPUs that may be assigned to different users (e.g., different processes, different applications, etc.). For illustrative purposes, FIG. 28 shows two different users X and Y using system 2800. As such, the CPUs of host data processing system 2802 are assigned to user X and user Y. Thus, host data processing system 2802 includes user X's CPU 2804 and user Y's CPU 2808. Host data processing system 2802 further includes a host interconnect 2806 that can establish communication with SoC 100. For example, host interconnect 2806 may be a PCIe node that can communicate with SoC 100 via a PCIe link.

[0245] Host data processing system 2802 is connected to host memory 2810. Host memory 2810 may include volatile and / or non-volatile memory. As shown, host memory 2810 is divided between user X and user Y. Thus, host memory 2810 includes user X memory 2812, which is assigned to user X, and user Y memory 2814, which is assigned to user Y.

[0246] SoC100 may be coupled to a circuit board or card that connects to a host data processing system 2802 via a PCIe link. The circuit board may include SoC100 and external RAM 2836 that is local to SoC100. A shell design implemented within SoC100 creates multiple partitions within SoC100. The term "partition," as used herein with respect to SoC100, refers to a collection or set of SoC100 resources that are allocated or reserved for use by any application implemented within that partition.

[0247] The shell itself can occupy a partition in that it contains selected components of the SoC 100 that can manage resources therein. The shell provides functionality such as configuration and management of the SoC 100 so that different applications implemented in different partitions created can be managed over time. As an illustrative example, the PMC 1602 and various functions described herein with reference to the PMC 1602 may be part of the shell so that a FaaS provider can manage the implementation of different users or applications within the SoC 100 and their respective partitions. In another aspect, the PMC 1602 may be separate from the shell but accessible only by the shell, such that applications implemented in the various partitions cannot access the PMC 1602. The shell may have a firewall, just like the other partitions. However, unlike the other partitions, the shell can monitor and access the different partitions implemented in the SoC 100 and the specific roles / users implemented in each partition.

[0248] In one aspect, the shell (not shown) may be implemented as a static region within SoC 100 that does not change, while the partitions may be implemented as dynamically reconfigurable regions within SoC 100. The shell may include, for example, PCIe nodes (e.g., 2816, 2820), DMAs (2816, 2822), memory controllers, etc. For example, the shell may include interfaces necessary to communicate with circuitry located outside SoC 100. In this manner, partitions implemented as dynamically reconfigurable regions can be reconfigured to implement different applications over time while the shell operates uninterrupted, allowing SoC 100 to maintain communication links to the host data processing system, RAM, and / or other external devices. The shell includes interfaces to the partitions so that, once implemented in the partitions, the applications can communicate with the shell and / or access devices and / or circuitry (e.g., external circuitry and / or devices such as host data processing system 2802 and external RAM 2836) through the shell. The shell may be implemented using portions of the PS 106, portions of the PL 104, portions of the NoC 108, and / or one or more hardwired circuit blocks 110.

[0249] In the example of FIG. 28, SoC 100 is divided into two partitions (e.g., not including the static region of the shell). Each partition has or includes a subset of the resources of SoC 100 used by a particular application running in that partition. For example, SoC 100 includes a first partition (e.g., partition X) that includes various resources allocated for use by user X. SoC 100 includes a second partition (e.g., partition Y) that includes various resources allocated for use by user Y. The partitions, and thus user X and user Y, can occupy SoC 100 simultaneously and are firewalled from each other. Partition X and partition Y are dynamically reconfigurable regions.

[0250] In the example of FIG. 28, partitions X and Y appear to include equal subsets of resources. However, this need not be the case. One partition may be allocated more or fewer resources than the other partition. The shell, as implemented in SoC 100, and PMC 1602 can establish the allocation of SoC resources to and between partitions. Once established by the shell, the shell and / or PMC 1602 and host data processing system 2802 can implement user applications in different partitions and change the applications implemented in each partition over time.

[0251] For example, resources of SoC 100 allocated to partition X are shaded. Partition X corresponding to user X includes PCIeA / PF / VF circuit block 2816 from PS 106, DMA 2818, one or more PL functions 2824 (e.g., circuit blocks) implemented in PL 104, one or more of the available hardwired circuit blocks GT 2032, MAC 2030, and PCIPB 2842, one or more DPEs 204 in DPE array 102, and an area of ​​external RAM 2836 shown as SoC memory 2838 for user X. Partition Y, corresponding to User Y, to which the non-shaded resources of SoC 100 are allocated, includes PCIeA / PF / VF circuit block 2820 and DMA 2822 from PS 106, one or more PL functions 2828 (e.g., circuit blocks) implemented in PL 104, one or more other GTs 2032, another MAC 2030, and another PCIPB 2842 of available hardwired circuit blocks, one or more other DPEs 204 of DPE array 102, and different areas of external RAM 2836 shown as User Y's SoC memory 2840. In the example of FIG. 28 , cryptographic circuit block 2826 (e.g., a hardware accelerator engine) is shared between Partition X and Partition Y, but this need not be the case.

[0252] Each of Partition X and Partition Y has a signal path through NoC 108 and an access to external RAM 2836. and access to one or more memory controllers (not shown) for accessing the PCI bus. Signal paths are established by loading the PDIs of the applications running in each respective partition (e.g., DPE configuration data, NoC configuration data, PL configuration data, and / or PS configuration data that form the application). PCIBs 2842 and 2844 may be used to access external storage devices.

[0253] In this example, PMC 1602 (e.g., either in a shell or operating under the control of a shell) configures the SMID circuit block and PPC with the appropriate identifiers and permission bindings to prevent resources in partition X from accidentally or maliciously accessing resources in partition Y, and vice versa. The exception is that in this example, both partitions have access to encryption circuit block 2826. The isolation and firewall achieved, each with independent data paths, interrupts, control signals, etc., means that a malfunction or error in an application in one partition will not affect the operation of applications in the other partition.

[0254] With reference to PCIe A and DMA resource allocation between Partition X and Partition Y, security, performance, and error isolation of PCIe traffic between SoC 100 and host data processing system 2802 can be achieved at various levels of granularity based on the FaaS multi-tenant isolation configuration implemented by the shell and / or PMC 1602. In one aspect, for example, a dual-socket host data processing system or a single-socket host data processing system having multiple PCIe root ports can operate with SoC 100, which is configured to allocate one PCIe A controller to each of Partition X and Partition Y. Performance isolation between the partitions can be achieved so that host data processing system bursts to SoC traffic for one partition do not impede the bandwidth available to the other partition. Furthermore, a PCIe link error or PCIe link down condition in one partition can be isolated to that partition. The PMC can isolate power management functions for Partition X from Partition Y.

[0255] A host data processing system having a single host data processing system to SoC PCIe connection may have SoC 100 configured to assign one PCIe physical function (PF) to each of partition X and partition Y. Thus, a PCIe function-level reset (FLR) of the PF associated with one partition can isolate error detection and recovery operations from the other partition. PCIe PASID TLP prefixes and address translation caches (ATCs) may be simultaneously and independently utilized for shared virtual memory interaction between User X and User Y executing on host data processing system 2802 and User X and User Y role functions implemented on SoC 100 (e.g., applications implemented in respective partitions X and Y).

[0256] The dual-tenancy example of Figure 28 illustrates that inter-partition PL 104 and memory resource allocation can be performed. Each partition can have a portion of PL 104 and associated memory resources available to service applications implemented in that partition. The shell can make available to users X and Y a standard pre-designed library of functions with characterized PL usage and performance metrics. In an alternative example, users X and Y can each deploy one or more custom functions that utilize the available per-user partitioned resources of SoC 100.

[0257] As shown in Figure 28, external RAM 2836 (e.g., DDR) may be allocated between partitions. The FaaS multi-tenant solution implemented by the shell can achieve security, performance, and error isolation of off-chip memory resources between users. This can be achieved at various levels of granularity. For example, SoC 100 having multiple DDR controllers may be configured to include multiple DDR controllers, one or more assigned to user X and one or more other DDR controllers assigned to user Y. Performance isolation may be achieved such that a reduction in DDR bandwidth due to, for example, either line blocking or page collisions on the part of user X does not affect the bandwidth of user Y for applications running therein.

[0258] In another example, the SoC 100 can be configured to interleave multiple DDR controllers across the SoC address map. Additionally, address space for off-chip memory (e.g., external RAM 2836) can be reserved and isolated per user using a combination of SMID and PPC. Thus, applications running in one partition are prevented from accessing the address space of another partition. This isolation can be achieved while achieving the aggregate bandwidth possible by using multiple DDR controllers.

[0259] The NoC 108 can provide inter-partition security, performance, and error isolation for data movement and communication between components on the SoC 100 assigned to Partition X and components on the SoC 100 assigned to Partition Y. Isolation can be achieved at various levels of granularity based on the FaaS multi-tenant isolation configuration. For example, the NoC 108 and circuit block-to-circuit block and circuit block-to-memory paths utilizing the NoC 108's buffering resources can be allocated on a per-user basis. The NoC 108 can be programmed, for example, so that NoC physical paths and their dedicated virtual channels are allocated on a per-user (e.g., per-partition) basis. As described, SMIDs, whether inserted into transactions at the source or around them and / or by SMID circuitry implemented at the NoC 108 entry point, can be used by the PPC to enforce firewalls between users when transactions emerge from the NoC 108. In another example, the NoC 108 physical paths and dedicated virtual channels may be shared between users.

[0260] External I / O controllers and hardware acceleration blocks may also be allocated among users. For example, user X may be assigned a particular one of GT2032, MAC2030, and PCIB2842, while user Y may be assigned a different GT2032, a different MAC2030, and a different PCIB2844. Thus, both user X and user Y have dedicated PCIe and Ethernet interface controllers and associated I / O.

[0261] However, in other configurations, SoC 100 may support user X and user Y using built-in firewall functionality to simultaneously share the PCIe and Ethernet interface controllers and associated I / O. Additionally, in the illustrated example, both user X and user Y share access to cryptographic circuitry block 2826. The block is shown in each partition only to represent shared access to the hardwired circuitry block by different users. Cryptographic circuitry block 2826 may provide encryption / decryption services to user X and user Y, with each user using cryptographic circuitry block 2826 having a unique encryption key. This is true regardless of whether data traffic is served by PCIe or Ethernet.

[0262] 26, 27, and 28 in combination, the boot process of SoC 100, which is hierarchical in nature, facilitates the FaaS use case described in connection with FIG. 28. For example, boot code for SoC 100 may initially be provided (e.g., by the manufacturer of SoC 100) as block 0 of PDI 2700. A shell created by the FaaS provider may then be loaded as block 1 of PDI 2700. The shell establishes the partitioning of SoC 100 by allocating resources to each partition, as described above. However, the resources of SoC 100 are not configured during partitioning. Subsequently, Block 2 and Block 3, which correspond to applications to be implemented in Partition X and Partition Y, respectively, are loaded.

[0263] When implemented, each application is aware of only the SoC 100 resources assigned to the partition in which it is implemented. As part of the firewall, PMC 1602 is configured to allow each user to access only the configuration space corresponding to that user's partition. In other words, PMC 1602 only allows user X to access the configuration space (e.g., configuration registers) for SoC 100 resources assigned to partition X (for a particular subset of the PL, a particular subset of the DPE array, and / or a particular element in the PS). Similarly, PMC 1602 only allows user Y to access the configuration space for SoC 100 resources assigned to partition Y (for a particular subset of the PL, a particular subset of the DPE array, and / or a particular element in the PS).

[0264] PMC 1602 is programmable so that interrupts for various circuit blocks (e.g., see the common interface described in connection with FIG. 23 ) are enabled and disabled in each partition. PMC 1602 can further associate specific interrupts with specific SMIDs. Using this framework, User X can, for example, determine that a design (e.g., the portion of an application for Partition X that runs on the portion of PS 106 assigned to Partition X) does not need to distinguish between one or more different circuit blocks within a domain for purposes of handling interrupts. For example, a PS component in Partition X can execute the same interrupt service routine regardless of whether a user-defined block in Partition X or a hardware accelerator block in Partition X triggered the interrupt.

[0265] As noted above, in the example of FIG. 28, partitions X and Y are shown as being substantially identical in terms of resource allocation. However, in other examples, the partitions may be tailored to the needs of each user and / or application. For example, if user Y requires fewer resources than user X, then partition X may be allocated more resources and / or bandwidth than partition Y. A partition may, for example, provide user X with increased bandwidth on NoC 108 to accommodate increased resource usage by user X. The partitions need not be symmetric in terms of resource allocation and / or usage by each user.

[0266] In a multi-tenant FaaS use case, no user is aware of other users on SoC 100. In this regard, increased usage of SoC 100 by user X is limited to partition X and does not degrade usage of SoC 100 by user Y. The partitions maintain independence with respect to performance, error handling, and reliability.

[0267] In a multi-tenant example, as a user completes an operation, other users may be deployed in the partition assigned to the user who completed the operation. For example, consider a case where user X intends to perform extended processing that may take place over a long period of time while user Y performs video processing related to delivering video to a particular end user. When the end user stops consuming the video content, user Y may be removed from the partition on SoC 100. Another different user, say user Z, may be deployed in partition Y previously used by user Y using partial reconfiguration. While this is happening, user X can continue to operate in partition X uninterrupted, like a shell. Partial reconfiguration reconfigures either the resources and / or connectivity within the partition previously used by user Y. That is, a new user implemented in the partition can use any combination of PL, NoC, PS, and / or DPE array previously used by user Y, albeit with different configurations and / or functionality (e.g., different configuration images loaded into each subset of resources and / or different SMIDs and permission bindings). The new user may, for example, do audio processing rather than delivering video.

[0268] FIG. 29 illustrates another example of SoC 100 implementing different partitions. FIG. 29 illustrates an exemplary use case in which SoC 100 is utilized in an automobile or other vehicle. As illustrated, SoC 100 is divided into two different partitions 2902 and 2904. Partition 2902 implements an application that performs real-time processing. As illustrated, partition 2902 includes a real-time processing domain 2906 that includes an RPU 2910, one or more external communication circuit blocks (e.g., I / O and / or interfaces) 2908, and local RAM 2912. In one aspect, RPU 2910, external communication 2908, and local RAM 2912 may be implemented within PS 106. Real-time processing domain 2906 is connected to DDR controller 2914 via NoC 108. PPC 2920 provides memory protection and a firewall. As shown, NoC 108 and PPC 2920 are global resources that can be used by both partition 2902 and partition 2904 .

[0269] Partition 2904 is independent from partition 2902. Therefore, processing, errors, and / or performance issues in partition 2904 do not affect partition 2902. Applications implemented in partition 2904 perform multiple different functions, shown as programmable functions 1, 2, and 3. The programmable functions utilize DPE array 102 and PL area 104. Programmable function 1 performs image processing and may utilize one or more DPEs 2916 connected to computer vision functions 2918 implemented in PL 104. Computer vision functions 2918 within PL 104 (e.g., standard cores implemented in PL 104 and / or user-defined circuit blocks in PL 104) connect to NoC 108 and to multiple interleaved DDR controllers 2922 via PPC 2920. Programmable function 2 performs machine learning and may utilize one or more DPEs 2924 connected to machine learning functions 2926 implemented in PL 104. The machine learning functions 2926 in the PL 104 (e.g., standard cores implemented in the PL 104 and / or user-defined circuit blocks in the PL 104) connect to the NoC 108 and connect to multiple interleaved DDR controllers 2922 via the PPC 2920. The programmable functions 3 provide an interface to external devices and can utilize an external interface 2928 implemented in the PL 104. The external interface 2928 in the PL 104 (e.g., standard cores implemented in the PL 104 and / or user-defined circuit blocks in the PL 104) connect to the NoC 108 and connect to multiple interleaved DDR controllers 2922 via the PPC 2920.

[0270] 29 illustrates an example in which partition 2904 may be used to perform image processing on video data streams acquired from one or more cameras and / or other sensors in an automobile or other vehicle. Partition 2904 may perform operations such as lane detection, object recognition, other computer vision tasks, and / or machine learning. Partition 2902 may perform control and communication functions and may also manage other timing-critical real-time tasks. Features of interest, such as data acquired and / or generated by each partition, may be accessed from a shared area in DDR memory accessible by both partitions, as determined by the SMID assigned to the respective master and PPC 2920 in each partition.

[0271] As mentioned above, the sections 2902 and 2904 are separated from each other. Partition 2902 and partition 2904 operate without interfering with each other. For example, if an error is detected in partition 2904, applications implemented in partition 2902 can continue to run while partition 2904 is recovered (e.g., by resetting the partition and reloading the applications therein via a partial reconfiguration).

[0272] Applications implemented on SoC 100 may be implemented based on SoC 100 boot-time allocation of resources by PMC 1602. PMC 1602 creates addressability for each of the two partitions, for example, using a programmable address map. NoC 108 provides QoS-controlled data paths through each of partitions 2902 and 2904. Data paths through NoC 108 are programmed with isolation between the data paths to ensure freedom from interference. PMC 1602 programs memory protection circuitry 2920 to provide access to (and restrict access to) resources such as DDR, SRAM, peripherals, and other partitions.

[0273] PMC 1602 can also dynamically reconfigure one or both partitions (e.g., to perform partial reconfiguration) during operation of SoC 100, e.g., at runtime. For example, an application running on partition 2904 can be replaced with a different version of the application during runtime to perform different computer vision and / or machine learning operations. As an illustrative and non-limiting example, the application running on partition 2904 may be changed from one that uses a forward-facing camera to provide driving assistance (e.g., for faster driving) to one that provides parking assistance and uses a rear-facing camera. For example, the time required to switch from forward to reverse in a vehicle may be sufficient to trigger a partial reconfiguration of partition 2904 and partially reconfigure partition 2904. Driving assistance and parking assistance functions are provided for illustrative purposes only. Applications implemented on each respective partition may use different sensor data and process the sensor data differently. In another example, the entire device can be reconfigured to implement different partitions and / or different applications on each of partitions 2902 and 2904.

[0274] The automotive use case illustrates a further feature where partitions may include encrypted and / or non-encrypted partitions. For example, one partition may be implemented in a secure zone with high reliability for performing safety-critical functions, while another partition may have fewer security features required for providing entertainment functions (e.g., video streaming and / or audio processing). The partitions still have firewalls.

[0275] In the example of Figure 29, a single user owns both partition 2902 and partition 2904, so a shell does not need to be implemented. That is, while both Figures 28 and 29 show examples of partitioning, Figure 28 shows a multi-tenant model in which multiple users can use SoC 100 simultaneously, while Figure 29 shows SoC 100 being used by a single user who owns both partitions. The shell described in connection with Figure 28 can be used in combination with PMC 1602 to manage a multi-tenant implementation.

[0276] 30-32 illustrate different exemplary use cases for implementing PDI within SoC 100. The examples in Figures 30-32 illustrate various features of SoC 100 described herein above, such as the ability of a centralized component such as PMC 1602 to configure an entire device including PL 104, PS 106, NoC 108, DPE array 102, and hardwired circuit blocks 110. As noted above, in some cases, PS 106 can configure PL 104, NoC 108, DPE array 102, and hardwired circuit blocks 110.

[0277] 30-32 also show No. 1 and No. 2 diagrams for connecting various circuit components within the same compartment. 30-32 illustrate the use of common infrastructure of SoC 100, such as C108. Figures 30-32 further illustrate different examples of remapping. One example of remapping refers to dynamic partial reconfiguration, where resources within a partition of SoC 100 are reconfigured over time for use by other, different applications. Another example of remapping is when SoC 100 resources are reconfigured to create different partitions over time.

[0278] FIG. 30 illustrates an example method 3000 for implementing a PDI within SoC 100. A PDI implemented in SoC 100 may include configuration data for implementing multiple different partitions. Typically, a PDI that specifies multiple different partitions includes one partition that functions as a primary or master partition. This partition can control other secondary or slave partitions. As an illustrative example, the shell design described herein in connection with the FaaS example of FIG. 28 can operate as a primary partition. In another example, the real-time processing domain shown in FIG. 29 can operate as a primary partition.

[0279] In block 3002, SoC 100 is powered on. In block 3004, PMC 1602 is powered on and performs an initial security configuration of SoC 100. PMC 1602 may perform one or more operations, such as those described herein above with respect to FIG. 26 .

[0280] For example, in block 3004, the PMC 1602 may perform initial configuration of one or more circuit blocks within the SoC 100. The initial configuration may include, for example, setting up clocks and security settings within the SoC 100. The PMC 1602 may write configuration data to various PPCs of the SoC 100. At this stage, the PMC 1602 may write configuration data that allows only the PMC 1602 to access the PPCs and / or specific slaves protected by the PPCs. The PMC 1602 may further configure the SMID circuitry.

[0281] In another aspect, the PMC 1602 can write initial configuration settings to global registers (not shown) of the DPE array 102. The PMC 1602 can, for example, write to the NPI 710 to access these global registers. The global registers can, for example, specify how the DPE identifies itself with an SMID.

[0282] By default at power-on, the NoC 108 is not configured with any data paths. No circuit blocks can utilize the NoC 108 to communicate with any other circuit blocks after power-on. However, the PMC 1602 can use the NPI 710 to program the NoC 108 to establish an initial data path to the DPE array 102 for programming purposes. An exemplary method for initializing the NoC 108 is described in connection with FIG. 10 . Once configured by the PMC 1602, the initial data path can be used by the PMC 1602 to program applications into the DPE array 102 by writing to other configuration registers in the DPE array 102 (e.g., to program individual DPE 204 cores, memory modules, DMAs, switches, etc.).

[0283] In one aspect, PMC 1602 may operate in a power domain of SoC 100 that is independent from other subsystems and / or components contained within SoC 100. SMID circuitry and / or PPC circuitry may be included in the PMC power domain. This allows PMC 1602 to power up or power down other subsystems independently while maintaining the active and trusted center of gravity of SoC 100. Additionally, security settings created by PMC 1602 may be configured by SMID circuitry and / or PPC to power such circuits. Thus, the particular subsystem being protected can be maintained even though it has been powered off.

[0284] In block 3006, the PMC 1602 loads the PDI into the SoC 100. The PMC 1602 executes the PDI to create partitions and implement applications in the partitions. The PDI, for example, specifies multiple partitions and one application to be implemented in each of the different partitions of the SoC 100. The PDI can specify a primary partition and one or more secondary partitions, each implementing an application. In one example, when the PDI is loaded into the SoC 100 and executed by the PMC 1602, it implements the partitions as described in connection with FIG. 28. The partitions may include a shell and two or more different user partitions. In another example, when the PDI is loaded into the SoC 100 and executed by the PMC 1602, it implements the partitions as described in connection with FIG. 29.

[0285] In performing block 3006, PMC 1602 may authenticate the PDI as described in connection with block 2620 of Figure 26. Additionally, PMC 1602 may execute the PDI as described in connection with block 2626 of Figure 26. PMC 1602 may configure portions of PL 104, portions of PS 106, portions of NoC 108, portions of DPE array 102, and / or any hardwired circuit blocks used by each respective partition specified by the PDI.

[0286] The PDI can be created using electronic design automation (EDA) tools that enforce implementation rules. The implementation rules generally ensure that functionality (e.g., user and / or application) fits within the partitions created within the SoC 100. For example, based on the partitions implemented within the SoC 100, the EDA tool may assign a specific number of DPEs 204 to each of “N” different partitions, a specific amount (e.g., number of tiles) of PLs 104 to each of the N partitions, a specific memory controller to each of the N partitions or only to certain of the N partitions, a specific processor within the PS 106 to N partitions or only to certain of the N partitions, etc. Thus, as each application is implemented, the EDA tool effectively ensures that the application can fit into and run within the available partitions of the SoC 100.

[0287] As part of block 3006, PMC 1602 can adjust security settings for the various partitions specified by the PDI to implement firewalls and isolation for the partitions. For example, the PDI includes configuration data that PMC 1602 writes to configuration registers, PPC, and / or SMID circuitry of SoC 100 to complete the configuration of the circuitry to implement a firewall and prevent circuitry within a partition from accessing circuit resources of other partitions across partition boundaries. For example, PMC 1602 can configure the memory controller to allocate a pool of external memory used only by a particular partition within SoC 100 and another pool of external memory (e.g., non-overlapping memory) used only by a different partition within SoC 100.

[0288] Once SoC 100 is configured, the applications implemented in each partition can run. As described, following block 3006, SoC 100 can implement partitions and applications as described in connection with FIG. 28 or FIG. 29.

[0289] 31 illustrates another exemplary method 3100 for implementing PDIs within SoC 100 and reconfiguring SoC 100 over time. In the example of FIG. 31, SoC 100 may be configured by loading a first PDI. The first PDI may specify a particular partition of SoC 100. Thereafter, in response to a trigger event, SoC 100 may be reconfigured with a different PDI specifying a different partition of SoC 100. PMC 1602 may, for example, load a different PDI to specify a different trigger event. A control program may be executed that is responsible for loading different PDIs into SoC 100 over time in response to events (eg, signals and / or interrupts).

[0290] Thus, in block 3102, SoC 100 is powered on. In block 3104, the PMC is powered on and performs an initial security configuration of SoC 100. In block 3106, the PMC loads applications into SoC 100 to create multiple partitions and implements the applications in each partition. Blocks 3102, 3104, and 3106 may be performed substantially as described in connection with blocks 3002, 3004, and 3006 of FIG. 30, respectively.

[0291] In block 3108, PMC 1602 determines whether a trigger event has been detected. The trigger event may be detected by any of a variety of different circuits implemented within SoC 100. Such circuitry may detect the trigger event within SoC 100 itself and / or may detect the trigger event from an external source. In response to detecting the trigger event, such circuitry may generate an interrupt that may be provided to PMC 1602 and / or the primary partition. In some example implementations, PMC 1602 may be included within the primary partition.

[0292] In response to detecting the trigger event, method 3100 continues at block 3110 with loading a different PDI into SoC 100, executing the different PDI to create a partition, and implementing an application within the partition. In the example of FIG. 31, the different PDI may configure the entire SoC 100. The partition specified by the different PDI may be the same as the partition that existed before block 3108, although the partition may also be completely different. The application implemented in the partition may also be different from the application originally implemented in block 3106.

[0293] In loading the different PDIs, the PMC 1602 may perform, for example, blocks 2620 and 2626 of FIG. 26 . In the illustrated example, the PMC 1602 authenticates the different PDIs. The PMC 1602 then loads different blocks of configuration data from the different PDIs to assign the DPE 204, tiles of the PL 104, paths within the NoC 108, components of the PS 106, and / or hardwired circuit blocks 110 to different partitions designated by the different PDIs. The loading of the different PDIs in block 3110 illustrates an example of remapping, in which resources of the SoC 100 are effectively reallocated to different partitions. Furthermore, the resources within each partition can be reconfigured to implement different applications.

[0294] If no trigger event is detected at block 3108, method 3100 may continue to loop at block 3108 to monitor for the occurrence of a trigger event. While looping, the partitions originally performed at block 3106 and the applications implemented in each partition continue to run.

[0295] Method 3100 can continue to iterate. The example of FIG. 31 illustrates a case where multiple different PDIs are available and PMC 1602 loads different PDIs over time in response to different trigger events. It should be appreciated that each different type of trigger event that may be detected in block 3108 may be associated with a specific PDI. This allows SoC 100 to be reconfigured as needed in response to different conditions. As described above, the reconfiguration extends to all subsystems of SoC 100.

[0296] 32 illustrates another exemplary method 3200 for implementing a PDI within an SoC 100 and performing partial reconfiguration of the SoC 100 over time. In the example of FIG. 32, the SoC 100 may be configured by loading a first PDI. The first PDI may be configured to reconfigure a particular area of ​​the SoC 100. 32, the partial reconfiguration may extend to any type of circuitry and / or subsystems contained in the partitions undergoing partial reconfiguration. Thereafter, in response to a trigger event, SoC 100 may undergo a partial reconfiguration in which functionality (e.g., applications) in one or more partitions is dynamically reconfigured. While partial reconfiguration in conventional FPGA-type devices involves only changing functionality implemented in some portions of PL 104 while other portions continue to operate uninterrupted, in the example of FIG. 32, the partial reconfiguration extends to any type of circuitry and / or subsystems contained in the partitions undergoing partial reconfiguration.

[0297] Accordingly, in block 3202, SoC 100 is powered on. In block 3204, the PMC is powered on and an initial security configuration of SoC 100 is performed. In block 3206, PMC 1602 loads the PDI into SoC 100, executes the PDI to create multiple partitions, and implements applications in each partition. The multiple partitions include one primary partition (e.g., a shell or real-time processing domain) and one or more secondary partitions. Blocks 3202, 3204, and 3206 can be performed substantially as described in connection with blocks 3002, 3004, and 3006 of FIG. 30, respectively.

[0298] At block 3208, the PMC 1602 determines whether a trigger event has been detected to perform dynamic partial reconfiguration. The trigger event may be detected by any of a variety of different circuits implemented within the SoC 100. Such circuitry may detect the trigger event within the SoC 100 itself and / or may detect the trigger event from an external source. In response to detecting the trigger event, such circuitry may generate an interrupt that may be provided to the PMC 1602 and / or the primary partition. In some example implementations, the PMC 1602 may be included within the primary partition. In response to detecting the trigger event, the method 3200 continues at block 3210 and loads a different PDI into the SoC 100 to reconfigure one or more partitions therein.

[0299] In the example of FIG. 32, the different PDI reconfigures a partition of SoC 100 referred to as the "selected partition." The selected partition may be a secondary partition that is initially implemented in block 3206. Thus, while FIGS. 30 and 31 illustrate the reconfiguration of the entire SoC 100, FIG. 32 illustrates the partial reconfiguration of a single partition. That is, the different PDI includes only configuration data for configuring (or reconfiguring) the particular portion of PL 104, portion of PS 106, portion of NoC 108, portion of DPE array 102, and any hardwired circuit blocks 110 that are part of the selected partition.

[0300] In block 3210, the PMC 1602 loads and executes a different PDI to dynamically reconfigure the selected partition. The different PDI contains configuration data necessary for the PMC 1602 to configure any circuitry included in the selected partition being dynamically reconfigured. In executing block 3210, the PMC 1602 may authenticate the different PDI, as described in connection with block 2620 of FIG. 26 . The PMC 1602 may also execute block 2626 of FIG. 26 for portions of the PL 104, PS 106, NoC 108, hardwired circuit blocks 110, and / or DPE 204 that are part of the selected partition. The PMC 1602 does not overwrite other configuration data for any portions of the PL 104, PS 106, NoC 108, hardwired circuit blocks 110, and / or DPE 204 that are not part of the selected partition, for example.

[0301] Although method 3200 describes partial reconfiguration of SoC100 in relation to reconfiguring a single partition, it should be understood that in other aspects partial reconfiguration may include reconfiguring multiple partitions, but less than all partitions within SoC100.

[0302] For illustrative purposes, consider an example where the architecture of FIG. 28 is first implemented in which PMC 1602 includes a shell (not shown) in block 3206. In the FaaS example of FIG. 28, PMC 1602 may be incorporated into the shell. The shell may be implemented as a static, immutable domain that can create partitions and control applications implemented in dynamically reconfigurable partitions. Thus, the shell may include PMC 1602 and control partial reconfiguration of each secondary partition. The shell may include external I / O and / or other support circuitry that remains active and connected to the host processing system while one or more or all secondary partitions are being reconfigured. In yet another example, PMC 1602 may be separate from the shell but accessible only by the shell.

[0303] Continuing with the FaaS example of FIG. 28 , at block 3210, PMC 1602 may reconfigure partition Y for use by user Z (e.g., another application or role). In reconfiguring the selected partition, PMC 1602 may perform a process similar to that described in connection with blocks 2620 and 2626 of FIG. 26 . However, rather than configuring the entire SoC 100, the different PDIs loaded and executed cause PMC 1602 to reconfigure only the DPEs 204 of partition Y's DPE array 102 currently used by user Z, the tiles of partition Y's PL 104 currently used by user Z, and the portions of partition Y's NoC 108 currently used by user Z to establish data paths between user Z's circuits. PMC 1602 may also load configuration data (e.g., executable code and / or register settings) for the portions of partition Y's PS 106 used by user Z and / or any hardwired circuit blocks of partition Y used by user Z.

[0304] It should be understood that PMC 1602 does not write to configuration registers corresponding to resources allocated to partition X (e.g., portions of PL 104, portions of PS 106, particular DPE 204, portions of NoC 108, and / or hardwired circuit blocks 110). Thus, an application implemented in partition X continues to run uninterrupted while a different application corresponding to user Z is implemented in partition Y.

[0305] 29. In that case, in block 3206, PMC 1602 first implements partition 2902 and partition 2904. Partition 2902 implements an application corresponding to a low-power domain (e.g., an RPU, its assigned memory controller, and a pool of external RAM with connections established through NoC 108 corresponding to partition 2902). PMC 1602 further implements functionality in partition 2904, implements an application that utilizes one or more DPEs, implements one or more circuit blocks in PL 104, and uses a memory controller and another pool of external RAM with connections established in NoC 108 (e.g., corresponding to partition 2904).

[0306] Thus, in block 3210, PMC 1602 loads a different PDI into SoC 100 and executes the different PDI. PMC 1602 may implement different applications in partition 2904 to implement different functions, for example, in response to a particular trigger event detected. Referring to the previous example, partition 2904 can be dynamically reconfigured to implement a driving application to a parking application and vice versa. In the example of FIG. 32, SoC 100 undergoes dynamic partial reconfiguration to implement a different application in partition 2904, while the resources allocated to partition 2904 remain unchanged.

[0307] In some cases, memory controllers and / or other circuit blocks may be shared between partitions, depending on the degree of security and isolation required between the partitions. The controller can enforce memory isolation so that each partition can only access its own pool of memory that is independent from other partitions. However, in other cases, partitions may have some shared memory.

[0308] In the automotive example, SoC 100 implements applications corresponding to one user. That is, a particular entity may develop multiple applications that run simultaneously in different partitions of SoC 100. Each application may be owned by the same user, but each application runs in a different, isolated partition to meet safety requirements. For example, applications that use low-power domains and the RPU may have safety requirements that require isolation from other applications. Furthermore, in the automotive example, PMC 1602 operates at a level above the partitions implemented in SoC 100, allowing applications to run simultaneously and providing the control necessary to swap different applications in and out of partitions (e.g., via partial reconfiguration).

[0309] If a trigger event is not detected, method 3200 continues to loop until a trigger event is detected. SoC 100 continues to operate with each partition operating as currently configured. Applications implemented in each partition can operate independently because each partition is isolated from the others. As described above, in some cases, a doorbell interrupt can be used to cross from one partition to another to provide signaling and / or messaging between partitions.

[0310] While Figures 30-32 illustrate using PMC1602 to load different PDIs into SoC100, it should be understood that once SoC100 is booted and PS106 is configured, a processor within PS106 can be used to control the loading of PDIs and to reconfigure SoC100 in whole or in part (e.g., to perform a partial reconfiguration).

[0311] 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.

[0312] 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.

[0313] 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.

[0314] As defined herein, the term "automatically" means without human intervention.

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

[0316] As defined herein, the term "in response to" and similar terms such as "when," "when," or "when," 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.

[0317] 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.

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

[0319] As defined herein, the term "substantially" means that the recited characteristic, 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 skilled in the art, may occur in amounts that do not eliminate the effect that the characteristic is intended to provide.

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

[0321] 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.

[0322] In some alternative implementations, the actions noted in the blocks may occur out of the order noted 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 a different order, with the results stored and utilized in a subsequent block or in another block that does 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 special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0323] The corresponding structure, material, acts, and equivalents of all means-plus-function or step-plus-function elements that may be found in the following claims are expressly incorporated by reference. It is intended to include any structure, material, or act that performs a function in combination with other claimed elements that are specifically claimed.

[0324] The device may include a programmable logic circuit, a processor system coupled to the programmable logic circuit, and a network-on-chip coupled to the programmable logic circuit and the processor system. The network-on-chip is programmable to establish user-specified data paths communicatively linking circuit blocks implemented in the programmable logic circuit and the processor system. The device may include a platform management controller that configures the programmable logic circuit, the network-on-chip, and the processor system.

[0325] In another aspect, the programmable logic device, the network-on-chip, and the processor system are each configured to implement a portion of a user application having master and slave nodes, the user application specifying the data paths and implementation of each node within the programmable logic device or the processor system.

[0326] In another aspect, the device includes a data processing engine array coupled to the network-on-chip, and a user-specified data path further communicatively links the data processing engines of the data processing engine array to at least one of the circuit blocks implemented in the programmable logic circuit or processor system.

[0327] In another aspect, the data processing engine array is configured to implement a portion of a user application, the user application specifying the implementation of at least one of the nodes in the data processing engine array.

[0328] In another aspect, the device includes application-specific hardwired circuit blocks coupled to a network-on-chip, the application-specific hardwired circuit blocks and the circuit blocks implemented in programmable logic circuitry having a common interface.

[0329] In another aspect, the network-on-chip and the programmable logic circuit are configured to implement multiple independent partitions.

[0330] In another aspect, each partition implements a different application, and the applications are isolated from each other.

[0331] In another aspect, the device includes programmable protection circuitry configured to compare an identifier of a transaction source in a received transaction to a list of authorized transaction sources.

[0332] In another aspect, the programmable protection circuit further compares the address specified in the received transaction with the allowed addresses of the transaction source identifier.

[0333] In another aspect, the processor system and the circuit blocks implemented in the programmable circuit use a common descriptor format for communication.

[0334] The method may include providing a device including a programmable logic circuit, a processor system coupled to the programmable logic circuit, and a network-on-chip coupled to the programmable logic circuit and the processor system, the network-on-chip being programmable to establish user-specified data paths communicatively linking circuit blocks implemented in the programmable logic circuit and the processor system. The method can include configuring the programmable logic circuit, network-on-chip, and processor system using a platform management controller located within the device.

[0335] In another aspect, the method includes configuring each of the programmable logic device, the network-on-chip, and the processor system to implement a portion of a user application having a master node and a slave node, the user application specifying a data path and implementation of each node within the programmable logic device or the processor system.

[0336] In another aspect, a device includes a data processing engine array coupled to a network-on-chip, wherein user-specified data paths communicatively link the data processing engines of the data processing engine array to at least one of the circuit blocks implemented in the programmable logic circuit or processor system.

[0337] In another aspect, the method includes configuring a data processing engine array to implement a portion of a user application, the user application specifying an implementation of at least one of the nodes in the data processing engine array.

[0338] In another aspect, the device includes application-specific hardwired circuit blocks coupled to a network-on-chip, in which case the method can include providing a common interface for the application-specific hardwired circuit blocks and circuit blocks implemented in programmable logic circuitry.

[0339] In another aspect, a method includes configuring a network-on-chip and a programmable logic circuit to implement a plurality of independent partitions.

[0340] In another aspect, the method includes dynamically reconfiguring at least one of the plurality of independent partitions.

[0341] In another aspect, the method includes implementing a different application in each partition and isolating the applications from one another.

[0342] In another aspect, a method includes providing a programmable protection circuit in a device and configuring the programmable protection circuit to compare an identifier of a transaction source in a received transaction to a list of authorized transaction sources.

[0343] In another aspect, the method includes configuring the programmable protection circuit to compare an address specified in a received transaction with an allowed address of an identifier of a transaction source.

[0344] 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 terminology used herein has been selected to explain the principles of the inventive configurations, their practical applications, or technical improvements over technology found in the marketplace, 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. An integrated circuit, the integrated circuit comprising: a first interface configured to operate with multiple tenants simultaneously implemented in the integrated circuit, the multiple tenants communicating with a host data processing system using the first interface, the integrated circuit further comprising: a second interface configured to operate with the plurality of tenants, the plurality of tenants communicating over a network with one or more network nodes using the second interface; and the integrated circuit further comprising: a programmable logic circuit configured to operate with the plurality of tenants, the programmable logic circuit implementing one or more hardware acceleration functions for the plurality of tenants and routing data between the first interface and the second interface; the first interface, the second interface, and the programmable logic circuit are configured to provide isolation between the multiple tenants.

2. The integrated circuit of claim 1 , wherein the first interface is configured to assign a first physical function to each tenant of the plurality of tenants.

3. 2. The integrated circuit of claim 1, wherein the first interface includes a plurality of Peripheral Component Interconnect Express (PCIe) controllers, and wherein each tenant of the plurality of tenants is assigned a PCIe controller of the plurality of PCIe controllers.

4. The integrated circuit of claim 1 , wherein the second interface is shared among the multiple tenants while maintaining isolation among the multiple tenants.

5. 2. The integrated circuit of claim 1, wherein the second interface includes a plurality of Ethernet interface controllers and a plurality of inputs / outputs, and wherein each tenant of the plurality of tenants has a dedicated Ethernet interface controller of the plurality of Ethernet interface controllers and a dedicated input / output of the plurality of inputs / outputs.

6. 10. The integrated circuit of claim 1, wherein the programmable logic circuit implements a plurality of hardware accelerated functions, at least one of the plurality of hardware accelerated functions corresponding to each tenant of the plurality of tenants.

7. The integrated circuit of claim 1 , wherein the one or more hardware accelerated functions include encryption techniques.

8. The integrated circuit of claim 1 , wherein the one or more hardware accelerated functions include machine learning.

9. The integrated circuit of claim 1 , wherein the one or more hardware accelerated functions include image processing.

10. a hardwired circuit block configured to implement selected hardware acceleration functions for selected tenants of the plurality of tenants; the programmable logic device implementing a circuit block configured for use with the selected tenant; The integrated circuit of claim 1 , wherein the hardwired circuit blocks and the circuit blocks of the programmable logic circuit use a common descriptor definition.

11. The integrated circuit of claim 10 , wherein the circuit blocks of the programmable logic circuit implement the selected hardware accelerated functionality for the selected tenant.

12. The integrated circuit of claim 10 , further comprising a processor configured to execute program code, said processor using said common descriptor definition.

13. 11. The integrated circuit of claim 10, further comprising a data processing engine array including a plurality of data processing engines, said plurality of data processing engines using said common descriptor definition.

14. 11. The integrated circuit of claim 10, wherein the hardwired circuit block is one of a plurality of hardwired circuit blocks, each of the plurality of hardwired circuit blocks including a cryptographic engine, each cryptographic engine using the common descriptor definition.

15. The integrated circuit of claim 10 , wherein each of the hardwired circuit blocks and the circuit blocks of the programmable logic circuit are configured to provide isolation from other tenants of the plurality of tenants.

16. a hardwired circuit block configured to implement selected hardware acceleration functions for selected tenants of the plurality of tenants; the programmable logic circuitry implements circuit blocks configured to implement the selected hardware acceleration functionality for the selected tenant; 2. The integrated circuit of claim 1, wherein the selected hardware accelerated functions are remapped from the hardwired circuit blocks to the circuit blocks in the programmable logic circuit or from the circuit blocks in the programmable logic circuit to the hardwired circuit blocks.

17. 17. The integrated circuit of claim 16, wherein the circuit blocks of the programmable logic circuit and the hardwired circuit blocks have a common interface.

18. 17. The integrated circuit of claim 16, wherein the hardwired circuit blocks and the circuit blocks of the programmable logic circuit use a common descriptor definition.

19. The integrated circuit of claim 16 , wherein isolation between the multiple tenants is maintained during the remapping.

20. The integrated circuit of claim 16 , wherein the selected hardware accelerated function is remapped without disrupting operation of the selected tenant.

Images