Patent Application
20230305842
At least some embodiments disclosed herein relate to configuring a computing device to execute instructions of a computer program in general and more particularly, but not limited to, configuring a computing device having circuit tiles for parallel execution.
Traditionally, assembly language programming is based on specifying operations to be performed on data stored in registers. A typical opcode is specified to identify an operation to be performed on data stored in one or more registers identified for the opcode; and the result of the operation is to be stored in a register identified for the opcode.
To execute such a traditional assembly language program, virtual registers referenced in the program are mapped to physical registers in a processor for execution of the program. When there are fewer physical registers than the virtual registers referenced in the program, values are shifted around among the physical registers to implement register reuse and satisfy the virtual register usages in the program.
The embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.
At least some embodiments disclosed herein provide techniques of configuring a coarse grained reconfigurable array to run an assembly language program specifying data flows through memory locations represented by memory variables.
Compute Near Memory (CNM) architecture can be used to leverage the dramatic opportunities provided by high performance communication protocols, such as the Compute Express Link (CXL) protocol. Such Compute Near Memory (CNM) architecture can incorporate heterogenous compute elements in a memory/storage subsystem to accelerate various computing tasks near data. An example of such compute elements is a Streaming Engine (SE) implemented via a Coarse Grained Reconfigurable Array (CGRA) having interconnected computing tiles. The tiles are interconnected with both a Synchronous Fabric (SF) and an Asynchronous Fabric (AF). The synchronous Fabric (SF) can be configured to connect each tile with neighboring tiles that are one or two clock cycles away. The Synchronous Fabric (SF) interconnects elements within each tile, such as tile memory, multiplexers, and Single Instruction Multiple Data (SIMD) units, etc. Tiles can be pipelined through Synchronous fabric (SF) to form a synchronous data flow (SDF) through the Single Instruction Multiple Data (SIMD) units for operations such as multiply/shift, add/logical operations, etc. Each tile can have a pipelined time-multiplexed processing unit such that a new instruction can start on each tile at every clock cycle. The asynchronous fabric (AF) connects a tile with other tiles, a dispatch interface (DI), and memory interfaces (MIs). The asynchronous fabric (AF) bridges synchronous data flows (SDF) through asynchronous operations, which include initiation of synchronous data flow, asynchronous data transfer from one synchronous data flow to another, system memory accesses, and branching and looping constructs. Each tile can have a delay register to hold its output for outputting with timing alignment with execution of an instruction that uses the output. Together, the Synchronous Fabric (SF) and Asynchronous Fabric (AF) allow the tiles to efficiently execute high-level programming language constructs. Simulation results of hand-crafted streaming engine (SE) kernels have shown orders-of-magnitude better performance per watt on data-intensive applications than existing computing platforms.
However, it is challenging to apply traditional compilation tools to program operations of a new architecture, such as Streaming Engine (SE) implemented using a Coarse Grained Reconfigurable Array (CGRA). In a dataflow based Coarse Grained Reconfigurable Array (CGRA), a program works by flowing data from one tile to another in a synchronous fashion. This requires instructions to be programmed at an exact cycle on the correct tile to avoid corrupting the synchronous flow of operations. Instead of morphing a dataflow to pretend it is a sequence of register transfers as in traditional assembly, at least some embodiments discussed in the present disclosure use a new assembly language with a corresponding parser that enables describing a program as a group of graphs that represent the data flows.
Configuring a Streaming Engine (SE) requires finding a synchronous schedule of instructions such that a flow can start for a data element and have every subsequent instruction line-up on a valid tile on the correct cycle. The assembly language of at least some embodiments discussed in the present disclosure is advantageous in the determination of such a synchronous schedule. It can be used to describe some of the configuration details of the hardware as well as the data flow of the computation.
In one embodiment, the assembly language is configured to describe the details of a program for a Streaming Engine (SE). For example, a dispatch interface (DI) block of the program can be configured to specify information about the dispatch interface of the Streaming Engine (SE); a memory interface (MI) block can be configured to specify information about memory operations implemented via memory interfaces of the Streaming Engine (SE); a tile memory (TM) block can be configured to specify information about memory variables to be mapped to tile memories of the Streaming Engine (SE); and a flows block can be configured to specify a group of graphs representative of the synchronous data flows.
Optionally, a user describes the computation to be performed by a Streaming Engine (SE) in terms of configuration details specified using the dispatch interface (DI) block, the memory interface (MI) block, and tile memory (TM) block, and the program details via the flows block. Such an assembly language program can be parsed, mapped, and lowered by a software tool into a program execution configuration of the Streaming Engine in running the assembly language program.
Optionally, a compiler can be used to automate the conversion of a computer program written in a high-level programming language to the assembly language program according to the present disclosure.
The disclosed techniques of assembly language programs have various advantages. For example, representing configuration and data flow allows the assembly to reflect the device state. For example, programming data flows allows a programmer to work in terms of how data is moving between operations instead of how to schedule the hardware details between tiles. For example, breaking code into separate synchronous flows allows the programmer to explicitly define the asynchronous messaging that happens between synchronous elements. For example, programming the device at the abstract representation of assembly language is much faster than working at the low-level details of specifying operations of the multiplexers and tile connections. For example, a parser can provide friendlier error messaging for typos and inconsistent logic instead of debugging why the device simulation didn't terminate or provided incorrect answers. For example, defining an assembly language opens future possibilities of leveraging mainstream compiler tools to compile high level code down to this more abstract description of the device. For example, since programs are lists of instructions, high and low-level knobs can be provided to the programmer through instruction representation. For example, a low-level type of instruction allows the programmer to specify individual fields/opcodes that end up in the instruction; or, a high-level format in terms of operations instead of fields can be used.
An assembly language program describing data flows can be mapped for execution on a specific Coarse Grained Reconfigurable Array (CGRA). The Coarse Grained Reconfigurable Array (CGRA) can have a particular structure, e.g., a number of tiles and memory interfaces, and particular inter-connectivity of Synchronous Fabric (SF) and/or Asynchronous Fabric (AF) among the tiles. Such a particular structure can be specific to the Coarse Grained Reconfigurable Array (CGRA) that is to be used in execution of the program and thus not reflected in the assembly language program. On the other hand, the assembly language program is shielded from such details and thus can be mapped for execution on different Coarse Grained Reconfigurable Array (CGRA) having different structural details.
A scheduler can map the instructions of the assembly language program for execution in tiles of a Coarse Grained Reconfigurable Array (CGRA). Since each tile can have a pipelined time-multiplexed processing unit, a new instruction can start on each tile at every clock cycle. Thus, the scheduler can generate a schedule specifying which instruction is programmed on which tile for execution at which clock cycle. The scheduler can determine the tiles and clock cycles of the instructions being mapped in a correct combination such that the data flows in the Coarse Grained Reconfigurable Array (CGRA) propagate with proper timing. For example, outputs of tiles are produced at proper clock cycles to be provided in time, through the Synchronous Fabric (SF), and/or the Asynchronous Fabric (AF), as inputs for further processing in the tiles. As the instructions are mapped to the tiles, the memory variables used by the instructions are also mapped to memories in the tiles.
Based on the schedule of the instructions for execution in the tiles, a software tool (e.g., a lowering program) can be configured to generate an execution configuration of the Coarse Grained Reconfigurable Array for running the assembly language program. The software tool can determine the details on how to configure each connection between tiles. The software tool can determine the low-level details of dividing the tile memory into regions to implement the memory variables mapped to the tiles. The software tool can determine the settings of the correct multiplexer bits in the tiles to ensure data flows correctly at correct clock cycle within the tiles. The entire program can break/corrupt for having even one missing bit. The details determined by the software tool can be specified in the execution configuration to control the execution of the assembly language program in the Coarse Grained Reconfigurable Array (CGRA).
For example, according to the assembly language program and the schedule, the software tool can walk the dataflow graph to trace which operations will be the master control of the successor operations. As it traces the graph, it can set the outgoing control for the current tile operation; and as it traverses to a child, it can set the incoming control information on the cycle it arrives. Control setting can also be determined and set for data passing through routes used on the tiles as well as delay registers.
The software tool can also use the dispatch interface information and the memory interface information provided in the assembly language program to configure operations of the dispatch interface and memory interfaces of the Coarse Grained Reconfigurable Array (CGRA). The assembly language program specifies high-level details about the messaging generated by the dispatch interface and memory interfaces. Using the schedule the software tool can identify the messaging in terms of physical hardware locations in the Coarse Grained Reconfigurable Array (CGRA).
The software tool has various advantages. Manual generating the execution configuration of a Coarse Grained Reconfigurable Array (CGRA) is a monotonous, laborious, error-prone process that can take dozens of man-hours for even simple problems. The software tool automates the work to allow easy verification of hardware constraints. If hardware timing details change, the software tool can rerun with changes in parameters to generate a new execution configuration. The design of such a software tool configured to receive the schedule generated by a scheduler as an input allows the offload many hardware details out of the scheduler, such that implementation of different mapping strategies for the scheduler can focus on instruction placement.
In
The dispatch interface information 111 identifies memory variables to accept arguments to be passed as input to the assembly language program 101, and data properties of the arguments. The dispatch interface information 111 can further specify the data proprieties of return value of the assembly language program 101. The dispatch interface information 111 can be used to configure the dispatch interface of a coarse grained reconfigurable array (CGRA) 103 used to implement the assembly language program 101. To execute the assembly language program 101, the memory variables identified in the dispatch interface information 111 are mapped to the tile memories in the coarse grained reconfigurable array (CGRA) 103. Thus, the dispatch interface information 111 specifies the operations of the dispatch interface to store input data to memory locations represented by the memory variables.
The memory interface information 113 identifies memory access operations that are performed in the flow description 117 to access tile memories in the coarse grained reconfigurable array (CGRA) 103. The memory access operations can include operations to store data into memory variables that are used in the flow description 117, and operations to read data from memory variables that are used in the flow description 117. To execute the assembly language program 101, the memory variables identified in the memory interface information are mapped to the tile memories in the coarse grained reconfigurable array (CGRA) 103.
The tile memory information 115 identifies memory variables used in the flow description 117 and access properties of the memory variables. Such memory variables can include the memory variables identified in the dispatch interface information 111 to store arguments or inputs to the assembly language program 101, the memory variables identified in the memory interface information 113, and other memory variables that can be used in synchronous operations of data flows in the flow description 117.
The flow description 117 specifies one or more data flow graphs. Each data flow graph identifies a synchronous flow of data through memory variables mapped to tile memories and synchronous values mapped to connections between tiles; and each data flow graph further identifies the computations (e.g., add, multiplication, bitwise shift, etc.) performed on those values on the tile data path. For example, some memory variables can be identified in dispatch interface information 111, memory interface information 113, tile memory information 115 for synchronous use (e.g., FIFO) or asynchronous use (e.g., dispatch/memory interface) of tile memories and thus for mapping to tile memories in implementations; additional variables can be used in the flow description 117 that may or may not be mapped to tile memories in implementations. For example, a synchronous value used through a FIFO in the flow description 117 is mapped to a tile memory; some variables in the flow description 117 can be mapped to tile memories using a FIFO to satisfy timing requirements in scheduling instructions for execution on tiles of the coarse grained reconfigurable array (CGRA) 103; and it is not necessary to map some variables in the flow description 117 to tile memories. The data flow graph can include identification of memory access operations specified in the memory interface information 113. The memory access operations specified in the memory interface information 113 are implemented via communications over asynchronous fabric (AF) in the coarse grained reconfigurable array (CGRA) 103. In one embodiment, the flow description 117 can have multiple segments, each specifying one data flow. Each data flow can optionally include the identification of a set of asynchronous variables specified in the dispatch interface information 111, the memory interface information 113, and the tile memory information 115. The instructions of a data flow can start execution upon receiving messages indicating the readiness of the data identified by the set of asynchronous variables. Each data flow can be programmed to send an asynchronous message to another data flow (e.g., to start execution of a loop, to continue a flow, to send a data value, etc.). Each data flow may stop with one or more instructions outputting results into asynchronous variables specified in the dispatch interface information 111, the memory interface information 113, and the tile memory information 115. New identifications of data/variables can be used in each data flow to represent data generated within the data flow. Such new variables used within each data flow are transient, since the data represented by the variables are consumed within the data flow and discarded after the execution of the data flow. Thus, asynchronous variable/data in the program 101 refers to the data being stored into a location/variable for use at an unspecified/unknown time when the data is needed; and there is no hardware imposed limitation on the time period between data arrival and data use; in contrast, synchronous variable/data refers to the data being generated for use at a time determined by a synchronous connection in the coarse grained reconfigurable array (CGRA) 103. The instructions in a data flow may not be connected based on the sequence of the instructions written in the flow description. Some instructions are tied to each other based on the data being consumed as input and data being generated as output that may be consumed synchronously, or propagated asynchronously.
Further details about the coarse grained reconfigurable array 103, the dispatch interface information 111, the memory interface information 113, and the tile memory information 115 are provided below in connection with
In
Alternatively, the user can write the assembly language program 101 without using a compiler (e.g., 107). For example, a programming/compilation tool can be adapted to receive user inputs to specify the assembly language program 101.
For example, the assembly language program 101 of
In
A typical tile 141 includes tile memories 131, . . . , 133 having synchronous connections 135 with a computing logic 137. The computing logic 137 can be configurable to execute different instructions. For example, the computing logic 137 can include a Single Instruction Multiple Data (SIMD) unit. Upon receiving a single instruction, the Single Instruction Multiple Data (SIMD) unit can operate on multiple data items in the tile memories 131, . . . , 133. For example, the computing logic 137 can include a pipelined time-multiplexed processing unit that can start execution of a new instruction at every clock cycle. Execution of an instruction can complete after a predetermined number of clock cycles. Results of executing instructions can propagate from one tile (e.g., 141) to a neighboring tile (e.g., 143) via synchronous connections 129 in a predetermined number of clock cycles. Results of executing instructions can also be accessed through memory interfaces (e.g., 123, . . . , 125, and dispatch interface 121) via asynchronous connections 127.
The coarse grained reconfigurable array 103 has synchronous connections 129 among some pairs of the tiles 141, 143, . . . , 145. For example, the synchronous connections 129 offer a direct connection between tile 141 and tile 143, but no direct connection between tile 143 and tile 145. For example, the synchronous connections 129 can connect neighboring tiles (e.g., 141, 143) to form a chain or pipeline among the tiles 141, 143, . . . , 145.
The coarse grained reconfigurable array 103 has asynchronous connections 127 between the tiles 141, 143, . . . , 145 and memory interfaces 123, . . . , 125 and a dispatch interface 121. The dispatch interface 121 can function as a memory interface. Each memory interface (e.g., 123 or dispatch interface 121) can access the tile memories of one or more tiles through the asynchronous connections 127. Each of the tiles 141, 143, . . . , 145 can have a delay register controllable to provide output of the tile for synchronization with the timing of the execution of a next instruction that uses the output. The dispatch interface 121 can communicate inputs and outputs of the coarse grained reconfigurable array 103 from or to a circuit external to the coarse grained reconfigurable array 103.
The assembly language program 101 of
With the details of the coarse grained reconfigurable array 103, the assembly language program 101 of
The operations of the Coarse Grained Reconfigurable Array 103 can be described and/or scheduled as flows of data among tile memories (e.g., 131, . . . , 133) of tiles (e.g., 141, 143, . . . , 145) through the connections 135, 129, and 127 and the computing logic 137 at various clock cycles. Since the flow description 117 describes the required data flows for the operations of the assembly language program 101, the data flows identified by the flow description 117 can be mapped to the data flows in the Coarse Grained Reconfigurable Array 103 for execution.
For example, the dispatch interface information 111 of
The assembly language program 101 of
The storing of the input data to the memory locations represented by the memory variables 153, . . . , 163 can be implemented via the operations of the dispatch interface 121 of the Coarse Grained Reconfigurable Array 103.
The dispatch interface information 111 can further specify the return value property 159 of the assembly language program 101. For example, the return value property 159 can specify the data type and/or a data size of the value to be returned by the assembly language program 101 upon completion of execution of the assembly language program 101.
For example, the memory interface information 113 of
The memory interface information 113 identifies a plurality of memory access operations 173, . . . , 183. Each memory access operation (e.g., 173 or 183) can be an operation to store data into memory or read data from memory, where the memory location is represented by a memory variable (e.g., 175 or 185) having a corresponding memory property (e.g., 177 or 187) for the data stored or accessed at the memory location. The memory access operations (e.g., 173 or 183) can be implemented via the operations of the memory interfaces 123, . . . , 125 and/or the dispatch interface 121 of the Coarse Grained Reconfigurable Array 103.
The memory access operations (e.g., 173 or 183) are associated with access IDs (e.g., 171 or 181) in the memory interface information 113 to represent the corresponding memory access operations (e.g., 173 or 183). The flow description 117 of the assembly language program 101 can use the access IDs (e.g., 171 or 181) to specify the uses of the respective memory access operations (e.g., 173 or 183) in the data flow graphs.
A memory property (e.g., 177 or 187) can identify a data type and/or a data size of the data to be operated upon via the memory access operation (e.g., 173 or 183).
For example, the tile memory information 115 of
The tile memory information 115 identifies the properties (e.g., 157, . . . , 167, 179, . . . , 189, 193, . . . ) of the respective memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ) used in the flow description 117 to identify memory locations in tiles of a Coarse Grained Reconfigurable Array 103. To execute the assembly language program 101, the memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ) are mapped to tile memories (e.g., 131, . . . , 133) of tiles (e.g., 141, 143, . . . , 145) of the Coarse Grained Reconfigurable Array 103.
The properties (e.g., 157, . . . , 167, 179, . . . , 189, 193, . . . ) can identify the memory access types, sizes, etc. of the respective memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ). Examples of memory access type can include unknown, shared, first in first out (FIFO), etc.
The memory variables specified in the tile memory information 115 can include memory variables (e.g., 153, . . . , 163) identified in the dispatch interface information 111, memory variables (e.g., 175, . . . , 185) identified in the memory interface information 113, and other memory variables used in the flow description 117 to identify memory locations of data flows. The flow description 117 further identifies operations perform to transform the data along the flows.
For example, the method of
At block 201, the user, compiler, and/or compilation/programming tool identifies dispatch interface information 111 representing operations to be performed via a dispatch interface 121 of a coarse grained reconfigurable array 103 to receive an input.
For example, the coarse grained reconfigurable array 103 can have a plurality of tiles 141, 143, . . . , 145 interconnected via synchronous connections 129 and 135 and asynchronous connections 127. Each of the tiles (e.g., 141) has tile memories (e.g., 131, . . . , 133) and a reconfigurable computing logic (e.g., 137). In response to an instruction, the computing logic 137 can be reconfigured to perform the operation of the instruction in the flow of data from one memory location to another in the coarse grained reconfigurable array 103.
For example, the dispatch interface information 111 can include identification of first memory variables 153, . . . , 163 for arguments 161, . . . , 161 respectively to indicate the operations of writing the input according to the arguments to the memory locations represented by the first memory variables 153, . . . , 163.
At block 203, the user, compiler, and/or compilation/programming tool identifies memory interface information 113 representing operations to be performed via one or more memory interfaces of the coarse grained reconfigurable array.
For example, the memory interface information 113 can include identification of second memory variables 175, . . . , 185 associated with memory access operations 173, . . . , 183 for storing or retrieving data items to or from memory locations referred to and represented by the second memory variables 175, . . . , 185.
The memory interface information 113 and the dispatch interface information 111 can include the types and sizes of data items identified by memory variables (e.g., 153, 163, 175, 185) and operated upon in the respective memory access operations (e.g., 173, 183, or storing inputs according to the arguments 151, . . . , 161).
At block 205, the user, compiler, and/or compilation/programming tool identifies tile memory information 115 about a set of memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ) referring to memory locations to be implemented in tile memories (e.g., 131, 133) of the coarse grained reconfigurable array 103.
The tile memory information 115 can further identify access types and sizes of the set of memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ) for implementation in the coarse grained reconfigurable array. The set of memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ) can include the first memory variables (e.g., 153, . . . , 163) identified in the dispatch interface information 111, the second memory variables (e.g., 175, . . . , 185) identified in the memory interface information 113, and at least one third memory variable 191 referring to a memory location in one or more synchronous data flows to be implemented via the coarse grained reconfigurable array 103.
At block 207, the user, compiler, and/or compilation/programming tool identifies one or more synchronous data flows, through memory locations referenced via the memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ) in the tile memory information 115, to produce a result from the input. Data can be transformed via execution of instructions along the flows; and the data flows can go through other variables that do not have to be mapped to tile memories.
At block 209, the user, compiler, and/or compilation/programming tool generates an assembly language program 101 containing the dispatch interface information 111, the memory interface information 113, the tile memory information 115, and a flow description 117 specifying the one or more data flows.
For example, a compiler 107 can be configured to compile a computer program 105 written in a high-level language to generate the assembly language program 101.
Alternatively, a compilation/programming tool can be configured to present a user interface to receive user inputs to identify the dispatch interface information 111, the memory interface information 113, the tile memory information 115, and the one or more data flows, etc. Based on the user inputs, the compilation/programming tool can check for errors and generate the assembly language program 101.
Optionally, a compiler and/or a compilation/programming tool can be further configured to map the one or more data flows specified in the assembly language program 101 to flows of data in the coarse grained reconfigurable array 103, including mapping the set of memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ) to tile memories (e.g., 131, 133) in the coarse grained reconfigurable array 103.
For example, the instruction execution schedule 223 can be generated from the assembly language program 101 of
The assembly language program 101 of
A hardware profile 239 can identify the high level structural features of a coarse grained reconfigurable array 103 to be used to run the assembly language program 101. Such high level structural features can specify to the coarse grained reconfigurable array 103 among possible implementations of coarse grained reconfigurable array. For example, the high level structural features can specify the number of tiles (141, 143, . . . , 145), the number of memory interfaces (e.g., 123, . . . , 125), the connection topologies in the synchronous connections and asynchronous connections 127, numbers of clock cycle delays in the synchronous connections and asynchronous connections 127, etc., in the coarse grained reconfigurable array 103.
The hardware profile 239 has sufficient details to allow a scheduler to map instructions (e.g., 233, 243) in the data flows of the assembly language program 101 into tiles 141, 143, . . . , 145 for execution at proper time instances represented by identification of cycles (e.g., 231, 241).
For best performance, the scheduler 221 can map instructions into different tiles 141, 143, . . . , 145 for execution. Although it is possible to map all instructions of the assembly language program 101 to a single tile (e.g., 143 or 141) for execution, such a schedule is inefficient in failing to utilize the resources in remaining tiles (e.g., 145). The scheduler 221 is configured to distribute instructions to different tiles 141, 143, . . . , 145 for parallel execution for improved performance and a reduced or minimized number clock cycles to complete the computation of the assembly language program 101.
For example, the scheduler 221 can distribute instructions of different data flows to different tiles. For example, the scheduler 221 can try to place a next instruction to be placed in different tiles and identify a placement that results in a best performance for execution up to the next instruction.
In placing the instructions (e.g., 233, . . . , 243), the scheduler 221 also identifies the clock cycle (e.g., 231, . . . , 241) for the initiation of the execution of the instructions (e.g., 233, . . . , 243) in the tiles (e.g., 141, 143, . . . , 145).
In general, the instruction execution schedule 223 can include a sequence of instruction placement for each of the tiles 141, 143, . . . , 145. For example, a typical tile 141 is assigned to execute instructions 233, . . . , 243 respectively at the clock cycles 231, . . . , 241. The scheduler 221 identifies the cycles 231 . . . , 241 such that the outputs of computations can be used in correct cycles as inputs to subsequent computations. Thus, the data can flow in and among the tiles 141, 143, . . . , 145 for synchronous operations.
Further, the hardware profile 239 allows the scheduler 221 to map the memory variables in the assembly language program 101 into the tiles 141, 143, . . . , 145 for implementation via tile memories (e.g., 131, . . . , 133), as illustrated in
In
For example, in a typical tile 141, memory variables 153, . . . , 175 of the assembly language program 101 are mapped in the memory map 225 for implementation via tile memories 131, . . . , 133 of the tile 141. Other memory variables of the assembly language program 101 are mapped to other tiles (e.g., 143, . . . , 145).
When the data stored in a variable (e.g., 153) is mapped to a tile (e.g., 141) for implementation using its tile memory (e.g., 131 or 133), it is typically efficient to map the instructions operating on the data to the same tile (e.g., 141), since accessing the data via connections between tiles can take a longer time than accessing within the tile. Thus, the generation of the memory map 225 and the generation of the instruction execution schedule 223 can be performed together to identify a high performance schedule 223.
Certain hardware details can be excluded from the hardware profile 239 to allow the scheduler 221 to focus on the operation of instruction placement in the tiles 141, 143, . . . , 145. Thus, the scheduler 223 does not determine low level details of configuring the coarse grained reconfigurable array 103 for running the assembly language program 101 according to the schedule 223. Such low level details can include how the dispatch interface 121 and the memory interfaces 123, . . . , 125 are configured for the operations of the assembly language program 101, how the memory locations represented by the memory variables (e.g., 153, 175) are implemented via tile memories (e.g., 131, 133), how the connections (e.g., 135) in the tiles (e.g., 141) are configured to facilitate the correct data flows within the tiles (e.g., 141, 143, . . . , 145), etc. A more detailed hardware profile can be used to generate the configuration to execute the assembly language program 101, as illustrated in
In
A configuration generator 229 can use the hardware profile 249 to determine an execution configuration 227 for an assembly language program 101 having a memory map 225 and an instruction execution schedule 223.
The execution configuration 227 has detailed information on how to control and/or use the elements of the coarse grained reconfigurable array 103 to run the assembly language program 101.
For example, the memory map 225 specifies which tile (e.g., 141) of the coarse grained reconfigurable array 103 is used to implement the memory represented by a memory variable (e.g., 153). The configuration generator 229 can further determine, for the execution configuration 227, which portion of tile memories (e.g., 131) in the tile (e.g., 141) is used for the memory represented by the memory variable (e.g., 153).
For example, the instruction execution schedule 223 identifies which instruction (e.g., 233) is scheduled to be initiated for execution on which tile (e.g., 141) at which clock cycle (e.g., 231). The configuration generator 229 can further determine the connectivity control 236 for the configuration of the connections 135 in the tile (e.g., 141) to ensure proper flow of data in the tile (e.g., 141) for the execution of the instruction. For example, the connections 135 in the tile (e.g., 141) can be configured via controlling bits for multiplexers in the connections 135; and the connectivity control 236 can identify the controlling bits.
For example, the dispatch interface information 111 of the assembly language program 101 specifies how the dispatch interface 121 is to store inputs received as arguments 151, . . . , 161. After the determination of how the memory variables 153, . . . , 163 associated with the arguments 151, . . . , 161 are implemented using which tile memories (e.g., 131, . . . 133) in which tiles (e.g., 141, 143, . . . , 145), the configuration generator 229 can further determine the operation control 237 of the dispatch interface 121 to process inputs.
Similarly, after the determination of the tile memory implementations of the memory variables 175, . . . , 185 identified in the memory interface information 113 of the assembly language program 101, the configuration generator 229 can further determine the operation control (e.g., 247) of the memory interfaces (e.g., 123, . . . , 125) to process memory access operations 173, . . . , 183 identified in the flow description 117 using their access IDs 171, . . . , 181.
For example, the configuration generator 229 can trace the data flows specified in the flow description 117 of the assembly language program 101 and implemented according to the instruction execution schedule 223. When the tracking detects data flowing into a tile (e.g., 141) at a clock cycle 231, the configuration generator 229 identifies the incoming control 235 to be applied to facilitate data flowing into the tile 141; and When the tracking detects data flowing out of the tile 141 at the clock cycle 241, the configuration generator 229 identifies the outgoing control 245 to be applied the tile 141 to facilitate data flowing out of the tile 141 (e.g., the timing control of the delay register of the tile 141).
When the coarse grained reconfigurable array 103 is controlled and/or used according to the execution configuration 227, the coarse grained reconfigurable array 103 can run instructions of the assembly language program 101 according to the instruction execution schedule 223 to implement the computation as specified in the assembly language program 101.
For example, the method of
At block 251, the configuration generator 229 receives an assembly language program 101 identifying data flows through memory locations represented by memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ) and identifying instructions configured to transform data in the data flows (e.g., as specified in a flow description 117).
At block 253, the configuration generator 229 further receives a hardware profile 249 identifying details of a coarse grained reconfigurable array 103 having a plurality of tiles 141, 143, . . . , 145 operable in parallel.
For example, the coarse grained reconfigurable array 103 can include a plurality of memory interfaces (e.g., 123). One of the memory interfaces can be configured/used as a dispatch interface 121. The coarse grained reconfigurable array 103 has the plurality of tiles 141, 143, . . . , 145 interconnected via synchronous connections 127 and asynchronous connections 129. Each of the tiles can have tile memories (e.g., 131, . . . , 133) and a reconfigurable computing logic 137.
At block 255, the configuration generator 229 further receives an instruction execution schedule 223 identifying timing of execution of the instructions of the assembly language program 101 in the tiles 141, 143, . . . , 145.
At block 257, the configuration generator 229 identifies memories (e.g., 131, . . . , 133) in the tiles (e.g., 141, 143, . . . , 145) configured to be used to implement the memory locations represented by the memory variables (e.g., 153, . . . , 163, 175, . . . , 185, 191, . . . ).
At block 259, the configuration generator 229 generates an execution configuration 227 identifying operation controls (e.g., 235, 245, 236, 237, 247) to be applied in the coarse grained reconfigurable array 103 during execution of the instructions of the assembly language program 101.
For example, the assembly language program 101 includes dispatch interface information 111 representing operations to be performed to store inputs into first memory locations represented by first memory variables (153, . . . , 163). After identifying the tile memories used to implement the first memory locations, the configuration generator 229 can identify, based on the dispatch interface information 111, operating controls 237 of the dispatch interface 121 of the coarse grained reconfigurable array 103 to store the inputs to tile memories identified to implement the first memory locations.
For example, the assembly language program 101 includes memory interface information 113 representing operations to be performed to store or retrieve data at or from second memory locations represented by second memory variables (175, . . . , 185). After identifying the tile memories used to implement the second memory locations, the configuration generator 229 can identify, based on the memory interface information 113, operating controls 247 of the memory interfaces (e.g., 123 or 125) of the coarse grained reconfigurable array 103 to store or retrieve data at or from tile memories identified to implement the second memory locations.
For example, the assembly language program 101 has a flow description 117 specifying the data flows. The configuration generator 229 can trace the data flows in connection with identification of the timing of execution of the instructions to identify timing of controls (e.g., 235, 245, 236, 237, 247) to be applied in the tiles during execution of the assembly language program 101.
For example, during the tracing of the data flows, the configuration generator 229 can detect an instance of data flowing into a first tile (e.g., 141) of the coarse grained reconfigurable array 103. In response, the configuration generator 229 can identify incoming controls 235 to be applied to the first tile 141 and the timing (e.g., cycle 231) of the incoming control 235 during execution of the assembly language program 101 in the coarse grained reconfigurable array 103.
For example, during the tracing of the data flows, the configuration generator 229 can detect an instance of data flowing out of the first tile 141 of the coarse grained reconfigurable array 103. In response, the configuration generator 229 can identify outgoing controls 245 to be applied to the first tile 141 and timing (e.g., cycle 241) of the outgoing controls during the execution of the assembly language program 101 in the coarse grained reconfigurable array 103.
For example, during the tracing of the data flows with tiles, the configuration generator 229 can identify connectivity controls 236 of the tiles 141, 143, . . . , 145 for data flowing within the tiles according to the instruction execution schedule 223. For example, each respective tile (e.g., 141) among the tiles has internal connections 135 between tile memories 131, . . . , 133 and a computing logic 137. After the determination of the tile memories implementing the memory variables in the assembly language program 101, the configuration generator 229 can determine the connectivity among the tile memories (e.g., 131, . . . , 133) and the computing logic 137 to facilitate the data flows within the tiles (e.g., 141). The internal connections 135 can include multiplexers to control data paths; and the connectivity controls 236 can include setting bits to control the multiplexers to implement the data flows.
After the determination of the execution configuration 227, the coarse grained reconfigurable array 103 can be controlled according to the content of the execution configuration 227 during execution of the instructions of the assembly language program 101 according to the instruction execution schedule 223. The use of the execution configuration 227 ensures the correct operation configuration for running the assembly language program 101. Different schedules (e.g., 223) of the assembly language program 101 as input to the configuration generator 229 can result in different configurations (e.g., 227).
The computer system of
In some embodiments, the machine can be connected (e.g., networked) to other machines in a Local Area Network (LAN), an intranet, an extranet, and/or the Internet. The machine can operate in the capacity of a server or a client machine in client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.
For example, the machine can be configured as a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
The example computer system illustrated in
The processing device 302 in
The computer system of
The data storage system 318 can include a machine-readable medium 324 (also known as a computer-readable medium) on which is stored one or more sets of instructions 326 or software embodying any one or more of the methodologies or functions described herein. The instructions 326 can also reside, completely or at least partially, within the main memory 304 and/or within the processing device 302 during execution thereof by the computer system, the main memory 304 and the processing device 302 also constituting machine-readable storage media.
In one embodiment, the instructions 326 include instructions to implement functionality corresponding to a configuration generator 303, such as the configuration generator 229 for an assembly language program 101 described with reference to
The present disclosure includes methods and apparatuses which perform the methods described above, including data processing systems which perform these methods, and computer readable media containing instructions which when executed on data processing systems cause the systems to perform these methods.
A typical data processing system may include an inter-connect (e.g., bus and system core logic), which interconnects a microprocessor(s) and memory. The microprocessor is typically coupled to cache memory.
The inter-connect interconnects the microprocessor(s) and the memory together and also interconnects them to input/output (I/O) device(s) via I/O controller(s). I/O devices may include a display device and/or peripheral devices, such as mice, keyboards, modems, network interfaces, printers, scanners, video cameras and other devices known in the art. In one embodiment, when the data processing system is a server system, some of the I/O devices, such as printers, scanners, mice, and/or keyboards, are optional.
The inter-connect can include one or more buses connected to one another through various bridges, controllers and/or adapters. In one embodiment the I/O controllers include a USB (Universal Serial Bus) adapter for controlling USB peripherals, and/or an IEEE-2394 bus adapter for controlling IEEE-2394 peripherals.
The memory may include one or more of: ROM (Read Only Memory), volatile RAM (Random Access Memory), and non-volatile memory, such as hard drive, flash memory, etc.
Volatile RAM is typically implemented as dynamic RAM (DRAM) which requires power continually in order to refresh or maintain the data in the memory. Non-volatile memory is typically a magnetic hard drive, a magnetic optical drive, an optical drive (e.g., a DVD RAM), or other type of memory system which maintains data even after power is removed from the system. The non-volatile memory may also be a random access memory.
The non-volatile memory can be a local device coupled directly to the rest of the components in the data processing system. A non-volatile memory that is remote from the system, such as a network storage device coupled to the data processing system through a network interface such as a modem or Ethernet interface, can also be used.
In the present disclosure, some functions and operations are described as being performed by or caused by software code to simplify description. However, such expressions are also used to specify that the functions result from execution of the code/instructions by a processor, such as a microprocessor.
Alternatively, or in combination, the functions and operations as described here can be implemented using special purpose circuitry, with or without software instructions, such as using Application-Specific Integrated Circuit (ASIC) or Field-Programmable Gate Array (FPGA). Embodiments can be implemented using hardwired circuitry without software instructions, or in combination with software instructions. Thus, the techniques are limited neither to any specific combination of hardware circuitry and software, nor to any particular source for the instructions executed by the data processing system.
While one embodiment can be implemented in fully functioning computers and computer systems, various embodiments are capable of being distributed as a computing product in a variety of forms and are capable of being applied regardless of the particular type of machine or computer-readable media used to actually effect the distribution.
At least some aspects disclosed can be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.
Routines executed to implement the embodiments may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as “computer programs.” The computer programs typically include one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects.
A machine readable medium can be used to store software and data which when executed by a data processing system causes the system to perform various methods. The executable software and data may be stored in various places including for example ROM, volatile RAM, non-volatile memory and/or cache. Portions of this software and/or data may be stored in any one of these storage devices. Further, the data and instructions can be obtained from centralized servers or peer to peer networks. Different portions of the data and instructions can be obtained from different centralized servers and/or peer to peer networks at different times and in different communication sessions or in a same communication session. The data and instructions can be obtained in entirety prior to the execution of the applications. Alternatively, portions of the data and instructions can be obtained dynamically, just in time, when needed for execution. Thus, it is not required that the data and instructions be on a machine readable medium in entirety at a particular instance of time.
Examples of computer-readable media include but are not limited to non-transitory, recordable and non-recordable type media such as volatile and non-volatile memory devices, Read Only Memory (ROM), Random Access Memory (RAM), flash memory devices, floppy and other removable disks, magnetic disk storage media, optical storage media (e.g., Compact Disk Read-Only Memory (CD ROM), Digital Versatile Disks (DVDs), etc.), among others. The computer-readable media may store the instructions.
The instructions may also be embodied in digital and analog communication links for electrical, optical, acoustical or other forms of propagated signals, such as carrier waves, infrared signals, digital signals, etc. However, propagated signals, such as carrier waves, infrared signals, digital signals, etc. are not tangible machine readable medium and are not configured to store instructions.
In general, a machine readable medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.).
In various embodiments, hardwired circuitry may be used in combination with software instructions to implement the techniques. Thus, the techniques are neither limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system.
The above description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding. However, in certain instances, well known or conventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure are not necessarily references to the same embodiment; and, such references mean at least one.
In the foregoing specification, the disclosure has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
