Transaction processing method, circuit and multi-core processor architecture

Abstract

The invention relates to the technical field of computing hardware architectures, in particular to a transaction processing method and circuit and a multi-core processor architecture. The method comprises the following steps: acquiring a transaction request from a data sending end through a transaction shunting module; if the transaction attribute information of the transaction request meets the advanced response condition, shunting the transaction attribute information to a response processing module, extracting a transaction identifier in the transaction attribute information through the response processing module, and generating an advanced completion response according to the transaction identifier so as to return the advanced completion response to the data sending end; and if the transaction attribute information does not meet the advanced response condition, shunting the transaction request to a downstream processing module for transaction processing. Therefore, through the execution modes of the two synchronization barrier transactions, the transaction processing efficiency and the response speed are improved, and the technical problems that in the prior art, due to the fact that the synchronization barrier execution mode is single, the bandwidth efficiency improvement is limited, and the supported synchronization barrier semantics is single are solved.

Description

Technical Field

[0001] This application relates to the field of computing hardware architecture technology, and in particular to a transaction processing method, circuit, and multi-core processor architecture. Background Technology

[0002] With the rapid development of artificial intelligence technology, GPUs (Graphics Processing Units) are increasingly used in AI inference scenarios, leading to a growing demand for inference acceleration. Link transmission efficiency has become a key factor affecting GPU inference performance. In distributed computing environments, multi-GPU collaborative inference requires frequent exchange of intermediate data, and data transmission often faces the challenge of multi-hop, long paths, introducing significant processing latency and bandwidth bottlenecks. Early response mechanisms, as an important means of optimizing link transmission, aim to hide processing latency from slave devices and improve link utilization by returning transaction completion responses in advance. However, existing early response mechanisms suffer from technical limitations in supporting efficient data synchronization, including limited bandwidth efficiency improvements due to the simplistic execution method of synchronization barriers and the limited semantic support for synchronization barriers. These limitations make it difficult to meet the stringent requirements of low latency and high throughput in AI inference scenarios. Summary of the Invention

[0003] This application addresses the aforementioned shortcomings and drawbacks by providing a transaction processing method, circuit, and multi-core processor architecture, which can solve the technical problems of limited bandwidth efficiency improvement and limited support for synchronization barrier semantics in existing early response mechanisms. The main technical solutions adopted in this application include: In a first aspect, this application provides a transaction processing method applied to a transaction processing circuit, the transaction processing circuit including a transaction diversion module and a response processing module; the transaction processing method includes: obtaining a transaction request from a data sender through the transaction diversion module; in response to the transaction attribute information of the transaction request satisfying the early response condition, diverting the transaction attribute information to the response processing module, extracting the transaction identifier from the transaction attribute information through the response processing module, and generating an early completion response based on the transaction identifier to return to the data sender; in response to the transaction attribute information not satisfying the early response condition, diverting the transaction request to a downstream processing module for transaction processing.

[0004] This embodiment integrates a transaction routing module and a response processing module into the transaction processing circuit. The transaction routing module directly connects to the data sending end and the response processing module, and is connected to the downstream processing module, i.e., the transaction processing pipeline, through a third end. This pipeline consists of multiple hardware processing modules arranged sequentially to perform segmented pipelined processing of transaction requests, such as barrier identification, identifier replacement, and arbitration output, to improve throughput and processing efficiency. Therefore, this circuit not only intelligently routes transaction requests from the data sending end, but also has low hardware overhead due to modular integration. If the transaction attribute information of a transaction request meets the early response condition, the transaction routing module routes the transaction attribute information to the response processing module. The response processing module extracts the transaction identifier from the transaction attribute information and generates an early completion response based on the transaction identifier to return to the data sending end. If the transaction attribute information of a transaction request does not meet the early response condition, the transaction request is routed to the transaction processing pipeline for transaction processing. In this way, the transaction processing circuit performs conditional judgments based on transaction attribute information to achieve transaction diversion processing. For transactions that meet the conditions, an early response is generated immediately, effectively hiding processing delays, reducing sender congestion, and thus improving link bandwidth utilization and system throughput. For transactions that do not meet the conditions, they enter the transaction processing pipeline for regular processing to ensure data consistency. This application improves transaction processing efficiency and response speed through a classification processing mechanism, solving the technical problems of high transaction processing latency and insufficient bandwidth utilization in the background art.

[0005] In one embodiment, the transaction processing circuit further includes a barrier processing module; the transaction processing method further includes: transmitting transaction requests to the barrier processing module through a transaction diversion module; performing barrier synchronization instruction identification on the received transaction requests through the barrier processing module; in response to the identification of the barrier synchronization instruction, determining the sending timing of the barrier synchronization instruction based on a preset configuration mode through the barrier processing module, and monitoring the completion status of all memory access transactions issued before the barrier synchronization instruction; when the hardware transaction completion confirmation signal of all memory access transactions issued before the barrier synchronization instruction is returned, controlling the issuance of the barrier synchronization instruction through the barrier processing module. The sending timing of the barrier synchronization instruction is fixed, i.e., it can only be sent after waiting for the hardware transaction completion confirmation signal of all preceding memory access transactions to return; the barrier processing module controls the blocking and allowing status of the corresponding channels based on a preset configuration mode (conservative mode or performance mode). Therefore, this embodiment, by introducing a barrier processing module and intelligently controlling the blocking and allowing of channels based on a preset configuration mode, enables the circuit to flexibly adapt to different application scenarios while ensuring the semantic correctness of barrier synchronization. Conservative mode ensures strong data consistency by blocking subsequent transactions, making it suitable for scenarios where strict ordering of transactions is required. Performance mode significantly reduces the blocking time of the transaction pipeline through asynchronous caching and processing barrier instructions, thereby improving the overall throughput and response speed of the system in scenarios that allow for weak consistency.

[0006] In one implementation, in response to the detection of a barrier synchronization command, the barrier processing module determines the timing of sending the barrier synchronization command based on a preset configuration mode. This includes: if the configuration mode is conservative, upon detection of the barrier synchronization command, the barrier processing module blocks the sending of subsequent transactions on the processing channel containing the barrier synchronization command, and waits for the hardware transaction completion confirmation signals of all memory access transactions prior to the barrier synchronization command to return before sending the barrier synchronization command to the downstream processing module, ensuring the correctness of the barrier synchronization semantics; if the configuration mode is performance mode, the barrier processing module does not block the sending of subsequent transactions upon detection of the barrier synchronization command, and caches the barrier synchronization command in a first-in-first-out queue within the barrier processing module; after the hardware transaction completion confirmation signals of all memory access transactions prior to the barrier synchronization command return, the barrier processing module inserts the barrier synchronization command into the transaction flow of the current transaction processing pipeline and sends it out. This implementation provides a clear and configurable execution path for barrier processing by explicitly defining the specific operation procedures of the two strategies, conservative mode and performance mode. Conservative mode provides reliable synchronization guarantees for applications with strict requirements on transaction order through strict sequence control, avoiding data consistency problems that may be caused by out-of-order execution. Performance mode, on the other hand, hides the latency caused by synchronization barriers by allowing non-barrier transactions to continue execution, optimizing the utilization efficiency of link bandwidth, and is suitable for high-concurrency, throughput-sensitive computing tasks.

