Compilation flow for heterogeneous multicore architectures

Abstract

An example method of implementing an application for a system on a chip (SOC) having an array of data processing engines (DPEs) includes determining a graph representation of the application, the graph representation including nodes representing application kernels and edges representing communication between the kernels; mapping the kernels onto DPEs of the array of DPEs and mapping data structures of the kernels onto memories in the array of DPEs based on the graph; routing communication channels between the DPEs and circuits of the application configured in programmable logic of the SOC; and generating implementation data for programming the SOC to implement the application based on results of the mapping and routing.

Description

TECHNICAL FIELD

[0001] Examples of the present disclosure relate generally to electronic circuit design, and in particular, to compilation flows for heterogeneous multi-core architectures. BACKGROUND

[0002] Processors, system on chips (SoCs), and application specific integrated circuits (ASICs) can include multiple cores for performing computational operations, such as processing digital signals, performing encryption, executing software applications, rendering graphics, and the like. While there are many multi-core architectures, compilers for these architectures do not directly handle heterogeneous architectures, particularly multi-core processors coupled with reconfigurable / programmable logic (e.g., field programmable gate array (FPGA) fabric). Further, existing compilers do not address mapping of computational kernels to processor cores and data structures to memory banks, and routing of streaming data and direct memory access (DMA) data between processor cores and between processor cores and programmable logic. SUMMARY

[0003] Techniques related to compilation flows for heterogeneous multi-core architectures are described. In one example, a method of implementing an application for a system on chip (SOC) having an array of data processing engines (DPEs) includes determining a graph representation of the application, the graph representation including nodes representing kernels of the application and edges representing communication between the kernels; mapping the kernels to DPEs of the array of DPEs and mapping data structures of the kernels to memory in the array of DPEs based on the graph; routing communication channels between circuits of the application configured in the DPEs and programmable logic of the SOC; and generating implementation data for programming the SOC to implement the application based on results of the mapping and the routing.

[0004] In another example, a non-transitory computer-readable medium has instructions stored thereon that, when executed by a processor, cause the processor to perform a method for implementing an application for a system on chip (SOC) having an array of data processing engines (DPEs), the method including determining a graph representation of the application, the graph representation including nodes representing kernels of the application and edges representing communication between the kernels; mapping the kernels to DPEs of the array of DPEs and mapping data structures of the kernels to memory in the array of DPEs based on the graph; routing communication channels between circuits of the application configured in the DPEs and programmable logic of the SOC; and generating implementation data for programming the SOC to implement the application based on results of the mapping and the routing.

[0005] In another example, a computer system includes a memory configured to store program code and a processor configured to execute the program code to apply an implementation of an application for a system on a chip (SOC) having an array of data processing engines (DPEs) by: determining a graph representation of the application, the graph representation including nodes representing kernels of the application and edges representing communications between the kernels; mapping the kernels onto DPEs of the array of DPEs and data structures of the kernels onto memories in the array of DPEs based on the graph; routing communication channels between circuits of the application configured in the DPEs and programmable logic of the SOC; and generating implementation data for programming the SOC to implement the application based on results of the mapping and the routing.

[0006] These and other aspects can be understood with reference to the following detailed description. BRIEF DESCRIPTION OF DRAWINGS

[0007] So that the manner in which the above-recited features can be understood, a brief overview of the examples can be had below, some of which are illustrated in the appended drawings. It should be noted that the appended drawings illustrate only typical examples and should not be considered limiting of its scope.

[0008] Figure 1 is a block diagram of a system on a chip (SoC) in accordance with an example.

[0009] Figure 2 is a block diagram depicting a cell block circuit in accordance with an example.

[0010] Figure 3 is a block diagram depicting a cell block circuit in accordance with an example. Figure 2

[0011] Figure 4 is a block diagram depicting a cell block interconnect circuit in accordance with an example.

[0012] Figure 5 is a block diagram depicting an example of a circuit design system in accordance with an example.

[0013] Figure 6 is a block diagram depicting an implementation of an application for a target platform in accordance with an example.

[0014] Figure 7 is a block diagram depicting an application in accordance with an example.

[0015] Figure 8 is a block diagram depicting a data processing engine (DPE) array compiler in accordance with an example.

[0016] Figures 9A-9D is a block diagram depicting an example directed graph representation of a portion of an application for a DPE array in accordance with an example.

[0017] ​Figure 10 is a block diagram depicting layout and routing of a directed graph in a DPE array, according to an example.

[0018] Figure 11 is a flow diagram of a method of generating code and configuration data for a data processing engine array that is a SOC, according to an example.

[0019] Figure 12 is a flow diagram of a method of partitioning kernels in an application among data processing engines, according to an example.

[0020] Figure 13 is a flow diagram of a method of assigning kernels to partitions, according to an example.

[0021] Figure 14 is a flow diagram of a method of mapping kernels and kernel groups onto DPEs, according to an example.

[0022] Figure 15 is a flow diagram of a method of FIFO insertion when implementing an application of a heterogeneous multi-core architecture.

[0023] Figure 16 is a block diagram of a processing system, according to an example.

[0024] Figure 17A is a block diagram of an implementation of the processing system of Figure 16 , according to an example.

[0025] Figure 17B is a block diagram of an implementation of the processing system of Figure 16 , according to another example.

[0026] Figure 18 is a flow diagram of a method of placing FIFOs, according to an example.

[0027] Figure 19 is a flow diagram of a method of routing an application that is mapped to a DPE array, according to an example.

[0028] Figure 20 is a block diagram of a programmable IC, according to an example, that can be used as an implementation of the SoC shown in Figure 1 .

[0029] Figure 21 is illustrated a field programmable gate array (FPGA) implementation of the programmable IC of Figure 20 , according to an example.

[0030] To facilitate an understanding of this description, like reference characters are used to identify like elements throughout the description and the drawings. It should be appreciated that elements of one example can be advantageously substituted for elements of another example. DETAILED DESCRIPTION

[0031] Various features are described with reference to the drawings. It should be noted that the figures can be drawn to scale and that in the entire document like reference numerals are used to denote like structures or functions throughout the drawings. It should be noted that the figures are merely meant to facilitate description of the features. They are not intended as a definition of the limits of the claimed invention or the scope of the claimed invention. Moreover, the illustrated examples need not have all the aspects or advantages shown. An aspect or an advantage described in conjunction with a particular example is not necessarily limited to that example and can be practiced in any other examples even if not so illustrated or so explicitly described.

[0032] The technology described herein provides a process for graph-based programming description of an application for a multi-core architecture of a system on a chip (SOC) and compiling the application to the multi-core architecture to generate an execution binary for each core and configuration code for programmable components. The compilation step includes converting an input graph description to an internal representation; performing code analysis and optimization; identifying which compute kernels should be grouped together (e.g., clustering); mapping these groups to specific data processing engines (e.g., cores) and data structures to be used by the kernels to local memory. The compilation step also includes routing streams and direct memory access (DMA) data between data processing engines and to and from programmable logic via a stream switch. The compilation step also includes generating wrapper code to coordinate execution of each data processing engine; generating configuration code for the DMA and stream switch; and generating a program executed by a processing system to control the application. These and further aspects are discussed below with reference to the figures.

[0033] Figure 1 is a block diagram of a device 100 including a data processing engine (DPE) array 105 according to an example. In an example, the device 100 is a system on a chip (SoC) type device. In general, an SoC refers to an IC that includes two or more subsystems that are capable of interacting with each other. As an example, an SoC can include a processor that executes program code and one or more other circuits. The other circuits can be implemented as hardwired circuits, programmable circuits, other subsystems, and / or any combination thereof. These circuits can cooperate with each other and / or with the processor. The DPE array 105 includes a plurality of data processing engines (DPEs) 110, which can be arranged in a grid, group, or checkerboard pattern in the device 100. Although Figure 1 Although illustrated with DPEs 110 arranged in a 2D array having rows and columns, examples are not limited to this arrangement. Moreover, the array 105 can be any size and have any number of rows and columns formed of DPEs 110.

[0034] In one embodiment, the DPEs 110 are identical. That is, each DPE 110 (also referred to as a tile or block) can have the same hardware components or circuitry. Moreover, the examples herein are not limited to DPEs 110. Rather, the device 100 can include any kind of array of processing elements or data processing engines. Moreover, the DPEs 110 can be cryptographic engines or other specialized hardware for performing one or more specialized tasks. Thus, the DPEs 110 can generally be referred to as data processing engines.

