Adaptive integrated programmable device platform

Abstract

An apparatus 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 programmable logic circuitry may be configured to implement a plurality of independent partitions. The network-on-chip may be programmable to establish a user-specified data path for each of the plurality of independent partitions, the user-specified data path communicatively linking a circuit block and a processor system implemented in the programmable logic circuit. The apparatus may also include a platform management controller to configure the programmable logic circuitry, the network-on-chip, and the processor system to implement the plurality of independent partitions.

Description

[0001] This application is a divisional application of the Chinese patent application with application date of March 13, 2020, application number 202080025155.4, and invention name: "Adaptive Integrated Programmable Device Platform". Technical Field

[0002] The present disclosure relates to integrated circuits (ICs), and more particularly to an integrated programmable device platform providing different heterogeneous subsystems. Technical Background

[0003] A programmable integrated circuit (IC) refers to a device that includes programmable logic. An example of a programmable device or programmable IC is a field programmable gate array (FPGA). FPGAs are characterized by 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 lock loops (DLLs).

[0004] Modern programmable ICs have evolved to include a combination of programmable logic and one or more other subsystems. For example, some programmable ICs have evolved into systems on a chip or "SoCs," which include both programmable logic and a hardwired processor. Other kinds of programmable ICs include additional and / or different subsystems. Summary of the invention

[0005] The device may include a programmable logic circuit, a processor system coupled to the programmable logic circuit, and an on-chip network coupled to the programmable logic circuit and the processor system. The on-chip network and the programmable logic circuit may be configured to implement multiple independent partitions. The on-chip network may be programmable to establish a user-specified data path for each of the multiple independent partitions to link circuit blocks implemented in the programmable logic circuit and the processor system in a communicative manner. The device may also include a platform management controller that configures the programmable logic circuit, the on-chip network, and the processor system to implement multiple independent partitions.

[0006] In one aspect, each of the plurality of independent partitions implements a different application, and the applications are isolated from each other.

[0007] In another aspect, the apparatus includes a data processing engine array coupled to a network on chip, wherein one or more partitions of the plurality of independent partitions include one or more data processing engines of the data processing engine array.

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

[0009] In another aspect, the apparatus includes a dedicated hardwired circuit block coupled to the on-chip network. The dedicated hardwired circuit block and the circuit block implemented in programmable logic circuitry in each of the plurality of independent partitions may have a common interface.

[0010] In another aspect, the apparatus includes programmable protection circuitry configured to isolate a plurality of independent partitions by comparing an identifier of a transaction source within a received transaction to a list of authorized transaction sources.

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

[0012] On the other hand, processor systems and circuit blocks implemented in programmable circuits communicate using a common descriptor format.

[0013] A method may include providing a device including a programmable logic circuit, a processor system coupled to the programmable logic circuit, and an on-chip network coupled to the programmable logic circuit and the processor system. The method may include configuring the on-chip network and the programmable logic circuit to implement multiple independent partitions. The on-chip network may be programmable to establish a user-specified data path for each of the multiple independent partitions to communicatively link circuit blocks implemented in the programmable logic circuit and the processor system. The method may include configuring the programmable logic circuit, the on-chip network, and the processor system to implement multiple independent partitions using a platform management controller disposed in the device.

[0014] On the one hand, each of the multiple independent partitions implements a different application, and the applications are isolated from each other.

[0015] In another aspect, the apparatus includes a data processing engine array coupled to a network on chip, wherein one or more partitions of the plurality of independent partitions include one or more data processing engines of the data processing engine array.

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

[0017] In another aspect, the apparatus may include a dedicated hardwired circuit block coupled to the on-chip network. In that case, the method may include providing a common interface for the dedicated hardwired circuit block and the circuit block implemented in the programmable logic circuit in each of the plurality of independent partitions.

[0018] In another aspect, the method may include dynamically reconfiguring at least one partition of the plurality of independent partitions.

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

[0020] This summary of the present invention is provided only to introduce certain concepts, without identifying any key or essential features of the claimed subject matter. Other features of the present arrangement will be apparent from the drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The arrangement of the present invention is shown by way of example in the accompanying drawings. However, the accompanying drawings should not be interpreted as limiting the arrangement of the present invention to the specific embodiments shown. Various aspects and advantages will become apparent by reading the following detailed description and referring to the accompanying drawings.

[0022] Figure 1 An example architecture for a system-on-chip (SoC) type integrated circuit (IC) is shown.

[0023] Figure 2 Shown for Figure 1 An example implementation of a data processing engine (DPE) array for an SoC.

[0024] Figure 3 Shows Figure 2 An example architecture of a DPE of a DPE array.

[0025] Figure 4 Shows Figure 3 Further aspects of the example architecture of .

[0026] Figure 5 Another example architecture of a DPE array is shown.

[0027] Figure 6 An example architecture showing a picture of the SoC interface block of a DPE array.

[0028] Figure 7 Shows Figure 1 An example implementation of a network on a chip (NoC) is provided.

[0029] Figure 8 is depicted by NoC in Figure 1 A block diagram of the connections between endpoint circuits in a SoC.

[0030] Fig. 9 is a block diagram depicting a NoC according to another example.

[0031] Fig.10 An example method of programming a NoC is shown.

[0032] Fig.11 Another example method of programming a NoC is shown.

[0033] Fig.12 Example data paths through the NoC between endpoint circuits are shown.

[0034] Fig.13 An example method of handling NoC-related read / write requests and responses is shown.

[0035] Fig.14 An example implementation of a NoC master unit is shown.

[0036] Fig.15 An example implementation of a NoC slave unit is shown.

[0037] Fig.16 An example connection through the NoC peripheral interconnect to the register block of the NoC is shown.

[0038] Fig.17 An example table used by the NoC is shown.

[0039] Fig.18 An example method for operating a SoC is shown.

[0040] Fig.19 is an example method for partially reconfiguring a NoC.

[0041] Fig. 20 Shows Figure 1 Another example implementation of a SoC.

[0042] Fig.21 An example implementation of a platform management controller (PMC) is shown.

[0043] Fig. 22 Shows Fig.21 An example implementation of a processor of the PMC.

[0044] Fig.23 Shows Figure 1 Further structural and functional aspects of the SoC.

[0045] Fig.24 Shows Figure 1 Further structural and functional aspects of the SoC.

[0046] Fig.25 Shows Fig.24 An example implementation of a programmable protection circuit.

[0047] Fig.26 Shows the startup Figure 1 An example method for an SoC.

[0048] Fig. 27 An example of a programming device image that can be used to boot a SoC is shown.

[0049] Fig.28 An example SoC implementing different partitions is shown.

[0050] Fig.29 Another example SoC implementing different partitions is shown.

[0051] Fig.30 An example method of implementing a programmed device image (PDI) within a SoC is shown.

[0052] Fig.31 Another example method of implementing a PDI within a SoC and reconfiguring the SoC over time is shown.

[0053] Fig.32 Another example method of implementing a PDI within a SoC and performing partial reconfiguration of the SoC over time is shown. DETAILED DESCRIPTION

[0054] Although the present disclosure is concluded with claims defining novel features, it is believed that the various features described in the present disclosure will be better understood by considering the detailed description in conjunction with the accompanying drawings. The processes, machines, manufactures, and any variations thereof described herein are provided for illustrative purposes. The specific structural and functional details described in the present disclosure should not be interpreted as limiting, but merely as a basis for the claims and a representative basis for teaching those skilled in the art to use the features described in virtually any appropriate detailed structure in different ways. In addition, the terms and phrases used in the present disclosure are not intended to be limiting, but rather to provide an understandable description of the described features.

[0055] The present disclosure relates to integrated circuits (ICs), and more particularly to an integrated programmable device platform (platform) that provides different heterogeneous subsystems. The platform takes advantage of the various subsystems described to provide a number of benefits. For example, the platform is able to take advantage of the area and power efficiency of fixed-function components (e.g., application specific integrated circuits or "ASICs"), the flexibility and functionality of programmable logic, extend this flexibility to fixed-function components, and provide services common to both fixed-function components and programmable logic.

[0056] The platform is able to extend the flexibility of fixed function components by providing a common infrastructure within the device that can be shared and used between different subsystems. This common infrastructure can provide functions including, but not limited to, data paths, firewalls, interrupts and doorbell pathways, performance monitors, and configuration. The different subsystems can be implemented so that the circuit blocks within these different subsystems, when implemented as part of a user application, can use a standard interface that is configured to connect to and utilize the common infrastructure.

[0057] The common infrastructure improves 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 of one component can be applied to another component in the platform. For example, unused network-on-chip (NoC) buffers, virtual channels, and physical paths allocated to one set of unused components of the platform can be allocated to another set of components in the platform for use by user applications. In addition, the platform allows any of the various components of the device to utilize the common infrastructure to access subsystems, such as programmable logic.

[0058] On the other hand, specific functions can be quickly remapped from one component of the platform to another component or subsystem in the platform. For example, programmable logic can be used to implement standard cryptographic acceleration functions, such as Advanced Encryption Standard Galois / Counter Mode (AES-GCM). The function can be remapped, for example, or moved to another device, such as a hardwired or hardened cryptographic accelerator block. This remapping frees up resources in the programmable logic and increases the flexibility of the device. The terms "hardwired" and "hardened" are used interchangeably in this disclosure.

[0059] The remapping is at least partially facilitated by a common infrastructure. The common infrastructure may include common interfaces to circuit blocks implemented in programmable logic and hardwired circuit blocks. The common infrastructure allows the properties of the function (e.g., communication paths, data paths, and interrupt paths) to be maintained despite the remapping of functionality from one subsystem to another. Any other components within the platform that interact with the cryptographic acceleration function, regardless of where it is implemented, can be protected from unauthorized access to the component by a firewall. For example, other components cannot access or view unencrypted data or encryption keys used by the cryptographic acceleration function. Firewalls can also be used to prevent unauthorized components from accessing or viewing encrypted data. Despite any remapping of the cryptographic acceleration function, other components in the platform can continue to operate in the same manner. Remapping of one function of an application to be implemented in the platform does not require remapping of all components and / or functions of the application across the platform.

[0060] The platform also supports the creation of multiple different partitions in the device at the same time. Each partition can implement different applications in it. Each partition and the applications executed therein can be isolated from each other partition in the platform. The term "application" used herein in connection with the platform and the example SoC described herein refers to any data, whether executable program code, configuration bitstream, register programming data, or an image for configuring the SoC or a portion thereof (e.g., the entire device or a partition thereof). The described partitions also support multi-client or multi-tenant use cases, where different applications corresponding to the same end user or different end users can be executed simultaneously in each different partition in the device. The platform allows any of the various components of the device to access subsystems, such as programmable logic, using a common infrastructure.

[0061] Other aspects of the arrangement of the present invention are described in more detail below with reference to the accompanying drawings. For simplicity and clarity of illustration, the elements shown in the drawings are not necessarily drawn to scale. For example, for clarity, the size of some elements may be enlarged relative to other elements. In addition, where deemed appropriate, the reference numerals in the accompanying drawings are repeated to indicate corresponding, similar or similar features.

[0062] Figure 1 An example architecture of a system on a chip (SoC) 100 is shown. SoC 100 is an example of a programmable IC and an integrated programmable device platform. Figure 1 In the example of FIG. 1 , various different subsystems or regions of the SoC 100 shown 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.

[0063] In this example, SoC 100 includes multiple regions of 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 referred to as 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.

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

[0065] Each programmable circuit block within PL 104 typically includes programmable interconnect circuitry and programmable logic circuitry. The programmable interconnect circuitry typically includes a large number of interconnect lines of varying lengths interconnected by programmable interconnect points (PIPs). Typically, the interconnect lines are configured (e.g., on a per-line basis) to provide connectivity on a bit basis (e.g., where each line carries one bit of information). The programmable logic circuitry implements user-designed logic using programmable elements, which may include, for example, lookup 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 operate.

[0066] PS106 is implemented as a hard-wired circuit, which is manufactured as a part for SoC 100. PS106 can be implemented as, or include, any of various different processor types, each of which can execute program code. For example, PS106 can be implemented as a separate processor, such as a single core that can execute program code. In another example, PS106 can be implemented as a multi-core processor. In another example, PS106 can include one or more cores, modules, coprocessors, interfaces and / or other resources. PS106 can use any of a variety of different types of architectures to realize. The example architecture that can be used to realize PS106 can include but is not limited to ARM processor architecture, x86 processor architecture, GPU architecture, mobile processor architecture, DSP architecture or other applicable architectures that can execute computer-readable instructions or program code.

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

[0068] NoC 108 provides connectivity to PL 104, PS 106, and to selected circuit blocks in hardwired circuit blocks 110. NoC 108 is programmable. In the case where a programmable NoC is used with other programmable circuits, the network to be routed through NoC 108 is unknown before creating a user circuit design to be implemented within SoC 100. NoC 108 can be programmed by loading configuration data into internal configuration registers that define how elements in NoC 108 (e.g., switches and interfaces) are configured and operated to pass data from switch to switch and between NoC interfaces.

[0069] The NoC 108 is manufactured as part of the SoC 100, and although it cannot be physically modified, it can be programmed to establish connections between different master circuits and different slave circuits of the user circuit design. For example, the NoC 108 can include a plurality of programmable switches capable of establishing a packet switched network connecting the user-specified master circuits and slave circuits. In this regard, the NoC 108 can accommodate different circuit designs, each of which has a different combination of master circuits and slave circuits implemented at different locations in the SoC 100 and 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 circuits and slave circuits of the user circuit design. For example, the NoC 108 can be programmed to couple different user-specified circuits implemented in the PL 104 with the PS 106, and / or the DPE array 102, with different hard-wired circuit blocks, and / or with different circuits and / or systems outside the SoC 100.

[0070] 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, and the like. Examples of different I / O blocks may include single-ended and pseudo-differential I / Os and high-speed differential clock transceivers. In addition, the hardwired circuit blocks 110 may be implemented to perform specific functions. Examples of hardwired circuit blocks 110 include, but are not limited to, encryption engines, digital-to-analog converters, analog-to-digital converters, and the like. The hardwired circuit blocks 110 within the SoC 100 may be referred to as dedicated blocks from time to time herein.

[0071] exist Figure 1 104 is shown in two separate regions. In another example, PL 104 can be implemented as a unified region of programmable circuitry. In yet another example, PL 104 can be implemented as more than two different regions of programmable circuitry. The particular organization of PL 104 is not intended to be limiting. In this regard, SoC 100 includes one or more PL regions 104, PS 106, and NoC 108. DPE array 102 can optionally be included.

[0072] In other example implementations, the SoC 100 may include two or more DPE arrays 102 located in different areas of the IC. In still 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. Using a stacked die architecture in which the IC is implemented as a multi-chip module (MCM) or the like, the different dies may be communicatively linked using any of a variety of available multi-die IC technologies, such as stacking the dies side by side on an interposer. In the multi-die IC example, it should be understood that each die may include a single subsystem, two or more subsystems, a subsystem and another partial subsystem, or any combination thereof.

[0073] Figure 2 An example implementation of a DPE array 102 is shown. Figure 2 In the example of FIG. 1 , the DPE array 102 is implemented as a two-dimensional array of DPEs 204 including SoC interface blocks 206. The DPE array 102 may be implemented using any of a variety of different architectures described in more detail below. For purposes of illustration and not limitation, Figure 2The DPEs 204 are shown arranged in aligned rows and aligned columns. However, in other embodiments, the DPEs 204 may be arranged so that the DPEs in a selected row and / or column are horizontally inverted or flipped relative to the DPEs in an adjacent row and / or column. In one or more other embodiments, the rows and / or columns of the 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 of which is capable of executing program code. The number of DPEs 204, the specific arrangement of the DPEs 204, and / or the orientation of the DPEs 204 are not intended to be limiting.

[0074] The SoC interface block 206 can couple the DPE 204 to one or more other subsystems of the device IC 200. In one or more embodiments, the SoC interface block 206 is coupled to adjacent DPEs 204. For example, the SoC interface block 206 can be directly coupled to each DPE 204 in the bottom row of DPEs in the DPE array 202. In the figure, the SoC interface block 206 can 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.

[0075] Figure 2 The SoC interface block 206 is provided for illustration 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 at multiple locations in 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 specific DPEs coupled to the SoC interface block 206 may vary.

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

[0077] The DPEs 204 are interconnected via DPE interconnects (not shown) when they collectively form a DPE interconnect network. Thus, the SoC interface block 206 is able to communicate with any DPE 204 of the DPE array 102 by communicating with one or more selected DPEs 204 of the DPE array 102 directly connected to the SoC interface block 206, as well as by utilizing the DPE interconnect network formed by the DPE interconnects implemented in each corresponding DPE 204.

