Computational Dataflow Architecture

Abstract

An exemplary integrated circuit comprises an array of circuit tiles and interconnects coupling the circuit tiles in the array, the interconnects including interconnect tiles each having a plurality of connections, the plurality of connections including a connection to at least one of the circuit tiles and a plurality of connections to at least one other interconnect tile, the integrated circuit comprising a plurality of local crossbars in each of the interconnect tiles, the plurality of local crossbars coupled to form a non-blocking crossbar, and each of the plurality of local crossbars comprising a handshake circuit for asynchronous communication.

Description

[Technical Field]

[0001] Examples of the present disclosure relate generally to electronic circuits, and more particularly to computational data flow architectures for programmable devices. [Background technology]

[0002] Programmable devices (e.g., integrated circuits containing programmable logic) include networks for transferring data between different configurable logic elements (CLEs). Synchronous networks can transfer data between two endpoints per clock cycle. However, the frequency of these transfers is limited by the clock speed and the placement of the CLEs. Furthermore, networks may include multiple interconnects (also called interconnect tiles or switching elements) that can be used to implement pipelining. Although clock speeds in integrated circuits have not increased rapidly in previous generations, highly pipelined designs can increase throughput despite slower circuits. However, in synchronous networks, pipeline stages in parallel paths must be aligned with each other to maintain functional correctness. However, pipelining is difficult to achieve in synchronous networks due to clock jitter, clock skew, flip-flop setup / clock-to-out overhead, and imperfect flip-flop timing locations.

[0003] One solution is to use asynchronous networks to transfer data between CLEs in the programmable logic, which overcomes the limitations of pipelining in synchronous networks. That is, asynchronous networks can have different parallel paths with different lengths and still perform pipelining. Furthermore, asynchronous networks are not dependent on clock jitter or different clock domains. However, asynchronous networks have drawbacks over synchronous networks, such as the need for handshaking and fanout enablement. Summary of the Invention [Means for solving the problem]

[0004] In one example, an integrated circuit includes an array of circuit tiles having circuits configured to perform data operations, and an interconnect coupling the circuit tiles in the array, the interconnect including interconnect tiles each having a plurality of connections, the plurality of connections having at least a first connection to a respective one of the circuit tiles and a plurality of connections to a plurality of other interconnect tiles, the integrated circuit includes a plurality of local crossbars in each of the interconnect tiles, the plurality of local crossbars being coupled to form a non-blocking crossbar.

[0005] In another example, an integrated circuit includes an array of circuit tiles having circuitry configured to perform data operations and an interconnect coupling the circuit tiles in the array, the interconnect including interconnect tiles each having a plurality of connections, the plurality of connections having at least a first connection to a respective one of the circuit tiles and a plurality of connections to a plurality of other interconnect tiles, and further, the interconnect tiles are connected to each other using a plurality of buses, and each of the interconnect tiles includes a handshake circuit for asynchronous communication.

[0006] In another example, a method includes receiving source code to be implemented in an integrated circuit comprising an array of circuit tiles communicatively coupled using a programmable interconnect and a plurality of interconnect tiles; converting the source code into a flow control graph; and converting the flow control graph into a primitive graph comprising a plurality of predefined primitives, each of the predefined primitives comprising circuitry for performing at least a portion of the operations defined in the flow control graph, the method further including mapping the predefined primitives in the primitive graph to a plurality of circuit tiles, the plurality of circuit tiles each comprising at least a multiplier and circuitry for performing one additional logic function that may be programmably selected, the method including implementing the source code in the integrated circuit by connecting the plurality of circuit tiles using a plurality of interconnect tiles. These and other aspects can be understood by reference to the following detailed description.

[0007] So that the above-enumerated features may be understood in detail, a more particular description briefly summarized above can be had by reference to exemplary implementations, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings are exemplary and depict only exemplary implementations, and therefore should not be considered limiting of the scope thereof. [Brief explanation of the drawings]

[0008] [Figure 1A] FIG. 1 is a block diagram illustrating a programmable IC according to an example. [Figure 1B] FIG. 1 is a block diagram illustrating a programmable device according to an example. [Figure 1C] FIG. 1 illustrates a Field Programmable Gate Array (FPGA) implementation of a programmable IC according to an example. [Figure 2] FIG. 2 is a block diagram illustrating a portion of programmable logic according to an example. [Figure 3]FIG. 2 is a block diagram illustrating interconnect tiles according to an example. [Figure 4] FIG. 2 is a block diagram illustrating a complete non-blocking crossbar for implementing interconnect tiles according to an example. [Figure 5] FIG. 2 is a block diagram illustrating a local crossbar according to an example. [Figure 6] 1 is a flowchart for configuring programmable logic using intermediate primitives according to an example. [Figure 7A] FIG. 10 is a block diagram illustrating different primitives that can be formed from a CLE according to an example. [Figure 7B] FIG. 10 is a block diagram illustrating different primitives that can be formed from a CLE according to an example. [Figure 7C] FIG. 10 is a block diagram illustrating different primitives that can be formed from a CLE according to an example. [Figure 7D] FIG. 10 is a block diagram illustrating different primitives that can be formed from a CLE according to an example. DETAILED DESCRIPTION OF THE INVENTION