[0007] In one embodiment, the transaction processing circuit further includes a transaction arbitration module; the transaction processing method further includes: receiving transaction requests diverted to downstream processing modules through the transaction arbitration module, arbitrating the transaction requests, and transmitting the arbitrated transaction requests to the downstream processing modules; wherein, the transaction requests include requests that meet the early response conditions and have been processed by the barrier processing module, and requests from the transaction diversion module that do not meet the early response conditions and have not been processed by the response processing module. This embodiment, by introducing a transaction arbitration module, aggregates and arbitrates transaction requests from different processing paths (such as requests processed by the early response path and requests from ordinary paths), achieving unified and orderly output of the transaction flow. This design ensures that transactions with different characteristics can be integrated according to a predetermined scheduling strategy when entering the downstream processing module, avoiding conflicts and blockages between paths, thereby ensuring the smoothness of the transaction processing pipeline and the fairness of system resources, and further improving overall processing efficiency.

[0008] In one embodiment, the transaction processing circuit further includes an identifier replacement module; the transaction processing method further includes: receiving a transaction request output by the barrier processing module through the identifier replacement module, and performing identifier remapping on the transaction identifier in the transaction request, so as to transmit the remapped transaction request to the transaction arbitration module. This embodiment isolates the identifier spaces of the upstream data sender and the downstream processing module by introducing an identifier replacement module to remap the transaction identifier. This mechanism prevents identifier conflict errors that may be caused by specific requirements or restrictions on transaction identifiers by downstream components, enhancing the circuit's versatility and robustness. Simultaneously, it provides transparent identifier management to the upstream sender, simplifying the sender's design and making the entire transaction processing flow more reliable and easier to maintain.

[0009] In one embodiment, the transaction processing circuit further includes a response splitting module; the transaction processing method further includes: receiving a hardware transaction completion confirmation signal from a downstream processing module through the response splitting module, and parsing the hardware transaction completion confirmation signal to obtain a transaction identifier; determining whether the corresponding transaction has been responded to prematurely based on the transaction identifier; if it has been responded to prematurely, transmitting the hardware transaction completion confirmation signal to the barrier processing module, and updating the completion status of the barrier synchronization instruction based on the received hardware transaction completion confirmation signal through the barrier processing module. This embodiment, by introducing a response splitting module, constructs a critical path for the feedback of the actual completion response to the barrier processing module. This module can intelligently split the hardware transaction completion confirmation signal returned from downstream: directing the actual response of transactions that have been responded to prematurely to the barrier processing module for updating the synchronization status, while directing the actual response of transactions that have not been responded to prematurely to the response arbitration module. This mechanism ensures the accuracy of the barrier synchronization instruction completion status judgment and is the core link connecting the premature response mechanism and the semantic correctness of barrier synchronization, ensuring that the system improves performance without sacrificing data consistency.

[0010] In one embodiment, the transaction processing circuit further includes a response arbitration module; the transaction processing method further includes: when no early response has been received, receiving a hardware transaction completion confirmation signal from the response splitting module and an early completion response from the response processing module through the response arbitration module; arbitrating and merging the early completion response and the hardware transaction completion confirmation signal, and returning the merged completion response to the data sender. This embodiment introduces a response arbitration module responsible for merging the early completion response from the response processing module and the genuine hardware transaction completion confirmation signal from the response splitting module. This module ensures that for any given transaction, the data sender receives only one completion response, avoiding errors of duplicate or lost responses. This merging mechanism makes the early response transparent to the sender, eliminating the need for the sender to distinguish between genuine and fake responses, thus simplifying upstream design while fully realizing the performance benefits of the early response mechanism.

[0011] In one embodiment, the transaction processing circuit further includes a caching module; the transaction processing method further includes: caching transaction requests from the transaction splitting module, and sequentially transmitting the cached transaction requests to the response processing module and the barrier processing module. This embodiment, by introducing a caching module, provides buffer space for transaction requests that require early responses. This design can smooth bursts of transaction flow, absorb temporary blockages that may occur due to barrier processing or downstream backpressure, prevent transaction loss, and maintain the continuous transmission capability of the upstream sender. The presence of the caching module enhances the circuit's fault tolerance and ability to handle peak loads, and further ensures the continuous and efficient utilization of link bandwidth by improving the resilience of transaction reception.

[0012] In one implementation, the number of response processing modules and barrier processing modules is the same, and the response processing modules and barrier processing modules constitute one or more independent processing channels. This implementation achieves parallelization of transaction processing by configuring multiple independent processing channels. Each channel can be independently configured with its synchronization barrier processing mode (conservative or performance-oriented) and caching strategy, enabling the system to perform fine-grained resource allocation and strategy formulation based on the characteristics of different types of transactions (such as real-time requirements and data consistency requirements). This multi-channel architecture effectively avoids a single channel blocking the entire system due to processing specific types of transactions (such as barrier waiting in conservative mode), improving the parallelism, flexibility, and overall throughput of the system when handling mixed transaction loads.

[0013] In a second aspect, this application provides a transaction processing circuit, which includes a transaction routing module and a response processing module. The transaction processing circuit is configured to: obtain a transaction request from a data sender through the transaction routing module; in response to the transaction attribute information of the transaction request satisfying the early response condition, route the transaction attribute information to the response processing module, extract the transaction identifier from the transaction attribute information through the response processing module, and generate an early completion response based on the transaction identifier to return to the data sender; in response to the transaction attribute information not satisfying the early response condition, route the transaction request to a downstream processing module for transaction processing.

[0014] In a third aspect, this application provides a multi-core processor architecture, wherein the data sending end includes any one of a plurality of processor cores, and a transaction processing circuit as described in the above embodiments; the transaction processing circuit is configured to implement the transaction processing method described in any of the above embodiments.

[0015] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0016] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of this application. Wherein: Figure 1 This is a schematic flowchart of a transaction processing method according to an embodiment of this application; Figure 2 This is a block diagram of a transaction processing circuit including a transaction routing module and a response processing module, as exemplified in this application. Figure 3 This is a partial structural diagram of the barrier processing module in the transaction processing circuit of an example of this application; Figure 4 This is a partial structural diagram of the transaction arbitration module in the transaction processing circuit of an example of this application; Figure 5 This is a partial structural diagram of an identifier replacement module in a transaction processing circuit, as shown in an example of this application. Figure 6 This is a partial structural diagram of the response routing module in the transaction processing circuit of an example of this application; Figure 7 This is a partial structural diagram of the response arbitration module in the transaction processing circuit of an example of this application; Figure 8 This is a partial structural diagram of a cache module in a transaction processing circuit, as shown in this application. Figure 9 This is a structural block diagram of a transaction processing circuit according to an embodiment of this application; Figure 10 This is a structural block diagram of a transaction processing circuit according to another embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] In related technologies, transaction processing circuits are key components in computer architecture for achieving efficient data transmission. By optimizing the architecture design of transaction processing circuits, it is possible to achieve rapid response to transaction requests, optimized link bandwidth, and hidden processing latency in multi-core processor systems. Currently, high-performance computing systems commonly employ hardware acceleration mechanisms to improve transaction processing efficiency, but these mechanisms also face challenges such as high transaction queuing latency, insufficient bandwidth utilization, and complex synchronization control. Therefore, improvements in circuit architecture design are needed to enhance transaction processing efficiency and system throughput.

[0019] In existing transaction processing solutions, a common approach is to provide a single synchronization barrier or to respond in advance regardless of transaction type, such as the port handling mechanism defined by the PCIe protocol. However, this approach struggles to flexibly support diverse software semantics and data paths with mixed transaction types, especially when handling transactions with different response characteristics, failing to achieve a balance between latency concealment and bandwidth optimization. Furthermore, traditional solutions lack intelligent identification and classification mechanisms for transaction attributes, resulting in an inability to flexibly adapt to the needs of different scenarios.