[0035] In Figure 1 the array 105 includes all the same type of DPEs 110 (e.g., a homogeneous array). However, in another embodiment, the array 105 can include different types of engines. For example, the array 105 can include DPEs 110, cryptographic engines, forward error correction (FEC) engines, etc. Regardless of whether the array 105 is homogeneous or heterogeneous, the DPEs 110 can include connections to memory modules in neighboring DPEs 110 that allow the DPEs 110 to share the memory modules, as described in more detail below.

[0036] In one embodiment, the DPEs 110 are formed from non-programmable logic - i.e., are hardwired. One advantage of doing so is that the DPEs 110 can occupy less space in the device 100 relative to using programmable logic to form the hardware elements in the DPEs 110. That is, using hardwired or non-programmable logic circuitry to form hardware elements (such as program memory, instruction fetch / decode units, fixed-point vector units, floating-point vector units, arithmetic logic units (ALUs), multiply-accumulators (MACs), etc.) in the DPEs 110 can significantly reduce the footprint of the array 105 in the device 100. While the DPEs 110 can be hardwired, this does not mean that the DPEs 110 are non-programmable. That is, the DPEs 110 can be configured to perform different functions or tasks upon power-up or reboot of the device 100.

[0037] The DPE array 105 also includes a SoC interface block 115 that serves as a communication interface between the DPEs 110 and other hardware components in the device 100. In this example, the device 100 includes a network-on-chip (NoC) 120 that is communicatively coupled to the SoC interface block 115. Although not shown, the NoC 120 can extend throughout the device 100 to allow various components in the device 100 to communicate with each other. For example, in a physical implementation, the DPE array 105 can be disposed in the upper right portion of an integrated circuit that forms the device 100. However, through the use of the NoC 120, the array 105 can still communicate with various subsystems, such as programmable logic (PL) 122, a processor subsystem (PS) 130, or input / output (I / O) 135, which can be disposed in different locations throughout the device 100.

[0038] In addition to providing an interface between the DPEs 110 and the NoC 120, the SoC interface block 115 can also provide a direct connection to a communication fabric in the PL 122. In one embodiment, the SoC interface block 115 includes a separate hardware component for communicatively coupling the DPEs 110 to the NoC 120 and the PL 122 disposed proximate to the array 105 in the device 100.

[0039] Although Figure 1 Although one block of the PL 122 is shown, the device 100 can include multiple PL 122 blocks (also referred to as configuration logic blocks) that can be disposed at different locations in the device 100. For example, the device 100 can include hardware elements that form a field programmable gate array (FPGA). However, in other embodiments, the device 100 can not include any PL 122 - e.g., the device 100 is an ASIC.

[0040] Figure 2 A block diagram of a DPE 110 is depicted in accordance with an example. The DPE 110 can be used to implement a DPE in a DPE array, as discussed above and shown in Figure 1 The DPE 110 includes a core 202, a memory 204, a DPE interconnect 209, and support circuits 214. The DPE interconnect 209 includes a stream interconnect 210 and a memory map (MM) interconnect 212. In an example, the support circuits 214 include a debug / trace / profile circuit 216, a hardware (HW) synchronization circuit (“HW lock 218”), and a direct memory access (DMA) circuit (“DMA 220”). The memory 204 includes a program memory (“PM 206”) and a data memory (“DM 208”).

[0041] The core 202 includes one or more compute units to process data according to instructions stored in the PM 206. In an example, the core 202 includes a very long instruction word (VLIW) processor; a single instruction, multiple data (SIMD) or vector processor; or a VLIW SIMD / vector processor. In one example, the PM 206 is private to the core 202 (e.g., the PM 206 stores instructions for use only by the core 202 in the DPE 200). In an example, the PM 206 includes a single port random access memory (RAM). The PM 206 can be coupled to the MM interconnect 212 for configuration and loading of instructions. In an example, the PM 206 supports parity, error correction code (ECC) protection and reporting, or both parity and ECC. For example, the PM 206 can support 9-bit ECC and be capable of correcting a 1-bit error or a 2-bit error in a program instruction (e.g., 128 bits).

[0042] The core 202 can be directly coupled to the stream interconnect 210 to receive input streams and / or provide output streams. In addition, the core 202 can read and write data to the DM 208 in the DPE 200. As discussed further below, the core 202 in the DPE 200 can also access DMs in one or more adjacent tile circuits (e.g., north, south, east, west adjacent tile circuits). In an example, as discussed further below, the core 202 can also include a direct connection to data processing engines in one or more adjacent tiles for forwarding accumulator outputs (e.g., input and output cascading connections). In an example, the core 202 views the DM 208 in the DPE 200 and other DMs in adjacent tiles as one continuous block of memory. The core 202 can also include an interface to the HW lock 218 and an interface to the debug / tracing / profile circuit 216. The debug / tracing / profile circuit 216 can include tracing, debugging, and / or profiling circuitry.

[0043] The MM interconnect 212 can be an AXI memory mapped interconnect or the like configured to transfer data using address transactions between components. In an example, the MM interconnect 212 is used for configuration, control, and debug functions of the DPE 200. The MM interconnect 212 includes one or more switches that route transactions based on addresses. The circuitry can use the MM interconnect 212 to access the memory 204, the core 202, the DMA 220, and configuration registers in the DPE 200.

[0044] The stream interconnect 210 can be an advanced extensible interconnect (AXI) stream interconnect or the like configured for transferring stream data between components. The stream interconnect 210 is used to transfer data between the DPE 200 and external circuits. The stream interconnect 210 can support circuit switching and packet switching mechanisms for both data and control.

[0045] In one example, the DM 208 can include one or more memory banks (e.g., random access memory (RAM) banks) as described further below. The DMA 220 is coupled between the stream interconnect 210 and the DM 208. The DMA 220 is configured to move data from the stream interconnect 210 to the DM 208 and from the DM 208 to the stream interconnect 210. In this way, external circuits (e.g., circuits configured in programmable logic or circuits in an embedded processing system of an IC) can use the DMA to read and write data from and to the DM 208 through the stream interconnect 210. The DMA 220 can be controlled through the MM interconnect 212 and / or the stream interconnect 210. In an example, the DM 208 supports parity, error correction code (ECC) protection and reporting, or both parity and ECC. For example, the DM 208 can support 9-bit ECC (e.g., 128-bit data).

[0046] The HW lock 218 can be used to lock a particular memory bank of the DM 208 for access by the core 202, another data processing engine in another unit tile, or the DMA 220. The HW lock 218 provides synchronization between adjacent data processing engines in adjacent unit tiles, between the core 202 and the DMA 220, and between the core 202 and external circuits (e.g., external processors). The HW lock 218 can also be used to lock a particular buffer in the DM 208, which can be stored in one or more memory banks or a portion of a single memory bank. The debug / tracing / profile circuit 216 is configured to provide debug, tracing, and profiling functions. The debug / tracing / profile circuit 216 can track events generated by circuits in the DPE 200. The debug / tracing / profile circuit 216 can provide profiling functions, such as configurable performance counters.