[0009] For ease of understanding, where possible, identical reference numbers have been used to indicate identical elements common to the figures. It is contemplated that elements of one example may be beneficially incorporated in other examples.

[0010] [Detailed explanation] Various features will now be described with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale, and that elements of similar structure or function are represented by similar reference numerals throughout the drawings. It should be noted that the drawings are intended only to facilitate the description of features. They are not intended as an exhaustive description of the claimed invention or as limitations on the scope of the claimed invention. Furthermore, the illustrated example need not have all aspects or advantages shown. An aspect or advantage described in connection with a particular example is not necessarily limited to that example and may be implemented in any other example, even if not so shown or explicitly described.

[0011] FIG. 1A is a block diagram illustrating a programmable IC 1 according to an example. The programmable IC 1 includes programmable logic 3 (also referred to as programmable fabric), configuration logic 25, and configuration memory 26. The programmable IC 1 can be connected 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 common logic functions of multiple inputs. The support circuits 31 include specialized circuits such as transceivers, input / output blocks, digital signal processors, and memories. The logic cells and support circuits 31 can be interconnected using programmable interconnect 32. Information for programming the logic cells 30, setting parameters of the support circuits 31, and programming the programmable interconnect 32 is stored in the configuration memory 26 by the configuration logic 25. Configuration logic 25 may obtain configuration data from non-volatile memory 27 or any other source (e.g., from DRAM 28 or other circuitry 29). In some examples, programmable IC 1 includes processing system 2. Processing system 2 may include a microprocessor, memory, support circuitry, IO circuitry, etc. In some examples, programmable IC 1 includes network-on-chip (NOC) 55 and data processing engine (DPE) array 56. NOC 55 is configured to provide communication between subsystems of programmable IC 1, such as between PS 2, PL 3, and DPE array 56. DPE array 56 may include an array of DPEs configured to perform data processing, such as an array of vector processors.

[0012] 1B is a block diagram illustrating a programmable device 54 according to an example. The programmable device 54 includes multiple programmable integrated circuits (ICs) 1, e.g., programmable ICs 1A, 1B, 1C, and 1D. In one example, each programmable IC 1 is an IC die disposed on an interposer 60. Each programmable IC 1 comprises a super logic region (SLR) 53, e.g., SLRs 53A, 53B, 53C, and 53D, of the programmable device 54. The programmable ICs 1 are interconnected via conductors (called super long lines (SLLs) 52) on the interposer 60.

[0013] FIG. 1C illustrates a field programmable gate array (FPGA) implementation of programmable IC 1, including PL 3. PL 3 shown in FIG. 1C can be used in any of the programmable device examples described herein. PL 3 has a number of different programmable tiles, including transceivers 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 and clock ports), and other programmable logic 39, such as a digital clock manager, analog-to-digital converters, and system monitoring logic. PL 3 also includes a PCIe interface 40, analog-to-digital converters (ADCs) 38, and the like.

[0014] In some PLs, each programmable tile 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 tile, as shown by the example included at the top of FIG. 1C. Each programmable interconnect element 43 may also include connections to interconnect segments 49 of adjacent programmable interconnect elements within the same or other tiles. Each programmable interconnect element 43 may also include connections to interconnect segments 50 of general-purpose routing resources between logic blocks (not shown). The general-purpose routing resources may include routing channels between logic blocks (not shown) that comprise tracks of interconnect segments (e.g., interconnect segments 50) and switch blocks (not shown) for connecting the interconnect segments. The interconnect segments of the general-purpose routing resources (e.g., interconnect segments 50) may span one or more logic blocks. The programmable interconnect elements 43, together with the general-purpose routing resources, implement the programmable interconnect structure (programmable interconnect) for the illustrated PL.

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

[0016] In the illustrated example, a horizontal region near the center of the die (shown in FIG. 3D) is used for configuration, clocks, 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 PL.

[0017] Some PLs utilizing the architecture shown in Figure 1C include additional logic blocks that break up the regular columnar structure that makes up the majority of the PL. The additional logic blocks can be programmable blocks and / or dedicated logic.

[0018] Note that Figure 1C is intended to illustrate only an exemplary PL architecture. For example, the number of logic blocks in a row, the relative width of the rows, the number and order of rows, the types of logic blocks included in the rows, the relative sizes of the logic blocks, and the interconnect / logic implementation included in the upper part of Figure 1C are purely illustrative. For example, in an actual PL, multiple adjacent rows of CLBs are typically included wherever CLBs appear to facilitate efficient implementation of user logic, although the number of adjacent CLB rows will vary depending on the overall size of the PL.

[0019] The programmable interconnect 32 described above couples to various circuit tiles within the programmable logic 3. The programmable interconnect 32 (also referred to as interconnect) can be programmed using the configuration memory 26 to connect different circuit tiles to each other to form circuits within the programmable logic 3. One type of interconnect 32 is a pipelined synchronous interconnect. However, for large devices, a highly pipelined synchronous interconnect would have a large number of registers and consume excessive area and power. Furthermore, signals flowing through many sequential registers have significant latency. In addition, clock enable (CE) timing becomes an issue at high frequencies. Finally, software tools that generate data to program the interconnect must guarantee matched cycle counts on parallel paths and require optional registers, extra first-in-first-out (FIFOs), and tool support for these components.