[0020] Based on this, according to an embodiment of this application, a transaction processing method is provided. This method is applied to a transaction processing circuit (hereinafter referred to as the "circuit"). The circuit includes a transaction routing module and a response processing module. Specifically, the circuit can be integrated into a multi-core processor architecture. The transaction routing module and the response processing module deployed in the circuit execute the above-mentioned transaction processing method. The transaction routing module should have intelligent routing capability based on transaction attribute information to complete the condition judgment and path selection of transaction requests. The response processing module should have the capability of transaction identifier extraction and early response generation to complete the rapid response generation and return to the data sending end, thereby effectively hiding processing latency and improving system throughput and bandwidth utilization.

[0021] The following examples illustrate the transaction processing method proposed in this application. Figure 1 As shown, the first end of the transaction routing module is connected to the data sending end, the second end is connected to the response processing module, and the third end is connected to the downstream processing module, i.e., the transaction processing pipeline. This transaction processing pipeline refers to an execution pipeline composed of multiple hardware processing modules arranged sequentially, used for segmented pipelined processing of transaction requests, such as barrier identification, identifier replacement, and arbitration output, to improve throughput and processing efficiency. This method may include: Step S110: Obtain the transaction request from the data sender through the transaction splitting module.

[0022] The transaction routing module can refer to the component in the circuit used to route transaction requests to different processing paths according to transaction attribute information; the data sending end can refer to the master device that initiates the transaction request (such as a GPU graphics processor or a host controller).

[0023] Specifically, the circuit can connect to the output interface of the data sender through the input interface of the transaction splitting module, and receive and parse the transaction request packets sent by the data sender in real time, such as AW (Address Write Channel) of AXI (Advanced eXtensible Interface) or REQ (Request Channel) of CHI (Coherent Hub Interface).

[0024] For example, in such Figure 2 In the transaction processing circuit shown, the transaction diversion module (module 2) captures the transaction requests transmitted by the data sender based on the hardware interface listening mechanism and performs preliminary parsing to extract key attribute fields.

[0025] Step S120: In response to the transaction attribute information of the transaction request meeting the early response condition, the transaction attribute information is diverted to the response processing module. The response processing module extracts the transaction identifier from the transaction attribute information and generates an early completion response based on the transaction identifier to return to the data sending end; or, in response to the transaction attribute information not meeting the early response condition, the transaction request is diverted to the downstream processing module for transaction processing.

[0026] The transaction attribute information can refer to metadata fields in the transaction request (such as the AWUSER user-defined field in the AXI protocol or the ReqTxnAttr request transaction attribute field in the CHI protocol). These metadata fields may include attributes such as the barrier flag, address range, transaction type, and QoS (Quality of Service) priority. The early response condition can refer to the transaction being a non-barrier transaction. The transaction must be a transaction whose access address falls within a preset security address range, such as the area defined by the address mask 0x0000 to 0xFFFF; the transaction identifier can refer to a unique identifier for the transaction, such as the AWID write transaction ID of the AXI protocol or the TxnID transaction ID of the CHI protocol, used to associate requests and responses at the protocol layer; the early completion response can refer to a completion signal forged by the response processing module, such as the B write response of the AXI protocol or the RespAck response confirmation of the CHI protocol, used to notify the data sender in advance that the transaction has been completed, so as to release its burst transmission capacity; the downstream processing module can be used to form a transaction processing pipeline, which can be a sequential processing chain, including a barrier processing component, an identifier replacement component and an arbitration output component, used to perform synchronous control and sequential processing on transactions that do not meet the early response conditions.

[0027] Specifically, the circuit can parse transaction attribute information through the transaction diversion module: if the early response conditions are met (such as the barrier identifier being "0" and the address being within the safe range), the transaction attribute information is diverted to the response processing module, which extracts the transaction identifier and generates a forged completion response, which is then directly returned to the data sender; if the conditions are not met (such as the barrier identifier being "1" or the address being outside the safe range), the complete transaction request is diverted to the transaction processing pipeline, where the components in the pipeline sequentially perform barrier identification, identifier replacement, and arbitration output.

[0028] For example, in the AXI protocol scenario, when the transaction routing module detects that the barrier identifier in the AWUSER (Address Write channelIDentifier) ​​field is "0" and the address value is in the range of 0x0000 to 0xFFFF, it determines that the early response condition is met and immediately triggers the response processing module to generate a B response to return to the data sender. This B response contains a matching BID (Write Response IDentifier) ​​field; otherwise, the transaction request is forwarded to the transaction processing pipeline for subsequent processing.

[0029] In one example, such as Figure 3As shown, the transaction processing circuit also includes a barrier processing module, which can be used to connect to the second end of the transaction splitting module through the receiving end. The transaction processing method further includes: transmitting the transaction request to the barrier processing module through the transaction splitting module; performing barrier synchronization instruction identification on the received transaction request through the barrier processing module; in response to the identification of the barrier synchronization instruction, determining the sending timing of the barrier synchronization instruction based on a preset configuration mode through the barrier processing module, and monitoring the completion status of all memory access transactions issued before the barrier synchronization instruction; when the hardware transaction completion confirmation signal of all memory access transactions issued before the barrier synchronization instruction is returned, controlling the issuance of the barrier synchronization instruction through the barrier processing module. The sending timing of the barrier synchronization instruction is fixed, i.e., it can only be sent after waiting for the hardware transaction completion confirmation signal of all preceding memory access transactions to return; the barrier processing module controls the blocking and allowing status of the corresponding channel based on a preset configuration mode (conservative mode or performance mode). Therefore, by introducing a barrier processing module and intelligently controlling the blocking and allowing of channels based on a preset configuration mode, this embodiment enables the circuit to flexibly adapt to different application scenarios while ensuring the semantic correctness of barrier synchronization. Conservative mode ensures strong data consistency by blocking subsequent transactions, making it suitable for scenarios where strict ordering of transactions is required. Performance mode significantly reduces the blocking time of the transaction pipeline through asynchronous caching and processing barrier instructions, thereby improving the overall throughput and response speed of the system in scenarios that allow for weak consistency.

[0030] The configuration mode refers to the preset working strategy in the barrier processing module, which includes two types: conservative mode and performance mode. Conservative mode means that when a barrier synchronization instruction is detected, the sending of all subsequent transactions is blocked immediately until the hardware transaction completion confirmation signals of all memory access transactions before the barrier synchronization instruction are returned before the barrier synchronization instruction is sent. Performance mode means that when a barrier synchronization instruction is detected, the sending of subsequent non-barrier transactions is not blocked. Instead, the barrier synchronization instruction is temporarily stored in a dedicated buffer area and inserted into the transaction stream and sent after the hardware transaction completion confirmation signals of all memory access transactions before it are returned.

[0031] Specifically, the barrier processing module can identify barrier synchronization instructions by parsing the transaction attribute information in the transaction request (such as the ReqTxnAttr field of the CHI protocol or the AWUSER field of the AXI protocol). After identifying the barrier synchronization instructions, different processing strategies are adopted according to the preset configuration mode: if it is the conservative mode, it immediately pauses receiving new transactions from the cache module and monitors the number of unfinished transactions through an internal counter. After the hardware transaction completion confirmation signals of all previous transactions (such as the BRESP signal of the AXI protocol or the CompAck signal of the CHI protocol) are returned, the barrier synchronization instruction is sent to the downstream module; if it is the performance mode, it continues to process non-barrier transactions, and at the same time stores the barrier synchronization instruction in a first-in-first-out cache queue, tracks the completion status of the previous transactions through a state machine. After all hardware transaction completion confirmation signals are returned, the barrier synchronization instruction is taken out of the queue and inserted into the current transaction stream for sending.