[0047] Figure 3is a block diagram depicting DPE 200 in more detail according to an example. In this example, DPE 200 includes core 202, memory module 351, and DPE interconnect 209. Core 202 includes compute circuitry 203 and PM 206. Memory module 351 includes memory interfaces 302N, 302S, 302E, and 302W (collectively memory interfaces or individually “mem IF”), RAM bank 318, HW lock 218, registers (“regs 304”), DMA interface 204A, and DMA interface 220B. Compute circuitry 203 includes registers (“regs 306”). DPE interconnect 209 includes MM interconnect 212 and stream interconnect 210 (as shown Figure 2 Both MM interconnect 212 and stream interconnect 210 can access RAM bank 318. RAM bank 318 includes arbitration logic 319 per bank. Arbitration logic 319 is configured to control which interface (N, S, E, W, DMA, external PS, etc.) can access which bank. Further details of DPE interconnect 209 are discussed below with respect to the example of Figure 4

[0048] DPE interconnect 209 includes stream connections 314W to west cell blocks, stream connections 314E to east cell blocks, stream connections 314N to north cell blocks, and stream connections 314S to south cell blocks. Each stream connection 314 includes one or more independent stream interfaces (e.g., buses), each interface having a particular bit width. DPE interconnect 209 also includes memory mapped connections 312S from south cell blocks and memory mapped connections 312N to north cell blocks. Although only north and south MM connections are shown, it should be understood that DPE interconnect 209 can include other configurations for MM interconnect (e.g., east to west, west to east, north to south, etc.). It should be understood that DPE interconnect 209 can include other arrangements of stream and memory mapped connections than those shown in the example of Figure 3 In general, DPE interconnect 209 includes at least one stream connection 314 and at least one memory mapped connection 312.

[0049] Compute circuitry 203 includes connections 308W to memory circuitry in west cell blocks, connections 308S to memory circuitry in south cell blocks, connections 308N to memory circuitry in north cell blocks, and connections 308E to memory module 351. Compute circuitry 203 includes stream interfaces to DPE interconnect 209. Compute circuitry 203 also includes connections 310A from cores in west cell blocks and connections 310B to cores in east cell blocks (e.g., cascading connections). It should be understood that DPE can include other arrangements of connections than those shown in the example of Figure 3 ​the memory and other arrangements of the cascaded connections shown in the example. In general, the compute circuit 203 includes at least one memory connection and can include at least one cascaded connection.

[0050] The mem IF 302W is coupled to the memory connection 308E of the compute circuit 203. The mem IF 302N is coupled to the memory connection of the data processing engine in the north tile. The mem IF 302E is coupled to the memory connection of the data processing engine in the east tile. The mem IF 302S is coupled to the memory connection of the data processing engine in the south tile. The mem IFs 302W, 302N, 302E, and 302S are coupled to the RAM bank 318. The DMA 220A includes an output coupled to the DPE interconnect 209 for processing memory to interconnect flows. The DMA 220B includes an input coupled to the DPE interconnect 209 for processing interconnect to memory flows. The regs 304 and the regs 306 are coupled to the DPE interconnect 209 to receive configuration data therefrom (e.g., by using a memory mapped interconnect).

[0051] Figure 4 is a block diagram depicting the DPE interconnect 209 according to an example. The DPE interconnect 209 includes a flow switch 402 and a MM switch 404. The flow switch 402 is coupled to a west flow interface 406W, a north flow interface 406N, an east flow interface 406E, and a south flow interface 406S. The west flow interface 406W receives flows and provides the flows to the DPE interconnect of the west tile. The north flow interface 406N receives flows and provides the flows to the DPE interconnect of the north tile. The west flow interface 406W receives flows and provides the flows to the DPE interconnect of the west tile. The south flow interface 406S receives flows and provides the flows to the DPE interconnect of the south tile. The MM switch 404 is coupled to a north MM interface 408N and a south MM interface 408S. The north MM interface 408N is coupled to the DPE interconnect in the north tile. The south MM interface 408S is coupled to the DPE interconnect in the south tile.

[0052] The flow switch 402 includes a first-in-first-out (FIFO) circuit (FIFO 412) and registers (regs 410). The FIFO 412 is configured to buffer flows through the flow switch 402. The regs 410 store configuration data for the flow switch 402 that controls the routing of flows through the flow switch. The regs 410 can receive configuration data from the MM switch 404. The flow switch 402 can include additional interfaces to the compute circuit 203 and additional interfaces to the DMA circuit 220. The flow switch 402 can send and receive control flows and receive trace flows (e.g., from the debug / trace / profile circuit 216).

[0053] Figure 5is a block diagram depicting an example of a circuit design system 500 according to an example. The circuit design system 500 includes a computer 501 coupled to input / output (IO) devices 512, a display 514, and a SOC 100. The computer 501 includes a hardware platform 518, which can include conventional components of a computing device, such as a central processing unit (CPU) 502, system memory 508, various support circuits 504, storage 520, and an IO interface 506. The CPU 502 can include one or more microprocessors. The CPU 502 is configured to execute instructions for one or more operations described herein. The instructions can be stored in the system memory 508, the storage 520, or any other memory in the hardware platform 518 (e.g., cache memory). The system memory 508 includes a device that stores information and can include, for example, a random access memory (RAM), a read only memory (ROM), or a combination thereof. The storage 520 includes a local storage device, such as a hard disk, a flash memory module, a solid state disk, an optical disk, etc. The storage 520 can also include an interface configured for communication with one or more network data storage systems. The support circuits 504 can include conventional cache, power supply, clock circuits, data registers, IO interfaces, etc. The IO interface 506 includes conventional interfaces to the computer 501 as known in the art. The IO interface 506 can be coupled to the IO devices 512, which can include a conventional keyboard, mouse, etc. The IO interface 506 can also be coupled to the display 514, which can present a GUI 516 to a user.

[0054] The computer 501 also includes a software platform that includes an operating system (OS) 522 and design tools 510. The OS 522 and design tools 510 include instructions executed by the CPU 502. The OS 522 can include any known operating system, such as Microsoft Mac and the like. The design tools 510 are applications executing within the OS 522 that provide an interface to the hardware platform 518. The operation of the design tools 510 is discussed below. An example design tool that can be adapted to include the examples of technology described herein is the Xilinx®Vivado®Design Suite, available from Xilinx, Inc. of San Jose, California, however other circuit design tools can similarly be adapted.

[0055] Compiler flow for heterogeneous multicore architecture

[0056] Figure 6 ​is a block diagram depicting implementation of an application for a target platform according to an example. Design tool 510 includes a software compiler ("SW compiler 602"), a DPE array compiler 604, and a hardware design tool ("HW design tool 606"). Design tool 510 receives an application 608, user constraints 610, and a hardware base platform ("HW base platform 612"). The user defines an application 608 to be implemented for SoC 100. Application 608 includes portions that map to PL 122, PS 130, and DPE array 105. SW compiler 602 is configured to compile portions of application 608 that map to PS 130, which can include source code defined using any programming language (e.g., C, C++, etc.). Hardware design tool 606 is configured to implement portions of application 608 that map to PL 122, which can include circuit descriptions defined using any hardware description language (HDL), register transfer language (RTL), high-level synthesis (HLS) models, concurrent programming languages (e.g., SystemC), etc. DPE array compiler 604 is configured to compile portions of application 608 that target DPE array 105, which will be further defined below.

[0057] Figure 7 is a block diagram of application 608 according to an example. A user interacts with design tool 510 to define application 608 for SOC 100. In this example, application 608 includes input circuit 702, kernel 704, kernel 706, output circuit 708, and control software 710. Input circuit 702 is coupled to and provides data to kernel 704. Kernel 704 is coupled to and provides data to kernel 706. Kernel 706 is coupled to and provides data to output circuit 708. Control software 710 controls and provides data to kernel 704 and kernel 706. In general, application 608 includes one or more circuits, one or more kernels, and control software that are connected to each other in a particular way according to the design.

[0058] In this example, input circuit 702 includes digital logic (and optional analog logic) configured to communicate with external systems / circuits and provide data to kernel 704 for processing. Input circuit 702 maps to PL 122. Likewise, output circuit 708 includes digital logic (and optional analog logic) configured to communicate with external systems / circuits and receive data from kernel 706 that has been processed. Output circuit 708 maps to PL 122. In an example, kernels 704 and 706 include a programmed description of a data processor. Kernels 704 and 706 map to DPE array 105. Control software 710 is a programmed description of a controller for kernels 704 and 706. In an example, control software 710 maps to PS 130.

[0059] Return Figure 6 The implementation data 614 includes flow switch configuration code 616, DMA engine configuration code 618, PS binary file 624, DPE binary file 620, and PL bitstream 622. The SW compiler 602 generates the PS binary file 624 from source code (e.g., control software 710) of the application 608 targeted for the PS 130. The PS binary file 624 is configured for a particular microprocessor architecture (e.g., x86, etc.). The HW design tool 606 generates the PL bitstream 622 from portions of the application 608 targeted for the PL 122 (e.g., input circuit 702 and output circuit 708). The PL bitstream 622 is targeted for a particular SOC device. The DPE array compiler 604 generates the flow switch configuration code 616, DMA engine configuration code 618, and DPE binary file 620 based on portions of the application 608 targeted for the DPE array 105 (e.g., kernels 704 and 706). The flow switch configuration code 616 includes data for programming the flow switches 402 in the DPE interconnect 209. The DMA engine configuration code 618 includes data for programming the DMA circuit 220 in the memory module 351 of the DPE 110. The DPE binary file 620 includes code for execution by the compute circuit 203 in the core 202 of the DPE 110.

[0060] The implementation output 614 is configured for implementation on a target platform 626. The target platform 626 includes a simulation platform (“simulation 628”), a simulation platform (“simulation 630”), and a hardware platform (“hardware 632”). The hardware 632 includes the SOC 100. The simulation and simulation platforms 628 and 630 simulate / emulate the hardware 632.

[0061] Figure 8 is a block diagram depicting the DPE array compiler 604 according to an example. The DPE array compiler 604 includes a front end 806, a mapper 808, a back end 810, and a single core compiler 812. While the DPE array compiler 604 is depicted as having discrete components, it should be understood that the functionality of these components can be implemented using more or less different configured components than those shown in the example. Portions of the application 608 targeted for the DPE array 105 include a user-defined graph description 802 and kernel source code 804. The user-defined graph description 802 describes components and their connectivity (e.g., input circuit 702, kernels 704 and 706, output circuit 708, and control software 710). The kernel source code 804 provides a programmatic description of the functionality to be implemented in the DPE 110 of the DPE array 105. Figure 8

[0062] ​The user-defined graph description 802 can be specified by using various programming languages (e.g., C, C++, etc.) or data structure languages (e.g., XML, JSON, etc.). One example of the user-defined graph description 802 specified in C++ is shown below:

[0063]

[0064] In the above example, the radio class is derived from a library of classes with graph building primitives (cardano). Using these primitives, the user-defined graph description 802 defines compute nodes a, b, c, d, e, and f. Compute nodes a and f are circuits mapped to the PL 122. Compute nodes b, c, d, and e are kernels mapped to the DPE array 105. Circuit a is connected to kernel b using a DMA stream connection. Kernel b is connected to kernel c; kernel c is connected to kernel d; kernel d is connected to kernel e; and kernel e is connected to kernel b, with each such connection through a memory block in the DPE 105. Kernel d is connected to circuit F through a DMA stream connection.

[0065] The user-defined graph description 802 can also include a top-level description of the platform. For example:

[0066] radio mygraph;

[0067] simulation::platform<1,1> platform ("in.txt", "out.txt");

[0068] connect<> net0 (platform.src[0], mygraph.in);

[0069] connect<> net1 (platform.sink[0], mygraph.out);

[0070] In the above example, the user instantiates the radio class (mygraph) and sets the simulation target. The user can also specify a control program that is executed on the PS 130, for example:

[0071] int main (void) {

[0072] mygraph.init();

[0073] mygraph.run();

[0074] mygraph.end();

[0075] return 0;}

[0076] }