[0020] In one example, the interconnect 32 is asynchronous. A highly pipelined asynchronous interconnect avoids most of the problems mentioned above associated with synchronous interconnect. Circuits switch only when data indicates they should. There are no clocks or clock enables. Asynchronous handshakes act as fine-grained clocks and clock enables. Parallel paths do not need to match in stage count. In the absence of pushback, data flows quickly through open gates, minimizing latency. Rather than guaranteeing the worst case of synchronization, the asynchronous interconnect 32 can operate as fast as the silicon, voltage, and temperature allow. This is advantageous for computational applications and is compatible with temperature-dependent voltage scaling within the device.

[0021] FIG. 2 is a block diagram illustrating a portion 200 of programmable logic 3 according to one example. Programmable logic 3 includes an array of circuit tiles, e.g., CLEs 202A-F (collectively referred to as CLEs 202). As mentioned above, programmable logic 3 can include different types of circuit tiles other than CLEs, but CLEs 202 are shown for clarity by example. Interconnect 32 includes interconnect tiles 204A-F (collectively referred to as interconnect tiles 204). Each CLE 202 is coupled to an interface of an interconnect tile 204. Each interconnect tile 204 includes additional interfaces to other interconnect tiles 204. In the illustrated example, connections between interconnect tiles 204 include single connections 206 and double connections 208. The connections further include connections 210 to CLEs 202. Single connections 206 connect adjacent interconnect tiles 204. A dual connection 208 connects one interconnect tile 204 to another non-adjacent interconnect tile 204 with one interconnect tile between them.

[0022] Each connection 206, 208, 210 includes multiple N-bit buses. For example, a single connection 206 may include two 4-bit buses in each direction between interconnect tiles 204. Similarly, a dual connection 208 may include two 4-bit buses in each direction between respective interconnect tiles 204. In such a case, 2×2×4=16 wires exist between two adjacent interconnect tiles 204 to implement the single connection 206. Similarly, there are 2×2×2×4=32 wires (assuming the non-edge case) carrying data signals between two adjacent interconnect tiles 204 to implement two dual connections 208 disposed between the interconnect tiles 204. Each bus may also have Ready and Acknowledge handshake signals, which add two more wires for each 4-bit bus, resulting in a total of 48 wires extending between two adjacent interconnect tiles 204. In one example, connections 210 between interconnect tiles 204 and CLEs 202 include three 4-bit buses to CLEs 202 and two 4-bit buses from CLEs 202. In such a case, there are 3×2×4=24 wires between interconnect tiles 204 and CLEs 202. Those skilled in the art will understand that the number of buses and the width N of the buses implementing single connections 206, dual connections 208, and connections 210 to CLEs 202 can vary from the example described herein.

[0023] In one embodiment, interconnect tiles 204 in portion 200 form an asynchronous network for transferring data between CLEs 202. In one embodiment, interconnect tiles 204 form a pipeline between CLEs 202. For example, each interconnect tile 204 can serve as a stage in the pipeline. Alternatively or additionally, each interconnect tile 204 can have multiple (internal) stages in the pipeline. Rather than using a clock signal, the stages in the pipeline can transfer data using a handshake protocol. For example, if CLE 202A in the upper left of FIG. 2 has data to be transferred to CLE 202F in the lower right, interconnect tiles 204A, B, C, and F can form a pipeline for transferring the data. That is, a first chunk of data is transferred from CLE 202A to interconnect tile 204A. Using the handshake protocol, interconnect tile 204A transfers the first chunk of data to interconnect tile 204B. In parallel, CLEs 202A can transfer the second data chunk to interconnect tile 204A. Again, using the handshake protocol, interconnect tile 204B can transfer the first data chunk to interconnect tile 204C, while interconnect tile 204A transfers the second data chunk to interconnect tile 204B, and CLEs 202A transfers the third data chunk to interconnect tile 204A. The first data chunk can then be transferred from interconnect tile 204C to interconnect tile 204F, while the second and third data chunks also advance in the pipeline, and CLEs 202A transfers the fourth data chunk to interconnect tile 204A. The first data chunk is then transferred to CLEs 202F. In this manner, multiple chunks can propagate through stages of a pipeline formed using interconnect tiles 204. Furthermore, the transfer of data is asynchronous and does not rely on a shared clock, but rather on handshaking signals that indicate when a stage is ready to transfer data.Additionally, although this example describes the use of interconnect tiles 204 as stages, as described below, the interconnect tiles 204 themselves can form multiple internal stages of a pipeline.

[0024] FIG. 3 is a block diagram illustrating an interconnect tile 204 according to one example. In this example, the interconnect tile 204 includes single connections 302N, 302E, 302S, and 302W to each of the interconnect tiles 204 adjacent to the north, east, south, and west. The interconnect tile 204 includes dual connections 304N, 304E, 304S, and 304W to each of the interconnect tiles 204 that are not adjacent to the north, east, south, and west. The interconnect tile 204 includes CLE connections 306 to each CLE. The interconnect tile 204 illustrated in FIG. 3 is for a non-edge case. Those skilled in the art will understand that an interconnect tile on an edge may have fewer than all of the N, E, S, and W connections because there may not be additional tiles in some directions at the edge.

