CTMA, a coarse-grained reconfigurable architecture oriented towards context switching, and its operation method

Abstract

This invention proposes a coarse-grained reconfigurable architecture (CTMA) for context switching and its operation method. The coarse-grained reconfigurable architecture (CTMA) includes: an independent routing network, a CTMA command receiver module, and a global CTMA controller module. The global CTMA controller module iteratively generates cross-tile memory access commands for each operation and sends them to the corresponding tiles via a chain bus that sequentially connects each tile. The CTMA command receiver module registers incoming CTMA commands, checks the routing validity between received CTMA commands and existing CTMA commands, handles conflicts, and locally caches CTMA commands. The independent routing network directly executes cross-tile memory access under the control of locally cached CTMA commands. The experimental task of this invention can directly access the memory distribution before the context switch after the context switch, without data migration, avoiding the negative impact of dynamic resource allocation on task throughput.

Description

Technical Field

[0001] This invention relates to a coarse-grained reconfigurable architecture CTMA for context switching and its operation method, belonging to the field of dynamic resource allocation technology. Background Technology

[0002] Highly evolving industries such as automotive, aerospace, and medical all demand high performance and energy efficiency from embedded coprocessors, but cannot afford the non-recurring engineering (NRE) costs associated with ASIC implementations. FPGAs are adaptable to emerging applications, but their overly fine-grained reconfigurability limits frequency and power. As a natural trade-off between ASICs and FPGAs, coarse-grained reconfigurable architectures (CGRAs) offer near-ASIC performance and energy efficiency while providing a reconfiguration granularity suitable for computing applications, thus attracting widespread attention from industry and academia.

[0003] Early research focused on compiling and executing single tasks across the entire CGRA. However, real-world embedded environments are rife with mixed workloads. For example, machine learning (ML)-based face detection in access control systems might consist of multiple data-dependent tasks that share the entire CGRA and are executed in a pipelined manner. Automotive electronic control units (ECS) can also process independent tasks in parallel from data generated by entertainment videos, audio, and sensors around the vehicle. Therefore, how to efficiently execute multiple tasks on the CGRA has been a focus of much research. Dynamic resource allocation (DRA) has emerged as a technological trend to improve CGRA resource utilization, as multiple tasks have different resource requirements at different stages of their lifecycle. More specifically, higher-priority tasks can dynamically absorb resources from other tasks during the build process. Many input-sensitive tasks, such as pollution, power grid, and traffic monitoring systems, can dynamically request more resources during peak periods. The significant resources released by task destruction can be dynamically reused by other tasks.

[0004] However, after performing DRA in an embedded CGRA architecture, all data stored in the previously allocated CGRATiles becomes incompatible with the newly allocated CGRATiles, requiring context switching to resolve this. Data migration is a state-of-the-art method for implementing context switching, and although the corresponding latency it introduces to the task execution timeline can be mitigated by double buffering, its efficiency remains low. This is because tasks cannot continue execution on the new resource allocation decision until the data migration is complete. If DRA is frequently triggered due to environmental changes, the overall throughput of multi-task operations can be severely impacted. Summary of the Invention

[0005] To address the technical problem that dynamic resource allocation negatively impacts task throughput in existing technologies, this invention proposes a coarse-grained reconfigurable architecture (CTMA) oriented towards context switching and its operation method.

[0006] The technical solution adopted by this invention to solve the above problems is as follows: This invention proposes a coarse-grained reconfigurable architecture CTMA oriented towards context switching, including:

[0007] Independent routing network, CTMA command receiver module, and global CTMA controller module;

[0008] The global CTMA controller module is used to receive all memory access operations that are incompatible with the layout tile and the data memory, iteratively generate cross-tile memory access commands for each operation, and send them to the corresponding tile through a chain bus that sequentially connects each tile.

[0009] The CTMA command receiver module is used to register incoming CTMA commands, check the route validity between the received CTMA command and existing CTMA commands, handle conflicts, and cache CTMA commands locally.

[0010] Independent routing networks are used to directly perform cross-tile memory accesses under the control of locally buffered CTMA commands.

[0011] Optionally, the global CTMA controller module includes an input manager, a local buffer module, a finite state machine, a pathfinder, and a command generator;

[0012] The input manager is used to decode the received input data;