[0077] In the above example, the user initializes mygraph, executes mygraph, and ends mygraph for simulation in the simulation platform.

[0078] The kernel source code 804 provides source code descriptions for each compute node (e.g., compute nodes b, c, d, and e in the above example) targeted for the DPEs 110. The kernel source code 804 can be defined using any programming language (e.g., C, C++, etc.). An example C++ source code for defining compute node c (equalizer) is shown below:

[0079]

[0080]

[0081] In this example, compute node c (equalizer) is implemented using a C / C++ function with input parameters defining the compute node inputs. The code includes compilation directives that help with scheduling performance. The code includes intrinsic functions for performing vectorized computations and an application programming interface (API) for accessing data.

[0082] The front end 806 is configured to process the user-defined graph description 802 and generate a directed graph as an internal representation. In the directed graph, nodes represent compute nodes and edges represent connections between compute nodes. The mapper 808 is configured to implement the directed graph for the DPE array 105 in the target device based on the device description 814. The mapper 808 partitions the compute nodes into groups and maps the partitioned compute nodes to the DPEs 110. The back end 810 is configured to route connections between circuits in the DPEs 110 and the PL 122, then invoke a single-core compiler 812 to generate DPE binaries, and also generate stream switcher and DMA configuration code based on the output of the mapper 808.

[0083] Figures 9A-9D is a block diagram depicting an example directed graph representation of a portion of the application 608 for the DPE array 105 according to an example. Figure 10 is a block diagram depicting the layout and routing of the directed graph in the DPE array 105. Figures 9A-9D The directed graph representation in depicts the example described above for the user-defined graph description 802 with compute nodes a, b, c, d, e, and f, where compute nodes a and f are mapped to the PL 122 and compute nodes b, c, d, and e are mapped to the DPE array 105. As Figure 9AAs shown, the directed graph includes nodes A 902, B 904, C 906, D 908, E 910, and F 912. Node A is connected to node B; node B is connected to node C; node C is connected to node D; node D is connected to node F and node E; and node E is connected to node B. Figures 9B-9D The mapper 808 is depicted as processing the directed graph through various steps, as further described below.

[0084] Figure 11 A flowchart of a method 1100 to generate code and configuration for a DPE array 105 depicted as a SOC 100 according to an example. The method 1100 is performed by the design tool 510 executing on the computer system 501. As described above, the design tool 510 is configured to process the application 608 to generate code and configuration data for the SOC 100. The method 1100 is performed by the DPE array compiler 604.

[0085] The method 1100 begins at step 1102, where the DPE array compiler 604 parses the application 608 and generates a directed graph based on a graph description of the user-defined design. In the example, the DPE array compiler 604 identifies the compute nodes 902-912 and the connections between them. The DPE array compiler 604 then forms a graph with the nodes being the kernels and the edges being the connections, as shown. Figure 9A

[0086] At step 1104, the DPE array compiler 604 processes the directed graph to cluster the kernels into groups that can be executed on cores in the data processing engines. In this example, the kernels are selected from the compute nodes B 904, C 906, D 908, and E 910. That is, each DPE 110 can execute one or more kernels, and the DPE array compiler 604 determines which kernels can be combined to be executed as a group. As shown, Figure 9B the DPE array compiler 604 can combine node B 904 and node C 906 into a group 905, and combine node D 908 and node E 910 into a group 907.

[0087] At step 1106, the DPE array compiler 604 processes the code defining each kernel for optimization to improve performance and reduce memory footprint of the kernel cluster. At step 1108, the DPE array compiler 604 maps the kernels (or kernel groups, if any) to DPEs 110 in the DPE array 105. As shown, Figure 10 ​As shown, the kernels represented by nodes B 904 and C 906 are mapped to core 202-1 of one DPE, and the kernels represented by nodes D 908 and E 910 are mapped to core 202-3 of another DPE.

[0088] At step 1110, the DPE array compiler 604 maps the data structures defined in the kernel code to local memory banks in the respective DPEs 110 or to DMA for non-local communication. As described above, DPEs that are close to each other can share memory banks. As further described herein, communication through shared memory can be single-buffered or double-buffered. However, in some cases, one DPE can be far enough from another DPE that the kernel executing on it requires DMA communication. As described above, the DPE array compiler 604 can determine the communication needs of the kernel code and map the data structures accordingly. Figure 9C As shown, the communication between nodes A 902 and B 904 is through double-buffer 914; the communication between nodes B 904 and C 906 is through single-buffer 916; the communication between nodes C 906 and D 908 is through double-buffer 918; the communication between nodes D 908 and E 910 is through single-buffer 920; the communication between nodes E 910 and B 904 is through double-buffer 922; and the communication between nodes D 908 and F 912 is through double-buffer 924. As described above, the DPE array compiler 604 can determine the communication needs of the kernel code and map the data structures accordingly. Figure 10 As shown, buffer 914 is mapped to a RAM bank 318 in memory module 351-1. Buffer 918 is mapped to a RAM bank 318 in memory module 351-2. Buffer 924 is mapped to a RAM bank 318 in memory module 351-4. Memory buffers 916, 920, and 922 are mapped to a RAM bank 318 in memory module 351-3.

[0089] At step 1112, the DPE array compiler 604 allocates communication channels between the DPE array 105 and the PL 122. For example, to input / output circuits (e.g., compute nodes a and f) configured in the PL 122. For example, as described above, the DPE array compiler 604 can determine the communication needs of the kernel code and allocate the communication channels accordingly. Figure 10 As shown, node A 902 is configured for DMA communication with DMA 220 in memory module 351-1. Node F 912 is configured for DMA communication with DMA 220 in memory module 351-4.

[0090] At step 1114, the DPE array compiler 604 allocates locks for core-to-core and core-to-DMA (if needed) synchronization between the kernels. As described above, the DPE array compiler 604 can determine the communication needs of the kernel code and allocate the locks accordingly. Figure 9DAs shown, the DPE array compiler 604 allocates lock 924 between nodes A 902 and B 904; lock 928 between nodes C 906 and D 908; lock 926 between nodes E 910 and B 904; and lock 930 between nodes D 908 and F 912. The locks 924, 926, 928, and 930 provide synchronization of the double buffers between the nodes.

[0091] At step 1116, the DPE array compiler 604 routes the streaming data communication between the cores and to / from the PL 122 through a stream switch (e.g., circuit switch and / or packet switch). At step 1118, the DPE array compiler 604 generates wrapper code for each DPE 110 and compiles the wrapper code to generate a DPE binary. At step 1120, the DPE array compiler 604 generates control code to configure the DMA stream switch. At step 1122, the DPE array compiler 604 generates an application program interface (API) for control software executing on the processing system to access and control the kernels executing in the data processing engine array.