[0078] The SoC interface block 206 can couple each DPE 204 within the DPE array 102 to 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. In this way, the DPE array 102 can communicate with circuit blocks implemented in the PL 104, the PS 106, and / or any hardwired circuit blocks 110. For example, the SoC interface block 206 can establish a connection between a selected DPE 204 and the PL 104. The SoC interface block 206 can also establish a connection between a selected DPE 204 and the NoC 108. Through the NoC 108, the selected DPE 204 can communicate with the PS 106 and / or the hardwired circuit block 110. The selected DPE 204 can communicate with the hardwired circuit block 110 via the SoC interface block 206 and the PL 104. In certain embodiments, SoC interface block 206 may be directly coupled to one or more subsystems of SoC 100. For example, SoC interface block 206 may be directly coupled to PS 106 and / or other hardwired circuit blocks 110. In certain embodiments, hardwired circuit blocks 110 may be considered examples of ASICs.

[0079] 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. Nevertheless, the DPE array 102 may include additional clocks that may be used to interact with other subsystems in the subsystem. In a particular embodiment, the SoC interface block 206 includes a clock signal generator capable of generating one or more clock signals that may be provided or distributed to the DPEs 204 of the DPE array 102.

[0080] The DPE array 102 can be programmed by loading configuration data into internal configuration memory cells (also referred to herein as "configuration registers") that define connectivity between the DPE 204 and the SoC interface block 206 and how the DPE 204 and the SoC interface block 206 operate. For example, for a particular DPE 204 or group of DPEs 204 to communicate with a subsystem, the DPE(s) 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 DPE is programmed to do so. The DPE 204 and the SoC interface block 206 can be programmed by loading configuration data into configuration registers within the DPE 204 and the SoC interface block 206, respectively. In another example, a clock signal generator that is part of the SoC interface block 206 can be programmable using configuration data to change the clock frequency provided to the DPE array 102.

[0081] Figure 3 Shows Figure 2 An example architecture of a DPE 204 of a DPE array 102 is shown in FIG. Figure 3 In the example of SoC 100, DPE 204 includes core 302, memory module 304, and DPE interconnect 306. Each DPE 204 is implemented as a hardwired and programmable circuit block on SoC 100.

[0082] Core 302 provides the data processing capabilities of DPE 204. Core 302 may be implemented as any of a variety of different processing circuits. Figure 3 In the example of the embodiment of the present invention, the core 302 includes an optional program memory 308. In the example implementation, the core 302 is implemented as a processor capable of executing program code (e.g., computer readable instructions). In that case, the program memory 308 is included and can store instructions executed by the core 302. For example, the core 302 can be implemented as a CPU, a GPU, a DSP, a vector processor, or other types of processors capable of executing instructions. The core 302 can be implemented using any of the various CPUs and / or processor architectures described herein. In another example, the core 302 is implemented as a very long instruction word (VLIW) vector processor or a DSP.

[0083] In a particular implementation, program memory 308 is implemented as a dedicated program memory that is exclusive to core 302 (e.g., accessed exclusively by core 302). Program memory 308 may only be used by cores of the same DPE 204. Thus, program memory 308 may only be accessed by core 302 and is not shared with any other DPE or components of another DPE. Program memory 308 may include a single port for read and write operations. Program memory 308 may support program compression and may be addressed using a memory-mapped network portion of DPE interconnect 306 described in more detail below. For example, via the memory-mapped network of DPE interconnect 306, program memory 308 may be loaded with program code that may be executed by core 302.

[0084] 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. Figure 3 In the example of , configuration registers 324 are addressable (eg, readable and / or writable) via a memory-mapped network of DPE interconnect 306 described in greater detail below.

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

[0086] In one or more other embodiments, the memory module 304 is capable of storing data that can be used and / or generated by one or more other cores of other DPEs within the DPE array, such as application data. One or more other cores of the DPE can also read from and / or write to the memory module 304. In a specific embodiment, the other cores that can read and / or write from the memory module 304 can be cores of one or more adjacent DPEs. Another DPE that shares a border or demarcation line (e.g., adjacent) with the DPE 204 is referred to as a "neighboring" DPE relative to the DPE 204. By allowing the core 302 and one or more other cores from the adjacent DPE to read and / or write to the memory module 304, the memory module 304 implements a shared memory that supports communication between different DPEs and / or cores that can access the memory module 304.

[0087] refer to Figure 2 , for example, DPEs 204-14, 204-16, 204-5, and 204-25 are considered to be neighboring DPEs of DPE 204-15. In one example, a core within each of DPEs 204-16, 204-5, and 204-25 is able to read and write to a memory module within DPE 204-15. In certain embodiments, only those neighboring DPEs that are adjacent to a memory module may access the memory module of DPE 204-15. For example, DPE 204-14, while adjacent to DPE 204-15, may not be 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. Therefore, in certain embodiments, the core of DPE 204-14 may not be able to access the memory module of DPE 204-15.

[0088] In a particular embodiment, whether a core of a DPE can access a memory module of another DPE depends on the number of memory interfaces included in the memory module and whether the cores are connected to an available memory interface among the memory interfaces of the memory module. In the above example, the memory module of DPE 204-15 includes four memory interfaces, wherein the core of each of DPEs 204-16, 204-5, and 204-25 is connected to such a memory interface. The core 302 within 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 a particular embodiment, each memory interface includes multiple read channels and multiple write channels, so that a particular core coupled thereto can read and / or write multiple banks within the memory module 304 at the same time.

[0089] In other examples, there may be more than four memory interfaces available. These other memory interfaces may be used to allow DPEs on a diagonal line of DPE 204-15 to access memory modules of DPE 204-15. For example, if cores in 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 in DPE 204-15, such other DPEs will also be able to access memory modules of DPE 204-15.

[0090] The memory module 304 may include a configuration register 336. The configuration register 336 may be loaded with configuration data to control the operation of the memory module 304. Figure 3In the example of , configuration registers 336 (and 324) are addressable (eg, readable and / or writable) via a memory-mapped network of DPE interconnect 306 described in greater detail below.

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

[0092] In a particular embodiment, the DPE interconnect 306 is implemented as an on-chip interconnect. An example of an on-chip interconnect is an Advanced Microcontroller Bus Architecture (AMBA) eXtensible Interface (AXI) bus (e.g., or a switch). The AMBA AXI bus is an embedded microcontroller bus interface for establishing on-chip connections between circuit blocks and / or systems. The AXI bus is provided here as an example of an interconnect circuit that can be used with the inventive arrangements described in the present disclosure and is therefore not intended to be limiting. Other examples of interconnect circuits may include other types of buses, crossbars, and / or other types of switches.

[0093] In one or more embodiments, the DPE interconnect 306 includes two different networks. The first network can exchange data with other DPEs of the DPE array 102 and / or other subsystems of the SoC 100. For example, the first network can exchange application data. The second network can exchange data for the DPE (e.g., configuration, control, and / or debug data).

[0094] exist Figure 3 In the example of FIG. 3 , the first network of DPE interconnects 306 is formed by a stream switch 326 and one or more stream interfaces (not shown). For example, the stream switch 326 includes a stream interface for connecting to each of the core 302, the memory module 304, the memory mapping switch 332, the upper DPE, the left DPE, the right DPE, and the lower DPE. Each stream interface may include one or more masters and one or more slaves.

[0095] Stream switch 326 can allow non-adjacent DPEs and / or DPEs not coupled to memory interfaces of memory module 304 to communicate with core 302 and / or memory module 304 via a DPE interconnect network formed by DPE interconnects of corresponding DPEs 204 of DPE array 102 .

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

[0097] Stream switch 326 may also be used to interact with subsystems such as PL 104 and / or NoC 108. Typically, stream switch 326 is programmed to operate as a circuit-switched stream interconnect or a packet-switched stream interconnect. Circuit-switched stream interconnects enable point-to-point dedicated streams suitable for high-bandwidth communications between DPEs. Packet-switched stream interconnects allow shared streams to time-division multiplex multiple logical streams onto one physical stream for medium-bandwidth communications.

[0098] The stream switch 326 may include configuration registers (in Figure 3 Configuration data may be written to configuration registers 334 by way of a memory-mapped network of DPE interconnect 306. The configuration data loaded into configuration registers 334 indicates which other DPEs and / or subsystems (e.g., NoC 108, PL 104, and / or PS 106) the DPE 204 is to communicate with, and whether such communications are to be established as circuit-switched point-to-point connections or as packet-switched connections.

[0099] The second network of DPE interconnects 306 is formed by a memory-mapped switch 332. The memory-mapped switch 332 includes a plurality of memory-mapped interfaces (not shown). Each memory-mapped interface may include one or more principals and one or more slaves. For example, the memory-mapped switch 332 includes a memory-mapped interface for connecting to each of the core 302, the memory module 304, the memory-mapped switch in the DPE above the DPE 204, and the memory-mapped switch in the DPE below the DPE 204.

[0100] The memory mapped switch 332 is used to transfer configuration, control and debug data of the DPE 204. Figure 32, memory mapped switch 332 can receive configuration data for configuring DPE 204. Memory mapped switch 332 can receive configuration data from a DPE located below DPE 204 and / or from SoC interface block 206. Memory mapped switch 332 can forward the received configuration data to one or more other DPEs above DPE 204, to core 302 (e.g., to program memory 308 and / or to configuration registers 324), to memory module 304 (e.g., to memory within memory module 304 and / or to configuration registers 336), and / or to configuration registers 334 within stream switch 326.

[0101] The DPE interconnect 306 is coupled to the DPE interconnect of each adjacent DPE and / or SoC interface block 206 according to the location of the DPE 204. In general, the DPE interconnects of the DPE 204 form a DPE interconnect network (which may include a stream network and / or a memory mapped network). The configuration registers of the stream switch of each DPE can be programmed by loading configuration data via the memory mapped switch. Through configuration, the stream switch and / or stream interface is programmed to establish a connection (whether a packet switched or circuit switched connection) with other endpoints (whether in one or more other DPEs 204 and / or in the SoC interface block 206).

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

[0103] exist Figure 3 In the example of , the memory mapped interface can receive configuration data for DPE 204. The configuration data can include program code to be loaded into program memory 308 (if included), configuration data to be loaded into configuration registers 324, 334, and / or 336, and / or data to be loaded into a memory (e.g., a memory bank) of memory module 304. Figure 3 In the example of FIG. 3 , configuration registers 324 , 334 , and 336 are shown as being located within the specific circuit structures (eg, core 302 , stream switch 326 , and memory module 304 ) that the configuration registers are intended to control. Figure 3The examples are for illustration purposes only and illustrate that elements within core 302, memory module 304, and / or stream switch 326 may be programmed by loading configuration data into corresponding configuration registers. In other embodiments, configuration registers may be consolidated within specific areas of DPE 204, although controlling the operation of components distributed throughout DPE 204.

[0104] 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 actual connections or application data paths within the DPE 204 with other DPEs and / or with other subsystems of the integrated circuit 300.

[0105] Figure 4 Shows Figure 3 Further aspects of the example architecture. Figure 4 In the example shown, details regarding DPE interconnect 306 are not shown. Figure 4 The connection of core 302 to other DPEs via shared memory is shown. Figure 4 Additional aspects of the memory module 304 are also shown. For illustration purposes, Figure 4 Refer to DPE 204-15.

[0106] As shown, the memory module 304 includes a plurality of memory interfaces 402, 404, 406, and 408. Figure 4 , memory interfaces 402 and 408 are abbreviated as "MI". The memory module 304 also includes a plurality of memory groups 412-1 to 412-N. In a particular embodiment, the memory module 304 includes eight memory groups. In other embodiments, the memory module 304 may include fewer or more memory groups 412. In one or more embodiments, each memory group 412 is single-ported, thereby allowing a maximum of one access to each memory group per clock cycle. In the case where the memory module 304 includes eight memory groups 412, such a configuration supports eight parallel accesses per clock cycle. In other embodiments, each memory group 412 is dual-ported or multi-ported, thereby allowing a greater number of parallel accesses per clock cycle.

[0107] exist Figure 4In the example of FIG. 4 , each of the memory groups 412-1 to 412-N has a respective arbiter 414-1 to 414-N. Each arbiter 414 can generate a stall signal in response to detecting a conflict. Each arbiter 414 can include arbitration logic. In addition, each arbiter 414 can include a crossbar. Therefore, any subject can write to any particular one or more memory groups 412. As shown in conjunction with Figure 3 As mentioned above, the memory module 304 is connected to the memory mapped switch 332 to facilitate reading and writing of data to the memory bank 412. Thus, specific data stored in the memory module 304 can be controlled (e.g., written) through the memory mapped switch 332 as part of a configuration, control, and / or debugging process.

[0108] Memory module 304 also 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 bank 412. One or more other interfaces can read data from memory bank 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 memory access interface (e.g., a stream switch) for accessing memory banks 412. Figure 3 The flow interface of the flow switch 326.

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

[0110] Core 302 can access memory modules of other adjacent DPEs through core interfaces 430, 432, and 434. Figure 4 4. In the example of , core interface 434 is coupled to a memory interface of DPE 204-25. Thus, core 302 is able to access the memory modules of DPE 204-25 via core interface 434 and a memory interface contained within the memory modules of DPE 204-25. Core interface 432 is coupled to a memory interface of DPE 204-14. Thus, core 302 is able to access the memory modules of DPE 204-14 via core interface 432 and a memory interface contained within the memory modules of DPE 204-14. Core interface 430 is coupled to a memory interface within DPE 204-5. Thus, core 302 is able to access the memory modules of DPE 204-5 via core interface 430 and a memory interface contained within the memory modules of DPE 204-5. As discussed, core 302 is able to access memory modules 304 within DPE 204-15 via core interface 428 and memory interface 402.

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

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

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

[0114] As discussed, the DMA engine 416 may include one or more stream-to-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 from other DPEs that share a boundary with the DPE 204-15 and / or do not share a boundary with the DPE 204-15 through the stream switch 326. Data may also be received from other subsystems of the SoC (e.g., NoC 108, hardwired circuit block 110, PL 104, and / or PS 106) through the stream switch of the DPE via the SoC interface block 206. The DMA engine 416 is capable of receiving such data from the stream switch and writing the data to one or more appropriate memory groups 412 within the memory module 304.

[0115] The DMA engine 416 may include one or more memory-to-stream interfaces. Through the DMA engine 416, data may be read from one or more memory banks 412 of the memory module 304 and sent to other destinations via a stream interface. 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., NoC 108, hardwired circuit block 110, PL 104, and / or PS 106) through a stream switch and SoC interface block 206.

[0116] In one or more embodiments, the DMA engine 416 is programmed by a memory mapped switch 332 within the DPE 204-15. For example, the DMA engine 416 may be controlled by a configuration register 336. The configuration register 336 may be written using the memory mapped switch 332 of the DPE interconnect 306. In a particular embodiment, the DMA engine 416 may be controlled by a stream switch 326 within the DPE 204-15. For example, the DMA engine 416 may include a control register that may be written by the stream switch 326 connected thereto. Depending on the configuration data loaded into the configuration registers 324, 334, and / or 336, a stream received via the stream switch 326 within 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, a stream may be sent from the DMA engine 416 (e.g., the memory module 304) and / or the core 302.

