Data processing engine configuration in a device

Abstract

To provide a device including a data processing engine and / or a data processing engine array.SOLUTION: The device includes a plurality of data processing engines 304. Each of the data processing engines 304 includes a core 602 and a memory module 604. The plurality of data processing engines 304 are organized into a plurality of columns. Each core 602 communicates with other neighboring data processing engines 304 of the plurality of data processing engines 304 by shared access to the memory modules 604 of the other neighboring data processing engines 304.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] Technical Field The present disclosure relates to integrated circuit devices (devices), and more particularly to devices that include data processing engines and / or arrays of data processing engines. [Background technology]

[0002] background A programmable integrated circuit (IC) refers to a type of IC that contains programmable circuits. An example of a programmable IC is a field programmable gate array (FPGA). FPGAs are characterized by containing programmable circuit blocks. Examples of programmable circuit blocks include, but are not limited to, input / output blocks (IOBs), configurable logic blocks (CLBs), dedicated random access memory blocks (BRAMs), digital signal processing blocks (DSPs), processors, clock managers, and delay-locked loops (DLLs).

[0003] A circuit design may be physically realized within the programmable circuitry of a programmable IC by loading configuration data, sometimes referred to as a configuration bitstream, into the device. The configuration data may be loaded into the device's internal configuration memory cells. The collective state of the individual configuration memory cells determines the functionality of the programmable IC. For example, the specific operations performed by various programmable circuit blocks and the connectivity between the programmable circuit blocks of the programmable IC are defined by the collective state of the configuration memory cells once the configuration data is loaded. Summary of the Invention [Means for solving the problem]

[0004] overview In one or more embodiments, a device may include multiple data processing engines, each of which may include a core and a memory module, and each core may be configured to access a memory module in the same data processing engine and a memory module in at least one other of the multiple data processing engines.

[0005] In one or more embodiments, a method may include a first core of a first data processing engine generating data, the first core writing the data to a first memory module in the first data processing engine, and the method may further include a second core of a second data processing engine reading the data from the first memory module.

[0006] In one or more embodiments, a device may include multiple data processing engines, a subsystem, and a system-on-chip (SoC) interface block coupled to the multiple data processing engines and the subsystem. The SoC interface block may be configured to exchange data between the subsystem and the multiple data processing engines.

[0007] In one or more embodiments, a tile for an SoC interface block includes a memory mapping unit configured to provide a first portion of the configuration data to a neighboring tile and a second portion of the configuration data to a data processing engine of the plurality of data processing engines. The tile may include a memory-mapped switch. The tile may include a stream switch configured to provide first data to at least one neighboring tile and provide second data to a data processing engine of the plurality of data processing engines. The tile may include an event broadcast circuit configured to receive events generated within the tile and events from circuitry external to the tile, the event broadcast circuit being programmable to provide selected ones of the events to selected destinations. The tile may include an interface circuit coupling the memory-mapped switch, the stream switch, and the event broadcast circuit to a subsystem of the device including the tile.

[0008] In one or more embodiments, a device may include multiple data processing engines. Each of the data processing engines may include a core and a memory module. The multiple data processing engines may be organized into multiple columns. Each core may be configured to communicate with other nearby data processing engines of the multiple data processing engines by shared access to the memory modules of the other nearby data processing engines.

[0009] In one or more embodiments, a device may include multiple data processing engines, each of which may include a memory pool having multiple memory banks, multiple cores each coupled to the memory pool and configured to access the multiple memory banks, a memory-mapped switch coupled to the memory pool and the memory-mapped switch of at least one neighboring data processing engine, and a stream switch coupled to each of the multiple cores and coupled to the stream switch of the at least one neighboring data processing engine.

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

[0011] Configurations of the present invention are illustrated by way of example in the accompanying drawings. However, the drawings should not be construed as limiting the configuration of the present invention to only the particular implementations shown. Various aspects and advantages will become apparent upon review of the following detailed description and by reference to the drawings. [Brief explanation of the drawings]

[0012] [Figure 1] 1 illustrates an example of a device that includes a data processing engine (DPE) array. [Figure 2A] 1 illustrates an exemplary architecture for a device having one or more DPE arrays. [Figure 2B] 1 illustrates an exemplary architecture for a device having one or more DPE arrays. [Figure 2C] 1 illustrates an exemplary architecture for a device having one or more DPE arrays. [Figure 2D] 1 illustrates an exemplary architecture for a device having one or more DPE arrays. [Figure 3] FIG. 1 illustrates another exemplary architecture of a device including a DPE array. [Figure 4A] 1 illustrates an example of a multi-die implementation of a device having one or more DPE arrays. [Figure 4B] 1 illustrates an example of a multi-die implementation of a device having one or more DPE arrays. [Figure 5A] 1 illustrates an exemplary multi-die implementation of a device having a DPE array. [Figure 5B] 1 illustrates an exemplary multi-die implementation of a device having a DPE array. [Figure 5C]1 illustrates an exemplary multi-die implementation of a device having a DPE array. [Figure 5D] 1 illustrates an exemplary multi-die implementation of a device having a DPE array. [Figure 5E] 1 illustrates an exemplary multi-die implementation of a device having a DPE array. [Figure 5F] 1 illustrates an exemplary multi-die implementation of a device having a DPE array. [Figure 5G] 1 illustrates an exemplary multi-die implementation of a device having a DPE array. [Figure 6] 1 illustrates an exemplary architecture for a DPE in an array of DPEs. [Figure 7] 1 illustrates an example of connectivity between multiple DPEs. [Figure 8] 7 illustrates further aspects of the exemplary DPE architecture of FIG. 6. [Figure 9] 1 illustrates an exemplary connectivity of the cascade interface of the core of a DPE. [Figure 10A] An example of connectivity between DPEs is shown. [Figure 10B] An example of connectivity between DPEs is shown. [Figure 10C] An example of connectivity between DPEs is shown. [Figure 10D] An example of connectivity between DPEs is shown. [Figure 10E] An example of connectivity between DPEs is shown. [Figure 11] 1 shows an example of an event processing circuit in a DPE. [Figure 12] 1 illustrates another exemplary architecture for a DPE. [Figure 13] 1 illustrates an exemplary architecture for a DPE array. [Figure 14A] 1 illustrates an exemplary architecture for implementing tiles of a system-on-chip (SoC) interface block. [Figure 14B] 1 illustrates an exemplary architecture for implementing tiles of a system-on-chip (SoC) interface block. [Figure 14C] 1 illustrates an exemplary architecture for implementing tiles of a system-on-chip (SoC) interface block. [Figure 15] 1 illustrates an exemplary implementation of a programmable logic interface for a tile of an SoC interface block. [Figure 16] 1 illustrates an exemplary implementation of a network-on-chip (NoC) stream interface for a tile of an SoC interface block. [Figure 17] 1 illustrates an exemplary implementation of a direct memory access (DMA) engine in a tile of an SoC interface block. [Figure 18] 1 illustrates an exemplary architecture for multiple DPEs. [Figure 19] 1 illustrates another exemplary architecture for multiple DPEs. [Figure 20] 1 illustrates an exemplary method for configuring a DPE array. [Figure 21] 1 illustrates an exemplary method of operation of a DPE array. [Figure 22] 10 illustrates another exemplary method of operation of a DPE array. [Figure 23] 10 illustrates another exemplary method of operation of a DPE array. [Figure 24] 10 illustrates another exemplary method of operation of a DPE array. DETAILED DESCRIPTION OF THE INVENTION

[0013] Detailed Description While this disclosure defines claims defining novel features, it is believed that the various features described within this disclosure will be better understood by considering the description in conjunction with the drawings. The processes, machines, manufacture, and any variations thereof described herein are provided for illustrative purposes. The specific structural and functional details described within this disclosure should not be construed as limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to employ the described features in various ways in substantially any appropriately detailed structure. Furthermore, the terms and phrases used within this disclosure are not intended to be limiting, but rather to provide an understandable description of the described features.

[0014] The present disclosure relates to an integrated circuit device (device) that includes one or more data processing engines (DPEs) and / or DPE arrays. A DPE array refers to multiple hardwired circuit blocks. The multiple circuit blocks may be programmable. A DPE array may include multiple DPEs and system-on-chip (SoC) interface blocks. Generally, a DPE includes cores that can provide data processing capabilities. A DPE further includes a memory module accessible by one or more cores within the DPE. In particular embodiments, the memory module of a DPE may also be accessed by one or more other cores in different DPEs of the DPE array.

[0015] A DPE may further include a DPE interconnect. A DPE interconnect refers to circuitry that can facilitate communication with other DPEs in a DPE array and / or with different subsystems of a device that includes a DPE array. The DPE interconnect may also support configuration of the DPE. In certain embodiments, the DPE interconnect can carry control data and / or debug data.

[0016] The DPE array may be organized using any of a variety of different architectures. In one or more embodiments, the DPE array may be organized into one or more rows and one or more columns. In some cases, the columns and / or rows of DPEs are aligned. In some embodiments, each DPE may include a single core coupled to a memory module. In other embodiments, one or more or each DPE of the DPE array may be implemented to include two or more cores coupled to a memory module.

[0017] In one or more embodiments, the DPE array is implemented as a homogeneous structure, where each DPE is identical to every other DPE. In other embodiments, the DPE array is implemented as a heterogeneous structure, where the DPE array includes two or more different types of DPEs. For example, the DPE array may include DPEs with a single core, DPEs with multiple cores, DPEs with different types of cores included therein, and / or DPEs with different physical architectures.

[0018] DPE arrays may be implemented in a variety of sizes. For example, a DPE array may be implemented to span the entire width and / or length of a device die. In another example, a DPE array may be implemented to span a portion of the entire width and / or length of such a die. In further embodiments, more than one DPE array may be implemented within a die, with different DPE arrays distributed in different regions on the die, having different sizes, having different shapes, and / or having different architectures described herein (e.g., aligned rows and / or columns, homogeneous and / or heterogeneous). Furthermore, DPE arrays may include different numbers of rows of DPEs and / or different numbers of columns of DPEs.

[0019] The DPE array may be utilized with and coupled to any of a variety of different subsystems within a device. Such subsystems may include, but are not limited to, a processor and / or processor system, programmable logic, and / or a network-on-chip (NoC). In particular embodiments, the NoC may be programmable. Further examples of subsystems that may be included in a device and coupled to a DPE array may include, but are not limited to, an application-specific integrated circuit (ASIC), hardwired circuit blocks, analog and / or mixed-signal circuitry, a graphics processing unit (GPU), and / or a general-purpose processor (e.g., a central processing unit or CPU). An example of a CPU is a processor having an x86-type architecture. As used herein, the term "ASIC" may refer to an IC, die, and / or portion of a die that includes application-specific circuitry in combination with another type or types of circuitry, and / or an IC and / or die that is formed entirely of application-specific circuitry.

[0020] In certain embodiments, a device including one or more DPE arrays may be implemented using a single-die architecture, in which case the DPE array and any other subsystems utilized with the DPE array are implemented on the same die of the device. In other embodiments, a device including one or more DPE arrays may be implemented as a multi-die device including two or more dies. In some multi-die devices, one or more DPE arrays may be implemented on one die, and one or more other subsystems are implemented on one or more other dies. In other multi-die devices, one or more DPE arrays may be implemented in one or more dies in combination with one or more other subsystems of the multi-die device (e.g., the DPE array is implemented in the same die as at least one subsystem).

[0021] The DPE arrays described in this disclosure can implement an optimized digital signal processing (DSP) architecture. The DSP architecture can efficiently perform any of a variety of different operations. Examples of the types of operations that can be performed by the architecture include, but are not limited to, operations related to wireless radio, decision feedback equalization (DFE), 5G / baseband, wireless backhaul, machine learning, automotive driver assistance, embedded vision, cable access, and / or radar. The DPE arrays described herein can perform such operations while consuming less power than other solutions that utilize traditional programmable (e.g., FPGA-type) circuitry. Furthermore, DPE array-based solutions can be implemented using less die area than other solutions that utilize traditional programmable circuitry. The DPE arrays are further capable of performing operations as described herein while meeting predictable and guaranteed data throughput and latency metrics.

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

[0023] FIG. 1 illustrates an example of a device 100 that includes a DPE array 102. In the example of FIG. 1, the DPE array 102 includes an SoC interface block 104. The device 100 also includes one or more subsystems 106-1 through 106-N. In one or more embodiments, the device 100 is implemented as a system-on-chip (SoC) type device. Generally, an SoC refers to an IC that includes two or more subsystems that can interact with each other. As an example, an SoC may include a processor that executes program code and one or more other circuits. The other circuits may be implemented as hardwired circuits, programmable circuits, other subsystems, and / or any combination thereof. The circuits may operate in cooperation with each other and / or with the processor.

[0024] The DPE array 102 is formed of multiple interconnected DPEs. Each DPE is a hardwired circuit block. Each DPE may be programmable. The SoC interface block 104 may include one or more tiles. Each of the tiles of the SoC interface block 104 may be hardwired. Each of the tiles of the SoC interface block 104 may be programmable. The SoC interface block 104 provides an interface between the DPE array 102, e.g., a DPE, and other parts of the SoC, such as the subsystems 106 of the device 100. The subsystems 106-1 through 106-N may include, for example, processors and / or processor systems (e.g., CPUs, general-purpose processors, and / or GPUs), programmable It may represent one or more or any combination of logic, NoC, ASIC, analog and / or mixed-signal circuitry, and / or hardwired circuitry blocks.

[0025] In one or more embodiments, device 100 is implemented using a single-die architecture, in which case DPE array 102 and at least one subsystem 106 may be included in or implemented on a single die. In one or more other embodiments, device 100 is implemented using a multi-die architecture, in which case DPE array 102 and subsystem 106 may be implemented across two or more dies. For example, DPE array 102 may be implemented on one die, with subsystem 106 implemented on one or more other dies. In another example, SoC interface block 104 may be implemented on a different die than the DPEs of DPE array 102. In yet another example, DPE array 102 and at least one subsystem 106 may be implemented on the same die, with other subsystems and / or other DPE arrays implemented on other dies. Further examples of single-die and multi-die architectures are described in more detail below in connection with FIGS. 2, 3, 4, and 5.

[0026] 2A, 2B, 2C, and 2D (collectively referred to as "FIG. 2") illustrate an example architecture for a device including one or more DPE arrays 102. More specifically, FIG. 2 illustrates an example of a single-die architecture for device 100. For illustrative purposes, SoC interface block 104 is not shown in FIG. 2.

[0027] FIG. 2A illustrates an exemplary architecture of device 100 including a single DPE array. In the example of FIG. 2A, DPE array 102 is implemented in device 100 together with subsystem 106-1. DPE array 102 and subsystem 106-1 are implemented within the same die. DPE array 102 may extend across the entire width of the die of device 100 or may extend partially across the die of device 100. As illustrated, DPE array 102 is implemented in the top region of device 100. However, it should be understood that DPE array 102 may be implemented in another region of device 100. Thus, the placement and / or size of DPE array 102 in FIG. 2A are not intended as limitations. DPE array 102 may be coupled to subsystem 106-1 by SoC interface block 104 (not shown).

[0028] FIG. 2B illustrates an exemplary architecture of device 100 including multiple DPE arrays. In the example of FIG. 2B, the multiple DPE arrays are shown implemented as DPE array 102-1 and DPE array 102-2. FIG. 2B illustrates that multiple DPE arrays may be implemented within the same die of device 100 along with subsystem 106-1. DPE array 102-1 and / or DPE array 102-2 may extend across the entire width of the die of device 100 or may extend only partially across the die of device 100. As illustrated, DPE array 102-1 is implemented in a top region of device 100, and DPE array 102-2 is implemented in a bottom region of device 100. As noted above, the placement and / or size of DPE arrays 102-1 and 102-2 in FIG. 2B are not intended as limitations.

[0029] In one or more embodiments, DPE array 102-1 and DPE array 102-2 may be substantially similar or identical. For example, DPE array 102-1 may be identical to DPE array 102-2 with respect to the size, shape, number of DPEs, and whether the DPEs are of the same type or similar type and arrangement in each respective DPE array. In one or more other embodiments, DPE array 102-1 may be identical to DPE array 102-2 with respect to the size, shape, number of DPEs, and whether the DPEs are of the same type and arrangement in each respective DPE array. For example, DPE array 102-1 may differ from DPE array 102-2 with respect to the size, shape, number, and type of cores of the DPEs, as well as whether the DPEs are homogeneous or of different types and / or arrangements in each respective DPE array.

[0030] In one or more embodiments, each of DPE array 102-1 and DPE array 102-2 is coupled to subsystem 106-1 via its own SoC interface block (not shown). For example, a first SoC interface block may be included and used to couple DPE array 102-1 to subsystem 106-1, and a second SoC interface block may be included and used to couple DPE array 102-2 to subsystem 106-1. In another embodiment, a single SoC interface block may be used to couple both DPE array 102-1 and DPE array 102-2 to subsystem 106-1. In the latter case, for example, one of the DPE arrays may not include an SoC interface block. DPEs in that array may couple to subsystem 106-1 using the SoC interface blocks of the other DPE arrays.

[0031] 2C illustrates an exemplary architecture for device 100 including multiple DPE arrays and multiple subsystems. In the example of FIG. 2C, multiple DPE arrays are implemented and are shown as DPE array 102-1 and DPE array 102-2. FIG. 2C illustrates that multiple DPE arrays may be implemented within the same die of device 100 and that the placement or location of DPE array 102 may vary. Furthermore, DPE arrays 102-1 and 102-2 are implemented within the same die as subsystems 106-1 and 106-2.

[0032] In the example of Figure 2C, DPE array 102-1 and DPE array 102-2 do not extend across the entire width of the die of device 100. Rather, each of DPE arrays 102-1 and 102-2 extends partially across the die of device 100 and is thus implemented within an area that is a portion of the width of the die of device 100. As in the example of Figure 2B, DPE array 102-1 and DPE array 102-2 in Figure 2C may be substantially similar or identical, or may be different.

[0033] In one or more embodiments, each of DPE array 102-1 and DPE array 102-2 is coupled to subsystem 106-1 and / or subsystem 106-2 via its own SoC interface block (not shown). In an illustrative and non-limiting example, a first SoC interface block may be included and used to couple DPE array 102-1 to subsystem 106-1, and a second SoC interface block may be included and used to couple DPE array 102-2 to subsystem 106-2. In that case, each DPE array communicates with a subset of the available subsystems of device 100. In another example, a first SoC interface block may be included and used to couple DPE array 102-1 to subsystems 106-1 and 106-2, and a second SoC interface block may be included and used to couple DPE array 102-2 to subsystems 106-1 and 106-2. In yet another example, a single SoC interface block may be used to couple both DPE array 102-1 and DPE array 102-2 to subsystem 106-1 and / or subsystem 106-2. As noted above, the placement and / or size of DPE arrays 102-1 and 102-2 in FIG. 2C are not intended as limitations.

[0034] 2D illustrates another exemplary architecture of device 100 including multiple DPE arrays and multiple subsystems. In the example of FIG. 2D, multiple DPE arrays are DPE arrays 102-1 and 102-2 are shown implemented as DPE arrays 102-1 and 102-2. Figure 2D also illustrates that multiple DPE arrays may be implemented within the same die of device 100, and that the placement and / or location of DPE arrays 102 may vary. In the example of Figure 2D, DPE arrays 102-1 and 102-2 do not extend across the entire width of the die of device 100. Rather, each of DPE arrays 102-1 and 102-2 is implemented in an area that is a portion of the width of the die of device 100. Additionally, device 100 of Figure 2D includes subsystems 106-1, 106-2, 106-3, and 106-4 within the same die as DPE arrays 102-1 and 102-2. As in the example of Figure 2B, DPE arrays 102-1 and 102-2 of Figure 2D may be substantially similar or identical, or may be different.

[0035] 2D example may vary. In some cases, the DPE array may be coupled to only a subset of the subsystems available in device 100. In other cases, the DPE array may be coupled to more than one subsystem or to each subsystem in device 100.

[0036] The example of Figure 2 is provided for purposes of illustration and not limitation. A device having a single die may include one or more different DPE arrays located in different regions of the die. The number, arrangement, and / or size of the DPE arrays may vary. Furthermore, the DPE arrays may be the same or different. One or more DPE arrays may be implemented in combination with one or more and / or any combination of the different types of subsystems described within this disclosure.

[0037] In one or more embodiments, two or more DPE arrays may be configured to communicate directly with each other. For example, DPE array 102-1 may be able to communicate directly with DPE array 102-2 and / or additional DPE arrays. In particular embodiments, DPE array 102-1 may communicate with DPE array 102-2 and / or other DPE arrays via one or more SoC interface blocks.