[0092] Heuristic partitioner

[0093] In the above described method 1100, the DPE array compiler 604 aggregates the kernels into groups that can be executed on the DPEs 110 (step 1104). In computation, the partitioning problem is non-polynomial (NP) hard, which is simplified from the classic bin packing problem with conflicts to the partitioning problem. In the examples herein, a greedy heuristic algorithm is used in the partitioning algorithm for ease of processing. In the graph-based programming model, each kernel has an associated runtime ratio, which represents an upper bound of its execution time compared to the cycle budget. The sum of the runtime ratios of the aggregated kernels together must not exceed 1. In addition, the user can also specify colocation constraints between the kernels or absolute position constraints on the kernels, which affect the assignment of the kernels to the partitions and the mapping of the kernels / partitions to the data processing engines. The unique aspect of the partitioning scheme described here compared to previous efforts is that it handles various constraints including absolute, relative, and derived constraints. The technique also dynamically infers some constraints when creating the partitions so that a feasible partition to core mapping can be found. In addition, the techniques allow the user to choose between different partition heuristics, each with a multi-criteria objective function.

[0094] Figure 12is a flowchart depicting a method 1200 of partitioning kernels in an application among DPEs according to an example. The method 1200 can be performed as part of the step 1104 described above. The method 1200 begins at step 1202, where the DPE array compiler 604 receives a directed graph (e.g., formed in the step 1102 described above). In the directed graph, nodes are kernels and edges represent data flow between kernels. The user can define absolute constraints, e.g., a particular kernel must be placed in a particular data processing engine. The user can also define relative constraints, e.g., a particular set of kernels must be placed in the same data processing engine. At step 1204, the DPE array compiler 604 groups some kernels into "macro nodes" based on the user-defined constraints ("user constraints"). The graph now includes nodes and macro nodes, where a node includes a single kernel and a macro node includes two or more kernels. Hereafter, the description does not distinguish between nodes and macro nodes, and instead uses nodes and kernels interchangeably.

[0095] At step 1206, the DPE array compiler 604 orders the nodes in the graph based on their runtime ratios and criticalities. This is done in two steps. First, the DPE array compiler 604 orders the nodes based on their static levels to create a list LI. The static level of a node n is computed as the maximum cumulative runtime ratio from n to any sink in the graph. The DPE array compiler 604 then scans LI to find an unexplored node m. It performs a reverse post-order (RPO) traversal rooted at m, while preferentially exploring in a depth-first manner. This traversal is referred to as a depth-first RPO in this description. All nodes explored in the RPO traversal are appended to a new list L2. A new unexplored node is then selected from LI and step 1206 is repeated until all nodes in LI have been explored. The RPO traversal exploits locality, increasing the probability of placing producer-consumer kernels in the same partition and increasing the probability that the critical path does not worsen.

[0096] At step 1208, the DPE array compiler 604 processes the ordered nodes one at a time and places them into final partitions. Each node can be placed in an existing partition or a new partition. The assignment is performed by determining constraints between the selected kernel and existing kernels in each partition. For example, the DPE array compiler 604 maintains that the runtime ratio of each partition is less than or equal to 1 (e.g., so that a given data processing engine does not become over-utilized) (step 1210). Thus, if the sum of the runtime ratios of the kernels in b_a and the runtime ratio of kernel k_a exceeds 1, then kernel k_a cannot be assigned to partition b_a.

[0097] In another example, a partition with a kernel with an absolute constraint inherits the absolute constraint (step 1212). Thus, if a kernel k_a has an absolute constraint that pins the kernel to a particular data processing engine, and the partitioning algorithm maps k_a to a partition b_a, the absolute constraint of k_a extends to the partition b_a. After that, the DPE array compiler 604 does not add a different kernel k_b to the partition b_a, where k_b has an absolute constraint that maps it to a different data processing engine than k_a.

[0098] In another example, the DPE array compiler 604 ensures that the partitions satisfy the physical constraints of the data processing engine array (step 1214). For example, for a given architecture, a partition cannot have more input / output stream ports than a defined number. Two kernels in the same partition cannot have a certain type of connection between them, such as a stream, cascade, or asynchronous connection.

[0099] In another example, the DPE array compiler 604 satisfies any dynamic location constraints caused by the partitioning process (step 1216). As the partitioning proceeds, some location constraints can dynamically arise between two partitions that have cross-dual-buffer data edges. Such partitions can need to be mapped to adjacent data processing engines in the array.

[0100] At step 1208, the partitioning algorithm keeps track of all constraints and respects them as it assigns kernels to partitions. If a kernel cannot be added to any pre-existing partition due to a constraint conflict, the DPE array compiler 604 creates a new partition. However, if there are multiple partitions to which the kernel can be added, there are two possibilities: (1) the DPE array compiler 604 can add the kernel to one of the pre-existing partitions; or (2) the DPE array compiler 604 can add the kernel to a new partition. The first option minimizes the number of open partitions, which has a direct impact on power consumption. The second option can help reduce the overall execution latency. Since users can have different goals for different applications (e.g., reducing power usage versus reducing execution time), the DPE array compiler 604 can provide the user with two implementations: (1) one that minimizes the number of partitions, i.e., adds the kernel to one of the pre-existing partitions without conflict as much as possible; and (2) one that adds the kernel to a non-conflicting partition only if it does not worsen the critical path length, otherwise a new partition is created. In both cases, if the algorithm decides that the kernel can be added to multiple partitions, the partition that minimizes the number of dual-buffer edges across partitions is preferred.

[0101] At step 1218, the design tool determines the execution order of the kernels in each partition based on criticality. After partitioning, the kernels in each partition are to be executed in order. To avoid an increase in execution latency, the kernels in a given partition are executed according to their criticality.

[0102] Some of the constraints of the partitioning problem can also be formulated as an integer linear programming (ILP) problem, which can be solved by using an ILP solver. However, not all constraints / objective functions can be effectively represented in ILP, and the solution can likely be exponential in time. The heuristic-based partitioner described here is greedy and thus linear in time. The partitioning is done together with the mapping. Alternatively, the partitioning and mapping can be done simultaneously.

[0103] Figure 13 A flowchart depicting a method 1300 of assigning kernels to partitions according to an example. The method 1300 can be performed as part of step 1208 in the method 1200 described above. The method 1300 begins at step 1302, where the DPE array compiler 604 obtains the set of nodes P in a depth-first reverse post-ordering (e.g., from step 1206). At step 1304, the DPE array compiler 604 determines whether the set P is empty (e.g., whether all kernels have been assigned to a partition). If so, the method 1300 proceeds to step 1306 and performs post-partition optimization for communication minimization. Otherwise, the method 1300 proceeds to step 1308. At step 1308, the DPE array compiler 604 removes a node n from the set P. At step 1310, the DPE array compiler 604 assigns the node n to an existing or new partition.

[0104] In particular, the DPE array compiler 604 determines a set R of existing partitions in which n can be added. At step 1312, the DPE array compiler 604 orders the partitions R in descending order of buffers shared with n. As described above, some kernels can share memory buffers with other kernels. At step 1314, the DPE array compiler 604 picks a first partition r in the ordered R such that a merge of n and r does not: (1) worsen the critical path or (2) result in an infeasible topology placement.

[0105] At step 1316, the DPE array compiler 604 determines whether r is empty (i.e., no existing partition exists for n). If not, the method 1300 proceeds to step 1318, where the DPE array compiler 604 merges the node n with the partition r and updates the location constraints of the partition r based on the node n (e.g., any absolute and / or relative constraints defined for n). If r is empty, the method 1300 instead proceeds to step 1320, where the DPE array compiler 604 creates a new partition, adds n to the new partition, and updates the location constraints of the new partition based on n. The method 1300 proceeds from step 1318 or step 1320 to step 1304 and repeats until all nodes have been processed.

[0106] Mapping

[0107] As described above in step 1108, the DPE array compiler 604 maps the kernels and kernel groups onto the DPEs 110. The input to the mapping algorithm is the static directed graph (e.g., G) and the device description. The mapping algorithm provides as output the placement of each kernel in the DPE array 105, placement of buffers between kernels, and the physical locations of the mapped IO nodes. Figure 9B