[0025] 4 is a block diagram illustrating a non-blocking crossbar 400 for implementing interconnect tiles 204 according to an example. That is, non-blocking crossbar 400 is one implementation of a circuit that may be used to implement interconnect tiles 204 of FIGS. 2 and 3. In one embodiment, crossbar 400 is “non-blocking” because any set of signals received simultaneously on the left bus can be successfully routed (without conflicts) to the right bus. That is, crossbar 400 can simultaneously receive any set of signals that can be successfully routed through crossbar 400, but crossbar 400 may have to rearrange how it routes signals to arrive at a non-blocking solution.

[0026] The non-blocking crossbar 400 is formed from local crossbars 402-430 (which may also be referred to as switch boxes). In this example, two buses in each direction are assumed for the single connection 206, and two buses in each direction are assumed for the dual connection 208. In such a case, there are four buses for each direction, coming from the N, S, E, and W directions. Specifically, there are two buses S1 and S2 from the south, two buses N1 and N2 from the north, two buses E1 and E2 from the east, and two buses W1 and W2 from the west. Also, in this example, there are three input buses (In) to the CLE and two output buses (Out) from the CLE. Furthermore, in this example, there is one 4-bit bus above and below in the Z direction to support communication between stacked die layers. The local crossbars 402-430 are connected to function as a non-blocking crossbar. Non-blocking crossbars allow software tools to significantly reduce runtime by simplifying the model of the device. One reason software tools can reduce runtime is that software algorithms operating on a more global scale can assume that local routing problems are solvable and do not need to worry about detailed connections at the local level. In other words, the details can be abstracted away, and all of the local routing problems can be solved quickly in parallel at a later stage. Using smaller local crossbars as building blocks allows the acknowledgment handshake circuitry to be implemented locally and efficiently, enabling fanout in the programmable interconnect (described below).

[0027] In one example, the number of connections between local crossbars 402-430 is reduced relative to the number typically present in a fully non-blocking crossbar implementation. That is, a fully non-blocking crossbar would include connections that allow signals to reverse and continue in the direction from which they came. For example, if a signal arrives from the south, a fully non-blocking crossbar could route the signal back south. However, in a full crossbar-based routing network, there is no reason for signals to reverse direction, and therefore the non-blocking crossbar 400 shown in FIG. 4 does not have circuitry for reversing the direction of signals. That is, connections that unnecessarily reverse direction are omitted.

[0028] This reduces the implementation cost of non-blocking crossbar 400 by approximately 20% while maintaining the non-blocking nature of the crossbar. The effect of eliminating the circuitry for reversing direction can be seen in the left column, where local crossbar 402 receives four inputs (two buses in the south direction) and has only four outputs to the center column. Notably, crossbar 402 does not connect to local crossbar 420 (labeled ∼S, or not SOUTH, indicating that the crossbar does not connect to local crossbars 402 and 430, which are coupled to buses extending in the south direction). Using the other four crossbars in the center column (i.e., local crossbars 412, 414, 416, and 418), local crossbar 402 can forward data in the N, E, and W directions. Similarly, local crossbars 404 and 424 coupled to buses extending in the east direction are not connected to local crossbar 418 (labeled ∼E), local crossbars 408 and 428 coupled to buses extending in the west direction are not connected to local crossbar 414 (labeled ∼W), and local crossbars 410 and 422 connected to local buses extending in the north direction are not connected to local crossbar 412 (labeled ∼N). This reduces circuit complexity while still maintaining the non-blocking aspect of crossbar 400 in the relevant direction; for example, southbound signals can be routed to N, E, and W, northbound signals can be routed to E, W, and S, eastbound signals can be routed to N, W, and S, and westbound signals can be routed to N, S, and E.

[0029] In this example, local crossbar 402 is coupled to S1 and S2 on one side and to each of local crossbars 412, 414, 416, and 418 on the other side. Local crossbar 404 is coupled to E1 and E2 on one side and to each of local crossbars 412, 414, 416, and 420 on the other side. Local crossbar 408 is coupled to receive W1 and W2 on one side and to each of local crossbars 412, 416, 418, and 420 on the other side. Local crossbar 402 is coupled to receive N1 and N2 on one side and to each of local crossbars 414, 416, 418, and 420 on the other side. Each of the local crossbars 402, 404, 408, and 410 is a 4x4 crossbar rather than a 4x5 crossbar because it does not need to be reversible in direction as described above.

[0030] In this example, local crossbar 430 is coupled to S1 and S2 on one side and to each of local crossbars 412, 414, 416, and 418 on the other side. Local crossbar 424 is coupled to E1 and E2 on one side and to each of local crossbars 412, 414, 416, and 420 on the other side. Local crossbar 428 is coupled to receive W1 and W2 on one side and to each of local crossbars 412, 416, 418, and 420 on the other side. Local crossbar 422 is coupled to receive N1 and N2 on one side and to each of local crossbars 414, 416, 418, and 420 on the other side. Each of local crossbars 422, 424, 428, and 430 is a 4x4 crossbar.