[0013] The local buffer module is used for storing decoded data;

[0014] A finite state machine is used to control the generation of different types of CTMA commands, including head CTMA commands, intermediate CTMA commands, and tail CTMA commands.

[0015] The path finder is used to generate the tiles to which the different types of CTMA commands belong.

[0016] The command generator is used to generate CTMA commands for cross-tile memory access.

[0017] Optionally, the CTMA command receiver module includes registers, a command memory module, a routing conflict processor, and a command memory read module;

[0018] The register is used to store the CTMA command passed in each clock cycle;

[0019] The command memory module is used to buffer CTMA commands;

[0020] The routing conflict handler is used to write control commands to memory during context switching;

[0021] The command memory read module is used to control command memory reads during task execution after a context switch.

[0022] Optionally, the independent routing network includes a memory arbiter, routing registers in eight directions, and functional units;

[0023] The memory arbiter is used to redirect data from the Tiles routes in eight directions—east, south, west, north, northeast, northwest, southeast, and southwest—to the input port of the memory access unit and to sample it on the rising edge of the next clock cycle.

[0024] The functional unit is used to provide output signals to the memory arbiter to perform STORE or LOAD operations on the memory access unit.

[0025] The operational methods for the context-switching coarse-grained reconfigurable architecture CTMA include:

[0026] Step 1: Based on the global CTMA controller, all memory access operations that are incompatible with the layout tile and data memory are received and stored in the local buffer module. The finite state machine switches between four states under the control of the auto-incrementing Cnt. When a new SrcTile is found, the path finder calls the command generator to generate the corresponding CTMA command and transmits it to the corresponding tile through the chain bus.

[0027] Step 2: The generated CTMA command is registered in the register module of the CTMA command receiver. The conflict is handled by the command memory module and the routing conflict processor and the CTMA command is written into the cache. During the task execution after the context switch, the command memory read module controls the reading of the command memory.

[0028] Step 3: Perform cross-tile memory access directly under the control of CTMA commands in a local buffer via an independent routing network.

[0029] Optionally, step 1, which involves the path finder calling the command generator to generate a corresponding CTMA command for each new SrcTile found, and then transmitting it to the corresponding Tile via the chain bus, includes:

[0030] Step 1.1: The local buffer module caches the decoded incompatible memory access operations. During the pre-mapping stage, the SrcTileXY and TgtTileXY in the local buffer module record the horizontal (X) and vertical (Y) coordinates of the placement blocks of incompatible memory access operations before and after resource allocation, respectively. SrcTileCycle provides the planned clock cycle of memory access operations on the layout tiles after resource allocation. XY2Tile queries the corresponding tile for a given (X, Y) coordinate.

[0031] Step 1.2: Calculate the XY coordinate difference DiffXY between SrcTileXY and TgtTileXY using a finite state machine to obtain the number of CTMA commands required to achieve cross-tile memory access, and generate the header CTMA command, the middle CTMA command, and the tail CTMA command.

[0032] Step 1.3: The path optimizer finds the head CTMA command, middle CTMA command and tail CTMA command generated by the received command, updates SrcTile and uses the SrcTileXY obtained by the iterative update to query XY2Tile, obtains the shortest path between the Tile with the target data memory and the Tile that actually performs the memory access operation, and compares it with DiffXY to refresh SrcTileXY and SrcCycle, and optimizes SrcTile in the next iteration;

[0033] Step 1.4: Based on the command generator output, the CTMA command for cross-tile memory access is generated. The CTMA command for cross-tile memory access is 24 bits and includes five fields: Opt, Cycle, TileID, XbarIn, and XbarOut. Opt is 4 bits in size and is used to control the memory access unit within the tile to perform LOAD, STORE, or BYPASS operations. Cycle is 4 bits in size and is used to obtain the execution clock cycle of Opt. TileID is 8 bits in size and is used to identify the tile that executes Opt. XbarIn and XbarOut are both 4 bits in size and are used to control the tile's memory arbiter to route the memory access result from the source direction to the destination direction.

[0034] Optionally, step 1.3, obtaining the shortest path between the tile containing the target data memory and the tile where the memory access operation is actually performed, specifically includes:

[0035] For cross-tile memory access in the LOAD operation, the header CTMA command reads the data memory of the current tile and routes the result to the next tile in the path. For cross-tile memory access in the STORE operation, the header CTMA command reads the output of the functional unit and routes it to the next tile in the path.

[0036] The intermediate CTMA command does not involve any memory access operations; it simply passes the memory access result to the next tile in the path.

[0037] For cross-tile memory accesses in LOAD operations, the tail CTMA command redirects the memory access result to a register in the CTMA command receiver. For cross-tile memory accesses in STORE operations, the tail CTMA command writes the route value to the data memory in the tile.

[0038] Optionally, step 2, which involves handling the conflict and writing the CTMA command to the cache, includes:

[0039] Step 2.1: The route conflict processor compares the TileID field of the registered CTMA command with its own ID. If TileID = ID, the registered CTMA command is written to the command memory. If TileID ≠ ID, the route conflict processor reads the existing CTMA command of the current Tile at the same Cycle and checks whether the Opt, XbarIn, and XbarOut fields in the CTMA command are the same as the corresponding fields of the registered CTMA command. If any of the corresponding blocking is the same, a conflict occurs, and the corresponding CTMA command is written to the conflict cache. If they are not the same, the corresponding CTMA command is written to the normal cache.

[0040] Step 2.2: After the CTMA command is written to the cache, the write address wrAddr is indicated by the Cycle field when writing to the normal cache and generated by the counter when writing to the conflict cache. The writing order of the conflict cache and the normal cache is recorded in the jump register. Each bit of the jump register will be responsible for strobing the two counters that generate the corresponding cache read address. After the context switch, the CTMA command will be read from the normal cache or the conflict cache in reverse order.

[0041] Optionally, step 3, which involves directly performing cross-tile memory access under the control of the local buffer's CTMA command, specifically includes:

[0042] After receiving the control instructions from the XbarIn and XbarOut fields of the CTMA command, the memory arbiter receives data from the Tiles routes in eight directions: East, South, West, North, Northeast, Northwest, Southeast, and Southwest. It then forwards the input to the input port of the memory access unit and samples it on the rising edge of the next clock cycle. The memory arbiter also uses the output signal of the functional unit as an input or write signal. When used as an input, it selects the Tiles to be routed in other directions. When used as a write signal, it performs a STORE operation on the memory access unit or directly performs a LOAD operation on the memory access unit. The read signal is used as the input of the memory arbiter, and it selects the Tiles to be routed in other directions or sends it as an operand to the functional unit for calculation, thus completing cross-Tile memory access.

[0043] The beneficial effects of this invention are:

[0044] 1. This invention, by employing CTMA, can bring an average throughput improvement of 1.68× to the Streamimg-Bench and Polybench task sets. Simultaneously, within 5 input data points after triggering resource allocation, it can achieve an average throughput exceeding 90.0% of the resource allocation decision target.

[0045] 2. According to the Synopsys+Cadence synthesis and placement and routing reports, the CTMA designed in this invention occupies only 9.02% of the area under TSMC's 45nm process.

[0046] 3. This invention enables tasks to directly access the memory distribution before the context switch after the context switch, without data migration, thereby avoiding the negative impact of dynamic resource allocation on task throughput. Attached Figure Description

[0047] Figure 1 A structural block diagram of the coarse-grained reconfigurable architecture CTMA for context switching provided by the present invention;

[0048] Figure 2 A flowchart illustrating the operation method of the context-switching coarse-grained reconfigurable architecture CTMA provided by this invention;

[0049] Figure 3 A flowchart of the CTMA controller algorithm provided by this invention. Detailed Implementation Specific Implementation Method 1

[0051] In this embodiment, CGRA is a coarse-grained reconfigurable architecture, and CTMA is a cross-tile memory accessor.

[0052] Combination Figure 1 This implementation method is described as follows: Figure 1As shown in (a), the coarse-grained reconfigurable architecture CTMA for context switching described in this embodiment includes: an independent routing network, a CTMA command receiver module, and a global CTMA controller module.

[0053] The global CTMA controller module is used to receive all memory access operations that are incompatible with the layout tile and the data memory, iteratively generate cross-tile memory access commands for each operation, and send them to the corresponding tile through a chain bus that sequentially connects each tile.

