Adaptive 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 the 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 multiple independent partitions.

[0008] In another aspect, the device includes an application specific hardwired circuit block coupled to the network on chip. 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 include a A programmable protection circuit is included that is configured to isolate the multiple independent partitions by comparing the identifier to a list of authorized transaction sources.

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

[0011] In another aspect, the processor system and the circuit blocks implemented in the programmable circuitry 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 the 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 multiple 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 a plurality of independent partitions by 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.

[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 subject matter 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: The invention should not be construed as limiting the scope of the invention to the particular embodiments illustrated in the drawings, and various aspects and advantages will become apparent upon consideration of the following detailed description and upon reference to the drawings. [Brief description of the drawings]

[0021] [Figure 1]1 shows an exemplary architecture for a system-on-chip (SoC) type of integrated circuit (IC). [Diagram 2] 2 illustrates an exemplary implementation of a data processing engine (DPE) array for the SoC of FIG. 1. [Diagram 3] 3 illustrates an example architecture of a DPE of the DPE array of FIG. 2. [Figure 4] 4 illustrates further aspects of the example architecture of FIG. 3. [Diagram 5] 4 illustrates another exemplary architecture of a DPE array. [Figure 6] 1 illustrates an example architecture of a tile of a SoC interface block of a DPE array. [Figure 7] 2 illustrates an exemplary implementation of the network-on-chip (NoC) of FIG. [Figure 8] 2 is a block diagram showing a connection between an endpoint circuit in the SoC of FIG. 1 and a NoC. [Figure 9] FIG. 13 is a block diagram showing 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 a NoC between endpoint circuits. [Figure 13] 1 illustrates an exemplary method for processing read / write requests and responses associated with a 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 a NoC peripheral interconnect. [Figure 17] 4 shows an example table used by the NoC. [Figure 18] 1 illustrates an exemplary method for operating a SoC. [Figure 19] 1 is an exemplary method for partially reconfiguring a NoC. [Figure 20] 2 illustrates another exemplary implementation of the SoC of FIG. [Figure 21] 1 illustrates an exemplary embodiment 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. [Figure 24] 2 illustrates further structural and functional aspects of the SoC of FIG. [Diagram 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] 3 illustrates another exemplary SoC implementing different partitions. [Diagram 30] 1 illustrates an exemplary method for implementing a Programming Device Image (PDI) within an SoC. [Diagram 31] 1 illustrates another exemplary method for implementing a PDI within a SoC and reconfiguring the SoC over time. [Diagram 32] 1 illustrates another exemplary method for implementing PDI within an SoC and performing partial reconfiguration of the SoC over time. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0023] The present disclosure relates to integrated circuits (ICs), and more particularly to an integrated programmable device platform (platform) that provides a variety of heterogeneous subsystems. The platform leverages the various subsystems described to provide numerous advantages. For example, the platform 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 those 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 the 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 in 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 in the platform. Furthermore, the platform allows any of the various components of the device to utilize the common infrastructure to access subsystems such as programmable logic.

[0026] In another aspect, a particular function 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 to 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 in 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 in the platform can continue to operate in the same manner despite the remapping of the encryption acceleration function. Remapping of one function of an application implemented in the platform does not require remapping of 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 therein. Each partition, and the applications running therein, may be isolated from each of the other partitions within the platform. The term "application" as used herein with respect to the platform and exemplary SoC described herein 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 partitioning also supports 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 various components of the device 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, dimensions of some elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding, similar or like features.

[0030] 1 illustrates an example architecture of 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 in PL 104 include, but are not limited to, configurable logic blocks (CLBs), dedicated random access memory blocks (BRAMs and / or UltraRAMs or URAMs), 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). Typically, the interconnect wires are 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, and the like. The programmable interconnect and programmable logic circuitry may be programmed by loading configuration data into internal configuration memory cells that define how the programmable elements are configured and behave.

[0034] The PS 106 is implemented as a hardwired circuit that is fabricated as part of the SoC 100. The PS 106 may be implemented as or include any of a variety of different processor types, each capable of executing program code. For example, the PS 106 may be implemented as an individual processor, e.g., a single core capable of executing program code. In another example, the PS 106 may be realized as a multi-core processor. In yet another example, the PS 106 may include one or more cores, modules, co-processors, interfaces, 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 interconnect network for sharing data between endpoint circuits in the SoC 100. The endpoint circuits may be located in the DPE array 102, the PL 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 examples. 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. For a programmable NoC used 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, but 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 a number of programmable switches that can establish a packet-switched network connecting user-specified master and slave circuits. In this regard, the NoC 108 can accommodate different circuit designs, each having a different combination of master and slave circuits implemented at different locations within the SoC 100 that can be coupled by the NoC 108. The NoC 108 can be programmed to route data, such as application data and / or configuration data, between the master and slave circuits of the user circuit design. For example, the NoC 108 can be programmed to couple different user-specified circuits implemented within the PL 104 with the PS 106 and / or the DPE array 102, with different hardwired circuit blocks, and / or with 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, memory controllers, etc. 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, cryptographic 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, the PL 104 is shown in two separate regions. In another example, the PL 104 may be implemented as a unified region of programmable circuitry. In yet another example, the PL 104 may be implemented as three or more distinct regions of programmable circuitry. The particular organization of the PL 104 is not intended to be limiting. Here, the SoC 100 includes one or more PL regions 104, a PS 106, and a NoC 108. A DPE array 102 may optionally be included.

[0040] In other exemplary implementations, the SoC 100 may include two or more DPE arrays 102 located in different areas of the IC. In yet other examples, the SoC 100 may be implemented as a multi-die IC. In that 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 techniques, 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), or the like. 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 that include 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 may include a plurality of 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 may 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 may be directly coupled to each DPE 204 in the bottom 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, the SoC interface block 206 may be located at the top of the DPE array 202, to the left of the DPE array 202 (e.g., as a column), to the right of the DPE array 202 (e.g., as a column), or in multiple locations within and around the DPE array 202 (e.g., as one or more intervening rows and / or columns within the DPE array 202). Depending on the layout and location of the SoC interface block 206, the particular DPEs coupled to the SoC interface block 206 may vary.

[0044] For purposes of illustration, if SoC interface block 206 is located to the left of DPE 204, then SoC interface block 206 may be coupled directly to the left row 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, then SoC interface block 206 may be coupled directly to the right row of DPEs including DPE 204-10, DPE 204-20, DPE 204-30, and DPE 204-40. If the SoC interface block 206 is located on top of the DPE 204, the 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 the SoC interface block 206 is located in multiple locations, the particular DPEs directly connected to the SoC interface block 206 may vary. For example, if the SoC interface block is implemented as rows and / or columns in the DPE array 202, the DPEs directly coupled to the SoC interface block 206 may be the DPEs adjacent to the SoC interface block 206 on one or both sides of the 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 the selected A connection between the DPE 204 and the PL 104 can be established. The SoC interface block 206 can also establish a connection between the 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 certain 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 certain embodiments, the hardwired circuit blocks 110 can be considered an example of an ASIC.

[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 the other subsystems. In certain embodiments, the SoC interface block 206 includes a clock signal generator that may generate one or more clock signals that may 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 illustrates 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 a core 302, a memory module 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. Program memory 308 may then be included to store instructions executed by core 302. Core 302 may be implemented as, for example, a CPU, GPU, DSP, vector processor, or other type of processor capable of executing instructions. Core 302 may be implemented using any of a variety of 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, the program memory 308 is dedicated to the core 302 (e.g., the core 3 302)と。 The program memory 308 may be used only by the cores of the same DPE 204. Thus, the program memory 308 may be accessed only by the cores 302 and is not shared with other DPEs or components of other DPEs. The program memory 308 may include a single port for read and write operations. The program memory 308 may support program compression and is addressable using a memory-mapped network portion of the DPE interconnect 306, which is described in more detail below. For example, through the memory-mapped network of the DPE interconnect 306, the program memory 308 may be loaded with program code that may be executed by the cores 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) that are written by core 302.