[0031] Local crossbar 406 is coupled to Out and Z on one side and to each of local crossbars 412-420 on the other side. In this example, local crossbar 406 is a 4x5 crossbar rather than a 4x4 crossbar, allowing the Out signal (connected to the CLE) to be reversed and fed back to the CLE using the In signal (also connected to the CLE). However, if data from the CLE does not need to reverse direction, local crossbar 406 could be a 4x4 crossbar. Local crossbar 426 is coupled to In and Z on one side and to each of local crossbars 412-420 on the other side. The Z bus is used when programmable devices (e.g., integrated circuits) are stacked with other programmable devices on other integrated circuits. That is, the Z bus allows interconnect tiles in a first programmable device to communicate with interconnect tiles in a second programmable device (in the Z direction, rather than the north, east, south, and west directions that extend in the X and Y directions). However, if the programmable device is not stacked (e.g., not daisy-chained) with other programmable devices, the Z bus may be omitted. In this example, local crossbar 426 is a 5x5 crossbar. Local crossbars 412, 414, 418, and 420 are each a 4x4 crossbar. Local crossbar 416 is a 5x5 crossbar.

[0032] Additionally, the circuitry of the local crossbar can be further reduced by eliminating the flexibility to select between identical wires. In FIG. 4, there are 4×4 switch boxes in the first and last columns, one serving each direction of the bus. For example, because there are two East buses of length 1, the routing does not care which of these two identical buses is used by a given routed signal. As a result, the local crossbar can be configured to route all combinations of signals through the local crossbar, but these signals are only routed to any output pin, not all output pin permutations. In one embodiment, the 4×4 switch box can be reduced to two 2×2 switch boxes in either the first or last column (but not both) to eliminate this bit of flexibility.

[0033] FIG. 5 is a block diagram illustrating a local crossbar 500 according to an example. The local crossbar 500 is a 2×2 crossbar, although the 4×5, 5×4, and 5×5 local crossbars shown in FIG. 4 can have similar structures. The local crossbar 500 includes a handshake circuit 502 that provides asynchronous communication between the inputs and outputs of the local crossbar 500. Asynchronous communication generally includes data and control signals for acknowledgment. As shown, the handshake circuit 502 includes acknowledgement signals (i.e., Aack, Back, Xack, and Yack) for data signals A, B, X, and Y in a data path 505. In one embodiment, the A and B signals may be inputs to the local crossbar 500, while the X and Y signals are outputs. For example, the A signal may be the first bit in a first bus received at the local crossbar 500, while the B signal may be the first bit in a second bus received at the local crossbar 500. Although not shown, local crossbar 500 may have multiple copies of datapath 505 depending on the width of the two buses. For example, if the two buses are 4-bit buses, then local crossbar will have four copies of datapath 505, one copy for each bit in the bus.

[0034] The handshake circuit 502 enables fanout, where one signal can “fan out” to multiple inputs. For example, the A signal can be output on the X output, the Y output, or both the X and Y outputs. Allowing the A signal to fan out, so that the A signal can be output on both the X and Y outputs simultaneously, requires the handshake circuit 502 to determine that data input at A has been received on both the X and Y outputs. To do so, the handshake circuit 502 may include C elements and multiplexing to enable asynchronous handshakes when input signals fan out to multiple output signals. Referring to the local crossbars of FIG. 4 , the handshake circuits in these crossbars allow one of the inputs to fan out to some or all of the outputs simultaneously (e.g., two, three, four, or five of the outputs, depending on the number of outputs in the local crossbar). In one embodiment, the fanout in these small local crossbars is highly localized, allowing the local circuitry to easily implement acknowledgment signaling, as shown in the example of FIG. 5 . If the fanout is not localized (e.g., extends to circuits far away from each other), generating acknowledgments can be very expensive and impractical because many wires would be required to return from each of the fanout locations. Therefore, localizing the fanout at the local crossbar improves the performance and cost of the device.

[0035] In one embodiment, in the local crossbar shown in Figure 5, X_select_A, Y_select_A, X_select_B, and Y_select_B are all signals from configuration memory cells consistent with typical FPGA routing architectures. In other words, the selection of which signals to route through the multiplexers is not continuously dynamic, but rather depends on the memory cell values.

[0036] In one example, a CLE implements a set of building blocks designed to support intermediate primitives in a high-level programming language, such as C or C++. This contrasts with traditional FPGAs, which have lookup tables (LUTs) and flip-flops to support random logic described using a hardware description language (HDL). That is, current solutions convert compiled source code from a programming language into interconnected LUTs and flip-flops, because these circuits can be used to represent essentially any logical configuration that can also be expressed in source code. However, synthesizing source code into a design for programmable logic containing LUTs and flip-flops requires a significant amount of time. Furthermore, the synthesis process requires consideration of routing constraints and timing issues. Furthermore, storage elements within the local crossbar can be either edge-sensitive or level-sensitive latches, depending, for example, on whether a two-phase or four-phase handshake is used. Both are possible and can be implemented with corresponding modifications to the internal handshake logic.

[0037] The following embodiments discuss using intermediate primitives to map source code into CLEs that are interconnected using an asynchronous network (e.g., the interconnect tiles described above). Doing so can save time and resources compared to traditional methods of translating source code into Register Transfer Level (RTL) code, which is then used to configure LUTs and flip-flops within programmable logic.