[0032] Exemplarily, in the scenario of a GPU processing an image rendering task, the barrier processing module identifies a fence synchronization instruction (corresponding to the barrier synchronization instruction). If configured in the conservative mode: the module immediately blocks subsequent texture sampling transactions and waits until all 10 memory write transactions sent previously receive BRESP responses (corresponding to the hardware transaction completion confirmation signals), and then sends the fence instruction to the rasterization module to ensure data consistency, but it will introduce a delay of about 50 nanoseconds. If configured in the performance mode: the module continues to process subsequent calculation transactions, and at the same time caches the fence instruction in a queue with a depth of 8, monitors the response status of 10 write transactions through a counter. When the 8th BRESP is returned, there are already 3 subsequent transactions being processed in the queue. After the last 2 BRESPs are returned, the fence instruction is immediately inserted into the transaction stream and sent to the downstream. This process only generates a delay of about 15 nanoseconds, and the perceived delay at the sending end is reduced by about 40%. Further, the throughput change depends on the burst capability of the sending end: if the burst capability is sufficient (i.e., the current capability M ≥ the sufficient demand N), the throughput remains basically unchanged; if the burst capability is insufficient (M < N), the throughput is actually , where 50 / 15 is the delay ratio between the conservative mode and the performance mode, and the upper limit is the throughput of the theoretical full burst capability of 100%.

[0033] In one example, in response to the detection of a barrier synchronization command, the barrier processing module determines the timing of sending the barrier synchronization command based on a preset configuration mode. This includes: if the configuration mode is conservative, upon detection of the barrier synchronization command, the barrier processing module blocks the sending of subsequent transactions on the processing channel containing the barrier synchronization command, and waits for the hardware transaction completion confirmation signals of all memory access transactions issued before the barrier synchronization command to be returned before sending the barrier synchronization command to the downstream processing module, to ensure the correctness of the barrier synchronization semantics; if the configuration mode is performance mode, the barrier processing module does not block the sending of subsequent transactions upon detection of the barrier synchronization command, and caches the barrier synchronization command in the first-in-first-out queue within the barrier processing module; after the hardware transaction completion confirmation signals of all memory access transactions issued before the barrier synchronization command are returned, the barrier processing module inserts the barrier synchronization command into the transaction flow of the current transaction processing pipeline and sends it out. This implementation provides a clear and configurable execution path for barrier processing by clearly defining the specific operation flow of the two strategies, conservative mode and performance mode. Conservative mode provides reliable synchronization guarantees for applications with strict requirements on transaction order through strict sequence control, avoiding data consistency problems that may be caused by out-of-order execution. Performance mode, on the other hand, hides the latency caused by synchronization barriers by allowing non-barrier transactions to continue execution, optimizing the utilization efficiency of link bandwidth, and is suitable for high-concurrency, throughput-sensitive computing tasks.

[0034] In the example above, the configuration mode refers to the preset working strategy in the barrier processing module, which includes two types: conservative mode and performance mode. Conservative mode means that when a barrier synchronization instruction is detected, the sending of all subsequent transactions is blocked immediately until the hardware transaction completion confirmation signals of all memory access transactions before the barrier synchronization instruction are returned before the barrier synchronization instruction is sent. Performance mode means that when a barrier synchronization instruction is detected, the sending of subsequent non-barrier transactions is not blocked. Instead, the barrier synchronization instruction is temporarily stored in a dedicated buffer area, and the barrier synchronization instruction is inserted into the transaction stream and sent after the hardware transaction completion confirmation signals of all memory access transactions before it are returned.

[0035] Specifically, the barrier processing module monitors the number of outstanding transactions through an internal state machine or counter mechanism: In conservative mode, the module immediately pauses receiving new transactions from the upstream, and records the number of memory access transactions that have been issued but not received responses before the barrier synchronization instruction through a counter. For each hardware transaction completion confirmation signal received (such as BRESP (write response signal) in the AXI protocol or CompAck (completion confirmation signal) in the CHI protocol), the counter decrements; when the counter reaches zero, the module sends the barrier synchronization instruction and unblocks. In performance mode, the module continues to process non-barrier transactions, while storing the barrier synchronization instruction in a First-In-First-Out (FIFO) cache queue and starting an independent counter to track the completion status of previous transactions; when all hardware transaction completion confirmation signals are returned, the module retrieves the barrier synchronization instruction from the queue and inserts it into the current transaction stream for transmission, ensuring transaction order consistency.

[0036] Exemplarily, in the scenario of a GPU processing an artificial intelligence inference task, the barrier processing module recognizes a barrier synchronization instruction, such as the DMB (Data Memory Barrier) instruction in the ARM architecture. If configured in conservative mode: the module immediately blocks subsequent texture sampling transactions and waits for all 8 memory write transactions previously issued to receive BRESP responses (status OKAY), which takes about 60 nanoseconds, and then sends the barrier synchronization instruction to the downstream computing unit to ensure strict data consistency. If configured in performance mode: the module continues to process subsequent computing transactions, while caching the barrier synchronization instruction in a queue with a depth of 6; when the 5th BRESP is returned, there are already 2 subsequent transactions being processed in the queue. After the last 3 BRESPs are returned (total latency about 25 nanoseconds), the module inserts the barrier synchronization instruction into the transaction stream for transmission, with the throughput increased by about 35% and the sender-perceived latency reduced by about 58%. Further, the throughput change depends on the sender's burst ability: if the burst ability is sufficient (i.e., the current ability M ≥ the sufficient demand N), the throughput remains basically unchanged; if the burst ability is insufficient (M < N), the throughput is actually , where 60 / 25 is the latency ratio between conservative mode and performance mode, and the upper limit is the throughput of the theoretical full burst ability of 100%. It is applicable to high-concurrency data processing scenarios.

[0037] In one example, such as Figure 4As shown, the transaction processing circuit also includes a transaction arbitration module. This module connects to the output of the transaction processing pipeline via its input and to a downstream processing module via its output. The transaction processing method further includes: receiving transaction requests diverted to downstream processing modules via the transaction arbitration module, arbitrating the transaction requests, and transmitting the arbitrated transaction requests to the downstream processing modules. The transaction requests include requests that meet the early response conditions and have been processed by the barrier processing module, as well as requests from the transaction diversion module that do not meet the early response conditions and have not been processed by the response processing module. This embodiment, by introducing a transaction arbitration module, aggregates and arbitrates transaction requests from different processing paths (such as requests processed by the early response path and requests from ordinary paths), achieving unified and orderly output of the transaction flow. This design ensures that transactions with different characteristics can be integrated according to a predetermined scheduling strategy when entering the downstream processing module, avoiding conflicts and blockages between paths, thereby guaranteeing the smoothness of the transaction processing pipeline and the fairness of system resources, further improving overall processing efficiency.