[0117] The memory module 304 may also include a hardware synchronization circuit 420 (in Figure 4 In general, the hardware synchronization circuit 420 is capable of synchronizing different cores (e.g., cores of adjacent DPEs), Figure 4 The hardware synchronization circuit 420 can synchronize the operation of the core 302, DMA engine 416, and other external entities (e.g., PS 106) that can communicate via the DPE interconnect 306. As an illustrative and non-limiting example, the hardware synchronization circuit 420 can synchronize the DMA in two different cores, stream switches, memory mapping interfaces, and / or DPEs 204-15 and / or different DPEs accessing the same (e.g., shared) cache in the memory module 304.

[0118] In the case where the two DPEs are not adjacent, the two DPEs cannot access a common memory module. In that case, the application data can be transferred via a data stream (the terms "data stream" and "stream" can be used interchangeably from time to time in this disclosure). In this way, the local DMA engine can 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 can be synchronized using the hardware synchronization circuit 420.

[0119] The PS 106 can communicate with the core 302 through 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 can also send an interrupt to the PS 106 when the state of the lock changes to avoid polling of the PS 106 by the hardware synchronization circuit 420. The PS 106 can also communicate with the DPE 204-15 via a stream interface.

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

[0121] exist Figure 4 In the example of , each of cascade interface 422 and cascade interface 424 may include a first-in-first-out (FIFO) interface for buffering. In certain embodiments, cascade interfaces 422 and 424 are capable of transmitting data streams that may be hundreds of bits wide. The specific bit widths of cascade interfaces 422 and 424 are not intended to be limiting. Figure 4 In the example of FIG. 4 , the cascade interface 424 is coupled to the accumulator register 436 (in Figure 4 Cascade interface 424 is capable of outputting the contents of accumulator register 436 and may do so at each clock cycle. Accumulator register 436 may store data generated and / or operated on by data processing circuitry within core 302.

[0122] exist Figure 4 In the example of FIG. 4 , cascade interfaces 422 and 424 can be programmed based on configuration data loaded into configuration register 324. For example, based on configuration register 324, cascade interface 422 can be activated or deactivated. Similarly, based on configuration register 324, cascade interface 424 can be activated or deactivated. Cascade interface 422 can be activated and / or deactivated independently of cascade interface 424.

[0123] In one or more other embodiments, the cascade interfaces 422 and 424 are controlled by the core 302. For example, the core 302 may include instructions to read / write the cascade interfaces 422 and / or 424. In another example, the core 302 may include hardwired circuitry that is capable of reading and / or writing the cascade interfaces 422 and / or 424. In certain embodiments, the cascade interfaces 422 and 424 may be controlled by an entity external to the core 302.

[0124] In the embodiments described in the present disclosure, DPE 204 does not include cache memory. By omitting cache memory, DPE array 202 is able to achieve predictable (e.g., deterministic) performance. In addition, since there is no need to maintain consistency between cache memories located in different DPEs, significant processing overhead is avoided.

[0125] According to one or more embodiments, the core 302 of the DPE 204 has no input interrupts. Therefore, the core 302 of the DPE 204 can run uninterrupted. Omitting input interrupts to the core 302 of the DPE 204 also allows the DPE array a02 to achieve predictable (eg, deterministic) performance.

[0126] Figure 5 Another example architecture of a DPE array is shown. Figure 5 In the example of FIG. 1 , 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 interrupts and communicate interrupts to entities external to the DPE array 102, communicate application data between other subsystems and the DPE 204, and / or communicate trace and / or debug data between other subsystems and the DPE 204.

[0127] exist Figure 5 In the example of , SoC interface block 206 includes a plurality of interconnected tiles. For example, SoC interface block 206 includes tiles 502, 504, 506, 508, 510, 512, 514, 516, 518, and 520. Figure 5 In the example of FIG. 5 , the cell blocks 502-520 are organized into a row. In other embodiments, the cell blocks may be arranged in columns, in a grid, or in another layout. For example, the SoC interface block 206 may be implemented as a column of cell blocks on the left side of the DPE 204, on the right side of the DPE 204, between the columns of the DPE 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 so that the cell blocks are located below the DPE array 202, on the left side of the DPE array 202, on the right side of the DPE array 202, and / or any combination of above the DPE array 202. Figure 5 It is provided for purposes of illustration and not limitation.

[0128] In one or more embodiments, the cell blocks 502-520 have the same architecture. In one or more other embodiments, the cell blocks 502-520 may be implemented with two or more different architectures. In a particular embodiment, different architectures may be used to implement the cell blocks within the SoC interface block 206, wherein each different cell block architecture supports communication with different types of subsystems or combinations of subsystems of the SoC 100.

[0129] exist Figure 5 In the example of , cell blocks 502-520 are coupled so that data can propagate from one cell block to another. For example, data can propagate from cell block 502 through cell blocks 504, 506, and down the line of cell blocks to cell block 520. Similarly, data can propagate from cell block 520 to cell block 502 in the opposite direction. In one or more embodiments, each of cell blocks 502-520 can operate as an interface to multiple DPEs. For example, each of cell blocks 502-520 can operate as an interface to a subset of DPEs 204 of DPE array 102. The subset of DPEs to which each cell block provides an interface can be mutually exclusive, such that no DPE is provided an interface by more than one cell block of SoC interface block 206.

[0130] In one example, each of the cell blocks 502-520 provides an interface to a column of DPEs 204. For purposes of illustration, cell block 502 provides an interface to the DPEs of column A. Cell block 504 provides an interface to the DPEs of column B, and so on. In each case, the cell block includes a direct connection to an adjacent DPE in the column of DPEs, which in this example is the bottom DPE. For example, for column A, cell block 502 is directly connected to DPE 204-1. Other DPEs within column A can communicate with cell block 502, but this is done through the DPE interconnects of intervening DPEs in the same column.

[0131] For example, cell block 502 can receive data from another source such as PS 106, PL 104, and / or another hardwired circuit block 110 (e.g., an ASIC block). Cell block 502 can provide those portions of the data addressed to the DPEs in column A to those DPEs, while sending data addressed to DPEs in other columns (e.g., DPEs to which cell block 502 is not an interface) to cell block 504. Cell block 504 can perform the same or similar processing, wherein data received from cell block 502 addressed to DPEs in column B is provided to those DPEs, while data addressed to DPEs in other columns is sent to cell block 506, and so on.

[0132] In this manner, data can propagate from cell block to cell block of the SoC interface block 206 until it reaches a cell block that serves as an interface to the DPE to which the data is addressed (e.g., a "target DPE"). A cell block operating as an interface to a target DPE can direct data to the target DPE using a memory-mapped switch of the DPE and / or a stream switch of the DPE.

[0133] As noted, the use of columns is an example implementation. In other embodiments, each unit block of the SoC interface block 206 is capable of providing an interface to a row of DPEs of the DPE array 102. Such a configuration can be used in the case where the SoC interface block 206 is implemented as a unit block column, whether it is on the left side, right side, or between columns of the DPE 204. In other embodiments, the subset of DPEs for which each unit block provides an interface can be any combination of less than all DPEs of the DPE array 102. For example, DPE204 can be assigned to a unit block of the SoC interface block 206. The specific physical layout of such DPEs can vary depending on the connectivity of the DPEs established by the DPE interconnection. For example, unit block 502 can provide interfaces to DPEs 204-1, 204-2, 204-11, and 204-12. Another unit block of the SoC interface block 206 can provide interfaces to four other DPEs, and so on.

[0134] Figure 6 FIG. 2 shows an example architecture of a unit block of the SoC interface block 206. Figure 6 In the example of FIG. 6 , two different types of cell blocks of the SoC interface block 206 are shown. Cell block 602 is configured to serve as an interface between the DPE and only the PL 104. Cell block 610 is configured to serve as an interface between the DPE and the NoC 108 and between the DPE and the PL 104. The SoC interface block 206 may include a combination of cell blocks using both architectures as shown for cell block 602 and cell block 610, or, in another example, only cell blocks having the architecture as shown for cell block 610.

[0135] exist Figure 6 1, cell block 602 includes a flow switch 604 connected to a PL interface 606 and a DPE (such as DPE 204-1 immediately above). PL interface 606 is connected to a boundary logic interface (BLI) circuit 620 and a BLI circuit 622, each located in PL 104. Cell block 610 includes a flow switch 612 connected to a NoC and PL interface 614 and to a DPE (such as DPE 204-5 immediately above). NoC and PL interface 614 is connected to BLI circuits 624 and 626 in PL 104, and is also connected to a NoC master unit (NMU) 630 and a NoC slave unit (NSU) 632 of NoC 108.

[0136] exist Figure 6 In the example of FIG. 6 , each stream interface 604 is capable of outputting six different 32-bit data streams to the DPE coupled thereto and receiving four different 32-bit data streams therefrom. Each of the PL interface 606 and the NoC to PL interface 614 is capable of providing six different 64-bit data streams to the PL 104 via the BLI 620 and the 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 the NoC to PL interface 614 connect. Each of the PL interface 606 and the NoC to PL interface 614 is capable of receiving eight different 64-bit data streams from the PL 210 via the BLI 622 and the BLI 624, respectively.

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

[0138] The stream switches 604 in adjacent cell blocks are connected. In one example, the stream switches 604 in adjacent cell blocks can communicate via four different 32-bit data streams in each of the left and right directions (eg, whenever the cell block is on the right or left, as appropriate).

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

[0140] The various bit widths and numbers of data flows described in conjunction with the various switches included in the unit blocks 602 and / or 610 of the DPE 204 and / or SoC interface block 206 are provided for purposes of illustration and are not intended to limit the inventive arrangements described in this disclosure.

[0141] Figure 7 An example implementation of the NoC 108 is shown. 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 entry circuit that connects an endpoint circuit to the NoC 108. Each NSU 704 is an exit circuit that connects the NoC 108 to the endpoint circuit. The NMU 702 is connected to the NSU 704 through a network 714. In one example, the network 714 includes a NoC packet switch 706 (NPS) and a route 708 between the NoC packet switches 706. Each NoC packet switch 706 performs the exchange of NoC packets. The NoC packet switches 706 are connected to each other and to the NMU 702 and the NSU 704 through a route 708 to implement multiple physical channels. The NoC packet switch 706 also supports multiple virtual channels for each physical channel.

[0142] The NPI 710 includes circuits for programming the NMU 702, the NSU 704, and the NoC packet switch 706. For example, the NMU 702, the NSU 704, and the NoC packet switch 706 may include registers 712 that determine their functions. The NPI 710 includes a peripheral interconnect coupled to the registers 712 for programming them 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.

[0143] NMU 702 is a traffic entry point. NSU 704 is a traffic exit point. The endpoint circuits coupled to NMU 702 and NSU 704 may be hardened circuits (e.g., hardwired circuit blocks 110) or circuits implemented in PL 104. A given endpoint circuit may be coupled to more than one NMU 702 or more than one NSU 704.

[0144] Figure 81 is a block diagram depicting 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 through 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 in PS 106, a circuit in PL region 104, or a circuit in another subsystem (e.g., hardwired circuit block 110).

[0145] The network 714 includes a plurality of 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 routes 708. The NMU 702 is connected to the NSU 704 through at least one physical channel 806. The physical channel 806 may also have one or more virtual channels 808.

[0146] The connection through the network 714 uses a master-slave arrangement. In one example, the most basic connection on the network 714 includes a single master connected to a single slave. However, in other examples, more complex structures can be implemented.

[0147] Fig. 9 1 is a block diagram depicting 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 PL regions 104. The HNoC 904 is disposed between the PL regions 104 and an I / O group 910 (e.g., an I / O block and / or a transceiver corresponding to a hardwired circuit block 110). The NoC 108 is connected to a memory interface 908 (e.g., other hardwired circuit blocks 110). The PS 106 is coupled to the HNoC 904.

[0148] In this example, the PS 106 includes a plurality of NMUs 702 coupled to the HNoC 904. The VNoC 902 includes both the NMUs 702 and the NSUs 704 arranged in the PL region 104. The memory interface 908 includes the NSU 704 coupled to the HNoC 904. Both the HNoC 904 and the VNoC 902 include NPSs 706 connected by routes 708. In the VNoC 902, the routes 708 extend vertically. In the HNoC 904, the routes extend horizontally. In each VNoC 902, each NMU 702 is coupled to the NPS 706. Similarly, each NSU 704 is coupled to the NPS 706. The NPSs 706 are coupled to each other to form a switch matrix. Some NPSs 706 in each VNoC 902 are coupled to other NPSs 706 in the HNoC 904.

[0149] Although only a single HNoC 904 is shown, in other examples, the NoC 108 may include more than one HNoC 904. Also, although two VNoCs 902 are shown, the NoC 108 may include more than two VNoCs 902. Although a memory interface 908 is shown by way of example, it should be understood that other hardwired circuit blocks 110 may be used in place of or in addition to the memory interface 908.

[0150] Fig.10 An example method 1000 of programming the NoC 108 is shown. Although the method 1000 is described independently of other subsystems of the SoC 100, the method 1000 may also be included and / or used as part of a larger boot-up or programming process for the SoC 100.

[0151] At block 1002, a platform management controller (PMC) implemented in 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 secure and reliable environment, boot the SoC 100, and manage the SoC 100 during normal operation.

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

[0153] Fig.11 An example method 1100 for programming the NoC 108 is shown. At block 1102, the PMC receives NoC programming data during execution time. 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 the routing table in the NPS 706. At block 1108, the PMC configures the QoS paths on the physical channels 806. At block 1110, the PMC configures the address space mapping. At block 1112, the PMC configures the ingress / egress interface protocol, width, and frequency. The QoS paths, address space mapping, routing tables, and ingress / egress configurations are discussed further below.

[0154] Fig.12 An example data path 1200 is shown between endpoint circuits through the NoC 108. 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.

[0155] The NMU 1206 is coupled to the NPS 1208. The NPSs 1208 are coupled to each other to form a chain of NPSs 1208 (e.g., a chain of five NPSs 1208 in this example). Generally, there is at least one NPS 1208 between the NMU 1206 and the NSU 1210. The NSU 1210 is coupled 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.

[0156] Each of the endpoint circuits 1202 and 1214 may be a hardened circuit (e.g., a PS circuit, a hardwired circuit 110, one or more DPEs 204) or a circuit configured in the PL 104. The endpoint circuit 1202 acts as a master circuit and sends a read / write request to the NMU 1206. In this example, the endpoint circuits 1202 and 1214 communicate with the NoC 108 by using the AXI protocol. Although AXI is described in the 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. By way of example, for clarity, the NoC 108 is described herein as supporting the AXI protocol. The NMU 1206 forwards the request through a set of NPSs 1208 to reach the destination NSU 1210. The NSU 1210 passes the request to the attached AXI slave circuit 1212 for processing and distribution of data to the endpoint circuit 1214. The AXI slave circuit 1212 may send a read / write response back to the NSU 1210. The NSU 1210 may forward the response to the NMU 1206 through a set of NPSs 1208. The NMU 1206 transmits the response to the AXI master circuit 1204, which distributes the data to the endpoint circuit 1202.

[0157] Fig.13 An example method 1300 for processing read / write requests and responses is shown. 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 the example, the NMU 1206 performs asynchronous crossing and rate matching between the clock domains of the endpoint circuit 1202 and the NoC 108. The NMU 1206 determines the destination address of the NSU 1210 based on the request. In the case of virtualization, the NMU 1206 can perform address remapping. The NMU 1206 also performs AXI conversion of the request. The NMU 1206 further packages the request into a data packet stream.

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

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

[0160] Fig.14An example implementation of NMU 702 is shown. NMU 702 includes AXI master interface 1402, packetization circuit 1404, address mapping table 1406, unpacking circuit 1408, QoS circuit 1410, VC mapping circuit 1412, and clock management circuit 1414. AXI master interface 1402 provides an AXI interface to NMU 702 for endpoint circuits. In other examples, different protocols can be used, so NMU 702 can have different master interfaces that conform to the selected protocol. NMU 702 routes inbound traffic to packetization circuit 1404, which generates packets from inbound data. Packetization circuit 1404 determines the destination ID from address mapping table 1406, which is used to route the packet. The destination ID is used internally in NoC 108 and is used to specify the destination interface to which the packet is sent. QoS circuit 1410 can provide ingress rate control to control the injection rate of packets to NoC 108. VC mapping circuit 1412 manages QoS virtual channels on each physical channel. The NMU 702 may be configured to select which virtual channel the data 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 unpacking circuit 1408 receives a return data packet from the NoC 108 and is configured to unpack the data packet for output by the AXI master interface 1402.

[0161] Fig.15 An example implementation of NSU 704 is shown. NSU 704 includes AXI slave interface 1502, clock management circuit 1504, packing circuit 1508, unpacking circuit 1506, and QoS circuit 1510. AXI slave interface 1502 provides an AXI interface to NSU 704 for endpoint circuits. In other examples, different protocols may be used, and thus NSU 704 may have different slave interfaces that conform to the selected protocol. NSU 704 routes inbound traffic from NoC 108 to unpacking circuit 1506 that generates unpacked data. 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. Packing circuit 1508 receives return data from slave interface 1502 and is configured to pack the return data for transmission through NoC 108. QoS circuit 1510 may provide ingress rate control to control the injection rate of data packets to NoC 108.

[0162] Fig.16An example connection to a register block 712 of a NoC 108 through an NPI 710 is shown. 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. In some examples, the root node 1604 resides in the PMC 1602. In some examples, the PMC 1602 resides in the PS 106, however in other examples, the root node 1604 and the PMC 1602 may be separate circuits or reside on another system or circuit. Typically, the root node 1604 may package a transaction request into a format implemented by the NPI 710, and may send a memory-mapped transaction request to the NPI switch 1608, which may further send the memory-mapped transaction request to other NPI switches 1608 or protocol blocks 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 as a tree topology to the root node 1604. The protocol block 1610 can then convert the memory mapped transaction request into a format implemented by the register block 712. The register block 712 Fig.16 , as an example of a slave endpoint circuit to which NPI 710 may be connected. NPI 710 may also be connected to other slave endpoint circuits.

[0163] PMC 1602 is further connected to configuration interconnect 1612, which in turn is connected to PL region 104. PMC 1602 is configured to program the fabric of PL region 104 through configuration interconnect 1612. Configuration interconnect 1612 is a transport mechanism for programming programmable cells on SoC 100 that is independent of the transport mechanism of NPI 710 used to program other programmable cells on SoC 100 (e.g., slave endpoint circuits).

[0164] As previously described, register block 712 includes registers that are programmed to create a corresponding routing table for NPS 706 . Fig.17A routing table 1700 according to an example is shown. The routing table 1700 packages registers according to a destination identifier. Each data packet received and subsequently sent by the NPS 706 includes a destination identifier, which the routing table 1700 uses to send and route the data packet. For this example, the NPS 706 has four ports (Ports 0 to 3) and eight virtual channels (VCs 0 to 7). The rows of the routing table correspond to the port-virtual channel combination (Port-VC) of the received data packet. The columns of the routing table correspond to the destination identifier (IDy) contained in the received data packet. The entries of the routing table indicate the outgoing ports on which the data packet will be transmitted based on the Port-VC and IDy. In some examples, the entries for a given IDy are packaged in one or more registers of the register block 712. The predefined bits of the one or more registers are entries of the routing table, and the predefined bits correspond to the Port-VC. NPS 706 is configured to receive a data packet, determine the port at which the data packet is received, determine the virtual channel of the data packet, determine a destination identifier contained in the data packet, identify an egress port of NPS 706 based on the receiving port, the virtual channel, and the destination identifier as programmed in registers forming a routing table, and send the data packet on the egress port of NPS 706.

[0165] In this example, based on four ports and eight virtual channels, there are 32 Port-VC combinations, and the entry for each outgoing port is at least two bits based on the four ports. Therefore, in this example, two 32-bit registers are implemented for each IDy. Other examples may implement the registers of the routing table in different ways.

[0166] In some examples, by packing registers based on destination identification, routing tables may be more easily reconfigured when a path is to be changed in a partial reconfiguration without having to reconfigure or disrupt other paths that are not to be reconfigured.

[0167] In other examples, other features may be implemented for the routing table. For example, multiple destination identifiers may be segmented in the routing table, e.g., multiple destination identifiers may be packed into one or more registers to reduce overhead and / or processing of data packets. In such examples, the segmentation may affect the ability to reconfigure a path. For example, if a portion of a path to be preserved during a partial reconfiguration corresponds to an entry in a segment of the routing table, the presence of the path to be preserved may prevent reconfiguration of another path in the same segment.

[0168] Fig.18An example method 1800 for operating a SoC such as the SoC 100 is shown. In block 1802, the NoC 108 is configured. More generally, the 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 the SoC 100 may also be configured during operation 1802. For example, the PL region 104 and / or the DPE array 102 may be configured. As described above, the NoC 108 may be configured via memory mapped transactions through the NPI 710 to write to the register blocks 712 of the NMU 702, NSU 704, and NPS 706. The PL region 104 may be configured via the configuration interconnect 1612. The DPE array 102 may be configured after the NoC 108 is configured and via the SoC interface block 206 of the NoC 108 and the DPE array 102. Configuration of the PL region 104 and / or the DPE array 102 may instantiate one or more applications, or any subset thereof, on the PL region 104 and / or the DPE array 102. The NoC 108 and any other components may be configured under the control of the PMC 1602. For example, the PMC 1602 may obtain the PDI from a memory, and the PDI may include configuration data for the NoC 108, a configuration bitstream for the PL region 104, and / or configuration data for the DPE array 102. The PMC 1602 may then coordinate and control the configuration of the components based on the PDI.

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

[0170] In block 1806, a partial reconfiguration event trigger occurs. The partial reconfiguration event trigger may be usage specific. For example, an application instantiated on PL region 104 and / or DPE array 102, or a subset thereof, may end its task and generate an interrupt to trigger a partial reconfiguration. The interrupt may be transmitted to PMC 1602 via NoC 108, a dedicated interconnect, or another interconnect, and in response to receiving the interrupt, PMC 1602 controls the partial reconfiguration.

[0171] In block 1808, NoC 108 is partially reconfigured. More generally, NoC 108 can be configured as part of a larger partial reconfiguration. Other subsystems of SoC 100 can also be partially reconfigured during block 1808. Circuit components of NoC 108 and any other subsystem instances to be reconfigured during partial reconfiguration are referred to herein as reconfiguration partitions (RPs). Circuit components or regions of RPs can be reconfigured during partial reconfiguration 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. For other subsystems, such as PL regions 104 and DPE arrays 102, various applications can be disabled and / or rewritten, and different applications or any subsets thereof can be instantiated on those subsystems through partial reconfiguration. Partial reconfiguration of NoC 108 and any other subsystems can be performed under the control of PMC 1602. PMC 1602 can obtain PDI from memory, and PDI can include configuration data and / or configuration bitstreams for reconfiguration partitions. PMC 1602 may thereafter coordinate and control the configuration of portions of the circuit components based on the PDI.

[0172] Partial reconfiguration may reconfigure components in the RP without reconfiguring other components outside the RP. Additionally, with respect to the NoC, communications (e.g., as occurs in block 1804) may continue via paths of the NoC that have not been reconfigured (e.g., paths outside the RP). Thus, a subset of the resources of the NoC may be modified while another subset of the resources of the NoC may remain active and undisturbed. Additional details of partial reconfiguration of the NoC 108 are described below with reference to Fig.19 Give a description.

[0173] In block 1810, communication occurs via NoC 108. More generally, SoC 100 operates based on the configuration of SoC 100 with partial reconfiguration. Once the partial reconfiguration is complete, PMC 1602 can enable components to operate and start operation. As previously described, various subsystems on SoC 100 communicate, for example, application data to each other via NoC 108.

[0174] Fig.19 yes Fig.181808 partially reconfigures 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 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 through the NPI 710 to control the NMU 702. The transaction request writes a value to the register block 712 of the NMU 702, which 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 through the NPI 710 to determine whether any NMU 702 still has a pending packet. If an NMU 702 still has a pending packet, an error is generated. If no NMU 702 has a pending packet, the PMC 1602 disables or stops the operation of the NMU 702 via a transaction request through the NPI 710.

[0175] In block 1904, the PMC 1602 controls the NSU 704 in the RP to be reconfigured. The PMC 1602 obtains the address or identification of the NSU 704 in the RP to be reconfigured from the PDI. The PMC 1602 then sends a transaction request to the register block 712 of the NSU 704 in the RP through the NPI 710 to control the NSU 704. The transaction request writes a value to the register block 712 of the NSU 704, which causes the NSU 704 to then refuse to receive packets from the NoC 108 and clear any pending packets. The PMC 1602 may then wait for 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 through the NPI 710 to determine whether any NSU 704 still has pending packets. If the NSU 704 still has pending packets, an error is generated. If no NSU 704 has a pending packet, the PMC 1602 disables or stops the operation of the NSU 704 via a transaction request through the NPI 710 .

[0176] By controlling the NMU 702 and the NSU 704 as described in conjunction with blocks 1902 and 1904, traffic on paths in the NoC 108 in the RP is stalled. After traffic is stalled, 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 contained in the PDI. As previously described, the PMC 1602 reconfigures the NPS 706, the NMU 702, and the NSU 704 via memory-mapped transactions through the NPI 710. Traffic can continue on some paths that do not enter or exit (or are independent of) the NoC 108 in the RP during reconfiguration. Since the NPS 706, NMU 702, and NSU 704 that are not part of the RP are not reconfigured and are not affected by the reconfiguration, the paths between these NPS 706, NMU 702, and NSU 704 may continue to operate during the reconfiguration of the NPS 706, NMU 702, and NSU 704 in the RP.

[0177] In block 1908, the PMC 1602 enables the NSU 704 that has been reconfigured to be in use. 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 be in use. After the reconfiguration, the NMU 702 that was disabled or stopped before the reconfiguration is enabled and enters normal operation. Fig.18 In block 1810, communication is allowed via the NPS 706, NMU 702, and NSU 704 in the reconfigured RP.

[0178] Fig. 20 Another example implementation of SoC 100 is shown. Fig. 20 1 shows a logical diagram of various components and / or subsystems of SoC 100. Fig. 20 In the example of , SoC 100 includes DPE array 102, PL 104, PS 106, and NoC 108. SoC 100 also includes PMC 1602, one or more hardwired circuit blocks 2012, 2018, 2024, 2034, and 2036, fabric interconnect 2038, and configuration interconnect 1612.

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

[0180] PMC 1602 operates as a root of trust for SoC 100. Fig. 20 1602, the PMC processing unit 2004 may include one or more processors capable of executing program code. The PMC 1602 also includes control circuitry 2006, memory 2008, and one or more interfaces 2010. The PMC processing unit 2004 is capable of executing control software from the memory 2008, which may include RAM and / or ROM. The PMC processing unit 2004 is capable of performing various security and safety functions within the SoC 100. For example, the PMC processing unit 2004 is capable of configuring interconnect 1612, fabric interconnect 2038, and / or NoC 108 (e.g., as combined with Fig.10 Once initially configured as described above, the SoC 100 is booted up, a partial reconfiguration of the SoC 100 is performed, the DPE array 102 is configured, the PL region 104 is configured, the PS 106 is configured, and the NoC 108 is configured.

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

[0182] 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, 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 cryptographic 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 Fig. 20 Fewer or more hard-wired circuit blocks as shown in .

[0183] PS106 is connected to NoC 108, fabric interconnect 2038, and configuration interconnect 1612. As shown, PS106 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. PS106 may also include PS memory 2048, which may include a level 2 cache and a system memory management unit (SMMU). PS106 may also include a coherent interconnect 2050, a snoop control unit (SCU, not shown), and one or more peripherals 2052. Coherent interconnect 2050 and SCU enable other entities to read and / or write to level 2 cache memory. For example, RPU 2042 and main circuit blocks in PL 104 can snoop level 2 cache memory. The peripheral device 2052 may include one or more different I / O interfaces, including but not limited to a universal serial bus (USB), Ethernet, a universal asynchronous receiver / transmitter (UART), a controller area network flexible data-rate (CANFD), a serial peripheral interface, a display port (DisplayPort), a high-definition multimedia interface (HDMI), an I2C interface, and a serial ATA interface.

[0184] As previously described, the PL region 104 may include LUTs 2054, BRAMs 2056, URAMs 2058, and DSPs 2060 interconnected via the fabric interconnect 2038. As shown, the PL region 104 is connected to the NoC 108, the fabric interconnect 2038, and the configuration interconnect 1612. The DPE array 102 may include a plurality of interconnected hardwired and programmable DPEs 204. The DPEs 204 are connected to the NoC 108, the fabric interconnect 2038, and the configuration interconnect 1612 via the SoC interface block 206.

[0185] exist Fig. 20 In the example of the present invention, NoC 108 can also be connected or coupled to another NoC located in another die and / or IC. For example, in the case where SoC 100 is formed by multiple dies interconnected by an interposer or other carrier, NoC 108 can be coupled to NoCs in other dies through the interposer or carrier.

[0186] exist Fig. 20 In the example of the embodiment of the present invention, CCIX 2026 or other multi-chip cache coherence equivalent can also be connected or coupled to another CCIX located in another die and / or IC. For example, in the case where SoC 100 is formed by multiple SoCs interconnected by a multi-chip cache coherence protocol, CCIX 2026 can be coupled through GT 2032 in other SoCs.

[0187] Fig. 20 100. Various structural and functional aspects of a programmable device platform implemented by SoC 100 are shown. In this regard, SoC 100 provides a flexible platform in which different functions can be remapped from one subsystem to another. For example, specific functions can be remapped from DPE array 102 to PL region 104, from PL region 104 to DPE array 102, from DPE array 102 to hardwired circuit blocks, from hardwired circuit blocks to DPE array 102, from PL region 104 to hardwired circuit blocks, and / or from hardwired circuit blocks to PL region 104. Such remapping can be performed without disrupting user applications in other portions of SoC 100.

[0188] Although SoC 100 is primarily described in terms of 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 "compute engines," "hardware acceleration engines," "memory resources," "external interfaces," and "pervasive interconnects" that extend to the different subsystems described.

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

[0190] The term "hardware acceleration engine" as defined herein refers to a special purpose or dedicated circuit that can be implemented as a hardwired circuit block 110 or a circuit block in the PL region 104. A hardware acceleration engine is also referred to as a "Group B" type circuit block. Examples of hardware acceleration engines include, but are not limited to, DPE, ADC, DAC, DSP, video codec, cryptographic engine, and custom circuit blocks implemented in the PL region 104.

[0191] In the context of SoC 100, the term "memory resource" includes any memory structure available in PS 106 and / or PL region 104. Memory resources are also referred to as "group C" type circuit blocks. For example, memory resources can include on-chip memory (OCM) and cache memory (e.g., illustrated as PS memory 2048) available in PS 106 and / or LUTs (e.g., LUTRAM), URAM, and / or BRAM available in PL region 104. Memory resources can also include off-chip or external memory, such as DDR, HBM, or other memory that can be accessed using a hardwired memory controller and / or a custom memory controller implemented in PL region 104.

[0192] With respect to SoC 100, the term "external interface" refers to controllers for industry standard protocols and for communicating with circuits and / or systems located outside the chip. External interfaces are also referred to as "Group D" type circuit blocks. Examples of external interfaces of SoC 100 include, but are not limited to, CCIX 2026, PCIe 2028, MAC 2030, Ethernet (in PS 106), and custom controllers for standard and / or non-standard protocols implemented in PL region 104.

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

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

[0195] NoC 108 can implement data paths and message passing between compute engines, hardware acceleration engines, memory resources, external interfaces, and coherent interconnect 2050 for universal data and message passing paths between any and all such components.

[0196] PL region 104 can implement customized data paths for user-defined, custom, hardware accelerator engines, peripherals, and / or other computational blocks that may be implemented in PL region 104 .

[0197] Fig. 20 The use of universal configuration and interrupt paths for static and dynamic configuration, control, and status of components in groups A, B, C, D, and E is shown. Universal configuration can be achieved by using PMC 1602 to access a universal set of configuration, control, and status registers (CCSRs) on a heterogeneous set of components (e.g., in various subsystems) of SoC 100, whether the components perform the same or different functions. For example, Fig.23 It is shown that components, whether performing the same function or different functions and implemented in different subsystems of SoC 100, may have commonly configurable interrupt status registers, error control and status registers, and / or performance control and status registers.

[0198] The general configuration described for SoC 100 can be used to implement higher level complex or macro functions. One example of a macro function that can be enabled is DMA data movement between components on SoC 100. Another type of macro function is task pipelining. A task pipeline can be an acceleration pipeline stage (e.g., a hardwired circuit block in the PL or a user-defined accelerator) followed by a computational pipeline stage (e.g., processing performed by a compute device in a PS or DPE of a DPE array).

[0199] In one example, universal configuration of DMA type megafunctions and pipelined task execution type megafunctions may be implemented in SoC 100 by using common descriptor definitions. The common descriptor definitions are universally interpreted among a set of heterogeneous components of SoC 100 (e.g., whether circuits in the PL, one or more DPEs, PS processors, or hardwired circuit blocks).

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

[0201] Fig.21 An example implementation of PMC 1602 is shown. PMC 1602 is a hardwired circuit block on SoC 100. Fig.21 In the example, the PMC 1602 includes a PMC processing unit 2004 (separate and distinct from the PS 106). The PMC processing unit 2004 may include a physically 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 example implementation, the PMC 1602 is on a separate power domain (e.g., having a separate and independent power supply) independent of the PL 104, the DPE array 102, and / or the PS 106.

[0202] In one aspect, the PMC processing unit 2004 includes a plurality of processors 2112 that operate in lockstep using appropriate voting circuits. In another aspect, the PMC processing unit 2004 includes a plurality of processors 2112, wherein one or more processors 2112 that can operate in lockstep are dedicated to accessing the RAM 2208 (e.g., executing the code stored in the RAM 2208), and one or more other processors 2112 that can also operate in lockstep are dedicated to accessing the ROM 2206 (e.g., executing the code stored in the ROM 2206).

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

[0204] In any case, the ROM 2106 and RAM 2108 can only be accessed by the processor 2112. On the other hand, each processor 2112 has a ROM 2106 and a RAM 2108, so that each processor 2112 has an independent and dedicated ROM 2106 and an independent and dedicated RAM 2108. The RAM 2108 can be protected with an error correction coding (ECC) circuit. The processor 2112 can be used to power on and configure the SoC 100 by executing the code stored in the ROM 2106 and executing the firmware loaded into the RAM 2108 from the main boot device by executing the code stored in the ROM 2106. The local register 2114 is a configuration register for the PMC processing unit 2004 and can only be accessed by the PMC processing unit 2004.

[0205] After startup, processor 2112 can perform a variety of different functions using the various components included in PMC 1602. For example, processor 2112 can perform power management, voltage and temperature monitoring, safety and security event response, and similar functions for SoC 100. As shown, processor 2112 can receive interrupts and wake-up signals for these purposes.

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

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

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

[0209] The security accelerator 2132 may include an AES-GCM circuit block 2146, an elliptic curve digital signature algorithm / Rivest-Shamir-Adleman (ECDSA / RSA) circuit block 2148, a secure hash algorithm 3 / 394 (SHA-3 / 394) circuit block 2150, a true random number generator (TRNG) circuit 2152, and a battery-backed RAM (BBRAM) 2154 circuit block. The AES-GCM circuit block 2146 is a symmetric key encryption engine capable of performing encryption and / or decryption. The ECDSA / RSA circuit block 2148 is a public key cryptographic engine capable of performing authentication. The SHA-3 / 394 circuit block 2150 is capable of performing secure hash operations. The TRNG circuit 2152 is capable of generating random numbers.

[0210] The analog system 2134 may include: a system monitor 2156 capable of monitoring voltage and temperature from one or more remote system monitor circuits that may be located in various locations and / or subsystems around the SoC 100; a system oscillator 2158 capable of generating a clock signal for the PMC 1602; an electronic fuse controller 2160 capable of maintaining and / or managing electronic fuse (e-fuse) circuits on the SoC 100; a bandgap circuit 2162 capable of generating one or more reference voltages for analog devices in the SoC 100 (e.g., a DAC and / or ADC that may be implemented as hardwired and programmable circuit blocks on the SoC 100); one or more phase-locked loops (PLLs) 2164 capable of generating clock signals for the PMC 1602, NoC 108, NPI 710, and PS 106; and a power-on reset (POR) circuit 2166.

[0211] The electronic fuse controller 2160 is capable of reading the electronic fuse circuit. The electronic fuse circuit (e.g., electronic fuse memory element) can be used to store design information such as device DNA and security keys. The electronic fuse circuit can also control functions such as disabling JTAG 2168.

[0212] The RTC 2136 is a clock circuit capable of running on a high-precision crystal oscillator. The RTC 2136 can be used to measure the current time and generate alarms for various operating systems and device management functions within the SoC 100 at specific times. The power management and reset circuit 2138 implements the logic and interfaces necessary for controlling power islands, power domains, and resetting other circuit blocks on the SoC 100. The power management and reset circuit 2138 is further connected to the PS106 to control the power island implemented in the PS106. The error management circuit 2140 is capable of receiving, recording, and responding to errors from other subsystems within the SoC 100. The debug packet controller 2142 is a packet controller for a high-speed debug port (HSDP) for processing packets passed to it from other interfaces on the SoC 100 (e.g., a high-speed serial interface and / or a PCIe block).

[0213] The CFU 2144 can perform configuration and readback of configuration data provided or loaded into configuration registers of the PL 104. For example, the PMC 1602 transmits a PL bitstream (eg, configuration data) through the CFU 2144 to configure the PL 104.

[0214] SoC 100 may be implemented to include several major power domains controlled by power management and reset circuitry 2138. The power domains include: a low power domain (which includes the RPU and OCM); a full power domain (which includes the APU and high-speed I / O); a NoC and system double data rate (DDR) power domain; and a PL power domain.

[0215] Other power domains may be created within SoC 100 that may be controlled by the circuit board on which SoC 100 is disposed. These other power domains may include, but are not limited to, further I / O power domains, a battery power domain, a PMC power domain (e.g., where the PMC has its own power domain and power supply), a PL RAM power domain, and a DPE array power domain.

[0216] Fig. 22 An example arrangement of the processor 2112 of the PMC processing unit 2004 is shown. Fig. 22 In the example of , processor 2112 is arranged in a triple redundant architecture. In one example implementation, processor 2112 is implemented as a hardwired Microblaze processor, but other types of processors may also be used.

[0217] Each processor 2112 is connected to a triple modular redundant (TMR) manager 2202 and an I / O module 2204. TMR managers 2202-1, 2202-2, and 2202-3 are interconnected. I / O modules 2204-1, 2204-2, and 2204-3 are also interconnected. Voting circuit 2210-1 is coupled to each I / O module 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 is capable of managing the state of a corresponding one of the processors 2112, including fault detection and error recovery.

[0218] Each voter circuit 2210 is capable of comparing received input signals. Each voter circuit 2210 is capable of detecting a mismatch in the received signal and accepting the majority result and continuing operation. The particular processor 2112 that provided the mismatch (e.g., the lost result) is placed in a reset state, while the other two remaining processors 2112 continue to operate in a lockstep manner. If all three processors 2112 do not match, each processor 2112 is reset.

[0219] Each processor 2112 is also connected to RAM control circuit 2206 and RAM control circuit 2208. RAM control circuit 2206 is connected to voter circuit 2210, which is connected to instruction RAM, such as RAM 2118. RAM control circuit 2208 is connected to voter circuit 2210-5, which is connected to data RAM, such as RAM 2118. As shown, RAM 2118 and voter circuits 2110-4 and 2110-5 are part of the ECC domain. Fig. 22 In the example of FIG. 1 , each RAM control circuit 2206 for the instruction RAM (e.g., 2206-1, 2206-2, and 2206-3) is connected to a voter circuit 2210-3. Each of the processors 2112-1, 2112-2, and 2112-3 is connected to the voting 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.

[0220] Fig. 22 An example of triple modular redundancy is shown, where a processor 2112 is dedicated to accessing RAM 2118. As previously described, a similar architecture may be used for ROM-dedicated processors within the PMC 1602. In another example, fewer than three processors 2112 may be used, with one or two processors (lock-step) 2112 dedicated to executing code stored in ROM 2106 and one or two other processors (lock-step) 2112 dedicated to executing firmware stored in RAM 2108.

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

[0222] Fig.23 Further structural and functional aspects of SoC 100 are shown. Fig.23 An example configuration is shown in which different types of computing engines and hardware acceleration engines are implemented across different subsystems of the SoC 100. Fig.23 In the example of FIG. 1 , the compute engines, hardware acceleration engines, memory resources, and external interfaces are implemented using standardized or common interfaces of other components and / or subsystems in SoC 100. These common interfaces allow the illustrated components to be coupled to global interconnect resources on SoC 100, which in this example is NoC 108.

[0223] exist Fig.23 2048) is coupled to a coherent interconnect 2050. The coherent interconnect 2050 is further connected to a memory 2304. The memory 2304 can be a memory located in the PL region 104, an external memory, or a memory within the PS 106 that can be accessed 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.

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

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

[0226] exist Fig.23 In the example of SoC 100, fixed peripheral interface 2312, user defined peripheral interface 2314, user defined accelerator 2320, DPE 204, DSP 2334, and cryptographic engine (crypto) 2336 utilize common interfaces despite performing different operations and being implemented across different subsystems. For example, each of the mentioned 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. In this way, although the various components belong to different groups as described above and / or are implemented across different subsystems of SoC 100, each component may have the same or common interface. The common interface supports remapping of functionality from one subsystem to another within SoC 100 because the signaling of the functional blocks remains unchanged despite moving from PL region 104 to a hardwired circuit block or DPE, etc.

[0227] The data path interface 2322 is an interface circuit capable of connecting to a global interconnect, in this example, the NoC 108. For example, the data path interface 2322 can provide a standard interface for connecting to the NMU and / or NSU of the NoC 108. The memory management unit (MMU) interface 2324 can perform address translation between virtual addresses and physical addresses within the SoC 100. For example, the MMU interface 2324 can access page tables stored in memory and / or maintain a local cached copy of such tables to perform address translation, which can be used for transactions received and / or sent through the data path interface 2322. The MMU interface 2324 can also enforce read / write permissions and authorizations to prevent circuit blocks containing the MMU interface 2324 from performing unauthorized reads and / or writes to memory addresses.

[0228] The interrupt interface 2326 implements standard interrupts, or user-defined and / or unique interrupts for a circuit block. In some cases, interrupts of two or more circuit blocks may be shared, for example, when the circuit blocks are located in the same partition within the SoC 100. In this case, the destination of the interrupt may be shared between the circuit blocks. Further descriptions related to partitions within the SoC 100 will be described in more detail with reference to the remaining figures.

[0229] DMA 2328 can perform data transfers through NoC 108 and data path interface 2322. Performance monitor 2330 can be coupled to other circuits and / or interfaces throughout SoC 100. Performance monitor 2330 can measure quantities such as bandwidth and latency of the circuit block to which performance monitor 2330 belongs. In one aspect, performance monitor 2330 can filter and measure data signals flowing into and out of the circuit block to measure the number of transactions or other quantities sent to a specific address range within a fixed time period. Performance monitor 2330 can transmit any measurement data to a programming destination through NoC 108 (e.g., PS106 or PMC 1602). Trace / debug interface 2332 can send and receive trace and / or debug data on NoC 108 for receipt by PMC 1602. For example, debug / trace interface can receive commands and send trace / debug data to debug package controller 2142 in PMC 1602.

[0230] Configuration interface 2334 is connected to NoC 108 and / or to other interconnects (e.g., configuration interconnect 1612 or fabric interconnect 2038), depending on the particular subsystem in which the circuit block is located. For example, PMC 1602 can configure the circuit block by providing configuration data to configuration interface 2334. For example, configuration interface 2334 allows PMC 1602 to read and / or write configuration registers (not shown) located in the circuit block.

[0231] On the other hand, different circuit blocks may include a combination of a small portion 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. On the one hand, interrupt interface 2326 is configured to receive and / or generate interrupts. In an example implementation, interrupt interface 2326 is implemented as a memory mapped interface. Interrupts can be received from other circuit blocks connected to interrupt interface 2326 and / or provided to other circuits connected to interrupt interface 2326. Interrupt signaling can be routed through NoC 108 to a specific hardwired circuit block 110, PS 106, or other such hardwired circuit blocks. Fig.23 any other circuit blocks shown.

[0232] In an illustrative example, the interrupt interface 2326 is capable of generating and / or receiving a doorbell interrupt. A doorbell interrupt is an interrupt that crosses from one domain (e.g., a partition) to another domain within the SoC 100. For example, by two partitions being isolated from each other, one or more interrupts may be allowed to pass into and / or from a partition to the other partition and / or the PMC 1602 to transmit a message or trigger / start a predetermined action. The doorbell interrupt may cross from one domain or partition to another domain or partition through the NoC 108.

[0233] In one example, a PCIe controller may be implemented in the PL 104. The PCIe controller is coupled to the DDR memory through the NoC 108. In this example, the PCIe controller may use a common interface and therefore include an interrupt interface 2326. A host system in communication with the SoC 100 may generate new jobs for the PCIe controller to execute and submit the new jobs (e.g., memory accesses) to the PCIe controller in the PL 104 of the SoC 100. For example, the host system may cause an interrupt to be generated to the PCIe controller, causing the PCIe controller to program one or more DMAs to perform the memory accesses.

[0234] Fig.23 The modularization of the functions and services of the components in groups A, B, and C of SoC 100 is shown. The components can maintain this modularity even when they provide different functions from each other. For example, the components implemented in PL area 104 are modularized so that the PL components have standard interfaces to the components in groups D, E, and F. Each PL component can be deployed in the service of any of the other functions implemented by the components in groups A, B, or C. Each component in group A, B, or C also has communication and data paths to another PL component or different components in groups A, B, and C.

[0235] In another example of modularity implemented using SoC 100, a particular functionality deployed as a PL component may be deployed in other parts of PL 104 to implement multiple concurrent instances of the same functionality. A common interface provides for common interrupt, address translation, debug, and performance monitoring schemes deployed across components in SoC 100 (whether in group A, B, or C). While providing a common interface, components implemented in group A, B, or C may alternatively be implemented with a unique or customized set of interrupt, address translation, debug, and performance monitoring schemes.

[0236] Fig.24 Further structural and functional aspects of SoC 100 are described. Fig.24 In the example of SoC 100, SoC 100 includes various additional circuits that can implement security features. These additional circuits can be used to create different and independent partitions in SoC 100 and firewalls between different partitions. Each partition can execute its own application in it. Fig.24 In the example of , multiple system management identifier (SMID) circuits 2402 and programmable protection circuits (PPC) 2418 are included.

[0237] The processor 2112, RPU 2042, APU 2044, other agents 2408, and I / O devices 2412 are connected to the local interconnect 2416 via the SMID circuit 2402. The I / O devices 2412 are further connected to the local interconnect 2416 via the SMMU 1416. 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.

[0238] Each SMID circuit 2402 can be programmed to use a specific SMID. During configuration, the PMC 1602 can assign an SMID and write it to the configuration registers in each of the various SMID circuits 2402 or at least those SMID circuits 2402 that are being used. The SMID circuits 2402 for each of the various components (e.g., processor 2112, RPU 2042, APU 2044, other subjects 2408, I / O devices 2412, PL 104, and / or DPE array 102) can attach or insert the SMID into transactions initiated by the various components. Thus, for example, each transaction originating from the processor 2112 will include the SMID in the transaction, which has been inserted by the SMID 2402-2 as assigned by the PMC 1602. Similarly, each transaction originating from the RPU 2042 will have the SMID inserted by the SMID 2402-2 as assigned by the PMC 1602. In this way, the source of a transaction from various components in SoC 100 can be identified by the specific SMID within the transaction. The SMID assigned to SMID circuit 2402 can be unique throughout SoC 100.

[0239] The PPC 2418 can protect access to slave circuits within the SoC 100. Each of the PPCs 2418 can check the specific SMID of each transaction entering a circuit block. Each of the PPCs 2418 can check whether the SMID of the transaction is an allowed SMID, for example, whether it is on the list of allowed SMIDs maintained by the corresponding PPC 2418. Each of the PPCs 2418 can also check that the address or address range to be accessed by the transaction is an address range that the SMID has access to. In this regard, the PPCs 2418 can enforce access privileges by ensuring that only authorized circuit blocks (based on the SMID) can access other circuit blocks and further only access those address ranges allowed for a specific SMID.

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

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

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

[0243] exist Fig.24In the example of , the specific location of SMID circuit 2402 and PPC 2418 is shown for the purpose of illustration. SMID circuit 2402 and PPC 2418 can be implemented in a circuit block as part of an interface, in a signal path between circuit blocks, or the like. SMID circuit 2402 and PPC 2418 can be implemented in different physical locations that provide logical equivalence. For example, multiple blocks can have an aggregated intermediary connected to a global path such as NoC 108. In that case, the aggregated intermediary can include SMID circuit 2402 and / or PPC 2418 as appropriate, rather than each individual circuit block aggregated by the intermediary. This may be correct for both the entry point and the exit point in NoC 108.

[0244] exist Fig.24 In the example of FIG. 1 , local interconnect 2416 may represent a physical circuit block capable of incorporating multiple logical functions. In another example, NoC 108 may be implemented to include one or more SMID attachment points. In other words, SMID circuits 2402 (e.g., 2402-8 and 2402-9) may be implemented in NoC 108 as opposed to within PL region 104 and / or DPE array 102. SMID circuits 2402 may be implemented in NoC 108 at an entry point, an exit point, or a combination of an entry and exit point.

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

[0246] For example, processor 2112, RPU 2042, and APU 2044 each have SMID circuit 2402. Each of processor 2112, RPU 2042, and APU 2044 can initiate transactions 1602 using a unique SMID assigned to it according to the configuration performed by the PMC. Transactions flow through NoC 108 and carry their respective SMIDs to their destinations. Similarly, transactions from PL region 104 or DPE array 102 each have an SMID inserted by SMID 2402-6 or SMID 2402-7, as appropriate. Transactions from PL region 104 and DPE array 102 carry the SMID to the destination.

[0247] As an illustrative example, consider the case where a circuit block implemented in PL region 104 initiates transactions A, B, and C. Each of transactions A, B, and C carries an SMID assigned by SMID circuit 2402-6 (or SMID circuit 2402-8 if implemented in NoC 108). If transaction A is directed to DDR memory controller 2428, NoC 108 serves as both an ingress path and an egress path. PPC 2418-6 can check whether the circuit block in PL region 104 has permission to access DDR memory controller 2428 (e.g., based on the SMID) and whether it has permission to access a specific memory address specified by the transaction. PPC 2418-6 can reject transaction A when the source of transaction A does not have the appropriate permissions.

[0248] Transaction B may be directed to a PMC slave 2420, while transaction C is directed to an RTP slave 2422. In the case of transaction B, PPC 2418-1 checks whether the source of transaction B (based on the SMID) is allowed to access the specific PMC slave 2420 specified by the transaction. In the case of transaction C, PPC 2418-3 checks whether the source of transaction C (based on the SMID) is allowed to access the specific RTP slave 2422 specified by the transaction. Each PPC 2418-1 and PPC 2418-3 allows or rejects the corresponding transaction based on the SMID and the specific target of the transaction (e.g., a specific PMC slave 2420 or a specific RTP slave 2422). Thus, the logical functionality of the SMID attachment and the exit check (e.g., performed by PPU 2418) may be physically distributed within SoC 100.

[0249] In another example, the I / O device 2412 may be an external flash device from which the 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 storing boot code, or registers used to program or configure other blocks in the SoC 100, such as registers used to configure the PL region 104 and / or the DPE array 102. In another example, the boot image may be program code from which the processor 2112 will boot. In this example, various gateways, such as the PPU 2418 and the SMID circuit 2402 have been configured by the PMC 1602 to only allow the boot image to be loaded into one specific PMC slave 2420. Therefore, the I / O device 2412 is only allowed to write the contents of the image file to the specified (e.g., first) PMC slave 2420 according to the provisions of the PPU 2418-1. The I / O device 2412 is not allowed to read or write other PMC slaves 2420.

[0250] Continuing with this example, the processor 2112 is authorized to load the boot image through an authentication scheme (described in more detail herein). For example, the PPC 2418-1 can be configured to allow the processor 2112 to read the PMC slave 2420 in which the boot image is stored by the I / O device 2412 (with only write access rights) based on the SMID corresponding to the SMID circuit 2402-1. The processor 2112 can only read the boot image and decrypt the boot image into a second PMC slave 2420, such as a working memory of the processor 2112. The processor 2112 can then use the decrypted boot image stored in the second PMC slave 2420 to program other configuration registers, for example, by writing to a third PMC slave 2420. The third PMC slave 2420 can be a configuration register for the PL region 104 or a configuration register for other circuit blocks.

[0251] On the other hand, the RPU 2042 may have a local interconnect that is separate from the PMC 1602 and / or other processors (e.g., APU 2044) of the PS 106. An RPU 2042 suitable for real-time operation may operate on the previously described low power domain and therefore have a local interconnect that is separate from the local interconnect of the PMC 1602 and / or APU 2044. This allows the RPU 2042 to react quickly to different events, such as real-time sensor data that may be received and / or processed by the RPU 2042. Fig.25 An example implementation of a PPC 2418 is shown. The PPC 2418 includes a SMID check circuit 2502, an address range check circuit 2504, and a configuration register 2506.

[0252] SMID check circuit 2502 is capable of checking the SMID of a received transaction. SMID check circuit 2502 determines the SMID in the received transaction and compares the SMID to a list of allowed SMIDs specified in configuration register 2506. Address range check circuit 2504 determines a specific address to be accessed in a destination specified by a transaction. Address range check circuit 2504 checks whether the address specified in the received transaction is within the allowed address set or address range of the SMID of the transaction per configuration register 2506.

[0253] The PPC 2418 can disallow (e.g., reject) any transaction that does not satisfy the checks performed by the SMID check circuit 2502 and the address range check circuit 2504. The PPC 2418 can also generate an interrupt signal in response to determining that a received transaction is rejected based on the checks performed by the SMID check circuit 2502 and / or the address range check circuit 2504.

[0254] Fig.26An example method 2600 of booting the SoC 100 is shown. The method 2600 may be performed to implement an application within the SoC 100 that utilizes the various subsystems described herein.

[0255] In block 2602, hardwired logic within SoC 100 performs a power-on reset sequence. In one aspect, the hardwired logic is combined with Fig.21 The POR circuit 2166 described. The power reset sequence refers to the initial operation performed after the SoC 100 is powered. Typically, the power reset sequence performed by the SoC 100 performs initial steps before handing control to the processor of the PMC 1602 to execute the BootROM code. The power reset sequence may include analog components that detect whether the voltage source is powered and qualify the power reset de-assertion. In addition, a boot mode pin that specifies the boot mode for the SoC 100 may be captured. The electronic fuse controller 2160 may read and cache electronic fuse bits. A state clearing operation is performed on the PMC 1602. The POR circuit 2166 is capable of authenticating the BootROM. For example, the SHA-3 / 384 circuit block 2150 of the PMC 1602 may be used to authenticate the BootROM. The end of the power reset releases the rest of the PMC 1602 from reset.

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

[0257] In block 2608, the PMC 1602 performs a BootROM execution phase. The BootROM execution phase may be performed by one or more processors 2112 of the PMC 1602. For example, the BootROM execution phase may be performed by a ROM-dedicated processor 2112 of the PMC 1602. In one aspect, the BootROM execution phase is uninterruptible. In block 2608, the processor 2112 clears the PMC shared RAM 2118. The processor 2112 initializes the system monitor 2156 and checks the voltage therein. The processor 2112 initializes the PLL 2164. The processor 2112 tests the PMC RAM 2118. The processor 2112 further disables (powers off) a power island that is disabled due to an electronic fuse based on the electronic fuse data read by the electronic fuse controller 2160.

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

[0259] In block 2614, PMC 1602 performs boot header / authentication certificate processing. Typically, processor 2112 executes BootROM code, loads boot header from boot source, and verifies boot header. Processor 2112 is capable of authenticating and decrypting (if necessary) the main PMC firmware. Processor 2112 loads boot header and authentication certificate from external boot device into PMC shared RAM 2118. Processor 2112 is capable of determining how the remainder of the PDI image is authenticated, decrypted when necessary, and interpreted based on the boot header. The boot header may include an initialization vector used with a device key and a PUF encryption black key. The authentication certificate may include an ECDSA / RSA primary public key and a secondary public key. The primary key is used to verify the secondary public key and for verification in subsequent stages.

[0260] In block 2616, processor 2112 determines whether an error condition has occurred. If so, method 2600 continues to block 2618 where SoC 100 is locked, for example, an interrupt is enabled.

[0261] In block 2620, the processor 2112 can load, authenticate and decrypt the programming partition of the PDI when executing the BootROM. In block 2622, the processor 2112 determines whether an error condition occurs. If so, the method 2600 continues to block 2624, where the SoC 100 is locked, for example, an interrupt is enabled.

[0262] In block 2626, processor 2112 executes the platform loader and manager level. In one aspect, RAM dedicated processor 2112 can execute the platform loader and manager level. According to the instructions contained in the boot header, processor 2112 can perform any of a variety of operations. For example, in block 2628, processor 2112 can execute the PS boot loader level. Processor 2112 can load PS boot code from an external source, verify the PS boot code, and copy the PS boot code to the OCM in PS 106 for execution by the PS processor.

[0263] In block 2630, processor 2112 can configure the PL. For example, the processor can 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).

[0264] In block 2632, the processor 2112 can configure the DPE array. The processor 2112 can load the DPE array programming segments (e.g., a configuration image of the DPE array) from an external source, authenticate the DPE array programming segments, and write the DPE programming segments to the appropriate destinations (particularly a DPE in the DPE array) through the NPI 710 and the NoC 108.

[0265] In block 2634, processor 2112 can configure one or more circuit blocks. The circuit blocks can be hardwired circuit blocks or circuit blocks implemented in PL 104 that require configuration data, such as programming configuration registers therein. Processor 2112 can load register programming segments from an external source, authenticate register programming, and write register programming to a destination through NPI 710 and NoC 108. As illustrative and non-limiting examples, processor 2112 can write register data to SMID circuit block 2402, PPC 2418, and / or other hardwired circuit blocks (e.g., cryptographic circuit blocks, ADC, DAC, etc.).

[0266] In block 2636, processor 2112 can configure NoC 108. As an illustrative and non-limiting example, processor 2112 can be configured as in conjunction with Fig.11 The NoC 108 is configured as described. In block 2638, the processor 2112 can configure any memory. For example, the processor 2112 can write configuration data to any memory controller and / or interface to external memory accessible by the SoC 100.

[0267] The various operations performed by processor 2112 during the platform loader and manager phases may or may not be independent of each other. In some cases, the operations may be performed in a synchronized manner. For example, although not explicitly described, an image of NPI 710 may be loaded before PL 104 can be configured. The particular ordering of sub-blocks within block 2626 is not intended to limit the arrangements of the present invention.

[0268] Fig.26 The PMC 1602 is illustrated as being responsible for configuring the PS 106, the PL 104, the DPE array 102, and selected other circuit blocks. In one or more other embodiments, for example, based on a boot header, the PMC 1602 is capable of configuring the PS 106 with program code that allows the PS 106 to configure the PL 104 and the DPE array 102. In that case, in response to configuring the PS in block 2628, blocks 2630, 2632, and 2634 may be executed by the PS 106 instead of the processor 2112 in the PMC 1602.

[0269] As method 2600 progresses, each level in the progression enables or disables authorization for a component to access other components in SoC 100. Fig.26 The process described is hierarchical, where authorization to increasingly narrower subsets of subsystems and / or components in SoC 100 may be denied or granted. Fig.26The layered aspects of the illustrated techniques can support configuration of the SoC 100 for a Field Programmable Gate Array (FPGA) as a Service (FPGA-as-a-Service) or "FaaS" processing environment. For example, the PMC 1602 can create multiple partitions in the SoC 100. When creating a partition, the PMC 1602 can map many logical destinations to one physical destination (e.g., to multiple circuit blocks implemented in the PL 104, multiple independent DPE clusters implemented in the DPE array 102, etc.). Similarly, the PMC 1602 can create partitions in the SoC 100 where many physical destinations are mapped to one logical destination.

[0270] 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. Since the SoC 100 can be configured, reconfigured, and / or partially reconfigured across different subsystems, the mapping of permissions and authorizations to create partitions and enforce firewalls between partitions can be dynamically modified.

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

[0272] The next image 2710 of the PDI 2700 may include a number of different blocks, shown as block 0, block 1, through block N. The various blocks included in the next image 2710 may be specified in the security header 2712. In general, each block 0-N corresponds to the PS boot code, the configuration bitstream for the PL, the DPE array programming segment, and the Fig.26 The register programming data referenced in blocks 2628, 2630, 2632, and 2634 of FIG. In certain embodiments, the blocks may be organized by application (e.g., partition), with multiple blocks representing one application for implementation in a first partition, and a different group of blocks representing another application that may be implemented in a second partition concurrently with the first application, or in a first partition after the first application completes execution.

[0273] Partial reconfiguration of one or more portions of SoC 100 may be performed by PMC 1602, which selectively executes different ones of blocks 2628-2638 over time and in response to certain conditions using available and / or different blocks or groups of blocks contained in PDI 2700 (or in a different PDI). Partial reconfiguration of SoC 100 facilitates stratification of physical components in SoC 100, or logical subsets thereof, into subsets or as a whole. For example, PMC 1602 can control isolation of partitions, unloading (and loading) of software drivers (as appropriate for modified applications), transfer of programming images from any secondary boot interface, and image verification and integrity checks before programming is complete.

[0274] Fig.28 Another example of a SoC 100 implementing different partitions is shown. Fig.28 For example, various different images may be sequentially loaded into SoC 100. These different images implement different partitions therein and are illustrative of a FaaS processing environment, wherein a platform provider implements a "shell" design in SoC 100 to facilitate communication with SoC 100 within a larger system and to facilitate simultaneous implementation of user applications in SoC 100 corresponding to more than one different user (e.g., a user of a host processing system coupled to SoC 100 via a PCIe link).

[0275] exist Fig.28 In the example of FIG. 2 , a system 2800 including a host data processing system 2802 is shown. The host data processing system 2802 can be implemented as a computer system such as a server. The host data processing system 2802 includes multiple different CPUs that can be assigned to different users (e.g., different processes, different applications, etc.). For illustration purposes, Fig.28 Two different users X and Y are shown using system 2800. Thus, the CPU of host data processing system 2802 has been divided between users X and Y. Thus, host data processing system 2802 includes user X CPU 2804 and user Y CPU 2808. Host data processing system 2802 also includes host interconnect 2806 capable of establishing communications with SoC 100. For example, host interconnect 2806 may be a PCIe node capable of communicating with SoC 100 via a PCIe link.

[0276] 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 user X and user Y. Therefore, the host memory 2810 includes a user X memory 2812 allocated to user X and a user Y memory 2814 allocated to user Y.

[0277] SoC 100 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 SoC 100 and external RAM 2836 that is local to SoC 100. The enclosure design implemented within SoC 100 creates multiple partitions within SoC 100. The term "partition" as used herein in connection with SoC 100 refers to a collection or group of SoC 100 resources that are allocated or reserved for use by any application implemented within the partition.

[0278] The shell itself may occupy a partition, in that the shell includes selected components of the SoC 100 that are capable of managing the 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 the various functions described herein with reference to the PMC 1602 may be part of the shell, enabling a FaaS provider to manage the SoC 100 and the implementation of different users or applications therein in their respective partitions. On the other hand, the PMC 1602 may be independent of the shell, but only accessible by the shell, so that applications implemented in the various partitions cannot access the PMC 1602. The shell may be firewalled like other partitions. However, unlike other partitions, the shell is able to monitor and access the different partitions implemented in the SoC 100 and the specific roles / users implemented in each partition.

[0279] In one aspect, a shell (not shown) may be implemented as a static region within the SoC 100 that does not change, while a partition may be implemented as a dynamically reconfigurable region within the SoC 100. For example, the shell may include a PCIe node (e.g., 2816, 2820) and a DMA (2816, 2822), a memory controller, and the like. For example, the shell may include interfaces necessary for communicating with circuits located outside the SoC 100. In this way, a partition implemented as a dynamically reconfigurable region may be reconfigured over time to implement different applications, while the SoC 100 is able to maintain a communication link with a host data processing system, RAM, and / or other external devices because the shell runs uninterrupted. The shell includes an interface to the partition so that once an application is implemented in the partition, the application can 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 the external RAM 2836) through the shell. The enclosure 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 .