[0038] FIG. 3 illustrates another exemplary architecture of device 100. In the example of FIG. 3, DPE array 102 is implemented as a two-dimensional array of DPEs 304, including SoC interface blocks 104. DPE array 102 may be implemented using any of a variety of different architectures, which are described in more detail below. For purposes of illustration and not limitation, FIG. 3 illustrates DPEs 304 arranged in aligned rows and aligned columns, as described in more detail in connection with FIG. 19. However, in other embodiments, DPEs 304 may be arranged such that DPEs in selected rows and / or columns are horizontally inverted or flipped relative to DPEs in adjacent rows and / or columns. An example of horizontal flipping of DPEs is described in connection with FIG. 18. In one or more other embodiments, rows and / or columns of DPEs may be offset relative to adjacent rows and / or columns. One or more or all of DPEs 304 may be implemented to include a single core, as generally described in connection with FIGS. 6 and 8, or to include two or more cores, as generally described in connection with FIG. 12.

[0039] The SoC interface block 104 can couple the DPE 304 to one or more other subsystems of the device 100. In one or more embodiments, the SoC interface block 104 is coupled to adjacent DPEs 304. For example, the SoC interface block 104 may be directly coupled to each DPE 304 in the bottom row of DPEs in the DPE array 102. In an example, the SoC interface block 104 may be directly connected to DPEs 304-1, 304-2, 304-3, 304-4, 304-5, 304-6, 304-7, 304-8, 304-9, and 304-10.

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

[0041] By way of example and not limitation, if the SoC interface block 104 is located to the left of the DPE 304, the SoC interface block 104 may be directly coupled to the left column of DPEs including DPE 304-1, DPE 304-11, DPE 304-21, and DPE 304-31. If the SoC interface block 104 is located to the right of the DPE 304, the SoC interface block 104 may be directly coupled to the right column of DPEs including DPE 304-10, DPE 304-20, DPE 304-30, and DPE 304-40. If the SoC interface block 104 is located above the DPE 304, the SoC interface block 104 may be coupled to a top row of DPEs, including DPE 304-31, DPE 304-32, DPE 304-33, DPE 304-34, DPE 304-35, DPE 304-36, DPE 304-37, DPE 304-38, DPE 304-39, and DPE 304-40. If the SoC interface block 104 is located in multiple locations, the particular DPEs directly connected to the SoC interface block 104 may vary. For example, if the SoC interface blocks are implemented as rows and / or columns in the DPE array 102, the DPEs directly coupled to the SoC interface block 104 may be adjacent to the SoC interface block 104 on one or more or each side of the SoC interface block 104.

[0042] The DPEs 304 are interconnected by DPE interconnects (not shown) that, when taken collectively, form a DPE interconnection network. Thus, the SoC interface block 104 can communicate with any DPE 304 in the DPE array 102 by communicating with one or more selected DPEs 304 in the DPE array 102 that are directly connected to the SoC interface block 104 and utilizing the DPE interconnection network formed by the DPE interconnects implemented within each respective DPE 304.

[0043] The SoC interface block 104 can couple each DPE 304 in the DPE array 102 with one or more other subsystems of the device 100. To illustrate, the device 100 includes subsystems (e.g., subsystem 106) such as an NoC 308, a programmable logic (PL) 310, a processor system (PS) 312, and / or any of the hardwired circuit blocks 314, 316, 318, 320, and / or 322. For example, the SoC interface block 104 can establish a connection between the selected DPE 304 and the PL 310. The SoC interface block 104 can also establish a connection between the selected DPE 304 and the NoC 308. Through the NoC 308, the selected DPE 304 can communicate with the PS 312 and / or the hardwired circuit blocks 320 and 322. The selected DPE 304 can communicate with the hardwired circuit blocks 314-318 via the SoC interface block 104 and the PL 310. In particular embodiments, the SoC interface block 104 may be directly coupled to one or more subsystems of the device 100. For example, the SoC interface block 104 may be directly coupled to the PS 312 and / or other hardwired circuit blocks. 4 to 322 can be considered examples of ASICs.

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

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

[0046] NoC 308 provides connections to PL 310, PS 312, and selected ones of the hardwired circuit blocks (e.g., circuit blocks 320 and 322). In the example of Figure 3, NoC 308 is programmable. For a programmable NoC used with other programmable circuits, the nets to be routed through NoC 308 are unknown until a user circuit design is created for implementation within device 100. NoC 308 can be programmed by loading internal configuration registers with configuration data that defines how elements within NoC 308, such as switches and interfaces, are configured and how data is passed from switch to switch and between NoC interfaces.

[0047] The NoC 308 is fabricated as part of the device 100 and is not physically modifiable, but can be programmed to establish connectivity between different master and slave circuits of a user circuit design. In this regard, the NoC 308 can accommodate different circuit designs, each having a different combination of master and slave circuits implemented in different locations within the device 100 that can be coupled by the NoC 308. The NoC 308 can be programmed to route data, e.g., application data and / or configuration data, between the master and slave circuits of the user circuit design. For example, the NoC 308 can be programmed to couple different user-specified circuits implemented within the PL 310 to the PS 312, to different DPEs of the DPE 304 via the SoC interface block 104, to different hardwired circuit blocks, and / or to different circuits and / or systems external to the device 100.

[0048] PL310 is a circuit that can be programmed to perform a specified function. As an example, PL310 may be implemented as a field programmable gate array (FPGA) circuit. PL 310 may include an array of programmable circuit blocks. Examples of programmable circuit blocks within PL 310 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), clock managers, and / or delay-locked loops (DLLs).

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

[0050] In the example of Figure 3, PL 310 is shown in two separate sections. In another example, PL 310 may be implemented as a unified region of programmable circuitry. In yet another example, PL 310 may be implemented as three or more distinct regions of programmable circuitry. The particular organization of PL 310 is not intended as a limitation.

[0051] In the example of FIG. 3 , PS 312 is implemented as a hardwired circuit fabricated as part of device 100. PS 312 may be implemented as or include any of a variety of different processor types. For example, PS 312 may be implemented as a separate processor, e.g., a single core capable of executing program code. In another example, PS 312 may be implemented as a multi-core processor. In yet another example, PS 312 may include one or more cores, modules, coprocessors, interfaces, and / or other resources. PS 312 may be implemented using any of a variety of different types of architectures. Exemplary architectures that may be used to implement PS 312 may include, but are not limited to, an ARM processor architecture, an x86 processor architecture, a GPU architecture, a mobile processor architecture, a DSP architecture, or other suitable architecture capable of executing computer-readable instructions or program code.

[0052] The circuit blocks 314-322 may be implemented as any of a variety of different hardwired circuit blocks. The hardwired circuit blocks 314-322 may be customized to perform dedicated functions. Examples of the circuit blocks 314-322 include, but are not limited to, input / output blocks (IOBs), transceivers, or other specialized circuit blocks. As mentioned above, the circuit blocks 314-322 may be considered examples of ASICs.

[0053] The example of Figure 3 illustrates an architecture that may be implemented in a device including a single die. While the DPE array 102 is shown as occupying the entire width of the device 100, in other embodiments, the DPE array 102 may occupy less than the entire width of the device 100 and / or be located in a different region of the device 100. Additionally, the number of DPEs 304 included may vary. Thus, the particular number of columns and / or rows of DPEs 304 may differ from that shown in Figure 3.

[0054] In one or more other embodiments, a device such as device 100 may include: 3. The DPE array 102 may include two or more DPE arrays 102 located in different areas of the DPE array 102. For example, additional DPE arrays may be located below the circuit blocks 320 and 322.

[0055] 2-3 illustrate an exemplary architecture for a device including a single die. In one or more other embodiments, device 100 may be implemented as a multi-die device including one or more DPE arrays 102.

[0056] 4A and 4B (collectively referred to as "FIG. 4") illustrate a multi-die implementation of device 100. A multi-die device is a device or IC that includes two or more dies in a single package.

[0057] FIG. 4A shows a topographical view of device 100. In the example of FIG. 4A, device 100 is realized as a "stacked die" type device formed by stacking multiple dies. Device 100 includes an interposer 402, a die 404, a die 406, and a substrate 408. Each of dies 404 and 406 is attached to a surface, e.g., the top surface, of interposer 402. In one embodiment, dies 404 and 406 are attached to interposer 402 using flip-chip technology. Interposer 402 is attached to the top surface of substrate 408.

[0058] In the example of Figure 4A, interposer 402 is a die having a flat surface on which dies 404 and 406 are stacked horizontally. As shown, dies 404 and 406 are arranged side-by-side on the flat surface of interposer 402. The number of dies shown on interposer 402 in Figure 4A is for illustration purposes and not limitation. In other embodiments, more than two dies may be attached to interposer 402.

[0059] Interposer 402 provides a common mounting surface and electrical coupling for each of dies 404 and 406. Fabrication of interposer 402 can include one or more process steps that allow for the deposition of one or more conductive layers that are patterned to form wires. These conductive layers may be formed from aluminum, gold, copper, nickel, various silicides, and / or other suitable materials. Interposer 402 can be fabricated using one or more additional process steps that allow for the deposition of one or more dielectric or insulating layers, such as silicon dioxide. Interposer 402 can also include vias and through vias (TVs). The TVs can be through silicon vias (TSVs), through glass vias (TGVs), or other via structures, depending on the specific materials used to implement interposer 402 and its substrate. If interposer 402 is implemented as a passive die, interposer 402 can only have various types of solder bumps, vias, wires, TVs, and under bump metallization (UBM). When implemented as an active die, interposer 402 may include additional process layers that form one or more active devices, such as transistors, diodes, and other electrical devices that include PN junctions.

[0060] Each of dies 404 and 406 may be implemented as a passive die or an active die including one or more active devices. For example, one or more DPE arrays, when implemented as active dies, may be implemented on one or both of dies 404 and / or 406. In one or more embodiments, die 404 may include one or more DPE arrays, and die 406 may implement any of the different subsystems described herein. The examples provided herein are for illustrative purposes and are not intended to be limiting. For example, device 100 may include three or more dies, the dies being of different types and / or functions.

[0061] FIG. 4B is a side cross-sectional view of the device 100 of FIG. 4A. FIG. 4B shows a view of the device 100 from FIG. 4A taken along section line 4B-4B. Each of the dies 404 and 406 is electrically and mechanically coupled to a first planar surface of the interposer 402 via solder bumps 410. In one example, the solder bumps 410 are implemented as microbumps. Additionally, any of a variety of other techniques may be used to attach the dies 404 and 406 to the interposer 402. For example, bond wires or edge wires may be used to mechanically and electrically attach the dies 404 and 406 to the interposer 402. In another example, an adhesive material may be used to mechanically attach the dies 404 and 406 to the interposer 402. Attaching the dies 404 and 406 to the interposer 402 using solder bumps 410, as shown in FIG. 4B, is provided for illustrative purposes and is not intended as a limitation.

[0062] The interposer 402 includes one or more conductive layers 412, indicated by dashed or dotted lines within the interposer 402. The conductive layers 412 are realized using any of the various metal layers described above. The conductive layers 412 are processed to form patterned metal layers that realize the wires 414 of the interposer 402. Wires realized within the interposer 402 that couple at least two different dies, e.g., dies 404 and 406, are referred to as inter-die wires. FIG. 4B shows the wires 414 considered inter-die wires for illustrative purposes. The wires 414 pass inter-die signals between the die 404 and the die 406. For example, each of the wires 414 couples a solder bump 410 under the die 404 to a solder bump 410 under the die 406, thereby enabling the exchange of inter-die signals between the dies 404 and 406. The wires 414 may be data or power lines. A power line may be a wire that carries a voltage potential or may be a wire that has a ground or reference voltage potential.

[0063] Different conductive layers 412 may be coupled using vias 416. Generally, via structures are used to realize vertical conductive paths (e.g., conductive paths perpendicular to the process layers of a device). In this regard, the vertical portions of wires 414 that contact solder bumps 410 are realized as vias 416. By using multiple conductive layers to realize interconnections within interposer 402, a larger number of signals may be routed and more complex signal routing may be achieved within interposer 402.

[0064] Solder bumps 418 can be used to mechanically and electrically couple the second planar surface of interposer 402 to substrate 408. In a particular embodiment, solder bumps 418 are implemented as controlled collapse chip connection (C4) balls. includes conductive paths (not shown) that couple different solder bumps 418 to one or more nodes underneath substrate 408. Thus, one or more of solder bumps 418 couple circuitry within interposer 402, via circuitry or wiring within substrate 408, to nodes external to device 100.

[0065] The TVs 420 are vias that form electrical connections that vertically traverse the interposer 402, e.g., extend through a substantial portion, if not the entirety, of the interposer 402. The TVs 420, like wires and vias, may be formed from any of a variety of different conductive materials, including, but not limited to, copper, aluminum, gold, nickel, various silicides, and / or other suitable materials. As shown, each of the TVs 420 extends from the bottom surface of the interposer 402 to the conductive layer 412 of the interposer 402. The TVs 420 may further be coupled to the solder bumps 410 through one or more of the conductive layers 412 in combination with one or more vias 416.

[0066] 5A, 5B, 5C, 5D, 5E, 5F, and 5G (collectively "FIG. 5"). 5 illustrates an exemplary multi-die implementation of device 100. The example of FIG. 5 can be implemented as described in connection with FIG.

[0067] Referring to FIG. 5A, die 404 includes one or more DPE arrays 102 and die 406 implements PS 312.

[0068] 5B, die 404 includes one or more DPE arrays 102, and die 406 implements ASIC 504. ASIC 504 may be implemented as any of a variety of different customized circuits suitable for performing specific or specialized operations.

[0069] Referring to FIG. 5C, die 404 includes one or more DPE arrays 102 and die 406 implements PL 310.

[0070] 5D, die 404 includes one or more DPE arrays 102, and die 406 implements analog and / or mixed (analog / mixed) signal circuitry 508. Analog / mixed signal circuitry 508 may include one or more radio receivers, radio transmitters, amplifiers, analog-to-digital converters, digital-to-analog converters, or other analog and / or digital circuitry.

[0071] 5E, 5F, and 5G show an example of a device 100 having three dies 404, 406, and 510. Referring to FIG. 5E, device 100 includes dies 404, 406, and 510. Die 404 includes one or more DPE arrays 102. Die 406 includes PL 310. Die 510 includes ASIC 504.

[0072] 5F, die 404 includes one or more DPE arrays 102. Die 406 includes PL 310. Die 510 includes analog / mixed-signal circuitry 508.

[0073] 5G, die 404 includes one or more DPE arrays 102. Die 406 includes ASIC 504. Die 510 includes analog / mixed-signal circuitry 508. In one or more embodiments, a PS (e.g., PS 312) is an example of an ASIC.

[0074] 5, each of the dies 406 and / or 510 is shown as including a particular type of subsystem. In other embodiments, the dies 404, 406, and / or 510 can include one or more subsystems in combination with one or more DPE arrays 102. Furthermore, the dies 404, 406, and / or 510 can include two or more different types of subsystems. Thus, any one or more of the dies 404, 406, and / or 510 can include one or more DPE arrays 102 in any combination with one or more subsystems.

[0075] In one or more embodiments, interposer 402 and dies 404, 406, and / or 510 may be realized using the same IC manufacturing technology (e.g., feature size). In one or more other embodiments, interposer 402 may be realized using a particular IC manufacturing technology, and dies 404, 406, and / or 510 are realized using a different IC manufacturing technology. In yet other embodiments, dies 404, 406, and / or 510 may be realized using different IC manufacturing technologies, which may be the same or different from the IC manufacturing technology used to realize interposer 402. By using different IC manufacturing technologies for different dies and / or interposers, a lower cost and / or more reliable IC manufacturing technology may be used for a particular die. While other IC manufacturing techniques capable of forming smaller feature sizes may be used for other dies, for example, more mature manufacturing techniques may be used to realize interposer 402, and other techniques capable of forming smaller feature sizes may be used to realize active dies and / or dies including DPE array 102.

[0076] 5 shows a multi-die implementation of device 100 including two or more dies mounted on an interposer. The number of dies shown is for illustrative purposes and not limitation. In other embodiments, device 100 may include more than three dies mounted on interposer 402.

[0077] In one or more other embodiments, a multi-die version of device 100 may be implemented using an architecture other than the stacked die architecture of FIG. 4 . For example, device 100 may be implemented as a multi-chip module (MCM). An MCM implementation of device 100 may be implemented using one or more pre-packaged ICs mounted on a circuit board having a form factor and / or footprint intended to mimic an existing chip package. In another example, an MCM implementation of device 100 may be implemented by integrating two or more dies on a high-density interconnect substrate. In yet another example, an MCM implementation of device 100 may be implemented as a “chip stack” package.

[0078] Using a DPE array as described herein in combination with one or more other subsystems, whether implemented in a single-die device or a multi-die device, increases the processing power of the device while keeping area usage and power consumption low. For example, one or more DPE arrays can be used to accelerate certain operations in hardware and / or perform functions offloaded from one or more of the device's subsystems described herein. For example, when used with a PS, the DPE array can be used as a hardware accelerator. The PS can offload operations performed by the DPE array or portions thereof. In other examples, a DPE array can be used to perform computationally resource-intensive operations, such as generating digital predistortion to be applied to analog / mixed-signal circuitry.

[0079] It should be understood that any of the various combinations of DPE arrays and / or other subsystems described herein in connection with Figures 1, 2, 3, 4 and / or 5 may be implemented in either single-die or multi-die type devices.

[0080] In various examples described herein, the SoC interface block is implemented within the DPE array. In one or more other embodiments, the SoC interface block may be implemented external to the DPE array. For example, the SoC interface block may be implemented as a circuit block, such as a standalone circuit block, separate from the circuit blocks that implement multiple DPEs.

[0081] 6 illustrates an exemplary architecture of a DPE 304 of a DPE array 102. In the example of FIG. 6, the DPE 304 includes a core 602, a memory module 604, and a DPE interconnect 606.

[0082] Core 602 provides the data processing capabilities of DPE 304. Core 602 may be implemented as any of a variety of different processing circuits. In the example of FIG. 6, core 602 is optionally In one or more embodiments, core 602 is implemented as a processor capable of executing program code, e.g., computer-readable instructions. In that case, program memory 608 is included and may store instructions executed by core 602. Core 602 may be implemented, for example, as a CPU, GPU, DSP, vector processor, or other type of processor capable of executing instructions. Core may be implemented using any of the various CPU and / or processor architectures described herein. In another example, core 602 is implemented as a very long instruction word (VLIW) vector processor or DSP.

[0083] In particular embodiments, program memory 608 is implemented as dedicated program memory that is private to core 602. Program memory 608 may be used only by cores of the same DPE 304. Thus, program memory 608 may be accessed only by core 602 and is not shared with any other DPE or components of another DPE. Program memory 608 may include a single port for read and write operations. Program memory 608 may support program compression and is addressable using a memory-mapped network portion of DPE interconnect 606, described in more detail below. For example, via the memory-mapped network of DPE interconnect 606, program memory 608 may be loaded with program code that can be executed by core 602.

[0084] In one or more embodiments, program memory 608 may support one or more error detection and / or error correction mechanisms. For example, program memory 608 may be implemented to support parity checking by adding parity bits. In another example, program memory 608 may be an error correcting code (ECC) memory capable of detecting and correcting various types of data corruption. In another example, program memory 608 may support both ECC and parity checking. The different types of error detection and / or error correction described herein are provided for illustrative purposes and are not intended to limit the described embodiments. Other error detection and / or error correction techniques may be used with program memory 608 other than those listed.

[0085] In one or more embodiments, core 602 may have a customized architecture to support application-specific instruction sets. For example, core 602 may be customized for a wireless application and configured to execute wireless-specific instructions. In another example, core 602 may be customized for machine learning and configured to execute machine learning-specific instructions.

[0086] In one or more other embodiments, core 602 is implemented as a hardwired circuit, such as a hardware-implemented intellectual property (IP) core, that is dedicated to performing a specific operation or operations. In this case, core 602 may not execute program code. In embodiments in which core 602 does not execute program code, program memory 608 may be omitted. As an illustrative and non-limiting example, core 602 may be implemented as a hardware-implemented forward error correction (FEC) engine or other circuit block.

[0087] Core 602 may include configuration registers 624. Configuration registers 624 may be loaded with configuration data to control the operation of core 602. In one or more embodiments, core 602 may be activated and / or deactivated based on the configuration data loaded into configuration registers 624. In the example of FIG. 6, configuration registers 624 are addressable (e.g., may be read and / or written) via a memory-mapped network of DPE interconnect 606, which is described in more detail below. ).

[0088] In one or more embodiments, memory module 604 may store data used by core(s) 602 and / or data generated by core(s) 602. For example, memory module 604 may store application data. Memory module 604 may include read / write memory, such as random access memory. Thus, memory module 604 is capable of storing data that may be read and consumed by core(s) 602. Memory module 604 may also store data (e.g., results) that is written by core(s) 602.

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

[0090] 3, for example, DPEs 304-14, 304-16, 304-5, and 304-25 are considered DPEs proximate to DPE 304-15. In one example, cores within each of DPEs 304-16, 304-5, and 304-25 can read from and write to the memory module within DPE 304-15. In particular embodiments, only the proximate DPEs adjacent to the memory module can access the memory module of DPE 304-15. For example, DPE 304-14 may be proximate to DPE 304-15 but not adjacent to the memory module of DPE 304-15 because the core of DPE 304-15 may be located between the core of DPE 304-14 and the memory module of DPE 304-15. Thus, in particular embodiments, the core of DPE 304-14 may not access the memory module of DPE 304-15.

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