[0054] In one or more other embodiments, the 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 the memory module 304. In certain embodiments, the other cores that may read from and / or write to the 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) the DPE 204 is said to be a "neighboring" DPE with respect to the DPE 204. By allowing the core 302 and one or more other cores from adjacent DPEs to read and write to the memory module 304, the memory module 304 implements a shared memory that supports communication between different DPEs and / or cores that may access the 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 in each of DPEs 204-16, 204-5, and 204-25 can read from and write to a memory module in DPE 204-15. In certain embodiments, only the neighbors that are adjacent to a memory module can access the memory module of DPE 204-15. For example, DPE 204-14 may be adjacent to DPE 204-15, but not adjacent to the memory module of DPE 204-15, because the core of DPE 204-15 may be located between the core of DPE 204-14 and the memory module of DPE 204-15. Thus, in certain embodiments, the 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 such a core can read from and write to a fourth memory interface depends on the number of memory interfaces included in the memory module and whether such a core is connected to an available one of the memory interfaces of the memory module. In the above example, 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. The 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 such that a particular core attached to it can simultaneously read from and / or write to multiple banks in the memory module 304.

[0057] In other examples, more than four memory interfaces may be available. Such other memory interfaces may be used to allow DPEs diagonally opposite DPE 204-15 to access memory modules of DPE 204-15. 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 memory modules of DPE 204-15, such other DPEs may also access memory modules of DPE 204-15.

[0058] Memory module 304 may include configuration registers 336. Configuration registers 336 may be loaded with configuration data to control 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 local 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 further enables configuration, control, and debugging of DPE 204.

[0060] In a particular embodiment, the 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 is therefore 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, the DPE interconnect 306 includes two distinct networks. A first network may exchange data with other DPEs in the DPE array 102 and / or other subsystems of the SoC 100. For example, the first network may exchange application data. A second network may exchange data, such as configuration, control, and / or debug data for the DPEs.

[0062] In the example of FIG. 3, a 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, the memory modules 304, the memory mapped switch 332, the upper DPE, the left DPE, the right DPE, and the lower DPE. Each stream interface can include one or more masters and one or more slaves.

[0063] The stream switch 326 may enable non-adjacent DPEs and / or DPEs that are 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 point of reference, stream switch 326 may be coupled to and communicate with another stream switch located in the DPE interconnect of DPE 204-14. Stream switch 326 may be coupled to and communicate with another stream switch located in the DPE interconnect of DPE 204-25. Stream switch 326 may be coupled to and communicate with another stream switch located in the DPE interconnect of DPE 204-16. Stream switch 326 may be coupled to and communicate with another stream switch located in the DPE interconnect of DPE 204-5. Thus, core 302 and / or memory module 304 may also communicate with any of the DPEs in DPE array 102 via the DPE interconnect in the DPE.

[0065] The stream switch 326 may also be used to interface with subsystems such as the PL 104 and / or the NoC 108. In general, the stream switch 326 is programmed to operate as a circuit switching stream interconnect or a packet switching stream interconnect. A circuit switching stream interconnect can implement point-to-point dedicated streams suitable for high bandwidth communication between DPEs. A packet switching stream interconnect allows for stream sharing to time multiplex 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 a memory-mapped network of the DPE interconnect 306. The configuration data loaded into the configuration register 334 dictates which other DPEs and / or subsystems (e.g., NoC 108, PL 104, and / or PS 106) the DPE 204 will communicate with, and whether such communications will be established as circuit-switched, point-to-point connections or as packet-switched connections.

[0067] A second network of the DPE interconnect 306 is formed from a memory-mapped switch 332. The 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, the memory-mapped switch 332 includes memory-mapped interfaces for connecting to each of the cores 302, the memory modules 304, memory-mapped switches in DPEs above the DPE 204, and memory-mapped switches in DPEs below the 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 cores 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 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 the stream switches of each DPE can be programmed by loading configuration data through the memory-mapped switches. Through configuration, the stream switches and / or stream interfaces are programmed to establish connections with other endpoints, whether packet-switched or circuit-switched, in one or more other DPEs 204 and / or in the SoC interface block 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 in the DPE 204 can be accessed via a memory-mapped interface. For example, memory in memory module 304, program memory 308, configuration register 324 in core 302, configuration register 336 in 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 may receive configuration data for the DPE 204. The configuration data may 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 a circuit switching mode between two different DPEs and / or other subsystems, or in a 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 the connectivity of the core 302 with other DPEs via shared memory. Figure 4 also illustrates additional aspects of the memory module 304. For illustrative purposes, Figure 4 refers to DPE 204-15.

[0074] As shown, the memory module 304 includes multiple memory interfaces 402, 404, 406, and 408. In FIG. 4, the memory interfaces 402 and 408 are abbreviated as "MI." The memory module 304 further includes multiple memory banks 412-1 through 412-N. In a particular embodiment, the memory module 304 includes eight memory banks. In other embodiments, the 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 the memory module 304 includes eight memory banks 412, such a configuration supports eight parallel accesses in each 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 the memory banks 412-1 through 412-N has a respective arbiter 414-1 through 414-N. Each arbiter 414 may generate a stall signal in response to detecting a conflict. Each arbiter 414 may include arbitration logic. Additionally, each arbiter 414 may include a crossbar. Thus, any master may write to any particular one or more of the memory banks 412. As discussed in connection with FIG. 3, the memory module 304 is connected to a memory mapped switch 332, thereby facilitating the reading and writing of data to the memory banks 412. Thus, certain data stored in the memory module 304 may be controlled, e.g., written, as part of a configuration, control, and / or debug process via the 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 out 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-5. The memory interface 408 provides the core of the DPE 204-5 with access to the memory bank 412. Each DPE that has a shared boundary with memory modules 304 of DPEs 204-15 can read from and write to memory bank 412. In the example of Figure 4, a 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 a memory interface of DPE 204-25. Thus, core 302 can access memory modules of DPE 204-25 via core interface 434 and a memory interface included in the memory module of DPE 204-25. Core interface 432 is coupled to a memory interface of DPE 204-14. Thus, core 302 can access memory modules of DPE 204-14 via core interface 432 and a memory interface included in the memory module of DPE 204-14. Core interface 430 is coupled to a memory interface in DPE 204-5. Thus, core 302 can access memory modules of DPE 204-5 via core interface 430 and a memory interface included in the memory module of DPE 204-5. As explained, the core 302 can access the memory module 304 in the DPE 204-15 via the core interface 428 and the memory interface 402.

[0079] In the example of Figure 4, core 302 may 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 may 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 may generate addresses for reads and writes assuming this contiguous memory model. Core 302 may direct read and / or write requests to the appropriate core interfaces 428, 430, 432, and / or 434 based on the generated addresses.

[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 forwards the memory operation to the correct core interface in the determined direction.

[0081] Thus, core 302 may communicate with cores of DPE 204-25 via a shared memory, which may be a memory module in DPE 204-25 and / or memory module 304 of DPE 204-15. Core 302 may communicate with cores of DPE 204-14 via a shared memory, which may be a memory module in DPE 204-14. Core 302 may communicate with cores of DPE 204-5 via a shared memory, which may be a memory module in DPE 204-5 and / or memory module 304 of DPE 204-15. Additionally, core 302 may communicate with cores of DPE 204-16 via a shared memory, which may be a memory module 304 in 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 in the memory module 304.

[0083] The DMA engine 416 may include one or more memory-to-stream interfaces. Through the DMA engine 416, data may be read from the memory bank or memory banks 412 of the memory module 304 and sent to other destinations through the stream interfaces. For example, the DMA engine 416 may read data from the memory module 304 and send such data to other DPEs that share and / or do not share a boundary with the DPE 204-15 through 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) through the stream switch and the SoC interface block 206.

[0084] In one or more embodiments, the DMA engine 416 is programmed by the memory mapped switch 332 in the DPE 204-15. For example, the DMA engine 416 may be controlled by the configuration registers 336. The configuration registers 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 the 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 the core 302 depending on configuration data loaded into configuration registers 324 , 334 and / or 336 .

[0085] The memory module 304 may further include a hardware synchronization circuit 420 (abbreviated as "HSC" in FIG. 4). In general, the hardware synchronization circuit 420 may synchronize the operation of different cores (e.g., cores of adjacent DPEs), the cores 302 of FIG. 4, the DMA engine 416, and other external masters (e.g., PS 106) that may communicate via the DPE interconnect 306. As an illustrative and non-limiting example, the 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 the DPE 204-15 and / or memory module 304.

[0086] If the two DPEs are not adjacent, the two DPEs cannot access a common memory module. In that case, the application data may be transferred via a data stream (the terms "data stream" and "stream" may be used interchangeably at times within this disclosure). Thus, the 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 the shared memory module and adjacent and / or non-adjacent DPEs via the DPE interconnect 306, the core 302 may include cascade interfaces. In the example of FIG. 4, the core 302 includes cascade interfaces 422 and 424 (abbreviated as "CI" in FIG. 4). The cascade interfaces 422 and 424 may provide direct communication with other cores. As shown, the cascade interface 422 of the core 302 receives an input data stream directly from a core of the DPE 204-14. The data stream received via the cascade interface 422 may be provided to data processing circuitry within the core 302. The cascade interface 424 of the core 302 may transmit an output data stream directly to a core of the DPE 204-16.