[0054] like Figure 1 As shown in (d), the global CTMA controller module includes an input manager, a local buffer module, a finite state machine, a pathfinder, and a command generator;

[0055] The input manager is used to receive input data and decode it;

[0056] The local buffer module is used for storing decoded data;

[0057] Finite state machines are used to perform state transitions within a clock cycle and control the generation of different types of CTMA commands. The different types of CTMA commands include head CTMA commands, intermediate CTMA commands, and tail CTMA commands.

[0058] The pathfinder is used to read from the data memory of the current tile based on the different types of CTMA commands generated and to route the read results to the next tile in the path;

[0059] The command generator is used to generate CTMA commands for cross-tile memory access.

[0060] The CTMA command receiver module is used to register incoming CTMA commands, check the route validity between the received CTMA command and existing CTMA commands, handle any conflicts, cache CTMA commands locally, and continue running the task on the new resource allocation decision after the context switch.

[0061] like Figure 1 As shown in (c), the CTMA command receiver module includes a register, a command memory module, a routing conflict processor, and a command memory read module;

[0062] The register is used to store the CTMA command passed in each clock cycle;

[0063] The command memory module is used to buffer CTMA commands;

[0064] The routing conflict handler is used to write control commands to memory during context switching;

[0065] The command memory read module is used to control command memory reads during task execution after a context switch.

[0066] Independent routing networks are used to directly perform cross-tile memory accesses under the control of locally buffered CTMA commands.

[0067] like Figure 1 As shown in (b), the independent routing network includes a memory arbiter, routing registers in eight directions, and functional units;

[0068] The memory arbiter is used to redirect data from the Tiles routes in eight directions—east, south, west, north, northeast, northwest, southeast, and southwest—to the input port of the memory access unit and to sample it on the rising edge of the next clock cycle.

[0069] The functional unit is used to provide output signals to the memory arbiter to perform STORE or LOAD operations on the memory access unit. Specific Implementation Method Two

[0071] Combination Figure 1-3 This embodiment will be described as follows: Figure 2 As shown, the steps of the operation method of the coarse-grained reconfigurable architecture CTMA for context switching described in this embodiment include:

[0072] S1: Global CTMA Controller (Receives all memory access operations that are incompatible with the data memory of the layout tile, iteratively generates cross-tile memory access commands (CTMA commands) for each operation, and sends them to the corresponding tiles through the chain bus that sequentially connects each tile;

[0073] S101: As Figure 1 As shown in (d), the input manager interacts with the central processing unit to receive input data from the CTMA controller and then stores it in a local buffer, including SrcTileXY, SrcTireCycle, TgtTileXY, and XY2Tile. For each incompatible memory access operation, SrcTileXY and TgtTileXY record the horizontal (X) and vertical (Y) coordinates of its placement block before and after resource allocation, respectively. SrcTileCycle provides the planned clock cycles for memory access operations on the layout tile after resource allocation, and XY2Tile is used to query the corresponding tile for a given (X, Y) coordinate. All inputs are generated during the pre-mapping stage and are well organized in off-chip memory. During context switching, the corresponding input is transferred to the CTMA controller via DMA and then decoded by the bus controller within the input manager.

[0074] S102: The CTMA command (24-bit) output by the CTMA controller contains five fields: Opt, Cycle, TileID, XbarIn, and XbarOut, to enable cross-tile memory access. Opt (4 bits) controls the memory access unit within the tile to perform LOAD, STORE, or BYPASS operations; Cycle (4 bits) indicates in which clock cycle Opt should be executed; TileID (8 bits) identifies the tile executing Opt; XbarIn (4 bits) and XbarOut (4 bits) are used to control the tile's memory arbiter to route the memory access result from the source direction to the destination direction.

[0075] S103: Based on the inputs of S101-S102, the CTMA controller... Figure 3 The algorithm shown outputs CTMA commands, finds the shortest path between the tile with the target data memory and the tile that actually performs the memory access operation, and generates CTMA commands for each tile within the path.

[0076] S10301: Figure 3 The algorithm shown first uses `Init()` to calculate the XY coordinate difference `DiffXY` between `SrcTileXY` and `TgtTileXY` (line 1). Then, it uses `Max()` to obtain the number of CTMA commands `NumCmds` required to achieve cross-tile memory access (line 2). To iteratively find the shortest path, `SrcTile` is updated at the beginning of each `While` loop iteration by querying `XY2Tile` with the latest `SrcTileXY` (lines 3-5). At the end of the `While` loop iteration, `MoveToNextTile()` is called to refresh `SrcTileXY` and `SrcCycle` by comparing them with `DiffXY` (line 15), making `SrcTile` closer to `TgtTile` in the next iteration. Finally, `Update()` updates `DiffXY` to prepare for the next iteration (line 16).

[0077] S10302: Each tile within the shortest path requires a CTMA command to continuously transmit memory access results. This is based on the Cnt value and the size of NumCmds. Figure 3 The algorithm shown can output three types of CTMA commands (lines 6-14): head CTMA command, middle head CTMA command, and tail head CTMA command;

[0078] Cnt == 0 represents the head CTMA command, which is always generated by GenCmd_Head(). For cross-Tile memory access of the LOAD operation, this command actually reads from the data memory of the current Tile and routes the result to the next Tile in the path. For cross-Tile memory access of the STORE operation, this command reads the output of the functional unit and routes it to the next Tile in the path.

[0079] 0 < Cnt < NumCmds represents the intermediate CTMA command generated by GenCmd_Body(), which does not involve any memory access operations and only bypasses the memory access result to the next Tile in the path.

[0080] Cnt == NumCmds represents the tail CTMA command, which is always generated by GenCmd_Tail(). For cross-Tile memory access of the LOAD operation, this command redirects the memory access result to the input register of the functional unit. For cross-Tile memory access of the STORE operation, this command actually writes the routing value to the data memory in the Tile.

[0081] S10303: When Figure 3 the algorithm shown is converted into a hardware design, the while loop is abstracted into a finite state machine. For the LOAD or STORE memory access operation, the finite state machine switches between 4 states under the control of the incrementing Cnt, including INIT, HEAD, BODY, and TAIL. All state transitions and state outputs are combinational logic circuits, and the state switching is sequential logic circuits. Other functions including Init(), MoveToNextTile(), and GenCmd_Head / Body / Tail() are abstracted into two hardware modules, a path finder and a command generator, both composed of combinational and sequential logic circuits and controlled by the finite state machine using the State signal.

[0082] S2: During the transmission of the CTMA command on the chain bus, if it is determined to belong to the current Tile, it is buffered locally by the CTMA command receiver in the Tile. The receiver also checks the routing legality between the received CTMA command and the existing CTMA commands and handles conflicts if necessary;

[0083] S201: As Figure 1 (c) shows, a register at the top of the CTMA command receiver is used to latch the incoming CTMA command at the rising edge of each clock cycle so that each CTMA command generated by the CTMA controller can be transmitted along the chain bus to all Tiles;

[0084] S202: The command memory module and the routing conflict processor handle the conflicts that occur and write the CTMA command to the cache. During the task execution after the context switch, the command memory read module controls the reading of the command memory.

[0085] S20201: In the route conflict handler, the Tile compares the TileID field of the registered CTMA command with its own ID. Only if TileID == ID is the registered CTMA command allowed to be written to command memory. Since no conflict check is performed in the CTMA controller, the route conflict handler reads the existing CTMA command Exist_Cmd of the current Tile at the same Cycle and checks whether its Opt, XbarIn, and XbarOut fields are the same as the corresponding fields of the registered CTMA command. If any of these fields are the same, a conflict occurs, the write enable signal wrEn of the conflict buffer is active, and the registered CTMA command is written to the conflict buffer. Otherwise, it is written to the normal buffer.

[0086] S20202: The write address wrAddr is indicated by the Cycle field when writing to the normal cache, and generated by a counter when writing to the conflict cache. The write order of the two caches is recorded in the jump register. After a context switch, the CTMA command will read from the normal cache or the conflict cache in reverse order to avoid conflicts. To achieve this, each bit of the jump register is responsible for strobing the two counters that generate the corresponding cache read address.

[0087] S3: After the context switch, the task continues to run based on the new resource allocation decision. The independent routing network in each tile consists of a memory arbiter, registers (R), and memory access units, and performs cross-tile memory access under the control of CTMA commands in the local buffer, thereby avoiding data migration.

[0088] S301: The input of the memory arbiter mainly includes data from the Tiles routes in the eight directions of east, south, west, north, northeast, northwest, southeast and southwest. It can redirect the data to the input ports of the eight route registers and sample it on the rising edge of the next clock cycle so that the corresponding Tile can stably receive the data in the next clock cycle.

[0089] S302: The memory arbiter also uses the output signal (FU_output) of the functional unit as input, selecting which Tiles to route to in other directions, or using it as a write signal (write_Data) to perform a STORE operation on the memory access unit. Conversely, a Tile can also directly perform a LOAD operation on the memory access unit, using the read signal (Read_Data) as input to the memory arbiter, and selecting which Tiles to route to in other directions, or sending it as an operand (Operand) to the functional unit for further computation. All behaviors of the memory arbiter and the memory access unit in each cycle are controlled by the XbarIn and XbarOut fields of the CTMA command, enabling tasks to directly access the memory distribution before the context switch without data migration, thus avoiding the negative impact of dynamic resource allocation on task throughput.

[0090] Example

[0091] Combination Figure 2 This embodiment will be described as follows: Figure 2 As shown, the application steps of the coarse-grained reconfigurable architecture CTMA for context switching described in this embodiment include:

[0092] Step 1: Suppose that in a certain computational task, the LOAD operation of variable X[i] is mapped to Tile 1 in clock cycle 3, but the corresponding data X[i] is actually located in the data memory of Tile 10. This creates a cross-tile memory access requirement. During the context switching process, the CTMA controller goes through four states over four clock cycles, including INIT, HEAD, BODY, and TAIL, generating a header CTMA command for Tile 10, a middle CTMA command for Tile 6, and a tail CTMA command for Tile 1 in turn. These commands are transmitted through Tiles sequentially connected by a chain bus and buffered by the CTMA command receiver in the corresponding Tile at clock cycles 5, 10, and 14, respectively.

[0093] Step 2: After the context switch, when CGRA executes its task under the new resource allocation decision, the CTMA command in Tile 10 first activates the memory access unit, reads X[i] from the data memory in clock cycle 1, and then controls the memory arbiter to redirect X[i] to the south register connected to Tile 6. Next, the CTMA command in Tile 6 controls the memory arbiter to redirect the registered value to the southwest register connected to Tile 1 in clock cycle 2. Finally, the CTMA command in Tile 1 controls the memory arbiter to redirect the registered value to the input register of the functional unit in clock cycle 3. Therefore, X[i] is accurately routed to the consumer operation in Tile 1 via CTMA in clock cycle 4, achieving the same effect as migrating X[i] from the data memory of Tile 1 to Tile 10, but eliminating the delay to the CGRA task execution timeline.

[0094] To verify the technical effects of the present invention, the following experimental setup was adopted in this embodiment:

[0095] (1) CGRA architecture: The size of the CGRA processing unit array is 16×16, with a total of 256 Tiles. The data memory size of each Tile is 1KB, and the configuration memory size is 512Bytes. The interconnection topology between Tiles is "orthogonal + diagonal". The command memory in the CTMA controller is set to 1KB, which is sufficient to accommodate the input required for all tasks to generate CTMA commands (XY2Tile is 512Bytes, TileXY and TileCycle together are 512Bytes). The cache in the CTMA command receiver is set to 64Bytes, which is divided into normal cache (48Bytes) and conflict cache (16Bytes).

[0096] (2) Data-intensive tasks: First, three embedded domain streaming tasks were selected from the open-source CGRA task set Streamimg-Bench, including GCN, RayTrac, and LU. Each task has its own 16×16CGRA, and all kernels within the task are executed in a pipelined manner. In addition, this embodiment selects three computational tasks in the matrix multiplication domain from the open-source CGRA task set Polybench, namely GEMM, SYRK, and SYMM. The three tasks are executed in parallel and share 16×16CGRA.

[0097] (3) Dynamic resource allocation decision: For the Streamimg-Bench task set, the resource allocation decision is generated by the DRIPS controller; for the Polybench task set, the resource allocation decision is generated by the modified Linux EEVDF algorithm.

[0098] Under the above experimental settings, CTMA delivers an average throughput improvement of 1.68× for the Streamimg-Bench and Polybench task sets. Furthermore, within five input data points after resource allocation is triggered, it achieves an average throughput exceeding 90.0% of the target resource allocation decision. Synopsys+Cadence synthesis and place-and-route reports show that CTMA occupies only 9.02% of the area on TSMC's 45nm process.

[0099] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent substitutions, and improvements made to the above embodiments without departing from the scope of the present invention, based on the technical essence of the present invention and within the spirit and principles of the present invention, shall still fall within the protection scope of the present invention.

Claims

1. A coarse-grained reconfigurable architecture CTMA oriented towards context switching, characterized in that: The structure of the coarse-grained reconfigurable architecture CTMA, which is context-switching oriented, includes: Independent routing network, CTMA command receiver module, and global CTMA controller module; CTMA is a cross-tile memory accessor. The global CTMA controller module is used to receive all memory access operations that are incompatible with the layout tile and the data memory, iteratively generate cross-tile memory access commands for each operation, and send them to the corresponding tiles through a chain bus that sequentially connects each tile. The CTMA command receiver module is used to register incoming CTMA commands, check the route validity between received CTMA commands and existing CTMA commands, handle conflicts, and cache CTMA commands locally. The independent routing network is used to directly perform cross-tile memory access under the control of locally buffered CTMA commands; The global CTMA controller module includes an input manager, a local buffer module, a finite state machine, a pathfinder, and a command generator; The input manager is used to decode the received input data; The local buffer module is used for storing the decoded data; The finite state machine is used to control the generation of different types of CTMA commands, including head CTMA commands, intermediate CTMA commands, and tail CTMA commands. The path finder is used to generate the tiles to which the different types of CTMA commands belong; The command generator is used to generate CTMA commands for cross-tile memory access.

2. The coarse-grained reconfigurable architecture CTMA for context-switching as described in claim 1, characterized in that, The CTMA command receiver module includes a register, a command memory module, a routing conflict processor, and a command memory read module; The register is used to store the CTMA command passed in each clock cycle; The command memory module is used to buffer CTMA commands; The routing conflict processor is used to write control command memory during context switching; The command memory reading module is used to read control command memory during task execution after a context switch.

3. The coarse-grained reconfigurable architecture CTMA for context-switching according to claim 1, characterized in that, The independent routing network includes a memory arbitrator, routing registers in eight directions, and functional units; The memory arbiter is used to redirect data from Tiles routes in eight directions (east, south, west, north, northeast, northwest, southeast, and southwest) to the input port of the memory access unit and to sample it on the rising edge of the next clock cycle. The functional unit is used to provide output signals to the memory arbiter to perform STORE or LOAD operations on the memory access unit.

4. A method for operating a coarse-grained reconfigurable architecture CTMA oriented to context switching, applied to the coarse-grained reconfigurable architecture CTMA oriented to context switching as described in any one of claims 1-3, characterized in that, include: Step 1: Based on the global CTMA controller, all memory access operations that are incompatible with the data memory of the layout tile are received and stored in the local buffer module. The finite state machine switches between four states under the control of the auto-incrementing Cnt. When a new SrcTile is found, the path finder calls the command generator to generate the corresponding CTMA command and transmits it to the corresponding tile through the chain bus. Step 2: The generated CTMA command is registered in the register module of the CTMA command receiver. The conflict is handled by the command memory module and the routing conflict processor and the CTMA command is written into the cache. During the task execution after the context switch, the command memory read module controls the reading of the command memory. Step 3: Perform cross-tile memory access directly under the control of CTMA commands in a local buffer via an independent routing network.

5. The method for operating the coarse-grained reconfigurable architecture CTMA oriented to context switching according to claim 4, characterized in that, Step 1, which involves the path finder calling the command generator to generate a corresponding CTMA command for each new SrcTile found, and then transmitting it to the corresponding Tile via the chain bus, includes the following steps: Step 1.1: The local buffer module caches the decoded incompatible memory access operations. During the pre-mapping stage, the SrcTileXY and TgtTileXY in the local buffer module record the horizontal (X) and vertical (Y) coordinates of the placement blocks of incompatible memory access operations before and after resource allocation, respectively. SrcTileCycle provides the planned clock cycle of memory access operations on the layout tiles after resource allocation. XY2Tile queries the corresponding tile for a given (X, Y) coordinate. Step 1.2: Calculate the XY coordinate difference DiffXY between SrcTileXY and TgtTileXY using a finite state machine to obtain the number of CTMA commands required to achieve cross-tile memory access, and generate the header CTMA command, the middle CTMA command, and the tail CTMA command. Step 1.3: The path optimizer finds the head CTMA command, middle CTMA command and tail CTMA command generated by the received command, updates SrcTile and uses the SrcTileXY obtained by the iterative update to query XY2Tile, obtains the shortest path between the Tile with the target data memory and the Tile that actually performs the memory access operation, and compares it with DiffXY to refresh SrcTileXY and SrcCycle, and optimizes SrcTile in the next iteration; Step 1.4: Output the CTMA command for cross-tile memory access based on the command generator. The CTMA command for cross-tile memory access is 24 bits and includes five fields: Opt, Cycle, TileID, XbarIn, and XbarOut. Opt is 4 bits in size and is used to control the memory access unit within the tile to perform LOAD, STORE, or BYPASS operations. Cycle is 4 bits in size and is used to obtain the execution clock cycle of Opt. TileID is 8 bits in size and is used to identify the tile that executes Opt. XbarIn and XbarOut are both 4 bits in size and are used to control the memory arbiter of the tile to route the memory access result from the source direction to the target direction.

6. The method for operating the coarse-grained reconfigurable architecture CTMA oriented to context switching according to claim 5, characterized in that, Step 1.3, obtaining the shortest path between the tile containing the target data memory and the tile where the memory access operation is actually performed, specifically includes: For cross-tile memory access in the LOAD operation, the header CTMA command reads the data memory of the current tile and routes the result to the next tile in the path. For cross-tile memory access in the STORE operation, the header CTMA command reads the output of the functional unit and routes it to the next tile in the path. The intermediate CTMA command does not involve any memory access operations; it simply passes the memory access result to the next tile in the path. For cross-tile memory accesses in LOAD operations, the tail CTMA command redirects the memory access result to a register in the CTMA command receiver. For cross-tile memory accesses in STORE operations, the tail CTMA command writes the route value to the data memory in the tile.

7. The method for operating the coarse-grained reconfigurable architecture CTMA oriented to context switching according to claim 4, characterized in that, Step 2, which involves handling the conflict and writing the CTMA command to the cache, includes: Step 2.1: The route conflict processor compares the TileID field of the registered CTMA command with its own ID. If TileID = ID, the registered CTMA command is written to the command memory. If TileID ≠ ID, the route conflict processor reads the existing CTMA command of the current Tile at the same Cycle and checks whether the Opt, XbarIn, and XbarOut fields in the CTMA command are the same as the corresponding fields of the registered CTMA command. If any of the corresponding blocking is the same, a conflict occurs, and the corresponding CTMA command is written to the conflict cache. If they are not the same, the corresponding CTMA command is written to the normal cache. Step 2.2: After the CTMA command is written to the cache, the write address wrAddr is indicated by the Cycle field when writing to the normal cache and generated by the counter when writing to the conflict cache. The writing order of the conflict cache and the normal cache is recorded in the jump register. Each bit of the jump register will be responsible for selecting the two counters that generate the corresponding cache read address. After the context switch, the CTMA command will be read from the normal cache or the conflict cache in reverse order.

8. The method for operating the coarse-grained reconfigurable architecture CTMA oriented to context switching according to claim 4, characterized in that, Step 3, which involves directly performing cross-tile memory access under the control of the local buffer's CTMA command, specifically includes: Upon receiving the control instructions from the XbarIn and XbarOut fields of the CTMA command, the memory arbiter receives data from Tiles routes in eight directions: East, South, West, North, Northeast, Northwest, Southeast, and Southwest. It then redirects the input to the input port of the memory access unit and samples it on the rising edge of the next clock cycle. Furthermore, the memory arbiter uses the output signal of the functional unit as either an input or a write signal. When used as an input, it selects a Tile route in another direction. When used as a write signal, it performs a STORE operation on the memory access unit or directly performs a LOAD operation on the memory access unit. The read signal is used as the input to the memory arbiter, and it selects a Tile route in another direction or sends it as an operand to the functional unit for calculation, thus completing cross-tile memory access.

Images