[0092] In other examples, more than four memory interfaces may be available. Such other memory interfaces may be used by DPEs diagonally opposite DPE 304-15. -15. For example, if cores within DPEs such as DPEs 304-14, 304-24, 304-26, 304-4, and / or 304-6 are also coupled to available memory interfaces of memory modules within DPE 304-15, then such other DPEs can also access the memory modules of DPE 304-15.

[0093] Memory module 604 may include configuration registers 636, which may be loaded with configuration data to control the operation of memory module 604. In the example of Figure 6, configuration registers 636 (and 624) are addressable (e.g., may be read and / or written) via a memory-mapped network of DPE interconnect 606, which is described in more detail below.

[0094] 6, the DPE interconnect 606 is dedicated to the DPE 304. The DPE interconnect 606 facilitates various operations, including communication between the DPE 304 and one or more other DPEs in the DPE array 102 and / or communication with other subsystems of the device 100. The DPE interconnect 606 further enables configuration, control, and debugging of the DPE 304.

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

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

[0097] In the example of FIG. 6, the first network of DPE interconnect 606 is formed by a stream switch 626 and one or more stream interfaces. As shown, stream switch 626 includes multiple stream interfaces (abbreviated as "SI" in FIG. 6). In one or more embodiments, each stream interface may include one or more masters (e.g., master interfaces or outputs) and / or one or more slaves (e.g., slave interfaces or inputs). Each master may be an independent output having a particular bit width. For example, each master included in a stream interface may be an independent AXI master. Each slave may be an independent input having a particular bit width. For example, each slave included in a stream interface may be an independent AXI slave.

[0098] Stream interfaces 610-616 are used to communicate with other DPEs in DPE array 102 and / or SoC interface block 104. For example, each of stream interfaces 610, 612, 614, and 616 can communicate in a different one of the four cardinal directions. In the example of FIG. 6, stream interfaces Stream interface 610 communicates with the DPE to the left (west). Stream interface 612 communicates with the DPE to the top (north). Stream interface 614 communicates with the DPE to the right (east). Stream interface 616 communicates with the DPE or SoC interface block 104 to the bottom (south).

[0099] The stream interface 628 is used to communicate with the core 602. The core 602 includes, for example, a stream interface 638 that connects to the stream interface 628, thereby allowing the core 602 to communicate directly with other DPEs 304 via the DPE interconnect 606. For example, the core 602 may include instructions or hardwired circuitry that allows the core 602 to send and / or receive data directly via the stream interface 638. The stream interface 638 may be blocking or non-blocking. In one or more embodiments, the core 602 may stall if it attempts to read from an empty stream or write to a full stream. In other embodiments, attempting to read from an empty stream or write to a full stream may not stall the core 602. Rather, the core 602 may continue to execute or operate.

[0100] The stream interface 630 is used to communicate with the memory module 604. The memory module 604, for example, includes a stream interface 640 that connects to the stream interface 630, thereby allowing other DPEs 304 to communicate with the memory module 604 via the DPE interconnect 606. The stream switch 626 can allow non-neighboring DPEs and / or DPEs not coupled to the memory interface of the memory module 604 to communicate with the cores 602 and / or memory modules 604 via the DPE interconnect network formed by the DPE interconnects of each DPE 304 in the DPE array 102.

[0101] 3, using DPE 304-15 as a reference point, stream interface 610 is coupled to and can communicate with another stream interface located in the DPE interconnect of DPE 304-14. Stream interface 612 is coupled to and can communicate with another stream interface located in the DPE interconnect of DPE 304-25. Stream interface 614 is coupled to and can communicate with another stream interface located in the DPE interconnect of DPE 304-16. Stream interface 616 is coupled to and can communicate with another stream interface located in the DPE interconnect of DPE 304-5. Thus, core 602 and / or memory module 604 can also communicate with any DPE in DPE array 102 via the DPE interconnect within the DPE.

[0102] The stream switch 626 may also be used to interface to subsystems such as the PL 310 and / or NoC 308. In general, the stream switch 626 may be programmed to operate as a circuit-switched stream interconnect or a packet-switched stream interconnect. A circuit-switched stream interconnect can provide point-to-point dedicated streams suitable for high-bandwidth communication between DPEs. A packet-switched stream interconnect allows for stream sharing, time-multiplexing multiple logical streams onto one physical stream for medium-bandwidth communication.

[0103] The stream switch 626 may include a configuration register (abbreviated as "CR" in FIG. 6) 634. Configuration data may be written to the configuration register 634 through the memory-mapped network of the DPE interconnect 606. The configuration data loaded into the configuration register 634 may be written to the DPE interconnect 606 through the memory-mapped network of the DPE interconnect 606. The configuration data determines with which other DPEs and / or subsystems (e.g., NoC 308, PL 310, and / or PS 312) DPE 304 communicates, and whether such communications are established as circuit-switched point-to-point connections or packet-switched connections.

[0104] It should be understood that the number of stream interfaces shown in FIG. 6 is for illustration purposes and not limitation. In other embodiments, stream switch 626 may include fewer stream interfaces. In particular embodiments, stream switch 626 may include more stream interfaces to facilitate connection to other components and / or subsystems within the device. For example, additional stream interfaces may be coupled to other non-neighboring DPEs, such as DPEs 304-24, 304-26, 304-4, and / or 304-6. In one or more other embodiments, stream interfaces may be included to couple a DPE, such as DPE 304-15, to other DPEs located one or more DPEs away. For example, one or more stream interfaces may be included that allow DPE 304-15 to directly couple to stream interfaces in DPE 304-13, DPE 304-16, or other non-neighboring DPEs.

[0105] The second network of DPE interconnect 606 is formed by memory-mapped switch 632. Memory-mapped switch 632 includes multiple memory-mapped interfaces (abbreviated as "MMI" in FIG. 6). In one or more embodiments, each memory-mapped interface may include one or more masters (e.g., master interfaces or outputs) and / or one or more slaves (e.g., slave interfaces or inputs). Each master may be an independent output having a particular bit-width. For example, each master included in a memory-mapped interface may be an independent AXI master. Each slave may be an independent input having a particular bit-width. For example, each slave included in a memory-mapped interface may be an independent AXI slave.

[0106] 6, memory-mapped switch 632 includes memory-mapped interfaces 620, 622, 642, 644, and 646. It should be understood that memory-mapped switch 632 may include additional or fewer memory-mapped interfaces. For example, for each component of a DPE that may be read and / or written using memory-mapped switch 632, memory-mapped switch 632 may include a memory-mapped interface coupled to such component. Furthermore, to facilitate reading and / or writing of memory addresses, the component itself may include a memory-mapped interface coupled to a corresponding memory-mapped interface in memory-mapped switch 632.

[0107] 6, memory-mapped interface 620 can receive configuration data used to configure DPE 304. Memory-mapped interface 620 can receive configuration data from DPEs located below DPE 304 and / or from SoC interface block 104. Memory-mapped interface 622 can transmit the configuration data received by memory-mapped interface 620 to one or more other DPEs above DPE 304, core 602 (e.g., program memory 608 and / or configuration registers 624), memory modules 604 (eg, memory and / or configuration registers 636 in memory module 604 ), and / or configuration registers 634 in stream switch 626 .

[0108] In particular embodiments, memory-mapped interface 620 communicates with a lower DPE or tile of SoC interface block 104, as described herein. Memory-mapped interface 622 communicates with an upper DPE. Referring again to FIG. 3 and using DPE 304-15 as a reference point, memory-mapped interface 620 can be coupled to and communicate with another memory-mapped interface located on the DPE interconnect of DPE 304-5. Memory-mapped interface 622 can be coupled to and communicate with another memory-mapped interface located on the DPE interconnect of DPE 304-25. In one or more embodiments, memory-mapped switch 632 conveys control and / or debug data from south to north. In other embodiments, memory-mapped switch 632 can also pass data from north to south.

[0109] Memory mapped interface 646 can be coupled to a memory mapped interface (not shown) in memory module 604 to facilitate reading and / or writing to configuration registers 636 and / or memory in memory module 604. Memory mapped interface 644 can be coupled to a memory mapped interface (not shown) in core 602 to facilitate reading and / or writing to program memory 608 and / or configuration registers 624. Memory mapped interface 642 can be coupled to configuration registers 634 to read and / or write to configuration registers 634.

[0110] 6, memory-mapped switch 632 can communicate with the circuits above (e.g., north) and below (e.g., south). In one or more other embodiments, memory-mapped switch 632 includes additional memory-mapped interfaces that are coupled to memory-mapped interfaces of the memory-mapped switches of the left and / or right DPEs. Using DPE 304-15 as a reference point, such additional memory-mapped interfaces can be connected to memory-mapped switches located at DPE 304-14 and / or DPE 304-16, thereby facilitating communication of configuration, control, and debug data between DPEs in the horizontal as well as vertical directions.

[0111] In other embodiments, memory-mapped switch 632 may include additional memory-mapped interfaces connected to memory-mapped switches in DPEs diagonal to DPE 304. For example, using DPE 304-15 as a reference point, such additional memory-mapped interfaces may be coupled to memory-mapped switches located at DPEs 304-24, 304-26, 304-4, and / or 304-6, thereby facilitating the communication of configuration, control, and debug information diagonally between DPEs.

[0112] The DPE interconnect 606 is coupled to the DPE interconnect and / or SoC interface block 104 of each neighboring DPE, depending on the location of the DPE 304. Collectively, the DPE interconnects of the DPEs 304 form a DPE interconnect network (which may include a stream network and / or a memory-mapped network). The configuration registers of each DPE's stream switch can be programmed by loading configuration data through the memory-mapped switch. Through configuration, the stream The home switch and / or stream interface are programmed to establish connections, either packet-switched or circuit-switched, with one or more other DPEs 304 and / or other endpoints in either the SoC interface block 104.

[0113] In one or more embodiments, the DPE array 102 is mapped into the address space of a processor system, such as the PS 312. Thus, any configuration register and / or memory within the DPE 304 may be accessed via a memory-mapped interface. For example, memory within the memory module 604, the program memory 608, the configuration register 624 within the core 602, the configuration register 636 within the memory module 604, and / or the configuration register 634 may be read and / or written via the memory-mapped switch 632.

[0114] In the example of Figure 6, the memory-mapped interface can receive configuration data for the DPE 304. The configuration data can include program code to be loaded into program memory 608 (if included), configuration data to load into configuration registers 624, 634, and / or 636, and / or data to be loaded into memory (e.g., memory banks) of the memory module 604. In the example of Figure 6, the configuration registers 624, 634, and 636 are shown as being located within the particular circuit structures they are intended to control, e.g., the core 602, the stream switch 626, and the memory module 604. The example of Figure 6 is for illustrative purposes only and illustrates that elements within the core 602, the memory module 604, and / or the stream switch 626 can be programmed by loading configuration data into corresponding configuration registers. In other embodiments, the configuration registers can be consolidated within particular regions of the DPE 304, despite controlling the operation of components distributed throughout the DPE 304.

[0115] Thus, the stream switch 626 may be programmed by loading configuration data into the configuration registers 634. The configuration data programs the stream switch 626 and / or the stream interfaces 610-616 and / or 628-630 to operate as a circuit-switched stream interface between two different DPEs and / or other subsystems, or as a packet-switched stream interface coupled to a selected DPE and / or other subsystem. Thus, the connections established by the stream switch 626 to other stream interfaces are programmed by loading the appropriate configuration data into the configuration registers 634 to establish actual connections or application data paths within the DPE 304 with other DPEs and / or with other subsystems of the device 100.

[0116] Figure 7 shows an example of connectivity between multiple DPEs 304. In the example of Figure 7, the architecture shown in Figure 6 is used to implement each of DPEs 304-14, 304-15, 304-24, and 304-25. Figure 7 shows an embodiment in which stream interfaces are interconnected between adjacent DPEs (on each side and above and below), and memory-mapped interfaces are connected to the DPEs above and below. For illustrative purposes, the stream switches and memory-mapped switches are not shown.

[0117] As noted, other embodiments may include additional memory-mapped interfaces to couple the DPEs vertically and horizontally as shown, and the memory-mapped interfaces may support bidirectional communication in the vertical and / or horizontal directions.

[0118] The memory-mapped interfaces 620 and 622 can implement a shared transaction switching network in which transactions propagate from memory-mapped switch to memory-mapped switch. Each of the memory-mapped switches can dynamically route transactions based on, for example, address. Transactions can be stalled at any given memory-mapped switch. The memory-mapped interfaces 620 and 622 allow other subsystems of the device 100 to access resources (e.g., components) of the DPE 304.

[0119] In particular embodiments, subsystems of device 100 can read the internal state of any register and / or memory element of the DPE via memory-mapped interfaces 620 and / or 622. Via memory-mapped interfaces 620 and / or 622, subsystems of device 100 can read and / or write to any configuration register within program memory 608 and DPE 304.

[0120] Stream interfaces 610-616 (e.g., stream switch 626) can provide deterministic throughput with guaranteed fixed latency from source to destination. In one or more embodiments, stream interfaces 610 and 614 can receive four 32-bit streams and output four 32-bit streams. In one or more embodiments, stream interface 614 can receive four 32-bit streams and output six 32-bit streams. In a particular embodiment, stream interface 616 can receive four 32-bit streams and output four 32-bit streams. The number of streams and stream sizes of each stream interface are given for illustrative purposes and are not intended as limitations.

[0121] Figure 8 illustrates further aspects of the exemplary architecture of Figure 6. In the example of Figure 8, details regarding the DPE interconnect 606 are not shown. Figure 8 shows the connectivity of the core 602 with other DPEs via shared memory. Figure 8 also shows additional aspects of the memory module 604. For purposes of explanation, Figure 8 refers to DPE 304-15.

[0122] As shown, memory module 604 includes multiple memory interfaces 802, 804, 806, and 808. In FIG. 8, memory interfaces 802 and 808 are abbreviated as "MI." Memory module 604 also includes multiple memory banks 812-1 through 812-N. In a particular embodiment, memory module 604 includes eight memory banks. In other embodiments, memory module 604 may include fewer or more memory banks 812. In one or more embodiments, each memory bank 812 is single-ported, thereby allowing a maximum of one access to each memory bank per clock cycle. If memory module 604 includes eight memory banks 812, such a configuration supports eight parallel accesses per clock cycle. In other embodiments, each memory bank 812 is dual-ported or multi-ported, thereby allowing more parallel accesses per clock cycle.

[0123] In one or more embodiments, memory module 604 may support one or more error detection and / or error correction mechanisms. For example, memory bank 812 may be implemented to support parity checking by adding parity bits. In another example, memory bank 812 may be implemented to detect various types of data corruption. The memory bank 604 may be an ECC memory capable of detecting and correcting errors. In another example, the memory bank 812 may support both ECC and parity checking. The different types of error detection and / or error correction described herein are provided for illustrative purposes and are not intended to limit the described embodiments. Other error detection and / or error correction techniques may be used with the memory module 604 other than those listed.

[0124] In one or more other embodiments, error detection and / or error correction mechanisms may be implemented for each memory bank 812. For example, one or more of the memory banks 812 may include parity checking, while one or more others of the memory banks 812 may be implemented as ECC memory. Further, other ones of the memory banks 812 may support both ECC and parity checking. Thus, different combinations of error detection and / or error correction may be supported by different memory banks 812 and / or combinations of memory banks 812.

[0125] In the example of FIG. 8 , each of memory banks 812-1 through 812-N includes an arbiter 814-1 through 814-N, respectively. Each of the arbiters 814 is capable of generating a stall signal in response to detecting a conflict. Each arbiter 814 may include arbitration logic. Additionally, each arbiter 814 may include a crossbar. Thus, any master can write to any particular one or more of the memory banks 812. As described in connection with FIG. 6 , the memory module 604 may include a memory-mapped interface (not shown) that communicates with the memory-mapped interface 646 of the memory-mapped switch 632. The memory-mapped interface in the memory module 604 may be connected to communication lines in the memory module 604 that couple the DMA engine 816, memory interfaces 802, 804, 806, and 808, and arbiter 814, for reading and / or writing to the memory banks 812.

[0126] Memory module 604 further includes a direct memory access (DMA) engine 816. In one or more embodiments, DMA engine 816 includes at least two interfaces. For example, one or more interfaces can receive an input data stream from DPE interconnect 606 and write the received data to memory banks 812. One or more other interfaces can read data from memory banks 812 and transmit the data through a stream interface of DPE interconnect 606. For example, DMA engine 816 can include stream interface 640 of FIG. 6.

[0127] The memory module 604 can operate as a shared memory that can be accessed by multiple different DPEs. In the example of FIG. 8 , the memory interface 802 is coupled to the core 602 via a core interface 828 included in the core 602. The memory interface 802 provides the core 602 with access to the memory bank 812 via an arbiter 814. The memory interface 804 is coupled to the core of the DPE 304-25. The memory interface 804 provides the core of the DPE 304-25 with access to the memory bank 812. The memory interface 806 is coupled to the core of the DPE 304-16. The memory interface 806 provides the core of the DPE 304-16 with access to the memory bank 812. The memory interface 808 is coupled to the core of the DPE 304-5. The memory interface 808 provides the core of the DPE 304-5 with access to the memory bank 812. 8, each DPE that has a shared boundary with memory module 604 of DPE 304-15 can read and write to memory bank 812. 4-15 does not have direct access to memory module 604.

[0128] The memory mapped switch 632 can write data to the memory bank 812. For example, the memory mapped switch 632 may be coupled to a memory mapped interface (not shown) located in the memory module 604, which in turn is coupled to the arbiter 814. Thus, certain data stored in the memory module 604 may be controlled, e.g., written, as part of a configuration, control, and / or debug process.

[0129] Core 602 can access memory modules of other nearby DPEs via core interfaces 830, 832, and 834. In the example of FIG. 8, core interface 834 is coupled to the memory interface of DPE 304-25. Thus, core 602 can access the memory module of DPE 304-25 via core interface 834 and the memory interface contained within the memory module of DPE 304-25. Core interface 832 is coupled to the memory interface of DPE 304-14. Thus, core 602 can access the memory module of DPE 304-14 via core interface 832 and the memory interface contained within the memory module of DPE 304-14. Core interface 830 is coupled to the memory interface within DPE 304-5. Thus, core 602 can access the memory module of DPE 304-5 via core interface 830 and the memory interface contained within the memory module of DPE 304-5. As described above, the core 602 can access the memory module 604 within the DPE 304-15 via the core interface 828 and the memory interface 802.

[0130] 8, core 602 can read from and write to any of the memory modules of the DPEs (e.g., DPEs 304-25, 304-14, and 304-5) that share a boundary with core 602 in DPE 304-15. In one or more embodiments, core 602 can view the memory modules in DPEs 304-25, 304-15, 304-14, and 304-5 as a single contiguous memory. Core 602 can generate addresses for reads and writes assuming this contiguous memory model. Based on the generated addresses, core 602 can direct read and / or write requests to the appropriate core interfaces 828, 830, 832, and / or 834.

[0131] In one or more other embodiments, memory module 604 includes additional memory interfaces that may be coupled to other DPEs. For example, memory module 604 may include memory interfaces coupled to cores of DPEs 304-24, 304-26, 304-4, and / or 304-5. In one or more other embodiments, memory module 604 may include one or more memory interfaces used to connect to cores of DPEs that are not neighboring DPEs. For example, such additional memory interfaces may be connected to cores of DPEs in the same row, the same column, or diagonally separated from DPE 304-15 by one or more other DPEs. Thus, the number of memory interfaces in memory module 604 and the particular DPEs to which such memory interfaces are connected, as shown in FIG. 8, are for purposes of illustration and not limitation.

[0132] As described above, core 602 can map read and / or write operations in the correct direction through core interfaces 828, 830, 832, and / or 834 based on the address of such operations. When generating an address for an access, the core 602 can decode the address to determine the direction (e.g., the particular DPE to be accessed) and forward the memory operation to the correct core interface in that determined direction.

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

[0134] As discussed, the DMA engine 816 may include one or more stream-memory interfaces (e.g., stream interface 640). Through the DMA engine 816, application data can be received from other sources within the device 100 and stored in the memory module 604. For example, data can be received by the stream switch 626 from other DPEs that share and / or do not share a boundary with the DPE 304-15. Data can also be received by the SoC interface block 104 from other subsystems of the device 100 (e.g., the NoC 308, the hardwired circuit block, the PL 310, and / or the PS 312) through the DPE's stream switch. The DMA engine 816 can receive such data from the stream switch and write the data to the appropriate memory bank or banks 812 within the memory module 604.