[0108] Figure 14 is a flowchart depicting a method 1400 of mapping kernels and kernel groups onto DPEs 110 according to an example. The method 1400 can be performed as part of step 1108 in the method 1100 described above. The method 1400 begins in step 1402, where the DPE array compiler 604 performs a first pass of mapping of the kernels, buffers, and IO nodes without introducing DMA communication for block-based data movement between kernels (e.g., data movement within the DPE array 105). In step 1404, the DPE array compiler 604 determines whether any DMA is needed. If not, the method 1400 proceeds to step 1410 and ends. Otherwise, the method 1400 proceeds to step 1406.

[0109] In step 1406, the DPE array compiler 604 inserts additional buffers in the directed graph to provide DMA communication between kernels within the DPE array 105. In step 1408, the DPE array compiler 604 performs a second pass of mapping with DMA communication links. The second pass of mapping can be performed faster than the first pass because the solution of the first pass mapping can be used as a starting point. Thus, the DPE array compiler 604 only needs to place the newly inserted buffers for DMA communication. The method 1400 then ends in step 1410.

[0110] Both passes of mapping (1402 and 1408) solve an ILP-based optimization problem with a heuristic cost objective. The objective of the optimization problem is to (1) minimize the number of data movements; 2) minimize memory conflicts; and 3) minimize latency.

[0111] Data movement optimization: Each core 202 in the DPE 110 can access data from the memory 206 as well as from other cores 202. The data movement optimization problem is to minimize the number of data movements between cores 202 and between cores 202 and the memory 206. Figure 3 ​All the memory modules 351 on all the base sides (north, south, east, and west) are shown. When mapping a kernel to a core 202, the DPE array compiler 604 ensures that all the buffers accessed by the kernel are placed in one of the memory modules 351 that can be accessed directly from the particular core 202. Two kernels mapped to different cores 202 can communicate through memory in two different ways, non-DMA and DMA. For non-DMA, a kernel writes data to memory, which is then read by another kernel. If the two kernels are mapped to cores 202 that can access the same memory module 351, no DMA communication is needed between the cores 202. For DMA, the two kernels are mapped to cores 202 that cannot access the same memory module 351. In this case, the buffers between the kernels are copied into two different memory modules 351, one of which can be accessed by the first core 202 and the other of which can be accessed by the second core 202. With DMA, data from the first memory module 351 is transferred to the second memory module 351 through the DPE interconnect 209. Compared to non-DMA, DMA requires twice the memory footprint, twice the number of locks, and two DMA channels in addition to the routing resources in the DPE interconnect 209.

[0112] The DPE array compiler 604 models the DPE array 105 as a chessboard architecture using a cost model, where the adjacent memory modules of each core have zero access cost and the rest of the memory modules have higher cost. The optimization problem is then to map the kernels to the cores and the buffers to the memory modules with minimum cost. This problem can be naturally represented as a quadratic optimization problem. The DPE array compiler 604 uses to reduce the quadratic problem to an ILP problem.

[0113] Memory conflict optimization: Each memory module 351 includes a set of RAMs 318 (e.g., eight sets of RAMs). Memory access conflicts arise when the same RAM set is accessed multiple times in the same cycle. Memory access conflicts can be classified into different types: (1) intra-core memory access conflicts; (2) inter-core memory access conflicts; (3) core-DMA memory access conflicts; and (4) DMA-DMA memory access conflicts. For intra-core memory access conflicts, a core executes very large instruction word (VLIW) instructions. Each VLIW instruction can have multiple memory access instructions (e.g., up to two loads and one store). If two or more memory operations in a single instruction access the same memory set, a memory stall, and thus a core stall, results. Two or more different cores accessing the same memory set in the same cycle results in inter-core memory access conflicts. A core and a DMA channel accessing the same memory set in the same cycle results in core-DMA memory access conflicts. Multiple DMA channels accessing the same memory set in the same cycle results in DMA-DMA memory access conflicts.

[0114] Because it can not be possible to avoid conflicts entirely for all applications, the DPE array compiler 604 allows the user to choose from a set of conflict avoidance and conflict minimization settings. The DPE array compiler 604 distinguishes between local buffers (e.g., buffers accessed by a single core) and shared buffers (e.g., buffers accessed by multiple cores) and performs different optimizations. The DPE array compiler 604 takes a two-pronged approach to resolving memory conflicts: 1) conflict avoidance; and 2) conflict minimization. To avoid conflicts, to avoid access conflicts between producers and consumers of a data block, the DPE array compiler 604 ensures that double buffers (e.g., ping and pong buffers) are mapped to different RAM sets. Similarly, the DPE array compiler 604 ensures that there are no conflicts between accesses to local buffers from different cores by placing them on different memory sets. By placing all buffers accessed by a single core on different RAM sets 318, intra-core memory conflicts are avoided.

[0115] For conflict minimization, the problem is reduced to the problem of minimizing the number of independent actors (cores, DMA channels) that access a given memory set. Modeling this as an ILP problem can be expensive for large devices because the number of cores and DMA channels is proportional to c times r, where c is the number of columns and r is the number of rows in the DPE array 105 of the device. The DPE array compiler 604 employs a technique that reduces the number of ILP variables by modeling all DMA channels as two different actors (readers and writers) instead of c x r x 4 different entities.

[0116] Delay minimization: Similar to FPGA placement algorithms, the DPE array compiler 604 minimizes the delay of the flow-based communication by minimizing the distance between sources and sinks.

[0117] Stream FIFO insertion in heterogeneous multicore architecture

[0118] FIFO determination and insertion for avoiding deadlocks and performance has been studied in the past, but mostly in the context of computational theory models (e.g., synchronous dataflow, Kahn process networks) and high-level synthesis. This problem has not been addressed for multiprocessor systems, mostly because few such systems use elastic, handshake-flow intercommunication (e.g., most multiprocessor systems use shared memory for data communication, or are systolic arrays that work in lockstep).

[0119] Figure 15 is a flowchart depicting a method 1500 of FIFO insertion when implementing an application of a heterogeneous multi-core architecture. The method 1500 can be performed during any of the steps 1108, 1110, 1112, 1114, and 1116 of the method 1100 described above. The method 1500 begins at step 1502, where the DPE array compiler 604 determines whether the application will deadlock or fail to meet performance criteria due to a mismatch in the delay of the flow data along the re-convergent computation and communication paths. If a failure occurs (step 1504), the method 1500 proceeds to step 1506. Otherwise, the method 1500 ends at step 1516. At step 1506, the DPE array compiler 604 determines a minimum FIFO size to avoid any deadlocks and / or performance failures identified in the computation and communication paths. In an example, one or more minimum FIFO sizes can be predefined (e.g., specified by a user).

[0120] For the general case, a theoretical analysis of this is difficult and conservative, which can lead to very large FIFOs. Thus, in an example, the DPE array compiler 604 implements a simulation-based approach. The DPE array compiler 604 simulates the system with a selected FIFO size until deadlocks / performance failures are avoided (step 1508). The simulation can be at different levels of abstraction: the computation kernel code can be untimed, but the kernels are run concurrently (“untimed and concurrent execution of kernels”); or the kernels can be modeled in a cycle-accurate manner (“cycle-accurate concurrent execution of kernels”).

[0121] Once the FIFO size is determined at step 1506, a FIFO needs to be inserted along the flow route between the producer and consumer compute kernels (step 1510). In the DPE array 105, there are two options: each flow switch has two finite size FIFOs (e.g., 16 words each); or local data memory can be used as FIFOs by the cell block-DMA engine. The latter option is needed if the FIFO size is very large. For the former option, a complication is that the number of flow switches on the producer-to-consumer route limits the total number of finite size FIFOs that can be used. Thus, it can be necessary to artificially lengthen the route itself to meet a specified or determined total FIFO size. Another complication is that multiple routes can share a flow switch. Thus, a heuristic method of flow switch assignment along a route that specifies or determines the length of the FIFOs takes this sharing into account. Thus, at step 1512, the DPE array compiler 604 can select FIFOs in the DPE interconnect. Additionally or alternatively, at step 1514, the DPE array compiler 604 can implement FIFOs in local memory. The method 1500 then ends at step 1516.

[0122] Figure 16 A block diagram of a processing system 1600 is depicted in accordance with an example. The processing system 1600 can be the result of step 1506 described above. In this example, the processing system 1600 includes a data source 1602 and a plurality of DPEs 1604A-1604D. The data source 1602 provides data to be processed by each DPE 1604. The DPEs 1604 are coupled in series (e.g., a pipeline formed by DPE 1604A, DPE 1604B, DPE 1604C, and DPE 1604D in that order). In step 1506, the DPE array compiler 604 can determine that the path between the data source 1602 and DPE 1604A does not require a FIFO; the path between the data source 1602 and DPE 1604B requires a FIFO of depth 10; the path between the data source 1602 and DPE 1604C requires a FIFO of depth 20; and the path between the data source 1602 and DPE 1604D requires a FIFO of depth 30.