[0038] The transaction arbitration module may refer to the hardware component in the circuit responsible for aggregating and arbitrating multiple transaction requests (e.g., Figure 9 Module 8 in the pipeline has its input end connected to the final output end of the transaction processing pipeline, and is used to receive all transaction requests after pipeline processing; the downstream processing module can be configured with a physical communication interface (such as AXI bus master interface or CHI (consistency bus interface) link interface connected to external devices or memory, and is used to transmit the arbitrated transaction requests to the downstream processing module; arbitration can refer to the process of selecting the output order from multiple input transaction requests based on a preset strategy (such as priority scheduling or fair polling) to ensure transaction processing efficiency and fairness.

[0039] Specifically, the circuit can receive transaction request streams from the transaction processing pipeline in real time through the input port of the transaction arbitration module: one request is a request that meets the early response conditions and has been processed by the barrier processing module and the identifier replacement module (such as transactions that have completed synchronization barrier identification and identifier remapping); the other request is a request that does not meet the early response conditions and is directly transmitted from the transaction diversion module to the pipeline (such as atomic operation transactions that require strict order preservation). The transaction arbitration module uses a configurable arbitration strategy (such as weighted round-robin or credit control mechanism based on QoS priority) to dynamically schedule the two requests: for example, prioritizing high-priority transactions (such as real-time computing tasks) while avoiding starvation of low-priority transactions (such as by setting a minimum bandwidth guarantee). After arbitration, the module transmits the ordered transaction request packets (such as AW / W channel data of the AXI protocol or REQ Flit of the CHI protocol) to the downstream processing module through the output port, and is finally sent to the target device by the interface protocol controller (such as PCIe, high-speed peripheral component interconnect interface) controller or DDR (Double Data Rate) memory controller.

[0040] For example, in a distributed GPU inference scenario, the transaction arbitration module receives two types of transaction requests from the transaction processing pipeline: one type is write transactions that meet the early response conditions (such as tensor data writing, address range 0x0000-0xFFFF), which have already undergone synchronization barrier checks (such as DMB instruction recognition) and identifier replacements (such as AWID remapping) by the barrier processing module; the other type is configuration transactions that do not meet the conditions (such as register read / write, which require strict ordering). The ratio of early response transactions to non-early response transactions in the transaction requests is approximately 8:1. The module schedules based on this ratio, processing approximately 9 transaction requests per 100 nanosecond cycle. For example, in the first 10 nanoseconds, the module outputs 8 early response transactions to the downstream AXI bus interface (throughput of approximately 5 gigabits per second), followed by 1 non-early response transaction; the entire arbitration process is conflict-free, with a transaction loss rate of less than 0.1%, significantly improving link utilization.

[0041] In one example, such as Figure 5As shown, the transaction processing circuit also includes an identifier replacement module. This module can be connected to the output of the barrier processing module via its input terminal and to the input of the transaction arbitration module via its output terminal. The transaction processing method further includes: receiving the transaction request output by the barrier processing module through the identifier replacement module, remapping the transaction identifier in the transaction request, and transmitting the remapped transaction request to the transaction arbitration module. This embodiment isolates the identifier space between the upstream data sender and the downstream processing module by introducing an identifier replacement module to remap the transaction identifier. This mechanism prevents identifier conflicts that may be caused by specific requirements or restrictions on transaction identifiers by downstream components, enhancing the circuit's versatility and robustness. Simultaneously, it provides transparent identifier management for the upstream sender, simplifying the sender's design and making the entire transaction processing flow more reliable and easier to maintain.

[0042] The identifier replacement module refers to the hardware component in the circuit responsible for remapping transaction identifiers to maintain downstream uniqueness. It receives transaction requests from the barrier processing module through its input terminal and is connected to the transaction arbitration module through its output terminal to ensure that transaction identifiers do not conflict during transmission. Identifier remapping refers to the process of replacing the original transaction identifier in the transaction request with a new identifier allocated internally by the module, which aims to avoid transaction confusion or errors caused by identifier duplication in downstream processing units. The transaction arbitration module refers to the hardware component responsible for aggregating and arbitrating multiple transaction requests. Its input terminal is connected to the output terminal of the identifier replacement module, and its output terminal is connected to the downstream processing module for scheduling and outputting the remapped transaction requests.

[0043] Specifically, after completing the synchronization barrier processing, the circuit transmits the output transaction request (such as AW / W channel data in the AXI protocol or REQ Flit in the CHI protocol) to the identifier replacement module. The identifier replacement module maintains an identifier pool (such as an ID allocation mechanism based on a FIFO queue). When a transaction request arrives, the module extracts its original transaction identifier (such as AWID in the AXI protocol or TxnID in the CHI protocol) and allocates a new, free identifier from the pool (such as remapping from 0x1 to 0x5), while recording the mapping relationship. After remapping, the module transmits the modified transaction request packet (containing the new identifier) ​​to the transaction arbitration module, which performs output scheduling based on a preset strategy (such as polling or priority scheduling). The entire process ensures that the transaction identifier received by downstream processing units (such as the memory controller) is unique, avoiding protocol errors caused by ID conflicts.

[0044] For example, when the GPU processes an AI inference task, the identifier replacement module receives a write transaction request from the barrier processing module, with its original AWID being 0x1 (hexadecimal). The module allocates a new AWID 0x5 from its internal ID pool (initially containing available IDs 0x5 to 0xA) and updates the transaction packet header information. The remapped transaction request is sent to the transaction arbitration module, which processes 8 transactions per 10 nanosecond cycles and outputs them to the downstream AXI bus interface. During this process, the ID pool is dynamically managed: when a transaction completion response (e.g., response B) is returned, the module reclaims the ID (e.g., reclaiming it to the pool if the BID is 0x5), ensuring ID reuse and no conflicts. This mechanism reduces the ID conflict rate to below 0.01% at a throughput of 5 gigabits per second, significantly improving system reliability.

[0045] In one example, such as Figure 6 As shown, the transaction processing circuit also includes a response splitting module. This module connects to downstream processing modules via a receiving end and to the receiving ends of both the barrier processing module and the response arbitration module via a sending end. The transaction processing method further includes: receiving a hardware transaction completion confirmation signal from the downstream processing module via the response splitting module, and parsing the signal to obtain a transaction identifier; determining whether the corresponding transaction has been prematurely responded to based on the transaction identifier; if it has been prematurely responded to, transmitting the hardware transaction completion confirmation signal to the barrier processing module, and updating the completion status of the barrier synchronization instruction based on the received hardware transaction completion confirmation signal. This implementation introduces a response splitting module, constructing a critical path for the actual completion response feedback to the barrier processing module. This module intelligently splits the hardware transaction completion confirmation signals returned from downstream: directing the actual responses of transactions that have been prematurely responded to to the barrier processing module for updating the synchronization status, while directing the actual responses of transactions that have not been prematurely responded to to the response arbitration module. This mechanism ensures the accuracy of the barrier synchronization instruction completion status judgment and is the core link connecting the premature response mechanism and the semantic correctness of barrier synchronization, ensuring that the system improves performance without sacrificing data consistency.

[0046] The response distribution module refers to the hardware component in the circuit responsible for receiving and distributing downstream responses. It connects to the hardware interface of the downstream processing module (such as the AXI bus slave interface or the CHI link interface) via a receiving end to receive hardware transaction completion confirmation signals from the downstream processing unit. The hardware transaction completion confirmation signal can be a physical completion signal returned by the downstream hardware (such as a memory controller or I / O device) (such as BRESP in the AXI protocol or CompAck in the CHI protocol), indicating that the transaction has been physically completed. The transaction identifier can be a unique identifier for the transaction (such as AX...). The BID of the I protocol or the TxnID of the CHI protocol is used to associate requests and responses; the barrier processing module can refer to the hardware component responsible for processing synchronization barrier instructions, whose receiving end is connected to the sending end of the response splitting module, and is used to update the barrier state based on the completion signal; the response arbitration module can refer to the hardware component responsible for merging and outputting responses, whose receiving end is connected to the sending end of the response splitting module, and is used to process the completion signal of transactions that have not been responded to in advance; updating the completion status of the barrier synchronization instruction can refer to reflecting the completion progress of the preceding transactions by decrementing the internal counter or modifying the state machine flag, so as to ensure the semantic correctness of the barrier.

[0047] Specifically, the circuit monitors the downstream processing module in real time through the receiver of the response splitter module. When it receives a hardware transaction completion confirmation signal (such as a B-channel data packet of the AXI protocol, containing BID and BRESP fields), the module parses the signal to extract the transaction identifier (e.g., decoding the BID value from the BRESP signal). Subsequently, the module queries its internal records or mapping table (e.g., a register-based ID status table) to determine whether the transaction corresponding to the transaction identifier has been responded to prematurely by the response processing module (i.e., whether a fake completion response has been generated). If it was responded to prematurely, the hardware transaction completion confirmation signal is transmitted to the barrier processing module through the sender. The barrier processing module updates its internal state based on this signal (e.g., decrementing the incomplete transaction counter by 1) to track the completion status of all transactions before the barrier synchronization instruction. If it was not responded to prematurely, the hardware transaction completion confirmation signal is transmitted to the response arbitration module through the sender, which directly merges and outputs the results. The entire process is implemented through a hardware state machine with a latency of less than 10 nanoseconds, ensuring real-time performance and reliability.

[0048] For example, in such Figure 6In the transaction processing circuit shown, when the GPU processes AI inference tasks, the response routing module receives a BRESP signal (BID 0x5, BRESP value OKAY) from the downstream AXI bus interface, parses it to obtain the transaction identifier 0x5, queries the internal ID record table (the record shows that the transaction corresponding to BID 0x5 was previously responded to by the response processing module), and transmits the BRESP signal to the barrier processing module through path 19. After receiving the signal, the barrier processing module decrements the incomplete transaction counter from the current value of 8 to 7, and checks whether the counter has returned to zero (if it has returned to zero, it sends a cached barrier synchronization command). In this scenario, the module processes a single response in approximately 5 nanoseconds, supports a throughput of up to 10 gigabits per second, and has an error rate of less than 0.001%, effectively improving system efficiency.

[0049] In one example, such as Figure 7 As shown, the transaction processing circuit also includes a response arbitration module. This module connects to the data sender via its output and to the sender of the response splitting module via its receiver. The transaction processing method further includes: when no early response has been received, receiving the hardware transaction completion confirmation signal from the response splitting module and the early completion response from the response processing module through the response arbitration module; arbitrating and merging the early completion response and the hardware transaction completion confirmation signal; and returning the merged completion response to the data sender. This embodiment introduces a response arbitration module responsible for merging the early completion response from the response processing module and the genuine hardware transaction completion confirmation signal from the response splitting module. This module ensures that for any given transaction, the data sender receives only one completion response, avoiding errors of duplicate or lost responses. This merging mechanism makes the early response transparent to the sender, eliminating the need for the sender to distinguish between genuine and fake responses, thus simplifying upstream design while fully realizing the performance benefits of the early response mechanism.

[0050] The response arbitration module refers to the hardware component in the circuit responsible for aggregating and arbitrating multiple response signals. Its output is connected to the data sending end (such as the response receiving interface of the GPU graphics processor or the host controller), and the receiving end is connected to the sending end of the response splitting module and the output end of the response processing module. It is used to merge real and fake completion responses. The hardware transaction completion confirmation signal refers to the physical completion signal returned by the downstream hardware (such as the memory controller) (such as BRESP of the AXI protocol or CompAck of the CHI protocol), which is used to indicate that the transaction has been actually completed. The early completion response refers to the fake completion signal generated by the response processing module (module 4) (such as the AXI B response containing a virtual BID or CHI RespAck), which is used to release the sending end resources in advance. Arbitration and merging can refer to the process of integrating responses from different sources into a unified output stream according to the protocol specification through a priority scheduling mechanism based on transaction identifier matching.

[0051] Specifically, the circuit uses a response splitting module to determine whether the transaction corresponding to the hardware transaction completion confirmation signal has been responded to in advance. If it has not been responded to in advance (e.g., a configuration register access transaction), the signal is transmitted to the response arbitration module. Simultaneously, the response processing module sends the generated early completion response to the response arbitration module. Internally, the response arbitration module uses a hash mapping table based on transaction identifiers (e.g., BID in the AXI protocol or TxnID in the CHI protocol) for response matching. For the same transaction identifier, only the first received response is retained (prioritizing the early completion response), and the signals are merged using a multiplexer (MUX). The merged response stream is returned to the data sender via the output according to protocol timing requirements (e.g., the VALID / READY handshake protocol of the AXI B channel), ensuring that the response order matches the transaction initiation order. The entire arbitration process has a latency of less than 5 nanoseconds and supports a throughput of up to 8 gigabits per second.

[0052] For example, when the GPU processes image rendering tasks, the response arbitration module simultaneously receives two responses: one is the genuine BRESP signal forwarded by the response splitting module (BID 0x3, BRESP value OKAY, corresponding to a configuration transaction that has not been responded to in advance); the other is a forged B response from the response processing module (BID 0x5, BRESP value OKAY, corresponding to a texture data write transaction that has been responded to in advance). The module detects no conflict with BID 0x3 through its internal hash table and directly outputs the genuine response; if a forged response record already exists for BID 0x5, subsequent genuine responses are discarded. The final merged output sequence is: the response with BID 0x3 is output in the first clock cycle (10 nanoseconds), and the forged response with BID 0x5 is output in the second cycle. This mechanism achieves a response error rate of less than 0.001% at a throughput of 6 gigabits per second, effectively improving the resource reclamation efficiency of the data sending end.

[0053] In one example, such as Figure 8As shown, the transaction processing circuit also includes a buffer module. The buffer module can be connected to the second end of the transaction splitting module via its input terminal and to the response processing module and barrier processing module via its output terminal. The transaction processing method further includes: receiving transaction requests from the transaction splitting module through the buffer module; buffering the received transaction requests; and transmitting the buffered transaction requests sequentially to the response processing module and barrier processing module. This embodiment provides a buffer space for transaction requests that require early response by introducing a buffer module. This design can smooth bursts of transaction flow, absorb temporary blockages that may occur due to barrier processing or downstream backpressure, prevent transaction loss, and maintain the continuous transmission capability of the upstream sender. The presence of the buffer module enhances the circuit's fault tolerance and ability to handle peak loads, and further ensures the continuous and efficient utilization of link bandwidth by improving the elasticity of transaction reception.

[0054] The caching module refers to a hardware component in the circuit responsible for temporarily storing transaction requests. Its input is connected to the output of the transaction routing module, and its output is connected to the response processing module and the barrier processing module, respectively. It is used to buffer transaction information that requires an early response, thereby smoothing traffic peaks and improving system throughput. The transaction routing module refers to a hardware component in the circuit that selects paths based on transaction attribute information, and its second end is connected to the input of the caching module. The response processing module refers to a hardware component in the circuit that generates a forged completion response. The barrier processing module refers to a hardware component in the circuit that processes synchronization barrier instructions. The definitions of the above modules are consistent with the aforementioned embodiments and will not be repeated here.

[0055] Specifically, the circuit uses the decision logic of the transaction diversion module (such as parsing the barrier identifier or address range in the transaction attribute information) to transmit transaction requests that meet the early response conditions (such as non-barrier write transactions) to the input of the cache module through the output. The cache module internally uses a first-in-first-out queue or a circular buffer structure to temporarily store the received transaction requests. The cache depth is configurable (such as 16 or 32 items) to cope with traffic bursts. The cache module transmits the cached transaction requests in parallel through the output to the response processing module (for generating early completion responses) and the barrier processing module (for synchronizing barrier identification and processing) according to the transaction arrival order (i.e., "in sequence"), ensuring the parallelism and data consistency of the transaction processing pipeline. The entire caching and transmission process is controlled by a hardware state machine, with a latency of less than 5 nanoseconds and a throughput of up to 10 gigabits per second.

[0056] For example, in such Figure 8In the transaction processing circuit shown, when the GPU processes AI inference tasks, the transaction routing module identifies a batch of non-barrier write transactions (address range 0x0000-0xFFFF) and transmits them to the cache module via path 10. The cache module uses a FIFO queue with a depth of 8 to cache, storing one transaction request packet (such as AW / W channel data of the AXI protocol) for each item. In the first 10 nanosecond cycle, the cache module receives 5 transactions and transmits them sequentially to the response processing module via path 12, while simultaneously transmitting them to the barrier processing module via path 13. This mechanism enables the system to maintain a zero packet loss rate during peak traffic periods (such as 1000 transactions per second), effectively optimizing system throughput. Furthermore, the degree of throughput improvement depends on the traffic load and the burst capability of the sending end, with cache utilization exceeding 90%.

[0057] In another embodiment, the transaction processing method described above is applied to, for example... Figure 9 The transaction processing circuit shown includes a transaction routing module (module 2) whose input receives transaction requests from the data sender (via path 1). The first output of module 2 is connected to the input of the transaction arbitration module (module 8, hereinafter referred to as the transaction arbitration module). The second output of module 2 (via path 10) is connected to the input of the cache module (module 3). The output of the cache module (module 3) is connected (via path 12) to the input of the forged response module (module 4) and (via path 13) to the input of the synchronization barrier execution module (module 5). The output of the forged response module (module 4) is connected (via path 21) to the input of the response arbitration module (module 9, hereinafter referred to as the response arbitration module). The synchronization barrier execution module... The output of module 5 (via path 14) is connected to the input of the unique identifier replacement module (module 6); the output of the unique identifier replacement module (module 6) (via path 15) is connected to the input of the transaction arbitration module (module 8) (via path 15); the input of the response splitting module (module 7) (via path 17) receives the completion response from the downstream; the first output of the response splitting module (module 7) (via path 19) is connected to the input of the synchronization barrier execution module (module 5); the second output of the response splitting module (module 7) (via path 20) is connected to the input of the response arbitration module (module 9); the output of the response arbitration module (module 9) is connected to the data sending end; the output of the transaction arbitration module (module 8) (via path 16) is connected to the downstream receiving end.

[0058] Specifically, when the transaction routing module (module 2) determines that a transaction request meets the conditions for early response, it sends the transaction's metadata to the cache module (module 3) via path 10 for temporary storage. The cache module (module 3) sends the transaction information to the forged response module (module 4) via path 12 to generate a forged completion response, and to the synchronization barrier execution module (module 5) via path 13 for barrier synchronization processing. The forged completion response generated by the forged response module (module 4) is sent to the response arbitration module (module 9) via path 21. After the transaction is processed by the synchronization barrier execution module (module 5), it is sent to the unique identifier replacement module (module 6) via path 14 for identifier remapping, and then to the transaction arbitration module (module 8) via path 15 for output arbitration. The response routing module (module 7) determines whether the corresponding transaction has been responded to early based on the received completion response (via path 18): if it has been responded to early, it sends the completion response to the synchronization barrier execution module (module 5) via path 19 to update the barrier status; if it has not been responded to early, it sends the completion response to the response arbitration module (module 9) via path 20. The response arbitration module (module 9) arbitrates and merges the metadata from path 10, the forged response from path 21, and the hardware transaction completion confirmation signal (e.g., AXI B response or CHI completion acknowledgment) from path 17, and returns them to the data sender. The transaction arbitration module (module 8) sends the processed transaction from path 15 to the downstream receiver via path 16.

[0059] Taking AXI write transaction processing as an example: When the transaction routing module (module 2) identifies that the write transaction address falls within the preset security range (e.g., 0x0000-0xFFFF) and is not a barrier transaction, it determines that the early response condition is met. The transaction routing module (module 2) sends the transaction ID and other metadata directly to the transaction arbitration module (module 8) via path 11, and simultaneously caches the complete write transaction in the cache module (module 3) via path 10. The cache module (module 3) sends the transaction information in parallel to the forged response module (module 4) via path 12 to generate a B response, and then sends it to the synchronization barrier execution module (module 5) via path 13 for barrier checking. The B response (including the corresponding BID) generated by the forged response module (module 4) is sent to the response arbitration module (module 9) via path 21, and the response arbitration module immediately returns the B response to the host, achieving early response. Meanwhile, after ensuring no barrier conflicts, the synchronization barrier execution module (module 5) sends the transaction via path 14 to the unique identifier replacement module (module 6) for AWID remapping, and then via path 15 through the transaction arbitration module (module 8) and path 16 to finally send it to the memory. When the memory returns a true B response, the response splitting module (module 7) receives the response via path 17, identifies that the transaction corresponding to its BID has been responded to in advance, and then sends the B response to the synchronization barrier execution module (module 5) via path 19 to update its internal state, instead of returning it to the host. In this way, through multi-module parallel processing and response merging mechanism, both low-latency early response and data consistency are achieved.

[0060] In another embodiment, such as Figure 10 As shown, the number of response processing modules and barrier processing modules is the same, and the response processing modules and barrier processing modules constitute one or more independent processing channels. This implementation achieves parallelization of transaction processing by configuring multiple independent processing channels. Each channel can independently configure its synchronization barrier processing mode (conservative or performance-oriented) and caching strategy, enabling the system to perform fine-grained resource allocation and strategy formulation based on the characteristics of different types of transactions (such as real-time requirements and data consistency requirements). This multi-channel architecture effectively avoids the entire system being blocked by a single channel handling a specific type of transaction (such as barrier waiting in conservative mode), improving the parallelism, flexibility, and overall throughput of the system when handling mixed transaction loads.

[0061] Here, an independent processing channel can refer to a parallel processing unit consisting of a pair of matched response processing modules and a barrier processing module (such as...). Figure 10Channels 1 to N each have independent transaction processing capabilities and state maintenance mechanisms; transaction attribute information can refer to metadata fields included in the transaction request (such as the AWUSER field in the AXI protocol or the ReqTxnAttr field in the CHI protocol), including address range, transaction type, and priority attributes; independent transaction requests can refer to independent transaction streams that are hashed and allocated to specific channels based on transaction attribute information, and transaction processing between channels does not block each other; transmission timing control can refer to the time scheduling mechanism of the barrier processing module for issuing barrier synchronization commands based on the configuration mode (conservative / performance mode).

[0062] Specifically, the transaction routing module ( Figure 10 Module 2) can dynamically allocate input transaction requests to multiple independent processing channels (e.g., 8 channels) based on transaction attribute information through a hash calculation unit (e.g., a hash function based on the lower 8 bits of the transaction address). The response processing module within each channel (e.g., module 4 of independent processing channel 1) generates an early completion response (e.g., an AXI B response) for the allocated independent transaction request. Simultaneously, the barrier processing module of that channel (e.g., module 5 of channel 1) performs barrier synchronization instruction identification (e.g., detecting ARM DMB instructions) and transmission timing control (e.g., cache insertion mechanism in performance mode) for the same transaction. Each channel is connected to downstream modules (identifier replacement module 6 and transaction arbitration module, which together form transaction arbitration module 8) via a crossbar to maintain transaction order integrity. A credit-based flow control mechanism is used between channels to avoid resource conflicts; a single channel supports processing 1.5 million transactions per second.

[0063] For example, when an 8-core processor processes an image rendering task, the transaction splitting module evenly distributes 256 texture sampling transactions to 8 independent processing channels (32 transactions per channel) based on pixel block addresses (such as the lower 8 bits of the address hash value). After receiving a transaction, the response processing module of independent processing channel 3 generates a B response (BID 0x33) within 10 nanoseconds and returns it to the GPU core. At the same time, the barrier processing module detects the memory barrier instruction in the transaction sequence and caches it in a queue with a depth of 4 using performance mode. After the BRESP signals of the other 31 transactions in this independent processing channel have all returned (taking about 180 nanoseconds), the barrier instruction is inserted into the transaction stream and sent downstream. The overall system throughput reaches 12.8 gigabits per second, which is about 85% higher than that of a single channel, and the channel utilization is stable at over 92%, effectively solving the problem of insufficient bandwidth utilization caused by multi-core contention.

[0064] In a second aspect, this application provides a transaction processing circuit, which includes a transaction routing module and a response processing module. The transaction processing circuit is configured to: obtain a transaction request from a data sender through the transaction routing module; in response to the transaction attribute information of the transaction request satisfying the early response condition, route the transaction attribute information to the response processing module, extract the transaction identifier from the transaction attribute information through the response processing module, and generate an early completion response based on the transaction identifier to return to the data sender; in response to the transaction attribute information not satisfying the early response condition, route the transaction request to a downstream processing module for transaction processing.

[0065] In a third aspect, this application provides a multi-core processor architecture, including multiple processor cores and a transaction processing circuit as described in the above embodiments; wherein, the transaction routing module in the transaction processing circuit is used to obtain transaction requests from at least one processor core, so that the multi-core processor architecture can execute the transaction processing method configured by the transaction processing circuit.

[0066] For specific limitations on the functionality of transaction processing circuits and multi-core processor architectures, please refer to the above text, which will not be repeated here.

[0067] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

[0068] The transaction processing method and apparatus described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0069] For ease of description, the above apparatus is described by dividing it into functional units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0070] Those skilled in the art will understand that embodiments of this application can provide transaction processing circuitry and multi-core processor architectures, as well as transaction processing methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.