[0280] exist Fig.28 In the example of , SoC 100 is divided into two partitions (e.g., excluding the shell static area). Each partition has or includes a subset of the resources of SoC 100 for use by a specific application executed in the 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 therefore, users X and Y, can occupy SoC 100 at the same time and be isolated from each other by firewalls. Partitions X and Y are dynamically reconfigurable areas.

[0281] exist Fig.28 In the example of FIG. 1 , partitions X and Y are shown as including equivalent subsets of resources. However, this need not be the case. One partition may be allocated more or fewer resources than another partition. The shell and PMC 1602 as implemented in SoC 100 may 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 may implement user applications in different partitions and change the applications implemented in each partition over time.

[0282] For example, resources of SoC 100 allocated to partition X are shaded. Partition X corresponding to user X includes: PCIeA / PF / VF circuit blocks 2816 and DMA 2818 from PS 106; one or more PL functions 2824 (e.g., circuit blocks) implemented in PL 104; one or more GTs 2032, MACs 2030, and PCIPBs 2842 of available hardwired circuit blocks; one or more DPEs 204 of DPE array 102; and a region of external RAM 2836, which is shown as user X SoC memory 2838. Partition Y, corresponding to user Y, has the resources of the SoC 100 allocated to it unshaded, including: PCIeA / PF / VF circuit block 2820 and DMA 2822 from PS 106; one or more PL functions 2828 (e.g., circuit blocks) implemented in PL 104; one or more other GTs 2032, another MAC 2030, and another PCIPB 2842 of available hardwired circuit blocks; one or more other DPEs 204 of DPE array 102; and various regions of external RAM 2836 shown as user Y SoC memory 2840. Fig.28 In the example of FIG. 2 , encryption circuit block 2826 (eg, hardware accelerator engine) is shared between partition X and partition Y, although this need not be the case.