[0135] The DMA engine 816 may include one or more memory-stream interfaces (e.g., stream interface 630). Through the DMA engine 816, data may be read from one or more memory banks 812 of the memory module 604 and sent to other destinations via the stream interface. For example, the DMA engine 816 may read data from the memory module 604 and send such data via a stream switch to other DPEs that share and / or do not share a boundary with the DPE 304-15. The DMA engine 816 may also send such data to other subsystems (e.g., the NoC 308, the hardwired circuit block PL 310, and / or the PS 312) via the stream switch and the SoC interface block 104.

[0136] In one or more embodiments, the DMA engine 816 may be programmed by a memory-mapped switch 632 in the DPE 304-15. For example, the DMA engine 816 may be controlled by a configuration register 636. The configuration register 636 may be written using the memory-mapped switch 632 of the DPE interconnect 606. In particular embodiments, the DMA engine 816 may be controlled by a stream switch 626 in the DPE 304-15. For example, the DMA engine 816 may include control registers that may be written by the stream switch 626 connected to it (e.g., via the stream interface 640). Streams received through the stream switch 626 in the DPE interconnect 606 may be connected to the DMA engine 816 in the memory module 604 and / or directly to the core 602 depending on the configuration data loaded into the configuration registers 624, 634, and / or 636. The streams are sent from the DMA engine 816 (e.g., memory module 604) and / or core 602 depending on the configuration data loaded into configuration registers 624, 634, and / or 636. It can be done.

[0137] Memory module 604 may further include a hardware synchronization circuit 820 (abbreviated as "HSC" in FIG. 8). Generally, hardware synchronization circuit 820 may synchronize the operation of different cores (e.g., cores of nearby DPEs), cores 602 of FIG. 8, DMA engine 816, and other external masters (e.g., PS 312) that may communicate via DPE interconnect 606. As an illustrative and non-limiting example, hardware synchronization circuit 820 may synchronize two different cores in different DPEs that access the same, e.g., shared, buffer in memory module 604.

[0138] In one or more embodiments, the hardware synchronization circuit 820 may include multiple different locks. The specific number of locks included in the hardware synchronization circuit 820 may depend on the number of entities that can access the memory module, but is not intended as a limitation. In particular embodiments, each different hardware lock may have an arbiter that can handle simultaneous requests. Furthermore, each hardware lock may handle a new request every clock cycle. The hardware synchronization circuit 820 may have multiple requestors, such as core 602, cores from each of DPEs 304-25, 304-16, and 304-5, DMA engine 816, and / or masters communicating over the DPE interconnect 606. A requestor, for example, obtains a lock for a particular portion of memory in a memory module from a local hardware synchronization circuit before accessing that particular portion. A requestor may release the lock so that another requestor may acquire the lock before accessing the same portion of memory.

[0139] In one or more embodiments, the hardware synchronization circuit 820 can synchronize access by multiple cores to the memory module 604, and more specifically, the memory bank 812. For example, the hardware synchronization circuit 820 can synchronize access to the memory module 604 of the core 602, the cores of the DPE 304-25, the cores of the DPE 304-16, and the cores of the DPE 304-5 shown in FIG. 8. In particular embodiments, the hardware synchronization circuit 820 can synchronize access to the memory bank 812 for any core that can directly access the memory module 604 via the memory interfaces 802, 804, 806, and / or 808. Each core that can access memory module 604 (e.g., core 602 of FIG. 8 and cores of one or more of the nearby DPEs) may, for example, access hardware synchronization circuitry 820 to request and acquire a lock before accessing a particular portion of memory in memory module 604, and then release the lock to allow another core to access that portion of memory once the other core has acquired the lock. Similarly, core 602 may access hardware synchronization circuitry 820, the hardware synchronization circuitry in DPE 304-14, the hardware synchronization circuitry in DPE 304-25, and the hardware synchronization circuitry in DPE 304-5 to request and acquire a lock to access a portion of memory in each respective DPE's memory module, and then release the lock. By coordinating and synchronizing the DPEs' access to the memory module, hardware synchronization circuitry 820 effectively manages the operation of the shared memory among the DPEs.

[0140] The hardware synchronization circuit 820 may also be accessed through the memory-mapped switch 632 of the DPE interconnect 606. In one or more embodiments, a lock transaction is implemented as an atomic acquire (e.g., test for unlock and set lock) and release (e.g., remove lock) operation on a resource. The lock in the hardware synchronization circuit 820 provides an efficient way to transfer ownership of a resource between two participants. The resource may be stored in a buffer in local memory (e.g., memory The input signal may be any of a variety of circuit components, such as a buffer within the submodule 604.

[0141] While the hardware synchronization circuit 820 may synchronize accesses to memory to support communication via shared memory, the hardware synchronization circuit 820 may also synchronize any of a variety of other resources and / or agents, including other DPEs and / or other cores. For example, the hardware synchronization circuit 820 provides a shared pool of locks so that a lock may be used by a DPE, e.g., a core of a DPE, to start and / or stop the operation of another DPE or core. The locks of the hardware synchronization circuit 820 may be allocated, e.g., based on configuration data, for different purposes, such as synchronizing different agents and / or resources that may be needed depending on the particular application implemented by the DPE array 102.

[0142] In particular embodiments, DPE and DMA accesses to the hardware synchronization circuit 820 lock are blocking. Such accesses can stall the requesting core or DMA engine if the lock cannot be acquired immediately. Once the hardware lock is available, the requesting core or DMA engine acquires the lock and automatically unstalls.

[0143] In one embodiment, memory-mapped accesses can be non-blocking, allowing a memory-mapped master to poll the hardware synchronization circuit 820 for the status of the lock. For example, a memory-mapped switch can send a lock "acquire" request to the hardware synchronization circuit 820 as a normal memory read operation. The read address may encode the lock's identifier and other requested data. The read data, e.g., a response to the read request, can signal the success of the acquire request operation. The "acquire" sent as a memory read may be sent in a loop until successful. In another example, the hardware synchronization circuit 820 can issue an event so that the memory-mapped master receives an interrupt when the status of the requested lock changes.

[0144] Thus, when two nearby DPEs share a data buffer via a memory module 604, a hardware synchronization circuit 820 in the particular memory module 604 containing that buffer synchronizes the access. Typically, but not necessarily, memory blocks can be double-buffered to improve throughput.

[0145] If two DPEs are not neighboring DPEs, the two DPEs do not have access to a common memory module. In that case, application data may be transferred via a data stream (the terms "data stream" and "stream" may sometimes be used interchangeably within this disclosure). Thus, the local DMA engine can convert the transfer from a local memory-based transfer to a stream-based transfer. In that case, the core 602 and the DMA engine 816 can be synchronized using the hardware synchronization circuit 820.

[0146] Core 602 may further have access to hardware synchronization circuits, e.g., locks of the hardware synchronization circuits, of neighboring DPEs to facilitate communication over the shared memory. Thus, the hardware synchronization circuits in such other or neighboring DPEs may synchronize access to resources, e.g., memory, among the cores of the neighboring DPEs.

[0147] The PS 312 can communicate with the cores 602 through a memory-mapped switch 632. For example, the PS 312 can access the memory module 604 and the hardware synchronization circuit 820 by initiating memory reads and writes. In another embodiment, the hardware synchronization circuit 820 may send an interrupt to the PS 312 when the status of a lock changes to avoid the PS 312 polling the hardware synchronization circuit 820. The PS 312 can also communicate with the DPE 304-15 through a stream interface.

[0148] The examples provided herein regarding entities sending memory-mapped requests and / or transfers are for purposes of illustration and not limitation. In certain embodiments, any entity external to the DPE array 102 may send memory-mapped requests and / or transfers. For example, a circuit block implemented in PL 310, an ASIC, or other circuitry external to the DPE array 102 described herein may send memory-mapped requests and / or transfers to a DPE 304 to access hardware synchronization circuitry in a memory module within such DPE.

[0149] In addition to communicating with neighboring DPEs via the shared memory module and with neighboring and / or non-neighboring DPEs via the DPE interconnect 606, the core 602 may include cascade interfaces. In the example of FIG. 8, the core 602 includes cascade interfaces 822 and 824 (abbreviated as "CI" in FIG. 8). The cascade interfaces 822 and 824 may provide direct communication with other cores. As shown, the cascade interface 822 of the core 602 receives input data streams directly from the cores of the DPE 304-14. The data streams received via the cascade interface 822 may be provided to data processing circuits within the core 602. The cascade interface 824 of the core 602 may send output data streams directly to the cores of the DPE 304-16.

[0150] In the example of FIG. 8 , each of cascade interface 822 and cascade interface 824 may include a first-in, first-out (FIFO) interface for buffering. In particular embodiments, cascade interfaces 822 and 824 are capable of conveying data streams that may be hundreds of bits wide. The particular bit widths of cascade interfaces 822 and 824 are not intended as limitations. In the example of FIG. 8 , cascade interface 824 is coupled to an accumulator register 836 (abbreviated as “AC” in FIG. 8 ) within core 602. Cascade interface 824 may output the contents of accumulator register 836, and may do so every clock cycle. Accumulation register 836 may store data generated and / or processed by data processing circuitry within core 602.

[0151] 8, cascade interfaces 822 and 824 may be programmed based on configuration data loaded into configuration registers 624. For example, cascade interface 822 may be activated or deactivated based on configuration registers 624. Similarly, cascade interface 824 may be activated or deactivated based on configuration registers 624. Cascade interface 822 may be activated and / or deactivated independently of cascade interface 824.

[0152] In one or more other embodiments, cascade interfaces 822 and 824 are controlled by core 602. For example, core 602 may include instructions for reading and writing to cascade interfaces 822 and / or 824. In another example, core 602 may include hardwired circuitry capable of reading and / or writing to cascade interfaces 822 and / or 824. In some embodiments, cascade interfaces 822 and 824 may be controlled by an entity external to core 602.

[0153] In the embodiments described in this disclosure, the DPE 304 does not include a cache memory. By omitting a cache memory, the DPE array 102 can achieve predictable, e.g., deterministic, performance. Furthermore, since there is no need to maintain coherency between cache memories located in different DPEs, significant processing overhead is avoided.

[0154] According to one or more embodiments, the cores 602 of the DPE 304 do not have incoming interrupts. Thus, the cores 602 of the DPE 304 can operate without being interrupted. By eliminating incoming interrupts to the cores 602 of the DPE 304, the DPE array 102 can also achieve predictable, e.g., deterministic, performance.

[0155] When one or more DPEs 304 communicate with an external agent implemented in the PS 312, the PL 310, a hardwired circuit block, and / or another subsystem (e.g., an ASIC) of the device 100 via a shared buffer in an external read-write (e.g., DDR) memory, the coherency interconnect in the PS 312 may be used to implement the coherency mechanism. In these scenarios, application data transfers between the DPE array 102 and the external agent may traverse both the NoC 308 and / or the PL 310.

[0156] In one or more embodiments, DPE array 102 may be functionally separated into groups of one or more DPEs. For example, specific memory interfaces may be enabled and / or disabled via configuration data to create one or more groups of DPEs, each group including one or more (e.g., a subset) of the DPEs of DPE array 102. In another example, stream interfaces may be configured independently for each group to communicate with other cores of the DPEs in the group and / or with specified input sources and / or output destinations.

[0157] In one or more embodiments, core 602 can support debug functions through a memory-mapped interface. As discussed, program memory 608, memory module 604, core 602, DMA engine 816, stream switch 626, and other components of the DPE are memory-mapped. The memory-mapped registers may be read and / or written by any source capable of generating memory-mapped requests, such as, for example, PS 312, PL 310, and / or a platform management controller within the IC. The requests may proceed through SoC interface block 104 to the intended or target DPE within DPE array 102.

[0158] Functions such as suspending a core, resuming a core, single-stepping a core, and / or resetting a core can be performed via a memory-mapped switch in the DPE. Furthermore, such operations can be initiated for multiple different DPEs. Other example debug operations that can be performed include, for example, reading the status of and / or setting the state of the hardware synchronization circuit 820 and / or the DMA engine 816 via the memory-mapped interfaces described herein.

[0159] In one or more embodiments, the stream interface of the DPE can generate trace information that can be output from the DPE array 102. For example, The interface may be configured to extract trace information from the DPE array 102. The trace information may be generated as a packet-switched stream containing time-stamped data marking event occurrences and / or limited branch traces of execution flow. In one aspect, the trace generated by the DPE may be pushed to a local trace buffer implemented in the PL 310 or to external RAM using the SoC interface block 104 and NoC 308. In another aspect, the trace generated by the DPE may be sent to a debug subsystem implemented on-chip.

[0160] In particular embodiments, each core 602 and memory module 604 of each DPE may include an additional stream interface that can output trace data directly to the stream switch 626. Stream interfaces for trace data may be in addition to those already described. The stream switch 626 may be configured to direct trace data onto a packet-switched stream so that trace information from multiple cores and memory modules of different DPEs can travel on a single data stream. As noted, the stream portion of the DPE interconnect network may be configured to transmit trace data directly to an on-chip debug system via the PL 310, to external memory via the SoC interface block 104, or to a gigabit transceiver via the NoC 308. Examples of different types of trace streams that may be generated include a PC trace stream that generates a program counter (PC) value at branch instructions as opposed to each change in the PC, and an application data trace stream that contains intermediate results within the DPE (e.g., from the cores and / or memory modules via their respective trace data streams).

[0161] Figure 9 illustrates an example connectivity of cascade interfaces of cores in multiple DPEs. In the example of Figure 9, only the cores 602 of the DPE are shown. Other parts of the DPE, such as the DPE interconnect and memory modules, are omitted for illustrative purposes.

[0162] As shown, the cores are connected in series via a cascade interface, as described in connection with FIG. 8 . Core 602-1 is coupled to core 602-2, which is coupled to core 602-3, which is coupled to core 602-4. Thus, application data can propagate directly from core 602-1 to core 602-2 to core 602-3 to core 602-4. Core 602-4 is coupled to core 602-8 in the next row up. Core 602-8 is coupled to core 602-7, which is coupled to core 602-6, which is coupled to core 602-5. Thus, application data can propagate directly from core 602-4 to core 608-8 to core 602-7 to core 602-6 to core 602-5. Core 602-5 is coupled to core 602-9 in the next row up. Core 602-9 is coupled to core 602-10, which is coupled to core 602-11, which is coupled to core 602-12. Therefore, application data can propagate directly from core 602-5 to core 602-9, to core 602-10, to core 602-11, and to core 602-12. Core 602-12 is coupled to core 602-16 in the next row up. Core 602-16 is coupled to core 602-15, which is coupled to core 602-14, and core 602-14 is coupled to core 602-13. Therefore, application data can propagate directly from core 602-12 to core 608-16, to core 602-15, to core 602-14, and to core 602-13.

[0163] Figure 9 is intended to illustrate how the cascade interfaces of the cores of a DPE may be coupled from one row of DPEs to another row of DPEs within a DPE array. The particular number of columns and / or rows of cores (e.g., DPEs) shown is not intended as a limitation. Figure 9 shows that connections between cores using a cascade interface can be made in an "S" or zigzag pattern, at alternate ends of a row of DPEs.

[0164] In embodiments in which the DPE array 102 implements two or more distinct clusters of DPEs 304, a first cluster of DPEs may not be coupled to a second cluster of DPEs via a cascade and / or stream interface. For example, if the first two rows of DPEs form a first cluster and the second two rows of DPEs form a second cluster, the cascade interface of core 602-5 may be programmed to be disabled so as not to pass data to the cascade input of core 602-9.

[0165] In the examples described in connection with Figures 8 and 9, each core is shown as having a cascade interface operating as an input and a cascade interface operating as an output. In one or more other embodiments, the cascade interfaces may be implemented as bidirectional interfaces. In particular embodiments, a core may include additional cascade interfaces such that the core can communicate directly with other cores above, below, to the left, and / or to the right via the cascade interfaces. As noted, such interfaces may be unidirectional or bidirectional.

[0166] 10A, 10B, 10C, 10D, and 10E illustrate examples of connectivity between DPEs. FIG. 10A illustrates an example of connectivity between DPEs using shared memory. In the example of FIG. 10A, a function or kernel implemented in a core 602-15 (e.g., a user circuit design implemented in a DPE and / or DPE array) processes data 1005, e.g., application data, and places it in memory module 604-15 using the core interface and memory interface in DPE 304-15. DPE 304-15 and DPE 304-16 are neighboring DPEs. Thus, core 602-16 can access data 1005 from memory module 604-15 based on obtaining a lock from a hardware synchronization circuit (not shown) in memory module 604-15 for the buffer containing data 1005. Shared access to memory module 604-15 by cores 602-15 and 602-16 facilitates high-speed transaction processing because data does not need to be physically transferred from one memory to another in order for core 602-16 to process application data.

[0167] Figure 10B shows an example of connectivity between DPEs using a stream switch. In the example of Figure 10B, DPEs 304-15 and 304-17 are non-proximal DPEs and are therefore separated by one or more intervening DPEs. A function or kernel implemented in core 602-15 processes data 1005 and places it in memory module 604-15. A DMA engine 816-15 in memory module 604-15 retrieves the data 1005 based on obtaining a lock on a buffer used to store the data 1005 in memory module 604-15. The DMA engine 816-15 sends the data 1005 to DPE 304-17 via a stream switch in the DPE interconnect. The DMA engine 816-17 in memory module 604-17 can retrieve data 1005 from the stream switch in DPE 304-17 and store the data 1005 in a buffer of memory module 604-17 after acquiring a lock from a hardware synchronization circuit in memory module 604-17 for the buffer in memory module 604-17. The connectivity shown in Figure 10B can be programmed by loading configuration data to configure the respective stream switches and DMA engines 816-15 and 816-17 in DPEs 304-15 and 304-17 to operate as described.

[0168] Figure 10C shows another example of connectivity between DPEs using a stream switch. In the example of Figure 10C, DPEs 304-15 and 304-17 are non-proximal DPEs and are therefore separated by one or more intervening DPEs. Figure 10C shows that data 1005 can be provided directly from DMA 816-15 to a core of another DPE through a stream switch. As shown, DMA 816-15 places data 1005 on the stream switch of DPE 304-15. Core 602-17 can receive data 1005 directly from the stream switch in DPE 304-17 using its included stream interface; data 1005 does not traverse to memory module 604-17. The connectivity shown in Figure 10C can be programmed by loading configuration data to configure the stream switches and DMA 816-15 of each of DPEs 304-15 and 304-17 to operate as described.

[0169] Generally, Figure 10C illustrates an example of a DMA-to-core transfer of data. It should be understood that core-to-DMA transfers of data may also be implemented. For example, the core 602-17 may send data to the DPE 304-15 via a stream interface included therein and a stream switch of the DPE 304-17. The DMA engine 816-15 may pull data from the stream switch included in the DPE 304-15 and store it in the memory module 604-15.

[0170] Figure 10D illustrates another example of connectivity between DPEs using a stream switch. Referring to Figure 10D, cores 602-15, 602-17, and 602-19 of different, non-neighboring DPEs can communicate directly with each other via the stream interfaces of each respective DPE. In the example of Figure 10D, core 602-15 can broadcast the same data stream to core 602-17 and core 602-19. The broadcast functionality of the stream interfaces in each respective DPE, including cores 602-15, 602-17, and 602-19, can be programmed by loading configuration data to configure the respective stream switches and / or stream interfaces as described. In one or more other embodiments, core 602-15 can multicast data to cores of other DPEs.

[0171] Figure 10E shows an example of connectivity between DPEs using a stream switch and a cascade interface. Referring to Figure 10E, DPE 304-15 and DPE 304-16 are neighboring DPEs. In some cases, a kernel may be split to run on multiple cores. In that case, the intermediate accumulated results of one sub-kernel may be transferred to the sub-kernel of the next core via the cascade interface.

[0172] In the example of FIG. 10E, core 602-15 receives data 1005 via a stream switch and processes the data 1005. Core 602-15 generates and outputs intermediate result data 1010 directly from an accumulation register within core 602-15 to core 602-16 via a cascade interface. In a particular embodiment, the cascade interface of core 602-15 is capable of transferring accumulator values ​​every clock cycle of DPE 304-15. The data 1005 received by core 602-15 further propagates to core 602-16 via a stream switch in the DPE interconnect, and core 602-16 can process both the data 1005 (e.g., original data) and the intermediate result data 1010 generated by core 602-15.

[0173] In the example of Figure 10, the sending of data streams, broadcasting of data streams, and / or multicasting of data streams are shown horizontally. It should be understood that a data stream may be sent, broadcast, and / or multicast from one DPE to any other DPE in a DPE array. Thus, the data stream Streams may be sent, broadcast, or multicast to the DPEs left, right, up, down, and / or diagonally as needed to reach each such DPE, based on configuration data loaded into the intended destination DPE.

[0174] Figure 11 illustrates an example of an event processing circuit within a DPE. A DPE may include event processing circuitry that is interconnected to the event processing circuitry of other DPEs. In the example of Figure 11, the event processing circuitry is implemented within a core 602 and a memory module 604. The core 602 may include an event broadcast circuit 1102 and event logic 1104. The memory module 604 may include a separate event processing circuitry that includes an event broadcast circuit 1106 and event logic 1108.

[0175] The event broadcast circuit 1102 may be connected to event broadcast circuitry within each of the cores of the DPEs adjacent above and below the exemplary DPE shown in Figure 11. The event broadcast circuit 1102 may also be connected to event broadcast circuitry within a memory module of a DPE adjacent to the left of the exemplary DPE shown in Figure 11. As shown, the event broadcast circuit 1102 is connected to event broadcast circuitry 1106. The event broadcast circuit 1106 may be connected to event broadcast circuitry within each of the memory modules of DPEs adjacent above and below the exemplary DPE shown in Figure 11. The event broadcast circuit 1106 may also be connected to event broadcast circuitry within a core of a DPE adjacent to the right of the exemplary DPE shown in Figure 11.

[0176] In this way, the event processing circuitry of the DPEs can form an independent event broadcast network within the DPE array. The event broadcast network within the DPE array can exist independently of the DPE interconnection network. Furthermore, the event broadcast network can be individually configurable by loading suitable configuration data into configuration registers 624 and / or 636.

[0177] In the example of FIG. 11 , the event broadcast circuit 1102 and the event logic 1104 may be configured by configuration registers 624. The event broadcast circuit 1106 and the event logic 1108 may be configured by configuration registers 636. The configuration registers 624 and 636 may be written through memory-mapped switches in the DPE interconnect 606. In the example of FIG. 11 , the configuration registers 624 program the event logic 1104 to detect specific types of events occurring within the core 602. The configuration data loaded into the configuration registers 624 determines, for example, which of multiple different types of predetermined events are detected by the event logic 1104. Examples of events may include, but are not limited to, the initiation and / or completion of a read operation by the core 602, the initiation and / or completion of a write operation by the core 602, a stall, and the occurrence of other operations performed by the core 602. Similarly, the configuration registers 636 program the event logic 1108 to detect specific types of events occurring within the memory module 604. Examples of events may include, but are not limited to, the start and / or end of a read operation by DMA engine 816, the start and / or end of a write operation by DMA engine 816, a stall, and the occurrence of other operations performed by memory module 604. The configuration data loaded into configuration registers 636, for example, determines which of several different types of predetermined events are detected by event logic 1108. Event logic 1104 and / or event logic 1108 may detect events originating from DMA engine 816, memory mapped switch 632, stream switch 626, the memory interface of memory module 604, the core interface of core 602, the cascade interface of core 602, and / or other components located within the DPE. , and / or events associated therewith, can be detected.

[0178] The configuration registers 624 can further program the event broadcast circuit 1102, and the configuration registers 636 can program the event broadcast circuit 1106. For example, the configuration data loaded into the configuration registers 624 can determine which events received by the event broadcast circuit 1102 from other event broadcast circuits are propagated to further event broadcast circuits and / or to the SoC interface block 104. The configuration data can also specify which events generated internally by the event logic 1104 are propagated to other event broadcast circuits and / or to the SoC interface block 104.

[0179] Similarly, the configuration data loaded into the configuration registers 636 can determine which events received by the event broadcast circuit 1106 from other event broadcast circuits are propagated to further event broadcast circuits and / or to the SoC interface block 104. The configuration data can also specify which events generated internally by the event logic 1108 are propagated to other event broadcast circuits and / or to the SoC interface block 104.

[0180] 11, the event broadcast circuit 1102 can broadcast events, whether generated internally or received from other DPEs, to the DPE above, the DPE to the left, and the DPE below or the SoC interface block 104. The event broadcast circuit 1102 can also broadcast events to an event broadcast circuit 1106 in the memory module 604.

[0181] Events generated by the event logic 1108 may be provided to an event broadcast circuit 1106 or may be broadcast to other DPEs. In the example of Figure 11, events, whether generated internally or received from other DPEs, may be broadcast to the DPE above, to the DPE to the right, and to the DPE below or the SoC interface block 104. The event broadcast circuit 1106 may also broadcast events to the event broadcast circuit 1102 in the core 602.

[0182] In the example of Figure 11, the event broadcast circuitry located in a core communicates vertically with the event broadcast circuitry located in the core of a neighboring DPE above and / or below. If a DPE is directly above (or directly adjacent to) the SoC interface block 104, the event broadcast circuitry in that DPE's core can communicate with the SoC interface block 104. Similarly, the event broadcast circuitry located in a memory module communicates vertically with the event broadcast circuitry located in the memory module of a neighboring DPE above and / or below. If a DPE is directly above (e.g., directly adjacent to) the SoC interface block 104, the event broadcast circuitry in that DPE's memory module can communicate with the SoC interface block 104. The event broadcast circuitry can also communicate with the event broadcast circuitry directly to its left and / or right, regardless of whether such event broadcast circuitry is located in another DPE and / or in a core or memory module. Communication is possible.

[0183] Once configuration registers 624 and 636 are written, event logic 1104 and 1108 can operate in the background. In particular embodiments, event logic 1104 generates events only in response to detecting certain conditions in core 602; event logic 1108 generates events only in response to detecting certain conditions in memory module 604.

[0184] FIG. 12 illustrates another exemplary architecture of the DPE 304. In the example of FIG. 12, the DPE 304 includes multiple different cores and may be referred to as a "cluster" type DPE architecture. In FIG. 12, the DPE 304 includes cores 1202, 1204, 1206, and 1208. Each of the cores 1202-1208 is connected to a memory pool 1220 via a core interface 1210, 1212, 1214, or 1216 (abbreviated as "core IF" in FIG. 12). Each of the core interfaces 1210-1216 is coupled to multiple memory banks 1222-1-1222-N via a crossbar 1224. Via the crossbar 1224, any one of the cores 1202-1208 can access any one of the memory banks 1222-1-1222-N. Thus, within the example architecture of FIG. 12, cores 1202-1208 can communicate with each other via shared memory banks 1222 of memory pool 1220.

[0185] In one or more embodiments, memory pool 1220 may include 32 memory banks. The number of memory banks included in memory pool 1220 is provided for illustration purposes and not limitation. In other embodiments, the number of memory banks included in memory pool 1220 may be more or less than 32.

[0186] In the example of FIG. 12, the DPE 304 includes a memory-mapped switch 1226. The memory-mapped switch 1226 includes multiple memory-mapped interfaces (not shown) that can couple to memory-mapped switches in neighboring DPEs in each of the four cardinal directions (e.g., north, south, west, east) and to the memory pool 1220. Each memory-mapped interface can include one or more masters and one or more slaves. For example, the memory-mapped switch 1226 is coupled to the crossbar 1224 via the memory-mapped interfaces. The memory-mapped switch 1226 can communicate configuration, control, and debug data as described in connection with other example DPEs in this disclosure. Accordingly, the memory-mapped switch 1226 can load configuration registers (not shown) in the DPE 304. In the example of FIG. 12, the DPE 304 can include configuration registers for controlling the operation of the stream switch 1232, the cores 1202-1208, and the DMA engine 1234.

[0187] 12, the memory-mapped switch 1226 can communicate in each of the four cardinal directions. In other embodiments, the memory-mapped switch 1226 can communicate only in the north and south directions. In other embodiments, the memory-mapped switch 1226 may include additional memory-mapped interfaces that allow the memory-mapped switch 1226 to communicate with more than four other entities, thereby enabling communication with other diagonally opposite DPEs and / or other non-neighboring DPEs.

[0188] The DPE 304 also includes a stream switch 1232. The stream switch 1232 provides multiple streams that can be coupled to stream switches in neighboring DPEs in each of the four cardinal directions (e.g., north, south, west, east) and to the cores 1202-1208. The stream switch 1232 further includes a stream interface coupled to a DMA engine 1234. Each stream interface may include one or more masters and one or more slaves.

[0189] DMA engine 1234 is coupled to crossbar 1224 via interface 1218. DMA engine 1234 may include two interfaces. For example, DMA engine 1234 may include a memory-to-stream interface that can read data from one or more of memory banks 1222 and send the data over stream switch 1232. DMA engine 1234 may also include a stream-to-memory interface that can receive data via stream switch 1232 and store the data in one or more of memory banks 1222. Each of the interfaces, whether memory-to-stream or stream-to-memory, can support one input / output stream or multiple simultaneous input / output streams.

[0190] The exemplary architecture of Figure 12 supports inter-DPE communication via both memory-mapped switch 1226 and stream switch 1232. As shown, memory-mapped switch 1226 can communicate with the memory-mapped switches of neighboring DPEs above, below, left, and right. Similarly, stream switch 1232 can communicate with the stream switches of neighboring DPEs above, below, left, and right.

[0191] In one or more embodiments, both the memory-mapped switch 1226 and the stream switch 1232 can support data transfers between cores of other DPEs (both nearby and non-neighboring) for sharing application data. The memory-mapped switch 1226 can further support the transfer of configuration, control, and debug data for purposes of configuring the DPE 304. In particular embodiments, the stream switch 1232 supports the transfer of application data, and the memory-mapped switch 1226 supports only the transfer of configuration, control, and debug data.

[0192] In the example of Figure 12, cores 1202-1208 are connected in series via cascade interfaces as described above. Additionally, core 1202 is coupled to the cascade interface (e.g., output) of the right-most core in a neighboring DPE to the left of the DPE in Figure 12, and core 1208 is coupled to the cascade interface (e.g., input) of the left-most core in a neighboring DPE to the right of the DPE in Figure 12. The cascade interfaces of DPEs using a cluster architecture may be connected row-by-row as shown in Figure 9. In one or more other embodiments, one or more of cores 1202-1208 may be connected to cores in neighboring DPEs above and / or below via cascade interfaces instead of and / or in addition to horizontal cascade connections.

[0193] The example architecture of FIG. 12 may be used to implement a DPE and form a DPE array, as described herein. The example architecture of FIG. 12 increases the amount of memory available to cores compared to other example DPE architectures described within this disclosure. Thus, in applications where cores require access to larger amounts of memory, the architecture of FIG. 12 may be used, clustering multiple cores together within a single DPE. For purposes of illustration, depending on the configuration of the DPE 304 of FIG. 12, it is not necessary to use all cores. Thus, one or more (e.g., all cores of the DPE 304) may be used. 1202-1208) have access to memory pool 1220 and can have access to a larger amount of memory than they would otherwise based on the configuration data loaded into configuration registers (not shown) in the example of FIG. 12.