[0123] Figure 17Ais a block diagram depicting an implementation 1700 of the processing system 1600 according to an example. In this example, the implementation 1700 includes nodes 1702, 1704, and 1706, each of which represents a switch in the DPE interconnect 209. The implementation 1700 is a worst-case implementation of the processing system 1600 because it requires the most FIFO resources (e.g., FIFOs with depths of 10, 20, and 30 for a total depth of 60). Thus, at step 1510, the DPE array compiler 604 can perform a more efficient FIFO layout as described in the following algorithm.

[0124] Figure 17B is a block diagram depicting an implementation 1701 of the processing system 1600 according to another example. In this example, the implementation 1701 includes FIFOs with depths of 10, 10, and 20 for a total depth of 40. The implementation 1701 uses fewer resources than the implementation 1700 to implement the FIFOs required by the processing system 1600. Figure 17B

[0125] Figure 18 is a flow diagram depicting a method 1800 of placing FIFOs according to an example. The method 1800 can be performed by the DPE array compiler 604 at step 1510 of the method 1500. The method 1800 begins at step 1802, where the DPE array compiler 604 determines the path order. A path is a collection of one or more nodes between a data source 1602 and a DPE 1604. In an example, the DPE array compiler 604 processes the paths in an arbitrary order (e.g., left to right). Another example is discussed further below. At step 1804, the DPE array compiler 604 determines the node order along each path. In an example, the DPE array compiler 604 determines the node order from the DPE 1604 to the data source 1602. Another example is discussed further below.

[0126] ​At step 1810, the DPE array compiler 604 selects a path to process. At step 1812, the DPE array compiler 604 annotates the edges with FIFO requirements along the order of nodes until a feasible FIFO placement is reached. In some cases, the DPE array compiler 604 “re-times” as many common FIFOs as possible to reach feasibility while still satisfying the FIFO requirements (step 1814). For example, consider the path between data source 1602 and DPE 1604C. When processing this path, the DPE array compiler 604 can allocate a FIFO of depth 10 between nodes 1704 and 1706, and a FIFO of depth 10 between node 1706 and DPE 1604C. This will satisfy the FIFO requirements of both DPEs 1604B and 1604C. However, when processing the path between data source 1602 and DPE 1604D, the DPE array compiler 604 can re-time the FIFO between data source 1602 and node 1704 from a depth of 0 to a depth of 10, and re-time the FIFO between nodes 1704 and 1706 from a depth of 10 to a depth of 0. The result is shown in FIG. 17. The DPE array compiler 604 determines that a FIFO of depth 20 between node 1704 and DPE 1704D to satisfy the FIFO requirement. Figure 17B

[0127] In an example, at step 1802, the DPE array compiler 604 performs a full graph analysis to determine an order of paths to process. Rather than looking at one path at a time to allocate FIFOs, the DPE array compiler 604 can look at all paths that require FIFO insertion. The DPE array compiler 604 can then order the paths in ascending order of path size based on the number of nodes along the path (step 1804). If the paths have the same number of nodes, the DPE array compiler 604 can order the paths in order of FIFO depth from smallest to largest based on the path.

[0128] In an example, at step 1806, the DPE array compiler 604 reorders the nodes along each path identified in step 1804. The degree of a node is defined as the total number of times the node is used on all paths. The DPE array compiler 604 can order the nodes in ascending order of degree. By performing a full graph analysis and node ordering prior to FIFO determination, the method 1800 can move common FIFO depths towards data sources while still being able to update depths near DPEs. In addition, the method 1800 can handle broadcasts from FIFO ports.

[0129] In Figure 17A ​In the example of FIG. 16, the shortest path that requires a FIFO is between data source 1602 and DPE 1604D. The path lengths between data source 1602 and DPEs 1604B and 1604C are the same (e.g., three nodes). However, the path between data source 1602 and DPE 1604B has a shallower FIFO depth (e.g., 10) than the path between data source 1602 and DPE 1604C (e.g., 20). Thus, DPE array compiler 604 can process the path between data source 1602 and DPE 1604D, then the path between data source 1602 and DPE 1604B, and finally the path between data source 1602 and DPE 1604C.

[0130] In the example of FIG. 17, node 1702 is part of three paths, node 1704 is part of three paths, and node 1706 is part of two paths. Thus, for the paths between data source 1602 and DPEs 1604B and 1604C, the node order is 1706, 1704, and 1702. For the path between data source 1602 and DPE 1604D, the node order is 1704 and 1702. Figure 17A

[0131] DPE array compiler 604 then performs steps 1810-1816 by processing the paths in the determined order and the determined node order for each path. The result, shown in FIG. 18, is the same as the result of the previous example (without path ordering and node reordering) in this case. However, in actual examples, the solution obtained can be different. Figure 17B

[0132] Routing of connections between cores in a DPE array

[0133] Routing between cores in a DPE array can be achieved by greedily assigning lanes to routes that need to communicate with the PL 122. As a greedy heuristic approach, this approach exposes limitations when routing larger graphs or when special constraints need to be handled. Prior approaches do not support handling architecture constraints, packet switching, and lanes that need to scale up / down conversion and routing for explicit packet switching in the programming model. Techniques for routing that handle these requirements are described herein.

[0134] ​​The following terms are introduced to describe the routing techniques described herein for routing applications mapped to the DPE array 105. Routing node: A node in the routing graph that represents a source or destination of data or an intermediate switch. Node capacity: An integer that represents the maximum allowed data flow through the node. Routing edge: A routing edge represents a potential data flow from a source to a destination. Routing graph: A routing graph represents all possible routing choices. These choices model the routing constraints imposed by the architecture switch constraints, user-defined shim constraints, constraints on expanding / reducing lanes, and constraints defined by the programmer through explicit packet split and merge operations. Network: A network represents a required routing with a source node in the routing graph and multiple destinations in the routing graph. Network utilization: An integer that models the bandwidth required by the network. A low bandwidth network can route together by sharing switch resources.

[0135] Figure 19 A flowchart of a method 1900 to describe routing applications mapped to the DPE array 105 is depicted according to an example. The method 1900 can be performed during step 1116 of the method 1100 described above. The method 1900 begins at step 1902, where the DPE array compiler 604 constructs a routing graph. The DPE array compiler 604 constructs the routing graph based on the description of the DPE array 105 architecture. Each stream switch port is modeled as a single routing node. Each DMA, control port, and core stream port is modeled as a routing node. The potential choices for switching are represented as edges between nodes. All possible switching options allowed in the architecture are modeled in the routing graph. Constructing the routing graph only requires the description of the architecture of the DPE array 105.

[0136] At step 1904, the DPE array compiler 604 models the PL connections. Since the output of a PL node can be connected to any shim port, the DPE array compiler 604 models each PL connection as a cross-bar connection from the PL source to all lanes in the shim. If the user specifies specific constraints on the shim lanes, the cross connection can be specialized to the given set of shim constraints.

[0137] At step 1906, the DPE array compiler 604 models the expander / reducer connections. The shim architecture allows higher bit-width lanes running at lower frequencies to be connected to lower bit-width lanes running at higher frequencies. The shim lanes have a fixed bit-width, so implementing some higher bit-width lanes requires using multiple adjacent shim lanes. This architecture further restricts that the shim lane groups must be allocated on even boundaries. These constraints are incorporated by modifying the routing graph using new nodes and edges. The constraints are represented by replacing all cross connections with finite connectivity of shim lanes.

[0138] At step 1908, the DPE array compiler 604 models other constraints. Some constraints are not easily represented as connections in the routing graph. These are represented as additional global constraints on the network and resource routing. For example, an architecture constraint can allow four packet switch networks to pass through each switch port. Another example is to allow only one network to pass through a pad channel even if the bandwidth utilization is low. Early or late merging explicit packet switch nodes are handled by using the constraint mechanism.

[0139] At step 1910, the DPE array compiler 604 invokes a satisfiability solver (SAT solver) to route the application in the DPE array 105. The input specification graph is examined to find the networks that need to be routed. The source and destination of the network are identified. The source or destination network must be a node in the routing graph. To enable packet switching, the user provides the network utilization. All the networks in the input specification along with the constraints are passed to the SAT solver. The solution provided by the SAT solver is used to program the flow switches (e.g., flow switch configuration code 616) of the DPE array 105.