[0071] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0072] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0073] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. Since they are fundamentally similar to the method embodiments, the descriptions are relatively simple; relevant parts can be found in the descriptions of the method embodiments.

[0074] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

[0075] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A transaction processing method, characterized in that, The method is applied to a transaction processing circuit, which includes a transaction routing module and a response processing module; the method includes: The transaction request from the data sender is obtained through the transaction routing module; If the transaction attribute information of the transaction request meets the early response condition, the transaction attribute information is diverted to the response processing module. The response processing module extracts the transaction identifier from the transaction attribute information and generates an early completion response based on the transaction identifier to return to the data sending end. If the transaction attribute information does not meet the early response condition, the transaction request is diverted to the downstream processing module for transaction processing.

2. The method according to claim 1, characterized in that, The transaction processing circuit further includes a barrier processing module; the method further includes: The transaction request is transmitted to the barrier processing module through the transaction diversion module. The barrier processing module identifies the barrier synchronization command for the received transaction request. In response to the detection of a barrier synchronization command, the barrier processing module determines the timing of sending the barrier synchronization command based on a preset configuration mode, and monitors the completion status of all memory access transactions issued before the barrier synchronization command. When the hardware transaction completion confirmation signal of all memory access transactions issued before the barrier synchronization command is detected, the barrier processing module controls the issuance of the barrier synchronization command.