[0194] Figure 13 shows an example architecture for the DPE array 102 of Figure 1. In the example of Figure 13, the SoC interface block 104 provides an interface between the DPE 304 and other subsystems of the device 100. The SoC interface block 104 integrates the DPE into the device. The SoC interface block 104 can communicate configuration data to the DPE 304, communicate events from the DPE 304 to other subsystems, communicate events from other subsystems to the DPE 304, generate and communicate interrupts to entities external to the DPE array 102, communicate application data between the other subsystems and the DPE 304, and / or communicate trace and / or debug data between the other subsystems and the DPE 304.

[0195] In the example of FIG. 13 , the SoC interface block 104 includes multiple interconnected tiles. For example, the SoC interface block 104 includes tiles 1302, 1304, 1306, 1308, 1310, 1312, 1314, 1316, 1318, and 1320. In the example of FIG. 13 , the tiles 1302-1320 are organized in rows. In other embodiments, the tiles may be arranged in columns, a grid, or another layout. For example, the SoC interface block 104 may be implemented as a column of tiles to the left of the DPE 304, to the right of the DPE 304, between the columns of DPEs 304, etc. In another embodiment, the SoC interface block 104 may be located above the DPE array 102. The SoC interface block 104 may be implemented such that the tiles are located in any combination below the DPE array 102, to the left of the DPE array 102, to the right of the DPE array 102, and / or above the DPE array 102. In this regard, Figure 13 is shown for purposes of illustration and not limitation.

[0196] In one or more embodiments, the tiles 1302-1320 have the same architecture. In one or more other embodiments, the tiles 1302-1320 may be implemented with two or more different architectures. In particular embodiments, different architectures are used to implement the tiles within the SoC interface block 104, and each different tile architecture can support communication with a different type or combination of subsystems of the device 100.

[0197] In the example of FIG. 13 , tiles 1302-1320 are coupled such that data can be propagated from one tile to another. For example, data can be propagated from tile 1302 through tiles 1304, 1306, and down the line of tiles to tile 1320. Similarly, data can be propagated in the reverse direction from tile 1320 to tile 1302. In one or more embodiments, each of tiles 1302-1320 can operate as an interface for multiple DPEs. For example, each of tiles 1302-1320 can operate as an interface for a subset of DPEs 304 in DPE array 102. The subset of DPEs to which each tile provides an interface may be mutually exclusive, such that no DPE is interfaced by more than one tile in SoC interface block 104.

[0198] In one example, tiles 1302-1320 each provide an interface for a row of DPEs 304. To illustrate, tile 1302 provides an interface to DPEs in row A. Tile 1304 provides an interface to DPEs in row B. In each case, the tile includes a direct connection to an adjacent DPE in the row of DPEs, which in this example is The DPE in is the bottom DPE. Referring to column A, for example, tile 1302 is directly connected to DPE 304-1. Other DPEs in column A can communicate with tile 1302, but through the DPE interconnects of intervening DPEs in the same column.

[0199] For example, tile 1302 may receive data from another source, such as PS 312, PL 310, and / or another hardwired circuit block, e.g., an ASIC block. Tile 1302 may provide portions of data addressed to DPEs in column A to such DPEs and transmit data addressed to DPEs in other columns (e.g., DPEs to which tile 1302 does not interface) to tile 1304. Tile 1304 may perform the same or similar processing, transmitting data addressed to DPEs in other columns that were received from tile 1302 and are addressed to DPEs in column B to such DPEs, while transmitting data addressed to DPEs in other columns to tile 1306.

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

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

[0202] 14A, 14B, and 14C show example architectures for implementing tiles of the SoC interface block 104. Figure 14A shows an example implementation of a tile 1304. The architecture shown in Figure 14A can also be used to implement any other tile included in the SoC interface block 104.

[0203] The tile 1304 includes a memory-mapped switch 1402. The memory-mapped switch 1402 may include multiple memory-mapped interfaces for communicating in each of multiple different directions. As an illustrative and non-limiting example, the memory-mapped switch 1402 may include one or more memory-mapped interfaces, each having a master that vertically connects to the memory-mapped interface of the DPE directly above it. Thus, the memory-mapped switch 1402 may act as a master for the memory-mapped interfaces of one or more of the DPEs. In a particular example, the memory-mapped switch 1402 may act as a master for a subset of the DPEs. For example, the memory-mapped switch 1402 may act as a master for a column of DPEs on the tile 1304, e.g., column B in FIG. 13 . The memory-mapped switch 1402 may also act as a master for the DPE array 102. It should be understood that the tile 1304 may include additional memory-mapped interfaces for connecting to different circuits (e.g., DPEs) within the tile 1304. The memory-mapped interface of the memory-mapped switch 1402 may also include one or more slaves that can communicate with circuits (e.g., one or more DPEs) located above the tile 1304.

[0204] In the example of FIG. 14A , memory-mapped switch 1402 may include one or more memory-mapped interfaces that facilitate horizontal communication to memory-mapped switches in neighboring tiles (e.g., tiles 1302 and 1306). To illustrate, memory-mapped switch 1402 may be connected horizontally to neighboring tiles via memory-mapped interfaces, with each such memory-mapped interface including one or more masters and / or one or more slaves. Thus, memory-mapped switch 1402 can move data (e.g., configuration, control, and / or debug data) from one tile to another to reach the correct DPE and / or the correct subset of DPEs, and direct the data to the target DPE, whether in the top row of tile 1304 or in another subset to which another tile of SoC interface block 104 interfaces. For example, when a memory-mapped transaction is received from the NoC 308, the memory-mapped switch 1402 can distribute the transaction horizontally, for example, to other tiles within the SoC interface block 104.

[0205] The memory-mapped switch 1402 may also include a memory-mapped interface having one or more masters and / or slaves coupled to configuration registers 1436 in the tile 1304. Via the memory-mapped switch 1402, configuration data may be loaded into the configuration registers 1436 to control various functions and operations performed by components in the tile 1304. FIGS. 14A, 14B, and 14C show connections between the configuration registers 1436 and one or more elements of the tile 1304. However, it should be understood that the configuration registers 1436 may control other elements of the tile 1304 and therefore may have connections to such other elements, although such connections are not shown in FIGS. 14A, 14B, and / or 14C.

[0206] The memory-mapped switch 1402 may include a memory-mapped interface coupled to the NoC interface 1426 via a bridge 1418. This memory-mapped interface may include one or more masters and / or slaves. The bridge 1418 may convert memory-mapped data transfers (e.g., configuration, control, and / or debug data) from the NoC 308 into memory-mapped data that can be received by the memory-mapped switch 1402.

[0207] The tile 1304 may also include event processing circuitry. For example, the tile 1304 includes event logic 1432. The event logic 1432 may be configured by configuration registers 1436. In the example of FIG. 14A , the event logic 1432 is coupled to the control, debug, and trace (CDT) circuit 1420. Configuration data loaded into the configuration registers 1436 defines specific events that may be detected locally within the tile 1304. The event logic 1432, via the configuration registers 1436, may control events originating from and / or connected to the DMA engine 1412, the memory-mapped switch 1402, the stream switch 1406, the first-in-first-out (FIFO) memory located in the PL interface 1410, and / or the NoC stream interface 1414. The event logic 1432 may detect a variety of different events associated with the CDT circuit 1420. Examples of events may include, but are not limited to, a DMA transfer end, a lock release, a lock acquisition, an end of a PL transfer, or other events associated with the start or end of data flow through the tile 1304. The event logic 1432 may provide such events to the event broadcast circuit 1404 and / or the CDT circuit 1420. For example, in another embodiment, the event logic 1432 may not have a direct connection to the CDT circuit 1420, but rather connects to the CDT circuit 1420 via the event broadcast circuit 1404.

[0208] The tile 1304 includes an event broadcast circuit 1404 and an event broadcast circuit 1430. The event broadcast circuit 1404 and the event broadcast circuit 1430 each provide an interface between the event broadcast network of the DPE array 102, other tiles of the SoC interface block 104, and the PL 310 of the device 100. The event broadcast circuit 1404 is coupled to the event broadcast circuit and the event broadcast circuit 1430 in an adjacent or nearby tile 1302. The event broadcast circuit 1430 is coupled to the event broadcast circuit in an adjacent or nearby tile 1306. In one or more other embodiments in which the tiles of the SoC interface block 104 are arranged in a grid or array, the event broadcast circuit 1404 and / or the event broadcast circuit 1430 may be connected to event broadcast circuitry located in other tiles above and / or below the tile 1304.

[0209] 14A , the event broadcast circuit 1404 is coupled to an event broadcast circuit in the core of a DPE adjacent to tile 1304, for example, DPE 304-2 immediately above tile 1304 in column B. The event broadcast circuit 1404 is also coupled to a PL interface 1410. The event broadcast circuit 1430 is coupled to an event broadcast circuit in the memory module of a DPE adjacent to tile 1304, for example, DPE 304-2 immediately above tile 1304 in column B. Although not shown, in other embodiments, the event broadcast circuit 1430 may also be coupled to the PL interface 1410.

[0210] Event broadcast circuit 1404 and event broadcast circuit 1430 can transmit events generated internally by event logic 1432, events received from other tiles in SoC interface block 104, and / or events received from the DPEs in column B (or other DPEs in DPE array 102) to other tiles. Event broadcast circuit 1404 can further transmit such events to PL 310 via PL interface 1410. In another example, events may be transmitted from event broadcast circuit 1404 to other blocks and / or subsystems within device 100, such as ASICs and / or PL circuit blocks located outside DPE array 102, using PL interface block 1410. Additionally, PL interface 1410 can receive events from PL 310 and provide such events to event broadcast switch 1404 and / or stream switch 1406. In one aspect, the event broadcast circuit 1404 can transmit any events received from the PL 310 via the PL interface 1410 to other tiles in the SoC interface block 104 and / or to the DPEs in column B and / or other DPEs in the DPE array 102. In another example, events received from the PL 310 can be transmitted from the event broadcast circuit 1404 to other blocks and / or subsystems in the device 100, such as ASICs. Because events can be broadcast between tiles in the SoC interface block 104, events can be transmitted to other tiles in the SoC interface block 104. Any DPE in DPE array 102 may be reached by traversing the tiles and event broadcast circuitry in block 104 to the target (e.g., intended) DPE. For example, event broadcast circuitry in tiles of SoC interface block 104 below the column (or subset) of DPEs managed by the tile containing the target DPE can propagate the event to the target DPE.

[0211] 14A , the event broadcast circuit 1404 and the event logic 1432 are coupled to the CDT circuit 1420. The event broadcast circuit 1404 and the event logic 1432 can send events to the CDT circuit 1420. The CDT circuit 1420 can packetize received events and send the events from the event broadcast circuit 1404 and / or the event logic 1432 to the stream switch 1406. In particular embodiments, the event broadcast circuit 1430 can also be connected to the stream switch 1406 and / or the CDT circuit 1420.