[0140] Figure 20 A block diagram of a programmable IC 1 is depicted in accordance with an example that can be used as an implementation of the device 100 shown in Figure 1 The programmable IC 1 includes programmable logic 3, configuration logic 25, and configuration memory 26. The programmable IC 1 can be coupled to external circuits, such as non-volatile memory 27, DRAM 28, and other circuits 29. The programmable logic 3 includes logic cells 30, support circuits 31, and programmable interconnect 32. The logic cells 30 include circuits that can be configured to implement a general logic function of multiple inputs. The support circuits 31 include special-purpose circuits, such as transceivers, input / output blocks, digital signal processors, memories, and the like. The logic cells and support circuits 31 can be interconnected using the programmable interconnect 32. Information for programming the logic cells 30, for setting parameters of the support circuits 31, and for programming the programmable interconnect 32 is stored in the configuration memory 26 by the configuration logic 25. The configuration logic 25 can obtain the configuration data from the non-volatile memory 27 or any other source, such as the DRAM 28 or from the other circuits 29. In some examples, the programmable IC 1 includes a processing system 2. The processing system 2 can include a microprocessor, memory, support circuits, IO circuits, and the like.

[0141] Figure 21The diagram illustrates a field-programmable gate array (FPGA) implementation of programmable IC 1, comprising a large number of different programmable cell blocks, including transceiver 37, configurable logic blocks (“CLBs”) 33, random access memory blocks (“BRAMs”) 34, input / output blocks (“IOBs”) 36, configuration and clock logic (“CONFIG / CLOCKS”) 42, digital signal processing blocks (“DSPs”) 35, dedicated input / output blocks (“I / O”) 41 (e.g., configuration ports and clock ports), and other programmable logic 39, such as a digital clock manager, analog-to-digital converters, system monitoring logic, etc. The FPGA may also include a PCIe interface 40, an analog-to-digital converter (ADC) 38, etc.

[0142] In some FPGAs, each programmable cell block may include at least one programmable interconnect element (“INT”) 43 having connections to input and output terminals 48 of programmable logic elements within the same cell block, such as in Figure 21 The example included at the top is shown. Each programmable interconnect element 43 may also include a connection to an interconnect segment 49 of adjacent programmable interconnect elements in the same cell block or other cell blocks. Each programmable interconnect element 43 may also include a connection to an interconnect segment 50 of a general routing resource between logic blocks (not shown). The general routing resource may include a routing path between logic blocks (not shown), which includes traces of interconnect segments (e.g., interconnect segment 50) and switch blocks (not shown) for connecting interconnect segments. The interconnect segment of the general routing resource (e.g., interconnect segment 50) may span one or more logic blocks. The programmable interconnect element 43, together with the general routing resource, implements a programmable interconnect structure (“programmable interconnect”) for the illustrated FPGA.

[0143] In the example implementation, CLB 33 may include configurable logic elements (“CLE”) 44, which can be programmed to implement user logic plus a single programmable interconnect element (“INT”) 43. In addition to one or more programmable interconnect elements, BRAM 34 may also include BRAM logic elements (“BRL”) 45. Typically, the number of interconnect elements included in a cell block depends on the height of the cell block. In the illustrated example, a BRAM block has the same height as five CLBs, but other numbers (e.g., four) may also be used. In addition to an appropriate number of programmable interconnect elements, DSP block 35 may also include DSP logic elements (“DSPL”) 46. In addition to one instance of programmable interconnect element 43, IOB 36 may include two instances, for example, input / output logic elements (“IOL”) 47. Those skilled in the art will appreciate that, for example, the actual I / O pads connected to I / O logic elements 47 are typically not limited to the area of ​​the input / output logic elements 47.

[0144] In the illustrated example, a horizontal region near the center of the die (e.g., as shown) is used for configuration, clock, and other control logic. Vertical columns 51 extending from this horizontal region or column are used to distribute clock and configuration signals across the width of the FPGA. Figure 12

[0145] Some FPGAs using the illustrated architecture include additional logic blocks that disrupt the regular columnar structure that makes up most of the FPGA. The additional logic blocks can be programmable blocks and / or dedicated logic. Figure 21

[0146] It should be noted that Figure 21 The illustrated FPGA architecture is intended to show only exemplary FPGAs. For example, the number of logic blocks in a row, the relative widths of the rows, the number and order of the rows, the types of logic blocks included in the rows, the relative sizes of the logic blocks, and the interconnect / logic implementation at the top are purely exemplary. For example, in actual FPGAs, more than one row of adjacent CLBs is typically included at any location where CLBs appear to facilitate efficient implementation of user logic, but the number of rows of adjacent CLBs varies with the overall size of the FPGA. Figure 21

[0147] While the foregoing is directed to specific examples, other and further examples can be devised without departing from the basic scope of the disclosure. The scope of the disclosure should be determined from the claims.​​​

Claims

1. A method for implementing an application for a system on chip (SOC) having an array of data processing engines (DPEs), the method comprising: The method comprises: determining a graph representation of the application, the graph representation comprising nodes representing kernels of the application and edges representing communication between the kernels; mapping the kernels onto DPEs of the DPE array and mapping data structures of the kernels onto memories of the DPE array based on the graph representation; routing communication channels between DPEs and circuits of the application configured in programmable logic of the SOC; generating implementation data for programming the SOC to implement the application based on results of the mapping and the routing; and determining the graph representation to aggregate kernels into groups prior to the mapping, wherein the mapping comprises mapping at least one group of kernels onto one DPE in the DPE array.

2. The method of claim 1, wherein, The method further comprises: optimizing code of one or more kernels prior to the mapping step; and allocating locks for DPE-to-DPE communication in the DPE array.

3. The method of claim 1, wherein, The mapping step comprises: mapping the data structures into at least one of memory banks in the DPEs and direct memory access (DMA) streams between the DPEs.

4. A non-transitory computer-readable medium, comprising: The non-transitory computer-readable medium has stored thereon instructions that, when executed by a processor, cause the processor to perform a method for implementing an application for a system on a chip (SOC) having a data processing engine (DPE) array, the method comprising: determining a graph representation of the application, the graph representation comprising nodes representing kernels of the application and edges representing communication between the kernels; mapping the kernels onto DPEs of the DPE array and mapping data structures of the kernels onto memories of the DPE array based on the graph representation; routing communication channels between DPEs and circuits of the application configured in programmable logic of the SOC; generating implementation data for programming the SOC to implement the application based on results of the mapping and the routing; and determining the graph representation to aggregate kernels into groups prior to the mapping, wherein the mapping comprises mapping at least one group of kernels onto one DPE in the DPE array.

5. The non-transitory computer-readable medium of claim 4, wherein, The method further comprises: optimizing code of one or more kernels prior to the mapping step.

6. The non-transitory computer-readable medium of claim 4, wherein, The mapping step comprises: mapping the data structures into at least one of memory banks in the DPEs and direct memory access (DMA) streams between the DPEs.

7. The non-transitory computer-readable medium of claim 4, wherein, The method further comprises: allocating locks for DPE-to-DPE communication in the DPE array.

8. The non-transitory computer-readable medium of claim 4, wherein, The generating the implementation data step comprises: generating code for each DPE to implement one or more kernels therein.

9. The non-transitory computer-readable medium of claim 4, wherein, The generating the implementation data step comprises: generating control code to configure direct memory access (DMA) and switch circuits in the DPE array.

10. A computer system, characterized by The computer system comprises: a memory to store program code; and a processor configured to execute the program code to implement an application for a system on a chip (SOC) having a data processing engine (DPE) array by: determining a graphical representation of the application, the graphical representation including nodes representing kernels of the application and edges representing communication between the kernels; mapping the kernels onto DPEs of the DPE array and mapping data structures of the kernels to memory in the DPE array based on the graphical representation; routing communication channels between the DPEs and circuitry of the application configured in programmable logic of the SOC; generating implementation data for programming the SOC to implement the application based on results of the mapping and the routing; and determining the graphical representation prior to the mapping to aggregate kernels into groups, wherein the mapping includes mapping at least one group of kernels onto one DPE in the DPE array.

11. The computer system of claim 10, wherein, the steps further include: optimizing code of one or more kernels prior to the mapping step.

12. The computer system of claim 10, wherein, the step of generating the implementation data includes: generating code for each DPE to implement one or more kernels therein; and generating control code to configure direct memory access DMA and switch circuitry in the DPE array.

Images