[0089] In the example of FIG. 4, each of the cascade interfaces 422 and 424 may include a first-in, first-out (FIFO) interface for buffering. In a particular embodiment, the cascade interfaces 422 and 424 may carry a data stream that may be hundreds of bits wide. The particular bit widths of the cascade interfaces 422 and 424 are not intended as limitations. In the example of FIG. 4, the cascade interface 424 is coupled to an accumulator register 436 (abbreviated as "AC" in FIG. 4) in the core 302. The cascade interface 424 may output the contents of the accumulator register 436, and may do so every clock cycle. The accumulation register 436 may store data generated and / or operated on by data processing circuits in the 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 to read from and write to cascade interfaces 422 and / or 424. In another example, core 302 may include hardwired circuitry that can read from and / or write 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, thus avoiding significant processing overhead.

[0093] According to one or more embodiments, the cores 302 of the DPE 204 do not have input interrupts. Thus, the cores 302 of the DPE 204 can operate uninterrupted. Eliminating the input 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 illustrates another exemplary architecture of a DPE array. In the example of Figure 5, the 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, the SoC interface block 206 includes multiple interconnected tiles. For example, the SoC interface block 206 includes tiles 502, 504, 506, 508, 510, 512, 514, 516, 518, and 520. In the example of FIG. 5, the tiles 502-520 are organized in a row. In other embodiments, the tiles may be arranged in a row, a grid, or another layout. For example, the SoC interface block 206 may be implemented as a row of tiles to the left of the DPE 204, to the right of the DPE 204, between the rows of DPEs 204, etc. In another embodiment, the SoC interface block 206 may be located above the DPE array 202. The SoC interface block 206 may be implemented such that the tiles are located in any combination below the DPE array 202, to the left of the DPE array 202, to the right of the DPE array 202, and / or above the DPE array 202. In this regard, FIG. 5 is provided for purposes of illustration and not limitation.

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

[0097] In the example of FIG. 5, tiles 502-520 are coupled such that data may be propagated from one tile to another. For example, data may propagate from tile 502, through tiles 504 and 506, down the line of tiles to tile 520. Similarly, data may propagate in the reverse direction from tile 520 to tile 502. In one or more embodiments, each of tiles 502-520 may act as an interface to multiple DPEs. For example, each of tiles 502-520 may act as an interface to a subset of DPEs 204 in DPE array 102. The subset of DPEs to which each tile provides an interface may be mutually exclusive such that a DPE is not provided an interface 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 in which data received from tile 502 addressed to DPEs in column B is provided to such DPEs.

[0100] In this manner, data may propagate from tile to tile in the SoC interface block 206 until it reaches a tile that acts as an interface for the DPE to which the data is addressed (e.g., a "target DPE") The tile that acts as an interface for the target DPE may 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 the SoC interface block 206 may provide an interface to a row of DPEs in the DPE array 102. Such a configuration may be used when the 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 DPEs that are less than all DPEs in the DPE array 102. For example, DPEs 204 may be assigned to tiles in the SoC interface block 206. The particular physical layout of such DPEs may vary based on the connectivity of the DPEs 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 the SoC interface block 206 may provide interfaces to four other DPEs, and so on.

[0102] 6 illustrates an example architecture of tiles for the SoC interface block 206. In the example of FIG. 6, two different types of tiles are shown for the SoC interface block 206. Tile 602 is configured to act as an interface between only the DPE and the PL 104. Tile 610 is configured to act as an interface between the DPE and the NoC 108 and between the DPE and the PL 104. The 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] In the example of Figure 6, tile 602 includes a PL interface 606 and a stream switch 604 connected to a DPE, such as DPE 204-1, located immediately above. PL interface 606 connects to a boundary logic interface (BLI) circuit 620 and a BLI circuit 622, each located in PL 104. Tile 610 includes a NoC and PL interface 614 and a stream switch 612 connected to a DPE, such as DPE 204-5, located immediately above. NoC and PL interface 614 connects to a BLI circuit 624 in PL 104. and 626 , as well as a NoC master unit (NMU) 630 and a NoC slave unit (NSU) 632 of the 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. Each of the PL interface 606 and NoC-and-PL interface 614 can provide six different 64-bit data streams to the PL 104 by way of the BLI 620 and BLI 624, respectively. In general, each of the BLIs 620, 622, 624, and 626 provides an interface or connection point within the PL 104 to which the PL interface 606 and / or NoC-and-PL interface 614 connect. Each of the PL interface 606 and NoC-and-PL interface 614 can receive eight different 64-bit data streams from the PL 210 via the 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 long as the tiles are to the right or left, as the case may be).

[0107] Each of the tiles 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 DPEs directly 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 association with the various switches included in the DPE 204 and / or tiles 602 and / or 610 of the SoC interface block 206 are provided for illustrative purposes and are not intended to limit the inventive configurations described within this disclosure.

[0109] 7 illustrates an exemplary implementation of the NoC 108. The NoC 108 includes a NoC Master Unit (NMU) 702, a NoC Slave Unit (NSU) 704, a network 714, a NoC Peripheral Interconnect (NPI) 710, and a register 712. Each NMU 702 is an ingress circuit that connects an endpoint circuit to the NoC 108. Each NSU 704 is an egress circuit that connects the NoC 108 to an endpoint circuit. The NMU 702 is connected to the NSU 704 via a network 714. In one example, the network 714 includes a NoC packet switch 706 (NPS) 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 NMU 702 and NSU 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 thereof 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 in 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 a non-volatile 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 ingress point. NSU 704 is a traffic egress point. The endpoint circuitry coupled to NMU 702 and NSU 704 may be hardened circuitry (e.g., hardwired circuit block 110) or circuitry implemented in PL 104. A given endpoint circuit may be coupled to multiple NMUs 702 or multiple NSUs 704.

[0112] 8 is a block diagram illustrating connections between endpoint circuits in 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 NMUs 702 connect with the NSUs 704 through at least one physical channel 806. The physical channels 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 a NoC 108 according to another example. In this example, the NoC 108 includes a vertical portion 902 (VNoC) and a horizontal portion 904 (HNoC). Each VNoC 902 is disposed between the PL regions 104. The HNoC 904 is disposed between the PL regions 104 and an I / O bank 910 (e.g., an I / O block and / or transceiver corresponding to a hardwired circuit block 110). The NoC 108 is connected to a memory interface 908 (e.g., another hardwired circuit block 110). The PS 106 is coupled to the HNoC 904.

[0116] In this example, the PS 106 includes multiple NMUs 702 coupled to an HNoC 904. The VNoC 902 includes both the NMUs 702 and the NSUs 704 located in 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 runs vertically. In the HNoC 904, the routing runs 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. Although the memory interface 908 is shown as an 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 at least configuration information for physical channel 806 between NMU 702 and NSU 704. The remaining configuration information for NoC 108 may be received during run-time, as described further below. In another example, all or a portion of the configuration information described below as being received during run-time may be received at boot time.

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

[0122] 12 illustrates an exemplary data path 1200 through the NoC 108 between endpoint circuits. The data path 1200 includes an endpoint circuit 1202, an AXI master circuit 1204, an NMU 1206, an NPS 1208, an NSU 1210, an AXI slave circuit 1212, and an endpoint circuit 1214. The endpoint circuit 1202 is coupled to the AXI master circuit 1204. The AXI master circuit 1204 is coupled to the 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 NPS 1208 are connected together to form a chain of NPSs 1208 (e.g., a chain of five NPSs 1208 in this example). Typically, 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 may 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. Although 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 a 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 circuits 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 crossing and rate matching between the clock domain of the endpoint circuit 1202 and the NoC 108. The NMU 1206 determines a 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 NMU 1206 sends the packet through 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 crossover 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 through the AXI master circuit 1204.

[0128] FIG. 14 illustrates 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 that 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 may 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 illustrates 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 circuit. In other examples, different protocols may be used, and thus the NSU 704 may have different slave interfaces that conform to the selected protocol. 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. The QoS circuitry 1510 may provide ingress rate control for controlling the injection rate of packets into the NoC 108 .