[0212] In one or more embodiments, the event broadcast circuit 1404 and the event broadcast circuit 1430 can collect broadcast events from one or more or all directions as shown in FIG. 14A (e.g., via any of the connections shown in FIG. 14A). In particular embodiments, the event broadcast circuit 1404 and / or the event broadcast circuit 1430 can perform a logical “OR” of the signals and forward the results to one or more or all directions (e.g., including the CDT circuit 1420). Each output from the event broadcast circuit 1404 and the event broadcast circuit 1430 can include a bit mask configurable by configuration data loaded into the configuration register 1436. The bit mask determines which events are broadcast in each direction on an individual basis. Such a bit mask can, for example, eliminate unwanted or duplicate propagation of events.

[0213] The interrupt handler 1434 is coupled to the event broadcast circuit 1404 and can receive events broadcast from the event broadcast circuit 1404. In one or more embodiments, the interrupt handler 1434 can be configured by configuration data loaded into the configuration registers 1436 to generate an interrupt in response to selected events and / or combinations of events from the event broadcast circuit 1404 (e.g., DPE-generated events, events generated in the tiles 1304, and / or PL 310-generated events). The interrupt handler 1434 can generate interrupts to the PS 312 and / or other device-level management blocks in the device 100 based on the configuration data. Thus, the interrupt handler 1434 can notify the PS 312 and / or such other device-level management blocks of events occurring in the DPE array 102, events occurring in the tiles of the SoC interface block 104, and / or events occurring in the PL 310 based on the interrupts generated by the interrupt handler 1434.

[0214] In a particular embodiment, the interrupt handler 1434 may be coupled to an interrupt handler or interrupt port of the PS 312 and / or other device-level management block by a direct connection. In one or more other embodiments, the interrupt handler 1434 may be coupled to the PS 312 and / or other device-level management block by another interface.

[0215] PL interface 1410 couples to and provides an interface to PL 310 of device 100. In one or more embodiments, PL interface 1410 provides an asynchronous clock domain crossing between the DPE array clock and the PL clock. The PL interface 1410 provides a power rail for the PL 310. The PL interface 1410 may also provide level shifters and / or isolation cells for integration with the PL power rails. In particular embodiments, the PL interface 1410 may be configured to provide a 32-bit, 64-bit, and / or 128-bit interface with FIFO support to handle backpressure. The particular width of the PL interface 1410 may be controlled by configuration data loaded into configuration registers 1436. In the example of FIG. 14A , the PL interface 1410 directly couples to one or more PL interconnect blocks 1422. In particular embodiments, the PL interconnect blocks 1422 are implemented as hardwired circuit blocks that couple to interconnect circuitry located in the PL 310.

[0216] In one or more other embodiments, the PL interface 1410 is coupled to other types of circuit blocks and / or subsystems. For example, the PL interface 1410 may be coupled to an ASIC, an analog / mixed-signal circuit, and / or other subsystem. Thus, the PL interface 1410 can transfer data between the tiles 1304 and such other subsystems and / or blocks.

[0217] In the example of FIG. 14A , tile 1304 includes a stream switch 1406. Stream switch 1406 is coupled to a stream switch in adjacent or nearby tile 1302 and a stream switch in adjacent or nearby tile 1306 via one or more stream interfaces. Each stream interface may include one or more masters and / or one or more slaves. In particular embodiments, each pair of adjacent stream switches can exchange data via one or more streams in each direction. Stream switch 1406 is also coupled by one or more stream interfaces to a stream switch in the DPE immediately above tile 1304 in column B, i.e., DPE 304-2. As discussed, the stream interface may include one or more stream slaves and / or stream masters. Stream switch 1406 is also coupled to a PL interface 1410, a DMA engine 1412, and / or an NoC stream interface 1414 via a stream multiplexer / demultiplexer 1408 (abbreviated as stream mux / demux in FIG. 14A ). The stream switch 1406 may include one or more stream interfaces used to communicate with each of the PL interface 1410, the DMA engine 1412, and / or the NoC stream interface 1414, for example, via the stream multiplexer / demultiplexer 1408.

[0218] In one or more other embodiments, the stream switch 1406 may be coupled to other circuit blocks in other directions and / or diagonal directions depending on the number of stream interfaces included and / or the arrangement of other circuit blocks around the tile and / or DPE and / or tile 1304.

[0219] In one or more embodiments, the stream switch 1406 is configurable by configuration data loaded into configuration registers 1436. The stream switch 1406 may be configured to support packet-switched and / or circuit-switched operations, for example, based on the configuration data. Furthermore, the configuration data specifies a particular DPE and / or multiple DPEs in the DPE array 102 with which the stream switch 1406 communicates. In one or more embodiments, the configuration data specifies a particular DPE and / or a subset of DPEs in the DPE array 102 with which the stream switch 1406 communicates (e.g., the DPEs in column B).

[0220] Stream mux / demultiplexer 1408 may direct data received from PL interface 1410, DMA engine 1412, and / or NoC stream interface 1414 to stream switch 1406. Similarly, stream mux / demultiplexer 1408 may direct data received from stream switch 1406 to PL interface 1410, DMA engine 1412, and / or NoC stream interface 1414. For example, stream mux / demultiplexer 1408 may be programmed by configuration data stored in configuration registers 1436 to route selected data to DMA engine 1412, where such data is transmitted through NoC 308 as memory-mapped transactions, and / or route selected data to NoC stream interface 1414, where the data is transmitted through NoC 308 as one or more data streams.

[0221] The DMA engine 1412 can act as a master to direct data through the selector block 1416 to the NoC interface 1426 and to the NoC 308. The DMA engine 1412 can receive data from the DPE and provide such data to the NoC 308 as memory-mapped data transactions. In one or more embodiments, the DMA engine 1412 includes hardware synchronization circuitry that can be used to synchronize multiple channels included in the DMA engine 1412 and / or a channel within the DMA engine 1412 with a master that polls and drives lock requests. For example, the master can be a device implemented within the PS 312 or the PL 310. The master can also receive interrupts generated by the hardware synchronization circuitry within the DMA engine 1412.

[0222] In one or more embodiments, the DMA engine 1412 can access external memory. For example, the DMA engine 1412 can receive a data stream from a DPE and send the data stream to external memory to a memory controller located within the SoC via the NoC 308. The memory controller then directs the data received as a data stream to the external memory (e.g., initiates reads and / or writes to the external memory as requested by the DMA engine 1412). Similarly, the DMA engine 1412 can receive data from external memory, which may be distributed to other tiles of the SoC interface block 104 and / or to a target DPE.

[0223] In particular embodiments, the DMA engine 1412 includes a security bit that can be set using the DPE Global Control Settings register (DPE GCS register) 1438. External memory can be divided into different regions or partitions, and the DPE array 102 is permitted to access only specific regions of external memory. The security bit within the DMA engine 1412 may be set to allow the DPE array 102, via the DMA engine 1412, to access only specific regions of external memory that are permitted according to the security bit. For example, an application implemented by the DPE array 102 can use this mechanism to be restricted to accessing only specific regions of external memory, restricted to reading only from specific regions of external memory, and / or restricted from writing to this external memory entirely.

[0224] The security bits in the DMA engine 1412 that control access to external memory may be implemented to control the DPE array 102 globally, or may be implemented in a more granular manner, where access to external memory is specified and / or controlled per DPE, e.g., per core, or for groups of cores that operate in cooperation, e.g., configured to implement a kernel and / or other applications. That's fine.

[0225] The NoC stream interface 1414 may receive data from the NoC 308 via the NoC interface 1426 and forward the data as a stream to the multiplexer / demultiplexer 1408. The NoC stream interface 1414 may further receive data from the stream multiplexer / demultiplexer 1408 and forward the data to the NoC interface 1426 via the selector block 1416. The selector block 1416 may be configurable to pass data from the DMA engine 1412 or the NoC stream interface 1414 to the NoC interface 1426.

[0226] The CDT circuit 1420 can perform control, debug, and trace operations within the tiles 1304. For debug, each of the registers located in the tiles 1304 is mapped onto a memory map accessible via the memory-mapped switch 1402. The CDT circuit 1420 can include circuits such as trace hardware, a trace buffer, performance counters, and / or stall logic. The trace hardware of the CDT circuit 1420 can collect trace data. The trace buffer of the CDT circuit 1420 can buffer the trace data. Furthermore, the CDT circuit 1420 can output the trace data to the stream switch 1406.

[0227] In one or more embodiments, the CDT circuit 1420 can collect data, e.g., trace and / or debug data, packetize such data, and then output the packetized data through the stream switch 1406. For example, the CDT circuit 1420 can output the packetized data and provide such data to the stream switch 1406. Additionally, configuration registers 1436 or others can be read or written via memory-mapped transactions through the memory-mapped switch 1402 of each tile during debugging. Similarly, performance counters within the CDT circuit 1420 can be read or written via memory-mapped transactions through the memory-mapped switch 1402 of each tile during profiling.

[0228] In one or more embodiments, the CDT circuit 1420 can receive any event propagated by the event broadcast circuit 1404 (or the event broadcast circuit 1430), or events selected according to a bit mask utilized by an interface of the event broadcast circuit 1404 coupled to the CDT circuit 1420. The CDT circuit 1420 can also receive events generated by the event logic 1432. For example, the CDT circuit 1420 can receive broadcast events, whether from the PL 310, the DPE 304, the tile 1304 (e.g., the event logic 1432 and / or the event broadcast switch 1404), and / or from other tiles in the SoC interface block 104. The CDT circuit 1420 can pack, e.g., packetize, multiple such events together in a packet and associate the packetized events with a timestamp. The CDT circuit 1420 can further transmit the packetized events via the stream switch 1406 to a destination external to the tile 1304. The events may be sent by the stream switch 1406 and stream multiplexer / demultiplexer 1408 through the PL interface 1410, the DMA engine 1412, and / or the NoC stream interface 1414.

[0229] The DPE GCS registers 1438 may store DPE global control settings / bits (also referred to herein as "security bits") used to enable or disable secure access to and / or from the DPE array 102. The DPE GCS registers 1438 may be programmed via the SoC secure / initialization interface, as described in more detail below in connection with FIG. 14C. The security bits received from the SoC secure / initialization interface may propagate from one tile of the SoC interface block 104 to the next via a bus, as shown in FIG. 14A.

[0230] In one or more embodiments, external memory-mapped data transfers to the DPE array 102 (e.g., using the NoC 308) are unsecure and unreliable. Without setting the security bit in the GCS register 1438, any entity in the device 100 that can communicate by memory-mapped data transfer (e.g., via the NoC 308) can communicate with the DPE array 102. By setting the security bit in the DPE GCS register 1438, the specific entities that are allowed to communicate with the DPE array 102 can be defined so that only designated entities capable of generating secure traffic can communicate with the DPE array 102.

[0231] For example, the memory-mapped interface of memory-mapped switch 1402 can communicate with NoC 308. Memory-mapped data transfers may include an additional sideband signal, e.g., a bit, that specifies whether the transaction is secure or insecure. When the security bit in DPE GCS register 1438 is set, a memory-mapped transaction entering SoC interface block 104 must have the sideband signal set to indicate that the memory-mapped transaction arriving at SoC interface block 104 from NoC 308 is secure. When a memory-mapped transaction arriving at SoC interface block 104 does not have the sideband bit set and the security bit is set in DPE GCS register 1438, SoC interface block 104 does not allow the transaction to enter or pass through DPE 304.

[0232] In one or more embodiments, the SoC includes a secure agent (e.g., circuitry) that acts as a root of trust. The secure agent can configure different entities (e.g., circuitry) within the SoC with the necessary permissions to set sideband bits in memory-mapped transactions to access the DPE array 102 when the security bit in the DPE GCS register 1438 is set. Once the SoC is configured, the secure agent grants permission to different masters, which may be implemented in the PL 310 or PS 312, thereby granting such masters the ability to issue (or not issue) secure transactions to the DPE array 102 via the NoC 308.

[0233] FIG. 14B illustrates another exemplary implementation of tile 1304. The exemplary architecture illustrated in FIG. 14B may also be used to implement any of the other tiles included in SoC interface block 104. The example of FIG. 14B illustrates a simplified version of the architecture illustrated in FIG. 14A. The tile architecture of FIG. 14B provides connectivity between the DPE and other subsystems and / or blocks within device 100. For example, tile 1304 of FIG. 14B may provide connectivity between the DPE and PL 310, analog / mixed-signal circuit blocks, ASICs, or other subsystems described herein. The tile architecture of FIG. 14B does not provide connectivity to the NoC 308. Thus, the DMA engine 1412, NoC interface 1414, selector block 1416, bridge 1418, and stream mux / demux 1408 are omitted. Thus, the tile 1304 of FIG. 14B may be implemented using less area of ​​the SoC. Additionally, as shown, the stream switch 1406 is directly coupled to the PL interface 1410.

[0234] The example architecture of Figure 14B cannot receive memory-mapped data, e.g., configuration data, for the purpose of configuring a DPE from the NoC 308. Such configuration data may be received via a memory-mapped switch 1402 from a neighboring tile and directed to a subset of the DPEs managed by the tile 1304 (e.g., up to the column of DPEs above the tile 1304 in Figure 14B).

[0235] 14C shows another example implementation of a tile 1304. In a particular embodiment, the architecture shown in FIG. 14C may be used to implement only one tile within the SoC interface block 104. For example, the architecture shown in FIG. 14C may be used to implement the tile 1302 within the SoC interface block 104. The architecture shown in FIG. 14C is similar to the architecture shown in FIG. 14B. In FIG. 14C, additional components such as an SoC secure / initialization interface 1440, a clock signal generator 1442, and a global timer 1444 are included.

[0236] In the example of FIG. 14C , SoC secure / initialize interface 1440 provides an additional interface for SoC interface block 104. In one or more embodiments, SoC secure / initialize interface 1440 is implemented as an NoC peripheral interconnect. SoC secure / initialize interface 1440 can provide access to global reset registers for DPE array 102 (not shown) and DPE GCS registers 1438. In a particular embodiment, DPE GCS registers 1438 include configuration registers for clock signal generator 1442. As shown, SoC secure / initialize interface 1440 can provide security bits to DPE GCS registers 1438 and propagate the security bits to other DPE GCS registers 1438 in other tiles of SoC interface block 104. In a particular embodiment, SoC secure / initialize interface 1440 implements a single slave endpoint for SoC interface block 104.

[0237] 14C , clock signal generator 1442 may generate one or more clock signals 1446 and / or one or more reset signals 1450. Clock signals 1446 and / or reset signals 1450 may be distributed to each of DPEs 304 and / or other tiles of SoC interface block 104 of DPE array 102. In one or more embodiments, clock signal generator 1442 may include one or more phase-locked loop circuits (PLLs). As shown, clock signal generator 1442 may receive a reference clock signal generated by another circuit external to DPE array 102 and located on the SoC. Clock signal generator 1442 may generate clock signal 1446 based on the received reference clock signal.

[0238] 14C, the clock signal generator 1442 is configured via the SoC secure / initialization interface 1440. For example, the clock signal generator 1442 may be configured by loading data into the DPE GCS register 1438. Thus, the clock signal generator 1442 may configure one or more clock frequencies and reset signals 1450 of the DPE array 102. The generation of may be set by writing appropriate configuration data to the DPE GCS registers 1438 via the SoC secure / initialization interface 1440. For testing purposes, the clock signal 1446 and / or the reset signal 1450 may also be routed directly to the PL 310.

[0239] The SoC secure / initialization interface 1440 may be coupled to an SoC control / debug (circuit) block (e.g., a control and / or debug subsystem of the device 100, not shown). In one or more embodiments, the SOC secure / initialization interface 1440 may provide a status signal to the SOC control / debug block. As an illustrative and non-limiting example, the SoC secure / initialization interface 1440 may provide a “PLL locked” signal generated from within the clock signal generator 1440 to the SoC control / debug block. The PLL locked signal may indicate when the PLL acquires lock on the reference clock signal.

[0240] The SoC secure / initialization interface 1440 can receive instructions and / or data via interface 1448. The data can include security bits described herein, clock signal generator configuration data, and / or other data that can be written to the DPE GCS registers 1438.

[0241] The global timer 1444 may interface to the CDT circuit 1420. For example, the global timer 1444 may be coupled to the CDT circuit 1420. The global timer 1444 may provide a signal used by the CDT circuit 1420 to timestamp events used for tracking. In one or more embodiments, the global timer 1444 may be coupled to the CDT circuit 1420 in other ones of the tiles of the SoC interface circuit 104. For example, the global timer 1444 may be coupled to the CDT circuit 1420 in the example tiles of FIGS. 14A, 14B, and / or 14C. The global timer 1444 may also be coupled to the SoC control / debug block.

[0242] 14A, 14B, and 14C collectively, the tiles 1304 can communicate with the DPE 304 using a variety of different data paths. In one example, the tiles 1304 can communicate with the DPE 304 using the DMA engine 1412. For example, the tiles 1304 can use the DMA engine 1412 to communicate with a DMA engine (e.g., DMA engine 816) of one or more DPEs in the DPE array 102. Communications can flow from the DPE to a tile in the SoC interface block 104 or from a tile in the SoC interface block 104 to the DPE. In another example, the DMA engine 1412 can communicate with cores of one or more DPEs in the DPE array 102 via a stream switch within the respective DPE. Communications can flow from a core to a tile in the SoC interface block 104 and / or from a tile in the SoC interface block 104 to a core in one or more DPEs in the DPE array 102.

[0243] FIG. 15 illustrates an exemplary implementation of a PL interface 1410. In the example of FIG. 15, the PL interface 1410 includes multiple channels coupling the PL 310 to the stream switch 1406 and / or the stream mux / demux 1408, depending on the particular tile architecture used. The particular number of channels shown in the PL interface 1410 in FIG. 15 is for illustration purposes and not limitation. In other embodiments, the PL interface 1410 may include fewer or more channels than shown in FIG. 15. Additionally, while the PL interface 1410 is shown as connecting to the PL 310, in one or more other embodiments, the PL interface 1410 may include multiple channels. The PL interface 1410 may be coupled to one or more other subsystems and / or circuit blocks. For example, the PL interface 1410 may also be coupled to an ASIC, an analog / mixed-signal circuit, and / or other circuit or subsystem.

[0244] In one or more embodiments, the PL 310 operates at a different reference voltage and a different clock speed than the DPE 304. Thus, in the example of FIG. 15 , the PL interface 1410 includes multiple shift and isolation circuits 1502 and multiple asynchronous FIFO memories 1504. Each channel includes a shift and isolation circuit 1502 and an asynchronous FIFO memory 1504. A first subset of the channels carries data from the PL 310 (and / or other circuits) to the stream switch 1406 and / or stream multiplexer / demultiplexer 1408. A second subset of the channels carries data from the stream switch 1406 and / or stream multiplexer / demultiplexer 1408 to the PL 310 and / or other circuits.

[0245] The shifting and isolation circuitry 1502 can interface between different voltage domains. In this case, the shifting and isolation circuitry 1502 can provide an interface that transitions between the operating voltage of the PL 310 and / or other circuits and the operating voltage of the DPE 304. The asynchronous FIFO memory 1504 can interface between two different clock domains. In this case, the asynchronous FIFO memory 1504 can provide an interface that transitions between the clock rate of the PL 310 and / or other circuits and the clock rate of the DPE 304.

[0246] In one or more embodiments, the asynchronous FIFO memory 1504 has a 32-bit interface to the DPE array 102. The connections between the asynchronous FIFO memory 1504 and the shift and isolate circuit 1502, as well as the connections between the shift and isolate circuit 1502 and the PL 310, may be programmable (e.g., configurable) in width. For example, the connections between the asynchronous FIFO memory 1504 and the shift and isolate circuit 1502, as well as the connections between the shift and isolate circuit 1502 and the PL 310, may be configured to be 32, 64, or 128 bits in width. As discussed, the PL interface 1410 is configurable by writing configuration data to the configuration registers 1436 via the memory-mapped switch 1402 to achieve the described bit widths. Using the memory-mapped switch 1402, the asynchronous FIFO memory 1504 side of the PL 310 side may be configurable to use either 32, 64, or 128 bits. The bit widths provided herein are for illustrative purposes. In other embodiments, other bit widths may be used. In any event, the widths described for the various components may vary based on the configuration data loaded into the configuration registers 1436.

[0247] Figure 16 shows an example implementation of the NoC stream interface 1414. The DPE array 102 has two general ways of communicating through the NoC 308 using the stream interface in the DPE. In one aspect, the DPE can use the stream switch 1406 to access the DMA engine 1412. The DMA engine 1412 can convert memory-mapped transactions from the NoC 308 into data streams for transmission to the DPE and convert data streams from the DPE into memory-mapped transactions for transmission through the NoC 308. In another aspect, the data streams can be directed to the NoC stream interface 1414.