[0038] 6 is a flowchart of a method 600 for configuring programmable logic using intermediate primitives, according to one embodiment described herein. At block 605, a compiler translates source code into a flow control graph. That is, the compiler maps source code developed using a high-level programming language (e.g., C, C++, etc.) to a flow control graph. Embodiments herein are not limited to any particular technique for translating source code into a flow control graph.

[0039] In one embodiment, a flow control graph represents how data flows as defined by operations in source code. For example, a flow control graph can indicate whether there are data dependencies between operations or whether operations are independent of one another. Independent operations can execute in parallel in a flow control graph. In contrast, dependent operations can be connected in a chain, such that the output of one operation can affect the input of another operation.

[0040] Typically, when implementing source code using programmable logic, a synthesizer converts the flow control graph into RTL, which is then mapped to LUTs and flip-flops in the programmable logic. However, as mentioned above, this introduces many complexities into the synthesis process, such as timing constraints, routing, and placement.

[0041] Instead of translating the flow control graph into RTL, in block 610 the synthesizer translates the flow control graph into a primitive graph formed using a predefined group of intermediate primitives. That is, the synthesizer can directly map operations in the source code (and the flow control graph) to predefined intermediate primitives. For example, there may be an intermediate primitive for each type of operation that can be expressed in the source code.

[0042] 7A-7D are block diagrams illustrating different intermediate primitives according to an example. FIG. 7A shows an intermediate primitive formed by a three-input, two-output LUT. The flexibility of LUTs allows them to perform many different source code operations. In other words, many different operations that can be defined using source code can be implemented in hardware using LUTs, such as any binary operation (e.g., bitwise OR, AND, NOT, etc., or a bit shift operation). Furthermore, while the primitive in FIG. 7A can be a two-input / two-output LUT, a three-input / two-output LUT can perform two binary operations in parallel with only the small amount of additional circuitry associated with a two-input / two-output LUT.

[0043] 7B shows intermediate primitives for performing addition, multiplication, or comparison operations (i.e., addition, subtraction, and multiplication operations), which can be mapped to addition, multiplication, or comparison operations defined in the source code and flow control graph.

[0044] FIG. 7C illustrates flow control primitives for performing flow control that can correspond to "if," "while," and "for" operations (or statements) in source code. For example, for an "if" operation, the primitive in FIG. 7C can compare inputs A and B and output a bit (0 or 1) indicating whether A and B are equal. This output can be provided to another flow control primitive as a CNTRL signal to select which of its inputs is output. Furthermore, the flow control primitives in FIG. 7C can use token management and handshaking to perform source code operations. In this way, an if operation can be mapped to two (or more) of the flow control primitives. Looping operations, such as a "while" or "for" operation, can be mapped in a similar manner (although the number of flow control primitives mapped to source code operations can vary).

[0045] FIG. 7D shows an intermediate primitive for performing multiple shift operations. In one embodiment, CLEs 202 can include a multiply block and can also be used as a shifter, since shifts are multiplied by powers of two. Reusing this block for shifting purposes can be more efficient, assuming shifting is not a common operation. If shifting turns out to be a very common primitive, CLEs 202 can have a separate shift block that performs the shift more efficiently than using a multiplier. For example, when using multiple blocks, there is an extra bit of logic to convert the shift value to its power of two.

[0046] The intermediate primitives shown in FIGS. 7A-7D are only some examples of primitives that may be defined and mapped to source code operations. In one embodiment, each source code operation may be mapped to one (or more) primitives. For example, several flow control primitives may be required to execute an if operation or a loop operation defined in the source code. However, in another embodiment, some source code operations may not have predefined primitives, or some operations may be mapped to the same type of primitive (e.g., a multiply and shift operation in the source code may both map to a multiply primitive). Furthermore, there may be source code operations that cannot be mapped to primitives. In that case, the corresponding portion of the flow control graph may be synthesized into programmable logic using previous techniques (e.g., translated to RTL rather than mapped to an intermediate primitive).

[0047] In one embodiment, the synthesizer identifies source code operations in the flow control graph that can be mapped to predefined primitives. As described above, a single operation may be mapped to multiple primitives (such as "if" and "while" statements in the source code). These primitives can be interconnected to form a primitive graph, much like the various signals in the flow control graph are connected. This allows the primitive graph to express the same logic as the flow control and source code.

[0048] Returning to method 600, in block 615, the synthesizer maps intermediate primitives in the primitive graph to CLEs in the programmable logic. For example, each intermediate primitive in FIGS. 7A-7D may be directly mapped to one of the CLEs 202 shown in FIG. 2. That is, a CLE 202 is configured to perform the function defined by one primitive. In one embodiment, CLEs 202 (e.g., circuit tiles) include circuits that perform different functions. In one embodiment, CLEs 202 include at least one multiplier and circuitry for performing at least one other logic function, such as a LUT, control flow, add / subtract / compare, etc. The primitives programmatically determine which of the logic functions are selected in CLEs 202. Thus, CLEs 202 differ from fixed blocks, which have fixed logic functions (i.e., the logic function performed by the block is not selectable).