[0283] Each of partitions X and Y has a signal path through NoC 108 and access to one or more memory controllers (not shown) for accessing external RAM 2836. The signal path is established by loading the PDI for the application implemented in each respective partition (e.g., forming the DPE configuration data, NoC configuration data, PL configuration data, and / or PS configuration data of the application). PCIBs 2842 and 2844 may be used to access external storage devices.

[0284] In this example, PMC 1602 (e.g., running in or under the control of a shell) has configured the SMID circuit block and PPC with appropriate identifiers and permission bindings to prevent erroneous or malicious access of resources in partition X to resources in partition Y, and vice versa. The exception is that both partitions in this example have access to cryptographic circuit block 2826. The separation and firewalls implemented (where each has independent data paths, interrupts, control signals, and the like) means that a failure or error in an application in one partition will not affect the operation of an application in another partition.

[0285] With reference to the allocation of PCIeA and DMA resources between partitions X and Y, security, performance, and error isolation of PCIe traffic between SoC 100 and the host data processing system can be implemented at different levels of granularity based on the FaaS multi-tenant isolation configuration implemented by the shell and / or PMC 1602. On the one hand, 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, where SoC 100 is configured to allocate a PCIeA controller to each of partitions X and Y. Performance isolation between partitions can be achieved so that bursty host data processing system to SoC traffic from one partition does not hinder the bandwidth available to another partition. In addition, PCIe link errors or PCIe link down conditions of one partition can be isolated from that partition. The PMC is able to isolate the power management functions of partition X from partition Y.