[0248] In the example of FIG. 16, the NoC stream interface 1414 connects the NoC 308 to the stream. 16 includes a plurality of channels coupled to the stream switch 1406 and / or the stream multiplexer / demultiplexer. Each channel may include a FIFO memory and either an upsize circuit or a downsize circuit. A first subset of the channels carries data from the NoC 308 to the stream switch 1406 and / or the stream multiplexer / demultiplexer 1408. A second subset of the channels carries data from the stream switch 1406 and / or the stream multiplexer / demultiplexer 1408 to the NoC 308. The particular number of channels in the NoC stream interface 1414 shown in FIG. 16 is for purposes of illustration and not limitation. In other embodiments, the NoC stream interface 1414 may include fewer or more channels than shown in FIG. 16.

[0249] In one or more embodiments, each of the upsize circuits 1608 (abbreviated as "US circuit" in FIG. 16) can receive a data stream and increase the width of the received data stream. For example, each upsize circuit 1608 may receive a 32-bit data stream and output a 128-bit data stream to a corresponding FIFO memory 1610. Each of the FIFO memories 1610 is coupled to an arbitration and multiplexer circuit 1612. The arbitration and multiplexer circuit 1612 can arbitrate between the received data streams using a particular arbitration scheme or priority (e.g., round-robin or other style) to provide the resulting output data stream to the NoC interface 1426. The arbitration and multiplexer circuit 1612 can process and accept new requests every clock cycle. Clock domain crossing between the DPE 304 and the NoC 308 can be handled within the NoC 308 itself. In one or more other embodiments, clock domain crossings between the DPE 304 and the NoC 308 may be handled within the SoC interface block 104. For example, clock domain crossings may be handled within the NoC stream interface 1414.

[0250] The demultiplexer 1602 can receive a data stream from the NoC 308. For example, the demultiplexer 1602 can be coupled to the NoC interface 1426. For illustration purposes, the data stream from the NoC interface 1426 can be 128 bits wide. Clock domain crossings between the DPE 304 and the NoC 308 can be handled within the NoC 308 and / or within the NoC stream interface 1414, as previously described. The demultiplexer 1602 can forward the received data stream to one of the FIFO memories 1604. The particular FIFO memory 1604 to which the demultiplexer 1602 provides the data stream can be encoded within the data stream itself. The FIFO memory 1604 is connected to a downsize circuit 1606 (abbreviated as "DS circuit" in FIG. 16). The downsize circuit 1606 can downsize the received stream to a narrower width after buffering using time division multiplexing. For example, the downsizing circuit 1606 may downsize a stream from 128 bits wide to 32 bits wide.

[0251] As shown, the downsize circuit 1606 and the upsize circuit 1608 are coupled to the stream switch 1406 or the stream multiplexer / demultiplexer 1408, depending on the particular architecture of the tile of the SoC interface block 104 used. Figure 16 is provided for illustrative purposes and is not intended as limiting. The order and / or connectivity of components (e.g., upsize / downsize circuits and FIFO memories) within a channel may vary.

[0252] In one or more other embodiments, the PL interface 1410 described in connection with FIG. 15 may include an upsizing circuit and / or a downsizing circuit as described in connection with FIG. 16. For example, a downsize circuit may be included in each channel that conveys data from the PL 310 (or other circuitry) to the stream switch 1406 and / or the stream multiplexer / demultiplexer 1408. An upsize circuit may be included in each channel that conveys data from the stream switch 1406 and / or the stream multiplexer / demultiplexer 1408 to the PL 310 (or other circuitry).

[0253] In one or more other embodiments, although shown as separate elements, each downsize circuit 1606 may be combined with a corresponding FIFO memory 1604, e.g., as a single block or circuit. Similarly, each upsize circuit 1608 may be combined with a corresponding FIFO memory 1610, e.g., as a single block or circuit.

[0254] FIG. 17 shows an exemplary implementation of the DMA engine 1412. In the example of FIG. 17, the DMA engine 1412 includes a DMA controller 1702. The DMA controller 1702 may be divided into two separate modules or interfaces. Each module can operate independently of the other. The DMA controller 1702 may include a memory-mapped-to-stream interface (interface) 1704 and a stream-to-memory-mapped interface (interface) 1706. Each of the interfaces 1704 and 1706 may include two or more separate channels. Thus, the DMA engine 1412 can receive two or more input streams from the stream switch 1406 via the interface 1706 and send two or more output streams to the stream switch 1406 via the interface 1704. The DMA controller 1702 may further include a master memory-mapped interface 1714. The master memory-mapped interface 1714 couples the NoC 308 to the interface 1704 and the interface 1706.

[0255] The DMA engine 1412 may also include a hardware synchronization circuit 1710 and a buffer descriptor register file 1708. The hardware synchronization circuit 1710 and the buffer descriptor register file 1708 may be accessed via a multiplexer 1712. Thus, both the hardware synchronization circuit 1710 and the buffer descriptor register file 1708 may be accessed externally through a control interface. Examples of such control interfaces include, but are not limited to, a memory-mapped interface or a control stream interface from the DPE. One example of a control stream interface of a DPE is a streaming interface output from the core of the DPE.

[0256] The hardware synchronization circuit 1710 may be used to synchronize multiple channels included in the DMA engine 1412 and / or a channel within the DMA engine 1412 with a master that polls and drives lock requests. For example, the master may be a device implemented within the PS312 or PL310. In another example, the master may also receive an interrupt generated by the hardware synchronization circuit 1710 within the DMA engine 1412 when a lock is available.

[0257] DMA transfers may be defined by buffer descriptors stored in a buffer descriptor register file 1708. The interface 1706 may request read transfers to the NoC 308 based on the information in the buffer descriptors. Outgoing streams from the interface 1704 to the stream switch 1406 may be configured as packet-switched or circuit-switched based on configuration registers for the stream switch.

[0258] FIG. 18 illustrates an exemplary architecture for multiple DPEs. This exemplary architecture illustrates a DPE 304 that may be included in the DPE array 102. The exemplary architecture of FIG. 18 may be referred to as a checkerboard architecture. The exemplary architecture of FIG. 18 allows a core of one DPE to communicate with up to eight other cores of other DPEs using shared memory (e.g., a total of nine cores communicating via shared memory). In the example of FIG. 18, each DPE 304 may be implemented as described in connection with FIGS. 6, 7, and 8. Thus, each core 602 can access four different memory modules 604. Each memory module 604 may be accessed by up to four different cores 602.

[0259] As shown, the DPE array 102 includes rows 1, 2, 3, 4, and 5. Each of rows 1 through 5 includes three DPEs 304. The specific number of DPEs 304 in each row and the number of rows shown in FIG. 18 are for illustrative purposes and not for limitation. With reference to rows 1, 3, and 5, the cores of each DPE in these rows are located to the left of the memory modules. With reference to rows 2 and 4, the cores of each DPE in these rows are located to the right of the memory modules. In effect, the orientation of the DPEs in rows 2 and 4 is horizontally inverted or horizontally flipped compared to the orientation of the DPEs in rows 1, 3, and 5. The orientation of the DPEs is reversed as shown in each alternating row.

[0260] In the example of FIG. 18, the DPEs 304 are aligned in columns. However, the cores and memory modules in adjacent rows are not aligned in columns. The architecture of FIG. 18 is an example of a heterogeneous architecture in which the DPEs are implemented differently based on the particular row in which they are located. Due to the horizontal flip of the DPEs 304, the cores in adjacent rows are not aligned. The cores in adjacent rows are offset from each other. Similarly, the memory modules in adjacent rows are not aligned. The memory modules in adjacent rows are offset from each other. However, the cores in every other row are aligned, as are the memory modules in every other row. For example, the cores and memory modules in rows 1, 3, and 5 are aligned vertically (e.g., in columns). Similarly, the cores and memory modules in rows 2 and 4 are aligned vertically (e.g., in columns).

[0261] For purposes of illustration, the cores in DPEs 304-2, 304-4, 304-5, 304-7, 304-8, 304-9, 304-10, 304-11, and 304-14 are considered part of a group and can communicate via shared memory. The arrows indicate how the exemplary architecture of FIG. 18 supports a core communicating with up to eight other cores in different DPEs using shared memory. Referring to DPE 304-8, for example, core 602-8 can access memory modules 604-11, 604-7, 604-8, and 604-5. Through memory module 604-11, core 602-8 can communicate with cores 602-14, 602-10, and 602-11. Through memory module 604-7, core 602-8 can communicate with cores 602-7, 602-4, and 602-10. Through memory module 604-8, core 602-8 can communicate with cores 602-9, 602-11, and 602-5. Through memory module 604-5, core 602-8 can communicate with cores 602-4, 602-5, and 602-2.

[0262] In the example of Figure 18, except for core 602-8, there are four different cores in the group that can access two different memory modules of the group's shared memory modules. The remaining four cores share only one memory module of the group's shared memory modules. The group's shared memory modules include memory modules 604-5, 604-7, 604-8, and 604-11. For example, Each of cores 602-10, 602-11, 602-4, and 602-5 can access two different memory modules. Core 602-10 can access memory modules 604-11 and 604-7. Core 602-11 can access memory modules 604-11 and 604-8. Core 602-4 can access memory modules 604-5 and 604-7. Core 602-5 can access memory modules 604-5 and 604-8.

[0263] 18, nine cores of up to nine total DPEs can communicate via shared memory without utilizing the DPE interconnect network of DPE array 102. As discussed, core 602-8 can view memory modules 604-11, 604-7, 604-5, and 604-8 as a unified memory space.

[0264] Cores 602-14, 602-7, 602-9, and 602-2 can access only one of the shared memory modules in the group. Core 602-14 can access memory module 604-11. Core 602-7 can access memory module 604-7. Core 602-9 can access memory module 604-8. Core 602-2 can access memory module 604-5.

[0265] As mentioned above, in other embodiments where more than four memory interfaces are provided for each memory module, a core can communicate with more than eight other cores via shared memory using the architecture of FIG. 18.

[0266] In one or more other embodiments, certain rows and / or columns of the DPE may be offset relative to other rows. For example, rows 2 and 4 may begin in a position that is not aligned with the beginning of rows 1, 3, and / or 5. For example, rows 2 and 4 may be shifted to the right relative to the beginning of rows 1, 3, and / or 5.

[0267] FIG. 19 illustrates another exemplary architecture for multiple DPEs. The exemplary architecture illustrates a DPE 304 that may be included in the DPE array 102. The exemplary architecture illustrated in FIG. 19 may be referred to as a grid architecture. The exemplary architecture of FIG. 19 allows a core of one DPE to communicate with up to 10 other cores of other DPEs using shared memory (e.g., a total of 11 cores communicating via shared memory). In the example of FIG. 19, each DPE 304 may be implemented as described in connection with FIGS. 6, 7, and 8. Thus, each core 602 can access four different memory modules 604. Each memory module 604 may be accessed by up to four different cores 602.

[0268] As shown, the DPE array 102 includes rows 1, 2, 3, 4, and 5. Each of rows 1 through 5 includes three DPEs 304. The specific number of DPEs 304 in each row and the number of rows shown in FIG. 19 are for illustrative purposes and not for limitation. In the example of FIG. 19, the DPEs 304 are aligned vertically in columns. Rows 1, 2, 3, 4, and 5 each have the same starting point, aligned with each other row of DPEs. Furthermore, the arrangement of the cores 602 and memory modules 604 within each respective DPE 304 is the same. In other words, the cores 602 are aligned vertically. Similarly, the memory modules 604 are aligned vertically.

[0269] For illustration purposes, DPEs 304-2, 304-4, 304-5, 304-6, 304-7, 304-8, 304-9, 304-10, 304-11, 304-12, and 304- The 14 cores are considered part of a group and can communicate via shared memory. The arrows indicate how the exemplary architecture of FIG. 19 supports a core communicating with up to 10 other cores in different DPEs using shared memory. Referring to DPE 304-8, for example, core 602-8 can access memory modules 604-11, 604-8, 604-5, and 604-9. Through memory module 604-11, core 602-8 can communicate with cores 602-14, 602-10, and 602-11. Through memory module 604-8, core 602-8 can communicate with cores 602-7, 602-11, and 602-5. Through memory module 604-5, core 602-8 can communicate with cores 602-4, 602-5, and 602-2. Through memory module 604-9, core 602-8 can communicate with cores 602-12, 602-9, and 602-6.

[0270] In the example of FIG. 19, except for core 602-8, there are two different cores in the group that can access two of the group's shared memory modules. The group's shared memory modules include memory modules 604-5, 604-8, 604-9, and 604-11. The remaining eight cores in the group share only one memory module. For example, cores 602-11 and 602-5 can each access two different memory modules. Core 602-11 can access memory modules 604-11 and 604-8. Because memory module 604-14 is not accessible by core 604-8, memory module 604-14 is not considered part of the group of shared memory modules. Core 602-5 can access memory modules 604-5 and 604-8. Because memory module 604-2 is not accessible by core 602-8, memory module 604-2 is not considered part of the group of shared memory modules.

[0271] Cores 602-14, 602-10, 602-12, 602-7, 602-9, 602-4, 602-6, and 602-2 can access only one of the shared memory modules in the group. Core 602-14 can access memory module 604-11. Core 602-10 can access memory module 604-11. Core 602-12 can access memory module 604-9. Core 602-7 can access memory module 604-8. Core 602-9 can access memory module 604-9. Core 602-4 can access memory module 604-5. Core 602-6 can access memory module 604-9. Core 602-2 can access memory module 604-5.

[0272] 19, eleven cores of up to eleven DPEs can communicate via shared memory without utilizing the DPE interconnect network of DPE array 102. As discussed, core 602-8 can view memory modules 604-11, 604-9, 604-5, and 604-8 as a unified memory space.

[0273] As mentioned above, in other embodiments where more than four memory interfaces are provided for each memory module, a core can communicate with more than ten other cores via shared memory using the architecture of FIG. 19.

[0274] 20 illustrates an exemplary method 2000 for configuring a DPE array. Method 2000 is provided for illustrative purposes and is not intended to limit the inventive configurations described within this disclosure.

[0275] Configuration data for the DPE array is loaded into the device at block 2002. The configuration data may be provided from any of a variety of different sources, whether from a computer system (e.g., a host), off-chip memory, or other suitable source.

[0276] In block 2004, configuration data is provided to an SoC interface block. In particular embodiments, the configuration data is provided via an NoC. A tile of the SoC interface block can receive the configuration data and convert the configuration data into memory-mapped data, which can be provided to a memory-mapped switch included within the tile.

[0277] In block 2006, the configuration data propagates between tiles of the SoC interface block to particular tiles that act as or provide an interface to the target DPE. The target DPE is the DPE to which the configuration data is addressed. For example, the configuration data includes addresses that specify the particular DPEs to which different portions of the configuration data should be directed. Memory-mapped switches within the tiles of the SoC interface block can propagate the different portions of the configuration data to particular tiles that act as interfaces for the target DPEs (e.g., a subset of the DPEs that includes the target DPE).

[0278] In block 2008, tiles of the SoC interface block that act as interfaces to target DPEs can direct portions of the configuration data for the target DPEs to the target DPEs. For example, a tile that provides an interface to one or more target DPEs can direct portions of the configuration data to a subset of the DPEs to which the tile provides an interface. As described above, the subset of DPEs includes one or more target DPEs. As each tile receives the configuration data, it can determine whether any portions of the configuration data are addressed to other DPEs in the same subset of DPEs to which the tile provides an interface. The tile directs any configuration data addressed to DPEs in the subset of DPEs to such DPEs.

[0279] In block 2010, the configuration data is loaded into the target DPE to program the elements of the DPE contained therein. For example, the configuration data is loaded into configuration registers to program elements of the target DPE, such as a stream interface, a core (e.g., a stream interface, a cascade interface, a core interface), a memory module (e.g., a DMA engine, a memory interface, an arbiter, etc.), a broadcast event switch, and / or broadcast logic. The configuration data may also include executable program code that may be loaded into the program memory of a core and / or data that may be loaded into the memory banks of a memory module.

[0280] It should be appreciated that the received configuration data may also include portions addressed to one or more or all of the tiles of the SoC interface block 104. In that case, a memory-mapped switch within each tile may transmit the configuration data to the appropriate (e.g., target) tile, extract such data, and write such data to the appropriate configuration registers within the respective tile.

[0281] 21 illustrates an exemplary method 2100 of operation of a DPE array. Method 2100 is provided for illustrative purposes and is not intended to limit the inventive configurations described within this disclosure. Method 2100 may include a DPE and / or SoC interface block. The process starts with the configuration data loaded into the . For illustration, refer to Figure 3.

[0282] In block 2102, a core 602-15 (e.g., a "first core") of a DPE 304-15 (e.g., a "first DPE") generates data. The generated data may be application data. For example, the core 602-15 may process data stored in a memory module accessible by the core. The memory module may be within the DPE 304-15 or within a different DPE, as described herein. The data may be received from another DPE and / or another subsystem of the device, for example, using the SoC interface block 104.

[0283] At block 2104, core 602-15 stores data in memory module 604-15 of DPE 304-15. At block 2106, one or more cores in a neighboring DPE (e.g., DPE 304-25, 304-16, and / or 304-5) read data from memory module 604-15 of DPE 304-15. The cores in the neighboring DPEs can use the data read from memory module 604-15 for further computation.

[0284] In block 2108, the DPE 304-15 optionally transmits the data to one or more other DPEs via the stream interface. The DPEs to which the data is transmitted may be non-proximate DPEs. For example, the DPE 304-15 may transmit data from the memory module 604-15 to one or more other DPEs, such as the DPEs 304-35 and 304-36. As discussed, in one or more embodiments, the DPE 304-15 may broadcast and / or multicast application data via a stream interface within the DPE interconnect network of the DPE array 102. In another example, the data transmitted to different DPEs may be different portions of the data, with each different portion of the data intended for a different target DPE. Although not shown in FIG. 21 , the core 602-15 may also transmit data to another core and / or DPE of the DPE array 102 using a cascade interface and / or directly from the core using a stream switch.

[0285] In block 2110, core 602-15 optionally transmits data to and / or receives data from neighboring cores via the cascade interface. The data may be application data. For example, core 602-15 may receive data directly from core 602-14 of DPE 304-14 and / or transmit data directly to core 602-16 of DPE 304-16 via the cascade interface.

[0286] In block 2112, the DPE 304-15 optionally transmits data to and / or receives data from one or more subsystems via the SoC interface block. The data may be application data. For example, the DPE 304-15 may transmit data to the PS 312 via the NoC 308, to a circuit implemented in the PL 310, to selected hardwired circuit blocks via the NoC 308, to selected hardwired circuit blocks via the PL 310, and / or to other external subsystems, such as external memory. Similarly, the DPE 304-15 may receive application data from such other subsystems via the SoC interface block.

[0287] 22 illustrates another exemplary method 2200 of operation of a DPE array. Provided for purposes of illustration and not intended to limit the inventive configurations described within this disclosure, method 2200 begins with the DPE array loaded with configuration data.

[0288] In block 2202, a first core, e.g., a core in a first DPE, requests a lock on a target memory region from a hardware synchronization circuit. The first core may, for example, request a lock from a hardware synchronization circuit for a target memory region in a memory module located in the same DPE as the first core, e.g., the first core, or for a target memory region in a memory module located in a different DPE than the first core. The first core may request a lock from a particular hardware synchronization circuit located in the same DPE as the target memory region to be accessed.

[0289] The first core acquires the requested lock at block 2204. For example, the hardware synchronization circuit grants the requested lock to the target memory region to the first core.

[0290] In block 2206, in response to acquiring the lock, the first core writes data to the target memory region. For example, if the target memory region is within the first DPE, the first core may write data to the target memory region via a memory interface located in a memory module within the first DPE. In another example, if the target memory region is located on a different DPE than the first core, the first core may write data to the target memory region using any of the various techniques described herein. For example, the first core may write data to the target memory region via any of the mechanisms described in connection with FIG. 10 .

[0291] In block 2208, the first core releases the lock on the target memory region. In block 2210, the second core requests a lock on the target memory region containing the data written by the first core. The second core may be located in the same DPE as the target memory region or in a different DPE than the target memory region. The second core requests the lock from the same hardware synchronization circuit that granted the lock to the first core. In block 2212, the second core acquires the lock from the hardware synchronization circuit. The hardware synchronization circuit grants the lock to the second core. In block 2214, the second core can access the data from the target memory region and use the data for processing. In block 2216, the second core releases the lock for the target memory region, for example, if access to the target memory region is no longer required.

[0292] The example of Figure 22 is described with reference to accessing a memory region. In particular embodiments, a first core may write data directly to a target memory region. In other embodiments, a first core may move data from a source memory region (e.g., in a first DPE) to a target memory region (e.g., located in a second or different DPE). In this case, the first core acquires locks on the source and target memory regions to perform the data transfer.