[0049] Using intermediate primitives to directly configure CLEs avoids the need to generate RTL and then place the RTL at various locations within the programmable logic. Instead, the intermediate primitives are designed to map to one of the CLEs. As noted above, an operation can map to multiple primitives, in which case the operation can be performed using multiple CLEs.

[0050] In one embodiment, an IC includes an array of CLEs, as shown in Figure 2. These CLEs are communicatively connected by interconnect tiles 204 and programmable connections 210 (e.g., programmable interconnects). That is, lines extend between interconnect tiles 204 and between tiles 204 and CLEs 202.

[0051] In block 620, the synthesizer connects CLEs according to the flow of data in the primitive graph. That is, the selected CLEs may be connected using asynchronous interconnect tiles shown in the figures above. For example, if the flow control graph includes a 32-bit addition operation, this operation may be divided into four addition primitives (e.g., as shown in FIG. 7B), assuming these primitives have 8-bit buses. These four primitives may be mapped to four CLEs in the programmable logic, and the interconnect tiles may be configured to transfer data between the CLEs (e.g., carry lines and intermediate sums) to perform the 32-bit addition operation. Because the interconnect tiles are asynchronous, the synthesizer does not need to consider timing constraints and different clock domains when selecting CLEs and configuring the interconnect tiles to transfer data between the CLEs.

[0052] The disclosed technology can be expressed in several non-limiting examples. [Example 1] 1. An integrated circuit comprising: an array of circuit tiles comprising circuitry configured to perform data operations; interconnects coupling the circuit tiles in the array, the interconnects including interconnect tiles each having a plurality of connections, the plurality of connections including at least a first connection to a respective one of the circuit tiles and a plurality of connections to a plurality of other interconnect tiles; Integrated circuits are an integrated circuit comprising a plurality of local crossbars in each of said interconnect tiles, the plurality of local crossbars coupled to form a non-blocking crossbar.

[0053] [Example 2] 10. The integrated circuit of example 1, wherein the plurality of connections of each interconnect tile includes north, east, south, and west connections to north, east, south, and west interconnect tiles, respectively.

[0054] [Example 3] 10. The integrated circuit of example 1, wherein the plurality of connections of each interconnect tile includes connections to adjacent interconnect tiles and connections to non-adjacent interconnect tiles.

[0055] [Example 4] 10. The integrated circuit of example 1, wherein the plurality of local crossbars are configured to remove connections that reverse direction through non-blocking crossbars.

[0056] [Example 5] 10. The integrated circuit of example 1, wherein the plurality of local crossbars are configured to route all combinations of signals through the local crossbars only to any output pin but not to all output pin permutations.

[0057] [Example 6] 10. The integrated circuit of example 1, wherein each of the plurality of local crossbars comprises a handshake circuit for asynchronous communication between an input of the local crossbar and an output of the local crossbar.

[0058] [Example 7] 7. The integrated circuit of example 6, wherein the handshake circuitry enables fanout in each of a plurality of local crossbars, where one input signal can be output to multiple outputs of the local crossbar simultaneously.

[0059] [Example 8] 10. The integrated circuit of Example 1, wherein the array of circuit tiles comprises programmable logic of the integrated circuit.

[0060] [Example 9] 10. The integrated circuit of Example 1, further comprising a configuration memory configured to program the array of circuit tiles and interconnections.

[0061] [Example 10] 1. An integrated circuit comprising: an array of circuit tiles comprising circuitry configured to perform data operations; and interconnects coupling circuit tiles in the array, the interconnects including interconnect tiles each having a plurality of connections, the plurality of connections including at least a first connection to a respective one of the circuit tiles and a plurality of connections to a plurality of other interconnect tiles, the interconnect tiles connected to each other using a plurality of buses, and each of the interconnect tiles comprising a handshake circuit for asynchronous communication.

[0062] [Example 11] 1. A method comprising: receiving source code implemented in an integrated circuit comprising an array of circuit tiles communicatively coupled using a programmable interconnect and a plurality of interconnect tiles; Transforming the source code into a flow control graph; converting the flow control graph into a primitive graph comprising a plurality of predefined primitives, each of the predefined primitives comprising circuitry for performing at least a portion of the operations defined in the flow control graph; The method is: further comprising mapping the predefined primitives in the primitive graph to a plurality of circuit tiles, each of the plurality of circuit tiles comprising at least a multiplier and circuitry for performing one additional programmably selectable logic function; The method is: 10. A method comprising: implementing the source code in an integrated circuit by connecting a plurality of circuit tiles using a plurality of interconnect tiles.

[0063] [Example 12] Converting the flow control graph into a primitive graph includes mapping the operations defined in the flow control graph to predefined primitives, respectively; and 12. The method of example 11, comprising connecting predefined primitives.

[0064] [Example 13] 12. The method of example 11, wherein predefined primitives in the primitive graph are mapped to multiple circuit tiles in a one-to-one manner.

[0065] [Example 14] 12. The method of example 11, wherein each of the plurality of circuit tiles includes programmable logic configurable to implement any one of a plurality of predefined primitives.

[0066] [Example 15] 12. The method of Example 11, wherein the plurality of interconnect tiles each have a plurality of connections including at least a first connection to a respective one of the plurality of circuit tiles and a plurality of connections to a plurality of other interconnect tiles.