[0286] A host data processing system with a single host data processing system to SoC PCIe connection may cause the SoC 100 to be configured to assign one PCIeA 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 other partitions. The PCIe PASIDTLP prefix and address translation cache (ATC) may be used for concurrent and independent shared virtual memory interactions between user X and user Y running on the host data processing system 2802 and user X and user Y role functions implemented on the SoC 100 (e.g., applications implemented in respective partitions X and Y).

[0287] Fig.28 The dual-tenancy example of FIG. 1 illustrates how the PL 104 and memory resource allocation between partitions may be performed. Each partition may have a portion of the PL 104 and associated memory resources available in the services of applications implemented in that partition. The shell may provide available standard, pre-designed function libraries to users X and Y, which have characterized PL usage and performance metrics. In an alternative example, each of users X and Y may be able to deploy one or more custom functions using the available, per-user, partitioned resources of the SoC 100.

[0288] like Fig.28As shown, external RAM 2836 (e.g., DDR) can be allocated between partitions. The FaaS multi-tenant solution implemented by the shell enables security, performance, and error isolation of off-chip memory resources between users. This can be achieved at different levels of granularity. For example, a SoC 100 with multiple DDR controllers can be configured to include multiple DDR controllers, one or more of which are assigned to user X and one or more other DDR controllers are assigned to user Y. Performance isolation can be achieved, for example, a decrease in DDR bandwidth due to head-of-line blocking or page conflicts for user X does not affect the bandwidth of applications executed by user Y therein.

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