3. The method according to claim 2, characterized in that, In response to the detection of a barrier synchronization command, the barrier processing module determines the timing of sending the barrier synchronization command based on a preset configuration mode, including: If the configuration mode is conservative, when a barrier synchronization command is detected, the barrier processing module blocks the transmission of subsequent transactions in the processing channel where the barrier synchronization command is located, and waits for the hardware transaction completion confirmation signal of all memory access transactions issued before the barrier synchronization command to be returned before sending the barrier synchronization command to the downstream processing module, so as to ensure the correctness of the barrier synchronization semantics. If the configuration mode is performance mode, the barrier processing module will not block the sending of subsequent transactions when it recognizes the barrier synchronization instruction, and will cache the barrier synchronization instruction in the first-in-first-out queue inside the barrier processing module. After the hardware transaction completion confirmation signal of all memory access transactions issued before the barrier synchronization instruction is returned, the barrier processing module will insert the barrier synchronization instruction into the transaction flow of the current transaction processing pipeline and issue it.

4. The method according to claim 2, characterized in that, The transaction processing circuit further includes a transaction arbitration module; the method further includes: The transaction arbitration module receives transaction requests that are diverted to the downstream processing module, arbitrates the transaction requests, and transmits the arbitrated transaction requests to the downstream processing module. The transaction requests include requests that meet the early response conditions and have been processed by the barrier processing module, as well as requests from the transaction diversion module that do not meet the early response conditions and have not been processed by the response processing module.