[0067] [Example 16] 16. The method of example 15, wherein the plurality of interconnected tiles transfers data using asynchronous communication.

[0068] [Example 17] 12. The method of example 11, wherein the predefined primitives map to operations in the source code.

[0069] [Example 18] 18. The method of Example 17, wherein the operations in the source code comprise at least one of an addition operation, a subtraction operation, and a multiplication operation.

[0070] [Example 19] 18. The method of Example 17, wherein the operations in the source code include at least one of an if statement and a when statement.

[0071] [Example 20] 20. The method of example 19, wherein a single instance of an if statement or a while statement in the source code is converted into a plurality of predefined primitives that are mapped to a plurality of circuit tiles of the plurality of circuit tiles.

[0072] While the forgoing is directed to specific embodiments, other and further embodiments may be devised without departing from the basic scope thereof, the scope of which is determined by the claims that follow.

Claims

1. 1. An integrated circuit comprising: an array of circuit tiles comprising circuitry configured to perform data operations; interconnects coupling the circuit tiles in the array; the interconnects include interconnect tiles each having a plurality of connections, the plurality of connections including at least a first connection to a respective one of the circuit tiles and a plurality of connections to a plurality of other interconnect tiles; The integrated circuit comprises: the integrated circuit further comprising a plurality of local crossbars included in each of the interconnect tiles, the plurality of local crossbars coupled to form a non-blocking crossbar, the plurality of local crossbars including a plurality of first local crossbars including north, east, south, and west connections to north, east, south, and west interconnect tiles, respectively, and a plurality of second local crossbars that route received signals in a first direction among north, east, south, and west to a second direction among north, east, south, and west, excluding the first direction.

2. The integrated circuit of claim 1 , wherein the plurality of connections of each interconnect tile includes connections to adjacent interconnect tiles and connections to non-adjacent interconnect tiles.

3. The integrated circuit of claim 1 , wherein the plurality of local crossbars are configured to eliminate connections that reverse direction through the non-blocking crossbars.

4. 2. The integrated circuit of claim 1, wherein the plurality of local crossbars are configured to route all combinations of signals through the local crossbars only to any output pin but not to all output pin permutations.

5. The integrated circuit of claim 1 , wherein each of the plurality of local crossbars comprises a handshake circuit for asynchronous communication between an input of the local crossbar and an output of the local crossbar.

6. 6. The integrated circuit of claim 5, wherein the handshake circuitry enables fanout in each of the local crossbars, where an input signal can be output to multiple outputs of the local crossbar simultaneously.

7. The integrated circuit of claim 1 , wherein the programmable logic of the integrated circuit comprises the array of circuit tiles.

8. The integrated circuit of claim 1 further comprising a configuration memory configured to program the array of circuit tiles and the interconnections.

9. 1. An integrated circuit comprising: an array of circuit tiles comprising circuitry configured to perform data operations; interconnects coupling the circuit tiles in the array; the interconnects include interconnect tiles each having a plurality of connections, the plurality of connections including at least a first connection to a respective one of the circuit tiles and a plurality of connections to a plurality of other interconnect tiles; the interconnect tiles are connected to one another using a plurality of buses; an integrated circuit, wherein each of the interconnect tiles comprises a plurality of local crossbars coupled to form a non-blocking crossbar, each comprising a handshake circuit for asynchronous communication, the plurality of local crossbars comprising: a plurality of first local crossbars including north, east, south, and west connections to north, east, south, and west interconnect tiles, respectively; and a plurality of second local crossbars that route received signals in a first direction among the north, east, south, and west to a second direction among the north, east, south, and west, excluding the first direction.

10. 1. A method comprising: receiving source code implemented in an integrated circuit comprising an array of circuit tiles communicatively coupled using a programmable interconnect and a plurality of interconnect tiles, each of the plurality of interconnect tiles comprising a plurality of local crossbars coupled to form a non-blocking crossbar, the plurality of local crossbars including a plurality of first local crossbars including north, east, south, and west connections to north, east, south, and west interconnect tiles, respectively, and a plurality of second local crossbars routing received signals in a first direction among north, east, south, and west to a second direction among north, east, south, and west, the second direction being excluding the first direction; Transforming the source code into a flow control graph; converting the flow control graph into a primitive graph comprising a plurality of predefined primitives; each of the predefined primitives includes circuitry for performing at least a portion of the operations defined in the flow control graph; The method comprises: further comprising mapping the predefined primitives in the primitive graph to the plurality of circuit tiles; each of the plurality of circuit tiles comprising at least a multiplier and circuitry for performing one additional programmably selectable logic function; The method comprises: implementing the source code in the integrated circuit by connecting the plurality of circuit tiles with the plurality of interconnect tiles.

11. Transforming the flow control graph into the primitive graph comprises: mapping each of the operations defined in the flow control graph to a predefined primitive; and The method of claim 10 , comprising connecting the predefined primitives.

12. The method of claim 10 , wherein the predefined primitives in the primitive graph are mapped to the plurality of circuit tiles in a one-to-one manner.

13. The method of claim 10 , wherein each of the plurality of circuit tiles comprises programmable logic configurable to implement any one of the plurality of predefined primitives.

Images