[0290] The NoC 108 is capable of providing security, performance, and error isolation between partitions 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. This isolation can be implemented at different levels of granularity based on the FaaS multi-tenant isolation configuration. For example, circuit block to circuit block and circuit block to memory paths that utilize the NoC 108 and the buffer resources of the NoC 108 can be allocated on a per-user basis. For example, the NoC 108 can be programmed so that the NoC physical paths and their dedicated virtual channels are allocated on a per-user (e.g., partition) basis. As discussed, SMIDs (whether inserted in transactions at or around the source and / or through SMID circuits implemented at the NoC 108 entry point) can be used by the PPC to enforce firewalls between users when transactions emerge from the NoC 108. In another example, the NoC 108 physical paths and dedicated virtual channels can be shared between users.

[0291] External I / O controllers and hardware acceleration blocks can also be allocated between users. For example, user X is allocated a specific GT 2032, MAC 2030, and PCIB 2842, while user Y is allocated a different GT 2032, a different MAC 2030, and a different PCIB 2844. Thus, user X and user Y have dedicated PCIe and Ethernet interface controllers and associated I / O.

[0292] However, in other configurations, using the built-in firewall functionality, the SoC 100 supports user X and user Y to simultaneously share the PCIe and Ethernet interface controllers and associated I / O. In addition, in the example shown, user X and user Y share access to the cryptographic circuit block 2826. The blocks shown in each partition simply represent the shared access of the hardwired circuit blocks by different users. The cryptographic circuit block 2826 is capable of providing encryption / decryption services to user X and user Y, where each user uses the cryptographic circuit block 2826 with a unique cryptographic key. This is true regardless of whether the data traffic is served by PCIe or Ethernet.

[0293] Also refer to Fig.26 , 27 and 28, the boot process of SoC 100 is hierarchical in nature, which is convenient for combining Fig.28 2700). For example, the boot code for the SoC 100 may initially be provided as block 0 of the PDI 2700 (e.g., from the SoC 100 manufacturer). Next, a shell created by the FaaS provider may be loaded as block 1 of the PDI 2700. As described above, the shell establishes the partitions of the SoC 100 by allocating resources to each partition. However, the resources of the SoC 100, although partitioned, are not configured. Blocks 2 and 3 corresponding to the applications to be implemented in partitions X and Y, respectively, are subsequently loaded.

[0294] At implementation time, each application is only aware of the resources of the SoC 100 that are allocated to the partition in which the application is implemented. As part of the firewall, the PMC 1602 is configured to allow each user access only to the configuration space corresponding to that user's partition. In other words, the PMC 1602 only allows user X to access the configuration space (e.g., configuration registers) of the SoC 100 resources allocated to partition X (whether a specific subset of the PL, a specific subset of the DPE array, and / or a specific unit in the PS). Similarly, the PMC 1602 only allows user Y to access the configuration space of the SoC 100 resources allocated to partition Y (whether a specific subset of the PL, a specific subset of the DPE array, and / or a specific unit in the PS).