[0130] FIG. 16 illustrates an example connection to a register block 712 of the 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 the PMC 1602. In some examples, the PMC 1602 resides in the PS 106, while in other examples, the root node 1604 and the PMC 1602 may be separate circuits or may reside on separate systems or circuits. In general, the root node 1604 routes transaction requests to the NPI 1604. 16. The memory-mapped transaction request may be packetized into a format implemented by the register block 712 and sent to the NPI switch 1608, which may further send the memory-mapped transaction request to other NPI switches 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 a configuration interconnect 1612, which is connected to PL domain 104. PMC 1602 is configured to program the fabric of PL domain 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 mentioned, the register block 712 includes registers that are programmed to create a corresponding routing table for the NPS 706. FIG. 17 illustrates a routing table 1700, according to an 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 that is 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). The rows of the routing table correspond to the port-virtual channel combinations (Port-VCs) at which the packets are received. The columns of the routing table correspond to the destination identifications (IDy) 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 IDy. In some examples, an entry for a given IDy 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 a destination identification contained in the packet, identify an outgoing port of NPS706 based on the receiving port, the virtual channel, and the 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 the 4 ports. Thus, in this example, a 232-bit register is implemented for each IDy. In other examples, the routing table registers may be implemented differently.

[0134] In some examples, by packing registers based on destination identification, routing tables can be more easily reconfigured when a route is 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, multiple destination identities may be added 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 that should persist during a partial reconfiguration corresponds to an entry in a segment of the routing table, the presence of the route that should persist 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 via NPI 710 to write to register blocks 712 of NMU 702, NSU 704, and NPS 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 domain 104 and / or the DPE array 102 can instantiate one or more applications, or any subset thereof, on the PL domain 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, obtain a PDI from memory, which can include configuration data for the NoC 108, a configuration bitstream for the PL domain 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] At 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 domain 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 a Reconfiguration Partition (RP). 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 be partially reconfigured during the partial reconfiguration. With reference thereto, various applications can be disabled and / or overridden, and different applications or any subset thereof can be instantiated on those subsystems by 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 obtain 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. Additionally, with respect to the NoC, communication (e.g., occurring at 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 resources of the NoC may be changed while another subset of the resources of the NoC may remain active and undisturbed. Further details of partial reconfiguration of the NoC 108 are described with respect to FIG. 19 below.

[0141] At 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 can enable and initiate operation of the components. The various subsystems on the SoC 100 communicate with each other, for example, application data 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 to the register block 712 of the NMU 702 in the RP via the NPI 710 to control the NMU 702. The transaction requests the NMU 702 to 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 NSU 704 in the RP to be reconfigured. The PMC 1602 obtains the address or identification information of the NSU 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 the NSU 704 to write a value to the register block 712 of the NSU 704 that causes the NSU 704 to reject any packets subsequently received 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 NSU 704 still has 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 has no packets pending, the PMC 1602 disables or stops operation of the NSU 704 via a transaction request over the NPI 710.

[0144] When the NMU 702 and NSU 704 are controlled as described in relation to blocks 1902 and 1904, traffic on paths in the NoC 108 in the RP is quiesced. Once the traffic is quiesced, the RP can be reconfigured. In block 1906, the PMC 1602 reconfigures the NPS 706, the NMU 702, and the NSU 704 in the RP. The PMC 1602 reconfigures the NPS 706, the NMU 702, and the NSU 704 according to the configuration data included in the PDI. The PMC 1602 reconfigures the NPS 706, the NMU 702, and the NSU 704 via memory-mapped transactions via the NPI 710 as previously described. Traffic can continue on paths that do not enter or exit the NoC 108 in the RP during the reconfiguration, or that are independent. Because 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, the NSU 704 that was disabled or stopped before the reconfiguration is enabled and enters normal operation. In block 1910, the PMC 1602 enables the NMU 702 that has been reconfigured to the used state. After the reconfiguration, the NMU 702 that was disabled or stopped before the reconfiguration is enabled and enters 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] FIG. 20 illustrates another exemplary implementation of SoC 100. FIG. 20 illustrates a logical view of various components and / or subsystems of SoC 100. In the example of FIG. 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 domain 104. As shown, various different subsystems, such as DPE array 102, PL domain 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 domain 104, PS 106, PMC 1602, and hardwired circuit blocks 2034 and 2036. For example, configuration interconnect 1612 can enable frame-based programming of PL domain 104 by PMC processing unit 2004 of PMC 1602.

[0148] The PMC 1602 acts as a root of trust for the SoC 100. In the example of FIG. 20, the PMC processing unit 2004 may include one or more processors capable of executing program code. The PMC 1602 further includes a control circuit 2006, a memory 2008, and one or more interfaces 2010. The PMC processing unit 2004 may execute control software from the memory 2008, which may include RAM and / or ROM. The 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 domain 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 the control circuitry 2006. The control circuitry 2006 can include security, safety, system monitor, e-fuse, and power management circuits 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., for reading configuration data from an external source, such as a PDI for the SoC 100), 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] The hardwired circuit block 2012 includes one or more configurable memory (e.g., DDR) controllers 2014 connected to the NoC 108 and configurable I / O 2016. The hardwired circuit block 2018 includes one or more configurable high-bandwidth memory (HBM) controllers 2020 connected to the NoC 108 and configurable I / O 2022. The 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. The 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.

[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 the master circuit block in the PL 104 may 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 interconnected by fabric interconnects 2038, as previously described. As shown, the PL domain 104 is connected to the NoC 108, fabric interconnects 2038, and configuration interconnects 1612. The DPE array 102 may include multiple interconnected hardwired and programmable DPEs 204. The DPEs 204 connect to the NoC 108, fabric interconnects 2038, and configuration interconnects 1612 via SoC interface blocks 206.

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

[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 hardwired circuit blocks, from hardwired circuit blocks to DPE array 102, from PL area 104 to hardwired circuit blocks, and / or from hardwired circuit blocks to PL area 104. This remapping may be performed without interrupting user applications in other parts 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] The term "computation engine" as defined herein refers to a processor capable of executing program code. Computation engines are also referred to as "Group A" type circuit blocks. Various types of computation 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 computational units that may be implemented in SoC 100 include soft processors implemented in 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, Calif. 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 a circuit block within the PL domain 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 to 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 to PS 106 (e.g., shown as PS memory 2048) and / or LUTs (e.g., LUTRAM), URAM, and / or BRAM available to 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 SoC 100, 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 SoC 100 include, but are not limited to, CCIX 2026, PCIe 2028, MAC 2030, Ethernet (in PS 106), 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 allows for a flexible platform so that different functions can be remapped from one subsystem to another. Pervasive interconnects are also referred to as "Group E" type circuits or circuit blocks. Examples of common infrastructure included in a pervasive interconnect include NoC 108, coherent interconnect 2050 in PS 106, and custom signal paths implemented in PL region 104. The pervasive interconnect in 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 domain 104, and / or DPEs 204 of the DPE array 102 via the NoC 108 and / or the fabric interconnect 2038. For example, the computational units of the PS 106 and computational units implemented in the PL domain 104 may access the coherent interconnect 2050. Similarly, hardware accelerator engines, whether hardwired or implemented in the PL domain 104, may access the coherent interconnect 2050. Memory resources, whether external, in the PL domain 104, or within the PS 106, are 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 domain 104 provides customization for user-defined, custom, hardware accelerator engines, peripherals, and / or other computational blocks that may be implemented in the PL domain 104. A scaled 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 set of heterogeneous 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 configuration illustrated for SoC 100 can be used to enable higher level composite 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 a 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 in the PL, one or more DPEs, PS processors, or hardwired circuit blocks).

[0168] As an illustrative example, a component in SoC 100 interprets an inbound descriptor to perform a pipeline stage function. Based on the result 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, the PL elements that interpret the descriptors and communicate with other components on SoC 100 can be replaced with hardware acceleration engines that interpret the same descriptors and communicate with the same adjacent components when implemented in a different SoC 100 using the same platform architecture or by a different application in the same SoC 100.