5. The method according to claim 4, characterized in that, The transaction processing circuit further includes an identifier replacement module; the method further includes: The identifier replacement module receives the transaction request output by the barrier processing module and performs identifier remapping on the transaction identifier in the transaction request so as to transmit the remapped transaction request to the transaction arbitration module.

6. The method according to claim 5, characterized in that, The transaction processing circuit further includes a response splitting module; the method further includes: The response splitting module receives a hardware transaction completion confirmation signal from the downstream processing module and parses the transaction identifier based on the hardware transaction completion confirmation signal. Determine whether the corresponding transaction has been responded to prematurely based on the transaction identifier: If a response has been received in advance, the hardware transaction completion confirmation signal is transmitted to the barrier processing module, which then updates the completion status of the barrier synchronization instruction based on the received hardware transaction completion confirmation signal.

7. The method according to claim 6, characterized in that, The transaction processing circuit further includes a response arbitration module; the method further includes: When no response is received in advance, the response arbitration module receives the hardware transaction completion confirmation signal from the response diversion module and the early completion response from the response processing module. Arbitrate and merge the early completion response with the hardware transaction completion confirmation signal, and return the merged completion response to the data sending end.

8. The method according to claim 7, characterized in that, The transaction processing circuit further includes a cache module; the method further includes: The caching module caches transaction requests from the transaction diversion module and transmits the cached transaction requests sequentially to the response processing module and the barrier processing module.

9. The method according to claim 2, characterized in that, The number of response processing modules is the same as the number of barrier processing modules, and the response processing modules and the barrier processing modules constitute one or more independent processing channels.

10. A transaction processing circuit, characterized in that, The transaction processing circuit includes a transaction routing module and a response processing module; the transaction processing circuit is configured as follows: The transaction request from the data sender is obtained through the transaction routing module; If the transaction attribute information of the transaction request meets the early response condition, the transaction attribute information is diverted to the response processing module. The response processing module extracts the transaction identifier from the transaction attribute information and generates an early completion response based on the transaction identifier to return to the data sending end. If the transaction attribute information does not meet the early response condition, the transaction request is diverted to the downstream processing module for transaction processing.

11. A multi-core processor architecture, characterized in that, The data sending end includes any one of a plurality of processor cores, and a transaction processing circuit as described in claim 10, the transaction processing circuit being configured to implement the method as described in any one of claims 1-9.

Images