[0293] In other embodiments, a first core may acquire a lock on a second core to stall the operation of the second core, and then release the lock to allow the second core to continue operation. For example, a first core may acquire a lock on a target memory region as well as a lock on the second core to stall the operation of the second core while data is written to the target memory region for use by the second core. Once the first core has finished writing the data, the first core may release the lock on the target memory region and the lock on the second core. The lock may be released so that the second core can process the data once it has acquired the lock on the target memory region.

[0294] In yet another embodiment, as shown in FIG. 10C, a first core may initiate a data transfer directly from a memory module within the same DPE to another core, for example, via a DMA engine within the memory module.

[0295] 23 illustrates another exemplary method of operation of a DPE array. Method 2300 is provided for illustrative purposes and is not intended to limit the inventive configurations described within this disclosure. Method 2300 begins with the DPE array being loaded with configuration data.

[0296] In block 2302, the first core places data in an accumulation register included therein. For example, the first core may perform a calculation, whether an intermediate result or a final result, of which part is to be provided directly to another core. In this case, the first core may load data to be sent to the second core into an accumulation register included therein.

[0297] In block 2304, the first core transmits data from an accumulation register included therein to the second core via the first core's cascade interface output. In block 2306, the second core receives the data from the first core on the second core's cascade interface input. The second core can then process the data or store the data in memory.

[0298] In one or more embodiments, utilization of the cascade interface by a core may be controlled by loading configuration data. For example, the cascade interface may be enabled or disabled between consecutive pairs of cores as needed for a particular application based on the configuration data. In particular embodiments, the cascade interface may be enabled and utilization of the cascade interface may be controlled based on program code loaded into the program memory of the core. In other cases, utilization of the cascade interface may be controlled by dedicated circuitry and configuration registers included in the core.

[0299] 24 illustrates another exemplary method of operation of a DPE array. Method 2400 is provided for illustrative purposes and is not intended to limit the inventive configurations described within this disclosure. Method 2400 begins with the DPE array being loaded with configuration data.

[0300] At block 2402, event logic within the first DPE detects one or more events locally within the first DPE. The events may be detected from a core, a memory module, or both a core and a memory module. At block 2404, event broadcast circuitry within the first DPE broadcasts events based on configuration data loaded into the first DPE. The broadcast circuitry may broadcast selected events from those generated at block 2402. The event broadcast circuitry may also broadcast selected events that may be received from one or more other DPEs in the DPE array 102.

[0301] At block 2406, events from the DPE are propagated to tiles within the SoC interface block. For example, events may be propagated in each of the four cardinal directions through the DPE in a pattern and / or route determined by configuration data. Broadcast circuitry within a particular DPE may be configured to propagate events to tiles within the SoC interface block.

[0302] Event logic within the tile of the SoC interface block optionally generates an event at block 2408. The tile of the SoC interface block optionally broadcasts the event to other tiles within the SoC interface block at block 2410. Broadcast circuitry within the tile of the SoC interface block can broadcast selected events generated by the tile itself and / or events received from other sources (e.g., whether other tiles of the SoC interface block or the DPE) to other tiles of the SoC interface block.

[0303] In block 2412, the tiles of the SoC interface block optionally generate one or more interrupts. The interrupts may be generated, for example, by the interrupt handler 1434. The interrupt handler can generate one or more interrupts in response to receiving a particular event, combination of events, and / or sequence of events over time. The interrupt handler can send the generated interrupts to other circuits, such as the PS 312 and / or circuits implemented within the PL 310.

[0304] The tiles of the SoC interface block optionally transmit the events to one or more other circuits in block 2414. For example, the CDT circuit 1420 may packetize the events and transmit the events from the tiles of the SoC interface block to the PS 312, to circuitry within the PL 310, to external memory, or to another destination with the SoC.

[0305] In one or more embodiments, PS 312 can respond to interrupts generated by tiles of SoC interface block 104. For example, PS 312 can reset DPE array 102 in response to receiving a particular interrupt. In another example, PS 312 can reconfigure DPE array 102 or a portion of DPE array 102 (e.g., perform a partial reconfiguration) in response to a particular interrupt. In another example, PS 312 can take other actions, such as loading new data into different memory modules of the DPE for use by cores in the DPE.

[0306] In the example of FIG. 24 , PS 312 performs operations in response to an interrupt. In other embodiments, PS 312 may operate as a global controller for DPE array 102. PS 312 can control application parameters stored in a memory module and used by one or more DPEs (e.g., cores) of DPE array 102 during runtime. As an illustrative and non-limiting example, one or more DPEs may operate as a kernel implementing a filter. In this case, PS 312 can execute program code that enables PS 312 to calculate and / or modify coefficients of the filter during runtime of DPE array 102, e.g., dynamically at runtime. PS 312 can calculate and / or update coefficients in response to certain conditions and / or signals detected within the SoC. For example, PS 312 can calculate new coefficients for a filter and / or write such coefficients to application memory (e.g., to one or more memory modules) in response to some detected condition. Examples of conditions that may cause PS 312 to write data, such as coefficients, to the memory module may include, but are not limited to, receiving specific data from DPE array 102, receiving an interrupt from the SoC interface block, receiving event data from DPE array 102, receiving a signal from a source external to the SoC, receiving another signal from within the SoC, and / or receiving new and / or updated coefficients from a source within the SoC or from outside the SoC. The PS 312 can calculate new coefficients and / or write new coefficients to application data, for example, memory modules utilized by the cores.

[0307] In another example, the PS 312 may execute a debugger application that can perform actions such as starting, stopping, and / or single-stepping execution of the DPE. The PS 312 may control starting, stopping, and / or single-stepping of the DPE via the NoC 308. In other examples, circuitry implemented in the PL 310 may be capable of controlling the operation of the DPE using debug operations.

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

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

[0310] 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, the phrases "at least one of A, B, and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C," and "A, B, and / or C" each mean A only, B only, C only, A and B together, A and C together, B and C together, or A, B, and C together.

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

[0312] As defined herein, the word "if" may be interpreted as "when" or "upon" or "in respone to" or "in response to," depending on the context. Thus, the phrases "if it is determined" or "if [a stated condition or event] is detected" may be interpreted to mean "upon determining" or "in response to determining" or "upon detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]" or "responsive to detecting [the stated condition or event]," depending on the context.

[0313] As defined herein, the phrase "response to" and and similar phrases as described above, such as "if," "when," or "upon," mean to readily respond or react to an action or event. The response or reaction occurs automatically. Thus, when a second action is performed "in response" to a first action, a causal relationship exists between the occurrence of the first action and the occurrence of the second action. The phrase "in response" indicates a causal relationship.

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

[0315] As defined herein, the term "substantially" means that the recited property, parameter, or value need not be achieved exactly, but that deviations or variations, including, for example, tolerances, measurement errors, measurement accuracy limitations, and other factors known to those skilled in the art, may occur in amounts that do not eliminate the effect intended to be imparted by the property.

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

[0317] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, devices, and / or methods according to various aspects of the present invention. In some alternative implementations, the operations noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may be executed substantially concurrently, or may sometimes be executed in the reverse order, depending on the functionality involved. In other examples, the blocks may be executed in generally ascending numerical order, while in still other examples, one or more blocks may be executed in a variety of orders, with the results stored and utilized in a subsequent block or other blocks that do not immediately follow.

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

[0319] In one or more embodiments, a device may include multiple DPEs. Each DPE may include a core and a memory module. Each core may be configured to access a memory module within the same DPE and a memory module within at least one other DPE of the multiple DPEs.

[0320] In one aspect, each core may be configured to access memory modules of multiple nearby DPEs.

[0321] In another embodiment, the cores of multiple DPEs may be directly coupled. In another embodiment, each of the plurality of DPEs is a hardwired and programmable circuit block.

[0322] In another aspect, each DPE may include interconnect circuitry including a stream switch configured to communicate with one or more selected DPEs from the plurality of DPEs. The stream switch may be programmable to communicate with one or more selected DPEs, e.g., other DPEs.

[0323] The device may also include a subsystem and an SoC interface block configured to couple multiple DPEs to the subsystem of the device. In one aspect, the subsystem includes programmable logic. In another aspect, the subsystem includes a processor configured to execute program code. In yet another aspect, the subsystem includes application specific integrated circuits and / or analog / mixed signal circuits.

[0324] In another aspect, the stream switch is coupled to the SoC interface block and configured to communicate with a subsystem of the device.

[0325] In another aspect, the interconnect circuitry of each DPE may include a memory-mapped switch coupled to the SoC interface block, the memory-mapped switch configured to communicate configuration data for programming the DPE from the SoC interface block. The memory-mapped switch may be configured to communicate at least one of control data or debug data with the SoC interface block.

[0326] In another aspect, multiple DPEs may be interconnected by an event broadcast network.

[0327] In another aspect, the SoC interface block may be configured to exchange events between the subsystem and an event broadcast network of multiple DPEs.

[0328] In one or more embodiments, a method may include a first core of a first data processing engine generating data, the first core writing the data to a first memory module in the first data processing engine, and a second core of a second data processing engine reading the data from the first memory module.

[0329] In one aspect, the method may include the first DPE and the second DPE being neighboring DPEs.

[0330] In another aspect, the method may further include allowing the first core to provide additional application data directly to the second core via the cascade interface.

[0331] In another aspect, the method may further include the first core being able to provide the application data to the third DPE via the stream switch.

[0332] In another aspect, the method may include programming the first DPE to communicate with selected other DPEs, including the second DPE.

[0333] In one or more embodiments, a device may include multiple data processing engines, a subsystem, and an SoC interface block coupled to the multiple data processing engines and the subsystem. The SoC interface block may be configured to exchange data between the subsystem and the multiple data processing engines.

[0334] In one aspect, the subsystem includes programmable logic. In another aspect, the subsystem includes a processor configured to execute program code. In another aspect, the subsystem includes application specific integrated circuits and / or analog / mixed signal circuits.

[0335] In another aspect, the SoC interface block includes multiple tiles, each configured to communicate with a subset of the multiple DPEs.

[0336] In another aspect, each tile may include a memory-mapped switch configured to provide a first portion of the configuration data to at least one neighboring tile and to provide a second portion of the configuration data to at least one of a subset of the plurality of DPEs.

[0337] In another aspect, each tile may include a stream switch configured to provide first data to at least one neighboring tile and second data to at least one of the plurality of DPEs.

[0338] In another aspect, each tile may include event broadcasting circuitry configured to receive events generated within the tile and events from circuitry external to the tile, the event broadcasting circuitry being programmable to provide selected ones of the events to selected destinations.

[0339] In another aspect, the SoC interface block may include control, debug, and trace circuitry configured to packetize selected events and provide the packetized selected events to the subsystem.

[0340] In another aspect, the SoC interface block can include an interface that couples the event broadcast circuitry to the subsystem.

[0341] In one or more embodiments, a tile for an SoC interface block may include a memory-mapped switch configured to provide a first portion of configuration data to a neighboring tile and a second portion of the configuration data to a data processing engine of a plurality of data processing engines. The tile may include a stream switch configured to provide the first data to at least one neighboring tile and the second data to a data processing engine of the plurality of data processing engines. The tile may include an event broadcast circuit configured to receive events generated within the tile and events from circuitry external to the tile, the event broadcast circuit being programmable to provide selected ones of the events to selected destinations. The tile may include an interface circuit coupling the memory-mapped switch, the stream switch, and the event broadcast circuit to a subsystem of a device including the tile.

[0342] In one aspect, the subsystem includes programmable logic. In another aspect, the subsystem includes a processor configured to execute program code. In another aspect, the subsystem includes application specific integrated circuits and / or analog / mixed signal circuits.

[0343] In another aspect, the event broadcast circuitry is programmable to provide events generated within the tile or received from at least one of the plurality of DPEs to the subsystem.

[0344] In another aspect, the event broadcast circuitry is programmable to provide events generated within the subsystem to at least one neighboring tile or at least one of the plurality of DPEs.

[0345] In another aspect, the tiles may be configured to broadcast events based on events received from the event broadcast circuitry. The device may include an interrupt handler configured to selectively generate an interrupt to a processor of the device based on the received signal.

[0346] In another aspect, a tile may include a clock generation circuit configured to generate a clock signal that is distributed to multiple DPEs.

[0347] In another aspect, the interface circuit may include a stream multiplexer / demultiplexer, a programmable logic interface, a direct memory access engine, and an NoC stream interface. The stream multiplexer / demultiplexer can couple the stream switch to the programmable logic interface, the direct memory access engine, and the network-on-chip stream interface. The stream multiplexer / demultiplexer is programmable to route data between the stream switch, the programmable logic interface, the direct memory access engine, and the NoC stream interface.

[0348] In another aspect, the tile can include a switch coupled to the DMA engine and the NoC stream interface, the switch selectively coupling the DMA engine or the NoC stream interface to the NoC. The tile can also include a bridge circuit coupling the NoC with the memory-mapped switch. The bridge circuit is configured to convert data from the NoC into a format usable by the memory-mapped switch.

[0349] In one or more embodiments, a device may include multiple data processing engines. Each of the data processing engines may include a core and a memory module. The multiple data processing engines may be organized into multiple columns. Each core may be configured to communicate with other nearby data processing engines of the multiple data processing engines by shared access to the memory modules of the other nearby data processing engines.

[0350] In one aspect, the memory module of each DPE includes a memory and multiple memory interfaces to the memory, where a first memory interface of the multiple memory interfaces may be coupled to a core within the same DPE and each of the other memory interfaces of the multiple memory interfaces may be coupled to a core of a different DPE of the multiple DPEs.

[0351] In another aspect, the multiple DPEs may be further organized into multiple columns, with the cores of the multiple DPEs in a column aligned and the memory modules of the multiple DPEs in a column aligned.

[0352] In another aspect, the memory module of the selected DPE may include a first memory interface coupled to a core of the DPE immediately above the selected DPE, a second memory interface coupled to a core within the selected DPE, a third memory interface coupled to a core of the DPE immediately adjacent to the selected DPE, and a fourth memory interface coupled to a core of the DPE immediately below the selected DPE.

[0353] In another aspect, the selected DPE is configured to communicate with a group of at least 10 DPEs of the plurality of DPEs via shared access to the memory module.

[0354] In another aspect, at least two of the DPEs in the group have access to two or more memory modules in a group of at least 10 DPEs in the plurality of DPEs. It is configured to

[0355] In another aspect, the multiple rows of DPEs may include a first row including a first subset of the multiple DPEs and a second row including a second subset of the multiple DPEs, wherein the orientation of each DPE in the second row is horizontally flipped relative to the orientation of each DPE in the first row.

[0356] In another aspect, the memory module of the selected DPE may include a first memory interface coupled to a core of the DPE immediately above the selected DPE, a second memory interface coupled to a core within the selected DPE, a third memory interface coupled to a core of the DPE immediately adjacent to the selected DPE, and a fourth memory interface coupled to a core of the DPE immediately below the selected DPE.

[0357] In another aspect, the selected DPE may be configured to communicate with a group of at least eight DPEs of the plurality of DPEs via shared access to a memory module.

[0358] In another aspect, at least four DPEs of the group are configured to access two or more memory modules of a group of at least eight DPEs of the plurality of DPEs.

[0359] In one or more embodiments, a device may include multiple data processing engines, each of which may include a memory pool having multiple memory banks, multiple cores, each coupled to the memory pool and configured to access the multiple memory banks, a memory-mapped switch coupled to the memory pool and to the memory-mapped switch of at least one neighboring data processing engine, and a stream switch coupled to each of the multiple cores and to the stream switch of at least one neighboring data processing engine.

[0360] In one aspect, the memory pool may include a crossbar coupled to each of the plurality of memory banks, and an interface coupled to each of the plurality of cores and the crossbar.

[0361] In another aspect, each DPE may include a direct memory access engine coupled to a memory pool and a stream switch, the direct memory access engine configured to provide data from the memory pool to the stream switch and write data from the stream switch to the memory pool.

[0362] In another aspect, the memory pool may include an additional interface coupled to the crossbar and the direct memory access engine.

[0363] In another aspect, each of the multiple cores has shared access to multiple memory banks. In another aspect, within each DPE, a memory-mapped switch may be configured to receive configuration data for programming the DPE.

[0364] In another aspect, the stream switch is programmable to establish connections with different ones of the plurality of DPEs based on configuration data.

[0365] In another aspect, the cores within each tile may be directly coupled. In another aspect, within each DPE, the first core of the plurality of cores may be directly coupled to a core in a first neighboring DPE, and the last core of the plurality of cores may be directly coupled to a core in a second neighboring DPE. The DPE is directly coupled to the core.

[0366] In another aspect, each of the multiple cores may be programmable to be deactivated. The description of the inventive configurations provided herein is for illustrative purposes and is not intended to be exhaustive or limited to the disclosed forms and examples. The terminology used herein has been selected to explain the principles of the inventive configurations, their practical applications or technical improvements over commercially available technologies, and / or to enable those skilled in the art to understand the inventive configurations disclosed herein. Modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the inventive configurations described. Accordingly, reference should be made to the claims, rather than the foregoing disclosure, as indicating the scope of such features and implementations.

Claims

1. A device, Equipped with multiple data processing engines, Each data processing engine includes a core and a memory module; the plurality of data processing engines are organized into a plurality of rows; 10. A device, wherein each core is configured to communicate with other nearby data processing engines of the plurality of data processing engines by shared access to memory modules of the other nearby data processing engines.

2. 2. The device of claim 1, wherein the memory module of each data processing engine includes a memory and a plurality of memory interfaces to the memory, a first memory interface of the plurality of memory interfaces being coupled to a core within a same data processing engine and each other memory interface of the plurality of memory interfaces being coupled to a core of a different data processing engine of the plurality of data processing engines.

3. 3. The device of claim 2, wherein the plurality of data processing engines are further organized into a plurality of columns, the cores of the plurality of data processing engines within the columns being aligned, and the memory modules of the plurality of data processing engines within the columns being aligned.

4. The memory modules of the selected data processing engine are a first memory interface coupled to a core of a data processing engine immediately above the selected data processing engine; a second memory interface coupled to a core within the selected data processing engine; a third memory interface coupled to a core of a data processing engine immediately adjacent to the selected data processing engine; a fourth memory interface coupled to a core of a data processing engine immediately below the selected data processing engine.

5. 4. The device of claim 3, wherein a selected data processing engine is configured to communicate with a group of at least 10 data processing engines of the plurality of data processing engines via shared access to a memory module.

6. 6. The device of claim 5, wherein at least two data processing engines of the group are configured to access two or more memory modules of a group of at least ten data processing engines of the plurality of data processing engines.

7. The plurality of rows of data processing engines include: a first row including a first subset of the plurality of data processing engines; a second row including a second subset of the plurality of data processing engines, wherein an orientation of each data processing engine in the second row is horizontally flipped relative to an orientation of each data processing engine in the first row.

8. The memory modules of the selected data processing engine are a first memory interface coupled to a core of a data processing engine immediately above the selected data processing engine; a second memory interface coupled to a core within the selected data processing engine; coupled to a core of a data processing engine immediately adjacent to the selected data processing engine; a third memory interface; and a fourth memory interface coupled to a core of a data processing engine immediately below the selected data processing engine.

9. 8. The device of claim 7, wherein a selected data processing engine is configured to communicate with a group of at least eight data processing engines of the plurality of data processing engines via shared access to a memory module.

10. 10. The device of claim 9, wherein at least four data processing engines of the group are configured to access two or more memory modules of a group of at least eight data processing engines of the plurality of data processing engines.

11. A device, Equipped with multiple data processing engines, Each data processing engine array a memory pool having a plurality of memory banks; a plurality of cores, each coupled to the memory pool and configured to access the plurality of memory banks; a memory-mapped switch coupled to the memory pool and to a memory-mapped switch of at least one adjacent data processing engine; a stream switch coupled to each of the plurality of cores and to a stream switch of the at least one proximate data processing engine.

12. The memory pool includes: a crossbar coupled to each of the plurality of memory banks; 12. The device of claim 11, comprising: an interface coupled to each of the plurality of cores and to the crossbar.

13. Each data processing engine further comprises:

13. The device of claim 12, further comprising: a direct memory access engine coupled to the memory pool and the stream switch, the direct memory access engine configured to provide data from the memory pool to the stream switch and to write data from the stream switch to the memory pool.

14. The memory pool further comprises: The device of claim 13 including a further interface coupled to the crossbar and the direct memory access engine.

15. The device of claim 11 , wherein each of the multiple cores has shared access to the multiple memory banks.

16. 12. The device of claim 11, wherein within each data processing engine, the memory-mapped switch is configured to receive configuration data for programming the data processing engine.

17. 17. The device of claim 16, wherein the stream switch is programmable to establish connections with different data processing engines of the plurality of data processing engines based on the configuration data.

18. The device of claim 11 , wherein the cores in each tile are directly coupled.

19. 20. The device of claim 18, wherein within each data processing engine, a first core of the plurality of cores is directly coupled to a core in a first nearby data processing engine, and a last core of the plurality of cores is directly coupled to a core in a second nearby data processing engine.

20. The device of claim 11 , wherein each of the plurality of cores is programmable to be deactivated.

Images