[0169] FIG. 21 illustrates an exemplary implementation of a PMC 1602. The PMC 1602 is a hardwired circuit block on the SoC 100. In the example of FIG. 21, the PMC 1602 includes a PMC processing unit 2004 (separate and distinct from the PS 106). The 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 an exemplary implementation, the PMC 1602 is on a separate power domain (e.g., has a separate, independent power supply) independent of the PL 104, the DPE array 102, and / or the 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 of the processors being able to operate in lockstep. The processor 2112 is dedicated to accessing the RAM 2208 (e.g., executing code stored in the ROM 2208), while one or more other processors 2112, which may also operate in lockstep, are dedicated to accessing the ROM 2206 (e.g., executing code stored in the 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 the 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 the additional processors 2112 of the 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, the ROM 2106 and the RAM 2108 are accessible only by the processor 2112. In another embodiment, each processor 2112 has a ROM 2106 and a RAM 2108, and each processor 2112 has an independent dedicated ROM 2106 and an independent dedicated RAM 2108. The RAM 2108 may be protected by an error correction coding (ECC) circuit. The processor 2112 may be used to power up and configure the SoC 100 by executing code stored in the ROM 2106 and by executing firmware loaded into the RAM 2108 from a primary boot device by executing code stored in the ROM 2106. The local registers 2114 are configuration registers for the PMC processing unit 2004 and may be accessed only by the PMC processing unit 2004.

[0173] After booting, the processor 2112 can perform a variety of different functions using various components included in the PMC 1602. For example, the processor 2112 can perform power management, voltage and temperature monitoring, safety and security event response, etc. for the SoC 100. As shown, the 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 in the SoC 100 through the interconnect 2116. The interconnect 2116 can include a number of memory mapped switches and interfaces and a number of stream switches and interfaces. The interconnect 2116 is connected to a PMC shared RAM 2118, a global register 2120, an 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, a power management and reset 2138, an error management 2140, a debug packet controller 2142, and a configuration frame unit (CFU) 2144.

[0175] The PMC shared RAM 2118 can be used to store configuration data for the SoC 100 during processing and as a general purpose data processing RAM for the PMC 1602. The global registers 2120 are configuration registers accessible by any (e.g., all) masters in the PMC 1602. The global registers 2120 can include general purpose power control registers, error management registers, and a service interrupt request interface. The I / O 2122 can include one or more I / Os coupled to a multiplexed input / output (MIO) 2168. / O. 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] The DMAs 2124 and 2126 are used to transfer data within the PMC 1602 for configuration of the SoC 100 and processing of configuration data. A secure stream switch 2128 ensures that the data stream provided to the security accelerator 2132 for processing is secure. A slave boot interface (SBI) 2130 facilitates slave boot and / or configuration in a multi-die SoC configuration. Although not shown, the SBI 2130 may be connected to the SelectMap 2170 and the 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 block 2152, and a Battery Backed RAM (BBRAM) 2154 circuit block. The AES-GCM circuit block 2146 is a symmetric key cryptographic engine that can perform encryption and / or decryption. The ECDSA / RSA circuit block 2148 is a public key cryptographic engine that can perform authentication. The SHA-3 / 394 circuit block 2150 may perform secure hash operations. The TRNG circuit 2152 may 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 circuitry on the SoC 100; a bandgap circuit 2162 capable of generating one or more reference voltages for analog devices in the SoC 100, such as DACs and / or ADCs, which may be implemented on the SoC 100 as hardwired and programmable circuit blocks; one or more phase-locked loops (PLLs) 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. The e-fuse circuits (e.g., e-fuse memory elements) 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 highly accurate 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 necessary logic and interfaces to control the 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 the 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, routes 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, a 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 via 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 illustrates an exemplary arrangement of processors 2112 of the PMC processing unit 2004. In the example of Figure 22, the processors 2112 are arranged in a triple redundant architecture. In the exemplary implementation, the 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. The TMR managers 2202-1, 2202-2, and 2202-3 are interconnected. The 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 may manage the state of each of the processors 2112, including fault detection and error recovery.

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

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

[0188] 22 illustrates an example of triple modular redundancy in which processors 2112 are dedicated to accessing RAM 2118. As previously discussed, a similar architecture may be used for a ROM-only processor 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] The PMC 1602 is the root of trust within the SoC 100. The PMC 1602 can build a chain of trust by ensuring that any external code loaded by the PMC 1602 to configure any part of the SoC 100 is authenticated and decrypted (if necessary). For example, the PMC 1602 can authenticate using the ECDSA / RSA circuit block 2148 and decrypt using the AES-GCM circuit block 2146. In general, the configuration data is authenticated and decrypted, and the PMC 1602 can load the configuration data into the appropriate configuration registers of the appropriate subsystems and / or circuit blocks of the SoC 100.

[0190] FIG. 23 illustrates further structural and functional aspects of SoC 100. FIG. 23 illustrates an example configuration in which different types of compute engines and hardware acceleration engines are implemented across different ones of the 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, the 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 the PS memory 2048). The coherent interconnect 2050 is further connected to a memory 2304. The memory 2304 may be a memory located in the PL domain 104, an external memory, or a memory within the PS 106 accessible by other circuit blocks in other subsystems. As shown, the memory 2304 is also connected to the NoC 108. Various other types of circuit blocks are connected to the NoC 108, such as one or more external I / Os 2308 and one or more hardware acceleration engines 2310.

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

[0193] The hardware acceleration engine 2310 includes a user-defined accelerator 2320 implemented in the PL domain 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 particular 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 common interfaces 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, each may have the same or common interfaces even though the various components belong to different groups as described above and / or are implemented across different subsystems of SoC 100. The common interfaces support remapping of functions from one subsystem to another within SoC 100, since the signaling of the functional blocks remains constant even when moved from PL domain 104 to hardwired circuit blocks or DPEs, etc.

[0195] Datapath interface 2322 is an interface circuit that can connect to a global interconnect, which in this example is NoC 108. Datapath 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 in 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 datapath interface 2322. MMU interface 2324 can also enforce read / write permissions and authorizations to prevent circuit blocks including MMU interface 2324 from performing unauthorized reads and / or writes to memory addresses.

[0196] The interrupt interface 2326 implements standard interrupts or user-defined and / or specific interrupts of the circuit blocks. In some cases, interrupts of 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, the destination of the interrupt may be shared between the circuit blocks. Further discussion regarding partitions within SoC 100 is described in more detail with reference to the remaining figures.

[0197] The DMA 2328 can perform data transfers 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 control 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, for example, enable the PMC 1602 to read and write configuration registers located within the circuit block (not shown).

[0199] In another aspect, different circuit blocks may include less 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 a particular hardwired circuit block 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, through two partitions that may be isolated from each other, one or more interrupts may be allowed to pass from a partition to the other partition and / or to the PMC 1602 to communicate a message or trigger / initiate a certain action. A doorbell interrupt can travel from one domain or partition to another domain or partition through 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 may use a common interface and include an interrupt interface 2326. A host system communicating with the SoC 100 may 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 may, for example, generate an interrupt to the PCIe controller to cause the PCIe controller to program one or more DMAs to execute the memory access.

[0202] 23 illustrates the modularity of functions and services across the components of groups A, B, and C of SoC 100. Components can maintain this modularity even when the components perform different functions from one another. For example, components implemented in PL area 104 are modularized such that the PL components have standard interfaces to components in groups D, E, and F. Each PL component can be deployed in service of 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 to different components in groups A, B, and C.

[0203] In another example of modularity achieved using SoC 100, a particular function deployed as a PL component may be deployed to other parts of PL 104 to implement multiple concurrent instances of the same function. 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 the SoC 100. In the example of FIG. 24, the SoC 100 includes various additional circuits that can implement security functions. These additional circuits can be used to create different independent partitions within the SoC 100 and firewalls between different partitions. Each partition can run its own application therein. In the example of FIG. 24, multiple system management identifier (SMID) circuits 2402 and a programmable protection circuit (PPC) 2418 are included.

[0205] The processor 2112, the RPU 2042, the APU 2044, the other masters 2408, and the I / O devices 2412 are connected to a local interconnect 2416 via the 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 the 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 particular SMID. During configuration, the PMC 1602 can assign and write a SMID to the configuration registers of the various SMID circuits 2402, or at least each of those SMID circuits 2402 being used. The SMID circuits 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 a SMID into transactions initiated by the respective component. Thus, each transaction originating from the processor 2112 includes a SMID in the transaction, e.g., inserted by the SMID 2402-2 assigned by the PMC 1602. Similarly, each transaction originating from the RPU 2042 has a 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 SMIDs assigned to SMID circuitry 2402 may be unique across SoC 100.