[0295] PMC 1602 can programmatically enable and disable various circuit blocks in each partition (e.g., reference bonding Fig.23The PMC 1602 can also associate a particular interrupt with a particular SMID. For example, using the framework, user X can determine that the design (e.g., the application portion of partition X executed in the portion of PS 106 assigned to partition X) does not need to distinguish one or more different circuit blocks in the domain for handling interrupts. For example, the PS components in partition X can execute the same interrupt service routine regardless of whether the user-defined block in partition X or the hardware accelerator block in partition X triggered the interrupt.

[0296] As pointed out, in Fig.28 In the example of FIG. 1 , partition X and partition Y are shown as being substantially identical in terms of resource allocation. However, in other examples, the partitions may be customized according to the needs of each user and / or application. For example, if user Y requires fewer resources than user X, more resources and / or bandwidth may be allocated to partition X rather than partition Y. The partitions provide user X with increased bandwidth on the NoC 108, for example, to accommodate increased resource usage by user X. The partitions need not be symmetrical in terms of resource allocation and / or usage by their respective users.

[0297] In the multi-tenant FaaS use case, neither user is aware of the other user on SoC 100. In this regard, the improvement in usage of SoC 100 by user X is limited to partition X and does not degrade usage of SoC 100 by user Y. Partitions remain independent in terms of performance, error handling, and reliability.

[0298] In the example of multi-tenancy, once one user has completed an operation, another user may be implemented in the partition assigned to the now completed user. For example, consider a situation where user X intends to perform extended processing that may occur for several hours, while user Y performs video processing related to delivering video to a specific end user. When the end user stops consuming video content, user Y can be removed from the partition on SoC 100. Another different user, such as user Z, can be implemented in partition Y previously used by user Y using partial reconfiguration. While this is happening, user X is able to continue operating uninterruptedly in partition X like a shell. Partial reconfiguration can reconfigure any resources and / or connectivity within 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 capabilities (e.g., different configuration images loaded in each resource subset and / or different SMID and permission bindings). For example, a new user can perform audio processing instead of delivering video.

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

[0300] Partition 2904 is independent of partition 2902. Therefore, any processing, errors, and / or performance issues in partition 2904 do not affect partition 2902. Applications implemented in partition 2904 perform multiple different functions, such as programmable functions 1, 2, and 3. The programmable functions utilize the DPE array 102 and the PL region 104. Programmable function 1 may perform image processing and utilize one or more DPEs 2916 connected to a computer vision function 2918 implemented in PL 104. The computer vision function 2918 in PL 104 (e.g., a standard core implemented in PL 104 and / or a user-defined circuit block in PL 104) is connected to NoC 108 and multiple interleaved DDR controllers 2922 through PPC 2920. Programmable function 2 may perform machine learning and utilize one or more DPEs 2924 connected to a machine learning function 2926 implemented in PL 104. The machine learning function 2926 in the PL 104 (e.g., a standard core implemented in the PL 104 and / or a user-defined circuit block in the PL 104) is connected to the NoC 108 and the plurality of interleaved DDR controllers 2922 via the PPC 2920. The programmable function 3 may provide an interface to an external device and utilize an external interface 2928 implemented in the PL 104. The external interface 2928 in the PL 104 (e.g., a standard core implemented in the PL 104 and / or a user-defined circuit block in the PL 104) is connected to the NoC 108 and the plurality of interleaved DDR controllers 2922 via the PPC 2920.

[0301] Fig.29An example of partition 2904 being used to perform image processing on a video data stream obtained from one or more cameras and / or other sensors in an automobile or other vehicle is shown. For example, partition 2904 can perform operations such as lane detection, target recognition, other computer vision tasks, and / or machine learning. Partition 2902 can perform control and communication functions and can also manage other timing-critical real-time tasks. Features of interest, such as data obtained and / or generated by each partition, can be accessed from a shared area in the DDR memory, which can be accessed by two partitions, as determined by the SMID and PPC 2920 assigned to the corresponding master in each partition.

[0302] As described above, partitions 2902 and 2904 are separated from each other. In addition, partitions 2902 and 2904 operate in a manner that does not interfere with each other. For example, if an error is detected in partition 2904, the application implemented in partition 2902 can continue to run while partition 2904 is restored (e.g., by resetting the partition and reloading the application therein through partial reconfiguration).

[0303] Applications implemented in the SoC 100 can be implemented by the PMC 1602 based on the allocation of resources at the SoC 100 boot time. For example, the PMC 1602 uses a programmable address map to create addressing capabilities for each of the two partitions. The NoC 108 provides a QoS controlled data path through each of the partitions 2902 and 2904. The data path through the NoC 108 is programmed to isolate between the data paths to ensure no interference. The PMC 1602 programs the memory protection circuit 2920 to provide access (and limit access) to resources such as DDR, SRAM, peripherals, and other partitions.

[0304] PMC 1602 is also capable of dynamically reconfiguring one or both partitions (e.g., performing partial reconfiguration) during operation of SoC 100, such as at execution time. For example, during execution time, an application executed in partition 2904 may be replaced by a different version of the application to perform different computer vision and / or machine learning operations. As an illustrative and non-limiting example, an application executed in partition 2904 may be changed from an application that performs driving assistance (e.g., for driving at higher speeds) using a front camera to an application that performs parking assistance and uses a rear camera. For example, the time required to switch from forward to reverse in a vehicle may trigger and be sufficient to partially reconfigure partition 2904. Driving assistance and parking assistance features are provided for illustrative purposes only. The applications implemented in 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 partitions and / or different applications in each of partitions 2902 and 2904.

[0305] The automotive use case illustrates further features where the partitions may include encrypted and / or non-encrypted partitions. For example, one partition may be implemented with a secure zone with high reliability to perform safety-critical features, while another partition may require less secure features when providing entertainment functions (e.g., video streaming and / or audio processing). Nonetheless, the partitions are firewalled.

[0306] exist Fig.29 In the example, because a user has two partitions 2902 and 2904, there is no need to implement a shell. That is, although the two diagrams, Fig.28 and 29 An example of partitioning is shown, but Fig.28 shows a multi-tenant model, where more than one user can use SoC 100 simultaneously, while Fig.29 In the example, a single user with two partitions is using SoC 100. Fig.28 The described shell can be combined with the PMC 1602 to manage a multi-tenant implementation.

[0307] Figure 30-32 Different example use cases for implementing PDI within SoC 100 are shown. Figure 30-32 The example of 1602 illustrates various features of SoC 100 as previously described herein, for example, the ability of a centralized component such as PMC 1602 to configure the entire device, including PL 104, PS 106, NoC 108, DPE array 102, and hardwired circuit blocks 110. As noted, in some cases, PS 106 is capable of configuring PL 104, NoC 108, DPE array 102, and hardwired circuit blocks 110.

[0308] Figure 30-32 Also shown is the use of common infrastructure of SoC 100, such as NoC 108, to connect various circuit components within the same partition. Figure 30-32 Different examples of remapping are further shown. One example of remapping refers to dynamic partial reconfiguration, where resources within a partition of SoC 100 are reconfigured over time for use by other different applications. Another example of remapping is where SoC 100 resources are reconfigured to create different partitions over time.

[0309] Fig.30 An example method 3000 for implementing a PDI within SoC 100 is shown. The PDI implemented in SoC 100 may include configuration data for implementing a plurality of different partitions. Typically, the PDI that specifies a plurality of different partitions includes one partition that is used as a master partition. The partition is capable of controlling other secondary or slave partitions. As an illustrative example, as described herein in conjunction with Fig.28 The FaaS example describes a shell design that can be run as a primary partition. In another example, Fig.29 The real-time processing domain shown can run as a primary partition.

[0310] In block 3002, SoC 100 is powered on. In block 3004, PMC 1602 is powered on and performs an initial security configuration in SoC 100. For example, PMC 1602 may perform one or more operations, as described above in conjunction with Fig.26 as described.

[0311] For example, in block 3004, the PMC 1602 can perform an initial configuration of one or more circuit blocks in the SoC 100. The initial configuration includes, for example, setting clocks and security settings within the SoC 100. The PMC 1602 can write configuration data to the various PPCs of the SoC 100. At this stage, the PMC 1602 can write configuration data that only allows the PMC 1602 to access the PPCs and / or specific slave devices protected by the PPCs. The PMC 1602 can also configure the SMID circuit.

[0312] On the other hand, PMC 1602 can write initial configuration settings to global registers of DPE array 102 (not shown). For example, PMC 1602 can write NPI 710 to access these global registers. For example, the global registers can specify how the DPE identifies itself by SMID.

[0313] By default, at power-up, the NoC 108 is not configured with any data paths. After power-up, no circuit block can communicate with any other circuit block using the NoC 108. However, the PMC 1602 can program the NoC 108 using the NPI 710 to establish an initial data path to the DPE array 102 for programming purposes. Fig.10 An example method is described for initially configuring the NoC 108. The initial datapath, once configured by the PMC 1602, can then be used by the PMC 1602 to program applications to the DPE array 102 (e.g., to program the cores, memory modules, DMAs, switches, etc. of a single DPE 204) by writing to other configuration registers in the DPE array 102.

[0314] In one aspect, PMC 1602 may operate on a power domain of SoC 100 that is independent of each other subsystem and / or component included within SoC 100. SMID circuitry and / or PPC circuitry may be included in the PMC power domain. This allows PMC 1602 to power up or power down subsystems independently of each other while maintaining an active and trusted center for SoC 100. Additionally, security settings created by PMC 1602 may be retained by SMID circuitry and / or PPC even though a particular subsystem protected by such circuitry is being powered down.

[0315] In block 3006, PMC 1602 loads PDI into SoC 100. PMC 1602 executes PDI to create partitions and implement applications in the partitions. For example, PDI specifies multiple partitions and applications to be implemented in each of the different partitions of SoC 100. PDI may specify a primary partition and one or more secondary partitions, each of which implements an application. In one example, PDI, when loaded into SoC 100 and executed by PMC 1602, implements the following: Fig.28 The partitions described herein may include a shell and two or more different user partitions. In another example, the PDI is implemented as a combination of the following when loaded into the SoC 100 and executed by the PMC 1602: Fig.29 The partition being described.

[0316] When executing block 3006, PMC 1602 can combine Fig.26 In addition, PMC 1602 can authenticate PDI as described in block 2620 of Fig.26 The PDI is performed as described in block 2626 of PMC 1602. PMC 1602 can configure portions of the PL, portions of PS 106, portions of NoC 108, portions of DPE array 102, and / or any hardwired circuit blocks used by each respective partition specified by the PDI.

[0317] The PDI may be created using an electronic design automation (EDA) tool that enforces implementation rules. Typically, the implementation rules ensure that functionality (e.g., user and / or application) will fit into the partitions to be created within the SoC 100. For example, based on the partitions to be implemented in the SoC 100, the EDA tool may assign a specific number of DPEs 204 to each of the "N" different partitions, assign a specific number (e.g., number of cell blocks) of PLs 104 to each of the N partitions, assign specific memory controllers to each of the N partitions or only to certain of the N partitions, assign certain processors in the PS 106 to the N partitions or only 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 execute in the available partitions of the SoC 100.

[0318] As part of block 3006, the PMC 1602 can adjust the security configuration of each partition specified by the PDI to implement firewalls and isolation of the partitions. For example, the PDI includes configuration data that the PMC 1602 writes to configuration registers, PPCs, and / or SMID circuits of the SoC 100 to complete the configuration of the circuits to implement firewalls and prevent circuits within a partition from crossing partition boundaries and accessing circuit resources of other partitions. For example, the PMC 1602 can configure the memory controller to allocate an external memory pool that is used only by a specific partition within the SoC 100, and another external memory pool (e.g., non-overlapping memory) that is used only by a different partition within the SoC 100.

[0319] Once the SoC 100 is configured, the applications implemented in each partition can be run. As discussed, after block 3006, the SoC 100 can implement the Fig.28 or Fig.29 The partitions and applications described.

[0320] Fig.31 Another example method 3100 of implementing PDI within SoC 100 and reconfiguring SoC 100 over time is shown. Fig.31 In the example of FIG. 1 , SoC 100 may be configured by loading a first PDI. The first PDI may specify a particular partition of SoC 100. Subsequently, in response to a trigger event, SoC 100 may be reconfigured with a different PDI specifying a different partition of SoC 100. For example, PMC 1602 may execute a control program responsible for loading different PDIs into SoC 100 over time in response to different trigger events (e.g., signals and / or interrupts).

[0321] Thus, in block 3102, SoC 100 is powered on. In block 3104, PMC is powered on and performs an initial security configuration in SoC 100. In block 3106, PMC loads the application into SoC 100 to create multiple partitions and implements the application in each partition. Blocks 3102, 3104, and 3106 may be substantially as respectively combined. Fig.30 The blocks 3002, 3004 and 3006 are performed as described.

[0322] In block 3108, the PMC 1602 determines whether a triggering event has been detected. The triggering event may be detected by any of a variety of different circuits implemented within the SoC 100. Such circuits may detect triggering events within the SoC 100 itself and / or detect triggering events from external sources. In response to detecting a triggering event, such circuits can generate an interrupt that can 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.

[0323] In response to detecting a trigger event, method 3100 continues to block 3110 to load a different PDI into SoC 100 and execute the different PDI to create a partition and implement an application in the partition. Fig.31 In the example of FIG. 31 , different PDIs may configure the entirety of SoC 100. Although the partitions specified by the different PDIs may be the same as the partitions that existed before block 3108, the partitions may be completely different. The applications implemented in the partitions may also be different from those originally implemented in block 3106.

[0324] When loading different PDIs, the PMC 1602 is able to perform Fig.26 Blocks 2620 and 2626. For example. In the illustration, PMC 1602 verifies different PDIs. PMC 1602 then loads different configuration data blocks from different PDIs to assign DPE 204, cell blocks of PL 104, routing in NoC 108, components of PS 106, and / or hardwired circuit blocks 110 to different partitions specified by different PDIs. Loading different PDIs in block 3110 shows an example of remapping, where resources of SoC 100 are effectively reallocated to different partitions. In addition, resources in each partition can be reconfigured to implement different applications.

[0325] If no trigger event is detected in block 3108, method 3100 can continue to loop through block 3108 to monitor for the occurrence of a trigger event. While looping, the partitions initially implemented in block 3106 and the applications implemented in the respective partitions continue to run.

[0326] Method 3100 may continue to iterate. Fig.31 The example shows a situation where multiple different PDIs are available and PMC1602 loads different PDIs over time in response to different trigger events. It should be understood that each different type of trigger event that can be detected in block 3108 can be associated with a specific PDI. This allows the SoC 100 to be reconfigured as needed in response to different conditions. As previously described, the reconfiguration extends to all subsystems of the SoC 100.

[0327] Fig.32 Another example method 3200 for implementing PDI within SoC 100 and performing partial reconfiguration of SoC 100 over time is shown. Fig.32 In the example of FIG. 1 , SoC 100 may be configured by loading a first PDI. The first PDI may specify a particular partition of SoC 100. Subsequently, in response to a triggering event, SoC 100 may undergo a partial reconfiguration in which functions (e.g., applications) in one or more partitions are dynamically reconfigured. While partial reconfiguration in conventional FPGA-type devices involves only modifying functions implemented in certain portions of PL 104 while other portions continue to operate uninterrupted, in Fig.32 In the example of FIG. 4 , partial reconfiguration is extended to include any type of circuits and / or subsystems in a partition undergoing partial reconfiguration.

[0328] Thus, in block 3202, SoC 100 is powered on. In block 3204, PMC is powered on and performs an initial security configuration in SoC 100. In block 3206, PMC 1602 loads PDI into SoC 100 and executes PDI to create multiple partitions and implement applications in each partition. The multiple partitions include a primary partition (e.g., a shell or a real-time processing domain) and one or more secondary partitions. Blocks 3202, 3204, and 3206 may be substantially as respectively combined. Fig.30 The blocks 3002, 3004 and 3006 are performed as described.

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

[0330] exist Fig.32 In the example of , a different PDI reconfigures a partition of SoC 100 called a "selected partition". The selected partition may be the sub-partition initially implemented in block 3206. Thus, given Fig.30 and 31 shows the reconfiguration of the entire SoC 100, while Fig.32 Partial reconfiguration of a single partition is shown. That is, the different PDIs include only configuration data for configuring (or reconfiguring) a specific portion of PL 104, a portion of PS 106, a portion of NoC 108, a portion of DPE array 102, and any hardwired circuit blocks 110 that are part of the selected partition.

[0331] In block 3210, PMC 1602 loads a different PDI and executes the different PDI to dynamically reconfigure the selected partition. The different PDI includes configuration data required for PMC 1602 to configure any circuits included in the selected partition being dynamically reconfigured. In executing block 3210, PMC 1602 can, as in conjunction with Fig.26 PMC 1602 can also perform authentication on those portions of PL 104, PS 106, NoC 108, hardwired circuit blocks 110, and / or DPE 204 that are part of the selected partition. Fig.26 For example, PMC 1602 will not overwrite any other configuration data for PL 104, PS 106, NoC 108, hardwired circuit block 110, and / or any portion of DPE 204 that is not part of the selected partition.

[0332] It should be appreciated that while method 3200 describes partial reconfiguration of SoC 100 in conjunction with reconfiguring a single partition, partial reconfiguration may alternatively include reconfiguring more than one but less than all partitions in SoC 100 .

[0333] For illustration purposes, consider the case where PMC 1602 was originally implemented Fig.28 An example of an architecture (including a housing not shown in block 3206). Fig.28In a FaaS example of , PMC 1602 may be incorporated into the shell. The shell may be implemented as a static, unchanging area that is capable of creating partitions and controlling applications implemented in the partitions, which are dynamically reconfigurable. Thus, the shell may include PMC 1602 and be capable of controlling partial reconfiguration of each secondary partition. The shell may include external I / O and / or other support circuits that remain operational and connected to the host processing system while reconfiguring one or more or all secondary partitions. In yet another example, PMC 1602 may be separate from the shell but accessible only by the shell.

[0334] continue Fig.28 In the FaaS example, in block 3210, PMC 1602 can reconfigure partition Y for use by user Z (e.g., another application or role). When reconfiguring the selected partition, PMC 1602 can perform Fig.26 106 and 107. The PMC 1602 may also load configuration data (e.g., executable code and / or register settings) for the portion of the PS 106 of Partition Y used by User Z and / or any hard-wired circuit blocks of Partition Y used by User Z.

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

[0336] In another example, consider Fig.29In that case, in block 3206, PMC 1602 initially implements partitions 2902 and 2904. Partition 2902 implements an application corresponding to the low-power domain (e.g., an RPU, a memory controller assigned to it, and an external RAM bank with a connection established through NoC 108 corresponding to partition 2902). PMC 1602 further implements functionality in partition 2904, which implements an application utilizing one or more DPEs, implements one or more circuit blocks in PL 104, and uses a memory controller and another external RAM bank with a connection established in NoC 108 (e.g., corresponding to partition 2904).

[0337] Therefore, in block 3210, PMC 1602 loads different PDIs into SoC 100 and executes different PDIs. For example, PMC 1602 may implement different applications in partition 2904 to implement different functions therein based on a specific trigger event detected. Referring to the previous example, partition 2904 may be dynamically reconfigured from implementing a driving application to a parking application, and vice versa. Fig.32 In the example of , although SoC 100 undergoes dynamic partial reconfiguration to implement different applications in partition 2904, the resources allocated to partition 2904 remain unchanged.

[0338] In some cases, memory controllers and / or other circuit blocks may be shared between partitions, depending on the desired security and degree of isolation between partitions. A shared memory controller may still enforce memory separation so that each partition can only access that partition's own memory bank, which is independent of other partitions. However, in other cases, partitions may have some shared memory.

[0339] In the automotive example, SoC 100 implements an application corresponding to one user. That is, a particular entity can develop multiple applications that will run concurrently in different partitions of SoC 100. Although each application may be owned by the same user, each application will be executed in a different isolated partition to meet security requirements. For example, applications using low-power domains and RPUs may have these security requirements and need to be isolated from other applications. In addition, in the automotive example, PMC 1602 can operate at a level higher than the partitions implemented in SoC 100 and provide the control required for simultaneous execution of applications and swapping different applications into and out of partitions (e.g., by partial reconfiguration). If no triggering event is detected, method 3200 continues to loop until a triggering event is detected. SoC100 continues to operate, and each partition operates according to the current configuration. Since each partition is isolated from each other, the applications implemented in each partition are able to run independently. As described above, in some cases, the doorbell interrupt can be used to cross from one partition to another to provide signaling and / or messaging between partitions.

[0340] It should be understood that although Figure 30-32 Using PMC 1602 to load different PDIs within SoC 100 is described. Once SoC 100 is booted and PS 106 is configured, a processor in PS 106 may be used to control the loading of PDIs to reconfigure all or part of SoC 100 (eg, perform a partial reconfiguration).

[0341] 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 specific aspects of the inventive apparatus only and is not intended to be limiting.

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

[0343] 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 expressly stated otherwise. For example, each of the expressions "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 A, B, or C," and "A, B, and / or C" refers to A alone, B alone, C alone; A and B together, A and C together, B and C together; or A, B, and C together.

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

[0345] As defined herein, the term "if" means "when" or "based on" or "in response to" or "in response to," depending on the context. Thus, the phrase "if it is determined" or "if [stated condition or event] is detected" can be interpreted as "according to the determination" or "in response to the determination" or "upon detecting [stated condition or event]" or "in response to detecting [the condition or event]" or "in response to detecting [the condition or event]," depending on the context.

[0346] As defined herein, the term "in response to" and similar language as described above, such as "if," "when," or "at," refers to readily responding to or reacting to an action or event. The response or reaction is automatically performed. Thus, if a second action is performed "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 to" indicates a causal relationship.

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

[0348] As defined herein, the term "real time" refers to a level of processing responsiveness that is immediate enough for a user or system to make a particular process or determination, or that enables the processor to keep up with some external process.

[0349] As defined herein, the term "substantially" means that the stated characteristic, parameter or value need not be achieved precisely, but rather that deviations or variations, including, for example, tolerances, measurement errors, measurement precision limitations and other factors known to those skilled in the art, may occur in amounts that do not eliminate the effect that the characteristic is intended to provide.

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

[0351] The flowchart and block diagram in the figure illustrate the possible architecture, function and operation of the system, method and computer program product according to various aspects of the device of the present invention. In this regard, each block in the flowchart or block diagram may represent a part of a module, segment or instruction, which includes one or more executable instructions for implementing a specified operation.

[0352] In some alternative embodiments, the operations noted in the blocks may not occur in the order noted in the figure. For example, two blocks shown in succession may be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functions involved. In other examples, the blocks may generally be executed in increasing numerical order, while in other examples, one or more blocks may be executed in a varying order, with the results stored and used in subsequent or non-immediately subsequent other blocks. It will also be noted that each block of the block diagram and / or flow chart illustration, and the combination of blocks in the block diagram and / or flow chart illustration, may be implemented by a dedicated hardware-based system that performs a specified function or action or action or performs a combination of dedicated hardware and computer instructions.

[0353] The corresponding structures, materials, acts, and equivalents of all means or step plus function elements found in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed.

[0354] The device may include a programmable logic circuit, a processor system coupled to the programmable logic circuit, and an on-chip network coupled to the programmable logic circuit and the processor system. The on-chip network is programmable to establish a user-specified data path to communicatively connect 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 on-chip network, and the processor system.

[0355] 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 a master node and slave nodes, wherein the user application specifies a data path and an implementation of each node in the programmable logic circuit or the processor system.

[0356] In another aspect, the apparatus includes an array of data processing engines coupled to an on-chip network, wherein user-specified data paths further communicatively link data processing engines of the array of data processing engines to the programmable logic circuit or processor system.

[0357] In another aspect, the data processing engine array is configured to implement a portion of a user application, wherein the user application specifies an implementation of at least one of the nodes within the data processing engine array.

[0358] In another aspect, the apparatus includes a dedicated hardwired circuit block coupled to the on-chip network. The dedicated hardwired circuit block and the circuit block implemented in the programmable logic circuit have a common interface.

[0359] On the other hand, the on-chip network and the programmable logic circuits are configured to implement multiple independent partitions.

[0360] On the other hand, each partition implements a different application and these applications are isolated from each other.

[0361] In another aspect, the apparatus includes a programmable protection circuit configured to compare an identifier of a transaction source within a received transaction to a list of authorized transaction sources.

[0362] In another aspect, the programmable protection circuitry also compares the address specified in the received transaction with the allowed addresses of the identifier of the transaction source.

[0363] On the other hand, processor systems and circuit blocks implemented in programmable circuits communicate using a common descriptor format.

[0364] A method may include providing a device including a programmable logic circuit, a processor system coupled to the programmable logic circuit, and an on-chip network coupled to the programmable logic circuit and the processor system. The on-chip network is programmable to establish a user-specified data path to communicatively connect circuit blocks implemented in the programmable logic circuit and the processor system. The method may include configuring the programmable logic circuit, the on-chip network, and the processor system using a platform management controller disposed in the device.

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

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

[0367] In another aspect, the method includes configuring a data processing engine array to implement a portion of a user application, wherein the user application specifies an implementation of at least one node within the data processing engine array.

[0368] In another aspect, the apparatus includes a dedicated hardwired circuit block coupled to the on-chip network. In that case, the method may include providing a common interface for the dedicated hardwired circuit block and the circuit block implemented in the programmable logic circuit.

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

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

[0371] In another aspect, the method includes implementing different applications in each partition and isolating the applications from each other.

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

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

[0374] The description of the inventive apparatus provided herein is for illustrative purposes and is not intended to be exhaustive or limited to the disclosed forms and examples. The terminology used herein is selected to explain the principles of the inventive apparatus, practical applications, or technical improvements over technologies found in the marketplace, and / or to enable one of ordinary skill in the art to understand the inventive arrangements disclosed herein. Modifications and variations will be apparent to one of ordinary skill in the art without departing from the scope and spirit of the inventive arrangements described. Therefore, reference should be made to the following claims, rather than to the foregoing disclosure, to indicate the scope of such features and embodiments.

Claims

1. A device, characterized in that: The device comprises: Programmable logic circuits; a processor system coupled to the programmable logic circuit; a network on chip coupled to the programmable logic circuit and the processor system; wherein the network on chip and the programmable logic circuit are configured to implement a plurality of independent partitions; wherein the network on chip is programmable to establish a user-specified data path for each of the plurality of independent partitions, the user-specified data path communicatively linking circuit blocks implemented in the programmable logic circuitry and the processor system; and A platform management controller configures the programmable logic circuit, the network on chip, and the processor system to implement the plurality of independent partitions.

2. The device according to claim 1, characterized in that Each of the plurality of independent partitions implements a different application, and the applications are isolated from each other.

3. The device according to claim 2, characterized in that The device also includes: A data processing engine array is coupled to the network on chip, wherein one or more independent partitions of the plurality of independent partitions include one or more data processing engines of the data processing engine array.

4. The device according to claim 3, characterized in that The array of data processing engines is configured to implement a portion of the application in each of one or more independent partitions of the plurality of independent partitions.

5. The device according to claim 1, characterized in that The device also includes: a dedicated hardwired circuit block coupled to the network on chip; and The dedicated hard-wired circuit block and the circuit block implemented in the programmable logic circuit in each of the plurality of independent partitions have a common interface.

6. The device according to claim 1, characterized in that The device also includes: A programmable protection circuit is configured to isolate the plurality of independent partitions by comparing an identifier of a transaction source within a received transaction to a list of authorized transaction sources.

7. The device according to claim 6, characterized in that The programmable protection circuit further compares an address specified in the received transaction to allowed addresses for the identifier of the transaction source.

8. The device according to claim 1, characterized in that The processor system and circuit blocks implemented in the programmable circuit communicate using a common descriptor format.

9. A method, characterized in that The method comprises: Providing an apparatus, the apparatus comprising 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; configuring the network on chip and the programmable logic circuit to implement a plurality of independent partitions; wherein the on-chip network is programmable to establish a user-specified data path for each of the plurality of independent partitions, the user-specified data path communicatively linking a circuit block implemented in the programmable logic circuit and the processor system; and Using a platform management controller disposed in the device, the programmable logic circuit, the network on chip, and the processor system are configured to implement the plurality of independent partitions.

10. The method according to claim 9, characterized in that Each of the plurality of independent partitions implements a different application, and the applications are isolated from each other.

11. The method according to claim 10, characterized in that The apparatus includes a data processing engine array coupled to the network on chip, wherein one or more independent partitions of the plurality of independent partitions include one or more data processing engines of the data processing engine array.

12. The method according to claim 11, characterized in that The method further comprises: The array of data processing engines is configured to implement a portion of the application in each of one or more of the plurality of independent partitions.

13. The method according to claim 9, characterized in that The apparatus comprises a dedicated hardwired circuit block coupled to the network on chip, the method further comprising: A common interface is provided for the dedicated hardwired circuit blocks and circuit blocks implemented in programmable logic circuitry in each of the plurality of independent partitions.

14. The method according to claim 9, characterized in that The method further comprises: At least one independent partition of the plurality of independent partitions is dynamically reconfigured.

15. The method according to claim 9, characterized in that The method further comprises: providing a programmable protection circuit in the device; and The plurality of independent partitions are isolated by configuring the programmable protection circuitry to compare an identifier of a transaction source within a received transaction to a list of authorized transaction sources.

Images