[0207] PPC2418 can protect access to slave circuits in SoC100. Each of PPC2418 can check the specific SMID of each transaction entering a circuit block. Each PPC2418 can check whether the SMID of the transaction is an authorized SMID, for example, on a list of authorized SMIDs maintained by each PPC2418. Each PPC2418 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, PPC2418 can enforce access privileges by ensuring that only authorized circuit blocks (based on 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, the PPC 2418 includes a first type configured to protect the configuration registers of a circuit block. Such a PPC 2418 can allow only authorized SMIDs to access the configuration registers, and can protect the specific configuration registers with addresses specified on a list of authorized addresses for each authorized SMID. Only one type of PPC 2418 may be allowed. 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. The PPCs 2418 may also include a second type configured to protect memory. The second type of PPC 2418 provides 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 may write to configuration registers in 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 further writes to the configuration registers of the PPC 2418 a list of permitted SMIDs and / or permitted addresses and / or address ranges that each SMID is permitted to access. These operations may create two or more partitions that are at least partially isolated from one another.

[0210] In this regard, PPC2418-1 can allow only authorized transactions from authorized sources to access PMC slave 2420. PPC2418-2 can allow only authorized transactions from authorized sources to access NPI 710. PPC2418-3 can allow only authorized transactions from authorized sources to access RTP slave 2422. PPC2418-4 can allow only authorized transactions from authorized sources to access OCM2424. PPC2418-5 can allow only authorized transactions from authorized sources to access APU slave 2426. PPC2418-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 through a repeater. This may be true for both entry and exit points of the NoC 108.

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

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

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

[0215] As an illustrative example, consider a circuit block implemented in PL domain 104 initiates transactions A, B, and C. Each of transactions A, B, and C carries a 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 acts as both an ingress path and an egress path. 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 has 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 allows 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 in the SoC 100, such as a set of registers for configuring the PL area 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 particular PMC slave 2420. Thus, the I / O device 2412 is only allowed 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 allowed to read or write to other PMC slaves 2420. I can't.

[0218] Continuing with the example, the processor 2112 is authorized to load the boot image via an authentication scheme (described in more detail herein). For example, the PPC 2418-1 may be configured to authorize the processor 2112 to read the PMC slave 2420 based on the SMID corresponding to the SMID circuit 2402-1, where the boot image is stored by the I / O device 2412 (which only had write access). The processor 2112 can only read the boot image and decrypt the boot image into the second PMC slave 2420, e.g., working memory for the processor 2112. The processor 2112 may then use the decrypted boot image stored in the second PMC slave 2420 to program other configuration registers, e.g., by writing to the third PMC slave 2420. The third PMC slave 2420 may be the configuration registers for the PL region 104 or the 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. The 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, e.g., 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 a SMID check circuit 2502, an address range check circuit 2504, and a configuration register 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 permitted 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 permitted 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 circuitry 2502 and the address range check circuitry 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 circuitry 2502 and / or the address range check circuitry 2504.

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

[0224] In block 2602, hardwired logic in the SoC 100 executes a power-on reset sequence. In one embodiment, 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 generally performs initial steps before handing control to the processor of the PMC 1602 to execute the BootROM code. The power-on reset sequence may include an analog component that detects if the voltage supply is powered up and qualifies the power-on reset deassertion. Additionally, a boot mode pin may be obtained that specifies the boot mode of the SoC 100. The e-fuse bits may be read and cached by the e-fuse controller 2160. A state clear operation is performed on the PMC 1602. The POR circuit 2166 may authenticate the BootROM. The BootROM may be authenticated, for example, using the SHA-3 / 384 circuit block 2150 of the PMC 1602. The end of the power-on reset releases the rest of the PMC 1602 from reset.

[0225] At 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 halted.

[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) the power islands that have been disabled by the 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 the boot of the SoC 100 continues.

[0228] In block 2614, the PMC 1602 performs a boot header / authentication certificate process. In general, 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 the 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 if necessary, and interpreted based on the boot header. The boot header can include an initialization vector that is 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 executes the Boot ROM. The PDI programming partition may be loaded, authenticated, and decrypted. In 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 in 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 of 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 the NoC 108. As illustrative and non-limiting examples, 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, the operations may be performed synchronously. For example, although not explicitly described, the images 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 the PMC 1602 is responsible for configuring the PS 106, the PL 104, the DPE array 102, and selected other circuit blocks. In response to a boot header, for example, PMC 1602 may configure PS 106 with program code that enables PS 106 to configure PL 104 and DPE array 102. In that case, in response to the setting of the PS in block 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 in SoC 100. The process described in connection with FIG. 26 is hierarchical in that authorization may be denied or granted for increasingly narrower subsets of subsystems and / or components in SoC 100. The hierarchical aspect of the technique illustrated in FIG. 26 may support SoC 100 configuration for use in a Field Programmable Gate Array (FPGA)-as-a-Service or “FaaS” processing environment. For example, PMC 1602 may create multiple partitions in SoC 100. In creating a partition, PMC 1602 may 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 may create partitions in SoC 100 with many physical destinations mapped to one logical destination.

[0239] At runtime of the SoC 100, the SMID circuit block 2402 and the 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 the SoC 100. Because the SoC 100 can be configured, reconfigured, and / or partially reconfigured across different subsystems, the permissions and authentication mappings that create the partitions and implement firewall functions between the partitions can be dynamically changed.

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

[0241] The next image 2710 of the PDI 2700 may include multiple different blocks, indicated as block 0, block 1 through block N. The various blocks included in the next image 2710 may be specified in a secure header 2712. Generally, the various blocks 0 through N correspond to the PS boot code, the configuration bitstream for the PL, the DPE array programming segment, and the register programming data referenced in blocks 2628, 2630, 2632, and 2634 of FIG. 26. In a particular embodiment, these blocks may be organized according to application (e.g., partition), with multiple blocks representing one application for implementation in a first partition and a different set of blocks representing another application that may be implemented in a second partition concurrently with the first application or in the first partition after the first application has finished executing.

[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 included in PDI 2700 (or different PDIs) over time and depending on certain conditions. Partial reconfiguration of SoC 100 facilitates hierarchical organization of subsets or wholes of physical components within SoC 100 or logical subsets thereof. For example, PMC 1602 may be used to separate partitions, (changed applications, It can control the unloading (and loading) of software drivers (as appropriate for the application), delivery of programming images from any secondary boot interfaces, 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, a variety of 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, a system 2800 is shown that includes a host data processing system 2802. The host data processing system 2802 may be implemented as a computer system such as a server. The 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 the system 2800. As such, the CPUs of the host data processing system 2802 are assigned to the user X and the user Y. Thus, the host data processing system 2802 includes a user X CPU 2804 and a user Y CPU 2808. The host data processing system 2802 further includes a host interconnect 2806 that can establish communication with the SoC 100. For example, the host interconnect 2806 may be a PCIe node that can communicate with the SoC 100 via a PCIe link.

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

[0246] SoC100 may be coupled to a circuit board or card that is connected 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. The 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 may 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 the 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 only accessible 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, the shell, unlike the other partitions, 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 the SoC 100 that does not change, and the partitions may be implemented as dynamically reconfigurable regions within the 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 the SoC 100. In this manner, partitions implemented as dynamically reconfigurable regions may be reconfigured to implement different applications over time while the shell operates uninterrupted and the SoC 100 may maintain communication links to the host data processing system, RAM, and / or other external devices. The shell includes interfaces to the partitions such that, once implemented in the partitions, the applications may communicate with the shell and / or access devices and / or circuits (e.g., external circuits and / or devices such as the 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 that are 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 users X and Y, can occupy SoC 100 simultaneously and are firewalled from each other. Partitions X and Y are dynamically reconfigurable regions.

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

[0251] For example, the resources of SoC 100 allocated to partition X are shaded. Partition X corresponding to user X includes PCIe A / 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 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 assigned, includes PCIe A / 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 a different area 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 partitions X and 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 internal memory. Signal paths are established by loading the PDI of the application being executed in each respective partition (e.g., DPE configuration data, NoC configuration data, PL configuration data, and / or PS configuration data that form the application). PCIB 2842 and 2844 may be used to access external storage devices.

[0253] In this example, PMC 1602 (e.g., either in a shell or running under the control of a shell) configures the SMID circuit block and PPC with 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. Isolation and firewalls are achieved, each with independent data paths, interrupts, control signals, etc., meaning that a malfunction or error in an application in one partition does 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 with multiple PCIe Root Ports can operate with SoC 100, which is configured to assign one PCIe A controller to each of partition X and partition Y. Performance isolation between partitions can be achieved such that host data processing system bursts to SoC traffic of one partition do not impede the bandwidth available to the other partition. Additionally, a PCIe link error or PCIe link down condition of one partition can be isolated to that partition. The PMC can isolate power management functions of 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 a PF associated with one partition may 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-tenant example of FIG. 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 FIG. 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, with 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 degradation in DDR bandwidth due to, for example, either line blocking or page collisions on the part of user X does not impact user Y's bandwidth 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, the address space of 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 still 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 buffering resources of the NoC 108 can be allocated on a per-user basis. The NoC 108 can be programmed, for example, such that NoC physical paths and their dedicated virtual channels are allocated on a per-user (e.g., partition) basis. As described, SMIDs can be used by the PPC to enforce firewalls between users when transactions emerge from the NoC 108, whether they are inserted into the transaction at the source or around it and / or by SMID circuitry implemented at the NoC 108 entry point. 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 between users. For example, user X is assigned a particular one of the GT 2032, MAC 2030, and PCIB 2842, and user Y is assigned a different GT 2032, a different MAC 2030, and a different PCIB 2844. Thus, both user X and user Y have dedicated PCIe and Ethernet interface controllers and associated I / O.

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

[0262] 26, 27, and 28 in combination, the boot process of the SoC 100, which is hierarchical in nature, facilitates the FaaS use case described in connection with FIG. 28. For example, the boot code for the SoC 100 may initially be provided (e.g., by the manufacturer of the SoC 100) as block 0 of the PDI 2700. A shell created by the FaaS provider may then be loaded as block 1 of the 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. Blocks 2 and 3 are then loaded, which correspond to applications to be implemented in partitions X and Y, respectively.

[0263] When implemented, each application is aware of only those SoC 100 resources that are assigned to the partition in which the application is implemented. As part of the firewall, PMC 1602 is configured to allow each user to only access the configuration space that corresponds 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 allows programming such 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 determine, for example, 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 to be substantially the same 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 assigned more resources and / or bandwidth than partition Y. The partitions 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 the other users on SoC 100. In this regard, increased usage of SoC 100 by user X is confined to partition X and does not degrade usage of SoC 100 by user Y. The partitions maintain their 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 implemented in the partitions assigned to the completed user. For example, consider the case where user X intends to perform extended processing that may take place over a long period of time while user Y is performing video processing related to delivering video to a particular end user. When the end user stops consuming video content, user Y may be removed from the partition on SoC 100. Another different user, say user Z, may be implemented 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 in the partition previously used by user Y. That is, a new user implemented in a partition can use any combination of PL, NoC, PS, and / or DPE arrays 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 the SoC 100 implementing different partitions. FIG. 29 illustrates an exemplary use case in which the SoC 100 is utilized in an automobile or other vehicle. As illustrated, the SoC 100 is divided into two different partitions 2902 and 2904. The partition 2902 implements an application that performs real-time processing. As illustrated, the partition 2902 includes a real-time processing domain 2906 including an RPU 2910, one or more external communication circuit blocks (e.g., I / O and / or interfaces) 2908, and a local RAM 2912. In one aspect, the RPU 2910, the external communication 2908, and the local RAM 2912 may be implemented within the PS 106. The real-time processing domain 2906 is connected to the DDR controller 2914 via the NoC 108. The PPC 2920 provides memory protection and a firewall. As shown, the NoC 108 and the PPC 2920 are global resources that may be used by both partition 2902 and partition 2904 .

[0269] Partition 2904 is independent of partition 2902. Thus, processing, errors, and / or performance issues in partition 2904 do not impact partition 2902. An application implemented in partition 2904 performs a number of 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 in 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. Machine learning functions 2926 in PL104 (e.g., standard cores implemented in PL104 and / or user-defined circuit blocks in PL104) connect to NoC108 and connect to multiple interleaved DDR controllers 2922 via PPC2920. Programmable functions 3 provide an interface to external devices and can utilize external interfaces 2928 implemented in PL104. External interfaces 2928 in PL104 (e.g., standard cores implemented in PL104 and / or user-defined circuit blocks in PL104) connect to NoC108 and connect to multiple interleaved DDR controllers 2922 via PPC2920.

[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, e.g., 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 SMIDs assigned to the respective masters and PPC 2920 in each partition.

[0271] As described above, the sections 2902 and 2904 are isolated from each other. Picture 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 the SoC 100 may be implemented based on the SoC 100 boot-time allocation of resources by the PMC 1602. The PMC 1602 creates addressability for each of the two partitions, for example using a programmable address map. The NoC 108 provides QoS controlled data paths through each of the partitions 2902 and 2904. The data paths through the NoC 108 are programmed with isolation between the data paths to ensure freedom from interference. The PMC 1602 programs the memory protection circuitry 2920 to provide access (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 run-time. For example, an application running on partition 2904 can be replaced with a different version of the application during run-time to perform different computer vision and / or machine learning operations. As an illustrative and non-limiting example, an application running on partition 2904 may be changed from one that uses a forward-facing camera to provide driving assistance (e.g., to drive faster) 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 in different ways. In another example, the entire device may be reconfigured to implement different sections 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 with a safety zone with high reliability for performing safety-critical functions, while another partition may have less safety features required in 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 no shell needs 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 of FIG. 30-32 illustrate various features of SoC 100 previously described herein, 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 discussed above, in some cases, PS 106 can configure PL 104, NoC 108, DPE array 102, and hardwired circuit blocks 110.

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

[0278] FIG. 30 illustrates an example method 3000 of implementing a PDI in a SoC 100. A PDI implemented in a 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 illustrated in FIG. 29 can operate as a primary partition.

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

[0280] For example, in block 3004, the PMC 1602 may perform an 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 of the DPE array 102 (not shown). 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 on power-up, the NoC 108 is not configured with a data path. No circuit block can utilize the NoC 108 to communicate with any other circuit block after power-up. 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, DMA, switches, etc.).

[0283] In one aspect, the PMC 1602 may operate in a power domain of the SoC 100 that is independent from other subsystems and / or components contained within the SoC 100. The SMID circuitry and / or PPC circuitry may be included in the PMC power domain. This allows the PMC 1602 to power up or power down other subsystems independently while still maintaining the active and trusted center of the SoC 100. Additionally, security settings created by the PMC 1602 may be configured by the SMID circuitry and / or PPC to be independent of such circuitry. Thus, the particular subsystem being protected may 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 partition implementing an application. In one example, the PDI, when loaded into the SoC 100 and executed by the PMC 1602, 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, the PDI, when loaded into the SoC 100 and executed by the PMC 1602, implements the partitions as described in connection with FIG. 29.

[0285] In performing block 3006, the PMC 1602 may authenticate the PDI as described in connection with block 2620 of Figure 26. Additionally, the PMC 1602 may execute the PDI as described in connection with block 2626 of Figure 26. The PMC 1602 may configure portions of the PL 104, portions of the PS 106, portions of the NoC 108, portions of the 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 partitions created within the SoC 100. For example, based on the partitions implemented in the SoC 100, the EDA tool may assign a certain number of DPEs 204 to each of "N" different partitions, a certain amount (e.g., number of tiles) of PLs 104 to each of the N partitions, a certain memory controller to each of the N partitions or only to certain of the N partitions, a certain processor in the PS 106 to the 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 and run within the available partitions of the SoC 100.

[0287] As part of block 3006, PMC 1602 may 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 configuration of the circuitry to implement a firewall and prevent circuitry in a partition from accessing circuit resources of other partitions across partition boundaries. For example, PMC 1602 may configure the memory controller to allocate a pool of external memory used only by a particular partition in SoC 100 and another pool of external memory (e.g., non-overlapping memory) used only by a different partition in SoC 100.

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

[0289] FIG. 31 illustrates another exemplary method 3100 of implementing PDIs within a SoC 100 and reconfiguring the SoC 100 over time. In the example of FIG. 31, the SoC 100 may be configured by loading a first PDI. The first PDI may specify a particular partition of the SoC 100. Thereafter, in response to a trigger event, the SoC 100 may be reconfigured with a different PDI that specifies a different partition of the SoC 100. The PMC 1602 may load a PDI that specifies a different partition of the SoC 100, for example, in response to 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 partitions and implements applications in each partition. Blocks 3102, 3104, and 3106 may be performed substantially as described in connection with blocks 3002, 3004, and 3006, respectively, of FIG.

[0291] At block 3108, the 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 the SoC 100. Such circuits 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 circuits 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.

[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 entirety of SoC 100. The partition specified by the different PDI may be the same as the partition that existed prior to block 3108, although the partition may 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 in 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 reassigned to different partitions. Furthermore, resources within each partition may be reconfigured to implement different applications.

[0294] If a trigger event is not detected at block 3108, the 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 deployed in the respective partitions continue to run.

[0295] The method 3100 can continue to iterate. The example of FIG. 31 illustrates a case where multiple different PDIs are available and the 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 particular PDI. This allows the SoC 100 to be reconfigured as needed in response to different conditions. As described above, the reconfiguration extends to all subsystems of the SoC 100.

[0296] 32 illustrates another example method 3200 of implementing a PDI within a 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. In response to a trigger event, SoC 100 may then undergo a partial reconfiguration in which functionality (e.g., applications) in one or more partitions are dynamically reconfigured. Whereas 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 included in the partitions undergoing the partial reconfiguration.

[0297] Thus, 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 and executes the PDI to create multiple partitions and implements applications in each partition. The multiple partitions include a primary partition (e.g., a shell or real-time processing domain) and one or more secondary partitions. Blocks 3202, 3204, and 3206 may be performed substantially as described in connection with blocks 3002, 3004, and 3006, respectively, of FIG. 30.

[0298] At block 3208, the PMC 1602 determines whether a trigger event has been detected to perform a dynamic partial reconfiguration. The trigger event may be detected by any of a variety of different circuits implemented within the SoC 100. Such circuits 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 circuits 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 to 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 a reconfiguration of the entire SoC 100, FIG. 32 illustrates a partial reconfiguration of a single partition. That is, the different PDI includes only configuration data to configure (or reconfigure) the particular portions of PL 104, PS 106, NoC 108, 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 includes 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 further 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 SoC 100 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 SoC 100.

[0302] For illustrative purposes, consider an example where the PMC 1602 first implements the architecture of FIG. 28 including a shell (not shown) in block 3206. In the FaaS example of FIG. 28, the 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 the 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, the PMC 1602 may be separate from the shell, but only accessible 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 entirety of SoC 100, the different PDIs loaded and executed cause PMC 1602 to reconfigure only the DPEs 204 of DPE array 102 of partition Y currently used by user Z, the tiles of PL 104 of partition Y currently used by user Z, and the portions of NoC 108 of partition Y currently used by user Z to establish data paths between the circuits of user Z. PMC 1602 may also load configuration data (e.g., executable code and / or register settings) for the portions of PS 106 of partition Y used by user Z and / or any hardwired circuit blocks of partition Y used by user Z.

[0304] It should be appreciated 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 DPEs 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 the low power domain (e.g., an RPU, a memory controller assigned to it, and a pool of external RAM with connections established through NoC 108 corresponding to partition 2902). PMC 1602 further implements the 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, the PMC 1602 loads different PDIs into the SoC 100 and executes the different PDIs. The PMC 1602 may implement different applications in the partition 2904 to implement different functions, for example, in response to a particular trigger event detected. With reference to the previous example, the partition 2904 can be dynamically reconfigured to implement a driving application to a parking application and vice versa. In the example of FIG. 32, the SoC 100 undergoes a dynamic partial reconfiguration to implement a different application in the partition 2904, while the resources allocated to the 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 of other partitions, however in other cases partitions may have some shared memory.

[0308] In the automotive example, the SoC 100 implements applications corresponding to one user. That is, a particular entity can develop multiple applications that run simultaneously in different partitions of the 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 using low power domains and RPUs may have these safety requirements that require isolation from other applications. Furthermore, in the automotive example, the PMC 1602 operates at a level above the partitions implemented in the 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 since each partition is isolated from the others. As mentioned above, in some cases, a doorbell interrupt can be used to cross from one partition to another to provide signaling and / or messaging between the partitions.

[0310] 30-32 are described 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 "when" means "when" or "when" or "depending on" or "in response to," depending on the context. Thus, the phrase "when it is 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. 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" and similar terms such as "when," "when," or "upon," means to readily respond or react to an action or event. The response or reaction occurs automatically. Thus, when a second action occurs "in response" to a first action, there is a causal relationship between the occurrence of the first action and the occurrence of the second action. The term "in response" indicates a causal relationship.

[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 property, parameter, or value need not be achieved exactly, but that deviations or variations including, for example, tolerances, measurement errors, measurement accuracy limits, and other factors known to those of ordinary skill in the art, may occur in an amount that does not eliminate the effect that the property is intended to provide.

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

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

[0323] The corresponding structure, material, acts, and equivalents of all means-plus-function or step-plus-function elements found in the following claims are expressly incorporated by reference. It is intended to include any structure, material, or act for performing 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 circuit, the network on chip, and the processor system are each configured to implement a portion of a user application having master nodes and slave nodes, the user application specifying the data paths and implementation of each node within the programmable logic circuit 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 an implementation for 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 permitted addresses of the transaction source identifier.

[0333] In another aspect, the processor system and the circuit blocks implemented in the programmable circuitry 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, the network-on-chip, and the 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, where 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 the 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 the network on chip, in which case the method can include providing a common interface for the application specific hardwired circuit blocks and the circuit blocks implemented in the 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 different applications 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 a programmable protection circuit to compare an address specified in a received transaction with an authorized 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 terms used herein are selected to explain the principles of the inventive configurations, practical applications or technical improvements to the art found in the market, and / or to enable those skilled in the art to understand the inventive configurations disclosed herein. Modifications and variations may be apparent to those skilled in the art without departing from the scope and spirit of the inventive configurations described. Accordingly, reference should be made to the following claims, rather than the foregoing disclosure, as indicating the scope of such features and embodiments.

Claims

1. A device, comprising: A programmable logic circuit; a processor system coupled to the programmable logic circuit; a network-on-chip coupled to the programmable logic circuit and the processor system; the network-on-chip and the programmable logic circuit are configured to implement a plurality of independent partitions; the network-on-chip is programmable to establish, for each of the plurality of independent partitions, a user-specified data path communicatively linking a circuit block implemented in the programmable logic circuit and the processor system, the device further comprising: A device comprising: a platform management controller that configures the programmable logic circuit, the network-on-chip, and the processor system to implement the multiple independent partitions.

2. The device of claim 1 , wherein each independent partition of the plurality of independent partitions implements a different application, and the applications are isolated from one another.

3. 3. The device of claim 2, further comprising a data processing engine array coupled to the network-on-chip, wherein one or more of the plurality of independent partitions includes one or more data processing engines of the data processing engine array.

4. The device of claim 3 , wherein the data processing engine array is configured to implement a portion of the application in each of the one or more of the multiple independent partitions.

5. the device further comprising an application specific hardwired circuit block coupled to the network on chip; 2. The device of claim 1, wherein the application specific hardwired circuit blocks and the circuit blocks implemented in the programmable logic circuit of each of the plurality of independent partitions have a common interface.

6. 10. The device of claim 1, further comprising: a programmable protection circuit configured to isolate the multiple independent partitions by comparing an identifier of a transaction source in a received transaction to a list of authorized transaction sources.

7. 7. The device of claim 6, wherein the programmable protection circuitry further compares an address specified in the received transaction with an authorized address of the identifier of the transaction source.

8. The device of claim 1 , wherein the processor system and the circuit blocks implemented in the programmable circuit use a common descriptor format for communication.

9. 1. A method comprising: 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 to the processor system; and configuring the network-on-chip and the programmable logic circuit to implement a plurality of independent partitions; the network-on-chip is programmable to establish, for each of the plurality of independent partitions, a user-specified data path communicatively linking a circuit block implemented in the programmable logic circuit and the processor system, the method further comprising: and configuring the programmable logic circuit, the network-on-chip, and the processor system to implement the multiple independent partitions using a platform management controller located within the device.

10. The method of claim 9 , wherein each partition of the plurality of independent partitions implements a different application, and the applications are isolated from one another.

11. 11. The method of claim 10, wherein the device includes a data processing engine array coupled to the 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.

12. 12. The method of claim 11, further comprising configuring the data processing engine array to implement a portion of the application in each of the one or more of the plurality of independent partitions.

13. the device includes application specific hardwired circuit blocks coupled to the network on chip, the method comprising:

10. The method of claim 9, further comprising providing a common interface for the application specific hardwired circuit blocks and the circuit blocks implemented in the programmable logic circuit of each of the plurality of independent partitions.

14. The method of claim 9 , further comprising dynamically reconfiguring at least one of the plurality of independent partitions.

15. providing a programmable protection circuit within the device; and isolating the plurality of independent partitions by configuring the programmable protection circuitry to compare an identifier of a transaction source in a received transaction to a list of authorized transaction sources.

Images